Subject: Re: [dhcwg] Bulk Leasequery for DHCPv6

From: John Jason Brzozowski <[email-masked]>
Date: Mon, 03 Dec 2007 15:27:57 -0500

Hello Mark, et al,

In advance of discussing this during the WG meeting this week I wanted to
present a question related to Query By Remote-ID.  Specifically, in the case
of DOCSIS where DHCPv6 is used we leveraged vendor specific / vendor
information options in the relay agent (CMTS) under the CableLabs
enterprise-id to identify the the MAC address of the cable modem.  At the
time we specified this as part of DOCSIS I  believe RFC4649 was still a
draft, so the option I am describing is not analogous to remote-id as
specified by RFC4649.

Since this is important functionality I wanted to point this out.  From a
DOCSIS point of view being able to query by the CableLabs cm-mac-address
option would be required for us to fully leverage what the data that can be
obtained care of bulk leasequeries, specifically related to IPv6 prefix
delegation.

Is this something we can or should add to the draft?  If not, perhaps we can
discuss some alternatives via email or in the WG meeting?

Also, regarding QUERY_BY_REMOTE_ID I notice in section 6.2 there is
reference to link-address, is this intended to limit the data set returned
by the DHCP server when replying to bulk leasequeries?  If yes, what would
happen in the device with remote-id ³foo² moved to a different relay agent
but the bindings associated with it are persistent?  Since the link-address
is likely different in this case the server would send no data, correct?

Thanks,

John

On 10/15/07 1:08 PM, "Mark Stapp" <[email-masked]> wrote:

> Hello, all,
> 
> I've just submitted a new draft proposing a TCP-based leasequery for
> DHCPv6. This is sort of a follow-on after the discussion in the WG that
> led to the simplification of the current UDP-based leasequery in
> rfc5007. Those discussions removed some elements of leasequery for v6
> that had tried to use UDP to manage large result sets. There were folks
> who felt that those elements were awkward, and overly complicated the
> core query protocol. This new draft is an attempt to specify some
> extensions to the leasequery protocol and use TCP as the transport in
> order to support large result sets.
> 
> I'd be very happy to hear feedback about the draft, and I'm planning to
> ask that it become a WG draft eventually.
> 
> Here's a url:
> 
> http://www.ietf.org/internet-drafts/draft-stapp-dhc-dhcpv6-bulk-leasequery-00.
> txt
> 
> Thanks,
> Mark
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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

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

---

From: Mark Stapp <[email-masked]>
Date: Mon, 03 Dec 2007 14:48:15 -0800

Hi John,

I don't have any objection at all to additional query types - especially 
if the mechanism isn't useable without them.

I guess I have a preference for having specific queries over trying to 
define some query syntax that can accomodate any arbitrary combination 
of options and suboptions. I think that reduces complexity, personally. 
unless there's interest in a 'universal' query, I'd prefer to add a 
specific query by 'docsis modem mac address'.

about the QUERY_BY_REMOTE_ID: yes, you're exactly right about the 
motivation to support use of the link-address. that was suggested to me 
at some point by someone clever ... Bernie Volz, or Richard Johnson 
maybe? regarding the question about your example use of link-address, I 
think the server returns no bindings if the link-addr is present, and 
the link-addr does match some configured dhcp server pools/prefixes, but 
the remote-id+link-addr combination doesn't match any bindings. if the 
link-addr itself doesn't match any server prefixes, the server returns 
NotConfigured (that's in the text already).

Thanks,
Mark

John Jason Brzozowski wrote:
> Hello Mark, et al,
> 
> In advance of discussing this during the WG meeting this week I wanted 
> to present a question related to Query By Remote-ID.  Specifically, in 
> the case of DOCSIS where DHCPv6 is used we leveraged vendor specific / 
> vendor information options in the relay agent (CMTS) under the CableLabs 
> enterprise-id to identify the the MAC address of the cable modem.  At 
> the time we specified this as part of DOCSIS I  believe RFC4649 was 
> still a draft, so the option I am describing is not analogous to 
> remote-id as specified by RFC4649.
> 
> Since this is important functionality I wanted to point this out.  From 
> a DOCSIS point of view being able to query by the CableLabs 
> cm-mac-address option would be required for us to fully leverage what 
> the data that can be obtained care of bulk leasequeries, specifically 
> related to IPv6 prefix delegation.
> 
> Is this something we can or should add to the draft?  If not, perhaps we 
> can discuss some alternatives via email or in the WG meeting?
> 
> reference to link-address, is this intended to limit the data set 
> returned by the DHCP server when replying to bulk leasequeries?  If yes, 
> what would happen in the device with remote-id “foo” moved to a 
> different relay agent but the bindings associated with it are 
> persistent?  Since the link-address is likely different in this case the 
> server would send no data, correct?
> 
> Thanks,
> 
> John
> 
> 
>     http://www.ietf.org/internet-drafts/draft-stapp-dhc-dhcpv6-bulk-leasequery-00.txt
> 
>     Thanks,
>     Mark
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 3 Dec 2007 17:57:35 -0500

John,

Wrt to what you said snipped below:

"What would happen in the device with remote-id "foo" moved to a 
> server would send no data, correct? "

Can you describe a situation in the cable network where the device with
remote-id "foo" moved to a different relay agent WITHOUT initiating a
new DHCP address acquisition with the new relay agent? I am saying, if a
cable modem moved from one relay agent to use another relay, then the
move will not happen unless the modem initiates a new DHCP address
acquisition that will update the new relay's tables as well as the
server client bindings. I am assuming, the same server is serving both
relays. It's up to the server now to purge the old relay binding. 

Am I missing anything here? We could use a more detailed description of
the problem and then see what needs to be done. 

Thanks.

Hemant

-----Original Message-----
From: Mark Stapp (mjs) 
Sent: Monday, December 03, 2007 2:48 PM
To: John Jason Brzozowski
Cc: dhc WG
Subject: Re: [dhcwg] Bulk Leasequery for DHCPv6

Hi John,

Thanks,
Mark

> what would happen in the device with remote-id "foo" moved to a 
http://www.ietf.org/internet-drafts/draft-stapp-dhc-dhcpv6-bulk-leaseque
ry-00.txt

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 3 Dec 2007 15:12:16 -0800

This is entirely a cosmetic thing, but I would substantially prefer
to see a DHCPv6 Mac Address option be produced as part of Mark Stapp's
bulk leasequery work, and for a query type to reference that, than for
some leasequery query types to reference explicit vendor encapsulated
spaces.

I think we could define it as an option inserted by DHCPv6 relay
agents, recording the source mac address as they received it, which
could be useful logging and management information to v6 server ops.

Is that feasible for DOCSIS?

-- 
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: Mon, 03 Dec 2007 18:19:09 -0800

Hello Mark,

I see your point Mark and it makes sense not attempting to create a
universal query type.  This could indeed become very complex.  If necessary
I am willing to help with the QUERY_BY_CL_MAC_ADDR query type, just let me
know.

Based on the below, it seems to me that strictly enforcing link-addr
+remote-id (or cl-mac-addr) may impact the mileage of bulk leasequery
particularly in the case where where a device has moved from behind one
relay agent to another.  Is this perhaps another query type?

Thanks,

John

On 12/3/07 5:48 PM, "Mark Stapp" <[email-masked]> wrote:

>> > what would happen in the device with remote-id ³foo² moved to a

---

From: John Jason Brzozowski <[email-masked]>
Date: Mon, 03 Dec 2007 18:30:57 -0800

Hello Hemant,

Excellent point, in the case below the cable modem would likely perform
DHCP.  A follow on question I have would be is, can we assume the CPE device
would perform DHCP as part of the move?  I think this is less obvious.
Irrespective of whether the same or different DHCP server is being used to
allocate addresses or prefixes I think a bulk leasequery by remote would
result in data that does not make the new, current state of affairs.  Hence
a bulk leasequery using the cable modem¹s MAC address using the link-address
as a qualifier would produce an empty dataset.  I *think* having two DHCP
servers in the mix in this case could complicate matters, however, I am not
certain if this is practical.  This would suggest that two servers are
autonomously (is this true?) configured to allocate IPv6 addresses and or
prefix from the same parent prefix in an overlapping fashion (which would be
bad).  This assume that no inter-server protocol is in place to coordinate
activities and events between DHCP servers.

HTH,

John

---

From: John Jason Brzozowski <[email-masked]>
Date: Mon, 03 Dec 2007 18:32:28 -0800

Hello David isn¹t this was RFC4649 provides for already?

---

From: Mark Stapp <[email-masked]>
Date: Mon, 03 Dec 2007 18:47:38 -0800

I think I must be missing something?

if the client has moved among relays, either

a) it has done some dhcp with the prefix(es) it has, in which case the 
server bindings should reflect the new location/relay/link, or

