[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

BESS Workgroup                                                     T. Yu
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                        December 5, 2018
Expires: June 8, 2019


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

Abstract

   This document aims to define a negotiation mechanism for L2
   capabilities in an EVPN scenario.

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 June 8, 2019.

Copyright Notice

   Copyright (c) 2018 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
   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.






Yu                        Expires June 8, 2019                  [Page 1]


Internet-Draft         L2 Attributes in EVPN ELAN          December 2018


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specification of Requirements . . . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  EVPN Layer 2 Attributes Extended Community  . . . . . . . . .   3
   5.  Usage of Control Flags  . . . . . . . . . . . . . . . . . . .   4
   6.  L2 MTU Processing . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Instructions of using control word and Flow Label . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   EVPN [RFC7432] is lacking a negotiation mechanism on L2 capabilities.
   If the L2 capabilities between PE devices are different, they are not
   able to communicate properly.

   This document aims to define a negotiation mechanism for L2
   capabilities in an EVPN scenario.

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 speficies
   EVPN defined in [RFC7432]

   CW: Control Word defined in [RFC4448]

   CI: Control word indicator, defined in Section 4 of this document

   PE: Provider Edge

   FL: Flow label, defined in [RFC6391]








Yu                        Expires June 8, 2019                  [Page 2]


Internet-Draft         L2 Attributes in EVPN ELAN          December 2018


4.  EVPN Layer 2 Attributes Extended Community

   EVPN Layer 2 Attributes Extended Community is defined in EVPN VPWS
   [RFC8214].  This document describes the behaviors how it adapts to
   EVPN ELAN.  A mechanism to achieve interoperability between devices
   with and without CW capabilities is defined.  Flow Label mechanism is
   defined.  EVPN Layer 2 Attributes Extended Community is advertised
   along with Ethernet Auto-discovery.  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:

           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.  BUM traffic
   SHOULD NOT include control word when forwarded no matter C bit is set
   to 1 or 0 when working in ELAN mode.

   CI bit is defined to achieve interoperability between devices with
   and without control word capability.  Control Word Indicator is one
   octet with value 0xFF.  CI bit MUST NOT set 1 if C bit is set 0.  The
   usage of CI bit is described in Section 4.




Yu                        Expires June 8, 2019                  [Page 3]


Internet-Draft         L2 Attributes in EVPN ELAN          December 2018


   F bit is defined to achieve Flow-Aware Transport Labels [RFC6391] in
   EVPN.  It can be used 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 MUST be same across all Ethernet
   Segments within one EVI on a local PE.  BUM traffic SHOULD NOT
   include Flow label when forwarded no matter F bit is set to 1 or 0
   when working in ELAN mode.

   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.

   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 bits enabled, the
   behavior SHOULD be spreaded to all MAC tables towards the
   corresponding ES when applicable.

5.  Usage of Control Flags

   The description below is based on the network topology showed in
   Figure 3:

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

   Figure 3: Network Topology for Control Word Interoperability

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

   When local PE receives auto-discovery routes from remote PE, if CI=0,
   then goes process A, if CI=1, then goes to process B.

   Process A:




Yu                        Expires June 8, 2019                  [Page 4]


Internet-Draft         L2 Attributes in EVPN ELAN          December 2018


   Compare 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 treat PE2 as a valid destination and PE3 as
   an invalid destination.  PE2 treat PE1 as a valid destination and PE3
   as an invalid destination.  PE3 treat both PE1 and PE2 as an 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 difference.

   Process B:

   In this process, if C is set 0, then remote PE is treated as valid
   EVPN destination.  If C is set 1, then only when CI and C bit status
   is same with local, remote PE is treated as a valid EVPN destination.
   When local PE forwards a packet to remote PE, if remote PE is control
   word enabled, 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, 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:

   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 into EVPN label, if the
   first byte is "0xFF", it indicates control word is included behind.
   If the first byte is not "0xFF", it indicates control word is not
   included behind.

   The control word interoperability mechanism described above is not
   applicable to EVPN VPWS, it is applicable to EVPN ELAN.






Yu                        Expires June 8, 2019                  [Page 5]


Internet-Draft         L2 Attributes in EVPN ELAN          December 2018


   When working in EVPN VPWS mode, in case of C bit status is not
   consistent on both ends, VPWS SHOULD be teared up and behave like
   control word not enabled.

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

   Figure 4: Network Topology for Flow Label Interoperability

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

   o  Services in EVPN instance 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 encapulation is as below:

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

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

   When sending traffic from PE2 and PE3 towarding PE1, packet
   encapulation is as below:

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

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



Yu                        Expires June 8, 2019                  [Page 6]


Internet-Draft         L2 Attributes in EVPN ELAN          December 2018


   When PE1 recieves packets, after looking at EVPN label, it can be
   both bottom of stack or not.  When EVPN label is bottom of stack, and
   flow label enabled locally, packet MUST be treated as valid and parse
   following bytes as payload.

   The flow label mechanism described above is applicable to both EVPN
   ELAN and EVPN VPWS.

   When interoperating with devices not supporting EVPN Layer 2
   Attributes Extended Community, A-D routes received will not contain
   such community.  Local PE MAY assume the behavior of all remote PE is
   same with local.

   When data plane is not using MPLS, all bits in control flags MUST be
   0.  Control word and Flow Label are only applicable to MPLS data
   plane.

6.  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
   destination.

7.  Instructions of 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 of 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 MUST 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 MUST be disabled, otherwise control word will be treated as
   part of MAC address mistakenly.

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






Yu                        Expires June 8, 2019                  [Page 7]


Internet-Draft         L2 Attributes in EVPN ELAN          December 2018


8.  Security Considerations

   There are no new security considerations due to the text of this
   document.

9.  IANA Considerations

   This document does not make any requests from IANA.

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

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

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

   [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                        Expires June 8, 2019                  [Page 8]


Internet-Draft         L2 Attributes in EVPN ELAN          December 2018


Author's Address

   Tianpeng Yu
   Huawei Technologies

   EMail: yutianpeng.ietf@gmail.com













































Yu                        Expires June 8, 2019                  [Page 9]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/