idnits 2.17.1 draft-delord-jounay-pwe3-ldp-aii-reachability-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 27. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 478. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 179 has weird spacing: '...ed into the n...' == Line 204 has weird spacing: '...part of an L...' == Line 245 has weird spacing: '...chieved by u...' == Line 247 has weird spacing: '...ability adve...' == Line 281 has weird spacing: '...ixes to its ...' == (1 more instance...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 20, 2008) is 5697 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-09 == Outdated reference: A later version (-22) exists of draft-ietf-pwe3-dynamic-ms-pw-08 == Outdated reference: A later version (-03) exists of draft-dolganow-pwe3-ospf-ms-pw-ext-02 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-ldp-capabilities-02 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft Simon Delord 4 Category: Standard Track Uecomm 5 Expires: March 2009 6 Frederic Jounay 7 Yaakov(J) Stein Philippe Niger 8 RAD Data Communications France Telecom 10 Cao Wei Matthew Bocci 11 Huawei Mustapha Aissaoui 12 Alcatel-Lucent 14 Luca Martini 15 Cisco Systems Inc. 17 September 20, 2008 19 LDP extensions for AII reachability 20 draft-delord-jounay-pwe3-ldp-aii-reachability-02.txt 22 Status of this Memo 24 By submitting this Internet-Draft, each author represents that any 25 applicable patent or other IPR claims of which he or she is aware 26 have been or will be disclosed, and any of which he or she becomes 27 aware will be disclosed, in accordance with Section 6 of BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that other 31 groups may also distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on March 20, 2009. 46 Abstract 48 The dynamic End-to-End Multisegment pseudowire setup requires PEs to 49 maintain a pseudowire routing table when using FEC129. There is a 50 requirement to automatically advertise Attachment Individual 51 Identifiers to enable the pseudowire routing tables to be populated. 52 Two mechanisms already exist, a BGP reachability information 53 distribution mechanism and an IGP based one. Here we define a third 54 solution relying on LDP. It allows for automatic advertisement of the 55 Attachment Individual Identifier prefixes provisioned on a T-PE when 56 this node does not run BGP or IGP. The mechanism described here runs 57 on the T-LDP (Targeted LDP) session between the T-PE and S-PE, and 58 is intended to complement existing PW routing mechanisms using BGP or 59 OSPF. 61 Conventions used in this document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [RFC2119]. 67 Table of Contents 69 1. Introduction....................................................3 70 2. Scope and Applicability.........................................3 71 2.1. Scope.........................................................3 72 2.2. Applicability.................................................4 73 3. LDP Extensions..................................................5 74 3.1. LDP AII Address Family Type...................................5 75 3.2. LDP AII Reachability Capability Advertisement.................6 76 4. AII Reachability Advertisement Procedures.......................6 77 4.1. Detailed AII Address Message Procedures.......................6 78 4.1.1. T-PE Procedures.............................................7 79 4.1.2. S-PE Procedures.............................................7 80 5. Security Considerations.........................................7 81 6. IANA Considerations.............................................7 82 6.1. Address Family Type...........................................7 83 6.2. TLV TYPE NAME SPACE...........................................8 84 7. Acknowledgments.................................................8 85 8. References......................................................8 86 8.1. Normative References..........................................8 87 8.2. Informative References........................................8 88 Authors' Addresses.................................................8 89 Intellectual Property and Copyright Statements.....................9 91 1. Introduction 93 This document describes procedures for PEs to populate their 94 Pseudowire (PW) routing tables via the Label Distribution Protocol 95 (LDP). It is targeted at MultiSegment Pseudowire (MS-PW) 96 applications. The dynamic End-to-End MS-PW architecture requires T- 97 PEs and S-PEs to maintain a PW routing tables when using FEC129. The 98 procedure addresses MS-PW architectures where a T-PE does not (for 99 whatever reason) run either an Interior Gateway Protocol (IGP) or 100 Multi-Protocol Border Gateway Protocol (MP-BGP). The mechanism 101 described here is intended to complement other existing PW routing 102 mechanisms already described in [DYN MS-PW], [BGP AD] and [OSPF MS- 103 PW]. 105 The need for MS-PWs is presented in [MS-PW REQ]. To allow for minimal 106 manual intervention/configuration, FEC129 needs to be used as per 107 [MS-PW] and [DYN MS-PW]. [RFC5003] describes the AII type and the 108 fields that identify pseudowire endpoints called attachment 109 individual identifiers (AII). 111 [DYN MS-PW] specifies a mechanism, based on the MP-BGP, that enables 112 the advertisement of MS-PW endpoint information in the form of 113 aggregated AIIs through the network, and thus allows the automatic 114 placement of MS-PWs. 116 [OSPF MS-PW] is another way of enabling the automatic placement of 117 MS-PWs across an OSPF domain when MP-BGP is not / cannot be used 118 (e.g. when PWE3 is extended into the access part of the network). 120 2. Scope and Applicability 122 2.1. Scope 124 One important application is the use of this ldp protocol extension 125 in access networks that use IP/MPLS as their access technology and 126 MS-PW to support L2 services (as per [MS-PW REQ]). MP-BGP or an IGP 127 is often not available in this part of the network. 129 |<--- PW Segt 1----><-- PW Segt 2---><---- PW Segt 3---->| 130 +-----+ +-----+ +-----+ +-----+ 131 |T-PE1+-------------+S-PE1+----------+S-PE2+--------------+T-PE2| 132 +-----+ +-----+ +-----+ +-----+ 133 <-static-IP-routing--><------IGP/MP-BGP-available----------> 135 Figure 1 MS-PW Use Case 137 Figure 1 describes a typical use case where T-PE1 and T-PE2 need to 138 establish one or several MS-PWs between them. A MS-PW will be 139 composed of at least two PW segments (PW Segt 1 between T-PE1 and S- 140 PE1, PW Segt 2 between S-PE1 and S-PE2 and PW Segt 3 between S-PE2 141 and T-PE2). However T-PE1 is not running either an IGP or MP-BGP and 142 only has one static default route and a T-LDP session towards SPE1. 143 SPE1, SPE2 and TPE2 are running an IGP and/or MP-BGP. 145 The aim here is for T-PE1 to announce to the S-PE(s) with which it 146 has a T-LDP session (there may be more than one S-PE) its locally 147 attached PW routes, so that the S-PE(s) can populate their AII PW 148 routing table with the T-PE prefixes. 150 The AII prefixes locally defined on the T-PE are then advertised via 151 an LDP Address Message containing a new Address Family. This new 152 address family capability will follow the processes defined in [LDP 153 CAP]. 155 This document does not presuppose any specific constraint on the AII 156 PW addressing space (i.e it does not require the AII PW addressing 157 space to be a subset of the IP addressing space). Therefore, this 158 document does not define a routing protocol as such, but rather a 159 "reachability" information distribution method by which a T-PE 160 advertises its AII to a S-PE. The S-PE will then aggregate and 161 advertise this information, using one of the MS-PW dynamic placement 162 mechanisms e.g. MP-BGP, to the other S-PEs and T-PEs in the network. 163 Note that the S-PE will also advertise it's locally attached 164 prefixes, and possibly an optional "default PW route". 166 2.2. Applicability 168 Section 7.1 of [DYN MS-PW] describes 7.1 the different rules for 169 aggregated AII PW routing table lookup. The next signaling hop for a 170 segment of the pseudowire may be determined via a fixed route (static 171 route and typically a "default route"). 173 In the case of MPLS enabled access networks, an S-PE (e.g. a DSLAM or 174 other access node) will aggregate up to a few thousands devices that 175 may require several pseudowires (or "services") on each of those 176 devices. 178 These devices may not require either an IGP or MP-BGP to be 179 integrated into the network, for example because it may not be 180 desirable for a Service Provider to have to re-engineer their 181 metro/access architecture by extending their IGP or inserting MP-BGP 182 further down in the access network. However, they may require basic 183 LDP functionality to setup and maintain pseudowires. They can also be 184 configured with one or two default static routes as described in [DYN 185 MS-PW], however on the S-PE side, the provisioning required becomes 186 increasingly complex. Furthermore, the closer to the end node, it is 187 quite possible that some pseudowires be setup, removed or modified 188 (e.g. for a bandwidth upgrade) over a short timescale. Therefore, 189 there is a need for a mechanism that will alleviate the provisioning 190 burden on the S-PE(s). 192 3. LDP Extensions 194 3.1. LDP AII Address Family Type 196 In the case described in this document, we assume LDP sessions 197 between the T-PE and related S-PEs. 199 A new Address Family (AF) type called "AII address family" (TBA) is 200 defined for the Address-List TLV carried in LDP Address and Address 201 Withdraw messages. 203 This new AF allows LDP peers to advertise directly attached AII 204 prefixes, as part of an LDP Address Message and to withdraw 205 directly attached AII prefixes as part of an LDP Address Withdraw 206 Message. 208 When a T-PE needs to advertise a new AII prefix to an S-PE, it sends 209 an LDP Address Message containing the AII prefixes to all the S-PEs 210 with which it maintains LDP sessions. 212 When a T-PE needs to withdraw an AII, it sends an LDP Address 213 Withdraw Message containing the AII prefixes to all S-PEs with which 214 it maintains LDP sessions. 216 The Address-List TLV is defined in [RFC5036]. 218 AII address prefix is formatted according to AII Type II, defined in 219 [RFC5003] section 3.2 (figure 1). 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 |0|0| Address List (0x0101) | Length | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Address Family | Prefix Length | | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 228 | | 229 ~ AII Type II Address (32 - 64) ~ 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Prefix Length One octet unsigned integer containing the length 233 in bits of the address prefix that follows. The 234 minimum prefix length for an AII address MUST be 235 of 32 bits. Prefix lengths of 65 to 95 are 236 invalid as the AC ID field cannot be aggregated. 238 Two AII Address prefixes (PW routes) are said to match only when both 239 the AII Type II as well as the 8 bits prefix length are the same. 241 3.2. LDP AII Reachability Capability Advertisement 243 In order to use this method of propagating l2 reachability 244 information a PE must first advertise this capability to all LDP 245 peers. This is achieved by using the methods in [LDP-CAP] and 246 advertising the AII Address Family LDP capability TLV. If an LDP peer 247 supports the dynamic capability advertisement, this can be done by 248 sending a new capability message with the S bit set for the AII 249 Address Family capability TLV when the first AII Prefix is enabled on 250 the PE. If the peer does not support dynamic capability 251 advertisement, then the AII Address Family TLV MUST be included in 252 the LDP initialization procedures in the capability parameter [LDP- 253 CAP]. 255 The following TLV is defined to indicate the AII Address Family 256 capability: 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 |1|0| AII Add. Family CAP(0x406)| Length (= 4) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 |1| Reserved | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 4. AII Reachability Advertisement Procedures 268 [RFC5036] defines the procedures by which LSRs maintain and exchange 269 label information via LDP. 271 This document does not change any of the standard LDP procedures; it 272 only adds the AII address family type for the Adress-List TLV carried 273 in LDP Address and Address Withdraw messages. 275 The rules for advertising and withdrawing addresses are as per [RFC 276 5036]. 278 4.1. Detailed AII Address Message Procedures 280 In order for a T-PE to begin advertising its locally attached AII 281 prefixes to its S-PEs, the T-PE must know the address(es) of the 282 remote S-PE(s) and already have a T-LDP with each one of those. This 283 information may have been configured on the T-PE, or it may have been 284 learned dynamically via some autodiscovery procedure. 286 4.1.1. T-PE Procedures 288 Upon provisioning on the T-PE with a prefix of one or more specific 289 AII(s), the T-PE MUST generate an Address Message including its ASN 290 and prefix, and optionally an aggregated AII representing its locally 291 attached AII address(es), to all the S-PEs with which it maintains T- 292 LDP sessions. 294 The addresses are structured according to AII type II [RFC5003]. 295 The T-PE MUST only advertise its AIIs over its T-LDP sessions towards 296 its directly attached S-PEs. 298 Whenever an attachment circuit not addressed by an existing 299 aggregated already advertised AII is configured on a T-PE, the T-PE 300 MUST advertise the new address with an Address message. 302 Whenever a T-PE "de-activates" a previously advertised AII Prefix, it 303 SHOULD withdraw the AII Prefix with an Address Withdraw message. 305 A T-PE may re-advertise an address that it has previously 306 advertised without explicitly withdrawing the address. If the 307 receiver already has address binding, it SHOULD take no further 308 action. 310 A T-PE MAY withdraw an address without having previously advertised 311 it. If the receiving S-PE has no address binding, it SHOULD take no 312 further action. 314 4.1.2. S-PE Procedures 316 If a PE receives an address TLV containing an address family that it 317 does not support, it SHOULD follow the procedures defined in 318 [RFC5036]. 320 An S-PE receiving an address list TLV containing one or more AII 321 addresses should install those addresses in its local PW routing 322 table. It MAY also re-advertise those addresses using any another 323 supported dynamic MS-PW routing mechanism. 325 5. Security Considerations 327 TBD 329 6. IANA Considerations 331 6.1. Address Family Type 333 This document defines a new Address Family type called AII address 334 family (TBA) for the Adress-List TLV carried in LDP Address and 335 Address Withdraw messages. 337 The following value is suggested for assignment: 339 Registry Number Description 341 27 AII Attachment Individual Identifier 343 6.2. TLV TYPE NAME SPACE 345 This document uses a new LDP TLV type, IANA already maintains a 346 registry of name "TLV TYPE NAME SPACE" defined by [RFC5036]. The 347 following value is suggested for assignment: 349 TLV Type Description 351 0x406 AII address family capability TLV 353 7. Acknowledgments 355 The authors would like to thank Florin Balus, Wim Hendeickx, Jean- 356 Louis Le Roux, Ed Wong and Raymond Key for their valuable comments 357 and suggestions. 359 8. References 361 8.1. Normative References 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, March 1997. 366 [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., 367 Thomas, B., "LDP Specification", January 2001. 369 [RFC5003] Chris Metz et. al., "AII Types for Aggregation", 370 February 2007. 372 8.2. Informative References 374 [MS-PW] Martini et al., "Segmented Pseudo Wire", Internet 375 Draft, draft-ietf-pwe3-segmented-pw-09.txt, July 376 2008 378 [DYN MS-PW] Bocci, M., Martini, L., "Dynamic placement of Multi 379 Segment Pseudo Wires", Internet Draft, draft-ietf- 380 pwe3-dynamic-ms-pw-08.txt, July 2008 382 [BGP AD] E. Rosen et. al., "Provisioning, Autodiscovery, and 383 Signaling in L2VPNs", draft-ietf-l2vpn-signaling- 384 08.txt, May 2006 386 [OSPF MS-PW] A. Dolganow, M. Bocci et. al., "OSPF Extensions for 387 Dynamic Multi- segment Pseudo 388 Wires",draft-dolganow-pwe3-ospf-ms-pw-ext-02.txt, 389 February 2008 391 [MS-PW REQ] Bitar, N., Bocci, M., and Martini, L., 392 "Requirements for inter domain Pseudo-Wires", 393 Internet Draft, draft-ietf-pwe3-ms-pw-requirements- 394 07.txt, June 2007 396 [LDP-CAP] B. Thomas, "LDP Capabilities", Internet Draft, draft- 397 ietf-mpls-ldp-capabilities-02.txt, April 2008 399 Author's Addresses 401 Simon Delord 402 Uecomm 403 8/658 Church St 404 Richmond VIC 3121 405 Australia 406 Email: sdelord@uecomm.com.au 408 Frederic Jounay 409 France Telecom 410 2, avenue Pierre-Marzin 411 22307 Lannion Cedex 412 FRANCE 413 Email: frederic.jounay@orange-ftgroup.com 415 Philippe Niger 416 France Telecom 417 2, avenue Pierre-Marzin 418 22307 Lannion Cedex 419 FRANCE 420 Email: philippe.niger@orange-ftgroup.com 422 Mustapha Aissaoui 423 Alcatel-Lucent 424 600 March Road 425 Kanata 426 ON, Canada 427 e-mail: mustapha.aissaoui@alcatel-lucent.com 429 Matthew Bocci 430 Alcatel-Lucent, 431 Voyager Place 432 Shoppenhangers Road 433 Maidenhead 434 Berks, UK 435 e-mail: matthew.bocci@alcatel-lucent.co.uk 437 Yaakov (Jonathan) Stein 438 RAD Data Communications 439 24 Raoul Wallenberg St., Bldg C 440 Tel Aviv 69719, Israel 441 EMail: yaakov_s@rad.com 442 Cao Wei 443 Huawei Technologies Co., Ltd. 444 Huawei Bld., No.3 Xinxi Rd. 445 Shang-Di Information Industry Base 446 Hai-Dian Distinct, Beijing 100085 447 China 448 Email: caowayne@huawei.com 450 Luca Martini 451 Cisco Systems, Inc. 452 9155 East Nichols Avenue, Suite 400 453 Englewood, CO, 80112 454 e-mail: lmartini@cisco.com 456 Intellectual Property Statement 458 The IETF takes no position regarding the validity or scope of any 459 Intellectual Property Rights or other rights that might be claimed to 460 pertain to the implementation or use of the technology described in 461 this document or the extent to which any license under such rights 462 might or might not be available; nor does it represent that it has 463 made any independent effort to identify any such rights. Information 464 on the procedures with respect to rights in RFC documents can be 465 found in BCP 78 and BCP 79. 467 Copies of IPR disclosures made to the IETF Secretariat and any 468 assurances of licenses to be made available, or the result of an 469 attempt made to obtain a general license or permission for the use of 470 such proprietary rights by implementers or users of this 471 specification can be obtained from the IETF on-line IPR repository at 472 http://www.ietf.org/ipr. 474 The IETF invites any interested party to bring to its attention any 475 copyrights, patents or patent applications, or other proprietary 476 rights that may cover technology that may be required to implement 477 this standard. Please address the information to the IETF at ietf- 478 ipr@ietf.org. 480 Disclaimer of Validity 482 This document and the information contained herein are provided on an 483 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 484 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 485 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 486 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 487 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 488 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 490 Copyright Statement 491 Copyright (C) The IETF Trust (2008). 492 This document is subject to the rights, licenses and restrictions 493 contained in BCP 78, and except as set forth therein, the authors 494 retain all their rights.