idnits 2.17.1 draft-ietf-pals-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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document updates RFC7385, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 635 has weird spacing: '...egistry withi...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When an L-PE receives a PW Label Mapping Message, it MUST verify the associated P2MP PSN LSP is in place. If the associated P2MP PSN LSP is not in place, and its type is LDP P2MP LSP, the L-PE MUST attempt to join the P2MP LSP associated with the P2MP PW. If the associated P2MP PSN LSP is not in place, and its type is RSVP-TE P2MP LSP, the L-PE SHOULD wait till the P2MP transport LSP is signaled. If an L-PE fails to join the P2MP PSN LSP, that L-PE MUST not enable the PW, and MUST notify the user. In this case, a PW status message with status code of 0x00000008 (Local PSN-facing PW (ingress) Receive Fault) MUST also be sent to the R-PE. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If an R-PE signals a PW with a pw type, CW mode, or interface parameters that a particular L-PE cannot accept, then the L-PE MUST not enable the PW, and notify the user. In this case, a PW status message with status code of 0x00000001 (Pseudowire Not Forwarding) MUST also be sent to the R-PE. -- The document date (January 5, 2017) is 2666 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: 'RFC4446' is mentioned on line 624, but not defined -- Possible downref: Normative reference to a draft: ref. 'RFC4447bis' Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). 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 Updates: RFC7385 Sami Boutros(Ed.) 6 VMware 8 Expires: July 9, 2017 January 5, 2017 10 Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP 11 draft-ietf-pals-p2mp-pw-02.txt 13 Abstract 15 This document specifies a mechanism to signal Point-to-Multipoint 16 (P2MP) Pseudowires (PW) tree using LDP. Such a mechanism is suitable 17 for any Layer 2 VPN service requiring P2MP connectivity over an IP or 18 MPLS enabled PSN. A P2MP PW established via the proposed mechanism is 19 root initiated. This document updates RFC7385 by re-assigning 20 reserved value 0xFF to be the wildcard transport tunnel type. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Signaling P2MP PW . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1 PW ingress to egress incompatibility issues . . . . . . . . 6 63 2.2 P2MP PW FEC . . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3 Typed Wildcard FEC Format for new FEC . . . . . . . . . . . 10 65 2.4 Group ID usage . . . . . . . . . . . . . . . . . . . . . . . 11 66 2.5 Generic Label TLV . . . . . . . . . . . . . . . . . . . . . 11 67 3. LDP Capability Negotiation . . . . . . . . . . . . . . . . . . 11 68 4. P2MP PW Status . . . . . . . . . . . . . . . . . . . . . . . . 13 69 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 70 6 Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 72 7.1. FEC Type Name Space . . . . . . . . . . . . . . . . . . . . 13 73 7.2. LDP TLV Type . . . . . . . . . . . . . . . . . . . . . . . 14 74 7.3. mLDP Opaque Value Element TLV Type . . . . . . . . . . . . 14 75 7.4. Selective Tree Interface Parameter sub-TLV Type . . . . . . 14 76 7.5. WildCard PMSI tunnel type . . . . . . . . . . . . . . . . . 14 77 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 80 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 83 1 Introduction 85 A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the essential 86 attributes of a unidirectional P2MP Telecommunications service such 87 as P2MP ATM over PSN. A major difference between a Point-to-Point 88 (P2P) PW outlined in [RFC3985] and a P2MP PW is that the former is 89 intended for bidirectional service whereas the latter is intended for 90 both unidirectional, and optionally bidirectional service. 91 Requirements for P2MP PW are described in [RFC7338]. P2MP PW can be 92 constructed as either Single Segment (P2MP SS-PW) or Multi Segment 93 (P2MP MS-PW) Pseudowires as mentioned in [RFC7338]. P2MP MS-PW is 94 outside the scope of this document. A reference model or a P2MP PW is 95 depicted in Figure 1 below. A transport LSP associated with a P2MP 96 SS-PW SHOULD be a P2MP MPLS LSP (i.e., P2MP TE tunnel established via 97 RSVP-TE [RFC4875] or P2MP LSP established via mLDP [RFC6388]) 98 spanning from the Root-PE to the Leaf-PE(s) of the P2MP SS-PW tree. 99 For example, in Figure 1, PW1 can be associated with a P2MP TE tunnel 100 or P2MP LSP setup using mLDP originating from PE1 and terminating at 101 PE2, PE23 and PE4. 103 |<--------------P2MP PW---------------->| 104 Native | | Native 105 Service | |<--PSN1->| |<--PSN2->| | Service 106 (AC) V V V V V V (AC) 107 | +-----+ +------+ +------+ | 108 | | | | P1 |=========|T-PE2 |AC3 | +---+ 109 | | | | .......PW1.........>|-------->|CE3| 110 | |T-PE1|=========| . |=========| | | +---+ 111 | | .......PW1........ | +------+ | 112 | | . |=========| . | +------+ | 113 | | . | | . |=========|T-PE3 |AC4 | +---+ 114 +---+ |AC1 | . | | .......PW1.........>|-------->|CE4| 115 |CE1|------->|... | | |=========| | | +---+ 116 +---+ | | . | +------+ +------+ | 117 | | . | +------+ +------+ | 118 | | . |=========| P2 |=========|T-PE4 |AC5 | +---+ 119 | | .......PW1..............PW1.........>|-------->|CE5| 120 | | |=========| |=========| | | +---+ 121 | +-----+ +------+ +------+ | 123 Figure 1: P2MP PW 125 Mechanisms for establishing P2P SS-PW using LDP are described in 126 [RFC4447bis]. In this document, we specify a method of signaling P2MP 127 PW using LDP. In particular, we define new FEC, TLVs, parameters, and 128 status codes to facilitate LDP to signal and maintain P2MP PWs. 130 As outlined in [RFC7338], even though the traffic flow from a Root-PE 131 (R-PE) to Leaf-PE(s) (L-PEs) is P2MP in nature, it may be desirable 132 for any L-PE to send unidirectional P2P traffic destined only to the 133 R-PE. The proposed mechanism takes such option into consideration. 135 The P2MP PW requires an MPLS LSP to carry the PW traffic, and the 136 MPLS packets carrying the PW upstream label will be encapsulated 137 according to the methods described in [RFC5332]. 139 1.1 Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 FEC: Forwarding Equivalence Class 147 LDP: Label Distribution Protocol 149 mLDP: Label Distribution Protocol for P2MP/MP2MP LSP 151 LSP: Label Switching Path 153 MS-PW: Multi-Segment Pseudowire 155 P2P: Point to Point 157 P2MP: Point to Multipoint 159 PE: Provider Edge 161 PSN: Packet Switched Network 163 PW: Pseudowire 165 SS-PW: Single-Segment Pseudowire 167 S-PE: Switching Provider Edge Node of MS-PW 169 TE: Traffic Engineering 171 R-PE: Root-PE - ingress PE, PE initiating P2MP PW setup. 173 L-PE: Leaf-PE - egress PE. 175 2. Signaling P2MP PW 176 In order to advertise labels as well as exchange PW related LDP 177 messages, PEs must establish LDP sessions among themselves using the 178 Extended Discovery Mechanisms. A PE discovers other PEs that are to 179 be connected via P2MP PWs either via manual configuration or 180 autodiscovery [RFC6074]. 182 R-PE and each L-PE MUST be configured with the same FEC as defined in 183 the following section. 185 P2MP PW requires that there is an active P2MP PSN LSP set up between 186 R-PE and L-PE(s). Note that the procedure to set up the P2MP PSN LSP 187 is different depending on the signaling protocol used (RSVP-TE or 188 mLDP). 190 In case of mLDP, a Leaf-PE can decide to join the P2MP LSP at any 191 time; whereas in the case of RSVP-TE, the P2MP LSP is set up by the 192 R-PE, generally at the initial service provisioning time. It should 193 be noted that local policy can override any decision to join, add or 194 prune existing or new L-PE(s) from the tree. In any case, the PW 195 setup can ignore these differences, and simply assume that the P2MP 196 PSN LSP is available when needed. 198 P2MP PW signaling is initiated by the R-PE which sends a separate 199 P2MP-PW LDP label mapping message to each of the the L-PE(s) 200 belonging to that P2MP PW. This label mapping message will contain 201 the following: 202 1. A FEC TLV containing P2MP PW Upstream FEC element that 203 includes Transport LSP sub TLV. 204 2. An Interface Parameters TLV, as described in [RFC4447bis]. 205 3. A PW Grouping TLV, as described in [RFC4447bis]. 206 4. A label TLV for the upstream-assigned label used by R-PE 207 for the traffic going from R-PE to L-PE(s). 209 The R-PE imposes the upstream-assigned PW label on the outbound 210 packets sent over the P2MP-PW, and using this label an L-PE 211 identifies the inbound packets arriving over the P2MP PW. 213 Additionally, the R-PE MAY send label mapping message(s) to one or 214 more L-PE(s) to signal unidirectional P2P PW(s). The L-PE(s) can use 215 such PW(s) to send traffic to the R-PE. This optional label mapping 216 message will contain the following: 218 1. P2P PW Downstream FEC element. 219 2. A label TLV for the down-stream assigned label used by the 220 corresponding L-PE to send traffic to the R-PE. 222 The LDP liberal label retention mode is used, and per requirements 223 specified in [RFC5036], the Label Request message MUST also be 224 supported. 226 The upstream-assigned label is allocated according to the rules in 227 [RFC5331]. 229 When an L-PE receives a PW Label Mapping Message, it MUST verify the 230 associated P2MP PSN LSP is in place. If the associated P2MP PSN LSP 231 is not in place, and its type is LDP P2MP LSP, the L-PE MUST attempt 232 to join the P2MP LSP associated with the P2MP PW. If the associated 233 P2MP PSN LSP is not in place, and its type is RSVP-TE P2MP LSP, the 234 L-PE SHOULD wait till the P2MP transport LSP is signaled. If an L-PE 235 fails to join the P2MP PSN LSP, that L-PE MUST not enable the PW, and 236 MUST notify the user. In this case, a PW status message with status 237 code of 0x00000008 (Local PSN-facing PW (ingress) Receive Fault) MUST 238 also be sent to the R-PE. 240 2.1 PW ingress to egress incompatibility issues 242 If an R-PE signals a PW with a pw type, CW mode, or interface 243 parameters that a particular L-PE cannot accept, then the L-PE MUST 244 not enable the PW, and notify the user. In this case, a PW status 245 message with status code of 0x00000001 (Pseudowire Not Forwarding) 246 MUST also be sent to the R-PE. 248 Note that this procedure does not apply if the L-PE had not been 249 provisioned with this particular P2MP PW. In this case according to 250 the LDP liberal label retention rules, no action is taken. 252 2.2 P2MP PW FEC 254 [RFC4447bis] specifies two types of LDP FEC elements called "PWid FEC 255 Element" and "Generalized PWid FEC Element" used to signal P2P PWs. 256 We define two new types of FEC elements called "P2MP PW Upstream FEC 257 Element" and "P2P PW Downstream FEC Element". These FEC elements are 258 associated with a mandatory upstream assigned label and an optional 259 downstream assigned label respectively. 261 A new FEC type for the P2MP PW Upstream FEC Element is pending IANA 262 allocation and is encoded as follows: 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | P2MP PW Up |C| PW Type | PW Info Length| 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | AGI Type | Length | AGI Value | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 ~ AGI Value (contd.) ~ 272 | | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | AII Type | Length | SAII Value | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 ~ SAII Value (contd.) ~ 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 |PMSI Tunnel typ| Length | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 281 + + 282 ~ Transport LSP ID ~ 283 | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | | 286 | Optional Parameters | 287 ~ ~ 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Figure 2: P2MP PW Upstream FEC Element 292 * P2MP PW Up 293 8 bits representation for the P2MP PW Upstream FEC type. 295 * PW Type: 297 15 bits representation of PW type, and the assigned values are 298 assigned by IANA. 300 * C bit: 302 A value of 1 or 0 indicates whether control word is present or 303 absent for the P2MP PW. 305 * PW Info Length: 307 Sum of the lengths of AGI, SAII, PMSI Tunnel info, and Optional 308 Parameters field in octets. If this value is 0, then it references 309 all PWs using the specified grouping ID. In this case, there are 310 neither other FEC element fields (AGI, SAII, etc.) present, nor any 311 interface parameters TLVs. Alternatively, we can use typed wildcard 312 FEC described in section 3.3 to achieve the same or to have better 313 filtering. 315 * AGI: 317 Attachment Group Identifier can be used to uniquely identify VPN or 318 VPLS instance associated with the P2MP PW. This has the same format 319 as the Generalized PWid FEC element [RFC4447bis]. 321 * SAII: 323 Source Attachment Individual Identifier is used to identify the root 324 of the P2MP PW. The root is represented using AII type 2 format 325 specified in [RFC5003]. Note that the SAII can be omitted by simply 326 setting the length and type to zero. 328 P2MP PW is identified by the Source Attachment Identifier (SAI). If 329 the AGI is non-null, the SAI is the combination of the SAII and the 330 AGI, if the AGI is null, the SAI is the SAII. 332 * PMSI Tunnel Type and Transport LSP ID: 334 A P2MP PW MUST be associated with a transport LSP which can be 335 established using RSVP-TE or mLDP. 337 * PMSI Tunnel Type: 339 The PMSI tunnel type is defined in [RFC6514]. 341 When the type is set to mLDP P2MP LSP, the Tunnel Identifier is a 342 P2MP FEC Element as defined in [RFC6388]. A new mLDP Opaque Value 343 Element type for L2VPN-MCAST application needs to be allocated. 345 * Transport LSP ID: This is the Tunnel Identifier which is defined in 346 [RFC6514]. 348 An R-PE sends Label Mapping Message as soon as the transport LSP ID 349 associated with the P2MP PW is known (e.g., via configuration) 350 regardless of the operational state of that transport LSP. Similarly, 351 an R-PE does not withdraw the labels when the corresponding transport 352 LSP goes down. Furthermore, an L-PE retains the P2MP PW labels 353 regardless of the operational status of the transport LSP. 355 Note that a given transport LSP can be associated with more than one 356 P2MP PWs in which case P2MP PWs will be sharing the same R-PE and L- 357 PE(s). An R-PE may also have many P2MP PWs with disjoint L-PE sets. 359 In the case of LDP P2MP LSP, when an L-PE receives the Label Mapping 360 Message, it can initiate the process of joining the P2MP LSP tree 361 associated with the P2MP PW. 363 In the case of RSVP-TE P2MP LSP, only the R-PE initiates the 364 signaling of P2MP LSP. 366 * Optional Parameters: 368 The Optional Parameter field can contain some TLVs that are not part 369 of the FEC, but are necessary for the operation of the PW. This 370 proposed mechanism uses two such TLVs: Interface Parameters TLV, and 371 Group ID TLV. 373 The Interface Parameters TLV and Group ID TLV specified in 374 [RFC4447bis] can also be used in conjunction with P2MP PW FEC in a 375 label message. For Group ID TLV, the sender and receiver of these 376 TLVs should follow the same rules and procedures specified in 377 [RFC4447bis]. For Interface Parameters TLV, the procedure differs 378 from the one specified in [RFC4447bis] due to specifics of P2MP 379 connectivity. When the interface parameters are signaled by a R-PE, 380 each L-PE must check if its configured value(s) is less than or equal 381 to the threshold value provided by the R-PE (e.g. MTU size 382 (Ethernet), max number of concatenated ATM cells, etc)). For other 383 interface parameters like CEP/TDM Payload bytes (TDM), the value MUST 384 exactly match the values signaled by the R-PE. 386 Multicast traffic stream associated with a P2MP PW can be selective 387 or inclusive. To support the former, this document defines a new 388 optional Selective Tree Interface Parameter sub-TLV (type is pending 389 IANA allocation) according to the format described in [RFC4447bis]. 390 The value of the sub-TLV contains the source and the group for a 391 given multicast tree as shown in Figure 3. Also, if a P2MP PW is 392 associated with multiple selective trees, the corresponding label 393 mapping message will carry more than one instance of this Sub-TLV. 394 Furthermore, in the absence of this sub-TLV, the P2MP PW is 395 associated with all multicast traffic stream originating from the 396 root. 398 +----------------------------------------- + 399 | Sub-TLV Type (1 Octet) | 400 +----------------------------------------- + 401 | Length (1 Octet) | 402 +----------------------------------------- + 403 | Multicast Source Length (1 Octet) | 404 +----------------------------------------- + 405 | Multicast Source (variable length) | 406 +----------------------------------------- + 407 | Multicast Group Length (1 Octet) | 408 +----------------------------------------- + 409 | Multicast Group (variable length) | 410 +----------------------------------------- + 412 Figure 3: Selective Tree Interface Parameter Sub-TLV Value 414 Note that since the LDP label mapping message is only sent by the R- 415 PE to all the L-PEs, it is not possible to negotiate any interface 416 parameters. 418 The type of optional P2P PW Downstream FEC Element is pending IANA 419 allocation, and is encoded as follows: 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | P2P PW Down |C| PW Type | PW Info Length| 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | AGI Type | Length | AGI Value | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 ~ AGI Value (contd.) ~ 429 | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | AII Type | Length | SAII Value | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 ~ SAII Value (contd.) ~ 434 | | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 Figure 4: P2P PW Downstream FEC Element 439 The definition of the fields in the P2P PW Downstream FEC Element is 440 the same as those of P2MP PW Upstream FEC Element shown in Figure 2. 442 2.3 Typed Wildcard FEC Format for new FEC 444 [RFC5918] defines the general notion of a "Typed Wildcard" FEC 445 Element, and requires FEC designer to specify a typed wildcard FEC 446 element for newly defined FEC element types. This document defines 447 two new FEC elements, "P2MP PW Upstream" and "P2P PW Downstream" FEC 448 element, and hence requires us to define their Typed Wildcard format. 450 [RFC6667] defines Typed Wildcard FEC element format for other PW FEC 451 Element types (PWid and Gen. PWid FEC Element) in section 2 as 452 follows: 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 |Typed Wcard=0x5|Type=PW FEC | Len = 3 |R| PW type | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | . . . | PMSI Tun Type | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Figure 5: Typed Wildcard Format for P2MP PW FEC Elements 463 [RFC6667] specifies that "Type" field can be either "PWid" (0x80) or 464 "Generalized PWid" (0x81) FEC element type. This document reuses the 465 existing typed wildcard format as specified in [RFC6667] and 466 illustrated in Figure 5. We extend the definition of "Type" field to 467 also include "P2MP PW Upstream" and "P2P PW Downstream" FEC element 468 types, as well as add an additional field "PMSI Tun Type". We reserve 469 PMSI tunnel Type 0xFF to mean "wildcard" transport tunnel type. This 470 "wildcard" transport tunnel type can be used in a typed wildcard p2mp 471 FEC for further filtering. This field only applies to Typed wildcard 472 P2MP PW Upstream FEC and MUST be set to "wildcard" for "P2P PW 473 Downstream FEC" typed wildcard element. 475 2.4 Group ID usage 477 The Grouping TLV as defined in [RFC4447bis] contains a group ID 478 capable of indicating an arbitrary group membership of a P2MP-PW. 479 This group ID can be used in LDP "wild card" status, and withdraw 480 label messages, as described in [RFC4447bis]. 482 2.5 Generic Label TLV 484 As in the case of P2P PW signaling, P2MP PW labels are carried within 485 Generic Label TLV contained in LDP Label Mapping Message. A Generic 486 Label TLV is formatted and processed as per the rules and procedures 487 specified in [RFC4447bis]. For a given P2MP PW, a single upstream- 488 assigned label is allocated by the R-PE, and is advertised to all L- 489 PEs using the Generic Label TLV in label mapping message containing 490 the P2MP PW Upstream FEC element. 492 The R-PE can also allocate a unique label for each L-PE from which it 493 intends to receive P2P traffic. Such a label is advertised to the L- 494 PE using Generic Label TLV and P2P PW Downstream FEC in label mapping 495 message. 497 3. LDP Capability Negotiation 498 The capability of supporting P2MP PW must be advertised to all LDP 499 peers. This is achieved by using the methods in [RFC5561] and 500 advertising the LDP "P2MP PW Capability" TLV. If an LDP peer supports 501 the dynamic capability advertisement, this can be done by sending a 502 new Capability message with the S bit set for the P2MP PW capability 503 TLV. If the peer does not supports dynamic capability advertisement, 504 then the P2MP PW Capability TLV MUST be included in the LDP 505 Initialization message during the session establishment. An LSR 506 having P2MP PW capability MUST recognize both P2MP PW Upstream FEC 507 Element and P2P PW Downstream FEC Element in LDP label messages. 509 In line with requirements listed in [RFC5561], the following TLV is 510 defined to indicate the P2MP PW capability: 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 |U|F| P2MP PW Capability TLV | Length | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 |S| Reserved | Reserved | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Figure 7: LDP P2MP PW Capability TLV 522 Note: TLV number pending IANA allocation. 524 * U-bit: 526 SHOULD be 1 (ignore if not understood). 528 * F-bit: 530 SHOULD be 0 (don't forward if not understood). 532 * P2MP PW Capability TLV Code Point: 534 The TLV type, which identifies a specific capability. The P2MP PW 535 capability code point is requested in the IANA allocation section 536 below. 538 * S-bit: 540 The State Bit indicates whether the sender is advertising or 541 withdrawing the P2MP PW capability. The State bit is used as 542 follows: 543 1 - The TLV is advertising the capability specified by the 544 TLV Code Point. 546 0 - The TLV is withdrawing the capability specified by the 547 TLV Code Point. 549 * Length: 551 MUST be set to 2 (octet). 553 4. P2MP PW Status 555 In order to support the proposed mechanism, a node MUST be capable of 556 handling PW status. As such, PW status negotiation procedure 557 described in [RFC4447bis] is not applicable to P2MP PW. A node MUST 558 NOT claim to be P2MP PW capable by sending a LDP P2MP PW Capability 559 TLV if it is not also capable of handling PW status. 561 Once an L-PE successfully processes a Label Mapping Message for a 562 P2MP PW, it MUST send appropriate PW status according to the 563 procedure specified [RFC4447bis] to report the PW status. If no PW 564 status notification is required, then no PW status notification is 565 sent (for example if the P2MP PW is established and operational with 566 a status code of Success (0x00000000), a PW status message is not 567 necessary). A PW status message sent from an L-PE to R-PE MUST 568 contain the P2P PW Downstream FEC to identify the PW. 570 An R-PE also sends PW status to L-PE(s) to reflect its view of a P2MP 571 PW state. Such PW status message contains P2MP PW Upstream FEC to 572 identify the PW. 574 Connectivity status of the underlying P2MP LSP that P2MP PW is 575 associated with, can be verified using LSP Ping and Traceroute 576 procedures described in [RFC6425]. 578 5 Security Considerations 580 The security measures described in [RFC4447bis] are adequate for the 581 proposed mechanism. 583 6 Acknowledgment 585 Authors would like thank Andre Pelletier and Parag Jain for their 586 valuable suggestions. 588 7 IANA Considerations 590 7.1. FEC Type Name Space 591 This document uses two new FEC element types, number 0x82 and 0x83 592 are suggested for assignment from the registry "FEC Type Name Space" 593 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 "LDP MP Opaque Value Element basic type" name space defined 614 in [RFC6388]. 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" defined in [RFC4446]. 626 The following value is suggested for assignment: 628 TLV type Description 629 0x1b Selective Tree Interface Parameter. 631 7.5. WildCard PMSI tunnel type 633 This document requests that IANA modify the following entry in the 634 "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" 635 registry within the "Border Gateway Protocol (BGP) Parameters" 636 namespace previously assigned by RFC7385 as "reserved". 638 Value Meaning Reference 639 0xFF wildcard transport tunnel type [This document] 641 8 References 643 8.1. Normative References 645 [RFC2119] Bradner. S, "Key words for use in RFCs to Indicate 646 Requirement Levels", RFC 2119, March, 1997. 648 [RFC4447bis] "Pseudowire Setup and Maintenance using the Label 649 Distribution Protocol", Martini, L., et al., draft-ietf-pals- 650 rfc4447bis-05.txt, July 2016. 652 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 653 Specification", RFC 5036, October 2007. 655 [RFC5003] C. Metz, L. Martini, F. Balus, J. Sugimoto, "Attachment 656 Individual Identifier (AII) Types for Aggregation", RFC5003, 657 September 2007. 659 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 660 Assignment and Context-Specific Label Space", RFC 5331, August 2008. 662 [RFC5332] T. Eckert, E. Rosen, Ed.,R. Aggarwal, Y. Rekhter, "MPLS 663 Multicast Encapsulations", RFC 5332, August 2008. 665 [RFC6388] I. Minei, K. Kompella, I. Wijnands, B. Thomas, "Label 666 Distribution Protocol Extensions for Point-to-Multipoint and 667 Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 668 2011. 670 [RFC4875] R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed., 671 "Extensions to Resource Reservation Protocol - Traffic Engineering 672 (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs).", 673 RFC 4875, May 2007. 675 [RFC6514] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, "BGP Encodings 676 and Procedures for Multicast in MPLS/BGP IP VPNs", RFC6514, February 677 2012. 679 [RFC5561] B.Thomas, K.Raza, S.Aggarwal, R.Agarwal, JL. Le Roux, "LDP 680 Capabilities", RFC 5561, July 2009. 682 [RFC5918] R. Asati, I. Minei, and B. Thomas, "LDP Typed Wildcard 683 Forwarding Equivalence Class", RFC 5918, August 2010. 685 [RFC6667] K. Raza, S. Boutros, and C. Pignataro, "LDP Typed Wildcard 686 FEC for PWid and Generalized PWid FEC Elements", RFC 6667, July 2012. 688 8.2. Informative References 690 [RFC3985] Stewart Bryant, et al., "PWE3 Architecture", RFC3985 692 [RFC6074] E. Rosen,W. Luo,B. Davie,V. Radoaca "Provisioning, Auto- 693 Discovery, and Signaling in Layer 2 Virtual Private Networks 694 (L2VPNs)", RFC6074, January 2011. 696 [RFC7338] F. Jounay, et. al, "Requirements for Point to Multipoint 697 Pseudowire", RFC7338, September 2014. 699 [RFC6425] A. Farrel, S. Yasukawa, "Detecting Data Plane Failures in 700 Point-to-Multipoint Multiprotocol Label Switching (MPLS)- Extensions 701 to LSP Ping", RFC6425, November 2011. 703 Contributors 705 The following co-authors have also contributed to this document: 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 Orange CH 725 Email: Frederic.Jounay@salt.ch 727 Philippe Niger 728 Orange CH 729 Email: philippe.niger@orange.com 730 Yuji Kamite 731 NTT Communications Corporation 732 Email: y.kamite@ntt.com 734 Lizhong Jin 735 Email: lizho.jin@gmail.com 737 Martin Vigoureux 738 Nokia 739 Email: martin.vigoureux@nokia.com 741 Laurent Ciavaglia 742 Nokia 743 Email: laurent.ciavaglia@nokia.com 745 Simon Delord 746 Telstra 747 E-mail: simon.delord@gmail.com 749 Kamran Raza 750 Cisco Systems 751 Email: skraza@cisco.com 753 Authors' Addresses 755 Siva Sivabalan 756 Cisco Systems, Inc. 757 Email: msiva@cisco.com 759 Sami Boutros 760 VMware Inc. 761 Email: sboutros@vmware.com