Network Working Group Himanshu Shah Internet Draft Xavier Briard Expiration Date: September 2001 Jim Tsillas Tenor Networks Extensions to MPLS-based Layer 2 VPNs draft-shah-mpls-l2vpn-ext-00.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. 2. Abstract The Provisioning of VPN based on Layer 2 circuits across MPLS-base network has been described in draft-kompella-mpls-l2vpn-02.txt. The draft describes how provider's edge routers distribute configured VPN information amongst themselves. This information is then processed to map layer 2 circuits of customer's edge devices to remote customer devices of the same VPN through MPLS cloud via adjoining provider's edge devices. The proposal requires a priori guestimating of customer's growth needs for the VPN and accordingly over provisioning of a contiguous set of (preferably per platform) MPLS labels. Unfortunately, when the actual needs exceed the already provisioned and advertised labels, incrementing to higher range causes disruptions in ongoing data traffic. This document proposes extension to draft-kompella-mpls-l2vpn-02.txt such that range on provider's edge router can be increased for the MPLS labels without requiring to being contiguous for all the customer edge devices. Also, when the range is increased to accommodate more customer edge devices into the existing VPN, the processing of increased range advertisement does not disturb the ongoing data traffic on existing layer 2 circuits. shah et al. page 1 Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 3. Introduction The service provider's edge (PE) router, which offers layer 2 VPN services are required to configure VPN specific information which includes VPN ID, Customer's Edge ID and a range that denotes the number of customer's edge devices that can be accommodated for this VPN. The range parameter is recommended to be over-provisioned to accommodate future additions of customer sites to the VPN with minimal configuration impact. In addition, if data link is of multi- access in nature for instance frame relay, "range" number of DLCIs must be configured where each DLCI denote a direct connection to remote customer edge device. It is not required that these DLCIs be contiguous within the range. The provider's edge router then allocates a contiguous range of MPLS labels and advertises to its peers; VPN ID, CE ID, CE range and MPLS label base. The remote peer validates the received information and proceeds to update cross-connect forwarding table based on which CE- ID sent the information and what CE-ID is locally configured for the VPN. The receiver calculates "inner label" by offsetting the local CE-ID into the received label base. This "inner label" is then used to send data traffic to the CE through advertising PE router via MPLS tunnels. This process of deriving the label by offsetting CE-ID from base mandates labels to be contiguous. On the one hand, this requirement of contiguousness offers reduction in amount of information that needs to be exchanged amongst PE routers. However, on the other hand disadvantages are two fold. First, because the manner in which these labels are used (LSP hierarchical fashion), the labels are required to be (per platform) global and to obtain a contiguous set of global labels may not always be possible. Secondly, when need exceeds already provisioned range, a new range with yet another whole set of contiguous labels are required. And re-advertising of this new range causes previously programmed cross-connects be removed from forwarding table and re-added with new label information. This document proposes a simple extension to the base document (of Kompella [Mpls]) where an information element is added to the distributed VPN information and an additional processing step to handle this information. 4. Extension to signalling MPLS-Based Layer 2 VPNs In Kompella [Mpls] draft, L2VPN information block is defined which constitute the VPN information. This information is then distributed using either LDP or BGP. shah et al. page 2 Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 A new information element, CE-Base is introduced to allow for advertisement of multiple ranges. A given range is then said to begin and end with associated CE-base and CE-range that is present in the advertisement. The L2VPN FEC element (for LDP) or L2VPN NLRI (for BGP) is then referred to as a set. One or more set of the VPN information elements would then constitute the configured range on the PE router. 4.1 CE-Base CE-base is Customer Edge base information. The base information identifies a VPN for a set of CE identifiers that fall within the CE-base and CE-range. In some sense, the associated MPLS label base is bounded by CE-base and CE-range. The labels are required to be sequential for total of CE-range minus CE-base. User is not required to configure CE-base. Instead, L2VPN software module obtains fragments of label sets, which are contiguous within the fragment. One or more fragments can be obtained to support the configured range. Each fragment is then delineated by CE-base and CE-range that is distributed to PE peers. The L2VPN FEC element for LDP as described in Kompella [Mpls] draft is shown below with added information of CE-base. "In LDP, VPN CE information and its associated label base are carried in a Label Mapping message, distributed in the downstream unsolicited mode described in [LDP]. A new FEC element is defined below to carry all the information corresponding to a VPN CE, except from the label base. The label base is carried in the Label TLV following the FEC TLV. If a FEC element in a FEC TLV encodes Layer 2 VPN information, it MUST be the only FEC element in the FEC TLV." When advertising more than one range that constitutes the configured range, user must generate advertisement for each FEC element with different CE-base information in the FEC TLV. shah et al. page 3 Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 The extended Layer 2 VPN FEC element is depicted in Figure 1 below. Figure 1: L2 VPN FEC Element 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Encaps. Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Flags | Reserved (Must Be Zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE ID | CE Range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE-base | reserved (must be zero) |new +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE Connectivity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs | . ... . . ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Again, following text from the Kompella [Mpls] draft for BGP signaling. "In BGP, the Multiprotocol Extensions [BGP-MP] are used to carry L2-VPN signalling information. [BGP-MP] defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. We introduce a new address family identifier (AFI) for L2-VPN [to be assigned by IANA], a new subsequent address family identifier (SAFI) [to be assigned by IANA], and also a new NLRI format for carrying the individual L2-VPN CE information. This NLRI will be carried in the above-mentioned BGP attributes. This NLRI MUST be accompanied by one or more extended communities. The extended community type is "Layer 2 VPN" (to be assigned by IANA); and the format is :, where is 4 octets in length, and is two octets. All extended communities accompanying one or more Layer 2 VPN NLRIs MUST have the same ." When advertising more than one range that constitutes a configured range, more than one NLRIs are included in a single MP_REACH_NLRI or MP_UNREACH_NLRI BGP attributes. The format of the extended Layer 2 VPN NLRI is as shown in Figure 2 below. shah et al. page 4 Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 Figure 2: BGP NLRI for L2 VPN Information +------------------------------------+ | Length (2 octets) | +------------------------------------+ | Encaps Type (1 octet) | +------------------------------------+ | Control Flags (1 octet) | +------------------------------------+ | Label base (3 octets) | +------------------------------------+ | Reserved (Must Be Zero) (1 octet) | +------------------------------------+ | CE ID (2 octets) | +------------------------------------+ | CE Base (2 octets) | <- new +------------------------------------+ | CE Range (2 octets) | +------------------------------------+ | Variable TLVs (0 to n octets) | | ... | +------------------------------------+ 4.2. Signalled Information The Kompella [Mpls] draft describes the individual information elements that is distributed as part of VPN information. Following sections describes those elements from the base draft with changes where necessary. 4.2.1. Type (LDP only) The Type is L2-VPN (to be decided by IETF Consensus Action). 4.2.2. Length In LDP, the Length is the entire length of the L2 VPN FEC element, including the fixed header and all the sub-TLVs. In BGP, the Length field indicates the length in octets of the L2- VPN address prefix. 4.2.3. Encapsulation Type Identifies the layer 2 encapsulation, e.g., ATM, Frame Relay etc. The following encapsulation types are defined: shah et al. page 5 Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 Value Encapsulation 0 Reserved 1 ATM PDUs (AAL/5) 2 ATM Cells 3 Frame Relay 4 PPP 5 Cisco-HDLC 6 Ethernet VLAN (unswitched) 7 MPLS 4.2.4. Control Flags This is a bit vector, defined as in the following Figure. Figure 3: Control Flags Bit Vector 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Reserved |S| +-+-+-+-+-+-+-+-+ The following bit is defined; the rest MUST be set to zero. Name Bit Meaning S 0 Sequenced delivery of frames is required 4.2.5. Label base (BGP only) The label-base which is to be used for determining the inner label for forwarding packets to the CE identified by CE ID. (Note: LDP carries the label-base in the Label TLV following the FEC TLV.) Note that label base is bounded by CE-base and CE-range parameters. 4.2.6. VPN ID (LDP only) A 32 bit number which uniquely identifies a VPN in a provider's domain. 4.2.7. CE ID A 16 bit number which uniquely identifies a CE in a VPN. 4.2.8 CE Base A 16 bit number which identifies the base of CE ID. shah et al. page 6 Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 4.2.9 CE Range A 16 bit number which describes the range of CE IDs starting from CE-base to which the advertised CE is willing to connect. In particular, a PE receiving an L2 VPN TLV MUST NOT use a label less than or greater than or equal to + ( - - 1) when sending traffic for this VPN to the advertising PE. The CE- Range present in the VPN information does not necessarily represent the total number of CE-Ids that advertising CE is willing to connect. In the case, where multiple number of VPN FEC elements (LDP) or NLRIs (BGP) exist for a VPN, total number of CE-Ids the advertising CE is willing to connect for the VPN is the sum of ( - ) present in each advertised set. These CE-ranges between the sets does not have to be contiguous either. For example, a given VPN contains 50 sites with CE-Ids starting from 0 to 49. However, a particular PE router could be configured with total CE-IDs of 20 with ranges of 0 to 9 and 30 to 39. Such level of flexibility, albeit with additional configuration, is possible. 4.2.10 CE Connectivity (LDP only) A 32-bit number encoding connectivity. If the leftmost bit is 1, the CE is a spoke. The remaining 31 bits encode the CE colors (bit i = 1 means the CE has color i). 4.2.11 Sub-TLVs New sub-TLVs can be introduced as needed. In LDP, the TLV encoding mechanism described in [LDP] must be used. In BGP, TLVs (type takes 1 octet) can be added to extend the information carried in the L2 VPN address prefix. A TLV (type = 1) will be used for carrying VLAN IDs if the encapsulation is VLAN. 4.3 Advantages of using BGP The Kompella [Mpls] draft discusses various advantages of using BGP as the signaling protocol for VPN information distribution as compared to LDP. The new mechanism proposed in this document where VPN information can be distributed in multiple sets bodes well in BGP parlance where each set is an L2VPN NLRI and multiple NLRIs can accompany in a single MP_REACH_NLRI or MP_UNREACH_NLRI attribute. Thus, the number of advertisements can be reduced if all the sets are known at the time of advertisement. shah et al. page 7 Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 5.0. Adding a New Site The first step in adding a new site to a VPN is to pick a new CE ID. If all current members of the VPN are over-provisioned, i.e., their range includes the new CE ID, adding the new site is a purely local task. Otherwise, the sites whose range doesn't include the new CE ID and wish to communicate directly with the new CE must have their ranges increased to incorporate the new CE ID. In the circumstances when the range is increased, PE router does not have to obtain a whole new set of labels that are contiguous from 0 to increased range. Instead, it obtains a small set of labels that covers the difference between the old range and new range and some increment to cover for future growth. This could be obtained in one or more sets. For example, original range configured in the PE router was 50. The service provider now wants to add 4 more sites to this VPN. It would increase the range to 60 with over-provision of 6 more sites. Now lets suppose that PE router could only obtain 2 sets of 5 each contiguous labels. PE router would then generate two L2VPN FEC element, one for each set, with CE-base and CE-range in one set to be 50 and 55 respectively and 55 and 60 in the second set. The next step is ensuring that the new site has the required connectivity (see below). This may require tweaking the connectivity mechanism; however, in several common cases, the only configuration needed is local to the PE to which the CE is attached. The rest of the configuration is a local matter between the new CE and the PE to which it is attached. It bears repeating that the key to making additions easy is over- provisioning. However, what is being over-provisioned is the number of DLCIs/VCIs that connect the CE to the PE. This is a local matter, and generally is not an issue. 5.1. PE Information Exchange When a PE is configured with all the needed information for a CE, it first of all chooses a contiguous set of labels with n labels, where n may or may not be the whole CE's range. In the event that a contiguous set of labels for the entire range could not be obtained, PE may obtain more than one smaller sets where individual set has contiguous labels and the combined sets represent the total range. Call the smallest label in each set the label-base. The PE then advertises each set(for this CE): its Router ID, the VPN ID, the CE ID, CE-base, CE-Range, and the label-base. When one set does not equal to CE's configured range, more than one set are advertised. shah et al. page 8 Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 This is the basic Layer 2 VPN advertisement. This same advertisement is sent to all other PEs. Note that PEs that may not be part of the VPN can receive and keep this information, in case at some future point, a CE connected to the PE joins the VPN. Also, note that PE participating in the VPN must save all the VPN information which may be spread in multiple sets. If the PE-CE connection goes down, or the CE configuration is removed, the above advertisement is withdrawn. 5.1.1 PE Advertisement Processing When a PE receives a Layer 2 VPN advertisement of a given set, it checks if the VPN ID matches any VPN that it is a member of. If not, the PE just stores the advertisement for future use. If VPN membership is verified but the received information set does not include the configured CE-ID, PE must save this information for later use. The simple rule of thumb when processing VPN information in multiple sets, is to match the local CE-ID through each set to find a set where the CE-ID falls within the CE-base and CE-range of the set. The CE-base is than subtracted from CE-ID and used as an offset into the associated label base to derive the "inner label" for send data traffic. Same logic is used with received CE-ID and the local VPN information in the multiple sets to derive the "inner label" to expect on receive data traffic. Lets suppose the advertisement is from PE A for VPN X, CE m with set range S-Rm, set base S-Bm and label base Lm. For each CE that the receiving PE B is connected to that is member of VPN X, PE B does the following. 0) Look up the configuration information associated with the CE. If the encapsulation type for VPN X in the advertisement does not match the configured encapsulation type for VPN X, stop. shah et al. page 9 Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 1) Say the configured CE-ID is k, the configured range is Rk, and the DLCI list is Dk[]. Also, the label base PE B allocated for this CE is in n sets, then set bases are S-B(1-n)k, set ranges are S-R(1-n_k and label bases are L(1-n)k where n is the number of sets. 2) Check if k = m. If so, issue an error: "CE-ID k has been allocated to two CE in VPN X (check CE at PE A)". Stop. 3) Check if S-Bm <= k < S-Rm. The received VPN information for a set does not include the configured CE-ID. Save this information. 4) Look through local 1 to n sets to find the set which contains the CE ID m. Let this set be S-Rjk (Set range j of CE-ID k). If none of the set contains this CE ID m, stop and issue a warning: "Cannot communicate with CE m (PE A) of VPN X: outside range". 5) Look in the appropriate table to see which label will get to PE A. This is the "outer" label, Z. 6) The DLCI that CE-k will use to talk to CE-m is Dk[m]. The "inner" label for sending packets to CE-m is (Lm + (k - S-Bm)). The "inner" label on which to expect packets from CE-m is (Ljk + (m - S-Bjk)). 7) Install a "route" such that packets from CE-k with DLCI Dk[m] will be sent with outer label Z, inner label (Lm + (k - S-Bm)). Also, install a route such that packets received with label (Lnk + (m - S-Bjk)) will be mapped to DLCI Dk[m] and be sent to CE-k. 8) Activate DLCI Dk[m] to the CE. This can be done using LMI. If an advertisement is withdrawn, the appropriate DLCI must be de- activated, and the corresponding routes must be removed from the forwarding table. 5.1.2. Example of PE Advertisment Processing shah et al. page 10 Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 Figure 3: Example Network Topology S0 S3 .............. .............. . . . . . +-----+ . . . . | CE0 |-----------+ . +-----+ . . +-----+ . | . | CE5 | . . . | . +--+--+ . . +-----+ . | . | . . | CE1 |-------+ | .......|...... . +-----+ . | | / . . | | / .............. | | / | | SP Network / .....|...|.............................../..... . | | / . . +-+---+-+ +-------+ / . . | PE0 |-------| P |-- | . . +-+---+-+ +-------+ \ | . . / \ \ +---+---+ . . | -----+ --| PE2 | . . | | +---+---+ . . | +---+---+ / . . | | PE1 | / . . | +---+---+ / . . | \ / . ...|.............|.............../............. | | / | | / | | / S1 | | S2 / .............. | ........|........../...... . . | . | | . . +-----+ . | . +--+--+ +--+--+ . . | CE2 |-----+ . | CE3 | | CE4 | . . +-----+ . . +-----+ +-----+ . . . . . .............. .......................... Consider the example network of Figure 3. Let the VPN connecting S0, S1, S2 and S3 have a VPN id of 1. Suppose PE2 receives an advertisement from PE0 for VPN 1, CE ID 0, CE-base = 4 with CE range R0 = 10 and label base L0 = 1000. Since PE2 is connected to CE4 which is also in VPN 1, PE2 does the following: 0) Look up the configuration information associated with CE4. The advertised encapsulation type matches the configured encapsulation type (both are Frame Relay), so proceed. shah et al. page 11 Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 1) Let's suppose that CE4 has 2 sets. Set 1 with set base (S-B4(1)) = 0, set range (S-R4(1)= 2, label base (L4(1)) = 2000 and set 2 has set base (S-B4(2)) = 2, set range (S-R4(2)) = 10 and label base (L4(2)) = 4000. The configured range R4 is 9, its DLCI list D4[] is [ 107, 209, 265, 301, 414, 555, 654, 777, 888]. 2) CE0 and CE4 have ids 0 and 4 respectively, so step 2 of 5.1.1 is skipped. 3) Since CE4's id is less than received range R0 (= 10) and greater than equal to CE-base = 4, step 3 of 5.1.1 is passed. CE0's id is then matched in local set 1. As it turns out CE 0 is equal to S-B4{1) (= 0) of set 1. Step 4 of 5.1.1 is passed. 4) Look in the appropriate table on PE2 to see which label will get to PE0. Let the label be 10001. 5) The DLCI that CE4 will use to talk to CE0 is D4[0], i.e., 107. The inner label for sending packets to CE0 is (4 - CE-base) equal 0, i.e. 1000. The inner label on which to expect packets from CE0 is (0 - S-B4(1)) equal 0 which is (L4(1) + 0), i.e., 2000. 6) Install a "route" such that packets from CE4 with DLCI 107 will be sent with outer label 10001, inner label 1000. Also, install a route such that packets received with label 2000 will be mapped to DLCI 107 and be sent to CE4. 7) Activate DLCI 107 to CE4. Since CE5 is also attached to PE2, PE2 needs to do processing similar to the above for CE5. Similarly, when PE0 receives an advertis ment from PE2 for VPN1, CE4, with two sets, S-B4(1) = 0, S-R4(1) = 2, L4(1) = 2000 and S- B4(2) = 2, S-R4(2) = 10, L4(2) = 4000. PE0 processes the advertis0ment for CE0 (and CE1, which is also in VPN 1). 0) Look up the configuration information associated with CE0. The advertised encapsulation type matches the configured encapsulation type (both are Frame Relay), so proceed. 1) CE0 has two range sets. S-B0(1) = 0, S-R0(1) = 4 and label base L0(1) = 577. S-B0(2) = 4, S-R0(2) = 10 and label base L0(2) = 1000. Its DLCI list D0[] is [100 - 109]. 2) CE0 and CE4 have ids 0 and 4 respectively, so step 2 of 5.1.1 is skipped. shah et al. page 12 Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 3) CE0's ID is first checked in received set 1. Since CE-ID 0 is greater than equal to S-B4(1) (=0) and is less than S-R4(1)(= 2), label base L4(1) of set 1 is selected. Similarly, received CE-ID 4 is checked against the local set 1. CE-ID 4 is greater than equal to set base S-B0(1) (= 0) but not less than set range S- R0(1) (= 4), set 1 is not selected. Now, CE-ID 4 is checked against local set 2. Since CE-ID 4 is greater than equal to set base S-B0(2) (= 4) and less than set range S-R0(2) (= 10), label base L0(2) of set 2 is selected. 4) Let the outer label to reach PE2 be 9999. 5) The DLCI which CE0 will use to talk to CE4 is D0[4], i.e., 103. The inner label for send packets to CE4 is L4(1) = 2000 + (CE-ID ( = 0) - CE-Base ( = 0) 0), i.e., 2000 + (0 - 0) = 2000. The inner label on which to expect the packets from CE4 is L0(2) = 1000 + CE-ID ( = 4) - CE-Base (= 4), i.e., 1000 + (4 - 4) = 1000. 6) Install a "route" such that packets from CE0 with DLCI 104 will be sent with outer label 9999, inner label 2000. Also, install a route that packets received with label 1000 will be mapped to DLCI 104 and be set to CE0. 7) Activate DLCI 103 to CE0. Note that the inner label of 2000, computed by PE0, for sending packets from CE0 to CE4 is the same as what PE2 computed as the incoming label for receiving packets originated at CE0 and destined to CE4. Similarly, the inner label of 1000, computed by PE0, for receiving packets from CE4 to CE0 is same what PE2 computed as the outgoing label for sending packets originated at CE4 and destined to CE0. 6.0 Generalizing the VPN Topology In the Kompella [Mpls] draft, full mesh and hub and spoke type of VPN topologies is described using the color value and spoke bit in the connectivity field of the distributed VPN information. However, the spoke bit is available only when using the LDP signaling. Same type of VPN topologies can be created when using BGP as signaling mechanism by creative ways of using the CE-Ids. For example, in order to create a hub and spoke type of VPN topologies, "hub" PE routers could be configured with CE-ID of the lowest values and highest range and the "spoke" PE routers with higher CE-IDs and the range of 1 or sum of the "hub" sites. The processing algorithm described above will then have "spoke" PE routers not creating layer 2 circuits among themseleves as the "spoke" CE-Ids would not fall under the received range. shah et al. page 13 Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 It is also possible to create sub-VPN clusters by using CE-ID sub ranges. This would require additional configuration on a per set basis where for each set, set-base and set-range is configured. With such configuration, all those CE-IDs that fall within the configured sets would form connectivity with other. These type of methodologies does not incur any further extensions to the protocol and in fact is the added advantage of the extension proposed in this document. 7. Acknowledgements Some of the text in this document is "borrowed" from the base Kompella draft for completeness. We would like to thank Bill Townsend for reviewing the draft. 8. References [MPLS] Kompella et al., "MPLS based Layer 2 VPNs", draft-kompella- mpls-l2vpn-02.txt, November 2000. 9. Authors Information Himanshu Shah Tenor Networks 100 Nanog Park Acton, MA 01720 hshah@tenornetworks.com Xavier Briard Tenor Networks 100 Nanog Park Acton, MA 01720 xbriard@tenornetworks.com Jim Tsillas Tenor Networks 100 Nanog Park Acton, MA 01720 jtsillas@tenornetworks.com shah et al. page 14