[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 draft-ietf-bess-evpn-ac-df

BESS Workgroup                                                J. Rabadan
Internet Draft                                                K. Nagaraj
                                                            S. Sathappan
Intended status: Standards Track                           W. Henderickx
                                                          Alcatel-Lucent

Expires: April 27, 2015                                 October 24, 2014




       AC-influenced Designated Forwarder Election for (PBB-)EVPN
                    draft-rabadan-bess-evpn-ac-df-00

Abstract

   The Designated Forwarder (DF) in (PBB-)EVPN networks is the PE
   responsible for sending multicast, broadcast and unknown unicast
   traffic to a multi-homed CE, on a given Ethernet Tag on a particular
   Ethernet Segment (ES). The DF is selected based on the list of PEs
   that advertise the Ethernet Segment Identifier (ESI) to the EVPN
   network. While PE node or link failures trigger the DF re-election
   for a given <ESI, EVI>, individual Attachment Circuit (AC) or MAC-VRF
   failures do not trigger such DF re-election and the traffic may
   therefore be permanently impacted, even though there is an
   alternative path. This document improves the DF election algorithm so
   that the AC status can influence the result of the election and this
   type of "logical" failures can be protected too.


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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt




Rabadan et al.           Expires April 27, 2015                 [Page 1]


Internet-Draft       AC-based DF election for EVPN      October 24, 2014


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on April 27, 2015.

Copyright Notice

   Copyright (c) 2014 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
   (http://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.


Table of Contents

   1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . .  2
   2. Solution description  . . . . . . . . . . . . . . . . . . . . .  4
     2.1. AC-influenced DF Election for EVPN  . . . . . . . . . . . .  4
       2.1.1. Current DF election procedure and AC failures . . . . .  5
       2.1.2. The Attachment Circuit (AC) influenced DF election  . .  6
     2.2. AC-influenced DF Election for PBB-EVPN  . . . . . . . . . .  7
       2.2.1. Current DF election procedure and AC failures . . . . .  8
       2.2.2. BGP encoding for advertising ACS per <ESI, ISID>  . . .  9
       2.2.3. The AC-influenced DF Election . . . . . . . . . . . . . 10
   3. Solution benefits . . . . . . . . . . . . . . . . . . . . . . . 11
   4. Conventions used in this document . . . . . . . . . . . . . . . 11
   5. Security Considerations . . . . . . . . . . . . . . . . . . . . 11
   6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
   7. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1. Normative References  . . . . . . . . . . . . . . . . . . . 12
     7.2. Informative References  . . . . . . . . . . . . . . . . . . 12
   8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12



1. Problem Statement

   [EVPN] defines the Designated Forwarder (DF) as the (PBB-)EVPN PE
   responsible for:



Rabadan et al.           Expires April 27, 2015                 [Page 2]


Internet-Draft       AC-based DF election for EVPN      October 24, 2014


   o Flooding Broadcast, Unknown unicast and Multicast traffic (BUM), on
     a given Ethernet Tag on a particular Ethernet Segment (ES), to the
     CE. This is valid for single-active and all-active EVPN
     multi-homing.

   o Sending unicast traffic on a given Ethernet Tag on a particular ES
     to the CE. This is valid for single-active multi-homing.

   The default DF election algorithm defined by [EVPN] is called
   service-carving and, for a given ESI, is based on a (V mod N)= i
   function that provides a local DF election of a PEi at <ESI, EVI>
   level (for EVPN) and at <ESI, ISID> level for PBB-EVPN. V is the
   Ethernet Tag associated to the EVI (the numerically lowest Ethernet
   Tag value in case of multiple Ethernet Tags), whereas N is the number
   of PEs for which ES routes have been successfully imported. In other
   words, EVPN's service-carving takes into account only two variables
   in the DF election for a given ESI: the existence of the PE's IP
   address on the candidate list and the locally provisioned Ethernet
   Tags (ISID identifiers in the case of PBB-EVPN).

   If the DF for an <ESI, EVI/ISID> fails (due to physical link/node
   failures) an ES route withdrawn will make the Non-DF (NDF) PEs re-
   elect the DF for that <ESI, EVI/ISID> and the service will be
   recovered.

   However the current DF election procedure does not provide a
   protection against "logical" failures or human errors that may occur
   at service level on the DF, while the list of active PEs for a given
   ESI does not change. These failures may have an impact not only on
   the local PE where the issue happens, but also on the rest of the PEs
   of the ESI. Some examples of such logical failures are listed below:

   a) A given individual Attachment Circuit (AC) defined in an ESI is
      accidentally shutdown or even not provisioned yet (hence the
      Attachment Circuit Status - ACS - is DOWN), while the ESI is
      operationally active (since the ES route is active).

   b) A given MAC-VRF - with an ESI defined - is shutdown or not
      provisioned yet, while the ESI is operationally active (since the
      ES route is active). In this case, the ACS of all the AC defined
      in that MAC-VRF is considered to be DOWN.

   Neither (a) nor (b) will trigger the DF re-election on the remote PEs
   for a given ESI since the ACS is not taken into account in the DF
   election procedures. While the ACS is used as a DF election tie-
   breaker and trigger in [VPLS-MH], there is no procedure defined in
   [EVPN] to trigger the DF re-election based on the ACS change on the
   DF.



Rabadan et al.           Expires April 27, 2015                 [Page 3]


Internet-Draft       AC-based DF election for EVPN      October 24, 2014


   This document improves the [EVPN] service-carving procedure so that
   the ACS may be taken into account as a variable in the DF election,
   and therefore EVPN can provide protection against logical failures.

2. Solution description

   The ACS for a given Ethernet Tag on an ESI is implicitly conveyed in
   the corresponding EVPN A-D per EVI route for that given <ESI,
   Ethernet Tag>. This section describes how to use the A-D per EVI
   routes to improve the DF election algorithm in both cases, EVPN and
   PBB-EVPN.

2.1. AC-influenced DF Election for EVPN

   Figure 1 illustrates an example EVPN network that will be used to
   describe the proposed solution for EVPN.

   EVI-1 is defined in PE-1, PE-2, PE-3 and PE-4. CE12 is a multi-homed
   CE connected to ESI12 in PE-1 and PE-2. Similarly CE23 is multi-homed
   to PE-2 and PE-3 using ESI23. CE12-VID 1 (VLAN ID 1 on CE12) is
   associated to AC1 and AC2 in EVI-1, whereas CE23-VID 1 is associated
   to AC3 and AC4 in EVI-1. Note that there are other ACs defined on
   these ESIs mapped to different EVIs.




























Rabadan et al.           Expires April 27, 2015                 [Page 4]


Internet-Draft       AC-based DF election for EVPN      October 24, 2014


                               +---+
                               |CE4|
                               +---+
                                 |
                            PE-4 |
                           +-----+-----+
           +---------------|  +-----+  |---------------+
           |               |  |EVI-1|  |               |
           |               +-----------+               |
           |                                           |
           |                   EVPN                    |
           |                                           |
           | PE-1              PE-2               PE-3 |
           | (NDF)             (DF)               (NDF)|
       +-----------+       +-----------+       +-----------+
       |  |EVI-1|  |       |  |EVI-1|  |       |  |EVI-1|  |
       |  +-----+  |-------|  +-----+  |-------|  +-----+  |
       +-----------+       +-----------+       +-----------+
              AC1\   ESI12  /AC2  AC3\   ESI23  /AC4
                  \        /          \        /
                   \      /            \      /
                    +----+              +----+
                    |CE12|              |CE23|
                    +----+              +----+

                       Figure 1 EVPN network example

2.1.1. Current DF election procedure and AC failures

   After running the service-carving DF election algorithm, PE-2 turns
   out to be the DF for ESI12 and ESI23 in EVI-1. The following two
   examples illustrate the issues with the existing defined procedure in
   [EVPN]:

   a) If AC2 is accidentally shutdown or even not configured, CE12
   traffic will be impacted. In case of all-active multi-homing, only
   the BUM traffic to CE12 will be impacted, whereas for single-active
   multi-homing all the traffic to/from CE12 will be discarded. This is
   due to the fact that a logical failure in PE-2 AC2 will not trigger
   an ES route withdrawn for ESI12 (since there are still other ACs
   active on ESI12) and therefore PE-1 will not re-run the DF election
   procedures.

   b) If EVI-1 is administratively shutdown or even not configured yet
   on PE-2, CE12 and CE23 will both be impacted: BUM traffic to both CEs
   will be discarded in case of all-active multi-homing and all traffic
   will be discarded to/from the CEs in case of single-active
   multi-homing. This is due to the fact that PE-1 and PE-3 will not



Rabadan et al.           Expires April 27, 2015                 [Page 5]


Internet-Draft       AC-based DF election for EVPN      October 24, 2014


   re-run the DF election procedures and will keep assuming PE-2 is the
   DF.

2.1.2. The Attachment Circuit (AC) influenced DF election

   Modifying the service-carving DF election procedure in the following
   way solves the issue:

   1. When PE-1 and PE-2 discover ESI12, they advertise an ES route for
      ESI12 with the associated ES-import extended community, starting a
      timer at the same time. Likewise, PE-2 and PE-3 advertise an ES
      route for ESI23 and start a timer.

   2. Similarly PE-1 and PE-2 advertise an Ethernet A-D per ES route for
      ESI12, and PE-2/PE-3 advertise an Ethernet A-D per ES route for
      ESI23.

   3. In addition, PE-1/PE-2/PE-3 advertise an Ethernet A-D per EVI
      route for AC1, AC2, AC3 and AC4 as soon as the ACs are enabled.

   4. When the timer expires, each PE builds an ordered "candidate" list
      of the IP addresses of all the PE nodes connected to the Ethernet
      Segment (including itself), in increasing numeric order. The
      candidate list is based on the Originator Router's IP addresses of
      the ES routes, excluding all the PEs for which no Ethernet A-D per
      ES route has been received.

   5. When electing the DF for a given EVI, a PE will not be considered
      candidate until an Ethernet A-D per EVI route has been received
      from that PE. In other words, the ACS on the ESI for a given PE
      must be UP so that the PE is considered as candidate for a given
      EVI. For example, PE-1 will not consider PE-2 as candidate for DF
      election for <ESI12, EVI-1> until an Ethernet A-D per EVI route is
      not received from PE-2 for <ESI12, EVI-1>.

   6. Once the PEs with ACS = DOWN for a given EVI have been eliminated
      from the candidate list, the (V mod N) = i function can be applied
      for the remaining N candidates, as per [EVPN].

   Note that this procedure does not modify the existing EVPN control
   plane whatsoever. It only modifies the candidate list of PEs taken
   into account for the DF election algorithm defined in [EVPN].

   In addition to the procedure described above, the following events
   SHALL modify the candidate PE list and trigger the DF re-election in
   a PE for a given <ESI,EVI>:

   a) Local ESI going DOWN due to a physical failure or reception of an



Rabadan et al.           Expires April 27, 2015                 [Page 6]


Internet-Draft       AC-based DF election for EVPN      October 24, 2014


      ES route withdraw for that ESI.

   b) Local ESI going UP due to its detection/configuration or reception
      of a new ES route update for that ESI.

   c) Local AC going DOWN/UP.

   d) Reception of a new Ethernet A-D per EVI update/withdraw for the
      <ESI, EVI>.

   e) Reception of a new Ethernet A-D per ES update/withdraw for the
      ESI.


2.2. AC-influenced DF Election for PBB-EVPN

   Figure 2 illustrates an example PBB-EVPN network that will be used to
   describe the proposed solution for PBB-EVPN.

   In this case, the B-component EVI-B is defined in BEB-1, BEB-2, BEB-
   3 and BEB-4 and runs EVPN. An I-component with ISID-N is also defined
   in all the BEBs and attached to EVI-B as per [PBB-EVPN]. As in the
   previous section, CE12 and CE 23 are multi-homed CEs connected to
   ESI12 and ESI23 respectively, but in this case the ACs are associated
   to the I-component on each BEB. Note that there are other ACs defined
   on these ESIs mapped to different ISIDs.

























Rabadan et al.           Expires April 27, 2015                 [Page 7]


Internet-Draft       AC-based DF election for EVPN      October 24, 2014


                               +---+
                               |CE4|
                               +---+
                                 |
                           BEB-4 |
                           +-----+-----+
                           |   ISID-N  |
                           |     |     |
           +---------------|  +-----+  |---------------+
           |               |  |EVI-B|  |               |
           |               +-----------+               |
           |                                           |
           |                  PBB-EVPN                 |
           |                                           |
           | BEB-1             BEB-2             BEB-3 |
           | (NDF)             (DF)              (NDF) |
       +-----------+       +-----------+       +-----------+
       |  |EVI-B|  |       |  |EVI-B|  |       |  |EVI-B|  |
       |  +-----+  |       |  +-----+  |       |  +-----+  |
       |     |     |-------|     |     |-------|     |     |
       |   ISID-N  |       |   ISID-N  |       |   ISID-N  |
       +-----------+       +-----------+       +-----------+
              AC1\   ESI12  /AC2  AC3\   ESI23  /AC4
                  \        /          \        /
                   \      /            \      /
                    +----+              +----+
                    |CE12|              |CE23|
                    +----+              +----+

                     Figure 2 PBB-EVPN network example

2.2.1. Current DF election procedure and AC failures

   After running the service-carving DF election algorithm, BEB-2 turns
   out to be the DF for ESI12 and ESI23 in ISID-N. The following two
   examples illustrate the issues with the existing defined procedure in
   [EVPN] when applied to PBB-EVPN:

   a) If AC2 is accidentally shutdown or even not configured, CE12
      traffic will be impacted - only the BUM traffic to CE12 if all-
      active multi-homing or all the traffic in case of single-active
      multi-homing. This is due to the fact that a logical failure in
      BEB- 2 AC2 will not trigger an ES route withdrawn for ESI12 (since
      there are still other ACs active on ESI12) and therefore BEB-1
      will not re-run the DF election procedures.

   b) If ISID-N is administratively shutdown or even not configured yet
      on BEB-2, CE12 and CE23 will both be impacted - again only BUM or



Rabadan et al.           Expires April 27, 2015                 [Page 8]


Internet-Draft       AC-based DF election for EVPN      October 24, 2014


      all the traffic depending on the multi-homing type. This is due to
      the fact that BEB-1 and BEB-3 will not re-run the DF election
      procedures and they will keep assuming BEB-2 is the DF.

   Note that regardless the B-MAC address assignment the user chooses
   for a PE (shared B-MAC for multiple ES or dedicated B-MAC per ES),
   the withdrawal of a B-MAC cannot be used as an indication of an
   individual AC going UP/DOWN. For instance, assuming a dedicated B-
   MAC per ES is used, when AC2 goes down, BEB-2 will not withdraw the
   B-MAC for ESI12 since there might be some other ACs in the same ESI
   using the B-MAC.

2.2.2. BGP encoding for advertising ACS per <ESI, ISID>

   This document proposes the use of an Ethernet A-D per ISID route to
   advertise the ACS of a given ISID in a given ESI. Note that the
   Ethernet A-D routes are not used in [PBB-EVPN] hence the procedure
   described here is OPTIONAL and, if enabled, it MUST be supported in
   all the BEBs part of the same ESI. The advertisement of ACS SHOULD be
   administratively enabled at system level and MAY be administratively
   enabled at ESI level.

   When enabled, the BEB will advertise an Ethernet A-D per ISID route
   as per [EVPN] with the following fields:

   - RD = B-component EVI's RD
   - ESI = non-reserved ESI where the ISID is defined
   - Ethernet Tag ID = ISID
   - MPLS Label = 0
   - The ES-Import Route Target used by the ES route for the same ESI

   The ES-Import Route Target will be used in the same way it is used
   with ES routes. It will only be imported by the BEBs where the ESI is
   defined and it is subject to RT Constraint procedures [RFC4684].

   In the example of Figure 2, BEB-2 will advertise an Ethernet A-D per
   ISID route for AC2 with the following fields:

   - RD = EVI-B RD
   - ESI = ESI12
   - Ethernet Tag ID = ISID-N

   And similarly it will send an Ethernet A-D per ISID route for AC3.

   If AC2 is shutdown, BEB-2 will withdraw the A-D per ISID route for
   AC2. That will be an indication for BEB-1 that AC2's status is DOWN.

   If ISID-N is administratively shutdown, BEB-2 will withdraw the A-D



Rabadan et al.           Expires April 27, 2015                 [Page 9]


Internet-Draft       AC-based DF election for EVPN      October 24, 2014


   per ISID routes for AC2 and AC3. This will be interpreted by BEB-1
   and BEB-3 respectively as ACS DOWN indications.

2.2.3. The AC-influenced DF Election

   When this procedure is enabled for a given ESI, the BEBs will
   advertise Ethernet A-D per ISID routes and the DF election procedure
   will be modified in the following way:

   1. When BEB-1 and BEB-2 discover ESI12, they advertise an ES route
      for ESI12 with the associated ES-import extended community,
      starting a timer at the same time. Likewise, BEB-2 and BEB-3
      advertise an ES route for ESI23 and start a timer.

   2. In addition, BEB-1/BEB-2/BEB-3 advertise an Ethernet A-D per ISID
      route for AC1, AC2, AC3 and AC4 as soon as the ACs are enabled.

   3. When the timer expires, each PE builds an ordered "candidate" list
      of the IP addresses of all the PE nodes connected to the Ethernet
      Segment (including itself), in increasing numeric order. The
      candidate list is based on the Originator Router's IP addresses of
      the ES routes.

   4. When electing the DF for a given ISID, a PE will not be considered
      candidate until an Ethernet A-D per ISID route has been received
      from that PE. In other words, the ACS on the ESI for a given PE
      must be UP so that the PE is considered as candidate for a given
      ISID. For example, BEB-1 will not consider BEB-2 as candidate for
      DF election for <ESI12, ISID-N> until an Ethernet A-D per ISID
      route is not received from BEB-2 for <ESI12, ISID-N>.

   5. Once the PEs with ACS = DOWN for a given ISID have been eliminated
      from the candidate list, the (V mod N) = i function can be applied
      for the remaining N candidates, as per [EVPN].

   This procedure modifies the PBB-EVPN control plane procedures, but
   does not define new routes or attributes. It reuses the components
   already existing in [EVPN] in order to define a DF election procedure
   that is consistent for EVPN and PBB-EVPN and protects the network
   against "logical" failures.

   In addition to the procedure described above, the following events
   SHALL modify the candidate PE list and trigger the DF re-election in
   a PE for a given <ESI,ISID>:

   a) Local ESI going DOWN due to a physical failure or reception of an
      ES route withdraw for that ESI.




Rabadan et al.           Expires April 27, 2015                [Page 10]


Internet-Draft       AC-based DF election for EVPN      October 24, 2014


   b) Local ESI going UP due to its detection/configuration or reception
      of a new ES route update for that ESI.

   c) Local AC going DOWN/UP.

   d) Reception of a new Ethernet A-D per ISID update/withdraw for the
      <ESI, ISID>.

3. Solution benefits

   The solution described in this document provides the following
   benefits:

   a) Improves the DF election procedures for EVPN so that failures due
      to human errors, logical failures or even delay in provisioning of
      Attachment Circuits can be protected by multi-homing.

   b) The above benefit is added to EVPN without the need to modify or
      add any BGP new attributes or NLRI changes.

   c) Improves the DF election procedures for PBB-EVPN so that the same
      failures as in (a) can be protected by multi-homing also in a
      PBB-EVPN network.

   d) The above benefit is provided without adding any BGP new
      attributes or NLRI changes. It simply re-uses the existing
      Ethernet A-D route in PBB-EVPN. PBB-EVPN implementations not
      supporting this document SHOULD ignore Ethernet A-D routes.

4. Conventions used in this document

   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 RFC-2119 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

   In this document, the characters ">>" preceding an indented line(s)
   indicates a compliance requirement statement using the key words
   listed above. This convention aids reviewers in quickly identifying
   or finding the explicit compliance requirements of this RFC.

5. Security Considerations

   Will be added.




Rabadan et al.           Expires April 27, 2015                [Page 11]


Internet-Draft       AC-based DF election for EVPN      October 24, 2014


6. IANA Considerations

   Will be added.

7. References

7.1. Normative References


   [RFC4684]  Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
   R., Patel, K., and J. Guichard, "Constrained Route Distribution for
   Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS)
   Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684,
   November 2006, <http://www.rfc-editor.org/info/rfc4684>.



7.2. Informative References

   [EVPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-ietf-
   l2vpn-evpn-11.txt, work in progress, October, 2014

   [VPLS-MH] Kothari, Henderickx et al., "BGP based Multi-homing in
   Virtual Private LAN Service", draft-ietf-l2vpn-vpls-multihoming-
   07.txt, work in progress, July, 2014


8. Acknowledgments

   Will be added.


Authors' Addresses

   Jorge Rabadan
   Alcatel-Lucent
   777 E. Middlefield Road
   Mountain View, CA 94043 USA
   Email: jorge.rabadan@alcatel-lucent.com

   Kiran Nagaraj
   Alcatel-Lucent
   Email: kiran.nagaraj@alcatel-lucent.com

   Senthil Sathappan
   Alcatel-Lucent
   Email: senthil.sathappan@alcatel-lucent.com




Rabadan et al.           Expires April 27, 2015                [Page 12]


Internet-Draft       AC-based DF election for EVPN      October 24, 2014


   Wim Henderickx
   Alcatel-Lucent
   Email: wim.henderickx@alcatel-lucent.com
















































Rabadan et al.           Expires April 27, 2015                [Page 13]


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