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

Versions: 00 01 02

Network Working Group                                        K. Kompella
Internet-Draft                                                B. Kothari
Updates: 4761 (if approved)                             Juniper Networks
Intended status: Standards Track                              T. Spencer
Expires: May 7, 2009                                                AT&T
                                                        November 3, 2008


         Multi-homing in BGP-based Virtual Private LAN Service
              draft-kompella-l2vpn-vpls-multihoming-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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.

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

   This Internet-Draft will expire on May 7, 2009.
















Kompella, et al.           Expires May 7, 2009                  [Page 1]


Internet-Draft            BGP VPLS Multi-homing            November 2008


Abstract

   Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private
   Network (VPN) that gives its customers the appearance that their
   sites are connected via a Local Area Network (LAN).  It is often
   required for the Service Provider (SP) to give the customer redundant
   connectivity to some sites, often called "multi-homing".  This memo
   shows how multi-homing can be offered in the context of BGP-based
   VPLS.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  General Terminology  . . . . . . . . . . . . . . . . . . .  3
     1.2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  VPLS Multi-homing Considerations . . . . . . . . . . . . .  5
     2.3.  Using the Spanning Tree Protocol for Multi-homing  . . . .  5
     2.4.  Active/Backup Links  . . . . . . . . . . . . . . . . . . .  6
     2.5.  Comparisons  . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Multi-homing Operation . . . . . . . . . . . . . . . . . . . .  7
     3.1.  VE ID Assignment . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  VE Preference  . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  BGP Local Preference . . . . . . . . . . . . . . . . . . .  8
     3.4.  Designated Forwarder Election  . . . . . . . . . . . . . .  8
       3.4.1.  BGP Path Selection . . . . . . . . . . . . . . . . . . 10
       3.4.2.  VPLS Path Selection  . . . . . . . . . . . . . . . . . 11
   4.  Multi-AS VPLS  . . . . . . . . . . . . . . . . . . . . . . . . 13
     4.1.  Inter-AS Method (b): EBGP Redistribution of VPLS
           Information between ASBRs  . . . . . . . . . . . . . . . . 13
     4.2.  Method (c): Multi-Hop EBGP Redistribution of VPLS
           Information between ASes . . . . . . . . . . . . . . . . . 15
   5.  VPLS Operation with multiple VE Identifiers  . . . . . . . . . 16
     5.1.  Pseudowire Establishment . . . . . . . . . . . . . . . . . 17
     5.2.  Handling Link Failures . . . . . . . . . . . . . . . . . . 19
   6.  MAC Flush Operations . . . . . . . . . . . . . . . . . . . . . 20
     6.1.  MAC List FLush . . . . . . . . . . . . . . . . . . . . . . 20
     6.2.  Implicit MAC Flush . . . . . . . . . . . . . . . . . . . . 21
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 24
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
     10.2. Informative References . . . . . . . . . . . . . . . . . . 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
   Intellectual Property and Copyright Statements . . . . . . . . . . 27



Kompella, et al.           Expires May 7, 2009                  [Page 2]


Internet-Draft            BGP VPLS Multi-homing            November 2008


1.  Introduction

   Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private
   Network (VPN) that gives its customers the appearance that their
   sites are connected via a Local Area Network (LAN).  It is often
   required for a Service Provider (SP) to give the customer redundant
   connectivity to one or more sites, often called "multi-homing".
   [RFC4761] explains how VPLS can be offered using BGP for auto-
   discovery and signaling; section 3.5 of that document describes how
   multi-homing can be achieved in this context.  Implementation and
   deployment of multi-homing in BGP-based VPLS has suggested some
   refinement of the procedures described earlier; this memo details
   these changes.

   Section 2 lays out some of the scenarios for multi-homing, other ways
   that this can be achieved, and some of the expectations of BGP-based
   multi-homing.  Section 3 defines the components of BGP-based multi-
   homing, and the procedures required to achieve this.  Section 7 may
   someday discuss security considerations.

1.1.  General Terminology

   Some general terminology is defined here; most is from [RFC4761] or
   [RFC4364].  Terminology specific to this memo is introduced as needed
   in later sections.

   A "Customer Edge" (CE) device, typically located on customer
   premises, connects to a "Provider Edge" (PE) device, which is owned
   and operated by the SP.  A "Provider" (P) device is also owned and
   operated by the SP, but has no direct customer connections.  A "VPLS
   Edge" (VE) device is a PE that offers VPLS services.

   A VPLS domain represents a bridging domain per customer.  A Route
   Target community as described in [RFC4360] is typically used to
   identify all the PE routers participating in a particular VPLS
   domain.  A VPLS site is a grouping of ports on a PE that belong to
   the same VPLS domain.  Sites are referred to as local or remote
   depending on whether they are configured on the PE router in context
   or on one of the remote PE routers (network peers).

1.2.  Conventions

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






Kompella, et al.           Expires May 7, 2009                  [Page 3]


Internet-Draft            BGP VPLS Multi-homing            November 2008


2.  Background

   This section describes various scenarios where multi-homing may be
   required, and the implications thereof.  It also describes some of
   the singular properties of VPLS multi-homing, and what that means
   from both an operational point of view and an implementation point of
   view.  It describes briefly how the Spanning Tree Protocol can be
   used to achieve multi-homing, and how that compares with BGP-based
   multi-homing.

2.1.  Scenarios

   The most basic scenario is shown in Figure 1.

   CE1 is a VPLS CE that is dual-homed to both PE1 and PE2 for redundant
   connectivity.

                             ...............
                            .               .    ___ CE2
                      ___ PE1                .  /
                     /    :                  PE3
                  __/    :       Service      :
              CE1 __     :       Provider    PE4
                    \     :                   : \___ CE3
                     \___ PE2                .
                            .               .
                             ...............

                           Figure 1: Scenario 1

   CE1 is a VPLS CE that is dual-homed to both PE1 and PE2 for redundant
   connectivity.  However, CE4, which is also in the same VPLS domain,
   is single-homed to just PE1.

              CE4 -------    ...............
                         \  .               .    ___ CE2
                      ___ PE1                .  /
                     /    :                  PE3
                  __/    :       Service      :
              CE1 __     :       Provider    PE4
                    \     :                   : \___ CE3
                     \___ PE2                .
                            .               .
                             ...............

                           Figure 2: Scenario 2





Kompella, et al.           Expires May 7, 2009                  [Page 4]


Internet-Draft            BGP VPLS Multi-homing            November 2008


2.2.  VPLS Multi-homing Considerations

   The first (perhaps obvious) fact about a multi-homed VPLS CE, such as
   CE1 in Figure 1 is that if CE1 is an Ethernet switch or bridge, a
   loop has been created in the customer VPLS.  This is a dangerous
   situation for an Ethernet network, and the loop must be broken.  Even
   if CE1 is a router, it will get duplicates every time a packet is
   flooded, which is clearly undesirable.

   The next is that (unlike the case of IP-based multi-homing) only one
   of PE1 and PE2 can be actively sending traffic, either towards CE1 or
   into the SP cloud.  That is to say, load balancing techniques will
   not work.  All other PEs MUST choose the same designated forwarder
   for a multi-homed site.  Call the PE that is chosen to send traffic
   to/from CE1 the "designated forwarder".

   In Figure 2, CE1 and CE4 must be dealt with independently, since CE1
   is dual-homed, but CE4 is not.

2.3.  Using the Spanning Tree Protocol for Multi-homing

   It is quite common to have redundant links in Ethernet networks; here
   too, redundancy leads to loops, but these can be broken by the use of
   the Spanning Tree Protocol (STP).  This technique can also be applied
   in the case of multi-homed CEs in a VPLS domain.  One approach is to
   run STP on the multi-homed CE (say CE1 in Figure 1).  CE1 would thus
   detect a potential loop in the virtual LAN, and "block" either the
   link to PE1 or to PE2, breaking the loop.  Blocking the link to PE2
   would effectively pick PE1 to be the designated forwarder, since (a)
   PE2 will not get any traffic from CE1 to forward; (b) PE2's traffic
   to CE1 will be ignored.

   There are several operational disadvantages to the STP approach:

   1.  The SP has to trust the customer to run STP correctly and manage
       changes carefully.  If the customer makes a mistake, the SP will
       pay for it by carrying the customer's "broadcast storm" across
       the SP network.

   2.  The choice of whether PE1 or PE2 will be the "designated
       forwarder" is made by the customer; however, the SP may feel that
       they should make this choice, and in fact may be in a better
       position to do so, as they know their network topology better.

   3.  STP has several characteristics that make it unsuitable for
       carrier networks.

   Another approach is to run STP on the PEs.  However, the whole point



Kompella, et al.           Expires May 7, 2009                  [Page 5]


Internet-Draft            BGP VPLS Multi-homing            November 2008


   of having a full mesh of PE-PE connections, and of "split horizon"
   forwarding (Section 4.2.5 [RFC4761]; Section 4.4 [RFC4762]) is so
   that STP is not needed on PEs.  Furthermore, in Figure 2, PE1 must
   not block the pseudowires to PE3 and PE4 in order to break the loop.

2.4.  Active/Backup Links

   Another approach is to define "active" and "backup" links from a
   multi-homed CE to the PEs.  For example, in Figure 1, CE1 could
   define the link to PE1 as active and the link to PE2 as backup.  If
   the link to PE1, or PE1 itself, fails, the CE1 could detect this and
   switch to the backup.  However, again, the SP has to trust the
   customer's staff to handle this correctly; also, the choice of
   whether to use PE1 or PE2 remains with the customer.

2.5.  Comparisons

   One of the above methods may be acceptable in some cases.  The
   technique described in this memo is for those who are unsatisfied
   with these methods.  This technique relies on BGP mechanisms;
   furthermore, the choice of "designated forwarder" is retained by the
   SP.  Finally, this technique can be used in conjunction with STP to
   get further "insurance" against the possibility of loops.




























Kompella, et al.           Expires May 7, 2009                  [Page 6]


Internet-Draft            BGP VPLS Multi-homing            November 2008


3.  Multi-homing Operation

   This section describes procedures for electing a designated forwarder
   among the set of PEs that are multi-homed to a customer site.  It is
   imperative that all VPLS PEs elect the same designated forwarder
   otherwise either a loop will be formed or traffic will be dropped.
   Thus, procedures defined here MUST be supported by all BGP speakers
   that are required to process VPLS NLRI advertisements.

