Re: [dhcwg] IETF76 dhcwg agenda UPDATE

zhengruobin 35664 <robin@huawei.com> Fri, 13 November 2009 00:50 UTC

Return-Path: <robin@huawei.com>
X-Original-To: dhcwg@core3.amsl.com
Delivered-To: dhcwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 496C53A6823 for <dhcwg@core3.amsl.com>; Thu, 12 Nov 2009 16:50:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.294
X-Spam-Level: **
X-Spam-Status: No, score=2.294 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, 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 p-h+cR21o8pX for <dhcwg@core3.amsl.com>; Thu, 12 Nov 2009 16:50:57 -0800 (PST)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 171353A67F0 for <dhcwg@ietf.org>; Thu, 12 Nov 2009 16:50:57 -0800 (PST)
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 <0KT000EE5VPFV0@szxga03-in.huawei.com> for dhcwg@ietf.org; Fri, 13 Nov 2009 08:51:16 +0800 (CST)
Received: from huawei.com ([172.17.1.31]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KT000BM9VPF9Z@szxga03-in.huawei.com> for dhcwg@ietf.org; Fri, 13 Nov 2009 08:51:15 +0800 (CST)
Received: from [172.24.1.6] (Forwarded-For: [133.93.19.44]) by szxmc03-in.huawei.com (mshttpd); Fri, 13 Nov 2009 08:51:15 +0800
Date: Fri, 13 Nov 2009 08:51:15 +0800
From: zhengruobin 35664 <robin@huawei.com>
In-reply-to: <C721C809.BD25A%john_brzozowski@cable.comcast.com>
To: John Jason Brzozowski <john_brzozowski@cable.comcast.com>
Message-id: <fb8c95641a03c.1a03cfb8c9564@huawei.com>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006)
Content-type: text/plain; charset="gb2312"
Content-language: zh-CN
Content-transfer-encoding: quoted-printable
Content-disposition: inline
X-Accept-Language: zh-CN
Priority: normal
References: <31D55C4D55BEED48A4459EB64567589A10041E4878@BLRKECMBX02.ad.infosys.com> <C721C809.BD25A%john_brzozowski@cable.comcast.com>
Cc: dhc WG <dhcwg@ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: [dhcwg] IETF76 dhcwg agenda UPDATE
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2009 00:50:58 -0000

Welome aboard! 

Regarding to the potential solution, what I can think is as follow.

1. To allow the "second" relay agent to modified the Circuit ID suboption of option82 in transit. But this will invalidate the signature added by the "first" relay agent.

2. To create a new sub-option for option 82. But again this will invalidate the signature added by the "first" relay agent.

3. To introduce a new option with multiple suboptions so that each relay agent can add its own relay agent information as one suboption. However, it's required to update the software of all devices where relay agent resides.

4. To allow adding the "second" option 82. It is simplest way. It will not invalidate the signature. There is no need to update the software of the first-level relay agent. Thus, protect the legacy device furthest.
 
5. To introduce a new option with the same format of Option 82. The "first" relay agent adds the Option 82 as usual. The "second" relay agent adds its relay agent information as a new option. If there is a "third" relay agent, it adds its relay agent information as a new option again. In this way,  it not only will not invalidate the signature but also will not need to update the software of the first-level relay agent.


As a vendor of access products, I would like to recommend the fourth one or the fifth one .


----- 原邮件 -----
发件人: John Jason Brzozowski <john_brzozowski@cable.comcast.com>
日期: 星期四, 十一月 12日, 2009 下午1:11
主题: Re: IETF76 dhcwg agenda UPDATE
收件人: Bharat Joshi <bharat_joshi@infosys.com>, Ruobin Zheng <robin@huawei.com>, Hui Deng <denghui02@gmail.com>
抄送: Ted Lemon <Ted.Lemon@nominum.com>, dhc WG <dhcwg@ietf.org>

> Bharat,
> 
> Our AD actually mentioned this to us and during the meeting we 
> felt that it
> might not be exactly related to the work you did.
> 
> However, since you have email about the time I would like to 
> suggest that
> the authors of the new work include you in their activities to see 
> if their
> is a collaborative opportunity here.
> 
> Does this work for you?
> 
> Sean, Hui,
> 
> Any comments?
> 
> John
> 
> 
> On 11/12/09 12:43 PM, "Bharat Joshi" <bharat_joshi@infosys.com> wrote:
> 
> > Hi All,
> > 
> >       Just noticed this. The following two drafts provide a 
> solution for
> > similar problem.
> > 
> >>           DHCP Relay Agent Stacking                  Robin 
> Zheng           10
> >> minutes
> >>                   <draft-zheng-dhc-relay-agent-stacking-00.txt>
> >>                   proposes to have more than one Relay Agents 
> adding DHCP
> >> Option 82
> >>          
> >>           Multiple Relay Agent Information Option    Hui Deng   
>           10
> >> minutes
> >>                   <draft-huang-dhc-multiple-relay-agents-option-00>
> >>                   proposes using a different option for 
> stacking relay agent
> >> information
> >>          
> > 
> >        Couple of years back, we have identified the similar 
> issue because of
> > the introduction of Layer 2 Relay Agent in the network and had 
> come out with a
> > draft based on the suggestions from working group. A new 
> revision of that
> > draft was published couple of months back. None of the author 
> could attend
> > this IETF meeting and so we could not present it.
> > 
> >        Our solution proposed to create a new sub-option for 
> option 82. A relay
> > agent receiving a packet with option 82, create its own option 
> 82, populate it
> > as it is configured and also create this new sub-option in its 
> own option 82
> > and populate it with the received option 82. This way server 
> will see only one
> > option 82 and can dig into sub-option recursively to find the 
> deepest option
> > 82. On return path, every relay agent will remove its own option 
> 82 and pass
> > it to the previous relay agent.
> > 
> >        For more detailed text, please refer to
> > http://tools.ietf.org/html/draft-kurapati-dhc-relay-chaining-
> dhcpv4-02
> > 
> >        Before we take a decision on a particular method to solve 
> this problem,
> > I would request everybody to review all the drafts and then take 
> an informed
> > decision.
> > 
> > Thanks,
> > Bharat
> > 
> > 
> 
> =========================================
> John Jason Brzozowski
> Comcast Cable
> e) mailto:john_brzozowski@cable.comcast.com
> o) 609-377-6594
> m) 484-962-0060
> =========================================
> 
>