[dhcwg] BCMCS server option drafts

Ralph Droms <rdroms@cisco.com> Thu, 21 October 2004 19:15 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08316 for <dhcwg-web-archive@ietf.org>; Thu, 21 Oct 2004 15:15:08 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKibg-0003rR-K2 for dhcwg-web-archive@ietf.org; Thu, 21 Oct 2004 15:28:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiA3-00021H-5b; Thu, 21 Oct 2004 14:59:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhn1-0005he-FH for dhcwg@megatron.ietf.org; Thu, 21 Oct 2004 14:35:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03928 for <dhcwg@ietf.org>; Thu, 21 Oct 2004 14:35:53 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhzf-0002nF-I7 for dhcwg@ietf.org; Thu, 21 Oct 2004 14:49:01 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 21 Oct 2004 11:43:17 -0700
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9LIZFk2025075 for <dhcwg@ietf.org>; Thu, 21 Oct 2004 11:35:15 -0700 (PDT)
Received: from rdroms-w2k01.cisco.com ([161.44.65.190]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AML78509; Thu, 21 Oct 2004 14:35:16 -0400 (EDT)
Message-Id: <4.3.2.7.2.20041021143445.02504d48@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 21 Oct 2004 14:35:14 -0400
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Subject: [dhcwg] BCMCS server option drafts
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a

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