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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 5 Jan 2007 09:30:27 -0500

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:[email-masked]] 
Sent: Thursday, January 04, 2007 4:25 PM
To: [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 8 Jan 2007 15:15:03 -0800

> protocols, you really have no other options?

I'm not aware of a better alternative, no.  Having the clients
perform the injection of the route is tantalizing, but unrealistic
with the current tools available.

That does leave only the DHCPv6 server as the last remaining party
to perform the injection, and as I think I detailed in past
exchanges I would have preferred my own network behave that way.

But as you and others have pointed out, that will not work so long
as the last leg between your final "router (really)" and "DHCPv6
client" is served by a device that is "a router that doesn't
participate in local dynamic routing protocols."  Eg the "i"
variety of BGP.

> If you were designing this, what would you do?

Probably go insane!

The very requirements you are working with, Bernie, are to effect
dynamic routing in a network without using any heretofore widely
tested and deployed dynamic routing protocol.  It is to me,
madness.  I would not come out of that sane, and it is a
statement to your endurance that you at least appear to have.

It is very much like asking someone to drink water from a tap
without using any of the array of glasses locked behind the
counter, but rather only what you have on your person as you
approached the bar.

I believe our species did not die of thirst before we learned how
to mold glass.  So too did we route.  I seem to recall living
through that era of mankind's digital evolution.  But I also
don't think we would consider the suggestion that cupped hands
might be used to intake liquids to be a keen idea all around,
now that we've already experienced more modern contrivances.

So too do I look with great suspicion upon this architecture
and design.  As a dynamic routing protocol, I find it not
merely wanting, but reminiscent of historic devices that caused
me, personally, ceaseless pain.  The idea of operating a network
with a dynamic routing protocol that looks remarkably similar
to RIP is no more appealing to me than drinking coffee with
cupped hands.

But really what we should talk about is that the problem your
draft solves is symptomatic of a deeper problem.

Which is the existence of "routers" that are beneath the task of
participating in the local routing protocols, but above the task
of merely operating their l2 magics.

Obviously I think there are at least two solutions to that problem,
one of which I might prefer...but I don't wield any power to
influence it, nor do I think any of the rest of us can.

And so I abstain (more vocally than I would have liked).