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

["[e-mail]" <[e-mail]>]

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 <[e-mail]> 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:[e-mail]]
>>> Sent: 2014年10月22日 11:14
>>> To: Lizhong Jin
>>> Cc: [e-mail]; [e-mail]; [e-mail];
>> '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:[e-mail]]
>>>>> Sent: 2014年10月22日 10:15
>>>>> To: Lizhong Jin
>>>>> Cc: [e-mail]; [e-mail]; [e-mail];
>>>> '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:[e-mail]]
>>>>>>> Sent: 2014年10月22日 0:06
>>>>>>> To: [e-mail]
>>>>>>> Cc: [e-mail]; [e-mail]; [e-mail];
>>>>>> 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, [e-mail] wrote:
>>>>>>>> Hi Joel, see inline below, thanks.
>>>>>>>> 
>>>>>>>> Lizhong
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 2014.10.21，PM9:30，Joel M. Halpern <[e-mail]>
>>> 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
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>