draft-ietf-mpls-ldp-ip-pw-capability-06.txt   draft-ietf-mpls-ldp-ip-pw-capability-07.txt 
MPLS Working Group Kamran Raza MPLS Working Group Kamran Raza
Internet Draft Sami Boutros Internet Draft Sami Boutros
Intended status: Standards Track Intended status: Standards Track
Expires: December 19, 2013 Cisco Systems Expires: October 26, 2014 Cisco Systems
June 20, 2013 April 27, 2014
Disabling IPoMPLS and P2P PW LDP Application's State Advertisement Controlling State Advertisements Of Non-negotiated LDP Applications
draft-ietf-mpls-ldp-ip-pw-capability-06.txt draft-ietf-mpls-ldp-ip-pw-capability-07.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 19, 2013. This Internet-Draft will expire on October 26, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with
to this document. Code Components extracted from this document must respect to this document. Code Components extracted from this
include Simplified BSD License text as described in Section 4.e of document must include Simplified BSD License text as described in
the Trust Legal Provisions and are provided without warranty as Section 4.e of the Trust Legal Provisions and are provided without
described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
Currently, no LDP capability is exchanged for LDP applications like There is no capability negotiation done for Label Distribution
IP Label Switching and L2VPN P2P PW signaling. When an LDP session Protocol (LDP) applications that setup Label Switched Paths (LSPs)
comes up, an LDP speaker may unnecessarily advertise its local state for IP prefixes or that signal Point-to-point (P2P) Pseudowires
for such LDP applications even when the peer session is established (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP
for some other applications like mLDP or ICCP. This document defines session comes up, an LDP speaker may unnecessarily advertise its
a solution by which an LDP speaker announces to its peer its local state for such LDP applications even when the peer session is
disinterest in such non-negotiated applications. This, in turn, established for some other applications like Multipoint LDP (mLDP)
disables the advertisement of corresponding application state, which or Inter-Chassis Communication Protocol (ICCP). This document
would have otherwise be advertised by default, over the established defines a solution by which an LDP speaker announces to its peer its
LDP session. disinterest in such 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 5 3.1. Non-interesting State 5
4. Controlling State Advertisement for Non-negotiated LDP Apps 5 4. Controlling State Advertisement 5
4.1 State Advertisement Control Capabilty 5 4.1. State Advertisement Control Capability 5
5.Capabilities Procedures 8 4.2. Capabilities Procedures 8
5.1 State Control Capability in an Initization message 8 4.2.1. State Control Capability in an Initialization message 9
5.2 State Control Capability in a Capabilty message 9 4.2.2. State Control capability in a Capability message 9
6. Operational Examples 9 5. Operational Examples 9
6.1 Disabling IPoMPLS and P2P PW applications on an ICCP session 9 5.1. Disabling Prefix-LSPs and P2P-PWs apps on an ICCP session 9
6.2 Disabling IPoMPLS application on a L2VPN/PW T-LDP session 10 5.2. Disabling Prefix-LSPs app on a PW Targeted LDP session 10
6.3 Disabling IPoMPLS app. dynamically on an IP/PW LDP session 10 5.3. Disabling Prefix-LSPs app dynamically on an LDP session 10
6.4 Disabling IPoMPLS application on an mLDP-only session 10 5.4. Disabling Prefix-LSPs app on an mLDP-only session 11
6.5 Disabling unwanted IP state advert. by an IP dual-stack LSR 11 5.5. Disabling IPv4 or IPv6 Prefix-LSPs app on an dual-stack LSR 11
7. Security Considerations 11 6. Security Considerations 11
8. IANA Considerations 11 7. IANA Considerations 12
9. References 12 8. References 12
9.1 Normative References 12 8.1. Normative References 12
9.2 Informative References 12 8.2. Informative References 12
10. Acknowledgments 12 9. Acknowledgments 13
1. Introduction 1. Introduction
LDP Capabilities [RFC5561] introduced a mechanism to negotiate LDP LDP Capabilities specification [RFC5561] introduced a mechanism to
capabilities for a given feature between peer LSRs. The capability negotiate LDP capabilities for a given feature between peer Label
mechanism insures that no unnecessary state is exchanged between peer Switching Routers (LSRs). The capability mechanism insures that no
LSRs unless the corresponding feature capability is successfully unnecessary state is exchanged between peer LSRs unless the
negotiated between the peers. corresponding feature capability is successfully negotiated between
the peers.
While new LDP features and applications, such as Typed Wildcard FEC Newly defined LDP features and applications, such as Typed Wildcard
[RFC5918], Inter-Chassis Communication Protocol [ICCP], mLDP Forwarding Equivalence Class (FEC) [RFC5918], Inter-Chassis
[RFC6388], and L2VPN P2MP PW [P2MP-PW] make use of LDP capabilities Communication Protocol [ICCP], mLDP [RFC6388], and L2VPN Point-to-
framework for their feature negotiation, the earlier LDP features and multipoint (P2MP) PW [P2MP-PW] make use of LDP capabilities framework
applications like IP Label Switching and L2VPN P2P PW signaling for their feature negotiation. However, the earlier LDP application
[RFC4447] [RFC4762] may cause LDP speakers to exchange application to establish LSPs for IP unicast prefixes, and application to signal
state unnecessarily even when the given application is not enabled on L2VPN P2P PW [RFC4447] [RFC4762] allowed LDP speakers to exchange
one of the LDP speakers participating in a given session. For application state without any capability negotiation, thus causing
example, when bringing up and using an LDP peer session with a remote unnecessary state advertisement when a given application is not
PE LSR for purely ICCP signaling reasons, an LDP speaker may enabled on one of the LDP speakers participating in a given session.
unnecessarily advertise labels for IP (unicast) prefixes to this ICCP For example, when bringing up and using an LDP peer session with a
related LDP peer. 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 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 for both IPv4 and IPv6 label switching an LSR that is locally enabled to setup LSPs for both IPv4 and IPv6
may advertise label bindings for both IPv4 and IPv6 address families prefixes may advertise (address and label) bindings for both IPv4 and
towards an LDP peer that is interested in IPv4 prefix labels only. In IPv6 address families towards an LDP peer that is interested in IPv4
this case, the advertisement of IPv6 prefix labels to the peer is bindings only. In this case, the advertisement of IPv6 bindings to
unnecessary, as well as wasteful, from the point of view of LSR the peer is unnecessary, as well as wasteful, from the point of view
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 some sort an operator is typically required to configure and define filtering
of filtering policies on the LSR, which introduces operational policies on the LSR, which introduces unnecessary operational
overhead and complexity for such deployments. overhead and complexity for such deployments.
This document defines an LDP Capabilities [RFC5561] based solution by This document defines an LDP Capabilities [RFC5561] based solution by
which an LDP speaker may announce to its peer(s) its disinterest (or which an LDP speaker may announce to its peer(s) its disinterest (or
non-support) for state related to IP Label Switching and/or L2VPN P2P non-support) for state to setup IP Prefix LSPs and/or to signal L2VPN
PW Signaling application at the time of session establishment. This P2P PW at the time of session establishment. This capability helps in
helps in avoiding unnecessary state advertisement for such feature avoiding unnecessary state advertisement for such feature
applications. The 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 disable or enable the state advertisement for such applications
during the session lifetime. The non-interesting state of an during the session lifetime. The non-interesting state of an
application depends on the type of application and is described later application depends on the type of application and is described later
in section 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.
This document uses shorthand terms "IPoMPLS" to refer to IP Label
Switching application, and "P2P PW" to refer to L2VPN PW signaling
for FEC 128 and FEC 129 P2P Pseudowires.
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 LDP
Capabilities framework [RFC5561], an LDP speaker typically Capabilities framework [RFC5561], an LDP speaker typically
advertises, without waiting for any capabilities exchange and advertises, without waiting for any capabilities exchange and
negotiation, its corresponding application state to its peers right negotiation, its corresponding application state to its peers after
after the session establishment. These early LDP applications the session establishment. These early LDP applications include:
include:
o IPv4/IPv6 Label Switching ("IPoMPLS") o IPv4/IPv6 Prefix LSPs Setup
o L2VPN P2P PW signaling ("P2P PW") o L2VPN P2P FEC128 and FEC129 PWs signaling
To disable unnecessary state advertisement for such LDP applications This document onward uses following shorthand terms for these
over an established LDP session, a new capability is introduced in 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 Pseudowires 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 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" disinterest in the state of one or more of these "Non-negotiated"
LDP applications at the time of session establishment. Upon receipt LDP applications at the time of session establishment. Upon receipt
of such capability, the receiving LDP speaker, if supporting the of such 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. This new capability can also be sent application towards the sender of the capability. This new
later in a Capability message to either disable a previously enabled capability can also be sent later in a Capability message to either
application's state advertisement or to enable a previously disabled disable a previously enabled application's state advertisement or to
application's state advertisement. enable a previously disabled application's state advertisement.
3.1. Non-interesting State 3.1. Non-interesting State
So far, this document has used the term application "state" to A non-interesting state of a non-negotiated LDP application:
generically refer to some non-interesting state. Now, let us further
specify and clarify this term:
. A non-interesting state of a non-negotiated application refers - is the application state which is of a no interest to an LSR
to the application state which is of a no interest to an LSR
and need not be advertised to the LSR; and need not be advertised to the LSR;
. This state MUST NOT be advertised in any of the LDP protocol - need not be advertised in any of the LDP protocol messages;
messages; - is dependent on application type and specified accordingly.
. This state is dependent on application type and specified
accordingly.
For IPoMPLS application type, the non-interesting state refers to For Prefix-LSPs application type, the non-interesting state refers
any state related to IP Prefix FEC (such as label bindings, LDP to any state related to IP Prefix FEC (such as FEC label bindings,
Status). This document, however, does not classify IP address LDP Status). This document, however, does not classify IP address
bindings as a non-interesting state and allows the advertisement of bindings as a non-interesting state and allows the advertisement of
IP Address bindings to facilitate other LDP applications (such as IP Address bindings to facilitate other LDP applications (such as
mLDP) that depend on learning of peer addresses over an LDP session mLDP) that depend on learning of peer addresses over an LDP session
for their correct operation. for their correct operation.
For P2P PW application type, the non-interesting state refers to any For P2P-PWs application type, the non-interesting state refers to
state related to P2P PW FEC (such as label bindings, MAC [address] any state related to P2P PW FEC128/FEC129 (such as FEC label
withdrawal, and LDP PW Status). bindings, MAC [address] withdrawal, and LDP PW Status).
From now onward in this document, the term "state" will mean to From now onward in this document, the term "state" will mean to
refer to the "non-interesting state" for an application, as defined refer to the "non-interesting state" for an application, as defined
in this section. in this section.
4. Controlling State Advertisement for Non-negotiated LDP Applications 4. Controlling State Advertisement
To control advertisement of non-interesting state related to non- To control advertisement of non-interesting state related to non-
negotiated LDP applications, namely IPoMPLS and P2P PW signaling, a negotiated LDP applications defined in section 3, a new capability
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
skipping to change at page 6, line 23 skipping to change at page 6, line 23
~ State Advertisement Control Element(s) ~ ~ State Advertisement Control Element(s) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of an "State Advertisement Control Capability" TLV Figure 1: Format of an "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 receiver MUST silently ignore this TLV if unknown to it, and
continue processing the rest of the message. Whereas, The value of continue processing the rest of the message. Whereas, The value of
F-bit MUST be set to 0. Once advertised, this capability cannot be F-bit MUST be set to 0. Once advertised, this capability cannot be
withdrawn; thus S-bit MUST be set to 1 both in an Initialization and withdrawn; thus S-bit MUST be set to 1 in an Initialization and
Capability message. Capability 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
(SAC) 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 non-interesting 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 0 1 2 3 4 5 6 7
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D| App |Unused |
| State |D|Rsvd1| Rsvd2 | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of an "State Advertisement Control Element" Figure 2: Format of "State Advertisement Control Element"
Where: Where:
State: Defines the type of application state (to be controlled). D bit: Controls the advertisement of the state specified in "App"
The value of this field is defined as follows: field:
1: IPv4 Label switching
2: IPv6 Label switching
3: P2P PW FEC128 signaling
4: P2P PW FEC129 signaling
0, 5-15: Reserved.
D bit: Controls the advertisement of the state:
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 to 1. When sent in an Initialization message, D bit MUST be set to 1.
Rsvd1, Rsvd2: Reserved for future use. MBZ on transmit and ignored App: Defines the application type whose state advertisement is to be
on receipt. 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: FEC128 P2P-PW (L2VPN PWid FEC signaling)
4: FEC129 P2P-PW (L2VPN Generalized PWid FEC signaling)
Any other value in this field MUST be treated as an error.
Unused: MBZ on transmit and ignored on receipt.
The "Length" field of SAC Capability TLV depends on the number of The "Length" field of SAC Capability TLV depends on the number of
SAC Elements present in the TLV. For example, if there are two SAC Elements present in the TLV. For example, if there are two
elements present, then the Length field is set to 5 octets. A elements present, then the Length field is set to 3 octets. A
receiver of this capability TLV can deduce number of elements receiver of this capability TLV can deduce number of elements
present in the TLV by using the Length field. present in the TLV by using the Length field.
From now onward, this document uses the term "element" to refer to a From now onward, this document uses the term "element" to refer to a
SAC Element. SAC Element.
As described earlier, SAC Capability TLV MAY be included by an LDP As described earlier, SAC Capability TLV MAY be included by an LDP
speaker in an Initialization message to signal to its peer LSR that speaker in an Initialization message to signal to its peer LSR that
state advertisement for one or more application(s) need to be state exchange for one or more application(s) need to be disabled on
disabled on the given peer session. This TLV can also be sent later the given peer session. This TLV can also be sent later in a
in a Capability message to selectively enable or disable these Capability message to selectively enable or disable these
applications. A SAC Capability TLV MUST contain elements with applications. If there are more than one elements present in a SAC
distinct state types and the TLV MUST NOT contain the same state Capability TLV, the elements MUST belong to distinct app types and
type more than once. If a receiver receives such a malformed TLV, it an app type MUST NOT appear more than once. If a receiver
SHOULD discard this TLV and continue processing rest of the message. receives such a malformed TLV, it SHOULD discard this TLV and
continue processing rest of the message. If an LSR receives a
message with a SAC capability TLV containing an element with "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 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 present, or can send separate messages with capability TLV
specifying one or more elements. A receiving LSR, however, MUST specifying one or more elements. A receiving LSR, however, MUST
treat each incoming capability TLV for a given application state treat each incoming capability TLV with an element corresponding to
type as an update to its existing policy for the given type. a given application type as an update to its existing policy for the
given type.
To understand capability updates from an example, let us consider 2 To understand capability updates from an example, let us consider 2
LSRs, S (LDP speaker) and P (LDP peer), both of which support all LSRs, S (LDP speaker) and P (LDP peer), both of which support all
the non-negotiated applications listed earlier. By default, these the non-negotiated applications listed earlier. By default, these
LSR will advertise state for these applications, as configured, to LSR will advertise state for these applications, as configured, to
their peer as soon as an LDP session is established. Now assume that their peer as soon as an LDP session is established. Now assume that
P receives from S a SAC capability in the Initialization message P receives from S a SAC capability in an Initialization message with
with "IPv6 Label switching" and "P2P PW FEC129" states disabled. "IPv6 Prefix-LSPs" and "FEC129 P2P-PW" applications disabled. This
This updates P's outbound policy towards S to advertise state updates P's outbound policy towards S to advertise state related to
related to only "IPv4 Label switching" and "P2P PW FEC 128" only IPv4 Prefix-LSPs and FEC128 P2P-PW applications. Later, P
applications. Later, P receives another capability update from S receives another capability update from S via a Capability message
via a Capability message with "IPv6 Label switching" enabled and with "IPv6 Prefix-LSPs" enabled and "FEC128 P2P-PWs" disabled. This
"P2P PW FEC128" disabled. This results in P's outbound policy results in P's outbound policy towards S to advertise both IPv4 and
towards S to advertise both IPv4 and IPv6 Label switching state, and IPv6 Prefix-LSPs application state, and disable both FEC128 and
disable both P2P PW FEC128 and FEC 129 signaling. Finally, P FEC129 P2P-PWs signaling. Finally, P receives another update from S
receives another update from S via a Capability message that via a Capability message that specifies to disable all four non-
specifies to disable all four non-negotiated applications state, negotiated applications state, resulting in P outbound policy
resulting in P outbound policy towards S to block/disable state for towards S to block/disable state for all these applications, and
all these applications, and only advertise state for any other only advertise state for any other application, as applicable.
application, as applicable.
5. 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 uni-lateral and uni-directional 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 After this capability is successfully negotiated (i.e. sent by an
LSR and received/understood by its peer), then the receiving LSR LSR and received/understood by its peer), then the receiving LSR
MUST NOT advertise any state related to the disabled applications MUST NOT advertise any state related to the disabled applications
towards the capability sending LSR until and unless these towards the capability sending LSR until and unless these
application states are explicitly enabled again via a capability application states are explicitly enabled again via a capability
update. Upon receipt of a capability update to disable an enabled update. Upon receipt of a capability update to disable an enabled
application [state] during the lifetime of a session, the receiving application [state] during the lifetime of a session, the receiving
LSR MUST also withdraw from the peer any previously advertised state LSR MUST also withdraw from the peer any previously advertised state
(corresponding to the disabled application). corresponding to the 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 "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.
5.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 LDP Capabilities [RFC5561] framework dictates that the S-bit of
capability parameter in an Initialization message MUST be set to 1 capability parameter in an Initialization message MUST be set to 1
and SHOULD be ignored on receipt. 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 IPoMPLS and/or P2P PW default policy) if it needs to disable Prefix-LSPs and/or P2P-PWs
applications with a peer LSR. If there is a need to disable, then 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 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 IPoMPLS and/or P2P PW applications if capability sending LSR for Prefix-LSPs and/or P2P-PWs applications
their SAC element's D bit is set to 1. if their SAC element's D bit is set to 1.
5.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" If the LDP peer supports "Dynamic Announcement Capability"
[RFC5561], then an LDP speaker may send SAC capability in a [RFC5561], then an LDP speaker may send SAC capability in a
Capability message towards the peer. Once advertised, these Capability message towards the peer. Once advertised, these
capabilities cannot be withdrawn and hence the S-bit of the TLV MUST capabilities cannot be withdrawn and hence the S-bit of the TLV MUST
be set to 1 when sent in a Capability message. be set to 1 when sent in a Capability message.
An LDP speaker may decide to send this TLV towards an LDP peer if An LDP speaker may decide to send this TLV towards an LDP peer if
one or more of its IPoMPLS and/or P2P PW signaling applications get one or more of its Prefix-LSPs and/or P2P-PWs applications get
disabled, or if previously disabled application gets enabled again. disabled, or if previously disabled application gets enabled again.
In this case, the LDP speaker constructs the TLV with appropriate In this case, the LDP speaker constructs the TLV with appropriate
SAC element(s) and sends the corresponding capability TLV in a SAC element(s) and sends the corresponding capability TLV in a
Capability message. Capability 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 from/to the capability
sending LDP speaker according to the capability update. sending LDP speaker according to the capability update.
6. Operational Examples 5. Operational Examples
6.1. Disabling IPoMPLS and P2P PW applications on an ICCP session 5.1. Disabling Prefix-LSPs and P2P-PWs applications on an ICCP session
Consider two PE routers, LSR1 and LSR2, which understand/support SAC Consider two PE routers, LSR1 and LSR2, which 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
IPoMPLS (IPv4/IPv6) and P2P PW (FEC128/129) application. Prefix-LSPs (IPv4/IPv6) and P2P-PWs (FEC128/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 4 SAC elements corresponding to
these 4 applications with D bit set to 1 for each one) in the these 4 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 FEC128/129 signaling,
towards its peer after session establishment. towards its peer after session establishment.
6.2. Disabling IPoMPLS application on a L2VPN/PW T-LDP session 5.2. Disabling Prefix-LSPs application on a PW Targeted LDP session
Now, consider LSR1 and LSR2 have an established T-LDP session for Now, consider LSR1 and LSR2 have an established Targeted LDP (T-LDP)
P2P PW application to exchange label bindings for FEC 128/129. Given session for P2P-PWs application to exchange label bindings for
that there is no need to exchange IP (v4/v6) label bindings between FEC 128/129. Given that there is no need to exchange IP Prefix label
the PE LSRs over a PW T-LDP session in most typical deployments, let bindings amongst the PE LSRs over a PW T-LDP session in most typical
us assume that LSRs are provisioned to disable IPoMPLS (IPv4/IPv6) deployments, let us assume that LSRs are provisioned to disable
application state on given PW session. IPv4/IPv6 Prefix-LSPs application state on the given PW session.
To indicate their disinterest in IPoMPLS application over a PW T-LDP To indicate their disinterest in Prefix-LSPs application over a PW
session, the LSRs will follow/apply the same procedures to disable T-LDP session, the LSRs will follow/apply the same procedures as
IPv4 and IPv6 label switching as described in previous section. As a described in previous section. As a result, only P2P-PWs related
result, only P2P PW related state will be exchanged between these state will be exchanged between these LSRs over this T-LDP session.
LSRs over this T-LDP session.
6.3. Disabling IPoMPLS application dynamically on an established IP/PW 5.3. Disabling Prefix-LSPs application dynamically on an established
LDP session LDP session
Assume that LSRs from previous sections were initially provisioned Assume that LSRs from previous sections were initially provisioned
to exchange both IPoMPLS and P2P PW state over the session between to exchange both Prefix-LSPs and P2P-PWs state over the session
them, and also support "Dynamic Announcement" Capability [RFC5561]. between them, and also support "Dynamic Announcement" Capability
Now, assume that LSR1 is dynamically provisioned to disable IPoMPLS [RFC5561]. Now, assume that LSR1 is dynamically provisioned to
(IPv4/IPv6) over T-LDP session with LSR2. In this case, LSR1 will disable (IPv4/IPv6) Prefix-LSPs over T-LDP session with LSR2. In
send SAC capability TLV in a Capability message towards LSR2 with this case, LSR1 will send SAC capability TLV in a Capability message
application control elements defined for IPv4 and IPv6 label towards LSR2 with application control elements defined for IPv4 and
switching with D bit set to 1. Upon receipt of this TLV, LSR2 will IPv6 Prefix-LSPs with D bit set to 1. Upon receipt of this TLV, LSR2
disable IPoMPLS application state(s) towards LSR1 and withdraw all will disable Prefix-LSPs application state(s) towards LSR1 and
previous application state from LSR1. To withdraw label bindings withdraw all previously advertised application state from LSR1. To
from its peer, LSR2 MAY use a single Prefix FEC Typed Wildcard Label withdraw label bindings from its peer, LSR2 MAY use a single Prefix
Withdraw message [RFC5918]. FEC Typed Wildcard Label Withdraw message [RFC5918] if the peer
supports Typed Wildcard FEC capability.
This dynamic disability of IPoMPLS application does not impact L2VPN This dynamic disability of Prefix-LSPs application does not impact
P2P PW application on the given session, and both LSRs should L2VPN P2P-PWs application on the given session, and both LSRs should
continue to exchange PW Signaling application related state. continue to exchange PW Signaling application related state.
6.4. Disabling IPoMPLS application on an mLDP-only session 5.4. Disabling Prefix-LSPs application on an mLDP-only session
Now assume that LSR1 and LSR2 have formed an LDP session to exchange Now assume that LSR1 and LSR2 have formed an LDP session to exchange
mLDP application state only. In typical deployments, LSR1 and LSR2 mLDP state only. In typical deployments, LSR1 and LSR2 also exchange
also exchange label bindings for IP prefixes over an mLDP session, bindings for IP (unicast) prefixes upon mLDP session, which is
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 IPoMPLS application state to its peer upon session disinterest in Prefix-LSPs application state to its peer upon
establishment time or dynamically later via LDP capabilities update. session establishment time or dynamically later via LDP capabilities
update.
Reference to section 3.1, the peer disables the advertisement of any Reference to section 3.1, the peer disables the advertisement of any
state related to IP Prefix FECs, but still advertises IP address state related to IP Prefix FECs, but still advertises IP address
bindings that are required for the correct operation of mLDP. bindings that are required for the correct operation of mLDP.
6.5. Disabling unwanted IP state advertisement by an IP dual-stack LSR 5.5. Disabling IPv4 or IPv6 Prefix-LSPs application on an dual-stack LSR
In IP dual-stack scenarios, an 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 label switching application once a session is established IPv6 Prefix-LSPs application once a session is established mainly
mainly for exchanging state for IPv4. The similar scenario also for exchanging state for IPv4. The similar scenario also applies
applies when advertising IPv4 label switching state on a session when advertising IPv4 Prefix-LSPs state on a session meant for IPv6.
meant for IPv6. The SAC capability and its procedures defined in The SAC capability and its procedures defined in this document can
this document can help to avoid such unnecessary state help to avoid such unnecessary state advertisement.
advertisement.
Consider IP dual-stack environment where LSR2 is enabled for IPoMPLS Consider IP dual-stack environment where LSR2 is enabled for Prefix-
application for both IPv4 and IPv6, but LSR1 is enabled for (or LSPs application for both IPv4 and IPv6, but LSR1 is enabled for (or
interested in) only IPv4oMPLS Label switching. To avoid receiving interested in) only IPv4 Prefix-LSPs. To avoid receiving unwanted
unwanted state advertisement for IPv6oMPLS Label switching state advertisement for IPv6 Prefix-LSPs application from LSR2, LSR1
application from LSR2, LSR1 can send SAC capability with element for can send SAC capability with element for IPv6 Prefix-LSPs with D bit
IPv6 label switching with D bit set to 1 in the Initialization set to 1 in the Initialization message towards LSR2 at the time of
message towards LSR2 at the time of session establishment. Upon session establishment. Upon receipt of this capability, LSR2 will
receipt of this capability, LSR2 will disable all IPv6 label binding disable all IPv6 label binding advertisement towards LSR1. If IPv6
advertisement towards LSR1. If IPv6oMPLS Label switching application Prefix-LSPs application is later enabled on LSR1, LSR1 can update
is later enabled on LSR1, LSR1 can update the capability by sending the capability by sending SAC capability in a Capability message
SAC capability in a Capability message towards LSR2 to enable towards LSR2 to enable this application dynamically.
IPv6oMPLS Label switching application dynamically.
7. Security Considerations 6. 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 that already apply to the base LDP
specification [RFC5036] and [RFC5920]. specification [RFC5036] and [RFC5920].
8. IANA Considerations 7. IANA Considerations
This document defines a new LDP capability parameter TLV. IANA is This document defines a new LDP capability parameter TLV. IANA is
requested to assign the lowest available value after 0x0500 from requested to assign the lowest available value after 0x0500 from
"TLV Type Name Space" in the "Label Distribution Protocol (LDP) "TLV Type Name Space" in the "Label Distribution Protocol (LDP)
Parameters" registry as the new code point for the new LDP Parameters" registry as the new code point for the new LDP
capability TLV code point. capability TLV code point.
+-----+---------------------+---------------+-----------------------+ +-----+---------------------+---------------+-----------------------+
|Value| Description | Reference |Notes/Registration Date| |Value| Description | Reference |Notes/Registration Date|
+-----+---------------------+---------------+-----------------------+ +-----+---------------------+---------------+-----------------------+
| TBA | State Advertisement | This document | | | TBA | State Advertisement | This document | |
| | Control Capability | | | | | Control Capability | | |
+-----+---------------------+---------------+-----------------------+ +-----+---------------------+---------------+-----------------------+
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP [RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP
Specification", RFC 5036, September 2007. Specification", RFC 5036, September 2007.
[RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, and JL. Le [RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, and JL. Le
Roux, "LDP Capabilities", RFC 5561, July 2009. Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997. Requirement Levels", BCP 14, RFC2119, March 1997.
9.2. Informative References 8.2. Informative References
[RFC5918] R. Asati, I. Minei, and B. Thomas, "Label Distribution [RFC5918] R. Asati, I. Minei, and B. Thomas, "Label Distribution
Protocol Typed Wildcard FEC", RFC 5918, August 2010. Protocol Typed Wildcard FEC", RFC 5918, August 2010.
[RFC4447] L. Martini, E. Rosen, El-Aawar, T. Smith, and G. Heron, [RFC4447] L. Martini, E. Rosen, El-Aawar, T. Smith, and G. Heron,
"Pseudowire Setup and Maintenance using the Label "Pseudowire Setup and Maintenance using the Label
Distribution Protocol", RFC 4447, April 2006. Distribution Protocol", RFC 4447, April 2006.
[RFC4762] M. Lasserre, and V. Kompella, "Virtual Private LAN Service [RFC4762] M. Lasserre, and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling", (VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007. RFC 4762, January 2007.
[P2MP-PW] Martini, L. et. al, "Signaling Root-Initiated Point-to- [P2MP-PW] Martini, L. et. al, "Signaling Root-Initiated Point-to-
Multipoint Pseudowires using LDP", draft-ietf-pwe3-p2mp-pw- Multipoint Pseudowires using LDP", draft-ietf-pwe3-p2mp-pw-
04.txt, Work in Progress, March 2012. 04.txt, Work in Progress, March 2012.
[ICCP] L. Martini, S. Salam, A. Sajassi, and S. Matsushima, [ICCP] L. Martini, S. Salam, A. Sajassi, and S. Matsushima,
"Inter-Chassis Communication Protocol for L2VPN PE "Inter-Chassis Communication Protocol for L2VPN PE
Redundancy", draft-ietf-pwe3-iccp-11.txt, Work in Redundancy", draft-ietf-pwe3-iccp-16.txt, Work in
Progress, February 2013. Progress, March 2014.
[RFC6388] I. Minei, I. Wijnands, K. Kompella, and B. Thomas, "LDP [RFC6388] I. Minei, I. Wijnands, K. Kompella, and B. Thomas, "LDP
Extensions for P2MP and MP2MP LSPs", RFC 6388, November Extensions for P2MP and MP2MP LSPs", RFC 6388, November
2011. 2011.
[RFC5920] L. Fang, et al., "Security Framework for MPLS and GMPLS [RFC5920] L. Fang, et al., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
10. Acknowledgments 9. Acknowledgments
The authors would like to thank Eric Rosen for his valuable input The authors would like to thank Eric Rosen for his valuable input
and comments. We also acknowledge Karthik Subramanian and IJsbrand and comments. We also acknowledge Karthik Subramanian and IJsbrand
Wijnands for bringing up mLDP use case. Wijnands for bringing up mLDP use case.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses Authors' Addresses
Kamran Raza Kamran Raza
 End of changes. 74 change blocks. 
240 lines changed or deleted 250 lines changed or added

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