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

Carlos, yes, and thanks for the review.

Regards
Lizhong

> -----Original Message-----
> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
> Sent: 2014年10月23日 22:29
> To: Lizhong Jin
> Cc: Joel Halpern Direct; mpls@ietf.org; gen-art@ietf.org; draft-ietf-mpls-lsp-
> ping-relay-reply.all; ietf@ietf.org
> Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04
> 
> Hi Lizhong,
> 
> Please also take into consideration the Ops Dir review of this doc, in which I
> have similar concerns as those from Joel.
> 
> There seem to be three major areas in discussion:
> 1. The scope of the problem being solved (i.e., which cases are solved, which
> are not, and which are the common cases) 2. The mechanism itself not
> working in many cases.
> 3. How this all works with IPv6 addresses (since your fix seems to cover the
> overlapping IPv4 private address case only)
> 
> Thanks,
> 
> Carlos.
> 
> > On Oct 22, 2014, at 10:05 AM, lizho.jin@gmail.com wrote:
> >
> > Joel, thank you for the review. We will send out a new version soon to
> reflect the discussion.
> >
> > Regards
> > Lizhong
> >
> >
> >
> >> 在 2014年10月22日，下午9:30，Joel Halpern Direct
> <jmh.direct@joelhalpern.com>
> >> wrote：
> >>
> >> It would be good to see a revision that clearly spelled out what the
> >> draft was solving, how the initial end-point knew what to create, and
> >> how the responder knew what to use.  It may well be that there is an
> >> effective solution to the problems here.  I look forward to seeing it
> >> in writing.
> >>
> >> Yours,
> >> Joel
> >>
> >>> On 10/22/14, 12:46 AM, Lizhong Jin wrote:
> >>> 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@joelhalpern.com]
> >>>> Sent: 2014年10月22日 11:14
> >>>> To: Lizhong Jin
> >>>> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org;
> >>> '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@joelhalpern.com]
> >>>>>> Sent: 2014年10月22日 10:15
> >>>>>> To: Lizhong Jin
> >>>>>> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org;
> >>>>> '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@joelhalpern.com]
> >>>>>>>> Sent: 2014年10月22日 0:06
> >>>>>>>> To: lizho.jin@gmail.com
> >>>>>>>> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org;
> >>>>>>> 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@gmail.com wrote:
> >>>>>>>>> Hi Joel, see inline below, thanks.
> >>>>>>>>>
> >>>>>>>>> Lizhong
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> 2014.10.21，PM9:30，Joel M. Halpern <jmh@joelhalpern.com>
> >>>> 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
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls