IETF Logo Mail Archive

Re: [grobj] Referral definition and its purpose?

Sheng Jiang <shengjiang@huawei.com> Thu, 27 May 2010 14:57 UTC

Return-Path: <shengjiang@huawei.com>
X-Original-To: grobj@core3.amsl.com
Delivered-To: grobj@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0416F3A6917 for <grobj@core3.amsl.com>; Thu, 27 May 2010 07:57:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.166
X-Spam-Level:
X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6VP0QWZP27P for <grobj@core3.amsl.com>; Thu, 27 May 2010 07:57:11 -0700 (PDT)
Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 562A73A6905 for <grobj@ietf.org>; Thu, 27 May 2010 07:57:11 -0700 (PDT)
Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3300JBT2V2IN@usaga03-in.huawei.com> for grobj@ietf.org; Thu, 27 May 2010 09:57:02 -0500 (CDT)
Received: from [192.168.171.227] ([207.219.128.130]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L33006V62V1D3@usaga03-in.huawei.com> for grobj@ietf.org; Thu, 27 May 2010 09:57:02 -0500 (CDT)
Date: Thu, 27 May 2010 22:56:27 +0800
From: Sheng Jiang <shengjiang@huawei.com>
In-reply-to: <20100527130230.GA4935@cisco.com>
To: Scott Brim <swb@employees.org>
Message-id: <4BFE881B.80000@huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset="UTF-8"; format="flowed"
Content-transfer-encoding: 8bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
References: <004d01caf668$b33272e0$730c6f0a@china.huawei.com> <115701cafd32$7cefc180$c4f0200a@cisco.com> <4BFDF394.6050102@network-heretics.com> <124e01cafd55$7f1aa2e0$c4f0200a@cisco.com> <20100527130230.GA4935@cisco.com>
Cc: grobj@ietf.org
Subject: Re: [grobj] Referral definition and its purpose?
X-BeenThere: grobj@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss Generic Referral Objects <grobj.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/grobj>, <mailto:grobj-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/grobj>
List-Post: <mailto:grobj@ietf.org>
List-Help: <mailto:grobj-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grobj>, <mailto:grobj-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 14:57:12 -0000

于 2010/5/27 21:02, Scott Brim 写道:
> Excerpts from Dan Wing on Wed, May 26, 2010 09:31:33PM -0700:
>> But my point is that it is a *different* path than the
>> signaling path.   I agree the path could be longer and
>> could go around the moon - twice.
>
> I've been trying to figure out why.  At the IP layer it does not
> necessarily _have_ to be a different path.
>
> The term from transport is "path-decoupled signaling".  It's not that
> the control packets take a different path, but that they _might_ and
> that you don't know if they do or not.  I think it's wrong to assert
> that it is a different path.
>
> Keith is right that it could be the same path but the referring entity
> doesn't know whether it will end up the same or not.

+1. The referral information received though an existing path may 
indicate the communication pair this is the best path out of many. Then 
it ends up remaining the same path. It is possible and reasonable.

Sheng

v2.23.0 | Report a Bug | By Email