idnits 2.17.00 (12 Aug 2021) /tmp/idnits53176/draft-ietf-mpls-ldp-ip-pw-capability-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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2014) is 2775 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) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: draft-ietf-rtgwg-remote-lfa has been published as RFC 7490 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group Kamran Raza 3 Internet Draft Sami Boutros 4 Intended Status: Standards Track 5 Expires: April 18, 2015 Cisco Systems, Inc. 7 October 15, 2014 9 Controlling State Advertisements Of Non-negotiated LDP Applications 11 draft-ietf-mpls-ldp-ip-pw-capability-08.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents carefully, 42 as they describe your rights and restrictions with respect to this 43 document. Code Components extracted from this document must include 44 Simplified BSD License text as described in Section 4.e of the Trust 45 Legal Provisions and are provided without warranty as described in the 46 Simplified BSD License. 48 Abstract 50 There is no capability negotiation done for Label Distribution 51 Protocol (LDP) applications that setup Label Switched Paths (LSPs) for 52 IP prefixes or that signal Point-to-point (P2P) Pseudowires (PWs) for 53 Layer 2 Virtual Private Networks (L2VPNs). When an LDP session comes 54 up, an LDP speaker may unnecessarily advertise its local state for 55 such LDP applications even when the peer session is established for 56 some other applications like Multipoint LDP (mLDP) or Inter-Chassis 57 Communication Protocol (ICCP). This document defines a solution by 58 which an LDP speaker announces to its peer its disinterest in such 59 non-negotiated applications, thus disabling the unnecessary 60 advertisement of corresponding application state, which would have 61 otherwise be advertised over the established LDP session. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions used in this document . . . . . . . . . . . . . . . 4 67 3. Non-negotiated LDP applications . . . . . . . . . . . . . . . . 4 68 3.1. Non-interesting State . . . . . . . . . . . . . . . . . . . 4 69 3.1.1 Prefix-LSPs . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1.2 P2P-PWs . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Controlling State Advertisement . . . . . . . . . . . . . . . . 5 72 4.1. State Advertisement Control Capability . . . . . . . . . . 5 73 4.2. Capabilities Procedures . . . . . . . . . . . . . . . . . . 8 74 4.2.1. State Control Capability in an Initialization message . 8 75 4.2.2. State Control capability in a Capability message . . . 9 76 5. Applicability Statement . . . . . . . . . . . . . . . . . . . . 9 77 6. Operational Examples . . . . . . . . . . . . . . . . . . . . . 11 78 6.1. Disabling Prefix-LSPs and P2P-PWs on an ICCP session . . . 11 79 6.2. Disabling Prefix-LSPs on a L2VPN/PW T-LDP session . . . . . 11 80 6.3. Disabling Prefix-LSPs dynamically on an established LDP 81 session . . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 6.4. Disabling Prefix-LSPs on an mLDP-only session . . . . . . . 12 83 6.5. Disabling IPv4 or IPv6 Prefix-LSPs on a dual-stack LSR . . 12 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 13 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 9.1 Normative References . . . . . . . . . . . . . . . . . . . 13 88 9.2 Informative References . . . . . . . . . . . . . . . . . . 13 89 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 94 LDP Capabilities specification [RFC5561] introduced a mechanism to 95 negotiate LDP capabilities for a given feature between peer Label 96 Switching Routers (LSRs). The capability mechanism insures that no 97 unnecessary state is exchanged between peer LSRs unless the 98 corresponding feature capability is successfully negotiated between 99 the peers. 101 Newly defined LDP features and applications, such as Typed Wildcard 102 Forwarding Equivalence Class (FEC) [RFC5918], Inter-Chassis 103 Communication Protocol [RFC7275], mLDP [RFC6388], and L2VPN Point-to- 104 multipoint (P2MP) PW [P2MP-PW] make use of LDP capabilities framework 105 for their feature negotiation. However, the earlier LDP application to 106 establish LSPs for IP unicast prefixes, and application to signal 107 L2VPN P2P PW [RFC4447] [RFC4762] allowed LDP speakers to exchange 108 application state without any capability negotiation, thus causing 109 unnecessary state advertisement when a given application is not 110 enabled on one of the LDP speakers participating in a given session. 111 For example, when bringing up and using an LDP peer session with a 112 remote Provider Edge (PE) LSR for purely ICCP signaling reasons, an 113 LDP speaker may unnecessarily advertise labels for IP (unicast) 114 prefixes to this ICCP related LDP peer. 116 Another example of unnecessary state advertisement can be cited when 117 LDP is to be deployed in an IP dual-stack environment. For instance, 118 an LSR that is locally enabled to setup LSPs for both IPv4 and IPv6 119 prefixes may advertise (address and label) bindings for both IPv4 and 120 IPv6 address families towards an LDP peer that is interested in IPv4 121 bindings only. In this case, the advertisement of IPv6 bindings to the 122 peer is unnecessary, as well as wasteful, from the point of view of 123 LSR memory/CPU and network resource consumption. 125 To avoid this unnecessary state advertisement and exchange, currently 126 an operator is typically required to configure and define filtering 127 policies on the LSR, which introduces unnecessary operational overhead 128 and complexity for such deployments. 130 This document defines an LDP Capabilities [RFC5561] based solution by 131 which an LDP speaker may announce to its peer(s) its disinterest (or 132 non-support) for state to setup IP Prefix LSPs and/or to signal L2VPN 133 P2P PW at the time of session establishment. This capability helps in 134 avoiding unnecessary state advertisement for such feature 135 applications. This document also states the mechanics to dynamically 136 disable or enable the state advertisement for such applications during 137 the session lifetime. The non-interesting state of an application 138 depends on the type of application and is described later in section 139 3.1. 141 2. 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 The term "IP" in this document refers to both IPv4 and IPv6 unicast 148 address families. 150 3. Non-negotiated LDP applications 152 For the applications that existed prior to the definition of LDP 153 Capabilities framework [RFC5561], an LDP speaker typically advertises, 154 without waiting for any capabilities exchange and negotiation, its 155 corresponding application state to its peers after the session 156 establishment. These early LDP applications include: 158 o IPv4/IPv6 Prefix LSPs Setup 159 o L2VPN P2P FEC128 and FEC129 PWs signaling 161 This document onward uses following shorthand terms for these earlier 162 LDP applications: 164 o "Prefix-LSPs": Refers to an application that sets up LDP LSPs 165 corresponding to IP routes/prefixes by advertising label 166 bindings for Prefix FEC (as defined in RFC-5036). 168 o "P2P-PWs": Refers to an application that signals FEC 128 and/or 169 FEC 129 L2VPN P2P Pseudowires using LDP (as defined in RFC-4447). 171 To disable unnecessary state exchange for such LDP applications over 172 an established LDP session, a new capability is being introduced in 173 this document. This new capability controls the advertisement of 174 application state and enables an LDP speaker to notify its peer its 175 disinterest in the state of one or more of these "Non-negotiated" LDP 176 applications at the time of session establishment. Upon receipt of 177 such capability, the receiving LDP speaker, if supporting the 178 capability, disables the advertisement of the state related to the 179 application towards the sender of the capability. This new capability 180 can also be sent later in a Capability message to either disable a 181 previously enabled application's state advertisement or to enable a 182 previously disabled application's state advertisement. 184 3.1. Non-interesting State 186 A non-interesting state of a non-negotiated LDP application: 187 - is the application state which is of a no interest to an LSR and 188 need not be advertised to the LSR; 190 - need not be advertised in any of the LDP protocol messages; 191 - is dependent on application type and specified accordingly. 193 3.1.1 Prefix-LSPs 195 For Prefix-LSPs application type, the non-interesting state refers to 196 any state related to IP Prefix FEC (such as FEC label bindings, LDP 197 Status). This document, however, does not classify IP address 198 bindings (advertised via ADDRESS message) as a non-interesting state 199 and allows the advertisement of IP Address bindings. The reason for 200 this allowance is that an LSR typically uses peer IP address(es) to 201 map an IP routing nexthop/address to an LDP peer for their 202 functionality. For example, mLDP [RFC6388] uses peer's IP address(es) 203 to determine its upstream LSR to reach Root node as well as to select 204 forwarding interface towards its downstream LSR. Hence in an mLDP- 205 only network, while it is desirable to disable advertisement of label 206 bindings for IP (unicast) Prefixes, disabling advertisement of IP 207 address bindings will break mLDP functionality. Similarly, other LDP 208 applications may also depend on learnt peer IP address and hence this 209 document does not put IP address binding into a non-interesting state 210 category to facilitate such LDP applications. 212 3.1.2 P2P-PWs 214 For P2P-PWs application type, the non-interesting state refers to any 215 state related to P2P PW FEC128/FEC129 (such as FEC label bindings, 216 MAC [address] withdrawal, and LDP PW Status). From now onward in this 217 document, the term "state" will mean to refer to the "non-interesting 218 state" for an application, as defined in this section. 220 4. Controlling State Advertisement 222 To control advertisement of non-interesting state related to non- 223 negotiated LDP applications defined in section 3, a new capability 224 TLV is defined as follows. 226 4.1. State Advertisement Control Capability 228 The "State Advertisement Control Capability" is a new Capability 229 Parameter TLV defined in accordance with section 3 of LDP 230 Capabilities specification [RFC5561]. The format of this new TLV is 231 as follows: 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 |U|F|State Adv. Ctrl. Cap (IANA)| Length | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 |S| Reserved | | 239 +-+-+-+-+-+-+-+-+ 240 | | 241 ~ State Advertisement Control Element(s) ~ 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 1: Format of an "State Advertisement Control Capability" TLV 247 The value of the U-bit for the TLV MUST be set to 1 so that a 248 receiver MUST silently ignore this TLV if unknown to it, and continue 249 processing the rest of the message. Whereas, The value of F-bit MUST 250 be set to 0. Once advertised, this capability cannot be withdrawn; 251 thus S-bit MUST be set to 1 in an Initialization and Capability 252 message. 254 The capability data associated with this State Advertisement Control 255 (SAC) Capability TLV is one or more State Advertisement Control 256 Elements, where each element indicates enabling/disabling of 257 advertisement of non-interesting state for a given application. The 258 format of a SAC Element is defined as follows: 260 0 1 2 3 4 5 6 7 261 +-+-+-+-+-+-+-+-+ 262 |D| App |Unused | 263 +-+-+-+-+-+-+-+-+ 265 Figure 2: Format of "State Advertisement Control Element" 267 Where: 268 D bit: Controls the advertisement of the state specified in "App" 269 field: 270 1: Disable state advertisement 271 0: Enable state advertisement 272 When sent in an Initialization message, D bit MUST be set 273 to 1. 275 App: Defines the application type whose state advertisement is to be 276 controlled. The value of this field is defined as follows: 278 1: IPv4 Prefix-LSPs (LSPs for IPv4 prefixes) 279 2: IPv6 Prefix-LSPs (LSPs for IPv6 prefixes) 280 3: FEC128 P2P-PW (L2VPN PWid FEC signaling) 281 4: FEC129 P2P-PW (L2VPN Generalized PWid FEC signaling) 283 Any other value in this field MUST be treated as an error. 285 Unused: MBZ on transmit and ignored on receipt. 287 The "Length" field of SAC Capability TLV depends on the number of SAC 288 Elements present in the TLV. For example, if there are two elements 289 present, then the Length field is set to 3 octets. A receiver of this 290 capability TLV can deduce number of elements present in the TLV by 291 using the Length field. 293 From now onward, this document uses the term "element" to refer to a 294 SAC Element. 296 As described earlier, SAC Capability TLV MAY be included by an LDP 297 speaker in an Initialization message to signal to its peer LSR that 298 state exchange for one or more application(s) need to be disabled on 299 the given peer session. This TLV can also be sent later in a 300 Capability message to selectively enable or disable these 301 applications. If there are more than one elements present in a SAC 302 Capability TLV, the elements MUST belong to distinct app types and 303 the an app type MUST NOT appear more than once. If a receiver 304 receives such a malformed TLV, it SHOULD discard this TLV and 305 continue processing rest of the message. If an LSR receives a message 306 with a SAC capability TLV containing an element with "App" field set 307 to a value other than defined above, the receiver MUST ignore and 308 discard the element and continue processing the rest of the TLV. 310 To control more than one application state, a sender LSR can either 311 send a single capability TLV in a message with multiple elements 312 present, or can send separate messages with capability TLV specifying 313 one or more elements. A receiving LSR, however, MUST treat each 314 incoming capability TLV with an element corresponding to a given 315 application type as an update to its existing policy for the given 316 type. 318 To understand capability updates from an example, let us consider 2 319 LSRs, S (LDP speaker) and P (LDP peer), both of which support all the 320 non-negotiated applications listed earlier. By default, these LSR 321 will advertise state for these applications, as configured, to their 322 peer as soon as an LDP session is established. Now assume that P 323 receives from S a SAC capability in an Initialization message with 324 "IPv6 Prefix-LSPs" and "FEC129 P2P-PW" applications disabled. This 325 updates P's outbound policy towards S to advertise state related to 326 only IPv4 Prefix-LSPs and FEC128 P2P-PW applications. Later, P 327 receives another capability update from S via a Capability message 328 with "IPv6 Prefix-LSPs" enabled and "FEC128 P2P-PWs" disabled. This 329 results in P's outbound policy towards S to advertise both IPv4 and 330 IPv6 Prefix-LSPs application state, and disable both FEC128 and 331 FEC129 P2P-PWs signaling. Finally, P receives another update from S 332 via a Capability message that specifies to disable all four non- 333 negotiated applications state, resulting in P outbound policy towards 334 S to block/disable state for all these applications, and only 335 advertise state for any other application, as applicable. 337 4.2. Capabilities Procedures 339 The SAC capability conveys the desire of an LSR to disable the 340 receipt of unwanted/unnecessary state from its LDP peer. This 341 capability is unilateral and unidirectional in nature, and a 342 receiving LSR is not required to send a similar capability TLV in an 343 Initialization or Capability message towards the sender of this 344 capability. This unilateral behavior conforms to the procedures 345 defined in the Section 6 of LDP Capabilities [RFC5561]. 347 After this capability is successfully negotiated (i.e. sent by an LSR 348 and received/understood by its peer), then the receiving LSR MUST NOT 349 advertise any state related to the disabled applications towards the 350 capability sending LSR until and unless these application states are 351 explicitly enabled again via a capability update. Upon receipt of a 352 capability update to disable an enabled application [state] during 353 the lifetime of a session, the receiving LSR MUST also withdraw from 354 the peer any previously advertised state corresponding to the 355 disabled application. 357 If a receiving LDP speaker does not understand the SAC capability 358 TLV, then it MUST respond to the sender with "Unsupported TLV" 359 notification as described in LDP Capabilities [RFC5561]. If a 360 receiving LDP speaker does not understand or does not support an 361 application specified in an application control element, it SHOULD 362 silently ignore/skip such an element and continue processing rest of 363 the TLV. 365 4.2.1. State Control Capability in an Initialization message 367 LDP Capabilities [RFC5561] framework dictates that the S-bit of 368 capability parameter in an Initialization message MUST be set to 1 369 and SHOULD be ignored on receipt. 371 An LDP speaker determines (e.g. via some local configuration or 372 default policy) if it needs to disable Prefix-LSPs and/or P2P-PWs 373 applications with a peer LSR. If there is a need to disable, then the 374 SAC TLV needs to be included in the Initialization message with 375 respective SAC elements included with their D bit set to 1. 377 An LDP speaker that supports the SAC capability MUST interpret the 378 capability TLV in a received Initialization message such that it 379 disables the advertisement of the application state towards the 380 capability sending LSR for Prefix-LSPs and/or P2P-PWs applications if 381 their SAC element's D bit is set to 1. 383 4.2.2. State Control capability in a Capability message 385 If the LDP peer supports "Dynamic Announcement Capability" [RFC5561], 386 then an LDP speaker may send SAC capability in a Capability message 387 towards the peer. Once advertised, these capabilities cannot be 388 withdrawn and hence the S-bit of the TLV MUST be set to 1 when sent 389 in a Capability message. 391 An LDP speaker may decide to send this TLV towards an LDP peer if one 392 or more of its Prefix-LSPs and/or P2P-PWs applications get disabled, 393 or if previously disabled application gets enabled again. In this 394 case, the LDP speaker constructs the TLV with appropriate SAC 395 element(s) and sends the corresponding capability TLV in a Capability 396 message. 398 Upon receipt of this TLV in a Capability message, the receiving LDP 399 speaker reacts in the same manner as it reacts upon the receipt of 400 this TLV in an Initialization message. Additionally, the peer 401 withdraws/advertises the application state from/to the capability 402 sending LDP speaker according to the capability update. 404 5. Applicability Statement 406 The procedures defined in this document may result in disabling 407 announcement of label bindings for IP Prefixes and/or P2P PW FECs, 408 and hence should be used with caution and discretion. This document 409 recommends that this new SAC capability and its procedures SHOULD be 410 enabled on an LSR only via a configuration knob. This knob could 411 either be a global LDP knob or be implemented per LDP neighbor. 412 Hence, it is recommended that an operator SHOULD enable this 413 capability and its associated procedures on an LSR towards a neighbor 414 only if it is known that such bindings advertisement and exchange 415 with the neighbor is unnecessary and wasteful. 417 Following table summarizes a non-exhaustive list of typical LDP 418 session types on which this new SAC capability and its procedures are 419 expected to be applied to disable advertisement of non-interesting 420 state: 422 +===============================+================================+ 423 | Session Type(s) | Non-interesting State | 424 +===============================+================================+ 425 | P2P-PW FEC128-only | IP Prefix LSPs + P2P-PW FEC129 | 426 |-------------------------------|--------------------------------| 427 | P2P-PW only (FEC128/129) | IP Prefix LSPs | 428 |-------------------------------|--------------------------------| 429 | IPv4-only on a Dual-Stack LSR | IPv6 Prefix LSPs + P2P-PW | 430 |-------------------------------|--------------------------------| 431 | IPv6-only on a Dual-Stack LSR | IPv4 Prefix LSPs + P2P-PW | 432 |-------------------------------|--------------------------------| 433 | mLDP-only | IP Prefix LSPs + P2P-PW | 434 |-------------------------------|--------------------------------| 435 | ICCP-only | IP Prefix LSPs + P2P-PW | 436 +-------------------------------+--------------------------------+ 438 It is to be noted that if an application state needs changing after 439 session initialization (e.g. to enable previously disabled 440 application or to disable previously enabled application), the 441 procedures defined in this document expect LSR peers to support LDP 442 "Dynamic Announcement" Capability to announce the change in SAC 443 capability via LDP Capability message. However, if any of the peering 444 LSR does not support this capability, the alternate option is to 445 force reset the LDP session to advertise the new SAC capability 446 accordingly during the following session initialization. 448 Following are some more important points that an operator need to 449 consider regarding the applicability of this new capability and 450 associated procedures defined in this document: 452 - An operator SHOULD disable Prefix-LSPs state on any Targeted LDP (T-LDP) 453 session that is established for ICCP-only and/or PW-only purposes. 455 - An operator MUST NOT disable Prefix-LSPs state on any T-LDP session 456 that is established for remote LFA FRR [RLFA] reasons. 458 - In a remote LFA FRR [RLFA] enabled network, it is RECOMMENDED to 459 not disable Prefix-LSPs state on a T-LDP session even if the current 460 session type is PW-only and/or ICCP-only. This is recommended because 461 any remote/T-LDP neighbor could potentially be picked as a remote LFA 462 PQ node. 464 - This capability SHOULD be enabled for Prefix-LSPs in the 465 scenarios when it is desirable to disable (or enable) 466 advertisement of "all" the prefix label bindings. For scenarios 467 when a "subset" of bindings need to be filtered, the existing 468 filtering procedures pertaining to label binding announcement 469 should be used. 471 - It is allowed to use label advertisement filtering policies in 472 conjunction with the procedures defined in this document for 473 Prefix-LSPs. In such cases, the label bindings will be announced 474 as per the label filtering policy for the given neighbor when 475 Prefix-LSP application is enabled. 477 6. Operational Examples 479 6.1. Disabling Prefix-LSPs and P2P-PWs on an ICCP session 481 Consider two PE routers, LSR1 and LSR2, which understand/support SAC 482 capability TLV, and have an established LDP session to exchange ICCP 483 state related to dual-homed devices connected to these LSRs. Let us 484 assume that both LSRs are provisioned not to exchange any state for 485 Prefix-LSPs (IPv4/IPv6) and P2P-PWs (FEC128/129) application. 487 To indicate their disinterest in these applications, the LSRs will 488 include a SAC capability TLV (with 4 SAC elements corresponding to 489 these 4 applications with D bit set to 1 for each one) in the 490 Initialization message. Upon receipt of this TLV in Initialization 491 message, the receiving LSR will disable the advertisement of 492 IPv4/IPv6 label bindings, as well as P2P PW FEC128/129 signaling, 493 towards its peer after session establishment. 495 6.2. Disabling Prefix-LSPs on a L2VPN/PW T-LDP session 497 Now, consider LSR1 and LSR2 have an established T-LDP session for 498 P2P-PWs application to exchange label bindings for FEC 128/129. Given 499 that there is no need to exchange IP label bindings amongst the PE 500 LSRs over a PW T-LDP session in most typical deployments, let us 501 assume that LSRs are provisioned to disable IPv4/IPv6 Prefix-LSPs 502 application state on the given PW session. 504 To indicate their disinterest in Prefix-LSPs application over a PW T- 505 LDP session, the LSRs will follow/apply the same procedures as 506 described in previous section. As a result, only P2P-PWs related 507 state will be exchanged between these LSRs over this T-LDP session. 509 6.3. Disabling Prefix-LSPs dynamically on an established LDP session 511 Assume that LSRs from previous sections were initially provisioned to 512 exchange both Prefix-LSPs and P2P-PWs state over the session between 513 them, and also support "Dynamic Announcement" Capability [RFC5561]. 514 Now, assume that LSR1 is dynamically provisioned to disable 515 (IPv4/IPv6) Prefix-LSPs over T-LDP session with LSR2. In this case, 516 LSR1 will send SAC capability TLV in a Capability message towards 517 LSR2 with application control elements defined for IPv4 and IPv6 518 Prefix-LSPs with D bit set to 1. Upon receipt of this TLV, LSR2 will 519 disable Prefix-LSPs application state(s) towards LSR1 and withdraw 520 all previously advertised application state from LSR1. To withdraw 521 label bindings from its peer, LSR2 MAY use a single Prefix FEC Typed 522 Wildcard Label Withdraw message [RFC5918] if the peer supports Typed 523 Wildcard FEC capability. 525 This dynamic disability of Prefix-LSPs application does not impact 526 L2VPN P2P-PWs application on the given session, and both LSRs should 527 continue to exchange PW Signaling application related state. 529 6.4. Disabling Prefix-LSPs on an mLDP-only session 531 Now assume that LSR1 and LSR2 have formed an LDP session to exchange 532 mLDP state only. In typical deployments, LSR1 and LSR2 also exchange 533 bindings for IP (unicast) prefixes upon mLDP session, which is 534 unnecessary and wasteful for an mLDP-only LSR. 536 Using the procedures defined earlier, an LSR can indicate its 537 disinterest in Prefix-LSPs application state to its peer upon session 538 establishment time or dynamically later via LDP capabilities update. 540 Reference to section 3.1, the peer disables the advertisement of any 541 state related to IP Prefix FECs, but still advertises IP address 542 bindings that are required for the correct operation of mLDP. 544 6.5. Disabling IPv4 or IPv6 Prefix-LSPs on a dual-stack LSR 546 In IP dual-stack scenarios, LSR2 may advertise unnecessary state 547 (e.g. IPv6 prefix label bindings) towards peer LSR1 corresponding to 548 IPv6 Prefix-LSPs application once a session is established mainly for 549 exchanging state for IPv4. The similar scenario also applies when 550 advertising IPv4 Prefix-LSPs state on a session meant for IPv6. The 551 SAC capability and its procedures defined in this document can help 552 to avoid such unnecessary state advertisement. 554 Consider IP dual-stack environment where LSR2 is enabled for Prefix- 555 LSPs application for both IPv4 and IPv6, but LSR1 is enabled for (or 556 interested in) only IPv4 Prefix-LSPs. To avoid receiving unwanted 557 state advertisement for IPv6 Prefix-LSPs application from LSR2, LSR1 558 can send SAC capability with element for IPv6 Prefix-LSPs with D bit 559 set to 1 in the Initialization message towards LSR2 at the time of 560 session establishment. Upon receipt of this capability, LSR2 will 561 disable all IPv6 label binding advertisement towards LSR1. If IPv6 562 Prefix-LSPs application is later enabled on LSR1, LSR1 can update the 563 capability by sending SAC capability in a Capability message towards 564 LSR2 to enable this application dynamically. 566 7. Security Considerations 568 The proposal introduced in this document does not introduce any new 569 security considerations beyond that already apply to the base LDP 570 specification [RFC5036] and [RFC5920]. 572 8. IANA Considerations 574 This document defines a new LDP capability parameter TLV. IANA is 575 requested to assign the lowest available value after 0x0500 from "TLV 576 Type Name Space" in the "Label Distribution Protocol (LDP) 577 Parameters" registry as the new code point for the new LDP capability 578 TLV code point. 580 +-----+---------------------+---------------+-----------------------+ 581 |Value| Description | Reference |Notes/Registration Date| 582 +-----+---------------------+---------------+-----------------------+ 583 | TBA | State Advertisement | This document | | 584 | | Control Capability | | | 585 +-----+---------------------+---------------+-----------------------+ 587 9. References 589 9.1 Normative References 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, March 1997, 593 . 595 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 596 "LDP Specification", RFC 5036, October 2007, 597 . 599 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 600 Le Roux, "LDP Capabilities", RFC 5561, July 2009, 601 . 603 9.2 Informative References 605 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 606 G. Heron, "Pseudowire Setup and Maintenance Using the 607 Label Distribution Protocol (LDP)", RFC 4447, April 2006, 608 . 610 [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private 611 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 612 Signaling", RFC 4762, January 2007, . 615 [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution 616 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 617 (FEC)", RFC 5918, August 2010, . 620 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 621 Networks", RFC 5920, July 2010, . 624 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 625 Thomas, "Label Distribution Protocol Extensions for Point- 626 to-Multipoint and Multipoint-to-Multipoint Label Switched 627 Paths", RFC 6388, November 2011, . 630 [RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M., 631 Matsushima, S., and T. Nadeau, "Inter-Chassis 632 Communication Protocol for Layer 2 Virtual Private Network 633 (L2VPN) Provider Edge (PE) Redundancy", RFC 7275, June 634 2014, . 636 [P2MP-PW] Martini, L. et. al, "Signaling Root-Initiated Point-to- 637 Multipoint Pseudowires using LDP", draft-ietf-pwe3-p2mp- 638 pw-04.txt, Work in Progress, March 2012. 640 [RLFA] Bryant, S., Filsfils, C., Previdi, S., Shand, M., So, N., 641 "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-08, Work in 642 Progress, September 2014. 644 10. Acknowledgments 646 The authors would like to thank Eric Rosen and Alexander Vainshtein 647 for their review and valuable comments. We also acknowledge Karthik 648 Subramanian and IJsbrand Wijnands for bringing up mLDP use case. 650 Authors' Addresses 652 Kamran Raza 653 Cisco Systems, Inc., 654 2000 Innovation Drive, 655 Ottawa, ON K2K-3E8, Canada. 656 E-mail: skraza@cisco.com 658 Sami Boutros 659 Cisco Systems, Inc. 660 3750 Cisco Way, 661 San Jose, CA 95134, USA. 662 E-mail: sboutros@cisco.com