idnits 2.17.1 draft-ietf-pals-p2mp-pw-00.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 date (March 21, 2016) is 2952 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) == Missing Reference: 'P2MP-PW-REQ' is mentioned on line 143, but not defined == Missing Reference: 'L3VPN-MCAST' is mentioned on line 352, but not defined == Missing Reference: 'PW-TWC-FEC' is mentioned on line 466, but not defined == Missing Reference: 'P2MP-LSP-PING' is mentioned on line 575, but not defined == Unused Reference: 'RFC6514' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'RFC 6667' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'RFC7338' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'RFC6425' is defined on line 693, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Siva Sivabalan(Ed.) 3 Intended Status: Standard Track Cisco Systems 5 Sami Boutros(Ed.) 6 VMware 8 Frederic Jounay Luca Martini 9 Philippe Niger Maciek Konstantynowicz 10 France Telecom Cisco Systems 12 Thomas D. Nadeau Gianni Del Vecchio 13 Brocade Swisscom 15 Simon Delord Yuji Kamite 16 Telstra NTT Communications 18 Laurent Ciavaglia Lizhong Jin 19 Martin Vigoureux ZTE 20 Alcatel-Lucent 22 Expires: September 22, 2016 March 21, 2016 24 Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP 25 draft-ietf-pals-p2mp-pw-00.txt 27 Abstract 29 This document specifies a mechanism to signal Point-to-Multipoint 30 (P2MP) Pseudowires (PW) tree using LDP. Such a mechanism is suitable 31 for any Layer 2 VPN service requiring P2MP connectivity over an IP or 32 MPLS enabled PSN. A P2MP PW established via the proposed mechanism is 33 root initiated. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as 43 Internet-Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/1id-abstracts.html 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html 56 Copyright and License Notice 58 Copyright (c) 2016 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 75 2. Signaling P2MP PW . . . . . . . . . . . . . . . . . . . . . . . 5 76 2.1 PW ingress to egress incompatibility issues . . . . . . . . 7 77 2.2 P2MP PW FEC . . . . . . . . . . . . . . . . . . . . . . . . 7 78 2.3 Typed Wildcard FEC Format for new FEC . . . . . . . . . . . 11 79 2.4 Group ID usage . . . . . . . . . . . . . . . . . . . . . . . 12 80 2.5 Generic Label TLV . . . . . . . . . . . . . . . . . . . . . 12 81 3. LDP Capability Negotiation . . . . . . . . . . . . . . . . . . 12 82 4. P2MP PW Status . . . . . . . . . . . . . . . . . . . . . . . . 13 83 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 84 6 Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 86 7.1. FEC Type Name Space . . . . . . . . . . . . . . . . . . . . 14 87 7.2. LDP TLV Type . . . . . . . . . . . . . . . . . . . . . . . 14 88 7.3. mLDP Opaque Value Element TLV Type . . . . . . . . . . . . 15 89 7.4. Selective Tree Interface Parameter sub-TLV Type . . . . . . 15 90 7.5. WildCard PMSI tunnel type. . . . . . . . . . . . . . . . . 15 91 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 93 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 96 1 Introduction 98 A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the essential 99 attributes of a unidirectional P2MP Telecommunications service such 100 as P2MP ATM over PSN. A major difference between a Point-to-Point 101 (P2P) PW outlined in [RFC3985] and a P2MP PW is that the former is 102 intended for bidirectional service whereas the latter is intended for 103 both unidirectional, and optionally bidirectional service. 104 Requirements for P2MP PW are described in [P2MP-PW-REQ]. P2MP PW can 105 be constructed as either Single Segment (P2MP SS-PW) or Multi Segment 106 (P2MP MS-PW) Pseudowires as mentioned in [P2MP-PW-REQ]. P2MP MS-PW is 107 outside the scope of this document. A reference model for P2MP PW is 108 depicted in Figure 1 below. A transport LSP associated with a P2MP 109 SS-PW SHOULD be a P2MP MPLS LSP (i.e., P2MP TE tunnel established via 110 RSVP-TE [RFC4875] or P2MP LSP established via mLDP [RFC6388]) 111 spanning from the Root-PE to the Leaf-PE(s) of the P2MP SS-PW tree. 112 For example, in Figure 1, PW1 can be associated with a P2MP TE tunnel 113 or P2MP LSP setup using mLDP originating from PE1 and terminating at 114 PE2 and PE3. 116 |<--------------P2MP PW---------------->| 117 Native | | Native 118 Service | |<--PSN1->| |<--PSN2->| | Service 119 (AC) V V V V V V (AC) 120 | +-----+ +------+ +------+ | 121 | | | | P1 |=========|T-PE2 |AC3 | +---+ 122 | | | | .......PW1.........>|-------->|CE3| 123 | |T-PE1|=========| . |=========| | | +---+ 124 | | .......PW1........ | +------+ | 125 | | . |=========| . | +------+ | 126 | | . | | . |=========|T-PE3 |AC4 | +---+ 127 +---+ |AC1 | . | | .......PW1.........>|-------->|CE4| 128 |CE1|------->|... | | |=========| | | +---+ 129 +---+ | | . | +------+ +------+ | 130 | | . | +------+ +------+ | 131 | | . |=========| P2 |=========|T-PE4 |AC5 | +---+ 132 | | .......PW1..............PW1.........>|-------->|CE5| 133 | | |=========| |=========| | | +---+ 134 | +-----+ +------+ +------+ | 136 Figure 1: P2MP PW 138 Mechanisms for establishing P2P SS-PW using LDP are described in 139 [RFC4447]. In this document, we specify a method to signal P2MP PW 140 using LDP. In particular, we define new FEC, TLVs, parameters, and 141 status codes to facilitate LDP to signal and maintain P2MP PWs. 143 As outlined in [P2MP-PW-REQ], even though the traffic flow from a 144 Root-PE (R-PE) to Leaf-PE(s) (L-PEs) is P2MP in nature, it may be 145 desirable for any L-PE to send unidirectional P2P traffic destined 146 only to the R-PE. The proposed mechanism takes such option into 147 consideration. 149 The P2MP PW requires an MPLS LSP to carry the PW traffic, and the 150 MPLS packets carried over the PW will be encapsulated according to 151 the methods described in [RFC5332]. 153 1.1 Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 FEC: Forwarding Equivalence Class 161 LDP: Label Distribution Protocol 163 mLDP: Label Distribution Protocol for P2MP/MP2MP LSP 165 LSP: Label Switching Path 167 MS-PW: Multi-Segment Pseudowire 169 P2P: Point to Point 171 P2MP: Point to Multipoint 173 PE: Provider Edge 175 PSN: Packet Switched Network 177 PW: Pseudowire 179 SS-PW: Single-Segment Pseudowire 181 S-PE: Switching Provider Edge Node of MS-PW 183 TE: Traffic Engineering 185 R-PE: Root-PE - ingress PE, PE initiating P2MP PW setup. 187 L-PE: Leaf-PE - egress PE. 189 2. Signaling P2MP PW 190 In order to advertise labels as well as exchange PW related LDP 191 messages, PEs must establish LDP sessions among themselves using the 192 Extended Discovery Mechanisms. A PE discovers other PEs that are to 193 be connected via P2MP PWs either via manual configuration or 194 autodiscovery [RFC6074]. 196 R-PE and each L-PE MUST be configured with the same FEC as defined in 197 the following section. 199 P2MP PW requires that there is an active P2MP PSN LSP set up between 200 R-PE and L-PE(s). Note that the procedure to set up the P2MP PSN LSP 201 is different depending on the signaling protocol used (RSVP-TE or 202 mLDP). 204 In case of mLDP, a Leaf-PE can decide to join the P2MP LSP at any 205 time; whereas in the case of RSVP-TE, the P2MP LSP is set up by the 206 R-PE, generally at the initial service provisioning time. It should 207 be noted that local policy can override any decision to join, add or 208 prune existing or new L-PE(s) from the tree. In any case, the PW 209 setup can ignore these differences, and simply assume that the P2MP 210 PSN LSP is available when needed. 212 A P2MP PW signaling is initiated by the R-PE simply by sending a 213 P2MP-PW LDP label mapping message to the L-PE(s) belonging to that 214 P2MP PW. This label mapping message will contain the following: 215 1. A FEC TLV containing P2MP PW Upstream FEC element that 216 includes Transport LSP sub TLV. 217 2. An Interface Parameters TLV, as described in [RFC4447]. 218 3. A PW Grouping TLV, as described in [RFC4447]. 219 4. A label TLV for the upstream-assigned label used by R-PE 220 for the traffic going from R-PE to L-PE(s). 222 The R-PE imposes the upstream-assigned label on the outbound packets 223 sent over the P2MP-PW, and using this label an L-PE identifies the 224 inbound packets arriving over the P2MP PW. 226 Additionally, the R-PE MAY send label mapping message(s) to one or 227 more L-PE(s) to signal unidirectional P2P PW(s). The L-PE(s) can use 228 such PW(s) to send traffic to the R-PE. This optional label mapping 229 message will contain the following: 231 1. P2P PW Downstream FEC element. 232 2. A label TLV for the down-stream assigned label used by the 233 corresponding L-PE to send traffic to the R-PE. 235 The LDP liberal label retention mode is used, and per requirements 236 specified in [RFC5036], the Label Request message MUST also be 237 supported. 239 The upstream-assigned label is allocated according to the rules in 240 [RFC5331]. 242 When an L-PE receives a PW Label Mapping Message, it MUST verify the 243 associated P2MP PSN LSP is in place. If the associated P2MP PSN LSP 244 is not in place, and its type is LDP P2MP LSP, the L-PE SHOULD 245 attempt to join the P2MP LSP associated with the P2MP PW. If the 246 associated P2MP PSN LSP is not in place, and its type is RSVP-TE P2MP 247 LSP, the L-PE SHOULD wait till the P2MP transport LSP is signaled. 249 2.1 PW ingress to egress incompatibility issues 251 If an R-PE signals a PW with a pw type, CW mode, or interface 252 parameters that a particular L-PE cannot accept, then the L-PE must 253 not enable the PW, and notify the user. In this case, a PW status 254 message with status code of 0x00000001 (Pseudowire Not Forwarding) 255 MUST also be sent to the R-PE. 257 Note that this procedure does not apply if the L-PE had not been 258 provisioned with this particular P2MP PW. In this case according to 259 the LDP liberal label retention rules, no action is taken. 261 2.2 P2MP PW FEC 263 [RFC4447] specifies two types of LDP FEC elements called "PWid FEC 264 Element" and "Generalized PWid FEC Element" used to signal P2P PWs. 265 We define two new types of FEC elements called "P2MP PW Upstream FEC 266 Element" and "P2P PW Downstream FEC Element". These FEC elements are 267 associated with a mandatory upstream assigned label and an optional 268 downstream assigned label respectively. 270 FEC type of the P2MP PW Upstream FEC Element is 0x82 (pending IANA 271 allocation) and is encoded as follows: 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | P2MP PW Up |C| PW Type | PW Info Length| 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | AGI Type | Length | AGI Value | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 ~ AGI Value (contd.) ~ 281 | | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | AII Type | Length | SAII Value | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 ~ SAII Value (contd.) ~ 286 | | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 |PMSI Tunnel typ| Length | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 290 + + 291 ~ Transport LSP ID ~ 292 | | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | | 295 | Optional Parameters | 296 ~ ~ 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 2: P2MP PW Upstream FEC Element 301 * PW Type: 303 15-bit representation of PW type, and the assigned values are 304 assigned by IANA. 306 * C bit: 308 A value of 1 or 0 indicates whether control word is present or 309 absent for the P2MP PW. 311 * PW Info Length: 313 Sum of the lengths of AGI, SAII, PMSI Tunnel info, and Optional 314 Parameters field in octets. If this value is 0, then it references 315 all PWs using the specified grouping ID. In this case, there are 316 neither other FEC element fields (AGI, SAII, etc.) present, nor any 317 interface parameters TLVs. Alternatively, we can use typed WC FEC 318 described in section 3.3 to achieve the same or to have better 319 filtering. 321 * AGI: 323 Attachment Group Identifier can be used to uniquely identify VPN or 324 VPLS instance associated with the P2MP PW. This has the same format 325 as the Generalized PWid FEC element [RFC4447]. 327 * SAII: 329 Source Attachment Individual Identifier is used to identify the root 330 of the P2MP PW. The root is represented using AII type 2 format 331 specified in [RFC5003]. Note that the SAII can be omitted by simply 332 setting the length and type to zero. 334 P2MP PW is identified by the Source Attachment Identifier (SAI). If 335 the AGI is non-null, the SAI is the combination of the SAII and the 336 AGI, if the AGI is null, the SAI is the SAII. 338 * PMSI Tunnel Type and Transport LSP ID: 340 A P2MP PW MUST be associated with a transport LSP which can be 341 established using RSVP-TE or mLDP. 343 * PMSI Tunnel Type: 345 The PMSI tunnel type is defined in [L3VPN-MCAST]. 347 When the type is set to mLDP P2MP LSP, the Tunnel Identifier is a 348 P2MP FEC Element as defined in [RFC6388]. A new mLDP Opaque Value 349 Element type for L2VPN-MCAST application needs to be allocated. 351 * Transport LSP ID: This is the Tunnel Identifier which is defined in 352 [L3VPN-MCAST]. 354 An R-PE sends Label Mapping Message as soon as the transport LSP ID 355 associated with the P2MP PW is known (e.g., via configuration) 356 regardless of the operational state of that transport LSP. Similarly, 357 an R-PE does not withdraw the labels when the corresponding transport 358 LSP goes down. Furthermore, an L-PE retains the P2MP PW labels 359 regardless of the operational status of the transport LSP. 361 Note that a given transport LSP can be associated with more than one 362 P2MP PWs and all P2MP PWs will be sharing the same R-PE and L-PE(s). 364 In the case of LDP P2MP LSP, when an L-PE receives the Label Mapping 365 Message, it can initiate the process of joining the P2MP LSP tree 366 associated with the P2MP PW. 368 In the case of RSVP-TE P2MP LSP, only the R-PE initiates the 369 signaling of P2MP LSP. 371 * Optional Parameters: 373 The Optional Parameter field can contain some TLVs that are not part 374 of the FEC, but are necessary for the operation of the PW. This 375 proposed mechanism uses two such TLVs: Interface Parameters TLV, and 376 Group ID TLV. 378 The Interface Parameters TLV and Group ID TLV specified in [RFC4447] 379 can also be used in conjunction with P2MP PW FEC in alabel message. 380 For Group ID TLV, the sender and receiver of these TLVs should follow 381 the same rules and procedures specified in [RFC4447]. For Interface 382 Parameters TLV, the procedure differs from the one specified in 383 [RFC4447] due to specifics of P2MP connectivity. When the interface 384 parameters are signaled by a R-PE, each L-PE must check if its 385 configured value(s) is less than or equal to the threshold value 386 provided by the R-PE (e.g. MTU size (Ethernet), max number of 387 concatenated ATM cells, etc)). For other interface parameters like 388 CEP/TDM Payload bytes (TDM), the value MUST exactly match the values 389 signaled by the R-PE. 391 Multicast traffic stream associated with a P2MP PW can be selective 392 or inclusive. To support the former, this document defines a new 393 optional Selective Tree Interface Parameter sub-TLV (type is pending 394 IANA allocation) according to the format described in [RFC4447]. The 395 value of the sub-TLV contains the source and the group for a given 396 multicast tree as shown in Figure 3. Also, if a P2MP PW is associated 397 with multiple selective trees, the corresponding label mapping 398 message will carry more than one instance of this Sub-TLV. 399 Furthermore, in the absence of this sub-TLV, the P2MP PW is 400 associated with all multicast traffic stream originating from the 401 root. 403 +----------------------------------------- + 404 | Multicast Source Length (1 Octet) | 405 +----------------------------------------- + 406 | Multicast Source (variable length) | 407 +----------------------------------------- + 408 | Multicast Group Length (1 Octet) | 409 +----------------------------------------- + 410 | Multicast Group (variable length) | 411 +----------------------------------------- + 413 Figure 3: Selective Tree Interface Parameter Sub-TLV Value 415 Note that since the LDP label mapping message is only sent by the R- 416 PE to all the L-PEs, it is not possible to negotiate any interface 417 parameters. 419 The type of optional P2P PW Downstream FEC Element is 0x83 (pending 420 IANA allocation), and is encoded as follows: 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | P2P PW Down |C| PW Type | PW Info Length| 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | AGI Type | Length | AGI Value | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 ~ AGI Value (contd.) ~ 430 | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | AII Type | Length | SAII Value | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 ~ SAII Value (contd.) ~ 435 | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 Figure 4: P2P PW Downstream FEC Element 440 The definition of the fields in the P2P PW Downstream FEC Element is 441 the same as those of P2MP PW Upstream FEC Element. 443 2.3 Typed Wildcard FEC Format for new FEC 445 [RFC5918] defines the general notion of a "Typed Wildcard" FEC 446 Element, and requires FEC designer to specify a typed wildcard FEC 447 element for newly defined FEC element types. This document defines 448 two new FEC elements, "P2MP PW Upstream" and "P2P PW Downstream" FEC 449 element, and hence requires us to define their Typed Wildcard format. 451 [PW-TWC-FEC] defines Typed Wildcard FEC element format for other PW 452 FEC Element types (PWid and Gen. PWid FEC Element) in section 2 as 453 follows: 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 |Typed Wcard=0x5|Type=PW FEC| Len = 3 |R| PW type | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | . . . | PMSI Tun Type | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Figure 5: Typed Wildcard Format for P2MP PW FEC Elements 464 [PW-TWC-FEC] specifies that "Type" field can be either "PWid" (0x80) 465 or "Generalized PWid" (0x81) FEC element type. This document reuses 466 the existing typed wildcard format as specified in [PW-TWC-FEC] and 467 illustrated in Figure 5. We extend the definition of "Type" field to 468 also include "P2MP PW Upstream" and "P2P PW Downstream" FEC element 469 types, as well as add an additional field "PMSI Tun Type". We reserve 470 PMSI tunnel Type 0xFF to mean "wildcard" transport tunnel type. This 471 "wildcard" transport tunnel type can be used in a typed wildcard p2mp 472 FEC for further filtering. This field only applies to Typed wildcard 473 P2MP PW Upstream FEC and MUST be set to "wildcard" for "P2P PW 474 Downstream FEC" typed wildcard element. 476 2.4 Group ID usage 478 The Grouping TLV as defined in [RFC4447] contains a group ID capable 479 of indicating an arbitrary group membership of a P2MP-PW. This group 480 ID can be used in LDP "wild card" status, and withdraw label 481 messages, as described in [RFC4447]. 483 2.5 Generic Label TLV 485 As in the case of P2P PW signaling, P2MP PW labels are carried within 486 Generic Label TLV contained in LDP Label Mapping Message. A Generic 487 Label TLV is formatted and processed as per the rules and procedures 488 specified in [RFC4447]. For a given P2MP PW, a single upstream- 489 assigned label is allocated by the R-PE, and is advertised to all L- 490 PEs using the Generic Label TLV in label mapping message containing 491 the P2MP PW Upstream FEC element. 493 The R-PE can also allocate a unique label for each L-PE from which it 494 intends to receive P2P traffic. Such a label is advertised to the L- 495 PE using Generic Label TLV and P2P PW Downstream FEC in label mapping 496 message. 498 3. LDP Capability Negotiation 500 The capability of supporting P2MP PW must be advertised to all LDP 501 peers. This is achieved by using the methods in [RFC5561] and 502 advertising the LDP "P2MP PW Capability" TLV. If an LDP peer supports 503 the dynamic capability advertisement, this can be done by sending a 504 new Capability message with the S bit set for the P2MP PW capability 505 TLV. If the peer does not supports dynamic capability advertisement, 506 then the P2MP PW Capability TLV MUST be included in the LDP 507 Initialization message during the session establishment. An LSR 508 having P2MP PW capability MUST recognize both P2MP PW Upstream FEC 509 Element and P2P PW Downstream FEC Element in LDP label messages. 511 In line with requirements listed in [RFC5561], the following TLV is 512 defined to indicate the P2MP PW capability: 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 |U|F| P2MP PW Capability (0x703)| Length | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 |S| Reserved | Reserved | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 Figure 7: LDP P2MP PW Capability TLV 524 Note: TLV number pending IANA allocation. 526 * U-bit: 528 SHOULD be 1 (ignore if not understood). 530 * F-bit: 532 SHOULD be 0 (don't forward if not understood). 534 * P2MP PW Capability TLV Code Point: 536 The TLV type, which identifies a specific capability. The P2MP PW 537 capability code point is requested in the IANA allocation section 538 below. 540 * S-bit: 542 The State Bit indicates whether the sender is advertising or 543 withdrawing the P2MP PW capability. The State bit is used as 544 follows: 545 1 - The TLV is advertising the capability specified by the 546 TLV Code Point. 548 0 - The TLV is withdrawing the capability specified by the 549 TLV Code Point. 551 * Length: 553 MUST be set to 2 (octet). 555 4. P2MP PW Status 556 In order to support the proposed mechanism, a node MUST be capable of 557 handling PW status. As such, PW status negotiation procedure 558 described in [RFC4447] is not applicable to P2MP PW. 560 Once an L-PE successfully processes a Label Mapping Message for a 561 P2MP PW, it MUST send appropriate PW status according to the 562 procedure specified [RFC4447] to notify the PW status. If there is no 563 PW status notification required, then no PW status notification is 564 sent (for example if the P2MP PW is established and operational with 565 a status code of Success (0x00000000), pw status message is not 566 necessary). PW status message sent from any L-PE to R-PE contains P2P 567 PW Downstream FEC to identify the PW. 569 An R-PE also sends PW status to L-PE(s) to reflect its view of a P2MP 570 PW state. Such PW status message contains P2MP PW Upstream FEC to 571 identify the PW. 573 Connectivity status of the underlying P2MP LSP that P2MP PW is 574 associated with, can be verified using LSP Ping and Traceroute 575 procedures described in [P2MP-LSP-PING]. 577 5 Security Considerations 579 The security measures described in [RFC4447] is adequate for the 580 proposed mechanism. 582 6 Acknowledgment 584 Authors would like thank Andre Pelletier and Parag Jain for their 585 valuable suggestions. 587 7 IANA Considerations 589 7.1. FEC Type Name Space 591 This document uses two new FEC element types, number 0x82 and 0x83 592 will be requested as an allocation from the registry "FEC Type Name 593 Space" for the Label Distribution Protocol (LDP RFC5036): 595 Value Hex Name Reference 596 ------- ----- ----------------------------- --------- 597 130 0x82 P2MP PW Upstream FEC Element RFCxxxx 598 131 0x83 P2P PW Downstream FEC Element RFCxxxx 600 7.2. LDP TLV Type 602 This document uses a new LDP TLV types, IANA already maintains a 603 registry of name "TLV TYPE NAME SPACE" defined by RFC5036. The 604 following values are suggested for assignment: 606 TLV type Description: 608 0x0703 P2MP PW Capability TLV 610 7.3. mLDP Opaque Value Element TLV Type 612 This document requires allocation of a new mLDP Opaque Value Element 613 Type from the LDP MP Opaque Value Element type name space defined in 614 [mLDP]. 616 The following value is suggested for assignment: 618 TLV type Description 619 0x3 L2VPN-MCAST application TLV 621 7.4. Selective Tree Interface Parameter sub-TLV Type 623 This document requires allocation of a sub-TLV from the registry 624 "Pseudowire Interface Parameters Sub-TLV Type". 626 The following value is suggested for assignment: 628 TLV type Description 629 0x0D Selective Tree Interface Parameter. 631 7.5. WildCard PMSI tunnel type. 633 This document requires the allocation of PMSI tunnel Type 0xFF to 634 mean wildcard transport tunnel type 636 8 References 638 8.1. Normative References 640 [RFC2119] Bradner. S, "Key words for use in RFCs to Indicate 641 Requirement Levels", RFC 2119, March, 1997. 643 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., et 644 al., RFC 4447, April 2006. 646 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 647 Specification", RFC 5036, October 2007. 649 [RFC5003] C. Metz, L. Martini, F. Balus, J. Sugimoto, "Attachment 650 Individual Identifier (AII) Types for Aggregation", RFC5003, 651 September 2007. 653 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 654 Assignment and Context-Specific Label Space", RFC 5331, August 2008. 656 [RFC5332] T. Eckert, E. Rosen, Ed.,R. Aggarwal, Y. Rekhter, "MPLS 657 Multicast Encapsulations", RFC 5332, August 2008. 659 [RFC6388] I. Minei, K. Kompella, I. Wijnands, B. Thomas, "Label 660 Distribution Protocol Extensions for Point-to-Multipoint and 661 Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 662 2011. 664 [RFC4875] R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed., 665 "Extensions to Resource Reservation Protocol - Traffic Engineering 666 (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs).", 667 RFC 4875, May 2007. 669 [RFC6514] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, "BGP Encodings 670 and Procedures for Multicast in MPLS/BGP IP VPNs", RFC6514, February 671 2012. 673 [RFC5561] B.Thomas, K.Raza, S.Aggarwal, R.Agarwal, JL. Le Roux, "LDP 674 Capabilities", RFC 5561, July 2009. 676 [RFC5918] R. Asati, I. Minei, and B. Thomas, "LDP Typed Wildcard 677 Forwarding Equivalence Class", RFC 5918, August 2010. 679 [RFC 6667] K. Raza, S. Boutros, and C. Pignataro, "LDP Typed Wildcard 680 FEC for PWid and Generalized PWid FEC Elements", RFC 6667, July 2012. 682 8.2. Informative References 684 [RFC3985] Stewart Bryant, et al., "PWE3 Architecture", RFC3985 686 [RFC6074] E. Rosen,W. Luo,B. Davie,V. Radoaca "Provisioning, Auto- 687 Discovery, and Signaling in Layer 2 Virtual Private Networks 688 (L2VPNs)", RFC6074, January 2011. 690 [RFC7338] F. Jounay, et. al, "Requirements for Point to Multipoint 691 Pseudowire", RFC7338, September 2014. 693 [RFC6425] A. Farrel, S. Yasukawa, "Detecting Data Plane Failures in 694 Point-to-Multipoint Multiprotocol Label Switching (MPLS)- Extensions 695 to LSP Ping", RFC6425, November 2011. 697 Authors' Addresses 699 Siva Sivabalan 700 Cisco Systems, Inc. 701 Email: msiva@cisco.com 703 Sami Boutros 704 VMware Inc. 705 Email: sboutros@vmware.com 707 Luca Martini 708 Cisco Systems, Inc. 709 Email: lmartini@cisco.com 711 Maciek Konstantynowicz 712 Cisco Systems, Inc. 713 e-mail: maciek@cisco.com 715 Gianni Del Vecchio 716 Swisscom 717 Email: Gianni.DelVecchio@swisscom.com 719 Thomas D. Nadeau 720 Brocade 721 Email: tnadeau@lucidvision.com 723 Frederic Jounay 724 France Telecom 725 Email: frederic.jounay@orange-ftgroup.com 727 Philippe Niger 728 France Telecom 729 Email: philippe.niger@orange-ftgroup.com 731 Yuji Kamite 732 NTT Communications Corporation 733 Email: y.kamite@ntt.com 735 Lizhong Jin 736 ZTE 737 Email: lizhong.jin@zte.com.cn 739 Martin Vigoureux 740 Alcatel-Lucent 741 Email: martin.vigoureux@alcatel-lucent.com 743 Laurent Ciavaglia 744 Alcatel-Lucent 745 Email: Laurent.Ciavaglia@alcatel-lucent.com 747 Simon Delord 748 Alcatel-Lucent 749 E-mail: simon.a.delord@team.telstra.com 751 Kamran Raza 752 Cisco Systems 753 Email: skraza@cisco.com