Subject: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs. Leasequery

From: Alfred Hönes <[email-masked]>
Date: Thu, 2 Apr 2009 11:46:24 +0200 (MESZ)

Hello,
studying the recently refreshed DHCPv6 RAAN Option draft,
    draft-ietf-dhc-dhcpv6-agentopt-delegate-03,
I find some close relationship to [Bulk] Leasequery:
the RAAN Option is intended to establish client specific
state, e.g. routing state, on a DHCP Relay Agent node;
[Bulk] Leasequery is intended to restore such state.

However, the DHCPv6 RAAN Option draft does not discuss this
relationship and/or potential applicability of the RAAN Option
to DHCPv6 [Bulk] Leasequery.

I would appreciate this being discussed and perhaps, the
applicability of RAAN expanded in the next draft revision.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Ralph Droms <[email-masked]>
Date: Fri, 3 Apr 2009 10:03:48 -0400

Alfred - good question.  You're right, the RAAN option introduces  
state in the network element hosting the relay agent, which must be  
restored if the network element loses that state.

We'll review DHCPv6 leasequery to see if what extensions would be  
required for routing state recovery.

- Ralph

On Apr 2, 2009, at 5:46 AM 4/2/09, Alfred HÎnes wrote:

>  Alfred HÎnes.
> +------------------------ 
> +--------------------------------------------+
> +------------------------ 
> +--------------------------------------------+
>

---

From: John Jason Brzozowski <[email-masked]>
Date: Fri, 03 Apr 2009 10:41:19 -0400

Ralph, Alfred,

I believe the expectation is that when a relay agent performs DHCPv6 bulk
lease query the RAAN option will be retrieved as part of the LEASEQUERY-DATA
Option providing the lease query includes the RAAN option (TBD).

RFC5007 and RFC5460 specify the protocol and mechanism required to retrieve
lease data from the DHCP server.

Just so I am clear are we suggesting that RFC5460 and or the RAAN draft
should specify how the relay agent is to rebuild routing state?

John
=========================================
John Jason Brzozowski
Comcast Corporation
e) mailto:[email-masked]
m) 609-377-6594
=========================================

> From: Ralph Droms <[email-masked]>
> Date: Fri, 3 Apr 2009 10:03:48 -0400
> To: Alfred HÎnes <[email-masked]>
> Cc: dhc WG <[email-masked]>,
> <[email-masked]>
> Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leasequery
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Fri, 3 Apr 2009 10:50:24 -0400

John - I don't recall: does the leasequery draft have a mechanism  
through which the routing information, as carried in the RAAN option,  
can be delivered to the relay agent?

- Ralph

---

From: John Jason Brzozowski <[email-masked]>
Date: Fri, 03 Apr 2009 11:03:47 -0400

Unless I am missing something, if the RAAN option is specified as part of
the initial lease query request via the ORO, the server will return it to
the requestor, if available.  In this case the RAAN option will be present
for processing by the relay agent.

Do we aim to specify how the relay agent will perform routing updates?  I
assume not.

John

> Date: Fri, 3 Apr 2009 10:50:24 -0400
> To: "Brzozowski, John" <[email-masked]>
> Cc: Alfred HÎnes <[email-masked]>, dhc WG <[email-masked]>,

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 3 Apr 2009 11:14:48 -0400

Yes, the RAAN draft should reference the LQ and bulk LQ drafts (Ralph just re-submitted the expired version without other changes to restore the draft to active status). And, at the time the draft last had major revisions was before the bulk LQ draft existed. The 02 draft was from Nov 2006. Bulk LQ was first submitted Oct 2007.

The RAAN option always required a separate state recovery mechanism and that was what (Bulk) LQ was to address. Normal on-demand LQ is incomplete because it required traffic to flow (ie, if the relay/router also needed to inject the prefixes, no traffic would ever flow if the injecting doesn't occur). Bulk LQ was to solve that issue. So for state recovery, LQ & bulk LQ is the correct way to go.

- Bernie

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Friday, April 03, 2009 10:04 AM
To: Alfred HÎnes
Cc: [email-masked]; Dhcwg WG
Subject: Re: draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs. Leasequery

- Ralph

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 6 Apr 2009 12:40:35 -0400

I'm not sure why the RAAN option would be needed at all for the Bulk LQ.

The main purpose of the RAAN option was to avoid having the Relay need to peek inside the message it is relaying to the client (and for some messages that also requires that the Relay would have peeked inside the message that it forwarded to the server).

And, the information in the Bulk LQ is designed for relay agents (or other devices that are NOT the client itself), so there's little reason to add yet another set / copy of the data.

I think Alfred's point was just that RAAN doesn't solve the power failure/reboot case of how a relay agent would recover any state. That is what BULK LQ was designed for and it already provides sufficient data.

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Jason Brzozowski
Sent: Friday, April 03, 2009 11:04 AM
To: Ralph Droms (rdroms)
Cc: dhc WG; Alfred HÎnes; [email-masked]
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leasequery

John

---

From: John Jason Brzozowski <[email-masked]>
Date: Mon, 06 Apr 2009 15:34:53 -0400

Perhaps I am missing something if a relay agent simply performs bulk
leasequery this at best results in all lease data being proactively
re-populated which does not explicitly suggest that routing information will
be re-established right?  So in cases where the bindings are being used for
access control the relay agent would have all the information required.

However, for cases where routing state needs to be recreated proactively I
was operating under the assumption that the bulk leasequery would specify in
the ORO the RAAN option to ensure that this data is returned in the
LEASEQUERY-DATA in turn enabling the relay agent to (re)create routing
state.

John

> From: Bernie Volz <[email-masked]>
> Date: Mon, 6 Apr 2009 12:40:35 -0400
> To: "Brzozowski, John" <[email-masked]>, Ralph Droms
> <[email-masked]>
> Cc: dhc WG <[email-masked]>, Alfred HÎnes <[email-masked]>,
> Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leasequery
> 
> The main purpose of the RAAN option was to avoid having the Relay need to peek
> inside the message it is relaying to the client (and for some messages that
> also requires that the Relay would have peeked inside the message that it
> forwarded to the server).
> 
> And, the information in the Bulk LQ is designed for relay agents (or other
> devices that are NOT the client itself), so there's little reason to add yet
> another set / copy of the data.
> 
> I think Alfred's point was just that RAAN doesn't solve the power
> failure/reboot case of how a relay agent would recover any state. That is what
> BULK LQ was designed for and it already provides sufficient data.
> 
> - Bernie
> 
> Cc: dhc WG; Alfred HÎnes;
> [email-masked]

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 6 Apr 2009 15:42:55 -0400

The RAAN option as it is presently defined just contains the IAADDR and IAPREFIX options:

   The RAAN option carries information about assigned IPv6 addresses and
   prefixes.  It encapsulates IA Address options (RFC 3315) and/or IA
   Prefix options (RFC 3633), and possibly other options that carry
   other information related to the assigned IPv6 address or prefix.

...

   The contents of options encapsulated in the RAAN option are
   interpreted according to the use of those options in the node on
   which the relay agent is implemented.  For the purposes of address
   and prefix assignment, the uses of the DHCP IA Address and IA Prefix
   options are defined in this document.

As Bulk LQ also returns this information, what information would be missing? And, if there were additional options defined to be encapsulated in the RAAN option, it would likely be easier if for Bulk LQ these were directly requested (in the ORO) and returned rather than having to encapsulate in the RAAN option? But I guess that will need to wait until they are defined?

- Bernie

-----Original Message-----
From: John Jason Brzozowski [mailto:[email-masked]] 
Sent: Monday, April 06, 2009 3:35 PM
To: Bernie Volz (volz); Ralph Droms (rdroms)
Cc: dhc WG; Alfred HÎnes; [email-masked]
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leasequery

John