Subject: RE: [dhcwg] Delegated prefix managed by multiple entities

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 15 Feb 2007 03:02:57 -0500

>Richard, no offense, but this looks like a completely contrived
example.

Maybe you can help me understand what part I "contrived"? Business
customers want multihoming? (they do) Cable modem going offline?
(unfortunately they do) The PI prefix remaining as a "stale route" in
the IGP routing table because the DHCP server can't detect the modem
going down? (tell me how *not* to make this happen)

The point of the example is that routing will be "wrong" until something
detects that the cable modem is down. If the DHCP server can detect the
cable modem going offline fairly quickly, then this issue is mitigated.
Maybe someone can explain to me how the DHCP server can detect this?

>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 would a customer truly worried about either of these cases be a
candidate for DHCP-PD at all?

I'm talking about intermittent connectivity causing a routing issue, and
you're talking about an operational blunder. This doesn't seem like a
fair comparison, even within this group. For example, if there is a
temporary network outage, I would expect DHCP failover to help us
maintain continuous DHCP operation, right? If I misconfigure a DHCP
server with the wrong subnet information, should I still expect it to
function properly in my network? If I am worried about DHCP server
misconfiguration, shouldn't I just number all of my computers by hand?

Here is my expected (business) customer experience. The customer orders
broadband service from the cable operator, and provides the PI prefix.
The cable operator sends a black box (cable modem) that is supposed to
connect to the customer's network and to the cable/coax network. The
black box is connected and turned on, and now the customer has broadband
IPv6 Internet service.

The customer orders broadband service from an alternate broadband
provider, who provides their own black box for service. Traffic from the
Internet to the customer arrives over both access networks, as
appropriate.

If there is an issue with cable access, then all customer traffic is
routed over the alternate broadband provider. If there is an issue with
alternate access, then all customer traffic is routed over the cable
network.

Why isn't that a reasonable customer expectation?

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

In "IPv4-land", routers inject routes into the IGP based on local state
and configuration. They learn about routes originating from other
routers through the IGP. Then they use all of that information to make
traffic forwarding decisions.

Suppose a router in Nominum has an Ethernet interface that has been
turned off, and you turn the Ethernet interface on. What happens? The
local router will detect that the Ethernet is up, and will tell the
other remote Nominum routers via IGP (e.g. by flooding) that the
Ethernet's IP subnet is reachable through it. If the Ethernet cable is
unplugged, the local router will withdraw the Ethernet's IP subnet from
the IGP, and the other remote routers won't forward that Ethernet's
traffic to the local router anymore. The reachability of the Ethernet's
IP subnet is announced by the local router.

If there are two routers attached to the same Ethernet, then they both
independently announce to the IGP that each can reach the Ethernet's IP
subnet. The "magic" of routing is that remote routers will forward that
Ethernet's traffic to the local router that is "closer". If one router's
Ethernet interface goes down, then that router withdraws the Ethernet IP
subnet from the IGP, and all of the remote routers forward that
Ethernet's traffic to the *other* local router, automatically.

Do you agree that this is how routing works in "IPv4-land" today? In
fact, this isn't really different from how routing works in IPv4 cable
networks, either.

Now suppose that someone wanted to change how things work, so that some
"server" (DHCP or otherwise) notifies the remote routers through the IGP
about whether the Ethernet's IP network is reachable through one or both
of the local routers. Is that how you run *your* network today? How
would this "server" know which local router's Ethernet interface is
down, and which is up? If the server gets it wrong, then part of the
Nominum network isn't going to be able to reach the Ethernet network
anymore; some routers will forward traffic to the local router whose
Ethernet interface is down.

The point in the Nominum network example is that the Ethernet edge
router knows whether the Ethernet is reachable or not. Not some "server"
elsewhere in the network.

In the DHCP-PD/cable world, the CMTS knows if the DOCSIS network is
reachable or not. The DHCP server isn't going to know that the DOCSIS
network, or some individual cable modem, is unreachable. It's the same
routing principle.

My root concern is that third-party route injection by the DHCP server
isn't going to work correctly in some pretty reasonable network
impairment cases (and multihoming). Please consider this when proposing
alternative-to-RAAN solutions. That's all I ask.

-- Rich

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Thursday, February 15, 2007 1:04 AM
To: Woundy, Richard
Cc: dhcwg
Subject: Re: [dhcwg] Delegated prefix managed by multiple entities

On Feb 14, 2007, at 10:32 PM, Woundy, Richard wrote:
> 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.

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?

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Feb 2007 01:15:06 -0700

> going down? (tell me how *not* to make this happen)

What seems contrived to me is doing prefix delegation in a case where  
you have a provider-independent prefix.   Why wouldn't you just use  
straightforward border routing protocols in this case?

> black box is connected and turned on, and now the customer has  

I think this is the crux of why we are thinking about this  
differently.   As a customer, there is no way that I want you  
configuring my router's addressing from a DHCP server if I have a  
provider-independent prefix.   I realize that that seems backwards  
from the perspective of the ISP, but the customer only has one P-I  
prefix, so they don't mind configuring it manually.   Or so I would  
naturally assume, absent some reason to assume differently.

When you say that this is your business customer experience, does  
this mean that you have actual customers (that is, people purchasing  
service from ISPs, not ISPs) doing this right now who asked for and  
are happy with this solution?   Or is this a use case that's still  
theoretical at this stage?

> fact, this isn't really different from how routing works in IPv4 cable

Yes, this is exactly how I think routing works in IPv4-land today.    
That is, there is no DHCP server involved at all.

---

From: Damien Neil <[email-masked]>
Date: Sat, 17 Feb 2007 14:10:50 -0800

> naturally assume, absent some reason to assume differently.

This doesn't strike me as being different from any other use of  
reservations or fixed-address assignments in DHCP.  Why wouldn't the  
provider want to centralize management of router address  
configuration on their DHCP server?  And why would the user expect to  
have any configuration access to the provider-supplied router?   
There's a DSL modem sitting on the floor by me; I certainly don't  
expect to be able to configure its address, regardless of whether  
that address is statically or dynamically assigned.

           - Damien

---

From: Ted Lemon <[email-masked]>
Date: Sat, 17 Feb 2007 15:32:47 -0700

On Feb 17, 2007, at 3:10 PM, Damien Neil wrote:
> reservations or fixed-address assignments in DHCP.  Why wouldn't  
> the provider want to centralize management of router address  
> configuration on their DHCP server?  And why would the user expect  
> to have any configuration access to the provider-supplied router?   

Because I think a multihoming customer really wants full  
configuration control of their end of things - relying on someone  
else's DHCP service seems like a variable that you wouldn't want to  
do.  Ask Chris what his attitude about this would be - I'm just  
speculating.