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

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/