Re: [dhcwg] IETF76 dhcwg agenda UPDATE

>> 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.
>>  
>
>Actually we had proposed this in one of the IETF meeting where we
>have proposed this work but there was some resistant on repeating
>this option in DHCP message. I do not remember the cause of this
>resistance though. May be someone still remembers that discussion
>and can add to it.

The problem is RFC 3396. A 2nd instance of an option just means to concatenate the two instances into one.

- Bernie

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bharat Joshi
Sent: Friday, November 13, 2009 1:57 AM
To: zhengruobin 35664; John Jason Brzozowski
Cc: dhc WG; Ted Lemon
Subject: Re: [dhcwg] IETF76 dhcwg agenda UPDATE

Hi,

> Welome aboard! 
>

Thanks!

Sometime back, we had some discussion on this with Hui and Lu Huang.

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

I agree and I think we should not go down this path.

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

How? What exactly you mean by 'invalidate the signature added by first relay agent'?

I am not sure if you read through our proposed solution. We proposed something on this line but our solution preserve the option 82 added by all relay agents and one relay agent does not change the option 82 added by any of the previous relay agent.

If you want I can describe the complete functionality here but I would suggest you to go through the draft which will provide more clarity.

There were multiple reasons to choose this:

* As you mentioned below, we do not need to change the software in the first RA.
* This also does not invalidate the option 82 added by the first RA as you want in the solution. 
* Because we are putting in the complete option 82 in a sub-option of option 82, we do not need to add any new option.
* DHCP server does not need to learn parsing a new option because the new sub-option contains the option 82 and it already knows how to parse it. [This is from implementation perspective]

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

We wanted to avoid getting a new DHCPv4 option for this. There were two reasons, one is as you pointed out that all the device's software need upgradation and another is that there are very small number of new DHCPv4 options available now so we wanted to avoid it if we can.

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

Actually we had proposed this in one of the IETF meeting where we have proposed this work but there was some resistant on repeating this option in DHCP message. I do not remember the cause of this resistance though. May be someone still remembers that discussion and can add to it.

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

Ok. But this is not very different than what you mentioned in point 4. The only thing which we are taking care is that not repeating option 82 instead we will repeat option 'X'.

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

It would be great if you can send me your comments on the solution proposed by us in our draft.

Thanks,
Bharat

> 
> ----- 原邮件 -----
> 发件人: 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
> > 
> > 
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg