Skip to main content

Usage of Layer 2 Attributes Extended Community in EVPN
draft-yu-bess-evpn-l2-attributes-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Tianpeng Yu , Haibo Wang
Last updated 2019-01-21
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-yu-bess-evpn-l2-attributes-03
BESS Workgroup                                                     T. Yu
Internet-Draft
Intended status: Standards Track                                 H. Wang
Expires: July 25, 2019                               Huawei Technologies
                                                        January 21, 2019

         Usage of Layer 2 Attributes Extended Community in EVPN
                  draft-yu-bess-evpn-l2-attributes-03

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 July 25, 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 July 25, 2019                 [Page 1]
Internet-Draft       Usage of L2 Attributes in EVPN         January 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
   5.  Usage of Control Word . . . . . . . . . . . . . . . . . . . .   5
     5.1.  EVPN ELAN . . . . . . . . . . . . . . . . . . . . . . . .   5
       5.1.1.  Deterministic mode  . . . . . . . . . . . . . . . . .   5
       5.1.2.  Interoperable mode  . . . . . . . . . . . . . . . . .   6
     5.2.  EVPN VPWS . . . . . . . . . . . . . . . . . . . . . . . .   7
       5.2.1.  Deterministic mode  . . . . . . . . . . . . . . . . .   7
       5.2.2.  Interoperable mode  . . . . . . . . . . . . . . . . .   8
     5.3.  EVPN E-Tree . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Usage of Flow Label . . . . . . . . . . . . . . . . . . . . .   9
   7.  L2 MTU Processing . . . . . . . . . . . . . . . . . . . . . .  10
   8.  Instructions on Using Control Word and Flow Label . . . . . .  10
   9.  Other Considerations  . . . . . . . . . . . . . . . . . . . .  10
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     12.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   EVPN [RFC7432] lacks of a negotiation mechanism on L2 capabilities.
   If the L2 capabilities between PE devices are different, they are not
   able to communicate properly.  [RFC8214] defines Layer 2 Attributes
   Extended Community but there is no description on how to be used in
   EVPN ELAN.  This document describes how Layer 2 Attributes Extended
   Community is used in EVPN ELAN.

   Considering some devices have no capability to support control word
   and there are legacy devices without control word function supported,
   an interoperability mechanism on control word is described.

   To achieve better load balancing on EVPN ELAN and VPWS services, flow
   label function in EVPN is described in this document.

Yu & Wang                 Expires July 25, 2019                 [Page 2]
Internet-Draft       Usage of L2 Attributes in EVPN         January 2019

2.  Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [RFC2119].

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].

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.

               +-------------------------------------------+
               |  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

   The definition of Control Flags is as below:

Yu & Wang                 Expires July 25, 2019                 [Page 3]
Internet-Draft       Usage of L2 Attributes in EVPN         January 2019

          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

   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 of known unicast
   traffic.  C bit MUST set 0 when advertising A-D route if PE has no
   capability of processing control word.  C bit SHOULD be same across
   all Ethernet Segments within one EVI on a local PE when used in EVPN
   ELAN.  BUM traffic SHOULD NOT include control word when forwarded no
   matter C bit is set to 1 or 0 when working in EVPN ELAN.

   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 an MPLS reserved label [RFC3032] and MUST be
   with TTL=1.  CI label MUST NOT be used for directing forwarding
   behavior in any cases.

   When a PE sends packet with CI label, it MUST keep CI label value
   consistent for traffic towards one ES.  EVI service label value,
   including type1 and type2, MAY be used as CI value directly.

   The usage of CI bit is described in Section 5.

   F bit is defined to achieve flow label signalling capability in both
   EVPN ELAN and VPWS.  When F bit is set to 1, the PE announces it has
   the capability of both sending and receiving flow label.  F bit
   SHOULD be same across all Ethernet Segments within one EVI on a local
   PE when used in EVPN ELAN.  BUM traffic in EVPN ELAN SHOULD NOT
   include Flow label when forwarded no matter F bit is set to 1 or 0
   when working in ELAN mode.

   C bit and F bit MUST NOT set 1 together.

   Other bits in Control Flags are reserved for future investigation and
   MUST be zero.

   L2 MTU is a 2-octet value indicating the CE-PE link MTU in bytes.  It
   MUST be same across all ES within one EVI on a local PE.

Yu & Wang                 Expires July 25, 2019                 [Page 4]
Internet-Draft       Usage of L2 Attributes in EVPN         January 2019

   If local PE does not support EVPN Layer 2 Attributes Extended
   Community, this community MUST be ignored.

   When a PE receives A-D routes with C, CI or F bit enabled, the
   behavior SHOULD be spread to all MAC tables towards the corresponding
   ES.

5.  Usage of Control Word

