Re: [dhcwg] DHCPv6 RAAN options

On Aug 8, 2014, at 12:06 PM 8/8/14, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:

> Hi Ralph,
> 
>> -----Original Message-----
>> From: Ralph Droms [mailto:rdroms.ietf@gmail.com]
>> Sent: Friday, August 08, 2014 8:57 AM
>> To: Ted Lemon
>> Cc: Templin, Fred L; dhcwg@ietf.org
>> Subject: Re: [dhcwg] DHCPv6 RAAN options
>> 
>> 
>> On Aug 8, 2014, at 10:53 AM 8/8/14, Ted Lemon <ted.lemon@nominum.com> wrote:
>> 
>>> On Aug 8, 2014, at 10:44 AM, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:
>>>> Write a little draft that (if approved) updates RFC3315?
>>> 
>>> That's the right process, if you can't get this into the 3315bis effort.   But it would have to go
>> through the working group.   I seem to be talking a lot on this topic, but I'm only one working group
>> participant, and not an active participant in the 3315bis effort.   Have any of the 3315bis people
>> been following this discussion?   Do you have thoughts on the matter?
>> 
>> If I recall correctly, draft-ietf-dhc-dhcpv6-agentopt-delegate-04 was not published by the working
>> group because of message transport and ordering concerns: no guarantees that...
>> 
>> ...messages containing RAAN options will be delivered in order so that the relay agent takes actions
>> in the correct order
>> ...transactions containing RAAN options will be forwarded through the correct relay agent; e.g., the
>> transaction delegating prefix P to device D might be forwarded through relay agent R1, causing R1 to
>> take action based on that delegation, while the subsequent transaction releasing P might be forwarded
>> through relay agent R2, which has no knowledge of the original delegation
> 
> I have a case where the Client can steer its DHCPv6 messaging through a
> specific relay agent or agents by mapping All_DHCP_Relay_Agents_and_Servers
> to a unicast L2 address. I think there would probably also be real-world
> use cases where there is only one relay agent on the link - otherwise, I
> think PD might have problems in some environments. But, perhaps others
> would know better.

After a short conversation at lunch on this topic, I also recall (and others with better memory should certainly correct me) that the WG eventually came to the conclusion that piggybacking information for the relay agent on client-server transactions is not a good design.  A protocol transaction (DHCP or something else) explicitly between the relay agent and some control function (perhaps in the DHCP server, perhaps elsewhere) would be a more robust design.

> 
> Thanks - Fred
> fred.l.templin@boeing.com
> 
>> - Ralph
>> 
>> PS I'm working from memory w/o bothering to research the mailing list...
>>> 
>>> _______________________________________________
>>> dhcwg mailing list
>>> dhcwg@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dhcwg
> 