idnits 2.17.00 (12 Aug 2021) /tmp/idnits24423/draft-ietf-mpls-app-aware-tldp-09.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 (June 27, 2017) is 1782 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group Santosh Esale 3 INTERNET-DRAFT Raveendra Torvi 4 Updates: 7473 (if approved) Juniper Networks 5 Intended Status: Proposed Standard Luay Jalil 6 Expires: December 29, 2017 Verizon 7 Uma Chunduri 8 Huawei 9 Kamran Raza 10 Cisco Systems, Inc. 11 June 27, 2017 13 Application-aware Targeted LDP 14 draft-ietf-mpls-app-aware-tldp-09 16 Abstract 18 Recent targeted Label Distribution Protocol (tLDP) applications such 19 as remote loop-free alternate (LFA) and BGP auto discovered 20 pseudowire may automatically establish a tLDP session to any Label 21 Switching Router (LSR) in a network. The initiating LSR has 22 information about the targeted applications to administratively 23 control initiation of the session. However, the responding LSR has no 24 such information to control acceptance of this session. This document 25 defines a mechanism to advertise and negotiate Targeted Applications 26 Capability (TAC) during LDP session initialization. As the 27 responding LSR becomes aware of targeted applications, it may 28 establish a limited number of tLDP sessions for certain applications. 29 In addition, each targeted application is mapped to LDP Forwarding 30 Equivalence Class (FEC) Elements to advertise only necessary LDP FEC- 31 label bindings over the session. This document updates RFC 7473 for 32 enabling advertisement of LDP FEC-label bindings over the session. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as 42 Internet-Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/1id-abstracts.html 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html 54 Copyright and License Notice 56 Copyright (c) 2017 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1 Conventions Used in This Document . . . . . . . . . . . . . 4 73 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Targeted Application Capability . . . . . . . . . . . . . . . . 5 75 2.1 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2.2 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 2.3 LDP message procedures . . . . . . . . . . . . . . . . . . . 8 78 2.3.1 Initialization message . . . . . . . . . . . . . . . . . 8 79 2.3.2 Capability message . . . . . . . . . . . . . . . . . . . 9 80 3. Targeted Application FEC Advertisement Procedures . . . . . . . 9 81 4. Interaction of Targeted Application Capabilities and State 82 Advertisement Control Capabilities . . . . . . . . . . . . . . 10 83 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 5.1 Remote LFA Automatic Targeted session . . . . . . . . . . . 12 85 5.2 FEC 129 Auto Discovery Targeted session . . . . . . . . . . 13 86 5.3 LDP over RSVP and Remote LFA targeted session . . . . . . . 13 87 5.4 mLDP node protection targeted session . . . . . . . . . . . 13 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 14 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 90 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 15 91 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 15 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 10.1 Normative References . . . . . . . . . . . . . . . . . . . 16 94 10.2 Informative References . . . . . . . . . . . . . . . . . . 16 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 97 1 Introduction 99 LDP uses the extended discovery mechanism to establish the tLDP 100 adjacency and subsequent session as described in [RFC5036]. A LSR 101 initiates extended discovery by sending tLDP Hello to specific 102 address. The remote LSR decides to either accept or ignore the tLDP 103 Hello based on local configuration only. Targeted LDP application is 104 an application that uses tLDP session to exchange information such as 105 FEC-Label bindings with a peer LSR in the network. For an application 106 such as FEC 128 pseudowire, the remote LSR is configured with the 107 source LSR address so that it can use that information to accept or 108 ignore given tLDP Hello. 110 However, applications such as Remote LFA and BGP auto discovered 111 pseudowire automatically initiate asymmetric extended discovery to 112 any LSR in a network based on local state only. With these 113 applications, the remote LSR is not explicitly configured with the 114 source LSR address. So the remote LSR either responds or ignores all 115 tLDP Hellos. 117 In addition, since the session is initiated and established after 118 adjacency formation, the responding LSR has no targeted applications 119 information available to choose a session with targeted application 120 that it is configured to support. Also, the initiating LSR may employ 121 a limit per application on locally initiated automatic tLDP sessions, 122 however the responding LSR has no such information to employ a 123 similar limit on the incoming tLDP sessions. Further, the responding 124 LSR does not know whether the source LSR is establishing a tLDP 125 session for configured, automatic or both applications. 127 This document proposes and describes a solution to advertise Targeted 128 Application Capability (TAC), consisting of a targeted application 129 list, during initialization of a tLDP session. It also defines a 130 mechanism to enable an new application and disable an old application 131 after session establishment. This capability advertisement provides 132 the responding LSR with the necessary information to control the 133 acceptance of tLDP sessions per application. For instance, an LSR may 134 accept all BGP auto discovered tLDP sessions as defined in [RFC6074] 135 but may only accept limited number of Remote LFA tLDP sessions as 136 defined in [RFC7490] 138 Also, the targeted LDP application is mapped to LDP FEC element type 139 to advertise specific application FECs only, avoiding the 140 advertisement of other unnecessary FECs over a tLDP session. 142 1.1 Conventions Used in This Document 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in RFC 147 2119 [RFC2119] and RFC 8174 [RFC8174] when, and only when, they 148 appear in all capitals, as shown here. 150 1.2 Terminology 152 In addition to the terminology defined in [RFC7473], this document 153 uses the following terms: 155 tLDP : Targeted LDP 156 TAC : Targeted Application Capability 157 TAE : Targeted Application Element 158 TA-Id : Targeted Application Identifier 159 SAC : State Advertisement Control Capability 160 LSR : Label Switching Router 161 mLDP : Multipoint LDP 162 PQ : Remote-LFA nexthops 163 RSVP-TE : RSVP Traffic Engineering 164 P2MP : Point-to-Multipoint 165 PW : Pseudowire 166 P2P-PW : Point-to-point Psuedowire 167 MP2MP : Multipoint-to-Multipoint 168 HSMP LSP: Hub and Spoke Multipoint Label Switched Path 169 LSP : Label Switched Path 170 MP2P : Multipoint-to-point 171 MPT : Merge Point 173 2. Targeted Application Capability 175 2.1 Encoding 177 An LSR MAY advertise that it is capable of negotiating a targeted LDP 178 application list over a tLDP session by using the Capability 179 Advertisement as defined in [RFC5561] and encoded as follows: 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 |U|F| TLV Code Point | Length | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 |S| Reserved | | 187 +-+-+-+-+-+-+-+-+ Capability Data | 188 | +-+-+-+-+-+-+-+-+ 189 | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 This document defines a new optional capability TLV of type TBD1 192 called 'Targeted Application Capability (TAC)'. Flag "U" MUST be 193 set to 1 to indicate that this capability must be silently ignored 194 if unknown. The TAC's Capability Data contains the Targeted 195 Application Element (TAE) information encoded as follows: 197 Targeted Application Element(TAE) 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Targ. Appl. Id |E| Reserved | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Targeted Application Identifier (TA-Id): 206 a 16 bit Targeted Application Identifier value. 208 E-bit: The enable bit indicates whether the sender is 209 advertising or withdrawing the TAE. The E-bit value is used as 210 follows: 212 1 - The TAE is advertising the targeted application. 213 0 - The TAE is withdrawing the targeted application. 215 2.2 Procedures 217 At tLDP session establishment time, a LSR MAY include a new 218 capability TLV, TAC TLV, as an optional TLV in the LDP Initialization 219 message. The TAC TLV's Capability data MAY consist of zero or more 220 TAEs each pertaining to a unique TA-Id that a LSR supports over the 221 session. If the receiver LSR receives the same TA-Id in more than one 222 TAE, it MUST process the first element and ignore the duplicate 223 elements. If the receiver LSR receives an unknown TA-Id in the TAE, 224 it MUST silently ignore such a TAE and continue processing the rest 225 of the TLV. 227 If the receiver LSR does not receive the TAC TLV in the 228 Initialization message or it does not understand the TAC TLV, the TAC 229 negotiation is considered unsuccessful and the session establishment 230 proceeds as per [RFC5036]. On the receipt of a valid TAC TLV, an LSR 231 MUST generate its own TAC TLV with TAEs consisting of unique TA-Ids 232 that it supports over the tLDP session. If there is at least one TAE 233 common between the TAC TLV it has received and its own, the session 234 MUST proceed to establishment as per [RFC5036]. If not, A LSR MUST 235 send a 'Session Rejected/Targeted Application Capability Mis-Match' 236 Notification message to the peer and close the session. The 237 initiating LSR SHOULD tear down the corresponding tLDP adjacency 238 after sent or receipt of a 'Session Rejected/Targeted Application 239 Capability Mis-Match' Notification message to or from the responding 240 LSR respectively. 242 If both the peers support TAC TLV, an LSR decides to establish or 243 close a tLDP session based on the negotiated targeted application 244 list. For example, an initiating LSR advertises A, B and C as TA-Ids, 245 and the responding LSR advertises C, D and E as TA-Ids. Then the 246 negotiated TA-Id as per both the LSRs is C. Another example, an 247 initiating LSR advertises A, B and C as TA-Ids, and the responding 248 LSR, which acts as a passive LSR, advertises all the applications - 249 A, B, C, D and E - as TA-Ids that it supports over this session. Then 250 the negotiated targeted applications as per both the LSRs are A, B 251 and C. Finally, If the initiating LSR advertises A, B and C as a TA- 252 Ids and the responding LSR advertises D and E as TA-Ids, then the 253 negotiated targeted applications as per both the LSRs are none. 254 Therefore, if the intersection of the sets of received and sent TA-Id 255 is null, then LSR sends 'Session Rejected/Targeted Application 256 Capability Mis-Match' Notification message to the peer LSR and closes 257 the session. 259 When the responding LSR playing the active role [RFC5036] in LDP 260 session establishment receives a 'Session Rejected/Targeted 261 Application Capability Mis-Match' Notification message, it MUST set 262 its session setup retry interval to a maximum value, as such 0xffff. 263 The session MAY stay in NON EXISTENT state. When it detects a change 264 in the initiating LSR or local LSR configuration pertaining to TAC 265 TLV, it MUST clear the session setup back off delay associated with 266 the session to re-attempt the session establishment. A LSR detects 267 configuration change on the other LSR with the receipt of tLDP Hello 268 message that has a higher configuration sequence number than the 269 earlier tLDP Hello message. 271 When the initiating LSR playing the active role in LDP session 272 establishment receives a 'Session Rejected/Targeted Application 273 Capability Mis-Match' Notification message, either it MUST close the 274 session and tear down the corresponding tLDP adjacency or it MUST set 275 its session setup retry interval to a maximum value, as such 0xffff. 277 If the initiating LSR decides to tear down the associated tLDP 278 adjacency, the session is closed on the initiating as well as the 279 responding LSR. It MAY also take appropriate actions. For instance, 280 if an automatic session intended to support the Remote LFA 281 application is rejected by the responding LSR, the initiating LSR may 282 inform the IGP to calculate another PQ node [RFC7490] for the route 283 or set of routes. More specific actions are a local matter and 284 outside the scope of this document. 286 If the initiating LSR sets the session setup retry interval to 287 maximum, the session MAY stay in a non-existent state. When this LSR 288 detects a change in the responding LSR configuration or its own 289 configuration pertaining to TAC TLV, it MUST clear the session setup 290 back off delay associated with the session in order to re-attempt the 291 session establishment. 293 After a tLDP session has been established with TAC capability, the 294 initiating and responding LSR MUST distribute FEC-label bindings for 295 the negotiated applications only. For instance, if the tLDP session 296 is established for BGP auto discovered pseudowire, only FEC 129 label 297 bindings MUST be distributed over the session. Similarly, a LSR 298 operating in downstream on demand mode MUST request FEC-label 299 bindings for the negotiated applications only. 301 If the Targeted Application Capability and Dynamic Capability, 302 described in [RFC5561], are negotiated during session initialization, 303 TAC MAY be re-negotiated after session establishment by sending an 304 updated TAC TLV in LDP Capability message. The updated TAC TLV 305 carries TA-Ids with incremental update only. The updated TLV MUST 306 consist of one or more TAEs with E-bit set or E-bit off to advertise 307 or withdraw the new and old application respectively. This may lead 308 to advertisements or withdrawals of certain types of FEC-Label 309 bindings over the session or tear down of the tLDP adjacency and 310 subsequently the session. 312 The Targeted Application Capability is advertised on tLDP session 313 only. If the tLDP session changes to link session, a LSR SHOULD 314 withdraw it with S bit set to 0. Similarly, if the link session 315 changes to tLDP, a LSR SHOULD advertise it via the Capability 316 message. If the capability negotiation fails, this may lead to 317 destruction of the tLDP session. 319 By default, LSR SHOULD accept tLDP hellos in order to then accept or 320 reject the tLDP session based on the application information. 322 In addition, LSR SHOULD allow the configuration of any TA-Id in order 323 to facilitate private TA-Id's usage by a network operator. 325 2.3 LDP message procedures 327 2.3.1 Initialization message 329 1. The S-bit of the Targeted Application Capability TLV MUST be 330 set to 1 to advertise Targeted Application Capability and 331 SHOULD be ignored on the receipt as defined in [RFC5561] 333 2. The E-bit of the Targeted Application Element MUST be set to 1 to 334 enable Targeted application and SHOULD be ignored on the receipt. 336 3. An LSR MAY add State Control Capability by mapping Targeted 337 Application Element to State Advertisement Control (SAC) Elements 338 as defined in Section 4. 340 2.3.2 Capability message 342 The initiating or responding LSR may re-negotiate the TAC after local 343 configuration change with the Capability message. 345 1. The S-bit of TAC is set to 1 or 0 to advertise or withdraw it. 347 2. After configuration change, If there is no common TAE between 348 its new TAE list and peers TAE list, the LSR MUST send a 349 'Session Rejected/Targeted Application Capability Mis-Match' 350 Notification message and close the session. 352 3. If there is a common TAE, a LSR MAY also update SAC Capability 353 based on updated TAC as described in section 4 and send the 354 updated TAC and SAC capabilities in a Capability message to 355 the peer. 357 4. A receiving LSR processes the Capability message with TAC TLV. 358 If the S-bit is set to 0, the TAC is disabled for the session. 360 5. If the S-bit is set to 1, a LSR process a list of TAEs from 361 TACs capability data with E-bit set to 1 or 0 to update the 362 peer's TAE. 364 3. Targeted Application FEC Advertisement Procedures 366 The targeted LDP application MUST be mapped to LDP FEC element types 367 as follows to advertise only necessary LDP FEC-Label bindings over 368 the tLDP session. 370 Targeted Application Description FEC mappings 371 +----------------------+------------------------+------------------+ 372 |LDPv4 Tunneling | LDP IPv4 over RSVP-TE | IPv4 prefix | 373 | | or other MPLS tunnel | | 374 +----------------------+------------------------+------------------+ 375 | | | | 376 |LDPv6 Tunneling | LDP IPv6 over RSVP-TE | IPv6 prefix | 377 | | or other MPLS tunnel | | 378 +----------------------+------------------------+------------------+ 379 |mLDP Tunneling | mLDP over RSVP-TE or | P2MP | 380 | | or other MPLS tunnel | MP2MP-up | 381 | | | MP2MP-down | 382 | | | HSMP-downstream | 383 | | | HSMP-upstream | 384 +----------------------+------------------------+------------------+ 385 | | | | 386 |LDPv4 Remote LFA | LDPv4 over LDPv4 or | IPv4 prefix | 387 | | other MPLS tunnel | | 388 +----------------------+------------------------+------------------+ 389 |LDPv6 Remote LFA | LDPv6 over LDPv6 or | IPv6 prefix | 390 | | other MPLS tunnel | | 391 +----------------------+------------------------+------------------+ 392 | | | | 393 |LDP FEC 128 PW | LDP FEC 128 Pseudowire | PWid FEC Element | 394 +----------------------+------------------------+------------------+ 395 | | | | 396 |LDP FEC 129 PW | LDP FEC 129 Pseudowire | Generalized PWid | 397 | | | FEC Element | 398 +----------------------+------------------------+------------------+ 399 | | | FEC types as | 400 |LDP Session Protection| LDP session protection | per protected | 401 | | | session | 402 +----------------------+------------------------+------------------+ 403 |LDP ICCP | LDP Inter-chasis | | 404 | | control protocol | None | 405 +----------------------+------------------------+------------------+ 406 | | | | 407 |LDP P2MP PW | LDP P2MP Pseudowire | P2MP PW Upstream | 408 | | | FEC Element | 409 +----------------------+------------------------+------------------+ 410 | | | P2MP | 411 |mLDP Node Protection | mLDP node protection | MP2MP-up | 412 | | | MP2MP-down | 413 | | | HSMP-downstream | 414 | | | HSMP-upstream | 415 +----------------------+------------------------+------------------+ 416 | | | | 417 |IPv4 intra-area FECs | IPv4 intra-area FECs | IPv4 prefix | 418 +----------------------+------------------------+------------------+ 419 | | | | 420 |IPv6 intra-area FECs | IPv6 intra-area FECs | IPv6 prefix | 421 +----------------------+------------------------+------------------+ 423 Intra-area FECs : FECs that are on the shortest path tree and not 424 leafs of the shortest path tree. 426 4. Interaction of Targeted Application Capabilities and State 427 Advertisement Control Capabilities 428 As described in this document, the set of TAEs negotiated between two 429 LDP peers advertising TAC represents the willingness of both peers to 430 advertise state information for a set of applications. The set of 431 applications negotiated by the TAC mechanism is symmetric between the 432 two LDP peers. In the absence of further mechanisms, two LDP peers 433 will both advertise state information for the same set of 434 applications. 436 As described in [RFC7473], State Advertisement Control(SAC) TLV can 437 be used by an LDP speaker to communicate its interest or disinterest 438 in receiving state information from a given peer for a particular 439 application. Two LDP peers can use the SAC mechanism to create 440 asymmetric advertisement of state information between the two peers. 442 The TAC negotiation facilitates the awareness of targeted 443 applications to both the peers. It enables them to advertise only 444 necessary LDP FEC-label bindings corresponding to negotiated 445 applications. With the SAC, the responding LSR is not aware of 446 targeted applications. Thus it may be unable to communicate its 447 interest or disinterest to receive state information from the peer. 448 Therefore, when the responding LSR is not aware of targeted 449 applications such a remote LFA and BGP auto discovered pseudowires, 450 TAC mechanism should be used and when the responding LSR is aware 451 (with appropriate configuration) of targeted applications such as FEC 452 128 pseudowire, SAC mechanism should be used. Also after TAC 453 mechanism makes the responding LSR aware of targeted application, the 454 SAC mechanism may be used to communicate its disinterest in receiving 455 state information from the peer for a particular negotiated 456 application, creating asymmetric advertisements. 458 Thus, the TAC mechanism enables two LDP peers to symmetrically 459 advertise state information for negotiated targeted applications. 460 Further, the SAC mechanism enables both of them to asymmetrically 461 disable receipt of state information for some of the already 462 negotiated targeted applications. Collectively, both TAC and SAC 463 mechanisms can be used to control the FEC-label bindings that are 464 advertised over the tLDP session. For instance, suppose the 465 initiating LSR establishes a tLDP session to the responding LSR for 466 Remote LFA and FEC 129 PW targeted applications with TAC. So each LSR 467 advertises the corresponding FEC-Label bindings. Further, suppose 468 the initiating LSR is not the PQ node for responding LSRs Remote LFA 469 IGP calculations. In such a case, the responding LSR may use the SAC 470 mechanism to convey its disinterest in receiving state information 471 for Remote LFA targeted LDP application. 473 For a given tLDP session, the TAC mechanism can be used without the 474 SAC mechanism, and the SAC mechanism can be used without the TAC 475 mechanism. It is useful to discuss the behavior when TAC and SAC 476 mechanisms are used on the same tLDP session. The TAC mechanism MUST 477 take precedence over the SAC mechanism with respect to enabling 478 applications for which state information will be advertised. For a 479 tLDP session using the TAC mechanism, the LDP peers MUST NOT 480 advertise state information for an application that has not been 481 negotiated in the most recent TAE list (referred to as an un- 482 negotiated application). This is true even if one of the peers 483 announces its interest in receiving state information that 484 corresponds to the un-negotiated application by sending a SAC TLV. 485 In other words, when TAC is being used, SAC cannot and should not 486 enable state information advertisement for applications that have not 487 been enabled by TAC. 489 On the other hand, the SAC mechanism MUST take precedence over the 490 TAC mechanism with respect to disabling state information 491 advertisements. If an LDP speaker has announced its disinterest in 492 receiving state information for a given application to a given peer 493 using the SAC mechanism, its peer MUST NOT send state information for 494 that application, even if the two peers have negotiated that the 495 corresponding application via the TAC mechanism. 497 For the purposes of determining the correspondence between targeted 498 applications defined in this document and application state as 499 defined in [RFC7473] an LSR MUST use the following mappings: 501 LDPv4 Tunneling - IPv4 Prefix-LSPs 502 LDPv6 Tunneling - IPv6 Prefix-LSPs 503 LDPv4 Remote LFA - IPv4 Prefix-LSPs 504 LDPv6 Remote LFA - IPv6 Prefix-LSPs 505 LDP FEC 128 PW - FEC128 P2P-PW 506 LDP FEC 129 PW - FEC129 P2P-PW 508 An LSR MUST map Targeted Application to LDP capability as follows: 510 mLDP Tunneling - P2MP Capability, MP2MP Capability 511 and HSMP LSP Capability TLV 512 mLDP node protection - P2MP Capability, MP2MP Capability 513 and HSMP LSP Capability TLV 515 5. Use cases 517 5.1 Remote LFA Automatic Targeted session 519 The LSR determines that it needs to form an automatic tLDP session to 520 remote LSR based on IGP calculation as described in [RFC7490] or some 521 other mechanism, which is outside the scope of this document. The LSR 522 forms the tLDP adjacency and constructs an Initialization message 523 with TAC TLV with TAE as Remote LFA during session establishment. The 524 receiver LSR processes the LDP Initialization message and verifies 525 whether it is configured to accept a Remote LFA tLDP session. If it 526 is, it may further verify that establishing such a session does not 527 exceed the configured limit for Remote LFA sessions. If all these 528 conditions are met, the receiver LSR may respond back with an 529 Initialization message with TAC corresponding to Remote LFA, and 530 subsequently the session may be established. 532 After the session has been established with TAC capability, the 533 sender and receiver LSR distribute IPv4 or IPv6 FEC label bindings 534 over the session. Further, the receiver LSR may determine that it 535 does not need these FEC label bindings. So it may disable the receipt 536 of these FEC label bindings by mapping targeted application element 537 to state control capability as described in section 4. 539 5.2 FEC 129 Auto Discovery Targeted session 541 BGP auto discovery may determine whether the LSR needs to initiate an 542 auto-discovery tLDP session with a border LSR. Multiple LSRs may try 543 to form an auto discovered tLDP session with a border LSR. So, a 544 service provider may want to limit the number of auto discovered tLDP 545 sessions a border LSR can accept. As described in Section 2, LDP may 546 convey targeted applications with TAC TLV to border LSR. A border LSR 547 may establish or reject the tLDP session based on local 548 administrative policy. Also, as the receiver LSR becomes aware of 549 targeted applications, it can also employ an administrative policy 550 for security. For instance, it can employ a policy to accept all 551 auto-discovered session from source-list. 553 Moreover, the sender and receiver LSR must exchange FEC 129 label 554 bindings only over the tLDP session. 556 5.3 LDP over RSVP and Remote LFA targeted session 558 A LSR may want to establish a tLDP session to a remote LSR for LDP 559 over RSVP tunneling and Remote LFA applications. The sender LSR may 560 add both these applications as a unique Targeted Application Element 561 in the Targeted Application Capability data of a TAC TLV. The 562 receiver LSR may have reached a configured limit for accepting Remote 563 LFA automatic tLDP sessions, but it may have been configured to 564 accept LDP over RSVP tunneling. In such a case, the tLDP session is 565 formed for both LDP over RSVP and Remote LFA applications as both 566 need same FECs - IPv4 or IPv6 or both. 568 5.4 mLDP node protection targeted session 569 A merge point LSR may determine that it needs to form automatic tLDP 570 session to the upstream point of local repair (PLR) LSR for MP2P and 571 MP2MP LSP [RFC6388] node protection as described in the [RFC7715]. 572 The MPT LSR may add a new targeted LDP application - mLDP protection 573 - as a unique TAE in the Targeted Application Capability Data of a 574 TAC TLV and send it in the Initialization message to the PLR. If the 575 PLR is configured for mLDP node protection and establishing this 576 session does not exceed the limit of either mLDP node protection 577 sessions or automatic tLDP sessions, the PLR may decide to accept 578 this session. Also, the PLR may respond back with the initialization 579 message with a TAC TLV that has one of the TAEs as - mLDP protection, 580 and the session proceeds to establishment as per [RFC5036]. 582 6. Security Considerations 584 The Capability procedure described in this document does not 585 introduce any change to LDP Security Considerations section described 586 in [RFC5036]. 588 As described in [RFC5036], DoS attacks via Extended Hellos, which are 589 required to establish a tLDP session, can be addressed by filtering 590 Extended Hellos using access lists that define addresses with which 591 Extended Discovery is permitted. Further, as described in section 592 5.2 of this document, a LSR can employ a policy to accept all auto- 593 discovered Extended Hellos from the configured source addresses 594 list. 596 Also for the two LSRs supporting TAC, the tLDP session is only 597 established after successful negotiation of the TAC. The initiating 598 and receiving LSR MUST only advertise TA-Ids that they support. In 599 other words, what they are configured for over the tLDP session. 601 7. IANA Considerations 603 This document requires the assignment of a new code point for a 604 Capability Parameter TLVs from the IANA managed LDP registry "TLV 605 Type Name Space", corresponding to the advertisement of the Targeted 606 Applications capability. IANA is requested to assign the lowest 607 available value after 0x050B. 609 Value Description Reference 610 ----- -------------------------------- --------- 611 TBD1 Targeted Applications capability [this document] 613 This document requires the assignment of a new code point for a 614 status code from the IANA managed registry "STATUS CODE NAME SPACE" 615 on the Label Distribution Protocol (LDP) Parameters page, 616 corresponding to the notification of session Rejected/Targeted 617 Application Capability Mis-Match. IANA is requested to assign the 618 lowest available value after 0x0000004B. 620 Value E Description Reference 621 ----- - -------------------------------- --------- 622 TBD2 1 Session Rejected/Targeted 623 Application Capability Mis-Match [this document] 625 This document also creates a new name space 'the LDP Targeted 626 Application Identifier' on the Label Distribution Protocol (LDP) 627 Parameters page, that is to be managed by IANA. The range is 0x0001- 628 0xFFFE, with the following values requested in this document. 630 Value Description Reference 631 -------- ------------------------- --------------- 632 0x0000 Reserved [this document] 633 0x0001 LDPv4 Tunneling [this document] 634 0x0002 LDPv6 Tunneling [this document] 635 0x0003 mLDP Tunneling [this document] 636 0x0004 LDPv4 Remote LFA [this document] 637 0x0005 LDPv6 Remote LFA [this document] 638 0x0006 LDP FEC 128 PW [this document] 639 0x0007 LDP FEC 129 PW [this document] 640 0x0008 LDP Session Protection [this document] 641 0x0009 LDP ICCP [this document] 642 0x000A LDP P2MP PW [this document] 643 0x000B mLDP Node Protection [this document] 644 0x000C LDPv4 Intra-area FECs [this document] 645 0x000D LDPv6 Intra-area FECs [this document] 646 0x0001 - 0x1FFF Available for assignment 647 by IETF Review 648 0x2000 - 0F7FF Available for assignment 649 as first come first served 650 0xF800 - 0xFBFF Available for private use 651 0xFC00 - 0xFFFE Available for experimental use 652 0xFFFF Reserved [this document] 654 8. Acknowledgments 656 The authors wish to thank Nischal Sheth, Hassan Hosseini, Kishore 657 Tiruveedhul, Loa Andersson, Eric Rosen, Yakov Rekhter, Thomas 658 Beckhaus, Tarek Saad, Lizhong Jin and Bruno Decraene for doing the 659 detailed review. Thanks to Manish Gupta and Martin Ehlers for their 660 input to this work and many helpful suggestions. 662 9. Contributing Authors 663 Chris Bowers 664 Juniper Networks 665 1133 Innovation Way 666 Sunnyvale, CA 94089 667 USA 668 EMail: cbowers@juniper.net 670 Zhenbin Li 671 Huawei 672 Bld No.156 Beiqing Rd 673 Beijing 100095 674 China 675 Email: lizhenbin@huawei.com 677 10. References 679 10.1 Normative References 681 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 682 "LDP Specification", RFC 5036, October 2007, 683 . 685 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 686 Le Roux, "LDP Capabilities", RFC 5561, July 2009, 687 . 689 [RFC7473] Kamran Raza, Sami Boutros, "Controlling State 690 Advertisements of Non-negotiated LDP Applications", RFC 691 7473, March 2015, . 694 [RFC7715] IJ. Wijnands, E. Rosen, K. Raza, J. Tantsura, A. Atlas, Q. 695 Zhao, "mLDP Node Protection", RFC 7715, January 2016, 696 . 698 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 699 Requirement Levels", BCP 14, RFC 2119, March 1997, 700 . 702 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 703 Key Words", BCP 14, RFC8174, May 2017, . 706 10.2 Informative References 708 [RFC7490] S. Bryant, C. Filsfils, S. Previdi, M. Shand, N. So, 709 "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 710 April 2015. 712 [RFC6074] E. Rosen, B. Davie, V. Radoaca, and W. Luo, "Provisioning, 713 Auto-Discovery, and Signaling in Layer 2 Virtual Private 714 Networks (L2VPNs)", January 2011. 716 [RFC6388] IJ. Wijnands, I. Minei, K. Kompella, B. Thomas, "Label 717 Distribution Protocol Extensions for Point-to-Multipoint 718 and Multipoint-to-Multipoint Label Switched Paths", 719 November 2011. 721 Authors' Addresses 723 Santosh Esale 724 Juniper Networks 725 1133 Innovation Way 726 Sunnyvale, CA 94089 727 USA 728 EMail: sesale@juniper.net 730 Raveendra Torvi 731 Juniper Networks 732 10 Technology Park Drive 733 Westford, MA 01886 734 USA 735 EMail: rtorvi@juniper.net 737 Luay Jalil 738 Verizon 739 1201 E Arapaho Rd 740 Richardson, TX 75081 741 USA 742 Email: luay.jalil@verizon.com 744 Uma Chunduri 745 Huawei 746 2330 Central Expy 747 Santa Clara, CA 95050 748 USA 749 Email: uma.chunduri@huawei.com 751 Kamran Raza 752 Cisco Systems, Inc. 753 2000 Innovation Drive 754 Ottawa, ON K2K-3E8 755 Canada 756 E-mail: skraza@cisco.com