Network Working Group Simon Delord Internet Draft Uecomm Category: Standards Track Expires: December 2008 Frederic Jounay Philippe Niger Yaakov(J) Stein France Telecom RAD Data Communications Matthew Bocci Cao Wei Mustapha Assaoui Huawei Alcatel-Lucent July 6, 2008 LDP extension for AII reachability draft-delord-jounay-pwe3-ldp-aii-reachability-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. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The dynamic End-to-End Multisegment pseudowire setup requires PEs to maintain a pseudowire routing table when using FEC129. There is therefore a requirement for automatic Attachment Individual Identifiers discovery. Two mechanisms already exist, a BGP based solution and an IGP based one. Here we define a third solution relying on LDP. It allows for automatic discovery of the Attachment Individual Identifiers provsionned on a PE when this node does not Delord et al. Expires December 25, 2008 [Page 1] Internet Draft LDP extension for AII reachability December 2008 run BGP or IGP. The mechanism described here only runs on the T-LDP (Targeted LDP) session between the T-PE and S-PE, but not on any other LDP session which may exist for the tunnels. The T-PE advertises its locally attached AIIs only for the S-PE to build its PW routing table (the S-PE does not propagate this information further via this mechanism). The mechanism described here is intended to complement other existing autodiscovery and routing mechanisms already described with BGP and OSPF. 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....................................................2 2. Scope and Access Network Considerations.........................3 2.1. Scope of this document........................................3 2.2. Specificity of AII PW routing table lookup for access networks4 3. LDP Extension...................................................5 4. Elements of Procedure...........................................7 4.1. High Level Procedure..........................................7 4.2. PW-AII Address Message Procedures.............................7 5. Security Considerations.........................................7 6. IANA Considerations.............................................7 7. Acknowledgments.................................................7 8. References......................................................8 8.1. Normative References..........................................8 8.2. Informative References........................................8 1. Introduction This document describes procedures for PEs to populate their Pseudowire Attachment Individual Identifiers (PW AII) routing tables via Label Distribution Protocol (LDP). It is mainly targeted at MultiSegment Pseudowire (MS-PW) applications. The dynamic End-to-End MS-PW setup requires PEs to maintain a PW routing table when using FEC129. The procedure addresses MS-PW architectures where a T-PE does not (for whatever reason) run either an Interior Gateway Protocol (IGP) or Multi-Protocol Border Gateway Protocol (MP-BGP). The mechanism described here is intended to complement other existing autodiscovery mechanisms already described in [BGP AD] and [OSPF MS-PW]. The need for MS-PWs is presented in [MS-PW REQ]. To allow for minimal manual intervention/configuration, FEC129 needs to be used as per [MS-PW] and [DYN MS-PW]. Delord et al. Expires December 25, 2008 [Page 2] Internet Draft LDP extension for AII reachability December 2008 [RFC5003] describes the fields that identify pseudowire endpoints called attachment individual identifiers (AII) and the structures that support AII aggregation for improved scalability and VPN autodiscovery. [BGP AD] specifies a number of L2VPN provisioning models and discusses the distribution of the pseudowires identifiers by the discovery process, when discovery is based on the Border Gateway Protocol (BGP). [OSPF MS-PW] is also another way of enabling the automatic routing of MS-PWs across an OSPF domain when MP-BGP is not / cannot be used (typically when MPLS gets extended into access networks as this is described in section 2 of [OSPF MS-PW]). 2. Scope and Access Network Considerations 2.1. Scope of this document There is a requirement for automatic AII discovery, two mechanisms already exist, a BGP based solution and an IGP based one. Here we define a third solution relying on LDP. It allows for automatic discovery of the Attachment Individual Identifiers provisionned on a PE when this node does not run BGP or IGP. Similarly to IP addressing, the PW-AII addresses MUST be configured on the PEs (either via a manual process, NMS and/or another protocol like DHCP) before the process described in this document can take place. Even though this document does not limit the scope of the proposed protocol extension, one important application is for its use in access networks using IP/MPLS as their access technology and using MS-PW to support L2 services (as per [MS-PW REQ]). MP-BGP or an IGP are not available on this part of the network (the following section describes why this could occur in a Service Provider network). |<---------PW1---------><-------PW2----><------PW3----------->| +----+ +----+ +----+ +----+ |TPE1+--------------+SPE1+-----------+SPE2+---------------+TPE2| +----+ +----+ +----+ +----+ <-static-IP-routing--><---OSPF/MP-BGP-available----------> Figure 1 MS-PW Use Case Figure 1 describes a typical use case where TPE1 and TPE2 need to establish one or several MS-PW between them. A MS-PW will be composed of at least two PWs (PW1 between TPE1 and SPE1, PW2 between SPE1 and SPE2 and PW3 between SPE2 and TPE2). However TPE1 is not running either an IGP or MP-BGP and only has one static default route and a T-LDP session towards SPE1. SPE1, SPE2 and TPE2 are running OSPF and/or MP-BGP. Delord et al. Expires December 25, 2008 [Page 3] Internet Draft LDP extension for AII reachability December 2008 The aim here is for T-PE1 to announce to the S-PE(s) with which it has a T-LDP session (there may be more than one S-PE) its AII, so that the S-PE(s) can populate their AII PW routing table. The AIIs locally defined on the T-PE are only advertised on the T- LDP session between the T-PE and S-PE, but not on any LDP session which may exist for the tunnels. Therefore, any P router that would receive the proposed message should silently discard it. This document does not presuppose any specific constraint on the AII PW addressing space (i.e it does not require the AII PW addressing space to be a subset of the IP addressing space, the following section describes why this may occur in a Service Provider network). Therefore, this document does not define a routing protocol but rather a "reachability" by which a T-PE advertises its AII to an S- PE. Reciprocally, this draft does not preclude an S-PE to do the same towards a T-PE, but this is not described in the current document. If this mechanism is allowed, in order to avoid any routing loop, a PE MUST NOT readvertise an AII back to the PE that originated that AII. Finally, this draft does not cover the dual-homing case, which may be covered in a later version. 2.2. Specificity of AII PW routing table lookup for access networks [DYN MS-PW] describes in section 7.1 the different rules for AII PW routing table Lookup aggregation. It states the possibility of determining the next signaling hop for a segment of the pseudo wire, via a fixed route (static route and typically a "default route"). In the case of MPLS enabled access networks, an S-PE (typically a DSLAM) will aggregate up to a few thousands devices that may require several Pseudowires (or "services") on each of those devices. For different reasons (one being that a Service Provider may not want to reengineer its metro/access architecture by extending its IGP or inserting MP-BGP further down in the access network), these devices do not require either an IGP or MP-BGP to be integrated into the network but they all require basic LDP functionalities to setup Pseudowires. They can also be configured with one or two default static routes as described in [DYN MS-PW], however on the S-PE side, the provisioning required becomes increasingly complex. Furthermore, the closer to the end node, it is quite possible that some Pseudowires be setup, removed or changed (like a bandwidth upgrade) in a short timeframe. Therefore, there is a need for a mechanism that will alleviate the provisioning burden on the S- PE(s). It is also intended in this document that the proposed mechanism can co-exist and work in cunjunction with other autodiscovery mechanisms already proposed ([BGP AD] and [OSPF MS-PW]) and be used only when those mechanisms are not available. This document does not presuppose any type of addressing for the AII PW layer. It is obviously possible for an AII numbering scheme that uses the IP loopback/LDP Router ID to be able to build an AII PW routing table based on this information, however, for several reasons (security, overlapping space, service provider policy) these Delord et al. Expires December 25, 2008 [Page 4] Internet Draft LDP extension for AII reachability December 2008 two addressing space do not necessarily match (this is also specified in [RFC5003] section 3.2 "Note that it is not required that the 32-bit prefix have any association with the IPv4 address space used in the provider's IGP or BGP for IP reachability"). One application requiring a distinct PW AII addressing space compared to the IP addressing space, would be the dual-homing of T- PEs where the same AII would need to be reached by two different paths irrespective of the IP loopback address of the T-PE (there may not be 2 equal cost paths from an IP perspective). The prefix in the AII is not assumed to be the same as the IP address used for the T- LDP session terminating on the T-PE. 3. LDP Extension In the case described in this document, we assume LDP sessions between the T-PE and related S-PEs. A new Address Family type called AII address family (TBA) is defined for the Adress-List TLV carried in LDP Address and Address Withdraw messages. It allows LDP peers to advertise directly attached AIIs, as part of an LDP Address Message and to withdraw directly attached AIIs as part of an LDP Address Withdraw Message. The Address List TLV contains one or more addresses, each to signal a specific fully qualified AII. When a T-PE needs to advertise a new AII to an S-PE, it sends an LDP Address Message containing the AII address to all the S-PEs with which it maintains LDP sessions. When a T-PE needs to withdraw an AII, it sends an LDP Address Withdraw Message containing the AII address to all S-PEs with which it maintains LDP sessions. The Address-List TLV is defined in [RFC5036]. It includes a set of addresses. It has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Address List (0x0101) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Addresses | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Family Two octet quantity containing a value that encodes the addresses Delord et al. Expires December 25, 2008 [Page 5] Internet Draft LDP extension for AII reachability December 2008 contained in the Addresses field. Addresses A list of addresses from the specified Address Family. The encoding of the individual addresses depends on the Address Family. Two address families are defined in [RFC5036], IPv4 and IPv6. Here we define a new address family type, the AII Address, to be assigned by IANA. The format of an AII address is defined in [RFC5003]. Following is the format of the AII address: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global ID (contd.) | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Prefix (contd.) | AC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Global ID = This is a 4 octet field containing a value that is unique to the provider. Prefix = The 32-bit prefix is a value assigned by the provider or it can be automatically derived from the PE's /32 IPv4 loopback address. Attachment Circuit (AC) ID = This is a fixed length four octet field used to further refine identification of an attachment circuit on the PE. The inclusion of the AC ID is used to identify individual attachment circuits that share a common prefix. 4. Elements of Procedure 4.1 High Level Procedure [RFC5036] defines the procedures by which LSRs maintain and exchange label information via LDP. These procedures are Peer Discovery, Session Management Adjacency, Label Distribution and Notification of errors and advisory information. This document does not change any of the standard LDP procedures, it only adds the AII address family type for the Adress-List TLV carried in LDP Address and Address Withdraw messages. This means that any issue on the LDP Session and Adjacency Maintenance are as per [RFC5036] Sections 2.5.5 and 2.5.6. Delord et al. Expires December 25, 2008 [Page 6] Internet Draft LDP extension for AII reachability December 2008 4.2 PW-AII Address Message Procedures The behaviour described here matches [RFC5036] Sections "3.5.5.1" and "3.5.6.1.". In order for a T-PE to begin advertising its locally attached AIIs to its S-PEs, the T-PE must know the address(es) of the remote S-PE(s) and already have a T-LDP with each one of those. This information may have been configured on the T-PE, or it may have been learned dynamically via some autodiscovery procedure. Upon provisioning on the T-PE of one or more specific AII(s) (fully qualified), the T-PE will generate an Address Message including its locally attached AII address(es) to all the S-PEs with which it maintains T-LDP sessions. The T-PE MUST only advertise its AIIs over its T-LDP sessions towards the other S-PEs. An S-PE that receives an Address Message with an AII address uses the addresses it learns to maintain its AII routing table for this specific T-PE by installing them in its PW routing table. The S-PE MUST NOT pass on T-LDP messages containing the address TLV to any other LSR. Similarly, an LSR that would receive such a message, without being an S-PE for this particular T-PE will silently ignore the message. Whenever an LSR "activates" a new AII, it should advertise the new address with an Address message. Whenever an LSR "de-activates" a previously advertised AII, it should withdraw the address with an Address Withdraw message. If an LSR (S-PE/T-PE) does not support the Address Family specified in the Address List TLV, it should send an "Unsupported Address Family" Notification to its LDP peer to signal an error and abort processing the message. An LSR (S-PE/T-PE) may re-advertise an address that it has previously advertised without explicitly withdrawing the address. If the receiver already has address binding , it SHOULD take no further action. An LSR may withdraw an address without having previously advertised it. If the receiver has no address binding, it SHOULD take no further action. 5. Security Considerations TBD Delord et al. Expires December 25, 2008 [Page 7] Internet Draft LDP extension for AII reachability December 2008 6. IANA Considerations 7. Acknowledgments The authors would like to thank Florin Balus, Wim Henderickx, Luca Martini, Jean-Louis Le Roux, Ed Wong and Raymond Key for their valuable comments and suggestions. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997. [RFC5234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., Thomas, B., "LDP Specification", January 2001. [RFC5003] Chris Metz et. al., "AII Types for Aggregation", February 2007. 8.2. Informative References [MS-PW] Martini et al., "Segmented Pseudo Wire", Internet Draft, draft-ietf-pwe3-segmented-pw-08.txt, November 2007 [DYN MS-PW] Bocci, M., Martini, L., "Dynamic placement of Multi Segment Pseudo Wires", Internet Draft, draft-ietf- pwe3-dynamic-ms-pw-06.txt, November 2007 [BGP AD] E. Rosen et. al., "Provisioning, Autodiscovery, and Signaling in L2VPNs", draft-ietf-l2vpn-signaling- 08.txt, May 2006 [OSPF MS-PW] M. Bocci et. al., "OSPF Extensions for Dynamic Multi- segment Pseudo Wires", draft-dolganow-pwe3-ospf-ms-pw-ext-02.txt, November 2007 [MS-PW REQ] Bitar, N., Bocci, M., and Martini, L., "Requirements for inter domain Pseudo-Wires", Internet Draft, draft-ietf-pwe3-ms-pw- requirements-07.txt, December 2007 Delord et al. Expires December 25, 2008 [Page 8] Internet Draft LDP extension for AII reachability December 2008 Author's Addresses Simon Delord Uecomm 8/658 Church St Richmond VIC 3121 Australia Email: sdelord@uecomm.com.au 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 Mustapha Aissaoui Alcatel-Lucent 600 March Road Kanata ON, Canada e-mail: mustapha.aissaoui@alcatel-lucent.com Matthew Bocci Alcatel-Lucent, Voyager Place Shoppenhangers Road Maidenhead Berks, UK e-mail: matthew.bocci@alcatel-lucent.co.uk Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719, Israel EMail: yaakov_s@rad.com Cao Wei Huawei Technologies Co., Ltd. Huawei Bld., No.3 Xinxi Rd. Shang-Di Information Industry Base Hai-Dian Distinct, Beijing 100085 China Email: caowayne@huawei.com Delord et al. Expires December 25, 2008 [Page 9] Internet Draft LDP extension for AII reachability December 2008 Intellectual Property Statement 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Delord et al. Expires June 22, 2008 [Page 10]