draft-ietf-mpls-ldp-ip-pw-capability-00.txt   draft-ietf-mpls-ldp-ip-pw-capability-01.txt 
MPLS Working Group Kamran Raza
Network Working Group Kamran Raza Internet Draft Sami Boutros
Internet Draft Cisco Systems
Intended status: Standards Track Intended status: Standards Track
Expires: December 16, 2011 Sami Boutros Expires: August 14, 2012 Cisco Systems
Cisco Systems
June 17, 2011 February 15, 2012
LDP IP and PW Capability LDP IP and PW Capability
draft-ietf-mpls-ldp-ip-pw-capability-00.txt draft-ietf-mpls-ldp-ip-pw-capability-01.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 36 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 December 16, 2011. This Internet-Draft will expire on August 14, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 the include Simplified BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described Trust Legal Provisions and are provided without warranty as described
in the Simplified BSD License. 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/PW signaling. When an LDP session comes IP label switching and L2VPN/PW signaling. When an LDP session comes
up, an LDP speaker may unnecessarily advertise its local state for up, an LDP speaker may unnecessarily advertise its local state for
such LDP applications even when the peer session may be established such LDP applications even when the peer session may be established
for some other applications like ICCP. This document proposes a for some other applications like ICCP. This document proposes a
solution by which an LDP speaker announces its "incapability" or solution by which an LDP speaker announces its disinterest or non-
disability or non-support for IP label switching or L2VPN/PW support for IP label switching or L2VPN/PW application, hence
application, hence disabling corresponding application state exchange disabling corresponding application state exchange over the
over the established LDP session. established LDP session.
Table of Contents Table of Contents
1. Introduction 3 1. Introduction ................................................... 3
2. Conventions used in this document 3 2. Conventions used in this document .............................. 4
3. Non-negotiated LDP applications 4 3. Non-negotiated LDP applications ................................ 4
3.1. Application Control Capabilities 4 4. Application Control Capabilities ............................... 5
3.1.1. IP Label Switching Capability TLV 4 4.1. IP Label Switching Capability TLV ......................... 5
3.1.2. PW Signaling Capability TLV 5 4.2. PW Signaling Capability TLV ............................... 6
3.2. Procedures for Application Control Capabilities in an 5. Capabilities Procedures ....................................... 7
Initialization message 6 5.1. Application Control Capabilities in an Initialization msg . 7
3.3. Procedures for Application Control capabilities in a 5.2. Application Control capabilities in a Capability msg ...... 8
Capability message 7 6. Operational Examples ........................................... 8
4. Operational Examples 8 6.1. Disabling IP/PW label applications on an ICCP session ..... 8
4.1. Disabling IP/PW label applications on an ICCP session 8 6.2. Disabling IP Label Switching app. on a L2VPN/PW session ... 9
4.2. Disabling IP Label Switching application on a PW session 8 6.3. Disabling IP app. dynamically on an estab. IP/PW session .. 9
4.3. Disabling IP application dynamically on an established 7. Security Considerations ....................................... 10
IP/PW session 9 8. IANA Considerations ........................................... 10
5. Security Considerations 9 9. Conclusions ................................................... 10
6. IANA Considerations 9 10. References ................................................... 10
7. Conclusions 10 10.1. Normative References .................................... 10
8. References 10 10.2. Informative References .................................. 11
8.1. Normative References 10 11. Acknowledgments .............................................. 11
8.2. Informative References 10
9. Acknowledgments 10
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. This mechanism capabilities for a given feature amongst peer LSRs. This mechanism
insures that no unnecessary state is exchanged between peer LSRs insures that no unnecessary state is exchanged between peer LSRs
unless corresponding feature capability is successfully negotiated unless corresponding feature capability is successfully negotiated
between peers. between peers.
While new features and applications, such as Typed Wildcard FEC While new features and applications, such as Typed Wildcard FEC
[RFC5918], Inter-Chassis Communication Protocol [ICCP], mLDP [RFC5918], Inter-Chassis Communication Protocol [ICCP], and mLDP
[MLDP], make use of LDP capabilities framework for their feature [RFC6388] make use of LDP capabilities framework for their feature
negotiation, the earlier LDP features and applications like IP label negotiation, the earlier LDP features and applications like IP label
switching and L2VPN/PW signaling [RFC4447] may cause unnecessary switching and L2VPN/PW signaling [RFC4447] [RFC4762] may cause
state exchange between LDP peers even when the given application is unnecessary state exchange between LDP peers even when the given
not enabled on one of the LDP speakers participating in a given application is not enabled on one of the LDP speakers participating
session. For example, when bringing up and using an LDP peer session in a given session.
with a remote PE LSR for purely ICCP signaling purposes, the LDP
speaker may unnecessarily advertise labels for IP (unicast) prefixes
to this ICCP related LDP peer as per its default behavior. To avoid
this unnecessary state advertisement and exchange, currently customers
are typically required to configure/define some sort of LDP state
(label) filtering policies on the box, which introduces operational
overhead and complexity.
This document proposes a solution by which an LDP speaker may announce For example, when bringing up and using an LDP peer session with a
its "incapability" (or disability) to its peer for IP Label Switching remote PE LSR for purely ICCP signaling purposes, the LDP speaker may
and/or L2VPN/PW Signaling application at session establishment time. unnecessarily advertise labels for IP (unicast) prefixes to this ICCP
This helps avoiding unnecessary state exchange for such feature related LDP peer as per its default behavior.
applications. The proposal also state the mechanics to enable
previously disabled application later during the session lifetime. Another example of unnecessary state advertisement can be cited when
The document introduces two new LDP Capabilities for IP label LDP is used in (IP) dual-stack environment. For instance, an LSR that
switching and L2VPN/PW applications to implement this proposal. is locally enabled for both IPv4 and IPv6 label switching may
advertise address/label bindings for both IPv4 and IPv6 address
families towards an IPv4-only LDP peer (i.e. a peer which is enabled
for IPv4 LDP only and with which hello adjacencies and transport
connection is formed using IPv4 only). In this case, the
advertisement of IPv6 addresses and labels to the peer is
unnecessary, as well as wasteful from LSR memory/CPU and network
resource consumption point of view.
To avoid this unnecessary state advertisement and exchange, currently
customers are typically required to configure/define some sort of LDP
state (e.g. label) filtering policies on the box, which introduces
operational overhead and complexity.
This document proposes an LDP Capabilities [RFC5561] based solution
by which an LDP speaker may announce its disinterest (or non-
support/disability) to its peer for IP Label Switching and/or
L2VPN/PW Signaling application at session establishment time. This
helps avoiding unnecessary state exchange for such feature
applications. The proposal also states the mechanics to enable a
previously disabled application to be enabled later during the
session lifetime. The document introduces two new LDP Capabilities
for IP label switching and L2VPN/PW applications 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 "IP unicast", unless The term "IP" in this document refers to "IP unicast", and refers to
otherwise explicitly stated. both IPv4 and IPv6 address families.
3. Non-negotiated LDP applications 3. Non-negotiated LDP applications
For the applications that existed before LDP Capabilities [RFC5561] For the applications that existed before LDP Capabilities [RFC5561]
mechanics were defined, LDP speaker may advertise relevant mechanics were defined, LDP speaker may advertise relevant
application state to its peers after session establishment without application state to its peers after session establishment without
waiting for any capabilities exchange and negotiation. waiting for any capabilities exchange and negotiation.
Currently, the most important non-negotiated applications include: Amongst non-negotiated features and applications, the two most
important non-negotiated applications are:
o IP [v4 and v6] label switching o IP [v4 and v6] label switching
o L2VPN/PW signaling o L2VPN/PW signaling
To disable unnecessary state exchange for such LDP applications, two To disable unnecessary state exchange for such LDP applications, two
new capabilities are being introduced in this document. These new new capabilities are being introduced in this document. These new
capabilities allow an LDP speaker to notify its LDP peer at the capabilities control application state advertisement and allow an LDP
session establishment time when one or more LDP "Non-negotiated speaker to notify its LDP peer at the session establishment time when
applications" are not required/configured on the sender side. Upon one or more of these "Non-negotiated" LDP applications are not
receipt of such capability, if supported, the receiving LDP speaker required/configured on the sender side. Upon receipt of such
MUST disable the advertisement of application state towards the capability, if supported, the receiving LDP speaker MUST disable the
advertisement of any state related to the application towards the
sender. These capabilities can also be sent later in a Capability sender. These capabilities can also be sent later in a Capability
message to either disable these applications, or to enable message to either disable these applications, or to enable previously
previously disabled applications. disabled applications.
3.1. Application Control Capabilities 4. Application Control Capabilities
To control advertisement of state related to non-negotiated LDP To control advertisement of state related to non-negotiated LDP
applications, namely IP Label switching and L2VPN/PW signaling, two applications, namely IP Label switching and L2VPN/PW signaling, two
new capability TLVs are defined as described in the following new capability TLVs are defined as described in the following sub-
subsections. sections.
3.1.1. IP Label Switching Capability TLV 4.1. IP Label Switching Capability TLV
The IP Label Switching capability is a new Capability Parameter The "IP Label Switching Capability" is a new Capability Parameter
defined with the following format: defined with the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| IP Label Sw. Cap (IANA) | Length (2) | |1|0| IP Label Sw. Cap. (IANA) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved | AF Bitmap | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved | AF Bitmap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value of the U-bit for the IP capability parameter TLV MUST be The value of the U-bit for the IP capability parameter TLV MUST be
set to 1 so that a receiver MUST silently ignore this TLV if unknown set to 1 so that a receiver MUST silently ignore this TLV if unknown
to it, and continue processing the rest of the message. Once to it, and continue processing the rest of the message. Once
advertised, this capability cannot be withdrawn and hence the S-bit advertised, this capability cannot be withdrawn and hence the S-bit
must always be set to 1 both in Initialization message and Capability must always be set to 1 both in Initialization message and Capability
message. The capability data associated with this TLV is 1 octet long message. The capability data associated with this TLV is 1 octet long
"Address Family Bitmap", and hence the TLV length MUST be set to 2. "Address Family Bitmap" and 2 octects "Reserved" field for future
use, and hence the TLV length MUST be set to 4.
The Capability data "Address Family Bitmap" is defined as: The Capability data "Address Family Bitmap" is defined as follows:
7 6 5 4 3 2 1 0 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| AF bitmap | | AF bitmap |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Where: Where:
bit0: IPv4 label switching application bit0: IPv4 label switching application
bit1: IPv6 label switching application bit1: IPv6 label switching application
bit2-7: Unused. MBZ on transmit and ignored on receipt.
bit2-7: Reserved.
A bit in the bitmap is set to 0 or 1 to disable or enable A bit in the bitmap is set to 0 or 1 to disable or enable
respectively a corresponding IP application. respectively a corresponding IP application.
As described earlier, "IP Label Switching" Capability Parameter TLV The "Reserved" field is reserved for future use and MBZ on transmit
and ignored on receipt.
As described earlier, "IP Label Switching Capability" Parameter TLV
MAY be included by an LDP speaker in an Initialization message to MAY be included by an LDP speaker in an Initialization message to
signal to its peer LSR that state exchange for IPv4 and/or IPv6 signal to its peer LSR that state exchange for IPv4 and/or IPv6
application(s) need to be disabled on a given peer session. This TLV application(s) need to be disabled on a given peer session. This TLV
can also be sent later in a Capability message to selectively enable can also be sent later in a Capability message to selectively enable
or disable IPv4/v6 label switching application(s). or disable IPv4/v6 label switching application(s).
3.1.2. PW Signaling Capability TLV 4.2. PW Signaling Capability TLV
The "PW Signaling" capability is a new Capability Parameter defined The "PW Signaling Capability" is a new Capability Parameter defined
with the following format: with the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PW Sig. Cap (IANA) | Length (2) | |1|0| PW Signaling Cap. (IANA) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved |E| Reserved | |1| Reserved |E| Unused | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value of the U-bit for the PW capability parameter TLV MUST be The value of the U-bit for the PW capability parameter TLV MUST be
set to 1 so that a receiver MUST silently ignore this TLV if unknown set to 1 so that a receiver MUST silently ignore this TLV if unknown
to it, and continue processing the rest of the message. Once to it, and continue processing the rest of the message. Once
advertised, this capability cannot be withdrawn and hence the S-bit advertised, this capability cannot be withdrawn and hence the S-bit
MUST always be set to 1 in Initialization message or Capability MUST always be set to 1 in Initialization message or Capability
message. The capability data associated with this TLV is 1 octet long message. The capability data associated with this TLV is 3 octets
and hence the TLV length MUST be set to 2. long and hence the TLV length MUST be set to 4.
The capability data is defined as following byte: The capability data is defined as follows:
7 6 5 4 3 2 1 0 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|E| Reserved | |E| Unused |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Where E-bit (Enable bit) is used to control PW signaling application Where:
by setting it to 0 and 1 to disable and enable the application
respectively. E-bit: Enable bit. Used to control PW signaling application by
setting it to 0 and 1 to disable and enable the application
respectively.
Unused: Unused bits. MBZ on transmit and ignored on receipt.
The "Reserved" field is reserved for future use and MBZ on transmit
and ignored on receipt.
As described earlier, PW Signaling Capability Parameter TLV MAY be As described earlier, PW Signaling Capability Parameter 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 PW application need to be its peer LSR that state exchange for PW application need to be
disabled on given peer session. This TLV can also be sent later in a disabled on given peer session. This TLV can also be sent later in a
Capability message to enable/disable the PW Signaling application. Capability message to enable/disable the PW Signaling application.
3.2. Procedures for Application Control Capabilities in an 5. Capabilities Procedures
Initialization message
5.1. Application Control Capabilities in an Initialization message
LDP Capabilities [RFC5561] dictate that the S-bit of capability LDP Capabilities [RFC5561] dictate that the S-bit of capability
parameter in an Initialization message MUST be set to 1 and SHOULD be parameter in an Initialization message MUST be set to 1 and SHOULD be
ignored on receipt. 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 IP and/or L2VPN/PW default policy) if they need to disable IP and/or L2VPN/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
IP and/or PW application capability TLVs need to be included in the IP and/or PW application capability TLVs need to be included in the
Initialization message with respective application bits set to 0 to Initialization message with respective application bits set to 0 to
indicate application disable, where the application bit refers to a indicate application disable, where the application bit refers to a
bit in "Address Family Bitmap" of the "IP Label Switching" Capability bit in "Address Family Bitmap" of the "IP Label Switching" Capability
or E-bit in "PW Signaling" Capability. or E-bit in the "PW Signaling" Capability.
An LDP speaker that supports the "IP Label Switching" and/or "PW An LDP speaker that supports the "IP Label Switching" and/or "PW
Signaling" capability MUST interpret those TLVs in a received Signaling" capability MUST interpret those TLVs in a received
Initialization message such that it disables the advertisement of the Initialization message such that it disables the advertisement of the
application state towards the sender LSR for IP (v4 and/or v6) and/or application state towards the sender LSR for IP (v4 and/or v6) and/or
L2VPN/PW applications if their application control bits are set to 0. L2VPN/PW applications if their application control bits are set to 0.
If a receiving LDP speaker does not understand the capability TLVs, If a receiving LDP speaker does not understand the capability TLVs,
then it MUST respond to the sender with "Unsupported TLV" then it MUST respond to the sender with "Unsupported TLV"
Notification as described in LDP Capabilities [RFC5561]. Upon receipt Notification as described in LDP Capabilities [RFC5561]. Upon receipt
of such Notification, the sender MAY still continue to block/disable of such Notification, the sender MAY still continue to block/disable
its outbound state advertisement towards the peer for the requested its outbound state advertisement towards the peer for the requested
disabled applications. disabled applications.
Once this capability has been sent by sender LSR and received and Once this capability has been sent by sender LSR and received and
understood by the receiver LSR, then both these LSRs MUST NOT understood by the receiver LSR, then both these LSRs MUST NOT
exchange any state related to the disabled applications until and exchange any state related to the disabled applications until and
skipping to change at page 7, line 21 skipping to change at page 7, line 52
disabled applications. disabled applications.
Once this capability has been sent by sender LSR and received and Once this capability has been sent by sender LSR and received and
understood by the receiver LSR, then both these LSRs MUST NOT understood by the receiver LSR, then both these LSRs MUST NOT
exchange any state related to the disabled applications until and exchange any state related to the disabled applications until and
unless these applications are explicitly enabled again (e.g. via the unless these applications are explicitly enabled again (e.g. via the
same Capability TLV sent in a Capability message with corresponding same Capability TLV sent in a Capability message with corresponding
application control bit set to 1). application control bit set to 1).
"IP Label Switching" and "PW Signaling" capability TLVs are "IP Label Switching" and "PW Signaling" capability TLVs are
unilateral/uni-directional in nature. This means that the receiving unilateral and uni-directional in nature -- i.e. a receiving LSR may
LSR may not need to send a similar capability TLV in an not need to send a similar capability TLV in an Initialization or
Initialization or Capability message towards the sender. This Capability message towards the sender. This unilateral behavior also
unilateral behavior also conforms to the procedures defined in the conforms to the procedures defined in the Section 6 of LDP
Section 6 of LDP Capabilities [RFC5561]. Capabilities [RFC5561].
3.3. Procedures for Application Control capabilities in a Capability 5.2. Application Control capabilities in a Capability message
message
If the LDP peer supports "Dynamic Announcement Capability" [RFC5561], If the LDP peer supports "Dynamic Announcement Capability" [RFC5561],
then an LDP speaker can send IP Label Switching and/or PW Signaling then an LDP speaker can send IP Label Switching and/or PW Signaling
capability in a Capability message. Once advertised, these capability in a Capability message. 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 any
of its IP and/or L2VPN/PW signaling applications gets disabled, or if of its IP and/or L2VPN/PW signaling applications gets disabled, or if
previously disabled IP and/or L2VPN/PW applications gets enabled previously disabled IP and/or L2VPN/PW application gets enabled
again. In this case, LDP speaker constructs the TLVs with appropriate again. In this case, LDP speaker constructs the TLVs with appropriate
application control bitmap and sends the corresponding capability application control bitmap and sends the corresponding capability
TLVs in a Capability message. Furthermore, the LDP speaker also TLVs in a Capability message. Furthermore, the LDP speaker also
withdraws application(s) related advertised state (such as label withdraws application(s) related advertised state (such as label
bindings) from its peer. bindings) from its peer.
Upon receipt of those TLVs in a Capability message, the receiving LDP Upon receipt of those TLVs 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
those TLVs in an Initialization message. Additionally, the receiving those TLVs in an Initialization message. Additionally, the receiving
LDP speaker withdraws the application(s) related advertised state LDP speaker withdraws the application(s) related advertised state
(such as label bindings) from the sending LDP speaker. If the (such as label bindings) from the sending LDP speaker. If the
receiving LDP speaker does not understand or support either Dynamic receiving LDP speaker does not understand or support either Dynamic
Announcement capability or received Application Control capability Announcement capability or received Application Control capability
TLV ("IP Label Switching" or "PW Signaling"), it MUST respond with TLV ("IP Label Switching" or "PW Signaling"), it MUST respond with
"Unsupported Capability" notification to the sender of the Capability "Unsupported Capability" notification to the sender of the Capability
message. message.
4. Operational Examples 6. Operational Examples
4.1. Disabling IP/PW label applications on an ICCP session 6.1. Disabling IP/PW label applications on an ICCP session
Consider two PE routers, LSR1 and LSR2, which understand/support "IP Consider two PE routers, LSR1 and LSR2, which understand/support "IP
Label Switching" and "PW Signaling" capability TLVs. These LSR have Label Switching" and "PW Signaling" capability TLVs. These LSR have
an established LDP session due to ICCP application in order to an established LDP session due to ICCP application in order to
exchange ICCP state related to dual-homed devices connected to these exchange ICCP state related to dual-homed devices connected to these
LSRs. Let us assume that LSR1 is provisioned not to exchange any LSRs. Let us assume that LSR1 is provisioned not to exchange any
label bindings related to IP (v4/v6) prefixes and PW layer2 FEC label bindings related to IP (v4/v6) prefixes and PW layer2 FEC
(FEC128/129) with LSR2. (FEC128/129) with LSR2.
To indicate its "disability" for the IP/PW applications, the LSR1 To indicate its "disability" for the IP/PW applications, the LSR1
skipping to change at page 8, line 34 skipping to change at page 9, line 15
capability TLV (with E-bit set to 0) in the Initialization message. capability TLV (with E-bit set to 0) in the Initialization message.
Upon receipt of those TLVs in Initialization message, the LSR2 will Upon receipt of those TLVs in Initialization message, the LSR2 will
disable any IP/PW address/label binding state advertisement towards disable any IP/PW address/label binding state advertisement towards
LSR1 after session establishment. LSR1 after session establishment.
The LSR1 will also disable any IP/PW address/label binding state The LSR1 will also disable any IP/PW address/label binding state
towards LSR2, irrespective of the fact whether or not LSR2 could towards LSR2, irrespective of the fact whether or not LSR2 could
disable the corresponding application state advertisement towards disable the corresponding application state advertisement towards
LSR1. LSR1.
4.2. Disabling IP Label Switching application on a L2VPN/PW session 6.2. Disabling IP Label Switching application on a L2VPN/PW session
Now, consider LSR1 and LSR2 have an established session due to Now, consider LSR1 and LSR2 have an established session due to
L2VPN/PW application just to exchange PW (FEC128/129) label L2VPN/PW application just to exchange PW (FEC128/129) label bindings
bindings for VPWS/VPLS services amongst them. Since in most typical for VPWS/VPLS services amongst them. Since in most typical
deployments, there is no need to exchange IP (v4/v6) address/label deployments, there is no need to exchange IP (v4/v6) address/label
bindings amongst the PE LSRs, let us assume that LSR1 is provisioned bindings amongst the PE LSRs, let us assume that LSR1 is provisioned
to disable IP (v4/v6) application on given PW session towards LSR2. to disable IP (v4/v6) application on given PW session towards LSR2.
To indicate its disability for IP application, the LSR1 will include To indicate its disinterest in IP label switching, the LSR1 will
the "IP Label Switching" capability TLV in the Initialization include the "IP Label Switching" capability TLV in the
message with bit0-1 (IPv4, IPv6) in "Address Family Bitmap" set to Initialization message with bit0-1 (IPv4, IPv6) in "Address Family
zero. Upon receipt of this TLV in Initialization message, the LSR2 Bitmap" set to zero. Upon receipt of this TLV in Initialization
will disable any IP address/label binding state advertisement message, the LSR2 will disable any IP address/label binding state
towards LSR1. advertisement towards LSR1.
The LSR1 will also disable any IP address/label binding state The LSR1 will also disable any IP address/label binding state
towards LSR2, irrespective of the fact whether or not LSR2 could towards LSR2, irrespective of the fact whether or not LSR2 could
disable the corresponding IP application state advertisement towards disable the corresponding IP application state advertisement towards
LSR1. LSR1.
4.3. Disabling IP application dynamically on an established IP/PW 6.3. Disabling IP 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 IP and PW state over the session between them, and also exchange both IP and PW state over the session between them, and also
support "Dynamic Announcement" capability [RFC5561]. Now, assume that support "Dynamic Announcement Capability" [RFC5561]. Now, assume that
LSR1 is dynamically provisioned to disable IP label switching with LSR1 is dynamically provisioned to disable IP label switching with
LSR2. In this case, LSR1 will first withdraw all its IP label state LSR2. In this case, LSR1 will first withdraw all its IP label state
by sending a single Label Withdraw message with IP Prefix Typed by sending a single Label Withdraw message with IP "Prefix Typed
Wildcard FEC using the mechanics described in [RFC5918], and Address Wildcard FEC" using the mechanics described in [RFC5918], and Address
Withdraw message to withdraw its addresses. LSR1 will also send IP Withdraw message to withdraw its addresses. LSR1 will also send IP
Label Switching capability TLV in Capability message towards LSR2 Label Switching capability TLV in Capability message towards LSR2
with bit0-1 (IPv4, IPv6) in "Address Family Bitmap" set to zero. Upon with bit0-1 (IPv4, IPv6) in "Address Family Bitmap" set to zero. Upon
receipt of this TLV, LSR2 will also disable IP label switching receipt of this TLV, LSR2 will also disable IP label switching
towards LSR1 and withdraw all previous IP application label/address towards LSR1 and withdraw all previous IP label/address state using
state using the same mechanics as described earlier for LSR1. The the same mechanics as described earlier for LSR1. The disability of
disability of IP label switching dynamically should not impact IP label switching dynamically should not impact L2VPN/PW application
L2VPN/PW application on given session, and both LSRs should continue on given session, and both LSRs should continue to exchange PW
to exchange PW Signaling application related state. Signaling application related state.
5. 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].
6. IANA Considerations 8. IANA Considerations
The document introduces following two new capability parameter TLVs The document defines following two new capability parameter TLVs and
and requests following LDP TLV code point assignment by IANA: requests following LDP TLV code point assignment by IANA from LDP
"TLV Type Name Space" registry:
o "IP Label Switching" Capability TLV (requested codepoint: 0x50C) o "IP Label Switching Capability" TLV (requested codepoint: 0x50C)
o "PW Signaling" Capability TLV (requested codepoint: 0x50D) o "PW Signaling Capability" TLV (requested codepoint: 0x50D)
7. Conclusions 9. Conclusions
The document proposed a solution using LDP Capabilities [RFC5561] The document proposed a solution using LDP Capabilities [RFC5561]
mechanics to disable unnecessary state exchange, if/as desired, mechanics to disable unnecessary state exchange, if/as desired,
between LDP peers for currently non-negotiated IP/PW applications. between LDP peers for currently non-negotiated IP/PW LDP
applications.
8. References
8.1. Normative References
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and Le 10. References
Roux, JL., "LDP Capabilities", RFC 5561, July 2009.
[RFC5918] Asati, R., Minei, I., and Thomas, B. "Label Distribution 10.1. Normative References
Protocol Typed Wildcard FEC", RFC 5918, August 2010.
[ICCP] Martini, L., Salam, S., and Matsushima, S., "Inter-Chassis [RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP Specification",
Communication Protocol for L2VPN PE Redundancy", draft- RFC 5036, September 2007.
ietf-pwe3-iccp-04.txt, Work in Progress, October 2010.
[MLDP] Minei, I., Kompella, K., Wijnands, I., and Thomas, B., "LDP [RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, and JL. Le
Extensions for Point-to-Multipoint and Multipoint-to- Roux, "LDP Capabilities", RFC 5561, July 2009.
Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp
-10.txt, Work in Progress, July 2010.
[RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, 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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC4762] M. Lasserre, and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007.
[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.
8.2. Informative References 10.2. Informative References
[RFC5036] Andersson, L., Menei, I., and Thomas, B., Editors, "LDP [RFC5918] R. Asati, I. Minei, and B. Thomas, "Label Distribution
Specification", RFC 5036, September 2007. Protocol Typed Wildcard FEC", RFC 5918, August 2010.
[RFC5920] Fang, L. et al., "Security Framework for MPLS and GMPLS [ICCP] L. Martini, S. Salam, A. Sajassi, and S. Matsushima,
"Inter-Chassis Communication Protocol for L2VPN PE
Redundancy", draft-ietf-pwe3-iccp-07.txt, Work in Progress,
February 2012.
[RFC6388] I. Minei, I. Wijnand, K. Kompella, and B. Thomas, "LDP
Extensions for P2MP and MP2MP LSPs", RFC 6388, November
2011.
[RFC5920] L. Fang, et al., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
9. Acknowledgments 11. 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.,
2000 Innovation Drive, 2000 Innovation Drive,
Kanata, ON K2K-3E8, Canada. Ottawa, ON K2K-3E8, Canada.
E-mail: skraza@cisco.com E-mail: skraza@cisco.com
Sami Boutros Sami Boutros
Cisco Systems, Inc. Cisco Systems, Inc.
3750 Cisco Way, 3750 Cisco Way,
San Jose, CA 95134, USA. San Jose, CA 95134, USA.
E-mail: sboutros@cisco.com E-mail: sboutros@cisco.com
 End of changes. 70 change blocks. 
157 lines changed or deleted 187 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/