3.1.  VE ID Assignment

   Figure 1 shows a customer site, CE1, multi-homed to two VPLS PEs, PE1
   and PE2.  In order for all VPLS PEs within the same VPLS domain to
   elect one of the multi-homed PEs as the designated forwarder, an
   indicator that the PEs are multi-homed is required.  This is achieved
   by assigning the same VE ID on PE1 and PE2 for CE1.  When remote VPLS
   PEs receive NLRI advertisement from PE1 and PE2 for CE1, the two NLRI
   advertisements for CE1 are identified as candidates for designated
   forwarder selection due to the same VE ID.  Thus, same VE ID MUST be
   assigned on all VPLS PEs that are multi-homed to the same customer
   site.

   Figure 2 shows two customer sites, CE1 and CE4, connected to PE1 and
   CE1 multi-homed to PE1 and PE2.  In such a case, PE1 SHOULD assign
   different VE IDs to CE1 and CE4, but the VE ID for CE1 on both PE1
   and PE2 MUST be same.

   Note that a VE ID = 0 is invalid.

3.2.  VE Preference

   When multiple PEs are assigned the same VE ID for multi-homing, it is
   often desired to make a particular PE as the designated forwarder.  A
   VE preference is introduced in this document that can be used to
   control the selection of the designated forwarder.  A VE preference
   indicates a degree of preference for a particular customer site.
   Absence of this preference will still elect a designated forwarder
   based on the algorithm explained in Section 3.4.

   Section 3.2.4 in [RFC4761] describes the Layer2 Info Extended
   Community that carries control information about the pseudowires.
   The last two octets that were reserved now carries VE preference as
   shown in Figure 3.








Kompella, et al.           Expires May 7, 2009                  [Page 7]


Internet-Draft            BGP VPLS Multi-homing            November 2008


                      +------------------------------------+
                      | Extended community type (2 octets) |
                      +------------------------------------+
                      |  Encaps Type (1 octet)             |
                      +------------------------------------+
                      |  Control Flags (1 octet)           |
                      +------------------------------------+
                      |  Layer-2 MTU (2 octet)             |
                      +------------------------------------+
                      |  VE Preference (2 octets)          |
                      +------------------------------------+



                 Figure 3: Layer2 Info Extended Community

   A VE preference is a 2-octets unsigned integer.  A value of zero
   indicates absence of VE preference and is not a valid preference
   value.  This interpretation is required for backwards compatibility.
   Implementations using Layer2 Info Extended Community as described in
   (Section 3.2.4) [RFC4761] MUST set the last two octets as zero since
   it was a reserved field.

3.3.  BGP Local Preference

   Section 3.5 in [RFC4761] describes the use of BGP Local Preference in
   path selection to choose a particular NLRI, where Local Preference
   indicates the degree of preference for a particular VE.  The use of
   Local Preference is inadequate when VPLS PEs are spread across
   multiple ASes as Local Preference is not carried across AS boundary.

   For backwards compatibility, if VE preference as described in
   Section 3.2 is used, then BGP Local Preference MUST be set to the
   value of VE preference.  Note that a Local Preference value of zero
   for a VE is not valid unless 'D' bit in the control flags is set (see
   [I-D.kothari-l2vpn-auto-site-id]).  In addition, Local Preference
   value greater than or equal to 2^16 for VPLS advertisements is not
   valid.

3.4.  Designated Forwarder Election

   BGP-based multi-homing for VPLS relies on BGP path selection and VPLS
   path selection.  BGP path selection as defined in this document for
   VPLS NLRIs MUST be done by any BGP speaker that is required to
   process VPLS NRLI advertisements.  Thus, a Route Reflector,
   [RFC4456], MUST support the procedures defined in this document for
   BGP path selection for VPLS.  Similarly, a BGP speaker that is also a
   VPLS PE MUST also do BGP path selection for VPLS advertisements.



Kompella, et al.           Expires May 7, 2009                  [Page 8]


