draft-ietf-mpls-ldp-ip-pw-capability-02.txt   draft-ietf-mpls-ldp-ip-pw-capability-03.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: February 17, 2013 Cisco Systems Expires: August 18, 2013 Cisco Systems
August 18, 2012 February 19, 2013
Disabling IPoMPLS and P2P PW LDP Applications Disabling IPoMPLS and P2P PW LDP Applications
draft-ietf-mpls-ldp-ip-pw-capability-02.txt draft-ietf-mpls-ldp-ip-pw-capability-03.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 February 17, 2013. This Internet-Draft will expire on August 18, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 may be
established for some other applications like ICCP. This document established for some other applications like ICCP. This document
proposes a solution by which an LDP speaker announces its disinterest proposes a solution by which an LDP speaker announces to its peer its
in such non-negotiated application. This, in turn, disables the disinterest in such non-negotiated applications. This, in turn,
advertisement of corresponding application state, which would have disables the advertisement of corresponding application state, which
otherwise be advertised by default, over the established LDP session. would have otherwise be advertised by default, 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
4. Controlling State Exchange for Non-negotiated LDP Applications 5 4. Controlling State Exchange for Non-negotiated LDP Applications 5
4.1. Application Control Capability 5 4.1. Application Control Capability 5
5. Capabilities Procedures 7 5. Capabilities Procedures 7
5.1. Application Control Capability in an Initialization message 7 5.1. Application Control Capability in an Initialization message 8
5.2. Application Control capability in a Capability message 8 5.2. Application Control capability in a Capability message 8
6. Operational Examples 8 6. Operational Examples 8
6.1. Disabling IPoMPLS and P2P PW application on an ICCP session 8 6.1. Disabling IPoMPLS and P2P PW apps. on an ICCP session 9
6.2. Disabling IPoMPLS application on a L2VPN/PW T-LDP session 9 6.2. Disabling IPoMPLS application on a L2VPN/PW T-LDP session 9
6.3. Disabling IPoMPLS appl. dynamically on an IP/PW session 9 6.3. Disabling IPoMPLS app.dynamically on an estab. IP/PW session 9
6.4. Disabling unwanted state advert. by an IP dual-stack LSR 10 6.4. Disabling unwanted state advertisement by a dual-stack LSR 10
7. Security Considerations 10 7. Security Considerations 10
8. IANA Considerations 10 8. IANA Considerations 10
9. Conclusions 11 9. References 11
10. References 11 9.1. Normative References 11
10.1. Normative References 11 9.2. Informative References 11
10.2. Informative References 11 10. Acknowledgments 12
11. 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 amongst 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 corresponding feature capability is successfully LSRs unless the corresponding feature capability is successfully
negotiated between 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 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 unnecessary state exchange between LDP [RFC4447] [RFC4762] may cause LDP speakers to exchange application
peers even when the given application is not enabled on one of the state unnecessarily even when the given application is not enabled on
LDP speakers participating in a given session. one of the LDP speakers participating in a given session. For
example, when bringing up and using an LDP peer session with a remote
For example, when bringing up and using an LDP peer session with a PE LSR for purely ICCP signaling reasons, an LDP speaker may
remote PE LSR for purely ICCP signaling purposes, the 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 as per its default behavior.
Another example of unnecessary state advertisement can be cited when Another example of unnecessary state advertisement can be cited when
LDP is used in an IP dual-stack environment. For instance, an LSR LDP is to be deployed in an IP dual-stack environment. For instance,
that is locally enabled for both IPv4 and IPv6 label switching may an LSR that is locally enabled for both IPv4 and IPv6 label switching
advertise address/label bindings for both IPv4 and IPv6 address may advertise address/label bindings for both IPv4 and IPv6 address
families towards an LDP peer that is interested in IPv4 only. In this families towards an LDP peer that is interested in IPv4 only. In this
case, the advertisement of IPv6 addresses and IPv4 prefix labels to case, the advertisement of IPv6 addresses and IPv6 prefix labels to
the peer is unnecessary, as well as wasteful from LSR memory/CPU and the peer is unnecessary, as well as wasteful, from the point of view
network resource consumption point of view. 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 some sort
of filtering policies on the box for LDP state exchange, which of filtering policies on the LSR for exchanging LDP applications
introduces operational overhead and complexity. state, which introduces operational overhead and complexity.
This document proposes an LDP Capabilities [RFC5561] based solution This document proposes an LDP Capabilities [RFC5561] based solution
by which an LDP speaker may announce its disinterest (or non- by which an LDP speaker may announce to its peer(s) its disinterest
support/disability) to its peer for IP Label Switching and/or L2VPN (or non-support/disability) for IP Label Switching and/or L2VPN P2P
P2P PW Signaling application at the time of session establishment. PW Signaling application at the time of session establishment. This
This helps avoiding unnecessary state exchange for such feature helps avoiding unnecessary state exchange for such feature
applications. The proposal also states the mechanics to disable or applications. The proposal also states the mechanics to dynamically
enable an application dynamically during the session lifetime. The disable or enable such an application during the session lifetime.
document introduces a new LDP capability to implement this proposal. The document introduces a new LDP capability to implement this
proposal.
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 unicast" and The term "IP" in this document refers to both IPv4 and IPv6 unicast
"IPv6 unicast" address families. address families.
This document uses shorthand terms "IPoMPLS" to refer to IP Label This document uses shorthand terms "IPoMPLS" to refer to IP Label
switching application, and "P2P PW" to refer to L2VPN PW signaling Switching application, and "P2P PW" to refer to L2VPN PW signaling
for FEC 128 and FEC 129 P2P PWs. for FEC 128 and FEC 129 P2P Pseudowires.
3. Non-negotiated LDP applications 3. Non-negotiated LDP applications
For the applications that existed before LDP Capabilities [RFC5561] For the applications that existed prior to the definition of LDP
procedures were defined, an LDP speaker typically advertises relevant Capabilities framework [RFC5561], an LDP speaker typically
application state to its peers after session establishment without advertises, without waiting for any capabilities exchange and
waiting for any capabilities exchange and negotiation. These LDP negotiation, its corresponding application state to its peers right
applications are: after the session establishment. These early LDP applications
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, a
new capability is being introduced in this document. This new new capability is being introduced in this document. This new
capability controls the advertisement of application state and capability controls the advertisement of application state and
enables an LDP speaker to notify its LDP peer its disinterest in one enables an LDP speaker to notify its peer its disinterest in one or
or more of these "Non-negotiated" LDP applications at the time of more of these "Non-negotiated" LDP applications at the time of
session establishment. Upon receipt of such capability, the receiving session establishment. Upon receipt of such capability, the receiving
LDP speaker, if supporting the capability, MUST disable the LDP speaker, if supporting the capability, disables the advertisement
advertisement of any state related to the application towards the of any state related to the application towards the sender. This new
sender. Moreover, the sender LSR SHOULD also disable the capability can also be sent later in a Capability message to either
advertisement of corresponding application state towards the peer. disable enabled applications or to enable previously disabled
This new capability can also be sent later in a Capability message to applications.
either disable these applications, or to enable previously disabled
applications dynamically.
4. Controlling State Exchange for Non-negotiated LDP Applications 4. Controlling State Exchange for Non-negotiated LDP Applications
To control advertisement of state related to non-negotiated LDP To control advertisement of state related to non-negotiated LDP
applications, namely IPoMPLS and P2P PW signaling, a new capability applications, namely IPoMPLS and P2P PW signaling, a new capability
TLVs is defined as follows. TLV is defined as follows.
4.1. Application Control Capability 4.1. Application Control Capability
The "Application Control Capability" is a new Capability Parameter The "Application Control Capability" is a new Capability Parameter
TLV defined in accordance with section 3 of LDP Capabilities TLV defined in accordance with section 3 of LDP Capabilities
specification [RFC5561]. The format of this new TLV is as follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 34 skipping to change at page 5, line 34
| | | |
~ Application Control Element(s) ~ ~ Application Control Element(s) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of an "Application Control Capability" TLV Figure 1: Format of an "Application Control Capability" TLV
The value of the U-bit for the TLV MUST be set to 1 so that a The value of the U-bit for the TLV MUST be set to 1 so that a
receiver MUST silently ignore this TLV if unknown to it, and continue receiver MUST silently ignore this TLV if unknown to it, and continue
processing the rest of the message. Whereas, The value of F-bit MUST processing the rest of the message. Whereas, The value of F-bit MUST
be set to 0. Once advertised, this capability cannot be withdrawn and be set to 0. Once advertised, this capability cannot be withdrawn;
hence the S-bit MUST be set to 1 both in Initialization message and thus S-bit MUST be set to 1 both in an Initialization and Capability
Capability message. message.
The capability data associated with this TLV is one or more The capability data associated with this TLV is one or more
Application Control Elements, where each element defines Application Control Elements, where each element indicates
enabling/disabling of state advertisement for a given application. enabling/disabling of state advertisement for a given application.
The format of an Application Control Element is defined as follows: The format of an Application Control 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| App |D|Rsvd1| Rsvd2 | |AppType|D|Rsvd1| Rsvd2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of an "Application Control Element" Figure 2: Format of an "Application Control Element"
Where: Where:
App: Defines the (non-negotiated) application type. The value of this AppType: Defines the (non-negotiated) application type. The value of
field is defined as: this field is defined as:
0: IPv4 Label switching 1: IPv4 Label switching
1: IPv6 Label switching 2: IPv6 Label switching
2: P2P PW FEC128 signaling 3: P2P PW FEC128 signaling
3: P2P PW FEC129 signaling 4: P2P PW FEC129 signaling
4-15: Reserved. 0, 5-15: Reserved.
D bit: Controls the advertisement of state for the application as D bit: Controls the advertisement of state for the application:
follows
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.
Rsvd1, Rsvd2: Reserved for future use. MBZ on transmit and ignored on Rsvd1, Rsvd2: Reserved for future use. MBZ on transmit and ignored on
receipt. receipt.
The "Length" field of "Application Control Capability" TLV depends on The "Length" field of "Application Control Capability" TLV depends on
the number of Application Control Elements present in the TLV. For the number of Application Control Elements present in the TLV. For
example, if there are two elements present, then the Length field is example, if there are two elements present, then the Length field is
set to 5 octets. A receiver of this capability TLV can deduce number set to 5 octets. A receiver of this capability TLV can deduce number
of application control elements present in the TLV by using Length of application control elements present in the TLV by using Length
field. field.
For now onward, this document uses term "element" to refer to an From now onward, this document uses the term "element" to refer to an
application control element. Application Control Element.
As described earlier, "Application Control Capability" TLV MAY be As described earlier, "Application Control Capability" TLV MAY be
included by an LDP speaker in an Initialization message to signal to included by an LDP speaker in an Initialization message to signal to
its peer LSR that state exchange for one or more application(s) need its peer LSR that state exchange for one or more application(s) need
to be disabled on a given peer session. This TLV can also be sent to be disabled on the given peer session. This TLV can also be sent
later in a Capability message to selectively enable or disable these later in a Capability message to selectively enable or disable these
applications. An "Application Control Capability" TLV MUST contain applications. An "Application Control Capability" TLV MUST contain
elements with distinct application types and the TLV MUST NOT contain elements with distinct application types and the TLV MUST NOT contain
the same application type more than once. the same application type more than once. If a receiver receives such
a malformed TLV, it SHOULD discard this TLV and continue processing
rest of the message.
To control more than one application, a sender LSR can either send a To control more than one application, a sender LSR can either send a
single capability TLV in a message with multiple elements present, or single capability TLV in a message with multiple elements present, or
can send separate messages with capability TLV specifying one or more can send separate messages with capability TLV specifying one or more
elements. A receiving LSR, however, MUST treat each incoming message elements. A receiving LSR, however, MUST treat each incoming
with capability TLV as an incremental update to the existing control. capability TLV for a given application type as an update to its
existing policy for given type.
To understand capability updates from an example, let us consider 2 To understand capability updates from an example, let us consider 2
LSR peers, R1 (sender) and R2 (receiver), both of which support all LSRs, S (LDP speaker) and P (LDP peer), both of which support all the
the non-negotiated applications listed earlier. By default, these LSR non-negotiated applications listed earlier. By default, these LSR
will advertise state for these applications to their peer as soon as will advertise state for these applications, as configured, to their
an LDP session is established. Now assume that R2 receives an peer as soon as an LDP session is established. Now assume that P
Application Control capability in the Initialization message with receives an Application Control capability in the Initialization
"IPv6 Label switching" and "P2P PW FEC129" applications disabled. message with "IPv6 Label switching" and "P2P PW FEC129" applications
This updates R2's outbound policy towards R1 to advertise state disabled. This updates P's outbound policy towards S to advertise
related to only "IPv4 Label switching" and "P2P PW FEC 128" state related to only "IPv4 Label switching" and "P2P PW FEC 128"
applications. Now, R2 receives a capability update from R1 via a applications. Later, P receives another capability update from S via
Capability message with "IPv6 Label switching" enabled and "P2P PW a Capability message with "IPv6 Label switching" enabled and "P2P PW
FEC128" disabled. This updates R2's outbound policy towards R1 to FEC128" disabled. This results in P's outbound policy towards S to
advertise both IPv4 and IPv6 Label switching state, and disable both advertise both IPv4 and IPv6 Label switching state, and disable both
P2P PW FEC128 and FEC 129 signaling. Finally, R2 receives another P2P PW FEC128 and FEC 129 signaling. Finally, P receives another
update from R1 via Capability message that specifies to disable all 4 update from S via a Capability message that specifies to disable all
non-negotiated applications, resulting R2 outbound policy towards R1 four non-negotiated applications, resulting P outbound policy towards
to block/disable state for all these applications, and only advertise S to block/disable state for all these applications, and only
state for any other application, if present. advertise state for any other application, if present.
5. Capabilities Procedures 5. Capabilities Procedures
The "Application Control" capability conveys the desire of a sending The "Application Control" capability conveys the desire of an LSR to
LSR to disable receipt of unwanted/unnecessary state from a peer. disable receipt of unwanted/unnecessary state from its LDP peer. This
Hence, this capability is unilateral and uni-directional in nature, capability is uni-lateral and uni-directional in nature, and a
and a receiving LSR is not required to send a similar capability TLV receiving LSR is not required to send a similar capability TLV in an
in an Initialization or Capability message towards the sender. This Initialization or Capability message towards the sender. This
unilateral behavior also conforms to the procedures defined in the unilateral behavior conforms to the procedures defined in the Section
Section 6 of LDP Capabilities [RFC5561]. 6 of LDP Capabilities [RFC5561].
After this capability is successfully negotiated (i.e. sent by a After this capability is successfully negotiated (i.e. sent by an LSR
sender and received/understood by the receiver), then both and received/understood by its peer), then the receiving LSR MUST NOT
participating LSRs MUST NOT exchange any state related to the advertise any state related to the disabled applications towards the
disabled applications until and unless these applications are capability sending LSR until and unless these applications are
explicitly enabled again via a capability update. explicitly enabled again via a capability update.
If a receiving LDP speaker does not understand the Application If a receiving LDP speaker does not understand the Application
Control capability TLV, then it MUST respond to the sender with Control capability TLV, then it MUST respond to the sender with
"Unsupported TLV" Notification as described in LDP Capabilities "Unsupported TLV" notification as described in LDP Capabilities
[RFC5561]. Upon receipt of such Notification, the sender MAY still [RFC5561]. If a receiving LDP speaker does not understand or does not
continue to block/disable its outbound state advertisement towards support an application specified in an application control element,
the peer for the requested disabled applications. If a receiving LDP it SHOULD silently ignore/skip such an element and continue
speaker does not understand or does not support an application processing rest of the TLV.
specified in an application control element, it SHOULD silently
ignore/skip such an element and continue processing rest of the TLV.
5.1. Application Control Capability in an Initialization message 5.1. Application Control Capability in an Initialization message
LDP Capabilities [RFC5561] dictate that the S-bit of capability LDP Capabilities [RFC5561] framework dictates that the S-bit of
parameter in an Initialization message MUST be set to 1 and SHOULD be capability parameter in an Initialization message MUST be set to 1
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 they need 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 the
"Application Control Capability" TLV needs to be included in the "Application Control Capability" TLV needs to be included in the
Initialization message with respective application control elements Initialization message with respective application control 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
An LDP speaker that supports the "Application Control" capability
MUST interpret the capability TLV in a received Initialization MUST interpret the capability TLV in a received Initialization
message such that it disables the advertisement of the application message such that it disables the advertisement of the application
state towards the sender LSR for IPoMPLS and/or P2P PW applications state towards the capability sending LSR for IPoMPLS and/or P2P PW
if their application control element's D bit is set to 1. applications if their application control element's D bit is set to
1.
5.2. Application Control capability in a Capability message 5.2. Application Control capability in a Capability message
If the LDP peer supports "Dynamic Announcement Capability" [RFC5561], If the LDP peer supports "Dynamic Announcement Capability" [RFC5561],
then an LDP speaker may send Application Control capability in a then an LDP speaker may send Application Control 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 any An LDP speaker may decide to send this TLV towards an LDP peer if one
of its IPoMPLS and/or P2P PW signaling applications get disabled, or or more of its IPoMPLS and/or P2P PW signaling applications get
if previously disabled application gets enabled again. In this case, disabled, or if previously disabled application gets enabled again.
LDP speaker constructs the TLV with appropriate application control In this case, the LDP speaker constructs the TLV with appropriate
elements and sends the corresponding capability TLV in a Capability application control element(s) and sends the corresponding capability
message. Furthermore, the LDP speaker also withdraws/advertises TLV in a Capability message.
application(s) related state (such as address/label bindings) from/to
its peer according to the capability update.
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 receiving this TLV in an Initialization message. Additionally, the peer
LDP speaker withdraws/advertises application state from/to the withdraws/advertises application state from/to the capability sending
sending peer according to the capability update. 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
"Application Control" capability TLV, and have an established LDP "Application Control" capability TLV, and have an established LDP
session due to ICCP application in order to exchange ICCP state session to exchange ICCP state related to dual-homed devices
related to dual-homed devices connected to these LSRs. Let us assume connected to these LSRs. Let us assume that both LSRs are
that LSR1 is provisioned not to exchange any state for IPoMPLS provisioned not to exchange any state for IPoMPLS (IPv4/IPv6) and
(IPv4/IPv6) and P2P PW (FEC128/129) application with LSR2. P2P PW (FEC128/129) application.
To indicate its disinterest in these applications, the LSR1 will To indicate their disinterest in these applications, the LSRs will
include an "Application Control" capability TLV (with 4 application include an "Application Control" capability TLV (with 4 application
control elements corresponding to these 4 applications with D bit control elements corresponding to these 4 applications with D bit
set to 1 for each one) in the Initialization message. Upon receipt set to 1 for each one) in the Initialization message. Upon receipt
of this TLV in Initialization message, the LSR2 will disable of this TLV in Initialization message, the receiving LSR will
advertisement of IPv4/IPv6 bindings (addresses and labels), as well disable advertisement of IPv4/IPv6 bindings (addresses and labels),
as P2P PW FEC128/129 signaling, towards LSR1 after session as well as P2P PW FEC128/129 signaling, towards its peer after
establishment. session establishment.
The LSR1 will also disable similar state advertisement for these
applications towards LSR2 independently, irrespective of the fact
whether or not LSR2 could disable the corresponding application
state advertisement towards LSR1.
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 just to exchange label bindings for FEC 128/129. P2P PW application to exchange label bindings for FEC 128/129. Given
Since in most typical deployments, there is no need to exchange IP that there is no need to exchange IP (v4/v6) address/label bindings
(v4/v6) address/label bindings amongst the PE LSRs, let us assume amongst the PE LSRs over a PW T-LDP session in most typical
that LSR1 is provisioned to disable IPoMPLS (IPv4/IPv6)application deployments, let us assume that LSRs are provisioned to disable
on given PW session towards LSR2. IPoMPLS (IPv4/IPv6)application on given PW session.
To indicate its disinterest in IPoMPLS application over PW T-LDP To indicate their disinterest in IPoMPLS application over PW T-LDP
session, the LSR1 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. IPv4 and IPv6 label switching as described in previous section. As a
Similarly, LSR2 will behave accordingly by disabling state result, only P2P PW related state will be exchanged between these
advertisement for IPoMPLS application towards LSR1. 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 session
Assume that LSRs from previous sections were initially provisioned to Assume that LSRs from previous sections were initially provisioned to
exchange both IPoMPLS and P2P PW state over the session between them, exchange both IPoMPLS and P2P PW state over the session between them,
and also support "Dynamic Announcement" Capability [RFC5561]. Now, and also support "Dynamic Announcement" Capability [RFC5561]. Now,
assume that LSR1 is dynamically provisioned to disable IPoMPLS 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
first disable its future outbound application state towards LSR2, and send Application Control capability TLV in a Capability message
also withdraw all its previously advertised IPoMPLS state (labels and towards LSR2 with application control elements defined for IPv4 and
addresses) by sending a single Prefix FEC Typed Wildcard Label IPv6 label switching with D bit set to 1. Upon receipt of this TLV,
Withdraw message [RFC5918], and an Address Withdraw message LSR2 will disable IPoMPLS application(s) towards LSR1 and withdraw
respectively towards LSR2. LSR1 will also send Application Control all previous IP label/address state from LSR1. To withdraw label and
capability TLV in a Capability message towards LSR2 with application address bindings from its peer, LSR2 MAY use a single Prefix FEC
control elements defined for IPv4 and IPv6 label switching with D bit Typed Wildcard Label Withdraw message [RFC5918] and an Address
set to 1. Upon receipt of this TLV, LSR2 will also disable IPoMPLS Withdraw message respectively.
applications towards LSR1 and withdraw all previous IP label/address
state using the same mechanics as described earlier for LSR1. This This dynamic disability of IPoMPLS application does not impact L2VPN
dynamic disability of IPoMPLS application will not impact L2VPN P2P P2P PW application on the given session, and both LSRs should
PW application on the given session, and both LSRs should continue to continue to exchange PW Signaling application related state.
exchange PW Signaling application related state.
6.4. Disabling unwanted state advertisement by an IP dual-stack LSR 6.4. Disabling unwanted 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 (label/address bindings) towards peer LSR1 corresponding to IPv6
label switching application once a session is established mainly for label switching application once a session is established mainly for
exchanging state for IPv4. The similar scenario also applies when exchanging state for IPv4. The similar scenario also applies when
advertising IPv4 label switching state on a session meant for IPv6. advertising IPv4 label switching state on a session meant for IPv6.
The Application Control capability and its procedures defined in this The Application Control capability and its procedures defined in this
document can help to avoid such unnecessary state advertisement. document can help to avoid such unnecessary state advertisement.
skipping to change at page 10, line 42 skipping to change at page 10, line 48
avoid the unnecessary state advertisement in the above scenario. 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 following a new capability parameter TLV and The document defines a new capability parameter TLV and requests
requests following LDP TLV code point assignment by IANA from LDP following LDP TLV code point assignment by IANA from LDP "TLV Type
"TLV Type Name Space" registry: Name Space" registry:
o "Application Control Capability" TLV (requested codepoint: 0x50C) o "Application Control Capability" TLV (requested codepoint: 0x50C)
9. Conclusions 9. References
The document proposed a solution using LDP Capabilities [RFC5561]
mechanics to disable unnecessary state exchange, if/as desired,
between LDP peers for currently non-negotiated IP/PW LDP
applications.
10. References
10.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 Specification",
RFC 5036, September 2007. 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.
10.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, October 2011. 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-09.txt, Work in Progress,
July 2012. July 2012.
[RFC6388] I. Minei, I. Wijnand, K. Kompella, and B. Thomas, "LDP [RFC6388] I. Minei, I. Wijnand, 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- [LDPv6] R. Asati, et al., "Updates to LDP for IPv6", draft-ietf-
mpls-ldp-ipv6-07.txt, Work in Progress, June 2012. 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.
11. 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 and
comments. comments.
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.,
 End of changes. 57 change blocks. 
207 lines changed or deleted 192 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/