draft-ietf-mpls-ldp-typed-wildcard-07.txt   rfc5918.txt 
MPLS Working Group Rajiv Asati
Internet Draft Cisco Systems
Intended status: Standards Track
Expires: July 2010 Ina Minei
Juniper Networks
Bob Thomas
March 4, 2010 Internet Engineering Task Force (IETF) R. Asati
Request for Comments: 5918 Cisco Systems
Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Category: Standards Track I. Minei
Equivalence Class (FEC) ISSN: 2070-1721 Juniper Networks
draft-ietf-mpls-ldp-typed-wildcard-07.txt B. Thomas
August 2010
Status of this Memo Label Distribution Protocol (LDP) 'Typed Wildcard'
Forward Equivalence Class (FEC)
This Internet-Draft is submitted to IETF in full conformance with Abstract
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering The Label Distribution Protocol (LDP) specification for the Wildcard
Task Force (IETF), its areas, and its working groups. Note that Forward Equivalence Class (FEC) element has several limitations.
other groups may also distribute working documents as Internet- This document addresses those limitations by defining a Typed
Drafts. Wildcard FEC Element and associated procedures. In addition, it
defines a new LDP capability to address backward compatibility.
Internet-Drafts are draft documents valid for a maximum of six Status of This Memo
months 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 current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on July 4, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5918.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the BSD License. described in the Simplified BSD License.
Abstract
The Label Distribution Protocol (LDP) specification for the Wildcard This document may contain material from IETF Documents or IETF
Forward Equivalence Class (FEC) element has several limitations. Contributions published or made publicly available before November
This document addresses those limitations by defining a Typed 10, 2008. The person(s) controlling the copyright in some of this
Wildcard FEC element and associated procedures. In addition, it material may not have granted the IETF Trust the right to allow
defines a new LDP capability to address backward compatibility. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction ....................................................3
2. Specification Language.........................................4 2. Specification Language ..........................................4
3. The Typed Wildcard FEC Element.................................4 3. The Typed Wildcard FEC Element ..................................4
4. Procedures for the Typed Wildcard FEC Element..................5 4. Procedures for the Typed Wildcard FEC Element ...................5
5. Typed Wildcard FEC Capability..................................6 5. Typed Wildcard FEC Capability ...................................6
6. Typed Wildcard FEC Element for Prefix FEC Element..............7 6. Typed Wildcard FEC Element for Prefix FEC Element ...............7
7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements..8 7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements ...8
8. IANA Considerations............................................8 8. IANA Considerations .............................................8
9. Security Considerations........................................9 9. Security Considerations .........................................8
10. Acknowledgments...............................................9 10. Acknowledgments ................................................9
11. References...................................................10 11. References .....................................................9
11.1. Normative References....................................10 11.1. Normative References ......................................9
11.2. Informative References..................................10 11.2. Informative References ....................................9
Author's Addresses...............................................11
1. Introduction 1. Introduction
LDP [RFC5036] distributes labels for Forwarding Equivalence Classes LDP [RFC5036] distributes labels for Forwarding Equivalence Classes
(FECs). LDP uses FEC TLVs in LDP messages to specify FECs. An LDP (FECs). LDP uses FEC TLVs in LDP messages to specify FECs. An LDP
FEC TLV includes 1 or more FEC Elements. A FEC element includes a FEC TLV includes one or more FEC elements. A FEC element includes a
FEC type and an optional type-dependent value. FEC type and an optional type-dependent value.
RFC5036 specifies two FEC types (Prefix and Wildcard), and other RFC 5036 specifies two FEC types (Prefix and Wildcard), and other
documents specify additional FEC types; e.g., see [RFC4447] [MLDP]. documents specify additional FEC types; e.g., see [RFC4447] and
[MLDP].
As specified by RFC5036, the Wildcard FEC Element refers to all FECs As specified by RFC 5036, the Wildcard FEC Element refers to all FECs
relative to an optional constraint. The only constraint RFC5036 relative to an optional constraint. The only constraint RFC 5036
specifies is one that limits the scope of the Wildcard FEC Element specifies is one that limits the scope of the Wildcard FEC Element to
to "all FECs bound to a given label". "all FECs bound to a given label".
The RFC5036 specification of the Wildcard FEC Element has the The RFC 5036 specification of the Wildcard FEC Element has the
following deficiencies which limit its utility: following deficiencies that limit its utility:
1) The Wildcard FEC Element is untyped. There are situations where 1) The Wildcard FEC Element is untyped. There are situations where
it would be useful to be able to refer to all FECs of a given it would be useful to be able to refer to all FECs of a given type
type (as another constraint). (as another constraint).
2) Use of the Wildcard FEC Element is limited to Label Withdraw and 2) Use of the Wildcard FEC Element is limited to Label Withdraw and
Label Release messages only. There are situations where it would Label Release messages only. There are situations where it would
be useful to have Wildcard FEC Element, with type constraint, in be useful to have a Wildcard FEC Element, with type constraint, in
Label Request messages. Label Request messages.
This document: This document:
- Addresses the above limitations by defining a Typed Wildcard - addresses the above limitations by defining a Typed Wildcard FEC
FEC Element and procedures for its use. Element and procedures for its use.
- Specifies use of the LDP capability mechanism [RFC5561] at - specifies use of the LDP capability mechanism [RFC5561] at
session establishment time for informing a peer that an LDP session establishment time for informing a peer that an LDP
speaker is capable of handling the Typed Wildcast FEC. speaker is capable of handling the Typed Wildcard FEC.
- Specifies use of Typed Wildcard FEC Element in Label Request - specifies use of the Typed Wildcard FEC Element in a Label
message. Request message.
- Specifies the Typed Wildcard FEC Element for the Prefix FEC - specifies the Typed Wildcard FEC Element for the Prefix FEC
Element specified by RFC5036. Element specified by RFC 5036.
Note that this document does not change procedures specified for the Note that this document does not change procedures specified for the
LDP Wildcard FEC Element by RFC5036. LDP Wildcard FEC Element by RFC 5036.
2. Specification Language 2. Specification Language
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
LDP - Label Distribution Protocol LDP - Label Distribution Protocol
FEC - Forwarding Equivalence Class FEC - Forwarding Equivalence Class
TLV - Type Length Value TLV - Type Length Value
LSR - Label Switch Router LSR - Label Switching Router
3. The Typed Wildcard FEC Element 3. The Typed Wildcard FEC Element
The Typed Wildcard FEC Element refers to all FECs of the specified The Typed Wildcard FEC Element refers to all FECs of the specified
type that meet the constraint. It specifies a 'FEC Element Type' and type that meet the constraint. It specifies a 'FEC Element Type' and
an optional constraint, which is intended to provide additional an optional constraint, which is intended to provide additional
information. information.
The format of the Typed Wildcard FEC Element is: The format of the Typed Wildcard FEC Element is:
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 2 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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Typed (IANA) | FEC Element | Len FEC Type | | | Typed (0x05) | FEC Element | Len FEC Type | |
| Wildcard | Type | Info | | | Wildcard | Type | Info | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
~ Additional FEC Type-specific Information ~ ~ Additional FEC Type-specific Information ~
| (Optional) | | (Optional) |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Typed Wildcard FEC Element Figure 1: Typed Wildcard FEC Element
where: Where:
Typed Wildcard : One octet FEC Element Type (to be assigned Typed Wildcard: One-octet FEC Element Type (0x05).
by IANA).
FEC Element Type : One octet FEC Element Type that specifies FEC Element Type: One-octet FEC Element Type that specifies the
the FEC Element Type to be wildcarded. Please see section 3.4.1 of FEC Element Type to be wildcarded. Please see Section 3.4.1 of
RFC5036. RFC 5036.
Any (future) document specifying new FEC Element Type (not Any (future) document specifying a new FEC Element Type (not
defined in RFC5630) should prescribe whether typed wildcarding defined in RFC 5036) should prescribe whether typed
is needed for that FEC Element Type. wildcarding is needed for that FEC Element Type.
Len FEC Type Info : One octet that specifies the length in Len FEC Type Info: One octet that specifies the length in octets
octets of the FEC Type Specific information field. It MUST be set of the FEC Type Specific information field. It MUST be set to
to 0 if there is no Additional FEC Type-specific Information. 0 if there is no Additional FEC Type-specific Information.
Additional FEC Type-specific Information: (Optional) Additional Additional FEC Type-specific Information (Optional): Additional
information specific to the FEC Element Type required to fully information that is specific to the FEC Element Type and that
specify the Typed Wildcard. If this field is absent, then all FECs is required to fully specify the Typed Wildcard. If this field
of the specified FEC Type would be matched. is absent, then all FECs of the specified FEC Type would be
matched.
Any (future) document specifying Typed wildcarding for any FEC Any (future) document specifying Typed wildcarding for any
Element Type should also specify the length and format of FEC Element Type should also specify the length and format
Additional FEC Type Specific Information, if included. of Additional FEC Type Specific Information, if included.
This document specifies one FEC Element Type instance (e.g. Prefix This document specifies one FEC Element Type instance (e.g., Prefix
FEC) for the 'Typed Wildcard FEC Element' in section 6. FEC) for the 'Typed Wildcard FEC Element' in Section 6.
4. Procedures for the Typed Wildcard FEC Element 4. Procedures for the Typed Wildcard FEC Element
When a FEC TLV contains a Typed Wildcard FEC Element, the Typed When a FEC TLV contains a Typed Wildcard FEC Element, the Typed
Wildcard FEC Element MUST be the only FEC Element in the TLV. If an Wildcard FEC Element MUST be the only FEC Element in the TLV. If an
LDP speaker receives a FEC TLV containing Typed Wildcard FEC Element LDP speaker receives a FEC TLV containing a Typed Wildcard FEC
and any other FEC Elements, then the LDP speaker should ignore the Element and any other FEC elements, then the LDP speaker should
other FEC Elements and continue processing as if the message had ignore the other FEC elements and continue processing as if the
contained only the Typed Wildcard FEC Element. message only contains the Typed Wildcard FEC Element.
An LDP implementation that supports the Typed Wildcard FEC Element An LDP implementation that supports the Typed Wildcard FEC Element
MUST support its use in Label Request, Label Withdraw and Label MUST support its use in Label Request, Label Withdraw, and Label
Release messages. Release messages.
An LDP implementation that supports the Typed Wildcard FEC Element An LDP implementation that supports the Typed Wildcard FEC Element
MUST support it for every FEC Element Type implemented for which it MUST support it for every FEC Element Type defined in [RFC5036].
is defined.
Receipt of a Label Request message with a FEC TLV containing a Typed Receipt of a Label Request message with a FEC TLV containing a Typed
Wildcard FEC Element is interpreted as a request to send one or more Wildcard FEC Element is interpreted as a request to send one or more
Label Mappings for all FECs of the type specified by the FEC Element Label Mappings for all FECs of the type specified by the FEC Element
Type field in the Typed Wildcard FEC Element encoding. Type field in the Typed Wildcard FEC Element encoding.
An LDP implementation that supports the Typed Wildcard FEC Element An LDP implementation that supports the Typed Wildcard FEC Element
MUST support the following constraints whenever a Typed Wildcard FEC MUST support the following constraints whenever a Typed Wildcard FEC
appears in a Label Withdraw or Label Release message: appears in a Label Withdraw or Label Release message:
1) If the message carries an optional Label TLV the Typed Wildcard 1) If the message carries an optional Label TLV, the Typed Wildcard
FEC Element refers to all FECs of the specified FEC type bound to FEC Element refers to all FECs of the specified FEC type bound to
the specified label. the specified label.
2) If the message has no Label TLV the Typed Wildcard FEC Element 2) If the message has no Label TLV, the Typed Wildcard FEC Element
refers to all FECs of the specified FEC type. refers to all FECs of the specified FEC type.
Backwards compatibility with a router not supporting the Typed Backwards compatibility with a router not supporting the Typed
Wildcard FEC element is ensured by the FEC procedures defined in Wildcard FEC element is ensured by the FEC procedures defined in RFC
RFC5036. Quoting from RFC5036: 5036. Quoting from RFC 5036:
"If it" [an LSR] "encounters a FEC Element type it cannot decode, If it [an LSR] encounters a FEC Element type it cannot decode, it
it SHOULD stop decoding the FEC TLV, abort processing the message SHOULD stop decoding the FEC TLV, abort processing the message
containing the TLV, and send an "Unknown FEC" Notification message containing the TLV, and send an "Unknown FEC" Notification message
to its LDP peer signaling an error." to its LDP peer signaling an error.
A router receiving a FEC TLV containing a Typed Wildcard FEC element A router receiving a FEC TLV containing a Typed Wildcard FEC element
for a FEC Element Type that it either doesn't support or for a FEC for either a FEC Element Type that it doesn't support or for a FEC
Element Type that doesn't support the use of wildcarding, MUST stop Element Type that doesn't support the use of wildcarding, MUST stop
decoding the FEC TLV, abort processing the message containing the decoding the FEC TLV, abort processing the message containing the
TLV, and send an "Unknown FEC" Notification message to its LDP peer TLV, and send an "Unknown FEC" Notification message to its LDP peer
signaling an error. to signal an error.
5. Typed Wildcard FEC Capability A router receiving a FEC TLV containing a Typed Wildcard FEC element
MAY also leverage mechanisms defined in [RFC5919] (say, if it had
zero label binding for the requested FEC type, etc.).
As noted above, RFC5056 FEC procedures provide for backward 5. Typed Wildcard FEC Capability
As noted above, RFC 5036 FEC procedures provide for backward
compatibility with an LSR not supporting the Typed Wildcard FEC compatibility with an LSR not supporting the Typed Wildcard FEC
Element. However, they don't provide means for LSR wishing to use Element. However, they don't provide means for an LSR that wishes to
the Typed Wildcard FEC Element to determine whether a peer supports use the Typed Wildcard FEC Element to determine whether a peer
it other than to send a message that uses the FEC Element and to supports it other than to send a message that uses the FEC Element
wait and see how the peer responds. and to wait and see how the peer responds.
An LDP speaker that supports the Typed Wildcard FEC Element MUST An LDP speaker that supports the Typed Wildcard FEC Element MUST
inform its peers of the support by including a Typed Wildcard FEC inform its peers of the support by including a Typed Wildcard FEC
Element Capability Parameter [RFC5561] in its Initialization Element Capability Parameter [RFC5561] in its Initialization messages
messages. only.
The Capability Parameter for the Typed Wildcard FEC capability is a The Capability Parameter for the Typed Wildcard FEC capability is a
TLV with the following format: TLV with the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Typed WCard FEC Cap (IANA)| Length | |U|F|Typed WCard FEC Cap(0x050B)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |S| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 2 Typed Wildcard FEC Capability format Figure 2: Typed Wildcard FEC Capability Format
Where: Where:
U and F bits : MUST be 1 and 0 respectively as per U and F bits: MUST be 1 and 0, respectively, as per Section 3 of
section 3 of LDP Capabilities [RFC5561]. LDP Capabilities [RFC5561].
Typed WCard FEC Cap : TLV code point to be assigned by IANA. Typed WCard FEC Cap: 0x050B
S-bit : MUST be 1 (indicates that capability is Length: Two octets. It MUST be set to 0x0001.
being advertised).
6. Typed Wildcard FEC Element for Prefix FEC Element S-bit: MUST be 1 (indicates that capability is being advertised).
RFC5036 defines the Prefix FEC Element but it does not specify a 6. Typed Wildcard FEC Element for Prefix FEC Element
Typed Wildcard for it. This section specifies the Typed Wildcard
FEC Element for Prefix FEC Elements. RFC 5036 defines the Prefix FEC Element, but it does not specify a
Typed Wildcard for it. This section specifies the Typed Wildcard FEC
Element for Prefix FEC Elements.
The format of the Prefix FEC Typed Wildcard FEC Element ("Prefix FEC The format of the Prefix FEC Typed Wildcard FEC Element ("Prefix FEC
Wildcard" for short), based on Figure 1, is: Wildcard" for short), based on Figure 1, is:
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 2 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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Typed Wcard | Type = Prefix | Len = 2 | Address... | | Typed Wcard | Type = Prefix | Len = 2 | Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Family | | ...Family |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3 Format of Prefix FEC Element using Typed Wildcard Figure 3: Format of Prefix FEC Element Using Typed Wildcard
Where: Where:
FEC Element Type : "Prefix" FEC Element (0x02, per RFC5036). FEC Element Type: "Prefix" FEC Element (0x02, per RFC 5036).
Len FEC Type Info : Two octets (=0x02). Len FEC Type Info: Two octets. It MUST be set to 0x0002.
Address Family : Two octet quantity containing a value from Address Family: Two-octet quantity containing a value from the
ADDRESS FAMILY NUMBERS in [IANA-AF]. "ADDRESS FAMILY NUMBERS" registry on http://www.iana.org.
The procedures described in Section 4 apply to the Prefix FEC The procedures described in Section 4 apply to the Prefix FEC
Wildcard processing. Wildcard processing.
7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements 7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements
There is no need to specify Typed Wildcard FEC Elements for the Host There is no need to specify Typed Wildcard FEC Elements for the Host
FEC Element specified by [RFC3036], nor for the Wildcard FEC Element FEC Element specified by [RFC3036], nor for the Wildcard FEC Element
specified by RFC5036. The [RFC3036] Host FEC Element has been specified by RFC 5036. The [RFC3036] Host FEC Element has been
removed from RFC5036, and the Wildcard FEC Element is untyped by removed from RFC 5036, and the Wildcard FEC Element is untyped by
definition. definition.
In other words, the 'FEC Element Type' field in 'Typed Wildcard FEC In other words, the 'FEC Element Type' field in 'Typed Wildcard FEC
Element' MUST NOT be 0x01. Element' MUST NOT be either 0x01 or 0x03.
8. IANA Considerations 8. IANA Considerations
This draft introduces a new LDP FEC Element Type and a new LDP This document introduces a new LDP FEC Element Type and a new LDP
Capability both of which require IANA assignment - Capability, both of which have been assigned by IANA.
The 'Typed Wildcard' FEC Element requires a code point from the IANA has assigned a 'Typed Wildcard FEC Element' code point (0x05)
LDP FEC Type Name Space. [RFC5036] partitions the FEC Type Name from the LDP FEC Type Name Space. [RFC5036] partitions the FEC
Space into 3 regions: IETF Consensus region, First Come First Type Name Space into 3 regions: IETF Consensus region, First Come
Served region, and Private Use region. The authors recommend First Served region, and Private Use region. The code point 0x05
that the code point 0x05 from the IETF Consensus range be is from the IETF Consensus range.
assigned to the 'Typed Wildcard' FEC Element.
The 'Typed Wildcard FEC' Capability requires a code point from IANA has assigned a 'Typed Wildcard FEC Capability' code point
the TLV Type name space. [RFC5036] partitions the TLV TYPE name (0x050B) from the TLV Type name space. [RFC5036] partitions the
space into 3 regions: IETF Consensus region, Vendor Private Use TLV TYPE name space into 3 regions: IETF Consensus region, Vendor
region, and Experimental Use region. The authors recommend that Private Use region, and Experimental Use region. The code point
a code point from the IETF Consensus range be assigned to the 0x050B is from the IETF Consensus range.
'Typed Wildcard FEC' Capability.
9. Security Considerations 9. Security Considerations
No security considerations beyond those that apply to the base LDP No security considerations beyond those that apply to the base LDP
specification [RFC5036] and further described in [MPLSsec] apply to specification [RFC5036] and that are further described in [RFC5920]
use of the Typed Wildcard FEC Elements as described in this apply to use of the Typed Wildcard FEC Elements as described in this
document. document.
One could deduce that the security exposure is reduced by this One could deduce that the security exposure is reduced by this
document, since an LDP speaker using Typed Wildcard FEC Element document, since an LDP speaker using the Typed Wildcard FEC Element
could use a single message to request, withdraw or release all the could use a single message to request, withdraw, or release all the
label mappings of a particular type (a particular AFI, for example), label mappings of a particular type (a particular Address Family
whereas an LDP speaker using Wildcard FEC Element, as defined in Identifier (AFI), for example), whereas an LDP speaker using the
based LDP specification [RFC5036], could use a single message to Wildcard FEC Element, as defined in the base LDP specification
request, withdraw or release all the label mappings of all types [RFC5036], could use a single message to request, withdraw, or
(all AFIs, for example). release all the label mappings of all types (all AFIs, for example).
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Yakov Rekhter for suggesting that The authors would like to thank Yakov Rekhter for suggesting that the
the limitations of the Wildcard FEC be addressed. Also, thanks to limitations of the Wildcard FEC be addressed. Also, thanks to Adrian
Adrian Farrel and Richard L. Barnes for extensive review of this Farrel, Kamran Raza, and Richard L. Barnes for extensive review of
document. this document.
This document was prepared using 2-Word-v2.0.template.dot. 11. References
11. References 11.1. Normative References
11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
Requirement Levels", BCP 14, RFC 2119, March 1997. "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Specification", RFC 5036, October 2007. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5561] Thomas, B., Aggarwal, S., Aggarwal, R., Le Roux, J.L., 11.2. Informative References
"LDP Capabilities", RFC5561, May 2007.
11.2. Informative References [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
Thomas, B., "LDP Specification", RFC 3036, January 2001. G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447] Martini, L., Editor, "Pseudowire Setup and Maintenance [RFC5919] Asati, R., Mohapatra, P., Minei, I., and B. Thomas,
Using the label Distribution Protocol (LDP)", RFC4447, "Signaling LDP Label Advertisement Completion", RFC 5919,
April 2006. August 2010.
[MLDP] Minei, I., Wijnands, I., Editors, "Label Distribution [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Protocol Extensions for Point-to-Multipoint and Networks", RFC 5920, July 2010.
Multipoint-to-Multipoint Label Switched Paths", draft-
ietf-mpls-ldp-p2mp-08.txt, Work in Progress, Oct 2009.
[MPLSsec] Fang, L., "Security Framework for MPLS and GMPLS [MLDP] Minei, I., Ed., Kompella, K., Wijnands, I., Ed., and B.
Networks", draft-ietf-mpls-mpls-and-gmpls-security- Thomas, "Label Distribution Protocol Extensions for Point-
framework-07, Work in Progress, Oct 2009. to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", Work in Progress, July 2010.
[IANA-AF] http://www.iana.org/assignments/address-family-numbers. Authors' Addresses
Author's Addresses Rajiv Asati
Cisco Systems
7025-6 Kit Creek Rd.
Research Triangle Park, NC 27709-4987
EMail: rajiva@cisco.com
Ina Minei Ina Minei
Juniper Networks Juniper Networks
1194 North Mathilda Ave. 1194 North Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: ina@juniper.net EMail: ina@juniper.net
Bob Thomas Bob Thomas
Email: bobthomas@alum.mit.edu EMail: bobthomas@alum.mit.edu
Rajiv Asati
Cisco Systems,
7025-6 Kit Creek Rd, RTP, NC, 27709-4987
Email: rajiva@cisco.com
 End of changes. 92 change blocks. 
232 lines changed or deleted 239 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/