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

Versions: 00 01

BESS                                                            J. Heitz
Internet-Draft                                                A. Sajassi
Intended status: Standards Track                                   Cisco
Expires: May 17, 2018                                           J. Drake
                                                                 Juniper
                                                              J. Rabadan
                                                                   Nokia
                                                       November 13, 2017


         Multi-homing and E-Tree in EVPN with Inter-AS Option B
                   draft-heitz-bess-evpn-option-b-01

Abstract

   The BGP speaker that originates an EVPN Ethernet A-D per ES route is
   identified by the next-hop of the route.  When the route is
   propagated by an ASBR as an Inter-AS Option B route, the ASBR
   overwrites the next-hop.  This document describes a method to
   identify the originator of the route.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

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 May 17, 2018.








Heitz, et al.             Expires May 17, 2018                  [Page 1]


Internet-Draft           EVPN Inter-AS Option B            November 2017


Copyright Notice

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

Table of Contents

   1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  EVPN multi-homing and Inter-AS Option B issue . . . . . .   3
     2.2.  EVPN E-tree and Inter-AS Option B issue . . . . . . . . .   4
   3.  Solution using the Tunnel Encapsulation Attribute . . . . . .   4
   4.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Procedures at the Imposition PE . . . . . . . . . . . . . . .   5
     5.1.  Primer for subsequent sections  . . . . . . . . . . . . .   5
     5.2.  OPE exists on all Type 2/5 and EAD Routes . . . . . . . .   5
     5.3.  Some routes do not contain OPE  . . . . . . . . . . . . .   6
     5.4.  OPE exists on EAD routes, but not on Type 2/5 routes  . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   9.  Appendix  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Alternative Ways to Signal OPE  . . . . . . . . . . . . .   7
       9.1.1.  Extended Community holding the IP addres  . . . . . .   7
       9.1.2.  Large Community holding the BGP Identifier  . . . . .   7
     9.2.  Considerations  . . . . . . . . . . . . . . . . . . . . .   7
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Terminology

   Inter-AS Option B: This is described in Section 10.b of [RFC4364]

   EAD-per-ES: Ethernet A-D per Ethernet Segment Route.

   EAD-per-EVI: Ethernet A-D per EVPN Instance Route.





Heitz, et al.             Expires May 17, 2018                  [Page 2]


Internet-Draft           EVPN Inter-AS Option B            November 2017


   EAD: EVPN Type 1 route: Ethernet Auto-discovery Route.  Either an
   EAD-per-ES or an EAD-per-EVI route.

   Type 2/5: either the EVPN Type 2 route: MAC/IP Advertisement Route or
   the EVPN Type 5 route: IP Prefix Route described in
   [I-D.ietf-bess-evpn-prefix-advertisement].

   Mass Withdraw: To withdraw the route from the forwarding table.  For
   example, a MAC route that is mass withdrawn remains in the BGP table.
   The MAC route is required for directing packets with the specified
   MAC destination address to a matching backup or alias route.  When a
   MAC route is completely withdrawn, then the matching backup or alias
   routes can no longer be used for the given MAC address.  The
   withdrawal of an EAD-per-ES route will cause the mass withdrawal of
   associated Type 2/5 routes as well as associated EAD-per-EVI routes.

2.  Introduction

   Inter-AS Option B is illustrated in Figure 1.

           CE3
            |
           PE1
          /   \
        CE1    ASBR1---ASBR2---PE3--CE2
          \   /
           PE2

           Figure 1: Inter-AS Option B

   Traffic flow is from CE2 to CE1 where PE3 is an imposition PE, and
   PE1 and PE2 are disposition PEs.  The following sections describe the
   issues that EVPN multi-homing and EVPN E-tree services have in these
   types of scenarios.

2.1.  EVPN multi-homing and Inter-AS Option B issue

   In a multi-homing scenario, the router that performs the redundancy
   switchover or the load balancing (e.g.  PE3) must know which router
   originated the Ethernet A-D routes.  These redundancy functions are
   normally implemented on a PE, but not on an ASBR.

   Quote from [RFC7432]:

      "A remote PE that receives a MAC/IP Advertisement route with a
      non-reserved ESI SHOULD consider the advertised MAC address to be
      reachable via all PEs that have advertised reachability to that
      MAC address's EVI/ES via the combination of an Ethernet A-D per



Heitz, et al.             Expires May 17, 2018                  [Page 3]


Internet-Draft           EVPN Inter-AS Option B            November 2017


      EVI route for that EVI/ES (and Ethernet tag, if applicable) AND
      Ethernet A-D per ES routes for that ES."

   In the Intra-AS case, the remote PE identifies the "PEs that have
   advertised reachability" by the next-hops of the Ethernet A-D routes.
   In the Inter-AS option B case, ASBR1 and ASBR2 rewrite the next-hops
   to themselves on all EVPN route advertisements, thus losing the
   identity of the PE that originated an advertisement.

   As a result, PE3 is unable to distinguish an EAD-per-ES route that
   originated at PE1 from one that originated at PE2.

2.2.  EVPN E-tree and Inter-AS Option B issue

   As described in [EVPN-Etree], leaf-to-leaf BUM traffic filtering is
   always performed at the disposition PE and based on the Leaf Label.
   The Leaf Label can be downstream allocated (ingress replication) or
   upstream allocated (p2mp tunnels) and is advertised in an EAD-per-ES
   route with ESI-0.  As in the multi-homing case, the PEs must identify
   the PE that originated a given EAD-per-ES route, for both cases,
   ingress replication or p2mp tunnels, so that the leaf-to-leaf BUM
   filtering can be successful.

   If ingress-replication is used for BUM traffic, the ingress PE must
   identify the originator of the ESI-0 EAD-per-ES route, program the
   Leaf Label and push it on the stack when sending BUM Leaf traffic to
   the egress PE.  However, this identification of the originating PE is
   not possible in Inter-AS option B scenarios where ASBRs rewrite the
   next-hops.  For instance, assuming CE2 and CE3 (Figure 1) are
   connected to Leaf ACs, PE1 will advertise a Leaf Label in an EAD-per-
   ES route for ESI-0.  When CE2 sends BUM traffic, PE3 will not know
   what Leaf Label to use for sending traffic to PE1.

   Similarly, when PE3 uses non-segmented p2mp tunnels for BUM traffic,
   PE3 will upstream allocate a Leaf Label and advertise it in an EAD-
   per-ES route, so that when sending BUM traffic with a Leaf Label, PE1
   can identify that is coming from a Leaf and not forward it to CE3.

   In both cases, the current Intra-AS procedures do not allow to
   identify the originator of the EAD-per-ES routes and therefore egress
   BUM filtering for leaf-to-leaf is not possible when the Leaf ACs are
   located on different AS'es.

3.  Solution using the Tunnel Encapsulation Attribute

   The Tunnel Encapsulation Attribute is specified in
   [I-D.ietf-idr-tunnel-encaps].  A new TLV to identify the Originating
   PE is specified here.  It is called OPE.  The tunnel type for the OPE



Heitz, et al.             Expires May 17, 2018                  [Page 4]


Internet-Draft           EVPN Inter-AS Option B            November 2017


   (suggested value 15) is to be assigned by IANA.  The OPE MUST contain
   the Remote Endpoint Sub-TLV.  The OPE must be able to uniquely
   identify the PE of origin within all ASes that participate in an EVPN
   instance.

   If a BGP speaker, such as a route reflector or an ASBR, is about to
   re-advertise a Type 2/5 or EAD route that does not have a OPE, and
   will change the next-hop of that route, then it MUST add one by
   putting the received next-hop into the Remote Endpoint Sub-TLV of the
   OPE.  This will ensure that all originating EVPN routes carry the
   necessary information for imposition PEs to function properly for
   aliasing and mass withdraw.

   Any router that re-advertises a route that contains a OPE may modify
   some TLVs in the Tunnel Encapsulation Attribute attribute.  However,
   it MUST keep the OPE unchanged.  Examples are ASBR1 and ASBR2 in
   Figure 1.

