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