RE: [dhcwg] BCMCS server option drafts

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

Hello Bernie,

Thanks for the details. Although what you suggest would need more code
changes on the DHCP server, I think it would work. I will take this proposal
back to 3GPP2 and have this discussed there.

Regards,
Kuntal

>-----Original Message-----
>From: Bernie Volz [mailto:[e-mail]] 
>Sent: Friday, October 29, 2004 2:40 PM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; 'Ralph Droms'
>Cc: [e-mail]
>Subject: RE: [dhcwg] BCMCS server option drafts
>
>
>I suspect Ralph meant that you're free to do whatever you want 
>within the bounds of the standard. This means you need to 
>define 3GPP2 vendor specific option codes, lengths, and contents.
>
>So, you might define the following 3GPP2 vendor-specific 
>information options that would be carried in the DHCPv6 
>OPTION_VENDOR_OPTS when the enterprise ID is the 3GPP2 one:
>
>1. 3GPP2_OPTION_ORO (=1). Same format as the ORO option, but 
>carries the 3GPP2 option numbers, not DHCPv6 ones.
>
>2. 3GPP2_OPTION_BCMCS_SERVER_D (=2) (same format as in
>draft-chowdhury-dhc-bcmcv6-option-01.txt)
>
>3. 3GPP2_OPTION_BCMCS_SERVER_A (=3) (same format as in
>draft-chowdhury-dhc-bcmcv6-option-01.txt)
>
>You can then have text that says "A server SHOULD return the 
>3GPP2 Vendor-Specific Options requested in the 
>3GPP2_OPTION_ORO option in a OPTION_VENDOR_OPTS with the 3GPP2 
>enterprise ID."
>
>A client would then send:
>	OPTION_VENDOR_OPTS, length=xx, data=<3ggp2 enterprise 
>ID>, <3GPP2_OPTION_ORO>, <length=4>,
>                <3GPP2_OPTION_BCMCS_SERVER_D
>code>,<3GPP2_OPTION_BCMCS_SERVER_A code>
>
>The server would then respond with:
>	OPTION_VENDOR_OPTS, length=xx, data<3gpp2 enterprise ID>, 
>		<3GPP2_OPTION_BCMCS_SERVER_D>, <length=xx>, <data>
>		<3GPP2_OPTION_BCMCS_SERVER_A>, <length=xx>, <data>
>
>- Bernie
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> On Behalf Of Kuntal Chowdhury
>> Sent: Friday, October 29, 2004 2:44 PM
>> To: Ralph Droms
>> Cc: [e-mail]; Bernie Volz
>> Subject: RE: [dhcwg] BCMCS server option drafts
>> 
>> 
>> Hello Ralph,
>> 
>> >The 3GPP2 standards bodies are free to define any syntax or 
>semantics 
>> >for the 3GPP2 OPTION_VENDOR_OPTS.  So, if 3GPP2 coule 
>require that a 
>> >client sends a 3GPP2 OPTION_VENDOR_OPTS request, which the server 
>> >parses and responds with 3GPP2 OPTION_VENDOR_OPTS containing 
>> >information for the client.
>> 
>> If I understand what your are saying, the semantics to
>> request/respond vendor specific information should also be 
>> vendor specific. I guess this is well understood to the DHCP 
>> implementers. It was not clear to me when I read RFC 3115.
>> 
>> The syntax of OPTION_VENDOR_OPTS is defined in 3315:
>> 
>> "
>>    The encapsulated vendor-specific options field MUST be 
>encoded as a
>>    sequence of code/length/value fields of identical format
>> to the DHCP
>>    options field.  The option codes are defined by the vendor 
>> identified
>>    in the enterprise-number field and are not managed by 
>> IANA.  Each of
>>    the encapsulated options is formatted as follows:
>> 
>>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 
>7 8 9 0 1
>>       
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       |          opt-code             |             
>> option-len        |
>>       
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       .                                                       
>>         .
>>       .                          option-data                  
>>         .
>>       .                                                       
>>         .
>>       
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> "
>> 
>> So, I don't understand your statement "3GPP2 is free to
>> define the syntax of OPTION_VENDOR_OPTS".  The syntax of 
>> OPTION_VENDOR_OPTS when it appears in a request message from 
>> the client is not clear. 
>> 
>> The suggested behavior of a 3GPP2 DHCP server sending all
>> 3GPP2 specific information to the client (blindly) is not an 
>> ideal one. The approach where the client sends specific 
>> information request and the server returns the requested 
>> information only is a better one, IMHO.
>> 
>> -Kuntal
>> 
>> >-----Original Message-----
>> >From: Ralph Droms [mailto:[e-mail]]
>> >Sent: Friday, October 29, 2004 6:49 AM
>> >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]
>> >Cc: Bernie Volz; [e-mail]
>> >Subject: RE: [dhcwg] BCMCS server option drafts
>> >
>> >
>> >Kuntal - in both DHCPv4 and DHCPv6, there are no required semantic 
>> >ties between the message from the client to the server and the 
>> >response from the server.  That is, the client is not required to 
>> >include any option request information or vendor 
>identification (I'm 
>> >using general terms rather than specific options because of the 
>> >differences between DHCPv4 and
>> >DHCPv6) to cause the server to send certain options or
>> >vendor-specific information back to the client.  The server 
>> >uses any option request information or vendor identification 
>> >or vendor-specific information as input ("hints") to the rules 
>> >the server uses to send a response to the client.  The server 
>> >is free to send information that has not been specifically 
>> >requested by the client, based on other information the server 
>> >gleans from the message it receives from the client.
>> >
>> >So, in the DHCPv6 case, the client is not required to send an 
>> >OPTION_ORO requesting OPTION_VENDOR_OPTS (although it may do
>> >so) and the server, based on other information, is free to
>> >send OPTION_VENDOR_OPTS.  In a 3GPP2 deployment, if the DHCPv6 
>> >server sees a request from a part of the network topology 
>> >known to be using 3GPP2, the server may assume that the device 
>> >sending the request is a 3GPP2 device and send 3GPP2 
>> >OPTION_VENDOR_OPTS to that client.  And, if, for some reason, 
>> >the client is not a 3GPP2 device, the client can simply ignore 
>> >the 3GPP2 OPTION_VENDOR_OPTS.
>> >
>> >The 3GPP2 standards bodies are free to define any syntax or 
>semantics 
>> >for the 3GPP2 OPTION_VENDOR_OPTS.  So, if 3GPP2 coule 
>require that a 
>> >client sends a 3GPP2 OPTION_VENDOR_OPTS request, which the server 
>> >parses and responds with 3GPP2 OPTION_VENDOR_OPTS containing 
>> >information for the client.
>> >
>> >
>> >- Ralph
>> >
>> >
>> >At 03:08 PM 10/28/2004 -0400, Kuntal Chowdhury wrote:
>> >>Hello Bernie,
>> >>
>> >>Thanks for the response. I guess what is not clear to me is
>> >how a DHCP
>> >>client requests vendor specific information from the DHCP server:
>> >>
>> >>"
>> >>- A Client includes OPTION_VENDOR_CLASS to identify itself.
>> >>- A Client MAY include OPTION_VENDOR_OPTS if it has vendor 
>specific 
>> >>data (other than classing information) to communicate.
>> >>- A Server includes OPTION_VENDOR_OPTS for matching
>> >enterprise IDs (and
>> >>class data, if appropriate). This is only REQUIRED if the ORO
>> >includes
>> >>the OPTION_VENDOR_OPTS code (the ORO doesn't say which
>> >vendors; that is
>> >>handled by OPTION_VENDOR_CLASS). "
>> >>
>> >>Second bullet seems to say that the DHCP client includes 
>> >>OPTION_VENDOR_OPTS to convey some vendor specific
>> information to the
>> >>DHCP server beside the vendor class info (which is in
>> >>OPTION_VENDOR_CLASS). It does not state that OPTION_VENDOR_OPTS is 
>> >>included in a DHCP message (such as information
>> >>request) to REQUEST for vendor specific info from the server. 
>> >It is true
>> >>that opcode for OPTION_VENDOR_OPTS can be included in ORO,
>> >but that won't
>> >>necessarily indicate to the server which vendor specific
>> >codes it needs to
>> >>return to the client. Also, the format of the
>> >OPTION_VENDOR_OPTS when it
>> >>appears in the REQUEST message is unclear.
>> >>
>> >>A clear description of how to use OPTION_VENDOR_OPTS to
>> >request vendor
>> >>specific information (such as broadcast server address) will be 
>> >>required by SDOs such as 3GPP2.
>> >>
>> >>Regards,
>> >>Kuntal
>> >>
>> >>
>> >> >-----Original Message-----
>> >> >From: Bernie Volz [mailto:[e-mail]]
>> >> >Sent: Wednesday, October 27, 2004 8:34 PM
>> >> >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; 'Ralph Droms'
>> >> >Cc: [e-mail]
>> >> >Subject: RE: [dhcwg] BCMCS server option drafts
>> >> >
>> >> >
>> >> >Hi:
>> >> >
>> >> >I believe the original model was for OPTION_VENDOR_CLASS to be 
>> >> >similar to DHCPv4 Vendor class identifier option (option
>> >60) and for
>> >> >OPTION_VENDOR_OPTS to be similar to DHCPv4 Vendor Specific 
>> >> >Information (option 43).
>> >> >
>> >> >You might refer to draft-ietf-dhc-vendor-03.txt, while for
>> >DHCPv4, it
>> >> >does have some additional information about how the options
>> >might be
>> >> >used. That work is modeled on the DHCPv6 options. In
>> >particular, see
>> >> >section 4:
>> >> >
>> >> >4.  Vendor-Identifying Vendor-Specific Information Option
>> >> >
>> >> >   DHCP clients and servers may use this option to
>> exchange vendor-
>> >> >   specific information.  Either party may send this
>> >option, as needed.
>> >> >   While a typical case might be for a client to send the
>> >> >   Vendor-Identifying Vendor Class option, to elicit a useful
>> >> >   Vendor-Identifying Vendor-Specific Information Option,
>> >there is no
>> >> >   requirement for such a flow.
>> >> >
>> >> >It would be good to get general agreement on this as
>> you're perhaps
>> >> >the first user. And, it would be best to set a "standard"
>> >for others
>> >> >to follow.
>> >> >
>> >> >I kind of liked the DHCPv4 model, as it is much easier and
>> >clearly to
>> >> >understand (and implement for clients and servers):
>> >> >- A Client includes OPTION_VENDOR_CLASS to identify itself.
>> >> >- A Client MAY include OPTION_VENDOR_OPTS if it has
>> vendor specific
>> >> >data (other than classing information) to communicate.
>> >> >- A Server includes OPTION_VENDOR_OPTS for matching
>> enterprise IDs
>> >> >(and class data, if appropriate). This is only REQUIRED
>> if the ORO
>> >> >includes the OPTION_VENDOR_OPTS code (the ORO doesn't say which
>> >> >vendors; that is handled by OPTION_VENDOR_CLASS).
>> >> >- I'm not sure why a server would ever need to include 
>> >> >OPTION_VENDOR_CLASS, though perhaps it could tell the 
>client what 
>> >> >implementation the server is so that perhaps the client knows it 
>> >> >could use some extended capabilities? Or, the server could 
>> >send back
>> >> >whatever the client sent to it?
>> >> >
>> >> >But, as draft-ietf-dhc-vendor-03.tx states, this is not the only 
>> >> >possible model.
>> >> >
>> >> >Note that in your case, I would assume that the
>> OPTION_VENDOR_CLASS
>> >> >would have your enterprise ID and some class information to
>> >indicate
>> >> >what capabilities the client supports (and therefore the server 
>> >> >should provide configuration for in the OPTION_VENDOR_OPTS).
>> >> >
>> >> >So, this is a good issue for the DHC WG to resolve and
>> >clarify for a
>> >> >future RFC 3315bis.
>> >> >
>> >> >- Bernie
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: [e-mail] 
>[mailto:[e-mail]] On 
>> >> >> Behalf Of Kuntal Chowdhury
>> >> >> Sent: Wednesday, October 27, 2004 4:33 PM
>> >> >> To: Ralph Droms; [e-mail]
>> >> >> Cc: [e-mail]
>> >> >> Subject: RE: [dhcwg] BCMCS server option drafts
>> >> >>
>> >> >>
>> >> >> 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
>> >> >>
>> >> >
>> >> >
>> >> >
>> >>
>> >>_______________________________________________
>> >>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