draft-ietf-bess-evpn-bum-procedure-updates-06.txt   draft-ietf-bess-evpn-bum-procedure-updates-07.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: December 19, 2019 Nokia Expires: February 10, 2020 Nokia
K. Patel K. Patel
Arrcus Arrcus
A. Sajassi A. Sajassi
Cisco Systems Cisco Systems
June 17, 2019 August 9, 2019
Updates on EVPN BUM Procedures Updates on EVPN BUM Procedures
draft-ietf-bess-evpn-bum-procedure-updates-06 draft-ietf-bess-evpn-bum-procedure-updates-07
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.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC2119. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 19, 2019. This Internet-Draft will expire on February 10, 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 31 skipping to change at page 2, line 31
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Reasons for Tunnel Segmentation . . . . . . . . . . . . . 4 2.1. Reasons for Tunnel Segmentation . . . . . . . . . . . . . 4
3. Additional Route Types of EVPN NLRI . . . . . . . . . . . . . 5 3. Additional Route Types of EVPN NLRI . . . . . . . . . . . . . 5
3.1. Per-Region I-PMSI A-D route . . . . . . . . . . . . . . . 6 3.1. Per-Region I-PMSI A-D route . . . . . . . . . . . . . . . 6
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 RFC 7117 . . . . . . . . . . 9 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 vs. Region . . . . . . . . . . . . . . . . . . . . . 12 6.1. Area/AS vs. Region . . . . . . . . . . . . . . . . . . . 12
6.2. Per-region Aggregation . . . . . . . . . . . . . . . . . 14 6.2. Per-region Aggregation . . . . . . . . . . . . . . . . . 14
6.3. Use of S-NH-EC . . . . . . . . . . . . . . . . . . . . . 15 6.3. Use of S-NH-EC . . . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 3, line 31 skipping to change at page 3, line 31
o IMET A-D route: Inclusive Multicast Ethernet Tag A-D route. The o IMET A-D route: Inclusive Multicast Ethernet Tag A-D route. The
EVPN equivalent of MVPN Intra-AS I-PMSI A-D route. EVPN equivalent of MVPN Intra-AS I-PMSI A-D route.
o SMET A-D route: Selective Multicast Ethernet Tag A-D route. The o SMET A-D route: Selective Multicast Ethernet Tag A-D route. The
EVPN equivalent of MVPN Leaf A-D route but unsolicited and EVPN equivalent of MVPN Leaf A-D route but unsolicited and
untargeted. untargeted.
2. Introduction 2. Introduction
RFC 7432 specifies procedures to handle broadcast, unknown unicast, [RFC7432] specifies procedures to handle broadcast, unknown unicast,
and multicast (BUM) traffic in Section 11, 12 and 16, using Inclusive and multicast (BUM) traffic in Section 11, 12 and 16, using Inclusive
Multicast Ethernet Tag Route. A lot of details are referred to RFC Multicast Ethernet Tag Route. A lot of details are referred to
7117 (VPLS Multicast). In particular, selective multicast is briefly [RFC7117] (VPLS Multicast). In particular, selective multicast is
mentioned for Ingress Replication but referred to RFC 7117. briefly mentioned for Ingress Replication but referred to [RFC7117].
RFC 7117 specifies procedures for using both inclusive tunnels and [RFC7117] specifies procedures for using both inclusive tunnels and
selective tunnels, similar to MVPN procedures specified in RFC 6513 selective tunnels, similar to MVPN procedures specified in [RFC6513]
and RFC 6514. A new SAFI "MCAST-VPLS" is introduced, with two types and [RFC6514]. A new SAFI "MCAST-VPLS" is introduced, with two types
of NLRIs that match MVPN's S-PMSI A-D routes and Leaf A-D routes. of NLRIs that match MVPN's S-PMSI A-D routes and Leaf A-D routes.
The same procedures can be applied to EVPN selective multicast for The same procedures can be applied to EVPN selective multicast for
both Ingress Replication and other tunnel types, but new route types both Ingress Replication and other tunnel types, but new route types
need to be defined under the same EVPN SAFI. need to be defined under the same EVPN SAFI.
MVPN uses terms I-PMSI and S-PMSI A-D Routes. For consistency and MVPN uses terms I-PMSI and S-PMSI A-D Routes. For consistency and
convenience, this document will use the same I/S-PMSI terms for VPLS convenience, this document will use the same I/S-PMSI terms for VPLS
and EVPN. In particular, EVPN's Inclusive Multicast Ethernet Tag and EVPN. In particular, EVPN's Inclusive Multicast Ethernet Tag
Route and VPLS's VPLS A-D route carrying PTA (PMSI Tunnel Attribute) Route and VPLS's VPLS A-D route carrying PTA (PMSI Tunnel Attribute)
for BUM traffic purpose will all be referred to as I-PMSI A-D routes. for BUM traffic purpose will all be referred to as I-PMSI A-D routes.
Depending on the context, they may be used interchangeably. Depending on the context, they may be used interchangeably.
MVPN provider tunnels and EVPN/VPLS BUM provider tunnels, which are MVPN provider tunnels and EVPN/VPLS BUM provider tunnels, which are
referred to as MVPN/EVPN/VPLS provider tunnels in this document for referred to as MVPN/EVPN/VPLS provider tunnels in this document for
simplicity, can be segmented for technical or administrative reasons, simplicity, can be segmented for technical or administrative reasons,
which are summarized in Section 2.1 of this document. RFC 6513/6514 which are summarized in Section 2.1 of this document. [RFC6513] and
cover MVPN inter-as segmentation, RFC 7117 covers VPLS multicast [RFC6514] cover MVPN inter-as segmentation, [RFC7117] covers VPLS
inter-as segmentation, and RFC 7524 (Seamless MPLS Multicast) covers multicast inter-as segmentation, and [RFC7524] (Seamless MPLS
inter-area segmentation for both MVPN and VPLS. Multicast) covers inter-area segmentation for both MVPN and VPLS.
There is a difference between MVPN and VPLS multicast inter-as There is a difference between MVPN and VPLS multicast inter-as
segmentation. For simplicity, EVPN will use the same procedures as segmentation. For simplicity, EVPN will use the same procedures as
in MVPN. All ASBRs can re-advertise their choice of the best route. in MVPN. All ASBRs can re-advertise their choice of the best route.
Each can become the root of its intra-AS segment and inject traffic Each can become the root of its intra-AS segment and inject traffic
it receives from its upstream, while each downstream PE/ASBR will it receives from its upstream, while each downstream PE/ASBR will
only pick one of the upstream ASBRs as its upstream. This is also only pick one of the upstream ASBRs as its upstream. This is also
the behavior even for VPLS in case of inter-area segmentation. the behavior even for VPLS in case of inter-area segmentation.
For inter-area segmentation, RFC 7524 requires the use of Inter-area For inter-area segmentation, [RFC7524] requires the use of Inter-area
P2MP Segmented Next-Hop Extended Community (S-NH-EC), and the setting P2MP Segmented Next-Hop Extended Community (S-NH-EC), and the setting
of "Leaf Information Required" (LIR) flag in PTA in certain of "Leaf Information Required" (LIR) flag in PTA in certain
situations. Either of these could be optional in case of EVPN. situations. Either of these could be optional in case of EVPN.
Removing these requirements would make the segmentation procedures Removing these requirements would make the segmentation procedures
transparent to ingress and egress PEs. transparent to ingress and egress PEs.
RFC 7524 assumes that segmentation happens at area borders. However, [RFC7524] assumes that segmentation happens at area borders.
it could be at "regional" borders, where a region could be a sub- However, it could be at "regional" borders, where a region could be a
area, or even an entire AS plus its external links (Section 6). That sub-area, or even an entire AS plus its external links (Section 6).
would allow for more flexible deployment scenarios (e.g. for single- That would allow for more flexible deployment scenarios (e.g. for
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
RFC 7117 and RFC 7524 procedures are specified, instead of repeating [RFC7117] and [RFC7524] procedures are specified, instead of
the entire procedures. Note that these are to be applied to EVPN repeating the entire procedures. Note that these are to be applied
only, even though sometimes they may sound to be updates to RFC to EVPN only, even though sometimes they may sound to be updates to
7117/7524. [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.,
provider A uses Ingress Replication, provider B uses RSVP-TE P2MP provider A uses Ingress Replication [RFC7988], provider B uses RSVP-
while provider C uses mLDP). Even if they use the same tunnel TE P2MP [RFC4875] while provider C uses mLDP [RFC6388]). Even if
technology like RSVP-TE P2MP, it may be impractical to set up the they use the same tunnel technology like RSVP-TE P2MP, it may be
tunnels across provider boundaries. impractical to set up the tunnels across provider boundaries.
The same situations may apply between the ASes and/or areas of a The same situations may apply between the ASes and/or areas of a
single provider. For example, the backbone area may use RSVP-TE P2MP single provider. For example, the backbone area may use RSVP-TE P2MP
tunnels while non-backbone areas may use mLDP tunnels. tunnels while non-backbone areas may use mLDP tunnels.
Segmentation can also be used to divide an AS/area to smaller Segmentation can also be used to divide an AS/area to smaller
regions, so that control plane state and/or forwarding plane state/ regions, so that control plane state and/or forwarding plane state/
burden can be limited to that of individual regions. For example, burden can be limited to that of individual regions. For example,
instead of Ingress Replicating to 100 PEs in the entire AS, with instead of Ingress Replicating to 100 PEs in the entire AS, with
inter-area segmentation [RFC 7524] a PE only needs to replicate to inter-area segmentation [RFC7524] a PE only needs to replicate to
local PEs and ABRs. The ABRs will further replicate to their local PEs and ABRs. The ABRs will further replicate to their
downstream PEs and ABRs. This not only reduces the forwarding plane downstream PEs and ABRs. This not only reduces the forwarding plane
burden, but also reduces the leaf tracking burden in the control burden, but also reduces the leaf tracking burden in the control
plane. plane.
Smaller regions also have the benefit that, in case of tunnel Smaller regions also have the benefit that, in case of tunnel
aggregation, it is easier to find congruence among the segments of aggregation, it is easier to find congruence among the segments of
different constituent (service) tunnels and the resulting aggregation different constituent (service) tunnels and the resulting aggregation
(base) tunnel in a region. This leads to better bandwidth (base) tunnel in a region. This leads to better bandwidth
efficiency, because the more congruent they are, the fewer leaves of efficiency, because the more congruent they are, the fewer leaves of
the base tunnel need to discard traffic when a service tunnel's the base tunnel need to discard traffic when a service tunnel's
segment does not need to receive the traffic (yet it is receiving the segment does not need to receive the traffic (yet it is receiving the
traffic due to aggregation). traffic due to aggregation).
Another advantage of the smaller region is smaller BIER sub-domains. Another advantage of the smaller region is smaller BIER sub-domains.
In this new multicast architecture BIER, packets carry a BitString, In this new multicast architecture BIER [RFC8279], packets carry a
in which the bits correspond to edge routers that needs to receive BitString, in which the bits correspond to edge routers that needs to
traffic. Smaller sub-domains means smaller BitStrings can be used receive traffic. Smaller sub-domains means smaller BitStrings can be
without having to send multiple copies of the same packet. used without having to send multiple copies of the same packet.
3. Additional Route Types of EVPN NLRI 3. Additional Route Types of EVPN NLRI
RFC 7432 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:
skipping to change at page 7, line 24 skipping to change at page 7, line 24
| Multicast Group Length (1 octet) | | Multicast Group Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Multicast Group (Variable) | | Multicast Group (Variable) |
+-----------------------------------+ +-----------------------------------+
|Originator's Addr Length (1 octet) | |Originator's Addr Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
|Originator's Addr (4 or 16 octets) | |Originator's Addr (4 or 16 octets) |
+-----------------------------------+ +-----------------------------------+
Other than the addition of Ethernet Tag ID and Originator's Addr Other than the addition of Ethernet Tag ID and Originator's Addr
Length, it is identical to the S-PMSI A-D route as defined in RFC Length, it is identical to the S-PMSI A-D route as defined in
7117. The procedures in RFC 7117 also apply (including wildcard [RFC7117]. The procedures in [RFC7117] also apply (including
functionality), except that the granularity level is per Ethernet wildcard functionality), except that the granularity level is per
Tag. Ethernet Tag.
3.3. Leaf-AD route 3.3. Leaf-AD route
The Route Type specific field of a Leaf A-D route consists of the The Route Type specific field of a Leaf A-D route consists of the
following: following:
+-----------------------------------+ +-----------------------------------+
| Route Key (variable) | | Route Key (variable) |
+-----------------------------------+ +-----------------------------------+
|Originator's Addr Length (1 octet) | |Originator's Addr Length (1 octet) |
skipping to change at page 7, line 49 skipping to change at page 7, line 49
|Originator's Addr (4 or 16 octets) | |Originator's Addr (4 or 16 octets) |
+-----------------------------------+ +-----------------------------------+
A Leaf A-D route is originated in response to a PMSI route, which A Leaf A-D route is originated in response to a PMSI route, which
could be an Inclusive Multicast Tag route, a per-region I-PMSI A-D could be an Inclusive Multicast Tag route, a per-region I-PMSI A-D
route, an S-PMSI A-D route, or some other types of routes that may be route, an S-PMSI A-D route, or some other types of routes that may be
defined in the future that triggers Leaf A-D routes. The Route Key defined in the future that triggers Leaf A-D routes. The Route Key
is the "Route Type Specific" field of the route for which this Leaf is the "Route Type Specific" field of the route for which this Leaf
A-D route is generated. A-D route is generated.
The general procedures of Leaf A-D route are first specified in RFC The general procedures of Leaf A-D route are first specified in
6514 for MVPN. The principles apply to VPLS and EVPN as well. RFC [RFC6514] for MVPN. The principles apply to VPLS and EVPN as well.
7117 has details for VPLS Multicast, and this document points out [RFC7117] has details for VPLS Multicast, and this document points
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 an 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
skipping to change at page 8, line 42 skipping to change at page 8, line 42
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 already advertises a
corresponding SMET route, and the source NVE will use that in lieu of corresponding SMET route, and the source NVE will use that in lieu of
the Leaf A-D route. the Leaf A-D route.
The optional optimizations specified for MVPN in The optional optimizations specified for MVPN in [RFC8534] are also
[I-D.ietf-bess-mvpn-expl-track] are also applicable to EVPN when the applicable to EVPN when the S-PMSI/Leaf A-D routes procedures are
S-PMSI/Leaf A-D routes procedures are used for EVPN selective used for EVPN selective multicast forwarding.
multicast forwarding.
5. Inter-AS Segmentation 5. Inter-AS Segmentation
5.1. Changes to Section 7.2.2 of RFC 7117
The first paragraph of Section 7.2.2.2 of RFC 7117 says: 5.1. Changes to Section 7.2.2 of [RFC7117]
"... The best route procedures ensure that if multiple The first paragraph of Section 7.2.2.2 of [RFC7117] says:
ASBRs, in an AS, receive the same Inter-AS A-D route from their EBGP
neighbors, only one of these ASBRs propagates this route in Internal "... The best route procedures ensure that if multiple
BGP (IBGP). This ASBR becomes the root of the intra-AS segment of ASBRs, in an AS, receive the same Inter-AS A-D route from their EBGP
the inter-AS tree and ensures that this is the only ASBR that accepts neighbors, only one of these ASBRs propagates this route in Internal
traffic into this AS from the inter-AS tree." BGP (IBGP). This ASBR becomes the root of the intra-AS segment of
the inter-AS tree and ensures that this is the only ASBR that accepts
traffic into this AS from the inter-AS tree."
The above VPLS behavior requires complicated VPLS specific procedures The above VPLS behavior requires complicated VPLS specific procedures
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
RFC 7117 itself. [RFC7117] itself.
The following text at the end of the second bullet: The following text at the end of the second bullet:
"................................................... If, in order "................................................... If, in order
to instantiate the segment, the ASBR needs to know the leaves of to instantiate the segment, the ASBR needs to know the leaves of
the tree, then the ASBR obtains this information from the A-D the tree, then the ASBR obtains this information from the A-D
routes received from other PEs/ASBRs in the ASBR's own AS." routes received from other PEs/ASBRs in the ASBR's own AS."
is changed to the following when applied to EVPN: is changed to the following when applied to EVPN:
"................................................... If, in order "................................................... If, in order
to instantiate the segment, the ASBR needs to know the leaves of to instantiate the segment, the ASBR needs to know the leaves of
the tree, then the ASBR MUST set the LIR flag to 1 in the PTA to the tree, then the ASBR MUST set the LIR flag to 1 in the PTA to
trigger Leaf A-D routes from egress PEs and downstream ASBRs. trigger Leaf A-D routes from egress PEs and downstream ASBRs.
It MUST be (auto-)configured with an import RT, which controls It MUST be (auto-)configured with an import RT, which controls
acceptance of leaf A-D routes by the ASBR." 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 and a receiving ASBR must originate a corresponding Leaf A-D route if
if and only if it received and imported one or more corresponding Leaf and only if it received and imported one or more corresponding Leaf
A-D routes from its downstream IBGP or EBGP peers, or it has non-null A-D routes from its downstream IBGP or EBGP peers, or it has non-null
downstream forwarding state for the PIM/mLDP tunnel that instantiates downstream forwarding state for the PIM/mLDP tunnel that instantiates
its downstream intra-AS segment. The ASBR that (re-)advertised the its downstream intra-AS segment. The ASBR that (re-)advertised the
Inter-AS A-D route then establishes a tunnel to the leaves discovered Inter-AS A-D route then establishes a tunnel to the leaves discovered
by the Leaf A-D routes." 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 I-PMSI's PTA, even
with Ingress Replication or RSVP-TE P2MP tunnels. It does not rely with Ingress Replication or RSVP-TE P2MP tunnels. It does not rely
on the Leaf A-D routes to discover leaves in its AS, and Section 11.2 on the Leaf A-D routes to discover leaves in its AS, and Section 11.2
of RFC 7432 explicitly states that the LIR flag must be set to zero. of [RFC7432] explicitly states that the LIR flag must be set to zero.
An implementation of RFC 7432 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 Inclusive Multicast Ethernet Tag
routes to determine the leaves, or might have used the Next Hop field routes to determine the leaves, or might have used the Next Hop field
instead. Within the same AS, both will lead to the same result. instead. Within the 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 I-PMSI 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 I-PMSI
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 I-PMSI A-D routes set to
skipping to change at page 12, line 16 skipping to change at page 12, line 13
of per-region I-PMSI has the benefit of keeping all per-PE I-PMSI A-D of per-region I-PMSI has the benefit of keeping all per-PE I-PMSI A-D
routes in their local ASes, greatly reducing the flooding of the routes in their local ASes, greatly reducing the flooding of the
routes and their corresponding Leaf A-D routes (when needed), and the routes and their corresponding Leaf A-D routes (when needed), and the
number of inter-as tunnels. number of inter-as tunnels.
5.3.1. Designated ASBR Election 5.3.1. Designated ASBR Election
When an ASBR re-advertises a per-region I-PMSI A-D route into an AS When an ASBR re-advertises a per-region I-PMSI A-D route into an AS
in which a designated ASBR needs to be used to forward traffic to the in which a designated ASBR needs to be used to forward traffic to the
legacy PEs in the AS, it SHOULD include a DF Election EC. The EC and legacy PEs in the AS, it SHOULD include a DF Election EC. The EC and
its use is specified in [I-D.ietf-bess-evpn-df-election-framework]. its use is specified in [RFC8584]. The AC-DF bit in the DF Election
The AC-DF bit in the DF Election EC SHOULD be cleared. If it is EC SHOULD be cleared. If it is known that no legacy PEs exist in the
known that no legacy PEs exist in the AS, the ASBR SHOULD NOT include AS, the ASBR SHOULD NOT include the EC and SHOULD remove the DF
the EC and SHOULD remove the DF Election EC if one is carried in the Election EC if one is carried in the per-region I-PMSI A-D routes
per-region I-PMSI A-D routes that it receives. Note that this is that it receives. Note that this is done for each set of per-region
done for each set of per-region I-PMSI A-D routes with the same NLRI. I-PMSI A-D routes with the same NLRI.
Based on the procedures in Based on the procedures in [RFC8584], an election algorithm is
[I-D.ietf-bess-evpn-df-election-framework], an election algorithm is
determined according to the DF Election ECs carried in the set of determined according to the DF Election ECs carried in the set of
per-region I-PMSI routes of the same NLRI re-adverised into the AS. per-region I-PMSI routes of the same NLRI re-adverised into the AS.
The algorithm is then applied to a candidate list, which is the set The algorithm is then applied to a candidate list, which is the set
of ASBRs that re-advertised the per-region I-PMSI routes of the same of ASBRs that re-advertised the per-region I-PMSI routes of the same
NLRI carrying the DF Election EC. NLRI carrying the DF Election EC.
6. Inter-Region Segmentation 6. Inter-Region Segmentation
6.1. Area vs. Region 6.1. Area/AS vs. Region
RFC 7524 is for MVPN/VPLS inter-area segmentation and does not [RFC7524] is for MVPN/VPLS inter-area segmentation and does not
explicitly cover EVPN. However, if "area" is replaced by "region" explicitly cover EVPN. However, if "area" is replaced by "region"
and "ABR" is replaced by "RBR" (Regional Border Router) then and "ABR" is replaced by "RBR" (Regional Border Router) then
everything still works, and can be applied to EVPN as well. everything still works, and can be applied to EVPN as well.
A region can be a sub-area, or can be an entire AS including its A region can be a sub-area, or can be an entire AS including its
external links. Instead of automatic region definition based on IGP external links. Instead of automatic region definition based on IGP
areas, a region would be defined as a BGP peer group. In fact, even areas, a region would be defined as a BGP peer group. In fact, even
with IGP area based region definition, a BGP peer group listing the with IGP area based region definition, a BGP peer group listing the
PEs and ABRs in an area is still needed. PEs and ABRs in an area is still needed.
skipping to change at page 13, line 16 skipping to change at page 13, line 16
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
| PE1 o ASBR1 -- ASBR2 ASBR3 -- ASBR4 o PE2 | | PE1 o ASBR1 -- ASBR2 ASBR3 -- ASBR4 o PE2 |
\ / \ / \ / \ / \ / \ /
\ / \ / \ / \ / \ / \ /
--------- ------ --------- --------- ------ ---------
AS 100 AS 200 AS 300 AS 100 AS 200 AS 300
|-----------|--------|---------|--------|------------| |-----------|--------|---------|--------|------------|
segment1 segment2 segment3 segment4 segment5 segment1 segment2 segment3 segment4 segment5
The inter-as segmentation procedures specified so far (RFC 6513/6514, The inter-as segmentation procedures specified so far ([RFC6513]
7117, and Section 5 of this document) requires all ASBRs to be [RFC6514], [RFC7117], and Section 5 of this document) require all
involved, and Ingress Replication is used between two ASBRs in ASBRs to be involved, and Ingress Replication is used between two
different ASes. ASBRs in different ASes.
In the above diagram, it's possible that ASBR1/4 does not support In the above diagram, it's possible that ASBR1/4 does not support
segmentation, and the provider tunnels in AS 100/300 can actually segmentation, and the provider tunnels in AS 100/300 can actually
extend across the external link. In this case, the inter-region extend across the external link. In this case, the inter-region
segmentation procedures can be used instead - a region is the entire segmentation procedures can be used instead - a region is the entire
(AS100 + ASBR1-ASBR2 link) or (AS300 + ASBR3-ASBR4 link). ASBR2/3 (AS100 + ASBR1-ASBR2 link) or (AS300 + ASBR3-ASBR4 link). ASBR2/3
would be the RBRs, and ASBR1/4 will just be a transit core router would be the RBRs, and ASBR1/4 will just be a transit core router
with respect to provider tunnels. with respect to provider tunnels.
As illustrated in the diagram below, ASBR2/3 will establish a As illustrated in the diagram below, ASBR2/3 will establish a
skipping to change at page 14, line 40 skipping to change at page 14, line 40
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 per-region I-PMSI route uses an embedded EC in NLRI to identify a
region. As long as it uniquely identifies the region and the RBRs region. As long as it uniquely identifies the region and the RBRs
for the same region uses the same EC it is permitted. In the case for the same region uses the same EC it is permitted. For example,
where an AS number or area ID is needed, the following can be used: 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. type, with the Global Administrator sub-field set to the area ID
and the Local Administrator sub-field set to 0.
Uses of other particular ECs may be specified in other documents. Uses of other particular ECs may be specified in other documents.
6.3. Use of S-NH-EC 6.3. Use of S-NH-EC
RFC 7524 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-
NH-EC. As a result, this document specifies that RBRs change the BGP NH-EC. As a result, this document specifies that RBRs change the BGP
next hop when they re-advertise I/S-PMSI A-D routes and do not use S- next hop when they re-advertise I/S-PMSI A-D routes and do not use S-
NH-EC. if a downstream PE/RBR needs to originate Leaf A-D routes, it NH-EC. If a downstream PE/RBR needs to originate Leaf A-D routes, it
simply uses the BGP next hop in the corresponding I/S-PMSI A-D routes constructs an IP-based Route Target Extended Community by placing the
to construct Route Targets. IP address carried in the Next Hop of the received I/S-PMSI A-D route
in the Global Administrator field of the Community, with the Local
Administrator field of this Community set to 0 and setting the
Extended Communities attribute of the Leaf A-D route to that
Community.
The advantage of this is that neither ingress nor egress PEs need to The advantage of this is that neither ingress nor egress PEs need to
understand/use S-NH-EC, and consistent procedure (based on BGP next understand/use S-NH-EC, and consistent procedure (based on BGP next
hop) is used for both inter-as and inter-region segmentation. hop) is used for both inter-as and inter-region segmentation.
6.4. Ingress PE's I-PMSI Leaf Tracking 6.4. Ingress PE's I-PMSI Leaf Tracking
RFC 7524 specifies that when an ingress PE/ASBR (re-)advertises an [RFC7524] specifies that when an ingress PE/ASBR (re-)advertises an
VPLS I-PMSI A-D route, it sets the LIR flag to 1 in the route's PTA. VPLS I-PMSI A-D route, it sets the LIR flag to 1 in the route's PTA.
Similar to the inter-as case, this is actually not really needed for Similar to the inter-as case, this is actually not really needed for
EVPN. To be consistent with the inter-as case, the ingress PE does EVPN. To be consistent with the inter-as case, the ingress PE does
not set the LIR flag in its originated I-PMSI A-D routes, and not set the LIR flag in its originated I-PMSI A-D routes, and
determines the leaves based on the BGP next hops in its received determines the leaves based on the BGP next hops in its received
I-PMSI A-D routes, as specified in Section 5.2. I-PMSI A-D routes, as specified in Section 5.2.
The same backward compatibility issue exists, and the same solution The same backward compatibility issue exists, and the same solution
as in the inter-as case applies, as specified in Section 5.3. as in the inter-as case applies, as specified in Section 5.3.
skipping to change at page 17, line 9 skipping to change at page 17, line 25
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
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-df-election-framework]
Rabadan, J., satyamoh@cisco.com, s., Sajassi, A., Drake,
J., Nagaraj, K., and S. Sathappan, "Framework for EVPN
Designated Forwarder Election Extensibility", draft-ietf-
bess-evpn-df-election-framework-09 (work in progress),
January 2019.
[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., Yeung, D., Drake, J.,
and W. Lin, "IGMP and MLD Proxy for EVPN", draft-ietf- and W. Lin, "IGMP and MLD Proxy for EVPN", draft-ietf-
bess-evpn-igmp-mld-proxy-03 (work in progress), June 2019. bess-evpn-igmp-mld-proxy-03 (work in progress), June 2019.
[I-D.ietf-bess-mvpn-expl-track]
Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang,
"Explicit Tracking with Wild Card Routes in Multicast
VPN", draft-ietf-bess-mvpn-expl-track-13 (work in
progress), November 2018.
[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 5 skipping to change at page 18, line 10
Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
Point-to-Multipoint (P2MP) Segmented Label Switched Paths Point-to-Multipoint (P2MP) Segmented Label Switched Paths
(LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
<https://www.rfc-editor.org/info/rfc7524>. <https://www.rfc-editor.org/info/rfc7524>.
[RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress [RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress
Replication Tunnels in Multicast VPN", RFC 7988, Replication Tunnels in Multicast VPN", RFC 7988,
DOI 10.17487/RFC7988, October 2016, DOI 10.17487/RFC7988, October 2016,
<https://www.rfc-editor.org/info/rfc7988>. <https://www.rfc-editor.org/info/rfc7988>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8534] Dolganow, A., Kotalwar, J., Rosen, E., Ed., and Z. Zhang,
"Explicit Tracking with Wildcard Routes in Multicast VPN",
RFC 8534, DOI 10.17487/RFC8534, February 2019,
<https://www.rfc-editor.org/info/rfc8534>.
[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
VPN Designated Forwarder Election Extensibility",
RFC 8584, DOI 10.17487/RFC8584, April 2019,
<https://www.rfc-editor.org/info/rfc8584>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-bier-architecture] [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and Yasukawa, Ed., "Extensions to Resource Reservation
S. Aldrin, "Multicast using Bit Index Explicit Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Replication", draft-ietf-bier-architecture-08 (work in Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
progress), September 2017. DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/info/rfc4875>.
[I-D.ietf-bier-evpn] [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan, Thomas, "Label Distribution Protocol Extensions for Point-
"EVPN BUM Using BIER", draft-ietf-bier-evpn-01 (work in to-Multipoint and Multipoint-to-Multipoint Label Switched
progress), April 2018. Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
<https://www.rfc-editor.org/info/rfc6388>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>. 2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>. <https://www.rfc-editor.org/info/rfc6514>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
Authors' Addresses Authors' Addresses
Zhaohui Zhang Zhaohui Zhang
Juniper Networks Juniper Networks
EMail: zzhang@juniper.net EMail: zzhang@juniper.net
Wen Lin Wen Lin
Juniper Networks Juniper Networks
 End of changes. 49 change blocks. 
132 lines changed or deleted 149 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/