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

Versions: 00 01                                                         
BESS WG                                                          Y. Wang
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                            11 July 2021
Expires: 12 January 2022


                   AC-Influenced DF Election per EVI
                 draft-wang-bess-evpn-ac-df-per-evi-01

Abstract

   The AC-influenced DF Election (AC-DF) per [RFC8584] is too dependent
   on EAD/EVI routes.  For example, when no failures occured on an ESI,
   that AC-DF procedures will give incorrect results if no EAD/EVI
   routes are advertised.  But in some light-weighted EVPNs (i.e.  PBB
   EVPNs), no EAD/EVI routes will be advertised at all.

   This draft proposes some new extensions to support AC-influenced DF
   Election without any EAD/EVI routes advertised in advance of any
   <ESI, EVI> failures.

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 12 January 2022.

Copyright Notice

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



Wang                     Expires 12 January 2022                [Page 1]


Internet-Draft                AC-DF per EVI                    July 2021


   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
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  AC-DF per EVI . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Use Case  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  AC-DF per EVI Capability  . . . . . . . . . . . . . . . .   4
       2.2.1.  Capability Negotiation Procedures . . . . . . . . . .   4
       2.2.2.  AC-DF Capability vs AC-DF per EVI Capability  . . . .   4
     2.3.  DF Election Procedures  . . . . . . . . . . . . . . . . .   4
       2.3.1.  Initiation of AC-DF per EVI Mode  . . . . . . . . . .   4
       2.3.2.  Reverse EAD/EVI Route . . . . . . . . . . . . . . . .   5
       2.3.3.  DF Election Rules . . . . . . . . . . . . . . . . . .   5
       2.3.4.  Route Filtering and RT Constraints Mechanism  . . . .   6
   3.  Other considerations  . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Reverse EAD/EVI Route in PBB EVPNs  . . . . . . . . . . .   6
     3.2.  Why no EAD/EVI Routes Advertised  . . . . . . . . . . . .   6
   4.  Comparison with other solutions . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  New DF Election Capability  . . . . . . . . . . . . . . .   8
     6.2.  New EVPN Layer 2 Attributes Control Flags . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   9.  Informative References  . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   When the EAD/EVI route is not advertised before the corresponding ESI
   sub-interface fails, The AC-influenced DF Election procedures should
   elect the right DF before and after that failure.

   Note that according to [RFC8584], the AC-influenced DF Election will
   be incorrect when no EAD/EVI route is advertised, even if no ESI sub-
   interface has failed at all.

   This draft proposes some extension to DF-Capability negotiation and
   DF-Election procedures to support AC-influenced DF-election when no
   EAD/EVI routes are advertised.







Wang                     Expires 12 January 2022                [Page 2]


Internet-Draft                AC-DF per EVI                    July 2021


1.1.  Terminology

   Most of the terminology used in this documents comes from [RFC8584]
   and [RFC7623] except for the following:

   *  Light-weighted EVPN: The EVPN solution without EAD/EVI Route
      advertisedment.

   *  EAD/ES: Ethernet A-D route per EVI, or RT-1 per ES route.

   *  EAD/EVI: Ethernet A-D route per EVI, or RT-1 per EVI route.

2.  AC-DF per EVI

2.1.  Use Case

   The ethernet segment ES1's ESI is ESI1, AC1/AC2 is two sub-interfaces
   on ES1, and AC3/AC4 is two sub-interfaces on ES2.  AC1 and AC3 are
   attached to EVPN Instance EVI1, while AC2 and AC4 are attached to
   EVI2.  The redundancy mode of ES1 is all-active.

                                    +----------+
                      PE1           |          |
                 +-------------+    |          |
                 | AC1         |    |          |         PE3
                /| AC2         |----|          |   +-------------+
               / |             |    |          |   |             |
          LAG /  +-------------+    |          |   |         AC3 |---CE2
      CE1=====                      |   PSN    |   |         AC4 |
              \  +-------------+    |          |---|             |
               \ |             |    |          |   +-------------+
                \| AC2         |----|          |
                 | AC1         |    |          |
                 +-------------+    |          |
                      PE2           |          |
                                    +----------+

                      Figure 1: AC-DF per EVI Usecase

   EVI1 and EVI2 are two EVPN Instances, and there are no EAD/EVI routes
   advertised for them.  Such EVPN Instances are called Light-weighted
   EVPNs in this draft.  For example, EVI1 and EVI2 can be the
   I-Components of PBB EVPNs, because no EAD/EVI routes are advertised
   for these I-Components.

   Initially PE1 is the DF for <ESI1, EVI1>, and PE2 is the DF for
   <ESI1, EVI2>.  When the AC1 of PE1 fails (but ESI1 and AC2 of PE1
   still works well), the DF for <ESI1, EVI1> should switch to PE2.



Wang                     Expires 12 January 2022                [Page 3]


Internet-Draft                AC-DF per EVI                    July 2021


   The DF-election should be done without any EAD/EVI routes advertised
   before any ESI sub-interface fails.  Otherwise those EAD/EVI routes
   are advertised just for the adaptation of AC-influenced DF-election
   procedures per [RFC8584], but will do nothing good for the unicast
   packet forwarding in data plane (because data plane MAC learning
   don't use EAD/EVI routes).

2.2.  AC-DF per EVI Capability

   We introduce a new bit named "AC-DF per EVI" in the "bitmap" field of
   the DF Election extended community.  The "AC-DF per EVI" bit means
   that the DF-Election for an <ESI, EVI> will not take EAD/EVI routes
   into considerations untill a Reverse EAD/EVI route for that <ESI,
   EVI> is received from any of the PEs.

2.2.1.  Capability Negotiation Procedures

   Only when all RT-4 routes of the same ESI indicate the "AC-DF per
   EVI" Capability, The DF Election will be executed in "AC-DF per EVI"
   mode.  We can say that the DF Election mode for that ESI is
   negotiated as "AC-DF per EVI" mode.

   Note that when any of the PEs on that ES is an old PE that don't
   support "AC-DF per EVI" mode, the RT-4 route from that PE will not
   indicate the "AC-DF per EVI" Capability, So the DF election will not
   be executed in "AD-DF per EVI" mode.  This is for compatibility
   purpose.

2.2.2.  AC-DF Capability vs AC-DF per EVI Capability

   When all RT-4 routes of the same ESI indicate both the "AC-DF per
   EVI" Capability and the old AC-DF Capability, The DF Election will be
   executed in "AD-DF per EVI" mode.

   Note that when any of the PEs on that ES is an old PE that don't
   support "AC-DF per EVI" mode, the RT-4 route from that PE may
   indicate the "old AC-DF" Capability only, So the DF election will
   still be executed in old AD-DF mode per [RFC8584].  This is for
   compatibility purpose.

2.3.  DF Election Procedures

2.3.1.  Initiation of AC-DF per EVI Mode

   According to [RFC8584], the AC-influenced DF Election will be
   incorrect when no EAD/EVI route is advertised, even if no ESI sub-
   interface has failed at all.




Wang                     Expires 12 January 2022                [Page 4]


Internet-Draft                AC-DF per EVI                    July 2021


   But when the DF Election mode for an ESI is negotiated as AC-DF per
   EVI mode, no normal EAD/EVI routes can impact the DF Election
   procedures.  The DF election will be done following that ESI's RT-4
   routes only until at least one reverse EAD/EVI route is received.

2.3.2.  Reverse EAD/EVI Route

   In order to do AC-influenced DF election after a sub-interface of
   that ES fails, we introduce the "Reverse EAD/EVI Route".  The reverse
   EAD/EVI Route is a special type of EAD/EVI Route that is advertised
   on the failure of corresponding <ESI, EVI>, not on the activation of
   that <ESI, EVI>.

   Reverse EAD/EVI routes can use the same format as EAD/EVI Routes
   except for the following differences:

   *  A Reverse EAD/EVI Route carries an EVPN Layer 2 Attributes
      Extended Community whose "Control Flags" field includes a new flag
      named "AC Down".  The "AC Down" flag means that the corresponding
      AC (for which the Reverse EAD/EVI route is advertised) is down.

   *  It is recommended to carry an ES-Import RT ([RFC7432]) and an EVI-
      RT ([I-D.ietf-bess-evpn-igmp-mld-proxy]) along with a reverse EAD/
      EVI route, no traditional Route-Targets have to be carried for DF-
      election purpose.

   *  A Reverse EAD/EVI Route should make its MPLS label field be set to
      zero.

   Note that when the corresponding sub-interface fails, the
   MP_REACH_NLRI of the reverse EAD/EVI route is advertised, and when
   the corresponding sub-interface recovers, the MP_UNREACH_NLRI of the
   reverse EAD/EVI route is sent.  This is the opposite of normal EAD/
   EVI route.  So it is called as reverse EAD/EVI route.

2.3.3.  DF Election Rules

   When a Reverse EAD/EVI Route for an <ESI, EVI> is received from a
   remote PE X, the RT-4 Route of that PE x are expelled from that <ESI,
   EVI>'s DF election.  Then the DF election for that <ESI, EVI> will be
   updated according to the corresponding DF Alg.

   Note that the DF election for other <ESI, EVI>s will not be affected
   by that Reverse EAD/EVI Route.







Wang                     Expires 12 January 2022                [Page 5]


Internet-Draft                AC-DF per EVI                    July 2021


2.3.4.  Route Filtering and RT Constraints Mechanism

   When PE Y receives a reverse EAD/EVI route from PE X, and the ES-
   Import RT of that route can't match any local ES of PE Y, PE Y will
   not import that route into the EVI that is identified by that route's
   EVI-RT.

   When RT Constraints Mechanism is enabled, each reverse EAD/EVI route
   will be distributed to the adjacent PEs of its ES only.  Because that
   only the ES-Import RT are visible to the RT Constraints Mechanism,
   The EVI-RT is not visible to the RT Constraints Mechanism.

3.  Other considerations

3.1.  Reverse EAD/EVI Route in PBB EVPNs

   The AC-DF per EVI mode is not confined to PBB EVPN which is just an
   example of light-weighted EVPNs.  But in PBB EVPN, the construction
   of reverse EAD/EVI route need some special considerations.

   *  It's EVI-RT should be the export route-target of the B-Component,
      not the C-Component.

   *  It's Ethernet Tag ID (ETI) should be the I-SID of the I-Component.

   Note that when PE Z receives a reverse EAD/EVI route whose EVI-RT
   matches a local B-Component but whose ETI matches none of the
   I-Components of that B-Component, PE Z may not import that reverse
   EAD/EVI route.

   Note that the reverse EAD/EVI route don't have to carry any B-MAC
   along with it.  Because that the B-MAC can do nothing helpful for the
   DF election.

3.2.  Why no EAD/EVI Routes Advertised

   When no RT-2 Routes advertised, no EAD/EVI routes need to be
   advertised either.  PBB EVPN is an example of that.  In PBB EVPN, the
   C-MACs are learnt in the data plane.

   Other light-weighted EVPNs also do data plane C-MAC learning, so they
   don't have to advertise EAD/EVI routes either.  In such EVPNs, AC-DF
   per EVI will help.








Wang                     Expires 12 January 2022                [Page 6]


Internet-Draft                AC-DF per EVI                    July 2021


4.  Comparison with other solutions

   PBB EVPN can assign a deicated vES to each sub-interface, in such
   case, the RT-4 routes are advertised per each sub-interface (or
   vESI).  But this will bring out some other disadvantages:

   *  The uniformity of service carving can't be achieved without
      careful configuring.

      With service carving, it is possible to elect multiple DFs per ES
      (one per EVI) in order to perform load balancing of traffic
      destined to a given ES.  The objective is that the load-balancing
      procedures should carve up the BD space among the redundant PE
      nodes evenly, in such a way that every PE is the DF for a distinct
      set of EVIs.

      When each EVI use a dedicated vESI to advertise the corresponding
      Ethernet Segment Routes for that <ES, EVI>, The service carving
      mechanisms can not work without manual configuration.

   *  The amount of B-MACs will be greatly increased.

   The brief comparisons are listed as the following table:

      +====================+================+=======================+
      | Items              | AC-DF per EVI  |          vESI         |
      +====================+================+=======================+
      | ESIs               |  one per port  | one per sub-interface |
      +--------------------+----------------+-----------------------+
      | RT-4 Routes        |  one per port  | one per sub-interface |
      +--------------------+----------------+-----------------------+
      | B-MACs             |  one per port  | one per sub-interface |
      +--------------------+----------------+-----------------------+
      | Service Carving    |      auto      |   manual-configured   |
      +--------------------+----------------+-----------------------+
      | EAD per EVI routes |      none      |          none         |
      +--------------------+----------------+-----------------------+
      | Reverse EAD per    | one per failed |          none         |
      | EVI routes         | sub-interfaces |                       |
      +--------------------+----------------+-----------------------+

                Table 1: Comparisons with vESI for PBB-EVPN

   Using AC-DF per EVI mode, the service-carving is automatically
   achieved, and no extra B-MACs should be configured and advertised.






Wang                     Expires 12 January 2022                [Page 7]


Internet-Draft                AC-DF per EVI                    July 2021


5.  Security Considerations

   Security considerations will be added in future versions.

6.  IANA Considerations

6.1.  New DF Election Capability

   IANA will be requested to allocate a new DF Election Capability in
   the "DF Election Capabilities" Registry.  This capability is called
   "AC-DF per EVI Capability".

           Bit         Name                             Reference
           ----        ----------------                 -------------
           4           AC-DF per EVI Capability         This draft


                     Figure 2: AC-DF per EVI Capability

6.2.  New EVPN Layer 2 Attributes Control Flags

   IANA will be requested to allocate a new Control Flag in the "EVPN
   Layer 2 Attributes Control Flags" Registry.  This Control Flag is
   called "D" Flag, where "D" means AC-Down.

      Bit     Name                                        Reference
      ----    ----------------                            -------------
      D       AC-Down on Advertising PE                   This Draft


                         Figure 3: AC Failure Flag

7.  Acknowledgements

   The authors would like to thank the following for their comments and
   review of this document:

   Chunning Dai.

8.  Normative References

   [I-D.ietf-bess-evpn-igmp-mld-proxy]
              Sajassi, A., Thoria, S., Mishra, M. P., Patel, K., Drake,
              J., and W. Lin, "IGMP and MLD Proxy for EVPN", Work in
              Progress, Internet-Draft, draft-ietf-bess-evpn-igmp-mld-
              proxy-09, 19 April 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
              evpn-igmp-mld-proxy-09>.



Wang                     Expires 12 January 2022                [Page 8]


Internet-Draft                AC-DF per EVI                    July 2021


   [I-D.ietf-bess-srv6-services]
              Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R.,
              Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based
              Overlay Services", Work in Progress, Internet-Draft,
              draft-ietf-bess-srv6-services-07, 11 April 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
              srv6-services-07>.

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

   [RFC7623]  Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
              Henderickx, "Provider Backbone Bridging Combined with
              Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
              September 2015, <https://www.rfc-editor.org/info/rfc7623>.

   [RFC8584]  Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
              J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
              VPN Designated Forwarder Election Extensibility",
              RFC 8584, DOI 10.17487/RFC8584, April 2019,
              <https://www.rfc-editor.org/info/rfc8584>.

9.  Informative References

   [RFC7041]  Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed.,
              "Extensions to the Virtual Private LAN Service (VPLS)
              Provider Edge (PE) Model for Provider Backbone Bridging",
              RFC 7041, DOI 10.17487/RFC7041, November 2013,
              <https://www.rfc-editor.org/info/rfc7041>.

   [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
              L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
              eXtensible Local Area Network (VXLAN): A Framework for
              Overlaying Virtualized Layer 2 Networks over Layer 3
              Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
              <https://www.rfc-editor.org/info/rfc7348>.

   [RFC8365]  Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
              Uttaro, J., and W. Henderickx, "A Network Virtualization
              Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
              DOI 10.17487/RFC8365, March 2018,
              <https://www.rfc-editor.org/info/rfc8365>.

Author's Address





Wang                     Expires 12 January 2022                [Page 9]


Internet-Draft                AC-DF per EVI                    July 2021


   Yubao Wang
   ZTE Corporation
   No.68 of Zijinghua Road, Yuhuatai Distinct
   Nanjing
   China

   Email: wang.yubao2@zte.com.cn












































Wang                     Expires 12 January 2022               [Page 10]