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
>       along@cisco.com
>
>So, they'd be good to go!
>
>- Bernie
>
> > -----Original Message-----
> > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]
> > On Behalf Of Ralph Droms
> > Sent: Thursday, October 21, 2004 2:35 PM
> > To: dhcwg@ietf.org
> > 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
> > dhcwg@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> >

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg