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