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

David:

In a multiple relay (well, really router since we're talking about
routing) situation, the routers need to have some protocol to
communicate with each other and it is assumed that is how that is
handled. This is no different than the initial lease (which likely is
communicated via only one path); it is no different than other learned
routes. If you have multiple partners participating, you need to have
some way to distribute the information between them. This is left to the
routers and is not up to DHCP to do, IMHO.

Unless you have the DHCP server itself participate in the routing
protocols, you really have no other options?

If you were designing this, what would you do?

- Bernie

-----Original Message-----
From: David W. Hankins [mailto:David_Hankins@isc.org] 
Sent: Thursday, January 04, 2007 4:25 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegateand
srsn-optiondrafts

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.

Thomas had a complaint about the use of the word 'reliable',
which I understand to have been cleared up in the edits that
brought SRSN (since that bit was edited to reference the new
draft).

I think it was only us two who said something, so that just
leaves me.

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).

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.

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.

Overall, I'm a critic of the madness rather than the method.  The
view these discussions have afforded me into this sort of madness
makes me rather glad I never worked for a Cable ISP.

I can't imagine actually craving the situation where I ask a "router"
to perform its duty without using a formal routing protocol, because
the alternative is too horrid to imagine.  In networks I have worked
at, we've always had the opposite problem: lack of adequate routing
protocol support being the horror we wished to escape [1].

But there you have it, and I accept it.  That's where these CMTS
operators are.

I cannot speak in support, for then I am helping lock the cage they
are trapped in, even if they say they like the decor.  I cannot
speak in objection, for then I am holding from them a coping
mechanism.

[1] On request, I can supply my copy of "OSPF", a song set to the
    tune of "YMCA" by _The Village People_.  It was writ, and oft
    sung over beer, by a group of people who had the misfortune of
    working with me for a company with ~300 Ascends (and we RMA'd
    30 a month).

    There is, of course, a much longer (but equally irrelevant)
    backstory behind its creation.

-- 
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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg