Hi Joel, see inline below, thanks. Lizhong
> 2014.10.21，PM9:30，Joel M. Halpern <[email protected]> wrote ： > > 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. [Lizhong] let me give an example to explain: the source address A is firstly added to the stack, then a second routable address B for replying AS is also added. The reply node will not use address A since it's not routable, then it will use address B. So it will work and I don't see the problem. > > 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. [Lizhong] still use the example above, source address A may be skipped if the node is able to reach the initiator directly. The reply path will not be redundant. > > 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. [Lizhong] any suggestion would be appreciated. > > 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" <[email protected]> >>> To: "A. Jean Mahoney" <[email protected]>, [email protected], >>> "[email protected]" <[email protected]>, Adrian Farrel >>> <[email protected]>, >>> IETF discussion list <[email protected]> >>> Subject: [mpls] [Gen-art] review: >>> draft-ietf-mpls-lsp-ping-relay-reply-04 >>> Message-ID: <[email protected]> >>> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> >>> ------------------------------ >>> >>> End of mpls Digest, Vol 126, Issue 10 >>> ************************************* >> >> _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
