diff options
Diffstat (limited to 'doc/rfc/rfc8223.txt')
| -rw-r--r-- | doc/rfc/rfc8223.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc8223.txt b/doc/rfc/rfc8223.txt new file mode 100644 index 0000000..706a7cc --- /dev/null +++ b/doc/rfc/rfc8223.txt @@ -0,0 +1,1011 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Esale +Request for Comments: 8223 R. Torvi +Updates: 7473 Juniper Networks +Category: Standards Track L. Jalil +ISSN: 2070-1721 Verizon + U. Chunduri + Huawei + K. Raza + Cisco Systems, Inc. + August 2017 + + + Application-Aware Targeted LDP + +Abstract + + Recent Targeted Label Distribution Protocol (tLDP) applications, such + as remote Loop-Free Alternates (LFAs) and BGP auto-discovered + pseudowires, may automatically establish a tLDP session with any + Label Switching Router (LSR) in a network. The initiating LSR has + information about the targeted applications to administratively + control initiation of the session. However, the responding LSR has + no such information to control acceptance of this session. This + document defines a mechanism to advertise and negotiate the Targeted + Application Capability (TAC) during LDP session initialization. As + the responding LSR becomes aware of targeted applications, it may + establish a limited number of tLDP sessions for certain applications. + In addition, each targeted application is mapped to LDP Forwarding + Equivalence Class (FEC) elements to advertise only necessary LDP FEC + label bindings over the session. This document updates RFC 7473 for + enabling advertisement of LDP FEC label bindings over the session. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8223. + + + + + + +Esale, et al. Standards Track [Page 1] + +RFC 8223 Application-Aware tLDP August 2017 + + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Conventions Used in This Document ..........................4 + 1.2. Terminology ................................................4 + 2. Targeted Application Capability .................................5 + 2.1. Encoding ...................................................5 + 2.2. Procedures .................................................5 + 2.3. LDP Message Procedures .....................................8 + 2.3.1. Initialization Message ..............................8 + 2.3.2. Capability Message ..................................8 + 3. Targeted Application FEC Advertisement Procedures ...............9 + 4. Interaction of Targeted Application Capabilities and State + Advertisement Control Capabilities .............................10 + 5. Use Cases ......................................................12 + 5.1. Remote LFA Automatic Targeted Session .....................12 + 5.2. FEC 129 Auto-discovery Targeted Session ...................13 + 5.3. LDP over RSVP and Remote LFA Targeted Session .............13 + 5.4. mLDP Node Protection Targeted Session .....................13 + 6. Security Considerations ........................................14 + 7. IANA Considerations ............................................14 + 8. References .....................................................15 + 8.1. Normative References ......................................15 + 8.2. Informative References ....................................16 + Acknowledgments ...................................................17 + Contributors ......................................................17 + Authors' Addresses ................................................18 + + + + + + + + + +Esale, et al. Standards Track [Page 2] + +RFC 8223 Application-Aware tLDP August 2017 + + +1. Introduction + + LDP uses the Extended Discovery mechanism to establish the + Targeted LDP (tLDP) adjacency and subsequent session, as described in + [RFC5036]. A Label Switching Router (LSR) initiates Extended + Discovery by sending a tLDP Hello to a specific address. The remote + LSR decides to either accept or ignore the tLDP Hello based on local + configuration only. A tLDP application is an application that uses a + tLDP session to exchange information such as FEC label bindings + ("FEC" stands for "Forwarding Equivalence Class") with a peer LSR in + the network. For an application such as FEC 128 pseudowire, the + remote LSR is configured with the source LSR address so that it can + use that information to accept or ignore a given tLDP Hello. + + However, applications such as remote Loop-Free Alternates (LFAs) and + BGP auto-discovered pseudowires automatically initiate asymmetric + Extended Discovery to any LSR in a network based on local state only. + With these applications, the remote LSR is not explicitly configured + with the source LSR address. So, the remote LSR either responds to + all tLDP Hellos or ignores them. + + In addition, since the session is initiated and established after + adjacency formation, the responding LSR has no information on + targeted applications available from which it can choose a session + with a targeted application that it is configured to support. Also, + the initiating LSR may employ a limit per application on locally + initiated automatic tLDP sessions; however, the responding LSR has + no such information to employ a similar limit on the incoming tLDP + sessions. Further, the responding LSR does not know whether the + source LSR is establishing a tLDP session for configured + applications, automatic applications, or both. + + This document proposes and describes a solution to advertise the + Targeted Application Capability (TAC), consisting of a list of + targeted applications, during initialization of a tLDP session. It + also defines a mechanism to enable a new application and disable an + old application after session establishment. This capability + advertisement provides the responding LSR with the necessary + information to control the acceptance of tLDP sessions + per application. For instance, an LSR may accept all BGP + auto-discovered tLDP sessions as described in [RFC6074] but may only + accept a limited number of remote LFA tLDP sessions as described + in [RFC7490]. + + Also, the tLDP application is mapped to LDP FEC element types to + advertise specific application FECs only, avoiding the advertisement + of other unnecessary FECs over a tLDP session. + + + + +Esale, et al. Standards Track [Page 3] + +RFC 8223 Application-Aware tLDP August 2017 + + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +1.2. Terminology + + In addition to the terminology defined in [RFC7473], this document + uses the following terms: + + tLDP : Targeted LDP + TAC : Targeted Application Capability + TAE : Targeted Application Element + TA-Id : Targeted Application Identifier + SAC : State Advertisement Control + LSR : Label Switching Router + mLDP : Multipoint LDP + PQ node : Remote LFA next hops + RSVP-TE : RSVP Traffic Engineering + P2MP : Point-to-Multipoint + PW : Pseudowire + P2P-PW : Point-to-Point Pseudowire + MP2MP : Multipoint-to-Multipoint + HSMP LSP: Hub and Spoke Multipoint Label Switched Path + LSP : Label Switched Path + MP2P : Multipoint-to-Point + MPT : Merge Point + + + + + + + + + + + + + + + + + + + + + +Esale, et al. Standards Track [Page 4] + +RFC 8223 Application-Aware tLDP August 2017 + + +2. Targeted Application Capability + +2.1. Encoding + + An LSR MAY advertise that it is capable of negotiating a tLDP + application list over a tLDP session by using the capability + advertisement as defined in [RFC5561] and encoded as follows: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |U|F| TLV Code Point | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| Reserved | | + +-+-+-+-+-+-+-+-+ Capability Data | + | +-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Flag "U" MUST be set to 1 to indicate that this capability must be + silently ignored if unknown. The TAC's Capability Data field + contains the Targeted Application Element (TAE) information, encoded + as follows: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TA-Id |E| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + TA-Id: A 16-bit Targeted Application Identifier value. + + E: E-bit (Enable bit). Indicates whether the sender is + advertising or withdrawing the TAE. The E-bit value is used + as follows: + + 1 - The TAE is advertising the targeted application. + 0 - The TAE is withdrawing the targeted application. + +2.2. Procedures + + At tLDP session establishment time, an LSR MAY include a new + capability TLV, the TAC TLV, as an optional TLV in the LDP + Initialization message. The TAC TLV's Capability data MAY consist of + zero or more TAEs, each pertaining to a unique TA-Id that an LSR + supports over the session. If the receiver LSR receives the same + TA-Id in more than one TAE, it MUST process the first element and + + + + +Esale, et al. Standards Track [Page 5] + +RFC 8223 Application-Aware tLDP August 2017 + + + ignore the duplicate elements. If the receiver LSR receives an + unknown TA-Id in the TAE, it MUST silently ignore such a TAE and + continue processing the rest of the TLV. + + If the receiver LSR does not receive the TAC TLV in the + Initialization message or it does not understand the TAC TLV, the TAC + negotiation is considered unsuccessful and the session establishment + proceeds as per [RFC5036]. On receipt of a valid TAC TLV, an LSR + MUST generate its own TAC TLV with TAEs consisting of unique TA-Ids + that it supports over the tLDP session. If there is at least one + common TAE between the TAC TLV it has received and its own, the + session MUST proceed to establishment as per [RFC5036]. If not, an + LSR MUST send a 'Session Rejected/Targeted Application Capability + Mismatch' Notification message to the peer and close the session. + The initiating LSR SHOULD tear down the corresponding tLDP adjacency + after sending or receiving a 'Session Rejected/Targeted Application + Capability Mismatch' Notification message to or from the responding + LSR, respectively. + + If both of the peers support the TAC TLV, an LSR decides to establish + or close a tLDP session based on the negotiated list of targeted + applications. For example, an initiating LSR advertises A, B, and C + as TA-Ids, and the responding LSR advertises C, D, and E as TA-Ids. + Then, the negotiated TA-Id as per both LSRs is C. In another + example, an initiating LSR advertises A, B, and C as TA-Ids, and the + responding LSR, which acts as a passive LSR, advertises all of the + applications -- A, B, C, D, and E -- as TA-Ids that it supports over + this session. The negotiated targeted applications as per both LSRs + are then A, B, and C. Finally, if the initiating LSR advertises A, + B, and C as TA-Ids and the responding LSR advertises D and E as + TA-Ids, then the negotiated targeted applications as per both LSRs + are "none". Therefore, if the intersection of the sets of received + and sent TA-Ids is null, then the LSR sends a 'Session + Rejected/Targeted Application Capability Mismatch' Notification + message to the peer LSR and closes the session. + + When the responding LSR playing the active role [RFC5036] in LDP + session establishment receives a 'Session Rejected/Targeted + Application Capability Mismatch' Notification message, it MUST set + its session setup retry interval to a maximum value -- that is, + 0xFFFF. The session MAY stay in a non-existent state. When it + detects a change in the initiating LSR or local LSR configuration + pertaining to the TAC TLV, it MUST clear the session setup backoff + delay associated with the session to reattempt session establishment. + An LSR detects the configuration change on the other LSR upon receipt + of a tLDP Hello message that has a higher configuration sequence + number than the earlier tLDP Hello message. + + + + +Esale, et al. Standards Track [Page 6] + +RFC 8223 Application-Aware tLDP August 2017 + + + When the initiating LSR playing the active role in LDP session + establishment receives a 'Session Rejected/Targeted Application + Capability Mismatch' Notification message, it MUST either (1) close + the session and tear down the corresponding tLDP adjacency or (2) set + its session setup retry interval to a maximum value -- that is, + 0xFFFF. + + If the initiating LSR decides to tear down the associated tLDP + adjacency, the session is closed on the initiating LSR as well as the + responding LSR. It MAY also take appropriate actions. For instance, + if an automatic session intended to support the remote LFA + application is rejected by the responding LSR, the initiating LSR may + inform the IGP to calculate another PQ node [RFC7490] for the route + or set of routes. More specific actions are a local matter and are + outside the scope of this document. + + If the initiating LSR sets the session setup retry interval to + maximum, the session MAY stay in a non-existent state. When this LSR + detects a change in the responding LSR configuration or its own + configuration pertaining to the TAC TLV, it MUST clear the session + setup backoff delay associated with the session in order to reattempt + session establishment. + + After a tLDP session using the TAC mechanism has been established, + the initiating and responding LSRs MUST distribute FEC label bindings + for the negotiated applications only. For instance, if the tLDP + session is established for a BGP auto-discovered pseudowire, only FEC + 129 label bindings MUST be distributed over the session. Similarly, + an LSR operating in downstream on-demand mode MUST request FEC label + bindings for the negotiated applications only. + + If the TAC and the Dynamic Capability [RFC5561] are negotiated during + session initialization, the TAC MAY be renegotiated after session + establishment by sending an updated TAC TLV in the LDP Capability + message. The updated TAC TLV carries TA-Ids with an incremental + update only. The updated TLV MUST consist of one or more TAEs with + the E-bit set (1) or off (0), to advertise or withdraw the new + application and the old application, respectively. This may lead to + advertisements or withdrawals of certain types of FEC label bindings + over the session or to teardown of the tLDP adjacency and, + subsequently, the session. + + The TAC is advertised on the tLDP session only. If the tLDP session + changes to a link session, an LSR SHOULD withdraw it with the S-bit + set to 0. Similarly, if the link session changes to tLDP, an LSR + SHOULD advertise it via the Capability message. If the capability + negotiation fails, this may lead to destruction of the tLDP session. + + + + +Esale, et al. Standards Track [Page 7] + +RFC 8223 Application-Aware tLDP August 2017 + + + By default, an LSR SHOULD accept tLDP Hellos in order to then accept + or reject the tLDP session based on the application information. + + In addition, an LSR SHOULD allow the configuration of any TA-Id in + order to facilitate the use of private TA-Ids by a network operator. + +2.3. LDP Message Procedures + +2.3.1. Initialization Message + + 1. The S-bit of the TAC TLV MUST be set to 1 to advertise the TAC and + SHOULD be ignored on receipt, as described in [RFC5561]. + + 2. The E-bit of the TAE MUST be set to 1 to enable the targeted + application and SHOULD be ignored on receipt. + + 3. An LSR MAY add the State Advertisement Control Capability by + mapping the TAE to the State Advertisement Control (SAC) elements + as defined in Section 4. + +2.3.2. Capability Message + + After a change to local configuration, the initiating or responding + LSR may renegotiate the TAC via the Capability message. + + 1. The S-bit of the TAC is set to 1 or 0 to advertise or withdraw it. + + 2. After the configuration change, if there is no common TAE between + its new TAE list and the peer's TAE list, the LSR MUST send a + 'Session Rejected/Targeted Application Capability Mismatch' + Notification message and close the session. + + 3. If there is a common TAE, an LSR MAY also update the SAC + Capability based on the updated TAC, as described in Section 4, + and send the updated TAC and SAC Capability in a Capability + message to the peer. + + 4. A receiving LSR processes the Capability message with the TAC TLV. + If the S-bit is set to 0, the TAC is disabled for the session. + + 5. If the S-bit is set to 1, the LSR processes a list of TAEs from + the TAC's data with the E-bit set to 1 or 0 to update the + peer's TAE. + + + + + + + + +Esale, et al. Standards Track [Page 8] + +RFC 8223 Application-Aware tLDP August 2017 + + +3. Targeted Application FEC Advertisement Procedures + + The tLDP application MUST be mapped to LDP FEC element types as + follows to advertise only necessary LDP FEC label bindings over the + tLDP session. + + Targeted Application Description FEC Mappings + +----------------------+------------------------+------------------+ + |LDPv4 Tunneling | LDP IPv4 over RSVP-TE | IPv4 prefix | + | | or other MPLS tunnel | | + +----------------------+------------------------+------------------+ + | | | | + |LDPv6 Tunneling | LDP IPv6 over RSVP-TE | IPv6 prefix | + | | or other MPLS tunnel | | + +----------------------+------------------------+------------------+ + |mLDP Tunneling | mLDP over RSVP-TE or | P2MP | + | | other MPLS tunnel | MP2MP-up | + | | | MP2MP-down | + | | | HSMP-downstream | + | | | HSMP-upstream | + +----------------------+------------------------+------------------+ + | | | | + |LDPv4 remote LFA | LDPv4 over LDPv4 or | IPv4 prefix | + | | other MPLS tunnel | | + +----------------------+------------------------+------------------+ + |LDPv6 remote LFA | LDPv6 over LDPv6 or | IPv6 prefix | + | | other MPLS tunnel | | + +----------------------+------------------------+------------------+ + | | | | + |LDP FEC 128 PW | LDP FEC 128 Pseudowire | PWid FEC element | + +----------------------+------------------------+------------------+ + | | | | + |LDP FEC 129 PW | LDP FEC 129 Pseudowire | Generalized PWid | + | | | FEC element | + +----------------------+------------------------+------------------+ + | | | FEC types as | + |LDP Session Protection| LDP session protection | per protected | + | | | session | + +----------------------+------------------------+------------------+ + |LDP ICCP | LDP Inter-Chassis | | + | | Communication Protocol | None | + +----------------------+------------------------+------------------+ + | | | | + |LDP P2MP PW | LDP P2MP Pseudowire | P2MP PW Upstream | + | | | FEC element | + + + + + + +Esale, et al. Standards Track [Page 9] + +RFC 8223 Application-Aware tLDP August 2017 + + + +----------------------+------------------------+------------------+ + | | | P2MP | + |mLDP Node Protection | mLDP node protection | MP2MP-up | + | | | MP2MP-down | + | | | HSMP-downstream | + | | | HSMP-upstream | + +----------------------+------------------------+------------------+ + | | | | + |IPv4 intra-area FECs* | IPv4 intra-area FECs* | IPv4 prefix | + +----------------------+------------------------+------------------+ + | | | | + |IPv6 intra-area FECs* | IPv6 intra-area FECs* | IPv6 prefix | + +----------------------+------------------------+------------------+ + + * Intra-area FECs: FECs that are on the shortest-path tree and + are not leafs of the shortest-path tree. + +4. Interaction of Targeted Application Capabilities and State + Advertisement Control Capabilities + + As described in this document, the set of TAEs negotiated between two + LDP peers advertising the TAC represents the willingness of both + peers to advertise state information for a set of applications. The + set of applications negotiated by the TAC mechanism is symmetric + between the two LDP peers. In the absence of further mechanisms, two + LDP peers will both advertise state information for the same set of + applications. + + As described in [RFC7473], the SAC TLV can be used by an LDP speaker + to communicate its interest or disinterest in receiving state + information from a given peer for a particular application. Two LDP + peers can use the SAC mechanism to create asymmetric advertisements + of state information between the two peers. + + The TAC negotiation facilitates the awareness of targeted + applications to both of the peers. It enables them to advertise only + necessary LDP FEC label bindings corresponding to negotiated + applications. With the SAC, the responding LSR is not aware of + targeted applications. Thus, it may be unable to communicate its + interest or disinterest in receiving state information from the peer. + Therefore, when the responding LSR is not aware of targeted + applications such as remote LFAs and BGP auto-discovered pseudowires, + the TAC mechanism should be used, and when the responding LSR is + aware (with appropriate configuration) of targeted applications such + as FEC 128 pseudowire, the SAC mechanism should be used. Also, after + the TAC mechanism makes the responding LSR aware of targeted + applications, the SAC mechanism may be used to communicate its + + + + +Esale, et al. Standards Track [Page 10] + +RFC 8223 Application-Aware tLDP August 2017 + + + disinterest in receiving state information from the peer for a + particular negotiated application, creating asymmetric + advertisements. + + Thus, the TAC mechanism enables two LDP peers to symmetrically + advertise state information for negotiated targeted applications. + Further, the SAC mechanism enables both of them to asymmetrically + disable receipt of state information for some of the already- + negotiated targeted applications. Collectively, the TAC mechanism + and the SAC mechanism can both be used to control the FEC label + bindings that are advertised over the tLDP session. For instance, + suppose that the initiating LSR establishes a tLDP session, using the + TAC mechanism, with the responding LSR for remote LFA and FEC 129 PW + targeted applications. So, each LSR advertises the corresponding FEC + label bindings. Further, suppose that the initiating LSR is not the + PQ node for the responding LSR's remote LFA IGP calculations. In + such a case, the responding LSR may use the SAC mechanism to convey + its disinterest in receiving state information for remote LFA tLDP + applications. + + For a given tLDP session, the TAC mechanism can be used without the + SAC mechanism, and the SAC mechanism can be used without the TAC + mechanism. It is useful to discuss the behavior that occurs when the + TAC and SAC mechanisms are used on the same tLDP session. The TAC + mechanism MUST take precedence over the SAC mechanism with respect to + enabling applications for which state information will be advertised. + For a tLDP session using the TAC mechanism, the LDP peers MUST NOT + advertise state information for an application that has not been + negotiated in the most recent TAE list (referred to as a + non-negotiated application). This is true even if one of the peers + announces its interest in receiving state information that + corresponds to the non-negotiated application by sending a SAC TLV. + In other words, when the TAC mechanism is being used, the SAC + mechanism cannot and should not enable state information + advertisements for applications that have not been enabled by the TAC + mechanism. + + On the other hand, the SAC mechanism MUST take precedence over the + TAC mechanism with respect to disabling state information + advertisements. If an LDP speaker has announced its disinterest in + receiving state information for a given application to a given peer + using the SAC mechanism, its peer MUST NOT send state information for + that application, even if the two peers have negotiated the + corresponding application via the TAC mechanism. + + + + + + + +Esale, et al. Standards Track [Page 11] + +RFC 8223 Application-Aware tLDP August 2017 + + + For the purposes of determining the correspondence between targeted + applications defined in this document and application state as + defined in [RFC7473], an LSR MUST use the following mappings: + + LDPv4 Tunneling - IPv4 Prefix-LSPs + LDPv6 Tunneling - IPv6 Prefix-LSPs + LDPv4 Remote LFA - IPv4 Prefix-LSPs + LDPv6 Remote LFA - IPv6 Prefix-LSPs + LDP FEC 128 PW - FEC 128 P2P-PW + LDP FEC 129 PW - FEC 129 P2P-PW + + An LSR MUST map the targeted application to the LDP capability + as follows: + + mLDP Tunneling - P2MP Capability, MP2MP Capability, and HSMP LSP + Capability TLV + + mLDP Node Protection - P2MP Capability, MP2MP Capability, and HSMP + LSP Capability TLV + +5. Use Cases + +5.1. Remote LFA Automatic Targeted Session + + The LSR determines that it needs to form an automatic tLDP session + with a remote LSR based on IGP calculation as described in [RFC7490] + or some other mechanism outside the scope of this document. The LSR + forms the tLDP adjacency and constructs an Initialization message + with the TAC TLV consisting of the TAE as the remote LFA during + session establishment. The receiver LSR processes the LDP + Initialization message and verifies whether it is configured to + accept a remote LFA tLDP session. If it is, it may further verify + that establishing such a session does not exceed the configured limit + for remote LFA sessions. If all of these conditions are met, the + receiver LSR may respond back with an Initialization message with the + TAC corresponding to the remote LFA, and subsequently the session + may be established. + + After the session using the TAC mechanism has been established, the + sender and receiver LSRs distribute IPv4 or IPv6 FEC label bindings + over the session. Further, the receiver LSR may determine that it + does not need these FEC label bindings. So, it may disable the + receipt of these FEC label bindings by mapping the TAE to the State + Advertisement Control Capability as described in Section 4. + + + + + + + +Esale, et al. Standards Track [Page 12] + +RFC 8223 Application-Aware tLDP August 2017 + + +5.2. FEC 129 Auto-discovery Targeted Session + + BGP auto-discovery may determine whether the LSR needs to initiate an + auto-discovery tLDP session with a border LSR. Multiple LSRs may try + to form an auto-discovered tLDP session with a border LSR. So, a + service provider may want to limit the number of auto-discovered tLDP + sessions that a border LSR can accept. As described in Section 2, + LDP may convey targeted applications with the TAC TLV to a border + LSR. A border LSR may establish or reject the tLDP session based on + local administrative policy. Also, as the receiver LSR becomes aware + of targeted applications, it can also employ an administrative policy + for security. For instance, it can employ a policy to accept all + auto-discovered sessions from a source addresses list. + + Moreover, the sender and receiver LSRs must exchange FEC 129 label + bindings only over the tLDP session. + +5.3. LDP over RSVP and Remote LFA Targeted Session + + An LSR may want to establish a tLDP session with a remote LSR for + LDP-over-RSVP tunneling and remote LFA applications. The sender LSR + may add both of these applications as a unique TAE in the TAC data of + a TAC TLV. The receiver LSR may have reached a configured limit for + accepting remote LFA automatic tLDP sessions, but it may have been + configured to accept LDP-over-RSVP tunneling. In such a case, the + tLDP session is formed for both LDP-over-RSVP tunneling and remote + LFA applications, as both need the same FECs -- IPv4, IPv6, or both. + +5.4. mLDP Node Protection Targeted Session + + A Merge Point (MPT) LSR may determine that it needs to form an + automatic tLDP session with the upstream point of local repair (PLR) + LSR for MP2P and MP2MP LSP [RFC6388] node protection as described in + [RFC7715]. The MPT LSR may add a new tLDP application -- mLDP + protection -- as a unique TAE in the TAC data of a TAC TLV and send + it in the Initialization message to the PLR. If the PLR is + configured for mLDP node protection and establishing this session + does not exceed the limit of either mLDP node protection sessions or + automatic tLDP sessions, the PLR may decide to accept this session. + Also, the PLR may respond back with the Initialization message with a + TAC TLV that has one of the TAEs as mLDP protection, and the session + proceeds to establishment as per [RFC5036]. + + + + + + + + + +Esale, et al. Standards Track [Page 13] + +RFC 8223 Application-Aware tLDP August 2017 + + +6. Security Considerations + + The procedures described in this document do not introduce any + changes to LDP security considerations as described in [RFC5036]. + + As described in [RFC5036], DoS attacks via Extended Hellos, which are + required to establish a tLDP session, can be addressed by filtering + Extended Hellos using access lists that define addresses with which + Extended Discovery is permitted. Further, as described in + Section 5.2 of this document, an LSR can employ a policy to accept + all auto-discovered Extended Hellos from the configured source + addresses list. + + Also, for the two LSRs supporting the TAC, the tLDP session is only + established after successful negotiation of the TAC. The initiating + and receiving LSRs MUST only advertise TA-Ids that they support -- + in other words, what they are configured for over the tLDP session. + +7. IANA Considerations + + IANA has assigned the following code point for the new Capability + Parameter TLV defined in this document. The code point has been + assigned from the "TLV Type Name Space" sub-registry of the "Label + Distribution Protocol (LDP) Parameters" registry. + + Value Description Reference + ------ ------------------------------- --------- + 0x050F Targeted Application Capability RFC 8223 + + IANA has assigned a new status code from the "Status Code Name Space" + sub-registry of the "Label Distribution Protocol (LDP) Parameters" + registry. + + Value E Description Reference + ---------- --- ----------------------------------- --------- + 0x0000004C 1 Session Rejected/Targeted + Application Capability Mismatch RFC 8223 + + + + + + + + + + + + + + +Esale, et al. Standards Track [Page 14] + +RFC 8223 Application-Aware tLDP August 2017 + + + IANA has created a new registry called "LDP Targeted Application + Identifier" in the "Label Distribution Protocol (LDP) Parameters" + registry. The range is 0x0001-0xFFFE. Values in the range + 0x0001-0x1FFF in this registry shall be allocated according to the + "IETF Review" procedure [RFC8126]; values in the range 0x2000-0xF7FF + shall be allocated according to the "First Come First Served" + procedure [RFC8126]. The initial values are as follows. + + Value Description Reference + --------------- ------------------------------- --------- + 0x0000 Reserved RFC 8223 + 0x0001 LDPv4 Tunneling RFC 8223 + 0x0002 LDPv6 Tunneling RFC 8223 + 0x0003 mLDP Tunneling RFC 8223 + 0x0004 LDPv4 Remote LFA RFC 8223 + 0x0005 LDPv6 Remote LFA RFC 8223 + 0x0006 LDP FEC 128 PW RFC 8223 + 0x0007 LDP FEC 129 PW RFC 8223 + 0x0008 LDP Session Protection RFC 8223 + 0x0009 LDP ICCP RFC 8223 + 0x000A LDP P2MP PW RFC 8223 + 0x000B mLDP Node Protection RFC 8223 + 0x000C LDPv4 Intra-area FECs RFC 8223 + 0x000D LDPv6 Intra-area FECs RFC 8223 + 0x000E-0xF7FF Unassigned + 0xF800-0xFBFF Available for Private Use + 0xFC00-0xFFFE Available for Experimental Use + 0xFFFF Reserved RFC 8223 + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., + "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, + October 2007, <https://www.rfc-editor.org/info/rfc5036>. + + [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. + Le Roux, "LDP Capabilities", RFC 5561, + DOI 10.17487/RFC5561, July 2009, + <https://www.rfc-editor.org/info/rfc5561>. + + + + + +Esale, et al. Standards Track [Page 15] + +RFC 8223 Application-Aware tLDP August 2017 + + + [RFC7473] Raza, K. and S. Boutros, "Controlling State Advertisements + of Non-negotiated LDP Applications", RFC 7473, + DOI 10.17487/RFC7473, March 2015, + <https://www.rfc-editor.org/info/rfc7473>. + + [RFC7715] Wijnands, IJ., Ed., Raza, K., Atlas, A., Tantsura, J., and + Q. Zhao, "Multipoint LDP (mLDP) Node Protection", + RFC 7715, DOI 10.17487/RFC7715, January 2016, + <https://www.rfc-editor.org/info/rfc7715>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in + RFC 2119 Key Words", BCP 14, RFC 8174, + DOI 10.17487/RFC8174, May 2017, + <https://www.rfc-editor.org/info/rfc8174>. + +8.2. Informative References + + [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, + "Provisioning, Auto-Discovery, and Signaling in Layer 2 + Virtual Private Networks (L2VPNs)", RFC 6074, + DOI 10.17487/RFC6074, January 2011, + <https://www.rfc-editor.org/info/rfc6074>. + + [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. + Thomas, "Label Distribution Protocol Extensions for + Point-to-Multipoint and Multipoint-to-Multipoint Label + Switched Paths", RFC 6388, DOI 10.17487/RFC6388, + November 2011, <https://www.rfc-editor.org/info/rfc6388>. + + [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. + So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", + RFC 7490, DOI 10.17487/RFC7490, April 2015, + <https://www.rfc-editor.org/info/rfc7490>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + + + + + + + + + + + + + +Esale, et al. Standards Track [Page 16] + +RFC 8223 Application-Aware tLDP August 2017 + + +Acknowledgments + + The authors wish to thank Nischal Sheth, Hassan Hosseini, Kishore + Tiruveedhula, Loa Andersson, Eric Rosen, Yakov Rekhter, Thomas + Beckhaus, Tarek Saad, Lizhong Jin, and Bruno Decraene for their + detailed reviews. Thanks to Manish Gupta and Martin Ehlers for their + input to this work and many helpful suggestions. + +Contributors + + The following people contributed substantially to the content of this + document and should be considered co-authors: + + Chris Bowers + Juniper Networks + 1133 Innovation Way + Sunnyvale, CA 94089 + United States of America + Email: cbowers@juniper.net + + Zhenbin Li + Huawei + Bldg. No. 156 Beiqing Rd. + Beijing 100095 + China + Email: lizhenbin@huawei.com + + + + + + + + + + + + + + + + + + + + + + + + + +Esale, et al. Standards Track [Page 17] + +RFC 8223 Application-Aware tLDP August 2017 + + +Authors' Addresses + + Santosh Esale + Juniper Networks + 1133 Innovation Way + Sunnyvale, CA 94089 + United States of America + + Email: sesale@juniper.net + + + Raveendra Torvi + Juniper Networks + 10 Technology Park Drive + Westford, MA 01886 + United States of America + + Email: rtorvi@juniper.net + + + Luay Jalil + Verizon + 1201 East Arapaho Road + Richardson, TX 75081 + United States of America + + Email: luay.jalil@verizon.com + + + Uma Chunduri + Huawei + 2330 Central Expressway + Santa Clara, CA 95050 + United States of America + + Email: uma.chunduri@huawei.com + + + Kamran Raza + Cisco Systems, Inc. + 2000 Innovation Drive + Ottawa, ON K2K-3E8 + Canada + + Email: skraza@cisco.com + + + + + + +Esale, et al. Standards Track [Page 18] + |