draft-ietf-mpls-ldp-typed-wildcard-04.txt   draft-ietf-mpls-ldp-typed-wildcard-05.txt 
MPLS Working Group Bob Thomas MPLS Working Group Rajiv Asati
Internet Draft Internet Draft Cisco Systems
Intended status: Standards Track Intended status: Standards Track
Expires: Feb 2010 Ina Minei Expires: July 2010 Ina Minei
Juniper Networks Juniper Networks
Rajiv Asati Bob Thomas
Cisco Systems
September 5, 2009 January 25, 2010
LDP Typed Wildcard FEC LDP Typed Wildcard FEC
draft-ietf-mpls-ldp-typed-wildcard-04.txt draft-ietf-mpls-ldp-typed-wildcard-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with
provisions of BCP 78 and BCP 79. This document may contain material the provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
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
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference 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. This Internet-Draft will expire on July 25, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the BSD License.
Abstract Abstract
The LDP specification [RFC5036] for the Wildcard FEC element has The Label Distribution Protocol (LDP) specification for the Wildcard
several deficiencies. This document corrects those deficiencies. In FEC element has several limitations. This document addresses those
addition, it specifies the Typed Wildcard FEC for the Prefix FEC limitations by defining a Typed Wildcard FEC element and associated
Element Type defined in RFC5036. procedures. In addition, it defines a new LDP capability to address
backward compatibility.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................2
2. Specification Language.........................................4 2. Specification Language.........................................3
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........................................8 9. Security Considerations........................................9
10. Acknowledgments...............................................8 10. Acknowledgments...............................................9
11. References....................................................9 11. References...................................................10
11.1. Normative References.....................................9 11.1. Normative References....................................10
11.2. Informative References...................................9 11.2. Informative References..................................10
Author's Addresses...............................................10 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 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 [RFC4447] [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
"all FECs bound to a given label". to "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 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.
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 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 limitations 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 [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 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
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
FEC - Forwarding Equivalence Class
TLV - Type Lenth Value
LSR - Label Switch Router
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
skipping to change at page 4, line 41 skipping to change at page 4, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Typed Wildcard FEC Element 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. It is defined in section 3.4.1
of RFC5036.
Len FEC Type Info: One octet that specifies the length of the FEC Len FEC Type Info: One octet that specifies the length in octets
Type Specific information field. MUST be 0 if there is no of the FEC Type Specific information field. It MUST be set to 0 if
Additional FEC Type-specific Information. there is no 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 It is the responsibility of the designer of the FEC Element Type
Specific Information for particular FEC Element Types is outside of to specify the length and format of any Additional FEC Type
the scope of this document. It is the responsibility of the Specific Information.
designer of the FEC Element Type to specify the length and format
of any Additional FEC Type Specific Information.
This document discusses two instances of Typed Wildcard FEC Elements This document specifies one FEC Element Type instance for the 'Typed
in section 6 and 7. Wildcard FEC Element' in section 6.
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 for the FEC Element
If typed wildcarding does make sense the specification for the FEC Type. If typed wildcarding does make sense, then the specification
Element Type MUST include support for it. for the FEC 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
responsibility of the designer to specify the length and format of the responsibility of the designer to specify the length and format
any Additional FEC Type Specific Information. of any Additional FEC Type Specific Information.
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. If an
LDP speaker receives a FEC TLV containing Typed Wildcard FEC Element
and any other FEC Elements, then the LDP speaker should ignore the
other FEC Elements and continue processing as if the message had
contained only 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 implemented for which it
is defined. 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 a Label Wildcard FEC Element is interpreted as a request to send one or more
Mapping for all FECs of the type specified by the FEC Element Type Label Mappings for all FECs of the type specified by the FEC Element
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
skipping to change at page 6, line 31 skipping to change at page 6, line 37
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 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 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
and see how the peer responds. 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.
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
skipping to change at page 7, line 17 skipping to change at page 7, line 20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Typed WCard FEC Cap (IANA)| Length | |U|F| Typed WCard FEC Cap (IANA)| 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 section U and F bits : MUST be 1 and 0 respectively as per
3 of LDP Capabilities [RFC5561]. section 3 of LDP Capabilities [RFC5561].
Typed WCard FEC Cap : TLV code point to be assigned by IANA. Typed WCard FEC Cap : TLV code point to be assigned by IANA.
S-bit : MUST be 1 (indicates that capability is S-bit : MUST be 1 (indicates that capability is
being advertised). 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
Element for Prefix FEC Elements. FEC 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 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 | Prefix (2) | 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:
Address Family: Two octet quantity containing a value from ADDRESS FEC Element Type : Prefix FEC Element (value=2, per RFC5036).
FAMILY NUMBERS in [IANA-AF].
The procedures of Section 4 apply to the Prefix FEC Wildcard. Len FEC Type Info : Two octets.
Address Family : Two octet quantity containing a value from
ADDRESS FAMILY NUMBERS in [IANA-AF].
The procedures described in Section 4 apply to the Prefix FEC
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 removed specified by RFC5036. The [RFC3036] Host FEC Element has been
from RFC5036, and the Wildcard FEC Element is untyped by definition. removed from RFC5036, and the Wildcard FEC Element is untyped by
definition.
In other words, the 'FEC Element Type' field in 'Typed Wildcard FEC
Element' can not be 0x01.
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 IANA assignment - Capability both of which require IANA assignment -
The 'Typed Wildcard' FEC Element requires a code point from the The 'Typed Wildcard' FEC Element requires a code point from the
LDP FEC Type Name Space. [RFC5036] partitions the FEC Type Name LDP FEC Type Name Space. [RFC5036] partitions the FEC Type Name
Space into 3 regions: IETF Consensus region, First Come First Space into 3 regions: IETF Consensus region, First Come First
Served region, and Private Use region. The authors recommend that Served region, and Private Use region. The authors recommend
the code point 0x05 from the IETF Consensus range be assigned to that the code point 0x05 from the IETF Consensus range be
the 'Typed Wildcard' FEC Element. assigned to the 'Typed Wildcard' FEC Element.
The 'Typed Wildcard FEC' Capability requires a code point from the The 'Typed Wildcard FEC' Capability requires a code point from
TLV Type name space. [RFC5036] partitions the TLV TYPE name space the TLV Type name space. [RFC5036] partitions the TLV TYPE name
into 3 regions: IETF Consensus region, First Come First Served space into 3 regions: IETF Consensus region, First Come First
region, and Private Use region. The authors recommend that a code Served region, and Private Use region. The authors recommend
point from the IETF Consensus range be assigned to the 'Typed that a code point from the IETF Consensus range be assigned to
Wildcard FEC' Capability. the '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 further described in [MPLSsec] apply to
use of the Typed Wildcard FEC Elements as described in this document. use of the Typed Wildcard FEC Elements as described in this
document.
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Yakov Rekhter for suggesting that the The authors would like to thank Yakov Rekhter for suggesting that
deficiencies of the Wildcard FEC be addressed. the limitations of the Wildcard FEC be addressed. Also, thanks to
Adrian Farrel for extensive review of this document.
This document was prepared using 2-Word-v2.0.template.dot. 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[RFC5561] Thomas, B., Aggarwal, S., Aggarwal, R., Le Roux, J.L., "LDP [RFC5561] Thomas, B., Aggarwal, S., Aggarwal, R., Le Roux, J.L.,
Capabilities", RFC5561, May 2007. "LDP Capabilities", RFC5561, May 2007.
11.2. Informative References 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.
[RFC4447] Martini, L., Editor, "Pseudowire Setup and Maintenance [RFC4447] Martini, L., Editor, "Pseudowire Setup and Maintenance
Using the label Distribution Protocol (LDP)", RFC4447, Using the label Distribution Protocol (LDP)", RFC4447,
April 2006. 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- Protocol Extensions for Point-to-Multipoint and
to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp- Multipoint-to-Multipoint Label Switched Paths", draft-
p2mp-07.txt, Work in Progress, July 2009. ietf-mpls-ldp-p2mp-08.txt, Work in Progress, Oct 2009.
[MPLSsec] Fang, L., "Security Framework for MPLS and GMPLS Networks", [MPLSsec] Fang, L., "Security Framework for MPLS and GMPLS
draft-ietf-mpls-mpls-and-gmpls-security-framework-06, Work Networks", draft-ietf-mpls-mpls-and-gmpls-security-
in Progress, July 13 2009. framework-07, Work in Progress, Oct 2009.
[IANA-AF] http://www.iana.org/assignments/address-family-numbers. [IANA-AF] http://www.iana.org/assignments/address-family-numbers.
Author's Addresses Author's Addresses
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
 End of changes. 40 change blocks. 
100 lines changed or deleted 115 lines changed or added

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