draft-ietf-mpls-ldp-ip-pw-capability-01.txt   draft-ietf-mpls-ldp-ip-pw-capability-02.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 14, 2012 Cisco Systems Expires: February 17, 2013 Cisco Systems
February 15, 2012 August 18, 2012
LDP IP and PW Capability Disabling IPoMPLS and P2P PW LDP Applications
draft-ietf-mpls-ldp-ip-pw-capability-01.txt draft-ietf-mpls-ldp-ip-pw-capability-02.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 14, 2012. This Internet-Draft will expire on February 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
Trust Legal Provisions and are provided without warranty as described the Trust Legal Provisions and are provided without warranty as
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/PW signaling. When an LDP session comes IP label switching and L2VPN P2P PW signaling. When an LDP session
up, an LDP speaker may unnecessarily advertise its local state for comes up, an LDP speaker may unnecessarily advertise its local state
such LDP applications even when the peer session may be established for such LDP applications even when the peer session may be
for some other applications like ICCP. This document proposes a established for some other applications like ICCP. This document
solution by which an LDP speaker announces its disinterest or non- proposes a solution by which an LDP speaker announces its disinterest
support for IP label switching or L2VPN/PW application, hence in such non-negotiated application. This, in turn, disables the
disabling corresponding application state exchange over the advertisement of corresponding application state, which would have
established LDP session. 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. Application Control Capabilities ............................... 5 4. Controlling State Exchange for Non-negotiated LDP Applications 5
4.1. IP Label Switching Capability TLV ......................... 5 4.1. Application Control Capability 5
4.2. PW Signaling Capability TLV ............................... 6 5. Capabilities Procedures 7
5. Capabilities Procedures ....................................... 7 5.1. Application Control Capability in an Initialization message 7
5.1. Application Control Capabilities in an Initialization msg . 7 5.2. Application Control capability in a Capability message 8
5.2. Application Control capabilities in a Capability msg ...... 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 IP/PW label applications on an ICCP session ..... 8 6.2. Disabling IPoMPLS application on a L2VPN/PW T-LDP session 9
6.2. Disabling IP Label Switching app. on a L2VPN/PW session ... 9 6.3. Disabling IPoMPLS appl. dynamically on an IP/PW session 9
6.3. Disabling IP app. dynamically on an estab. IP/PW session .. 9 6.4. Disabling unwanted state advert. by an IP dual-stack LSR 10
7. Security Considerations ....................................... 10 7. Security Considerations 10
8. IANA Considerations ........................................... 10 8. IANA Considerations 10
9. Conclusions ................................................... 10 9. Conclusions 11
10. References ................................................... 10 10. References 11
10.1. Normative References .................................... 10 10.1. Normative References 11
10.2. Informative References .................................. 11 10.2. Informative References 11
11. Acknowledgments .............................................. 11 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. This mechanism capabilities for a given feature amongst peer LSRs. The capability
insures that no unnecessary state is exchanged between peer LSRs mechanism insures that no unnecessary state is exchanged between peer
unless corresponding feature capability is successfully negotiated LSRs unless corresponding feature capability is successfully
between peers. negotiated between peers.
While new 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], and mLDP [RFC5918], Inter-Chassis Communication Protocol [ICCP], mLDP
[RFC6388] make use of LDP capabilities framework for their feature [RFC6388], and P2MP PW [P2MP-PW] make use of LDP capabilities
negotiation, the earlier LDP features and applications like IP label framework for their feature negotiation, the earlier LDP features and
switching and L2VPN/PW signaling [RFC4447] [RFC4762] may cause applications like IP label switching and L2VPN P2P PW signaling
unnecessary state exchange between LDP peers even when the given [RFC4447] [RFC4762] may cause unnecessary state exchange between LDP
application is not enabled on one of the LDP speakers participating peers even when the given application is not enabled on one of the
in a given session. LDP speakers participating in a given session.
For example, when bringing up and using an LDP peer session with a For example, when bringing up and using an LDP peer session with a
remote PE LSR for purely ICCP signaling purposes, the 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 (IP) dual-stack environment. For instance, an LSR that LDP is used in an IP dual-stack environment. For instance, an LSR
is locally enabled for both IPv4 and IPv6 label switching may that is locally enabled for both IPv4 and IPv6 label switching may
advertise address/label bindings for both IPv4 and IPv6 address advertise address/label bindings for both IPv4 and IPv6 address
families towards an IPv4-only LDP peer (i.e. a peer which is enabled families towards an LDP peer that is interested in IPv4 only. In this
for IPv4 LDP only and with which hello adjacencies and transport case, the advertisement of IPv6 addresses and IPv4 prefix labels to
connection is formed using IPv4 only). In this case, the the peer is unnecessary, as well as wasteful from LSR memory/CPU and
advertisement of IPv6 addresses and labels to the peer is network resource consumption point of view.
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 To avoid this unnecessary state advertisement and exchange, currently
customers are typically required to configure/define some sort of LDP an operator is typically required to configure and define some sort
state (e.g. label) filtering policies on the box, which introduces of filtering policies on the box for LDP state exchange, which
operational overhead and complexity. 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 its disinterest (or non-
support/disability) to its peer for IP Label Switching and/or support/disability) to its peer for IP Label Switching and/or L2VPN
L2VPN/PW Signaling application at session establishment time. This P2P PW Signaling application at the time of session establishment.
helps avoiding unnecessary state exchange for such feature This helps avoiding unnecessary state exchange for such feature
applications. The proposal also states the mechanics to enable a applications. The proposal also states the mechanics to disable or
previously disabled application to be enabled later during the enable an application dynamically during the session lifetime. The
session lifetime. The document introduces two new LDP Capabilities document introduces a new LDP capability to implement this proposal.
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", and refers to The term "IP" in this document refers to both "IPv4 unicast" and
both IPv4 and IPv6 address families. "IPv6 unicast" address families.
This document uses shorthand terms "IPoMPLS" to refer to IP Label
switching application, and "P2P PW" to refer to L2VPN PW signaling
for FEC 128 and FEC 129 P2P PWs.
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 procedures were defined, an LDP speaker typically advertises 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. These LDP
applications are:
Amongst non-negotiated features and applications, the two most
important non-negotiated applications are:
o IP [v4 and v6] label switching o IPv4/IPv6 label switching ("IPoMPLS")
o L2VPN/PW signaling o L2VPN P2P PW signaling ("P2P PW")
To disable unnecessary state exchange for such LDP applications, two To disable unnecessary state exchange for such LDP applications, a
new capabilities are being introduced in this document. These new new capability is being introduced in this document. This new
capabilities control application state advertisement and allow an LDP capability controls the advertisement of application state and
speaker to notify its LDP peer at the session establishment time when enables an LDP speaker to notify its LDP peer its disinterest in one
one or more of these "Non-negotiated" LDP applications are not or more of these "Non-negotiated" LDP applications at the time of
required/configured on the sender side. Upon receipt of such session establishment. Upon receipt of such capability, the receiving
capability, if supported, the receiving LDP speaker MUST disable the LDP speaker, if supporting the capability, MUST disable the
advertisement of any state related to the application towards the advertisement of any state related to the application towards the
sender. These capabilities can also be sent later in a Capability sender. Moreover, the sender LSR SHOULD also disable the
message to either disable these applications, or to enable previously advertisement of corresponding application state towards the peer.
disabled applications. This new capability can also be sent later in a Capability message to
either disable these applications, or to enable previously disabled
applications dynamically.
4. Application Control Capabilities 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 IP Label switching and L2VPN/PW signaling, two applications, namely IPoMPLS and P2P PW signaling, a new capability
new capability TLVs are defined as described in the following sub- TLVs is defined as follows.
sections.
4.1. IP Label Switching Capability TLV 4.1. Application Control Capability
The "IP Label Switching Capability" is a new Capability Parameter The "Application Control Capability" is a new Capability Parameter
defined with the following format: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| IP Label Sw. Cap. (IANA) | Length (4) | |U|F| App Control Cap. (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved | AF Bitmap | Reserved | |S| Reserved | |
+-+-+-+-+-+-+-+-+
| |
~ Application Control Element(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value of the U-bit for the IP capability parameter TLV MUST be Figure 1: Format of an "Application Control Capability" TLV
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
advertised, this capability cannot be withdrawn and hence the S-bit
must always be set to 1 both in Initialization message and Capability
message. The capability data associated with this TLV is 1 octet long
"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 follows:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| AF bitmap |
+-+-+-+-+-+-+-+-+
Where: 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
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
hence the S-bit MUST be set to 1 both in Initialization message and
Capability message.
bit0: IPv4 label switching application The capability data associated with this TLV is one or more
bit1: IPv6 label switching application Application Control Elements, where each element defines
bit2-7: Unused. MBZ on transmit and ignored on receipt. enabling/disabling of state advertisement for a given application.
The format of an Application Control Element is defined as follows:
A bit in the bitmap is set to 0 or 1 to disable or enable 0 1
respectively a corresponding IP application. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| App |D|Rsvd1| Rsvd2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "Reserved" field is reserved for future use and MBZ on transmit Figure 2: Format of an "Application Control Element"
and ignored on receipt.
As described earlier, "IP Label Switching Capability" Parameter TLV Where:
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
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
or disable IPv4/v6 label switching application(s).
4.2. PW Signaling Capability TLV App: Defines the (non-negotiated) application type. The value of this
field is defined as:
0: IPv4 Label switching
1: IPv6 Label switching
2: P2P PW FEC128 signaling
3: P2P PW FEC129 signaling
4-15: Reserved.
The "PW Signaling Capability" is a new Capability Parameter defined D bit: Controls the advertisement of state for the application as
with the following format: follows
1: Disable state advertisement
0: Enable state advertisement
0 1 2 3 Rsvd1, Rsvd2: Reserved for future use. MBZ on transmit and ignored on
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 receipt.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PW Signaling Cap. (IANA) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved |E| Unused | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value of the U-bit for the PW capability parameter TLV MUST be The "Length" field of "Application Control Capability" TLV depends on
set to 1 so that a receiver MUST silently ignore this TLV if unknown the number of Application Control Elements present in the TLV. For
to it, and continue processing the rest of the message. Once example, if there are two elements present, then the Length field is
advertised, this capability cannot be withdrawn and hence the S-bit set to 5 octets. A receiver of this capability TLV can deduce number
MUST always be set to 1 in Initialization message or Capability of application control elements present in the TLV by using Length
message. The capability data associated with this TLV is 3 octets field.
long and hence the TLV length MUST be set to 4.
The capability data is defined as follows: For now onward, this document uses term "element" to refer to an
application control element.
0 1 2 3 4 5 6 7 As described earlier, "Application Control Capability" TLV MAY be
+-+-+-+-+-+-+-+-+ included by an LDP speaker in an Initialization message to signal to
|E| Unused | 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
later in a Capability message to selectively enable or disable these
applications. An "Application Control Capability" TLV MUST contain
elements with distinct application types and the TLV MUST NOT contain
the same application type more than once.
Where: To control more than one application, a sender LSR can either send a
single capability TLV in a message with multiple elements present, or
can send separate messages with capability TLV specifying one or more
elements. A receiving LSR, however, MUST treat each incoming message
with capability TLV as an incremental update to the existing control.
E-bit: Enable bit. Used to control PW signaling application by To understand capability updates from an example, let us consider 2
setting it to 0 and 1 to disable and enable the application LSR peers, R1 (sender) and R2 (receiver), both of which support all
respectively. the non-negotiated applications listed earlier. By default, these LSR
will advertise state for these applications to their peer as soon as
an LDP session is established. Now assume that R2 receives an
Application Control capability in the Initialization message with
"IPv6 Label switching" and "P2P PW FEC129" applications disabled.
This updates R2's outbound policy towards R1 to advertise state
related to only "IPv4 Label switching" and "P2P PW FEC 128"
applications. Now, R2 receives a capability update from R1 via a
Capability message with "IPv6 Label switching" enabled and "P2P PW
FEC128" disabled. This updates R2's outbound policy towards R1 to
advertise both IPv4 and IPv6 Label switching state, and disable both
P2P PW FEC128 and FEC 129 signaling. Finally, R2 receives another
update from R1 via Capability message that specifies to disable all 4
non-negotiated applications, resulting R2 outbound policy towards R1
to block/disable state for all these applications, and only advertise
state for any other application, if present.
Unused: Unused bits. MBZ on transmit and ignored on receipt. 5. Capabilities Procedures
The "Reserved" field is reserved for future use and MBZ on transmit The "Application Control" capability conveys the desire of a sending
and ignored on receipt. LSR to disable receipt of unwanted/unnecessary state from a peer.
Hence, this capability is unilateral and uni-directional in nature,
and a receiving LSR is not required to send a similar capability TLV
in an Initialization or Capability message towards the sender. This
unilateral behavior also conforms to the procedures defined in the
Section 6 of LDP Capabilities [RFC5561].
As described earlier, PW Signaling Capability Parameter TLV MAY be After this capability is successfully negotiated (i.e. sent by a
included by an LDP speaker in an Initialization message to signal to sender and received/understood by the receiver), then both
its peer LSR that state exchange for PW application need to be participating LSRs MUST NOT exchange any state related to the
disabled on given peer session. This TLV can also be sent later in a disabled applications until and unless these applications are
Capability message to enable/disable the PW Signaling application. explicitly enabled again via a capability update.
5. Capabilities Procedures If a receiving LDP speaker does not understand the Application
Control capability TLV, then it MUST respond to the sender with
"Unsupported TLV" Notification as described in LDP Capabilities
[RFC5561]. Upon receipt of such Notification, the sender MAY still
continue to block/disable its outbound state advertisement towards
the peer for the requested disabled applications. If a receiving LDP
speaker does not understand or does not support an application
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 Capabilities 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] 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 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
IP and/or PW application capability TLVs need to be included in the "Application Control Capability" TLV needs to be included in the
Initialization message with respective application bits set to 0 to Initialization message with respective application control elements
indicate application disable, where the application bit refers to a included with their D bit set to 1.
bit in "Address Family Bitmap" of the "IP Label Switching" Capability
or E-bit in the "PW Signaling" Capability.
An LDP speaker that supports the "IP Label Switching" and/or "PW
Signaling" capability MUST interpret those TLVs in a received
Initialization message such that it disables the advertisement of the
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.
If a receiving LDP speaker does not understand the capability TLVs,
then it MUST respond to the sender with "Unsupported TLV"
Notification as described in LDP Capabilities [RFC5561]. Upon receipt
of such Notification, the sender MAY still continue to block/disable
its outbound state advertisement towards the peer for the requested
disabled applications.
Once this capability has been sent by sender LSR and received and
understood by the receiver LSR, then both these LSRs MUST NOT
exchange any state related to the disabled applications until and
unless these applications are explicitly enabled again (e.g. via the
same Capability TLV sent in a Capability message with corresponding
application control bit set to 1).
"IP Label Switching" and "PW Signaling" capability TLVs are An LDP speaker that supports the "Application Control" capability
unilateral and uni-directional in nature -- i.e. a receiving LSR may MUST interpret the capability TLV in a received Initialization
not need to send a similar capability TLV in an Initialization or message such that it disables the advertisement of the application
Capability message towards the sender. This unilateral behavior also state towards the sender LSR for IPoMPLS and/or P2P PW applications
conforms to the procedures defined in the Section 6 of LDP if their application control element's D bit is set to 1.
Capabilities [RFC5561].
5.2. Application Control capabilities 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 can send IP Label Switching and/or PW Signaling then an LDP speaker may send Application Control capability in a
capability in a Capability message. 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 any
of its IP and/or L2VPN/PW signaling applications gets disabled, or if of its IPoMPLS and/or P2P PW signaling applications get disabled, or
previously disabled IP and/or L2VPN/PW application gets enabled if previously disabled application gets enabled again. In this case,
again. In this case, LDP speaker constructs the TLVs with appropriate LDP speaker constructs the TLV with appropriate application control
application control bitmap and sends the corresponding capability elements and sends the corresponding capability TLV in a Capability
TLVs in a Capability message. Furthermore, the LDP speaker also message. Furthermore, the LDP speaker also withdraws/advertises
withdraws application(s) related advertised state (such as label application(s) related state (such as address/label bindings) from/to
bindings) from its peer. its peer according to the capability update.
Upon receipt of those TLVs 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
those TLVs in an Initialization message. Additionally, the receiving this TLV in an Initialization message. Additionally, the receiving
LDP speaker withdraws the application(s) related advertised state LDP speaker withdraws/advertises application state from/to the
(such as label bindings) from the sending LDP speaker. If the sending peer according to the capability update.
receiving LDP speaker does not understand or support either Dynamic
Announcement capability or received Application Control capability
TLV ("IP Label Switching" or "PW Signaling"), it MUST respond with
"Unsupported Capability" notification to the sender of the Capability
message.
6. Operational Examples 6. Operational Examples
6.1. Disabling IP/PW label 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 "IP
Label Switching" and "PW Signaling" capability TLVs. These LSR have
an established LDP session due to ICCP application in order to
exchange ICCP state related to dual-homed devices connected to these
LSRs. Let us assume that LSR1 is provisioned not to exchange any
label bindings related to IP (v4/v6) prefixes and PW layer2 FEC
(FEC128/129) with LSR2.
To indicate its "disability" for the IP/PW applications, the LSR1 Consider two PE routers, LSR1 and LSR2, which understand/support
will include both the "IP Label Switching" capability TLV (with "Application Control" capability TLV, and have an established LDP
bit0-1 of "Address Family Bitmap" set to 0) and "PW Signaling" session due to ICCP application in order to exchange ICCP state
capability TLV (with E-bit set to 0) in the Initialization message. related to dual-homed devices connected to these LSRs. Let us assume
Upon receipt of those TLVs in Initialization message, the LSR2 will that LSR1 is provisioned not to exchange any state for IPoMPLS
disable any IP/PW address/label binding state advertisement towards (IPv4/IPv6) and P2P PW (FEC128/129) application with LSR2.
LSR1 after session establishment.
The LSR1 will also disable any IP/PW address/label binding state To indicate its disinterest in these applications, the LSR1 will
towards LSR2, irrespective of the fact whether or not LSR2 could include an "Application Control" capability TLV (with 4 application
disable the corresponding application state advertisement towards control elements corresponding to these 4 applications with D bit
LSR1. set to 1 for each one) in the Initialization message. Upon receipt
of this TLV in Initialization message, the LSR2 will disable
advertisement of IPv4/IPv6 bindings (addresses and labels), as well
as P2P PW FEC128/129 signaling, towards LSR1 after session
establishment.
6.2. Disabling IP Label Switching application on a L2VPN/PW session 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.
Now, consider LSR1 and LSR2 have an established session due to 6.2. Disabling IPoMPLS application on a L2VPN/PW T-LDP session
L2VPN/PW application just to exchange PW (FEC128/129) label bindings
for VPWS/VPLS services amongst them. Since in most typical
deployments, there is no need to exchange IP (v4/v6) address/label
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 indicate its disinterest in IP label switching, the LSR1 will Now, consider LSR1 and LSR2 have an established T-LDP session for
include the "IP Label Switching" capability TLV in the P2P PW application just to exchange label bindings for FEC 128/129.
Initialization message with bit0-1 (IPv4, IPv6) in "Address Family Since in most typical deployments, there is no need to exchange IP
Bitmap" set to zero. Upon receipt of this TLV in Initialization (v4/v6) address/label bindings amongst the PE LSRs, let us assume
message, the LSR2 will disable any IP address/label binding state that LSR1 is provisioned to disable IPoMPLS (IPv4/IPv6)application
advertisement towards LSR1. on given PW session towards LSR2.
The LSR1 will also disable any IP address/label binding state To indicate its disinterest in IPoMPLS application over PW T-LDP
towards LSR2, irrespective of the fact whether or not LSR2 could session, the LSR1 will follow/apply the same procedures to disable
disable the corresponding IP application state advertisement towards IPv4 and IPv6 label switching as described in previous section.
LSR1. Similarly, LSR2 will behave accordingly by disabling state
advertisement for IPoMPLS application towards LSR1.
6.3. Disabling IP 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 IP and PW state over the session between them, and also exchange both IPoMPLS and P2P PW state over the session between them,
support "Dynamic Announcement Capability" [RFC5561]. Now, assume that and also support "Dynamic Announcement" Capability [RFC5561]. Now,
LSR1 is dynamically provisioned to disable IP label switching with assume that LSR1 is dynamically provisioned to disable IPoMPLS
LSR2. In this case, LSR1 will first withdraw all its IP label state (IPv4/IPv6) over T-LDP session with LSR2. In this case, LSR1 will
by sending a single Label Withdraw message with IP "Prefix Typed first disable its future outbound application state towards LSR2, and
Wildcard FEC" using the mechanics described in [RFC5918], and Address also withdraw all its previously advertised IPoMPLS state (labels and
Withdraw message to withdraw its addresses. LSR1 will also send IP addresses) by sending a single Prefix FEC Typed Wildcard Label
Label Switching capability TLV in Capability message towards LSR2 Withdraw message [RFC5918], and an Address Withdraw message
with bit0-1 (IPv4, IPv6) in "Address Family Bitmap" set to zero. Upon respectively towards LSR2. LSR1 will also send Application Control
receipt of this TLV, LSR2 will also disable IP label switching capability TLV in a Capability message towards LSR2 with application
towards LSR1 and withdraw all previous IP label/address state using control elements defined for IPv4 and IPv6 label switching with D bit
the same mechanics as described earlier for LSR1. The disability of set to 1. Upon receipt of this TLV, LSR2 will also disable IPoMPLS
IP label switching dynamically should not impact L2VPN/PW application applications towards LSR1 and withdraw all previous IP label/address
on given session, and both LSRs should continue to exchange PW state using the same mechanics as described earlier for LSR1. This
Signaling application related state. dynamic disability of IPoMPLS application will not impact L2VPN P2P
PW application on the given session, and both LSRs should continue to
exchange PW Signaling application related state.
6.4. Disabling unwanted state advertisement by an IP dual-stack LSR
In IP dual-stack scenarios, an LSR2 may advertise unnecessary state
(label/address bindings) towards peer LSR1 corresponding to IPv6
label switching application once a session is established mainly for
exchanging state for IPv4. The similar scenario also applies when
advertising IPv4 label switching state on a session meant for IPv6.
The Application Control capability and its procedures defined in this
document can help to avoid such unnecessary state advertisement.
Consider IP dual-stack environment where LSR2 is enabled for IPoMPLS
application for both IPv4 and IPv6, but LSR1 is enabled for (or
interested in) only IPv4oMPLS. To avoid receiving unwanted state
advertisement for IPv6oMPLS application from LSR2, LSR1 can send
"Application Control" capability with element for IPv6 label
switching with D bit set to 1 in the Initialization message towards
LSR2 at the time of session establishment. Upon receipt of this
capability, LSR2 will disable all IPv6 label and address binding
advertisement towards LSR1. If IPv6oMPLS is later enabled on LSR1,
LSR1 can update the capability by sending Application Control
capability in Capability message towards LSR2 to enable IPv6oMPLS
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 following two new capability parameter TLVs and The document defines following a new capability parameter TLV and
requests following LDP TLV code point assignment by IANA from LDP requests following LDP TLV code point assignment by IANA from LDP
"TLV Type Name Space" registry: "TLV Type Name Space" registry:
o "IP Label Switching Capability" TLV (requested codepoint: 0x50C) o "Application Control Capability" TLV (requested codepoint: 0x50C)
o "PW Signaling Capability" TLV (requested codepoint: 0x50D)
9. 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 LDP between LDP peers for currently non-negotiated IP/PW LDP
applications. applications.
10. References 10. References
10.1. Normative References 10.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.
[RFC4447] L. Martini, E. Rosen, El-Aawar, T. Smith, and G. Heron, [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
"Pseudowire Setup and Maintenance using the Label
Distribution Protocol", RFC 4447, April 2006.
[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.
10.2. Informative References 10.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,
"Pseudowire Setup and Maintenance using the Label
Distribution Protocol", RFC 4447, April 2006.
[RFC4762] M. Lasserre, and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007.
[P2MP-PW] Martini, L. et. al, "Signaling Root-Initiated Point-to-
Multipoint Pseudowires using LDP", draft-ietf-pwe3-p2mp-pw-
04.txt, Work in Progress, October 2011.
[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-07.txt, Work in Progress, Redundancy", draft-ietf-pwe3-iccp-09.txt, Work in Progress,
February 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-
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 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.
 End of changes. 70 change blocks. 
281 lines changed or deleted 312 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/