4.  Operation

   For an inter-AS option B scenario, when a PE receives EVPN route(s)
   with OPE from an ASBR, then everything works per [RFC7432]
   specification including both aliasing function and mass withdraw.
   i.e., the imposition PE (e.g., PE3) can process mass withdraw
   messages (Ethernet A-D per ES route).  However, if a PE receives EVPN
   route(s) without a OPE from an ASBR, then the mass withdraw function
   operates in a degenerate mode where only Ethernet A-D per EVI route
   can be processed (for its corresponding MAC-VRF) but not Ethernet A-D
   per ES route (corresponding to all the impacted MAC-VRFs).  The
   following sections detail the procedures associated with OPE
   processing.

5.  Procedures at the Imposition PE

5.1.  Primer for subsequent sections

   When routes are being compared, they must exist in the same MAC-VRF
   and have the same non-reserved ESI.  In addition, when Type 2/5
   routes and EAD-per-EVI routes are being compared, they must have the
   same Ethernet Tag. Type 2/5 routes with ESI==0 do not use mass
   withdrawal or aliasing.

5.2.  OPE exists on all Type 2/5 and EAD Routes

   If all Type 2/5 and EAD routes have a OPE, then "PEs that have
   advertised reachability" can be identified by the OPE and the
   procedures of [RFC7432] can be applied without modification.




Heitz, et al.             Expires May 17, 2018                  [Page 5]


Internet-Draft           EVPN Inter-AS Option B            November 2017


5.3.  Some routes do not contain OPE

   The routes that have a OPE are handled as per the previous section.
   The routes that do not have a OPE need the following procedures.

   Type 2/5 routes without a OPE and EAD-per-EVI routes without a OPE
   are valid if at least one EAD-per-ES route without a OPE exists with
   the same next-hop.  In other words: if multiple EAD-per-ES routes
   with the same next-hop as a Type 2/5 route exist, then the Type 2/5
   route will only be mass withdrawn once all of the EAD-per-ES routes
   are withdrawn.  This rule is necessary, because a BGP speaker may
   serve dual roles as ASBR and PE

   [Editorial note: If it is determined that no BGP speakers exist that
   do not normally follow the procedures in this document (Legacy
   speakers) then the following sub sections may be omitted]

   If an EAD-per-EVI route without a OPE is withdrawn, it will mass
   withdraw all Type 2/5 routes without a OPE that have the same next-
   hop and the same RD as the EAD-per-EVI route.  This is called mass-
   withdraw per EVI.  Note, it is not the absence of the EAD-per-EVI
   route that causes mass-withdrawal, but the actual withdrawal itself.
   If the route was never there to begin with, then no withdrawal took
   place.

   If any entity in the network rewrites an RD, then all entities must
   rewrite the RD in a consistent manner, such that routes with the same
   RD continue to have the same RD and routes with different RDs
   continue to have different RDs.  Note that if this condition is
   violated, then other network functions would also break.

5.4.  OPE exists on EAD routes, but not on Type 2/5 routes

   If a Type 2/5 route exists without a OPE and an EAD-per-EVI route
   exists with a OPE and it has the same next-hop and the same RD as the
   Type 2/5 route, then the Type 2/5 route shall inherit the OPE from
   the EAD-per-EVI route.  Thereafter, Section 5.2 applies.

6.  Security Considerations

   TBD

7.  IANA Considerations

   A Tunnel Encapsulation Attribute Tunnel Type for the OPE is required.






Heitz, et al.             Expires May 17, 2018                  [Page 6]


Internet-Draft           EVPN Inter-AS Option B            November 2017


8.  Acknowledgements

   Thanks to Kiran Pillai, Patrice Brissette, Satya Mohanty and Keyur
   Patel for careful review and suggestions.

9.  Appendix

9.1.  Alternative Ways to Signal OPE

   [Note to RFC editor: This appendix to be removed before publication]

9.1.1.  Extended Community holding the IP addres

   The Extended Community to use must be transitive and either IPv4
   Specific or IPv6 Specific as described in [RFC5701].  Thus, if it is
   IPv4 Specific, it will be of type 0x41 and if IPv6 Specific, it will
   be of type 0x40.

   The Extended Community will hold the IP address of the PE that
   originates the EVPN routes.

