MPLS Working Group                                         Santosh
Internet Engineering Task Force (IETF)                          S. Esale
INTERNET-DRAFT                                           Raveendra
Request for Comments: 8223                                      R. Torvi
Updates: 7473 (if approved)                                           Juniper Networks
Intended Status: Proposed Standard                            Luay
Category: Standards Track                                       L. Jalil
Expires: December 29, 2017
ISSN: 2070-1721                                                  Verizon
                                                            Uma
                                                             U. Chunduri
                                                                  Huawei
                                                             Kamran
                                                                 K. Raza
                                                     Cisco Systems, Inc.
                                                           June 27,
                                                             August 2017

                     Application-aware

                     Application-Aware Targeted LDP
                   draft-ietf-mpls-app-aware-tldp-09

Abstract

   Recent targeted Targeted Label Distribution Protocol (tLDP) applications applications, such
   as remote loop-free alternate (LFA) Loop-Free Alternates (LFAs) and BGP auto discovered
   pseudowire auto-discovered
   pseudowires, may automatically establish a tLDP session to 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 Applications
   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 elements to advertise only necessary LDP FEC- FEC
   label bindings over the session.  This document updates RFC 7473 for
   enabling advertisement of LDP FEC-label FEC label bindings over the session.

Status of this This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum
   (IETF).  It represents the consensus of six months the IETF community.  It has
   received public review and may be updated, replaced, or obsoleted has been approved for publication by other documents at any
   time.  It the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work available in progress."
   The list Section 2 of RFC 7841.

   Information about the current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list status of Internet-Draft Shadow Directories can this document, any errata,
   and how to provide feedback on it may be accessed obtained at
   http://www.ietf.org/shadow.html
   https://www.rfc-editor.org/info/rfc8223.

Copyright and License 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
   (http://trustee.ietf.org/license-info)
   (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

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1 ....................................................3
      1.1. Conventions Used in This Document  . . . . . . . . . . . . .  4
     1.2 ..........................4
      1.2. Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  5 ................................................4
   2. Targeted Application Capability . . . . . . . . . . . . . . . .  5
     2.1 .................................5
      2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2 ...................................................5
      2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.3 .................................................5
      2.3. LDP message procedures . . . . . . . . . . . . . . . . . . .  8
       2.3.1 Message Procedures .....................................8
           2.3.1. Initialization message . . . . . . . . . . . . . . . . .  8
       2.3.2 Message ..............................8
           2.3.2. Capability message . . . . . . . . . . . . . . . . . . .  9 Message ..................................8
   3. Targeted Application FEC Advertisement Procedures . . . . . . .  9 ...............9
   4. Interaction of Targeted Application Capabilities and State
      Advertisement Control Capabilities  . . . . . . . . . . . . . . 10 .............................10
   5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.1 Cases ......................................................12
      5.1. Remote LFA Automatic Targeted session  . . . . . . . . . . . 12
     5.2 Session .....................12
      5.2. FEC 129 Auto Discovery Auto-discovery Targeted session  . . . . . . . . . . 13
     5.3 Session ...................13
      5.3. LDP over RSVP and Remote LFA targeted session  . . . . . . . 13
     5.4 Targeted Session .............13
      5.4. mLDP node protection targeted session  . . . . . . . . . . . 13 Node Protection Targeted Session .....................13
   6. Security Considerations . . . . . . . . . . . . . . . . . . . . 14 ........................................14
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 ............................................14
   8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 15
   9. Contributing Authors  . . . . . . . . . . . . . . . . . . . . . 15
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . 16
     10.1 .....................................................15
      8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     10.2 ......................................15
      8.2. Informative References . . . . . . . . . . . . . . . . . . 16 ....................................16
   Acknowledgments ...................................................17
   Contributors ......................................................17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17

1 ................................................18

1.  Introduction

   LDP uses the extended discovery Extended Discovery mechanism to establish the tLDP
   Targeted LDP (tLDP) adjacency and subsequent session session, as described in
   [RFC5036].  A LSR Label Switching Router (LSR) initiates extended discovery 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. Targeted LDP  A tLDP application is an application that uses a
   tLDP session to exchange information such as
   FEC-Label 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 LFA remote Loop-Free Alternates (LFAs) and
   BGP auto discovered
   pseudowire auto-discovered pseudowires automatically initiate asymmetric extended discovery
   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  So, the remote LSR either responds or ignores to
   all tLDP Hellos. 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
   information available to 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 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, configured
   applications, automatic applications, or both applications. both.

   This document proposes and describes a solution to advertise the
   Targeted Application Capability (TAC), consisting of a list of
   targeted application
   list, applications, during initialization of a tLDP session.  It
   also defines a mechanism to enable an 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
   auto-discovered tLDP sessions as defined described in [RFC6074] but may only
   accept a limited number of Remote remote LFA tLDP sessions as
   defined described
   in [RFC7490] [RFC7490].

   Also, the targeted LDP tLDP application is mapped to LDP FEC element type types to
   advertise specific application FECs only, avoiding the advertisement
   of other unnecessary FECs over a tLDP session.

1.1

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 RFC
   2119
   BCP 14 [RFC2119] and RFC 8174 [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2

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 Capability
      LSR     : Label Switching Router
      mLDP    : Multipoint LDP
      PQ node : Remote-LFA nexthops Remote LFA next hops
      RSVP-TE : RSVP Traffic Engineering
      P2MP    : Point-to-Multipoint
      PW      : Pseudowire
      P2P-PW  : Point-to-point Psuedowire 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 Multipoint-to-Point
      MPT     : Merge Point

2.  Targeted Application Capability

2.1

2.1.  Encoding

   An LSR MAY advertise that it is capable of negotiating a targeted LDP tLDP
   application list over a tLDP session by using the Capability
   Advertisement 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                         |
      |                                               +-+-+-+-+-+-+-+-+
      |                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     This document defines a new optional capability TLV of type TBD1
     called 'Targeted Application Capability (TAC)'.

   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 information, encoded
   as follows:

       Targeted Application Element(TAE)

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Targ. Appl. Id           TA-Id               |E|       Reserved              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Targeted Application Identifier (TA-Id):
       a 16 bit

      TA-Id: A 16-bit Targeted Application Identifier value.

       E-bit: The enable bit indicates

      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

2.2.  Procedures

   At tLDP session establishment time, a 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 TAEs, each pertaining to a unique TA-Id that a 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
   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 the 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 TAE
   common TAE between the TAC TLV it has received and its own, the
   session MUST proceed to establishment as per [RFC5036].  If not, A an
   LSR MUST send a 'Session Rejected/Targeted Application Capability Mis-Match'
   Mismatch' Notification message to the peer and close the session.
   The initiating LSR SHOULD tear down the corresponding tLDP adjacency
   after sent sending or receipt of receiving a 'Session Rejected/Targeted Application
   Capability Mis-Match' Mismatch' Notification message to or from the responding
   LSR
   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 application
   list.
   applications.  For example, an initiating LSR advertises A, B B, and C
   as TA-Ids, and the responding LSR advertises C, D D, and E as TA-Ids. Then
   Then, the negotiated TA-Id as per both the LSRs is C.  Another  In another
   example, an initiating LSR advertises A, B 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 D, and E - -- as TA-Ids that it supports over
   this session. Then
   the  The negotiated targeted applications as per both the LSRs
   are then A, B B, and C.  Finally, If if the initiating LSR advertises A, B
   B, and C as a TA-
   Ids TA-Ids and the responding LSR advertises D and E as
   TA-Ids, then the negotiated targeted applications as per both the LSRs
   are none. "none".  Therefore, if the intersection of the sets of received
   and sent TA-Id TA-Ids is null, then the LSR sends a 'Session
   Rejected/Targeted Application Capability Mis-Match' 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 Mis-Match' Mismatch' Notification message, it MUST set
   its session setup retry interval to a maximum value, as such 0xffff. value -- that is,
   0xFFFF.  The session MAY stay in NON EXISTENT 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 back off backoff
   delay associated with the session to re-attempt the reattempt session establishment. A
   An LSR detects the configuration change on the other LSR with the upon receipt
   of a tLDP Hello message that has a higher configuration sequence
   number than the earlier tLDP Hello message.

   When the initiating LSR playing the active role in LDP session
   establishment receives a 'Session Rejected/Targeted Application
   Capability Mis-Match' Mismatch' Notification message, either it MUST either (1) close
   the session and tear down the corresponding tLDP adjacency or it MUST (2) set
   its session setup retry interval to a maximum value, as such 0xffff. 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 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
   back off backoff delay associated with the session in order to re-attempt the reattempt
   session establishment.

   After a tLDP session using the TAC mechanism has been established with TAC capability, established,
   the initiating and responding LSR LSRs MUST distribute FEC-label FEC label bindings
   for the negotiated applications only.  For instance, if the tLDP
   session is established for a BGP auto discovered auto-discovered pseudowire, only FEC
   129 label bindings MUST be distributed over the session.  Similarly, a
   an LSR operating in downstream on demand on-demand mode MUST request FEC-label FEC label
   bindings for the negotiated applications only.

   If the Targeted Application Capability TAC and the Dynamic Capability,
   described in [RFC5561], Capability [RFC5561] are negotiated during
   session initialization, the TAC MAY be re-negotiated 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 E-bit off (0), to advertise or withdraw the new
   application and the old application application, respectively.  This may lead to
   advertisements or withdrawals of certain types of FEC-Label FEC label bindings
   over the session or tear down to teardown of the tLDP adjacency and
   subsequently and,
   subsequently, the session.

   The Targeted Application Capability TAC is advertised on the tLDP session only.  If the tLDP session
   changes to a link session, a an LSR SHOULD withdraw it with S bit the S-bit
   set to 0.  Similarly, if the link session changes to tLDP, a an LSR
   SHOULD advertise it via the Capability message.  If the capability
   negotiation fails, this may lead to destruction of the tLDP session.

   By default, an LSR SHOULD accept tLDP hellos 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-Id's usage TA-Ids by a network operator.

2.3

2.3.  LDP message procedures

2.3.1 Message Procedures

2.3.1.  Initialization message Message

   1. The S-bit of the Targeted Application Capability TAC TLV MUST be set to 1 to advertise Targeted Application Capability the TAC and
      SHOULD be ignored on the receipt receipt, as defined described in [RFC5561] [RFC5561].

   2. The E-bit of the Targeted Application Element TAE MUST be set to 1 to enable Targeted the targeted
      application and SHOULD be ignored on the receipt.

   3. An LSR MAY add the State Advertisement Control Capability by
      mapping Targeted
     Application Element the TAE to the State Advertisement Control (SAC) Elements elements
      as defined in Section 4.

2.3.2

2.3.2.  Capability message

  The Message

   After a change to local configuration, the initiating or responding
   LSR may re-negotiate renegotiate the TAC after local
  configuration change with 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 if there is no common TAE between
      its new TAE list and peers the peer's TAE list, the LSR MUST send a
      'Session Rejected/Targeted Application Capability Mis-Match' Mismatch'
      Notification message and close the session.

   3. If there is a common TAE, a an LSR MAY also update the SAC
      Capability based on the updated TAC TAC, as described in section 4 Section 4,
      and send the updated TAC and SAC capabilities 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, a the LSR process processes a list of TAEs from
     TACs capability
      the TAC's data with the E-bit set to 1 or 0 to update the
      peer's TAE.

3.  Targeted Application FEC Advertisement Procedures

   The targeted LDP tLDP application MUST be mapped to LDP FEC element types as
   follows to advertise only necessary LDP FEC-Label FEC label bindings over the
   tLDP session.

     Targeted Application     Description              FEC mappings 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             |
   |                      | or other MPLS tunnel      | MP2MP-up         |
   |                      |                        | MP2MP-down       |
   |                      |                        | HSMP-downstream  |
   |                      |                        | HSMP-upstream    |
   +----------------------+------------------------+------------------+
   |                      |                        |                  |
   |LDPv4 Remote remote LFA      | LDPv4 over LDPv4 or    | IPv4 prefix      |
   |                      | other MPLS tunnel      |                  |
   +----------------------+------------------------+------------------+
   |LDPv6 Remote remote LFA      | LDPv6 over LDPv6 or    | IPv6 prefix      |
   |                      | other MPLS tunnel      |                  |
   +----------------------+------------------------+------------------+
   |                      |                        |                  |
   |LDP FEC 128 PW        | LDP FEC 128 Pseudowire | PWid FEC Element element |
   +----------------------+------------------------+------------------+
   |                      |                        |                  |
   |LDP FEC 129 PW        | LDP FEC 129 Pseudowire | Generalized PWid |
   |                      |                        | FEC Element element      |
   +----------------------+------------------------+------------------+
   |                      |                        | FEC types as     |
   |LDP Session Protection| LDP session protection | per protected    |
   |                      |                        | session          |
   +----------------------+------------------------+------------------+
   |LDP ICCP              | LDP Inter-chasis Inter-Chassis      |                  |
   |                      | control protocol Communication Protocol | None             |
   +----------------------+------------------------+------------------+
   |                      |                        |                  |
   |LDP P2MP PW           | LDP P2MP Pseudowire    | P2MP PW Upstream |
   |                      |                        | FEC Element element      |
   +----------------------+------------------------+------------------+
   |                      |                        | P2MP             |
   |mLDP Node Protection  | mLDP node protection   | MP2MP-up         |
   |                      |                        | MP2MP-down       |
   |                      |                        | HSMP-downstream  |
   |                      |                        | HSMP-upstream    |
   +----------------------+------------------------+------------------+
   |                      |                        |                  |
   |IPv4 intra-area FECs FECs* | IPv4 intra-area FECs FECs*  | IPv4 prefix      |
   +----------------------+------------------------+------------------+
   |                      |                        |                  |
   |IPv6 intra-area FECs FECs* | IPv6 intra-area FECs FECs*  | IPv6 prefix      |
   +----------------------+------------------------+------------------+

   * Intra-area FECs : FECs: FECs that are on the shortest path shortest-path tree and
     are not leafs of the shortest path 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], State Advertisement Control(SAC) 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 advertisement 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 FEC label bindings corresponding to negotiated
   applications.  With the SAC, the responding LSR is not aware of
   targeted applications. Thus  Thus, it may be unable to communicate its
   interest or disinterest to receive in receiving state information from the peer.
   Therefore, when the responding LSR is not aware of targeted
   applications such a as remote LFA LFAs and BGP auto discovered auto-discovered pseudowires,
   the TAC mechanism should be used 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  Also, after
   the TAC mechanism makes the responding LSR aware of targeted application,
   applications, the SAC mechanism may be used to communicate its
   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 already-
   negotiated targeted applications.  Collectively, both the TAC mechanism
   and the SAC
   mechanisms mechanism can both be used to control the FEC-label FEC label
   bindings that are advertised over the tLDP session.  For instance,
   suppose that the initiating LSR establishes a tLDP session to session, using the
   TAC mechanism, with the responding LSR for
   Remote remote LFA and FEC 129 PW
   targeted applications with TAC. So applications.  So, each LSR advertises the corresponding FEC-Label FEC
   label bindings.  Further, suppose that the initiating LSR is not the
   PQ node for the responding LSRs Remote 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 remote LFA targeted LDP application. 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 an un-
   negotiated a
   non-negotiated application).  This is true even if one of the peers
   announces its interest in receiving state information that
   corresponds to the un-negotiated 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 advertisement
   advertisements for applications that have not been enabled by TAC. 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 that the
   corresponding application via the TAC mechanism.

   For the purposes of determining the correspondence between targeted
   applications defined in this document and application state as
   defined in [RFC7473] [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 - FEC128 FEC 128 P2P-PW
      LDP FEC 129 PW - FEC129 FEC 129 P2P-PW

   An LSR MUST map Targeted Application the targeted application to the LDP capability
   as follows:

   mLDP Tunneling - P2MP Capability, MP2MP Capability Capability, and HSMP LSP
      Capability TLV

   mLDP node protection Node Protection - P2MP Capability, MP2MP Capability Capability, and HSMP
      LSP Capability TLV

5.  Use cases

5.1 Cases

5.1.  Remote LFA Automatic Targeted session Session

   The LSR determines that it needs to form an automatic tLDP session to
   with a remote LSR based on IGP calculation as described in [RFC7490]
   or some other mechanism, which is mechanism outside the scope of this document.  The LSR
   forms the tLDP adjacency and constructs an Initialization message
   with the TAC TLV with consisting of the TAE as Remote the remote LFA during
   session establishment.  The receiver LSR processes the LDP
   Initialization message and verifies whether it is configured to
   accept a Remote remote LFA tLDP session.  If it is, it may further verify
   that establishing such a session does not exceed the configured limit
   for Remote 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 Remote the remote LFA, and subsequently the session
   may be established.

   After the session using the TAC mechanism has been established with TAC capability, established, the
   sender and receiver LSR 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  So, it may disable the
   receipt of these FEC label bindings by mapping targeted application element the TAE to state control capability the State
   Advertisement Control Capability as described in section Section 4.

5.2

5.2.  FEC 129 Auto Discovery Auto-discovery Targeted session Session

   BGP auto discovery 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 auto-discovered tLDP session with a border LSR.  So, a
   service provider may want to limit the number of auto discovered 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 session sessions from source-list. a source addresses list.

   Moreover, the sender and receiver LSR LSRs must exchange FEC 129 label
   bindings only over the tLDP session.

5.3

5.3.  LDP over RSVP and Remote LFA targeted session

   A Targeted Session

   An LSR may want to establish a tLDP session to with a remote LSR for LDP
   over RSVP
   LDP-over-RSVP tunneling and Remote remote LFA applications.  The sender LSR
   may add both of these applications as a unique Targeted Application Element TAE in the Targeted Application Capability TAC data of
   a TAC TLV.  The receiver LSR may have reached a configured limit for
   accepting Remote remote LFA automatic tLDP sessions, but it may have been
   configured to accept LDP over RSVP LDP-over-RSVP tunneling.  In such a case, the
   tLDP session is formed for both LDP over RSVP LDP-over-RSVP tunneling and Remote remote
   LFA applications applications, as both need the same FECs - IPv4 or IPv6 -- IPv4, IPv6, or both.

5.4

5.4.  mLDP node protection targeted session Node Protection Targeted Session

   A merge point Merge Point (MPT) LSR may determine that it needs to form an
   automatic tLDP session to with the upstream point of local repair (PLR)
   LSR for MP2P and MP2MP LSP [RFC6388] node protection as described in the
   [RFC7715].  The MPT LSR may add a new targeted LDP tLDP application - -- mLDP
   protection
   - -- as a unique TAE in the Targeted Application Capability Data 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 Initialization message with a
   TAC TLV that has one of the TAEs as - mLDP protection, and the session
   proceeds to establishment as per [RFC5036].

6.  Security Considerations

   The Capability procedure procedures described in this document does do not introduce any change
   changes to LDP Security Considerations section 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
   Section 5.2 of this document, a an LSR can employ a policy to accept
   all auto-
   discovered auto-discovered Extended Hellos from the configured source
   addresses list.

   Also

   Also, for the two LSRs supporting the TAC, the tLDP session is only
   established after successful negotiation of the TAC.  The initiating
   and receiving LSR LSRs MUST only advertise TA-Ids that they support. In support --
   in other words, what they are configured for over the tLDP session.

7.  IANA Considerations

   This document requires

   IANA has assigned the assignment of a new following code point for a the new Capability
   Parameter TLVs TLV defined in this document.  The code point has been
   assigned from the IANA managed LDP registry "TLV Type Name Space", corresponding to the advertisement Space" sub-registry of the Targeted
   Applications capability. IANA is requested to assign the lowest
   available value after 0x050B. "Label
   Distribution Protocol (LDP) Parameters" registry.

      Value   Description                      Reference
      -----  --------------------------------
      ------  -------------------------------  ---------
      TBD1
      0x050F  Targeted Applications capability  [this document]

   This document requires the assignment of Application Capability  RFC 8223

   IANA has assigned a new code point for a status code from the IANA managed registry "STATUS CODE NAME SPACE"
   on "Status Code Name Space"
   sub-registry of the Label "Label Distribution Protocol (LDP) Parameters page,
   corresponding to the notification of session Rejected/Targeted
   Application Capability Mis-Match. IANA is requested to assign the
   lowest available value after 0x0000004B. Parameters"
   registry.

      Value        E   Description                           Reference
      ----- - --------------------------------
      ----------  ---  -----------------------------------   ---------
      TBD2
      0x0000004C   1   Session Rejected/Targeted
                          Application Capability Mis-Match  [this document]

   This document also creates Mismatch    RFC 8223
   IANA has created a new name space 'the LDP registry called "LDP Targeted Application Identifier' on
   Identifier" in the Label "Label Distribution Protocol (LDP)
   Parameters page, that is to be managed by IANA. Parameters"
   registry.  The range is 0x0001-
   0xFFFE, with 0x0001-0xFFFE.  Values in the following values requested range
   0x0001-0x1FFF in this document. 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                   [this document]                         RFC 8223
      0x0001           LDPv4 Tunneling            [this document]                  RFC 8223
      0x0002           LDPv6 Tunneling            [this document]                  RFC 8223
      0x0003           mLDP Tunneling             [this document]                   RFC 8223
      0x0004           LDPv4 Remote LFA           [this document]                 RFC 8223
      0x0005           LDPv6 Remote LFA           [this document]                 RFC 8223
      0x0006           LDP FEC 128 PW             [this document]                   RFC 8223
      0x0007           LDP FEC 129 PW             [this document]                   RFC 8223
      0x0008           LDP Session Protection     [this document]           RFC 8223
      0x0009           LDP ICCP                   [this document]                         RFC 8223
      0x000A           LDP P2MP PW                [this document]                      RFC 8223
      0x000B           mLDP Node Protection       [this document]             RFC 8223
      0x000C           LDPv4 Intra-area FECs      [this document]            RFC 8223
      0x000D           LDPv6 Intra-area FECs      [this document]
      0x0001 - 0x1FFF  Available for assignment
                       by IETF Review
      0x2000 - 0F7FF   Available for assignment
                       as first come first served
      0xF800 - 0xFBFF            RFC 8223
      0x000E-0xF7FF    Unassigned
      0xF800-0xFBFF    Available for private use
      0xFC00 - 0xFFFE Private Use
      0xFC00-0xFFFE    Available for experimental use Experimental Use
      0xFFFF           Reserved                   [this document]                         RFC 8223

8. Acknowledgments

   The authors wish to thank Nischal Sheth, Hassan Hosseini, Kishore
   Tiruveedhul, Loa Andersson, Eric Rosen, Yakov Rekhter, Thomas
   Beckhaus, Tarek Saad, Lizhong Jin and Bruno Decraene for doing the
   detailed review. Thanks to Manish Gupta and Martin Ehlers for their
   input to this work and many helpful suggestions.

9. Contributing Authors

   Chris Bowers
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, CA  94089
   USA
   EMail: cbowers@juniper.net

   Zhenbin Li
   Huawei
   Bld No.156 Beiqing Rd
   Beijing  100095
   China
   Email: lizhenbin@huawei.com

10.  References

10.1

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,
              <http://www.rfc-editor.org/info/rfc5036>. <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,
              <http://www.rfc-editor.org/info/rfc5561>.
              <https://www.rfc-editor.org/info/rfc5561>.

   [RFC7473] Kamran  Raza, Sami K. and S. Boutros, "Controlling State Advertisements
              of Non-negotiated LDP Applications", RFC 7473,
              DOI 10.17487/RFC7473, March 2015, <http://www.rfc-
              editor.org/info/rfc7473>.
              <https://www.rfc-editor.org/info/rfc7473>.

   [RFC7715] IJ.  Wijnands, E. Rosen, K. IJ., Ed., Raza, J. Tantsura, A. K., Atlas, A., Tantsura, J., and
              Q. Zhao, "mLDP "Multipoint LDP (mLDP) Node Protection",
              RFC 7715, DOI 10.17487/RFC7715, January 2016,
              <http://www.rfc-editor.org/info/rfc7715>.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.
              <https://www.rfc-editor.org/info/rfc7715>.

   [RFC8174] B.  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
              RFC 2119 Key Words", BCP 14, RFC8174, RFC 8174,
              DOI 10.17487/RFC8174, May 2017, <http://www.rfc-
              editor.org/info/rfc8174>.

10.2
              <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [RFC7490] S. Bryant, C. Filsfils, S. Previdi, M. Shand, N. So,
              "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
              April 2015.

   [RFC6074] E.  Rosen, B. E., Davie, V. 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. 2011,
              <https://www.rfc-editor.org/info/rfc6074>.

   [RFC6388] IJ.  Wijnands, I. IJ., Ed., Minei, K. 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.

8. 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>.

Acknowledgments

   The authors wish to thank Nischal Sheth, Hassan Hosseini, Kishore
   Tiruveedhul,
   Tiruveedhula, Loa Andersson, Eric Rosen, Yakov Rekhter, Thomas
   Beckhaus, Tarek Saad, Lizhong Jin Jin, and Bruno Decraene for doing the their
   detailed review. reviews.  Thanks to Manish Gupta and Martin Ehlers for their
   input to this work and many helpful suggestions.

9. Contributing Authors

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
   USA
   EMail:
   United States of America
   Email: cbowers@juniper.net

   Zhenbin Li
   Huawei
   Bld No.156
   Bldg. No. 156 Beiqing Rd Rd.
   Beijing  100095
   China
   Email: lizhenbin@huawei.com

Authors' Addresses

   Santosh Esale
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, CA  94089
              USA
              EMail:
   United States of America

   Email: sesale@juniper.net

   Raveendra Torvi
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
              USA
              EMail:
   United States of America

   Email: rtorvi@juniper.net

   Luay Jalil
   Verizon
   1201 E East Arapaho Rd Road
   Richardson, TX  75081
              USA
   United States of America

   Email: luay.jalil@verizon.com

   Uma Chunduri
   Huawei
   2330 Central Expy Expressway
   Santa Clara, CA  95050
              USA
   United States of America

   Email: uma.chunduri@huawei.com

   Kamran Raza
   Cisco Systems, Inc.
   2000 Innovation Drive
   Ottawa, ON  K2K-3E8
   Canada
              E-mail:

   Email: skraza@cisco.com