draft-ietf-bess-evpn-bum-procedure-updates-07.txt   draft-ietf-bess-evpn-bum-procedure-updates-08.txt 
BESS Z. Zhang BESS Z. Zhang
Internet-Draft W. Lin Internet-Draft W. Lin
Updates: 7432 (if approved) Juniper Networks Updates: 7432 (if approved) Juniper Networks
Intended status: Standards Track J. Rabadan Intended status: Standards Track J. Rabadan
Expires: February 10, 2020 Nokia Expires: May 21, 2020 Nokia
K. Patel K. Patel
Arrcus Arrcus
A. Sajassi A. Sajassi
Cisco Systems Cisco Systems
August 9, 2019 November 18, 2019
Updates on EVPN BUM Procedures Updates on EVPN BUM Procedures
draft-ietf-bess-evpn-bum-procedure-updates-07 draft-ietf-bess-evpn-bum-procedure-updates-08
Abstract Abstract
This document specifies procedure updates for broadcast, unknown This document specifies procedure updates for broadcast, unknown
unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),
including selective multicast, and provider tunnel segmentation. including selective multicast, and provider tunnel segmentation.
This document updates RFC 7432. This document updates RFC 7432.
Requirements Language Requirements Language
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 10, 2020. This Internet-Draft will expire on May 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
3.2. S-PMSI A-D route . . . . . . . . . . . . . . . . . . . . 6 3.2. S-PMSI A-D route . . . . . . . . . . . . . . . . . . . . 6
3.3. Leaf-AD route . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Leaf-AD route . . . . . . . . . . . . . . . . . . . . . . 7
4. Selective Multicast . . . . . . . . . . . . . . . . . . . . . 8 4. Selective Multicast . . . . . . . . . . . . . . . . . . . . . 8
5. Inter-AS Segmentation . . . . . . . . . . . . . . . . . . . . 8 5. Inter-AS Segmentation . . . . . . . . . . . . . . . . . . . . 8
5.1. Changes to Section 7.2.2 of [RFC7117] . . . . . . . . . . 8 5.1. Changes to Section 7.2.2 of [RFC7117] . . . . . . . . . . 8
5.2. I-PMSI Leaf Tracking . . . . . . . . . . . . . . . . . . 10 5.2. I-PMSI Leaf Tracking . . . . . . . . . . . . . . . . . . 10
5.3. Backward Compatibility . . . . . . . . . . . . . . . . . 10 5.3. Backward Compatibility . . . . . . . . . . . . . . . . . 10
5.3.1. Designated ASBR Election . . . . . . . . . . . . . . 12 5.3.1. Designated ASBR Election . . . . . . . . . . . . . . 12
6. Inter-Region Segmentation . . . . . . . . . . . . . . . . . . 12 6. Inter-Region Segmentation . . . . . . . . . . . . . . . . . . 12
6.1. Area/AS vs. Region . . . . . . . . . . . . . . . . . . . 12 6.1. Area/AS vs. Region . . . . . . . . . . . . . . . . . . . 12
6.2. Per-region Aggregation . . . . . . . . . . . . . . . . . 14 6.2. Per-region Aggregation . . . . . . . . . . . . . . . . . 13
6.3. Use of S-NH-EC . . . . . . . . . . . . . . . . . . . . . 15 6.3. Use of S-NH-EC . . . . . . . . . . . . . . . . . . . . . 14
6.4. Ingress PE's I-PMSI Leaf Tracking . . . . . . . . . . . . 15 6.4. Ingress PE's I-PMSI Leaf Tracking . . . . . . . . . . . . 15
7. Multi-homing Support . . . . . . . . . . . . . . . . . . . . 15 7. Multi-homing Support . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Terminology 1. Terminology
It is expected that audience is familiar with EVPN and MVPN concepts It is expected that audience is familiar with EVPN and MVPN concepts
and terminologies. For convenience, the following terms are briefly and terminologies. For convenience, the following terms are briefly
explained. explained.
o PMSI: P-Multicast Service Interface - a conceptual interface for a o PMSI: P-Multicast Service Interface - a conceptual interface for a
PE to send customer multicast traffic to all or some PEs in the PE to send customer multicast traffic to all or some PEs in the
same VPN. same VPN.
skipping to change at page 4, line 39 skipping to change at page 4, line 39
However, it could be at "regional" borders, where a region could be a However, it could be at "regional" borders, where a region could be a
sub-area, or even an entire AS plus its external links (Section 6). sub-area, or even an entire AS plus its external links (Section 6).
That would allow for more flexible deployment scenarios (e.g. for That would allow for more flexible deployment scenarios (e.g. for
single-area provider networks). single-area provider networks).
This document specifies/clarifies/redefines certain/additional EVPN This document specifies/clarifies/redefines certain/additional EVPN
BUM procedures, with a salient goal that they're better aligned among BUM procedures, with a salient goal that they're better aligned among
MVPN, EVPN and VPLS. For brevity, only changes/additions to relevant MVPN, EVPN and VPLS. For brevity, only changes/additions to relevant
[RFC7117] and [RFC7524] procedures are specified, instead of [RFC7117] and [RFC7524] procedures are specified, instead of
repeating the entire procedures. Note that these are to be applied repeating the entire procedures. Note that these are to be applied
to EVPN only, even though sometimes they may sound to be updates to to EVPN only, and not updates to [RFC7117] or [RFC7524].
[RFC7117] or [RFC7524].
2.1. Reasons for Tunnel Segmentation 2.1. Reasons for Tunnel Segmentation
Tunnel segmentation may be required and/or desired because of Tunnel segmentation may be required and/or desired because of
administrative and/or technical reasons. administrative and/or technical reasons.
For example, an MVPN/VPLS/EVPN network may span multiple providers For example, an MVPN/VPLS/EVPN network may span multiple providers
and Inter-AS Option-B has to be used, in which the end-to-end and Inter-AS Option-B has to be used, in which the end-to-end
provider tunnels have to be segmented at and stitched by the ASBRs. provider tunnels have to be segmented at and stitched by the ASBRs.
Different providers may use different tunnel technologies (e.g., Different providers may use different tunnel technologies (e.g.,
skipping to change at page 5, line 48 skipping to change at page 5, line 48
[RFC7432] defines the format of EVPN NLRI as the following: [RFC7432] defines the format of EVPN NLRI as the following:
+-----------------------------------+ +-----------------------------------+
| Route Type (1 octet) | | Route Type (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Length (1 octet) | | Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Route Type specific (variable) | | Route Type specific (variable) |
+-----------------------------------+ +-----------------------------------+
So far eight types have been defined: So far eight types have been defined in [RFC7432],
[I-D.ietf-bess-evpn-prefix-advertisement], and
[I-D.ietf-bess-evpn-igmp-mld-proxy]:
+ 1 - Ethernet Auto-Discovery (A-D) route + 1 - Ethernet Auto-Discovery (A-D) route
+ 2 - MAC/IP Advertisement route + 2 - MAC/IP Advertisement route
+ 3 - Inclusive Multicast Ethernet Tag route + 3 - Inclusive Multicast Ethernet Tag route
+ 4 - Ethernet Segment route + 4 - Ethernet Segment route
+ 5 - IP Prefix Route + 5 - IP Prefix Route
+ 6 - Selective Multicast Ethernet Tag Route + 6 - Selective Multicast Ethernet Tag Route
+ 7 - Multicast Join Synch Route + 7 - Multicast Join Synch Route
+ 8 - Multicast Leave Synch Route + 8 - Multicast Leave Synch Route
skipping to change at page 6, line 35 skipping to change at page 6, line 35
3.1. Per-Region I-PMSI A-D route 3.1. Per-Region I-PMSI A-D route
The Per-region I-PMSI A-D route has the following format. Its usage The Per-region I-PMSI A-D route has the following format. Its usage
is discussed in Section 6.2. is discussed in Section 6.2.
+-----------------------------------+ +-----------------------------------+
| RD (8 octets) | | RD (8 octets) |
+-----------------------------------+ +-----------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+-----------------------------------+ +-----------------------------------+
| Extended Community (8 octets) | | Region ID (8 octets) |
+-----------------------------------+ +-----------------------------------+
After Ethernet Tag ID, an Extended Community (EC) is used to identify The Region ID identifies the region and is encoded just as how an
the region. Various types and sub-types of ECs provide maximum Extended Community is encoded, as detailed in Section 6.2.
flexibility. Note that this is not an EC Attribute, but an 8-octet
field embedded in the NLRI itself, following EC encoding scheme.
3.2. S-PMSI A-D route 3.2. S-PMSI A-D route
The S-PMSI A-D route has the following format: The S-PMSI A-D route has the following format:
+-----------------------------------+ +-----------------------------------+
| RD (8 octets) | | RD (8 octets) |
+-----------------------------------+ +-----------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+-----------------------------------+ +-----------------------------------+
skipping to change at page 8, line 12 skipping to change at page 8, line 12
[RFC7117] has details for VPLS Multicast, and this document points [RFC7117] has details for VPLS Multicast, and this document points
out some specifics for EVPN, e.g. in Section 5. out some specifics for EVPN, e.g. in Section 5.
4. Selective Multicast 4. Selective Multicast
[I-D.ietf-bess-evpn-igmp-mld-proxy] specifies procedures for EVPN [I-D.ietf-bess-evpn-igmp-mld-proxy] specifies procedures for EVPN
selective forwarding of IP multicast using SMET routes. It assumes selective forwarding of IP multicast using SMET routes. It assumes
selective forwarding is always used with IR or BIER for all flows. selective forwarding is always used with IR or BIER for all flows.
An NVE proxies the IGMP/MLD state that it learns on its ACs to An NVE proxies the IGMP/MLD state that it learns on its ACs to
(C-S,C-G) or (C-*,C-G) SMET routes and advertises to other NVEs, and (C-S,C-G) or (C-*,C-G) SMET routes and advertises to other NVEs, and
an receiving NVE converts the SMET routes back to IGMP/MLD messages a receiving NVE converts the SMET routes back to IGMP/MLD messages
and send them out of its ACs. The receiving NVE also uses the SMET and send them out of its ACs. The receiving NVE also uses the SMET
routes to identify which NVEs need to receive traffic for a routes to identify which NVEs need to receive traffic for a
particular (C-S,C-G) or (C-*,C-G) to achieve selective forwarding particular (C-S,C-G) or (C-*,C-G) to achieve selective forwarding
using IR or BIER. using IR or BIER.
With the above procedures, selective forwarding is done for all flows With the above procedures, selective forwarding is done for all flows
and the SMET routes are advertised for all flows. It is possible and the SMET routes are advertised for all flows. It is possible
that an operator may not want to track all those (C-S, C-G) or that an operator may not want to track all those (C-S, C-G) or
(C-*,C-G) state on the NVEs, and the multicast traffic pattern allows (C-*,C-G) state on the NVEs, and the multicast traffic pattern allows
inclusive forwarding for most flows while selective forwarding is inclusive forwarding for most flows while selective forwarding is
needed only for a few high-rate flows. For that, or for tunnel types needed only for a few high-rate flows. For that, or for tunnel types
other than IR/BIER, S-PMSI/Leaf A-D procedures defined for Selective other than IR/BIER, S-PMSI/Leaf A-D procedures defined for Selective
Multicast for VPLS in [RFC7117] are used. Other than that different Multicast for VPLS in [RFC7117] are used. Other than that different
route types and formats are specified with EVPN SAFI for S-PMSI A-D route types and formats are specified with EVPN SAFI for S-PMSI A-D
and Leaf A-D routes (Section 3), all procedures in [RFC7117] with and Leaf A-D routes (Section 3), all procedures in [RFC7117] with
respect to Selective Multicast apply to EVPN as well, including respect to Selective Multicast apply to EVPN as well, including
wildcard procedures. In a nut shell, a source NVE advertises S-SPMSI wildcard procedures. In a nutshell, a source NVE advertises S-PMSI
A-D routes to announce the tunnels used for certain flows, and A-D routes to announce the tunnels used for certain flows, and
receiving NVEs either join the announced PIM/mLDP tunnel or respond receiving NVEs either join the announced PIM/mLDP tunnel or respond
with Leaf A-D routes if the Leaf Information Requested flag is set in with Leaf A-D routes if the Leaf Information Requested flag is set in
the S-PMSI A-D route's PTA (so that the source NVE can include them the S-PMSI A-D route's PTA (so that the source NVE can include them
as tunnel leaves). as tunnel leaves).
An optimization to the [RFC7117] procedures may be applied. Even if An optimization to the [RFC7117] procedures may be applied. Even if
a source NVE sets the LIR bit to request Leaf A-D routes, an egress a source NVE sets the LIR bit to request Leaf A-D routes, an egress
NVE may omit the Leaf A-D route if it already advertises a NVE MAY omit the Leaf A-D route if it has already advertised a
corresponding SMET route, and the source NVE will use that in lieu of corresponding SMET route, and the source NVE MUST use that in lieu of
the Leaf A-D route. the Leaf A-D route.
The optional optimizations specified for MVPN in [RFC8534] are also The optional optimizations specified for MVPN in [RFC8534] are also
applicable to EVPN when the S-PMSI/Leaf A-D routes procedures are applicable to EVPN when the S-PMSI/Leaf A-D routes procedures are
used for EVPN selective multicast forwarding. used for EVPN selective multicast forwarding.
5. Inter-AS Segmentation 5. Inter-AS Segmentation
5.1. Changes to Section 7.2.2 of [RFC7117] 5.1. Changes to Section 7.2.2 of [RFC7117]
skipping to change at page 9, line 23 skipping to change at page 9, line 23
for the ASBRs to reach agreement. For EVPN, a different approach is for the ASBRs to reach agreement. For EVPN, a different approach is
used and the above quoted text is not applicable to EVPN. used and the above quoted text is not applicable to EVPN.
With the different approach for EVPN, each ASBR will re-advertise its With the different approach for EVPN, each ASBR will re-advertise its
received Inter-AS A-D route to its IBGP peers and becomes the root of received Inter-AS A-D route to its IBGP peers and becomes the root of
an intra-AS segment of the inter-AS tree. The intra-AS segment an intra-AS segment of the inter-AS tree. The intra-AS segment
rooted at one ASBR is disjoint with another intra-AS segment rooted rooted at one ASBR is disjoint with another intra-AS segment rooted
at another ASBR. This is the same as the procedures for S-PMSI in at another ASBR. This is the same as the procedures for S-PMSI in
[RFC7117] itself. [RFC7117] itself.
The following text at the end of the second bullet: The first bullet does not apply to EVPN.
"................................................... If, in order
to instantiate the segment, the ASBR needs to know the leaves of
the tree, then the ASBR obtains this information from the A-D
routes received from other PEs/ASBRs in the ASBR's own AS."
is changed to the following when applied to EVPN: The second bullet is changed to the following when applied to EVPN:
"................................................... If, in order "The PMSI Tunnel attribute MUST specify the tunnel for the segment.
to instantiate the segment, the ASBR needs to know the leaves of If and only if, in order
the tree, then the ASBR MUST set the LIR flag to 1 in the PTA to to establish the tunnel, the ASBR needs to know the leaves of
trigger Leaf A-D routes from egress PEs and downstream ASBRs. the tree, then the ASBR MUST set the LIR flag to 1 in the PTA to
It MUST be (auto-)configured with an import RT, which controls trigger Leaf A-D routes from egress PEs and downstream ASBRs.
acceptance of leaf A-D routes by the ASBR." It MUST be (auto-)configured with an import RT, which controls
acceptance of leaf A-D routes by the ASBR."
Accordingly, the following paragraph in Section 7.2.2.4: Accordingly, the following paragraph in Section 7.2.2.4:
"If the received Inter-AS A-D route carries the PMSI Tunnel attribute "If the received Inter-AS A-D route carries the PMSI Tunnel attribute
with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR
that originated the route MUST establish an RSVP-TE P2MP LSP with the that originated the route MUST establish an RSVP-TE P2MP LSP with the
local PE/ASBR as a leaf. This LSP MAY have been established before local PE/ASBR as a leaf. This LSP MAY have been established before
the local PE/ASBR receives the route, or it MAY be established after the local PE/ASBR receives the route, or it MAY be established after
the local PE receives the route." the local PE receives the route."
is changed to the following when applied to EVPN: is changed to the following when applied to EVPN:
"If the received Inter-AS A-D route has the LIR flag set in its PTA, "If the received Inter-AS A-D route has the LIR flag set in its PTA,
then a receiving PE must originate a corresponding Leaf A-D route, then a receiving PE MUST originate a corresponding Leaf A-D route,
and a receiving ASBR must originate a corresponding Leaf A-D route if while a receiving ASBR MUST originate a corresponding Leaf A-D route
and only if it received and imported one or more corresponding Leaf if and only if it received and imported one or more corresponding
A-D routes from its downstream IBGP or EBGP peers, or it has non-null Leaf A-D routes from its downstream IBGP or EBGP peers, or it has
downstream forwarding state for the PIM/mLDP tunnel that instantiates non-null downstream forwarding state for the PIM/mLDP tunnel that
its downstream intra-AS segment. The ASBR that (re-)advertised the instantiates its downstream intra-AS segment. The targeted ASBR for
Inter-AS A-D route then establishes a tunnel to the leaves discovered the Leaf A-D route, which (re-)advertised the Inter-AS A-D route,
by the Leaf A-D routes." MUST establish a tunnel to the leaves discovered by the Leaf A-D
routes."
5.2. I-PMSI Leaf Tracking 5.2. I-PMSI Leaf Tracking
An ingress PE does not set the LIR flag in its I-PMSI's PTA, even An ingress PE does not set the LIR flag in its Inclusive Multicast
with Ingress Replication or RSVP-TE P2MP tunnels. It does not rely Ethernet Tag (IMET) A-D route's PTA, even with Ingress Replication or
on the Leaf A-D routes to discover leaves in its AS, and Section 11.2 RSVP-TE P2MP tunnels. It does not rely on the Leaf A-D routes to
of [RFC7432] explicitly states that the LIR flag must be set to zero. discover leaves in its AS, and Section 11.2 of [RFC7432] explicitly
states that the LIR flag must be set to zero.
An implementation of [RFC7432] might have used the Originating An implementation of [RFC7432] might have used the Originating
Router's IP Address field of the Inclusive Multicast Ethernet Tag Router's IP Address field of the IMET A-D routes to determine the
routes to determine the leaves, or might have used the Next Hop field leaves, or might have used the Next Hop field instead. Within the
instead. Within the same AS, both will lead to the same result. same AS, both will lead to the same result.
With segmentation, an ingress PE MUST determine the leaves in its AS With segmentation, an ingress PE MUST determine the leaves in its AS
from the BGP next hops in all its received I-PMSI A-D routes, so it from the BGP next hops in all its received IMET A-D routes, so it
does not have to set the LIR bit set to request Leaf A-D routes. PEs does not have to set the LIR bit set to request Leaf A-D routes. PEs
within the same AS will all have different next hops in their I-PMSI within the same AS will all have different next hops in their IMET
A-D routes (hence will all be considered as leaves), and PEs from A-D routes (hence will all be considered as leaves), and PEs from
other ASes will have the next hop in their I-PMSI A-D routes set to other ASes will have the next hop in their IMET A-D routes set to
addresses of ASBRs in this local AS, hence only those ASBRs will be addresses of ASBRs in this local AS, hence only those ASBRs will be
considered as leaves (as proxies for those PEs in other ASes). Note considered as leaves (as proxies for those PEs in other ASes). Note
that in case of Ingress Replication, when an ASBR re-advertises IBGP that in case of Ingress Replication, when an ASBR re-advertises IMET
I-PMSI A-D routes, it MUST advertise the same label for all those for A-D routes to IBGP peers, it MUST advertise the same label for all
the same Ethernet Tag ID and the same EVI. When an ingress PE builds those for the same Ethernet Tag ID and the same EVI. When an ingress
its flooding list, multiple routes may have the same (nexthop, label) PE builds its flooding list, multiple routes might have the same
tuple and they will only be added as a single branch in the flooding (nexthop, label) tuple and they MUST only be added as a single branch
list. in the flooding list.
5.3. Backward Compatibility 5.3. Backward Compatibility
The above procedures assume that all PEs are upgraded to support the The above procedures assume that all PEs are upgraded to support the
segmentation procedures: segmentation procedures:
o An ingress PE uses the Next Hop instead of Originating Router's IP o An ingress PE uses the Next Hop instead of Originating Router's IP
Address to determine leaves for the I-PMSI tunnel. Address to determine leaves for the I-PMSI tunnel.
o An egress PE sends Leaf A-D routes in response to I-PMSI routes, o An egress PE sends Leaf A-D routes in response to I-PMSI routes,
skipping to change at page 14, line 38 skipping to change at page 14, line 26
MVPN does not aggregate S-PMSI routes from all PEs in an AS like it MVPN does not aggregate S-PMSI routes from all PEs in an AS like it
does for I-PMSIs routes, because the number of PEs that will does for I-PMSIs routes, because the number of PEs that will
advertise S-PMSI routes for the same (s,g) or (*,g) is small. This advertise S-PMSI routes for the same (s,g) or (*,g) is small. This
is also the case for EVPN, i.e., there is no per-region S-PMSI is also the case for EVPN, i.e., there is no per-region S-PMSI
routes. routes.
Notice that per-region I-PMSI routes can also be used to address Notice that per-region I-PMSI routes can also be used to address
backwards compatibility issue, as discussed in Section 5.3. backwards compatibility issue, as discussed in Section 5.3.
The per-region I-PMSI route uses an embedded EC in NLRI to identify a The Region ID in the per-region I-PMSI route's NLRI is encoded like
region. As long as it uniquely identifies the region and the RBRs an EC. For example, the Region ID can encode an AS number or area ID
for the same region uses the same EC it is permitted. For example, in the following EC format:
an AS number or area ID can be used to as following:
o For a two-octet AS number, a Transitive Two-Octet AS-Specific EC o For a two-octet AS number, a Transitive Two-Octet AS-Specific EC
of sub-type 0x09 (Source AS), with the Global Administrator sub- of sub-type 0x09 (Source AS), with the Global Administrator sub-
field set to the AS number and the Local Administrator sub-field field set to the AS number and the Local Administrator sub-field
set to 0. set to 0.
o For a four-octet AS number, a Transitive Four-Octet AS-Specific EC o For a four-octet AS number, a Transitive Four-Octet AS-Specific EC
of sub-type 0x09 (Source AS), with the Global Administrator sub- of sub-type 0x09 (Source AS), with the Global Administrator sub-
field set to the AS number and the Local Administrator sub-field field set to the AS number and the Local Administrator sub-field
set to 0. set to 0.
o For an area ID, a Transitive IPv4-Address-Specific EC of any sub- o For an area ID, a Transitive IPv4-Address-Specific EC of any sub-
type, with the Global Administrator sub-field set to the area ID type, with the Global Administrator sub-field set to the area ID
and the Local Administrator sub-field set to 0. and the Local Administrator sub-field set to 0.
Uses of other particular ECs may be specified in other documents. Uses of other EC encoding MAY be allowed as long as it uniquely
identifies the region and the RBRs for the same region uses the same
Region ID.
6.3. Use of S-NH-EC 6.3. Use of S-NH-EC
[RFC7524] specifies the use of S-NH-EC because it does not allow ABRs [RFC7524] specifies the use of S-NH-EC because it does not allow ABRs
to change the BGP next hop when they re-advertise I/S-PMSI AD routes to change the BGP next hop when they re-advertise I/S-PMSI AD routes
to downstream areas. That is only to be consistent with the MVPN to downstream areas. That is only to be consistent with the MVPN
Inter-AS I-PMSI A-D routes, whose next hop must not be changed when Inter-AS I-PMSI A-D routes, whose next hop must not be changed when
they're re-advertised by the segmenting ABRs for reasons specific to they're re-advertised by the segmenting ABRs for reasons specific to
MVPN. For EVPN, it is perfectly fine to change the next hop when MVPN. For EVPN, it is perfectly fine to change the next hop when
RBRs re-advertise the I/S-PMSI A-D routes, instead of relying on S- RBRs re-advertise the I/S-PMSI A-D routes, instead of relying on S-
skipping to change at page 17, line 26 skipping to change at page 16, line 48
Beijing 100095 Beijing 100095
China China
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-bess-evpn-igmp-mld-proxy] [I-D.ietf-bess-evpn-igmp-mld-proxy]
Sajassi, A., Thoria, S., Patel, K., Yeung, D., Drake, J., Sajassi, A., Thoria, S., Patel, K., Drake, J., and W. Lin,
and W. Lin, "IGMP and MLD Proxy for EVPN", draft-ietf- "IGMP and MLD Proxy for EVPN", draft-ietf-bess-evpn-igmp-
bess-evpn-igmp-mld-proxy-03 (work in progress), June 2019. mld-proxy-04 (work in progress), September 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and [RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and
C. Kodeboniya, "Multicast in Virtual Private LAN Service C. Kodeboniya, "Multicast in Virtual Private LAN Service
(VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014,
<https://www.rfc-editor.org/info/rfc7117>. <https://www.rfc-editor.org/info/rfc7117>.
skipping to change at page 18, line 27 skipping to change at page 17, line 48
<https://www.rfc-editor.org/info/rfc8534>. <https://www.rfc-editor.org/info/rfc8534>.
[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, [RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
VPN Designated Forwarder Election Extensibility", VPN Designated Forwarder Election Extensibility",
RFC 8584, DOI 10.17487/RFC8584, April 2019, RFC 8584, DOI 10.17487/RFC8584, April 2019,
<https://www.rfc-editor.org/info/rfc8584>. <https://www.rfc-editor.org/info/rfc8584>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-bess-evpn-prefix-advertisement]
Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A.
Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf-
bess-evpn-prefix-advertisement-11 (work in progress), May
2018.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to- Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875, Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007, DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/info/rfc4875>. <https://www.rfc-editor.org/info/rfc4875>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point- Thomas, "Label Distribution Protocol Extensions for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched to-Multipoint and Multipoint-to-Multipoint Label Switched
 End of changes. 28 change blocks. 
68 lines changed or deleted 72 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/