draft-ietf-mpls-ldp-ip-pw-capability-07.txt | draft-ietf-mpls-ldp-ip-pw-capability-08.txt | |||
---|---|---|---|---|
MPLS Working Group Kamran Raza | ||||
Internet Draft Sami Boutros | ||||
Intended status: Standards Track | ||||
Expires: October 26, 2014 Cisco Systems | ||||
April 27, 2014 | MPLS Working Group Kamran Raza | |||
Internet Draft Sami Boutros | ||||
Intended Status: Standards Track | ||||
Expires: April 18, 2015 Cisco Systems, Inc. | ||||
Controlling State Advertisements Of Non-negotiated LDP Applications | October 15, 2014 | |||
draft-ietf-mpls-ldp-ip-pw-capability-07.txt | Controlling State Advertisements Of Non-negotiated LDP Applications | |||
Status of this Memo | draft-ietf-mpls-ldp-ip-pw-capability-08.txt | |||
This Internet-Draft is submitted in full conformance with the | Status of this Memo | |||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | This Internet-Draft is submitted to IETF in full conformance with the | |||
Task Force (IETF), its areas, and its working groups. Note that | provisions of BCP 78 and BCP 79. | |||
other groups may also distribute working documents as Internet- | ||||
Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six | Internet-Drafts are working documents of the Internet Engineering Task | |||
months and may be updated, replaced, or obsoleted by other documents | Force (IETF), its areas, and its working groups. Note that other | |||
at any time. It is inappropriate to use Internet-Drafts as | groups may also distribute working documents as Internet-Drafts. | |||
reference material or to cite them other than as "work in progress." | ||||
The list of current Internet-Drafts can be accessed at | Internet-Drafts are draft documents valid for a maximum of six months | |||
http://www.ietf.org/ietf/1id-abstracts.txt | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | ||||
material or to cite them other than as "work in progress." | ||||
The list of Internet-Draft Shadow Directories can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/shadow.html | http://www.ietf.org/1id-abstracts.html | |||
This Internet-Draft will expire on October 26, 2014. | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2014 IETF Trust and the persons identified as the | Copyright (c) 2014 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, | |||
carefully, as they describe your rights and restrictions with | as they describe your rights and restrictions with respect to this | |||
respect to this document. Code Components extracted from this | document. Code Components extracted from this document must include | |||
document must include Simplified BSD License text as described in | Simplified BSD License text as described in Section 4.e of the Trust | |||
Section 4.e of the Trust Legal Provisions and are provided without | Legal Provisions and are provided without warranty as described in the | |||
warranty as described in the Simplified BSD License. | Simplified BSD License. | |||
Abstract | Abstract | |||
There is no capability negotiation done for Label Distribution | There is no capability negotiation done for Label Distribution | |||
Protocol (LDP) applications that setup Label Switched Paths (LSPs) | Protocol (LDP) applications that setup Label Switched Paths (LSPs) for | |||
for IP prefixes or that signal Point-to-point (P2P) Pseudowires | IP prefixes or that signal Point-to-point (P2P) Pseudowires (PWs) for | |||
(PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP | Layer 2 Virtual Private Networks (L2VPNs). When an LDP session comes | |||
session comes up, an LDP speaker may unnecessarily advertise its | up, an LDP speaker may unnecessarily advertise its local state for | |||
local state for such LDP applications even when the peer session is | such LDP applications even when the peer session is established for | |||
established for some other applications like Multipoint LDP (mLDP) | some other applications like Multipoint LDP (mLDP) or Inter-Chassis | |||
or Inter-Chassis Communication Protocol (ICCP). This document | Communication Protocol (ICCP). This document defines a solution by | |||
defines a solution by which an LDP speaker announces to its peer its | which an LDP speaker announces to its peer its disinterest in such | |||
disinterest in such non-negotiated applications, thus disabling the | non-negotiated applications, thus disabling the unnecessary | |||
unnecessary advertisement of corresponding application state, which | advertisement of corresponding application state, which would have | |||
would have otherwise be advertised over the established LDP session. | otherwise be advertised 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 | |||
3.1. Non-interesting State 5 | 3.1. Non-interesting State . . . . . . . . . . . . . . . . . . . 4 | |||
4. Controlling State Advertisement 5 | 3.1.1 Prefix-LSPs . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4.1. State Advertisement Control Capability 5 | 3.1.2 P2P-PWs . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4.2. Capabilities Procedures 8 | 4. Controlling State Advertisement . . . . . . . . . . . . . . . . 5 | |||
4.2.1. State Control Capability in an Initialization message 9 | 4.1. State Advertisement Control Capability . . . . . . . . . . 5 | |||
4.2.2. State Control capability in a Capability message 9 | 4.2. Capabilities Procedures . . . . . . . . . . . . . . . . . . 8 | |||
5. Operational Examples 9 | 4.2.1. State Control Capability in an Initialization message . 8 | |||
5.1. Disabling Prefix-LSPs and P2P-PWs apps on an ICCP session 9 | 4.2.2. State Control capability in a Capability message . . . 9 | |||
5.2. Disabling Prefix-LSPs app on a PW Targeted LDP session 10 | 5. Applicability Statement . . . . . . . . . . . . . . . . . . . . 9 | |||
5.3. Disabling Prefix-LSPs app dynamically on an LDP session 10 | 6. Operational Examples . . . . . . . . . . . . . . . . . . . . . 11 | |||
5.4. Disabling Prefix-LSPs app on an mLDP-only session 11 | 6.1. Disabling Prefix-LSPs and P2P-PWs on an ICCP session . . . 11 | |||
5.5. Disabling IPv4 or IPv6 Prefix-LSPs app on an dual-stack LSR 11 | 6.2. Disabling Prefix-LSPs on a L2VPN/PW T-LDP session . . . . . 11 | |||
6. Security Considerations 11 | 6.3. Disabling Prefix-LSPs dynamically on an established LDP | |||
7. IANA Considerations 12 | session . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
8. References 12 | 6.4. Disabling Prefix-LSPs on an mLDP-only session . . . . . . . 12 | |||
8.1. Normative References 12 | 6.5. Disabling IPv4 or IPv6 Prefix-LSPs on a dual-stack LSR . . 12 | |||
8.2. Informative References 12 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 13 | |||
9. Acknowledgments 13 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | ||||
9.1 Normative References . . . . . . . . . . . . . . . . . . . 13 | ||||
9.2 Informative References . . . . . . . . . . . . . . . . . . 13 | ||||
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 | ||||
1. Introduction | 1. Introduction | |||
LDP Capabilities specification [RFC5561] introduced a mechanism to | LDP Capabilities specification [RFC5561] introduced a mechanism to | |||
negotiate LDP capabilities for a given feature between peer Label | negotiate LDP capabilities for a given feature between peer Label | |||
Switching Routers (LSRs). The capability mechanism insures that no | Switching Routers (LSRs). The capability mechanism insures that no | |||
unnecessary state is exchanged between peer LSRs unless the | unnecessary state is exchanged between peer LSRs unless the | |||
corresponding feature capability is successfully negotiated between | corresponding feature capability is successfully negotiated between | |||
the peers. | the peers. | |||
Newly defined LDP features and applications, such as Typed Wildcard | Newly defined LDP features and applications, such as Typed Wildcard | |||
Forwarding Equivalence Class (FEC) [RFC5918], Inter-Chassis | Forwarding Equivalence Class (FEC) [RFC5918], Inter-Chassis | |||
Communication Protocol [ICCP], mLDP [RFC6388], and L2VPN Point-to- | Communication Protocol [RFC7275], mLDP [RFC6388], and L2VPN Point-to- | |||
multipoint (P2MP) PW [P2MP-PW] make use of LDP capabilities framework | multipoint (P2MP) PW [P2MP-PW] make use of LDP capabilities framework | |||
for their feature negotiation. However, the earlier LDP application | for their feature negotiation. However, the earlier LDP application to | |||
to establish LSPs for IP unicast prefixes, and application to signal | establish LSPs for IP unicast prefixes, and application to signal | |||
L2VPN P2P PW [RFC4447] [RFC4762] allowed LDP speakers to exchange | L2VPN P2P PW [RFC4447] [RFC4762] allowed LDP speakers to exchange | |||
application state without any capability negotiation, thus causing | application state without any capability negotiation, thus causing | |||
unnecessary state advertisement when a given application is not | unnecessary state advertisement when a given application is not | |||
enabled on one of the LDP speakers participating in a given session. | enabled on one of the 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 Provider Edge (PE) LSR for purely ICCP signaling reasons, an | remote Provider Edge (PE) LSR for purely ICCP signaling reasons, an | |||
LDP speaker may unnecessarily advertise labels for IP (unicast) | LDP speaker may unnecessarily advertise labels for IP (unicast) | |||
prefixes to this ICCP related LDP peer. | prefixes to this ICCP related LDP peer. | |||
Another example of unnecessary state advertisement can be cited when | Another example of unnecessary state advertisement can be cited when | |||
LDP is to be deployed in an IP dual-stack environment. For instance, | LDP is to be deployed in an IP dual-stack environment. For instance, | |||
an LSR that is locally enabled to setup LSPs for both IPv4 and IPv6 | an LSR that is locally enabled to setup LSPs for both IPv4 and IPv6 | |||
prefixes may advertise (address and label) bindings for both IPv4 and | prefixes may advertise (address and label) bindings for both IPv4 and | |||
IPv6 address families towards an LDP peer that is interested in IPv4 | IPv6 address families towards an LDP peer that is interested in IPv4 | |||
bindings only. In this case, the advertisement of IPv6 bindings to | bindings only. In this case, the advertisement of IPv6 bindings to the | |||
the peer is unnecessary, as well as wasteful, from the point of view | peer is unnecessary, as well as wasteful, from the point of view of | |||
of LSR memory/CPU and network resource consumption. | 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 filtering | an operator is typically required to configure and define filtering | |||
policies on the LSR, which introduces unnecessary operational | policies on the LSR, which introduces unnecessary operational overhead | |||
overhead and complexity for such deployments. | and complexity for such deployments. | |||
This document defines an LDP Capabilities [RFC5561] based solution by | This document defines an LDP Capabilities [RFC5561] based solution by | |||
which an LDP speaker may announce to its peer(s) its disinterest (or | which an LDP speaker may announce to its peer(s) its disinterest (or | |||
non-support) for state to setup IP Prefix LSPs and/or to signal L2VPN | non-support) for state to setup IP Prefix LSPs and/or to signal L2VPN | |||
P2P PW at the time of session establishment. This capability helps in | P2P PW at the time of session establishment. This capability helps in | |||
avoiding unnecessary state advertisement for such feature | avoiding unnecessary state advertisement for such feature | |||
applications. This document also states the mechanics to dynamically | applications. This document also states the mechanics to dynamically | |||
disable or enable the state advertisement for such applications | disable or enable the state advertisement for such applications during | |||
during the session lifetime. The non-interesting state of an | the session lifetime. The non-interesting state of an application | |||
application depends on the type of application and is described later | depends on the type of application and is described later in section | |||
in section 3.1. | 3.1. | |||
2. Conventions used in this document | 2. Conventions used in this document | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC-2119 [RFC2119]. | document are to be interpreted as described in RFC-2119 [RFC2119]. | |||
The term "IP" in this document refers to both IPv4 and IPv6 unicast | The term "IP" in this document refers to both IPv4 and IPv6 unicast | |||
address families. | address families. | |||
3. Non-negotiated LDP applications | 3. Non-negotiated LDP applications | |||
For the applications that existed prior to the definition of LDP | For the applications that existed prior to the definition of LDP | |||
Capabilities framework [RFC5561], an LDP speaker typically | Capabilities framework [RFC5561], an LDP speaker typically advertises, | |||
advertises, without waiting for any capabilities exchange and | without waiting for any capabilities exchange and negotiation, its | |||
negotiation, its corresponding application state to its peers after | corresponding application state to its peers after the session | |||
the session establishment. These early LDP applications include: | establishment. These early LDP applications include: | |||
o IPv4/IPv6 Prefix LSPs Setup | ||||
o L2VPN P2P FEC128 and FEC129 PWs signaling | o IPv4/IPv6 Prefix LSPs Setup | |||
o L2VPN P2P FEC128 and FEC129 PWs signaling | ||||
This document onward uses following shorthand terms for these | This document onward uses following shorthand terms for these earlier | |||
earlier LDP applications: | LDP applications: | |||
o "Prefix-LSPs": Refers to an application that sets up LDP LSPs | o "Prefix-LSPs": Refers to an application that sets up LDP LSPs | |||
corresponding to IP routes/prefixes by advertising label | corresponding to IP routes/prefixes by advertising label | |||
bindings for Prefix FEC (as defined in RFC-5036). | bindings for Prefix FEC (as defined in RFC-5036). | |||
o "P2P-PWs": Refers to an application that signals FEC 128 and/or | o "P2P-PWs": Refers to an application that signals FEC 128 and/or | |||
FEC 129 L2VPN P2P Pseudowires using LDP (as defined in | FEC 129 L2VPN P2P Pseudowires using LDP (as defined in RFC-4447). | |||
RFC-4447). | ||||
To disable unnecessary state exchange for such LDP applications over | To disable unnecessary state exchange for such LDP applications over | |||
an established LDP session, a new capability is being introduced in | an established LDP session, a new capability is being introduced in | |||
this document. This new capability controls the advertisement of | this document. This new capability controls the advertisement of | |||
application state and enables an LDP speaker to notify its peer its | application state and enables an LDP speaker to notify its peer its | |||
disinterest in the state of one or more of these "Non-negotiated" | disinterest in the state of one or more of these "Non-negotiated" LDP | |||
LDP applications at the time of session establishment. Upon receipt | applications at the time of session establishment. Upon receipt of | |||
of such capability, the receiving LDP speaker, if supporting the | such capability, the receiving LDP speaker, if supporting the | |||
capability, disables the advertisement of the state related to the | capability, disables the advertisement of the state related to the | |||
application towards the sender of the capability. This new | application towards the sender of the capability. This new capability | |||
capability can also be sent later in a Capability message to either | can also be sent later in a Capability message to either disable a | |||
disable a previously enabled application's state advertisement or to | previously enabled application's state advertisement or to enable a | |||
enable a previously disabled application's state advertisement. | previously disabled application's state advertisement. | |||
3.1. Non-interesting State | 3.1. Non-interesting State | |||
A non-interesting state of a non-negotiated LDP application: | A non-interesting state of a non-negotiated LDP application: | |||
- is the application state which is of a no interest to an LSR and | ||||
need not be advertised to the LSR; | ||||
- is the application state which is of a no interest to an LSR | ||||
and need not be advertised to the LSR; | ||||
- need not be advertised in any of the LDP protocol messages; | - need not be advertised in any of the LDP protocol messages; | |||
- is dependent on application type and specified accordingly. | - is dependent on application type and specified accordingly. | |||
For Prefix-LSPs application type, the non-interesting state refers | 3.1.1 Prefix-LSPs | |||
to any state related to IP Prefix FEC (such as FEC label bindings, | ||||
LDP Status). This document, however, does not classify IP address | ||||
bindings as a non-interesting state and allows the advertisement of | ||||
IP Address bindings to facilitate other LDP applications (such as | ||||
mLDP) that depend on learning of peer addresses over an LDP session | ||||
for their correct operation. | ||||
For P2P-PWs application type, the non-interesting state refers to | For Prefix-LSPs application type, the non-interesting state refers to | |||
any state related to P2P PW FEC128/FEC129 (such as FEC label | any state related to IP Prefix FEC (such as FEC label bindings, LDP | |||
bindings, MAC [address] withdrawal, and LDP PW Status). | Status). This document, however, does not classify IP address | |||
bindings (advertised via ADDRESS message) as a non-interesting state | ||||
and allows the advertisement of IP Address bindings. The reason for | ||||
this allowance is that an LSR typically uses peer IP address(es) to | ||||
map an IP routing nexthop/address to an LDP peer for their | ||||
functionality. For example, mLDP [RFC6388] uses peer's IP address(es) | ||||
to determine its upstream LSR to reach Root node as well as to select | ||||
forwarding interface towards its downstream LSR. Hence in an mLDP- | ||||
only network, while it is desirable to disable advertisement of label | ||||
bindings for IP (unicast) Prefixes, disabling advertisement of IP | ||||
address bindings will break mLDP functionality. Similarly, other LDP | ||||
applications may also depend on learnt peer IP address and hence this | ||||
document does not put IP address binding into a non-interesting state | ||||
category to facilitate such LDP applications. | ||||
From now onward in this document, the term "state" will mean to | 3.1.2 P2P-PWs | |||
refer to the "non-interesting state" for an application, as defined | ||||
in this section. | For P2P-PWs application type, the non-interesting state refers to any | |||
state related to P2P PW FEC128/FEC129 (such as FEC label bindings, | ||||
MAC [address] withdrawal, and LDP PW Status). From now onward in this | ||||
document, the term "state" will mean to refer to the "non-interesting | ||||
state" for an application, as defined in this section. | ||||
4. Controlling State Advertisement | 4. Controlling State Advertisement | |||
To control advertisement of non-interesting state related to non- | To control advertisement of non-interesting state related to non- | |||
negotiated LDP applications defined in section 3, a new capability | negotiated LDP applications defined in section 3, a new capability | |||
TLV is defined as follows. | TLV is defined as follows. | |||
4.1. State Advertisement Control Capability | 4.1. State Advertisement Control Capability | |||
The "State Advertisement Control Capability" is a new Capability | The "State Advertisement Control Capability" is a new Capability | |||
Parameter TLV defined in accordance with section 3 of LDP | Parameter TLV defined in accordance with section 3 of LDP | |||
Capabilities specification [RFC5561]. The format of this new TLV is | Capabilities specification [RFC5561]. The format of this new TLV is | |||
as follows: | as follows: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|U|F| State Adv. Ctrl Cap.(IANA)| Length | | |U|F|State Adv. Ctrl. Cap (IANA)| Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|S| Reserved | | | |S| Reserved | | | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
~ State Advertisement Control Element(s) ~ | ~ State Advertisement Control Element(s) ~ | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 1: Format of an "State Advertisement Control Capability" TLV | Figure 1: Format of an "State Advertisement Control Capability" TLV | |||
The value of the U-bit for the TLV MUST be set to 1 so that a | The value of the U-bit for the TLV MUST be set to 1 so that a | |||
receiver MUST silently ignore this TLV if unknown to it, and | receiver MUST silently ignore this TLV if unknown to it, and continue | |||
continue processing the rest of the message. Whereas, The value of | processing the rest of the message. Whereas, The value of F-bit MUST | |||
F-bit MUST be set to 0. Once advertised, this capability cannot be | be set to 0. Once advertised, this capability cannot be withdrawn; | |||
withdrawn; thus S-bit MUST be set to 1 in an Initialization and | thus S-bit MUST be set to 1 in an Initialization and Capability | |||
Capability message. | message. | |||
The capability data associated with this State Advertisement Control | The capability data associated with this State Advertisement Control | |||
(SAC) Capability TLV is one or more State Advertisement Control | (SAC) Capability TLV is one or more State Advertisement Control | |||
Elements, where each element indicates enabling/disabling of | Elements, where each element indicates enabling/disabling of | |||
advertisement of non-interesting state for a given application. The | advertisement of non-interesting state for a given application. The | |||
format of a SAC Element is defined as follows: | format of a SAC Element is defined as follows: | |||
0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
|D| App |Unused | | |D| App |Unused | | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
Figure 2: Format of "State Advertisement Control Element" | Figure 2: Format of "State Advertisement Control Element" | |||
Where: | Where: | |||
D bit: Controls the advertisement of the state specified in "App" | D bit: Controls the advertisement of the state specified in "App" | |||
field: | field: | |||
1: Disable state advertisement | 1: Disable state advertisement | |||
0: Enable state advertisement | 0: Enable state advertisement | |||
When sent in an Initialization message, D bit MUST be set to 1. | When sent in an Initialization message, D bit MUST be set | |||
to 1. | ||||
App: Defines the application type whose state advertisement is to be | App: Defines the application type whose state advertisement is to be | |||
controlled. The value of this field is defined as follows: | controlled. The value of this field is defined as follows: | |||
1: IPv4 Prefix-LSPs (LSPs for IPv4 prefixes) | 1: IPv4 Prefix-LSPs (LSPs for IPv4 prefixes) | |||
2: IPv6 Prefix-LSPs (LSPs for IPv6 prefixes) | 2: IPv6 Prefix-LSPs (LSPs for IPv6 prefixes) | |||
3: FEC128 P2P-PW (L2VPN PWid FEC signaling) | 3: FEC128 P2P-PW (L2VPN PWid FEC signaling) | |||
4: FEC129 P2P-PW (L2VPN Generalized PWid FEC signaling) | 4: FEC129 P2P-PW (L2VPN Generalized PWid FEC signaling) | |||
Any other value in this field MUST be treated as an error. | Any other value in this field MUST be treated as an error. | |||
Unused: MBZ on transmit and ignored on receipt. | Unused: MBZ on transmit and ignored on receipt. | |||
The "Length" field of SAC Capability TLV depends on the number of | The "Length" field of SAC Capability TLV depends on the number of SAC | |||
SAC Elements present in the TLV. For example, if there are two | Elements present in the TLV. For example, if there are two elements | |||
elements present, then the Length field is set to 3 octets. A | present, then the Length field is set to 3 octets. A receiver of this | |||
receiver of this capability TLV can deduce number of elements | capability TLV can deduce number of elements present in the TLV by | |||
present in the TLV by using the Length field. | using the Length field. | |||
From now onward, this document uses the term "element" to refer to a | From now onward, this document uses the term "element" to refer to a | |||
SAC Element. | SAC Element. | |||
As described earlier, SAC Capability TLV MAY be included by an LDP | As described earlier, SAC Capability TLV MAY be included by an LDP | |||
speaker in an Initialization message to signal to its peer LSR that | speaker in an Initialization message to signal to its peer LSR that | |||
state exchange for one or more application(s) need to be disabled on | state exchange for one or more application(s) need to be disabled on | |||
the given peer session. This TLV can also be sent later in a | the given peer session. This TLV can also be sent later in a | |||
Capability message to selectively enable or disable these | Capability message to selectively enable or disable these | |||
applications. If there are more than one elements present in a SAC | applications. If there are more than one elements present in a SAC | |||
Capability TLV, the elements MUST belong to distinct app types and | Capability TLV, the elements MUST belong to distinct app types and | |||
an app type MUST NOT appear more than once. If a receiver | the an app type MUST NOT appear more than once. If a receiver | |||
receives such a malformed TLV, it SHOULD discard this TLV and | receives such a malformed TLV, it SHOULD discard this TLV and | |||
continue processing rest of the message. If an LSR receives a | continue processing rest of the message. If an LSR receives a message | |||
message with a SAC capability TLV containing an element with "App" | with a SAC capability TLV containing an element with "App" field set | |||
field set to a value other than defined above, the receiver MUST | to a value other than defined above, the receiver MUST ignore and | |||
ignore and discard the element and continue processing the rest of | discard the element and continue processing the rest of the TLV. | |||
the TLV. | ||||
To control more than one application state, a sender LSR can either | To control more than one application state, a sender LSR can either | |||
send a single capability TLV in a message with multiple elements | send a single capability TLV in a message with multiple elements | |||
present, or can send separate messages with capability TLV | present, or can send separate messages with capability TLV specifying | |||
specifying one or more elements. A receiving LSR, however, MUST | one or more elements. A receiving LSR, however, MUST treat each | |||
treat each incoming capability TLV with an element corresponding to | incoming capability TLV with an element corresponding to a given | |||
a given application type as an update to its existing policy for the | application type as an update to its existing policy for the given | |||
given type. | type. | |||
To understand capability updates from an example, let us consider 2 | To understand capability updates from an example, let us consider 2 | |||
LSRs, S (LDP speaker) and P (LDP peer), both of which support all | LSRs, S (LDP speaker) and P (LDP peer), both of which support all the | |||
the non-negotiated applications listed earlier. By default, these | non-negotiated applications listed earlier. By default, these LSR | |||
LSR will advertise state for these applications, as configured, to | will advertise state for these applications, as configured, to their | |||
their peer as soon as an LDP session is established. Now assume that | peer as soon as an LDP session is established. Now assume that P | |||
P receives from S a SAC capability in an Initialization message with | receives from S a SAC capability in an Initialization message with | |||
"IPv6 Prefix-LSPs" and "FEC129 P2P-PW" applications disabled. This | "IPv6 Prefix-LSPs" and "FEC129 P2P-PW" applications disabled. This | |||
updates P's outbound policy towards S to advertise state related to | updates P's outbound policy towards S to advertise state related to | |||
only IPv4 Prefix-LSPs and FEC128 P2P-PW applications. Later, P | only IPv4 Prefix-LSPs and FEC128 P2P-PW applications. Later, P | |||
receives another capability update from S via a Capability message | receives another capability update from S via a Capability message | |||
with "IPv6 Prefix-LSPs" enabled and "FEC128 P2P-PWs" disabled. This | with "IPv6 Prefix-LSPs" enabled and "FEC128 P2P-PWs" disabled. This | |||
results in P's outbound policy towards S to advertise both IPv4 and | results in P's outbound policy towards S to advertise both IPv4 and | |||
IPv6 Prefix-LSPs application state, and disable both FEC128 and | IPv6 Prefix-LSPs application state, and disable both FEC128 and | |||
FEC129 P2P-PWs signaling. Finally, P receives another update from S | FEC129 P2P-PWs signaling. Finally, P receives another update from S | |||
via a Capability message that specifies to disable all four non- | via a Capability message that specifies to disable all four non- | |||
negotiated applications state, resulting in P outbound policy | negotiated applications state, resulting in P outbound policy towards | |||
towards S to block/disable state for all these applications, and | S to block/disable state for all these applications, and only | |||
only advertise state for any other application, as applicable. | advertise state for any other application, as applicable. | |||
4.2. Capabilities Procedures | 4.2. Capabilities Procedures | |||
The SAC capability conveys the desire of an LSR to disable the | The SAC capability conveys the desire of an LSR to disable the | |||
receipt of unwanted/unnecessary state from its LDP peer. This | receipt of unwanted/unnecessary state from its LDP peer. This | |||
capability is unilateral and unidirectional in nature, and a | capability is unilateral and unidirectional in nature, and a | |||
receiving LSR is not required to send a similar capability TLV in an | receiving LSR is not required to send a similar capability TLV in an | |||
Initialization or Capability message towards the sender of this | Initialization or Capability message towards the sender of this | |||
capability. This unilateral behavior conforms to the procedures | capability. This unilateral behavior conforms to the procedures | |||
defined in the Section 6 of LDP Capabilities [RFC5561]. | defined in the Section 6 of LDP Capabilities [RFC5561]. | |||
After this capability is successfully negotiated (i.e. sent by an | After this capability is successfully negotiated (i.e. sent by an LSR | |||
LSR and received/understood by its peer), then the receiving LSR | and received/understood by its peer), then the receiving LSR MUST NOT | |||
MUST NOT advertise any state related to the disabled applications | advertise any state related to the disabled applications towards the | |||
towards the capability sending LSR until and unless these | capability sending LSR until and unless these application states are | |||
application states are explicitly enabled again via a capability | explicitly enabled again via a capability update. Upon receipt of a | |||
update. Upon receipt of a capability update to disable an enabled | capability update to disable an enabled application [state] during | |||
application [state] during the lifetime of a session, the receiving | the lifetime of a session, the receiving LSR MUST also withdraw from | |||
LSR MUST also withdraw from the peer any previously advertised state | the peer any previously advertised state corresponding to the | |||
corresponding to the disabled application. | disabled application. | |||
If a receiving LDP speaker does not understand the SAC capability | If a receiving LDP speaker does not understand the SAC capability | |||
TLV, then it MUST respond to the sender with "Unsupported TLV" | TLV, then it MUST respond to the sender with "Unsupported TLV" | |||
notification as described in LDP Capabilities [RFC5561]. If a | notification as described in LDP Capabilities [RFC5561]. If a | |||
receiving LDP speaker does not understand or does not support an | receiving LDP speaker does not understand or does not support an | |||
application specified in an application control element, it SHOULD | application specified in an application control element, it SHOULD | |||
silently ignore/skip such an element and continue processing rest of | silently ignore/skip such an element and continue processing rest of | |||
the TLV. | the TLV. | |||
4.2.1. State Control Capability in an Initialization message | 4.2.1. State Control Capability in an Initialization message | |||
LDP Capabilities [RFC5561] framework dictates that the S-bit of | LDP Capabilities [RFC5561] framework dictates that the S-bit of | |||
capability parameter in an Initialization message MUST be set to 1 | capability parameter in an Initialization message MUST be set to 1 | |||
and SHOULD be ignored on receipt. | and SHOULD be ignored on receipt. | |||
An LDP speaker determines (e.g. via some local configuration or | An LDP speaker determines (e.g. via some local configuration or | |||
default policy) if it needs to disable Prefix-LSPs and/or P2P-PWs | default policy) if it needs to disable Prefix-LSPs and/or P2P-PWs | |||
applications with a peer LSR. If there is a need to disable, then | applications with a peer LSR. If there is a need to disable, then the | |||
the SAC TLV needs to be included in the Initialization message with | SAC TLV needs to be included in the Initialization message with | |||
respective SAC elements included with their D bit set to 1. | respective SAC elements included with their D bit set to 1. | |||
An LDP speaker that supports the SAC capability MUST interpret the | An LDP speaker that supports the SAC capability MUST interpret the | |||
capability TLV in a received Initialization message such that it | capability TLV in a received Initialization message such that it | |||
disables the advertisement of the application state towards the | disables the advertisement of the application state towards the | |||
capability sending LSR for Prefix-LSPs and/or P2P-PWs applications | capability sending LSR for Prefix-LSPs and/or P2P-PWs applications if | |||
if their SAC element's D bit is set to 1. | their SAC element's D bit is set to 1. | |||
4.2.2. State Control capability in a Capability message | 4.2.2. State Control capability in a Capability message | |||
If the LDP peer supports "Dynamic Announcement Capability" | If the LDP peer supports "Dynamic Announcement Capability" [RFC5561], | |||
[RFC5561], then an LDP speaker may send SAC capability in a | then an LDP speaker may send SAC capability in a Capability message | |||
Capability message towards the peer. Once advertised, these | towards the peer. Once advertised, these capabilities cannot be | |||
capabilities cannot be withdrawn and hence the S-bit of the TLV MUST | withdrawn and hence the S-bit of the TLV MUST be set to 1 when sent | |||
be set to 1 when sent in a Capability message. | in a Capability message. | |||
An LDP speaker may decide to send this TLV towards an LDP peer if | An LDP speaker may decide to send this TLV towards an LDP peer if one | |||
one or more of its Prefix-LSPs and/or P2P-PWs applications get | or more of its Prefix-LSPs and/or P2P-PWs applications get disabled, | |||
disabled, or if previously disabled application gets enabled again. | or if previously disabled application gets enabled again. In this | |||
In this case, the LDP speaker constructs the TLV with appropriate | case, the LDP speaker constructs the TLV with appropriate SAC | |||
SAC element(s) and sends the corresponding capability TLV in a | element(s) and sends the corresponding capability TLV in a Capability | |||
Capability message. | message. | |||
Upon receipt of this TLV in a Capability message, the receiving LDP | Upon receipt of this TLV in a Capability message, the receiving LDP | |||
speaker reacts in the same manner as it reacts upon the receipt of | speaker reacts in the same manner as it reacts upon the receipt of | |||
this TLV in an Initialization message. Additionally, the peer | this TLV in an Initialization message. Additionally, the peer | |||
withdraws/advertises the application state from/to the capability | withdraws/advertises the application state from/to the capability | |||
sending LDP speaker according to the capability update. | sending LDP speaker according to the capability update. | |||
5. Operational Examples | 5. Applicability Statement | |||
5.1. Disabling Prefix-LSPs and P2P-PWs applications on an ICCP session | The procedures defined in this document may result in disabling | |||
announcement of label bindings for IP Prefixes and/or P2P PW FECs, | ||||
and hence should be used with caution and discretion. This document | ||||
recommends that this new SAC capability and its procedures SHOULD be | ||||
enabled on an LSR only via a configuration knob. This knob could | ||||
either be a global LDP knob or be implemented per LDP neighbor. | ||||
Hence, it is recommended that an operator SHOULD enable this | ||||
capability and its associated procedures on an LSR towards a neighbor | ||||
only if it is known that such bindings advertisement and exchange | ||||
with the neighbor is unnecessary and wasteful. | ||||
Following table summarizes a non-exhaustive list of typical LDP | ||||
session types on which this new SAC capability and its procedures are | ||||
expected to be applied to disable advertisement of non-interesting | ||||
state: | ||||
+===============================+================================+ | ||||
| Session Type(s) | Non-interesting State | | ||||
+===============================+================================+ | ||||
| P2P-PW FEC128-only | IP Prefix LSPs + P2P-PW FEC129 | | ||||
|-------------------------------|--------------------------------| | ||||
| P2P-PW only (FEC128/129) | IP Prefix LSPs | | ||||
|-------------------------------|--------------------------------| | ||||
| IPv4-only on a Dual-Stack LSR | IPv6 Prefix LSPs + P2P-PW | | ||||
|-------------------------------|--------------------------------| | ||||
| IPv6-only on a Dual-Stack LSR | IPv4 Prefix LSPs + P2P-PW | | ||||
|-------------------------------|--------------------------------| | ||||
| mLDP-only | IP Prefix LSPs + P2P-PW | | ||||
|-------------------------------|--------------------------------| | ||||
| ICCP-only | IP Prefix LSPs + P2P-PW | | ||||
+-------------------------------+--------------------------------+ | ||||
It is to be noted that if an application state needs changing after | ||||
session initialization (e.g. to enable previously disabled | ||||
application or to disable previously enabled application), the | ||||
procedures defined in this document expect LSR peers to support LDP | ||||
"Dynamic Announcement" Capability to announce the change in SAC | ||||
capability via LDP Capability message. However, if any of the peering | ||||
LSR does not support this capability, the alternate option is to | ||||
force reset the LDP session to advertise the new SAC capability | ||||
accordingly during the following session initialization. | ||||
Following are some more important points that an operator need to | ||||
consider regarding the applicability of this new capability and | ||||
associated procedures defined in this document: | ||||
- An operator SHOULD disable Prefix-LSPs state on any Targeted LDP (T-LDP) | ||||
session that is established for ICCP-only and/or PW-only purposes. | ||||
- An operator MUST NOT disable Prefix-LSPs state on any T-LDP session | ||||
that is established for remote LFA FRR [RLFA] reasons. | ||||
- In a remote LFA FRR [RLFA] enabled network, it is RECOMMENDED to | ||||
not disable Prefix-LSPs state on a T-LDP session even if the current | ||||
session type is PW-only and/or ICCP-only. This is recommended because | ||||
any remote/T-LDP neighbor could potentially be picked as a remote LFA | ||||
PQ node. | ||||
- This capability SHOULD be enabled for Prefix-LSPs in the | ||||
scenarios when it is desirable to disable (or enable) | ||||
advertisement of "all" the prefix label bindings. For scenarios | ||||
when a "subset" of bindings need to be filtered, the existing | ||||
filtering procedures pertaining to label binding announcement | ||||
should be used. | ||||
- It is allowed to use label advertisement filtering policies in | ||||
conjunction with the procedures defined in this document for | ||||
Prefix-LSPs. In such cases, the label bindings will be announced | ||||
as per the label filtering policy for the given neighbor when | ||||
Prefix-LSP application is enabled. | ||||
6. Operational Examples | ||||
6.1. Disabling Prefix-LSPs and P2P-PWs on an ICCP session | ||||
Consider two PE routers, LSR1 and LSR2, which understand/support SAC | Consider two PE routers, LSR1 and LSR2, which understand/support SAC | |||
capability TLV, and have an established LDP session to exchange ICCP | capability TLV, and have an established LDP session to exchange ICCP | |||
state related to dual-homed devices connected to these LSRs. Let us | state related to dual-homed devices connected to these LSRs. Let us | |||
assume that both LSRs are provisioned not to exchange any state for | assume that both LSRs are provisioned not to exchange any state for | |||
Prefix-LSPs (IPv4/IPv6) and P2P-PWs (FEC128/129) application. | Prefix-LSPs (IPv4/IPv6) and P2P-PWs (FEC128/129) application. | |||
To indicate their disinterest in these applications, the LSRs will | ||||
To indicate their disinterest in these applications, the LSRs will | ||||
include a SAC capability TLV (with 4 SAC elements corresponding to | include a SAC capability TLV (with 4 SAC elements corresponding to | |||
these 4 applications with D bit set to 1 for each one) in the | these 4 applications with D bit set to 1 for each one) in the | |||
Initialization message. Upon receipt of this TLV in Initialization | Initialization message. Upon receipt of this TLV in Initialization | |||
message, the receiving LSR will disable the advertisement of | message, the receiving LSR will disable the advertisement of | |||
IPv4/IPv6 label bindings, as well as P2P PW FEC128/129 signaling, | IPv4/IPv6 label bindings, as well as P2P PW FEC128/129 signaling, | |||
towards its peer after session establishment. | towards its peer after session establishment. | |||
5.2. Disabling Prefix-LSPs application on a PW Targeted LDP session | 6.2. Disabling Prefix-LSPs on a L2VPN/PW T-LDP session | |||
Now, consider LSR1 and LSR2 have an established Targeted LDP (T-LDP) | Now, consider LSR1 and LSR2 have an established T-LDP session for | |||
session for P2P-PWs application to exchange label bindings for | P2P-PWs application to exchange label bindings for FEC 128/129. Given | |||
FEC 128/129. Given that there is no need to exchange IP Prefix label | that there is no need to exchange IP label bindings amongst the PE | |||
bindings amongst the PE LSRs over a PW T-LDP session in most typical | LSRs over a PW T-LDP session in most typical deployments, let us | |||
deployments, let us assume that LSRs are provisioned to disable | assume that LSRs are provisioned to disable IPv4/IPv6 Prefix-LSPs | |||
IPv4/IPv6 Prefix-LSPs application state on the given PW session. | application state on the given PW session. | |||
To indicate their disinterest in Prefix-LSPs application over a PW | To indicate their disinterest in Prefix-LSPs application over a PW T- | |||
T-LDP session, the LSRs will follow/apply the same procedures as | LDP session, the LSRs will follow/apply the same procedures as | |||
described in previous section. As a result, only P2P-PWs related | described in previous section. As a result, only P2P-PWs related | |||
state will be exchanged between these LSRs over this T-LDP session. | state will be exchanged between these LSRs over this T-LDP session. | |||
5.3. Disabling Prefix-LSPs application dynamically on an established | 6.3. Disabling Prefix-LSPs dynamically on an established LDP session | |||
LDP session | ||||
Assume that LSRs from previous sections were initially provisioned | Assume that LSRs from previous sections were initially provisioned to | |||
to exchange both Prefix-LSPs and P2P-PWs state over the session | exchange both Prefix-LSPs and P2P-PWs state over the session between | |||
between them, and also support "Dynamic Announcement" Capability | them, and also support "Dynamic Announcement" Capability [RFC5561]. | |||
[RFC5561]. Now, assume that LSR1 is dynamically provisioned to | Now, assume that LSR1 is dynamically provisioned to disable | |||
disable (IPv4/IPv6) Prefix-LSPs over T-LDP session with LSR2. In | (IPv4/IPv6) Prefix-LSPs over T-LDP session with LSR2. In this case, | |||
this case, LSR1 will send SAC capability TLV in a Capability message | LSR1 will send SAC capability TLV in a Capability message towards | |||
towards LSR2 with application control elements defined for IPv4 and | LSR2 with application control elements defined for IPv4 and IPv6 | |||
IPv6 Prefix-LSPs with D bit set to 1. Upon receipt of this TLV, LSR2 | Prefix-LSPs with D bit set to 1. Upon receipt of this TLV, LSR2 will | |||
will disable Prefix-LSPs application state(s) towards LSR1 and | disable Prefix-LSPs application state(s) towards LSR1 and withdraw | |||
withdraw all previously advertised application state from LSR1. To | all previously advertised application state from LSR1. To withdraw | |||
withdraw label bindings from its peer, LSR2 MAY use a single Prefix | label bindings from its peer, LSR2 MAY use a single Prefix FEC Typed | |||
FEC Typed Wildcard Label Withdraw message [RFC5918] if the peer | Wildcard Label Withdraw message [RFC5918] if the peer supports Typed | |||
supports Typed Wildcard FEC capability. | Wildcard FEC capability. | |||
This dynamic disability of Prefix-LSPs application does not impact | This dynamic disability of Prefix-LSPs application does not impact | |||
L2VPN P2P-PWs application on the given session, and both LSRs should | L2VPN P2P-PWs application on the given session, and both LSRs should | |||
continue to exchange PW Signaling application related state. | continue to exchange PW Signaling application related state. | |||
5.4. Disabling Prefix-LSPs application on an mLDP-only session | 6.4. Disabling Prefix-LSPs on an mLDP-only session | |||
Now assume that LSR1 and LSR2 have formed an LDP session to exchange | Now assume that LSR1 and LSR2 have formed an LDP session to exchange | |||
mLDP state only. In typical deployments, LSR1 and LSR2 also exchange | mLDP state only. In typical deployments, LSR1 and LSR2 also exchange | |||
bindings for IP (unicast) prefixes upon mLDP session, which is | bindings for IP (unicast) prefixes upon mLDP session, which is | |||
unnecessary and wasteful for an mLDP-only LSR. | unnecessary and wasteful for an mLDP-only LSR. | |||
Using the procedures defined earlier, an LSR can indicate its | Using the procedures defined earlier, an LSR can indicate its | |||
disinterest in Prefix-LSPs application state to its peer upon | disinterest in Prefix-LSPs application state to its peer upon session | |||
session establishment time or dynamically later via LDP capabilities | establishment time or dynamically later via LDP capabilities update. | |||
update. | ||||
Reference to section 3.1, the peer disables the advertisement of any | Reference to section 3.1, the peer disables the advertisement of any | |||
state related to IP Prefix FECs, but still advertises IP address | state related to IP Prefix FECs, but still advertises IP address | |||
bindings that are required for the correct operation of mLDP. | bindings that are required for the correct operation of mLDP. | |||
5.5. Disabling IPv4 or IPv6 Prefix-LSPs application on an dual-stack LSR | 6.5. Disabling IPv4 or IPv6 Prefix-LSPs on a dual-stack LSR | |||
In IP dual-stack scenarios, LSR2 may advertise unnecessary state | In IP dual-stack scenarios, LSR2 may advertise unnecessary state | |||
(e.g. IPv6 prefix label bindings) towards peer LSR1 corresponding to | (e.g. IPv6 prefix label bindings) towards peer LSR1 corresponding to | |||
IPv6 Prefix-LSPs application once a session is established mainly | IPv6 Prefix-LSPs application once a session is established mainly for | |||
for exchanging state for IPv4. The similar scenario also applies | exchanging state for IPv4. The similar scenario also applies when | |||
when advertising IPv4 Prefix-LSPs state on a session meant for IPv6. | advertising IPv4 Prefix-LSPs state on a session meant for IPv6. The | |||
The SAC capability and its procedures defined in this document can | SAC capability and its procedures defined in this document can help | |||
help to avoid such unnecessary state advertisement. | to avoid such unnecessary state advertisement. | |||
Consider IP dual-stack environment where LSR2 is enabled for Prefix- | Consider IP dual-stack environment where LSR2 is enabled for Prefix- | |||
LSPs application for both IPv4 and IPv6, but LSR1 is enabled for (or | LSPs application for both IPv4 and IPv6, but LSR1 is enabled for (or | |||
interested in) only IPv4 Prefix-LSPs. To avoid receiving unwanted | interested in) only IPv4 Prefix-LSPs. To avoid receiving unwanted | |||
state advertisement for IPv6 Prefix-LSPs application from LSR2, LSR1 | state advertisement for IPv6 Prefix-LSPs application from LSR2, LSR1 | |||
can send SAC capability with element for IPv6 Prefix-LSPs with D bit | can send SAC capability with element for IPv6 Prefix-LSPs with D bit | |||
set to 1 in the Initialization message towards LSR2 at the time of | set to 1 in the Initialization message towards LSR2 at the time of | |||
session establishment. Upon receipt of this capability, LSR2 will | session establishment. Upon receipt of this capability, LSR2 will | |||
disable all IPv6 label binding advertisement towards LSR1. If IPv6 | disable all IPv6 label binding advertisement towards LSR1. If IPv6 | |||
Prefix-LSPs application is later enabled on LSR1, LSR1 can update | Prefix-LSPs application is later enabled on LSR1, LSR1 can update the | |||
the capability by sending SAC capability in a Capability message | capability by sending SAC capability in a Capability message towards | |||
towards LSR2 to enable this application dynamically. | LSR2 to enable this application dynamically. | |||
6. 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]. | |||
7. IANA Considerations | 8. IANA Considerations | |||
This document defines a new LDP capability parameter TLV. IANA is | This document defines a new LDP capability parameter TLV. IANA is | |||
requested to assign the lowest available value after 0x0500 from | requested to assign the lowest available value after 0x0500 from "TLV | |||
"TLV Type Name Space" in the "Label Distribution Protocol (LDP) | Type Name Space" in the "Label Distribution Protocol (LDP) | |||
Parameters" registry as the new code point for the new LDP | Parameters" registry as the new code point for the new LDP capability | |||
capability TLV code point. | TLV code point. | |||
+-----+---------------------+---------------+-----------------------+ | +-----+---------------------+---------------+-----------------------+ | |||
|Value| Description | Reference |Notes/Registration Date| | |Value| Description | Reference |Notes/Registration Date| | |||
+-----+---------------------+---------------+-----------------------+ | +-----+---------------------+---------------+-----------------------+ | |||
| TBA | State Advertisement | This document | | | | TBA | State Advertisement | This document | | | |||
| | Control Capability | | | | | | Control Capability | | | | |||
+-----+---------------------+---------------+-----------------------+ | +-----+---------------------+---------------+-----------------------+ | |||
8. References | 9. References | |||
8.1. Normative References | 9.1 Normative References | |||
[RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Specification", RFC 5036, September 2007. | Requirement Levels", BCP 14, RFC 2119, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2119>. | ||||
[RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, and JL. Le | [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., | |||
Roux, "LDP Capabilities", RFC 5561, July 2009. | "LDP Specification", RFC 5036, October 2007, | |||
<http://www.rfc-editor.org/info/rfc5036>. | ||||
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate | [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. | |||
Requirement Levels", BCP 14, RFC2119, March 1997. | Le Roux, "LDP Capabilities", RFC 5561, July 2009, | |||
<http://www.rfc-editor.org/info/rfc5561>. | ||||
8.2. Informative References | 9.2 Informative References | |||
[RFC5918] R. Asati, I. Minei, and B. Thomas, "Label Distribution | [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and | |||
Protocol Typed Wildcard FEC", RFC 5918, August 2010. | G. Heron, "Pseudowire Setup and Maintenance Using the | |||
Label Distribution Protocol (LDP)", RFC 4447, April 2006, | ||||
<http://www.rfc-editor.org/info/rfc4447>. | ||||
[RFC4447] L. Martini, E. Rosen, El-Aawar, T. Smith, and G. Heron, | [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private | |||
"Pseudowire Setup and Maintenance using the Label | LAN Service (VPLS) Using Label Distribution Protocol (LDP) | |||
Distribution Protocol", RFC 4447, April 2006. | Signaling", RFC 4762, January 2007, <http://www.rfc- | |||
editor.org/info/rfc4762>. | ||||
[RFC4762] M. Lasserre, and V. Kompella, "Virtual Private LAN Service | [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution | |||
(VPLS) Using Label Distribution Protocol (LDP) Signaling", | Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class | |||
RFC 4762, January 2007. | (FEC)", RFC 5918, August 2010, <http://www.rfc- | |||
editor.org/info/rfc5918>. | ||||
[P2MP-PW] Martini, L. et. al, "Signaling Root-Initiated Point-to- | [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS | |||
Multipoint Pseudowires using LDP", draft-ietf-pwe3-p2mp-pw- | Networks", RFC 5920, July 2010, <http://www.rfc- | |||
04.txt, Work in Progress, March 2012. | editor.org/info/rfc5920>. | |||
[ICCP] L. Martini, S. Salam, A. Sajassi, and S. Matsushima, | [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. | |||
"Inter-Chassis Communication Protocol for L2VPN PE | Thomas, "Label Distribution Protocol Extensions for Point- | |||
Redundancy", draft-ietf-pwe3-iccp-16.txt, Work in | to-Multipoint and Multipoint-to-Multipoint Label Switched | |||
Progress, March 2014. | Paths", RFC 6388, November 2011, <http://www.rfc- | |||
editor.org/info/rfc6388>. | ||||
[RFC6388] I. Minei, I. Wijnands, K. Kompella, and B. Thomas, "LDP | [RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M., | |||
Extensions for P2MP and MP2MP LSPs", RFC 6388, November | Matsushima, S., and T. Nadeau, "Inter-Chassis | |||
2011. | Communication Protocol for Layer 2 Virtual Private Network | |||
(L2VPN) Provider Edge (PE) Redundancy", RFC 7275, June | ||||
2014, <http://www.rfc-editor.org/info/rfc7275>. | ||||
[RFC5920] L. Fang, et al., "Security Framework for MPLS and GMPLS | [P2MP-PW] Martini, L. et. al, "Signaling Root-Initiated Point-to- | |||
Networks", RFC 5920, July 2010. | Multipoint Pseudowires using LDP", draft-ietf-pwe3-p2mp- | |||
pw-04.txt, Work in Progress, March 2012. | ||||
9. Acknowledgments | [RLFA] Bryant, S., Filsfils, C., Previdi, S., Shand, M., So, N., | |||
"Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-08, Work in | ||||
Progress, September 2014. | ||||
The authors would like to thank Eric Rosen for his valuable input | 10. Acknowledgments | |||
and comments. We also acknowledge Karthik Subramanian and IJsbrand | ||||
Wijnands for bringing up mLDP use case. | ||||
This document was prepared using 2-Word-v2.0.template.dot. | The authors would like to thank Eric Rosen and Alexander Vainshtein | |||
for their review and valuable comments. We also acknowledge Karthik | ||||
Subramanian and IJsbrand Wijnands for bringing up mLDP use case. | ||||
Authors' Addresses | Authors' Addresses | |||
Kamran Raza | Kamran Raza | |||
Cisco Systems, Inc., | Cisco Systems, Inc., | |||
2000 Innovation Drive, | 2000 Innovation Drive, | |||
Ottawa, ON K2K-3E8, Canada. | Ottawa, ON K2K-3E8, Canada. | |||
E-mail: skraza@cisco.com | E-mail: skraza@cisco.com | |||
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. 92 change blocks. | ||||
285 lines changed or deleted | 381 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/ |