b) it hasn't done any dhcp, so the server doesn't know it's moved, so 
... that won't really work, will it? the original relay router will be 
advertising the PD prefixes' routes, and so the client won't get its 
packets. or the new relay actually is in a place in the network that's 
different enough that it can't possibly advertise the specific PD 
prefixes the client has, so the client still won't work right.

so ... is case (b) really something that can happen (in a way that 
hasn't got all kinds of problems)?

-- Mark

John Jason Brzozowski wrote:
> universal query type.  This could indeed become very complex.  If 
> necessary I am willing to help with the QUERY_BY_CL_MAC_ADDR query type, 
> just let me know.
>

---

From: John Jason Brzozowski <[email-masked]>
Date: Mon, 03 Dec 2007 18:56:40 -0800

See below.

John

On 12/3/07 6:47 PM, "Mark Stapp" <[email-masked]> wrote:

> [jjmb] Define client?  In the cable scenario there are two, the CM and the
> CPE.  A DHCP event on the modem does not necessarily guarantee a DHCP event
> for the CPE.  This is the case specifically, I was referring to, the CM has
> done DHCP perhaps as a result of being move but the CPE has not, so the relay
> agent would need to relearn information.
> 
> [jjmb] I believe you are correct, this will not work.  The packets will be
> sent where the client was, not where it is now.
>

---

From: Mark Stapp <[email-masked]>
Date: Mon, 03 Dec 2007 19:12:30 -0800

replies inline ...

John Jason Brzozowski wrote:
>     [jjmb] Define client?  In the cable scenario there are two, the CM
>     and the CPE.  A DHCP event on the modem does not necessarily
>     guarantee a DHCP event for the CPE.  This is the case specifically,
>     I was referring to, the CM has done DHCP perhaps as a result of
>     being move but the CPE has not, so the relay agent would need to
>     relearn information.
> 

but ... if the CPE has PDs, and the PDs are still being routed at the 
'old' network connection point, that's case (b) isn't it? and if we 
agree that (b) doesn't work ...

I guess if the CM changes links, it sort of needs to twiddle the 
client-facing link(s) also in order to get all the parties back in sync. 
  it might well be that the PD leases can't be used at the new point of 
attachment (because of the way aggregation might be used), so any DHCP 
leases really need to get confirmed if the link changes.

-- Mark

---

From: John Jason Brzozowski <[email-masked]>
Date: Tue, 04 Dec 2007 00:46:27 -0800

See inline.

John

On 12/3/07 7:12 PM, "Mark Stapp" <[email-masked]> wrote:

> [jjmb] The above is not necessarily a valid assumption.  I am not sure we can
> assume that the interface in the subscriber domain will reset or perform DHCP
> as a result of the CM resetting or performing DHCP.
> 
> [jjmb] Whether a prefix is usable at the new attachment point depends on
> several variables.  It is conceivable that a prefix may need to be persistent
> even if routes are not aggregated and the CPE moves from relay agent to relay
> agent.
> 
> -- Mark

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 3 Dec 2007 22:31:09 -0800

> Hello David isn¹t this was RFC4649 provides for already?

I suppose that's one way to do it; leasequery by remote-id.  The
reason I didn't think of that is the remote-id is ostensibly an
opaque field preceeded by enterprise-id, not neccessarily "the
client's mac address".

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 4 Dec 2007 17:47:03 -0500

John,
 
Sorry for the delayed reply. I have been swamped lately. It is true that
for CPE, one will not be able to recover them after the CPE modem moves
- after modem move CPE will be dead in the water. During modem move CPE
is also likely (depends how long does the modem move take) to loose IPv6
neighbor detachability.
 
We should not need any inter-comm between the two relays exchanging
their client leases for DHCPv6 Lease Query (LQ). On the new relay, why
not just configure another server to direct LQ requests to. So the new
relay has one setting pointing to its own server and a new setting you
will configure to point to the old server that the modem was using
before move. That way if the CPE lease info is queried upon, the query
will go to both servers. 
 
I think it's not the job of DHCPv6 LQ or Bulk LQ to figure out such
scenarios relating to modem moves. Let's stick to LQ's primary purpose
which is to query for leases in single shot or bulk. 
 
Thanks.
 
Hemant

________________________________

From: John Jason Brzozowski [mailto:[email-masked]] 
Sent: Monday, December 03, 2007 6:31 PM
To: Hemant Singh (shemant); Mark Stapp (mjs)
Cc: dhc WG
Subject: Re: [dhcwg] Bulk Leasequery for DHCPv6

Hello Hemant,

Excellent point, in the case below the cable modem would likely perform
DHCP.  A follow on question I have would be is, can we assume the CPE
device would perform DHCP as part of the move?  I think this is less
obvious.  Irrespective of whether the same or different DHCP server is
being used to allocate addresses or prefixes I think a bulk leasequery
by remote would result in data that does not make the new, current state
of affairs.  Hence a bulk leasequery using the cable modem's MAC address
using the link-address as a qualifier would produce an empty dataset.  I
*think* having two DHCP servers in the mix in this case could complicate
matters, however, I am not certain if this is practical.  This would
suggest that two servers are autonomously (is this true?) configured to
allocate IPv6 addresses and or prefix from the same parent prefix in an
overlapping fashion (which would be bad).  This assume that no
inter-server protocol is in place to coordinate activities and events
between DHCP servers.

HTH,

John

	John,

	> persistent?  Since the link-address is likely different in
this case
	the 
	> server would send no data, correct? "
	
	Can you describe a situation in the cable network where the
device with
	remote-id "foo" moved to a different relay agent WITHOUT
initiating a
	new DHCP address acquisition with the new relay agent? I am
saying, if a
	cable modem moved from one relay agent to use another relay,
then the
	move will not happen unless the modem initiates a new DHCP
address
	acquisition that will update the new relay's tables as well as
the
	server client bindings. I am assuming, the same server is
serving both
	relays. It's up to the server now to purge the old relay
binding. 
	
	Am I missing anything here? We could use a more detailed
description of
	the problem and then see what needs to be done. 
	
	Thanks.
	
	Hemant
	
	-----Original Message-----
	From: Mark Stapp (mjs) 
	Sent: Monday, December 03, 2007 2:48 PM
	To: John Jason Brzozowski
	Cc: dhc WG
	Subject: Re: [dhcwg] Bulk Leasequery for DHCPv6
	
	Hi John,
	
	I don't have any objection at all to additional query types -
especially
	if the mechanism isn't useable without them.
	
	I guess I have a preference for having specific queries over
trying to
	define some query syntax that can accomodate any arbitrary
combination
	of options and suboptions. I think that reduces complexity,
personally. 
	unless there's interest in a 'universal' query, I'd prefer to
add a
	specific query by 'docsis modem mac address'.
	
	about the QUERY_BY_REMOTE_ID: yes, you're exactly right about
the
	motivation to support use of the link-address. that was
suggested to me
	at some point by someone clever ... Bernie Volz, or Richard
Johnson
	maybe? regarding the question about your example use of
link-address, I
	think the server returns no bindings if the link-addr is
present, and
	the link-addr does match some configured dhcp server
pools/prefixes, but
	the remote-id+link-addr combination doesn't match any bindings.
if the
	link-addr itself doesn't match any server prefixes, the server
returns
	NotConfigured (that's in the text already).
	
	Thanks,
	Mark

	
	
	> Since this is important functionality I wanted to point this
out.
	From 
	> Is this something we can or should add to the draft?  If not,
perhaps
	we 
	> returned by the DHCP server when replying to bulk
leasequeries?  If
	yes, 
	> persistent?  Since the link-address is likely different in
this case
	the 
	>     I've just submitted a new draft proposing a TCP-based
leasequery
	for
	>     DHCPv6. This is sort of a follow-on after the discussion
in the WG
	that
	>     rfc5007. Those discussions removed some elements of
leasequery for
	v6
	>     that had tried to use UDP to manage large result sets.
There were
	folks
	>     who felt that those elements were awkward, and overly
complicated
	the
	>     extensions to the leasequery protocol and use TCP as the
transport
	in
	>     I'd be very happy to hear feedback about the draft, and
I'm
	planning to

---

From: John Jason Brzozowski <[email-masked]>
Date: Tue, 04 Dec 2007 16:13:17 -0800

Ok, however, RFC4649 does cite cable modem MAC as a candidate scenario in
the introduction.  Are we saying the same thing and or are we agreeing?

John

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 4 Dec 2007 19:15:56 -0500

Very sorry for the typo. "detachability" in email below is
"reachability".
 
Hemant

From: Hemant Singh (shemant) 
Sent: Tuesday, December 04, 2007 2:47 PM
To: John Jason Brzozowski; Mark Stapp (mjs)
Cc: dhc WG
Subject: RE: [dhcwg] Bulk Leasequery for DHCPv6

John,

 
 
Thanks.
 
Hemant

Hello Hemant,

HTH,

John

	John,

this case
	the 

	
	Thanks.
	
	Hemant
	
	-----Original Message-----
	From: Mark Stapp (mjs) 
	Sent: Monday, December 03, 2007 2:48 PM
	To: John Jason Brzozowski
	Cc: dhc WG
	Subject: Re: [dhcwg] Bulk Leasequery for DHCPv6
	
	Hi John,

	
	
	Thanks,
	Mark

	
	
out.
	From 
perhaps
	we 
leasequeries?  If
	yes, 
this case
	the 
leasequery
	for
in the WG
	that
leasequery for
	v6
There were
	folks
complicated
	the
transport
	in
I'm
	planning to

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 4 Dec 2007 19:17:31 -0500

Right ... the model would be to use the CableLabs Enterprise-ID followed
by the 6-byte mac address as the remote-id data.
 
Thus, the cablelabs version might be:

        0                   1                   2                   3
        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       OPTION_REMOTE_ID        |         option-len = 10       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   enterprise-number = 4491                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                         Mac-address                           .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

But this RFC wasn't available until after Cablelabs had already decided
to encode this into the Vendor option (17) as a suboption.

- Bernie

From: John Jason Brzozowski [mailto:[email-masked]] 
Sent: Tuesday, December 04, 2007 7:13 PM
To: David Hankins; dhc WG
Subject: Re: [dhcwg] Bulk Leasequery for DHCPv6

Ok, however, RFC4649 does cite cable modem MAC as a candidate scenario
in the introduction.  Are we saying the same thing and or are we
agreeing?

John

	On Mon, Dec 03, 2007 at 06:32:28PM -0800, John Jason Brzozowski
wrote:
	> Hello David isn't this was RFC4649 provides for already?

---

From: John Jason Brzozowski <[email-masked]>
Date: Tue, 04 Dec 2007 16:22:18 -0800

I figured that is what you meant.  Replying to original email.

John

On 12/4/07 4:15 PM, "Hemant Singh (shemant)" <[email-masked]> wrote:

> Very sorry for the typo. "detachability" in email below is "reachability".
>  
> Hemant
> 
> 
> Sorry for the delayed reply. I have been swamped lately. It is true that for
> CPE, one will not be able to recover them after the CPE modem moves - after
> modem move CPE will be dead in the water. During modem move CPE is also likely
> (depends how long does the modem move take) to loose IPv6 neighbor
> detachability.
>  
> We should not need any inter-comm between the two relays exchanging their
> client leases for DHCPv6 Lease Query (LQ). On the new relay, why not just
> configure another server to direct LQ requests to. So the new relay has one
> setting pointing to its own server and a new setting you will configure to
> point to the old server that the modem was using before move. That way if the
> CPE lease info is queried upon, the query will go to both servers.
>  
> I think it's not the job of DHCPv6 LQ or Bulk LQ to figure out such scenarios
> relating to modem moves. Let's stick to LQ's primary purpose which is to query
> for leases in single shot or bulk.
>  
> Thanks.
>  
> Hemant
> 
> 
> Excellent point, in the case below the cable modem would likely perform DHCP.
> A follow on question I have would be is, can we assume the CPE device would
> perform DHCP as part of the move?  I think this is less obvious.  Irrespective
> of whether the same or different DHCP server is being used to allocate
> addresses or prefixes I think a bulk leasequery by remote would result in data
> that does not make the new, current state of affairs.  Hence a bulk leasequery
> using the cable modem¹s MAC address using the link-address as a qualifier
> would produce an empty dataset.  I *think* having two DHCP servers in the mix
> in this case could complicate matters, however, I am not certain if this is
> practical.  This would suggest that two servers are autonomously (is this
> true?) configured to allocate IPv6 addresses and or prefix from the same
> parent prefix in an overlapping fashion (which would be bad).  This assume
> that no inter-server protocol is in place to coordinate activities and events
> between DHCP servers.
> 
> HTH,
> 
> John
>

---

From: John Jason Brzozowski <[email-masked]>
Date: Tue, 04 Dec 2007 16:39:08 -0800

Hello Hemant thanks for the feedback.  See my comment below.

John

On 12/4/07 2:47 PM, "Hemant Singh (shemant)" <[email-masked]> wrote:

> [jjmb] Just so we are on the same page.  The CPE will still be active, just
> unreachable because the route may not be known.  Also, are you suggesting that
> the absence of the IPv6 connectivity or reachability will cause the CPE to
> reinitialize or more specifically re-initiate DHCP?
>  
> [jjmb] I agree inter-relay communication is not the answer.  So I think there
> are two scenarios here a) one server and b) two.  A single server model is
> pretty simple assuming the data set from the bulk leasequery does not return a
> null data server because the link-address + remote-id (or cl-mac-address)
> options do not match.  From a deployment point of view I am not sure if an
> autonomous, two server model is likely.  This would suggest the two servers
> that are not aware of one another have overlapping configurations, which would
> be problematic.
>  
> [jjmb] I think I would agree, the DHCP server should reply to the query.  My
> point above and in previous emails was related in part to the particulars of
> the link-address aspect of the remote-id (or cl-mac-address) query.  As long
> as the old or new relay can get the data it requires then it can
> differentiate.
>  
> Thanks.
>  
> Hemant
> 
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 4 Dec 2007 22:24:07 -0500

Hey John,
 
Please see in line below in this color.

From: John Jason Brzozowski [mailto:[email-masked]] 
Sent: Tuesday, December 04, 2007 4:39 PM
To: Hemant Singh (shemant); Mark Stapp (mjs)
Cc: dhc WG
Subject: Re: [dhcwg] Bulk Leasequery for DHCPv6

John

	John,
	
	Sorry for the delayed reply. I have been swamped lately. It is
true that for CPE, one will not be able to recover them after the CPE
modem moves - after modem move CPE will be dead in the water. During
modem move CPE is also likely (depends how long does the modem move
take) to loose IPv6 neighbor detachability.
	
	[jjmb] Just so we are on the same page.  The CPE will still be
active, just unreachable because the route may not be known.  Also, are
you suggesting that the absence of the IPv6 connectivity or reachability
will cause the CPE to reinitialize or more specifically re-initiate
DHCP? 
	 
	[hs]  No, I am not suggesting at all that CPE will re-imitate
DHCPv6. The CPE ND stack will fail neighbor reachability with the relay
which is also the IPV6 router. As a last resort after router cannot be
reached by CPE, CPE will try address resolution. That address resolution
will also be not replied to.  In the new relay setup, the CPE will also
receive the RA from the new relay router. We will have to check some
DHCPv6 core standards to see if a host has information for two RA's
(that is fine since ND does let a host keep a union of router info from
multiple routers) after how much timeout interval will the host kick off
a new DHCPv6 if the host has determined in the meantime that the first
router is dead and let me move to the new one. Let's see if such
behavior is specified anywhere between DHCPv6 and/or ND.
	
	We should not need any inter-comm between the two relays
exchanging their client leases for DHCPv6 Lease Query (LQ). On the new
relay, why not just configure another server to direct LQ requests to.
So the new relay has one setting pointing to its own server and a new
setting you will configure to point to the old server that the modem was
using before move. That way if the CPE lease info is queried upon, the
query will go to both servers. 
	
	[jjmb] I agree inter-relay communication is not the answer.  So
I think there are two scenarios here a) one server and b) two.  A single
server model is pretty simple assuming the data set from the bulk
leasequery does not return a null data server because the link-address +
remote-id (or cl-mac-address) options do not match.  From a deployment
point of view I am not sure if an autonomous, two server model is
likely.  This would suggest the two servers that are not aware of one
another have overlapping configurations, which would be problematic.
	 
	[hs] For the single server case, before the relay will be able
to send any LQ request to server for CPE data, the modem for the CPE
will be up and running. Therefore, the server knows the CM remote-id
coming from this new relay giaddr and the server will have to purge the
old remote-id vs. old giaddr binding. So now if the LQ request is sent
for CPE data,  the giaddr used from the new relay does have a correct
binding on the server. 
	 
	I think it's not the job of DHCPv6 LQ or Bulk LQ to figure out
such scenarios relating to modem moves. Let's stick to LQ's primary
purpose which is to query for leases in single shot or bulk. 
	
	[jjmb] I think I would agree, the DHCP server should reply to
the query.  My point above and in previous emails was related in part to
the particulars of the link-address aspect of the remote-id (or
cl-mac-address) query.  As long as the old or new relay can get the data
it requires then it can differentiate.
	 
	[hs] Yup. See above.
	 
	Hemant

	Thanks.
	
	Hemant

	From: John Jason Brzozowski
[mailto:[email-masked]] 
	Sent: Monday, December 03, 2007 6:31 PM
	To: Hemant Singh (shemant); Mark Stapp (mjs)
	Cc: dhc WG
	Subject: Re: [dhcwg] Bulk Leasequery for DHCPv6
	
	Hello Hemant,
	
	Excellent point, in the case below the cable modem would likely
perform DHCP.  A follow on question I have would be is, can we assume
the CPE device would perform DHCP as part of the move?  I think this is
less obvious.  Irrespective of whether the same or different DHCP server
is being used to allocate addresses or prefixes I think a bulk
leasequery by remote would result in data that does not make the new,
current state of affairs.  Hence a bulk leasequery using the cable
modem's MAC address using the link-address as a qualifier would produce
an empty dataset.  I *think* having two DHCP servers in the mix in this
case could complicate matters, however, I am not certain if this is
practical.  This would suggest that two servers are autonomously (is
this true?) configured to allocate IPv6 addresses and or prefix from the
same parent prefix in an overlapping fashion (which would be bad).  This
assume that no inter-server protocol is in place to coordinate
activities and events between DHCP servers.
	
	HTH,
	
	John
	
	On 12/3/07 5:57 PM, "Hemant Singh (shemant)" <[email-masked]>
wrote:

		John,

		"What would happen in the device with remote-id "foo"
moved to a  
		> persistent?  Since the link-address is likely
different in this  case
		the 
		> server would send no data, correct? "
		
		Can you  describe a situation in the cable network where
the device with
		remote-id  "foo" moved to a different relay agent
WITHOUT initiating a
		new DHCP  address acquisition with the new relay agent?
I am saying, if a
		cable modem  moved from one relay agent to use another
relay, then the
		move will not  happen unless the modem initiates a new
DHCP address
		acquisition that will  update the new relay's tables as
well as the
		server client bindings. I am  assuming, the same server
is serving both
		relays. It's up to the server now  to purge the old
relay binding. 
		
		Am I missing anything here? We could  use a more
detailed description of
		the problem and then see what needs to  be done. 
		
		Thanks.
		
		Hemant
		
		-----Original  Message-----
		From: Mark Stapp (mjs) 
		Sent: Monday, December 03, 2007  2:48 PM
		To: John Jason Brzozowski
		Cc: dhc WG
		Subject: Re: [dhcwg]  Bulk Leasequery for DHCPv6
		
		Hi John,
		
		I don't have any objection  at all to additional query
types - especially
		if the mechanism isn't  useable without them.
		
		I guess I have a preference for having specific  queries
over trying to
		define some query syntax that can accomodate any
arbitrary combination
		of options and suboptions. I think that reduces
complexity, personally. 
		unless there's interest in a 'universal' query,  I'd
prefer to add a
		specific query by 'docsis modem mac  address'.
		
		about the QUERY_BY_REMOTE_ID: yes, you're exactly right
about  the
		motivation to support use of the link-address. that was
suggested to  me
		at some point by someone clever ... Bernie Volz, or
Richard  Johnson
		maybe? regarding the question about your example use of
link-address, I
		think the server returns no bindings if the link-addr is
present, and
		the link-addr does match some configured dhcp server
pools/prefixes, but
		the remote-id+link-addr combination doesn't match any
bindings. if the
		link-addr itself doesn't match any server prefixes, the
server returns
		NotConfigured (that's in the text  already).
		
		Thanks,
		Mark

		
		
		> vendor  information options in the relay agent (CMTS)
under the
		CableLabs 
		> Since this is  important functionality I wanted to
point this out.
		From 
		> Is this something we can or should  add to the draft?
If not, perhaps
		we 
leasequeries?  If
		yes, 
		> persistent?   Since the link-address is likely
different in this case
		the 
		>     I've just submitted a new draft  proposing a
TCP-based leasequery
		for
		>      DHCPv6. This is sort of a follow-on after the
discussion in the WG
		that
		>      rfc5007. Those discussions removed some elements
of  leasequery for
		v6
		>     that had tried to use UDP  to manage large result
sets. There were
		folks
		>      who felt that those elements were awkward, and
overly  complicated
		the
		>      extensions to the leasequery protocol and use TCP
as  the transport
		in
		>     I'd be very happy to  hear feedback about the
draft, and I'm
		planning to

---

From: John Jason Brzozowski <[email-masked]>
Date: Tue, 04 Dec 2007 20:56:25 -0800

Hello Hemant - see inline.

> Please see in line below in this color.
[jjmb] When the modem has moved it will likely reinitiate DHCP which will
get is squared away with the router which happens to be a relay agent in
this case.  The CPE router or RG in this case will not have a trigger to
reinitiate DHCP so the router/relay agent will not have any knowledge of our
to route prefixes that have been delegated to it.  In this case a bulk
leasequery by remote-id (or cl-mac-address) could be used to re-populate the
routing information in the router/relay agent (CMTS).  Once the CM is back
online the CPE and RG will see RAs which should allow it to pass upstream
traffic.  If a bulk leasequery has not been issued yet the traffic
originating from the CPE/RG will trigger a single leasequery (RFC5007).
> for CPE data,  the giaddr used from the new relay does have a correct
[jjmb] I agree the CM needs to come up first.  Do you expect that a server
will purge the remote-id to old giaddr bindings when the modem comes online
against the new relay?  I would assume not, perhaps this is implementation
specific?  These should be separate bindings.  I am not certain the last
sentence is a valid assumption.  Perhaps someone else on the list could
chime in?

---

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

> the introduction.  Are we saying the same thing and or are we agreeing?

The differentiation is that you have to know the remote-id a
particular vendor has selected to use, and you have to know this in
advance of making your leasequery.  Client mac address is only one
example.

I misunderstood earlier I think; I thought you were asking for
leasequery to permit a query based on a DOCSIS VSIO option contents.

If remote-id fits your needs, that's fine.

Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/

---

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

I actually am suggesting a specific query by cl-mac-address which resides in
a VSIO and not in an RFC4649 option.

John

---

From: "Andre Kostur" <[email-masked]>
Date: Wed, 5 Dec 2007 08:13:45 -0800

FYI: in DOCSIS, the Remote-ID is defined to be the Cable Modem's MAC
address.

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2007 8:05 AM
To: DHC WG
Subject: Re: [dhcwg] Bulk Leasequery for DHCPv6

in

---

From: John Jason Brzozowski <[email-masked]>
Date: Wed, 05 Dec 2007 08:51:50 -0800

In DOCSIS relative to DHCPv6 the MAC address of the modem transmitted as
part of the relay forward message is not in an RFC4649 option.  It is in a
VSIO specified under CableLabs.

---

From: John Jason Brzozowski <[email-masked]>
Date: Wed, 05 Dec 2007 08:47:34 -0800

In DOCSIS 3.0 relative to IPv6

---

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

Sorry this was a mis-send.

---

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

> a VSIO and not in an RFC4649 option.

OK, and although this might seem cosmetic, I'd actually rather
a standard client-mac-address-option (that really means "client mac
address" and not "vendor specific remote-id that may be a mac address
or not") rather than do what we need to do to delve into VSIO.

It seems to me that one way to populate a relay's state table that is
incomplete (due e.g. to a failure in a peer dhcpv6 relay) is to
leasequery for observed mac addresses and cache the positive/negative
results.

---

From: Josh Littlefield <[email-masked]>
Date: Wed, 05 Dec 2007 15:30:39 -0500

David,

I'm still not sure if you're clear that the MAC address in question is
not the client's MAC address.  It is the Cable Modem's MAC address. 
There may be many clients behind the cable modem.  The relay adds the CM
MAC address (the CM is essentially a transparent bridge) into a
relay-vendor-option (should be remote-id, but it wasn't, due to timing)
in order to identify which CM a client is behind.  In Cable, the CM MAC
address is the subscriber identifier, and the relay (within the CMTS)
can determine from which CM any client traffic originates.

I think John's goal is to retrieve all information (addresses and
prefixes) for clients behind any particular CM using bulk leasequery.

-josh

David W. Hankins wrote:
> ------------------------------------------------------------------------
>

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA  01719-2205

---

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

Thanks Josh, this is indeed the scenario.

---

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

Inline.

John

> or not") rather than do what we need to do to delve into VSIO.
[jjmb] Well I do not disagree, however, at the time of writing DOCSIS the
RFC that specifies the same was not ratified.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 5 Dec 2007 13:37:45 -0800

> can determine from which CM any client traffic originates.

Right, remote-id and subscriber-id, I always get them backwards.

It still seems odd to me to have a query type that keys on the vendor
specific option spaces, but I'll table this until I see Mark's
revisions.

---

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

Hi David,
there's sort of a twist here in that there's a 'vendor' space for 
DOCSIS, which is really sort of more an 'industry'. so I feel less 
uneasy than I would if we were talking about an individual corporate 
entity's vendor space.

Thanks,
Mark