5.1.  EVPN ELAN

   The description on EVPN ELAN CW mechanism is based on the network
   topology showed in Figure 3:

                        +--------+       +--------+
                        |   PE1  |       |   PE2  |
                        |  (CW)  |-------|  (CW)  |
                        +--------+       +--------+
                              \           /
                               \         /
                                +--------+
                                |   PE3  |
                                |  (NCW) |
                                +--------+

   Figure 3: Network Topology for EVPN ELAN Control Word

   PE1 and PE2 are routers with CW enabled and PE3 is router CW disabled
   or without CW capability.  It is assumed that PE1, PE2 and PE3 are
   working in the same EVI.

5.1.1.  Deterministic mode

   When an EVPN ELAN working in deterministic mode, each PE advertises
   CW capability based on local status in auto-discovery route via l2
   attribute.  CI bit is not used in this mode.  In such case, C bit of
   devices in Figure 3 is: C bit of PE1 and PE2 is 1, C bit of PE3 is 0.
   After a PE receives EVPN auto-discovery route, it compares the value
   of C bit with local control word enable status.  If same, local PE
   treats remote PE as a valid EVPN destination.  If not same, local PE
   treats remote PE as an invalid EVPN destination.

   After such process:

   PE1 treats PE2 as valid destination and PE3 as invalid destination.

   PE2 treats PE1 as valid destination and PE3 as invalid destination.

Yu & Wang                 Expires July 25, 2019                 [Page 5]
Internet-Draft       Usage of L2 Attributes in EVPN         January 2019

   PE3 treats PE1 and PE2 as invalid destination.

   PE1 and PE2 will forward traffic with control word encapsulated.  PE1
   and PE2 will not be able to interoperate with PE3, due to control
   word status being different.

5.1.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 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.

   Considering EVPN label is "upstream-assigned", a PE can receive
   packets with same 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, the PE MUST set both C and CI bit = 0.

   After a PE receives EVPN auto-discovery route, it compares the value
   of C bit and CI:

   o  If C=CI: remote PE is treated as valid EVPN destination.

   o  Else: remote PE is treated as invalid EVPN destination.

   After such process, PE1, PE2 and PE3 treat each other as valid EVPN
   destination.

   When local PE forwards a packet to remote PE, if remote PE is control
   word enabled (C=1), then the unicast packet MUST be encapsulated with
   a control word indicator before control word.  If remote PE is
   control word disabled or no control word capability (C=0), then
   unicast packet is directly encapsulated after MPLS label as payload.

   For example:

   PE1 advertises A-D route with CI and C bit set 1, packet forwarding
   behavior is as below:

Yu & Wang                 Expires July 25, 2019                 [Page 6]
Internet-Draft       Usage of L2 Attributes in EVPN         January 2019

   PE2->PE1: Transport Label + EVPN Label to PE1 + CI + CW + Payload

   PE3->PE1: Transport Label + EVPN Label to PE1 + Payload

   PE2 advertises A-D route with CI and C bit set 1, PE3 advertise A-D
   route with CI and C bit set 0, packet forwarding from PE1 to PE2 and
   PE3 is as below::

   PE1->PE2: Transport Label + EVPN Label to PE2 + CI + CW + Payload

   PE1->PE3: Transport Label + EVPN Label to PE3 + Payload

   After a PE receives a packet, after looking at EVPN label, if it is
   bottom of stack, it indicates CW is not included behind.  If it is
   not bottom of stack, it indicates CW is included behind CI.

   When working in interoperable mode, impact of lacking complete CW
   between PEs SHOULD be evaluated based on section 8 of this document.

5.2.  EVPN VPWS

   The description on EVPN VPWS CW mechanism is based on the network
   topology showed in Figure 4:

                        +--------+       +--------+
                        |   PE1  |       |   PE2  |
                        |  (CW)  |-------|  (CW)  |
                        +--------+       +--------+
                              \
                               \
                                +--------+
                                |   PE3  |
                                |  (NCW) |
                                +--------+

   Figure 4: Network Topology for EVPN VPWS Control Word

   PE1 and PE2 are routers with CW enabled and PE3 is router CW disabled
   or without CW capability.  It is assumed that there is one EVPN VPWS
   between PE1 and PE2 and another VPWS between PE1 and PE3.

5.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.  In such case, C bit of devices in Figure 4 is: C bit of
   PE1 is 1, C bit of PE2 is 0.  After a PE receives EVPN auto-discovery

Yu & Wang                 Expires July 25, 2019                 [Page 7]
Internet-Draft       Usage of L2 Attributes in EVPN         January 2019

   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.

   After such process:

   EVPN VPWS between PE1 and PE2 is up.

   EVPN VPWS between PE1 and PE3 is down.

   PE1 and PE2 will forward traffic with control word encapsulated.

5.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.

   In such case:

   EVPN VPWS between PE1 and PE2 is up.

   EVPN VPWS between PE1 and PE3 is up.

   PE1 and PE2 will forward traffic with CW encapsulated.  PE1 and PE3
   forward traffic without CW encapsulated.

   When working in interoperable mode, impact of lacking complete CW
   between PEs SHOULD be evaluated based on section 8 of this document.

   CI MUST NOT set 1 when working in EVPN VPWS.

5.3.  EVPN E-Tree

   The procedure described in section 5.1 applies to EVPN E-Tree, both
   "two RTs" and "single RT" via "leaf" flag solution.

   When using "single RT" E-Tree, there is a particular case that
   devices with and without CW capability can interoperate without CI
   involved.  This case is: root device is CW disabled but (part of) the

Yu & Wang                 Expires July 25, 2019                 [Page 8]
Internet-Draft       Usage of L2 Attributes in EVPN         January 2019

   leaf devices CW enabled.  In such case, leaf PE SHOULD treat root and
   other leaves as valid EVPN destination, even C bit status is not
   consistent.  Leaf PEs with CW enabled forward known unicast traffic
   without CW encapsulated towards root.  Similarly when an E-tree is
   working in interoperable mode instead of deterministic mode, impact
   of lacking complete CW between PEs SHOULD be evaluated based on
   section 8 of this document.

6.  Usage of Flow Label

                        +--------+       +--------+
                        |   PE1  |       |   PE2  |
                        |  (FL)  |-------|  (FL)  |
                        +--------+       +--------+
                              \           /
                               \         /
                                +--------+
                                |   PE3  |
                                |  (NFL) |
                                +--------+

   Figure 5: Network Topology for Flow Label Usage

   Flow label is introduced allowing to achieve better load-balancing in
   the network in conditions mentioned below:

   o  Services in EVPN is not sensitive to misordering.

   o  Transit network has no capability parsing payload inside MPLS
      label as hash factor.

   PE1 and PE2 are routers with flow label capability and flow label
   enabled and PE3 is router flow label disabled or without flow label
   capability.  It is assumed that PE1, PE2 and PE3 are working in same
   EVI.

   When local PE receives auto-discovery routes from remote PE, F bit
   does not impact validation process of EVPN auto-discovery routes.
   Even F bit of remote PE does not match with local status, local PE
   SHOULD still add remote PE as a valid EVPN destination.

   When sending traffic from PE1 towards PE2 and PE3, as PE1 has already
   learnt the FL status of PE2 and PE3, packet encapsulation is as
   below:

   PE1->PE2: Transport Label + EVPN Label to PE2 + FL + Payload

   PE1->PE3: Transport Label + EVPN Label to PE3 + Payload

Yu & Wang                 Expires July 25, 2019                 [Page 9]
Internet-Draft       Usage of L2 Attributes in EVPN         January 2019

   When sending traffic from PE2 and PE3 towardsPE1, packet
   encapsulation is as below:

   PE2->PE1: Transport Label + EVPN Label to PE1 + FL + Payload

   PE3->PE1: Transport Label + EVPN Label to PE1 + Payload

   When PE1 receives a packet, after looking at EVPN label, if it is
   bottom of stack, it indicates FL is not included behind.  If it is
   not bottom of stack, it indicates FL is included behind.

   The flow label mechanism described above is applicable to both EVPN
   ELAN, E-Tree and EVPN VPWS.

7.  L2 MTU Processing

   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.

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 SHOULD NOT be used in EVPN carrying services sensitive to
   misordering.  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.

   Similarly, entropy label [RFC6790] SHOULD NOT be used in EVPN
   carrying services sensitive to misordering.

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.

Yu & Wang                 Expires July 25, 2019                [Page 10]
Internet-Draft       Usage of L2 Attributes in EVPN         January 2019

   When working with legacy devices without L2 attribute in EVPN ELAN,
   local PE SHOULD assume the behavior of all remote PE is same with
   local.  This allows backward compatibility of using L2 attribute.
   Also a route policy MAY be implemented to specify L2 behavior
   manually in case l2 attribute is absent.  This function SHOULD be
   used only for interoperability.  A PE SHOULD NOT overwrite existing
   l2 attribute in a received route.

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

   This document does not make any requests from IANA.

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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, <https://www.rfc-editor.org/info/rfc7432>.

   [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,
              <https://www.rfc-editor.org/info/rfc8214>.

   [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, <https://www.rfc-editor.org/info/rfc8317>.

   [RFC8469]  Bryant, S., Malis, A., and I. Bagdonas, "Recommendation to
              Use the Ethernet Control Word", RFC 8469,
              DOI 10.17487/RFC8469, November 2018,
              <https://www.rfc-editor.org/info/rfc8469>.

Yu & Wang                 Expires July 25, 2019                [Page 11]
Internet-Draft       Usage of L2 Attributes in EVPN         January 2019

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,
              <https://www.rfc-editor.org/info/rfc3032>.

   [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,
              <https://www.rfc-editor.org/info/rfc4448>.

   [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,
              <https://www.rfc-editor.org/info/rfc6391>.

   [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,
              <https://www.rfc-editor.org/info/rfc6790>.

Authors' Addresses

   Tianpeng Yu

   EMail: yutianpeng.ietf@gmail.com

   Haibo Wang
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Road
   Beijing   100085
   China

   EMail: rainsword.wang@huawei.com

Yu & Wang                 Expires July 25, 2019                [Page 12]