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

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

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

We have customers with pretty similar IPv4 service today. Let me more
precise about what I mean:

> Here is my expected (business) customer experience. The customer
> orders
> broadband service from the cable operator, and provides the PI prefix.

In today's world, most business customers would get an IPv4 subnet from
us, but some customers might bring their own IPv4 subnets. In the latter
case, we may have to reconfigure our external BGP routers to announce
the customer's subnet to the rest of the world (depending on whether we
use "white lists" or "black lists" for eBGP subnet reachability); this
extra work is part of the reason why customer-owned subnets would be
strongly discouraged (customer-owned subnets also cause route table
growth in the default-free backbone, which also isn't good). In any
case, we would reconfigure the CMTS (manually) to expect the customer
subnet to be announced by the "cable router" at the customer premise via
RIP.

> 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

Today, we would install a "cable router" (a cable modem with router
functionality) at the customer's premise, with the customer's IPv4
subnet and RIP routing configured by the cable operator (either manually
in advance, or via TFTP configuration download to the cable router).

> black box is connected and turned on, and now the customer has  
> broadband IPv6 Internet service.

Well, they would have v4 service today, not v6. :)

The "cable router" at the customer premise would boot on the DOCSIS
network, the CMTS and cable router would exchange RIP messages, and the
CMTS would pass the customer subnet received from RIP (and expected from
the customer according to its configuration) into the IGP, which would
ultimately be advertised to the Internet at large.

A portion of these customers do some form of multi-homing, from
anecdotal evidence, but that's harder for us to know about.

-- Rich

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

On Feb 15, 2007, at 1:02 AM, Woundy, Richard wrote:
> 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)

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?

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

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?

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

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

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Feb 2007 02:14:11 -0700

What you're saying is actually pretty close to my picture of what was  
going on in an IPv4 network.   Including the grottiness of having to  
deal with the customer's special IP address range that's alien to  
your network.   And clearly we would like the end result of what we  
do to be that the grottiness is eliminated, you can provide them with  
the service they want, they can do multihoming, and it all works with  
no pain, so that there's no disincentive to give the customer what  
they need, and what the customer gets is convenient and reliable.

What I question in the scenario you are describing as your present  
reality, versus the scenario you are proposing for DHCPv6, is whether  
or not what is being proposed actually makes things better, or  
whether it just makes things different.   And that's why I keep  
asking questions.   The reason I call your IPv6 PD scenario  
"contrived" is because it doesn't match my understanding of how  
things are done now, and I don't think it's a natural place to go  
from where we are now.

I think that it would be really good if the interested parties could  
sit down together sometime when we're in Prague and talk about  
this.   Possibly part of the problem is that since I wasn't in San  
Diego, I am missing some state that would make it clearer to me why  
you went down the route that led us to our recent lack of consensus.