draft-ietf-bess-evpn-bum-procedure-updates-01.txt   draft-ietf-bess-evpn-bum-procedure-updates-02.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: June 17, 2017 Nokia Expires: March 23, 2018 Nokia
K. Patel K. Patel
Arrcus
A. Sajassi
Cisco Systems Cisco Systems
December 14, 2016 September 19, 2017
Updates on EVPN BUM Procedures Updates on EVPN BUM Procedures
draft-ietf-bess-evpn-bum-procedure-updates-01 draft-ietf-bess-evpn-bum-procedure-updates-02
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 35 skipping to change at page 1, line 37
document are to be interpreted as described in RFC2119. document are to be interpreted as described in RFC2119.
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 http://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 June 17, 2017. This Internet-Draft will expire on March 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . 6
4. Selective Multicast . . . . . . . . . . . . . . . . . . . . . 7 4. Selective Multicast . . . . . . . . . . . . . . . . . . . . . 7
5. Inter-AS Segmentation . . . . . . . . . . . . . . . . . . . . 7 5. Inter-AS Segmentation . . . . . . . . . . . . . . . . . . . . 8
5.1. Changes to Section 7.2.2 of RFC 7117 . . . . . . . . . . 7 5.1. Changes to Section 7.2.2 of RFC 7117 . . . . . . . . . . 8
5.2. I-PMSI Leaf Tracking . . . . . . . . . . . . . . . . . . 8 5.2. I-PMSI Leaf Tracking . . . . . . . . . . . . . . . . . . 9
5.3. Backward Compatibility . . . . . . . . . . . . . . . . . 9 5.3. Backward Compatibility . . . . . . . . . . . . . . . . . 9
6. Inter-Region Segmentation . . . . . . . . . . . . . . . . . . 10 6. Inter-Region Segmentation . . . . . . . . . . . . . . . . . . 11
6.1. Area vs. Region . . . . . . . . . . . . . . . . . . . . . 10 6.1. Area vs. Region . . . . . . . . . . . . . . . . . . . . . 11
6.2. Per-region Aggregation . . . . . . . . . . . . . . . . . 12 6.2. Per-region Aggregation . . . . . . . . . . . . . . . . . 12
6.3. Use of S-NH-EC . . . . . . . . . . . . . . . . . . . . . 13 6.3. Use of S-NH-EC . . . . . . . . . . . . . . . . . . . . . 13
6.4. Ingress PE's I-PMSI Leaf Tracking . . . . . . . . . . . . 13 6.4. Ingress PE's I-PMSI Leaf Tracking . . . . . . . . . . . . 14
7. Multi-homing Support . . . . . . . . . . . . . . . . . . . . 13 7. Multi-homing Support . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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
skipping to change at page 3, line 31 skipping to change at page 3, line 41
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. RFC 6513/6514
cover MVPN inter-as segmentation, RFC 7117 covers VPLS multicast cover MVPN inter-as segmentation, RFC 7117 covers VPLS multicast
inter-as segmentation, and RFC 7524 (Seamless MPLS Multicast) covers inter-as segmentation, and RFC 7524 (Seamless MPLS Multicast) covers
inter-area segmentation for both MVPN and VPLS. 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 uses the same procedures as in segmentation. For simplicity, EVPN will use the same procedures as
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, RFC 7524 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, RFC 7524 assumes that segmentation happens at area borders. However,
it could be at "regional" borders, where a region could be a sub- 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). That area, or even an entire AS plus its external links (Section 6). That
would allow for more flexible deployment scenarios (e.g. for single- would allow for more flexible deployment scenarios (e.g. for single-
area provider networks). area provider networks).
This document specifies/clarifies/redefines certain/additional EVPN This document specifies/clarifies/redefines certain/additional EVPN
skipping to change at page 5, line 33 skipping to change at page 5, line 42
+ 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
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 6 and type 7 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
router for a given EVI, except the Leaf A-D route (Section 3.3). router for a given EVI, except the Leaf A-D route (Section 3.3).
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.
+-----------------------------------+ +-----------------------------------+
skipping to change at page 7, line 12 skipping to change at page 7, line 19
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
6514 for MVPN. The principles apply to VPLS and EVPN as well. RFC 6514 for MVPN. The principles apply to VPLS and EVPN as well. RFC
7117 has details for VPLS Multicast, and this document points out 7117 has details for VPLS Multicast, and this document points out
some specifics for EVPN, e.g. in Section 5. some specifics for EVPN, e.g. in Section 5.
4. Selective Multicast 4. Selective Multicast
RFC 7117 specifies Selective Multicast for VPLS. Other than that [I-D.ietf-bess-evpn-igmp-mld-proxy] specifies procedures for EVPN
different route types and formats are specified with EVPN SAFI for selective forwarding of IP multicast using SMET routes. It assumes
S-PMSI A-D and Leaf A-D routes (Section 3), all procedures in RFC selective forwarding is always used with IR or BIER for all flows.
7117 with respect to Selective Multicast apply to EVPN as well, An NVE proxies the IGMP/MLD state that it learns on its ACs to
including wildcard procedures. (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
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
particular (C-S,C-G) or (C-*,C-G) to achieve selective forwarding
using IR or BIER.
With the above procedures, selective forwarding is done for all flows
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
(C-*,C-G) state on the NVEs, and the multicast traffic pattern allows
inclusive forwarding for most flows while selective forwarding is
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
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
and Leaf A-D routes (Section 3), all procedures in [RFC7117] with
respect to Selective Multicast apply to EVPN as well, including
wildcard procedures. In a nut shell, a source NVE advertises S-SPMSI
A-D routes to announce the tunnels used for certain flows, and
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
the S-PMSI A-D route's PTA (so that the source NVE can include them
as tunnel leaves).
An optimization to the [RFC7117] procedures may be applied. In case
of RSVP-TE P2MP tunnels, while 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 corresponding SMET route, and the source NVE
will use that in lieu of 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
skipping to change at page 15, line 4 skipping to change at page 15, line 22
Zhenbin Li Zhenbin Li
Huawei Technologies Huawei Technologies
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-ir] [I-D.ietf-bess-evpn-igmp-mld-proxy]
Rosen, E., Subramanian, K., and J. Zhang, "Ingress Sajassi, A., Thoria, S., Patel, K., Yeung, D., Drake, J.,
Replication Tunnels in Multicast VPN", draft-ietf-bess- and W. Lin, "IGMP and MLD Proxy for EVPN", draft-ietf-
ir-00 (work in progress), January 2015. bess-evpn-igmp-mld-proxy-00 (work in progress), March
2017.
[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,
<http://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,
<http://www.rfc-editor.org/info/rfc7117>. <https://www.rfc-editor.org/info/rfc7117>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <http://www.rfc-editor.org/info/rfc7432>. 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
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,
<http://www.rfc-editor.org/info/rfc7524>. <https://www.rfc-editor.org/info/rfc7524>.
12.2. Informative References [RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress
Replication Tunnels in Multicast VPN", RFC 7988,
DOI 10.17487/RFC7988, October 2016,
<https://www.rfc-editor.org/info/rfc7988>.
[I-D.ietf-bess-dci-evpn-overlay] 12.2. Informative References
Rabadan, J., Sathappan, S., Henderickx, W., Palislamovic,
S., Balus, F., Sajassi, A., and D. Cai, "Interconnect
Solution for EVPN Overlay networks", draft-ietf-bess-dci-
evpn-overlay-00 (work in progress), January 2015.
[I-D.ietf-bess-evpn-overlay] [I-D.ietf-bess-evpn-overlay]
Sajassi, A., Drake, J., Bitar, N., Isaac, A., Uttaro, J., Sajassi, A., Drake, J., Bitar, N., Shekhar, R., Uttaro,
and W. Henderickx, "A Network Virtualization Overlay J., and W. Henderickx, "A Network Virtualization Overlay
Solution using EVPN", draft-ietf-bess-evpn-overlay-01 Solution using EVPN", draft-ietf-bess-evpn-overlay-08
(work in progress), February 2015. (work in progress), March 2017.
[I-D.rabadan-bess-evpn-optimized-ir]
Rabadan, J., Sathappan, S., Henderickx, W., Sajassi, A.,
and A. Isaac, "Optimized Ingress Replication solution for
EVPN", draft-rabadan-bess-evpn-optimized-ir-00 (work in
progress), October 2014.
[I-D.wijnands-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-wijnands-bier-architecture-05 (work in Replication", draft-ietf-bier-architecture-08 (work in
progress), March 2015. progress), September 2017.
[I-D.zzhang-bier-evpn]
Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan,
"EVPN BUM Using BIER", draft-zzhang-bier-evpn-00 (work in
progress), June 2017.
[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, <http://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,
<http://www.rfc-editor.org/info/rfc6514>. <https://www.rfc-editor.org/info/rfc6514>.
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
skipping to change at page 16, line 31 skipping to change at page 17, line 4
Zhaohui Zhang Zhaohui Zhang
Juniper Networks Juniper Networks
EMail: zzhang@juniper.net EMail: zzhang@juniper.net
Wen Lin Wen Lin
Juniper Networks Juniper Networks
EMail: wlin@juniper.net EMail: wlin@juniper.net
Jorge Rabadan Jorge Rabadan
Nokia Nokia
EMail: jorge.rabadan@nokia.com EMail: jorge.rabadan@nokia.com
Keyur Patel Keyur Patel
Arrcus
EMail: keyur@arrcus.com
Ali Sajassi
Cisco Systems Cisco Systems
EMail: keyupate@cisco.com EMail: sajassi@cisco.com
 End of changes. 34 change blocks. 
56 lines changed or deleted 92 lines changed or added

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