Network Working Group Simon Delord Internet Draft Mark Latham Category: Informational Track Telstra Expires: June 2010 Frederic Jounay Tom Nadeau Philippe Niger BT France Telecom Dave McDysan Yuji Kamite Verizon NTT Communications January 08, 2010 MS-PW based L2VPN provisioning, auto-discovery, signaling draft-jounay-delord-l2vpn-ms-pw-provisioning-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/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, 2010. Abstract Service Providers (SPs) have described the requirements to allow them to extend the Pseudowires (PWs) across multiple domains via the use of multi-segment Pseudowires (MS-PWs). Several tools relating to Jounay et al. Expires June, 2010 [Page 1] Internet Draft MS-PW based L2VPN provisioning January 2010 provisioning, auto-discovery and signaling have been developed to allow the dynamic setup of MS-PWs. However there is no end to end view that describes how these tools can be used in carrier networks. This document aims at providing this view by describing the different stages required for an end to end L2VPN service setup relying on MS-PWs. These stages are VPN provisioning, auto-discovery (network and service), signaling and monitoring. Conventions used in this document 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]. Table of Contents 1. Introduction....................................................3 1.1. High-level L2VPN setup procedure..............................4 1.1.1. L2VPN Provisioning..........................................4 1.1.2. L2VPN Auto-discovery........................................4 1.1.3. L2VPN Signaling.............................................5 1.1.4. L2VPN Monitoring............................................5 1.2. Assumptions...................................................5 2. Terminology.....................................................6 3. Provider-Provisioned L2VPN Reference Model......................7 4. AII Addressing Considerations...................................7 4.1. IP addressing reference model.................................8 4.2. Model1: IP Address derived AII addressing plane...............9 4.2.1. N-AII addressing plane......................................9 4.2.2. C-AII addressing plane......................................9 4.3. Model2: Non IP Address derived AII addressing plane..........10 4.4. N-AII addressing plane.......................................10 4.5. C-AII addressing plane.......................................10 5. L2VPN Provisioning.............................................11 5.1. VPWS.........................................................11 5.2. VPLS.........................................................11 6. Auto-Discovery.................................................12 6.1. Network AII Auto-Discovery...................................12 6.1.1. Scope for AII Auto-Discovery...............................12 6.1.2. N-AII Auto-discovery.......................................13 6.1.2.1. N-AII Auto-discovery in the access network...............13 6.1.2.2. N-AII Auto-discovery in the metro/core network...........13 6.2. Service VPN Auto-Discovery...................................14 6.3. Auto-discovery summary.......................................14 7. L2VPN Signaling................................................15 7.1. P2P MS-PW....................................................15 7.2. P2MP MS-PW...................................................16 8. Monitoring.....................................................16 9. Protection.....................................................16 Jounay et al. Expires June, 2010 [Page 2] Internet Draft MS-PW based L2VPN provisioning January 2010 10. Manageability considerations..................................16 11. Backward Compatibility........................................16 12. Security Considerations.......................................16 13. IANA Considerations...........................................16 14. Acknowledgments...............................................16 15. References....................................................16 15.1. Normative References........................................17 15.2. Informative References......................................17 16. Author's Addresses............................................18 Copyright Notice..................................................19 1. Introduction This document provides a framework regarding the different steps required for a L2VPN setup when the end to end architecture relies on the MS-PW construct. It describes how some of the tools currently available can work together to achieve the setup of point to point (P2P), point to multipoint (P2MP) or multipoint to multipoint (MP2MP) L2VPNs over MS-PWs. [RFC4447] defines two different types of Forwarding Equivalent Clas- ses (FEC) called the PWid FEC (type 128) and the Generalised ID (GID) FEC (type 129).The PWid FEC element includes a fixed-length 32-bit value called the PWid that serves as an endpoint identifier. The same PWid value must be configured on the local and remote PE prior to PW setup. The GID FEC element includes TLV fields for attachment individual identifiers (AIIs) that, in conjunction with an attachment group identifier (AGI), serve as PW endpoint identifiers. The use of the GID FEC TLV provides the flexibility to structure AII values to best fit the needs of a particular application or provisioning model. The use of FEC128 for MS-PWs is therefore not considered in this version of the document. [RFC5659] defines two different deployment models, the inter-carrier model and the intra-carrier model. The different architecture scenarios described in this version focus on the intra-carrier model. The structure of this document is therefore described as follows - section 4: AII addressing considerations - section 5: VPN provisioning for P2P, P2MP and MP2MP services - section 6: Auto-discovery - section 7: VPN Signaling for P2P, P2MP and MP2MP L2VPN services - section 8: VPN Monitoring for P2P, P2MP and MP2MP L2VPN services Jounay et al. Expires June, 2010 [Page 3] Internet Draft MS-PW based L2VPN provisioning January 2010 1.1. High-level L2VPN setup procedure To setup any L2VPN service relying on MS-PWs, every service provider will have to go through the four following phases (that usually happen in the following order): - L2VPN provisioning - L2VPN auto-discovery - L2VPN signaling - L2VPN monitoring 1.1.1. L2VPN Provisioning The provisioning phase covers two sub-elements, the provisioning of the network elements and the provisioning of the individual services. The Network element provisioning corresponds to the AII configuration at T-PE(and also S-PE if required). The operator may configure a set of AIIs per T-PE. During service provisioning, the operator selects one or more AIIs from the AII subset and binds it to the VPN to be setup. The service provisioning also includes the endpoints components configuration (either by manual intervention or via NMS)of the VPN (for example a VLAN, a DLCI, a VPI/VCI on a physical interface). The operator then associates this endpoint to a VPN instance. When two Attachment Circuits are to be connected by a MS-PW and use the FEC Type 129, only one of them needs to be provisioned with the remote endpoint identifier ([L2VPN SIG] section 3.1.1.2). A service auto-discovery mechanism would let all endpoints of a VPN advertising in which VPN they participate so the signaling can be initiated automatically (as per [L2VPN Sig] section 3.5). 1.1.2. L2VPN Auto-discovery Auto-discovery covers two sub-elements, the auto-discovery of the network elements and the auto-discovery of the service elements. Network auto-discovery allows network elements to reach each other. In the context of MS-PWs, the network discovery part is the populating by all the network elements (T-PEs and S-PEs) of their own PW AII routing table to allow them to reach any other part of the network. There is no notion of VPN id in this phase since the AII is supposed to be globally unique. Service Discovery allows endpoints participating in a specific VPN to discover each other and eventually automate the signaling between them without manual intervention. The service discovery part is for the T-PEs to announce their AII/AGIs to the rest of the network (all the other S-PEs and T-PEs). Jounay et al. Expires June, 2010 [Page 4] Internet Draft MS-PW based L2VPN provisioning January 2010 1.1.3. L2VPN Signaling Signaling is the last operation to happen before the L2VPN service is up and running. It corresponds to the building of the forwarding plane in the service provider network. In the case of MS-PWs, this will correspond to the T-PEs/S-PEs initiating MS-PWs via an LDP Label Mapping towards the S-PE/T-PEs. 1.1.4. L2VPN Monitoring The aim of L2VPN monitoring is described in [L2VPN OAM FWK]. The main focus of this document is on fault detection, notification as well as L2VPN performance management. The first function is to check the status of the MS-PW and notify the service endpoints of the alarm condition, or error so that a specific action can be taken accordingly to the criticality of the event. The second function is to check the performance against specific parameters on the L2VPN. 1.2. Assumptions This document assumes that the underlying network layer of the interconnecting domains is MPLS (LDP or RSVP-TE based) only (even though it is possible to use L2TPv3, but this is not discussed here). As per [RFC5659] the interconnection of MPLS domains falls into the cases of intra and inter providers which is an administrative partition of the domains. Another type of partition that will be called logical/architectural partition corresponds to the separation of MPLS domains into different functional responsibilities. Typically core networks run an IGP as well as BGP (or even MP-BGP) whereas access networks do not necessarily run either one or the other. That is, the dynamic routing domain is located in the metro/core but it is not always fully transparent across all access networks. Both these types of partitions are complementary, e.g. it is possible to have an inter-provider partition between an access and a metro/core domain (this is the case when a SP uses another SP infrastructure for last mile access) and have an intra-provider case between two core/metro networks (one example being when a single SP decouples the administrative responsibilities per geographical regions or network technologies). Jounay et al. Expires June, 2010 [Page 5] Internet Draft MS-PW based L2VPN provisioning January 2010 Similar tools can therefore be available in different metro/core dom- ains (typically MP-BGP and high-end MPLS capabilities such as FRR) even if these domains do not belong to the same SP, however a restricted set of tools may only be available in access networks. As a consequence, S-PEs as defined in [RFC5659] will either be administrative domain separation points (e.g an ASBR) or architectural domain separation points (e.g the first IP point to run an IGP or MP-BGP or the first IP point to run MPLS FRR for protection mechanisms). There are therefore two sets of challenges for the deployment of L2VPN services relying on MS-PWs that come from either: - Different architectural domains that rely on different set of tools (typically an access to metro interconnection). - Different administrative domains that may or may not rely on a similar/different set of tools. The authors believe that at the moment, the end to end approach that presents most difficulties is an L2VPN service setup across different architectural regions (access to metro/core to access). This will therefore be the focus of this document (as presented in figure 1) but may evolve in future versions. 2. Terminology This document uses terminology described in [RFC4447], [L2VPN SIG],[RFC5659], [SEG PW], [RFC5003]. It also introduces additional terms needed in the context of PW addressing plane. The Exterior AII TLV only contains the prefix and global ID of the T- PE. Such summarization allows the content of the Exterior AII TLV to remain unchanged when an AC is added or removed, thus removing a need to re-advertise the Exterior AII TLV. S-PEs use AII summarization that minimizes the impact on the S-PEs' advertisements into backbone on changes to Exterior AII received in a non-backbone advertisements. C-AII ("a" on figures) C-AII corresponds to the "customer" AII addresses (GID, Prefix, ACID) configured on the access part, i.e. on T-PE. Therefore C-AII correspond to the PW endpoints addresses. N-AII ("A" on figures) N-AII corresponds to the "network" AII addresses (GID, Prefix) configured on the access/metro/core part, i.e. the AII loopback addresses configured on T-PE and S-PE. Jounay et al. Expires June, 2010 [Page 6] Internet Draft MS-PW based L2VPN provisioning January 2010 3. Provider-Provisioned L2VPN Reference Model Figure 1 describes the L2VPN MS-PW Reference Model. The AC are not shown on the Figure but are attached to T-PEs. The proposed model assumes the existence of a T-LDP signaling adjacency between T-PE/S- PE, S-PE/S-PE and/or S-PE/T-PE. |<---Access--->|<-----Metro/Core network----->|<---Access--->| | T-LDP | T-LDP | T-LDP | | | IGP (IS-IS, OSPF) | | V V BGP V V +----+ +----+ +-----+ +----+ +----+ |TPE1+---------+ | | | | | |TPE9| +----+ |S-PE+---------+S-PE | |S-PE+-----------+ | +----+ | 5 | | 7 | | 8 | | | |TPE2+---------+ | | | | | | | | | +----+ | | | | +----+ | | +----+ | | | | | +---------+ | | +---------+ | +----+ |S-PE| | | | | | 6 | | | | | +----+ | | | | | | +----+ |TPE3+---------+ | | | | | |TPE | +----+ | +---------+ | | +-----------+ 10 | +----+ | | | | | | | | |TPE4+---------+ | | | | | | | +----+ +----+ +-----+ +----+ +----+ Figure 1 Provider-Provisioned L2VPN Reference Model In this model, it is assumed that neither MP-BGP nor an IGP are available on the access part of the network. [OSPF AII REACH] and [LDP AII REACH] explain why this could be the case. 4. AII Addressing Considerations [RFC5003] describes the fields that identify PW endpoints called attachment individual identifiers (AII) and the structures that support AII aggregation for improved scalability and VPN auto- discovery. In this document we refer to the PW layer 2 addresses (type 2) defined in [RFC5003]. The AII may be configured via NMS ou CLI. This document considers two types of addressing spaces for MS-PWs the first one called an N-AII related to network elements and another one called the C-AII related to the MS-PW endpoints (or the L2VPN service endpoints). Jounay et al. Expires June, 2010 [Page 7] Internet Draft MS-PW based L2VPN provisioning January 2010 The N-AII will typically be a unique identifier within an administrative domain (or as per RFC5003 recommendation be globally unique) that will identify a specific network element that can establish and maintain MS-PWs; this is similar to the use of an IP loopback address used for management.Note that N-AII may be optional and is only required for specific SP requirements. This differentiation is important when it comes to the auto-discovery phase of the L2VPN setup process. It is possible to automate part or all of the MS-PW addressing space based on whether the SP wants to achieve network and or service endpoints discovery. Another consideration in this section is whether the AII addressing space (AII Prefix field) should be relying on the IP addressing space (IP loopback). Typical reasons for separating the AII and IP addressing schemes are security reasons, inter-domain architecture and service provider policy ([RFC5254] also references some other elements). The main advantage of keeping a PW addressing scheme based on the IP addressing scheme is to release some of the constraints during the provisioning as well as the auto-discovery phases. 4.1. IP addressing reference model +----+ +--------+ | | | | T-PE1 | ip11/xx--- | IP1/32 | | | | +----+ ip10/xx | +----+ | | | | | S-PE5 | T-PE2 | ip12/xx--- | IP5/32| IP2/32 | | | | +----+ +--------+ Figure 2 IP addressing reference model This section is given as an example of a typical IP allocation scheme for an access network. Ip10, 11, 12 are typically the interface IP addresses whereas IP1, IP2 and IP3 are the loopback addresses. One of the AII addressing scheme can rely on the IP addressing scheme. At this step the IP addresses are configured locally on T-PE with sometimes a summarization scheme being combined to it. In Figure 2, ip10/xx is used at S-PE1 for summarizing ip11+ip12. IP1, IP2 and IP5 Jounay et al. Expires June, 2010 [Page 8] Internet Draft MS-PW based L2VPN provisioning January 2010 correspond respectively to the local IP loopback address of T-PE1, T- PE2 and S-PE5. 4.2. Model1: IP Address derived AII addressing plane In this first model, the MS-PW addressing scheme relies on the IP allocation scheme (e.g. IP loopback). 4.2.1. N-AII addressing plane The N-AII configured on S-PE may be used for the Explicit Routing of MS-PWs. The loopback addresses are derived from the IP loopback addresses. Figure 3 uses A1, A3, A5, A6, A7, A8, A9 as N-AII respectively associated to T-PE1, T-PE3, S-PE5, S-PE6, S-PE7, S-PE8 and T-PE9. In this case, An is composed of (ASN, IPn), IPn being the T-PEn IP loopback address. ASN and IPn are encoded in appropriate fields in Section 4.2 following [RFC5003] encoding. Note that the AC ID is equal to 0. The ASN refers to an AS number. +----+ +----+ +----+ +-----+ |TPE1| |S-PE| | | | | | A1 +-----| 5 +---------+ | | | +----+ | | | A5 | |S-PE| |S-PE | |TPE9| +----+ +----+ | 7 +---------+ 8 +-----| A9 | +----+ +----+ | | | | | | |TPE3| |T-PE| | | | | +----+ | A3 +-----+ 6 +---------+ A7 | | A8 | | | | A6 | | | | | +----+ +----+ +----+ +-----+ Figure 3 N-AII addressing plane 4.2.2. C-AII addressing plane +----+ +--------+ | | | | T-PE1 | a1 | | | A1 | | | | +----+ | | +----+ | | | | | S-PE5 | T-PE2 | a2 | | A5 | A2 | a3 | | | +----+ +--------+ Figure 4 C-AII addressing reference model Jounay et al. Expires June, 2010 [Page 9] Internet Draft MS-PW based L2VPN provisioning January 2010 At this step the C-AII addresses are not attached to a physical or virtual port of the T-PE equipment. This operation is part of VPN provisioning. The C-AII scheme corresponds to the AII addresses. These addresses are derived directly from the IP addresses locally configured on T-PE (typically the loopback or management address). Therefore each endpoint to be configured on T-PEs is associated to a different AC ID as follows: e.g. AII (GID, Prefix, ACID) a1: (ASN, IP1, ACID1) a2: (ASN, IP2, ACID1) a3: (ASN, IP2, ACID2) A1: (ASN, IP1) A2: (ASN, IP2) A5: (ASN, IP5) Note that the same ACID can be reused on a different T-PE since it is appended with a different prefix. 4.3. Model2: Non IP Address derived AII addressing plane In this second model, the MS-PW addressing scheme does not rely on the IP allocation scheme. 4.4. N-AII addressing plane In model 2, it is assumed that N-AII are not derived from the provider's IP addressing scheme, e.g. A1 is not derived from the IP loopback address IP1. In this case the provider allocates a unique prefix per T or S-PE. The prefix MUST be unique per ASN. 4.5. C-AII addressing plane The AII addressing plane is distinct from the IP addressing plane. Where prefix1 is the assigned address for N-AII A1, then C-AII addresses are: a1: (ASN, Prefix1, ACID1) a2: (ASN, Prefix2, ACID1) a3: (ASN, Prefix2, ACID2) A1: (ASN, Prefix1) A2: (ASN, Prefix2) A5: (ASN, Prefix5) Jounay et al. Expires June, 2010 [Page 10] Internet Draft MS-PW based L2VPN provisioning January 2010 The fact that C-AIIs configured on T-PE are derived from N-AII is to derive benefit of the AII address aggregation. Therefore as explained later for the AII auto-discovery step the C-AII subnet is implicitly represented by the only N-AII, i.e. the Prefix field. 5. L2VPN Provisioning 5.1. VPWS As discussed section 1.1, the FEC129 single sided provisioning allows the SP when two Attachment circuits are to be connected by a PW, to provision both ends and only one of them with the name of the other remote end (which of course is the local name of the other Attachment Circuit) as described in [L2VPN SIG] section 3.1.1.2. It is recommended to let the SP enter or not an AGI value corresponding to a VPN-id. This field is not compulsory since the couple (SAII, TAII) is unique. However for some security purposes the SP may choose to use the AGI for the VPN-id definition. In that case the VPN-id must be provisioned on the both endpoints T-PEs. The T-PE must associate the VPN-id with one of its local C-AII configured. The couple (VPN-id, AII) corresponds to the MS-PW endpoint and needs to be attached to a physical or virtual port (VID, etc...). As described above, if one of the remote ends is provisioned with the other end of the service, then there is no need for an auto-discovery mechanism. Otherwise, if none of the endpoints knows the remote end then service auto-discovery will need to be part of the setup process. 5.2. VPLS [L2VPN SIG] describes in section 3.2.1 the VPLS provisioning based on the VPN-id, a globally unique identifier. The VPN-id must be provisioned on each T-PE belonging to the VPN. The T-PE must associate the VPN-id to one of its locally configured C-AII. The selected C-AII is directly related to a Virtual Switching Instance dedicated to the VPN. Note that in VPLS the same C-AII selected at a T-PE may be used to setup as many PWs as remote T-PEs belonging to the VPN. This case is not defined in RFC4762 since it tackles flat VPLS. The use of non- null TAII and SAII is mainly required for D-VPLS (Distributed VPLS - when a VSI attaches to one or more MS-PWs) when it is desired to setup MS-PW in an optimized routing way. Jounay et al. Expires June, 2010 [Page 11] Internet Draft MS-PW based L2VPN provisioning January 2010 T-PE1 +-----------+ | ... ===== .-----. =======T-PE2 | /VSI\...a1=====/ S-PEs \=======T-PE3 | \.../VPNid=====\ cloud /=======T-PE4 | ===== .-----. =======T-PE4 +-----------+ Figure 5: VSI - C-AII attachment The same comment as in the previous section applies here. In order to avoid provisioning at half of the T-PEs the remote endpoints of all the other T-PEs, a service auto-discovery mechanism is required. Such a mechanism is described in section 3.5 of [L2VPN SIG], however the procedure and addressing scheme are conflicting with the procedure described in [DYN MS-PW] and addressing scheme defined in [RFC5003]. 6. Auto-Discovery Auto-discovery covers two sub-elements, the auto-discovery of the network elements (the N-AII) and the auto-discovery of the service elements (the C-AIIs and AGIs). If we apply these 2 notions to the concept of MS-PWs, the network discovery part will be the populating by all the network elements (T-PEs and S-PEs) of their own PW AII routing table to allow them to reach any other part of the network (there is no notion of VPN id in this phase since the AII is supposed to be "globally unique"), the service discovery part will be for the T-PEs to announce their AII/AGIs to the rest of the network (all the other S-PEs and T-PEs). 6.1. Network AII Auto-Discovery 6.1.1. Scope for AII Auto-Discovery The AII auto-discovery is only required for model 2 (non IP derived), since model 1 (IP derived) assumes a direct 1:1 relationship between local IP address and AII address. In model 1 an IP routing lookup is sufficient to select the next hop PE (the IP address is retrieved from the TAII indicated in the FEC129 advertised in the LDP Label Mapping message). Since C-AII is assumed to be derived from N-AII, only the N-AII configured on T-PE must be known in the PW routing table of S-PEs. This is done using summarized Type 2 AIIs so that a separate advertisement is not required to every AC. C-AIIs are summarized using the aggregation rules for AII Type 2 described in [RFC5003]. Therefore only N-AII configured on the T-PEs need to be advertised in the metro/core network. Jounay et al. Expires June, 2010 [Page 12] Internet Draft MS-PW based L2VPN provisioning January 2010 Referring to Figure 4 the set of C-AII (a2, a3) is summarized to A2. Consequently S-PE5 only advertises A2. The N-AII auto-discovery is only required for the model 2 since the AII addressing scheme is assumed to be totally distinct from the IP layer. 6.1.2. N-AII Auto-discovery 6.1.2.1. N-AII Auto-discovery in the access network This document is limited to access networks using IP/MPLS as their access technology and using MS-PW to support L2 services (as per [RFC5254]). The aim here is for the T-PE to announce to its directly connected S- PE(s) the set AII which have been configured via CLI or NMS. As explained above the set of C-AII is represented by the relevant N- AII. T-PE may be configured with one or several default gateway in case of dual-homing scenario. The attached S-PE needs a mechanism to populate its AII PW routing table towards the access. Where neither IGP nor BGP are available on the access part, it is recommended to use [LDP AII REACH] to maintain dynamically the S-PE PW routing table. Where IGP is extended to the T-PE either [OSPF AII REACH] or [LDP AII REACH] may be used. Another alternative would be to configure statically T-PE AII routes on the S-PE, and inject them as Network AII's via IGP/BGP inside the metro/core domain. Other alternatives may also be carried out. 6.1.2.2. N-AII Auto-discovery in the metro/core network N-AII configured on T-PEs In the MPLS network the S-PE at the edge of both the access and the metro/core networks must advertise the set of C-AII configured on T- PEs. For consistency with the IP routing scheme managed by the SP, the T- PE N-AII may be relayed in the metro/core network via BGP by using the specific NLRI. [OSPF AII REACH] may also be used. N-AII configured on S-PEs A method is required to advertise the N-AII configured on each S-PE. For consistency with the IP routing scheme, it is recommended to use [OSPF AII REACH] (IS-IS ext. not yet defined). Jounay et al. Expires June, 2010 [Page 13] Internet Draft MS-PW based L2VPN provisioning January 2010 6.2. Service VPN Auto-Discovery This step consists in informing each T-PE about the remote T-PEs belonging to the same VPN. As explained in the section 6.1, the presence of VPN-id may not be necessary for VPWS. In that case the SP just has to provision the FEC associated to the VPWS. Note that the PW endpoints at the both sides must be attached to a physical or a logical port, so it is still required to provision this attachment. The following section describes the commonalities in terms of VPN auto-discovery for VPWS and VPLS. It is proposed to advertise the tuple (AGI,AII) identifying the VPN on a particular T-PE via different auto-discovery protocols. In case BGP is not available on the access part, it is recommended that the access T-PE informs its VPN membership via [LDP L2VPN AD]. This would require an extension to what is currently proposed in the draft as its scope is limited to N-AII advertisement only. The S-PE receives the VPN information and is in charge to relay it to other S-PEs up to the remote T-PE. The S-PEs do not need to retrieve any VPN information, they only maintain a PW routing information based on AII addresses which have been previously filled during the AII auto-discovery step. It is recommended to relay the VPN information in the metro/core network via BGP as described in section 3.2.2 of [L2VPN SIG]. Note that this auto-discovery step is particularly useful for VPLS when a new site is added to a VPN as it avoids having to provision on a specific T-PE all the remote identifiers of all other T-PEs belonging to the same L2VPN. 6.3. Auto-discovery summary +----------------------------------------------------------------+ | Addressing | Network Discovery | Service Discovery | | Scheme | (N-AII) | (C-AII) | | |-------------------------|---------------- --------| | | T-PE | S-PE | S-PE | T-PE | S-PE | S-PE | | | | (no BGP | (BGP & | |(no BGP | (BGP & | | | | but IGP)|IGP av.)| | but IGP)|IGP av.)| |------------|-------------------------|------|---------|--------| | Model1 | | via | via | via | | IP Based | NOT NEEDED | LDP | IGP | MP-BGP | | | | | | | |------------|-------------------------|------|---------|--------| | Model2 | | | | | | | | Non IP | via | via | via | via | via | via | | Based | LDP | IGP | MP-BGP | LDP | IGP | MP-BGP | Jounay et al. Expires June, 2010 [Page 14] Internet Draft MS-PW based L2VPN provisioning January 2010 | | | | | | | | +----------------------------------------------------------------+ Table 1: Auto-discovery mechanisms for N-AII and C-AII/AGI 7. L2VPN Signaling The signaling MUST comply with the procedures defined in [RFC5659] and [DYN MS-PW] for services relying on MS-PWs and [LDP P2MP MS-PW] for services relying on P2MP MS-PWs. 7.1. P2P MS-PW S-PEs are assumed to be transparent to the VPN information (VPN-id) and only base their processing (basically which hop to reach next) on the C-AII, not the double C-AII & AGI. The procedure MUST follow the signaling procedure defined in [RFC5659] and [DYN MS-PW]. The MS-PW signaling is initiated at one of the MS-PW endpoints, i.e. on a T-PE. The signaling occurs after the T-PE is manually configured or dynamically discovers via an auto-discovery mechanism the remote C-AII belonging to the VPN. The T-PE initiates an LDP Label Mapping message to the S-PE selected to join the TAII. The SAII is composed of the local C-AII and the VPN-Id (or AGI) and the TAII corresponds to the C-AII retrieved from the auto-discovery procedure corresponding to the C-AII configured on the remote T-PE and attached also to the VPN. When an S-PE receives the Label Mapping message, it checks if the TAII contained in the FEC129 has a valid entry in its AII PW routing table. If no matching is found an error procedure must be applied as defined in [SEG PW]. Based on the result of the matching the S-PE validates as well its PW-to-label bindings. This ends the PW setup between the S-PE and T- PE. In turn the S-PE selects the "next hops" to reach the TAII (This selection may be constraint-based, e.g. capacity) . A next hop can be another S-PE or directly the remote T-PE. The S-PE sends one Label Mapping message to the selected next hop with the same FEC so far used. This process is repeated hop by hop until the MS-PW for this direction is completely built. When receiving a Label Mapping message T-PE checks that the TAII and the AGI included in the FEC129 are locally configured. If this is the case, the T-PE validates its forwarding plane by acknowledging the PW-to-label binding for the last segment of the MS- PW in this direction. Jounay et al. Expires June, 2010 [Page 15] Internet Draft MS-PW based L2VPN provisioning January 2010 Finally, the remote T-PE carries on the process by sending a Label Mapping message in the reverse direction as per [RFC4447]. 7.2. P2MP MS-PW In the case where a P2MP topology is required (use cases can be found in [P2MP PW REQ]), each T-PE MUST be capable to setup a P2MP MS-PW. The mechanism described for P2P MS-PW may apply for P2MP MS-PW by considering either [LDP P2MP MS-PW]. Indeed the T-PE receiving the VPN information from the remote T-PE may act as the root T-PE in the [LDP P2MP PW] case or as a leaf T-PE in the [LDP P2MP MS-PW]. This section will be completed in a future version. 8. Monitoring This section will be completed in a next version, however all mechanisms deployed here MUST comply with [L2VPN OAM FWK]. 9. Protection This section will be completed in a future version. Discuss implications of BGP autodiscovery and reconvergence times. 10. Manageability considerations This section will be added in a future version. 11. Backward Compatibility This section will be added in a future version. 12. Security Considerations This section will be added in a future version. 13. IANA Considerations This draft does not define any new protocol element, and hence does not require any IANA action. 14. Acknowledgments This section will be added in a future version. 15. References Jounay et al. Expires June, 2010 [Page 16] Internet Draft MS-PW based L2VPN provisioning January 2010 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997. [RFC4447] El-Aawar, N., Heron, G., Martini, L., Smith, T., Rosen, E., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", April 2006 [RFC5254] Bitar, N., Bocci, M., and Martini, L., "Requirements for inter domain Pseudo-Wires", October 2006 [RFC5659] Bocci, M., and Bryant, S.,T., " An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge", October 2009 [RFC5003] A Mets, et al., "AII Types for Aggregation", September 2007 15.2. Informative References [L2VPN SIG] Rosen, et al. "Provisioning, Auto-discovery, and Signaling in L2VPNs", Internet Draft, draft-ietf-l2vpn- signaling-08.txt, May 2006 [SEG PW] Martini et al, "Segmented Pseudo Wire", Internet Draft, draft-ietf-pwe3-segmented-pw-13.txt, August 2009 [DYN MS-PW] Balus, F., Bocci, M., Martini, L., "Dynamic Placement of Multi Segment Pseudo Wires", Internet Draft, draft-ietf- pwe3-dynamic-ms-pw-10.txt, October 2009 [LDP AII REACH] Delord, S., Jounay, F., Niger, P. "LDP extension for AII reachability", Internet Draft, draft-ietf- delord-jounay-pwe3-ldp-aii-reachability-00.txt, July 2007 [LDP L2VPN AD] Delord, S., Stein, Y., "LDP-based Auto-discovery for L2 Services", Internet Draft, draft-stein-ldp- auto-00.txt, July 2005 [OSPF AII REACH] Dolganow et al., "OSPF Extensions for Dynamic Multi-segment Pseudo Wires", Internet Draft, draft- ietf-dolganow-pwe3-ospf-ms-pw-ext-00.txt, February 2007 [P2MP PW REQ] Jounay, et al "Requirements for Point to Multipoint Pseudowire", Internet Draft, July 2009. [L2VPN OAM FWK] Sajassi, Mohan "L2VPN OAM Framework". Jounay et al. Expires June, 2010 [Page 17] Internet Draft MS-PW based L2VPN provisioning January 2010 [LDP P2MP MS-PW] Jounay, F., "LDP Extensions for Leaf-initiated Point-to-Multipoint Pseudowire", Internet Draft, draft-jounay-pwe3-leaf-initiated-p2mp-pw-00.txt, January 2007 16. Author's Addresses Frederic Jounay France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: frederic.jounay@orange-ftgroup.com Philippe Niger France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: philippe.niger@orange-ftgroup.com Simon Delord Telstra 242 Exhibition Street Melbourne, VIC, 3000, Australia E-mail: simon.a.delord@team.telstra.com Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421 Japan Email: y.kamite@ntt.com Mark Latham Telstra Corporation Limited 242 Exhibition Street Melbourne, VIC, 3000, Australia E-mail : mark.latham@team.telstra.com Thomas D. Nadeau (editor) BT BT Centre 81 Newgate Street London EC1A 7AJ United Kingdom Email: thomas.nadeau@bt.com Dave McDysan Verizon Jounay et al. Expires June, 2010 [Page 18] Internet Draft MS-PW based L2VPN provisioning January 2010 22001 Loudoun County PKWY Ashburn, VA 20147 Phone: +1 707-886-1891 Email: dave.mcdysan@verizon.com Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Jounay et al. Expires June, 2010 [Page 19]