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

["Joel M. Halpern" <[e-mail]>]

If the process for this draft is to use the top address that can be 
reached in the routing table, then there is a significant probability 
that the original source address, which is always at the top of the 
list, will be used.  As such, the intended problem will not be solved.

Assuming that the source domain and the replying domain are not using 
the same private address space, while trying to craft a solution for 
replying to messages sourced by nodes in a private address domain, does 
not seem effective.

Yes, changing the text so that you never refer to public address and 
always talk about routable address will make the document consistent. 
But that does not seem to me to be sufficient.  The design, with the 
search order and the removal of entries, is clearly aimed at using as 
few relays as possible.  Which is understandable.  But makes the problem 
very hard.

Yours,
Joel

On 10/20/14, 2:35 AM, Lizhong Jin wrote:
> 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" <[e-mail]>
>> To: "A. Jean Mahoney" <[e-mail]>, [e-mail],
>> 	"[e-mail]" <[e-mail]>, Adrian Farrel
>> <[e-mail]>,
>> 	IETF discussion list <[e-mail]>
>> Subject: [mpls] [Gen-art] review:
>> 	draft-ietf-mpls-lsp-ping-relay-reply-04
>> Message-ID: <[e-mail]>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>>
>> ------------------------------
>>
>> End of mpls Digest, Vol 126, Issue 10
>> *************************************
>
>