draft-ietf-mpls-ldp-typed-wildcard-00.txt   draft-ietf-mpls-ldp-typed-wildcard-01.txt 
Network Working Group Bob Thomas Network Working Group Bob Thomas
Internet Draft Cisco Systems, Inc. Internet Draft Cisco Systems, Inc.
Expiration Date: November 2007
Ina Minei Ina Minei
Juniper Networks Juniper Networks
January 2007
LDP Typed Wildcard FEC LDP Typed Wildcard FEC
draft-ietf-mpls-ldp-typed-wildcard-00.txt draft-ietf-mpls-ldp-typed-wildcard-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
addition, it specifies the Typed Wildcard FEC for the Prefix FEC addition, it specifies the Typed Wildcard FEC for the Prefix FEC
Element Type defined in RFC3036. Element Type defined in RFC3036.
Table of Contents Table of Contents
1 Introduction .......................................... 2 1 Introduction .......................................... 2
2 Specification Language ................................ 3 2 Specification Language ................................ 3
3 The Typed Wildcard FEC Element ........................ 3 3 The Typed Wildcard FEC Element ........................ 3
4 Procedures for the Typed Wildcard FEC Element ......... 4 4 Procedures for the Typed Wildcard FEC Element ......... 4
5 Typed Wildcard FEC Element for RFC3036 Prefix FEC Element 5 5 Typed Wildcard FEC Element for RFC3036 Prefix FEC Element 5
6 IANA Considerations ................................... 5 6 RFC3036 Host and Wildcard FEC Elements ................ 5
7 Security Considerations ............................... 6 7 IANA Considerations ................................... 5
8 Acknowledgements ...................................... 6 8 Security Considerations ............................... 6
9 References ............................................ 6 9 Acknowledgements ...................................... 6
10 Author Information .................................... 7 10 References ............................................ 6
11 Intellectual Property Statement ....................... 7 11 Author Information .................................... 7
12 Full Copyright Statement .............................. 8 12 Intellectual Property Statement ....................... 7
13 Full Copyright Statement .............................. 8
1. Introduction 1. Introduction
LDP [RFC3036] distributes labels for Forwarding Equivalence Classes LDP [RFC3036] 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 1 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.
RFC3036 specifies two FEC types (Wildcard and Prefix), and other RFC3036 specifies two FEC types (Wildcard and Prefix), and other
documents specify additional FEC types; e.g., see [PWE3] [MLDP]. documents specify additional FEC types; e.g., see [PWE3] [MLDP].
skipping to change at page 3, line 6 skipping to change at page 3, line 6
1. The Wildcard FEC Element is untyped. There are situations 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 where it would be useful to be able to refer to all FECs of a
given type. given type.
2. Use of the Wildcard FEC Element is limited to Label Withdraw 2. Use of the Wildcard FEC Element is limited to Label Withdraw
and Label Release messages only. There are situations where it and Label Release messages only. There are situations where it
would be useful in Label Request messages. would be useful in Label Request messages.
This document addresses these deficiencies by defining a Typed This document addresses these deficiencies by defining a Typed
Wildcard FEC Element and procedures for its use. Wildcard FEC Element and procedures for its use. Note that this
document does not change procedures specified for the LDP Wildcard
FEC Element by RFC3036.
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].
3. The Typed Wildcard FEC Element 3. The Typed Wildcard FEC Element
The Typed Wildcard FEC Element refers to all FECs of a given type The Typed Wildcard FEC Element refers to all FECs of a given type
skipping to change at page 4, line 24 skipping to change at page 4, line 26
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. Wildcard FEC Element MUST be the only FEC Element in the TLV.
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.
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 a Label Wildcard FEC Element is interpreted as a request to send a Label
Mapping for all FECs of the type specified by the FEC Element type in Mapping for all FECs of the type specified by the FEC Element type
the Typed Wildcard FEC Element encoding. 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
skipping to change at page 5, line 28 skipping to change at page 5, line 29
| Typed WCard | Prefix (2) | 2 | Address... | | Typed WCard | Prefix (2) | 2 | Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Family | | ...Family |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Address Family: Two octet quantity containing a value from ADDRESS Address Family: Two octet quantity containing a value from ADDRESS
FAMILY NUMBERS in [IANA-AF]. FAMILY NUMBERS in [IANA-AF].
The procedures of Section 4 apply to the Prefix FEC Wildcard. The procedures of Section 4 apply to the Prefix FEC Wildcard.
6. IANA Considerations 6. RFC3036 Host and Wildcard FEC Elements
There is no need to specify Typed Wildcard FEC Elements for the Host
and Wildcard FEC Elements specified by RFC3036. The RFC3036 Host FEC
Element has been removed from rfc3036bis [RFC3036bis], and the
Wildcard FEC Element is untyped by definition.
7. IANA Considerations
The Typed Wildcard FEC Element requires a code point from the LDP FEC The Typed Wildcard FEC Element requires a code point from the LDP FEC
Type Name Space. IANA manages the FEC TYPE name space as recommended Type Name Space. IANA manages the FEC TYPE name space as recommended
by the following from [RFC3036]: by the following from [RFC3036]:
"FEC Type Name Space "FEC Type Name Space
The range for FEC types is 0 - 255. The range for FEC types is 0 - 255.
Following the policies outlined in [RFC3036], FEC types in the Following the policies outlined in [RFC3036], FEC types in the
range 0 - 127 are allocated through an IETF Consensus action, range 0 - 127 are allocated through an IETF Consensus action,
types in the range 128 - 191 are allocated as First Come First types in the range 128 - 191 are allocated as First Come First
Served, and types in the range 192 - 255 are reserved for Private Served, and types in the range 192 - 255 are reserved for Private
Use." Use."
The authors recommend that the code point 0x04 from the IETF The authors recommend that the code point 0x05 from the IETF
Consensus range be assigned to the Typed Wildcard FEC Element. Consensus range be assigned to the Typed Wildcard FEC Element.
7. Security Considerations 8. 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 and described in [RFC3036] apply to use of the Typed specification and described in [RFC3036] apply to use of the Typed
Wildcard FEC Element defined in this document. Wildcard FEC Element defined in this document.
8. Acknowledgements 9. Acknowledgements
The authors wish to thank Yakov Rehkter for suggesting that the The authors wish to thank Yakov Rehkter for suggesting that the
deficiencies of the Wildcard FEC be addressed. deficiencies of the Wildcard FEC be addressed.
9. References 10. References
Normative References Normative References
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
Thomas, B., "LDP Specification", RFC 3036, January 2001. Thomas, B., "LDP Specification", RFC 3036, January 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997. Requirement Levels", BCP 14, RFC2119, March 1997.
[IANA-AF] http://www.iana.org/assignments/address-family-numbers [IANA-AF] http://www.iana.org/assignments/address-family-numbers
Informative References Informative References
[PWE3] Martini, L., Editor, "Pseudowire Setup and Maintenance Using [PWE3] Martini, L., Editor, "Pseudowire Setup and Maintenance Using
the Label Distribution Protocol (LDP)", RFC 4447, April 2006. the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[MLDP] Minei, I., Wijnamds, I., Editors, "Label Distribution [MLDP] Minei, I., Wijnamds, I., Editors, "Label Distribution
Protocol Extensions for Point-to-Multipoint and Multipoint-to- Protocol Extensions for Point-to-Multipoint and Multipoint-to-
Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp-00.txt, Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp-02.txt,
Work in Progress, June 2006. Work in Progress, October 2006.
10. Author Information [RFC3036bis] Andersson, L., Minei, I., Thomas, B., Editors, "LDP
Specification", draft-ietf-mpls-rfc3036bis-04.txt, Work in
Progress, September 2006.
11. Author Information
Bob Thomas Bob Thomas
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough MA 01719 Boxborough MA 01719
Email: rhthomas@cisco.com Email: rhthomas@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
11. Intellectual Property Statement 12. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
12. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST
 End of changes. 15 change blocks. 
25 lines changed or deleted 36 lines changed or added

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