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

Versions: 00                                                            
BESS WG                                                          Y. Wang
Internet-Draft                                                   R. Chen
Intended status: Standards Track                         ZTE Corporation
Expires: 31 January 2022                                    30 July 2021


                     Egress Protection for EVPN BUM
             draft-wang-bess-evpn-bum-egress-protection-00

Abstract

   When the procedures per [I-D.ietf-rtgwg-srv6-egress-protection] are
   applied to EVPN services, the egress-protection on PLR is typically
   more faster than the new DF node of the affected ESI is re-elected.
   As a result of that, replicated BUM packets will be sent to the CEs
   of the affected ES.  This draft describes a "NDF-bias" mechanism that
   is used to avoid such excessive BUM packets.

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



Wang & Chen              Expires 31 January 2022                [Page 1]


Internet-Draft            BUM Egress Protection                July 2021


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology and Acronyms  . . . . . . . . . . . . . . . .   2
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Solutions . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Solution 1: Separate Locators for End.DT2M SIDs . . . . .   5
     3.2.  Solution 2: The mirrored End.DT2M SIDs are not
           installed . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Solution 3: NDF-Bias Mechanism  . . . . . . . . . . . . .   6
   4.  Condisderations on EVPN Mulicast and Other EVPNs  . . . . . .   6
     4.1.  Condisderations on EVPN Mulicast  . . . . . . . . . . . .   6
     4.2.  Condisderations on Other EVPNs  . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   A principal feature of EVPN is the ability to support multi-homing
   from a customer equipment (CE) to multiple PE with Ethernet segment
   (ES) links.  This draft leverages the egress protection mechanism per
   [I-D.ietf-rtgwg-srv6-egress-protection] in the multi-homed cases and
   enhance EVPN convergency on the egress PE node failures, especially
   for the convergency of BUM packets (Section 3.3).

1.1.  Terminology and Acronyms

   Most of the acronyms and terms used in this documents comes from
   [RFC7432], [RFC8679], [I-D.ietf-bess-srv6-services] and
   [I-D.ietf-rtgwg-srv6-egress-protection] except for the following:

   *  Mirrored SID - A mirrored SID is a VPN SID which will be installed
      in the context of a mirror SID (as per
      [I-D.ietf-rtgwg-srv6-egress-protection]).

   *  bypassed BUM packet - A BUM packet that is received via a mirrored
      End.DT2M SID.

   *  EVPN SID - SRv6 SID for EVPN Instances, e.g.  End.DT2M SID,
      End.DT2U SID, End.DX2 SID, End.DX2V SID.

   *  NDF - non-DF, non Designated-Forwarder.  Note that Backup DF is a
      special NDF.




Wang & Chen              Expires 31 January 2022                [Page 2]


Internet-Draft            BUM Egress Protection                July 2021


   *  NDF-Bias - An exception for filtering bypassed BUM packets.  It
      says that when an outgoing AC is a DF on its ES, the bypassed BUM
      packets will be dropped but when an outgoing AC is a NDF on its
      ES, the bypassed BUM packets will not be dropped.

   *  Pairing Route - When IMET_PE3 and IMET_PE4 are two IMET routes of
      same Bridge Domain, and IMET_PE4 is a local IMET route, while
      IMET_PE3 is a remote IMET route whose End.DT2M SID is allocated
      from a remote locator that is protected by a local Mirror SID, we
      say that IMET_PE4 are paired with IMET_PE3 by the Mirror SID, or
      just say that IMET_PE4 is IMET_PE3's pairing route.  Note that we
      don't say IMET_PE3 is IMET_PE4's pairing route, because that a
      local route will have many pairing routes, one per local mirror
      SID.

   *  ORIP - Originating Router's IP Address, or Originator's IP
      Address.

