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

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 22 October 2014 02:15 UTC

Return-Path: <jmh@joelhalpern.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 DB3DA1A8A1A; Tue, 21 Oct 2014 19:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 Xr9hvZpWgZ4R; Tue, 21 Oct 2014 19:14:59 -0700 (PDT)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD5D1A8A0F; Tue, 21 Oct 2014 19:14:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id EA6301BC875A; Tue, 21 Oct 2014 19:14:58 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from Joels-MacBook-Pro.local (pool-70-106-134-195.clppva.east.verizon.net [70.106.134.195]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8CB9F1BC8767; Tue, 21 Oct 2014 19:14:56 -0700 (PDT)
Message-ID: <5447131F.5040709@joelhalpern.com>
Date: Tue, 21 Oct 2014 22:14:55 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Lizhong Jin <lizho.jin@gmail.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>
In-Reply-To: <00ff01cfed9c$caf88740$60e995c0$@gmail.com>
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/__MmNWerfv4IfVG1ujexqgvMPGI
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 02:15:01 -0000

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