--- 1/draft-ietf-mpls-lsp-ping-relay-reply-05.txt	2014-12-05 07:14:49.116825734 -0800
+++ 2/draft-ietf-mpls-lsp-ping-relay-reply-06.txt	2014-12-05 07:14:49.148826509 -0800
@@ -1,23 +1,23 @@
 
 Network Working Group                                        J. Luo, Ed.
 Internet-Draft                                                       ZTE
 Updates: 4379 (if approved)                                  L. Jin, Ed.
 Intended status: Standards Track
-Expires: May 18, 2015                                     T. Nadeau, Ed.
+Expires: June 8, 2015                                     T. Nadeau, Ed.
                                                              Lucidvision
                                                          G. Swallow, Ed.
                                                                    Cisco
-                                                       November 14, 2014
+                                                        December 5, 2014
 
                Relayed Echo Reply mechanism for LSP Ping
-                draft-ietf-mpls-lsp-ping-relay-reply-05
+                draft-ietf-mpls-lsp-ping-relay-reply-06
 
 Abstract
 
    In some inter autonomous system (AS) and inter-area deployment
    scenarios for RFC 4379 "Label Switched Path (LSP) Ping and
    Traceroute", a replying LSR may not have the available route to the
    initiator, and the Echo Reply message sent to the initiator would be
    discarded resulting in false negatives or complete failure of
    operation of LSP Ping and Traceroute.  This document describes
    extensions to LSP Ping mechanism to enable the replying Label
@@ -33,21 +33,21 @@
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on May 18, 2015.
+   This Internet-Draft will expire on June 8, 2015.
 
 Copyright Notice
 
    Copyright (c) 2014 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
@@ -378,21 +378,22 @@
 
 4.3.  Originating an Relayed Echo Reply
 
    To find out the next relay node address, the node SHOULD check the
    address items in Relay Node Address Stack TLV in sequence from top to
    down, and find the first IP routable address, e.g., A, and the last
    address with K bit set, e.g., B.  If address A is before address B in
    Relay Node Address Stack TLV, then use address B as the next relay
    node address.  Otherwise, use address A as the next relay node
    address.  If there is no B existed, then use A as the next relay node
-   address.
+   address.  If the resolved next relay node address is not routable,
+   then sending of Relayed Echo Reply or Echo Reply will fail.
 
    When the replying LSR receives an Echo Request, and the first IP
    address in the Relay Node Address Stack TLV is not the next relay
    node address, the replying LSR SHOULD send a Relayed Echo Reply
    message to the next relay node.  The processing of Relayed Echo Reply
    is the same with the procedure of the Echo Reply described in
    Section 4.5 of [RFC4379], except the destination IP address and the
    destination UDP port.  The destination IP address of the Relayed Echo
    Reply is set to the next relay node address from the Relay Node
    Address Stack TLV, and both the source and destination UDP port is