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

From: "Woundy, Richard" <[email-masked]>
Date: Mon, 12 Feb 2007 20:16:34 -0500

>You can't generally inject a route into the routing infrastructure
specifying that the next-hop is someone else. Although I believe OSPF
supports this.

I believe you are correct. According to RFC 2740 (OSPF for IPv6), an
AS-external-LSA may include a "forwarding address"; see sections 3.4.3.5
and A.4.7.

>If the link is down it may be best not to advertise the route.

Agreed. And I believe it would be a real challenge for a DHCP server to
figure this out.

Let's use the DOCSIS example here, assuming the DHCP server delegated a
prefix to a cable modem. First, the DHCP server has to determine whether
the CMTS is up or down. If the DHCP server is participating in the same
OSPF area as the CMTS, it might examine the flooded Router-LSAs,
Network-LSAs, etc. and deduce whether the CMTS is reachable or not. But
different CMTSs sharing the same DHCP server may be located in distinct
OSPF areas, implying that the DHCP server needs to participate in all
relevant OSPF areas.

If the CMTS is up, then the DHCP server has to determine whether the
DOCSIS blade (used to reach the cable modem) is up or down. Again, if
the DHCP server is participating in the same OSPF area as the CMTS, it
might examine the Intra-Area-Prefix-LSAs to deduce whether the CMTS is
advertising reachability to the prefix associated with the DOCSIS blade.
But it is theoretically possible that a single prefix is shared among
multiple DOCSIS blades (in today's cable world we call this "interface
bundling"), so this deduction may not be totally accurate.

If the CMTS is up and the relevant DOCSIS blade is up, the cable modem
may still be unreachable from the CMTS, for a variety of reasons (e.g.
power down, disconnected coax, local management). I am pretty sure it is
impractical for the CMTS to announce reachability to each individual
cable modem using OSPF or any other routing protocol; each CMTS manages
up to thousands or tens of thousands of cable modems today. I suspect
the DHCP server would have to leverage some other means to determine
cable modem reachability.

Now suppose the DHCP server uses OSPF to announce reachability to the
delegated prefix, but the cable modem is unreachable (e.g. CMTS is down,
DOCSIS blade is down, or cable modem is offline). In the best case,
traffic to the delegated prefix is drawn to the CMTS and is dropped, but
the prefix wasn't reachable from anywhere in the Internet. 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.

I haven't played with routing protocols many years. I would advise
validating my analysis with a real routing expert / routing AD.

-- Rich

-----Original Message-----
From: Stig Venaas [mailto:[email-masked]] 
Sent: Sunday, February 11, 2007 12:12 AM
To: Ralph Droms
Cc: dhcwg; Andre Kostur; Ted Lemon
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegateand
srsn-optiondrafts

Ralph Droms wrote:
> Sure ... It *might* be useful.  But, I think we would need to show at 
> least an existence proof for how the DHCP server could inject routing 
> into *any* routing infrastructure.  We can't expect a network that has

> ISIS deployed to also deploy OSPF in parallel with an ISIS-OSPF 
> gayeway if we specify OSPF as the way for a DHCPv6 server to inject 
> routing information.

You can't generally inject a route into the routing infrastructure
specifying that the next-hop is someone else. Although I believe OSPF
supports this.

Another issue is that the DHCP server won't know whether the link to the
customer is up. If the link is down it may be best not to advertise the
route.

Stig

> 
> - Ralph
> 
> 
> On 2/10/07 9:27 PM, "Andre Kostur" <[email-masked]> wrote:
> 
>> Could OSPF/RIP/BGP, or some such similar routing protocol be useful 
>> for this purpose?
>>
>>
>> Regards,
>>  
>> Andre Kostur
>> Incognito Software Inc.
>> Senior Software Design Engineer
>> T: +1(604)678-2864
>> F: +1(604)688-4339
>> E: [email-masked]
>>  
>> www.incognito.com
>>
>> -----Original Message-----
>> From: Ralph Droms [mailto:[email-masked]]
>> Sent: Saturday, February 10, 2007 12:34 PM
>> To: Ted Lemon; Stig Venaas
>> Cc: dhcwg
>> Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and 
>> srsn-optiondrafts
>>
>> How do you propose to arrange for the DHCP server to inject that 
>> routing information, for every possible routing infrastructure 
>> deployment?
>>
>> - Ralph
>>
>>
>> On 2/10/07 3:27 PM, "Ted Lemon" <[email-masked]> wrote:
>>
>>> The way I would prefer to solve this problem is to have the DHCP 
>>> server communicate with the routing system to inject these routes. 
>>> And I would prefer that this *not* be part of the regular DHCP 
>>> packet stream.
>>>
>>>
>>>
>>> _______________________________________________
>>> dhcwg mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/dhcwg
>> _______________________________________________
>> dhcwg mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg

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

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

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 14 Feb 2007 18:08:59 +0000

I'm not sure why we're talking about dynamic routing protocols.

So bear with me while I nitpick and quibble about the topic I'm
not sure we should be debating.  The real content is after the
'===' break below.

> AS-external-LSA may include a "forwarding address"; see sections 3.4.3.5

Huh, I had no idea OSPF could do that.  I doubt the facility is well
used.

But I'm not sure why a modern network operator would use OSPF for
their "non-connected" IGP, so it's rather strange to postulate that
situation.

The general practice I've engaged in is to use OSPF only to distribute
connected routes (subnets attached to routers' interfaces), and then
to use BGP to distribute any static bindings, which are customer
attachments that lack dynamic impetus, or any redistributed routes
from other routing protocol states (such as a unique OSPF protocol
state declared specifically to carry dynamic routes from a
customer).

In summary, the IGP carries prefixes directly connected to interfaces
on routers, and BGP carries prefixes delivered to their remote ends.

Both OSPF and ISIS have trouble scaling to large numbers of routes
(even with areas there are low ceillings), so this works much better.
Minimizing the size of the IGP, and maximizing the number of routes
carried by BGP, which is more efficient at the task of carrying routes
in bulk.

This is not a different protocol from BGP, but the operational practice
is commonly referred to as "iBGP" to differentiate between the task
of carrying routes internally or externally.

I'd honestly be pretty suprised if there were a single operator today
that used BGP only for the aggregates they advertise externally, and
consequently relied entirely upon OSPF (or even ISIS) for every
more-specific route.

So I'd also be pretty surprised, were I still an operator, if my
IETF representatives came to any conclusions about how a system
would work in my network based upon the principle of OSPF networks
stuffed to the gills.

> OSPF areas, implying that the DHCP server needs to participate in all

IFF you use "i"BGP, you require only one TCP connection over which
to process BGP commands.  Most operators would probably want more
than one, and probably would also want more than one DHCPv6 server
to perform the announcements, preferrably in different geographic
locations.

There are already quite appropriate tools in BGP router
implementations for limiting the number of routes advertised to
neighbors that don't wish to (or can't) carry a full table.

I see no reason why a single generic filter can't be made to
define "routes for CMTS's in facility X".

> In the worst

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.

===  What was the question again?

As I said, I'm not sure why we're talking about dynamic routing
protocols.

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.

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.

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.

He's already done a lot of great work towards enumerating the problems
and solutions.  If we could all take a moment to make sure they're all
in there, and if Markus and Ole are willing, I'd like to get a handle
on 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.

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

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 15 Feb 2007 13:59:13 +0900

"David W. Hankins" <[email-masked]> 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.
>

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

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

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

> 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