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(_at_)cisco(_dot_)com]
Sent: 2014年10月23日 22:29
To: Lizhong Jin
Cc: Joel Halpern Direct; mpls(_at_)ietf(_dot_)org; 
gen-art(_at_)ietf(_dot_)org; draft-ietf-mpls-lsp-
ping-relay-reply.all; ietf(_at_)ietf(_dot_)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(_dot_)jin(_at_)gmail(_dot_)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(_dot_)direct(_at_)joelhalpern(_dot_)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(_at_)joelhalpern(_dot_)com]
Sent: 2014年10月22日 11:14
To: Lizhong Jin
Cc: gen-art(_at_)ietf(_dot_)org; mpls(_at_)ietf(_dot_)org; 
ietf(_at_)ietf(_dot_)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(_at_)joelhalpern(_dot_)com]
Sent: 2014年10月22日 10:15
To: Lizhong Jin
Cc: gen-art(_at_)ietf(_dot_)org; mpls(_at_)ietf(_dot_)org; 
ietf(_at_)ietf(_dot_)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(_at_)joelhalpern(_dot_)com]
Sent: 2014年10月22日 0:06
To: lizho(_dot_)jin(_at_)gmail(_dot_)com
Cc: gen-art(_at_)ietf(_dot_)org; mpls(_at_)ietf(_dot_)org; 
ietf(_at_)ietf(_dot_)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(_dot_)jin(_at_)gmail(_dot_)com wrote:
Hi Joel, see inline below, thanks.

Lizhong

2014.10.21，PM9:30，Joel M. Halpern <jmh(_at_)joelhalpern(_dot_)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,

...

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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls