draft-ietf-mpls-lsp-ping-relay-reply-10.txt   draft-ietf-mpls-lsp-ping-relay-reply-11.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 Individual Intended status: Standards Track Individual
Expires: January 7, 2016 T. Nadeau, Ed. Expires: April 7, 2016 T. Nadeau, Ed.
Lucidvision Lucidvision
G. Swallow, Ed. G. Swallow, Ed.
Cisco Cisco
July 6, 2015 October 5, 2015
Relayed Echo Reply mechanism for LSP Ping Relayed Echo Reply mechanism for LSP Ping
draft-ietf-mpls-lsp-ping-relay-reply-10 draft-ietf-mpls-lsp-ping-relay-reply-11
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 Label Switching Router (LSR) may not have the Traceroute", a replying Label Switching Router (LSR) may not have the
available route to an initiator, and the Echo Reply message sent to available route to an initiator, and the Echo Reply message sent to
the initiator would be discarded resulting in false negatives or the initiator would be discarded resulting in false negatives or
complete failure of operation of LSP Ping and Traceroute. This complete failure of operation of LSP Ping and Traceroute. This
document describes extensions to LSP Ping mechanism to enable the document describes extensions to LSP Ping mechanism to enable the
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 January 7, 2016. This Internet-Draft will expire on April 7, 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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Relayed Echo Reply message . . . . . . . . . . . . . . . 5 3.1. Relayed Echo Reply message . . . . . . . . . . . . . . . 5
3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . 6 3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . 6
3.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 8 3.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 8
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 8 4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 9
4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 9 4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 9
4.3. Originating an Relayed Echo Reply . . . . . . . . . . . . 10 4.3. Originating an Relayed Echo Reply . . . . . . . . . . . . 10
4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . 10 4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . 11
4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 11 4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 11
4.6. Sending Subsequent Echo Requests . . . . . . . . . . . . 11 4.6. Sending Subsequent Echo Requests . . . . . . . . . . . . 12
4.7. Impact to Traceroute . . . . . . . . . . . . . . . . . . 12 4.7. Impact to Traceroute . . . . . . . . . . . . . . . . . . 12
5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 12 5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 14 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. New Message Type . . . . . . . . . . . . . . . . . . . . 14 8.1. New Message Type . . . . . . . . . . . . . . . . . . . . 15
8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 15 8.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 16
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document describes extensions to the Label Switched Path (LSP) This document describes extensions to the Label Switched Path (LSP)
Ping as specified in [RFC4379], by adding a relayed echo reply Ping as specified in [RFC4379], by adding a relayed echo reply
mechanism which could be used to report data plane failures for inter mechanism which could be used to report data plane failures for inter
autonomous system (AS) and inter-area LSPs. Without these autonomous system (AS) and inter-area LSPs. Without these
extensions, the ping functionality provided by [RFC4379] would fail extensions, the ping functionality provided by [RFC4379] would fail
in many deployed inter-AS scenarios, since the replying Label in many deployed inter-AS scenarios, since the replying Label
Switching Router (LSR) in one AS may not have an available route to Switching Router (LSR) in one AS may not have an available route to
skipping to change at page 4, line 9 skipping to change at page 4, line 9
from PE1 directed towards PE2 can result in a failure because an LSR from PE1 directed towards PE2 can result in a failure because an LSR
in AS2 may not be able to send the Echo Reply message. E.g., P2 in AS2 may not be able to send the Echo Reply message. E.g., P2
cannot forward packets back to PE1 given that it is an routable IP cannot forward packets back to PE1 given that it is an routable IP
address in AS1 but not routable in AS2. In this case, PE1 would address in AS1 but not routable in AS2. In this case, PE1 would
detect a path break, as the Echo Reply messages would not be detect a path break, as the Echo Reply messages would not be
received. Then localization of the actual fault would not be received. Then localization of the actual fault would not be
possible. possible.
Note that throughout the document, routable address means that it is Note that throughout the document, routable address means that it is
possible to route an IP packet to this address using the normal possible to route an IP packet to this address using the normal
information exchanged by the IGP operating in the AS. information exchanged by the IGP and BGP (or EGP) operating in the
AS.
+-------+ +-------+ +------+ +------+ +------+ +------+ +-------+ +-------+ +------+ +------+ +------+ +------+
| | | | | | | | | | | | | | | | | | | | | | | |
| PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 |
| | | | | | | | | | | | | | | | | | | | | | | |
+-------+ +-------+ +------+ +------+ +------+ +------+ +-------+ +-------+ +------+ +------+ +------+ +------+
<---------------AS1-------------><---------------AS2------------> <---------------AS1-------------><---------------AS2------------>
<---------------------------- LSP ------------------------------> <---------------------------- LSP ------------------------------>
Figure 1: Simple Inter-AS LSP Configuration Figure 1: Simple Inter-AS LSP Configuration
A second example that illustrates how [RFC4379] would be insufficient A second example that illustrates how [RFC4379] would be insufficient
would be the inter-area situation in a seamless MPLS architecture would be the inter-area situation in a seamless MPLS architecture
[I-D.ietf-mpls-seamless-mpls] as shown below in Figure 2. In this [I-D.ietf-mpls-seamless-mpls] as shown below in Figure 2. In this
example LSRs in the core network would not have IP reachable route to example LSRs in the core network would not have IP reachable route to
any of the ANs. When tracing an LSP from one access node (AN) to the any of the access nodes (AN). When tracing an LSP from one AN to the
remote AN, the LSR1/LSR2 node cannot send the Echo Reply either, like remote AN, the LSR1/LSR2 node cannot send the Echo Reply either, like
the P2 node in the inter-AS scenario in Figure 1. the P2 node in the inter-AS scenario in Figure 1.
+-------+ +-------+ +------+ +------+ +-------+ +-------+ +------+ +------+
| | | | | | | | | | | | | | | |
+--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN
/ | | /| | | | | | / | | /| | | | | |
+----+/ +-------+\/ +-------+ +------+ /+------+ +----+/ +-------+\/ +-------+ +------+ /+------+
| AN | /\ \/ | AN | /\ \/
+----+\ +-------+ \+-------+ +------+/\ +------+ +----+\ +-------+ \+-------+ +------+/\ +------+
skipping to change at page 5, line 16 skipping to change at page 5, line 19
to the next relay node or to the initiator. Using a recursive to the next relay node or to the initiator. Using a recursive
approach, relay node could relay the message to the next relay node approach, relay node could relay the message to the next relay node
until the initiator is reached. until the initiator is reached.
The LSP Ping relay mechanism in this document is defined for unicast 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 case. How to apply the LSP Ping relay mechanism in multicast case is
out of the scope. out of the scope.
3. Extensions 3. Extensions
[RFC4379] describes the basic MPLS LSP Ping mechanism, which defines [RFC4379] defines two message types, Echo Request and Echo Reply.
two message types, Echo Request and Echo Reply message. This This document defines a new message type, Relayed Echo Reply. The
document defines a new message, Relayed Echo Reply message. This new Relayed Echo Reply message is used in place of the Echo Reply message
message is used to replace Echo Reply message which is sent from the when an LSR is replying LSR to a relay node.
replying LSR to a relay node or from a relay node to another relay
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
document, to carry the IP addresses of the relay nodes for the document, to carry the IP addresses of the relay nodes for the
replying LSR. replying LSR.
In addition, MTU (Maximum Transmission Unit) Exceeded Return Code is In addition, MTU (Maximum Transmission Unit) Exceeded Return Code is
defined to indicate to the initiator that one or more TLVs will not defined to indicate to the initiator that one or more TLVs will not
be returned due to MTU size. be returned due to MTU size.
It should be noted that this document focuses only on detecting the It should be noted that this document focuses only on detecting the
skipping to change at page 6, line 23 skipping to change at page 6, line 23
messages if the echo reply relayed mechanism described in this messages if the echo reply relayed mechanism described in this
document is required. Figure 3 illustrates the TLV format. document is required. Figure 3 illustrates the TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Source Port | Reply Add Type| Reserved | | Initiator Source Port | Reply Add Type| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address of Replying Router (0, 4, or 16 octects) | | Source Address of Replying Router (0, 4, or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address Offset | Number of Relayed Addresses | | Destination Address Offset | Number of Relayed Addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Stack of Relayed Addresses ~ ~ Stack of Relayed Addresses ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Relay Node Address Stack TLV Figure 3: Relay Node Address Stack TLV
- Type: value is TBD2. The value should be assigned by IANA from - Type: value is TBD2. The value should be assigned by IANA from
32768-49161 as suggested by [RFC4379] Section 3. 32768-49161 as suggested by [RFC4379] Section 3.
skipping to change at page 7, line 9 skipping to change at page 7, line 9
Type# Address Type Address Length Type# Address Type Address Length
---- ------------ ------------ ---- ------------ ------------
0 Null 0 0 Null 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.
- Source Address of Replying Router: source IP address of the - Source Address of Replying Router: source IP address of the
originator of Echo Reply or Replay Echo Reply message. originator of Echo Reply or Replay Echo Reply message.
- Destination Address Offset: an offset (octets) to indicate the - Destination Address Offset: the offset in octets from the top-of-
position of the destination address of the Reply or Relayed Reply stack to the destination address entry. Each entry size has been
message. The entry on the top of the Stack of Relayed Addresses listed in this section. Please also refer to section 4.2 for more
will have offset of 0. detail of the operation.
- Number of Relayed Addresses: an integer indicating the number of - Number of Relayed Addresses: an integer indicating the number of
relayed addresses in the stack. relayed addresses in the stack.
- Stack of Relayed Addresses: a list of relay node addresses. - Stack of Relayed Addresses: a list of relay node address entries.
This stack grows downward, with relay nodes address further along
the LSP appearing lower down in the stack. Please refer to
section 4.2 for the relay node discovery mechanism.
The format of each relay node address is as below: The format of each relay node address entry is as below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type |K| Reserved | Reserved | | Address Type |K| Reserved | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Relayed Address (0, 4, or 16 octects) ~ ~ Relayed Address (0, 4, or 16 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type# Address Type Address Length Figure 4: Relay Node Address Entry
---- ------------ ------------
0 Null 0 Type# Address Type Address Length Size of the Entry
1 IPv4 4 ---- ------------ ------------ -----------------
2 IPv6 16 0 Null 0 4
1 IPv4 4 8
2 IPv6 16 20
Reserved: The two fields are reserved and MUST be set to zero. Reserved: The two fields are reserved and MUST be set to zero.
K bit: if the K bit is set to 1, then this address stack entry MUST K bit: if the K bit is set to 1, then this address stack entry MUST
NOT be stripped from the Relay Node Address Stack during processing NOT be stripped from the Relay Node Address Stack during processing
described in Section 4.2. If the K bit is clear, the entry might be described in Section 4.2. If the K bit is clear, the entry might be
stripped according to the processing described in Section 4.2. stripped according to the processing described in Section 4.2.
Having the K bit set in the relay node address entry causes that Having the K bit set in the relay node address entry causes that
entry to be preserved in the Relay Node Address Stack TLV for the entry to be preserved in the Relay Node Address Stack TLV for the
skipping to change at page 8, line 31 skipping to change at page 8, line 36
added: added:
Before sending Echo Reply, the new packet size should be checked. If Before sending Echo Reply, the new packet size should be checked. If
Best-return-code is 3 ("Replying router is an egress for the FEC at Best-return-code is 3 ("Replying router is an egress for the FEC at
stack depth"), or 8 ("Label switched at stack-depth"), and if the stack depth"), or 8 ("Label switched at stack-depth"), and if the
packet size exceeds MTU size, then Best-return-code is TBD3 ("One or packet size exceeds MTU size, then Best-return-code is TBD3 ("One or
more TLVs not returned due to MTU size") more TLVs not returned due to MTU size")
4. Procedures 4. Procedures
In the following section, we describe the relay reply procedures with To preform a ping operation, the initiator first discovers the relay
traceroute operation. If operator has knowledge of the relay nodes, nodes. Once those nodes have been discovered, the initiator includes
the initiator could do LSP Ping by directly sending Echo Request with the Relay Node Address Stack TLV into any Echo Request message. The
Relay Node Address Stack TLV containing the already known relay node can then ping as normal. Note that in some cases, the repeated
lack of replies to Echo Request messages may be due to a route change
that has impacted the necessary stack of relay nodes. In this case
the initiator may need to re-discover the relay nodes. The following
sections describe the procedures for sending and receiving Echo
Request messages with the the Relay Node Address Stack TLV. These
procedures can be used in "trace route" mode to discover the relay
nodes. nodes.
4.1. Sending an Echo Request 4.1. Sending an Echo Request
In addition to the procedures described in section 4.3 of [RFC4379], In addition to the procedures described in section 4.3 of [RFC4379],
a Relay Node Address Stack TLV MUST be carried in the Echo Request a Relay Node Address Stack TLV MUST be carried in the Echo Request
message if the relay functionality is required. message if the relay functionality is required. The relay function
initiation is out of the scope of this document, one possible way is
that the operator will explicitly add an option to the ping command.
When the initiator sends the first Echo Request with a Relay Node When the initiator sends the first Echo Request with a Relay Node
Address Stack TLV, the TLV MUST contain the initiator address as the Address Stack TLV, the TLV MUST contain the initiator address as the
first entry of the stack of relayed addresses, the Destination first entry of the stack of relayed addresses, the Destination
Address Offset set to this entry, and the source address of the Address Offset set to this entry, and the source address of the
replying router set to null. The Initiator Source Port field MUST be replying router set to null. The Initiator Source Port field MUST be
set to the source UDP port. Note that the first relay node address set to the source UDP port. Note that the first relay node address
in the stack will always be the initiator's address. in the stack will always be the initiator's address.
When sending subsequent Echo Request message, refer to section 4.6. When sending subsequent Echo Request message, refer to section 4.6.
4.2. Receiving an Echo Request 4.2. Receiving an Echo Request
The Type of the Relay Node Address Stack TLV is chosen from the range The Type of the Relay Node Address Stack TLV is chosen from the range
32768 to 49161 so that (per section 3 of [RFC4379]) an LSR that does defined in [RFC4379] as "optional TLVs that can be silently dropped
not recognize the TLV knows that the TLV is optional and can safely if not recognized. An LSR that does not recognize the TLV SHOULD
ignore it. ignore it.
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 in an Echo Request Upon receiving a Relay Node Address Stack TLV in an Echo Request
message, the receiver updates the "Source Address of Replying message, the receiver updates the "Source Address of Replying
Router". The address MUST be same as the source IP address of Relay Router". The address MUST be same as the source IP address of Relay
Echo Reply (section 4.3) or Echo Reply message (section 4.5) being Echo Reply (section 4.3) or Echo Reply message (section 4.5) being
sent. sent.
skipping to change at page 12, line 21 skipping to change at page 12, line 40
if (Relay Node Address Stack TLV exists) { if (Relay Node Address Stack TLV exists) {
Print the Source Address of Replying Router in Print the Source Address of Replying Router in
Relay Node Address Stack TLV; Relay Node Address Stack TLV;
} else { } else {
Print the source IP address of Echo Reply message; 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. AS1 and AS2 are Considering the inter-AS scenario in Figure 5 below. AS1 and AS2 are
two independent address domains. In the example, an LSP has been two independent address domains. In the example, an LSP has been
created between PE1 to PE2, but PE1 in AS1 is not reachable by P2 in created between PE1 to PE2, but PE1 in AS1 is not reachable by P2 in
AS2. AS2.
+-------+ +-------+ +------+ +------+ +------+ +------+ +-------+ +-------+ +------+ +------+ +------+ +------+
| | | | | | | | | | | | | | | | | | | | | | | |
| PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 |
| | | | | | | | | | | | | | | | | | | | | | | |
+-------+ +-------+ +------+ +------+ +------+ +------+ +-------+ +-------+ +------+ +------+ +------+ +------+
<---------------AS1-------------><---------------AS2------------> <---------------AS1-------------><---------------AS2------------>
<--------------------------- LSP -------------------------------> <--------------------------- LSP ------------------------------->
Figure 4: Example Inter-AS LSP Figure 5: Example Inter-AS LSP
When performing LSP traceroute on the LSP, the first Echo Request When performing LSP traceroute on the LSP, the first Echo Request
sent by PE1 with outer-most label TTL=1, contains the Relay Node sent by PE1 with outer-most label TTL=1, contains the Relay Node
Address Stack TLV with PE1's address as the first relayed address. Address Stack TLV with PE1's address as the first relayed address.
After processed by P1, P1's interface address facing ASBR1 without After processed by P1, P1's interface address facing ASBR1 without
the K bit set will be added in the Relay Node Address Stack TLV the K bit set will be added in the Relay Node Address Stack TLV
address list following PE1's address in the Echo Reply. address list following PE1's address in the Echo Reply.
PE1 copies the Relay Node Address Stack TLV into the next Echo PE1 copies the Relay Node Address Stack TLV into the next Echo
skipping to change at page 15, line 22 skipping to change at page 15, line 49
8.2. New TLV 8.2. New TLV
This document requires allocation of one new TLV from "Multi-Protocol This document requires allocation of one new TLV from "Multi-Protocol
Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
registry, the "TLVs" registry: registry, the "TLVs" registry:
Type Meaning Type Meaning
---- -------- ---- --------
TBD2 Relay Node Address Stack TLV TBD2 Relay Node Address Stack TLV
A suggested value should be assigned from "Standards Action" range A value should be assigned from "Standards Action" range
(32768-49161) as suggested by [RFC4379] Section 3, using the first (32768-49161) as suggested by [RFC4379] Section 3, using the first
free value within this range. free value within this range.
8.3. MTU Exceeded Return Code 8.3. MTU Exceeded Return Code
This document requires allocation of MTU Exceeded return code from This document requires allocation of MTU Exceeded return code from
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
Ping Parameters" registry, the "Return Codes" registry: Ping Parameters" registry, the "Return Codes" registry:
Value Meaning Value Meaning
skipping to change at page 16, line 15 skipping to change at page 16, line 38
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
[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>.
[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>.
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", draft- M., and D. Steinberg, "Seamless MPLS Architecture", draft-
ietf-mpls-seamless-mpls-07 (work in progress), June 2014. ietf-mpls-seamless-mpls-07 (work in progress), June 2014.
Authors' Addresses Authors' Addresses
 End of changes. 28 change blocks. 
50 lines changed or deleted 65 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/