Internet-Draft            BGP VPLS Multi-homing            November 2008


   VPLS path selection, however, is done only by a VPLS PE.  The net
   result of doing both BGP and VPLS path selection is that of electing
   a single designated forwarder among the set of PEs to which a
   customer site is multi-homed.

   In order to explain how these two path selection algorithms work, one
   must refer to the format of the VPLS NLRI.  This NLRI contains:
   <Route Distinguisher, VE ID, VE Block Offset, VE Block Size, Label
   Base> (Section 3.2.2) [RFC4761].  These components are referred as
   RD, VE-ID, VBO, VBS and LB, respectively.  In addition, a VPLS
   advertisement contains some attributes, among them the BGP nexthop
   (BNH), control flags (CF), VE Preference (VP), and Local Preference
   (LP).  A VPLS advertisement might contain a Route Origin Attribute
   (RO).  Finally, the VPLS domain (DOM) is needed; this is not carried
   explicitly in a VPLS advertisement, but is derived, typically from
   BGP policies applied on Route Targets carried in the advertisement.
   In addition to these fields in the advertisement, there are two
   derived fields called PE-ID and PREF.  The Table 1 shows how to set
   the value of PREF based on VP and LP.  The Table 2 shows how to set
   the value of PE-ID based on RO and BNH.

   +-------------+-------------+---------------+-----------------------+
   |    Valid    |    Valid    |  Valid values |        Comment        |
   |  values for |  values for |    for PREF   |                       |
   |      VP     |      LP     |               |                       |
   +-------------+-------------+---------------+-----------------------+
   |      0      |      0      |       0       |       malformed       |
   |             |             |               | advertisement, unless |
   |             |             |               |         CF:D=1        |
   |             |             |               |                       |
   |      0      |     1 to    |       LP      |       backwards       |
   |             |   (2^16-1)  |               |     compatibility     |
   |             |             |               |                       |
   |      0      |   2^16 to   |    (2^16-1)   |       backwards       |
   |             |   (2^32-1)  |               |     compatibility     |
   |             |             |               |                       |
   |      >0     |  LP same as |       VP      |     Implementation    |
   |             |      VP     |               |      supports VP      |
   |             |             |               |                       |
   |      >0     |   LP != VP  |       0       |       malformed       |
   |             |             |               |     advertisement     |
   +-------------+-------------+---------------+-----------------------+

                                  Table 1







Kompella, et al.           Expires May 7, 2009                  [Page 9]


Internet-Draft            BGP VPLS Multi-homing            November 2008


   +----------+---------------------------+----------------------------+
   |    RO    |           PE-ID           |           Comment          |
   |  Present |                           |                            |
   +----------+---------------------------+----------------------------+
   |    Yes   |    Global Administrator   |  Source PE as specified in |
   |          |      sub-field of RO      |             RO             |
   |          |                           |                            |
   |    No    |            BNH            |  Source PE as specified by |
   |          |                           |         BGP nexthop        |
   +----------+---------------------------+----------------------------+

                                  Table 2

   Taken all together, this yields:

           <RD, VE-ID, VBO, VBS, LB; DOM, PE-ID, CF, PREF>

   Both BGP and VPLS path selection algorithms are described in two
   stages.  For each algorithm, the first stage divides all received
   VPLS advertisements into buckets of relevant and comparable
   advertisements.  In this stage, advertisements may be discarded as
   not being relevant to path selection.  The second stage picks a
   single "winner" from each bucket by repeatedly applying a tie-
   breaking algorithm on a pair of advertisements from that bucket.  The
   tie-breaking rules are such that the order in which advertisements
   are picked from the bucket does not affect the final result.  Note
   that this is a conceptual description of the process; an
   implementation MAY choose to realize this differently as long as the
   semantics are preserved.

3.4.1.  BGP Path Selection

3.4.1.1.  Bucketization

   An advertisement

            AD = <RD, VE-ID, VBO, VBS, LB; DOM, PE-ID, CF, PREF>

   is discarded if DOM is not of interest to the BGP speaker.
   Otherwise, AD is put into the bucket for <RD, VE-ID, VBO>.  In other
   words, the prefix to use for comparison in BGP path selection
   consists of <RD, VE-ID, VBO> and only advertisements with exact same
   <RD, VE-ID, VBO> are candidates for path selection.

3.4.1.2.  Tie-breaking Rules

   Given two advertisements AD1 and AD2 as below, the following tie-
   breaking rules MUST be applied in the given order (note that the RDs,



Kompella, et al.           Expires May 7, 2009                 [Page 10]


Internet-Draft            BGP VPLS Multi-homing            November 2008


   VE-IDs and VBOs are the same):

        AD1 = <RD, VE-ID, VBO, VBS1, LB1; DOM, PE-ID1, CF1:D, PREF1>
        AD2 = <RD, VE-ID, VBO, VBS2, LB2; DOM, PE-ID2, CF2:D, PREF2>

   where CF:D is the 'D' bit in the control flags and PREF is derived as
   shown in Table 1

   1.  if (CF1:D != 1) AND (CF2:D == 1) AD1 wins; stop
       if (CF1:D == 1) AND (CF2:D != 1) AD2 wins; stop
       else continue

   2.  if (PREF1 > PREF2) AD1 wins; stop;
       else if (PREF1 < PREF2) AD2 wins; stop;
       else continue

   3.  if (PE-ID1 < PE-ID2) AD1 wins; stop;
       else if (PE-ID1 > PE-ID2) AD2 wins; stop;
       else AD1 and AD2 are equivalent; BGP will consider this as an
       update

   For VPLS advertisements, the above rules supercede the tie breaking
   rules described in (Section 9.1.2.2) [RFC4271]

3.4.2.  VPLS Path Selection

3.4.2.1.  Bucketization

   An advertisement

            AD = <RD, VE-ID, VBO, VBS, LB; DOM, PE-ID, CF, PREF>

   is discarded if DOM is not of interest to the VPLS PE.  Otherwise, AD
   is put into the bucket for <DOM, VE-ID>.  In other words, all
   advertisements for a particular VPLS domain that have the same VE-ID
   are candidates for VPLS path selection.

