draft-ietf-mpls-ldp-ip-pw-capability-03.txt   draft-ietf-mpls-ldp-ip-pw-capability-04.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: August 18, 2013 Cisco Systems Expires: November 8, 2013 Cisco Systems
February 19, 2013 May 9, 2013
Disabling IPoMPLS and P2P PW LDP Applications Disabling IPoMPLS and P2P PW LDP Application's State Advertisement
draft-ietf-mpls-ldp-ip-pw-capability-03.txt draft-ietf-mpls-ldp-ip-pw-capability-04.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.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 August 18, 2013. This Internet-Draft will expire on November 8, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 13 skipping to change at page 2, line 13
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Abstract
Currently, no LDP capability is exchanged for LDP applications like Currently, no LDP capability is exchanged for LDP applications like
IP Label Switching and L2VPN P2P PW signaling. When an LDP session IP Label Switching and L2VPN P2P PW signaling. When an LDP session
comes up, an LDP speaker may unnecessarily advertise its local state comes up, an LDP speaker may unnecessarily advertise its local state
for such LDP applications even when the peer session may be for such LDP applications even when the peer session is established
established for some other applications like ICCP. This document for some other applications like mLDP or ICCP. This document defines
proposes a solution by which an LDP speaker announces to its peer its a solution by which an LDP speaker announces to its peer its
disinterest in such non-negotiated applications. This, in turn, disinterest in such non-negotiated applications. This, in turn,
disables the advertisement of corresponding application state, which disables the advertisement of corresponding application state, which
would have otherwise be advertised by default, over the established would have otherwise be advertised by default, over the established
LDP session. 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
4. Controlling State Exchange for Non-negotiated LDP Applications 5 3.1 Non-interesting State 5
4.1. Application Control Capability 5 4. Controlling State Advertisement for Non-negotiated LDP Apps 5
5. Capabilities Procedures 7 4.1 State Advertisement Control Capabilty 5
5.1. Application Control Capability in an Initialization message 8 5.Capabilities Procedures 8
5.2. Application Control capability in a Capability message 8 5.1 State Control Capability in an Initization message 8
6. Operational Examples 8 5.2 State Control Capability in a Capabilty message 9
6.1. Disabling IPoMPLS and P2P PW apps. on an ICCP session 9 6. Operational Examples 9
6.2. Disabling IPoMPLS application on a L2VPN/PW T-LDP session 9 6.1 Disabling IPoMPLS and P2P PW applications on an ICCP session 9
6.3. Disabling IPoMPLS app.dynamically on an estab. IP/PW session 9 6.2 Disabling IPoMPLS application on a L2VPN/PW T-LDP session 10
6.4. Disabling unwanted state advertisement by a dual-stack LSR 10 6.3 Disabling IPoMPLS app. dynamically on an IP/PW LDP session 10
7. Security Considerations 10 6.4 Disabling IPoMPLS application on an mLDP-only session 10
8. IANA Considerations 10 6.5 Disabling unwanted IP state advert. by an IP dual-stack LSR 11
9. References 11 7. Security Considerations 11
9.1. Normative References 11 8. IANA Considerations 11
9.2. Informative References 11 9. References 12
9.1 Normative References 12
9.2 Informative References 12
10. Acknowledgments 12 10. Acknowledgments 12
1. Introduction 1. Introduction
LDP Capabilities [RFC5561] introduced a mechanism to negotiate LDP LDP Capabilities [RFC5561] introduced a mechanism to negotiate LDP
capabilities for a given feature amongst peer LSRs. The capability capabilities for a given feature between peer LSRs. The capability
mechanism insures that no unnecessary state is exchanged between peer mechanism insures that no unnecessary state is exchanged between peer
LSRs unless the corresponding feature capability is successfully LSRs unless the corresponding feature capability is successfully
negotiated between the peers. negotiated between the peers.
While new LDP features and applications, such as Typed Wildcard FEC While new LDP features and applications, such as Typed Wildcard FEC
[RFC5918], Inter-Chassis Communication Protocol [ICCP], mLDP [RFC5918], Inter-Chassis Communication Protocol [ICCP], mLDP
[RFC6388], and L2VPN P2MP PW [P2MP-PW] make use of LDP capabilities [RFC6388], and L2VPN P2MP PW [P2MP-PW] make use of LDP capabilities
framework for their feature negotiation, the earlier LDP features and framework for their feature negotiation, the earlier LDP features and
applications like IP Label Switching and L2VPN P2P PW signaling applications like IP Label Switching and L2VPN P2P PW signaling
[RFC4447] [RFC4762] may cause LDP speakers to exchange application [RFC4447] [RFC4762] may cause LDP speakers to exchange application
state unnecessarily even when the given application is not enabled on state unnecessarily even when the given application is not enabled on
one of the LDP speakers participating in a given session. For one of the LDP speakers participating in a given session. For
example, when bringing up and using an LDP peer session with a remote example, when bringing up and using an LDP peer session with a remote
PE LSR for purely ICCP signaling reasons, an LDP speaker may PE LSR for purely ICCP signaling reasons, an LDP speaker may
unnecessarily advertise labels for IP (unicast) prefixes to this ICCP unnecessarily advertise labels for IP (unicast) prefixes to this ICCP
related LDP peer as per its default behavior. 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 for both IPv4 and IPv6 label switching
may advertise address/label bindings for both IPv4 and IPv6 address may advertise label bindings for both IPv4 and IPv6 address families
families towards an LDP peer that is interested in IPv4 only. In this towards an LDP peer that is interested in IPv4 prefix labels only. In
case, the advertisement of IPv6 addresses and IPv6 prefix labels to this case, the advertisement of IPv6 prefix labels to the peer is
the peer is unnecessary, as well as wasteful, from the point of view unnecessary, as well as wasteful, from the point of view of LSR
of LSR memory/CPU and network resource consumption. 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 some sort
of filtering policies on the LSR for exchanging LDP applications of filtering policies on the LSR, which introduces operational
state, which introduces operational overhead and complexity. overhead and complexity for such deployments.
This document proposes an LDP Capabilities [RFC5561] based solution This document defines an LDP Capabilities [RFC5561] based solution by
by which an LDP speaker may announce to its peer(s) its disinterest which an LDP speaker may announce to its peer(s) its disinterest (or
(or non-support/disability) for IP Label Switching and/or L2VPN P2P non-support) for state related to IP Label Switching and/or L2VPN P2P
PW Signaling application at the time of session establishment. This PW Signaling application at the time of session establishment. This
helps avoiding unnecessary state exchange for such feature helps in avoiding unnecessary state advertisement for such feature
applications. The proposal also states the mechanics to dynamically applications. The document also states the mechanics to dynamically
disable or enable such an application during the session lifetime. disable or enable the state advertisement for such applications
The document introduces a new LDP capability to implement this during the session lifetime. The non-interesting state of an
proposal. application depends on the type of application and is described later
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.
skipping to change at page 4, line 35 skipping to change at page 4, line 35
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 right
after the session establishment. These early LDP applications after the session establishment. These early LDP applications
include: include:
o IPv4/IPv6 Label Switching ("IPoMPLS") o IPv4/IPv6 Label Switching ("IPoMPLS")
o L2VPN P2P PW signaling ("P2P PW") o L2VPN P2P PW signaling ("P2P PW")
To disable unnecessary state exchange for such LDP applications, a To disable unnecessary state exchange for such LDP applications over
new capability is being introduced in this document. This new an established LDP session, a new capability is being introduced in
capability controls the advertisement of application state and this document. This new capability controls the advertisement of
enables an LDP speaker to notify its peer its disinterest in one or application state and enables an LDP speaker to notify its peer its
more of these "Non-negotiated" LDP applications at the time of disinterest in the state of one or more of these "Non-negotiated"
session establishment. Upon receipt of such capability, the receiving LDP applications at the time of session establishment. Upon receipt
LDP speaker, if supporting the capability, disables the advertisement of such capability, the receiving LDP speaker, if supporting the
of any state related to the application towards the sender. This new capability, disables the advertisement of the state related to the
capability can also be sent later in a Capability message to either application towards the sender. This new capability can also be sent
disable enabled applications or to enable previously disabled later in a Capability message to either disable a previously enabled
applications. application's state advertisement or to enable a previously disabled
application's state advertisement.
4. Controlling State Exchange for Non-negotiated LDP Applications 3.1. Non-interesting State
To control advertisement of state related to non-negotiated LDP So far, this document has used the term application "state" to
applications, namely IPoMPLS and P2P PW signaling, a new capability generically refer to some non-interesting state. Now, let us further
TLV is defined as follows. specify and clarify this term:
4.1. Application Control Capability . A non-interesting state of a non-negotiated application refers
to the application state which is of a no interest to an LSR
and need not be advertised to the LSR;
. This state MUST NOT be advertised in any of the LDP protocol
messages;
. This state is dependent on application type and specified
accordingly.
The "Application Control Capability" is a new Capability Parameter For IPoMPLS application type, the non-interesting state refers to
TLV defined in accordance with section 3 of LDP Capabilities any state related to IP Prefix FEC (such as label bindings, LDP
specification [RFC5561]. The format of this new TLV is as follows: Status). This document, however, does not classify IP address
bindings as a non-interesting state and allows the advertisement of
IP Address bindings to facilitate other LDP applications (such as
mLDP) that depend on learning of peer addresses over an LDP session
for their correct operation.
For P2P PW application type, the non-interesting state refers to any
state related to P2P PW FEC (such as label bindings, MAC [address]
withdrawal, and LDP PW Status).
From now onward in this document, the term "state" will mean to
refer to the "non-interesting state" for an application, as defined
in this section.
4. Controlling State Advertisement for Non-negotiated LDP Applications
To control advertisement of non-interesting state related to non-
negotiated LDP applications, namely IPoMPLS and P2P PW signaling, a
new capability TLV is defined as follows.
4.1. State Advertisement Control Capability
The "State Advertisement Control Capability" is a new Capability
Parameter TLV defined in accordance with section 3 of LDP
Capabilities specification [RFC5561]. The format of this new TLV is
as follows:
0 1 2 3 0 1 2 3
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| App Control Cap. (IANA) | Length | |U|F| State Adv. Ctrl Cap.(IANA)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | | |S| Reserved | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | | |
~ Application Control Element(s) ~ ~ State Advertisement Control Element(s) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of an "Application 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 continue receiver MUST silently ignore this TLV if unknown to it, and
processing the rest of the message. Whereas, The value of F-bit MUST continue processing the rest of the message. Whereas, The value of
be set to 0. Once advertised, this capability cannot be withdrawn; F-bit MUST be set to 0. Once advertised, this capability cannot be
thus S-bit MUST be set to 1 both in an Initialization and Capability withdrawn; thus S-bit MUST be set to 1 both in an Initialization and
message. Capability message.
The capability data associated with this TLV is one or more The capability data associated with this State Advertisement Control
Application Control Elements, where each element indicates (SAC) Capability TLV is one or more State Advertisement Control
enabling/disabling of state advertisement for a given application. (SAC) Elements, where each element indicates enabling/disabling of
The format of an Application Control Element is defined as follows: advertisement of non-interesting state for a given application. The
format of a SAC Element is defined as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AppType|D|Rsvd1| Rsvd2 | | State |D|Rsvd1| Rsvd2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of an "Application Control Element" Figure 2: Format of an "State Advertisement Control Element"
Where: Where:
AppType: Defines the (non-negotiated) application type. The value of State: Defines the type of application state (to be controlled).
this field is defined as: The value of this field is defined as follows:
1: IPv4 Label switching 1: IPv4 Label switching
2: IPv6 Label switching 2: IPv6 Label switching
3: P2P PW FEC128 signaling 3: P2P PW FEC128 signaling
4: P2P PW FEC129 signaling 4: P2P PW FEC129 signaling
0, 5-15: Reserved. 0, 5-15: Reserved.
D bit: Controls the advertisement of state for the application: 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 on Rsvd1, Rsvd2: Reserved for future use. MBZ on transmit and ignored
receipt. on receipt.
The "Length" field of "Application Control Capability" TLV depends on The "Length" field of SAC Capability TLV depends on the number of
the number of Application Control Elements present in the TLV. For SAC Elements present in the TLV. For example, if there are two
example, if there are two elements present, then the Length field is elements present, then the Length field is set to 5 octets. A
set to 5 octets. A receiver of this capability TLV can deduce number receiver of this capability TLV can deduce number of elements
of application control elements present in the TLV by using Length present in the TLV by using the Length field.
field.
From now onward, this document uses the term "element" to refer to an From now onward, this document uses the term "element" to refer to a
Application Control Element. SAC Element.
As described earlier, "Application Control Capability" TLV MAY be As described earlier, SAC Capability TLV MAY be included by an LDP
included by an LDP speaker in an Initialization message to signal to speaker in an Initialization message to signal to its peer LSR that
its peer LSR that state exchange for one or more application(s) need state exchange for one or more application(s) need to be disabled on
to be disabled on the given peer session. This TLV can also be sent the given peer session. This TLV can also be sent later in a
later in a Capability message to selectively enable or disable these Capability message to selectively enable or disable these
applications. An "Application Control Capability" TLV MUST contain applications. A SAC Capability TLV MUST contain elements with
elements with distinct application types and the TLV MUST NOT contain distinct state types and the TLV MUST NOT contain the same state
the same application type more than once. If a receiver receives such type more than once. If a receiver receives such a malformed TLV, it
a malformed TLV, it SHOULD discard this TLV and continue processing SHOULD discard this TLV and continue processing rest of the message.
rest of the message.
To control more than one application, a sender LSR can either send a To control more than one application state, a sender LSR can either
single capability TLV in a message with multiple elements present, or send a single capability TLV in a message with multiple elements
can send separate messages with capability TLV specifying one or more present, or can send separate messages with capability TLV
elements. A receiving LSR, however, MUST treat each incoming specifying one or more elements. A receiving LSR, however, MUST
capability TLV for a given application type as an update to its treat each incoming capability TLV for a given application state
existing policy for given type. 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 the LSRs, S (LDP speaker) and P (LDP peer), both of which support all
non-negotiated applications listed earlier. By default, these LSR the non-negotiated applications listed earlier. By default, these
will advertise state for these applications, as configured, to their LSR will advertise state for these applications, as configured, to
peer as soon as an LDP session is established. Now assume that P their peer as soon as an LDP session is established. Now assume that
receives an Application Control capability in the Initialization P receives from S a SAC capability in the Initialization message
message with "IPv6 Label switching" and "P2P PW FEC129" applications with "IPv6 Label switching" and "P2P PW FEC129" states disabled.
disabled. This updates P's outbound policy towards S to advertise This updates P's outbound policy towards S to advertise state
state related to only "IPv4 Label switching" and "P2P PW FEC 128" related to only "IPv4 Label switching" and "P2P PW FEC 128"
applications. Later, P receives another capability update from S via applications. Later, P receives another capability update from S
a Capability message with "IPv6 Label switching" enabled and "P2P PW via a Capability message with "IPv6 Label switching" enabled and
FEC128" disabled. This results in P's outbound policy towards S to "P2P PW FEC128" disabled. This results in P's outbound policy
advertise both IPv4 and IPv6 Label switching state, and disable both towards S to advertise both IPv4 and IPv6 Label switching state, and
P2P PW FEC128 and FEC 129 signaling. Finally, P receives another disable both P2P PW FEC128 and FEC 129 signaling. Finally, P
update from S via a Capability message that specifies to disable all receives another update from S via a Capability message that
four non-negotiated applications, resulting P outbound policy towards specifies to disable all four non-negotiated applications state,
S to block/disable state for all these applications, and only resulting in P outbound policy towards S to block/disable state for
advertise state for any other application, if present. all these applications, and only advertise state for any other
application, as applicable.
5. Capabilities Procedures 5. Capabilities Procedures
The "Application Control" capability conveys the desire of an LSR to The SAC capability conveys the desire of an LSR to disable the
disable 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 uni-lateral and uni-directional 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. This Initialization or Capability message towards the sender of this
unilateral behavior conforms to the procedures defined in the Section capability. This unilateral behavior conforms to the procedures
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
advertise any state related to the disabled applications towards the MUST NOT advertise any state related to the disabled applications
capability sending LSR until and unless these applications are towards the capability sending LSR until and unless these
explicitly enabled again via a capability update. application states are explicitly enabled again via a capability
update. Upon receipt of a capability update to disable an enabled
application [state] during the lifetime of a session, the receiving
LSR MUST also withdraw from the peer any previously advertised state
(corresponding to the disabled application).
If a receiving LDP speaker does not understand the Application If a receiving LDP speaker does not understand the SAC capability
Control capability TLV, then it MUST respond to the sender with TLV, then it MUST respond to the sender with "Unsupported TLV"
"Unsupported TLV" notification as described in LDP Capabilities notification as described in LDP Capabilities [RFC5561]. If a
[RFC5561]. If a receiving LDP speaker does not understand or does not receiving LDP speaker does not understand or does not support an
support an application specified in an application control element, application specified in an application control element, it SHOULD
it SHOULD silently ignore/skip such an element and continue silently ignore/skip such an element and continue processing rest of
processing rest of the TLV. the TLV.
5.1. Application Control Capability in an Initialization message 5.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 IPoMPLS 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
"Application Control Capability" TLV needs to be included in the the SAC TLV needs to be included in the Initialization message with
Initialization message with respective application control elements respective SAC elements included with their D bit set to 1.
included with their D bit set to 1.
An LDP speaker that supports the "Application Control" capability
MUST interpret the capability TLV in a received Initialization
message such that it disables the advertisement of the application
state towards the capability sending LSR for IPoMPLS and/or P2P PW
applications if their application control element's D bit is set to
1.
5.2. Application Control capability in a Capability message An LDP speaker that supports the SAC capability MUST interpret the
capability TLV in a received Initialization message such that it
disables the advertisement of the application state towards the
capability sending LSR for IPoMPLS and/or P2P PW applications if
their SAC element's D bit is set to 1.
If the LDP peer supports "Dynamic Announcement Capability" [RFC5561], 5.2. State Control capability in a Capability message
then an LDP speaker may send Application Control capability in a
If the LDP peer supports "Dynamic Announcement Capability"
[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 one An LDP speaker may decide to send this TLV towards an LDP peer if
or more of its IPoMPLS and/or P2P PW signaling applications get one or more of its IPoMPLS and/or P2P PW signaling 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
application control element(s) and sends the corresponding capability SAC element(s) and sends the corresponding capability TLV in a
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 application state from/to the capability sending withdraws/advertises the application state from/to the capability
LDP speaker according to the capability update. sending LDP speaker according to the capability update.
6. Operational Examples 6. Operational Examples
6.1. Disabling IPoMPLS and P2P PW applications on an ICCP session 6.1. Disabling IPoMPLS and P2P PW applications on an ICCP session
Consider two PE routers, LSR1 and LSR2, which understand/support Consider two PE routers, LSR1 and LSR2, which understand/support SAC
"Application Control" capability TLV, and have an established LDP capability TLV, and have an established LDP session to exchange ICCP
session to exchange ICCP state related to dual-homed devices state related to dual-homed devices connected to these LSRs. Let us
connected to these LSRs. Let us assume that both LSRs are assume that both LSRs are provisioned not to exchange any state for
provisioned not to exchange any state for IPoMPLS (IPv4/IPv6) and IPoMPLS (IPv4/IPv6) and P2P PW (FEC128/129) application.
P2P PW (FEC128/129) application.
To indicate their disinterest in these applications, the LSRs will To indicate their disinterest in these applications, the LSRs will
include an "Application Control" capability TLV (with 4 application include a SAC capability TLV (with 4 SAC elements corresponding to
control elements corresponding to these 4 applications with D bit these 4 applications with D bit set to 1 for each one) in the
set to 1 for each one) in the Initialization message. Upon receipt Initialization message. Upon receipt of this TLV in Initialization
of this TLV in Initialization message, the receiving LSR will message, the receiving LSR will disable the advertisement of
disable advertisement of IPv4/IPv6 bindings (addresses and labels), IPv4/IPv6 label bindings, as well as P2P PW FEC128/129 signaling,
as well as P2P PW FEC128/129 signaling, towards its peer after towards its peer after session establishment.
session establishment.
6.2. Disabling IPoMPLS application on a L2VPN/PW T-LDP session 6.2. Disabling IPoMPLS application on a L2VPN/PW T-LDP session
Now, consider LSR1 and LSR2 have an established T-LDP session for Now, consider LSR1 and LSR2 have an established T-LDP session for
P2P PW application to exchange label bindings for FEC 128/129. Given P2P PW application to exchange label bindings for FEC 128/129. Given
that there is no need to exchange IP (v4/v6) address/label bindings that there is no need to exchange IP (v4/v6) label bindings between
amongst the PE LSRs over a PW T-LDP session in most typical the PE LSRs over a PW T-LDP session in most typical deployments, let
deployments, let us assume that LSRs are provisioned to disable us assume that LSRs are provisioned to disable IPoMPLS (IPv4/IPv6)
IPoMPLS (IPv4/IPv6)application on given PW session. application state on given PW session.
To indicate their disinterest in IPoMPLS application over PW T-LDP To indicate their disinterest in IPoMPLS application over a PW T-LDP
session, the LSRs will follow/apply the same procedures to disable session, the LSRs will follow/apply the same procedures to disable
IPv4 and IPv6 label switching as described in previous section. As a IPv4 and IPv6 label switching as described in previous section. As a
result, only P2P PW related state will be exchanged between these result, only P2P PW related 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 6.3. Disabling IPoMPLS application dynamically on an established IP/PW
session LDP session
Assume that LSRs from previous sections were initially provisioned to Assume that LSRs from previous sections were initially provisioned
exchange both IPoMPLS and P2P PW state over the session between them, to exchange both IPoMPLS and P2P PW state over the session between
and also support "Dynamic Announcement" Capability [RFC5561]. Now, them, and also support "Dynamic Announcement" Capability [RFC5561].
assume that LSR1 is dynamically provisioned to disable IPoMPLS Now, assume that LSR1 is dynamically provisioned to disable IPoMPLS
(IPv4/IPv6) over T-LDP session with LSR2. In this case, LSR1 will (IPv4/IPv6) over T-LDP session with LSR2. In this case, LSR1 will
send Application Control capability TLV in a Capability message send SAC capability TLV in a Capability message towards LSR2 with
towards LSR2 with application control elements defined for IPv4 and application control elements defined for IPv4 and IPv6 label
IPv6 label switching with D bit set to 1. Upon receipt of this TLV, switching with D bit set to 1. Upon receipt of this TLV, LSR2 will
LSR2 will disable IPoMPLS application(s) towards LSR1 and withdraw disable IPoMPLS application state(s) towards LSR1 and withdraw all
all previous IP label/address state from LSR1. To withdraw label and previous application state from LSR1. To withdraw label bindings
address bindings from its peer, LSR2 MAY use a single Prefix FEC from its peer, LSR2 MAY use a single Prefix FEC Typed Wildcard Label
Typed Wildcard Label Withdraw message [RFC5918] and an Address Withdraw message [RFC5918].
Withdraw message respectively.
This dynamic disability of IPoMPLS application does not impact L2VPN This dynamic disability of IPoMPLS application does not impact L2VPN
P2P PW application on the given session, and both LSRs should P2P PW 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 unwanted state advertisement by an IP dual-stack LSR 6.4. Disabling IPoMPLS application on an mLDP-only session
Now assume that LSR1 and LSR2 have formed an LDP session to exchange
mLDP state only. In typical deployments, LSR1 and LSR2 also exchange
bindings for IP prefixes upon mLDP session, which is unnecessary and
wasteful for an mLDP-only LSR.
Using the procedures defined earlier, an LSR can indicate its
disinterest in IPoMPLS application state to its peer upon session
establishment time or dynamically later via LDP capabilities update.
Reference to section 3.1, the peer disables the advertisement of any
state related to IP Prefix FECs, but still advertises IP address
bindings that are required for the correct operation of mLDP.
6.5. Disabling unwanted IP state advertisement by an IP dual-stack LSR
In IP dual-stack scenarios, an LSR2 may advertise unnecessary state In IP dual-stack scenarios, an LSR2 may advertise unnecessary state
(label/address bindings) towards peer LSR1 corresponding to IPv6 (e.g. IPv6 prefix label bindings) towards peer LSR1 corresponding to
label switching application once a session is established mainly for IPv6 label switching application once a session is established
exchanging state for IPv4. The similar scenario also applies when mainly for exchanging state for IPv4. The similar scenario also
advertising IPv4 label switching state on a session meant for IPv6. applies when advertising IPv4 label switching state on a session
The Application Control capability and its procedures defined in this meant for IPv6. The SAC capability and its procedures defined in
document can help to avoid such unnecessary state advertisement. this document can help to avoid such unnecessary state
advertisement.
Consider IP dual-stack environment where LSR2 is enabled for IPoMPLS Consider IP dual-stack environment where LSR2 is enabled for IPoMPLS
application for both IPv4 and IPv6, but LSR1 is enabled for (or application for both IPv4 and IPv6, but LSR1 is enabled for (or
interested in) only IPv4oMPLS. To avoid receiving unwanted state interested in) only IPv4oMPLS Label switching. To avoid receiving
advertisement for IPv6oMPLS application from LSR2, LSR1 can send unwanted state advertisement for IPv6oMPLS Label switching
"Application Control" capability with element for IPv6 label application from LSR2, LSR1 can send SAC capability with element for
switching with D bit set to 1 in the Initialization message towards IPv6 label switching with D bit set to 1 in the Initialization
LSR2 at the time of session establishment. Upon receipt of this message towards LSR2 at the time of session establishment. Upon
capability, LSR2 will disable all IPv6 label and address binding receipt of this capability, LSR2 will disable all IPv6 label binding
advertisement towards LSR1. If IPv6oMPLS is later enabled on LSR1, advertisement towards LSR1. If IPv6oMPLS Label switching application
LSR1 can update the capability by sending Application Control is later enabled on LSR1, LSR1 can update the capability by sending
capability in Capability message towards LSR2 to enable IPv6oMPLS SAC capability in a Capability message towards LSR2 to enable
application dynamically. IPv6oMPLS Label switching application dynamically.
[LDPv6] specification section 7 also suggests an alternate way to
avoid the unnecessary state advertisement in the above scenario.
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 that already apply to the base LDP
specification [RFC5036] and [RFC5920]. specification [RFC5036] and [RFC5920].
8. IANA Considerations 8. IANA Considerations
The document defines a new capability parameter TLV and requests The document defines a new capability parameter TLV and requests
following LDP TLV code point assignment by IANA from LDP "TLV Type following LDP TLV code point assignment by IANA from LDP "TLV Type
Name Space" registry: Name Space" registry:
o "Application Control Capability" TLV (requested codepoint: 0x50C) o "State Advertisement Control Capability" TLV (requested
codepoint: 0x50C)
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP Specification", [RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP
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 9.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-09.txt, Work in Progress, Redundancy", draft-ietf-pwe3-iccp-11.txt, Work in
July 2012. Progress, February 2013.
[RFC6388] I. Minei, I. Wijnand, 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.
[LDPv6] R. Asati, et al., "Updates to LDP for IPv6", draft-ietf-
mpls-ldp-ipv6-07.txt, Work in Progress, June 2012.
[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 10. Acknowledgments
The authors would like to thank Eric Rosen for his valuable input and The authors would like to thank Eric Rosen for his valuable input
comments. and comments. We also acknowledge Karthik Subramanian and IJsbrand
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
Cisco Systems, Inc., Cisco Systems, Inc.,
2000 Innovation Drive, 2000 Innovation Drive,
Ottawa, ON K2K-3E8, Canada. Ottawa, ON K2K-3E8, Canada.
E-mail: skraza@cisco.com E-mail: skraza@cisco.com
 End of changes. 64 change blocks. 
222 lines changed or deleted 269 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/