idnits 2.17.1 draft-dolganow-pwe3-ospf-ms-pw-ext-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 15, 2009) is 5461 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) -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-arch-06 == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-11 == Outdated reference: A later version (-22) exists of draft-ietf-pwe3-dynamic-ms-pw-09 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group 2 Internet Draft A. Dolganow (ed.) 3 M. Bocci (ed.) 4 Alcatel-Lucent 6 L. Martini (ed.) 7 Cisco 9 Frederic Jounay (ed.) 10 France Telecom 12 Yuji Kamite (ed.) 13 NTT Communications 14 Intended status: Standards Track April 15, 2009 15 Expires: October 15, 2009 17 OSPF Extensions for Dynamic Placement of Multi-Segment Pseudowires 18 draft-dolganow-pwe3-ospf-ms-pw-ext-03.txt 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on October 8, 2009. 43 Abstract 45 Multi-segment pseudowires have been defined to enable emulated layer 46 1 and layer 2 services to be delivered from an IP based packet 47 switched network over a sparse mesh of PSN tunnels and PW control 48 protocol sessions. MS-PWs can be used to scale PW based networks 50 over both a single AS, or between multiple ASs, and there is a 51 particular need to be able to dynamically route MS-PWs through a 52 given AS to reach PEs at or beyond the edge of the AS, where the 53 route of the PW through each AS needs to be automatically determined. 55 This draft proposes extensions to OSPF to enable the automatic 56 advertisement of summarized PW FECs, thus enabling the dynamic 57 routing of MS-PWs across an OSPF domain. 59 Copyright Notice 61 Copyright (c) 2009 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents in effect on the date of 66 publication of this document (http://trustee.ietf.org/license-info). 67 Please review these documents carefully, as they describe your rights 68 and restrictions with respect to this document. 70 This document may contain material from IETF Documents or IETF 71 Contributions published or made publicly available before November 72 10, 2008. The person(s) controlling the copyright in some of this 73 material may not have granted the IETF Trust the right to allow 74 modifications of such material outside the IETF Standards Process. 75 Without obtaining an adequate license from the person(s) controlling 76 the copyright in such materials, this document may not be modified 77 outside the IETF Standards Process, and derivative works of it may 78 not be created outside the IETF Standards Process, except to format 79 it for publication as an RFC or to translate it into languages other 80 than English. 82 Table of Contents 84 1. Introduction................................................3 85 1.1. Terminology............................................4 86 1.2. Architecture...........................................4 87 2. Conventions used in this document...........................5 88 3. Applicability...............................................6 89 4. OSPF Extensions.............................................6 90 4.1. Attachment Circuit Addressing..........................6 91 4.2. OSPFv2 LSAs............................................6 92 4.2.1. Pseudowire Switching LSA..........................7 93 4.3. OSPFv3 LSAs............................................7 94 4.3.1. Pseudowire Switching LSA..........................7 95 4.4. LSA Information Field..................................7 96 4.4.1. Exterior AII TLV..................................7 97 5. LSA Processing Procedures...................................8 98 5.1. P Routers..............................................8 99 5.2. PE Routers.............................................8 100 6. Deployment Considerations...................................8 101 6.1. Addition and Removal of ACs, S-PEs and T-PEs...........8 102 6.2. Impact on Existing P-Routers...........................9 103 6.3. Congestion in the Underlying PSN Routing...............9 104 7. Security Considerations....................................10 105 8. IANA Considerations........................................10 106 9. Acknowledgments............................................10 107 10. References................................................11 108 10.1. Normative References.................................11 109 10.2. Informative References...............................11 110 Author's Addresses............................................12 112 1. Introduction 114 Multi-segment pseudowires have been defined to enable emulated layer 115 2 services to be delivered from an IP based packet switched network 116 over a sparse mesh of PSN tunnels and PW control protocol 117 adjacencies. MS-PWs can be used to scale PW based networks over both 118 a single AS, and multiple ASs. Requirements for MS-PWs are detailed 119 in [8]. 121 A basic approach to MS-PWs, where the switching points are statically 122 placed, is described in [10]. This is extended in [11]to allow the 123 automatic placement of the MS-PWs. This draft uses FEC 129 with AII 124 type II to summarize the PW end points that are reachable through a 125 given PE, and to provide a layer 2 address for the S-PEs. MP-BGP is 126 used to distribute FECs. 128 The use of MP-BGP is primarily focused on scenarios where each PWE3 129 domain is a separate AS, and S-PEs are used to switch PWs between 130 adjacent ASs. MP-BGP; therefore, provides the BGP-enabled T-PE or S- 131 PE at the ingress of the AS with reachability information for AIIs at 132 or beyond the border of the AS. This provides sufficient information 133 to dynamically route the PW across the AS when there is a direct PSN 134 tunnel between the ingress and egress S-PE or T-PE. When there is no 135 direct PSN tunnel, a mechanisms must be provided to determine an 136 indirect route for the PW via some intermediate S-PE within an AS 137 domain. 139 A second important case is where MS-PWs are deployed in service 140 provider access and metro networks. Pseudowires in these networks 141 typically span only a single IGP domain or AS. Furthermore, the nodes 142 contain a minimal routing implementation to cut on the operational 143 complexity. In such networks MP-BGP is not typically deployed on MTUs 144 and full MP-BGP functionality may not be required. This prevents 145 methods defined in [11] to be employed; however, the need to be able 146 to dynamically route MS-PWs through these topologies still exists. 148 To enable automatic placement of MS-PWs in the above described cases, 149 it is possible to leverage the mechanisms of the PSN IGP to 150 distribute MS-PW endpoint reachability information. This draft 151 proposes extensions to OSPF to enable the automatic advertisement of 152 summarized PW layer 2 addresses within a single AS, thus enabling the 153 automatic placement of MS-PWs across an OSPF domain. The advertised 154 information is used by T-PEs and S-PEs to derive the MS-PW next hop 155 route which is used then to signal the next-hop S-PE or T-PE, as 156 described in [11]. The draft also describes mechanisms to isolate 157 OSPF advertisements used for MS-PWs from those used for routing in 158 the underlying PSN to avoid any overloading of the IGP routing by the 159 mechanisms proposed. 161 1.1. Terminology 163 The terminology defined in [9] applies. 165 1.2. Architecture 167 +-----+ +-----+ 168 |T-PE1+--------------------------------------------------+T-PE2| 169 +-----+ +-----+ 171 |<---------------------------PW----------------------------->| 173 +-----+ +-----+ +-----+ +-----+ 174 |T-PE1+-------------+S-PE1+-----------+S-PE2+------------+T-PE2| 175 +-----+ +-----+ +-----+ +-----+ 177 <---------------------- Single AS --------------------------> 179 Figure 1 MS-PW Routing Model for a Single AS 181 Figure 1 illustrates the MS-PW routing model for a single AS. ACs 182 attached to T-PE2 are associated with the OSPF Router_ID or any 183 locally assigned routable address. Each S-PE / T-PE is also assigned 184 its own layer 2 address in the form of an AII as described in [11]. 186 The proposed model requires the existence of PSN tunnels between T- 187 PE/S-PE, S-PE/S-PE and/or S-PE/T-PE. PWs are established on these 188 tunnels using Targeted LDP signaling [11]. 190 When a PSN tunnel exists and can be used for the establishment of MS- 191 PW or it segment, T-PE advertises the set of exterior AIIs reachable 192 via this tunnel. This is done using summarized Type 2 AIIs so that a 193 separate advertisement is not required for every AC reachable via 195 that tunnel. AIIs may be summarized using the aggregation rules for 196 AII Type 2 described in [6]. When an advertisement is received by an 197 S-PE and the S-PE has a PSN tunnel connectivity to the advertising 198 PE, the advertisement is installed in the S-PE's routing information 199 and the S-PE summarizes AIIs at the far end of the tunnel in its own 200 advertisement for propagation in the AS backbone and further 201 propagation into other areas. When an advertisement is received by a 202 T-PE and the T-PE has PSN tunnel connectivity to the advertising PE, 203 the advertisement is installed in the PE's routing information base. 204 As an alternative to this summarization-based population of an 205 advertisement at S-PEs, a static (through configuration) method may 206 be employed at the S-PE in order to populate the AIIs reachable 207 through it. 209 Based on the advertised information, each PE builds a routing 210 information base containing all exterior AIIs reachable through a 211 given next hop S-PE. When creating a MS-PW, the PE looks up the AII 212 and determines the next hop S-PE or T-PE for LDP signaling, as 213 described in [11]. 215 Figure 1 depicts the simple model of a one-to-one relationship of T- 216 PE to S-PE and S-PE to S-PE, and of a single S-PE to S-PE segment. 217 In the general case, multiple S-PE segments will exist, and the 218 relationship between two S-PEs and/or the T-PE and S-PEs will be one- 219 to-many or many-to-one. Processing in these cases follows that of 220 the general case illustrated in Figure 1. Selection of an S-PE from 221 a set of multiple available next-hop S-PEs may be achieved by 222 comparing the IGP metrics for the route to the terminating T-PE (TT- 223 PE) via each of these next-hop S-PEs. 225 2. Conventions used in this document 227 In examples, "C:" and "S:" indicate lines sent by the client and 228 server respectively. 230 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 231 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 232 document are to be interpreted as described in RFC-2119 [1]. 234 3. Applicability 236 The proposed OSPFv2 and OSPFv3 protocol extensions are intended for 237 domains where MP-BGP is not used and/or only a partial mesh of PSN 238 tunnels exists. In many cases, this will apply to routing MS-PWs 240 across a single AS, where the source T-PE (ST-PE), the Terminating T- 241 PE (TT-PE) and all of the intermediate S-PEs reside in the same AS. 243 However, the above application may also be used where OSPF is used to 244 route one portion of a MS-PW across a given AS where the ST-PE and 245 the TT-PE reside in different ASs. Here, OSPF is used to advertise 246 the AIIs reachable through S-PEs corresponding to ASBRs. This 247 enables the ingress S-PEs and intermediate S-PEs in an AS to route 248 MS-PWs to the correct egress S-PE in the AS to reach a TT-PE in 249 another AS. This draft does not define how the egress S-PE learns 250 what AIIs are externally reachable through it, but this could be by 251 configuration, or by learning the exterior reachable addresses from 252 an exterior gateway protocol such as BGP. 254 4. OSPF Extensions 256 4.1. Attachment Circuit Addressing 258 As in [11], attachment circuit addressing is derived from AII type 2 259 [2], as shown in the following figure: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | AII Type=02 | Length | Global ID | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Global ID (contd.) | Prefix | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Prefix (contd.) | AC ID | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | AC ID (contd.) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 2 Attachment Circuit Addressing 274 Implementations of this procedure MUST interpret the AII as described 275 in [11]. 277 4.2. OSPFv2 LSAs 279 This extension makes use of the opaque LSA. 281 One new LSA is defined: the PW Switching LSA. This LSA describes the 282 S-PEs/T-PEs, PSN tunnel(s) between peer S-PEs or T-PEs, and AII 283 addresses reachable. 285 4.2.1. Pseudowire Switching LSA 287 OSPFv2 routers behaving as S-PEs or T-PEs advertise the layer 2 288 addresses reachable through them. This advertisement MUST be in an 289 AS-scoped or Area-scoped opaque LSA described in [3]. 291 The 'O' bit in the LSA Option field MUST be set to 1. The Opaque LSA 292 type is TBD. 294 [Note: IANA will assign the Opaque LSA value] 296 The LSA Information field is formatted as described in Section 4.4. 297 below. 299 4.3. OSPFv3 LSAs 301 4.3.1. Pseudowire Switching LSA 303 The OSPFv3 PW switching LSA has a function code of TBD. The S1/S2 304 bit are set to indicate an AS flooding scope for the LSA. The U bit 305 is set indicating the OSPFv3 PW switching LSA should be flooded even 306 if it is not understood. The LSA Information field is formatted as 307 described in Section 4.4. below. 309 4.4. LSA Information Field 311 The LSA information consists of two or more nested Type/Length/Value 312 (TLV) triplets. 314 The LSA MUST contain a TLV for the IP address of the advertising 315 router. For OSPF v2 routers, this is the Router Address TLV defined 316 in Section 2.4.1 of RFC 3630 [4]. For OSPF v3 routers, this is the 317 Router IPv6 Address TLV specified in Section 3 of draft-ietf-ospf- 318 ospfv3-traffic-07.txt [5]. In each of these, the router address MUST 319 be set to the IP address of the advertising T-PE/S-PE. 321 4.4.1. Exterior AII TLV 323 The Exterior AII TLV is used to describe addresses attached of 324 attached T-PEs or those routable through S-PEs to T-PEs in another 325 AS. If the LSA information is of type AII, then the value field 326 contains one or more AII Type 2 TLVs, as described above. 328 Exterior AIIs correspond to the AII (or AC) configured on a T-PE, 329 which must contain at least the prefix and global ID to be used in 330 FEC129 for signaling the PW endpoint. The prefix may or may not be 331 directly related to the loopback address of the T-PE. 333 5. LSA Processing Procedures 335 Nodes capable of pseudowire switching on either side of a PSN tunnel 336 exchange PW switching information using the Pseudowire Switching 337 opaque LSA. These Pseudowire Switching LSAs are processed and 338 flooded as described in Section 5.2. 340 5.1. P Routers 342 OSPF routers that receive LSAs described in this draft and that are 343 not S-PEs or T-PEs MUST flood them according to the rules of OSPFv2 344 or OSPFv3, as applicable. 346 5.2. PE Routers 348 S-PEs and T-PEs that are OSPF routers and that receive LSAs described 349 in this draft MUST flood them according to the rules of OSPFv2 or 350 OSPFv3, as applicable. These LSAs are also installed in a PW routing 351 database. This routing database MAY be used by S-PEs and T-PEs to 352 calculate a PW routing table. The PW routing table has the structure 353 described in Section 7 of [11], and is used to determine the next 354 signaling hop when a S-PE receives a PW setup message as described in 355 that draft. PW static routes may also be provisioned, as described 356 in [11]. 358 S-PEs that are also OSPF ABR MAY opt to summarize the PW routing 359 information receive in type 10 area scoped opaque LSA. The 360 summarization can be done in a similar way as for Ipv4 or ipv6 361 routes. 363 S-PEs that are ASBRs that receive type 10 LSAs described in this 364 draft MAY summarize Exterior AII TLVs received in non-backbone 365 advertisements in that S-PEs' own backbone advertisement, and MAY 366 summarize Exterior AII TLVs received in backbone advertisements in 367 that S-PEs non-backbone area advertisements. 369 6. Deployment Considerations 371 6.1. Addition and Removal of ACs, S-PEs and T-PEs 373 It is important that the impact of PW switching information 374 advertised on the underlying OSPF routing is minimized. To achieve 375 that it is RECOMMENDED that: 377 1. The Exterior AII TLV only contains the prefix and global ID of the 378 T-PE. Such summarization allows the content of the Exterior AII 379 TLV to remain unchanged when an AC is added or removed, thus 380 removing a need to re-advertise the Exterior AII TLV. 381 Likewise, no new LSA is advertised when AC connectivity flaps or 382 when a pseudowire is established/provisioned. 384 2. S-PEs use AII summarization that minimizes the impact on the S- 385 PEs' advertisements into backbone on changes to Exterior AII TLV 386 received in a non-backbone advertisements. 388 6.2. Impact on Existing P-Routers 390 P-routers supporting Opaque LSA processing procedures must exist 391 along the flooding path in the AS to ensure propagation of the 392 information required for dynamic pseudowire routing. Ideally, 393 multiple "Opaque LSA" flooding paths exist, so a failure of a router 394 along a path does not isolate subset of a network. 396 Routers supporting Opaque LSA processing as described in [3] will 397 flood the LSAs as specified in [3]. The impact of this additional 398 Opaque LSA flooding load MAY be constrained through appropriate 399 levels of aggregation of AIIs as described in Section 6.1. Section 400 6.3. describes complementary methods for limiting the impact of any 401 additional flooding. 403 6.3. Congestion in the Underlying PSN Routing 405 This draft describes the use of the underlying interior gateway 406 protocol in an IP network to advertise routing information for the 407 automatic placement of MS-PWs. Congestion may occur in the routing 408 plane of the PSN if a large amount of pseudowire LSAs are flooded. 409 It is therefore important to ensure that this does not degrade the 410 performance of the IGP for the underlying PSN. 412 Implementations MAY use a number of methods to avoid routing 413 congestion, including: 415 o Prioritization of PSN LSAs over PW Switching LSAs. 417 o Rate limiting PW Switching LSAs so that they do not consume 418 excessive bandwidth or route processor capacity. 420 o AII summarization methods as described in section 6.1. above 422 o OSPF Refresh and Flooding reduction mechanisms as defined in [7]. 424 It is RECOMMENDED that implementations either: 426 o Use all of the above mentioned techniques to minimize the impact 427 of pseudowire switching advertisements on the underlying IGP 428 routing when a single routing instance is used, or 430 o Use a separate transport instance for pseudowire switching 431 advertisements. 433 7. Security Considerations 435 The security discussion in Section 6 of [3]is also applicable to PW 436 routing information. 438 8. IANA Considerations 440 This draft requests that the following allocations be made from 441 existing registries: 443 1. The OSPFv2 opaque LSA type TBD for the PW switching opaque LSA. 445 2. The OSPFv3 LSA type function code TBD for the PW switching LSA 447 9. Acknowledgments 449 The authors gratefully acknowledge the contributions of Vach 450 Kompella, Devendra Raut and Yuichi Ikejiri. 452 This document was prepared using 2-Word-v2.0.template.dot. 454 10. References 456 10.1. Normative References 458 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 459 Levels", BCP 14, RFC 2119, March 1997. 461 [2] Metz, C., et al, "AII Types for Aggregation", Internet Draft, 462 draft-metz-aii-aggregate-01.txt, October 2006. 464 [3] L. Berger, et al, " The OSPF Opaque LSA Option", RFC 5250, 465 July 2008 467 [4] Katz D. et al., "Traffic Engineering (TE) Extensions to OSPF 468 Version 2", RFC 3630, September 2003 470 [5] Ishiguro K. et al., "Traffic Engineering Extensions to OSPF 471 version 3", RFC 5329, September 2008 473 [6] Metz C. et al., "Attachment Individual Identifier (AII) Types 474 for Aggregation", RFC 5003, September 2007 476 10.2. Informative References 478 [7] Pillay-Esnault P., "OSPF Refresh and Flooding Reduction in 479 Stable Topologies", RFC 4136, July 2005 481 [8] Bitar, N. at al. "Requirements for Multi-Segment Pseudowire 482 Emulation Edge-to-Edge (PWE3)", RFC 5254, October 2008 484 [9] Bocci, M., and Bryant, S.,T., "An Architecture for Multi- 485 Segment Pseudo Wire Emulation Edge-to-Edge", Internet Draft, 486 draft-ietf-pwe3-ms-pw-arch-06.txt, February 2009 488 [10] Martini et al, "Segmented Pseudo Wire", Internet Draft, draft- 489 ietf-pwe3-segmented-pw-11.txt, February 2009 491 [11] Martini, L., Bocci, M., Balus, F., et al, "Dynamic Placement of 492 Multi Segment Pseudo Wires", Internet Draft, draft-ietf-pwe3- 493 dynamic-ms-pw-09.txt, March 2009 495 Author's Addresses 497 Matthew Bocci 498 Alcatel-Lucent 499 Voyager Place, 500 Shoppenhangers Road 501 Maidenhead 502 Berks, UK 503 Email: matthew.bocci@alcatel-lucent.co.uk 505 Dimitri Papadimitriou 506 Alcatel-Lucent 507 Copernicuslaan 50 508 2018 ANTWERP 509 BELGIUM 510 Email: dimitri.papadimitriou@alcatel-lucent.be 512 Alex Zinin 513 ALCATEL-Lucent. 514 701 East Middlefield Road 515 M/S MOUNT-HRPB6 516 MOUNTAIN VIEW, CA 94043 517 USA 518 Email: alex.zinin@alcatel-lucent.com 520 Mustapha Aissaoui 521 Alcatel-Lucent 522 600 March Road 523 OTTAWA, ON K2K 2E6 524 CANADA 525 Email: mustapha.aissaoui@alcatel-lucent.com 527 Andrew Dolganow 528 Alcatel-Lucent 529 600 March Road 530 OTTAWA, ON K2K 2E6 531 CANADA 532 Email: andrew.dolganow@alcatel-lucent.com 534 Yuji Kamite 535 NTT Communcations 536 Email: y.kamite@ntt.com 538 Luca Martini 539 Cisco 540 Email: lmartini@cisco.com 541 Frederic Jounay 542 France Telecom 543 Email : Frederic.jounay@orange-ftgroup.com