3.4.2.2.  Tie-breaking Rules

   Given two advertisements AD1 and AD2 as below, the following tie-
   breaking rules MUST be applied in the given order (note that VE-IDs
   are same).

        AD1 = <RD, VE-ID, VBO, VBS1, LB1; DOM, PE-ID1, CF1:D, PREF1>
        AD2 = <RD, VE-ID, VBO, VBS2, LB2; DOM, PE-ID2, CF2:D, PREF2>

   where CF:D is the 'D' bit in the control flags




Kompella, et al.           Expires May 7, 2009                 [Page 11]


Internet-Draft            BGP VPLS Multi-homing            November 2008


   1.  if (CF1:D != 1) AND (CF2:D == 1) AD1 wins; stop
       if (CF1:D == 1) AND (CF2:D != 1) AD2 wins; stop
       else continue

   2.  if (PREF1 > PREF2) AD1 wins; stop;
       else if (PREF1 < PREF2) AD2 wins; stop;
       else continue

   3.  if (PE-ID1 < PE-ID2) AD1 wins; stop;
       else if (PE-ID1 > PE-ID2) AD2 wins; stop;
       else AD1 and AD2 are from the same VPLS PE; AD1 and AD2 should
       both be retained and an implementation MAY sort the
       advertisements by other criteria such as VBO

   If the final "winning" advertisement has VE-ID = 0 OR VBO = 0 OR VBS
   = 0, it is discarded.



































Kompella, et al.           Expires May 7, 2009                 [Page 12]


Internet-Draft            BGP VPLS Multi-homing            November 2008


4.  Multi-AS VPLS

   Section 3.4 in [RFC4761] describes three methods (a, b and c) to
   connect sites in a VPLS to PEs that are across multiple AS.  Since
   VPLS advertisements in method (a) do not cross AS boundaries, multi-
   homing operations for method (a) remain exactly the same as they are
   within as AS.  However, both for method (b) and (c), VPLS
   advertisements do cross AS boundary.  This section describes the VPLS
   operations for method (b) and method (c).  Consider Figure 4 for
   inter-AS VPLS with multi-homed customer sites.

4.1.  Inter-AS Method (b): EBGP Redistribution of VPLS Information
      between ASBRs




                            AS1                    AS2
                           ........               ........
            CE2 _______   .        .             .        .
                    ___ PE1         .           .          PE3 --- CE3
                   /    :            .         .            :
                __/    :             :         :             :
            CE1 __     :           ASBR1 --- ASBR2           :
                  \     :            :         :            :
                   \___ PE2         .           .          PE4 ---- CE4
                          .        .             .         .
                           ........                ........


           Assume VE IDs to be:
           CE1: 1
           CE2: 2
           CE3: 3
           CE4: 4

                          Figure 4: Inter-AS VPLS

   A customer has four sites, CE1, CE2, CE3 and CE4.  CE1 is multi-homed
   to PE1 and PE2 in AS1.  CE2 is single-homed to PE1.  CE3 and CE4 are
   also single homed to PE3 and PE4 respectively in AS2.  After running
   path selection algorithm, all four VPLS PEs must elect the same set
   of designated forwarder for all customer sites.  Since BGP Local
   Preference is not carried across AS boundary, VE preference as
   described in Section 3.2 MUST be used for carrying site preference in
   inter-AS VPLS operations.

   As explained in (Section 3.4.2) [RFC4761], ASBR1 will send a VPLS



Kompella, et al.           Expires May 7, 2009                 [Page 13]


Internet-Draft            BGP VPLS Multi-homing            November 2008


   NLRI received from PE1 to ASBR2 with new labels and itself as the BGP
   nexthop.  ASBR2 will send the received NLRI from ASBR1 to PE3 and PE4
   with new labels and itself as the BGP nexthop.  Since VPLS PEs use
   BGP Local Preference in path selection, for backwards compatibility,
   ASBR2 MUST set the Local Preference value in the VPLS advertisements
   it sends to PE3 and PE4 to the VE preference value contained in the
   VPLS advertisement it receives from ASBR1.  ASBR1 MUST do the same
   for the NLRIs it sends to PE1 and PE2.  If ASBR1 receives a VPLS
   advertisement without a valid VE preference from a PE within its AS,
   then ASBR1 MUST set the VE preference in the advertisements to the
   Local Preference value before sending it to ASBR2.  Similarly, ASBR2
   must do the same for advertisements without VE Preference it receives
   from PEs within its AS.  Thus, in method (b), ASBRs MUST update the
   VE and Local Preference based on the advertisements they receive
   either from a PE within their AS or an ASBR.

   Since ASBR rewrites the BGP nexthop for VPLS advertisements it
   receives from other ASes, the VPLS PEs no longer have the visibility
   of the remote end PEs.  In Figure 4, both PE3 and PE4 receives VPLS
   NLRIs from ASBR2 for VE IDs 1 and 2, with BGP nexthop of ASBR2.
   However, the VPLS PEs that originated the advertisements for VE IDs 1
   and 2 are PE1 and PE2.  Due to lack of information about the PEs that
   originated the VPLS NLRIs, both PE3 and PE4 will only create one PW
   to ASBR2 as to PE3 and PE4, the customer sites CE1 and CE2 appear
   connected to ASBR2.  However, two PWs are required in this case, one
   for CE1 and another one for CE2.  This can only be achieved if PE3
   and PE4 know the originator PE for each advertisement received.  For
   this purpose, Route Origin Extended Community [RFC4360] is used to
   carry the source PE's IP address.

   To use Route Origin Extended Community for carrying the originator
   VPLS PE's loopback address, the type field of the community MUST be
   set to 0x01 and the Global Administrator sub-field MUST be set to the
   PE's loopback IP address.

   If a PE receives a VPLS NLRI with Route Origin Extended Community,
   then the PE MUST use the IP address contained in the community as the
   source PE.  Otherwise, BGP nexthop for the VPLS advertisements MUST
   be used as the source PE IP address.  A VPLS PE MUST create one
   active PW per remote PE.  In Figure 4, PE1 will send the VPLS
   advertisements with Route Origin Extended Community containing its
   loopback address.  PE2 will do the same.  Even though PE3 receives
   the VPLS advertisements for VE ID 1 and 2 from the same BGP nexthop,
   ASBR2, the source PE address contained in the Route Origin Extended
   Community is different for the CE1 and CE2 advertisements, and thus,
   PE3 creates two PWs, one for CE1 (for VE ID 1) and another one for
   CE2 (for VE ID 2).




