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

From: "Lizhong Jin" <[email-masked]>
Date: Mon, 20 Oct 2014 14:35:48 +0800

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-masked]>
> To: "A. Jean Mahoney" <[email-masked]>, [email-masked],
> 	"[email-masked]" <[email-masked]>, Adrian Farrel
> <[email-masked]>,
> 	IETF discussion list <[email-masked]>
> Subject: [mpls] [Gen-art] review:
> 	draft-ietf-mpls-lsp-ping-relay-reply-04
> Message-ID: <[email-masked]>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> 
> 
> ------------------------------
> 
> End of mpls Digest, Vol 126, Issue 10
> *************************************

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Oct 2014 09:30:21 -0400

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.

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.

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.

Yours,
Joel

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 21 Oct 2014 22:36:07 +0800

Hi Joel, see inline below, thanks.

Lizhong

> 2014.10.21，PM9:30，Joel M. Halpern <[email-masked]> 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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Oct 2014 12:06:21 -0400

In line.

On 10/21/14, 10:36 AM, [email-masked] wrote:
>> 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.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Oct 2014 22:14:55 -0400

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:[email-masked]]
>> Sent: 2014年10月22日 0:06
>> To: [email-masked]
>> Cc: [email-masked]; [email-masked]; [email-masked];
> draft-ietf-mpls-lsp-ping-
>> relay-reply.all
>> Subject: Re: [mpls] [Gen-art] review:
>>> 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.
>>
> 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.
> 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
> 
> 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Oct 2014 23:14:05 -0400

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
> 
> 
>> Sent: 2014年10月22日 10:15
>> To: Lizhong Jin
> 'draft-ietf-mpls-lsp-ping-
>> relay-reply.all'
> 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.
>>
> 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.
>>
>> 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
>>
> ...
>>> [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.
>>> 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".

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 22 Oct 2014 09:30:52 -0400

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
> 
>> Sent: 2014年10月22日 11:14
>> addresses for its internal numbering, but is not distributing that address
> block
>> externally?
>>
> produce
>> the same problem, but would not be amenable to this solution.
>> 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
>>
>>> 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
>>>
>>>
>>>> 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
>>>> problem,
>>>>>>>> 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
>>>>>>> [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.
>>>>>>
>>>>> [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.

---

From: "Lizhong Jin" <[email-masked]>
Date: Wed, 22 Oct 2014 10:51:09 +0800

Hi Joel,

Regards
Lizhong

with a
some
source
reachable
but I can
...

---

From: "Lizhong Jin" <[email-masked]>
Date: Wed, 22 Oct 2014 12:46:58 +0800

Hi Joel,

Regards
Lizhong

block
produce
of the
you
does
confusing for
address.

---

From: "Lizhong Jin" <[email-masked]>
Date: Wed, 22 Oct 2014 10:06:15 +0800

Inline, thanks.

with
X
routable
examines
fails to

Regards
Lizhong

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 22 Oct 2014 22:05:16 +0800

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 <[email-masked]> wrote：
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 23 Oct 2014 14:29:12 +0000

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, [email-masked] wrote:
>

---

From: "Lizhong Jin" <[email-masked]>
Date: Fri, 24 Oct 2014 13:15:04 +0800

Carlos, yes, and thanks for the review.

Regards
Lizhong

> From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
> Sent: 2014年10月23日 22:29
> To: Lizhong Jin
> Cc: Joel Halpern Direct; [email-masked]; [email-masked]; draft-ietf-mpls-lsp-
> ping-relay-reply.all; [email-masked]
> 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.
> 
> 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.
> 
> >> 在 2014年10月22日，下午9:30，Joel Halpern Direct
> <[email-masked]>
> >> wrote：
> >>
> >> effective solution to the problems here.  I look forward to seeing it
> >> in writing.
> >>
> >> Yours,
> >> 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
> >>>
> >>>> 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?
> >>>>
> >>>> 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
> >>>> And it is well known that many ISPs do internal number assignment
> >>>> from private blocks.
> >>>>
> >>>> portion
> >>>>> 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
> >>>>>
> >>>>>
> >>>>>> But the destination that is reached by that address is either a
> >>>>>> black hole or
> >>>>> some
> >>>>>> If the problem is something other than private addressing
> >>>>>> preventing reachability, it is likely there is still a mistaken
> >>>>>> routability problem,
> >>>>> but I can
> >>>>>>>>>> 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.
> >>>>>>>>
> >>>>>>> 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".