draft-ietf-mpls-ldp-typed-wildcard-03.txt   draft-ietf-mpls-ldp-typed-wildcard-04.txt 
MPLS Working Group Bob Thomas
Network Working Group Bob Thomas Internet Draft
Internet Draft Cisco Systems, Inc. Intended status: Standards Track
Expiration Date: September 2008 Expires: Feb 2010 Ina Minei
Intended Status: Proposed Standard Ina Minei
Juniper Networks Juniper Networks
LDP Typed Wildcard FEC
draft-ietf-mpls-ldp-typed-wildcard-03.txt Rajiv Asati
Cisco Systems
September 5, 2009
LDP Typed Wildcard FEC
draft-ietf-mpls-ldp-typed-wildcard-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow 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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
This Internet-Draft will expire on Feb 5, 2010.
Copyright Notice Copyright Notice
Copyright (C) The IETF TRUST (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
The LDP specification [RFC5036] for the Wildcard FEC element has The LDP specification [RFC5036] for the Wildcard FEC element has
several deficiencies. This document corrects those deficiencies. In several deficiencies. This document corrects those deficiencies. In
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 RFC5036. Element Type defined in RFC5036.
Table of Contents Table of Contents
1 Introduction ....................................... 2 1. Introduction...................................................3
2 Specification Language ............................. 3 2. Specification Language.........................................4
3 The Typed Wildcard FEC Element ..................... 3 3. The Typed Wildcard FEC Element.................................4
4 Procedures for the Typed Wildcard FEC Element ...... 4 4. Procedures for the Typed Wildcard FEC Element..................5
5 Typed Wildcard FEC Capability ...................... 5 5. Typed Wildcard FEC Capability..................................6
6 Typed Wildcard FEC Element for Prefix FEC Element .. 6 6. Typed Wildcard FEC Element for Prefix FEC Element..............7
7 Host FEC and Wildcard FEC Elements ................. 7 7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements..8
8 IANA Considerations ................................ 7 8. IANA Considerations............................................8
9 Security Considerations ............................ 7 9. Security Considerations........................................8
10 Acknowledgements ................................... 7 10. Acknowledgments...............................................8
11 References ......................................... 8 11. References....................................................9
12 Author Information ................................. 8 11.1. Normative References.....................................9
13 Intellectual Property Statement .................... 9 11.2. Informative References...................................9
14 Full Copyright Statement ........................... 9 Author's Addresses...............................................10
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 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.
RFC5036 specifies two FEC types (Prefix and Wildcard), and other RFC5036 specifies two FEC types (Prefix and Wildcard), and other
documents specify additional FEC types; e.g., see [PWE3] [MLDP]. documents specify additional FEC types; e.g., see [RFC4447] [MLDP].
As specified by RFC5036 the Wildcard FEC Element refers to all FECs As specified by RFC5036 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 RFC5036
specifies is one that limits the scope of the Wildcard FEC Element to specifies is one that limits the scope of the Wildcard FEC Element 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 RFC5036 specification of the Wildcard FEC Element has the
following deficiencies which limit its utility: following deficiencies which limit its utility:
1. The Wildcard FEC Element is untyped. There are situations 1) The Wildcard FEC Element is untyped. There are situations where
where it would be useful to be able to refer to all FECs of a it would be useful to be able to refer to all FECs of a given
given type. 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
and Label Release messages only. There are situations where it Label Release messages only. There are situations where it would
would be useful in Label Request messages. be useful in Label Request messages.
This document: This document:
- Addresses the above deficiencies by defining a Typed Wildcard - Addresses the above deficiencies by defining a Typed Wildcard
FEC Element and procedures for its use. FEC Element and procedures for its use.
- Specifies use of the LDP capability mechanism [LDPCap] 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 Wildcast FEC.
- 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 RFC5036.
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 RFC5036.
2. Specification Language 2. Specification Language
skipping to change at page 3, line 40 skipping to change at page 4, line 21
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
relative to an optional constraint. The constraint, if present, is relative to an optional constraint. The constraint, if present, is
determined from the context in which the Typed Wildcard FEC Element determined from the context in which the Typed Wildcard FEC Element
appears. appears.
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 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 (IANA) | FEC Element | Len FEC Type | |
| Wildcard | Type | Info | | | Wildcard | Type | Info | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
~ Additional FEC Type-specific Information ~ ~ Additional FEC Type-specific Information ~
| | | |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Typed Wildcard FEC Element
where: where:
Typed Wildcard: One octet FEC Element Type (to be assigned by Typed Wildcard: One octet FEC Element Type (to be assigned by
IANA). IANA).
FEC Element Type: One octet FEC Element Type that specifies the FEC Element Type: One octet FEC Element Type that specifies the
FEC Element Type to be wildcarded. FEC Element Type to be wildcarded.
Len FEC Type Info: One octet that specifies the length of the FEC Len FEC Type Info: One octet that specifies the length of the FEC
Type Specific information field. MUST be 0 if there is no Type Specific information field. MUST be 0 if there is no
Additional FEC Type-specific Information. Additional FEC Type-specific Information.
Additional FEC Type-specific Information: Additional information Additional FEC Type-specific Information: Additional information
specific to the FEC Element Type required to fully specify the specific to the FEC Element Type required to fully specify the
Typed Wildcard. Typed Wildcard.
Specification of the length and format of Additional FEC Type Specification of the length and format of Additional FEC Type
Specific Information for particular FEC Element Types is outside of Specific Information for particular FEC Element Types is outside of
the scope of this document. It is the responsibility of the designer the scope of this document. It is the responsibility of the
of the FEC Element Type to specify the length and format of any designer of the FEC Element Type to specify the length and format
Additional FEC Type Specific Information. of any Additional FEC Type Specific Information.
This document discusses two instances of Typed Wildcard FEC Elements
in section 6 and 7.
4. Procedures for the Typed Wildcard FEC Element 4. Procedures for the Typed Wildcard FEC Element
It is the responsibility of the designer of the FEC Element Type to It is the responsibility of the designer of the FEC Element Type to
determine whether typed wildcarding makes sense the FEC Element Type. determine whether typed wildcarding makes sense the FEC Element Type.
If typed wildcarding does make sense the specification for the FEC If typed wildcarding does make sense the specification for the FEC
Element Type MUST include support for it. Element Type MUST include support for it.
When typed wildcarding is supported for a FEC Element Type it is the When typed wildcarding is supported for a FEC Element Type it is the
responsibility of the designer to specify the length and format of responsibility of the designer to specify the length and format of
skipping to change at page 5, line 11 skipping to change at page 6, line 5
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 Mapping for all FECs of the type specified by the FEC Element Type
field in 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
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
RFC5036. Quoting from RFC5036: RFC5036. Quoting from RFC5036:
"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 SHOULD stop decoding the FEC TLV, abort processing the it SHOULD stop decoding the FEC TLV, abort processing the message
message containing the TLV, and send an "Unknown FEC" containing the TLV, and send an "Unknown FEC" Notification message
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 a FEC Element Type that it either 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. signaling an error.
5. Typed Wildcard FEC Capability 5. Typed Wildcard FEC Capability
As noted above RFC5056 FEC procedures provide for backward As noted above, RFC5056 FEC procedures provide for backward
compatibility with a LSR not supporting the Typed Wildcard FEC compatibility with a 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 LSR wishing to use
the Typed Wildcard FEC Element to determine whether a peer supports the Typed Wildcard FEC Element to determine whether a peer supports
it other than to send a message that uses the FEC Element and to wait it other than to send a message that uses the FEC Element and to wait
and see how the peer responds. 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 [LDPCap] in its Initialization messages. Element Capability Parameter [RFC5561] in its Initialization
messages.
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 (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |S| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
where: Figure 2 Typed Wildcard FEC Capability format
U and F bits: As specified by RFC5036. Where:
Typed WCard FEC Cap: TLV code point for the Typed Wildcard FEC U and F bits : MUST be 1 and 0 respectively as per section
capability (to be assigned by IANA). 3 of LDP Capabilities [RFC5561].
S-bit: Must be 1 (indicates that capability is being advertised). Typed WCard FEC Cap : TLV code point to be assigned by IANA.
S-bit : MUST be 1 (indicates that capability is
being advertised).
6. Typed Wildcard FEC Element for Prefix FEC Element 6. Typed Wildcard FEC Element for Prefix FEC Element
RFC5036 defines the Prefix FEC Element but it does not specify a RFC5036 defines the Prefix FEC Element but it does not specify a
Typed Wildcard for it. This section specifies the Typed Wildcard FEC Typed Wildcard for it. This section specifies the Typed Wildcard FEC
Element for Prefix FEC Elements. Element for Prefix FEC Elements.
The format of the Prefix FEC Typed Wildcard FEC ("Prefix FEC The format of the Prefix FEC Typed Wildcard FEC ("Prefix FEC
Wildcard" for short) is: Wildcard" for short) 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 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 | Prefix (2) | 2 | Address... | | Typed Wcard | Prefix (2) | 2 | Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Family | | ...Family |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3 Format of Prefix FEC Element using Typed Wildcard
Where:
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.
7. Host FEC 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 RFC5036. The [RFC3036] Host FEC Element has been removed
removed from RFC5036, and the Wildcard FEC Element is untyped by from RFC5036, and the Wildcard FEC Element is untyped by definition.
definition.
8. IANA Considerations 8. IANA Considerations
This draft introduces a new LDP FEC Element Type and a new LDP This draft introduces a new LDP FEC Element Type and a new LDP
Capability both of which require code points. Capability both of which require IANA assignment -
The Typed Wildcard FEC Element requires a code point from the LDP FEC The 'Typed Wildcard' FEC Element requires a code point from the
Type name space. [RFC5036] partitions the FEC TYPE name space into 3 LDP FEC Type Name Space. [RFC5036] partitions the FEC Type Name
regions: IETF Consensus region, First Come First Served region, and Space into 3 regions: IETF Consensus region, First Come First
Private Use region. The authors recommend that the code point 0x05 Served region, and Private Use region. The authors recommend that
from the IETF Consensus range be assigned to the Typed Wildcard FEC the code point 0x05 from the IETF Consensus range be assigned to
Element. the 'Typed Wildcard' FEC Element.
The Typed Wildcard FEC Capability requires a code point from the TLV The 'Typed Wildcard FEC' Capability requires a code point from the
Type name space. [RFC5036] partitions the TLV TYPE name space into 3 TLV Type name space. [RFC5036] partitions the TLV TYPE name space
regions: IETF Consensus region, First Come First Served region, and into 3 regions: IETF Consensus region, First Come First Served
Private Use region. The authors recommend that a code point from the region, and Private Use region. The authors recommend that a code
IETF Consensus range be assigned to the Typed Wildcard FEC point from the IETF Consensus range be assigned to the 'Typed
Capability. 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 and described in [RFC5036] apply to use of the Typed specification [RFC5036] and further described in [MPLSsec] apply to
Wildcard FEC Element defined in this document. use of the Typed Wildcard FEC Elements as described in this document.
10. Acknowledgements 10. Acknowledgments
The authors wish to thank Yakov Rehkter for suggesting that the The authors would like to thank Yakov Rekhter for suggesting that the
deficiencies of the Wildcard FEC be addressed. deficiencies of the Wildcard FEC be addressed.
11. References This document was prepared using 2-Word-v2.0.template.dot.
Normative References 11. References
[RFC5036] Andersson, L., Minei, I., Thomas, B., Editors, "LDP 11.1. Normative References
Specification", RFC 5036, October 2007.
[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.
[LDPCap] Thomas, B., Aggarwal, S., Aggarwal, R., Le Roux, J.L., [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP
"LDP Capabilities", draft-ietf-mpls-ldp-capabilities-01, Work in Specification", RFC 5036, October 2007.
Progress, February 2008.
Informative References [RFC5561] Thomas, B., Aggarwal, S., Aggarwal, R., Le Roux, J.L., "LDP
Capabilities", RFC5561, May 2007.
11.2. Informative 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.
[PWE3] Martini, L., Editor, "Pseudowire Setup and Maintenance Using [RFC4447] Martini, L., Editor, "Pseudowire Setup and Maintenance
the Label Distribution Protocol (LDP)", RFC 4447, April 2006. Using the label Distribution Protocol (LDP)", RFC4447,
April 2006.
[MLDP] Minei, I., Wijnands, I., Editors, "Label Distribution [MLDP] Minei, I., Wijnands, I., Editors, "Label Distribution
Protocol Extensions for Point-to-Multipoint and Multipoint-to- Protocol Extensions for Point-to-Multipoint and Multipoint-
Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp-04.txt, to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp-
Work in Progress, February 2008. p2mp-07.txt, Work in Progress, July 2009.
[IANA-AF] http://www.iana.org/assignments/address-family-numbers [MPLSsec] Fang, L., "Security Framework for MPLS and GMPLS Networks",
draft-ietf-mpls-mpls-and-gmpls-security-framework-06, Work
in Progress, July 13 2009.
12. Author Information [IANA-AF] http://www.iana.org/assignments/address-family-numbers.
Bob Thomas Author's Addresses
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough MA 01719
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
13. Intellectual Property Statement Bob Thomas
Email: bobthomas@alum.mit.edu
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
14. Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an Rajiv Asati
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS Cisco Systems,
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 7025-6 Kit Creek Rd, RTP, NC, 27709-4987
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, Email: rajiva@cisco.com
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
 End of changes. 47 change blocks. 
126 lines changed or deleted 132 lines changed or added

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