idnits 2.17.1 draft-esale-mpls-app-aware-tldp-03.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 (January 26, 2015) is 3378 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) == Unused Reference: 'I-D.draft-ietf-mpls-mldp-node-protection' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'RFC4762' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'RFC4447' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'RFC5331' is defined on line 700, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-mpls-mldp-node-protection-02 == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-remote-lfa-10 -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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 Chris Bowers 5 Expires: July 30, 2015 Juniper Networks 7 Luay Jalil 8 Verizon 10 U. Chunduri 11 Ericsson Inc. 13 Zhenbin Li 14 Huawei 16 Kamran Raza 17 Cisco Systems Inc. 19 January 26, 2015 21 Application-aware Targeted LDP 22 draft-esale-mpls-app-aware-tldp-03 24 Abstract 26 Recent targeted LDP applications such as remote loop-free alternates 27 (LFA) and BGP auto discovered pseudowire may automatically establish 28 a tLDP session to any LSR in a network. The initiating LSR has 29 information about the targeted applications to administratively 30 control initiation of the session. However the responding LSR has no 31 such information to control acceptance of this session. This document 32 defines a mechanism to advertise and negotiate Targeted Applications 33 Capability during LDP session initialization. As the responding LSR 34 becomes aware of targeted applications, it may establish a limited 35 number of tLDP sessions for certain applications. In addition, each 36 targeted application is mapped to LDP Forwarding Equivalence Class 37 (FEC) Elements to advertise only necessary LDP FEC-label bindings 38 over the session. 40 Status of this Memo 42 This Internet-Draft is submitted to IETF in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF), its areas, and its working groups. Note that 47 other groups may also distribute working documents as 48 Internet-Drafts. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 The list of current Internet-Drafts can be accessed at 56 http://www.ietf.org/1id-abstracts.html 58 The list of Internet-Draft Shadow Directories can be accessed at 59 http://www.ietf.org/shadow.html 61 Copyright and License Notice 63 Copyright (c) 2015 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.1 Conventions Used in This Document . . . . . . . . . . . . . 4 80 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 81 2. Targeted Application Capability . . . . . . . . . . . . . . . . 5 82 2.1 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 2.2 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6 84 2.3 LDP message procedures . . . . . . . . . . . . . . . . . . . 8 85 2.3.1 Initialization message . . . . . . . . . . . . . . . . . 8 86 2.3.2 Capability message . . . . . . . . . . . . . . . . . . . 8 87 3. Targeted Application FEC Advertisement Procedures . . . . . . . 9 88 4. Interaction of Targeted Application Capabilities and State 89 Advertisement Control Capabilities . . . . . . . . . . . . . . 10 90 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 5.1 Remote LFA Automatic Targeted session . . . . . . . . . . . 12 92 5.2 FEC 129 Auto Discovery Targeted session . . . . . . . . . . 13 93 5.3 LDP over RSVP and Remote LFA targeted session . . . . . . . 13 94 5.4 mLDP node protection targeted session . . . . . . . . . . . 13 95 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 96 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 97 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 15 98 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 99 9.1 Normative References . . . . . . . . . . . . . . . . . . . 15 100 9.2 Informative References . . . . . . . . . . . . . . . . . . 16 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 103 1 Introduction 105 LDP can use the extended discovery mechanism to establish a tLDP 106 adjacency and subsequent session as described in [RFC5036]. An LSR 107 initiates extended discovery by sending a tLDP Hello to a specific 108 address. The remote LSR decides either to accept or ignore a tLDP 109 Hello based on local configuration only. For an application such as 110 FEC 128 pseudowire, the remote LSR is configured with the source LSR 111 address, so the remote LSR can use that information to accept or 112 ignore a given tLDP Hello. 114 Applications such as Remote LFA and BGP auto discovered pseudowire 115 automatically initiate asymmetric extended discovery to any LSR in a 116 network based on local state only. With these applications, the 117 remote LSR is not explicitly configured with the source LSR address. 118 so the remote LSR either responds to all LDP requests or ignores all 119 LDP requests. 121 In addition, since the session is initiated and established after 122 adjacency formation, the responding LSR has no targeted applications 123 information to choose the targeted application it is configured to 124 support. Also, the initiating LSR may employ a limit per application 125 on locally initiated automatic tLDP sessions, however the responding 126 LSR has no such information to employ a similar limit on the incoming 127 tLDP sessions. Further, the responding LSR does not know whether the 128 source LSR is establishing a tLDP session for a configured or an 129 automatic application or both. 131 This document proposes and describes a solution to advertise Targeted 132 Application Capability, consisting of a targeted application list, 133 during initialization of a tLDP session. It also defines a mechanism 134 to enable a new application and disable an old application after 135 session establishment. This capability advertisement provides the 136 responding LSR with the necessary information to control the 137 acceptance of tLDP sessions per application. For instance, an LSR may 138 accept all BGP auto discovered tLDP sessions as defined in [RFC6074] 139 but may only accept limited number of Remote LFA tLDP sessions as 140 defined in [I-D.draft-ietf-rtgwg-remote-lfa] 142 Also, targeted LDP application is mapped to LDP FEC element type to 143 advertise specific application FECs only, avoiding the advertisement 144 of other unnecessary FECs over a tLDP session. 146 1.1 Conventions Used in This Document 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [RFC2119]. 152 1.2 Terminology 154 This document uses terminology discussed in [I-D.draft-ietf-mpls-ldp- 155 ip-pw-capability] along with others defined in this document. 157 TAC : Targeted Application Capability 158 TAE : Targeted Application Element 159 TA-Id : Targeted Application Identifier 160 SAC : State Advertisement Control Capability 162 2. Targeted Application Capability 164 2.1 Encoding 166 An LSR MAY advertise that it is capable to negotiate a targeted LDP 167 application list over a tLDP session by using the Capability 168 Advertisement as defined in [RFC5561]. 170 A new optional capability TLV is defined, 'Targeted Application 171 Capability (TAC)'. Its encoding is as follows: 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 |U|F| Targeted App. Cap.(IANA)| Length | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 |S| Reserved | | 179 +-+-+-+-+-+-+-+-+ | 180 | | 181 ~ Targeted App. Cap. data ~ 182 | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 As described in [RFC5561] 186 U: set to 1. Ignore, if not known. 187 F: Set to 0. Do not forward. 188 S: MUST be set to 1 or 0 to advertise or withdraw the Targeted 189 Application Capability TLV respectively. 191 Targeted Application Capability data: 192 A Targeted Applications Capability data consists of none, one 193 or more 32 bit Targeted Application Elements. Its encoding is 194 as follows: 196 Targeted Application Element(TAE) 198 0 1 2 3 199 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 |E| Targ. Appl. Id | 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 Targeted Application. 210 The E-bit value is used as follows: 212 1 - The TAE is advertising the targeted application. 213 0 - The TAE is withdrawing the targeted application. 215 The length of TAC depends on the number of TAEs. For instance, 216 if two TAEs are added, the length is set to 9. 218 2.2 Procedures 220 At tLDP session establishment time, a LSR MAY include a new 221 capability TLV, Targeted Application Capability (TAC) TLV, as an 222 optional TLV in the LDP Initialization message. The TAC TLV's 223 Capability data MUST consists of none, one or more Targeted 224 Application Element(TAE) each pertaining to a unique Targeted 225 Application Identifier(TA-Id) that a LSR supports over the session. 226 If the receiver LSR receives the same TA-Id in more than one TAE, it 227 MUST process the first element and ignore the duplicate elements. If 228 the receiver LSR receives an unknown TA-Id in a TAE, it MUST silently 229 ignore such a TAE and continue processing the rest of the TLV. 231 If the receiver LSR does not receive the TAC in the Initialization 232 message or it does not understand the TAC TLV, the TAC negotiation 233 MUST be considered unsuccessful and the session establishment MUST 234 proceed as per [RFC5036]. On the receipt of a valid TAC TLV, an LSR 235 MUST generate its own TAC TLV with TAEs consisting of unique TA-Ids 236 that it supports over the tLDP session. If there is at least one TAE 237 common between the TAC TLV it has received and its own, the session 238 MUST proceed to establishment as per [RFC5036]. If not, A LSR MUST 239 send a 'Session Rejected/Targeted Application Capability Mis-Match' 240 Notification message to the peer and close the session. The 241 initiating LSR SHOULD tear down the corresponding tLDP adjacency 242 after send or receipt of a 'Session Rejected/Targeted Application 243 Capability Mis-Match' Notification message to or from the responding 244 LSR respectively. 246 If both the peers advertise TAC, an LSR decides to establish or close 247 a tLDP session based on the negotiated targeted application list. For 248 instance, suppose a initiating LSR advertises A, B and C as TA-Ids. 249 Further, suppose the responding LSR advertises C, D and E as TA-Ids. 250 Than the negotiated TA-Id, as per both the LSRs is C. In the second 251 instance, suppose a initiating LSR advertises A, B and C as TA-Ids 252 and the responding LSR, which acts as a passive LSR, advertises all 253 the applications - A, B, C, D and E that it supports over this 254 session. Than the negotiated targeted application as per both the 255 LSRs are A, B and C. In the last instance, suppose the initiating LSR 256 advertises A, B and C as a TA-Ids and the responding LSR advertises D 257 and E as TA-Ids, than the negotiated targeted applciations as per 258 both the LSRs is none. The Responding LSR sends 'Session 259 Rejected/Targeted Application Capability Mis-Match' Notification 260 message to the initiating LSR and may close the session. 262 When the responding LSR playing the active role in LDP session 263 establishment receives a 'Session Rejected/Targeted Application 264 Capability Mis-Match' Notification message, it MUST set its session 265 setup retry interval to a maximum value, as 0xffff. The session MAY 266 stay in non-existent state. When it detects a change in the 267 initiating LSR configuration or local LSR configuration pertaining to 268 TAC TLV, it MUST clear the session setup back off delay associated 269 with the session to re-attempt the session establishment. A LSR 270 detects configuration change on the other LSR with the receipt of 271 tLDP Hello message that has a higher configuration sequence number 272 than the earlier tLDP Hello message. 274 When the initiating LSR playing the active role in LDP session 275 establishment receives a 'Session Rejected/Targeted Application 276 Capability Mis-Match' Notification message, either it MUST close the 277 session and tear down the corresponding tLDP adjacency or it MUST set 278 its session setup retry interval to a maximum value, as 0xffff. 280 If it decides to tear down the associated tLDP adjacency, the session 281 is destroyed on the initiating as well as the responding LSR. The 282 initiating LSR MAY take appropriate actions if it is unable to bring 283 up the tLDP session. For instance, if an automatic session intended 284 to support the Remote LFA application is rejected by the responding 285 LSR, the initiating LSR may inform the IGP to calculate another PQ 286 node [I-D.draft-ietf-rtgwg-remote-lfa] for the route or set of 287 routes. More specific actions are a local matter and outside the 288 scope of this document. 290 If it sets the session setup retry interval to maximum, the session 291 MAY stay in a non-existent state. When this LSR detects a change in 292 the responding LSR configuration or its own configuration pertaining 293 to TAC TLV, it MUST clear the session setup back off delay associated 294 with the session to re-attempt the session establishment. 296 After a tLDP session has been established with TAC capability, the 297 initiating and responding LSR MUST distribute FEC-label bindings for 298 the negotiated applications only. For instance, if the tLDP session 299 is established for BGP auto discovered pseudowire, only FEC 129 label 300 bindings MUST be distributed over the session. Similarly, a LSR 301 operating in downstream on demand mode MUST request FEC-label 302 bindings for the negotiated applications only. 304 If the Targeted Application Capability and Dynamic Capability, as 305 described in [RFC5561], are negotiated during session initialization, 306 TAC MAY be re-negotiated after session establishment by sending an 307 updated TAC TLV in LDP Capability message. The updated TAC TLV 308 carries TA-Ids with incremental update only. The updated TLV MUST 309 consist of one or more TAEs with E-bit set or E-bit off to advertise 310 or withdraw the new and old application respectively. This may lead 311 to advertisements or withdrawals of certain types of FEC-Label 312 bindings over the session or tear down of the tLDP adjacency and 313 subsequently the session. 315 The Targeted Application Capability is advertised on tLDP session 316 only. If the tLDP session changes to link session, a LSR should 317 withdraw it with S bit set to 0, which indicates wildcard withdrawal 318 of all TAE elements. Similarly, if the link session changes to tLDP, 319 a LSR should advertise it via the Capability message. If the 320 capability negotiation fails, this may lead to destruction of the 321 tLDP session. 323 Also, currently the remote LSR accepts asymmetric extended Hellos by 324 default or by appropriate configuration. With this document, the LSR 325 MUST accept tLDP hellos in order to then accept or reject the tLDP 326 session based on the application information. 328 2.3 LDP message procedures 330 2.3.1 Initialization message disbaled 331 1. The S-bit of the Targeted Application Capability TLV MUST be 332 set to 1 to advertise Targeted Application Capability and 333 SHOULD be ignored on the receipt. 335 2. The E-bit of the Targeted Application Element MUST be set to 1 to 336 enable Targeted application and SHOULD be ignored on the receipt. 338 3. An LSR MAY add State Control Capability by mapping Targeted 339 Application Element to State Advertisement Control (SAC) Elements 340 as defined in Section 4. 342 2.3.2 Capability message 343 The initiating or responding LSR may re-negotiate the TAC after local 344 configuration change with the Capability message. 346 1. The S-bit of Targeted Application Capability is set to 1 or 0 347 to advertise or withdraw it. 349 2. After configuration change, If there is no common TAE between 350 its new TAE list and peers TAE list, the LSR MUST send a 351 'Session Rejected/Targeted Application Capability Mis-Match' 352 Notification message and close the session. 354 3. If there is a common TAE, a LSR MAY also update SAC Capability 355 based on updated TAC as described in section 4 and sends the 356 updated TAC and SAC capabilities in a Capability message to 357 the peer. 359 4. A receiving LSR processes the Capability message with TAC TLV. 360 If the S-bit is set to 0, the TAC is disabled for the session. 361 After that, the session may remain in established state or 362 torn down based on [RFC5036] rules. 364 5. If the S-bit is set to 1, a LSR process a list of TAEs from 365 TACs capability data with E-bit set to 1 or 0 to update the 366 peers TAE. Also, it updates the negotiated TAE list over the 367 tLDP session. 369 3. Targeted Application FEC Advertisement Procedures 371 The targeted LDP application MUST be mapped to LDP FEC element types 372 as follows to advertise only necessary LDP FEC-Label bindings over 373 the tLDP session. 375 Targeted Application Description FEC mappings 376 +----------------------+------------------------+------------------+ 377 |LDPv4 Tunneling | LDP IPv4 over RSVP-TE | IPv4 FEC | 378 | | or other MPLS tunnel | | 379 +----------------------+------------------------+------------------+ 380 | | | | 381 |LDPv6 Tunneling | LDP IPv6 over RSVP-TE | IPv6 FEC | 382 | | or other MPLS tunnel | | 383 +----------------------+------------------------+------------------+ 384 |mLDP Tunneling | mLDP over RSVP-TE or | P2MP FEC | 385 | | or other MPLS tunnel | MP2MP FEC | 386 | | | HSMP-downstream | 387 | | | FEC | 388 | | | HSMP-upstream FEC| 389 +----------------------+------------------------+------------------+ 390 | | | | 391 |LDPv4 Remote LFA | LDPv4 over LDPv4 or | IPv4 FEC | 392 | | other MPLS tunnel | | 393 +----------------------+------------------------+------------------+ 394 |LDPv6 Remote LFA | LDPv6 over LDPv6 or | IPv6 FEC | 395 | | other MPLS tunnel | | 396 +----------------------+------------------------+------------------+ 397 | | | | 398 |LDP FEC 128 PW | LDP FEC 128 Pseudowire | FEC 128 | 399 +----------------------+------------------------+------------------+ 400 | | | | 401 |LDP FEC 129 PW | LDP FEC 129 Pseudowire | FEC 129 | 402 +----------------------+------------------------+------------------+ 403 | | | FEC types as | 404 |LDP Session Protection| DP session protection | per protected | 405 | | other MPLS tunnel | session | 406 +----------------------+------------------------+------------------+ 407 |LDP ICCP | LDP Inter-chasis | | 408 | | control protocol | None | 409 +----------------------+------------------------+------------------+ 410 | | | | 411 |LDP P2MP PW | LDP P2MP Pseudowire | P2MP PW FEC | 412 +----------------------+------------------------+------------------+ 413 | | | P2MP FEC | 414 |mLDP Node Protection | mLDP node protection | MP2MP FEC | 415 | | | HSMP-downstream | 416 | | | FEC | 417 | | | HSMP-upstream FEC| 418 +----------------------+------------------------+------------------+ 419 | | | | 420 |IPv4 intra-area FECs | IPv4 intra-area FECs | IPv4 FECs | 421 +----------------------+------------------------+------------------+ 422 | | | | 423 |IPv6 intra-area FECs | IPv6 intra-area FECs | IPv6 FECs | 424 +----------------------+------------------------+------------------+ 426 4. Interaction of Targeted Application Capabilities and State 427 Advertisement Control Capabilities 429 As described in this document, the set of TAEs negotiated between two 430 LDP peers advertising TAC represents the willingness of both peers to 431 advertise state information for a set of applications. The set of 432 applications negotiated by the TAC mechanism is symmetric between the 433 two LDP peers. In the absence of further mechanisms, two LDP peers 434 will both advertise state information for the same set of 435 applications. 437 As described in [I-D.draft-ietf-mpls-ldp-ip-pw-capability], State 438 Advertisement Control(SAC) TLV can be used by an LDP speaker to 439 communicate its interest or disinterest in receiving state 440 information from a given peer for a particular application. Two LDP 441 peers can use the SAC mechanism to create asymmetric advertisement of 442 state information between the two peers. 444 The TAC negotiation facilitates the awareness of targeted 445 applications to both the peers. It enables them to advertise only 446 necessary LDP FEC-label bindings corresponding to negotiated 447 applications. With the SAC, the responding LSR is not aware of 448 targeted applications. Thus it may be unable to communicate its 449 interest or disinterest to receive state information from the peer. 450 However after TAC mechanism makes the responding LSR aware of 451 targeted application, the SAC mechanism may be used to communicate 452 its disinterest in receiving state information from the peer for a 453 particular negotiated application. 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 [I-D.draft-ietf-mpls-ldp-ip-pw-capability] an LSR MUST use 497 the following mappings: 499 LDPv4 Tunneling - IPv4 Prefix-LSPs 500 LDPv6 Tunneling - IPv6 Prefix-LSPs 501 LDPv4 Remote LFA - IPv4 Prefix-LSPs 502 LDPv6 Remote LFA - IPv6 Prefix-LSPs 503 LDP FEC 128 PW - FEC128 P2P-PW 504 LDP FEC 129 PW - FEC129 P2P-PW 506 An LSR MUST map Targeted Application to LDP capability as follows: 508 mLDP Tunneling - P2MP Capability, MP2MP Capability 509 and HSMP LSP Capability TLV 510 mLDP node protection - P2MP Capability, MP2MP Capability 511 and HSMP LSP Capability TLV 513 5. Use cases 515 5.1 Remote LFA Automatic Targeted session 517 An LSR determines that it needs to form an automatic tLDP session to 518 remote LSR based on IGP calculation as described in [I-D.draft-ietf- 519 rtgwg-remote-lfa] or some other mechanism, which is outside the scope 520 of this document. The LSR forms the tLDP adjacency and during session 521 setup, constructs an Initialization message with Targeted 522 Applications Capability (TAC) with Targeted Application Element (TAE) 523 as Remote LFA. The receiver LSR processes the LDP Initialization 524 message and verifies whether it is configured to accept a Remote LFA 525 tLDP session. If it is, it may further verify that establishing such 526 a session does not exceed the configured limit for Remote LFA 527 sessions. If all these conditions are met, the receiver LSR may 528 respond back with an Initialization message with TAC corresponding to 529 Remote LFA, and subsequently the session may be established. 531 After the session has been established with TAC capability, the 532 sender and receiver LSR distribute IPv4 or IPv6 FEC label bindings 533 over the session. Further, the receiver LSR may determine that it 534 does not need these FEC label bindings. So it may disable the receipt 535 of these FEC label bindings by mapping targeted application element 536 to state control capability as described in section 4. 538 5.2 FEC 129 Auto Discovery Targeted session 540 BGP auto discovery MAY determine whether an LSR needs to initiate an 541 auto-discovery tLDP session with a border LSR. Multiple LSRs MAY try 542 to form an auto discovered tLDP session with a border LSR. So, a 543 service provider may want to limit the number of auto discovered tLDP 544 sessions a border LSR may accept. As described in Section 2, LDP may 545 convey targeted applications with TAC TLV to border LSR. A border LSR 546 may establish or reject the tLDP session based on local 547 administrative policy. Also, as the receiver LSR becomes aware of 548 targeted applications, it can also employ an administrative policy 549 for security. For instance, it can employ a policy 'accept all auto- 550 discovered session from source-list'. 552 Moreover, the sender and receiver LSR MUST exchange FEC 129 label 553 bindings only over the tLDP session. 555 5.3 LDP over RSVP and Remote LFA targeted session 557 A LSR may want to establish a tLDP session to a remote LSR for LDP 558 over RSVP tunneling and Remote LFA applications. The sender LSR may 559 add both these applications as a unique Targeted Application Element 560 in the Targeted Application Capability data of a TAC TLV. The 561 receiver LSR MAY have reached a configured limit for accepting Remote 562 LFA automatic tLDP sessions, but it may also be configured to accept 563 LDP over RSVP tunneling. In such a case, the tLDP session is formed 564 for both LDP over RSVP and Remote LFA applications as both needs same 565 FECs - IPv4 and/or IPv6. 567 5.4 mLDP node protection targeted session 569 A merge point LSR may determines that it needs to form automatic tLDP 570 session to the upstream point of local repair (PLR) LSR for MP2P and 571 MP2MP LSP node protection as described in the [I-D.draft-ietf-mpls- 572 mldp-node-protection]. The MPT LSR may add a new targeted LDP 573 application - mLDP protection, as a unique TAE in the Targeted 574 Application Capability Data of a TAC TLV and send it in the 575 Initialization message to the PLR. If the PLR is configured for mLDP 576 node protection and establishing this session does not exceed the 577 limit of either mLDP node protection sessions or automatic tLDP 578 sessions, the PLR may decide to accept this session. Further, the PLR 579 responds back with the initialization message with a TAC TLV that has 580 one of the TAEs as - mLDP protection and the session proceeds to 581 establishment as per [RFC5036]. 583 6 Security Considerations 585 The Capability procedure described in this document will apply and 586 does not introduce any change to LDP Security Considerations section 587 described in [RFC5036]. 589 As described in [RFC5036], DoS attacks via Extended Hellos can be 590 addressed by filtering Extended Hellos using access lists that define 591 addresses with which Extended Discovery is permitted. Further, as 592 described in section 5.2 of this document, a LSR can employ a policy 593 to accept all auto-discovered Extended Hellos from the configured 594 source addresses list. 596 Also for the two LSRs supporting TAC, the tLDP session is only 597 established after successful negotiation of the TAC. When there is no 598 common targeted LDP application between two LSRs due to 599 administrative policy, the tLDP session is not established. 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 draft] 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 Description Reference 621 ----- -------------------------------- --------- 622 TBD2 Session Rejected/Targeted 623 Application Capability Mis-Match [This draft] 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 0x0000: Reserved 631 0x0001: LDPv4 Tunneling 632 0x0002: LDPv6 Tunneling 633 0x0003: mLDP Tunneling 634 0x0004: LDPv4 Remote LFA 635 0x0005: LDPv6 Remote LFA 636 0x0006: LDP FEC 128 PW 637 0x0007: LDP FEC 129 PW 638 0x0008: LDP Session Protection 639 0x0009: LDP ICCP 640 0x000A: LDP P2MP PW 641 0x000B: mLDP Node Protection 642 0x000C: LDPv4 Intra-area FECs 643 0x000D: LDPv6 Intra-area FECs 644 0xFFFF: Reserved 646 Following the policies outlined in IANA, Targeted Application 647 Identifiers in the range 0x0001 - 0x1FFF are allocated through an 648 IETF Consensus action, and Targeted Application Identifiers in the 649 range 0x2000 - 0x7FFE are allocated as First Come First Served. 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 for 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. 666 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 667 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 669 [I-D.draft-ietf-mpls-ldp-ip-pw-capability] Kamran Raza, Sami Boutros, 670 "Disabling IPoMPLS and P2P PW LDP Application's State 671 Advertisement", draft-ietf-mpls-ldp-ip-pw-capability-09 672 (work in progress), October 15, 2014. 674 [I-D.draft-ietf-mpls-mldp-node-protection] IJ. Wijnands, E. Rosen, K. 675 Raza, J. Tantsura, A. Atlas, Q. Zhao, "mLDP Node 676 Protection", draft-ietf-mpls-mldp-node-protection-02 (work 677 in progress), November 13, 2014. 679 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 680 Requirement Levels", BCP 14, RFC 2119, March 1997. 682 9.2 Informative References 684 [I-D.draft-ietf-rtgwg-remote-lfa] S. Bryant, C. Filsfils, S. Previdi, 685 M. Shand, N. So, "Remote LFA FRR", draft-ietf-rtgwg- 686 remote-lfa-10 (work in progress), September 26, 2014. 688 [RFC6074] E. Rosen, B. Davie, V. Radoaca, and W. Luo, "Provisioning, 689 Auto-Discovery, and Signaling in Layer 2 Virtual Private 690 Networks (L2VPNs)" 692 [RFC4762] M. Lasserre, and V. Kompella, "Virtual Private LAN Service 693 VPLS) Using Label Distribution Protocol (LDP) Signaling", 694 RFC 4762, January 2007. 696 [RFC4447] L. Martini, E. Rosen, El-Aawar, T. Smith, and G. Heron, 697 "Pseudowire Setup and Maintenance using the Label 698 Distribution Protocol", RFC 4447, April 2006. 700 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 701 Label Assignment and Context-Specific Label Space", RFC 702 5331, August 2008. 704 Authors' Addresses 706 Santosh Esale 707 Juniper Networks 708 1194 N. Mathilda Ave. 709 Sunnyvale, CA 94089 710 US 711 EMail: sesale@juniper.net 713 Raveendra Torvi 714 Juniper Networks 715 10 Technology Park Drive. 716 Westford, MA 01886 717 US 718 EMail: rtorvi@juniper.net 720 Chris Bowers 721 Juniper Networks 722 1194 N. Mathilda Ave. 723 Sunnyvale, CA 94089 724 US 725 EMail: cbowers@juniper.net 727 Luay Jalil 728 Verizon 729 1201 E Arapaho Rd. 730 Richardson, TX 75081 731 US 732 Email: luay.jalil@verizon.com 734 Uma Chunduri 735 Ericsson Inc. 736 300 Holger Way 737 San Jose, California 95134 738 US 739 Email: uma.chunduri@ericsson.com 741 Zhenbin Li 742 Huawei Bld No.156 Beiqing Rd. 743 Beijing 100095 744 China 745 Email: lizhenbin@huawei.com 747 Kamran Raza 748 Cisco Systems, Inc. 749 2000 Innovation Drive 750 Ottawa, ON K2K-3E8 751 Canada 752 E-mail: skraza@cisco.com