Kompella, et al.           Expires May 7, 2009                 [Page 14]


Internet-Draft            BGP VPLS Multi-homing            November 2008


4.2.  Method (c): Multi-Hop EBGP Redistribution of VPLS Information
      between ASes

   In this method, there is a multi-hop E-BGP peering between the PEs or
   Route Reflectors in AS1 and the PEs or Route Reflectors in AS2.
   There is no VPLS state in either control or data plane on the ASBRs.
   The multi-homing operations on the PEs in this method are exactly the
   same as they are in intra-AS scenario.  However, since Local
   Preference is not carried across AS boundary, the translation of LP
   to VP and vice versa MUST be done by RR, if RR is used to reflect
   VPLS advertisements to other ASes.  This is exactly the same as what
   a ASBR does in case of method (b).  A RR must set the VP to the LP
   value in an advertisement before sending it to other ASes and must
   set the LP to the VP value in an advertisement that it receives from
   other ASes before sending to the PEs within the AS.




































Kompella, et al.           Expires May 7, 2009                 [Page 15]


Internet-Draft            BGP VPLS Multi-homing            November 2008


5.  VPLS Operation with multiple VE Identifiers

   VE Identifiers uniquely identifies a particular customer site in a
   VPLS domain.  Even when multiple customer sites are attached to the
   same VPLS PE as in Figure 5, a single VE ID is sufficient to
   represent the two customer sites, A and B, as both are connected to
   the same PE.

                                      ...............
                         ...         .               .
                        | A |       :    Service      :
                         --- \      :    Provide      :        ...
                              \__   :     VPLS       PE2 ---  | C |
                              ___  PE1   Network      :        ---
                         ... /      :                 :
                        | B |        .               .
                         ---          ...............


            Figure 5: Multiple Customer sites with single VE ID

   However, if sites of a customer are multi-homed to different set of
   PEs, such as in Figure 6, and redundancy per site is desired, then
   PEs MUST advertise a unique VE ID for each site that requires
   redundancy.

                                      ...............
                         ...         .               .
                        | B |       :                 :
                         --- \      :                 :        ...
                              \__   :   Service      PE2 ---  | C |
                              ___  PE1                :        ---
                         ... /      :     Provider    :
                        | A |       :                 :
                         --- \      :                 :
                              \__  PE3                :
                                    :                 :
                                     .................


          Figure 6: Multiple Customer sites with different VE ID

   In Figure 6, site A is multi-homed to PE1 and PE3, but site B is
   single homed to PE1.  Since redundancy for both A and B is desired,
   PE1 and PE3 MUST assign the same VE ID for site A, and PE1 MUST
   assign a different VE ID for B.

   This section describes the VPLS operations, both for intra and inter



Kompella, et al.           Expires May 7, 2009                 [Page 16]


Internet-Draft            BGP VPLS Multi-homing            November 2008


   AS scenarios, when there are multiple sites with different VE IDs, as
   in Figure 6.

5.1.  Pseudowire Establishment

   This section explains how PWs are established between the PEs, when
   more than one customer site with different VE ID is connected to the
   same PE.  Procedures described in this section are in context of one
   VPLS domain.  Route Target, as explained in [RFC4360], identifies a
   VPLS domain.

   When a PE receives VPLS NLRIs for multiple VE IDs for the same VPLS
   instance from a remote PE, it MUST create an active PW by selecting
   one of the VE IDs as primary and SHOULD create standby PWs for other
   VE IDs.  The setting up of PWs follow existing procedures defined in
   RFC 4761.  To select a site for setting up primary PW, an
   advertisement with the lowest VE ID is selected.

   In Figure 7,since VE preference of PE1 is better than PE3 for VE ID
   1, PE1 wins the designated forwarder election based on Section 3.4.
   Thus, PE1 is the designated forwarder for site A, and since site B is
   single homed to PE1, PE1 will always be the forwarder for site B.





























Kompella, et al.           Expires May 7, 2009                 [Page 17]


