RE: [dhcwg] dhc wg last call on agentopt-delegateand srsn-optiondrafts

["Templin, Fred L" <Fred.L.Templin at boeing.com>]

Hi David, 

> On Thu, Jan 04, 2007 at 09:23:29AM -0800, Templin, Fred L wrote:
> > OK. Then, can you (or someone who was involved in the earlier
> > discussions) summarize what other issues might remain?
> 
> I think you mean me.

I wasn't trying to single out anyone; I truthfully was not
aware of the 05/06 discussion thread until late yesterday
afternoon and then only had time for a quick skim.

> The vast exchange between Bernie and myself (throughout the
> entire history of same) can be summarized I hope without
> offense:
> 
> 1) "Turning DHCPv6 into a kind of RIP-like thing" (my critique)
>    is possibly not the most robust network design modern men can
>    invent (alternatives given).
> 	a) But it may be the easiest to implement for CMTS people,
> 	   especially since CMTS already have to implement DHCPv6
> 	   relays.
> 	b) And isn't specified in this option anyway.  The entire
> 	   question of what you do with the contents of this option
> 	   are left to implementors.  It might just program an ACL
> 	   for a formal routing protocol (although at least this
> 	   purpose is one that does not strictly require the SRSN).

I may have a slightly different slant on this as we have
discussed before. My motivation is to reduce churn in the
backhaul network routing protocol in the presence of highly
mobile nodes (MNs).  

> 2) It falls down in multiple-relay (failsafe, not chained) scenarios.
> 	a) But there are no multiple-relay scenarios for CMTS,
> 	   for which this is being designed.  Such network designs
> 	   have 'cold spares' not 'running peers' for fault tolerance.
> 	b) And our volunteer is, understandably, unwilling to design
> 	   for multiple-relays.

My scenario supports (and benefits from) multiple relays
on the link, where each relay is co-resident with a router.
MNs can use any of the available relays as a default router
but the one that actually relayed the DHCP address/prefix
delegations will be the one that receives the RAAN and SRSN
options. If the MN detects that it can no longer reach this
"primary" relay (e.g., via IPv6 NUD), it can treat this as
a link change event and issue a DHCPv6 Confirm via a new
relay. The server will reply with RAAN/SRSN options via the
new relay which will take the place of the old as the MN's
"primary" relay. 

> So there are arguments either way.
> 
> 
> For the record, I am abstaining from this WGLC, so nothing I just
> said or am about to say should be taken in support or objection, I
> just wanted to sum up for Fred.

Appreciated.

Fred
fred.l.templin at boeing.com

_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg