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

Versions: 00                                                            
BESS Working Group                                            A. Sajassi
Internet Draft                                                  S. Salam
Category: Standard Track                                    P. Brissette
                                                                   Cisco

                                                                L. Jalil
                                                                 Verizon

Expires: January 2, 2018                                    July 2, 2017


       (PBB-)EVPN Integration with (PBB-)VPLS in All-Active Mode
               draft-sajassi-bess-evpn-vpls-all-active-00


Abstract

   This draft discusses the backward compatibility of the (PBB-)EVPN
   solution with (PBB-)VPLS in all-active redundancy mode.


Status of this Memo

   This Internet-Draft is submitted to IETF 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/1id-abstracts.html

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


Copyright and License Notice

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




Sajassi et al.          Expires January 2, 2018                 [Page 1]


INTERNET DRAFT  draft-sajassi-bess-evpn-vpls-all-active     July 2, 2017


   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  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1 Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
   2 Limitations  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3 Solution for MAC Flip-Flopping . . . . . . . . . . . . . . . . .  4
     3.1 Load-Balancing . . . . . . . . . . . . . . . . . . . . . . .  5
   4 Changes on EVPN PEs  . . . . . . . . . . . . . . . . . . . . . .  5
     4.1 Control Plane Changes  . . . . . . . . . . . . . . . . . . .  5
     4.2 Data Plane Changes . . . . . . . . . . . . . . . . . . . . .  6
       4.2.1 Known Unicast Traffic  . . . . . . . . . . . . . . . . .  6
       4.2.2 BUM Traffic  . . . . . . . . . . . . . . . . . . . . . .  6
   5 Failure Handling . . . . . . . . . . . . . . . . . . . . . . . .  7
   6 EVPN-VPWS termination onto multi-homing EVPN PEs . . . . . . . .  7
   7 Security Considerations  . . . . . . . . . . . . . . . . . . . .  8
   8  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  8
   9  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     9.1  Normative References  . . . . . . . . . . . . . . . . . . .  8
     9.2  Informative References  . . . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  8



















Sajassi et al.          Expires January 2, 2018                 [Page 2]


INTERNET DRAFT  draft-sajassi-bess-evpn-vpls-all-active     July 2, 2017


1  Introduction

   VPLS and PBB-VPLS are widely-deployed L2VPN technologies. Many SPs
   who are looking at adopting EVPN and PBB-EVPN want to preserve their
   investment in the (PBB-)VPLS networks. Hence, it is required to
   provide mechanisms by which (PBB-)EVPN technology can be introduced
   into existing L2VPN networks without requiring a fork-lift upgrade.
   [EVPN-VPLS] discusses mechanisms for the seamless integration of the
   two technologies in the same MPLS/IP network, however, operation is
   limited to single-active redundancy mode. In this document, we extend
   the solution to support all-active redundancy.

   Section 2 provides the limitations in the current (PBB-)EVPN/(PBB-
   )VPLS interoperability solution. Section 3 discusses the solution for
   addressing those limitations. Section 4 describes the required
   control and data plane changes to support all-active redundancy.
   Section 5 covers the failure handling.

1.1 Terminology

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


2 Limitations

   [EVPN-VPLS] defines mechanisms for (PBB-)EVPN seamless
   interoperability with (PBB-)VPLS. The solution defined in [EVPN-VPLS]
   suffers from a major limitation that hinders brown-field deployment
   of EVPN solution: It provides support for all-active redundancy only
   for VPN instances confined to (PBB-)EVPN PEs. For VPN instances that
   span both (PBB-)EVPN as well as (PBB-)VPLS PEs only single-active
   redundancy mode is supported. This eliminates one of the key value
   propositions of inserting EVPN solution in existing networks.

   The reason why this capability is not currently supported is due to
   the issue of MAC address flip-flopping on the VPLS PEs. This is best
   explained with an example: Consider the example network of Figure 1
   below. Assume that CE1 is connected over an all-active link
   aggregation group (LAG) to EVPN-capable PEs (PE2 and PE3). For
   traffic destined from CE1 to CE2, different flows from the same
   source MAC address MAC-A will be load-balanced over the LAG to PE2
   and PE3. PE2 will forward the traffic over its own pseudowire (call
   it PW-Blue) to PE5, whereas PE3 will forward the traffic over its own
   pseudowire (call it PW-Red) to PE5. As such, VPLS PE (PE5) will learn
   the same MAC address (MAC-A) over both PW-Red and PW-Blue, depending
   on the load-balancing. This MAC flip-flopping will continue



