Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04

Hi Joel,
Sorry for the late reply. I missed this email, and was reminded by Adrian.
Thank you for the review. Please see my comments inline below.

Regards
Lizhong

> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 08 Oct 2014 19:20:17 -0400
> From: "Joel M. Halpern" <jmh@joelhalpern.com>
> To: "A. Jean Mahoney" <mahoney@nostrum.com>, gen-art@ietf.org,
> 	"mpls@ietf.org" <mpls@ietf.org>, Adrian Farrel
> <adrian@olddog.co.uk>,
> 	IETF discussion list <ietf@ietf.org>
> Subject: [mpls] [Gen-art] review:
> 	draft-ietf-mpls-lsp-ping-relay-reply-04
> Message-ID: <5435C6B1.2090908@joelhalpern.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-
> ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments you
> may receive.
> 
> Document: draft-ietf-mpls-lsp-ping-relay-reply-04
>      Relayed Echo Reply mechanism for LSP Ping
> Reviewer: Joel M. Halpern
> Review Date: 8-October-2014
> IETF LC End Date: 13-October-2014
> IESG Telechat date: (if known)
> 
> Summary: This document is not ready for publication as a Proposed Standard
> 
> Major issues:
>      There is either a major technical flaw in this document, or there is
a need
> for significantly better explanation.  The following is what I was able to
> understand from reading the document.
>      The procedure in the document calls for a responding or relaying LSR
to
> search the response addresses from the top to the bottom (top being the
> originator of the request, bottom being visible originators).
>   The responder then sends the reply to the first usable address it can
find in
> the stack.  Usable is variously described as "public routable"
> and as "routable" (in sections 4.2), the converse is described as
"unroutable"
> in section 4.3, while section 4.4 uses "routable".
> If it means "routable", then this assumes that the private addresses used
by
> one AS will not happen to also be used in another AS (which would make
> them routable in that domain, directing the reply to completely the wrong
> place.
> If it means "publicly routable", this would seem to fail since routers do
not
> know whether routable addresses are public, private, or simply not
martian.
[Lizhong] the "routable address" means that it is possible to route an IP
packet to this address using the normal information exchanged by the IGP
operating in the AS. I will add the definition explicitly in the document.
And for section 2, change "private address" to "routable address in AS1, but
not routable in AS2". For section 4.2, change "first public routable IP
address" to "first routable IP address".
Hope above changing will make things clear.

> 
> Minor issues:
>      The procedures assume that border routers will know the correct
address
> to put in the reply stack.  It is not bovious that even if the router has
a public
> address, it will get put on.  The requirement stated here is that the
address
> put on be the same one used to originate the reply.  Which would seem
likely
> to be na internal address in many cases.
[Lizhong] If there is a public address on the node, it is also possible to
add that address to the stack, which will help to relay the reply back.
Rephrase section 4.2:
The first address entry added by the replying LSR MUST be same as the source
IP address of Relay Echo Reply (section 4.3) or Echo Reply message (section
4.5) being sent. A second or more address entries could also be added if
necessary, which depends on implementation.

> 
>      The procedure for setting k=0 allowing entries to be removed from the
> stack seems fragile.  It relies on routers being able to determine that
their
> address will not be needed for relay by the next hop.
[Lizhong] if k=0, then the Relay Node Address Stack TLV could be compressed
to reduce the relayed hop number. This is a useful feature, and top to down
searching of the routable address will ensure relaying reply back correctly.

> 
> Nits/editorial comments:
>     Some of the procedure for originating a reply is described in section
4.2 on
> Receiving a request, rather than in seciton 4.3 on originating the reply.
> (Information such as the address to put on the stack, where it goes on the
> stack, and the handling of the reply packet being too large all belong in
4.3.)
[Lizhong] we try to put all Relay Node Address Stack processing into one
place to make it clear. Splitting the stack processing words into two
sections may cause confusion. But we could add a sentence in section 4.3,
saying that the updating of Relay Node Address Stack TLV in Relayed Echo
Reply is described in section 4.2.

> 
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> 
> 
> ------------------------------
> 
> End of mpls Digest, Vol 126, Issue 10
> *************************************