doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc7473.txt b/doc/rfc/rfc7473.txt
new file mode 100644
index 0000000..c372dc2
--- /dev/null
+++ b/doc/rfc/rfc7473.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           K. Raza
+Request for Comments: 7473                                    S. Boutros
+Category: Standards Track                            Cisco Systems, Inc.
+ISSN: 2070-1721                                               March 2015
+
+
+  Controlling State Advertisements of Non-negotiated LDP Applications
+
+Abstract
+
+   There is no capability negotiation done for Label Distribution
+   Protocol (LDP) applications that set up Label Switched Paths (LSPs)
+   for IP prefixes or that signal point-to-point (P2P) Pseudowires (PWs)
+   for Layer 2 Virtual Private Networks (L2VPNs).  When an LDP session
+   comes up, an LDP speaker may unnecessarily advertise its local state
+   for such LDP applications even when the peer session is established
+   for some other applications like Multipoint LDP (mLDP) or the Inter-
+   Chassis Communication Protocol (ICCP).  This document defines a
+   solution by which an LDP speaker announces to its peer its
+   disinterest in such non-negotiated applications, thus disabling the
+   unnecessary advertisement of corresponding application state, which
+   would have otherwise been advertised over the established LDP
+   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 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7473.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raza & Boutros               Standards Track                    [Page 1]
+
+RFC 7473        State Adv. Control of Non-negotiated Apps     March 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 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) 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
+   2. Conventions Used in This Document ...............................4
+   3. Non-negotiated LDP Applications .................................4
+      3.1. Uninteresting State ........................................5
+           3.1.1. Prefix-LSPs .........................................5
+           3.1.2. P2P-PWs .............................................5
+   4. Controlling State Advertisement .................................5
+      4.1. State Advertisement Control Capability .....................6
+      4.2. Capabilities Procedures ....................................8
+           4.2.1. State Control Capability in an
+                  Initialization Message ..............................9
+           4.2.2. State Control Capability in a Capability Message ....9
+   5. Applicability Statement .........................................9
+   6. Operational Examples ...........................................11
+      6.1. Disabling Prefix-LSPs and P2P-PWs on an ICCP Session ......11
+      6.2. Disabling Prefix-LSPs on a L2VPN/PW tLDP Session ..........11
+      6.3. Disabling Prefix-LSPs Dynamically on an
+           Established LDP Session ...................................12
+      6.4. Disabling Prefix-LSPs on an mLDP-only Session .............12
+      6.5. Disabling IPv4 or IPv6 Prefix-LSPs on a Dual-Stack LSR ....12
+   7. Security Considerations ........................................13
+   8. IANA Considerations ............................................13
+   9. References .....................................................14
+      9.1. Normative References ......................................14
+      9.2. Informative References ....................................14
+   Acknowledgments ...................................................15
+   Authors' Addresses ................................................15
+
+
+
+
+
+
+
+Raza & Boutros               Standards Track                    [Page 2]
+
+RFC 7473        State Adv. Control of Non-negotiated Apps     March 2015
+
+
+1.  Introduction
+
+   The LDP Capabilities specification [RFC5561] introduced a mechanism
+   to negotiate LDP capabilities for a given feature between peer Label
+   Switching Routers (LSRs).  The capability mechanism ensures that no
+   unnecessary state is exchanged between peer LSRs unless the
+   corresponding feature capability is successfully negotiated between
+   the peers.
+
+   Newly defined LDP features and applications, such as Typed Wildcard
+   Forwarding Equivalence Class (FEC) [RFC5918], Inter-Chassis
+   Communication Protocol [RFC7275], mLDP [RFC6388], and L2VPN Point-to-
+   multipoint (P2MP) PW [RFC7338] make use of LDP capabilities framework
+   for their feature negotiation.  However, the earlier LDP applications
+   allowed LDP speakers to exchange application state without any
+   capability negotiation.  This, in turn, results in the unnecessary
+   advertisement of state when a given application is not enabled on one
+   of the LDP speakers.  These earlier LDP applications include (i)
+   application to establish LSPs for IP unicast prefixes and (ii)
+   application to signal when L2VPN P2P PW [RFC4447] [RFC4762].  For
+   example, when bringing up and using an LDP peer session with a remote
+   Provider Edge (PE) LSR for purely ICCP-signaling reasons, an LDP
+   speaker may unnecessarily advertise labels for IP (unicast) prefixes
+   to this ICCP-related LDP peer.
+
+   Another example of unnecessary state advertisement can be cited when
+   LDP is to be deployed in an IP dual-stack environment.  For instance,
+   an LSR that is locally enabled to set up LSPs for both IPv4 and IPv6
+   prefixes may advertise (address and label) bindings for both IPv4 and
+   IPv6 address families towards an LDP peer that is interested in IPv4
+   bindings only.  In this case, the advertisement of IPv6 bindings to
+   the peer is unnecessary, as well as wasteful, from the point of view
+   of LSR memory/CPU and network resource consumption.
+
+   To avoid this unnecessary state advertisement and exchange, currently
+   an operator is typically required to configure and define filtering
+   policies on the LSR, which introduces unnecessary operational
+   overhead and complexity for such deployments.
+
+   This document defines a solution based on LDP Capabilities [RFC5561]
+   by which an LDP speaker may announce to its peer(s) its disinterest
+   (or non-support) for state to set up IP Prefix LSPs and/or to signal
+   L2VPN P2P PW at the time of session establishment.  This capability
+   helps in avoiding unnecessary state advertisement for such feature
+   applications.  This document also states the mechanics to dynamically
+
+
+
+
+
+
+Raza & Boutros               Standards Track                    [Page 3]
+
+RFC 7473        State Adv. Control of Non-negotiated Apps     March 2015
+
+
+   disable or enable the state advertisement for such applications
+   during the session lifetime.  The "uninteresting" state of an
+   application depends on the type of application and is described later
+   in Section 3.1.
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+   The term "IP" in this document refers to both IPv4 and IPv6 unicast
+   address families.
+
+3.  Non-negotiated LDP Applications
+
+   For the applications that existed prior to the definition of the LDP
+   Capabilities framework [RFC5561], an LDP speaker typically
+   advertises, without waiting for any capabilities exchange and
+   negotiation, its corresponding application state to its peers after
+   the session establishment.  These early LDP applications include:
+
+      o IPv4/IPv6 Prefix LSPs Setup
+      o L2VPN P2P FEC 128 and FEC 129 PWs Signaling
+
+   The rest of This document uses the following shorthand terms for
+   these earlier LDP applications:
+
+   o  "Prefix-LSPs": Refers to an application that sets up LDP LSPs
+      corresponding to IP routes/prefixes by advertising label bindings
+      for Prefix FEC (as defined in RFC 5036).
+
+   o  "P2P-PWs": Refers to an application that signals FEC 128 and/or
+      FEC 129 L2VPN P2P PWs using LDP (as defined in RFC 4447).
+
+   To disable unnecessary state exchange for such LDP applications over
+   an established LDP session, a new capability is being introduced in
+   this document.  This new capability controls the advertisement of
+   application state and enables an LDP speaker to notify its peer its
+   disinterest in the state of one or more of these "Non-negotiated" LDP
+   applications at the time of session establishment.  Upon receipt of
+   such a capability, the receiving LDP speaker, if supporting the
+   capability, disables the advertisement of the state related to the
+   application towards the sender of the capability.  This new
+   capability can also be sent later in a Capability message either to
+   disable a previously enabled application's state advertisement or to
+   enable a previously disabled application's state advertisement.
+
+
+
+
+Raza & Boutros               Standards Track                    [Page 4]
+
+RFC 7473        State Adv. Control of Non-negotiated Apps     March 2015
+
+
+3.1.  Uninteresting State
+
+   A uninteresting state of a non-negotiated LDP application:
+
+   -  is the application state that is of no interest to an LSR and need
+      not be advertised to the LSR;
+
+   -  need not be advertised in any of the LDP protocol messages;
+
+   -  is dependent on application type and specified accordingly.
+
+3.1.1.  Prefix-LSPs
+
+   For the Prefix-LSP application type, the uninteresting state refers
+   to any state related to IP Prefix FEC (such as FEC label bindings,
+   LDP Status).  This document, however, does not classify IP address
+   bindings (advertised via ADDRESS message) as a uninteresting state
+   and allows the advertisement of IP address bindings.  The reason for
+   this allowance is that an LSR typically uses peer IP address(es) to
+   map an IP routing next hop to an LDP peer in order to implement its
+   control plane procedures.  For example, mLDP [RFC6388] uses a peer's
+   IP address(es) to determine its upstream LSR to reach the Root node
+   as well as to select the forwarding interface towards its downstream
+   LSR.  Hence, in an mLDP-only network, while it is desirable to
+   disable advertisement of label bindings for IP (unicast) prefixes,
+   disabling advertisement of IP address bindings will break mLDP
+   functionality.  Similarly, other LDP applications may also depend on
+   learnt peer IP addresses; hence, this document does not put IP
+   address binding into a uninteresting state category to facilitate
+   such LDP applications.
+
+3.1.2.  P2P-PWs
+
+   For the P2P-PW application type, the uninteresting state refers to
+   any state related to P2P PW FEC 128 / FEC 129 (such as FEC label
+   bindings, Media Access Control (MAC) address withdrawal, and LDP PW
+   Status).  In this document, the term "state" will mean to refer to
+   the "uninteresting state" for an application, as defined in this
+   section.
+
+4.  Controlling State Advertisement
+
+   To control advertisement of uninteresting state related to non-
+   negotiated LDP applications defined in Section 3, a new capability
+   TLV is defined as follows.
+
+
+
+
+
+
+Raza & Boutros               Standards Track                    [Page 5]
+
+RFC 7473        State Adv. Control of Non-negotiated Apps     March 2015
+
+
+4.1.  State Advertisement Control Capability
+
+   The "State Advertisement Control Capability" is a new Capability
+   Parameter TLV defined in accordance with Section 3 of LDP
+   Capabilities specification [RFC5561].  The format of this new TLV is
+   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|  SAC Capability (0x050D)  |           Length              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |S|  Reserved   |                                               |
+   +-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~            State Advertisement Control Element(s)             ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 1: Format of a "State Advertisement Control Capability" TLV
+
+   The value of the U-bit for the TLV MUST be set to 1 so that a
+   receiver MUST silently ignore this TLV if unknown to it, and continue
+   processing the rest of the message.  Whereas, The value of F-bit MUST
+   be set to 0.  Once advertised, this capability cannot be withdrawn;
+   thus, the S-bit MUST be set to 1 in an Initialization and Capability
+   message.
+
+   The capability data associated with this State Advertisement Control
+   (SAC) Capability TLV is one or more State Advertisement Control
+   Elements, where each element indicates enabling/disabling of
+   advertisement of uninteresting state for a given application.  The
+   format of a SAC Element is defined as follows:
+
+                         0 1 2 3 4 5 6 7
+                        +-+-+-+-+-+-+-+-+
+                        |D| App |Unused |
+                        +-+-+-+-+-+-+-+-+
+
+   Figure 2: Format of "State Advertisement Control Element"
+
+   Where:
+   D-bit: Controls the advertisement of the state specified in the "App"
+   field:
+      1: Disable state advertisement
+      0: Enable state advertisement
+          When sent in an Initialization message, the D-bit MUST be set
+          to 1.
+
+
+
+Raza & Boutros               Standards Track                    [Page 6]
+
+RFC 7473        State Adv. Control of Non-negotiated Apps     March 2015
+
+
+   App: Defines the legacy application type whose state advertisement is
+      to be controlled.  The value of this field is defined as follows:
+
+      1: IPv4 Prefix-LSPs (LSPs for IPv4 prefixes)
+      2: IPv6 Prefix-LSPs (LSPs for IPv6 prefixes)
+      3: FEC 128 P2P-PW (L2VPN PWid FEC signaling)
+      4: FEC 129 P2P-PW (L2VPN Generalized PWid FEC signaling)
+
+      Any other value in this field MUST be treated as an error.
+
+   Unused: Must Be Zero (MBZ) on transmit and ignored on receipt.
+
+   The "Length" field of the SAC Capability TLV (in octets) is computed
+   as follows:
+
+      Length (in octets) = 1 + number of SAC elements
+
+   For example, if there are two SAC elements present, then the "Length"
+   field is set to 3 octets.  A receiver of this capability TLV can
+   deduce the number of elements present in the TLV by using the
+   "Length" field.
+
+   This document uses the term "element" to refer to a SAC Element.
+
+   As described earlier, the SAC Capability TLV MAY be included by an
+   LDP speaker in an Initialization message to signal to its peer LSR
+   that state exchange for one or more applications needs to be disabled
+   on the given peer session.  This TLV can also be sent later in a
+   Capability message to selectively enable or disable these
+   applications.  If there is more than one element present in a SAC
+   Capability TLV, the elements MUST belong to distinct app types and
+   the app type MUST NOT appear more than once.  If a receiver receives
+   such a malformed TLV, it SHOULD discard this TLV and continue
+   processing the rest of the message.  If an LSR receives a message
+   with a SAC capability TLV containing an element with the "App" field
+   set to a value other than defined above, the receiver MUST ignore and
+   discard the element and continue processing the rest of the TLV.
+
+   To control more than one application state, a sender LSR can either
+   send a single capability TLV in a message with multiple elements
+   present or send separate messages with a capability TLV specifying
+   one or more elements.  A receiving LSR, however, MUST treat each
+   incoming capability TLV with an element corresponding to a given
+   application type as an update to its existing policy for the given
+   type.
+
+
+
+
+
+
+Raza & Boutros               Standards Track                    [Page 7]
+
+RFC 7473        State Adv. Control of Non-negotiated Apps     March 2015
+
+
+   To understand capability updates from an example, let us consider two
+   LSRs, S (LDP speaker) and P (LDP peer), both of which support all the
+   non-negotiated applications listed earlier.  By default, these LSRs
+   will advertise state for these applications, as configured, to their
+   peer as soon as an LDP session is established.  Now assume that P
+   receives from S a SAC capability in an Initialization message with
+   "IPv6 Prefix-LSPs" and "FEC 129 P2P-PW" applications disabled.  This
+   updates P's outbound policy towards S to advertise state related to
+   only IPv4 Prefix-LSPs and FEC 128 P2P-PW applications.  Later, P
+   receives another capability update from S via a Capability message
+   with "IPv6 Prefix-LSPs" enabled and "FEC 128 P2P-PWs" disabled.  This
+   results in P's outbound policy towards S to advertise both IPv4 and
+   IPv6 Prefix-LSPs application state and disable both FEC 128 and FEC
+   129 P2P-PWs signaling.  Finally, P receives another update from S via
+   a Capability message that specifies to disable all four non-
+   negotiated applications states, resulting in P outbound policy
+   towards S to block/disable state for all these applications and only
+   advertise state for any other application, as applicable.
+
+4.2.  Capabilities Procedures
+
+   The SAC capability conveys the desire of an LSR to disable the
+   receipt of unwanted/unnecessary state from its LDP peer.  This
+   capability is unilateral and unidirectional in nature, and a
+   receiving LSR is not required to send a similar capability TLV in an
+   Initialization or Capability message towards the sender of this
+   capability.  This unilateral behavior conforms to the procedures
+   defined in the Section 6 of LDP Capabilities [RFC5561].
+
+   After this capability is successfully negotiated (i.e., sent by an
+   LSR and received/understood by its peer), then the receiving LSR MUST
+   NOT advertise any state related to the disabled applications towards
+   the capability-sending LSR until and unless these application states
+   are explicitly enabled again via a capability update.  Upon receipt
+   of a capability update to disable an enabled application state during
+   the lifetime of a session, the receiving LSR MUST also withdraw from
+   the peer any previously advertised state corresponding to the
+   disabled application.
+
+   If a receiving LDP speaker does not understand the SAC capability
+   TLV, then it MUST respond to the sender with an "Unsupported TLV"
+   notification as described in "LDP Capabilities" [RFC5561].  If a
+   receiving LDP speaker does not understand or does not support an
+   application specified in an application control element, it SHOULD
+   silently ignore/skip such an element and continue processing rest of
+   the TLV.
+
+
+
+
+
+Raza & Boutros               Standards Track                    [Page 8]
+
+RFC 7473        State Adv. Control of Non-negotiated Apps     March 2015
+
+
+4.2.1.  State Control Capability in an Initialization Message
+
+   The LDP Capabilities framework [RFC5561] dictates that the S-bit of
+   the capability parameter in an Initialization message MUST be set to
+   1 and SHOULD be ignored on receipt.
+
+   An LDP speaker determines (e.g., via some local configuration or
+   default policy) if it needs to disable Prefix-LSPs and/or P2P-PW
+   applications with a peer LSR.  If there is a need to disable, then
+   the SAC TLV needs to be included in the Initialization message with
+   respective SAC elements included with their D-bit set to 1.
+
+   An LDP speaker that supports the SAC capability MUST interpret the
+   capability TLV in a received Initialization message such that it
+   disables the advertisement of the application state towards the
+   capability sending LSR for Prefix-LSPs and/or P2P-PW applications if
+   their SAC element's D-bit is set to 1.
+
+4.2.2.  State Control Capability in a Capability Message
+
+   If the LDP peer supports "Dynamic Announcement Capability" [RFC5561],
+   then an LDP speaker may send a SAC capability in a Capability message
+   towards the peer.  Once advertised, these capabilities cannot be
+   withdrawn; hence, the S-bit of the TLV MUST be set to 1 when sent in
+   a Capability message.
+
+   An LDP speaker may decide to send this TLV towards an LDP peer if one
+   or more of its Prefix-LSPs and/or P2P-PW applications get disabled,
+   or if a previously disabled application gets enabled again.  In this
+   case, the LDP speaker constructs the TLV with appropriate SAC
+   elements and sends the corresponding capability TLV in a Capability
+   message.
+
+   Upon receipt of this TLV in a Capability message, the receiving LDP
+   speaker reacts in the same manner as it reacts upon the receipt of
+   this TLV in an Initialization message.  Additionally, the peer
+   withdraws/advertises the application state to/from the capability-
+   sending LDP speaker according to the capability update.
+
+5.  Applicability Statement
+
+   The procedures defined in this document may result in a disabling
+   announcement of label bindings for IP Prefixes and/or P2P PW FECs
+   and, hence, should be used with caution and discretion.  This
+   document recommends that this new SAC capability and its procedures
+   SHOULD be enabled on an LSR only via a configuration knob.  This knob
+   could either be a global LDP knob or be implemented per LDP neighbor.
+   Hence, it is recommended that an operator SHOULD enable this
+
+
+
+Raza & Boutros               Standards Track                    [Page 9]
+
+RFC 7473        State Adv. Control of Non-negotiated Apps     March 2015
+
+
+   capability and its associated procedures on an LSR towards a neighbor
+   only if it is known that such bindings advertisement and exchange
+   with the neighbor is unnecessary and wasteful.
+
+   The following table summarizes a non-exhaustive list of typical LDP
+   session types on which this new SAC capability and its procedures are
+   expected to be applied to disable advertisement of uninteresting
+   state:
+
+   +===============================+=================================+
+   | Session Type(s)               | Uninteresting State             |
+   +===============================+=================================+
+   | P2P-PW FEC 128-only           | IP Prefix LSPs + P2P-PW FEC 129 |
+   |-------------------------------|---------------------------------|
+   | P2P-PW only (FEC 128/129)     | IP Prefix LSPs                  |
+   |-------------------------------|---------------------------------|
+   | IPv4-only on a Dual-Stack LSR | IPv6 Prefix LSPs + P2P-PW       |
+   |-------------------------------|---------------------------------|
+   | IPv6-only on a Dual-Stack LSR | IPv4 Prefix LSPs + P2P-PW       |
+   |-------------------------------|---------------------------------|
+   | mLDP-only                     | IP Prefix LSPs + P2P-PW         |
+   |-------------------------------|---------------------------------|
+   | ICCP-only                     | IP Prefix LSPs + P2P-PW         |
+   +-------------------------------+---------------------------------+
+
+   It is to be noted that if an application state needs changing after
+   session initialization (e.g., to enable a previously disabled
+   application or to disable a previously enabled application), the
+   procedures defined in this document expect LSR peers to support the
+   LDP "Dynamic Announcement" Capability to announce the change in SAC
+   capability via an LDP Capability message.  However, if any of the
+   peering LSRs do not support this capability, the alternate option is
+   to force reset the LDP session to advertise the new SAC capability
+   accordingly during the following session initialization.
+
+   The following are some additional important points that an operator
+   needs to consider regarding the applicability of this new capability
+   and associated procedures defined in this document:
+
+   -  An operator SHOULD disable Prefix-LSP state on any Targeted LDP
+      (tLDP) session that is established for ICCP-only and/or PW-only
+      purposes.
+
+   -  An operator MUST NOT disable Prefix-LSP state on any tLDP session
+      that is established for reasons related to remote Loop-Free
+      Alternate (LFA) Fast Re-Route (FRR) [RLFA].
+
+
+
+
+
+Raza & Boutros               Standards Track                   [Page 10]
+
+RFC 7473        State Adv. Control of Non-negotiated Apps     March 2015
+
+
+   -  In a remote network that is LFA FRR [RLFA] enabled, it is
+      RECOMMENDED not to disable Prefix-LSP state on a tLDP session even
+      if the current session type is PW-only and/or ICCP-only.  This is
+      recommended because any remote/tLDP neighbor could potentially be
+      picked as a remote LFA PQ node.
+
+   -  This capability SHOULD be enabled for Prefix-LSPs in the scenarios
+      when it is desirable to disable (or enable) advertisement of "all"
+      the prefix label bindings.  For scenarios in which a "subset" of
+      bindings need to be filtered, the existing filtering procedures
+      pertaining to label binding announcement should be used.
+
+   -  Using label advertisement filtering policies in conjunction with
+      the procedures defined in this document for Prefix-LSPs is
+      allowed.  In such cases, the label bindings will be announced as
+      per the label filtering policy for the given neighbor when Prefix-
+      LSP application is enabled.
+
+6.  Operational Examples
+
+6.1.  Disabling Prefix-LSPs and P2P-PWs on an ICCP Session
+
+   Consider two PE routers, LSR1 and LSR2, that understand/support SAC
+   capability TLV and have an established LDP session to exchange ICCP
+   state related to dual-homed devices connected to these LSRs.  Let us
+   assume that both LSRs are provisioned not to exchange any state for
+   Prefix-LSPs (IPv4/IPv6) and P2P-PWs (FEC 128/129) application.
+
+   To indicate their disinterest in these applications, the LSRs will
+   include a SAC capability TLV (with four SAC elements corresponding to
+   these four applications with D-bit set to 1 for each one) in the
+   Initialization message.  Upon receipt of this TLV in Initialization
+   message, the receiving LSR will disable the advertisement of
+   IPv4/IPv6 label bindings, as well as P2P PW FEC 128/129 signaling,
+   towards its peer after session establishment.
+
+6.2.  Disabling Prefix-LSPs on a L2VPN/PW tLDP Session
+
+   Consider LSR1 and LSR2 have an established tLDP session for P2P-PW
+   applications to exchange label bindings for FEC 128/129.  Given that
+   there is no need to exchange IP label bindings amongst the PE LSRs
+   over a PW tLDP session in most typical deployments, let us assume
+   that LSRs are provisioned to disable IPv4/IPv6 Prefix-LSPs
+   application state on the given PW session.
+
+
+
+
+
+
+
+Raza & Boutros               Standards Track                   [Page 11]
+
+RFC 7473        State Adv. Control of Non-negotiated Apps     March 2015
+
+
+   To indicate their disinterest in Prefix-LSP applications over a PW
+   tLDP session, the LSRs will follow/apply the same procedures as
+   described in previous section.  As a result, only P2P-PW-related
+   state will be exchanged between these LSRs over this tLDP session.
+
+6.3.  Disabling Prefix-LSPs Dynamically on an Established LDP Session
+
+   Assume that LSRs from previous sections were initially provisioned to
+   exchange both Prefix-LSP and P2P-PW state over the session between
+   them and also support the "Dynamic Announcement" Capability of
+   [RFC5561].  Now, assume that LSR1 is dynamically provisioned to
+   disable (IPv4/IPv6) Prefix-LSPs over a tLDP session with LSR2.  In
+   this case, LSR1 will send a SAC capability TLV in a Capability
+   message towards LSR2 with application control elements defined for
+   IPv4 and IPv6 Prefix-LSPs with the D-bit set to 1.  Upon receipt of
+   this TLV, LSR2 will disable Prefix-LSPs application state(s) towards
+   LSR1 and withdraw all previously advertised application state from
+   LSR1.  To withdraw label bindings from its peer, LSR2 MAY use a
+   single Prefix FEC Typed Wildcard Label Withdraw message [RFC5918] if
+   the peer supports the Typed Wildcard FEC capability.
+
+   This dynamic disability of Prefix-LSPs application does not impact
+   L2VPN P2P-PW application on the given session, and both LSRs should
+   continue to exchange state related to PW Signaling applications.
+
+6.4.  Disabling Prefix-LSPs on an mLDP-only Session
+
+   Assume that LSR1 and LSR2 have formed an LDP session to exchange mLDP
+   state only.  In typical deployments, LSR1 and LSR2 also exchange
+   bindings for IP (unicast) prefixes upon mLDP session, which is
+   unnecessary and wasteful for an mLDP-only LSR.
+
+   Using the procedures defined earlier, an LSR can indicate its
+   disinterest in Prefix-LSP application state to its peer upon session
+   establishment time or dynamically later via an LDP capabilities
+   update.
+
+   In reference to Section 3.1, the peer disables the advertisement of
+   any state related to IP Prefix FECs, but it still advertises IP
+   address bindings that are required for the correct operation of mLDP.
+
+6.5.  Disabling IPv4 or IPv6 Prefix-LSPs on a Dual-Stack LSR
+
+   In IP dual-stack scenarios, LSR2 may advertise unnecessary state
+   (e.g., IPv6 prefix label bindings) towards peer LSR1 corresponding to
+   IPv6 Prefix-LSP applications once a session is established mainly for
+   exchanging state for IPv4.  The similar scenario also applies when
+
+
+
+
+Raza & Boutros               Standards Track                   [Page 12]
+
+RFC 7473        State Adv. Control of Non-negotiated Apps     March 2015
+
+
+   advertising IPv4 Prefix-LSP state on a session meant for IPv6.  The
+   SAC capability and its procedures defined in this document can help
+   to avoid such unnecessary state advertisement.
+
+   Consider an IP dual-stack environment where LSR2 is enabled for
+   Prefix-LSPs application for both IPv4 and IPv6, but LSR1 is enabled
+   for (or interested in) only IPv4 Prefix-LSPs.  To avoid receiving
+   unwanted state advertisement for IPv6 Prefix-LSP applications from
+   LSR2, LSR1 can send a SAC capability with an element for IPv6 Prefix-
+   LSPs with the D-bit set to 1 in the Initialization message towards
+   LSR2 at the time of session establishment.  Upon receipt of this
+   capability, LSR2 will disable all IPv6 label binding advertisements
+   towards LSR1.  If IPv6 Prefix-LSP applications are later enabled on
+   LSR1, LSR1 can update the capability by sending a SAC capability in a
+   Capability message towards LSR2 to enable this application
+   dynamically.
+
+7.  Security Considerations
+
+   The proposal introduced in this document does not introduce any new
+   security considerations beyond those that already apply to the base
+   LDP specification [RFC5036] and to MPLS and GMPLS [RFC5920].
+
+8.  IANA Considerations
+
+   This document defines a new LDP capability parameter TLV.  IANA has
+   assigned the following value from "TLV Type Name Space" in the "Label
+   Distribution Protocol (LDP) Parameters" registry as the new code
+   point for the new LDP capability TLV code point.
+
+   +--------+---------------------+-----------+-----------------------+
+   | Value  | Description         | Reference |Notes/Registration Date|
+   +--------+---------------------+-----------+-----------------------+
+   | 0x050D | State Advertisement | RFC 7473  |                       |
+   |        | Control Capability  |           |                       |
+   +--------+---------------------+-----------+-----------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raza & Boutros               Standards Track                   [Page 13]
+
+RFC 7473        State Adv. Control of Non-negotiated Apps     March 2015
+
+
+9.  References
+
+9.1  Normative References
+
+   [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>.
+
+   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
+              "LDP Specification", RFC 5036, October 2007,
+              <http://www.rfc-editor.org/info/rfc5036>.
+
+   [RFC5561]  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
+              Le Roux, "LDP Capabilities", RFC 5561, July 2009,
+              <http://www.rfc-editor.org/info/rfc5561>.
+
+9.2.  Informative References
+
+   [RFC4447]  Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
+              G. Heron, "Pseudowire Setup and Maintenance Using the
+              Label Distribution Protocol (LDP)", RFC 4447, April 2006,
+              <http://www.rfc-editor.org/info/rfc4447>.
+
+   [RFC4762]  Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
+              LAN Service (VPLS) Using Label Distribution Protocol (LDP)
+              Signaling", RFC 4762, January 2007,
+              <http://www.rfc-editor.org/info/rfc4762>.
+
+   [RFC5918]  Asati, R., Minei, I., and B. Thomas, "Label Distribution
+              Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
+              (FEC)", RFC 5918, August 2010,
+              <http://www.rfc-editor.org/info/rfc5918>.
+
+   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
+              Networks", RFC 5920, July 2010,
+              <http://www.rfc-editor.org/info/rfc5920>.
+
+   [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, November 2011,
+              <http://www.rfc-editor.org/info/rfc6388>.
+
+   [RFC7275]  Martini, L., Salam, S., Sajassi, A., Bocci, M.,
+              Matsushima, S., and T. Nadeau, "Inter-Chassis
+              Communication Protocol for Layer 2 Virtual Private Network
+              (L2VPN) Provider Edge (PE) Redundancy", RFC 7275, June
+              2014, <http://www.rfc-editor.org/info/rfc7275>.
+
+
+
+Raza & Boutros               Standards Track                   [Page 14]
+
+RFC 7473        State Adv. Control of Non-negotiated Apps     March 2015
+
+
+   [RFC7338]  Jounay, F., Ed., Kamite, Y., Ed., Heron, G., and M. Bocci,
+              "Requirements and Framework for Point-to-Multipoint
+              Pseudowires over MPLS Packet Switched Networks", RFC 7338,
+              September 2014, <http://www.rfc-editor.org/info/rfc7338>.
+
+   [RLFA]     Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
+              So, "Remote Loop-Free Alternate (LFA) Fast Re-Route
+              (FRR)", draft-ietf-rtgwg-remote-lfa-11, Work in Progress,
+              January 2015.
+
+Acknowledgments
+
+   The authors would like to thank Eric Rosen and Alexander Vainshtein
+   for their review and valuable comments.  We also acknowledge Karthik
+   Subramanian and IJsbrand Wijnands for bringing up mLDP use case.
+
+Authors' Addresses
+
+   Kamran Raza
+   Cisco Systems, Inc.
+   2000 Innovation Drive
+   Ottawa, ON K2K-3E8
+   Canada
+   EMail: skraza@cisco.com
+
+   Sami Boutros
+   Cisco Systems, Inc.
+   3750 Cisco Way
+   San Jose, CA 95134
+   United States
+   EMail: sboutros@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raza & Boutros               Standards Track                   [Page 15]
+