draft-ietf-mpls-lsp-ping-relay-reply-03.txt   draft-ietf-mpls-lsp-ping-relay-reply-04.txt 
Network Working Group J. Luo, Ed. Network Working Group J. Luo, Ed.
Internet-Draft ZTE Internet-Draft ZTE
Updates: 4379 (if approved) L. Jin, Ed. Updates: 4379 (if approved) L. Jin, Ed.
Intended status: Standards Track Intended status: Standards Track
Expires: October 4, 2014 T. Nadeau, Ed. Expires: January 31, 2015 T. Nadeau, Ed.
Lucidvision Lucidvision
G. Swallow, Ed. G. Swallow, Ed.
Cisco Cisco
April 2, 2014 July 30, 2014
Relayed Echo Reply mechanism for LSP Ping Relayed Echo Reply mechanism for LSP Ping
draft-ietf-mpls-lsp-ping-relay-reply-03 draft-ietf-mpls-lsp-ping-relay-reply-04
Abstract Abstract
In some inter autonomous system (AS) and inter-area deployment In some inter autonomous system (AS) and inter-area deployment
scenarios for RFC 4379 "Label Switched Path (LSP) Ping and scenarios for RFC 4379 "Label Switched Path (LSP) Ping and
Traceroute", a replying LSR may not have the available route to the Traceroute", a replying LSR may not have the available route to the
initiator, and the Echo Reply message sent to the initiator would be initiator, and the Echo Reply message sent to the initiator would be
discarded resulting in false negatives or complete failure of discarded resulting in false negatives or complete failure of
operation of LSP Ping and Traceroute. This document describes operation of LSP Ping and Traceroute. This document describes
extensions to LSP Ping mechanism to enable the replying Label extensions to LSP Ping mechanism to enable the replying Label
Switching Router (LSR) to have the capability to relay the Echo Switching Router (LSR) to have the capability to relay the Echo
Response by a set of routable intermediate nodes to the initiator. Response by a set of routable intermediate nodes to the initiator.
This document updates RFC 4379. This document updates RFC 4379.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 4, 2014. This Internet-Draft will expire on January 31, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 3, line 7 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Relayed Echo Reply message . . . . . . . . . . . . . . . . 6 3.1. Relayed Echo Reply message . . . . . . . . . . . . . . . 5
3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . . 6 3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . 6
3.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 8 3.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 7
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 8 4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 8
4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 8 4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 8
4.3. Originating an Relayed Echo Reply . . . . . . . . . . . . 9 4.3. Originating an Relayed Echo Reply . . . . . . . . . . . . 9
4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . . 9 4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . 9
4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 10 4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 10
4.6. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 10 4.6. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 10
5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 10 4.7. Impact to Traceroute . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 10
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 12
8.1. New Message Type . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. New Message Type . . . . . . . . . . . . . . . . . . . . 13
8.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 13 8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 8.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 13
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document describes the extensions to the Label Switched Path This document describes the extensions to the Label Switched Path
(LSP) Ping as specified in [RFC4379], by adding a relayed echo reply (LSP) Ping as specified in [RFC4379], by adding a relayed echo reply
mechanism which could be used to detect data plane failures for the mechanism which could be used to detect data plane failures for the
inter autonomous system (AS) and inter-area LSPs. The extensions are inter autonomous system (AS) and inter-area LSPs. The extensions are
to update the [RFC4379]. Without these extensions, the ping to update the [RFC4379]. Without these extensions, the ping
functionality provided by [RFC4379] would fail in many deployed functionality provided by [RFC4379] would fail in many deployed
inter-AS scenarios, since the replying LSR in one AS may not have the inter-AS scenarios, since the replying LSR in one AS may not have the
skipping to change at page 6, line 5 skipping to change at page 5, line 9
Figure 2: Seamless MPLS Architecture Figure 2: Seamless MPLS Architecture
This document describes extensions to the LSP Ping mechanism to This document describes extensions to the LSP Ping mechanism to
facilitate a response from the replying LSR, by defining a simple facilitate a response from the replying LSR, by defining a simple
mechanism that uses a relay node (e.g, ASBR) to relay the message mechanism that uses a relay node (e.g, ASBR) to relay the message
back to the initiator. Every designated or learned relay node must back to the initiator. Every designated or learned relay node must
have an IP route to the next relay node or to the initiator. Using a have an IP route to the next relay node or to the initiator. Using a
recursive approach, relay node could relay the message to the next recursive approach, relay node could relay the message to the next
relay node until the initiator is reached. relay node until the initiator is reached.
The LSP Ping relay mechanism in this document is defined for unicast
case. How to apply the LSP Ping relay mechanism in multicast case is
out of the scope.
3. Extensions 3. Extensions
[RFC4379] describes the basic MPLS LSP Ping mechanism, which defines [RFC4379] describes the basic MPLS LSP Ping mechanism, which defines
two message types, Echo Request and Echo Reply message. This two message types, Echo Request and Echo Reply message. This
document defines a new message, Relayed Echo Reply message. This new document defines a new message, Relayed Echo Reply message. This new
message is used to replace Echo Reply message which is sent from the message is used to replace Echo Reply message which is sent from the
replying LSR to a relay node or from a relay node to another relay replying LSR to a relay node or from a relay node to another relay
node. node.
A new TLV named Relay Node Address Stack TLV is defined in this A new TLV named Relay Node Address Stack TLV is defined in this
skipping to change at page 6, line 28 skipping to change at page 5, line 36
In addition, a new Return Code is defined to notify the initiator In addition, a new Return Code is defined to notify the initiator
that the packet length is exceeded unexpected by the Relay Node that the packet length is exceeded unexpected by the Relay Node
Address Stack TLV. Address Stack TLV.
It should be noted that this document focuses only on detecting the It should be noted that this document focuses only on detecting the
LSP which is set up using a uniform IP address family type. That is, LSP which is set up using a uniform IP address family type. That is,
all hops between the source and destination node use the same address all hops between the source and destination node use the same address
family type for their LSP ping control planes. This does not family type for their LSP ping control planes. This does not
preclude nodes that support both IPv6 and IPv4 addresses preclude nodes that support both IPv6 and IPv4 addresses
simultaneously, but the entire path must be addressable using only simultaneously, but the entire path must be addressable using only
one address family type. Supporting for mixed IPv4-only and IPv6- one address family type. Supporting for mixed IPv4-only and
only is beyond the scope of this document. IPv6-only is beyond the scope of this document.
3.1. Relayed Echo Reply message 3.1. Relayed Echo Reply message
The Relayed Echo Reply message is a UDP packet, and the UDP payload The Relayed Echo Reply message is a UDP packet, and the UDP payload
has the same format with Echo Request/Reply message. A new message has the same format with Echo Request/Reply message. A new message
type is requested from IANA. type is requested from IANA.
New Message Type: New Message Type:
Value Meaning Value Meaning
----- ------- ----- -------
skipping to change at page 8, line 7 skipping to change at page 7, line 23
Type# Address Type Address Length Type# Address Type Address Length
---- ------------ ------------ ---- ------------ ------------
0 Unspecified 0 0 Unspecified 0
1 IPv4 4 1 IPv4 4
2 IPv6 16 2 IPv6 16
Reserved: This field is reserved and MUST be set to zero. Reserved: This field is reserved and MUST be set to zero.
K bit: if the K bit is set to 1, then this sub-TLV MUST be kept in K bit: if the K bit is set to 1, then this sub-TLV MUST be kept in
Relay Node Address Stack during TLV compress process described in Relay Node Address Stack during TLV compress process described in
section 4.2. The K bit may be set by ASBRs whose address would be section 4.2. The entry with Unspecified Address Type SHOULD NOT set
kept in the stack if necessary. K bit.
Having the K bit set on the relay node address entry causes that
entry to be preserved in the Relay Node Address Stack TLV for the
entire traceroute operation. A responder node MAY set the K bit to
ensure its relay node address entry remains as one of the relay nodes
in the Relay Node Address Stack TLV. Some nodes could be configured
to always set the K bit, or the module handling MPLS echo requests
could discover its K bit use through topology awareness. How a node
determines to set the K bit is outside the scope of this document.
Relayed Address: this field specifies the node address, either IPv4 Relayed Address: this field specifies the node address, either IPv4
or IPv6. or IPv6.
3.3. New Return Code 3.3. New Return Code
A new Return Code is used by the replying LSR to notify the initiator A new Return Code is used by the replying LSR to notify the initiator
that the packet length is exceeded unexpected by the Relay Node that the packet length is exceeded unexpected by the Relay Node
Address Stack TLV. Address Stack TLV.
skipping to change at page 9, line 7 skipping to change at page 8, line 34
In addition to the processes in section 4.4 of [RFC4379], the In addition to the processes in section 4.4 of [RFC4379], the
procedures of the Relay Node Address Stack TLV are defined here. procedures of the Relay Node Address Stack TLV are defined here.
Upon receiving a Relay Node Address Stack TLV of the Echo Request Upon receiving a Relay Node Address Stack TLV of the Echo Request
message, the receiver MUST check the addresses of the stack in message, the receiver MUST check the addresses of the stack in
sequence from top to bottom (the first address in the stack will be sequence from top to bottom (the first address in the stack will be
the first one to be checked), to find out the first public routable the first one to be checked), to find out the first public routable
IP address. Those address entries behind of the first routable IP IP address. Those address entries behind of the first routable IP
address in the address list with K bit set to 0 MUST be deleted, and address in the address list with K bit set to 0 MUST be deleted, and
the address entry of the replying LSR MUST be added at the bottom of the address entry of the replying LSR MUST be added at the bottom of
the stack. Those address entries with K bit set to 1 MUST be kept in the stack. The address entry added by the replying LSR MUST be same
the stack. The updated Relay Node Address Stack TLV MUST be carried as the source IP address of Relay Echo Reply (section 4.3) or Echo
in the response message. Reply message (section 4.5) being sent. Those address entries with K
bit set to 1 MUST be kept in the stack. The updated Relay Node
Address Stack TLV MUST be carried in the response message.
If the replying LSR is configured to hide its routable address If the replying LSR is configured to hide its routable address
information, the address entry added in the stack SHOULD be a blank information, the address entry added in the stack SHOULD be a blank
entry with Address Type set to unspecified. The blank address entry entry with Address Type set to unspecified. The blank address entry
in the receiving Echo Request SHOULD be treated as an unroutable in the receiving Echo Request SHOULD be treated as an unroutable
address entry. address entry.
If the packet length was exceeded unexpectedly by the Relay Node If the packet length was exceeded unexpectedly by the Relay Node
Address Stack TLV, the TLV SHOULD be returned back unchanged in the Address Stack TLV, the TLV SHOULD be returned back unchanged in the
Echo Reply message. And the new return code in section 3.3 SHOULD be Echo Reply message. And the new return code in section 3.3 SHOULD be
skipping to change at page 9, line 39 skipping to change at page 9, line 22
An LSR not recognize the Relay Node Address Stack TLV, SHOULD ignore An LSR not recognize the Relay Node Address Stack TLV, SHOULD ignore
it according to section 3 of [RFC4379]. it according to section 3 of [RFC4379].
4.3. Originating an Relayed Echo Reply 4.3. Originating an Relayed Echo Reply
When the replying LSR receives an Echo Request with the first IP When the replying LSR receives an Echo Request with the first IP
address in the Relay Node Address Stack TLV is IP unroutable, the address in the Relay Node Address Stack TLV is IP unroutable, the
replying LSR SHOULD send a Relayed Echo Reply message to the first replying LSR SHOULD send a Relayed Echo Reply message to the first
routable intermediate node. The processing of Relayed Echo Reply is routable intermediate node. The processing of Relayed Echo Reply is
the same with the procedure of the Echo Reply described in Section the same with the procedure of the Echo Reply described in
4.5 of [RFC4379], except the destination IP address and the Section 4.5 of [RFC4379], except the destination IP address and the
destination UDP port. The destination IP address of the Relayed Echo destination UDP port. The destination IP address of the Relayed Echo
Reply is set to the first routable IP address from the Relay Node Reply is set to the first routable IP address from the Relay Node
Address Stack TLV, and both the source and destination UDP port is Address Stack TLV, and both the source and destination UDP port is
set to 3503. set to 3503.
4.4. Relaying an Relayed Echo Reply 4.4. Relaying an Relayed Echo Reply
Upon receiving an Relayed Echo Reply message with its own address as Upon receiving an Relayed Echo Reply message with its own address as
the destination address in the IP header, the relay node SHOULD check the destination address in the IP header, the relay node SHOULD check
the address items in Relay Node Address Stack TLV in sequence from the address items in Relay Node Address Stack TLV in sequence from
top to down, and find the first routable node address. top to down, and find the first routable node address.
If the first routable address is the top one of the address list, If the first routable address is the top one of the address list,
e.g, the initiator address, the relay node SHOULD send an Echo Reply e.g, the initiator address, the relay node SHOULD send an Echo Reply
message to the initiator containing the same payload with the Relayed message to the initiator containing the same payload with the Relayed
Echo Reply message received. See section 4.5 for detail. Echo Reply message received. See section 4.5 for detail.
If the first routable address is not the top one of the address list, If the first routable address is not the top one of the address list,
e.g, another intermediate relay node, the relay node SHOULD send an e.g, another intermediate relay node, the relay node SHOULD send an
Relayed Echo Reply message to this relay node with the payload Relayed Echo Reply message to this relay node with the payload
unchanged. unchanged. The TTL of the Relayed Echo Reply SHOULD be copied from
the received Relay Echo Reply and decremented by 1.
Note, the replying LSR SHOULD send a Relayed Echo Reply message to Note, the replying LSR SHOULD send a Relayed Echo Reply message to
the first relay node found in Relay Node Address Stack TLV that is the first relay node found in Relay Node Address Stack TLV that is IP
routable by the router. The routable address MUST be located before routable. The routable address MUST be located before the source IP
the source IP address of the received Relayed Echo Reply which must address of the received Relayed Echo Reply which must be also in the
be also in the stack, otherwise the Relayed Echo Reply should not be stack, otherwise the Relayed Echo Reply SHOULD not be sent, so as to
sent, so as to avoid potential loop. avoid potential loop.
4.5. Sending an Echo Reply 4.5. Sending an Echo Reply
The Echo Reply is sent in two cases: The Echo Reply is sent in two cases:
1. When the replying LSR receives an Echo Request with the first IP 1. When the replying LSR receives an Echo Request with the first IP
address in the Relay Node Address Stack TLV IP routable, the replying address in the Relay Node Address Stack TLV IP routable, the replying
LSR would send an Echo Reply to the initiator. In addition to the LSR would send an Echo Reply to the initiator. In addition to the
procedure of the Echo Reply described in Section 4.5 of [RFC4379], procedure of the Echo Reply described in Section 4.5 of [RFC4379],
the Relay Node Address Stack TLV would be carried in the Echo Reply. the Relay Node Address Stack TLV would be carried in the Echo Reply.
2. When the intermediate relay node receives a Relayed Echo Reply 2. When the intermediate relay node receives a Relayed Echo Reply
with the first IP address in the Relay Node Address Stack TLV IP with the first IP address in the Relay Node Address Stack TLV IP
routable, the intermediate relay node would send the Echo Reply to routable, the intermediate relay node would send the Echo Reply to
the initiator with the UDP payload unchanged other than the Message the initiator with the UDP payload unchanged other than the Message
Type field (change from type of Relayed Echo Reply to Echo Reply). Type field (change from type of Relayed Echo Reply to Echo Reply).
The destination IP address of the Echo Reply is set to the first IP The destination IP address of the Echo Reply is set to the first IP
address in the stack, and the destination UDP port would be copied address in the stack, and the destination UDP port would be copied
from the Initiator Source Port field of the Relay Node Address Stack from the Initiator Source Port field of the Relay Node Address Stack
TLV. The source UDP port should be 3503. TLV. The source UDP port should be 3503. The TTL of the Echo Reply
SHOULD be copied from the received Relay Echo Reply and decremented
by 1.
4.6. Receiving an Echo Reply 4.6. Receiving an Echo Reply
In addition to the processes in Section 4.6 of [RFC4379], the In addition to the processes in Section 4.6 of [RFC4379], the
initiator would copy the Relay Node Address Stack TLV received in the initiator would copy the Relay Node Address Stack TLV received in the
Echo Reply to the next Echo Request. Echo Reply to the next Echo Request.
4.7. Impact to Traceroute
Source IP address in Echo Reply and Relay Echo Reply are to be of the
address of the node sending those packets, not the original
responding node. Then the traceroute address output module will
print the source IP address as below:
if (Relay Node Address Stack TLV exists) {
Print the last address in the stack;
} else {
Print the source IP address of Echo Reply message;
}
5. LSP Ping Relayed Echo Reply Example 5. LSP Ping Relayed Echo Reply Example
Considering the inter-AS scenario in Figure 4 below. Considering the inter-AS scenario in Figure 4 below.
+-------+ +-------+ +------+ +------+ +------+ +------+ +-------+ +-------+ +------+ +------+ +------+ +------+
| | | | | | | | | | | | | | | | | | | | | | | |
| PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 |
| | | | | | | | | | | | | | | | | | | | | | | |
+-------+ +-------+ +------+ +------+ +------+ +------+ +-------+ +-------+ +------+ +------+ +------+ +------+
<---------------AS1-------------><---------------AS2------------> <---------------AS1-------------><---------------AS2------------>
skipping to change at page 14, line 16 skipping to change at page 14, line 16
----- ------- ----- -------
TBD Response Packet length was exceeded unexpected by the Relay TBD Response Packet length was exceeded unexpected by the Relay
Node Address Stack TLV unexpected Node Address Stack TLV unexpected
The value should be assigned from the "Standards Action" range The value should be assigned from the "Standards Action" range
(0-191), and using the lowest free value within this range. (0-191), and using the lowest free value within this range.
9. Acknowledgement 9. Acknowledgement
The authors would like to thank Carlos Pignataro, Xinwen Jiao, Manuel The authors would like to thank Carlos Pignataro, Xinwen Jiao, Manuel
Paul, Loa Andersson, Wim Henderickx, Mach Chen, Thomas Morin and Paul, Loa Andersson, Wim Henderickx, Mach Chen, Thomas Morin, Gregory
Gregory Mirsky for their valuable comments and suggestions. Mirsky, and Nobo Akiya for their valuable comments and suggestions.
10. Contributors 10. Contributors
Ryan Zheng Ryan Zheng
JSPTPD JSPTPD
371, Zhongshan South Road 371, Zhongshan South Road
Nanjing, 210006, China Nanjing, 210006, China
Email: ryan.zhi.zheng@gmail.com Email: ryan.zhi.zheng@gmail.com
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-mpls-proxy-lsp-ping]
Swallow, G., Lim, V., and S. Aldrin, "Proxy MPLS Echo
Request", draft-ietf-mpls-proxy-lsp-ping-02 (work in
progress), July 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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. February 2006.
11.2. Informative References 11.2. Informative References
[I-D.ietf-mpls-seamless-mpls] [I-D.ietf-mpls-seamless-mpls]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M., and D. Steinberg, "Seamless MPLS Architecture", M., and D. Steinberg, "Seamless MPLS Architecture", draft-
draft-ietf-mpls-seamless-mpls-06 (work in progress), ietf-mpls-seamless-mpls-07 (work in progress), June 2014.
February 2014.
Authors' Addresses Authors' Addresses
Jian Luo (editor) Jian Luo (editor)
ZTE ZTE
50, Ruanjian Avenue 50, Ruanjian Avenue
Nanjing, 210012, China Nanjing, 210012, China
Email: luo.jian@zte.com.cn Email: luo.jian@zte.com.cn
 End of changes. 18 change blocks. 
53 lines changed or deleted 89 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/