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/ |