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: "Lizhong Jin" <[email-masked]>
Date: Wed, 22 Oct 2014 10:06:15 +0800

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

---

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

---

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

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

---

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

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

---

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

---

From: "Lizhong Jin" <[email-masked]>
Date: Fri, 31 Oct 2014 23:37:30 +0800

Hi Joel,
cc to mpls list as AD requested.
In your example, only when B, C, D, E with K bit set, then will relay to E, to D, to C, then to B.
This is the intention of K bit which is inherited from draft-ietf-mpls-interas-lspping (a merged draft), and when K bit is set, the address will be a relay node. 
In the draft, it says in section 3.2
"The address with K bit set will
always be a relay node address for the Relayed Echo Reply"

But the next relay address selection mechanism does need to be updated, which has led to misunderstanding.

Regards
Lizhong Jin
 
From: Joel M. Halpern
Date: 2014-10-31 21:54
To: Lizhong Jin; 'Carlos Pignataro (cpignata)'; 'draft-ietf-mpls-lsp-ping-relay-reply'
CC: 'adrian'; 'loa'; 'Jari Arkko'
Subject: Re: update of draft-ietf-mpls-lsp-ping-relay-reply-04
That is indeed a different algorithm, and does not depend upon whether
the K bit is set on the origin.
 
It does have an important result that is VERY different from your
earlier algorithm.  It is an acceptable result to me, but you should
make sure it is your intention.  The reply will now go back to the
closest reliable reverse, rather than the furthest.  So if the LSP goes
through ASBRs B, C, D, and E, the earlier algorithm would send a reply
from F to B to be relayed to the originator.  The new algorithm will
send a reply to E, to be relayed to D, thence to C, thence to B, and
thence to the originator.  This is far more robust.  But it is a
dramatic change in behavior.  I think that such a change really needs
working group review and approval.
 
Yours,
Joel
 
