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

Versions: 00 01 02 03 04 05

BESS Workgroup                                                T. Yu, Ed.
Internet-Draft
Updates: RFC7432, RFC8214 (if approved)                          H. Wang
Intended status: Standards Track                     Huawei Technologies
Expires: October 5, 2019                                   April 3, 2019


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

Abstract

   This document adopts Layer 2 Attributes Extended Community defined in
   [RFC8214] to EVPN allowing negotiate Layer2 information in the
   control plane.

   An interoperability mechanism between PEs with and without control
   word capability is described for EVPN and VPWS in this document.

   Flow label signaling mechanism is also described for EVPN ELAN and
   VPWS with interoperability capability considered.

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 October 5, 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



Yu & Wang                Expires October 5, 2019                [Page 1]


Internet-Draft       Usage of L2 Attributes in EVPN           April 2019


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specification of Requirements . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  EVPN Layer 2 Attributes Extended Community  . . . . . . . . .   4
     4.1.  Control Flag Attribute  . . . . . . . . . . . . . . . . .   6
     4.2.  L2 MTU Attribute  . . . . . . . . . . . . . . . . . . . .   7
   5.  Control Word Indicator Extended Community . . . . . . . . . .   7
   6.  Usage of Control Word . . . . . . . . . . . . . . . . . . . .   8
     6.1.  EVPN ELAN . . . . . . . . . . . . . . . . . . . . . . . .   8
       6.1.1.  Deterministic mode  . . . . . . . . . . . . . . . . .   8
       6.1.2.  Interoperable mode  . . . . . . . . . . . . . . . . .   9
     6.2.  EVPN VPWS . . . . . . . . . . . . . . . . . . . . . . . .   9
       6.2.1.  Deterministic mode  . . . . . . . . . . . . . . . . .   9
       6.2.2.  Interoperable mode  . . . . . . . . . . . . . . . . .   9
   7.  Usage of Flow Label . . . . . . . . . . . . . . . . . . . . .  10
   8.  Instructions on Using Control Word and Flow Label . . . . . .  10
   9.  Other Considerations  . . . . . . . . . . . . . . . . . . . .  11
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     13.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Appendix A.  Example of using Layer 2 Attributes Extended
                Community  . . . . . . . . . . . . . . . . . . . . .  13
     A.1.  Example 1: ELAN Control Word Deterministic mode . . . . .  13
     A.2.  Example 2: ELAN Control Word Interoperable mode . . . . .  13
     A.3.  Example 3: Usage of Flow Label  . . . . . . . . . . . . .  14
     A.4.  Example 4: Combination of Control Word and Flow Label . .  14
     A.5.  Example 5: Combination of CW Interoperable mode and FL  .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   EVPN [RFC7432] lacks a negotiation mechanism on L2 capabilities.
   Lacking such capabilities will lead to malformed packets on
   forwarding plane without any prevention from the control plane
   signaling.  Issues caused due to mismatch of Layer 2 capabilities are
   listed below:




Yu & Wang                Expires October 5, 2019                [Page 2]


Internet-Draft       Usage of L2 Attributes in EVPN           April 2019


   o  Mismatching of MTU across interfaces attached within one EVPN ELAN
      or VPWS leads to consistent packet loss on the interface with
      smaller MTU than the other interfaces, due to fragmentation is not
      possible in the Layer 2 network.

   o  Mismatching of control word enable status between PEs within the
      same EVPN ELAN or VPWS leads to control word being treated as
      payload of the EVPN instead of being stripped off.

   [RFC8214] defines Layer 2 Attributes Extended Community but there is
   no definition on how it is used in EVPN ELAN.

   There are scenarios that PEs are deployed in a mixed environment
   where some PEs support Control Word but others not.  The behavior and
   interoperate mechanism of such scenario is needed.

   There is also a requirement on flow label capability on EVPN ELAN and
   VPWS in absence of entropy label.  The signaling capability of flow
   label on the control plane is also necessary.

   In summary, this document aims to describe how Layer 2 Attributes
   Extended Community to be used in EVPN ELAN, with targets listed
   below:

   o  MTU consistency validation for EVPN ELAN.

   o  CW (Control Word) consistency validation for EVPN ELAN.

   o  Introduce a CW interoperate mechanism in case not all devices
      within the EVPN ELAN or VPWS support Control Word.

   o  Introduce flow label signaling mechanism allowing EVPN ELAN and
      VPWS to achieve better load balancing, with interoperability
      capability considered.

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





Yu & Wang                Expires October 5, 2019                [Page 3]


Internet-Draft       Usage of L2 Attributes in EVPN           April 2019


   EVPN ELAN: In order to distinguish EVPN VPWS, EVPN ELAN specifies
   EVPN defined in [RFC7432].

   EVI: An EVPN ELAN Instance.

   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: Broadcast, Unknown-Unicast, Multicast.

   P2MP: Point to Multi-Point.

   MP2P: Multi-Point to Point.

   MP2MP: Multi-Point to Multi-Point.

   LSP: Label-Switched Path.

   EAD Route: Ethernet Auto-discovery Route Route defined in [RFC7432].

   IMET Route: Inclusive Multicast Ethernet Tag Route defined in
   [RFC7432].

   BoS: Bottom-of-Stack.

4.  EVPN Layer 2 Attributes Extended Community

   The definition of EVPN Layer 2 Attributes Extended Community is the
   same with [RFC8214]. it is listed as below for convenience.













Yu & Wang                Expires October 5, 2019                [Page 4]


Internet-Draft       Usage of L2 Attributes in EVPN           April 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.  Layer 2 Attributes Extended Community is necessary for per
   Ethernet Segment based EAD (section 8.2.1 of [RFC7432]) and optional
   for per EVPN instance based EAD (section 8.4.1 of [RFC7432]).

   For a single-homed ES in ELAN, the Layer 2 Attributes Extended
   Community is advertised along with a per EVI based EAD route with an
   all-zero ESI and a set of RTs corresponding to the EVI on the PE.
   This updates the behavior defined in section 8.2.1 of [RFC7432],
   which says "The Ethernet A-D route is not needed when the Segment
   Identifier is set to 0".

   For an EVPN ELAN, Layer 2 Attributes Extended Community included in
   EAD route applies to unicast traffic and IMET Route applies to BUM
   traffic.

   Layer 2 Attributes Extended Community for unicast SHOULD be same
   across all Ethernet Segments in EAD routes within one EVI on a local
   PE when used in EVPN ELAN.

   Layer 2 Attributes Extended Community for BUM SHOULD be same across
   EVIs in IMET route sharing the same P-Tunnel within a PE.

   Any inconsistency on L2 Attributes Extended Community of interfaces
   attached to the same EVI (EAD route) MUST or EVIs sharing same
   P-tunnel (IMET route) SHOULD be resolved before the corresponding
   route being advertised.

   Layer 2 Attributes Extended Community MAY be different between EAD
   route and IMET Route for one EVI.  For example, EAD route advertises
   control word capability but IMET route advertises no control word
   capability.  This means, the validation of Layer 2 Attributes
   Extended Community in EAD and IMET route are independent.





Yu & Wang                Expires October 5, 2019                [Page 5]


Internet-Draft       Usage of L2 Attributes in EVPN           April 2019


   When a PE receives routes without L2 Attributes Extended Community,
   the 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

   The P bit and B bit defined in [RFC8214] must be zero when used in
   EVPN ELAN 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 in IMET route for P2MP or MP2MP LSPs.

   F bit is defined to achieve flow label signaling 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 in IMET route for 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.  The target of



Yu & Wang                Expires October 5, 2019                [Page 6]


Internet-Draft       Usage of L2 Attributes in EVPN           April 2019


   CI is to allow equipments with CW capability and a higher level of
   programmability to be able to communicate together with equipments
   has and does not have CW capability together in an MP2MP ELAN
   network.

   CI label MUST NOT be a MPLS reserved label [RFC3032], MUST be with
   TTL=1.  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.

   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 absence of Control Word Indicator Extended Community, EVPN
      service label MAY be copied into CWI.

   The usage of CI bit is described in Section 6.

   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 SHOULD NOT add the remote PE as the EVPN ELAN
   or VPWS destination.  The process described is applicable to both EAD
   and IMET routes.

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
   to indicate 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.





