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

["Woundy, Richard" <[e-mail]>]

>Oh, so cableland is sort of 'almost IP' land

I *beg* you to read my email entitled "Background on CMTSs and routing"
before you draw your final conclusions about what 'cableland' is really
like. :(

<http://www1.ietf.org/mail-archive/web/dhcwg/current/msg06938.html>

-- Rich

-----Original Message-----
From: Markus Stenberg [mailto:[e-mail]] 
Sent: Wednesday, February 14, 2007 11:59 PM
To: David W. Hankins
Cc: Woundy, Richard; dhcwg
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegateand
srsn-optiondrafts


"David W. Hankins" <[e-mail]> writes:

.. snipped OSPF<>BGP discussion; I think the used routing protocol
doesn't have significant impact on the mechanics; only extent
(local/global) and the nature (static/dynamic) of the (aggregated?)
prefixes does, and it is affected more by ISP operating policy than
routing protocol choice ..

>> In the worst case, the delegated prefix is reachable from the 
>> Internet through another network path (perhaps unknown to the DHCP 
>> server), but because the delegated prefix is advertised by the DHCP 
>> server, traffic is drawn to the CMTS and is blackholed. It might even

>> be possible for a routing loop to form.
>
> This is the first time I think anyone has suggested that DHCPv6 
> delegated prefixes in this case would be administratively controlled 
> by multiple independent entities.
>
> I understood that if the client was using the same prefix, and 
> connected at a different location, that it would contact the same (or 
> same group
> of) DHCPv6 servers.

Well, in theory, if you are using some sort of multihoming approach from
two ISPs, it could be possible for you to get same prefix from both of
them, with completely different DHCPv6 servers, and have the route
advertised from both ISPs BGP. Then, if one of those ISPs DRs (for
example) went down, you'd want only one route to be globally reachable.

Of course, doing that you're probably acting in the evil PI space and
might as well configure the stuff by hand, and run your own routing
protocol, but I'm not sure if you really need to. If we assume that DR
availability triggers the advertising for that prefix in the AS-land
(and beyond), it would be possible to do reasonable multihoming on the
multihomed systems without anything else than DHCPv6 PD, which would be
nice I suppose. 

Although I have sort of bad feeling about that in general; the PD stuff,
from my point of view, is a pseudo routing protocol if it involves route
injection. Purist in me would prefer just doing the things with real
routing protocols (whatever their names are), but DHCPv6 PD + whatever
route injection solution you prefer seems awfully convenient at times.

> In the various discussions we've had about this, it's been stipulated 
> that one requirement is that the CMTS not be required to participate 
> in any dynamic routing protocol at all.

Oh, so cableland is sort of 'almost IP' land; certainly, it provides
prefixes, but they're not really truly dynamically routable as such, and
aimed only for end user use I suppose. Multihoming example noted above
(as far as I understand the cable requirements) would be impossible with
that sort of system.

I think the contrived multihoming example in and of itself is mostly
academic, as most ISPs wouldn't really _want_ to advertise
non-aggregated PI prefixes for individual customers anyway, but in the
real world they seem to be doing it, albeit with real routing protocols
instead of DHCPv6 PD..

> So the very notion should be impossible.  We shouldn't even be able to

> consider a routing protocol solution to a problem that, I thought I 
> understood, must span networks that do not implement any routing 
> protocols.
>
> The implication being that the CMTS would enter only a local 
> "pseudo-static" route in its table, thanks to this option.  The "real"

> router it was connected to (possibly via other similarly 
> non-dynamically-routing devices) would advertise the prefix's route 
> dynamically (by also participating as a DHCPv6 relay, and being 
> delivered similar options).
>
> Basically, to use DHCPv6 relay chaining to reach a router that does 
> participate in dynamic routing, which either advertises the delegated 
> prefix or relies upon external routing updates to direct it to send 
> routes to the nearest non-dynamic router.
>
> This implication is reinforced by reports from various people in the 
> WG and without, that CMTS operating software does not implement 
> dynamic routing protocols, is not provisioned with sufficient 
> processor power or memory (even to manage a "small" local network), 
> or...since CMTS people are "RF people" and not "IP people"...simply 
> aren't well suited in their implementation of the protocols.
>
> So I'm pretty confused by looking at a routing protocol centric view 
> of solutions to this problem (which I thought was an impossible 
> candidate), and placing upon it criticisms for limitations that are 
> both the same and measurably worse in this DHCPv6-option centric view 
> I've been delivered previously.
>
> So I don't get it.  Either I'm dense (probable), the problem hasn't 
> been explained sufficiently (possible), or there are so many problems 
> and solutions that no one can keep them straight.

I look mostly at the generic problem, and your description of the
cableland is actually interesting for me, as I don't actually know much
about it. I admit it freely, despite number of people actually claiming
me to be either for or against the DOCSIS stuff, while in fact I know
little beyond the acronyms involved :-)

> So, may I make a suggestion?
>
> Let's have another look at draft-stenberg-pd-route-maintenance.
>
> I think at least one thing that has caused us to stumble is that RAAN 
> is intentionally so general-purpose that none of us seem to agree 
> about what it's going to be used for.  The very first things I 
> imagined by reading it were counterpositive to the CMTS environment 
> that's been postulated ever since.

I've rewritten some parts of the section 2.1 based on your comments (and
some others'); I accounted for cableland-style approach, although I
still don't consider it desirable as such, but for sake of completeness
I rewrote bunch of it. I'm still soliciting more input though, and I'll
post the draft-delta here most likely tomorrow. 

The -01 version itself will be posted before the meeting deadline and
I'm still considering where, if anywhere, I really want to talk about it
:-)

> I feel somewhat responsible since my abstention was more vocal than I 
> would have liked.  I don't know how much time I'll have until Q2 '07, 
> I've probably already spent too much time "away from my desk" just 
> writing this (unjustifiably long) email this morning.

Sounds familiar. This feels like a hobby for me too!

Cheers,

-Markus

-- 
"...very few phenomena can pull someone out of Deep Hack Mode, with two
noted exceptions: being struck by lightning, or worse, your *computer*
being struck by lightning."
	- Matt Welsh

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg