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

"Lizhong Jin" <lizho.jin@gmail.com> Wed, 22 October 2014 04:47 UTC

Return-Path: <lizho.jin@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624E41A8A97; Tue, 21 Oct 2014 21:47:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUYKgfbTebZ7; Tue, 21 Oct 2014 21:47:06 -0700 (PDT)
Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B4AE1A8A8D; Tue, 21 Oct 2014 21:47:06 -0700 (PDT)
Received: by mail-pd0-f177.google.com with SMTP id g10so716367pdj.36 for <multiple recipients>; Tue, 21 Oct 2014 21:47:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=9Zx+yjs/nDlkwihYa3VOk2YbqZswE85Jm6BdA2uPzTA=; b=zFGeo6+XMkynjQT2pVAKPvdKAG1Uq0pZfbwL5BIttkq9oOGHszUKI97XmFT2fGODi5 RD5I3LJ/dWtCSY6advjsDixOXUsSJwf31gBRpuu61TOB1maN5lX1JTrPqHwlYlHeWkqw P3QHmQy6Nw/nDgIMKVja19QgfL0GOLbqc2Nn89Qd/FIhOSbeLB0Pp1pDaXWk6ptWmLBC DUTWNhpGdlVw3stKdIZTuIigw3COFWh5UBMJ5tKxgCYGc6QdBGpuY1vkyd9uqfnXFJ5Q q0SIaimSsTHbsVS33TV/fPSv9Z0FOX91QpoQyZgHomKRbqu8aTlyvUozH/JEizngWJXj bO/w==
X-Received: by 10.70.89.48 with SMTP id bl16mr39711175pdb.29.1413953225856; Tue, 21 Oct 2014 21:47:05 -0700 (PDT)
Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id hp4sm13143855pbb.95.2014.10.21.21.47.03 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Oct 2014 21:47:05 -0700 (PDT)
From: Lizhong Jin <lizho.jin@gmail.com>
To: "'Joel M. Halpern'" <jmh@joelhalpern.com>
References: <012001cfec30$18d91920$4a8b4b60$@gmail.com> <54465FED.6030005@joelhalpern.com> <B16F6336-3E7B-41E1-AB92-A7A7D818594A@gmail.com> <5446847D.4030500@joelhalpern.com> <00ff01cfed9c$caf88740$60e995c0$@gmail.com> <5447131F.5040709@joelhalpern.com> <010101cfeda3$0cfaf820$26f0e860$@gmail.com> <544720FD.5030703@joelhalpern.com>
In-Reply-To: <544720FD.5030703@joelhalpern.com>
Date: Wed, 22 Oct 2014 12:46:58 +0800
Message-ID: <010901cfedb3$3a47b2e0$aed718a0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIoLsexpoDjeNgEXN4xVax6BLciqgI4g/XAAhLnkzMCHjdnVwJETDgiAMwAguMCSbWPXwLVKPYomxY9O3A=
Content-Language: zh-cn
Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1ypzGJWQnpD4n4TKqM82GzADAHo
Cc: mpls@ietf.org, gen-art@ietf.org, "'draft-ietf-mpls-lsp-ping-relay-reply.all'" <draft-ietf-mpls-lsp-ping-relay-reply.all@tools.ietf.org>, ietf@ietf.org
Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Oct 2014 04:47:08 -0000

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@joelhalpern.com]
> Sent: 2014年10月22日 11:14
> To: Lizhong Jin
> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.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@joelhalpern.com]
> >> Sent: 2014年10月22日 10:15
> >> To: Lizhong Jin
> >> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.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@joelhalpern.com]
> >>>> Sent: 2014年10月22日 0:06
> >>>> To: lizho.jin@gmail.com
> >>>> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.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.jin@gmail.com wrote:
> >>>>> Hi Joel, see inline below, thanks.
> >>>>>
> >>>>> Lizhong
> >>>>>
> >>>>>
> >>>>>> 2014.10.21,PM9:30,Joel M. Halpern <jmh@joelhalpern.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,
> > ...
> >>> 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
> >>>
> >>>
> >>>
> >