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

Versions: 00

BESS WG                                                          Y. Wang
Internet-Draft                                                  Z. Zhang
Intended status: Standards Track                         ZTE Corporation
Expires: 19 March 2021                                 15 September 2020


                  EVPN VPWS as VRF Attachment Circuit
                  draft-wz-bess-evpn-vpws-as-vrf-ac-00

Abstract

   When a VRF Attachment Cirucit (VRF-AC) is far away from its IP-VRF
   instance, we can deploy an EVPN VPWS ([RFC8214]) between that VRF-AC
   and its IP-VRF instance.  From the viewpoint of the IP-VRF instance,
   a local virtual interface takes the place of that remote "VRF-AC".
   The intended IP address for that VRF-AC is now configured to the
   virtual interface, in other words, the virtual interface is the
   actual VRF-AC of the IP-VRF instance.  The virtual interface is also
   the AC of that VPWS instance, in other words, the virtual interface
   is cross-connected to that remote "VRF-AC" by the VPWS instance.

   This document proposes an extension to [RFC7432] to support this
   scenario.

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 19 March 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.






Wang & Zhang              Expires 19 March 2021                 [Page 1]


Internet-Draft             EVPN VPWS as VRF-AC            September 2020


   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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Integrated Routing and Cross-connecting . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  ARP/ND Synching and IP Prefix Synching  . . . . . . . . . . .   5
     2.1.  Constructing MAC/IP Advertisement Route . . . . . . . . .   6
     2.2.  Constructing Ethernet A-D Route . . . . . . . . . . . . .   6
     2.3.  Constructing IP Prefix Advertisement Route  . . . . . . .   6
   3.  Packet Walk Through . . . . . . . . . . . . . . . . . . . . .   7
   4.  Fast Convergence for Routed Traffic . . . . . . . . . . . . .   8
   5.  Considerations on ABRs and Route Reflectors . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   9.  Informative References  . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   When a VRF Attachment Cirucit (VRF-AC) is far away from its IP-VRF
   instance, we can deploy an EVPN VPWS ([RFC8214]) between that VRF-AC
   and its IP-VRF instance.  From the viewpoint of the IP-VRF instance,
   a local virtual interface takes the place of that remote "VRF-AC".
   The intended IP address for that VRF-AC is now configured to the
   virtual interface, in other words, the virtual interface is the
   actual VRF-AC of the IP-VRF instance.  The virtual interface is also
   the AC of that VPWS instance, in other words, the virtual interface
   is cross-connected to that remote "VRF-AC" by the VPWS instance.

   The requirements of this scenario is described in Section 1.1.











Wang & Zhang              Expires 19 March 2021                 [Page 2]


Internet-Draft             EVPN VPWS as VRF-AC            September 2020


1.1.  Integrated Routing and Cross-connecting

   When an IP-VRF instance and an EVPN VPWS instance are connected by an
   virtual-interface, We call such scenarios as Integrated Routing and
   Cross-connecting (IRC) use-case, and the virtual-interface connecting
   EVPN VPWS and IP-VRF is called as IRC interface, because that the
   packets received from the virtual-interface is routed in the IP-VRF
   and the data packets sent to the virtual-interface is cross-connected
   to the remote AC of that EVPN VPWS.

   The IRC use case are illustrated by the following figure:

                       PE1
                     +---------------------+
                     |      IRC1=10.1      |
                     |  +-----+   +------+ |.
                    .|  |VPWS1|---|IPVRF1| |  .
                  .  |  +-----+   +------+ |    .
       PE4      .    |                     |      .   PE3
    +--------+.      +---------------------+       +---------+
    |        |                    |                |         |
    |+-----+ |                    | RT-2           |+------+ |
    ||VPWS1| |                    | <10.2, N1>     ||IPVRF1| |
    |+-----+ |                    | label2=IPVRF1  |+------+ |
    |   |    |                    | label1=NULL    |   |     |
    +---|----+.                   |               .+---|-----+
        |       .      PE2        V             .      |
        |         .  +---------------------+  .        |
        |           .|      IRC2=10.1      |.          |
      N1=10.2        |  +-----+   +------+ |         N2=20.2
                     |  |VPWS1|---|IPVRF1| |
    Behind N1:       |  +-----+   +------+ |
    60.0/24          |                     |
    70.0/24          +---------------------+

             Figure 1: ARP/ND Synchronizing for IRC Interfaces

   There are four PE nodes named PE1/PE2/PE3/PE4 in the above network.
   PE4 is a pure EVPN VPWS PE, there may be no IP-VRFs on it.  PE3 is a
   pure L3 EVPN PE, there may be no VPWSes or MAC-VRFs on it.  PE1 and
   PE2 are the border of the EVPN VPWS domain and the L3 EVPN domain, so
   they are both EVPN VPWS PE and L3 EVPN PE, there will be both EVPN
   IP-VRFs and EVPN VPWSes on them.  N1/N2/N3/N4 may be a host or an IP
   router.  N1/N3/N4 is in the subnet 10.0/24.  N2 is in the subnet
   20.0/24.  When N1/N2/N3/N4 is a host, it is also called H1/H2/H3/H4
   in this document.  When N1/N2/N3/N4 is a router, it is also called
   R1/R2/R3/R4 in this document.  When N1 is a Router, there are two
   subnets behind N1, these subnets are 60.0/24 and 70.0/24.



