Subject: [dhcwg] Modem MAC query for v6 bulk leasequery

From: Mark Stapp <[email-masked]>
Date: Wed, 05 Dec 2007 12:55:25 -0800

I've been following the sub-thread about docsis modem mac addresses. 
would it be fair to say "it's a goal to have a query that can query by 
docsis modem MAC address?"

if so, we could do that in a couple of ways:

1. add a 'docsis modem id (or 'mac')' query type, and define it to mean 
"match the vendor-specific value if present, and the remote-id otherwise."

2. add a 'query by docsis vendor-specific modem mac', which is defined 
to match only the specific docsis vendor-specific piece of data.

I think I'd prefer (1) at this point, if only to make it easier in case 
there are mixed relays in a network, or in case docsis specifies a 
migration away from the vendor-specific value towards the remote-id.

Thanks,
Mark

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

---

From: John Jason Brzozowski <[email-masked]>
Date: Wed, 05 Dec 2007 13:15:12 -0800

So #1 will default to remote-id if cl-mac-address is not present?  If yes,
this seems reasonable as it offers a sort of migration path to RFC4649.

John

> migration away from the vendor-specific value towards the remote-id.

=========================================
John Jason Brzozowski (CISSP, RHCT)
Comcast Corporation
e) mailto:[email-masked]
m) 609-377-6594
p) 856-324-2671
=========================================

---

From: Mark Stapp <[email-masked]>
Date: Wed, 05 Dec 2007 13:24:20 -0800

John,

> this seems reasonable as it offers a sort of migration path to RFC4649.

yes, that'd be the idea. and that would imply that the target server(s) 
would need to be able to support that logic.

-- Mark

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 5 Dec 2007 21:58:39 -0500

Of course, at present all it means is to use the DOCSIS vendor option as
there is no mechanism to store the cm mac address in the anything else
(such as Remote ID, as it requires an enterprise-id). So, I can't see
how that would be specified at this point in time.

I'm also a bit concerned about using a query type for each new vendor
specific option/requirement. This won't scale well? It also is rather
odd to require standards action to get vendor-specific behavior when
we've provided a good mechanism in DHCPv6 to let vendors extend the
protocol (well options data), but don't do it for LQ.

I'd prefer we define a vendor specific query that would include the
enterprise-id and then the "data" inside the remainder of the option is
up to the vendor (and specified by the vendor). Then, CableLabs, DSL
Forum, or whatever could specify their own queries.

Note that this is different than specifying a query-by-vendor-option.
This is a vendor specific query and a vendor would have well defined
queries as we're presently specifying for the "core" protocol.

This isn't perfect, because it requires the DHCP server (or at least the
LQ server) to be able to support specific vendor queries.

To resolve that issue, the other choice would be to have a (or several)
queries by vendor-option or vendor-suboption. For example, we would have
a query type that is query-by-vendor-option which means compare the
enterprise-id and all the bytes on a lease against this data -- return
those that match. And a query-by-vendor-suboption which would include an
enterprise-id and then a sub-option for the vendor-id (this is what
could be used to exact the cm-mac-address from the CableLabs vendor
option) -- in this case, the server would need to see if that suboption
was present and matched the specified data. This is a general query
mechanism, but also is nice in that it can be optimized for those
implementations that are targeted at specific markets.

---

While it may be late to change DOCSIS, only the CMTS' (Relay) would need
to be "enhanced" to also include a Remote-ID option with the Cablelabs
enterprise-id and put the cm-mac-address into the remote-id option data
(they would continue to leave it in the Cablelabs vendor option).

Sure, it might take a while before the CMTS' are updated, but it is
going to take a while before the Bulk LQ is done too. So, this would
avoid much of the above issues and keep things simple - just a
Query-by-Remote-ID. [And, servers COULD also support a special mapping
for this query to the existing Cablelabs vendor-option option to support
those CMTS' that didn't do the Remote-ID option. Which is close to what
you're proposing anyway, though in the opposite direct.]

Personally, I like this approach best!!

---

Anyway, just some things to think about. There really isn't a simple
solution here.

- Bernie

-----Original Message-----
From: Mark Stapp (mjs) 
Sent: Wednesday, December 05, 2007 4:24 PM
To: John Jason Brzozowski
Cc: dhc WG
Subject: Re: [dhcwg] Modem MAC query for v6 bulk leasequery

John,

-- Mark

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 5 Dec 2007 22:08:09 -0800

> Personally, I like this approach best!!

I have to agree now that you think about it.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: John Jason Brzozowski <[email-masked]>
Date: Thu, 06 Dec 2007 10:51:21 -0800

Hello Bernie see comments inline below.

John

> how that would be specified at this point in time.
[jjmb] Why could it not be specified from a technical point of view?  A
server could implement storage of such options and provide a key to lookup
the same, no?  However, to your point below scalability may be an issue and
this of course would be vendor specific.

> Forum, or whatever could specify their own queries.
[jjmb] This is interesting.  Each vendor would have to specify their own
specific queries.  This could work.

> implementations that are targeted at specific markets.
[jjmb] This seems a bit complicated maybe overly complicated compared to
some other alternatives.

> (they would continue to leave it in the Cablelabs vendor option).
[jjmb] This might be the best solution relatively speaking.  As you mention
timing is an important consideration.  It would be nice to hear feedback
from others in the WG regarding the different approaches.

---

From: Bud Millwood <[email-masked]>
Date: Wed, 12 Dec 2007 08:06:42 +0100

On Thursday 06 December 2007 03:58, Bernie Volz (volz) wrote:

<snip>

> implementations that are targeted at specific markets.

This sounds like a great idea - it should cover a lot uf use cases. And I'd 
prefer not to see vendor-specific queries if at all possible.

- Bud

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687