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

[Joel Halpern Direct <[e-mail]>]

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
>>>>>
>>>>>
>>>>>
>>>
>