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

Versions: 00 01 02 draft-ietf-l2vpn-vpls-multihoming

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


         Multi-homing in BGP-based Virtual Private LAN Service
              draft-kompella-l2vpn-vpls-multihoming-01.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 January 14, 2009.
















Kompella, et al.        Expires January 14, 2009                [Page 1]


Internet-Draft            BGP VPLS Multi-homing                July 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 . . . . . . . . . . . . . . . . . .  9
       3.4.2.  VPLS Path Selection  . . . . . . . . . . . . . . . . . 10
   4.  Multi-AS VPLS  . . . . . . . . . . . . . . . . . . . . . . . . 12
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18













Kompella, et al.        Expires January 14, 2009                [Page 2]


Internet-Draft            BGP VPLS Multi-homing                July 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 5 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 January 14, 2009                [Page 3]


Internet-Draft            BGP VPLS Multi-homing                July 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 January 14, 2009                [Page 4]


Internet-Draft            BGP VPLS Multi-homing                July 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 January 14, 2009                [Page 5]


Internet-Draft            BGP VPLS Multi-homing                July 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 January 14, 2009                [Page 6]


Internet-Draft            BGP VPLS Multi-homing                July 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.

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 January 14, 2009                [Page 7]


Internet-Draft            BGP VPLS Multi-homing                July 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 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.  A VPLS
   advertisement with a higher VE preference MUST be preferred.

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

3.4.  Designated Forwarder Election

   BGP-based multi-homing for VPLS relies on BGP path selection and VPLS
   path selection.  BGP path selection 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.  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



Kompella, et al.        Expires January 14, 2009                [Page 8]


Internet-Draft            BGP VPLS Multi-homing                July 2008


   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).  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.
   Taken all together, this yields:

           <RD, VE-ID, VBO, VBS,LB; DOM, BNH, CF, VP, LP>

   Note that an advertisement with VE-ID = 0 is invalid.

   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, BNH, CF, VP, LP>

   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.







Kompella, et al.        Expires January 14, 2009                [Page 9]


Internet-Draft            BGP VPLS Multi-homing                July 2008


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,
   VE-IDs and VBOs are the same):

       AD1 = <RD, VE-ID, VBO, VBS1, LB1; DOM, BNH1, CF1:D, VP1, LP1>
       AD2 = <RD, VE-ID, VBO, VBS2, LB2; DOM, BNH2, CF2:D, VP2, LP2>

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

   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 (VP1 == 0) OR (VP2 == 0) continue
       else if (VP1 > VP2) AD1 wins; stop
       else if (VP1 < VP2) AD2 wins; stop
       else continue

   3.  if (LP1 > LP2) AD1 wins; stop;
       else if (LP1 < LP2) AD2 wins; stop;
       else continue

   4.  if (BNH1 < BNH2) AD1 wins; stop;
       else if (BNH1 > BNH2) AD2 wins; stop;
       else AD1 and AD2 are equivalent; BGP will consider this as an
       update

   Note that all other BGP path selection criteria, such as IGP metric,
   MUST be ignored while doing path selection for VPLS advertisements.

3.4.2.  VPLS Path Selection

3.4.2.1.  Bucketization

   An advertisement

            AD = <RD, VE-ID, VBO, VBS, LB; DOM, BNH, CF, VP, LP>

   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.







Kompella, et al.        Expires January 14, 2009               [Page 10]


Internet-Draft            BGP VPLS Multi-homing                July 2008


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, BNH1, CF1:D, VP1, LP1>
       AD2 = <RD, VE-ID, VBO, VBS2, LB2; DOM, BNH2, CF2:D, VP2, LP2>

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

   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 (VP1 == 0) OR (VP2 == 0) continue
       else if (VP1 > VP2) AD1 wins; stop
       else if (VP1 < VP2) AD2 wins; stop
       else continue

   3.  if (LP1 > LP2) AD1 wins; stop;
       else if (LP1 < LP2) AD2 wins; stop;
       else continue

   4.  if (BNH1 < BNH2) AD1 wins; stop;
       else if (BNH1 > BNH2) 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 January 14, 2009               [Page 11]


Internet-Draft            BGP VPLS Multi-homing                July 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.  Consider Figure 4 for inter-AS
   VPLS with multi-homed customer sites.

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

                          Figure 4: Inter-AS VPLS

   A customer has two sites, CE1 and CE2.  CE1 is multi-homed to PE1 and
   PE2 in AS1.  CE2 is multi-homed to PE3 and PE4 in AS2.  After running
   path selection algorithm, all four VPLS PEs must elect the same set
   of designated forwarder for CE1 and CE2.  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.

   In method (b), there is control plane VPLS state on the ASBRs.  As
   explained in (Section 3.4.2) [RFC4761], ASBR1 will send a VPLS 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.  Thus, in method (b), ASBRs
   MUST set the BGP Local Preference in VPLS advertisements to the VE
   preference value, if specified in the NLRIs received from other
   ASBRs.

   In method (c), there is no state of any kind on the ASBRs.  Thus,
   multi-homing operations do not apply to ASBRs in this method.



Kompella, et al.        Expires January 14, 2009               [Page 12]


Internet-Draft            BGP VPLS Multi-homing                July 2008


5.  Security Considerations

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















































Kompella, et al.        Expires January 14, 2009               [Page 13]


Internet-Draft            BGP VPLS Multi-homing                July 2008


6.  IANA Considerations

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
















































Kompella, et al.        Expires January 14, 2009               [Page 14]


Internet-Draft            BGP VPLS Multi-homing                July 2008


7.  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 January 14, 2009               [Page 15]


Internet-Draft            BGP VPLS Multi-homing                July 2008


8.  References

8.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-00 (work in progress),
              November 2007.

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



















Kompella, et al.        Expires January 14, 2009               [Page 16]


Internet-Draft            BGP VPLS Multi-homing                July 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 January 14, 2009               [Page 17]


Internet-Draft            BGP VPLS Multi-homing                July 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 January 14, 2009               [Page 18]


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