Wang & Zhang              Expires 19 March 2021                 [Page 3]


Internet-Draft             EVPN VPWS as VRF-AC            September 2020


   Note that there may be L2 switches between N1/N2/N3/N4 and their PEs.
   These switches are not shown in Figure 1.

   Note that the IRC interfaces are considered as AC interfaces in EVPN
   VPWS instances.  At the same time, they are considered as VRF-ACs in
   IP-VRF instances.

   When N1 sends an ARP Request REQ_P1, then REQ_P1 will be forwarded by
   PE4 to either PE1 or PE2, not to the both.  Both the IRC1 on PE1 and
   IRC2 on PE2 are N1's subnet-gateway(SNGW).  But when N2 send an ARP
   Reply REP_P2 to N1, then PE3 may load-balance REP_P2 to either PE1 or
   PE2, not to the both.

   When REQ_P1 is load-balanced to PE1, not to PE2, but PE3 load-balance
   REP_P2 to PE2, The ARP entry of N1 will not be prepared on PE2 for
   REP_P2.  So the fowarding of REP_P2 will be delayed due to ARP
   missing.

   We use RT-2 routes to advertise the ARP entry of N1 from PE2 to PE3.
   But there SHOULD be no RT-2 advertisement in EVPN VPWS according to
   [RFC8214].  So the RT-2 routes from PE2 to PE3 SHOULD not carry any
   export-RTs of VPWS1, and the MPLS label1 field of these RT-2 routes
   should be set to NULL, not VPWS1.

   Note that an ESI may be assigned to IRC1 and IRC2, But it is not
   necessary to advertise that ESI in the L3 EVPN domain.  The ESI may
   be advertised in the EVPN VPWS domain only.

1.2.  Terminology

   Most of the terminology used in this documents comes from [RFC7432]
   and [I-D.ietf-bess-evpn-prefix-advertisement] except for the
   following:

   VRF AC: VRF Attachment Circuit, An Attachment Circuit (AC) that
   attaches a CE to an IP-VRF.  It is defined in [RFC4364].

   IRC: Integrated Routing and Cross-connecting, thus a IRC interface is
   the virtual interface connecting an IP-VRF and an EVPN VPWS.

   L3 EVI: An EVPN instance spanning the Provider Edge (PE) devices
   participating in that EVPN which contains VRF ACs and maybe contains
   IRB interfaces or IRC interfaces.

   IP-AD/EVI: Ethernet Auto-Discovery route per EVI, and the EVI here is
   an IP-VRF.





Wang & Zhang              Expires 19 March 2021                 [Page 4]


Internet-Draft             EVPN VPWS as VRF-AC            September 2020


   IP-AD/ES: Ethernet Auto-Discovery route per ES, and the EVI for one
   of its route targets is an IP-VRF.

   CE-BGP: The BGP session between PE and CE.  Note that CE-BGP route
   doesn't have a RD or Route-Target.

   RMAC: Router's MAC, which is signaled in the Router's MAC extended
   community.

   RT-2E: A MAC/IP Advertisement Route with a non-reserved ESI.

   RT-5E: An EVPN Prefix Advertisement Route with a non-reserved ESI.

   RT-5G: An EVPN Prefix Advertisement Route with a zero ESI and a non-
   zero GW-IP.

   RT-5L: An EVPN Prefix Advertisement Route with both zero ESI and zero
   GW-IP, but a valid MPLS label.

2.  ARP/ND Synching and IP Prefix Synching

   Host IP-MAC relations are learnt by PEs on the access side via a
   control plane protocol like ARP.  In case where N1 is multihomed to
   multiple L3 EVPN PE nodes by an All-Active EVPN VPWS, N1's Host IP/
   MAC will be learnt and advertised in the MAC/IP Advertisement only by
   the PE that receives the ARP packet.  The MAC/ IP Advertisement with
   non-zero ESI will be received by the other multihomed PE.

   As a result, after PE2 receives the MAC/IP Advertisement and imports
   it to the L3 EVI, PE2 installs an ARP entry to the VRF interface
   whose subnet matches the IP Address from the MAC/IP Advertisement.
   Such ARP entry is called remote synched ARP Entry in this document.

   Note that the PE3 follows the DGW1 behavior of
   [I-D.ietf-bess-evpn-prefix-advertisement]'s section 4.3 to achieve
   the load balancing procedures based on the recursive route resolution
   by the ESI Overlay Index.

   When PE3 load balance the traffic towards PE1/PE2, both PE1 and PE2
   would have been prepared with corresponding ARP entry yet because of
   the following ARP synching procedures.