Yu & Wang                Expires October 5, 2019                [Page 7]


Internet-Draft       Usage of L2 Attributes in EVPN           April 2019


   When a PE advertising the community, it MUST ensure value of CWI
   label same across Ethernet Segments within one EVI in EAD route and
   EVIs sharing the same P-Tunnel in IMET route.  CI label value
   advertised SHOULD NOT be same with EVPN service labels.  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 existence 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 existence of CW.

   When CI bit and F bit set 1 together, Control Word Indicator Extended
   Community MUST be included.  The packet encapsulation from ingress PE
   is: transport label(s) + EVPN service label(s) + CI + FL (BoS) + 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
   calculated locally does not equal CI value learnt from EVPN routes.

      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

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 received routes are same with local statue,
   the received routes are treated valid.  CI bit is not used in this
   mode.








Yu & Wang                Expires October 5, 2019                [Page 8]


Internet-Draft       Usage of L2 Attributes in EVPN           April 2019


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.

   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 received routes, received routes are
   treated valid.

   With such procedure, an egress PE is able to identify existence of CW
   on forwarding plane via CI for packets received 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.



Yu & Wang                Expires October 5, 2019                [Page 9]


Internet-Draft       Usage of L2 Attributes in EVPN           April 2019


   When an EVPN VPWS working in interoperable mode, in case of C bit
   status is not consistent on both ends, VPWS MUST tear up with control
   word disabled on both ends.

   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 signaling 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
   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 contained 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 to 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.







Yu & Wang                Expires October 5, 2019               [Page 10]


Internet-Draft       Usage of L2 Attributes in EVPN           April 2019


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

   TBD

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

12.  IANA Considerations

   IANA is requested to allocate a new "EVPN Extended Community Sub-
   Types" registry defined in [RFC7153] as follow:

    SUB-TYPE   NAME                                         Reference
    -------------------------------------------------------------------
      TBD     Control Word Indicator Extended Community  This document

13.  References

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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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



Yu & Wang                Expires October 5, 2019               [Page 11]


Internet-Draft       Usage of L2 Attributes in EVPN           April 2019


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

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


















Yu & Wang                Expires October 5, 2019               [Page 12]


Internet-Draft       Usage of L2 Attributes in EVPN           April 2019


Appendix A.  Example of using Layer 2 Attributes Extended Community

   The procedures described below are applicable to both EAD and IMET
   routes, if the applicable route is not explicitly specified.

A.1.  Example 1: ELAN Control Word Deterministic mode

   Assume PE1 and PE2 have CW capability and announce C=1, PE3 has no CW
   capability and announces C=0.  When working in control word
   deterministic mode, CI is announced with 0.

   After validation of Layer2 Attribute Extended community, PE1 and PE2
   treat each other as valid destination, and PE3 as invalid
   destination.

   Packet encapsulation is as below:

   o  PE1 <-- Transport label(s) + EVPN label(s) + CW + Payload --> PE2

   o  PE1 <-- Not allowed --> PE3

   o  PE2 <-- Not allowed --> PE3

A.2.  Example 2: ELAN Control Word Interoperable mode

   Assume PE1 and PE2 have CW capability and announce C=1, CI=1, PE3 has
   no CW capability and announces C=0 and CI=0.

   After validation of Layer2 Attribute Extended community, PE1, PE2 and
   PE3 treat each other as valid destination.

   Packet encapsulation is as below:

   o  PE1 <-- Transport label(s) + EVPN label(s) + CI (BoS) + CW +
      Payload --> PE2

   o  PE1 <-- Transport label(s) + EVPN label(s) + Payload --> PE3

   o  PE2 <-- Transport label(s) + EVPN label(s) + Payload --> PE3

   In this scenario, CI label can be either the EVPL label closest to
   the BoS, or signaled via Control Word Indicator Extended Community.
   existence of CI can be identified via EVPN labels not being BoS or CI
   label being advertised.