Internet-Draft            BGP VPLS Multi-homing            November 2008


                                  ...............
                     ...         .               .
           VE ID=2  | B |       :                 :
                     --- \      :                 :        ...
                          \__   :   Service      PE2 ---  | C | VE ID=3
                          ___  PE1                :        ---
                     ... /      :     Provider    :
           VE ID=1  | A |       :                 :
                     --- \      :                 :
                          \__  PE3                :
                                :                 :
                                 .................

            VPLS NLRIs advertised by each PE:

            PE1: VE_ID=1, LB=11, OFF=1, Pref=200 (for site A)
                 VE_ID=2, LB=11, OFF=1, Pref=100 (for site B)

            PE2: VE_ID=3, LB=21, OFF=1 Pref=100 (for site B)

            PE3: VE_ID=1, LB=101, OFF=1 Pref=100 (for site C)

            where 'LB' is label base and 'OFF' is VE block offset
            as carried in VPLS NLRI. 'Pref' is VE Preference as
            carried in Layer2 Info Extended Community


          Figure 7: Multiple Customer sites with different VE ID

   PE2 MUST select VE ID of 1 for setting up active PW to PE1.  Thus,
   PE2 MUST use labels 21 and 22 to accept traffic from PE1, label 21
   being the active PW and label 22 for standby PW.  Note that PE2 MUST
   associate MAC addresses from both PWs to remote PE, PE1, and should
   not associate MAC addresses to individual PWs.  In case the active PW
   from PE1 to PE2 goes down, all MAC addresses learned from PE1 on PE2
   will remain associated unless age out occurs or PE1 sends a FLUSH-
   MESSAGE to PE2 [I-D.kothari-l2vpn-vpls-flush].  More details on
   flushing of MAC addresses are explained in Section 6.

   When a PE has multiple sites, it MUST advertise the same label base,
   block offset and range for all its sites.  In Figure 7, PE1 is
   advertising label base of 11, block offset of 1 and block range of 8
   for both sites A (VE ID 1) and B (VE ID 2).  When PE1's
   advertisements reach PE2, PE2 will always send traffic to PE1 with
   label 13, irrespective of which site A or B is active.  This
   eliminates the need for PE2 to have multiple PWs to PE1.





Kompella, et al.           Expires May 7, 2009                 [Page 18]


Internet-Draft            BGP VPLS Multi-homing            November 2008


5.2.  Handling Link Failures

   In Figure 7, when link connectivity between site A and PE1 goes down,
   PE1 MUST immediately send traffic to PE2 with label 22 instead of
   label 21 that it was previously using.  It MUST also send a BGP
   update with 'D' bit set in the control flags.  PE1 is no longer the
   designated forwarder for site A.

   Since PE2 has both labels, 21 and 22, there is no disruption of
   traffic to PE2 when PE1 switches to label 22 from label 21.  There
   should be no MAC movement or re-learning on PE2 for traffic from PE1
   for site B as a result of label switch by PE1.  In addition, PE2 will
   continue to use label 13 for traffic to PE1 and thus, connectivity
   failure between A and PE1 has no impact on the traffic from PE2 to
   PE1.

   When PE3 receives the advertisement from PE1 with the 'D' bit set, it
   MUST elect itself as the designated forwarder for site A based on the
   multi-homing path selection rules.  Similarly, PE2 elects PE3 as the
   designated forwarder for the site A. PE3 creates PWs to PE2 using
   normal procedures and starts using label advertised by PE2 to send
   traffic to PE2.  Due to the change in designated forwarder, MAC
   addresses received on PE2 with label 21 are associated with PE3.
   Note that if MAC addresses for site A were not flushed on PE2 when
   link between A and PE1 went down, then PE2 can see MAC movement as it
   is now learning site A's MAC addresses from PE3.

   Instead of connectivity between site A and PE1, if link connectivity
   between site B and PE1 goes down, there is no impact on traffic as
   PE1 is already using label 21 for traffic to PE2.  PE2 will continue
   to use label 13 for traffic to PE1 with no change.  Unless explicitly
   flushed or age out occurs, MAC addresses for site B will remain as is
   on PE2.


















Kompella, et al.           Expires May 7, 2009                 [Page 19]


Internet-Draft            BGP VPLS Multi-homing            November 2008


6.  MAC Flush Operations

   In a service provider VPLS network, customer MAC learning is confined
   to PE devices and any intermediate nodes, such as a Route Reflector,
   do not have any for state for MAC addresses.

   Topology changes either in the service provider's network or in
   customer's network can result in the movement of MAC addresses from
   one PE device to another.  Such events can result into traffic being
   dropped due to stale state of MAC addresses on the PE devices.  Age
   out timers that clear the stale state will resume the traffic
   forwarding, but age out timers are typically in minutes, and
   convergence of the order of minutes can severely impact customer's
   service.  To handle such events and expedite convergence of traffic,
   flushing of affected MAC addresses is highly desirable.

   A VPLS PE uses VPLS FLush Capability [I-D.kothari-l2vpn-vpls-flush]
   to negotiate the use of VPLS-FLUSH message for MAC flush operations.
   This section describes the scenarios where VPLS flush is desirable
   and the specific VPLS Flush TLVs that provide capability to flush the
   affected MAC addresses on the PE devices.  All operations described
   in this section are in context of a particular VPLS domain and not
   across multiple VPLS domains.

6.1.  MAC List FLush

   If multiple customer sites are connected to the same PE, PE1 as shown
   in Figure 7, and redundancy per site is desired when multi-homing
   procedures described in this document are in affect, then it is
   desired to flush just the relevant MAC addresses from a particular
   site when the site connectivity is lost.

   To flush particular set of MAC addresses, a PE SHOULD originate a
   VPLS-FLUSH message with MAC list TLV (TLV type 0) that contains a
   list of MAC addresses that needs to be flushed.  In Figure 7, if
   connectivity between A and PE1 goes down and if PE1 was the
   designated forwarder for A, PE1 SHOULD send a list of MAC addresses
   that belong to A to all its BGP peers.

   If connectivity to both site A and B are down on PE1, then PE1 SHOULD
   not send a VPLS-FLUSH message as the remote PEs will flush all MAC
   addresses that belong to PE1, as described in Section 6.2.

   If a single customer site is connected to a PE, and the connectivity
   to the site is lost, then the PE SHOULD not send a VPLS-FLUSH message
   as the remote PEs will flush all MAC addresses that they learned from
   the source PE (see Section 6.2).




Kompella, et al.           Expires May 7, 2009                 [Page 20]


Internet-Draft            BGP VPLS Multi-homing            November 2008


   It is RECOMMENDED that in case of excessive link flap of customer
   attachment circuit in a short duration, a PE should have a means to
   throttle advertisements of VPLS-FLUSH messages so that excessive
   flooding of such advertisements do not occur.

6.2.  Implicit MAC Flush

   If a PE detects that all PWs from a source PE for a VPLS domain are
   down, then the PE should flush all MAC addresses learned from that
   source PE.  Need for a VPLS-FLUSH message is only for cases when a
   primary PW is torn down and standby PWs are in operational state.
   Thus, a PE should not advertise VPLS-FLUSH message for cases when an
   implicit flush due to loss of all PWs is sufficient.

   When a connectivity to a customer site is lost, a PE either withdraws
   the VPLS NLRI that it previously advertised for the site or it sends
   a BGP update message for the site's VPLS NLRI with the 'D' bit set.
   In either case, remote PEs learn that a particular site is no longer
   reachable.

   In Figure 7, if PE1 withdraws VPLS NLRIs for both site A and B or
   sends BGP update with VPLS NLRIs for both A and B with 'D' bit set,
   then PE2 SHOULD flush all MAC addresses that it learned from PE1.
   PE1 should not send a VPLS-FLUSH message in this case.

   If PE1 withdraws VPLS NLRIs for just site A or sends an update for
   site A NLRIs with 'D' bit set, then PE2 SHOULD not flush MAC
   addresses that it learned from PE1, unless PE2 has no standby PWs to
   PE1.






















Kompella, et al.           Expires May 7, 2009                 [Page 21]


Internet-Draft            BGP VPLS Multi-homing            November 2008


7.  Security Considerations

   No new security issues are introduced beyond those that are described
   in [RFC4761].















































Kompella, et al.           Expires May 7, 2009                 [Page 22]


Internet-Draft            BGP VPLS Multi-homing            November 2008


8.  IANA Considerations

   At this time, this memo includes no request to IANA.
















































Kompella, et al.           Expires May 7, 2009                 [Page 23]


Internet-Draft            BGP VPLS Multi-homing            November 2008


9.  Acknowledgments

   The authors would like to thank Chaitanya Kodeboyina, Yakov Rekhter,
   Nischal Sheth and Amit Shukla for their insightful comments and
   probing questions.














































Kompella, et al.           Expires May 7, 2009                 [Page 24]


Internet-Draft            BGP VPLS Multi-homing            November 2008


10.  References

10.1.  Normative References

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

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

   [I-D.kothari-l2vpn-auto-site-id]
              Kothari, B., Kompella, K., and T. IV, "Automatic
              Generation of Site IDs for Virtual Private LAN Service",
              draft-kothari-l2vpn-auto-site-id-01 (work in progress),
              October 2008.

   [I-D.kothari-l2vpn-vpls-flush]
              Kothari, B. and R. Fernando, "VPLS Flush in BGP-based
              Virtual Private LAN Service",
              draft-kothari-l2vpn-vpls-flush-00 (work in progress),
              October 2008.

10.2.  Informative References

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, February 2006.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

   [RFC4456]  Bates, T., Chen, E., and R. Chandra, "BGP Route
              Reflection: An Alternative to Full Mesh Internal BGP
              (IBGP)", RFC 4456, April 2006.

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

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.










Kompella, et al.           Expires May 7, 2009                 [Page 25]


Internet-Draft            BGP VPLS Multi-homing            November 2008


Authors' Addresses

   Kireeti Kompella
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US

   Email: kireeti@juniper.net


   Bhupesh Kothari
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US

   Email: bhupesh@juniper.net


   Tom Spencer
   AT&T

   Email: tsiv@att.com



























Kompella, et al.           Expires May 7, 2009                 [Page 26]


Internet-Draft            BGP VPLS Multi-homing            November 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Kompella, et al.           Expires May 7, 2009                 [Page 27]


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