9.1.2.  Large Community holding the BGP Identifier

   A PE can be uniquely identified by its BGP identifier (also called
   Router ID) and its AS number (ASN).  A Large Community [RFC8092] can
   be used to carry the BGP identifier and the ASN.  A well known Large
   Community needs to be allocated for this.  This allocation is for the
   Global Administrator field.  The Local Data Part 1 field should carry
   ASN and the Local Data Part 2 should carry the BGP identifier.

9.2.  Considerations

   It may be possible to associate the EAD-per-ES route with the Type
   2/5 route by matching the Administrator Subfield of the RD.  However,
   there are too many constraints that need to be met to make this
   method reliable.  Basically, the RD was emphatically designed to
   distinguish routes, not to identify them.  The constraints that need
   to be met are:

   o  The RD MUST by of Type 1.  [RFC7432] recommends Type 1, but does
      not mandate it.

   o  The Administrator subfield of the RD MUST be the same for each of
      these routes originated by one PE.  [RFC7432] does not require
      this.  It just says "The value field comprises an IP address of
      the PE", but does not say that it must be the same IP address for
      all.  In an IPv6 only scenario, other ways will be used to assign
      RD.



Heitz, et al.             Expires May 17, 2018                  [Page 7]


Internet-Draft           EVPN Inter-AS Option B            November 2017


   o  The Administrator subfield of the RD MUST be unique among all PEs
      participating in the Inter-AS EVPN.  This is likely, but not
      guaranteed.

   o  If RDs are rewritten at AS boundaries, then the Administrator
      subfield MUST be rewritten in a consistent way such as to preserve
      the above properties.

   By allowing a single EAD-per-ES route to validate all EAD-per-EVI
   routes and all Type 2/5 routes, some of those routes may be falsely
   validated.  However that is the best possible outcome without a OPE.
   It is transient until the Type 2/5 route can be withdrawn.

   The possibility of the address space of PE next-hops in one AS
   overlapping that of another AS was raised.  In such a case, the IP
   address of a PE in one AS may be the same as the IP address of a
   different PE in another AS.  Because an ASBR overwrites next-hops,
   this can work.  The OPE contains both the ASN as well as the IP
   address of the originating PE, so this works too.  However, EVPN
   route types 3 and 4 contain only the originating router's IP address,
   but not the originating router's ASN.  Therefore, EVPN route types 3
   and 4 may also need a OPE.

   The possibility of making the EAD-per-EVI route mandatory was raised.
   This would make some of the procedures easier, because the RD of the
   EAD-per-EVI route can be matched with the RD of the Type 2/5 route

10.  Normative References

   [I-D.ietf-bess-evpn-prefix-advertisement]
              Rabadan, J., Henderickx, W., Palislamovic, S., and A.
              Isaac, "IP Prefix Advertisement in EVPN", draft-ietf-bess-
              evpn-prefix-advertisement-02 (work in progress), September
              2015.

   [I-D.ietf-idr-tunnel-encaps]
              Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel
              Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-02
              (work in progress), May 2016.

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

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <https://www.rfc-editor.org/info/rfc4364>.



Heitz, et al.             Expires May 17, 2018                  [Page 8]


Internet-Draft           EVPN Inter-AS Option B            November 2017


   [RFC5701]  Rekhter, Y., "IPv6 Address Specific BGP Extended Community
              Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009,
              <https://www.rfc-editor.org/info/rfc5701>.

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

   [RFC8092]  Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas,
              I., and N. Hilliard, "BGP Large Communities Attribute",
              RFC 8092, DOI 10.17487/RFC8092, February 2017,
              <https://www.rfc-editor.org/info/rfc8092>.

Authors' Addresses

   Jakob Heitz
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: jheitz@cisco.com


   Ali Sajassi
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: sajassi@cisco.com


   John Drake
   Juniper

   Email: jdrake@juniper.net


   Jorge Rabadan
   Nokia

   Email: jorge.rabadan@nokia.com







Heitz, et al.             Expires May 17, 2018                  [Page 9]


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