Wang & Zhang              Expires 19 March 2021                 [Page 5]


Internet-Draft             EVPN VPWS as VRF-AC            September 2020


2.1.  Constructing MAC/IP Advertisement Route

   This draft introduces a new usage/construction of MAC/IP
   Advertisement route to enable ARP/ND synching for IP addresses in
   EVPN IRC use-cases.  The usage/construction of this route remains
   similar to that described in RFC 7432 with a few notable exceptions
   as below.

   *  The Route-Distinguisher should be set to the corresponding IP-VRF
      context.

   *  The Ethernet Tag should be set to 0.

   *  The MAC/IP Advertisement SHOULD carry one or more IP VRF Route-
      Target (RT) attributes.

   *  The ESI can be simply set to zero.

      Note that we use the subnet consistency between the host IP
      address and the IRC interface to determine which interface the
      synched ARP/ND entry should be installed to.

   *  The MPLS Label1 should be set to NULL.

      Note that the NULL value of MPLS label1 in MPLS EVPN should be
      implicit-null.  The NULL value of MPLS label1 in VXLAN EVPN should
      be 0.

   *  The MPLS Label2 should be set to IPVRF1.

   *  The RMAC Extended Community attribute SHOULD be carried in VXLAN
      EVPN.

2.2.  Constructing Ethernet A-D Route

   The ESI of the IRC interface is mainly use in the EVPN VPWS domain.
   That ESI has nothing to do with the fundamental function of the L3
   EVPN domain.

   Note that the Ethernet A-D route advertisement in the EVPN VPWS
   domain still follows [RFC8214].  The IRC interface is considered as
   an ordinary AC in the EVPN VPWS domain.

2.3.  Constructing IP Prefix Advertisement Route

   There may be two types of IP prefixes on PE1/PE2.  The first type is
   the prefix of the IRC interface itself.  The second type is the
   prefixes behind N1 (especially when N1 is a router).



Wang & Zhang              Expires 19 March 2021                 [Page 6]


Internet-Draft             EVPN VPWS as VRF-AC            September 2020


   Given that PE1/PE2 can install synced ARP entries to its proper IRC
   interface benefitting from the RT-2 route of Section 2.  This ensures
   that both PE1 and PE2 will know all hosts of the IRC interface's own
   subnet.  So it is not necessary for PE1/PE2 to advertise per-host IP
   prefixes of that subnet to PE3 by RT-2 routes.  It is recommended
   that PE1/PE2 advertise a single RT-5 route of that subnet to PE3
   instead.  The ESI of these RT-5 routes can be simply set to zero,
   because when PE3 receives such RT-5 routes from both PE1 and PE2, PE3
   can consider them as ECMP or FRR even when their ESI is zero.

   Note that N1 may be a host or a router, when it is a router, there
   may be some prefixes behind N1 on PE1.  Those prefixes will be learnt
   via a PE-CE route protocol.  N1's IP address may be considered as the
   overlay nexthop of those prefixes.  The overlay nexthop of those
   prefixes will be carried in the RT-5 route's GW-IP field.  Those RT-5
   routes are called as RT-5G routes because their Overlay Indexes are
   their GW-IPs (and their ESI and label are zero).

   Note that those RT-5G routes are advertised by PE1 to both PE2 and
   PE3.  If the IRC1 interface fails, the prefixes of the second type
   will achieve more faster convergency on PE3 by the withdraw (from
   PE1) of the corresponding prefix of the first type.

3.  Packet Walk Through

   The procedures for local/remote host learning and MAC/IP
   Advertisement route constructing are described above.

   When R2(N2) send a data packet P21 to a host 60.1 whose location is
   behind R1(N1), P21 will matches prefix 60.0/24 on PE3.  The RT-5G
   route for 60.0/24 will be used.  The GW-IP of that RT-5G route is
   10.1 (R1).  So PE3 use 10.1 to do recursive route resolution and
   matches the RT-5L route of 10.0/24.

   Note that the recursive route resolution follows the DGW1 behavior of
   [I-D.ietf-bess-evpn-prefix-advertisement]'s section 4.1.

   Both PE1 and PE2 have advertised the RT-5L route of 10.0/24 to PE3.
   PE3 may consider them as ECMP or FRR, depending on their route
   attributes.  Then PE3 should forward P21 to PE1 or PE2, depending on
   the ECMP/FRR procedures.

   We can assume that it is PE2 that will receive P21 from PE3.  The
   destination IP of P21 is in prefix 60.0/24.  That prefix has been
   installed into IPVRF1 on PE2.  PE2 previously received that prefix
   either from a PE-CE route protocol or from a RT-5G route from PE1.
   The overlay nexthop or GW-IP of prefix 60.0/24 is 10.1 (R1).  The
   outgoing interface for P21 is IRC2 interface.



Wang & Zhang              Expires 19 March 2021                 [Page 7]


Internet-Draft             EVPN VPWS as VRF-AC            September 2020


   The ARP entry for 10.1 is a synched ARP entry, because PE1 sent the
   ARP Request only to PE1.  It is intalled to IRC2 interface just
   because it is the ARP entry of a host of IRC2's subnet.

   Then P21 is encapsulated with a ethernet header and becomes an
   ethernet packet P21E.  The destination MAC address of P21E is N1's
   MAC address which is determined by that ARP entry.  The source MAC
   address of P21E is IRC2's MAC address.  Then P21E is sent to IRC2
   interface.

   After P21E is sent to IRC2 interface, it will be forwarded to PE4 in
   the EVPN VPWS instance according to [RFC8214]

4.  Fast Convergence for Routed Traffic

   When IRC1 interface goes down, PE1 will withdraw the RT-5L route of
   10.0/24.  And the RT-5G routes of 60.0/24 and 70.0/24 will be just
   changed to stale state.  When PE3 receives the withdraw of that RT-5L
   route, it will stop to forward the data packets of those two subnets
   to PE1 again.

5.  Considerations on ABRs and Route Reflectors

   When a Route Reflector (RR) receives a MAC/IP Advertisement Route
   whose MPLS label1 field is NULL, It should reflect that route to its
   clients as a normal route.  It should not consider that route as
   malformed.

   When a ABR or ASBR receives a MAC/IP Advertisement Route whose MPLS
   label1 field is NULL, It should re-advertise that route and that
   route's nexthop will be changed to itself.  It should not consider
   that route as malformed.  It should not allocate a new label for the
   MPLS label1 field.  That field should be kept NULL during the re-
   advertisement.  But the MPLS label2 field should be rewritten along
   with the nexthop-rewritting.

6.  Security Considerations

   This document does not introduce any new security considerations
   other than already discussed in [RFC7432] and
   [I-D.ietf-bess-evpn-prefix-advertisement].

7.  IANA Considerations

   There is no IANA consideration needed.

8.  Normative References




Wang & Zhang              Expires 19 March 2021                 [Page 8]


Internet-Draft             EVPN VPWS as VRF-AC            September 2020


   [I-D.dawra-bess-srv6-services]
              Dawra, G., Filsfils, C., Brissette, P., Agrawal, S.,
              Leddy, J., daniel.voyer@bell.ca, d.,
              daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
              Decraene, B., Matsushima, S., Zhuang, S., and J. Rabadan,
              "SRv6 BGP based Overlay services", Work in Progress,
              Internet-Draft, draft-dawra-bess-srv6-services-02, 8 July
              2019, <https://tools.ietf.org/html/draft-dawra-bess-srv6-
              services-02>.

   [I-D.ietf-bess-evpn-prefix-advertisement]
              Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A.
              Sajassi, "IP Prefix Advertisement in EVPN", Work in
              Progress, Internet-Draft, draft-ietf-bess-evpn-prefix-
              advertisement-11, 18 May 2018,
              <https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-
              advertisement-11>.

   [I-D.ietf-bess-evpn-inter-subnet-forwarding]
              Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
              Rabadan, "Integrated Routing and Bridging in EVPN", Work
              in Progress, Internet-Draft, draft-ietf-bess-evpn-inter-
              subnet-forwarding-10, 3 September 2020,
              <https://tools.ietf.org/html/draft-ietf-bess-evpn-inter-
              subnet-forwarding-10>.

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

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

9.  Informative References

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

Authors' Addresses






Wang & Zhang              Expires 19 March 2021                 [Page 9]


Internet-Draft             EVPN VPWS as VRF-AC            September 2020


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

   Email: yubao.wang2008@hotmail.com


   Zheng(Sandy) Zhang
   ZTE Corporation
   No. 50 Software Ave, Yuhuatai Distinct
   Nanjing
   China

   Email: zzhang_ietf@hotmail.com



































Wang & Zhang              Expires 19 March 2021                [Page 10]


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