draft-ietf-mpls-forwarding-03.txt | draft-ietf-mpls-forwarding-04.txt | |||
---|---|---|---|---|
MPLS C. Villamizar, Ed. | MPLS C. Villamizar, Ed. | |||
Internet-Draft OCCNC | Internet-Draft OCCNC | |||
Intended status: Informational K. Kompella | Intended status: Informational K. Kompella | |||
Expires: May 18, 2014 Juniper Networks | Expires: June 20, 2014 Juniper Networks | |||
S. Amante | S. Amante | |||
Apple Inc. | Apple Inc. | |||
A. Malis | A. Malis | |||
Consultant | Consultant | |||
C. Pignataro | C. Pignataro | |||
Cisco | Cisco | |||
November 14, 2013 | December 17, 2013 | |||
MPLS Forwarding Compliance and Performance Requirements | MPLS Forwarding Compliance and Performance Requirements | |||
draft-ietf-mpls-forwarding-03 | draft-ietf-mpls-forwarding-04 | |||
Abstract | Abstract | |||
This document provides guidelines for implementers regarding MPLS | This document provides guidelines for implementers regarding MPLS | |||
forwarding and a basis for evaluations of forwarding implementations. | forwarding and a basis for evaluations of forwarding implementations. | |||
Guidelines cover many aspects of MPLS forwarding. Topics are | Guidelines cover many aspects of MPLS forwarding. Topics are | |||
highlighted where implementers might otherwise overlook practical | highlighted where implementers might otherwise overlook practical | |||
requirements which are unstated or under emphasized or are optional | requirements which are unstated or under emphasized or are optional | |||
for conformance to RFCs but are often considered mandatory by | for conformance to RFCs but are often considered mandatory by | |||
providers. | providers. | |||
skipping to change at page 1, line 43 | skipping to change at page 1, line 43 | |||
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 May 18, 2014. | This Internet-Draft will expire on June 20, 2014. | |||
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 | |||
skipping to change at page 2, line 38 | skipping to change at page 2, line 38 | |||
2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 10 | 2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 10 | |||
2.1.1. MPLS Special Purpose Labels . . . . . . . . . . . . . 11 | 2.1.1. MPLS Special Purpose Labels . . . . . . . . . . . . . 11 | |||
2.1.2. MPLS Differentiated Services . . . . . . . . . . . . 12 | 2.1.2. MPLS Differentiated Services . . . . . . . . . . . . 12 | |||
2.1.3. Time Synchronization . . . . . . . . . . . . . . . . 13 | 2.1.3. Time Synchronization . . . . . . . . . . . . . . . . 13 | |||
2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . 14 | 2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . 14 | |||
2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . 15 | 2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . 15 | |||
2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . 15 | 2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . 15 | |||
2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 15 | 2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 15 | |||
2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . 16 | 2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . 16 | |||
2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . 16 | 2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . 16 | |||
2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 17 | 2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 18 | |||
2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . 17 | 2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . 18 | |||
2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . 18 | 2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . 19 | |||
2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 20 | 2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 21 | |||
2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 21 | 2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 22 | |||
2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . 22 | 2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . 22 | |||
2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 22 | 2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 23 | |||
2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . 22 | 2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . 23 | |||
2.4.5. Fields Used for Multipath Load Balance . . . . . . . 23 | 2.4.5. Fields Used for Multipath Load Balance . . . . . . . 23 | |||
2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . 23 | 2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . 24 | |||
2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . 25 | 2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . 25 | |||
2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 26 | 2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 27 | |||
2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . 26 | 2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . 27 | |||
2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 27 | 2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 28 | |||
2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 27 | 2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 28 | |||
2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . 28 | 2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . 28 | |||
2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . 30 | 2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . 30 | |||
2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 31 | 2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 31 | |||
2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 31 | 2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 32 | |||
2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 32 | 2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 33 | |||
2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 33 | 2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 33 | |||
2.7. Number and Size of Flows . . . . . . . . . . . . . . . . 34 | 2.7. Number and Size of Flows . . . . . . . . . . . . . . . . 34 | |||
3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 34 | 3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 35 | |||
3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 34 | 3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 35 | |||
3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 36 | 3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 36 | |||
3.3. Multipath Capabilities and Performance . . . . . . . . . 37 | 3.3. Multipath Capabilities and Performance . . . . . . . . . 37 | |||
3.4. Pseudowire Capabilities and Performance . . . . . . . . . 37 | 3.4. Pseudowire Capabilities and Performance . . . . . . . . . 38 | |||
3.5. Entropy Label Support and Performance . . . . . . . . . . 38 | 3.5. Entropy Label Support and Performance . . . . . . . . . . 38 | |||
3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 38 | 3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 38 | |||
3.7. OAM Capabilities and Performance . . . . . . . . . . . . 38 | 3.7. OAM Capabilities and Performance . . . . . . . . . . . . 39 | |||
4. Forwarding Compliance and Performance Testing . . . . . . . . 39 | 4. Forwarding Compliance and Performance Testing . . . . . . . . 39 | |||
4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 39 | 4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 40 | |||
4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 40 | 4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 40 | |||
4.3. Multipath Capabilities and Performance . . . . . . . . . 40 | 4.3. Multipath Capabilities and Performance . . . . . . . . . 41 | |||
4.4. Pseudowire Capabilities and Performance . . . . . . . . . 41 | 4.4. Pseudowire Capabilities and Performance . . . . . . . . . 42 | |||
4.5. Entropy Label Support and Performance . . . . . . . . . . 42 | 4.5. Entropy Label Support and Performance . . . . . . . . . . 42 | |||
4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 42 | 4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 43 | |||
4.7. OAM Capabilities and Performance . . . . . . . . . . . . 43 | 4.7. OAM Capabilities and Performance . . . . . . . . . . . . 43 | |||
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 | 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 44 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 45 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 45 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 45 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 46 | 8.2. Informative References . . . . . . . . . . . . . . . . . 46 | |||
Appendix A. Organization of References Section . . . . . . . . . 51 | Appendix A. Organization of References Section . . . . . . . . . 51 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 | |||
1. Introduction and Document Scope | 1. Introduction and Document Scope | |||
The initial purpose of this document was to address concerns raised | The initial purpose of this document was to address concerns raised | |||
on the MPLS WG mailing list about shortcomings in implementations of | on the MPLS WG mailing list about shortcomings in implementations of | |||
MPLS forwarding. Documenting existing misconceptions and potential | MPLS forwarding. Documenting existing misconceptions and potential | |||
skipping to change at page 12, line 7 | skipping to change at page 12, line 7 | |||
general purpose CPU or other highly programmable hardware. For | general purpose CPU or other highly programmable hardware. For | |||
example, ELI will only be sent to LSR which have signaled support for | example, ELI will only be sent to LSR which have signaled support for | |||
[RFC6790] and high OAM packet rate must be negotiated among | [RFC6790] and high OAM packet rate must be negotiated among | |||
endpoints. | endpoints. | |||
[RFC3429] reserves a label for ITU-T Y.1711, however Y.1711 does not | [RFC3429] reserves a label for ITU-T Y.1711, however Y.1711 does not | |||
work with multipath and its use is strongly discouraged. | work with multipath and its use is strongly discouraged. | |||
The current list of special purpose labels can be found on the | The current list of special purpose labels can be found on the | |||
"Multiprotocol Label Switching Architecture (MPLS) Label Values" | "Multiprotocol Label Switching Architecture (MPLS) Label Values" | |||
registry reachable at IANA's pages at [1]. | registry reachable at IANA's pages at http://www.iana.org. | |||
[I-D.ietf-mpls-special-purpose-labels] introduces an IANA "Extended | [I-D.ietf-mpls-special-purpose-labels] introduces an IANA "Extended | |||
Special Purpose MPLS Label Values" registry and makes use of the | Special Purpose MPLS Label Values" registry and makes use of the | |||
"extension" label, label 15, to indicate that the next label is an | "extension" label, label 15, to indicate that the next label is an | |||
extended special purpose label and requires special handling. The | extended special purpose label and requires special handling. The | |||
range of only 16 values for special purpose labels allows a table to | range of only 16 values for special purpose labels allows a table to | |||
be used. The range of extended special purpose labels with 20 bits | be used. The range of extended special purpose labels with 20 bits | |||
available for use may have to be handled in some other way in the | available for use may have to be handled in some other way in the | |||
unlikely event that in the future the range of currently reserved | unlikely event that in the future the range of currently reserved | |||
values 256-1048575 are used. If only the standards action range, | values 256-1048575 are used. If only the standards action range, | |||
skipping to change at page 16, line 35 | skipping to change at page 16, line 35 | |||
The pseudowire encapsulation is out of scope for this document. | The pseudowire encapsulation is out of scope for this document. | |||
Pseudowire impact on MPLS forwarding at midpoint LSR is within scope. | Pseudowire impact on MPLS forwarding at midpoint LSR is within scope. | |||
The impact on ingress MPLS push and egress MPLS UHP pop are within | The impact on ingress MPLS push and egress MPLS UHP pop are within | |||
scope. While pseudowire encapsulation is out of scope, some advice | scope. While pseudowire encapsulation is out of scope, some advice | |||
is given on sequence number support. | is given on sequence number support. | |||
2.1.8.1. Pseudowire Sequence Number | 2.1.8.1. Pseudowire Sequence Number | |||
Pseudowire (PW) sequence number support is most important for PW | Pseudowire (PW) sequence number support is most important for PW | |||
payload types with a high expectation of in-order delivery. | payload types with a high expectation of lossless and/or in-order | |||
Resequencing support, rather than dropping at egress on out of order | delivery. Identifying lost PW packets and exact amount of lost | |||
arrival, is most important for PW payload types with a high | payload is critical for PW services which maintain bit timing, such | |||
expectation of lossless delivery. For example, TDM payloads require | as Time Division Multiplexing (TDM) services since these services | |||
sequence number support and require resequencing support. The same | MUST compensate lost payload on a bit-for-bit basis. | |||
is true of ATM CBR service. ATM VBR or ABR may have somewhat relaxed | ||||
requirements, but generally require ATM Early Packet Discard (EPD) or | With PW services which maintain bit timing, packets that have been | |||
ATM Partial Packet Discard (PPD) [ATM-EPD-and-PPD]. Though sequence | received out of order also MUST be identified and may be either re- | |||
number support and resequencing support are beneficial to PW packet | ordered or dropped. Reordering requires, in addition to sequence | |||
oriented payloads such as FR and Ethernet, they are highly desirable | numbering, a "reorder buffer" in the egress PE, and ability to | |||
but not as strongly required. | reorder is limited by the depth of this buffer. The down side of | |||
maintaining a large reorder buffer is added end-to-end service delay. | ||||
For PW services which maintain bit timing or any other service where | ||||
jitter must be bounded, a jitter buffer is always necessary. The | ||||
jitter buffer is needed regardless of whether reordering is done. In | ||||
order to be effective, a reorder buffer must often be larger than a | ||||
jitter buffer needs to be creating a tradeoff between reducing loss | ||||
and minimizing delay. | ||||
PW services which are not timing critical bit streams in nature are | ||||
cell oriented or frame oriented. Though resequencing support may be | ||||
beneficial to PW cell and frame oriented payloads such as ATM, FR and | ||||
Ethernet, this support is desirable but not required. Requirements | ||||
to hamdle out of order packets at all vary among services and | ||||
deployments. For example for Ethernet PW, occasional (very rare) | ||||
reordering is usually acceptable. If the Ethernet PW is carrying | ||||
MPLS-TP, then this reordering may be acceptable. | ||||
Reducing jitter is best done by an end-system, given that the | ||||
tradeoff of loss vs delay varies among services. For example with | ||||
interactive real time services low delay is preferred, while with | ||||
non-interactive (one way) real time services low loss is preferred. | ||||
The same end-site may be receiving both types of traffic. Regardless | ||||
of this, bounded jitter is sometimes a requiremnet for specific | ||||
deployments. | ||||
Packet reorder should be rare except in a small number of | Packet reorder should be rare except in a small number of | |||
circumstances, most of which are due to network design or equipment | circumstances, most of which are due to network design or equipment | |||
design errors: | design errors: | |||
1. The most common case is where reordering occurs is rare, | 1. The most common case is where reordering occurs is rare, | |||
occurring only when a network or equipment fault forces traffic | occurring only when a network or equipment fault forces traffic | |||
on a new path with different delay. The packet loss that | on a new path with different delay. The packet loss that | |||
accompanies a network or equipment fault is generally more | accompanies a network or equipment fault is generally more | |||
disruptive than any reordering which may occur. | disruptive than any reordering which may occur. | |||
skipping to change at page 17, line 30 | skipping to change at page 18, line 5 | |||
4. Another avoidable case is where some core equipment has multipath | 4. Another avoidable case is where some core equipment has multipath | |||
and for some reason insists on periodically installing a new | and for some reason insists on periodically installing a new | |||
random number as the multipath hash seed. If supporting MPLS-TP, | random number as the multipath hash seed. If supporting MPLS-TP, | |||
equipment MUST provide a means to disable periodic hash reseeding | equipment MUST provide a means to disable periodic hash reseeding | |||
and deployments MUST disable periodic hash reseeding. Even if | and deployments MUST disable periodic hash reseeding. Even if | |||
not supporting MPLS-TP, equipment should provide a means to | not supporting MPLS-TP, equipment should provide a means to | |||
disable periodic hash reseeding and deployments should disable | disable periodic hash reseeding and deployments should disable | |||
periodic hash reseeding. | periodic hash reseeding. | |||
In provider networks which use multipath techniques and which may | ||||
occassionally rebalance traffic or which may change PW paths | ||||
occasionally for other reasons, reordering may be far more common | ||||
than loss. Where reordering is more common than loss, resequencing | ||||
packets is beneficial, rather than dropping packets at egress when | ||||
out of order arrival occus. Resequencing is most important for PW | ||||
payload types with a high expectation of lossless delivery since in | ||||
such cases out of order delivery within the network results in PW | ||||
loss. | ||||
2.1.9. Layer-2 and Layer-3 VPN | 2.1.9. Layer-2 and Layer-3 VPN | |||
Layer-2 VPN [RFC4664] and Layer-3 VPN [RFC4110] add one or more label | Layer-2 VPN [RFC4664] and Layer-3 VPN [RFC4110] add one or more label | |||
entry to the MPLS label stack. VPN encapsulations are out of scope | entry to the MPLS label stack. VPN encapsulations are out of scope | |||
for this document. Its impact on forwarding at midpoint LSR are | for this document. Its impact on forwarding at midpoint LSR are | |||
within scope. | within scope. | |||
Any of these services may be used on an MPLS entropy label enabled | Any of these services may be used on an MPLS entropy label enabled | |||
ingress and egress (see Section 2.4.4 for discussion of entropy | ingress and egress (see Section 2.4.4 for discussion of entropy | |||
label) which would add an additional two labels to the MPLS label | label) which would add an additional two labels to the MPLS label | |||
skipping to change at page 44, line 24 | skipping to change at page 44, line 50 | |||
also provided a number of clarifications to the questions and tests | also provided a number of clarifications to the questions and tests | |||
in Section 3 and Section 4. | in Section 3 and Section 4. | |||
Gregory Mirsky and Thomas Beckhaus provided useful comments during | Gregory Mirsky and Thomas Beckhaus provided useful comments during | |||
the MPLS RT review. | the MPLS RT review. | |||
Tal Mizrahi provided comments that prompted clarifications regarding | Tal Mizrahi provided comments that prompted clarifications regarding | |||
timestamp processing, local delivery of packets, and the need for | timestamp processing, local delivery of packets, and the need for | |||
hardware assistance in processing OAM traffic. | hardware assistance in processing OAM traffic. | |||
Alexander (Sasha) Vainshtein pointed out errors in Section 2.1.8.1 | ||||
and suggested new text which after lengthy discussion resulted in | ||||
restating the sumarization of requirements from PWE3 RFCs and more | ||||
clearly stating the benefits and drawbacks of packet resequencing | ||||
based on PW sequence number. | ||||
6. IANA Considerations | 6. IANA Considerations | |||
This memo includes no request to IANA. | This memo includes no request to IANA. | |||
7. Security Considerations | 7. Security Considerations | |||
This document reviews forwarding behavior specified elsewhere and | This document reviews forwarding behavior specified elsewhere and | |||
points out compliance and performance requirements. As such it | points out compliance and performance requirements. As such it | |||
introduces no new security requirements or concerns. | introduces no new security requirements or concerns. | |||
skipping to change at page 46, line 17 | skipping to change at page 46, line 42 | |||
RFC 6790, November 2012. | RFC 6790, November 2012. | |||
8.2. Informative References | 8.2. Informative References | |||
[ACK-compression] | [ACK-compression] | |||
, , , "Observations and Dynamics of a Congestion Control | , , , "Observations and Dynamics of a Congestion Control | |||
Algorithm: The Effects of Two-Way Traffic", Proc. ACM | Algorithm: The Effects of Two-Way Traffic", Proc. ACM | |||
SIGCOMM, ACM Computer Communications Review (CCR) Vol 21, | SIGCOMM, ACM Computer Communications Review (CCR) Vol 21, | |||
No 4, 1991, pp.133-147., 1991. | No 4, 1991, pp.133-147., 1991. | |||
[ATM-EPD-and-PPD] | ||||
, "Dynamics of TCP Traffic over ATM Networks", IEEE | ||||
Journal of Special Areas of Communication Vol 13 No 4, May | ||||
1995, pp. 633-641., May 1995. | ||||
[I-D.ietf-mpls-special-purpose-labels] | [I-D.ietf-mpls-special-purpose-labels] | |||
Kompella, K., Andersson, L., and A. Farrel, "Allocating | Kompella, K., Andersson, L., and A. Farrel, "Allocating | |||
and Retiring Special Purpose MPLS Labels", draft-ietf- | and Retiring Special Purpose MPLS Labels", draft-ietf- | |||
mpls-special-purpose-labels-03 (work in progress), July | mpls-special-purpose-labels-03 (work in progress), July | |||
2013. | 2013. | |||
[I-D.ietf-pwe3-vccv-impl-survey-results] | [I-D.ietf-pwe3-vccv-impl-survey-results] | |||
Malis, A., "The Pseudowire (PW) & Virtual Circuit | Malis, A., "The Pseudowire (PW) & Virtual Circuit | |||
Connectivity Verification (VCCV) Implementation Survey | Connectivity Verification (VCCV) Implementation Survey | |||
Results", draft-ietf-pwe3-vccv-impl-survey-results-03 | Results", draft-ietf-pwe3-vccv-impl-survey-results-03 | |||
End of changes. 21 change blocks. | ||||
47 lines changed or deleted | 83 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/ |