Hi Joel, The things may not be that bad. You could add a second address (address B in our example) with K bit set. The address entry with K bit set must be as a relay node, and could not be skipped. Section 4.4 should be changed to: Find the first routable address A, and the first address B with K bit set. If address A is before address B in the stack, then use address B as the relay address. Otherwise, use address A as the relay address. In that case, if A is the private address, the packet will be firstly relayed to address B. And address A and B belong to one router. Here I assume one router at least has one routable address for another AS. Regards Lizhong > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@xxxxxxxxxxxxxxx] > Sent: 2014年10月22日 11:14 > To: Lizhong Jin > Cc: gen-art@xxxxxxxx; mpls@xxxxxxxx; ietf@xxxxxxxx; 'draft-ietf-mpls-lsp-ping- > relay-reply.all' > Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 > > ou are saying that this is only for the case where an AS is using public > addresses for its internal numbering, but is not distributing that address block > externally? > > If so, you need to state that very clearly. > I believe a far more common case is one where the numbering is from a > portion of a publicly allocated space, but firewalled. Which would produce > the same problem, but would not be amenable to this solution. > And it is well known that many ISPs do internal number assignment from > private blocks. > > So what you are now saying is that this draft solves a very small portion of the > problem? But it works for that small portion? If so, at the very least you > need to be VERY clear about what cases this works for and what cases it does > not. And I fear that even if you are clear, it is going to be very confusing for > folks who are trying to use it. > > Yours, > Joel > > On 10/21/14, 10:51 PM, Lizhong Jin wrote: > > Hi Joel, > > I now see your concern. The "private" word in draft is not correct, I > > will remove it. The original motivation of "draft-relay-reply" is from > > the scenario where IP address distribution is restricted among AS or IGP > area. > > And the IP address is not private address. As I know, most deployed > > inter-AS or inter-area MPLS LSP is in the network without private IP address. > > > > Regards > > Lizhong > > > > > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@xxxxxxxxxxxxxxx] > >> Sent: 2014年10月22日 10:15 > >> To: Lizhong Jin > >> Cc: gen-art@xxxxxxxx; mpls@xxxxxxxx; ietf@xxxxxxxx; > > 'draft-ietf-mpls-lsp-ping- > >> relay-reply.all' > >> Subject: Re: [mpls] [Gen-art] review: > > draft-ietf-mpls-lsp-ping-relay-reply-04 > >> > >> The problem is that the original source A, that we are trying to > >> reach > > with a > >> reply, has an address that appears to the responder X to be routable. > >> But the destination that is reached by that address is either a black > >> hole or > > some > >> other entity using the same address. > >> > >> The reason for the duplication is that, as described in the draft, > >> the > > source > >> address for A is a private address. That same address may well be > > reachable > >> according to the routing table at X. But it won't get to A. > >> > >> If the problem is something other than private addressing preventing > >> reachability, it is likely there is still a mistaken routability > >> problem, > > but I can > >> not illustrate the failure without some other case being described. > >> > >> Yours, > >> Joel > >> > >> On 10/21/14, 10:06 PM, Lizhong Jin wrote: > >>> Inline, thanks. > >>> > >>>> -----Original Message----- > >>>> From: Joel M. Halpern [mailto:jmh@xxxxxxxxxxxxxxx] > >>>> Sent: 2014年10月22日 0:06 > >>>> To: lizho.jin@xxxxxxxxx > >>>> Cc: gen-art@xxxxxxxx; mpls@xxxxxxxx; ietf@xxxxxxxx; > >>> draft-ietf-mpls-lsp-ping- > >>>> relay-reply.all > >>>> Subject: Re: [mpls] [Gen-art] review: > >>> draft-ietf-mpls-lsp-ping-relay-reply-04 > >>>> > >>>> In line. > >>>> > >>>> On 10/21/14, 10:36 AM, lizho.jin@xxxxxxxxx wrote: > >>>>> Hi Joel, see inline below, thanks. > >>>>> > >>>>> Lizhong > >>>>> > >>>>> > >>>>>> 2014.10.21，PM9:30，Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> > 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. > >>>> > >>>> The whole point of this relay mechanism, as I understand it, is to > >>>> cope > >>> with > >>>> the case when the responder X can not actually reach the source A. > >>>> Now suppose that the packet arrives at X with the Address stack > >>>> A, B, > > ... > >>> X > >>>> examines the stack. The domain of A was numbered using net 10. > >>>> The domain of X is numbered using net 10. A's address is probably > >>> routable > >>>> in X's routing table. The problem is, that routing will not get to > >>>> A. X > >>> examines > >>>> the stack, determines that A is "routable", and sends the packet. > >>>> This > >>> fails to > >>>> meet the goal. > >>> [Lizhong] The source A you are referring is the initiator, right? > >>> The goal of relay mechanism is to reach the initiator. If X is > >>> routable to the initiator (address A), then it is great, other relay > >>> node in the stack will be skipped. > >>> If the source A you are referring is the interface address of one > >>> intermediate node, then I do not understand "routing will not get to > >>> A. X examines the stack, determines that A is "routable", and sends > >>> the > >> packet". > >>> Why routing will not get to A, but A is routable? > >>> > >>> Regards > >>> Lizhong > >>> > >>> > >>>> > >>>> Yours, > >>>> Joel > >>> > >>> > >>> > >