2.  Problem Statement

   Figure 1 shows an example of protecting egress PE3 of a SR path,
   which is from ingress PE1 to egress PE3.

                                   Locator: A3:1::/64
                 *******  *******  VPN SID: A3:1::B100
             [PE1]-----[P1]-----[PE3]---[CE2]      PE3 Egress
             / |        |&        | \   /          PE4 Backup Egress
            /  |        |&        |  \ /           CEx Customer Edge
       [CE1]   |        |&        |   X            Px  Non-Provider Edge
            \  |        |&        |  / \           *** SR Path
             \ |        |& &&&&&  | /   \          &&& Backup Path
             [PE2]-----[P2]-----[PE4]---[CE3]
                                   Locator: A4:1::/64
                                   VPN SID: A4:1::B100
                                Mirror SID: A4:1::3, protect A3:1::/64

                 Figure 1: Egress Protection Scenario

   In Figure 2, All PEs are EVPN PEs per [RFC7432], and Both CE2 and CE3
   are dual homed to PE3 and PE4.  PE3 has a locator A3:1::/64 and a
   End.DT2M SID A3:1::B100.  PE4 has a locator A4:1::/64 and a End.DT2M
   SID A4:1::B100.  A Mirror SID A4:1::3 is configured on PE4 for
   protecting a remote locator (PE3's locator) A3:1::/64.  P1 has a
   locator A1:1::/64.  CE2 is on Ethernet Segment ES2 whose DF is PE4,
   non-DF is PE3.  CE3 is on Ethernet Segment ES3 whose DF is PE3, non-
   DF is PE4.  Both ES2 and ES3 are all-active mode.





Wang & Chen              Expires 31 January 2022                [Page 3]


Internet-Draft            BUM Egress Protection                July 2021


   After the configuration, PE4 advertises this information through an
   IGP LS (i.e., LSA in OSPF or LSP in IS-IS), which includes PE3's
   locator and Mirror SID A4:1::3.  Every node in the SR domain will
   receive this IGP LS, which indicates that PE4 wants to protect PE3's
   locator with Mirror SID A4:1::3.

   When PE4 (e.g., BGP on PE4) receives a IMET route IMET_PE3 whose VPN
   SID belongs to PE3 that is protected by PE4 through Mirror SID
   A4:1::3, it finds IMET_PE3's VPN SID corresponding to a remote
   locator (A3:1::/64) which is protected by a local Mirror SID
   (A4:1::3).  Then PE4 find out the corresponding local IMET route (say
   IMET_PE4) which are paired with IMET_PE3 by the Mirror SID.

   Note that although PE4 don't have a local IMET route of IMET_PE3, It
   can know that the IMET_PE3 is for the same EVPN VPLS of a local IMET
   route IMET_PE4.  Because that the IMET_PE3 will be imported into the
   EVPN VPLS of the IMET_PE4.  So the IMET_PE3 is the corresponding
   route of IMET_PE4 from the Mirror SID's point of view.  In other
   words, we say that IMET_PE4 are paired with IMET_PE3 by the Mirror
   SID, or just say that IMET_PE4 is IMET_PE3's pairing route.  This
   procedure is different from [I-D.ietf-rtgwg-srv6-egress-protection].

   The forwarding behaviors for the VPN SID (PE3's EVPN SID A3:1::B100
   of End.DT2M Function) of IMET_PE3 are the same as the VPN SID
   (A4:1::B100) of the local IMET_PE4 from function's point of view.  If
   the behavior for PE3's VPN SID in PE3 forwards the packet with it to
   CE2, then the behavior for PE4's VPN SID in PE4 forwards the packet
   to the same CE2; and vice versa.  PE4 creates a forwarding entry for
   PE3's VPN SID A3:1::B100 in the FIB table identified by Mirror SID
   A4:1::3 according to the forwarding behavior for PE4's VPN SID
   A4:1::B100.

   Note that there are two FIB entries for A3:1:B100, one(say FIB_1) is
   on PE3 , the other(say FIB_2) is on PE4.  We call the FIB entry FIB_2
   as the FIB entry FIB_1's mirrored FIB entry.  Because that the FIB_2
   is in the FIB table identified by a Mirror SID.  The SID instance
   corresponding to a mirrored FIB entry is called as a Mirrored SID.

   Node P1's pre-computed backup path for destination PE3`s locator is
   from P1 to PE4 having mirror SID A4:1::3.  When P1 receives a packet
   destined to PE3's VPN SID A3:1::B100, in normal operations, it
   forwards the packet with source A1:1:: and destination PE3's VPN SID
   A3:1::B100 according to the FIB using the destination PE3's VPN SID
   A3:1::B100.

   When PE3 fails, P1 as PLR sends the packet to PE4 via the backup path
   pre-computed.  P1 encapsulates the packet using H.Encaps before
   sending it to PE4.



Wang & Chen              Expires 31 January 2022                [Page 4]


Internet-Draft            BUM Egress Protection                July 2021


   When PE4 receives the re-routed packet, it decapsulates the packet
   and forwards the decapsulated packet by executing End.DT6 behavior
   for an End.DT6 SID instance.  The SID instance is End.M, the Mirror
   SID that is associated with the IPv6 FIB table for PE3.  The packet
   received by PE4 is (T, Mirror SID A4:1::3) (A1:1::, PE3's VPN SID
   A3:1::B100)Pkt0.

   PE4 obtains Mirror SID A4:1::3 in the outer IPv6 header of the
   packet, removes this outer IPv6 header, and then processes the inner
   IPv6 packet (A1:1::, A3:1::B100)Pkt0.  It finds the FIB table for PE3
   using Mirror SID A4:1::3 as the context ID, gets the forwarding entry
   for PE3's VPN SID A3:1::B100 from the table, and forwards the packet
   to CE2 using the entry.

   When the SID instance A3:1::B100 is End.DT2M, the Pkt0 is a BUM
   packet.  The Pkt0 will be replicated to CE2 as long as PE4 is the DF
   of <ES2,EVI1> The Pkt0 will be replicated to CE3 as long as PE4 is
   the DF of <ES3,EVI1>

   Typically, the local-repair on P1 is more faster than the new DFs of
   ES2 and ES3 are re-elected.  So PE4 will still be the DF of <ES2,
   EVI1> untill the DF re-election finishes, and PE4 will still be the
   non-DF of <ES3, EVI1> untill DF the re-election finishes,

   Note that PE1 will broadcast a BUM packet (say BUM0) to PE3 and PE4
   separately.  One copy of BUM0 which is replicated by PE1 for PE3 is
   called as BUM3.  The other copy of BUM0 which is replicated by PE1
   for PE4 is called as BUM4.

   As a result of current DF filtering rules, CE2 will receive both BUM3
   and BUM4 untill the DF re-election finishes.  At the same time, CE3
   will receive niether BUM3 nor BUM4.

3.  Solutions

3.1.  Solution 1: Separate Locators for End.DT2M SIDs

   The End.DT2M SIDs are not allocated from the same locator with the
   End.DT2U/End.DX2/End.DX2V SIDs.  The locator from where the End.DT2M
   SIDs are allocated are called as DT2M_LOCATOR.  The DT2M_LOCATOR must
   not be protected by any Mirror SID.

   This solution can prevent CE2 from receiving excessive BUM packets,
   but can not help to accelerate the convergence of CE3's BUM packets.







Wang & Chen              Expires 31 January 2022                [Page 5]


Internet-Draft            BUM Egress Protection                July 2021


3.2.  Solution 2: The mirrored End.DT2M SIDs are not installed

   When the SID instance A3:1::B100 is not installed on PE4, BUM4 will
   be dropped after PLR's egress protection procedures.

   Note that a mirrored SID is very different from a Mirror SID.  A
   mirrored SID is a VPN SID which will be installed in the context of a
   mirror SID as per [I-D.ietf-rtgwg-srv6-egress-protection].  But it
   must not be installed in this solution.

   This solution can prevent CE2 from receiving excessive BUM packets,
   but can not help CE3 to receive one copy of BUM0 as soon as possible.

3.3.  Solution 3: NDF-Bias Mechanism

   In order to accelerate the convergence of bypass-BUM packets, some
   specific rules are defined in the following6:

   The mirrored End.DT2M SIDs need to be installed, and those BUM
   packets which is received via a mirrored End.DT2M SID are called as
   bypass BUM packets.  Those bypass BUM packets will not be dropped
   when they are about to be forwarded to an AC whose DF-role is NDF.
   Note that the single-homing ACs are always considered as DF-role, so
   those ACs will filter all bypass BUM packets.  Accordingly, those
   bypass BUM packets will be dropped when they are about to be
   forwarded to an AC whose DF-role is DF.

   These rules are called as "NDF-Bias" rules in this draft.

   This solution can prevent CE2 from receiving excessive BUM packets,
   at the same time, this solution can accelerate the convergence of
   CE3's BUM packets.

4.  Condisderations on EVPN Mulicast and Other EVPNs

4.1.  Condisderations on EVPN Mulicast

   The pairing routes for EVPN multicast are two EVPN routes of the same
   <Multicast source,Multicast Group,BD>.  And they are of the same EVPN
   route type, while they have different ORIPs.

4.2.  Condisderations on Other EVPNs

   Just the recognition methods to pick the bypassed BUM packets out are
   different.

   *  MPLS EVPN - The bypassed BUM packets will be received over an ILM
      entry in a context-specific label-space.



Wang & Chen              Expires 31 January 2022                [Page 6]


Internet-Draft            BUM Egress Protection                July 2021


   *  VXLAN EVPN - see [I-D.wang-bess-evpn-egress-protection].

5.  IANA Considerations

   no IANA Considerations.

6.  Security Considerations

   TBD.

7.  References

7.1.  Normative References

   [I-D.ietf-rtgwg-srv6-egress-protection]
              Hu, Z., Chen, H., Chen, H., Wu, P., Toy, M., Cao, C., He,
              T., Liu, L., and X. Liu, "SRv6 Path Egress Protection",
              Work in Progress, Internet-Draft, draft-ietf-rtgwg-srv6-
              egress-protection-03, 28 May 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
              srv6-egress-protection-03>.

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

   [RFC8679]  Shen, Y., Jeganathan, M., Decraene, B., Gredler, H.,
              Michel, C., and H. Chen, "MPLS Egress Protection
              Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019,
              <https://www.rfc-editor.org/info/rfc8679>.

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

7.2.  Informative References

   [I-D.wang-bess-evpn-egress-protection]
              Wang, Y. and R. Chen, "EVPN Egress Protection", Work in
              Progress, Internet-Draft, draft-wang-bess-evpn-egress-
              protection-04, 29 October 2020,
              <https://datatracker.ietf.org/doc/html/draft-wang-bess-
              evpn-egress-protection-04>.



Wang & Chen              Expires 31 January 2022                [Page 7]


Internet-Draft            BUM Egress Protection                July 2021


Authors' Addresses

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

   Email: wang.yubao2@zte.com.cn


   Ran Chen
   ZTE Corporation
   No. 50 Software Ave, Yuhuatai Distinct
   Nanjing
   China

   Email: chen.ran@zte.com.cn

































Wang & Chen              Expires 31 January 2022                [Page 8]