draft-kompella-mpls-special-purpose-labels-02.txt | draft-kompella-mpls-special-purpose-labels-03.txt | |||
---|---|---|---|---|
Network Working Group K. Kompella | Network Working Group K. Kompella | |||
Internet-Draft Juniper Networks | Internet-Draft Juniper Networks | |||
Updates: 3032, 3038, 3209, 3811, 4182, L. Andersson | Updates: 3032, 3038, 3209, 3811 (if approved) L. Andersson | |||
4928, 5331, 5586, 5921, 5960, 6391, Huawei | Intended status: Standards Track Huawei | |||
6478, 6790 (if approved) A. Farrel | Expires: November 28, 2013 A. Farrel | |||
Intended status: Standards Track Juniper Networks | Juniper Networks | |||
Expires: September 16, 2013 March 15, 2013 | May 27, 2013 | |||
Allocating and Retiring Special Purpose MPLS Labels | Allocating and Retiring Special Purpose MPLS Labels | |||
draft-kompella-mpls-special-purpose-labels-02 | draft-kompella-mpls-special-purpose-labels-03 | |||
Abstract | Abstract | |||
Some MPLS labels have been allocated for specific purposes. A block | Some MPLS labels have been allocated for specific purposes. A block | |||
of labels (0-15) has been set aside to this end, and are commonly | of labels (0-15) has been set aside to this end, and are commonly | |||
called "reserved labels". They will be called "special purpose | called "reserved labels". They will be called "special purpose | |||
labels" in this document. As there are only 16 of these labels, | labels" in this document. As there are only 16 of these labels, | |||
caution is needed in the allocation of new special purpose labels, | caution is needed in the allocation of new special purpose labels, | |||
yet at the same time allow forward progress when one is called for. | yet at the same time allow forward progress when one is called for. | |||
This memo defines some procedures to follow in the allocation and | This memo defines some procedures to follow in the allocation and | |||
retirement of special purpose labels, as well as a method to extend | retirement of special purpose labels, as well as a method to extend | |||
the special purpose label space. Finally, this memo renames the IANA | the special purpose label space. Finally, this memo renames the IANA | |||
registry for these labels to "Special Purpose MPLS Label Values", and | registry for these labels to "Special Purpose MPLS Label Values", and | |||
creates a new one called the "Extended Special Purpose MPLS Label | creates a new one called the "Extended Special Purpose MPLS Label | |||
Values" registry. | Values" registry. | |||
Status of this Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
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." | |||
This Internet-Draft will expire on September 16, 2013. | This Internet-Draft will expire on November 28, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 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 respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Conventions used . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Conventions used . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3.1. Extended Special Purpose MPLS Label Values . . . . . . . . 5 | 3.1. Extended Special Purpose MPLS Label Values . . . . . . . 4 | |||
3.2. Process for Retiring Special Purpose Labels . . . . . . . 6 | 3.2. Process for Retiring Special Purpose Labels . . . . . . . 5 | |||
4. Updated RFCs . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 4. Updated RFCs . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 | |||
7.2. Informational References . . . . . . . . . . . . . . . . . 12 | 7.2. Informational References . . . . . . . . . . . . . . . . 8 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
1. Introduction | 1. Introduction | |||
The specification of the Label Stack Encoding for Multi-Protocol | The specification of the Label Stack Encoding for Multi-Protocol | |||
Label Switching (MPLS) [RFC3032] defined four special purpose label | Label Switching (MPLS) [RFC3032] defined four special purpose label | |||
values (0 to 3), and set aside values 4 through 15 for future use. | values (0 to 3), and set aside values 4 through 15 for future use. | |||
These labels have special significance in both the control and the | These labels have special significance in both the control and the | |||
data plane. Since then, three further values have been allocated | data plane. Since then, three further values have been allocated | |||
(values 7, 13, and 14 in [RFC6790], [RFC5586] and [RFC3429], | (values 7, 13, and 14 in [RFC6790], [RFC5586] and [RFC3429], | |||
respectively), leaving nine unassigned values from the original space | respectively), leaving nine unassigned values from the original space | |||
skipping to change at page 5, line 12 | skipping to change at page 3, line 44 | |||
5. What is a feasible mechanism to extend the space of special | 5. What is a feasible mechanism to extend the space of special | |||
purpose labels, should this become necessary? | purpose labels, should this become necessary? | |||
3. Answers | 3. Answers | |||
This section provides answers to the questions posed in the previous | This section provides answers to the questions posed in the previous | |||
section. | section. | |||
1. | 1. | |||
A. Allocation of special purpose MPLS labels is via "Standards | a. Allocation of special purpose MPLS labels is via "Standards | |||
Action". | Action". | |||
B. The IANA registry will be renamed "Special Purpose MPLS | b. The IANA registry will be renamed "Special Purpose MPLS | |||
Labels". | Labels". | |||
C. Early allocation may be allowed on a case-by-case basis. | c. Early allocation may be allowed on a case-by-case basis. | |||
D. The current space of 16 special purpose labels is too small | d. The current space of 16 special purpose labels is too small | |||
for setting aside value for experimental or private use. | for setting aside value for experimental or private use. | |||
However, the extended special purpose labels registry created | However, the extended special purpose labels registry created | |||
by this document has enough space, and this document defines | by this document has enough space, and this document defines | |||
a range for experimental use. | a range for experimental use. | |||
2. A Standards Track RFC must accompany a request for allocation of | 2. A Standards Track RFC must accompany a request for allocation of | |||
special purpose labels, as per [RFC5226]. | Standards Action special purpose labels, as per [RFC5226]. | |||
3. The retirement of a special purpose MPLS label value must follow | 3. The retirement of a special purpose MPLS label value must follow | |||
a strict and well-documented process. This is necessary since we | a strict and well-documented process. This is necessary since we | |||
must avoid orphaning the use of this label value in existing | must avoid orphaning the use of this label value in existing | |||
deployments. This process is detailed in Section 3.2. | deployments. This process is detailed in Section 3.2. | |||
4. The use of the "implicit null label" (label 3) in the data plane | 4. For now, the use of the "implicit null label" (label 3) in the | |||
may be allowed, subject to approval by the MPLS WG, and an | data plane will not be allowed. If this decision is revisited | |||
accompanying Standards Track RFC that details the use of the | later, an accompanying Standards Track RFC that details the use | |||
label, and a discussion of possible sources of confusion between | of the label, a discussion of possible sources of confusion | |||
signaling and data plane, and mitigation thereof. | between signaling and data plane, and mitigation thereof. | |||
5. The special purpose label (the "extension" label) is to be set | 5. A special purpose label (the "extension" label, label 15) is to | |||
aside for the purpose of extending the space of special purpose | be set aside for the purpose of extending the space of special | |||
labels. Further details are described in Section 3.1. | purpose labels. Further details are described in Section 3.1. | |||
A further question to be settled in this regard is whether a | A further question to be settled in this regard is whether a | |||
"regular" special purpose label retains its meaning if it follows the | "regular" special purpose label retains its meaning if it follows the | |||
extension label; see Section 3.1. | extension label; see Section 3.1. | |||
3.1. Extended Special Purpose MPLS Label Values | 3.1. Extended Special Purpose MPLS Label Values | |||
An extension label MUST be followed by another label L (and thus MUST | An extension label MUST be followed by another label L (and thus MUST | |||
have the bottom-of-stack bit clear). L MUST be interpreted as an | have the bottom-of-stack bit clear). L MUST be interpreted as an | |||
"extended special purpose label" from a new registry created by this | "extended special purpose label" and interpreted as defined in a new | |||
document (see Section 5). Whether or not L has the bottom-of-stack | registry created by this document (see Section 5). Whether or not L | |||
bit set depends on whether other labels follow L. Only L is | has the bottom-of-stack bit set depends on whether other labels | |||
interpreted as an extended special purpose label; labels following L | follow L. The extension label only assigns special meaning to L. A | |||
are interpreted as normal. | label after L (if any) is parsed as usual, and thus may be a regular | |||
label, a special purpose label or (if prefixed by another extension | ||||
label) an extended special purpose label. | ||||
IANA is asked to set aside label value 15 as the extension label. | IANA is asked to set aside label value 15 as the extension label. | |||
The first 16 values of the extended special purpose label registry | Values 0-6 and 8-15 of the extended special purpose label registry | |||
are duplicated from the pre-existing special purpose label registry. | are set aside as reserved; these MUST NOT appear in the data plane. | |||
This includes the previously allocated values (0-3, 7, 13, and 14), | Label 7 (when received) retains its meaning as ELI whether a regular | |||
the extension label value (15) allocated by this document, and the | or an extended special purpose label; however, an implementation | |||
remaining unallocated values (4-6 and 8-12). Any of these values | SHOULD NOT insert a label of 7 as an extended special purpose label, | |||
present as an extended special purpose label MUST be interpreted | preferring instead to send 7 as a regular special purpose label. | |||
exactly as it would if it was presented as a special purpose label. | ||||
In particular, an arbitrary string of consecutive extension labels is | ||||
legal, and semantically equivalent to a single extension label (note | ||||
that this string of extension labels MUST be followed by an extended | ||||
special purpose label that is not the extension label). | ||||
3.2. Process for Retiring Special Purpose Labels | 3.2. Process for Retiring Special Purpose Labels | |||
While the following process is defined for the sake of completeness, | ||||
note that retiring special purpose labels is difficult. It is | ||||
recommended that this process be used sparingly. | ||||
a. A label value that has been assigned from the "Special Purpose | a. A label value that has been assigned from the "Special Purpose | |||
MPLS Label Values" may be deprecated by IETF consensus with | MPLS Label Values" may be deprecated by IETF consensus with | |||
review by the MPLS working group (or designated experts if the | review by the MPLS working group (or designated experts if the | |||
working group or a successor does not exist). An RFC with at | working group or a successor does not exist). An RFC with at | |||
least Informational status is required. | least Informational status is required. | |||
The RFC will direct the IANA to mark the label value as | The RFC will direct the IANA to mark the label value as | |||
"deprecated" in the registry, but will not release it at this | "deprecated" in the registry, but will not release it at this | |||
stage. | stage. | |||
skipping to change at page 8, line 14 | skipping to change at page 5, line 50 | |||
4. Updated RFCs | 4. Updated RFCs | |||
The following RFCs contain references to the term "reserved labels": | The following RFCs contain references to the term "reserved labels": | |||
[RFC3032] ("MPLS Label Stack Encoding"), [RFC3038] ("VCID | [RFC3032] ("MPLS Label Stack Encoding"), [RFC3038] ("VCID | |||
Notification for LDP"), [RFC3209] ("Extensions to RSVP for LSP | Notification for LDP"), [RFC3209] ("Extensions to RSVP for LSP | |||
Tunnels"), [RFC3811] ("MPLS TC MIB"), [RFC4182] ("Removing a | Tunnels"), [RFC3811] ("MPLS TC MIB"), [RFC4182] ("Removing a | |||
Restriction on the use of MPLS"), [RFC4928] ("Avoiding ECMP Treatment | Restriction on the use of MPLS"), [RFC4928] ("Avoiding ECMP Treatment | |||
in MPLS Networks"), [RFC5331], [RFC5586] ("G-ACh and GAL"), [RFC5921] | in MPLS Networks"), [RFC5331], [RFC5586] ("G-ACh and GAL"), [RFC5921] | |||
("MPLS Transport Profile Framework"), [RFC5960] ("MPLS-TP Data Plane | ("MPLS Transport Profile Framework"), [RFC5960] ("MPLS-TP Data Plane | |||
Architecture"), [RFC6790] ("MPLS Entropy Labels"), [RFC6391] | Architecture"), [RFC6790] ("MPLS Entropy Labels"), [RFC6391] ("FAT- | |||
("FAT-PW"), and [RFC6478] ("Pseudowire Status for Static | PW"), and [RFC6478] ("Pseudowire Status for Static Pseudowires"). | |||
Pseudowires"). All such references should be read as "special | All such references should be read as "special purpose labels". | |||
purpose labels". | ||||
5. IANA Considerations | 5. IANA Considerations | |||
This document requests IANA to make the following changes and | This document requests IANA to make the following changes and | |||
additions to its registration of MPLS Labels. | additions to its registration of MPLS Labels. | |||
1. Change the name of the "Multiprotocol Label Switching | 1. Change the name of the "Multiprotocol Label Switching | |||
Architecture (MPLS) Label Values" registry to the "Special | Architecture (MPLS) Label Values" registry to the "Special | |||
Purpose MPLS Label Values". | Purpose MPLS Label Values". | |||
skipping to change at page 9, line 32 | skipping to change at page 6, line 32 | |||
4. Assign label 15 from the "Special Purpose MPLS Label Values" | 4. Assign label 15 from the "Special Purpose MPLS Label Values" | |||
registry, naming it the "extension label", and citing this | registry, naming it the "extension label", and citing this | |||
document as the reference. | document as the reference. | |||
5. Create a new registry called the "Extended Special Purpose MPLS | 5. Create a new registry called the "Extended Special Purpose MPLS | |||
Label Values" registry. The ranges and allocation policies for | Label Values" registry. The ranges and allocation policies for | |||
this registry are as follows (using terminology from [RFC5226]). | this registry are as follows (using terminology from [RFC5226]). | |||
Early allocation following the policy defined in [RFC4020] is | Early allocation following the policy defined in [RFC4020] is | |||
allowed only for those values assigned by Standards Action. | allowed only for those values assigned by Standards Action. | |||
+---------------------+---------------------------------------------+ | +------------------+------------------------------------------------+ | |||
| Range | Allocation Policy | | | Range | Allocation Policy | | |||
+---------------------+---------------------------------------------+ | +------------------+------------------------------------------------+ | |||
| 0, 1, 2, 3, 7, 13, | Reserved. Not to be allocated. Meaning is | | | 0 - 6, 8 - 15 | Reserved. Not to be allocated. MUST NOT | | |||
| 14, 15 | defined by values in the "Special Purpose | | | | appear in the data plane. | | |||
| | MPLS Label Values" registry. | | | | | | |||
| | | | | 7 | Allocated; meaning is ELI [RFC6790] | | |||
| 4, 5, 6, 8, 9, 10, | Standards Action (see Note) | | | | | | |||
| 11, 12 | | | | 16 - TBD1 | Standards Action | | |||
| | | | | | | | |||
| 16 - 1048559 | Standards Action | | | TBD1+1 - TBD2 | Reserved | | |||
| | | | | | | | |||
| 1048560 - 1048575 | Experimental | | | TBD2+1 - 1048559 | First Come, First Served | | |||
+---------------------+---------------------------------------------+ | | | | | |||
| 1048560 - | Experimental | | ||||
| 1048575 | | | ||||
+------------------+------------------------------------------------+ | ||||
Table 1 | Table 1 | |||
6. Security Considerations | 6. Security Considerations | |||
This document does not make a large change to the operation of the | This document does not make a large change to the operation of the | |||
MPLS data plane and security considerations are largely unchanged | MPLS data plane and security considerations are largely unchanged | |||
from those specified in the MPLS architecture [RFC3031] and in the | from those specified in the MPLS architecture [RFC3031] and in the | |||
MPLS and GMPLS Security Framework [RFC5920]. | MPLS and GMPLS Security Framework [RFC5920]. | |||
skipping to change at page 11, line 20 | skipping to change at page 7, line 33 | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | |||
Label Switching Architecture", RFC 3031, January 2001. | Label Switching Architecture", RFC 3031, January 2001. | |||
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., | [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., | |||
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack | Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack | |||
Encoding", RFC 3032, January 2001. | Encoding", RFC 3032, January 2001. | |||
[RFC3038] Nagami, K., Katsube, Y., Demizu, N., Esaki, H., and P. | [RFC3038] Nagami, K., Katsube, Y., Demizu, N., Esaki, H., and P. | |||
Doolan, "VCID Notification over ATM link for LDP", | Doolan, "VCID Notification over ATM link for LDP", RFC | |||
RFC 3038, January 2001. | 3038, January 2001. | |||
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | |||
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP | and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP | |||
Tunnels", RFC 3209, December 2001. | Tunnels", RFC 3209, December 2001. | |||
[RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual | [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual | |||
Conventions (TCs) for Multiprotocol Label Switching (MPLS) | Conventions (TCs) for Multiprotocol Label Switching (MPLS) | |||
Management", RFC 3811, June 2004. | Management", RFC 3811, June 2004. | |||
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of | [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of | |||
Standards Track Code Points", BCP 100, RFC 4020, | Standards Track Code Points", BCP 100, RFC 4020, February | |||
February 2005. | 2005. | |||
[RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS | [RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS | |||
Explicit NULL", RFC 4182, September 2005. | Explicit NULL", RFC 4182, September 2005. | |||
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal | [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal | |||
Cost Multipath Treatment in MPLS Networks", BCP 128, | Cost Multipath Treatment in MPLS Networks", BCP 128, RFC | |||
RFC 4928, June 2007. | 4928, June 2007. | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
May 2008. | May 2008. | |||
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream | [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream | |||
Label Assignment and Context-Specific Label Space", | Label Assignment and Context-Specific Label Space", RFC | |||
RFC 5331, August 2008. | 5331, August 2008. | |||
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS | [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS | |||
Networks", RFC 5920, July 2010. | Networks", RFC 5920, July 2010. | |||
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. | [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. | |||
Berger, "A Framework for MPLS in Transport Networks", | Berger, "A Framework for MPLS in Transport Networks", RFC | |||
RFC 5921, July 2010. | 5921, July 2010. | |||
[RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport | [RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport | |||
Profile Data Plane Architecture", RFC 5960, August 2010. | Profile Data Plane Architecture", RFC 5960, August 2010. | |||
[RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, | [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, | |||
J., and S. Amante, "Flow-Aware Transport of Pseudowires | J., and S. Amante, "Flow-Aware Transport of Pseudowires | |||
over an MPLS Packet Switched Network", RFC 6391, | over an MPLS Packet Switched Network", RFC 6391, November | |||
November 2011. | 2011. | |||
[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, | [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, | |||
"Pseudowire Status for Static Pseudowires", RFC 6478, | "Pseudowire Status for Static Pseudowires", RFC 6478, May | |||
May 2012. | 2012. | |||
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and | [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and | |||
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", | L. Yong, "The Use of Entropy Labels in MPLS Forwarding", | |||
RFC 6790, November 2012. | RFC 6790, November 2012. | |||
7.2. Informational References | 7.2. Informational References | |||
[RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for | [RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for | |||
Multiprotocol Label Switching Architecture (MPLS) | Multiprotocol Label Switching Architecture (MPLS) | |||
Operation and Maintenance (OAM) Functions", RFC 3429, | Operation and Maintenance (OAM) Functions", RFC 3429, | |||
skipping to change at page 13, line 6 | skipping to change at page 9, line 4 | |||
[RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for | [RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for | |||
Multiprotocol Label Switching Architecture (MPLS) | Multiprotocol Label Switching Architecture (MPLS) | |||
Operation and Maintenance (OAM) Functions", RFC 3429, | Operation and Maintenance (OAM) Functions", RFC 3429, | |||
November 2002. | November 2002. | |||
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic | [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic | |||
Associated Channel", RFC 5586, June 2009. | Associated Channel", RFC 5586, June 2009. | |||
Authors' Addresses | Authors' Addresses | |||
Kireeti Kompella | Kireeti Kompella | |||
Juniper Networks | Juniper Networks | |||
1133 Innovation Way | 1194 N. Mathilda Ave | |||
Sunnyvale, CA 94089 | Sunnyvale, CA 94089 | |||
US | US | |||
Email: kireeti.kompella@gmail.com | Email: kireeti.kompella@gmail.com | |||
Loa Andersson | Loa Andersson | |||
Huawei | Huawei | |||
Email: loa@mail01.huawei.com | Email: loa@mail01.huawei.com | |||
End of changes. 26 change blocks. | ||||
84 lines changed or deleted | 86 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |