draft-smack-mpls-rfc4379bis-06.txt   draft-smack-mpls-rfc4379bis-07.txt 
Network Working Group C. Pignataro Network Working Group C. Pignataro
Internet-Draft N. Kumar Internet-Draft N. Kumar
Obsoletes: 4379, 6829 (if approved) Cisco Obsoletes: 4379, 6829 (if approved) Cisco
Intended status: Standards Track S. Aldrin Intended status: Standards Track S. Aldrin
Expires: April 8, 2016 Google Expires: April 13, 2016 Google
M. Chen M. Chen
Huawei Huawei
October 6, 2015 October 11, 2015
Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
draft-smack-mpls-rfc4379bis-06 draft-smack-mpls-rfc4379bis-07
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 8, 2016. This Internet-Draft will expire on April 13, 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 . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . 5
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 2.2. Router Alert Option . . . . . . . . . . . . . . . . . . . 8
3.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 12 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Target FEC Stack . . . . . . . . . . . . . . . . . . . . 12 3.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. LDP IPv4 Prefix . . . . . . . . . . . . . . . . . . . 14 3.2. Target FEC Stack . . . . . . . . . . . . . . . . . . . . 13
3.2.2. LDP IPv6 Prefix . . . . . . . . . . . . . . . . . . . 14 3.2.1. LDP IPv4 Prefix . . . . . . . . . . . . . . . . . . . 15
3.2.3. RSVP IPv4 LSP . . . . . . . . . . . . . . . . . . . . 14 3.2.2. LDP IPv6 Prefix . . . . . . . . . . . . . . . . . . . 15
3.2.4. RSVP IPv6 LSP . . . . . . . . . . . . . . . . . . . . 15 3.2.3. RSVP IPv4 LSP . . . . . . . . . . . . . . . . . . . . 15
3.2.5. VPN IPv4 Prefix . . . . . . . . . . . . . . . . . . . 15 3.2.4. RSVP IPv6 LSP . . . . . . . . . . . . . . . . . . . . 16
3.2.6. VPN IPv6 Prefix . . . . . . . . . . . . . . . . . . . 16 3.2.5. VPN IPv4 Prefix . . . . . . . . . . . . . . . . . . . 16
3.2.7. L2 VPN Endpoint . . . . . . . . . . . . . . . . . . . 17 3.2.6. VPN IPv6 Prefix . . . . . . . . . . . . . . . . . . . 17
3.2.8. FEC 128 Pseudowire - IPv4 (Deprecated) . . . . . . . 17 3.2.7. L2 VPN Endpoint . . . . . . . . . . . . . . . . . . . 18
3.2.9. FEC 128 Pseudowire - IPv4 (Current) . . . . . . . . . 18 3.2.8. FEC 128 Pseudowire - IPv4 (Deprecated) . . . . . . . 18
3.2.10. FEC 129 Pseudowire - IPv4 . . . . . . . . . . . . . . 19 3.2.9. FEC 128 Pseudowire - IPv4 (Current) . . . . . . . . . 19
3.2.11. BGP Labeled IPv4 Prefix . . . . . . . . . . . . . . . 20 3.2.10. FEC 129 Pseudowire - IPv4 . . . . . . . . . . . . . . 20
3.2.12. BGP Labeled IPv6 Prefix . . . . . . . . . . . . . . . 20 3.2.11. BGP Labeled IPv4 Prefix . . . . . . . . . . . . . . . 21
3.2.13. Generic IPv4 Prefix . . . . . . . . . . . . . . . . . 21 3.2.12. BGP Labeled IPv6 Prefix . . . . . . . . . . . . . . . 21
3.2.14. Generic IPv6 Prefix . . . . . . . . . . . . . . . . . 21 3.2.13. Generic IPv4 Prefix . . . . . . . . . . . . . . . . . 22
3.2.15. Nil FEC . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.14. Generic IPv6 Prefix . . . . . . . . . . . . . . . . . 22
3.2.16. FEC 128 Pseudowire - IPv6 . . . . . . . . . . . . . . 22 3.2.15. Nil FEC . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.17. FEC 129 Pseudowire - IPv6 . . . . . . . . . . . . . . 23 3.2.16. FEC 128 Pseudowire - IPv6 . . . . . . . . . . . . . . 23
3.3. Downstream Mapping . . . . . . . . . . . . . . . . . . . 24 3.2.17. FEC 129 Pseudowire - IPv6 . . . . . . . . . . . . . . 24
3.3.1. Multipath Information Encoding . . . . . . . . . . . 27 3.3. Downstream Mapping . . . . . . . . . . . . . . . . . . . 25
3.3.2. Downstream Router and Interface . . . . . . . . . . . 29 3.3.1. Multipath Information Encoding . . . . . . . . . . . 28
3.4. Pad TLV . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.2. Downstream Router and Interface . . . . . . . . . . . 30
3.5. Vendor Enterprise Number . . . . . . . . . . . . . . . . 30 3.4. Pad TLV . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6. Interface and Label Stack . . . . . . . . . . . . . . . . 31 3.5. Vendor Enterprise Number . . . . . . . . . . . . . . . . 31
3.7. Errored TLVs . . . . . . . . . . . . . . . . . . . . . . 32 3.6. Interface and Label Stack . . . . . . . . . . . . . . . . 32
3.8. Reply TOS Byte TLV . . . . . . . . . . . . . . . . . . . 32 3.7. Errored TLVs . . . . . . . . . . . . . . . . . . . . . . 33
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 33 3.8. Reply TOS Byte TLV . . . . . . . . . . . . . . . . . . . 33
4.1. Dealing with Equal-Cost Multi-Path (ECMP) . . . . . . . . 33 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 34
4.2. Testing LSPs That Are Used to Carry MPLS Payloads . . . . 34 4.1. Dealing with Equal-Cost Multi-Path (ECMP) . . . . . . . . 34
4.3. Sending an MPLS Echo Request . . . . . . . . . . . . . . 34 4.2. Testing LSPs That Are Used to Carry MPLS Payloads . . . . 35
4.4. Receiving an MPLS Echo Request . . . . . . . . . . . . . 35 4.3. Sending an MPLS Echo Request . . . . . . . . . . . . . . 35
4.4.1. FEC Validation . . . . . . . . . . . . . . . . . . . 41 4.4. Receiving an MPLS Echo Request . . . . . . . . . . . . . 36
4.5. Sending an MPLS Echo Reply . . . . . . . . . . . . . . . 42 4.4.1. FEC Validation . . . . . . . . . . . . . . . . . . . 42
4.6. Receiving an MPLS Echo Reply . . . . . . . . . . . . . . 43 4.5. Sending an MPLS Echo Reply . . . . . . . . . . . . . . . 43
4.7. Issue with VPN IPv4 and IPv6 Prefixes . . . . . . . . . . 43 4.6. Receiving an MPLS Echo Reply . . . . . . . . . . . . . . 44
4.8. Non-compliant Routers . . . . . . . . . . . . . . . . . . 44 4.7. Issue with VPN IPv4 and IPv6 Prefixes . . . . . . . . . . 44
5. Security Considerations . . . . . . . . . . . . . . . . . . . 44 4.8. Non-compliant Routers . . . . . . . . . . . . . . . . . . 45
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 5. Security Considerations . . . . . . . . . . . . . . . . . . . 45
6.1. Message Types, Reply Modes, Return Codes . . . . . . . . 46 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.1. Message Types, Reply Modes, Return Codes . . . . . . . . 47
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48
8.1. Normative References . . . . . . . . . . . . . . . . . . 48 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.2. Informative References . . . . . . . . . . . . . . . . . 49 8.1. Normative References . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 8.2. Informative References . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
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 15 skipping to change at page 5, line 25
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 4. Incorporate the updates from RFC 6829, adding the PW FECs
advertised over IPv6. advertised over IPv6.
5. Incorporate the updates from RFC 7506, adding IPv6 Router Alert
Option for MPLS OAM.
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, 7506, and 7537. RFCs RFCs updated RFC 4379: 6424, 6425, 6426 and 7537. RFCs that
that updated RFC 4379 and are incorporated into this 4379bis, updated RFC 4379 and are incorporated into this 4379bis, will be
will be Obsoleted by 4379bis. 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 7, line 43 skipping to change at page 8, line 10
checks. If such a switch is provided, it MUST default to checks. If such a switch is provided, it MUST default to
performing the checks. performing the checks.
This helps to ensure that diagnostic packets are never IP forwarded. This helps to ensure that diagnostic packets are never IP forwarded.
The 127/8 address range provides 16M addresses allowing wide The 127/8 address range provides 16M addresses allowing wide
flexibility in varying addresses to exercise ECMP paths. Finally, as flexibility in varying addresses to exercise ECMP paths. Finally, as
an implementation optimization, the 127/8 provides an easy means of an implementation optimization, the 127/8 provides an easy means of
identifying possible LSP packets. identifying possible LSP packets.
2.2. Router Alert Option
This document requires the use of the Router Alert Option (RAO) set
in IP header in order to have the transit node process the MPLS OAM
payload.
[RFC2113] defines a generic Option Value 0x0 for IPv4 RAO that alerts
transit router to examine the IPv4 packet. [RFC7506] defines MPLS
OAM Option Value 69 for IPv6 RAO to alert transit routers to examine
the IPv6 packet more closely for MPLS OAM purposes.
The use of the Router Alert IP Option in this document is as follows:
In case of an IPv4 header, the generic IPv4 RAO value 0x0
[RFC2113] SHOULD be used. In case of an IPv6 header, the IPv6 RAO
value (69) for MPLS OAM [RFC7506] MUST be used.
3. Packet Format 3. Packet Format
An MPLS echo request is a (possibly labeled) IPv4 or IPv6 UDP packet; An MPLS echo request is a (possibly labeled) IPv4 or IPv6 UDP packet;
the contents of the UDP packet have the following format: the contents of the UDP packet have the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Global Flags | | Version Number | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 34, line 45 skipping to change at page 35, line 45
packet out unlabeled interfaces. packet out unlabeled interfaces.
4.3. Sending an MPLS Echo Request 4.3. Sending an MPLS Echo Request
An MPLS echo request is a UDP packet. The IP header is set as An MPLS echo request is a UDP packet. The IP header is set as
follows: the source IP address is a routable address of the sender; follows: the source IP address is a routable address of the sender;
the destination IP address is a (randomly chosen) IPv4 address from the destination IP address is a (randomly chosen) IPv4 address from
the range 127/8 or IPv6 address from the range the range 127/8 or IPv6 address from the range
0:0:0:0:0:FFFF:7F00/104. The IP TTL is set to 1. The source UDP 0:0:0:0:0:FFFF:7F00/104. The IP TTL is set to 1. The source UDP
port is chosen by the sender; the destination UDP port is set to 3503 port is chosen by the sender; the destination UDP port is set to 3503
(assigned by IANA for MPLS echo requests). The Router Alert option (assigned by IANA for MPLS echo requests). The Router Alert IP
MUST be set in the IP header. option of value 0x0 [RFC2113] for IPv4 or value 69 [RFC7506] for IPv6
MUST be set in IP header.
An MPLS echo request is sent with a label stack corresponding to the An MPLS echo request is sent with a label stack corresponding to the
FEC Stack being tested. Note that further labels could be applied FEC Stack being tested. Note that further labels could be applied
if, for example, the normal route to the topmost FEC in the stack is if, for example, the normal route to the topmost FEC in the stack is
via a Traffic Engineered Tunnel [RFC3209]. If all of the FECs in the via a Traffic Engineered Tunnel [RFC3209]. If all of the FECs in the
stack correspond to Implicit Null labels, the MPLS echo request is stack correspond to Implicit Null labels, the MPLS echo request is
considered unlabeled even if further labels will be applied in considered unlabeled even if further labels will be applied in
sending the packet. sending the packet.
If the echo request is labeled, one MAY (depending on what is being If the echo request is labeled, one MAY (depending on what is being
skipping to change at page 42, line 36 skipping to change at page 43, line 36
4.5. Sending an MPLS Echo Reply 4.5. Sending an MPLS Echo Reply
An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response
to an MPLS echo request. The source IP address is a routable address to an MPLS echo request. The source IP address is a routable address
of the replier; the source port is the well-known UDP port for LSP of the replier; the source port is the well-known UDP port for LSP
ping. The destination IP address and UDP port are copied from the ping. The destination IP address and UDP port are copied from the
source IP address and UDP port of the echo request. The IP TTL is source IP address and UDP port of the echo request. The IP TTL is
set to 255. If the Reply Mode in the echo request is "Reply via an set to 255. If the Reply Mode in the echo request is "Reply via an
IPv4 UDP packet with Router Alert", then the IP header MUST contain IPv4 UDP packet with Router Alert", then the IP header MUST contain
the Router Alert IP option. If the reply is sent over an LSP, the the Router Alert IP option of value 0x0 [RFC2113] for IPv4 or 69
topmost label MUST in this case be the Router Alert label (1) (see [RFC7506] for IPv6. If the reply is sent over an LSP, the topmost
label MUST in this case be the Router Alert label (1) (see
[RFC3032]). [RFC3032]).
The format of the echo reply is the same as the echo request. The The format of the echo reply is the same as the echo request. The
Sender's Handle, the Sequence Number, and TimeStamp Sent are copied Sender's Handle, the Sequence Number, and TimeStamp Sent are copied
from the echo request; the TimeStamp Received is set to the time-of- from the echo request; the TimeStamp Received is set to the time-of-
day that the echo request is received (note that this information is day that the echo request is received (note that this information is
most useful if the time-of-day clocks on the requester and the most useful if the time-of-day clocks on the requester and the
replier are synchronized). The FEC Stack TLV from the echo request replier are synchronized). The FEC Stack TLV from the echo request
MAY be copied to the reply. MAY be copied to the reply.
skipping to change at page 48, line 26 skipping to change at page 49, line 28
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/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>.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
DOI 10.17487/RFC2113, February 1997,
<http://www.rfc-editor.org/info/rfc2113>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <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>.
skipping to change at page 49, line 15 skipping to change at page 50, line 20
[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>.
[RFC7506] Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert
Option for MPLS Operations, Administration, and
Maintenance (OAM)", RFC 7506, DOI 10.17487/RFC7506, April
2015, <http://www.rfc-editor.org/info/rfc7506>.
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, DOI 10.17487/RFC0792, September 1981, RFC 792, DOI 10.17487/RFC0792, September 1981,
<http://www.rfc-editor.org/info/rfc792>. <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>.
 End of changes. 14 change blocks. 
60 lines changed or deleted 91 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/