Sajassi et al.          Expires January 2, 2018                 [Page 3]


INTERNET DRAFT  draft-sajassi-bess-evpn-vpls-all-active     July 2, 2017


   indefinitely depending on traffic patterns.


                               VPLS PE
                                +---+
                                |PE1|
                                +---+
                                  /
           EVPN/VPLS PE  +---------------+   VPLS PE
                +---+    |               |   +---+    +---+
                |PE4|----|    MPLS/IP    |---|PE5|----|CE2| MAC-D
                +---+    |     Core      |   +---+    +---+
                         |               |
                         +---------------+
                           /        \
                        +---+     +---+
                        |PE2|     |PE3|
                        +---+     +---+
                  EVPN/VPLS PE   EVPN/VPLS PE
                           \      /
                            \    /
                             \  /
                             +---+
                             |CE1| MAC-A
                             +---+

    Figure 1: Seamless Integration of (PBB-)EVPN PEs & (PBB-)VPLS

   The focus of this draft is on providing a solution that addresses the
   above limitation, thereby enabling the support of all-active
   redundancy in mixed (PBB-)EVPN/(PBB-)VPLS deployments.

3 Solution for MAC Flip-Flopping

   In order to address the MAC flip-flopping problem on the VPLS PEs,
   these PEs must learn the traffic originating from a given source MAC
   address over the same pseudowire consistently, regardless of which
   remote EVPN-capable PE forwarded the traffic in a given multi-homed
   setup. To that end, every multi-homed EVPN-capable PE must maintain,
   in addition to its own pseudowires, a set of shadow or "alias"
   pseudowires for each of its peers in a given Redundancy Group (RG).
   For instance, in the example network of Figure 1, PE2 maintains its
   own pseudowire towards PE5 in addition to an "alias" pseudowire
   corresponding to the pseudowire between PE3 and PE5.

   When traffic arrives from a multi-homed CE over a multi-chassis LAG,
   the EVPN-capable PE then examines whether or not it is the Designated
   Forwarder (DF) for the Ethernet Segment (ES) in question. In the case



Sajassi et al.          Expires January 2, 2018                 [Page 4]


INTERNET DRAFT  draft-sajassi-bess-evpn-vpls-all-active     July 2, 2017


   where the PE is the DF for the ES, it would use its own pseudowire
   label to forward traffic towards a remote VPLS PE. However, in the
   case where the PE is not the DF for the ES, it would then use the
   "alias" pseudowire label associated with the DF PE in order to
   forward traffic towards the remote VPLS PE. To illustrate this using
   the example of Figure 1, consider that PE3 is the DF for the ES
   associated with CE1. Furthermore, assume that the pseudowire labels
   from PE2 and PE3 to PE5 are Label-Blue and Label-Red, respectively.
   When CE1 load-balances traffic destined to CE2 towards PE3, the
   latter will use its own pseudowire label (Label-Red) to forward
   traffic to PE5. Whereas, when CE1 forwards traffic destined to CE2
   towards PE2, it will use the alias pseudowire label (Label-Red)
   instead of its own pseudowire label to forward traffic towards PE5.
   This is because PE2 is not the DF for the Ethernet Segment associated
   with CE1.

3.1 Load-Balancing

   For traffic flowing from the EVPN-capable PEs towards the MPLS
   network, the load-balancing is on a per-flow granularity, regardless
   of whether the traffic is destined towards remote EVPN or VPLS PEs.

   For traffic flowing from the VPLS PEs towards the EVPN-capable PEs,
   the load-balancing is on a per-VLAN per destination site granularity.
   That is, the traffic for a given VLAN in a destination site is sent
   to only one of the multi-homed EVPN-capable PEs. This is because all
   the EVPN-capable PEs in a given redundancy group will use the the
   pseudowire label associated with the DF to forward traffic towards
   remote VPLS PEs (recall, also, that EVPN DF election is per VLAN per
   ES).