Yu & Wang                Expires October 5, 2019               [Page 13]


Internet-Draft       Usage of L2 Attributes in EVPN           April 2019


A.3.  Example 3: Usage of Flow Label

   Assume PE1 and PE2 have FL capability and announce F=1, PE3 has no FL
   capability and announces F=0.  Assume control word of PE1, PE2 and
   PE3 are disabled and C=0.

   After validation of Layer2 Attribute Extended community, PE1, PE2 and
   PE3 treat each other as valid destination.

   Packet encapsulation is as below:

   o  PE1 <-- Transport label(s) + EVPN label(s) + FL (BoS) + Payload
      --> PE2

   o  PE1 <-- Transport label(s) + EVPN label(s) + Payload --> PE3

   o  PE2 <-- Transport label(s) + EVPN label(s) + Payload --> PE3

A.4.  Example 4: Combination of Control Word and Flow Label

   Considering it is possible that transit node looks into flow label
   (BoS), parse the first nibble of payload wrongly and lead to
   misordering, control word mechanism is still applicable when flow
   label being used.

   Assume PE1 and PE2 have FL capability and announce F=1, PE3 has no FL
   capability and announces F=0.  Assume control word of PE1, PE2 and
   PE3 are enabled and C=1.

   After validation of Layer2 Attribute Extended community, PE1, PE2 and
   PE3 treat each other as valid destination.

   Packet encapsulation is as below:

   o  PE1 <-- Transport label(s) + EVPN label(s) + FL (BoS) + CW +
      Payload --> PE2

   o  PE1 <-- Transport label(s) + EVPN label(s) + CW + Payload --> PE3

   o  PE2 <-- Transport label(s) + EVPN label(s) + CW + Payload --> PE3

A.5.  Example 5: Combination of CW Interoperable mode and FL

   Assume PE1 and PE2 have FL capability and announce F=1, PE3 has no FL
   capability and announces F=0.  Assume control word of PE1 and PE2 are
   enabled and C=1, CI=1, control word of PE3 is disabled and C=0 CI=0.





Yu & Wang                Expires October 5, 2019               [Page 14]


Internet-Draft       Usage of L2 Attributes in EVPN           April 2019


   After validation of Layer2 Attribute Extended community, PE1, PE2 and
   PE3 treat each other as valid destination.

   Packet encapsulation is as below:

   o  PE1 <-- Transport label(s) + EVPN label(s) + CI + FL (BoS) + CW +
      Payload --> PE2

   o  PE1 <-- Transport label(s) + EVPN label(s) + Payload --> PE3

   o  PE2 <-- Transport label(s) + EVPN label(s) + Payload --> PE3

   In this scenario, when F=1 and CI=1, value of CI MUST be signaled via
   Control Word Indicator Extended Community. existence of CI is
   identified via CI value being advertised instead of BoS. existence of
   FL is identified via CI not being BoS.

   Another possibility is: PE1 and PE2 announce F=1, PE3 announces F=0.
   PE1 and PE3 announce C=1 and CI=1, PE2 announces C=0.

   After validation of Layer2 Attribute Extended community, PE1, PE2 and
   PE3 treat each other as valid destination.

   Packet encapsulation is as below:

   o  PE1 <-- Transport label(s) + EVPN label(s) + FL (BoS) + Payload
      --> PE2

   o  PE1 <-- Transport label(s) + EVPN label(s) + CI (BoS) + CW +
      Payload --> PE3

   o  PE2 <-- Transport label(s) + EVPN label(s) + Payload --> PE3

   In this scenario, when F=1 and CI=1 on PE1, value of CI on PE1 MUST
   be signaled via Control Word Indicator Extended Community. existence
   of CI is identified via CI value being advertised instead of BoS.

Authors' Addresses

   Tianpeng Yu (editor)

   EMail: yutianpeng.ietf@gmail.com


   Haibo Wang
   Huawei Technologies

   EMail: rainsword.wang@huawei.com



Yu & Wang                Expires October 5, 2019               [Page 15]


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