Re: [grobj] Referral definition and its purpose?

Sheng Jiang <shengjiang@huawei.com> Fri, 21 May 2010 00:56 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 89B153A6A02 for <grobj@core3.amsl.com>; Thu, 20 May 2010 17:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.311
X-Spam-Level: *
X-Spam-Status: No, score=1.311 tagged_above=-999 required=5 tests=[AWL=-0.794, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 02X3LsyFuFom for <grobj@core3.amsl.com>; Thu, 20 May 2010 17:56:23 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 33EB83A6A24 for <grobj@ietf.org>; Thu, 20 May 2010 17:56:14 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2Q00GT3VX90C@szxga03-in.huawei.com> for grobj@ietf.org; Fri, 21 May 2010 08:55:57 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2Q00264VX99T@szxga03-in.huawei.com> for grobj@ietf.org; Fri, 21 May 2010 08:55:57 +0800 (CST)
Received: from j66104a ([10.111.12.115]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L2Q00IK7VX8LR@szxml06-in.huawei.com> for grobj@ietf.org; Fri, 21 May 2010 08:55:57 +0800 (CST)
Date: Fri, 21 May 2010 08:55:56 +0800
From: Sheng Jiang <shengjiang@huawei.com>
In-reply-to: <4BF4E37C.4010807@gmail.com>
To: 'Brian E Carpenter' <brian.e.carpenter@gmail.com>
Message-id: <001901caf880$5f579c80$730c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: Acr37WsfG2wju4tgQKi3fR8wfXWovQAkJiaw
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: Fri, 21 May 2010 00:56:24 -0000

Yes, we are too early to make decisions or recommendations. That's why we start the discussion from
very basic conception and try to reach common understanding on the basic issues

Currently, the charter is only a start point. We start from PS and requirement discussion. Whether
we set milestones for followups will depend on BoF participants and AD's instruction. What we can
do now is to discuss the scenarios and issues, then try to make a PS as mature as we can.

Cheers,

Sheng

> Two or three general comments on this discussion:
> 
> 1. I think it's too soon to discuss which layer the referral 
> takes place at. In fact, in the general case, we don't know - 
> what we do know is that a network layer referral *will* fail 
> in many cases. If that wasn't true, we would just be able to 
> pass IP addresses around, like we did in 1990. So the problem 
> statement needs to talk about layer (in)dependence as part of 
> the problem. A related issue is the problem of fragmented 
> scope, which is an acute problem at the network layer.
> 
> 2. It's also too soon to discuss whether the solution 
> direction is a referral object, as I originally suggested, or 
> a generalised equivalent of ICE, which Simon suggested.
> That's the main reason we need to start with a problem 
> definition IMHO.
> 
> 3. As for whether the charter should immediately include 
> specifying a solution as well as the problem and 
> requirements, this really depends on how well the next BOF 
> works out and how the prospective AD wants to handle it. I 
> think we should keep an open mind on that for now.
> 
>     Brian
> 
> 
> On 2010-05-19 22:17, Sheng Jiang wrote:
> >>> Fully agree. The approach we are discussing is application
> >> independent. 
> >>> So, natually, the solution we may produce will have the 
> ability to 
> >>> traverse application boundaries. My ideal model is the
> >> referral will happen in transport layer to serve all applications.
> >>
> >> Why not in IP layer? I mean using the extension header, such as 
> >> destination options header.
> > 
> > As the same answer in another thread, many referral information is 
> > from IP layer, such as IP addresses, hostnames, etc. The referral 
> > information may carried as IP payload. So, it is beyond the 
> IP layer.
> > 
> > Cheers,
> > 
> > Sheng
> >  
> >> Thanks.
> >> ------------------				 
> >> Dong Zhang
> >> 2010-05-19
> >>
> > 
> > _______________________________________________
> > grobj mailing list
> > grobj@ietf.org
> > https://www.ietf.org/mailman/listinfo/grobj
> >