draft-smack-mpls-rfc4379bis-05.txt   draft-smack-mpls-rfc4379bis-06.txt 
Network Working Group C. Pignataro Network Working Group C. Pignataro
Internet-Draft N. Kumar Internet-Draft N. Kumar
Obsoletes: 4379 (if approved) Cisco Obsoletes: 4379, 6829 (if approved) Cisco
Intended status: Standards Track S. Aldrin Intended status: Standards Track S. Aldrin
Expires: April 5, 2016 Google Expires: April 8, 2016 Google
M. Chen M. Chen
Huawei Huawei
October 3, 2015 October 6, 2015
Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
draft-smack-mpls-rfc4379bis-05 draft-smack-mpls-rfc4379bis-06
Abstract Abstract
This document describes a simple and efficient mechanism that can be This document describes a simple and efficient mechanism that can be
used to detect data plane failures in Multi-Protocol Label Switching used to detect data plane failures in Multi-Protocol Label Switching
(MPLS) Label Switched Paths (LSPs). There are two parts to this (MPLS) Label Switched Paths (LSPs). There are two parts to this
document: information carried in an MPLS "echo request" and "echo document: information carried in an MPLS "echo request" and "echo
reply" for the purposes of fault detection and isolation, and reply" for the purposes of fault detection and isolation, and
mechanisms for reliably sending the echo reply. mechanisms for reliably sending the echo reply.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 April 5, 2016. This Internet-Draft will expire on April 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Structure of This Document . . . . . . . . . . . . . . . 4 1.2. Structure of This Document . . . . . . . . . . . . . . . 4
1.3. Contributors . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Contributors . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Scope of RFC4379bis work . . . . . . . . . . . . . . . . 4 1.4. Scope of RFC4379bis work . . . . . . . . . . . . . . . . 4
1.5. ToDo . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. ToDo . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Use of Address Range 127/8 . . . . . . . . . . . . . . . 6 2.1. Use of Address Range 127/8 . . . . . . . . . . . . . . . 6
3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 7 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Target FEC Stack . . . . . . . . . . . . . . . . . . . . 12 3.2. Target FEC Stack . . . . . . . . . . . . . . . . . . . . 12
3.2.1. LDP IPv4 Prefix . . . . . . . . . . . . . . . . . . 14 3.2.1. LDP IPv4 Prefix . . . . . . . . . . . . . . . . . . . 14
3.2.2. LDP IPv6 Prefix . . . . . . . . . . . . . . . . . . 14 3.2.2. LDP IPv6 Prefix . . . . . . . . . . . . . . . . . . . 14
3.2.3. RSVP IPv4 LSP . . . . . . . . . . . . . . . . . . . 14 3.2.3. RSVP IPv4 LSP . . . . . . . . . . . . . . . . . . . . 14
3.2.4. RSVP IPv6 LSP . . . . . . . . . . . . . . . . . . . 15 3.2.4. RSVP IPv6 LSP . . . . . . . . . . . . . . . . . . . . 15
3.2.5. VPN IPv4 Prefix . . . . . . . . . . . . . . . . . . 15 3.2.5. VPN IPv4 Prefix . . . . . . . . . . . . . . . . . . . 15
3.2.6. VPN IPv6 Prefix . . . . . . . . . . . . . . . . . . 16 3.2.6. VPN IPv6 Prefix . . . . . . . . . . . . . . . . . . . 16
3.2.7. L2 VPN Endpoint . . . . . . . . . . . . . . . . . . 17 3.2.7. L2 VPN Endpoint . . . . . . . . . . . . . . . . . . . 17
3.2.8. FEC 128 Pseudowire (Deprecated) . . . . . . . . . . 17 3.2.8. FEC 128 Pseudowire - IPv4 (Deprecated) . . . . . . . 17
3.2.9. FEC 128 Pseudowire (Current) . . . . . . . . . . . . 18 3.2.9. FEC 128 Pseudowire - IPv4 (Current) . . . . . . . . . 18
3.2.10. FEC 129 Pseudowire . . . . . . . . . . . . . . . . . 19 3.2.10. FEC 129 Pseudowire - IPv4 . . . . . . . . . . . . . . 19
3.2.11. BGP Labeled IPv4 Prefix . . . . . . . . . . . . . . 20 3.2.11. BGP Labeled IPv4 Prefix . . . . . . . . . . . . . . . 20
3.2.12. BGP Labeled IPv6 Prefix . . . . . . . . . . . . . . 20 3.2.12. BGP Labeled IPv6 Prefix . . . . . . . . . . . . . . . 20
3.2.13. Generic IPv4 Prefix . . . . . . . . . . . . . . . . 21 3.2.13. Generic IPv4 Prefix . . . . . . . . . . . . . . . . . 21
3.2.14. Generic IPv6 Prefix . . . . . . . . . . . . . . . . 21 3.2.14. Generic IPv6 Prefix . . . . . . . . . . . . . . . . . 21
3.2.15. Nil FEC . . . . . . . . . . . . . . . . . . . . . . 22 3.2.15. Nil FEC . . . . . . . . . . . . . . . . . . . . . . . 22
3.3. Downstream Mapping . . . . . . . . . . . . . . . . . . . 22 3.2.16. FEC 128 Pseudowire - IPv6 . . . . . . . . . . . . . . 22
3.3.1. Multipath Information Encoding . . . . . . . . . . . 26 3.2.17. FEC 129 Pseudowire - IPv6 . . . . . . . . . . . . . . 23
3.3.2. Downstream Router and Interface . . . . . . . . . . 28 3.3. Downstream Mapping . . . . . . . . . . . . . . . . . . . 24
3.4. Pad TLV . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.1. Multipath Information Encoding . . . . . . . . . . . 27
3.5. Vendor Enterprise Number . . . . . . . . . . . . . . . . 29 3.3.2. Downstream Router and Interface . . . . . . . . . . . 29
3.6. Interface and Label Stack . . . . . . . . . . . . . . . 29 3.4. Pad TLV . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.7. Errored TLVs . . . . . . . . . . . . . . . . . . . . . . 31 3.5. Vendor Enterprise Number . . . . . . . . . . . . . . . . 30
3.8. Reply TOS Byte TLV . . . . . . . . . . . . . . . . . . . 31 3.6. Interface and Label Stack . . . . . . . . . . . . . . . . 31
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . 31 3.7. Errored TLVs . . . . . . . . . . . . . . . . . . . . . . 32
4.1. Dealing with Equal-Cost Multi-Path (ECMP) . . . . . . . 32 3.8. Reply TOS Byte TLV . . . . . . . . . . . . . . . . . . . 32
4.2. Testing LSPs That Are Used to Carry MPLS Payloads . . . 33 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 33
4.3. Sending an MPLS Echo Request . . . . . . . . . . . . . . 33 4.1. Dealing with Equal-Cost Multi-Path (ECMP) . . . . . . . . 33
4.4. Receiving an MPLS Echo Request . . . . . . . . . . . . . 34 4.2. Testing LSPs That Are Used to Carry MPLS Payloads . . . . 34
4.4.1. FEC Validation . . . . . . . . . . . . . . . . . . . 40 4.3. Sending an MPLS Echo Request . . . . . . . . . . . . . . 34
4.5. Sending an MPLS Echo Reply . . . . . . . . . . . . . . . 41 4.4. Receiving an MPLS Echo Request . . . . . . . . . . . . . 35
4.6. Receiving an MPLS Echo Reply . . . . . . . . . . . . . . 42 4.4.1. FEC Validation . . . . . . . . . . . . . . . . . . . 41
4.7. Issue with VPN IPv4 and IPv6 Prefixes . . . . . . . . . 42 4.5. Sending an MPLS Echo Reply . . . . . . . . . . . . . . . 42
4.8. Non-compliant Routers . . . . . . . . . . . . . . . . . 42 4.6. Receiving an MPLS Echo Reply . . . . . . . . . . . . . . 43
5. Security Considerations . . . . . . . . . . . . . . . . . . 43 4.7. Issue with VPN IPv4 and IPv6 Prefixes . . . . . . . . . . 43
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44 4.8. Non-compliant Routers . . . . . . . . . . . . . . . . . . 44
6.1. Message Types, Reply Modes, Return Codes . . . . . . . . 44 5. Security Considerations . . . . . . . . . . . . . . . . . . . 44
6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 6.1. Message Types, Reply Modes, Return Codes . . . . . . . . 46
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.1. Normative References . . . . . . . . . . . . . . . . . . 47 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47
8.2. Informative References . . . . . . . . . . . . . . . . . 48 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 8.1. Normative References . . . . . . . . . . . . . . . . . . 48
8.2. Informative References . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
This document describes a simple and efficient mechanism that can be This document describes a simple and efficient mechanism that can be
used to detect data plane failures in MPLS Label Switched Paths used to detect data plane failures in MPLS Label Switched Paths
(LSPs). There are two parts to this document: information carried in (LSPs). There are two parts to this document: information carried in
an MPLS "echo request" and "echo reply", and mechanisms for an MPLS "echo request" and "echo reply", and mechanisms for
transporting the echo reply. The first part aims at providing enough transporting the echo reply. The first part aims at providing enough
information to check correct operation of the data plane, as well as information to check correct operation of the data plane, as well as
a mechanism to verify the data plane against the control plane, and a mechanism to verify the data plane against the control plane, and
skipping to change at page 5, line 13 skipping to change at page 5, line 13
including: including:
1. Updates to all references and citations. Obsoleted RFCs 2434, 1. Updates to all references and citations. Obsoleted RFCs 2434,
2030, and 3036 are respectively replaced with RFCs 5226, 5905, 2030, and 3036 are respectively replaced with RFCs 5226, 5905,
and 5036. Additionally, these three documents published as RFCs: and 5036. Additionally, these three documents published as RFCs:
RFCs 4447, 5085, and 4761. RFCs 4447, 5085, and 4761.
2. Incorporate all outstanding Errata. These include Erratum with 2. Incorporate all outstanding Errata. These include Erratum with
IDs: 108, 1418, 1714, 1786, 3399, 742, and 2978. IDs: 108, 1418, 1714, 1786, 3399, 742, and 2978.
3. Replace EXP with Traffic Class (TC), based on the update from RFC 3. Replace EXP with Traffic Class (TC), based on the update from RFC
5462. 5462.
4. Incorporate the updates from RFC 6829, adding the PW FECs
advertised over IPv6.
1.5. ToDo 1.5. ToDo
This section should be empty, and removed, prior to publication. This section should be empty, and removed, prior to publication.
ToDos: ToDos:
1. Evaluation of which of the RFCs that updated RFC 4379 need to be 1. Evaluation of which of the RFCs that updated RFC 4379 need to be
incorporated into this 4379bis document. Specifically, these incorporated into this 4379bis document. Specifically, these
RFCs updated RFC 4379: 6424, 6425, 6426, 6829, 7506, and 7537. RFCs updated RFC 4379: 6424, 6425, 6426, 7506, and 7537. RFCs
RFCs that updated RFC 4379 and are incorporated into this that updated RFC 4379 and are incorporated into this 4379bis,
4379bis, will be Obsoleted by 4379bis. will be Obsoleted by 4379bis.
2. Review IANA Allocations 2. Review IANA Allocations
2. Motivation 2. Motivation
When an LSP fails to deliver user traffic, the failure cannot always When an LSP fails to deliver user traffic, the failure cannot always
be detected by the MPLS control plane. There is a need to provide a be detected by the MPLS control plane. There is a need to provide a
tool that would enable users to detect such traffic "black holes" or tool that would enable users to detect such traffic "black holes" or
misrouting within a reasonable period of time, and a mechanism to misrouting within a reasonable period of time, and a mechanism to
isolate faults. isolate faults.
skipping to change at page 13, line 5 skipping to change at page 13, line 5
The Return Subcode contains the point in the label stack where The Return Subcode contains the point in the label stack where
processing was terminated. If the RSC is 0, no labels were processing was terminated. If the RSC is 0, no labels were
processed. Otherwise the packet would have been label switched at processed. Otherwise the packet would have been label switched at
depth RSC. depth RSC.
3.2. Target FEC Stack 3.2. Target FEC Stack
A Target FEC Stack is a list of sub-TLVs. The number of elements is A Target FEC Stack is a list of sub-TLVs. The number of elements is
determined by looking at the sub-TLV length fields. determined by looking at the sub-TLV length fields.
Sub-Type Length Value Field Sub-Type Length Value Field
-------- ------ ----------- -------- ------ -----------
1 5 LDP IPv4 prefix 1 5 LDP IPv4 prefix
2 17 LDP IPv6 prefix 2 17 LDP IPv6 prefix
3 20 RSVP IPv4 LSP 3 20 RSVP IPv4 LSP
4 56 RSVP IPv6 LSP 4 56 RSVP IPv6 LSP
5 Not Assigned 5 Not Assigned
6 13 VPN IPv4 prefix 6 13 VPN IPv4 prefix
7 25 VPN IPv6 prefix 7 25 VPN IPv6 prefix
8 14 L2 VPN endpoint 8 14 L2 VPN endpoint
9 10 "FEC 128" Pseudowire (deprecated) 9 10 "FEC 128" Pseudowire - IPv4 (deprecated)
10 14 "FEC 128" Pseudowire 10 14 "FEC 128" Pseudowire - IPv4
11 16+ "FEC 129" Pseudowire 11 16+ "FEC 129" Pseudowire - IPv4
12 5 BGP labeled IPv4 prefix 12 5 BGP labeled IPv4 prefix
13 17 BGP labeled IPv6 prefix 13 17 BGP labeled IPv6 prefix
14 5 Generic IPv4 prefix 14 5 Generic IPv4 prefix
15 17 Generic IPv6 prefix 15 17 Generic IPv6 prefix
16 4 Nil FEC 16 4 Nil FEC
24 38 "FEC 128" Pseudowire - IPv6
25 40+ "FEC 129" Pseudowire - IPv6
Other FEC Types will be defined as needed. Other FEC Types will be defined as needed.
Note that this TLV defines a stack of FECs, the first FEC element Note that this TLV defines a stack of FECs, the first FEC element
corresponding to the top of the label stack, etc. corresponding to the top of the label stack, etc.
An MPLS echo request MUST have a Target FEC Stack that describes the An MPLS echo request MUST have a Target FEC Stack that describes the
FEC Stack being tested. For example, if an LSR X has an LDP mapping FEC Stack being tested. For example, if an LSR X has an LDP mapping
[RFC5036] for 192.168.1.1 (say, label 1001), then to verify that [RFC5036] for 192.168.1.1 (say, label 1001), then to verify that
label 1001 does indeed reach an egress LSR that announced this prefix label 1001 does indeed reach an egress LSR that announced this prefix
skipping to change at page 17, line 41 skipping to change at page 17, line 41
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's VE ID | Receiver's VE ID | | Sender's VE ID | Receiver's VE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero | | Encapsulation Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.8. FEC 128 Pseudowire (Deprecated) 3.2.8. FEC 128 Pseudowire - IPv4 (Deprecated)
FEC 128 (0x80) is defined in [RFC4447], as are the terms PW ID FEC 128 (0x80) is defined in [RFC4447], as are the terms PW ID
(Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero (Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero
32-bit connection ID. The PW Type is a 15-bit number indicating the 32-bit connection ID. The PW Type is a 15-bit number indicating the
encapsulation type. It is carried right justified in the field below encapsulation type. It is carried right justified in the field below
termed encapsulation type with the high-order bit set to zero. Both termed encapsulation type with the high-order bit set to zero. Both
of these fields are treated in this protocol as opaque values. of these fields are treated in this protocol as opaque values.
When an FEC 128 is encoded in a label stack, the following format is When an FEC 128 is encoded in a label stack, the following format is
used. The value field consists of the remote PE address (the used. The value field consists of the remote PE IPv4 address (the
destination address of the targeted LDP session), the PW ID, and the destination address of the targeted LDP session), the PW ID, and the
encapsulation type as follows: encapsulation type as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address | | Remote PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID | | PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero | | PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This FEC is deprecated and is retained only for backward This FEC is deprecated and is retained only for backward
compatibility. Implementations of LSP ping SHOULD accept and process compatibility. Implementations of LSP ping SHOULD accept and process
this TLV, but SHOULD send LSP ping echo requests with the new TLV this TLV, but SHOULD send LSP ping echo requests with the new TLV
(see next section), unless explicitly configured to use the old TLV. (see next section), unless explicitly configured to use the old TLV.
An LSR receiving this TLV SHOULD use the source IP address of the LSP An LSR receiving this TLV SHOULD use the source IP address of the LSP
echo request to infer the sender's PE address. echo request to infer the sender's PE address.
3.2.9. FEC 128 Pseudowire (Current) 3.2.9. FEC 128 Pseudowire - IPv4 (Current)
FEC 128 (0x80) is defined in [RFC4447], as are the terms PW ID FEC 128 (0x80) is defined in [RFC4447], as are the terms PW ID
(Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero (Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero
32-bit connection ID. The PW Type is a 15-bit number indicating the 32-bit connection ID. The PW Type is a 15-bit number indicating the
encapsulation type. It is carried right justified in the field below encapsulation type. It is carried right justified in the field below
termed encapsulation type with the high-order bit set to zero. termed encapsulation type with the high-order bit set to zero.
Both of these fields are treated in this protocol as opaque values. Both of these fields are treated in this protocol as opaque values.
When matching these field to the local FEC information, the match When matching these field to the local FEC information, the match
MUST be exact. MUST be exact.
When an FEC 128 is encoded in a label stack, the following format is When an FEC 128 is encoded in a label stack, the following format is
used. The value field consists of the sender's PE address (the used. The value field consists of the sender's PE IPv4 address (the
source address of the targeted LDP session), the remote PE address source address of the targeted LDP session), the remote PE IPv4
(the destination address of the targeted LDP session), the PW ID, and address (the destination address of the targeted LDP session), the PW
the encapsulation type as follows: ID, and the encapsulation type as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE Address | | Sender's PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address | | Remote PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID | | PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero | | PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.10. FEC 129 Pseudowire 3.2.10. FEC 129 Pseudowire - IPv4
FEC 129 (0x81) and the terms PW Type, Attachment Group Identifier FEC 129 (0x81) and the terms PW Type, Attachment Group Identifier
(AGI), Attachment Group Identifier Type (AGI Type), Attachment (AGI), Attachment Group Identifier Type (AGI Type), Attachment
Individual Identifier Type (AII Type), Source Attachment Individual Individual Identifier Type (AII Type), Source Attachment Individual
Identifier (SAII), and Target Attachment Individual Identifier (TAII) Identifier (SAII), and Target Attachment Individual Identifier (TAII)
are defined in [RFC4447]. The PW Type is a 15-bit number indicating are defined in [RFC4447]. The PW Type is a 15-bit number indicating
the encapsulation type. It is carried right justified in the field the encapsulation type. It is carried right justified in the field
below PW Type with the high-order bit set to zero. All the other below PW Type with the high-order bit set to zero. All the other
fields are treated as opaque values and copied directly from the FEC fields are treated as opaque values and copied directly from the FEC
129 format. All of these values together uniquely define the FEC 129 format. All of these values together uniquely define the FEC
within the scope of the LDP session identified by the source and within the scope of the LDP session identified by the source and
remote PE addresses. remote PE IPv4 addresses.
When an FEC 129 is encoded in a label stack, the following format is When an FEC 129 is encoded in a label stack, the following format is
used. The Length of this TLV is 16 + AGI length + SAII length + TAII used. The Length of this TLV is 16 + AGI length + SAII length + TAII
length. Padding is used to make the total length a multiple of 4; length. Padding is used to make the total length a multiple of 4;
the length of the padding is not included in the Length field. the length of the padding is not included in the Length field.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE Address | | Sender's PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address | | Remote PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | AGI Type | AGI Length | | PW Type | AGI Type | AGI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value ~ ~ AGI Value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | SAII Length | SAII Value | | AII Type | SAII Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (continued) ~ ~ SAII Value (continued) ~
| | | |
skipping to change at page 22, line 26 skipping to change at page 22, line 26
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | MBZ | | Label | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label is the actual label value inserted in the label stack; the MBZ Label is the actual label value inserted in the label stack; the MBZ
fields MUST be zero when sent and ignored on receipt. fields MUST be zero when sent and ignored on receipt.
3.2.16. FEC 128 Pseudowire - IPv6
The FEC 128 Pseudowire IPv6 sub-TLV has a structure consistent with
the FEC 128 Pseudowire IPv4 sub-TLV as described in Section 3.2.9.
The value field consists of the Sender's PE IPv6 address (the source
address of the targeted LDP session), the remote PE IPv6 address (the
destination address of the targeted LDP session), the PW ID, and the
encapsulation type as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sender's PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Remote PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender's PE IPv6 Address: The source IP address of the target IPv6
LDP session. 16 octets.
Remote PE IPv6 Address: The destination IP address of the target IPv6
LDP session. 16 octets.
PW ID: Same as FEC 128 Pseudowire IPv4 in Section 3.2.9.
PW Type: Same as FEC 128 Pseudowire IPv4 in Section 3.2.9.
3.2.17. FEC 129 Pseudowire - IPv6
The FEC 129 Pseudowire IPv6 sub-TLV has a structure consistent with
the FEC 129 Pseudowire IPv4 sub-TLV as described in Section 3.2.10.
When an FEC 129 is encoded in a label stack, the following format is
used. The length of this TLV is 40 + AGI (Attachment Group
Identifier) length + SAII (Source Attachment Individual Identifier)
length + TAII (Target Attachment Individual Identifier) length.
Padding is used to make the total length a multiple of 4; the length
of the padding is not included in the Length field.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sender's PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Remote PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | AGI Type | AGI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | SAII Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | TAII Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAII (cont.) | 0-3 octets of zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender's PE IPv6 Address: The source IP address of the target IPv6
LDP session. 16 octets.
Remote PE IPv6 Address: The destination IP address of the target IPv6
LDP session. 16 octets.
The other fields are the same as FEC 129 Pseudowire IPv4 in
Section 3.2.10.
3.3. Downstream Mapping 3.3. Downstream Mapping
The Downstream Mapping object is a TLV that MAY be included in an The Downstream Mapping object is a TLV that MAY be included in an
echo request message. Only one Downstream Mapping object may appear echo request message. Only one Downstream Mapping object may appear
in an echo request. The presence of a Downstream Mapping object is a in an echo request. The presence of a Downstream Mapping object is a
request that Downstream Mapping objects be included in the echo request that Downstream Mapping objects be included in the echo
reply. If the replying router is the destination of the FEC, then a reply. If the replying router is the destination of the FEC, then a
Downstream Mapping TLV SHOULD NOT be included in the echo reply. Downstream Mapping TLV SHOULD NOT be included in the echo reply.
Otherwise the replying router SHOULD include a Downstream Mapping Otherwise the replying router SHOULD include a Downstream Mapping
object for each interface over which this FEC could be forwarded. object for each interface over which this FEC could be forwarded.
skipping to change at page 46, line 5 skipping to change at page 47, line 12
values in the range 31744-32767 and 64512-65535 are for Vendor values in the range 31744-32767 and 64512-65535 are for Vendor
Private Use, and MUST NOT be allocated. Private Use, and MUST NOT be allocated.
If a TLV or sub-TLV has a Type that falls in the range for Vendor If a TLV or sub-TLV has a Type that falls in the range for Vendor
Private Use, the Length MUST be at least 4, and the first four octets Private Use, the Length MUST be at least 4, and the first four octets
MUST be that vendor's SMI Private Enterprise Number, in network octet MUST be that vendor's SMI Private Enterprise Number, in network octet
order. The rest of the Value field is private to the vendor. order. The rest of the Value field is private to the vendor.
TLVs and sub-TLVs defined in this document are the following: TLVs and sub-TLVs defined in this document are the following:
Type Sub-Type Value Field Type Sub-Type Value Field
---- -------- ----------- ---- -------- -----------
1 Target FEC Stack 1 Target FEC Stack
1 LDP IPv4 prefix 1 LDP IPv4 prefix
2 LDP IPv6 prefix 2 LDP IPv6 prefix
3 RSVP IPv4 LSP 3 RSVP IPv4 LSP
4 RSVP IPv6 LSP 4 RSVP IPv6 LSP
5 Not Assigned 5 Not Assigned
6 VPN IPv4 prefix 6 VPN IPv4 prefix
7 VPN IPv6 prefix 7 VPN IPv6 prefix
8 L2 VPN endpoint 8 L2 VPN endpoint
9 "FEC 128" Pseudowire (Deprecated) 9 "FEC 128" Pseudowire - IPv4 (Deprecated)
10 "FEC 128" Pseudowire 10 "FEC 128" Pseudowire - IPv4
11 "FEC 129" Pseudowire 11 "FEC 129" Pseudowire - IPv4
12 BGP labeled IPv4 prefix 12 BGP labeled IPv4 prefix
13 BGP labeled IPv6 prefix 13 BGP labeled IPv6 prefix
14 Generic IPv4 prefix 14 Generic IPv4 prefix
15 Generic IPv6 prefix 15 Generic IPv6 prefix
16 Nil FEC 16 Nil FEC
2 Downstream Mapping 24 "FEC 128" Pseudowire - IPv6
3 Pad 25 "FEC 129" Pseudowire - IPv6
4 Not Assigned 2 Downstream Mapping
5 Vendor Enterprise Number 3 Pad
6 Not Assigned 4 Not Assigned
7 Interface and Label Stack 5 Vendor Enterprise Number
8 Not Assigned 6 Not Assigned
9 Errored TLVs 7 Interface and Label Stack
Any value The TLV not understood 8 Not Assigned
10 Reply TOS Byte 9 Errored TLVs
Any value The TLV not understood
10 Reply TOS Byte
7. Acknowledgements 7. Acknowledgements
The original acknowledgements from RFC 4379 state the following: The original acknowledgements from RFC 4379 state the following:
This document is the outcome of many discussions among many This document is the outcome of many discussions among many
people, including Manoj Leelanivas, Paul Traina, Yakov Rekhter, people, including Manoj Leelanivas, Paul Traina, Yakov Rekhter,
Der-Hwa Gan, Brook Bailey, Eric Rosen, Ina Minei, Shivani Der-Hwa Gan, Brook Bailey, Eric Rosen, Ina Minei, Shivani
Aggarwal, and Vanson Lim. Aggarwal, and Vanson Lim.
The description of the Multipath Information sub-field of the The description of the Multipath Information sub-field of the
Downstream Mapping TLV was adapted from text suggested by Curtis Downstream Mapping TLV was adapted from text suggested by Curtis
Villamizar. Villamizar.
We would like to thank Loa Andersson for motivating the advancement We would like to thank Loa Andersson for motivating the advancement
of this bis specification. of this bis specification. We also would like to thank Alexander
Vainshtein for his review and comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, DOI 10.17487/ Communication Layers", STD 3, RFC 1122,
RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>. <http://www.rfc-editor.org/info/rfc1122>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<http://www.rfc-editor.org/info/rfc1812>. <http://www.rfc-editor.org/info/rfc1812>.
[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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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, DOI 10.17487/RFC3032, January 2001, Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<http://www.rfc-editor.org/info/rfc3032>. <http://www.rfc-editor.org/info/rfc3032>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, DOI Private Network (VPN) Terminology", RFC 4026,
10.17487/RFC4026, March 2005, DOI 10.17487/RFC4026, March 2005,
<http://www.rfc-editor.org/info/rfc4026>. <http://www.rfc-editor.org/info/rfc4026>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI Border Gateway Protocol 4 (BGP-4)", RFC 4271,
10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>. <http://www.rfc-editor.org/info/rfc4271>.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006. DOI 10.17487/RFC4379, February 2006,
<http://www.rfc-editor.org/info/rfc4379>.
[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,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>. <http://www.rfc-editor.org/info/rfc5905>.
8.2. Informative References 8.2. Informative References
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981. RFC 792, DOI 10.17487/RFC0792, September 1981,
<http://www.rfc-editor.org/info/rfc792>.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
<http://www.rfc-editor.org/info/rfc3107>. <http://www.rfc-editor.org/info/rfc3107>.
[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, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>. <http://www.rfc-editor.org/info/rfc3209>.
[RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP [RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP
Virtual Private Networks (VPNs)", RFC 4365, DOI 10.17487/ Virtual Private Networks (VPNs)", RFC 4365,
RFC4365, February 2006, DOI 10.17487/RFC4365, February 2006,
<http://www.rfc-editor.org/info/rfc4365>. <http://www.rfc-editor.org/info/rfc4365>.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447, DOI Label Distribution Protocol (LDP)", RFC 4447,
10.17487/RFC4447, April 2006, DOI 10.17487/RFC4447, April 2006,
<http://www.rfc-editor.org/info/rfc4447>. <http://www.rfc-editor.org/info/rfc4447>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<http://www.rfc-editor.org/info/rfc4761>. <http://www.rfc-editor.org/info/rfc4761>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036, "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>. October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
Connectivity Verification (VCCV): A Control Channel for Circuit Connectivity Verification (VCCV): A Control
Pseudowires", RFC 5085, December 2007. Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
December 2007, <http://www.rfc-editor.org/info/rfc5085>.
Authors' Addresses Authors' Addresses
Carlos Pignataro Carlos Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
Email: cpignata@cisco.com Email: cpignata@cisco.com
Nagendra Kumar Nagendra Kumar
Cisco Systems, Inc. Cisco Systems, Inc.
Email: naikumar@cisco.com Email: naikumar@cisco.com
Sam Aldrin Sam Aldrin
Google Google
Email: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
 End of changes. 34 change blocks. 
137 lines changed or deleted 225 lines changed or added

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