draft-ietf-bess-evpn-bum-procedure-updates-02.txt   draft-ietf-bess-evpn-bum-procedure-updates-03.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: March 23, 2018 Nokia Expires: October 22, 2018 Nokia
K. Patel K. Patel
Arrcus Arrcus
A. Sajassi A. Sajassi
Cisco Systems Cisco Systems
September 19, 2017 April 20, 2018
Updates on EVPN BUM Procedures Updates on EVPN BUM Procedures
draft-ietf-bess-evpn-bum-procedure-updates-02 draft-ietf-bess-evpn-bum-procedure-updates-03
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.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 March 23, 2018. This Internet-Draft will expire on October 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Leaf-AD route . . . . . . . . . . . . . . . . . . . . . . 7
4. Selective Multicast . . . . . . . . . . . . . . . . . . . . . 7 4. Selective Multicast . . . . . . . . . . . . . . . . . . . . . 7
5. Inter-AS Segmentation . . . . . . . . . . . . . . . . . . . . 8 5. Inter-AS Segmentation . . . . . . . . . . . . . . . . . . . . 8
5.1. Changes to Section 7.2.2 of RFC 7117 . . . . . . . . . . 8 5.1. Changes to Section 7.2.2 of RFC 7117 . . . . . . . . . . 8
5.2. I-PMSI Leaf Tracking . . . . . . . . . . . . . . . . . . 9 5.2. I-PMSI Leaf Tracking . . . . . . . . . . . . . . . . . . 9
5.3. Backward Compatibility . . . . . . . . . . . . . . . . . 9 5.3. Backward Compatibility . . . . . . . . . . . . . . . . . 10
6. Inter-Region Segmentation . . . . . . . . . . . . . . . . . . 11 6. Inter-Region Segmentation . . . . . . . . . . . . . . . . . . 11
6.1. Area vs. Region . . . . . . . . . . . . . . . . . . . . . 11 6.1. Area vs. Region . . . . . . . . . . . . . . . . . . . . . 11
6.2. Per-region Aggregation . . . . . . . . . . . . . . . . . 12 6.2. Per-region Aggregation . . . . . . . . . . . . . . . . . 13
6.3. Use of S-NH-EC . . . . . . . . . . . . . . . . . . . . . 13 6.3. Use of S-NH-EC . . . . . . . . . . . . . . . . . . . . . 14
6.4. Ingress PE's I-PMSI Leaf Tracking . . . . . . . . . . . . 14 6.4. Ingress PE's I-PMSI Leaf Tracking . . . . . . . . . . . . 14
7. Multi-homing Support . . . . . . . . . . . . . . . . . . . . 14 7. Multi-homing Support . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Terminology 1. Terminology
To be added To be added
2. Introduction 2. Introduction
RFC 7432 specifies procedures to handle broadcast, unknown unicast, RFC 7432 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 RFC
skipping to change at page 5, line 28 skipping to change at page 5, line 28
RFC 7432 defines the format of EVPN NLRI as the following: RFC 7432 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 five types have been defined: So far eight types have been defined:
+ 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
+ 7 - IGMP Join Synch Route
+ 8 - IGMP Leave Synch Route
This document defines three additional route types: This document defines three additional route types:
+ 9 - Per-Region I-PMSI A-D route + 9 - Per-Region I-PMSI A-D route
+ 10 - S-PMSI A-D route + 10 - S-PMSI A-D route
+ 11 - Leaf A-D route + 11 - Leaf A-D route
The "Route Type specific" field of the type 9 and type 10 EVPN NLRIs The "Route Type specific" field of the type 9 and type 10 EVPN NLRIs
starts with a type 1 RD, whose Administrative sub-field MUST match starts with a type 1 RD, whose Administrative sub-field MUST match
that of the RD in all the EVPN routes from the same advertising that of the RD in all the EVPN routes from the same advertising
skipping to change at page 6, line 35 skipping to change at page 6, line 40
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+-----------------------------------+ +-----------------------------------+
| Multicast Source Length (1 octet) | | Multicast Source Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Multicast Source (Variable) | | Multicast Source (Variable) |
+-----------------------------------+ +-----------------------------------+
| Multicast Group Length (1 octet) | | Multicast Group Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Multicast Group (Variable) | | Multicast Group (Variable) |
+-----------------------------------+ +-----------------------------------+
| Originating Router's IP Addr | |Originator's Addr Length (1 octet) |
+-----------------------------------+
|Originator's Addr (4 or 16 octets) |
+-----------------------------------+ +-----------------------------------+
Other than the addition of Ethernet Tag ID, it is identical to the Other than the addition of Ethernet Tag ID and Originator's Addr
S-PMSI A-D route as defined in RFC 7117. The procedures in RFC 7117 Length, it is identical to the S-PMSI A-D route as defined in RFC
also apply (including wildcard functionality), except that the 7117. The procedures in RFC 7117 also apply (including wildcard
granularity level is per Ethernet Tag. functionality), except that the granularity level is per 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) |
+-----------------------------------+ +-----------------------------------+
| Originating Router's IP Addr | |Originator's Addr Length (1 octet) |
+-----------------------------------+
|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 RFC
skipping to change at page 7, line 48 skipping to change at page 8, line 12
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 nut shell, a source NVE advertises S-SPMSI
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. In case An optimization to the [RFC7117] procedures may be applied. Even if
of RSVP-TE P2MP tunnels, while a source NVE sets the LIR bit to a source NVE sets the LIR bit to request Leaf A-D routes, an egress
request Leaf A-D routes, an egress NVE may omit the Leaf A-D route if NVE may omit the Leaf A-D route if it already advertises a
it already advertises a corresponding SMET route, and the source NVE corresponding SMET route, and the source NVE will use that in lieu of
will use that in lieu of the Leaf A-D route. the Leaf A-D route.
5. Inter-AS Segmentation 5. Inter-AS Segmentation
5.1. Changes to Section 7.2.2 of RFC 7117 5.1. Changes to Section 7.2.2 of RFC 7117
The first paragraph of Section 7.2.2.2 of RFC 7117 says: The first paragraph of Section 7.2.2.2 of RFC 7117 says:
"... The best route procedures ensure that if multiple "... The best route procedures ensure that if multiple
ASBRs, in an AS, receive the same Inter-AS A-D route from their EBGP 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 neighbors, only one of these ASBRs propagates this route in Internal
BGP (IBGP). This ASBR becomes the root of the intra-AS segment of 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 the inter-AS tree and ensures that this is the only ASBR that accepts
traffic into this AS from the inter-AS tree." 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.
The Leaf A-D based procedure is used for each ASBR who re-advertises With the different approach for EVPN, each ASBR will re-advertise its
into the AS to discover the leaves on the segment rooted at itself. received Inter-AS A-D route to its IBGP peers and becomes the root of
This is the same as the procedures for S-PMSI in RFC 7117 itself. 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
at another ASBR. This is the same as the procedures for S-PMSI in
RFC 7117 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: is changed to the following:
skipping to change at page 10, line 22 skipping to change at page 10, line 39
ASes) as leaves of the inclusive tunnel and try to send traffic to ASes) as leaves of the inclusive tunnel and try to send traffic to
them directly (no segmentation), which is either undesired or not them directly (no segmentation), which is either undesired or not
possible; a legacy egress PE would not send Leaf A-D routes so the possible; a legacy egress PE would not send Leaf A-D routes so the
ASBRs would not know to send external traffic to them. ASBRs would not know to send external traffic to them.
To address this backward compatibility problem, the following To address this backward compatibility problem, the following
procedure can be used (see Section 6.2 for per-PE/AS/region I-PMSI procedure can be used (see Section 6.2 for per-PE/AS/region I-PMSI
A-D routes): A-D routes):
o An upgraded PE indicates in its per-PE I-PMSI A-D route that it o An upgraded PE indicates in its per-PE I-PMSI A-D route that it
supports the new procedures. Details will be provided in a future supports the new procedures. This is done by setting a flag bit
revision. in the EVPN Multicast Flags Extended Community.
o All per-PE I-PMSI A-D routes are restricted to the local AS and o All per-PE I-PMSI A-D routes are restricted to the local AS and
not propagated to external peers. not propagated to external peers.
o The ASBRs in an AS originate per-region I-PMSI A-D routes and o The ASBRs in an AS originate per-region I-PMSI A-D routes and
advertise to their external peers to advertise tunnels used to advertise to their external peers to advertise tunnels used to
carry traffic from the local AS to other ASes. Depending on the carry traffic from the local AS to other ASes. Depending on the
types of tunnels being used, the LIR flag in the PTA may be set, types of tunnels being used, the LIR flag in the PTA may be set,
in which case the downstream ASBRs and upgraded PEs will send Leaf in which case the downstream ASBRs and upgraded PEs will send Leaf
A-D routes to pull traffic from their upstream ASBRs. In a A-D routes to pull traffic from their upstream ASBRs. In a
particular downstream AS, one of the ASBRs is elected, based on particular downstream AS, one of the ASBRs is elected, based on
the per-region I-PMSI A-D routes for a particular source AS, to the per-region I-PMSI A-D routes for a particular source AS, to
send traffic from that source AS to legacy PEs in the downstream send traffic from that source AS to legacy PEs in the downstream
AS. The traffic arrives at the elected ASBR on the tunnel AS. The traffic arrives at the elected ASBR on the tunnel
announced in the best per-region I-PMSI A-D route for the source announced in the best per-region I-PMSI A-D route for the source
AS, that the ASBR has selected of all those that it received over AS, that the ASBR has selected of all those that it received over
EBGP or IBGP sessions. Details of the election procedure will be EBGP or IBGP sessions. Details of the election procedure will be
provided in a future revision. provided in a future revision.
o In an ingress AS, if and only if an ASBR has active downstream o In an ingress/upstream AS, if and only if an ASBR has active
receivers (PEs and ASBRs), which are learned either explicitly via downstream receivers (PEs and ASBRs), which are learned either
Leaf AD routes or implicitly via PIM join or mLDP label mapping, explicitly via Leaf AD routes or implicitly via PIM join or mLDP
the ASBR originates a per-PE I-PMSI A-D route (i.e., regular label mapping, the ASBR originates a per-PE I-PMSI A-D route
Inclusive Multicast Ethernet Tag route) into the local AS, and (i.e., regular Inclusive Multicast Ethernet Tag route) into the
stitches incoming per-PE I-PMSI tunnels into its per-region I-PMSI local AS, and stitches incoming per-PE I-PMSI tunnels into its
tunnel. With this, it gets traffic from local PEs and send to per-region I-PMSI tunnel. With this, it gets traffic from local
other ASes via the tunnel announced in its per-region I-PMSI A-D PEs and send to other ASes via the tunnel announced in its per-
route. region I-PMSI A-D route.
Note that, even if there is no backward compatibility issue, the Note that, even if there is no backward compatibility issue, the
above procedures have the benefit of keeping all per-PE I-PMSI A-D above procedures have 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.
6. Inter-Region Segmentation 6. Inter-Region Segmentation
6.1. Area vs. Region 6.1. Area vs. Region
skipping to change at page 11, line 46 skipping to change at page 12, line 23
|-----------|--------|---------|--------|------------| |-----------|--------|---------|--------|------------|
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 (RFC 6513/6514,
7117, and Section 5 of this document) requires all ASBRs to be 7117, and Section 5 of this document) requires all ASBRs to be
involved, and Ingress Replication is used between two ASBRs in involved, and Ingress Replication is used between two ASBRs in
different ASes. 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 the 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
multihop EBGP session with either a RR or directly with PEs in the multihop EBGP session with either a RR or directly with PEs in the
neighboring AS. I/S-PMSI A-D routes from ingress PEs will not be neighboring AS. I/S-PMSI A-D routes from ingress PEs will not be
processed by ASBR1/4. When ASBR2 re-advertises the routes into AS processed by ASBR1/4. When ASBR2 re-advertises the routes into AS
200, it changes the next hop to its own address and changes PTA to 200, it changes the next hop to its own address and changes PTA to
skipping to change at page 14, line 29 skipping to change at page 15, line 7
If multi-homing does not span across different ASes or regions, If multi-homing does not span across different ASes or regions,
existing procedures work with segmentation, and a segmentation point existing procedures work with segmentation, and a segmentation point
will remove the ESI label from the packets. If an ES is multi-homed will remove the ESI label from the packets. If an ES is multi-homed
to PEs in different ASes or regions, additional procedures are needed to PEs in different ASes or regions, additional procedures are needed
to work with segmentation. The procedures are well understood but to work with segmentation. The procedures are well understood but
omitted here until the requirement becomes clear. omitted here until the requirement becomes clear.
8. IANA Considerations 8. IANA Considerations
This document requests IANA to assign the following new EVPN route IANA has temporaritly assigned the following new EVPN route types:
types:
o 9 - Per-Region I-PMSI A-D route o 9 - Per-Region I-PMSI A-D route
o 10 - S-PMSI A-D route o 10 - S-PMSI A-D route
o 11 - Leaf A-D route o 11 - Leaf A-D route
This document requests IANA to assign one flag bit from the EVPN
Multicast Flags Extended Community:
o Bit-S - The router supports segmentation procedure defined in this
document
9. Security Considerations 9. Security Considerations
This document does not seem to introduce new security risks, though This document does not seem to introduce new security risks, though
this may be revised after further review and scrutiny. this may be revised after further review and scrutiny.
10. Acknowledgements 10. Acknowledgements
The authors thank Eric Rosen, John Drake, and Ron Bonica for their The authors thank Eric Rosen, John Drake, and Ron Bonica for their
comments and suggestions. comments and suggestions.
skipping to change at page 15, line 28 skipping to change at page 16, line 12
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., 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-00 (work in progress), March bess-evpn-igmp-mld-proxy-01 (work in progress), March
2017. 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 16, line 15 skipping to change at page 16, line 46
[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>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-bess-evpn-overlay] [I-D.ietf-bess-evpn-overlay]
Sajassi, A., Drake, J., Bitar, N., Shekhar, R., Uttaro, Sajassi, A., Drake, J., Bitar, N., Shekhar, R., Uttaro,
J., and W. Henderickx, "A Network Virtualization Overlay J., and W. Henderickx, "A Network Virtualization Overlay
Solution using EVPN", draft-ietf-bess-evpn-overlay-08 Solution using EVPN", draft-ietf-bess-evpn-overlay-12
(work in progress), March 2017. (work in progress), February 2018.
[I-D.ietf-bier-architecture] [I-D.ietf-bier-architecture]
Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
S. Aldrin, "Multicast using Bit Index Explicit S. Aldrin, "Multicast using Bit Index Explicit
Replication", draft-ietf-bier-architecture-08 (work in Replication", draft-ietf-bier-architecture-08 (work in
progress), September 2017. progress), September 2017.
[I-D.zzhang-bier-evpn] [I-D.zzhang-bier-evpn]
Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan, Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan,
"EVPN BUM Using BIER", draft-zzhang-bier-evpn-00 (work in "EVPN BUM Using BIER", draft-zzhang-bier-evpn-00 (work in
 End of changes. 25 change blocks. 
50 lines changed or deleted 66 lines changed or added

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