idnits 2.17.1 draft-ietf-pals-p2mp-pw-04.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 654 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 (November 12, 2017) is 2329 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 643, 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 Sami Boutros(Ed.) 3 Intended Status: Standard Track VMware 5 Updates: RFC7385 Siva Sivabalan(Ed.) 6 Cisco Systems 8 Expires: May 16, 2018 November 12, 2017 10 Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP 11 draft-ietf-pals-p2mp-pw-04.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 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Signaling P2MP PW . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1 PW ingress to egress incompatibility issues . . . . . . . . 6 64 2.2 P2MP PW FEC . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.2.1 P2MP PW Upstream FEC Element . . . . . . . . . . . . . . 6 66 2.2.2 P2P PW Downstream FEC Element . . . . . . . . . . . . . 10 67 2.3 Typed Wildcard FEC Format for new FEC . . . . . . . . . . . 10 68 2.4 Group ID usage . . . . . . . . . . . . . . . . . . . . . . . 11 69 2.5 Generic Label TLV . . . . . . . . . . . . . . . . . . . . . 11 70 3. LDP Capability Negotiation . . . . . . . . . . . . . . . . . . 12 71 4. P2MP PW Status . . . . . . . . . . . . . . . . . . . . . . . . 13 72 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 73 6 Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 75 7.1. FEC Type Name Space . . . . . . . . . . . . . . . . . . . . 14 76 7.2. LDP TLV Type . . . . . . . . . . . . . . . . . . . . . . . 14 77 7.3. mLDP Opaque Value Element TLV Type . . . . . . . . . . . . 14 78 7.4. Selective Tree Interface Parameter sub-TLV Type . . . . . . 14 79 7.5. WildCard PMSI tunnel type . . . . . . . . . . . . . . . . . 15 80 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 83 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 86 1 Introduction 88 A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the essential 89 attributes of a unidirectional P2MP Telecommunications service such 90 as P2MP ATM over PSN. A major difference between a Point-to-Point 91 (P2P) PW outlined in [RFC3985] and a P2MP PW is that the former is 92 intended for bidirectional service whereas the latter is intended for 93 both unidirectional, and optionally bidirectional service. 94 Requirements for P2MP PW are described in [RFC7338]. P2MP PW can be 95 constructed as either Single Segment (P2MP SS-PW) or Multi Segment 96 (P2MP MS-PW) Pseudowires as mentioned in [RFC7338]. P2MP MS-PW is 97 outside the scope of this document. A reference model or a P2MP PW is 98 depicted in Figure 1 below. A transport LSP associated with a P2MP 99 SS-PW SHOULD be a P2MP MPLS LSP (i.e., P2MP TE tunnel established via 100 RSVP-TE [RFC4875] or P2MP LSP established via mLDP [RFC6388]) 101 spanning from the Root-PE to the Leaf-PE(s) of the P2MP SS-PW tree. 102 For example, in Figure 1, PW1 can be associated with a P2MP TE tunnel 103 or P2MP LSP setup using mLDP originating from PE1 and terminating at 104 PE2, PE3 and PE4. 106 |<--------------P2MP PW---------------->| 107 Native | | Native 108 Service | |<--PSN1->| |<--PSN2->| | Service 109 (AC) V V V V V V (AC) 110 | +-----+ +------+ +------+ | 111 | | | | P1 |=========|T-PE2 |AC3 | +---+ 112 | | | | .......PW1.........>|-------->|CE3| 113 | |T-PE1|=========| . |=========| | | +---+ 114 | | .......PW1........ | +------+ | 115 | | . |=========| . | +------+ | 116 | | . | | . |=========|T-PE3 |AC4 | +---+ 117 +---+ |AC1 | . | | .......PW1.........>|-------->|CE4| 118 |CE1|------->|... | | |=========| | | +---+ 119 +---+ | | . | +------+ +------+ | 120 | | . | +------+ +------+ | 121 | | . |=========| P2 |=========|T-PE4 |AC5 | +---+ 122 | | .......PW1..............PW1.........>|-------->|CE5| 123 | | |=========| |=========| | | +---+ 124 | +-----+ +------+ +------+ | 126 Figure 1: P2MP PW 128 Mechanisms for establishing P2P SS-PW using LDP are described in 129 [RFC4447bis]. This document specify a method of signaling P2MP PW 130 using LDP. In particular, this document defines new FEC, TLVs, 131 parameters, and status codes to facilitate LDP to signal and maintain 132 P2MP PWs. 134 As outlined in [RFC7338], even though the traffic flow from a Root-PE 135 (R-PE) to Leaf-PE(s) (L-PEs) is P2MP in nature, it may be desirable 136 for any L-PE to send unidirectional P2P traffic destined only to the 137 R-PE. The proposed mechanism takes such option into consideration. 139 The P2MP PW requires an MPLS LSP to carry the PW traffic, and the 140 MPLS packets carrying the PW upstream label will be encapsulated 141 according to the methods described in [RFC5332]. 143 1.1 Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [RFC2119]. 149 FEC: Forwarding Equivalence Class 151 LDP: Label Distribution Protocol 153 mLDP: Label Distribution Protocol for P2MP/MP2MP LSP 155 LSP: Label Switching Path 157 MS-PW: Multi-Segment Pseudowire 159 P2P: Point to Point 161 P2MP: Point to Multipoint 163 PE: Provider Edge 165 PSN: Packet Switched Network 167 PW: Pseudowire 169 SS-PW: Single-Segment Pseudowire 171 S-PE: Switching Provider Edge of MS-PW 173 TE: Traffic Engineering 175 R-PE: Root-PE - ingress PE, PE initiating P2MP PW setup. 177 L-PE: Leaf-PE - egress PE. 179 2. Signaling P2MP PW 180 In order to advertise labels as well as exchange PW related LDP 181 messages, PEs must establish LDP sessions among themselves. A PE 182 discovers other PEs that are to be connected via P2MP PWs either via 183 manual configuration or autodiscovery [RFC6074]. 185 R-PE and each L-PE MUST be configured with the same FEC as defined in 186 the following section. 188 P2MP PW requires that there is an active P2MP PSN LSP set up between 189 R-PE and L-PE(s). Note that the procedure to set up the P2MP PSN LSP 190 is different depending on the signaling protocol used (RSVP-TE or 191 mLDP). 193 In case of mLDP, a Leaf-PE can decide to join the P2MP LSP at any 194 time. In the case of RSVP-TE, the P2MP LSP is set up by the R-PE, 195 generally at the initial service provisioning time. It should be 196 noted that local policy can override any decision to join, add or 197 prune existing or new L-PE(s) from the tree. In any case, the PW 198 setup can ignore these differences, and simply assume that the P2MP 199 PSN LSP is available when needed. 201 P2MP PW signaling is initiated by the R-PE which sends a separate 202 P2MP-PW LDP label mapping message to each of the the L-PE(s) 203 belonging to that P2MP PW. This label mapping message will contain 204 the following: 205 1. A FEC TLV containing P2MP PW Upstream FEC element that 206 includes Transport LSP sub TLV. 207 2. An Interface Parameters TLV, as described in [RFC4447bis]. 208 3. A PW Grouping TLV, as described in [RFC4447bis]. 209 4. A label TLV for the upstream-assigned label used by R-PE 210 for the traffic going from R-PE to L-PE(s). 212 The R-PE imposes the upstream-assigned PW label on the outbound 213 packets sent over the P2MP-PW, and using this label an L-PE 214 identifies the inbound packets arriving over the P2MP PW. 216 Additionally, the R-PE MAY send label mapping message(s) to one or 217 more L-PE(s) to signal unidirectional P2P PW(s). The L-PE(s) can use 218 such PW(s) to send traffic to the R-PE. This optional label mapping 219 message will contain the following: 221 1. P2P PW Downstream FEC element. 222 2. A label TLV for the down-stream assigned label used by the 223 corresponding L-PE to send traffic to the R-PE. 225 The LDP liberal label retention mode MUST be used, and per 226 requirements specified in [RFC5036], the Label Request message MUST 227 also be supported. 229 The upstream-assigned label is allocated according to the rules in 230 [RFC5331]. 232 When an L-PE receives a PW Label Mapping Message, it MUST verify the 233 associated P2MP PSN LSP is in place. If the associated P2MP PSN LSP 234 is not in place, and its type is LDP P2MP LSP, the L-PE MUST attempt 235 to join the P2MP LSP associated with the P2MP PW. If the associated 236 P2MP PSN LSP is not in place, and its type is RSVP-TE P2MP LSP, the 237 L-PE SHOULD wait till the P2MP transport LSP is signaled. If an L-PE 238 fails to join the P2MP PSN LSP, that L-PE MUST not enable the PW, and 239 MUST notify the user. In this case, a PW status message with status 240 code of 0x00000008 (Local PSN-facing PW (ingress) Receive Fault) MUST 241 also be sent to the R-PE. 243 2.1 PW ingress to egress incompatibility issues 245 If an R-PE signals a PW with a pw type, CW mode, or interface 246 parameters that a particular L-PE cannot accept, then the L-PE MUST 247 not enable the PW, and notify the user. In this case, a PW status 248 message with status code of 0x00000001 (Pseudowire Not Forwarding) 249 MUST also be sent to the R-PE. 251 Note that this procedure does not apply if the L-PE had not been 252 provisioned with this particular P2MP PW. In this case according to 253 the LDP liberal label retention rules, no action is taken. 255 2.2 P2MP PW FEC 257 [RFC4447bis] specifies two types of LDP FEC elements called "PWid FEC 258 Element" and "Generalized PWid FEC Element" used to signal P2P PWs. 259 This document defines two new types of FEC elements called "P2MP PW 260 Upstream FEC Element" and "P2P PW Downstream FEC Element". These FEC 261 elements are associated with a mandatory upstream assigned label and 262 an optional downstream assigned label respectively. 264 2.2.1 P2MP PW Upstream FEC Element 266 A new FEC type for the P2MP PW Upstream FEC Element is encoded as 267 follows: 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 |P2MP PW Up=0x82|C| PW Type | PW Info Length| 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | AGI Type | Length | AGI Value | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 ~ AGI Value (contd.) ~ 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | AII Type | Length | SAII Value | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 ~ SAII Value (contd.) ~ 282 | | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 |PMSI Tunnel typ| Length | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 286 + + 287 ~ Transport LSP ID ~ 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | | 291 | Optional Parameters | 292 ~ ~ 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Figure 2: P2MP PW Upstream FEC Element 297 * P2MP PW Up: 299 8 bits representation for the P2MP PW Upstream FEC type. 301 * PW Type: 303 15 bits representation of PW type as specified in [RFC4447bis]. 305 * C bit: 307 A value of 1 or 0 indicates whether control word is present or absent 308 for the P2MP PW. 310 * PW Info Length: 312 Sum of the lengths of AGI, SAII, PMSI Tunnel info, and Optional 313 Parameters field in octets. If this value is 0, then it references 314 all PWs using the specified grouping ID. In this case, there are 315 neither other FEC element fields (AGI, SAII, etc.) present, nor any 316 interface parameters TLVs. Alternatively, typed wildcard FEC 317 described in section 3.3, can be used to achieve the same or to have 318 better filtering. 320 * AGI: 322 Attachment Group Identifier can be used to uniquely identify VPN or 323 VPLS instance associated with the P2MP PW. This has the same format 324 as the Generalized PWid FEC element [RFC4447bis]. 326 * SAII: 328 Source Attachment Individual Identifier is used to identify the root 329 of the P2MP PW. The root is represented using AII type 2 format 330 specified in [RFC5003]. Note that the SAII can be omitted by simply 331 setting the length and type to zero. 333 P2MP PW is identified by the Source Attachment Identifier (SAI). If 334 the AGI is non-null, the SAI is the combination of the SAII and the 335 AGI, if the AGI is null, the SAI is the SAII. 337 * PMSI Tunnel info 339 PMSI Tunnel info is the combination of PMSI Tunnel Type, Length and 340 Transport LSP ID. 342 A P2MP PW MUST be associated with a transport LSP which can be 343 established using RSVP-TE or mLDP. 345 * PMSI Tunnel Type: 347 The PMSI tunnel type is defined in [RFC6514]. 349 When the type is set to mLDP P2MP LSP, the Tunnel Identifier is a 350 P2MP FEC Element as defined in [RFC6388]. A new mLDP Opaque Value 351 Element type for L2VPN-MCAST application as specified in the IANA 352 considerations MUST be used. 354 * Transport LSP ID: This is the Tunnel Identifier which is defined in 355 [RFC6514]. 357 An R-PE sends Label Mapping Message as soon as the transport LSP ID 358 associated with the P2MP PW is known (e.g., via configuration) 359 regardless of the operational state of that transport LSP. Similarly, 360 an R-PE does not withdraw the labels when the corresponding transport 361 LSP goes down. Furthermore, an L-PE retains the P2MP PW labels 362 regardless of the operational status of the transport LSP. 364 Note that a given transport LSP can be associated with more than one 365 P2MP PWs in which case P2MP PWs will be sharing the same R-PE and L- 366 PE(s). An R-PE may also have many P2MP PWs with disjoint L-PE sets. 368 In the case of LDP P2MP LSP, when an L-PE receives the Label Mapping 369 Message, it can initiate the process of joining the P2MP LSP tree 370 associated with the P2MP PW. 372 In the case of RSVP-TE P2MP LSP, only the R-PE initiates the 373 signaling of P2MP LSP. 375 * Optional Parameters: 377 The Optional Parameter field can contain some TLVs that are not part 378 of the FEC, but are necessary for the operation of the PW. This 379 proposed mechanism uses two such TLVs: Interface Parameters TLV, and 380 Group ID TLV. 382 The Interface Parameters TLV and Group ID TLV specified in 383 [RFC4447bis] can also be used in conjunction with P2MP PW FEC in a 384 label message. For Group ID TLV, the sender and receiver of these 385 TLVs should follow the same rules and procedures specified in 386 [RFC4447bis]. For Interface Parameters TLV, the procedure differs 387 from the one specified in [RFC4447bis] due to specifics of P2MP 388 connectivity. When the interface parameters are signaled by a R-PE, 389 each L-PE must check if its configured value(s) is less than or equal 390 to the threshold value provided by the R-PE (e.g. MTU size 391 (Ethernet), max number of concatenated ATM cells, etc)). For other 392 interface parameters like CEP/TDM Payload bytes (TDM), the value MUST 393 exactly match the values signaled by the R-PE. 395 Multicast traffic stream associated with a P2MP PW can be selective 396 or inclusive. To support the former, this document defines a new 397 optional Selective Tree Interface Parameter sub-TLV, as described in 398 the IANA considerations and according to the format described in 399 [RFC4447bis]. The value of the sub-TLV contains the source and the 400 group for a given multicast tree as shown in Figure 3. Also, if a 401 P2MP PW is associated with multiple selective trees, the 402 corresponding label mapping message will carry more than one instance 403 of this Sub-TLV. Furthermore, in the absence of this sub-TLV, the 404 P2MP PW is associated with all multicast traffic stream originating 405 from the root. 407 +----------------------------------------- + 408 | Sub-TLV Type (1 Octet) | 409 +----------------------------------------- + 410 | Length (1 Octet) | 411 +----------------------------------------- + 412 | Multicast Source Length (1 Octet) | 413 +----------------------------------------- + 414 | Multicast Source (variable length) | 415 +----------------------------------------- + 416 | Multicast Group Length (1 Octet) | 417 +----------------------------------------- + 418 | Multicast Group (variable length) | 419 +----------------------------------------- + 421 Figure 3: Selective Tree Interface Parameter Sub-TLV Value 423 Note that since the LDP label mapping message is only sent by the R- 424 PE to all the L-PEs, it is not possible to negotiate any interface 425 parameters. 427 2.2.2 P2P PW Downstream FEC Element 429 The optional P2P PW Downstream FEC Element is encoded as follows: 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 |P2P PWDown=0x83|C| PW Type | PW Info Length| 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | AGI Type | Length | AGI Value | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 ~ AGI Value (contd.) ~ 439 | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | AII Type | Length | SAII Value | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 ~ SAII Value (contd.) ~ 444 | | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Figure 4: P2P PW Downstream FEC Element 449 The definition of the fields in the P2P PW Downstream FEC Element is 450 the same as those of P2MP PW Upstream FEC Element shown in Figure 2. 452 2.3 Typed Wildcard FEC Format for new FEC 454 [RFC5918] defines the general notion of a "Typed Wildcard" FEC 455 Element, and requires FEC designer to specify a typed wildcard FEC 456 element for newly defined FEC element types. This document defines 457 two new FEC elements, "P2MP PW Upstream" and "P2P PW Downstream" FEC 458 element, and hence requires us to define their Typed Wildcard format. 460 [RFC6667] defines Typed Wildcard FEC element format for other PW FEC 461 Element types (PWid and Gen. PWid FEC Element) in section 2 as 462 follows: 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 |Typed Wcard=0x5|Type=PW FEC | Len = 3 |R| PW type | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | . . . | PMSI Tun Type | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 Figure 5: Typed Wildcard Format for P2MP PW FEC Elements 473 [RFC6667] specifies that "Type" field can be either "PWid" (0x80) or 474 "Generalized PWid" (0x81) FEC element type. This document reuses the 475 existing typed wildcard format as specified in [RFC6667] and 476 illustrated in Figure 5 and extends the definition of "Type" field to 477 also include "P2MP PW Upstream" and "P2P PW Downstream" FEC element 478 types. This document adds an additional field "PMSI Tun Type". This 479 document reserves PMSI tunnel Type 0xFF to mean "wildcard" transport 480 tunnel type. The PMSI tunnel Type field only applies to Typed 481 wildcard P2MP PW Upstream FEC and MUST be set to "wildcard" for "P2P 482 PW Downstream FEC" typed wildcard element. 484 2.4 Group ID usage 486 The Grouping TLV as defined in [RFC4447bis] contains a group ID 487 capable of indicating an arbitrary group membership of a P2MP-PW. 488 This group ID can be used in LDP "wild card" status, and withdraw 489 label messages, as described in [RFC4447bis]. 491 2.5 Generic Label TLV 493 As in the case of P2P PW signaling, P2MP PW labels are carried within 494 Generic Label TLV contained in LDP Label Mapping Message. A Generic 495 Label TLV is formatted and processed as per the rules and procedures 496 specified in [RFC4447bis]. For a given P2MP PW, a single upstream- 497 assigned label is allocated by the R-PE, and is advertised to all L- 498 PEs using the Generic Label TLV in label mapping message containing 499 the P2MP PW Upstream FEC element. 501 The R-PE can also allocate a unique label for each L-PE from which it 502 intends to receive P2P traffic. Such a label is advertised to the L- 503 PE using Generic Label TLV and P2P PW Downstream FEC in label mapping 504 message. 506 3. LDP Capability Negotiation 508 The capability of supporting P2MP PW MUST be advertised to all LDP 509 peers. This is achieved by using the methods in [RFC5561] to 510 advertise the LDP "P2MP PW Capability" TLV. If an LDP peer supports 511 the dynamic capability advertisement, this can be done by sending a 512 new Capability message with the S bit set for the P2MP PW capability 513 TLV. If the peer does not supports dynamic capability advertisement, 514 then the P2MP PW Capability TLV MUST be included in the LDP 515 Initialization message during the session establishment. An LSR 516 having P2MP PW capability MUST recognize both P2MP PW Upstream FEC 517 Element and P2P PW Downstream FEC Element in LDP label messages. 519 In line with requirements listed in [RFC5561], the following TLV is 520 defined to indicate the P2MP PW capability: 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 |U|F| P2MP PW Capability TLV | Length | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 |S| Reserved | Reserved | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 Figure 7: LDP P2MP PW Capability TLV 532 * U-bit: 534 SHOULD be 1 (ignore if not understood). 536 * F-bit: 538 SHOULD be 0 (don't forward if not understood). 540 * P2MP PW Capability TLV Code Point: 542 The TLV type, which identifies a specific capability. The P2MP PW 543 capability code point is requested in the IANA allocation section 544 below. 546 * S-bit: 548 The State Bit indicates whether the sender is advertising or 549 withdrawing the P2MP PW capability. The State bit is used as 550 follows: 551 1 - The TLV is advertising the capability specified by the 552 TLV Code Point. 554 0 - The TLV is withdrawing the capability specified by the 555 TLV Code Point. 557 * Length: 559 MUST be set to 2 (octet). 561 4. P2MP PW Status 563 In order to support the proposed mechanism, an LSR MUST be capable of 564 handling PW status. As such, PW status negotiation procedure 565 described in [RFC4447bis] is not applicable to P2MP PW. An LSR MUST 566 NOT claim to be P2MP PW capable by sending a LDP P2MP PW Capability 567 TLV if it is not also capable of handling PW status. 569 Once an L-PE successfully processes a Label Mapping Message for a 570 P2MP PW, it MUST send appropriate PW status according to the 571 procedure specified [RFC4447bis] to report the PW status. If no PW 572 status notification is required, then no PW status notification is 573 sent (for example if the P2MP PW is established and operational with 574 a status code of Success (0x00000000), a PW status message is not 575 necessary). A PW status message sent from an L-PE to R-PE MUST 576 contain the P2P PW Downstream FEC to identify the PW. 578 An R-PE also sends PW status to L-PE(s) to reflect its view of a P2MP 579 PW state. Such PW status message contains P2MP PW Upstream FEC to 580 identify the PW. 582 Connectivity status of the underlying P2MP LSP that P2MP PW is 583 associated with, can be verified using LSP Ping and Traceroute 584 procedures described in [RFC6425]. 586 5 Security Considerations 588 In general the security measures described in [RFC4447bis] are 589 adequate for this protocol. However the use of MD5 as the method of 590 securing an LDP control plane is no longer considered adequately 591 secure. Implementations should be written in such a way that they can 592 migrate to a more secure cryptographic hash function when the next 593 authentication method to be used in the LDP might not be simple hash 594 based authentication algorithm. 596 6 Acknowledgment 598 Authors would like thank Andre Pelletier and Parag Jain for their 599 valuable suggestions. 601 7 IANA Considerations 603 7.1. FEC Type Name Space 605 This document uses two new FEC element types, number 0x82 and 0x83 606 are suggested for assignment from the registry "FEC Type Name Space" 607 for the Label Distribution Protocol (LDP RFC5036): 609 Value Hex Name Reference 610 ------- ----- ----------------------------- --------- 611 130 0x82 P2MP PW Upstream FEC Element RFCxxxx 612 131 0x83 P2P PW Downstream FEC Element RFCxxxx 614 7.2. LDP TLV Type 616 This document uses a new LDP TLV types, IANA already maintains a 617 registry of name "TLV TYPE NAME SPACE" defined by RFC5036. The 618 following values are suggested for assignment: 620 TLV type Description: 622 0x0703 P2MP PW Capability TLV 624 7.3. mLDP Opaque Value Element TLV Type 626 This document requires allocation of a new mLDP Opaque Value Element 627 Type from "LDP MP Opaque Value Element basic type" name space defined 628 in [RFC6388]. 630 The following value is suggested for assignment: 632 TLV type Description 633 13 L2VPN-MCAST application TLV 635 Length: 4 637 Value: A 32-bit integer, unique in the context of the root, as 638 identified by the root's address. 640 7.4. Selective Tree Interface Parameter sub-TLV Type 642 This document requires allocation of a sub-TLV from the registry 643 "Pseudowire Interface Parameters Sub-TLV Type" defined in [RFC4446]. 645 The following value is suggested for assignment: 647 TLV type Description 648 0x1b Selective Tree Interface Parameter. 650 7.5. WildCard PMSI tunnel type 652 This document requests that IANA modify the following entry in the 653 "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" 654 registry within the "Border Gateway Protocol (BGP) Parameters" 655 namespace previously assigned by RFC7385 as "reserved". 657 Value Meaning Reference 658 0xFF wildcard transport tunnel type [This document] 660 8 References 662 8.1. Normative References 664 [RFC2119] Bradner. S, "Key words for use in RFCs to Indicate 665 Requirement Levels", RFC 2119, March, 1997. 667 [RFC4447bis] "Pseudowire Setup and Maintenance using the Label 668 Distribution Protocol", Martini, L., et al., draft-ietf-pals- 669 rfc4447bis-05.txt, July 2016. 671 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 672 Specification", RFC 5036, October 2007. 674 [RFC5003] C. Metz, L. Martini, F. Balus, J. Sugimoto, "Attachment 675 Individual Identifier (AII) Types for Aggregation", RFC5003, 676 September 2007. 678 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 679 Assignment and Context-Specific Label Space", RFC 5331, August 2008. 681 [RFC5332] T. Eckert, E. Rosen, Ed.,R. Aggarwal, Y. Rekhter, "MPLS 682 Multicast Encapsulations", RFC 5332, August 2008. 684 [RFC6388] I. Minei, K. Kompella, I. Wijnands, B. Thomas, "Label 685 Distribution Protocol Extensions for Point-to-Multipoint and 686 Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 687 2011. 689 [RFC4875] R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed., 690 "Extensions to Resource Reservation Protocol - Traffic Engineering 691 (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs).", 692 RFC 4875, May 2007. 694 [RFC6514] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, "BGP Encodings 695 and Procedures for Multicast in MPLS/BGP IP VPNs", RFC6514, February 696 2012. 698 [RFC5561] B.Thomas, K.Raza, S.Aggarwal, R.Agarwal, JL. Le Roux, "LDP 699 Capabilities", RFC 5561, July 2009. 701 [RFC5918] R. Asati, I. Minei, and B. Thomas, "LDP Typed Wildcard 702 Forwarding Equivalence Class", RFC 5918, August 2010. 704 [RFC6667] K. Raza, S. Boutros, and C. Pignataro, "LDP Typed Wildcard 705 FEC for PWid and Generalized PWid FEC Elements", RFC 6667, July 2012. 707 8.2. Informative References 709 [RFC3985] Stewart Bryant, et al., "PWE3 Architecture", RFC3985 711 [RFC6074] E. Rosen,W. Luo,B. Davie,V. Radoaca "Provisioning, Auto- 712 Discovery, and Signaling in Layer 2 Virtual Private Networks 713 (L2VPNs)", RFC6074, January 2011. 715 [RFC7338] F. Jounay, et. al, "Requirements for Point to Multipoint 716 Pseudowire", RFC7338, September 2014. 718 [RFC6425] A. Farrel, S. Yasukawa, "Detecting Data Plane Failures in 719 Point-to-Multipoint Multiprotocol Label Switching (MPLS)- Extensions 720 to LSP Ping", RFC6425, November 2011. 722 Contributors 724 The following co-authors have also contributed to this document: 726 Luca Martini 727 Cisco Systems, Inc. 728 Email: lmartini@cisco.com 730 Maciek Konstantynowicz 731 Cisco Systems, Inc. 732 e-mail: maciek@cisco.com 734 Gianni Del Vecchio 735 Swisscom 736 Email: Gianni.DelVecchio@swisscom.com 738 Thomas D. Nadeau 739 Brocade 740 Email: tnadeau@lucidvision.com 742 Frederic Jounay 743 Orange CH 744 Email: Frederic.Jounay@salt.ch 746 Philippe Niger 747 Orange CH 748 Email: philippe.niger@orange.com 750 Yuji Kamite 751 NTT Communications Corporation 752 Email: y.kamite@ntt.com 754 Lizhong Jin 755 Email: lizho.jin@gmail.com 757 Martin Vigoureux 758 Nokia 759 Email: martin.vigoureux@nokia.com 761 Laurent Ciavaglia 762 Nokia 763 Email: laurent.ciavaglia@nokia.com 765 Simon Delord 766 Telstra 767 E-mail: simon.delord@gmail.com 769 Kamran Raza 770 Cisco Systems 771 Email: skraza@cisco.com 773 Authors' Addresses 775 Sami Boutros 776 VMware Inc. 777 Email: sboutros@vmware.com 779 Siva Sivabalan 780 Cisco Systems, Inc. 781 Email: msiva@cisco.com