RE: [dhcwg] BCMCS server option drafts

["Kuntal Chowdhury" <[e-mail]>]

I have a few questions on the possible use of DHCPv6 OPTION_VENDOR_CLASS and
OPTION_VENDOR_OPTS to request vendor specific info:

1. Since the enterprise number is included in OPTION_VENDOR_OPTS, will it
suffice to use only this option in the information request message from the
DHCP client? Is the use of OPTION_VENDOR_CLASS mandatory while vendor
specific options are requested?

2. Does the mere inclusion of OPTION_VENDOR_OPTS in the information request
message indicate to the DHCP server that the DHCP client is requesting for
some specific vendor specific options?

3. O-R-O has the format where each of requested option codes are listed in
it. However, in OPTION_VENDOR_OPTS the encapsulated vendor-specific options
field MUST be encoded as a sequence of code/length/value fields. What value
does the DHCP client use while requesting for a vendor specific option? 

These things are not clearly defined in RFC3315.

Regards,
Kuntal

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>On Behalf Of Ralph Droms
>Sent: Wednesday, October 27, 2004 2:29 PM
>To: [e-mail]
>Subject: RE: [dhcwg] BCMCS server option drafts
>
>
>
>What about the deployment issue? The 3GGP2 specification will 
>be ratified in November, with deployment following soon.  Some 
>service providers already have DHCP servers in place that must 
>be updated for any new options.  The options defined in the 
>current drafts can likely be supported without code changes to 
>existing servers, allowing for faster deployment.  Use of a 
>VIVSO sub-option would require code changes to existing 
>servers.  How long would it take to deploy DHCP server that 
>can support VIVSO?
>
>BTW, we need more discussion of this issue *soon* due to the 
>time constraints of the upcoming 3GPP2 standards process and 
>deployment.
>
>- Ralph
>
>At 04:12 PM 10/21/2004 -0400, Bernie Volz wrote:
>>Personally, I'd like to see the DHCPv4 VIVSO get deployed and pushing 
>>these options to using it would be a step at making this 
>happen (as one 
>>would expect 3GPP2 vendors to have some significant input to the 
>>decisions of DHCP server vendors).
>>
>>It also means that 3GPP2 is free to define other VIVSO options in the 
>>future within their own forum and need not go to the IETF 
>(and DHC WG). 
>>I suspect that this would provide much faster deployment for them in 
>>the future.
>>
>>Also, the DHCPv6 OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS 
>are already 
>>there for DHCPv6.
>>
>>BTW, 3GPP2 already has an enterprise-id number:
>>
>>5535
>>   3rd Generation Partnership Project 2 (3GPP2)
>>     Allen Long
>>       [e-mail]
>>
>>So, they'd be good to go!
>>
>>- Bernie
>>
>> > -----Original Message-----
>> > From: [e-mail] [mailto:[e-mail]] On 
>> > Behalf Of Ralph Droms
>> > Sent: Thursday, October 21, 2004 2:35 PM
>> > To: [e-mail]
>> > Subject: [dhcwg] BCMCS server option drafts
>> >
>> >
>> > We need to have a short WG conversation about two options 
>that were 
>> > discussed at the WG meeting in San Diego.  The outcome of the 
>> > conversation will be to determine consensus about taking on these 
>> > two
>> > drafts:
>> >
>> > draft-chowdhury-dhc-bcmcv4-option-01.txt
>> > draft-chowdhury-dhc-bcmcv6-option-01.txt
>> >
>> > as dhc WG work items or recommending that 3GPP2 define 
>> > vendor-identifying vendor-specific option (VIVSO; option code
>> > 125) sub-options to carry the information described in the drafts.
>> >
>> > If the WG consensus is to take on the drafts as WG work items 
>> > drafts, are they acceptable as currently published?
>> >
>> > Because of the time constraints imposed by the 3GPP2 schedule, I'm 
>> > going to cut off discussion on this topic next Thursday, 
>10/28, and 
>> > determine WG consensus at that time.
>> >
>> > Here are some considerations for discussion:
>> >
>> > 3GPP2 has defined some vendor-specific sub-options, for 
>example, to 
>> > identify a MIP home agent for the DHCP client.
>> >
>> > A 3GPP2 client needs to specify to the DHCP server which 
>parameters 
>> > it needs - specifically, whether it needs to receive the BCMCS 
>> > servers. If the current drafts are adopted, the client can simply 
>> > use the parameter request list option (option code 55) for the 
>> > request.  If a VIVSO sub-option is used, 3GPP2 would also define a 
>> > parameter request list sub-option.
>> >
>> > There is a deployment issue, as some service providers 
>already have 
>> > DHCP servers in place that must be updated for any new 
>options.  Is 
>> > it the case that the options defined in the current drafts can be 
>> > supported without code changes to existing servers?  Use 
>of a VIVSO 
>> > sub-option would require code changes to existing servers. 
> How long 
>> > would it take to deploy DHCP server that can support VIVSO.
>> >
>> > BCMCS may be adopted across multiple technologies, so the 
>options in 
>> > the current drafts would not be specific to 3GPP2.  However, the 
>> > BCMCS specification has not adopted by other standards, yet, so we 
>> > may need to define additional options for related services in the 
>> > future if those services are not interoperable with the 
>3GPP2 BCMCS 
>> > service.
>> >
>> > CableLabs has one option with sub-options (RFC 3495) rather than 
>> > multiple options because:
>> > * wanted to avoid exhaustion of DHCP option code space; 
>perhaps less
>> >    of an issue with option code reclassification
>> > * would have used VIVSO if available
>> > * use of VIVSO with sub-options would give 3GPP2 freedom 
>to define new
>> >    sub-options on demand
>> > Do these considerations have an impact on our decision 
>about how to 
>> > proceed with the 3GPP2 options?
>> >
>> > - Ralph
>> >
>> >
>> > _______________________________________________
>> > dhcwg mailing list
>> > [e-mail]
>> > https://www1.ietf.org/mailman/listinfo/dhcwg
>> >
>
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/dhcwg
>
>

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg