Subject: [dhcwg] Delegated prefix managed by multiple entities

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 15 Feb 2007 00:32:46 -0500

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

Please allow me to use a potentially controversial example in this
reply.

Suppose a business entity/organization approaches both a cable operator
and an alternative broadband provider (e.g. a telco) for multihomed
Internet connectivity, bringing their own Provider Independent prefix
per <http://tools.ietf.org/wg/ipv6/draft-hain-ipv6-pi-addr-10.txt> and
<http://tools.ietf.org/wg/ipv6/draft-hain-ipv6-pi-addr-use-10.txt>.

Note: please do not use this example as an endorsement of PI addressing.
The second draft enumerates why PI addressing is difficult for service
providers.

Anyway, suppose the cable operator uses DHCP-PD to send the PI prefix to
the customer's cable modem, for broadband service over DOCSIS. Further
suppose that the PI prefix is injected into the IGP by the DHCP server.
The alternative provider sets up routing as appropriate to their
environment. At this point, traffic to the customer's PI address on the
cable operator's backbone would be forwarded to the CMTS (and to the
CM), traffic on the alternative provider's backbone would be routed over
the alternative broadband network, and general Internet traffic would be
routed to either the cable operator or the alternative provider based on
routing topology and preferences in various national/worldwide
backbones.

Now suppose that the customer's cable modem goes offline. From what I've
seen, we don't have a mechanism for the DHCP server to figure out very
quickly that the cable modem is offline, so the PI prefix remains in the
cable backbone IGP routing tables. That means that cable network traffic
directed to the customer's PI address will still be routed to the CMTS,
where it will be blackholed. Some general Internet traffic to the PI
address will also be blackholed.

If the CMTS is responsible for PI prefix injection into the IGP, then
the CMTS could detect the cable modem going offline in minutes, if not
in seconds, and remove the PI prefix from the IGP routing tables. Then
cable network traffic (and some Internet traffic) that would have
otherwise been blackholed at the CMTS, could be routed to the alternate
broadband provider's network -- thus enabling a highly available network
connection for the multihomed organization.

This is why having a "stale route" in the IGP can be an issue for
multihomed customers.

I think there are some other variations on the multihomed-customer theme
(e.g. multihomed to the same provider using different access networks)
that could be relevant here.

-- Rich

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 1:09 PM
To: Woundy, Richard
Cc: dhcwg
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegateand
srsn-optiondrafts

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.

On Mon, Feb 12, 2007 at 08:16:34PM -0500, Woundy, Richard wrote:
> 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.

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 
> relevant OSPF areas.

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

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

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Feb 2007 23:03:37 -0700

> address will also be blackholed.

Richard, no offense, but this looks like a completely contrived  
example.   Why would you ever do that?   Does the routing  
infrastructure require you to do it?   Is it the easiest, most  
failsafe way to do it?   What if your DHCP server is accidentally  
configured so that it hands your customer the wrong prefix?   Why  
wouldn't the customer simply hard-code their provider-independent  
routes in their border gateways?

Why isn't the routing infrastructure capable of handling this sort of  
problem without the assistance of DHCP on any level?   It seems to  
work okay in IPv4-land.   Or am I just naive about this?

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 15 Feb 2007 16:08:39 +0900

> routes in their border gateways?

I think DHCP-PD based multihoming is not contrived example because it makes
customer life easier; they don't NEED to run routing protocol, nor have
manual configuration for that matter and the stuff 'just works' for some
definition of works (inbound traffic winds up at their RR; how RR sends
stuff out is another matter).

Given RAAN, or DHCPv6 traffic snooping at the first-hop delegating router
(aka DHCPv6 relay), you can also have relay responsible for pushing this
routing information. I find the server pushing routing state for someone
else somewhat distasteful, but possibly it's valid in some cases.

You need routability for the prefixes handed via PD; whether the route is
valid for the lease lifetime, or only when the interface is really
reachable (information not always available, subject to crashes somewhere
on the path, etc) is a matter of preference..

Cheers,

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Feb 2007 00:23:33 -0700

> stuff out is another matter).

Even the way you say this tells me that it's contrived.   A halfway  
solution with serious reliability concerns (because it would be so  
easy to misconfigure their border router from the DHCP server) is not  
something you can describe as making customer life easier.   I don't  
mean you're wrong, but if we're only talking about half the solution,  
let's talk about the other half before we start using this as a user  
story.

> else somewhat distasteful, but possibly it's valid in some cases.

I am not strongly advocating this position - it's just the one that  
makes the most sense to me as a network engineer, but I am _not_ a  
network engineer at an ISP, so I'm not claiming I'm right about  
this.   I'm just asking you to tell me why I'm wrong, and hoping I'll  
hear something I can believe.   I'm perfectly fine with the DHCP  
server communicating with the relay agent if that's the right thing  
to do, although nobody's said anything so far that makes me think  
that's the case.   I don't care what's distasteful, and indeed I  
think it's an unfortunate choice of words.   I care what is reliable,  
in the sense that it works consistently, that it's clean to  
implement, easy to maintain, and difficult to configure in a way that  
creates heisenbuggy instability (complete malfunction is fine because  
that's quickly noticed and usually easily diagnosed).

> on the path, etc) is a matter of preference..

Clearly the latter is preferable to the former, all other factors  
being equal.

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 15 Feb 2007 02:37:22 -0500

> Clearly the latter is preferable to the former, all other factors  

Being a network engineer, I have to agree with Ted here.  Especially 
in the multi-homed case, anything other than the latter solution is 
broken by design.  If you want to multi-home, you have to expect to 
run a real routing protocol on the customer's router.  I would be 
strongly against any attempt to piggyback routing on top of DHCP.