On 10/30/14, 11:13 PM, Lizhong Jin wrote:
> Hi Joel,
> It is not necessary to require to unset K bit for the originator. It is
> required for the border node to add address entry with K bit set, then the
> Echo Reply could be relayed back.
> Back to the example in section 5, if P1 add non-routable address entry with
> K bit set, it is OK. ASBR1 will add IP1 with K bit unset, and IP2 with K bit
> set in the stack. Then P2/ASBR2 will first send Echo Reply to ASBR1, then
> ASBR1 send Echo Reply to P1. Even if the non-routable P1 address is also
> routable in AS2, the node in AS2 will still select ASBR1 as the next relay
> node.
> 
> I read section 4.3 again, and not correctly use word "first", and lead your
> misunderstanding:
> OLD:
> To find out the next relay node address, the node SHOULD check the
>     address items in Relay Node Address Stack TLV in sequence from top to
>     down, and find the first IP routable address, e.g., A, and the first
>     address with K bit set, e.g., B.
> NEW:
> To find out the next relay node address, the node SHOULD check the
>     address items in Relay Node Address Stack TLV in sequence from top to
>     down, and find the first IP routable address, e.g., A, and the last
>     address with K bit set, e.g., B.
> 
> Regards
> Lizhong
> 
>> From: Joel Halpern Direct [mailto:[email-masked]]
>> Sent: 2014年10月31日 0:10
>> To: Lizhong Jin; Carlos Pignataro (cpignata);
> draft-ietf-mpls-lsp-ping-relay-
>> reply
>> Cc: adrian; loa; Jari Arkko
>> Subject: Re: update of draft-ietf-mpls-lsp-ping-relay-reply-04
>>
>> Not quite:
>>
>> 1) You still have not fixed 4.2.  So if the originator puts on its address
> with the
>> K bit unset, the entry will be removed.  But in order to make the rest of
> your
>> logic work, the originator whose address is not reachable needs to put on
> the
>> entry with the k bit unset.
>>
>> 2) The case I wanted added in section 5 was when P1, the request
> originator,
>> has a non-routable address.  Then when it originates the request, it has
> to
>> provide a stack with its own address with the K bit unset.  Otherwise the
> rest
>> of the logic won't work.
>>
>> Yours,
>> Joel
>>
>> On 10/30/14, 11:31 AM, Lizhong Jin wrote:
>>> Hi Joel,
>>> Thanks for the comments, I made the following changing. Please check
>>> if they are confortable for you.
>>>
>>> In Section 3.2:
>>> Delete: How a node determines to set the K bit is outside the scope of
>>> this document.
>>> Add: One application scenario of K bit is given out in section 5.
>>>
>>> In Section 4.3:
>>> Add: If there is no B existed, then use A as the next relay node
> address.
>>>
>>> In section 5:
>>> Add: In the case that the interface address of ASBR1 to P1 is IP1
>>> which maybe an IPv4 private address and not IP routable for AS2, and
>>> the loopback address on ASRB1 is IP2 which is routable for AS2. Then
>>> when ASBR1 sends a Relayed Echo Reply, it will firstly add IP1 without
>>> K bit set in the Relay Node Address Stack TLV, and then add
>>> IP2 with K bit set in the stack TLV. Then ASBR2/P2 could relay the
>>> Relayed Echo Reply back first to IP2 which is routable for ASBR2/P2,
>>> then ASBR1 will send Echo Reply to PE1. Thanks for the K bit, the
>>> ASBR1 will not be skipped for message relay.
>>>
>>> --
>>> Lizhong Jin
>>>      *From:* Joel M. Halpern <mailto:[email-masked]>
>>>      *Date:* 2014-10-30 11:15
>>>      *To:* Lizhong Jin <mailto:[email-masked]>; 'Carlos Pignataro
>>>      (cpignata)' <mailto:[email-masked]>;
>>>      'draft-ietf-mpls-lsp-ping-relay-reply'
>>>      <mailto:[email-masked]>
>>>      *CC:* 'adrian' <mailto:[email-masked]>; 'loa'
>>>      <mailto:[email-masked]>; Jari Arkko <mailto:[email-masked]>
>>>      *Subject:* Re: update of draft-ietf-mpls-lsp-ping-relay-reply-04
>>>      As I tried to say in my previous reply, your solution to sources who
> are
>>>      not reachable, but for which the routing table may claim
> reachability
>>>      (due to private address duplication or firewalling of sub-blocks
> within
>>>      an advertised region, or...) seems to depend both upon such sources
> not
>>>      setting the k bit in their (first) entry, and on such entries
> surviving
>>>      the intermediate processing.
>>>      Given that this is central to the purpose of the draft, the bit
> setting
>>>      really needs to be described.  And given that this preservation
>>>      contradicts current text, it must be spelled out.
>>>      Yours,
>>>      Joel
>>>      On 10/29/14, 10:28 PM, Lizhong Jin wrote:
>>>       > Hi Joel,
>>>       > Thank you for the prompt reply.
>>>       >
>>>       > The scenario you raised could be solved by setting K bit for a
>>>      routable
>>>       > address. Let me give you the detail.
>>>       > PE1----P1----ASBR1-----ASBR2-----P2-----PE2
>>>       > The initiator is PE1, and the interface address of ASBR1 to P1 is
>>>      Addr1
>>>       > which maybe a private address, and the routable address on ASRB1
>>>      is Addr2.
>>>       > Then when ASBR1 send a relayed echo reply, it will firstly add
>>>      Addr1 in the
>>>       > stack, and then add Addr2 with K bit set in the stack.
>>>       > Then P2 could relay the echo reply back first to Addr2, then
>>>      Addr1 by ASBR1.
>>>       >
>>>       > I consider above as an application case of K bit, so I did not
>>>      give out the
>>>       > detail. But I could add some text about above example in section
>>>      5 if you
>>>       > insist.
>>>       > In the document, it says:
>>>       > Some nodes could be configured to always set the K bit,
>>>       >     or the module handling MPLS echo requests could discover its
>>>      K bit
>>>       >     use through topology awareness.  How a node determines to set
>>>      the K
>>>       >     bit is outside the scope of this document.
>>>       >
>>>       > But I forget to add the sentence in section 4.2 which I promise
>>>      to Carlos to
>>>       > add:
>>>       > A second or more address entries could also be added if
>>>      necessary, which
>>>       >> Sent: 2014年10月30日 0:24
>>>       >> To: Lizhong Jin; Carlos Pignataro (cpignata);
>>>       > draft-ietf-mpls-lsp-ping-relay-
>>>       >> reply
>>>       >> Cc: adrian; loa
>>>       >> Subject: Re: update of draft-ietf-mpls-lsp-ping-relay-reply-04
>>>       >>
>>>       >> This revision does not seem to address my comments from October
>>>      24.  The
>>>       >> assumption that sources will set K in certain ways is still
>>>      implici rather
>>>       > than
>>>       >> explicit, as far as I can tell.
>>>       >>
>>>       >> More importantly, if sources do not set the K bit on their own
> stack
>>>       > entry, so
>>>       >> as to enable the improved relay selection logic to work, then
>>>      the soure
>>>       > entry
>>>       >> will be removed by the logic in 4.2.
>>>       >>
>>>       >> Yours,
>>>       >> Joel
>>>       >>
>>>       >> PS: Here is the body of what I wrote on the 24th:
>>>       >>
>>>       >> We are getting close.
>>>       >> I believe that the intent is that if a node has reason to
>>>      believe that its
>>>       > address
>>>       >> will be NATed or firewalled at the domain edge, then it should
>>>      put in its
>>>       >> address, but not set the K bit.
>>>       >> If the originator does this, then other folks within his domain
> will
>>>       > respond
>>>       >> directly, while anyone past the domain edge will relay to the
>>>      border node,
>>>       >> who will set the K bit.
>>>       >>
>>>       >> If that is the intent, then there are two things that are
> needed:
>>>       >> 1) We need to actually say that, and not leave the implementor
>>>      guessing.
>>>       >> 2) In section 4.2 it needs to be noted that the originator
>>>      address must
>>>       > not be
>>>       >> removed even if the K bit is not set on that address.
>>>       >>
>>>       >> On 10/29/14, 11:17 AM, Lizhong Jin wrote:
>>>       >>> Hi, all,
>>>       >>> The cut-off time of draft submission has been passed. I will
> upload
>>>       >>> the new version once it is reopened.
>>>       >>> Please check if the new version is OK for you all. Thank you.
>>>       >>>
>>>       >>>
>>>
>>>       >>> --
>>>       >>> Lizhong Jin
>>>       >>>      *发件人：* Lizhong Jin <mailto:[email-masked]>
>>>       >>>      *发送时间：* 2014-10-25 00:03
>>>       >>>      *收件人：* jmh <mailto:[email-masked]>; loa
>>>       >> <mailto:[email-masked]>;
>>>       >>>      Carlos Pignataro (cpignata) <mailto:[email-masked]>
>>>       >>>      *抄送：* draft-ietf-mpls-lsp-ping-relay-reply
>>>       >>>
> <mailto:[email-masked]>
>>>       >>>      *主题：* update of draft-ietf-mpls-lsp-ping-relay-reply-04
>>>       >>>      Hi Joel, Carlos
>>>       >>>      The new version attached is sending to you for
>>>      confirmation, before
>>>       >>>      publishing. Thank you again for your comments.
>>>       >>>
>>>       >>>
>>>       >
>>>
> ------------------------------------------------------------------------
>>>       >>>      Regards
>>>       >>>      Lizhong Jin
>>>       >>>
>>>       >>>          *发件人：* Joel M. Halpern
> <mailto:[email-masked]>
>>>       >>>          *发送时间：* 2014-10-23 22:25
>>>       >>>          *收件人：* Loa Andersson <mailto:[email-masked]>;
>>>      [email-masked]
>>>       >>>          <mailto:[email-masked]>
>>>       >>>          *主题：* Re: [mpls] [Gen-art] review:
>>>       >>>          It has converged to the degree that Lizhong believes
>>>      he can make
>>>       > the
>>>       >>>          changes needed to address my concerns.  I believe he
>>>      understands
>>>       > the
>>>       >>>          concerns.  I do not understand some of the important
>>>      aspects of
>>>       > his
>>>       >>>          proposal, but look forward to seeing the draft.
>>>       >>>          Yours,
>>>       >>>          Joel
>>>       >>>          On 10/23/14, 10:17 AM, Loa Andersson wrote:
>>>       >>>           > Lizhong and Joel,
>>>       >>>           >
>>>       >>>           > Should I interpret this as that the discussion has
>>>      converged
>>>       > on a
>>>       >>>           > solution that you both are comfortable with?
>>>       >>>           >
>>>       >>>           > /Loa
>>>       >>>           >
>>>       >>>           > On 2014-10-22 16:05, [email-masked] wrote:
>>>       >>>           >> Joel, thank you for the review. We will send out a
> new
>>>       >>>          version soon to reflect the discussion.
>>>       >>>           >>
>>>       >>>           >> Regards
>>>       >>>           >> Lizhong
>>>       >>>           >>
>>>       >>>           >>
>>>       >>>           >>
>>>       >>>          <[email-masked]> 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
>>>       >>>           >>>
>>>       >>>           >>>> 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
>>>       >>>           >>>> 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
>>>       >>>           >>>>> 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
>>>       >>>           >>>>>> I now see your concern. The "private" word in
>>>      draft is
>>>       >>>          not correct, I
>>>       >>>           >>>>>> 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
>>>       >>>           >>>>>>
>>>       >>>           >>>>>>
>>>       >>>           >>>>>>> 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
>>>       >>>           >>>>>>> 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
>>>       >>>           >>>>>>>
>>>       >>>           >>>>>>>>>>> 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
>>>      node will
>>>       >>>          not use address
>>>       >>>           >>>>>>>>>> A since it's not routable, then it will
>>>      use address
>>>       >>>          B. So it will
>>>       >>>           >>>>>>>>> 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
>>>       >>>           >>>>>>>> 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".