4 Changes on EVPN PEs

   The changes to support the mechanisms of this draft are confined to
   the EVPN-capable PEs. In the following two sub-sections we cover both
   the control plane as well as data plane changes required.

4.1 Control Plane Changes

   In order for the EVPN-capable PEs to maintain the alias pseudowires,
   it is required to synchronize the VPLS pseudowire labels among the
   PEs in the same Redundancy Group. For VPLS-BGP [RFC4761], this is
   straight-forward to achieve because the VE-IDs and label blocks
   associated with all PEs are advertised in BGP. Hence, a PE in an EVPN
   RG can easily extract the alias pseudowire labels associated with its
   peers in the same RG. For VPLS-LDP [RFC4762], protocol message
   extensions are required but are outside the scope of the current
   document.



Sajassi et al.          Expires January 2, 2018                 [Page 5]


INTERNET DRAFT  draft-sajassi-bess-evpn-vpls-all-active     July 2, 2017


   Another control plane extension that is required is to synchronize
   the MAC addresses learnt over the active pseudowire at DF EVPN PEs to
   the non-DF EVPN PEs with alias pseudowire using BGP. This can be done
   using the existing EVPN MAC Advertisement route. The identity of the
   pseudowire over which the address was learnt is encoded in the ESI
   field. This can be done using a Type 4 ESI, where the Router ID holds
   the IP address of the remote pseudowire endpoint IP address (i.e.
   VPLS PE address) and the high-order 2 octets of the Local
   Discriminator encode the VE-ID of the remote pseudowire endpoint
   (i.e. EVPN-capable PE that is the DF).

4.2 Data Plane Changes

4.2.1 Known Unicast Traffic

   After DF election is complete, the EVPN-capable PE programs its data
   plane based on the outcome of DF election as follows:

   If known unicast traffic is received by the PE from an Ethernet
   Segment for which it is the DF, then it uses its own pseudowire label
   in the label stack when forwarding traffic to remote VPLS PEs.

   If known unicast traffic is received by the PE from an Ethernet
   Segment for which is non-DF, then it uses the alias pseudowire label
   (associated with the DF) instead of its own pseudowire label in the
   label stack when forwarding traffic to remote VPLS PEs.

   In other words, the EVPN-capable PE must use the DF/non-DF status of
   the incoming attachment circuit interface in order to choose the
   correct label stack for VPLS forwarding.

4.2.2 BUM Traffic

   The EVPN-capable PEs must maintain two replication lists: one that
   uses their own pseudowires, and another that uses the alias
   pseudowires. When BUM traffic is received from the attachment
   circuit, the PE examines the DF status of the incoming interface to
   identify which of the two replication lists to use: If the PE is the
   DF, then it uses the replication list which encompasses its own
   pseudowires. Whereas, if the PE is non-DF, then it uses the
   replication list encompassing the alias pseudowires.

   BUM traffic received over a VPLS pseudowire is handled as follows:

   Broadcast and multicast traffic is identified as such by inspecting
   the destination MAC address, and is handled as usual per EVPN MPLS
   ingress flooding mechanisms. At egress to the attachment circuit, all
   broadcast and multicast VPLS traffic is subjected to DF filtering



Sajassi et al.          Expires January 2, 2018                 [Page 6]


INTERNET DRAFT  draft-sajassi-bess-evpn-vpls-all-active     July 2, 2017


   procedures per existing EVPN procedures.

   Unknown unicast traffic cannot be identified as such by the
   disposition PE on egress from the pseudowire, since nothing in the
   Ethernet frame or the MPLS label stack (unlike EVPN) distinguishes
   this traffic from known unicast. Furthermore, the disposition PE
   cannot rely on its own MAC forwarding table to infer whether the
   frame was flooded or not - i.e., an unknown MAC address on the
   imposition PE cannot be known to the disposition PE. Due to this, the
   egress (disposition) PE will treat unicast MAC addresses based on its
   own local forwarding state - i.e., if the MAC address is known
   locally, then it is treated as such and if the MAC address is unknown
   locally, then it is treated as BUM traffic and will apply DF
   filtering. This can lead to a side-effect for a very specific
   scenario where the MAC-DA is unknown at the ingress PE but it is
   known to the egress multi-homing PEs (i.e., there is no issue when
   MAC-DA is known at the ingress and unknown at the egress, or MAC-DA
   is unknown at both the ingress and egress PEs). In such a specific
   scenario, a multi-homed CE will experience duplicate packets for an
   interim period of time until the remote VPLS PE learns the MAC
   address from reverse traffic. The CE's application layer will handle
   the discard of transient duplicate frames. While it is acknowledged
   that this behavior deviates from classical Ethernet, which guarantees
   the absence of packet duplication, the side-effect occurs in very
   specific scenario and it is both short-lived and confined in scope to
   the PE/CE links. Hence, it is a reasonable trade-off to accept in
   favor of enabling all-active redundancy in the solution.

5 Failure Handling

   Failure handling follows standard EVPN and VPLS procedures:

   For link failure on DF EVPN-capable PE, the PE sends a mass withdraw
   indication using per ES Ethernet A-D route to other EVPN PEs, causing
   them to update their forwarding entries to point to only the non-DF
   PE. The DF PE also sends VPLS MAC address flush message to remote
   VPLS PEs, causing them to flush their entries. The non-DF EVPN PE
   takes over and assumes the DF role. It uses its own VPLS pseudowire
   labels for sending traffic towards the VPLS PEs.

   For link failure on non-DF EVPN PE, the PE sends mass withdraw per ES
   Ethernet A-D route to other EVPN PEs, causing them to update their
   forwarding entries to point to only the DF PE. Nothing is done with
   respect to the VPLS PEs, as this failure is transparent to them.


6 EVPN-VPWS termination onto multi-homing EVPN PEs This section will be
   added in the future revision to describe how the MAC synchroniation



Sajassi et al.          Expires January 2, 2018                 [Page 7]


INTERNET DRAFT  draft-sajassi-bess-evpn-vpls-all-active     July 2, 2017


   mechanism over PW described above can be used for this scenario.

7 Security Considerations

   No new security considerations beyond those for VPLS and EVPN.


8  IANA Considerations

   This document has no actions for IANA.


9  References

9.1  Normative References

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4761]  Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
              LAN Service (VPLS) Using BGP for Auto-Discovery and
              Signaling", RFC 4761, January 2007.

   [RFC4762]  Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
              LAN Service (VPLS) Using Label Distribution Protocol (LDP)
              Signaling", RFC 4762, January 2007.



   [EVPN-VPLS] Sajassi, A., Salam, S., Del Regno, N., and Rabadan, J.,
              "(PBB-)EVPN Seamless Integration with (PBB-)VPLS", draft-
              ietf-bess-evpn-vpls-seamless-integ-00, work in progress,
              February 2015,
              <https://datatracker.ietf.org/doc/html/draft-sajassi-bess-
              evpn-vpls-seamless-integ>.


9.2  Informative References




Authors' Addresses


   Ali Sajassi
   Cisco
   170 West Tasman Drive



Sajassi et al.          Expires January 2, 2018                 [Page 8]


INTERNET DRAFT  draft-sajassi-bess-evpn-vpls-all-active     July 2, 2017


   San Jose, CA  95134, US
   Email: sajassi@cisco.com


   Samer Salam
   Cisco
   595 Burrard Street, Suite 2123
   Vancouver, BC V7X 1J1, Canada
   Email: ssalam@cisco.com


   Patrice Brissette
   Cisco
   Email: pbrisset@cisco.com


   Luay Jalil
   Cisco
   Email: luay.jalil@verizon.com
































Sajassi et al.          Expires January 2, 2018                 [Page 9]