doc: Add RFC documents

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]
+