idnits 2.17.1 draft-jounay-pwe3-leaf-initiated-p2mp-pw-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (July 12, 2010) is 5035 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) ** Downref: Normative reference to an Informational RFC: RFC 3985 ** Downref: Normative reference to an Informational RFC: RFC 5254 == Outdated reference: A later version (-22) exists of draft-ietf-pwe3-dynamic-ms-pw-10 == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-15 == Outdated reference: A later version (-15) exists of draft-ietf-mpls-ldp-p2mp-10 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Jounay 3 Internet Draft J.L. Le Roux 4 Category: Standards Track P. Niger 5 Expires: January 2011 France Telecom Orange 7 L.Jin Y. Kamite 8 ZTE NTT Communications 10 July 12, 2010 12 LDP Extensions for Leaf-initiated Point-to-Multipoint Pseudowire 13 draft-jounay-pwe3-leaf-initiated-p2mp-pw-02.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January, 2011. 38 Abstract 40 This document provides a solution to extend LDP signaling to set up 41 and maintain Point-to-Multipoint MultiSegment Pseudowire (P2MP MS- 42 PW). The P2MP PW described in this draft is constructed by multiple 43 unidirectional PW segments. Such an extension of existing point to 44 point Pseudowire is made necessary by new applications. The document 45 only deals with the leaf-initiated P2MP PW setup and maintenance. The 46 processing for setting up a P2MP MS-PW is based on the same as MLDP 47 for P2MP LSP setup. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in [RFC2119]. 55 Table of Contents 57 1. Terminology.....................................................3 58 2. Preliminary Notes...............................................3 59 3. Introduction....................................................3 60 4. P2MP MS-PW Reference Model......................................3 61 5. MPLS-PW to MPLS-PW Replication..................................5 62 6. Overview of the P2MP MS-PW Setup................................5 63 7. LDP S-PE TLV....................................................5 64 8. Configuration...................................................6 65 9. Capability Negotiation Procedure................................6 66 10. Signaling for P2MP MS-PW with dynamic S-PE routing.............6 67 10.1. Label Map....................................................7 68 10.1.1. Determining one's 'upstream PE'............................7 69 10.1.2. Egress T-PE Operation......................................7 70 10.1.3. Branch S-PE Operation......................................7 71 10.1.4. Ingress T-PE Operation.....................................7 72 10.2. Label Withdraw...............................................8 73 10.2.1. Egress T-PE Operation......................................8 74 10.2.2. Branch S-PE Operation......................................8 75 10.2.3. Ingress T-PE Operation.....................................8 76 10.2.4. Upstream PE Change.........................................8 77 11. Security Considerations........................................8 78 12. IANA Considerations............................................9 79 13. Acknowledgments................................................9 80 14. References.....................................................9 81 14.1. Normative References.........................................9 82 14.2. Informative References.......................................9 83 Copyright Notice..................................................10 84 Authors's Addresses.. ............................................11 85 Intellectual Property and Copyright Statements....................12 87 1. Terminology 89 This document uses acronyms and terminologies defined in [RFC5036], 90 [RFC3985], [P2MP PW REQ] and [RFC5254]. 92 2. Preliminary Notes 94 The current version of the document does not cover: 96 - The mechanism for the leaves to discover the P2MP PW FEC 97 identifying the P2MP MS-PW, out of the scope of this document. 99 - The P2MP PW Upstream Label Assignment required when the underlying 100 layer is a P2MP LSP. This document describes LDP extensions for 101 setting up P2MP MS-PW where the PW segments are supported over P2P 102 PSN tunnels. 104 3. Introduction 106 [P2MP PW REQ] describes a set of requirements for setting up a P2MP 107 PW setup. In the MS-PW architecture, the underlying layer which 108 supports a PW segment belonging to the PW tree may be either a 109 unidirectional P2P or a P2MP PSN tunnel. 111 Note that a P2MP PW is optionally bidirectional [P2MP PW REQ]. This 112 version of the document does dot cover the return path from leaf to 113 root, this point will be addressed in a next version. 115 This document describes LDP extensions for setting up P2MP MS-PW 116 where the PW segments are supported over P2P PSN tunnels. 118 For that purpose the P2MP PW FEC element is reused from [ROOT INIT 119 P2MP PW] to encode MS-PW parameters. The procedures for setting up a 120 P2MP MS-PW are very similar with LDP mechanisms for setting P2MP LSP 121 [MLDP], where hops are here S-PEs and T-PEs. Therefore a leaf can 122 join the tree by sending a Label Map associated to this FEC towards 123 the root. 125 4. P2MP MS-PW Reference Model 127 Figure 1 describes the P2MP MS-PW reference model which is derived 128 from [P2MP PW REQ] to support P2MP emulated services. 130 |<-----------P2MP MS-PW------------>| 131 Native | P2P P2P | Native 132 Service | |<-PSN1-->| |<-PSN2-->| | Service 133 (AC) V V tunnels V V tunnels V V (AC) 134 | +----+ +-----+ +----+ | 135 | |T-PE| |S-PE1|=========|T-PE| | +----+ 136 | | 1 | | .......PW3......2.|-----------|CE2 | 137 | | |=========| . |=========| | | +----+ 138 | | .......PW1....... | +----+ | 139 | | . |=========| . | +----+ | 140 | | . | | . |=========|T-PE| | +----+ 141 | | . | | .......PW4......3.|-----------|CE3 | 142 +----+ | | . | | |=========| | | +----+ 143 |CE1 |---------|.. | +-----+ +----+ | 144 +----+ | | . | +-----+ +----+ | 145 | | . | |S-PE2|=========|T-PE| | +----+ 146 | | . | | .......PW5......4.|-----------|CE4 | 147 | | . | | . |=========| | | +----+ 148 | | . |=========| . | +----+ | 149 | | .......PW2....... +----+ | 150 | | |=========| . |=========|T-PE| | +----+ 151 | | | | .......PW6......5.|-----------|CE5 | 152 | | | | |=========| | | +----+ 153 | +----+ +-----+ +----+ | 155 Figure 1 P2MP MS-PW over P2P PSN tunnels Reference Model 157 Figure 1 describes the P2MP MS-PW reference model which is derived 158 from [P2MP PW REQ] where the PW segments are supported over 159 individual P2P PSN tunnels. Here in a P2MP MS-PW configuration the S- 160 PE is responsible for switching a MS-PW from one input unidirectional 161 P2P segment to one or several output unidirectional P2P segments at 162 PW layer level. 164 Referring to Figure 1, T-PE1 is the Ingress T-PE and T-PE2, T-PE3, T- 165 PE4 and T-PE5 are the Egress T-PEs. The S-PE S-PE1 and S-PE2 play the 166 role of branch S-PE since they are in charge of switching the input 167 unidirectional P2P PW1 and the unidirectional P2P PW2 segment to 168 respectively the output unidirectional P2P PW3,4 and the output 169 unidirectional P2P PW5,6 segments. For example, packets received from 170 unidirectional P2P PW1 will replicate to unidirectional P2P PW3 and 171 PW4 at PW layer level. 173 Note that a P2MP MS-PW may obviously transit through more than one S- 174 PE along its path. 176 5. MPLS-PW to MPLS-PW Replication 178 Referencing Figure 1, PDUs are replicated to the Pseudowire segments 179 at the PW label level. Hence the data plane does not need any special 180 knowledge of the specific PW type. A simple standard MPLS label swap 181 operation is sufficient to connect the PW segments. However when 182 pushing a new PSN label the TTL SHOULD be set to 255, or some other 183 locally configured fixed value. This process can be repeated as many 184 times as necessary, the only limitation to the number of S-PEs 185 traversed is imposed by the TTL field of the PW MPLS Label. The 186 setting of the TTL of the PW MPLS label is a matter of local policy 187 on the originating PE, but SHOULD be set to 255 except OAM packet. 189 6. Overview of the P2MP MS-PW Setup 191 The P2MP MS-PW setup relies on the use of the P2MP PW FEC Element 192 defined also in [ROOT INIT P2MP PW]. The solution aims at setting up 193 a unidirectional P2MP MS-PW. 195 The principle proposed here relies on a leaf-initiated P2MP MS-PW 196 setup. In the proposed approach the leaf is assumed to know the P2MP 197 PW FEC which contains the source AII address and the VPN ID (AGI). 198 The procedure used for the P2MP PW FEC discovery by the leaves is out 199 of scope of this document. 201 The document describes the solution to setup the P2MP MS-PW in the 202 case the PW segments are supported individually over a P2P PSN 203 tunnel. After a negotiation procedure between Ingress T-PE/S-PE and 204 S-PE/Egress T-PEs to verify their P2MP PW FEC capability, the Egress 205 T-PE sends a Label Map to its upstream PE selected to reach the SAII 206 specified in the P2MP PW FEC. At turn the S-PE carries on the 207 signalling procedure by sending if required a new Label Map towards 208 its next hop to reach the source SAII. In the MS-PW architecture, the 209 hop consists either in a branch S-PE or the Ingress T-PE. Each PE 210 receiving the P2MP FEC installs a forwarding state to map traffic 211 into the P2MP MS-PW. 213 The definition of PW Type, C bit, PW Info Length, AGI, SAII, and 214 Optional Parameters are same as defined in [ROOT INIT P2MP PW]. 216 7. LDP S-PE TLV 218 The S-PE TLV defined in [SEGMENT MS-PW] can also be applied for P2MP 219 MS-PW. PW loop detection will be performed by S-PE which is same as 220 [SEGMENT MS-PW], by using Sub-TLV of Local IP address of S-PE. When 221 egress PE sends notification to ingress PE to indicate PW status, 222 each S-PE on the path to ingress PE SHOULD append S-PE TLV with local 223 IP address to LDP notification message, which allows the Root T-PE to 224 build the P2MP MS-PW topology. 226 8. Configuration 228 After configuring on each T-PE the attached AIIs, it is assumed that 229 all the PEs (Ingress/Egress T-PEs and all S-PEs) maintain an AII PW 230 routing table which gives for each AII as entry the "next hop" to 231 reach that AII. This AII routing table can be filled manually or 232 updated dynamically by means of some extended routing protocol like 233 proposed in [DYN MS-PW]. The construction of the table is out of 234 scope of the present document. 236 Each PE relies on its AII PW routing table to select the next hop PE 237 (S-PE or T-PE) to reach a given AII. 239 The target-LDP session between T-PE and S-PE, or two S-PEs should be 240 configured automatically or manually. The P2MP MS-PW signaling 241 message should be transmitted over this target-LDP session. 243 9. Capability Negotiation Procedure 245 For the dynamic LDP protocol, the capability negotiation the solution 246 MUST follow the PW Status Capability advertisement mechanism 247 described in [ROOT INIT P2MP PW]. 249 The PEs belonging to a given P2MP MS-PW MUST support the P2MP PW FEC 250 Element used by LDP to setup the P2MP MS-PW. 252 10. Signaling for P2MP MS-PW with dynamic S-PE routing 254 The following defines the rules for the processing and propagation of 255 the P2MP FEC Element for the Leaf-initiated P2MP MS-PW setup. The 256 following notation is derived from [MLDP] and is used in the 257 processing rules: 259 1. P2MP PW FEC Element : a FEC Element with SAII X, AGI Y. 261 2. P2MP PW Label Map : a Label Map message with a FEC TLV 262 with a single P2MP PW FEC Element and Label TLV with label L. 264 3. P2MP PW Label Withdraw : a Label Withdraw message with a 265 FEC TLV with a single P2MP PW FEC Element and Label TLV with 266 label L. 268 4. P2MP MS-PW (or simply ): a P2MP MS-PW with SAII X 269 and AGI Y. 271 5. The notation L' -> { ..., } on branch S- 272 PE S means that on receiving a packet with label L', S makes n copies 273 of the packet. For copy i of the packet, S swaps L' with Li and 274 sends it out over interface Ii. 276 The procedures below are organized by the role which the PE plays in 277 the P2MP MS-PW. T-PE Z knows that it is an Egress T-PE by a discovery 278 process which is outside the scope of this document. A T-PE is 279 defined as an Egress T-PE if one or several leaf AIIs are configured. 280 During the course of protocol operation, the Ingress T-PE recognizes 281 its role because it owns the SAII of the PW tree. 283 10.1. Label Map 285 The following lists procedures for generating and processing P2MP 286 Label Map messages for PEs participating in a P2MP MS-PW. 288 For the approach described here we use downstream assigned labels. 290 10.1.1. Determining one's 'upstream PE' 292 For the case of P2MP MS-PW with dynamic S-PE routing, a a PE Z that 293 is part of P2MP MS-PW determines the T-LDP peer U which lies 294 on the best path from Z to the SAII. The path selection is achieved 295 by means of looking up the AII PW routing table. U is Z's "Upstream 296 PE" for . 298 10.1.2. Egress T-PE Operation 300 An Egress T-PE Z of P2MP MS-PW determines its upstream PE U 301 for , allocates a label L, and sends a P2MP PW Label Map to U. 304 10.1.3. Branch S-PE Operation 306 Suppose a branch S-PE Z receives a P2MP PW Label Map from 307 LDP peer T. Z checks whether it already has state for . If 308 not, Z allocates a label L', and installs state to swap L' with L 309 over interface I associated with peer T. Z also determines its 310 upstream PE U for and sends a P2MP PW Label Map to 311 U. 313 If Z already has state for , then Z does not send a Label Map 314 message for P2MP MS-PW . All that Z needs to do in this case 315 is to update its forwarding state. Assuming its old forwarding state 316 was L'-> { ..., }, its new forwarding state 317 becomes L'-> { ..., , }. 319 10.1.4. Ingress T-PE Operation 321 Suppose the Ingress T-PE Z receives a P2MP Label Map from 322 peer T. Z checks whether it already has forwarding state for . 324 If not, Z creates forwarding state to push label L onto the traffic 325 that Z wants to forward over the P2MP MS-PW. 327 If Z already has forwarding state for , then Z adds "push label 328 L, send over interface I" to the nexthop, where I is the interface 329 associated with peer T. 331 10.2. Label Withdraw 333 The following lists procedures for generating and processing P2MP PW 334 Label Withdraw messages for PEs that participate in a P2MP MS-PW. 336 10.2.1. Egress T-PE Operation 338 If an Egress T-PE Z discovers that it has no longer leaves AII 339 belonging to the P2MP MS-PW, it SHOULD send a P2MP PW Label Withdraw 340 to its upstream PE U for , where L is the label it 341 had previously advertised to U for . 343 10.2.2. Branch S-PE Operation 345 If a branch S-PE Z receives a P2MP PW Label Withdraw message from a node W, it deletes label L from its forwarding state, and 347 sends a P2MP PW Label Release message with label L to W. 349 If deleting L from Z's forwarding state for P2MP MS-PW results 350 in no state remaining for , then Z propagates the P2MP PW Label 351 Withdraw for , to its upstream T, by sending a P2MP PW Label 352 Withdraw where L1 is the label Z had previously advertised 353 to T for . 355 10.2.3. Ingress T-PE Operation 357 The procedure when the Ingress T-PE of a P2MP MS-PW receives a P2MP 358 PW Label Withdraw message are the same as for branch S-PE, except 359 that it would not propagate the P2MP PW Label Withdraw upstream (as 360 it has no upstream). 362 10.2.4. Upstream PE Change 364 If, for a given PE Z participating in a P2MP MS-PW , the 365 upstream PE changes, say from U to U', then Z MUST update its 366 forwarding state by deleting the state for label L, allocating a new 367 label, L', for , and installing the forwarding state for L'. In 368 addition Z MUST send a P2MP PW Label Map to U' and send a 369 P2MP PW Label Withdraw to U. 371 11. Security Considerations 373 This section will be added in a future version. 375 12. IANA Considerations 377 This draft does not define any new protocol element, and hence does 378 not require any IANA action. 380 13. Acknowledgments 382 14. References 384 14.1. Normative References 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, March 1997. 389 [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., 390 Thomas, B., "LDP Specification", October 2007. 392 [RFC3985] Bryant, S., Pate, P. "PWE3 Architecture", March 2005 394 [RFC5254] Bitar, N., Bocci, M., and Martini, L., "Requirements for 395 inter domain Pseudo-Wires", October 2008 397 14.2. Informative References 399 [P2MP PW REQ] Jounay, F., Niger, P., Kamite, Y., Martini, L., 400 Heron, G., Wang, L., Delord, .S, "Use Cases and 401 signaling requirements for Point-to-Multipoint 402 PW", Internet Draft, draft-ietf-pwe3-p2mp-pw- 403 requirements-02.txt, January 2010 405 [DYN MS-PW] Balus, F., Bocci, M., Martini. L, "Dynamic 406 Placement of Multi Segment Pseudo Wires", 407 Internet Draft, draft-ietf-pwe3-dynamic-ms-pw- 408 10.txt, October 2009 410 [SEGMENT MS-PW] Martini, L, &all, "Segmented Pseudowire", 411 Internet Draft, draft-ietf-pwe3-segmented-pw- 412 15.txt, June 2010 414 [MLDP] Minei, I., Kompella, K., Thomas, B., Wijnands, 415 I. "Label Distribution Protocol Extensions for 416 Point-to-Multipoint and Multipoint-to-Multipoint 417 Label Switched Paths", Internet Draft, draft- 418 ietf-mpls-ldp-p2mp-10, July 2010 420 [ROOT INIT P2MP PW] Martini, L., Jounay, &all , "Signaling 421 Root-Initiated Point-to-Multipoint 422 Pseudowires using LDP", draft-martini- 423 pwe3-p2mp-pw-01, October, 2009 425 Author's Addresses 427 Frederic Jounay 428 France Telecom 429 2, avenue Pierre-Marzin 430 22307 Lannion Cedex 431 FRANCE 432 Email: frederic.jounay@orange-ftgroup.com 434 Jean-Louis Le Roux 435 France Telecom 436 2, avenue Pierre-Marzin 437 22307 Lannion Cedex 438 FRANCE 439 Email: jeanlouis.leroux@orange-ftgroup.com 441 Philippe Niger 442 France Telecom 443 2, avenue Pierre-Marzin 444 22307 Lannion Cedex 445 FRANCE 446 Email: philippe.niger@orange-ftgroup.com 448 Yuji Kamite 449 NTT Communications Corporation 450 Tokyo Opera City Tower 451 3-20-2 Nishi Shinjuku, Shinjuku-ku 452 Tokyo 163-1421 453 Japan 454 Email: y.kamite@ntt.com 456 Lizhong Jin 457 ZTE Corporation 458 889, Bibo Road 459 Shanghai, 201203, China 460 Email: lizhong.jin@zte.com.cn 462 Copyright Notice 464 Copyright (c) 2010 IETF Trust and the persons identified as the 465 document authors. All rights reserved. 467 This document is subject to BCP 78 and the IETF Trust's Legal 468 Provisions Relating to IETF Documents 469 (http://trustee.ietf.org/license-info) in effect on the date of 470 publication of this document. Please review these documents 471 carefully, as they describe your rights and restrictions with respect 472 to this document. Code Components extracted from this document must 473 include Simplified BSD License text as described in Section 4.e of 474 the Trust Legal Provisions and are provided without warranty as 475 described in the Simplified BSD License. 477 This document may contain material from IETF Documents or IETF 478 Contributions published or made publicly available before November 479 10, 2008. The person(s) controlling the copyright in some of this 480 material may not have granted the IETF Trust the right to allow 481 modifications of such material outside the IETF Standards Process. 482 Without obtaining an adequate license from the person(s) controlling 483 the copyright in such materials, this document may not be modified 484 outside the IETF Standards Process, and derivative works of it may 485 not be created outside the IETF Standards Process, except to format 486 it for publication as an RFC or to translate it into languages other 487 than English.