BESS Workgroup T. Yu, Ed. Internet-Draft Intended status: Standards Track H. Wang Expires: September 11, 2019 Huawei Technologies March 10, 2019 Usage of Layer 2 Attributes Extended Community in EVPN draft-yu-bess-evpn-l2-attributes-04 Abstract This document adopts Layer 2 Attributes Extended Community defined in [RFC8214] to EVPN allowing signalling L2 information in control plane. An interoperability mechanism of control word is described for EVPN and VPWS in this document. Also flow label signalling mechanism is described for EVPN and VPWS. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 11, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Yu & Wang Expires September 11, 2019 [Page 1] Internet-Draft Usage of L2 Attributes in EVPN March 2019 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. EVPN Layer 2 Attributes Extended Community . . . . . . . . . 3 4.1. Control Flag Attribute . . . . . . . . . . . . . . . . . 4 4.2. L2 MTU Attribute . . . . . . . . . . . . . . . . . . . . 6 5. Control Word Indicator Extended Community . . . . . . . . . . 6 6. Usage of Control Word . . . . . . . . . . . . . . . . . . . . 7 6.1. EVPN ELAN . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1.1. Deterministic mode . . . . . . . . . . . . . . . . . 7 6.1.2. Interoperable mode . . . . . . . . . . . . . . . . . 7 6.2. EVPN VPWS . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2.1. Deterministic mode . . . . . . . . . . . . . . . . . 8 6.2.2. Interoperable mode . . . . . . . . . . . . . . . . . 8 7. Usage of Flow Label . . . . . . . . . . . . . . . . . . . . . 8 8. Instructions on Using Control Word and Flow Label . . . . . . 9 9. Other Considerations . . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction EVPN [RFC7432] lacks of a negotiation mechanism on L2 capabilities. Lacking of such capabilities will lead to malformed packets on forwarding plane without any prevention from control plane signalling. [RFC8214] defines Layer 2 Attributes Extended Community but there is no defination on how it can used in EVPN ELAN. This document aims to describe how Layer 2 Attributes Extended Community to be used in EVPN ELAN. To achieve better load balancing on EVPN ELAN and VPWS services, flow label function in EVPN is described in this document. Yu & Wang Expires September 11, 2019 [Page 2] Internet-Draft Usage of L2 Attributes in EVPN March 2019 2. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "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. 3. Terminology EVPN: BGP MPLS-Based Ethernet VPN defined in [RFC7432]. EVPN ELAN: In order to distinguish EVPN VPWS, EVPN ELAN specifies EVPN defined in [RFC7432]. EVI: An EVPN Instance spanning the Provider Edge (PE) devices participating in that EVPN ELAN. EVPN VPWS: EVPN Virtual Private Wire Service, refers to [RFC8214]. EVPN E-Tree: Ethernet VPN Ethernet-Tree defined in [RFC8317]. CW: Control Word defined in [RFC4448]. CI: Control Word Indicator, defined in Section 4 of this document. PE: Provider Edge device. FL: Flow-Aware Transport Label, defined in [RFC6391]. BUM: Broadbast, Unknown-Unicast, Multicast. P2MP: Point to Multi-Point. MP2P: Multi-Point to Point. LSP: Label-Switched Path. 4. EVPN Layer 2 Attributes Extended Community The definition of EVPN Layer 2 Attributes Extended Community is same with [RFC8214]. it is listed as below for convenience. Yu & Wang Expires September 11, 2019 [Page 3] Internet-Draft Usage of L2 Attributes in EVPN March 2019 +-------------------------------------------+ | Type (0x06) / Sub-type (0x04) (2 octets) | +-------------------------------------------+ | Control Flags (2 octets) | +-------------------------------------------+ | L2 MTU (2 octets) | +-------------------------------------------+ | Reserved (2 octets) | +-------------------------------------------+ Figure 1: EVPN Layer 2 Attributes Extended Community Layer 2 Attributes Extended Community SHOULD be included in Ethernet Auto-discovery Route route and Inclusive Multicast Ethernet Tag Route. For an EVPN ELAN, Layer 2 Attributes Extended Community included in Auto-discovery route applies to unicast traffic and Inclusive Multicast Ethernet Tag Route applies to BUM traffic. Layer 2 Attributes Extended Community for unicast MUST be same across all Ethernet Segments in Auto-discovery routes within one EVI on a local PE when used in EVPN ELAN. Layer 2 Attributes Extended Community for BUM MUST be same across EVIs sharing the same P-Tunnel within a PE. Layer 2 Attributes Extended Community MAY be different between Auto-discovery route and Inclusive Multicast Ethernet Tag Route. When a PE recieves routes without L2 Attributes Extended Community, local PE SHOULD assume the values of Layer 2 Attributes Extended Community of all corresponding PEs are same with local. This allows backward compatibility of introducing L2 Attributes Extended Community into EVPN ELAN. If a local PE does not support EVPN Layer 2 Attributes Extended Community, this community MUST be ignored. 4.1. Control Flag Attribute The definition of Control Flags is as below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+ | MBZ |CI|F|C|P|B| (MBZ = MUST Be Zero) +-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+ Figure 2: Control Flags in EVPN Layer 2 Attributes Extended Community Yu & Wang Expires September 11, 2019 [Page 4] Internet-Draft Usage of L2 Attributes in EVPN March 2019 The P bit and B bit defined in [RFC8214] must be zero when used in EVPN ELAN mode. This is because [RFC7432] has defined ESI Label Extended Community to achieve single-active redundancy mode. C bit indicates the control word enable status: o When C bit is set to 1, the PE announces it has the capability of both sending and receiving CW. o C bit MUST set 0 if PE has no capability of sending or receiving control word. o C bit SHOULD not set 1 if Layer 2 Attributes Extended Community is used on P2MP or MP2MP LSPs. F bit is defined to achieve flow label signalling capability in EVPN: o When F bit is set to 1, the PE announces it has the capability of both sending and receiving flow label. o F bit MUST set 0 if PE has no capability of sending or receiving flow label. o F bit SHOULD not set 1 if Layer 2 Attributes Extended Community is used on P2MP or MP2MP LSPs. CI bit is defined to achieve interoperability between devices with and without control word capability. Control Word Indicator is a MPLS label. CI bit MUST NOT set 1 if C bit is set 0. CI label MUST NOT be a MPLS reserved label [RFC3032], MUST be with TTL=1 and MUST be Bottom-of-Stack. CI label MUST NOT be used to direct forwarding behavior in any cases. When a PE sends packets with CI label, it MUST keep value CI labels consistent for traffic towards the same ES. Due to CI usage is to indicate the existance of CW and will never direct fowarding, CI MPLS label can be any none-reserved MPLS label. There are two ways of filling CWI label value: o Use the label value advertised in Control Word Indicator Extended Community (refer to section 5). o In case absense of Control Word Indicator Extended Community, EVPN service label MAY be copied into CWI. The usage of CI bit is described in Section 6. Yu & Wang Expires September 11, 2019 [Page 5] Internet-Draft Usage of L2 Attributes in EVPN March 2019 Other bits in Control Flag are reserved for future investigation and MUST be zero. When a PE receives Auto-discovery routes with C or F bit enabled, the behavior SHOULD be spread to all MAC tables towards the corresponding ES. 4.2. L2 MTU Attribute L2 MTU is a 2-octet value indicating the CE-PE link MTU in bytes. If a non-zero MTU attribute is received, it MUST be checked against local MTU value if the local value is not zero. If there is a mismatch, the local PE MUST NOT add the remote PE as the EVPN ELAN or VPWS destination. 5. Control Word Indicator Extended Community This extended community is a new transitive extended community having a Type field value of 0x06 (EVPN) and the Sub-Type TBD. It is used for Control Word Indicator of known unicast and BUM traffic. It indicates that the frame contains a CW after MPLS Bottom-of-Stack. This extended community MAY be advertised along Ethernet Auto- discovery Route route and Inclusive Multicast Ethernet Tag Route when CI bit is 1 in EVPN Layer 2 Attributes Extended Community. When a PE advertising the communnity, it MUST ensure CWI label same across Ethernet Segments within one EVI and EVIs sharing the same P-Tunnel. CI label value advertised SHOULD NOT be same with EVPN service lables. Control Word Indicator Extended Community MUST NOT be included if CI is 0. If a PE contains Control Word Indicator Extended Community when establishing the MP2P LSP, when receiving packets from MP2P LSP, it uses the CI label value been advertised to identify existance of CW. If a PE does not contain Control Word Indicator Extended Community when establishing the MP2P LSP, it relies on the MPLS Bottom-of-Stack bit to identify existance of CW. When CI bit and F bit set 1 together, Control Word Indicator Extended Community MUST be included. The packet encapulation from ingress PE is: transport label(s) + EVPN service label(s) + FL + CI + CW + payload. Forwarding plane on egress PE MUST use CI value in the extended community to identify CW and identify FL in between if exits. When working in such mode, source PE MUST ensure FL value calaulated locally does not equal CI value learnt from EVPN routes. Yu & Wang Expires September 11, 2019 [Page 6] Internet-Draft Usage of L2 Attributes in EVPN March 2019 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x06 | Sub-Type=TBD | Flags(1 Octet)| Reserved=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved=0 | CI Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Control Word Indicator Extended Community 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | MBZ |C| (MBZ = MUST Be Zero) +-+-+-+-+-+-+-+-+ Figure 4: Flags in Control Word Indicator Extended Community 6. Usage of Control Word 6.1. EVPN ELAN 6.1.1. Deterministic mode PE advertises CW local enable status via Layer 2 Attributes Extended Community. A validation procedure is added in procedure of Auto- discovery and Inclusive Multicast Ethernet Tag Route. Only if C bit status in L2 attribute of recieved routes are same with local statue, the recieved routes are treated valid. CI bit is not used in this mode. 6.1.2. Interoperable mode 1. Disable CW function on all devices and keep CW status consistent within EVI, then the EVI can work in the deterministic mode. 2. An interoperable mode based on CI MAY be implemented to achieve interoperability with such devices. An egress PE can receive packets from MP2P LSP with same EVPN label but with different CW status from different remote PEs. This brings challenge on CW interoperate mechanism. To overcome this challenge, CI is introduced to allow a PE identifying CW status on forwarding plane. When an EVPN ELAN working in interoperable mode, if CW on a PE is enabled, the PE MUST set both C and CI bit = 1. If CW on a PE is disabled or the PE is not capable to add CW, the PE MUST set both C and CI bit = 0. Yu & Wang Expires September 11, 2019 [Page 7] Internet-Draft Usage of L2 Attributes in EVPN March 2019 In this mode, A validation procedure is added in procedure of Auto- discovery and Inclusive Multicast Ethernet Tag Route. Only if C bit = CI bit in L2 attribute of recieved routes, recieved routes are treated valid. With such procedure, an egress PE is able to identify existance of CW on fowarding plane via CI for packets recieved from MP2P LSP. 6.2. EVPN VPWS 6.2.1. Deterministic mode When an EVPN VPWS working in deterministic mode, each PE advertises CW capability based on local status in Auto-discovery route via l2 attribute. After a PE receives EVPN Auto-discovery route, it compares the value of C bit with local control word enable status. If not same, local PE MUST NOT bring up the EVPN VPWS. 6.2.2. Interoperable mode Considering some devices has no capability of adding and parsing CW, there are two ways to interoperate such devices: 1. Disable CW function on PE1 and keep CW status consistent within EVPN VPWS towards PE3, then the EVPN VPWS can work in the deterministic mode. 2. An interoperable mode MAY be implemented to achieve interoperability with such devices. When an EVPN VPWS working in interoperable mode, in case of C bit status is not consistent on both ends, VPWS MUST tear up. When working in interoperable mode, impact of lacking complete CW between PEs SHOULD be evaluated based on section 8 of this document. 7. Usage of Flow Label PE advertises FL local enable status via Layer 2 Attributes Extended Community. Different from CW, flow label signalling on control plane uses a loose validation procedure, which means FL status in received routes MAY be different from local. For MP2P LSP, when sending packet towards remote PE, FL is added if both local and remote PEs are enabled. If a PE has no FL capability, it will not receive packets with FL from MP2P LSP as all source PEs will not send packets with FL towards this PE. If a PE has FL capability, it MAY receive packets with and without FL from MP2P LSP Yu & Wang Expires September 11, 2019 [Page 8] Internet-Draft Usage of L2 Attributes in EVPN March 2019 as source PEs MAY have or haven't FL capability. In such case, the PE SHOULD treat packet without FL valid on forwarding plane even though local FL status is enabled. MPLS Bottom-of-Stack bit is used to identify whether FL is containted in the packets. The flow label mechanism described above is applicable to both EVPN ELAN, E-Tree and EVPN VPWS. 8. Instructions on Using Control Word and Flow Label In EVPN, CW is used avoid misordering caused by transit node using MPLS payload as hash factor. The detailed reason for this refers to [RFC8469]. CW is mandatory for an EVPN carrying misordering sensitive service, when CW is not available, mitigations described in section 6 of [RFC8469] also apply to EVPN. Flow Label MAY be used to achieve better load-balancing in network, when transit node has no capability to look inside MPLS payload as hash factor. It has been recognized that some transit nodes treat payload after MPLS label as MAC address info and use as hash factor directly. When it is bearing services sensitive to misordering, such load balancing function SHOULD be disabled, otherwise control word will be treated as part of MAC address mistakenly. 9. Other Considerations When data plane is not using MPLS, C, F and CI bits in control flags MUST be 0. Control word and Flow Label are only applicable to MPLS data plane. 10. Security Considerations This document updates the behavior specified in [RFC7432] and [RFC8214]. The security considerations listed in these two documents apply. However, there are no new security considerations due to the text of this document. 11. IANA Considerations IANA is requested to allocate a new "EVPN Extended Community Sub- Types" registry defined in [RFC7153] as follow: SUB-TYPE VALUE NAME Reference ------------------------------------------------------------------- Yu & Wang Expires September 11, 2019 [Page 9] Internet-Draft Usage of L2 Attributes in EVPN March 2019 TBD Control Word Indicator Extended Community This document 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. Rabadan, "Virtual Private Wire Service Support in Ethernet VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, . [RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, January 2018, . [RFC8469] Bryant, S., Malis, A., and I. Bagdonas, "Recommendation to Use the Ethernet Control Word", RFC 8469, DOI 10.17487/RFC8469, November 2018, . 12.2. Informative References [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, . [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, . Yu & Wang Expires September 11, 2019 [Page 10] Internet-Draft Usage of L2 Attributes in EVPN March 2019 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, DOI 10.17487/RFC6391, November 2011, . [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, . Authors' Addresses Tianpeng Yu (editor) EMail: yutianpeng.ietf@gmail.com Haibo Wang Huawei Technologies EMail: rainsword.wang@huawei.com Yu & Wang Expires September 11, 2019 [Page 11]