Subject: RE: [dhcwg] Background on CMTSs and routing

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

The stale route would break routing to a multihomed customer (cable +
non-cable) using PI addresses, for example.

-- Rich

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Thursday, February 15, 2007 12:05 AM
To: Woundy, Richard
Cc: dhcwg
Subject: Re: [dhcwg] Background on CMTSs and routing

On Feb 14, 2007, at 10:01 PM, Ted Lemon wrote:
> I guess if the lack of a route to the CMTS is discovered high in
> the network hierarchy,

This was poorly phrased.   What I meant is that if the lack of a  
route to the customer is discovered by the CMTS and quickly  
propagated into the network, there may be some minor benefits to  
that, but I don't find them particularly compelling.

_______________________________________________
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: "Woundy, Richard" <[email-masked]>
Date: Thu, 15 Feb 2007 04:36:18 -0500

>if an "end-to-end" DHCP infrastructure is wanted, I suppose one could
use a DHCP proxy on the edge device. server downstream, client upstream.
that should take care of the state maintenance issues that came up with
the RAAN proposal.

Ole, please allow me attempt to re-state. And allow me to inject a
"static versus dynamic routing" component as well.

In normal operation, the customer premise router (requesting router)
requests a prefix from the ISP edge router (delegating router), similar
to RFC 3633. If the ISP edge router does not know the prefix / lifetime
for the requesting router, then ISP edge router uses "proxy DHCP-PD" to
request a prefix from the DHCP server on behalf of the customer premise
router. The ISP edge router may already know this information based on a
previous boot cycle of the customer premise router.

Once the ISP edge router knows the prefix / lifetime, then the ISP edge
router could either (1) statically inject the delegated prefix into the
IGP on behalf of the customer premise router, or (2) set up a routing
protocol adjacency (RIP, OSPF/IS-IS, BGP) with the customer premise
router, so that when the ISP edge router learns of the delegated prefix
from the customer premise router, it can redistribute the prefix into
the IGP of the ISP. The ISP edge router then responds to the PD request
of the customer premise router.

The customer premise router behavior would depend on the ISP edge router
behavior, which would be commmnicated in the DHCP-PD message. If the ISP
edge router expects a routing protocol adjacency with the customer
premise router, then the customer premise router needs to set up a
routing protocol adjacency (RIP, OSPF/IS-IS, BGP) with the ISP edge
router that advertises reachability to the delegated prefix.

If the ISP edge router statically injects the delegated prefixes into
the IGP, then the ISP edge router must remove those prefixes whenever it
discovers the associated customer premise router is unreachable.
Otherwise, the ISP edge router will determine this by some dynamic
routing protocol.

Basically, this allows for "static routing" and "dynamic routing",
without using DHCP as a routing protocol in either case.

Based on the email list discussions so far, this leaves a few unanswered
questions, that seem tractable:

1. When would "static routing" be acceptable? Single-homed customers
only? Or according to the decision of the service provider?

2. Should "static routing" versus "dynamic routing" setup be managed at
the ISP edge router, or in the DHCP server?

3. How much effort is required to set up a routing adjacency for the
"dynamic routing" case (e.g. matching routing protocol timers)?

-- Rich

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] 
Sent: Thursday, February 15, 2007 3:13 AM
To: Ted Lemon
Cc: Woundy, Richard; dhcwg
Subject: Re: [dhcwg] Background on CMTSs and routing

> On Feb 15, 2007, at 1:02 AM, Ole Troan wrote:
>> route injection from the edge does require state in the L3 edge 
>> device. the act of doing prefix delegation does create this state and

>> it is very convenient to take advantage of that so that the edge 
>> router can inject the route based on PD state.
>>
>> since a DHCP relay should (at least architecturally) be stateless, 
>> then a DHCP relay and edge route injection are mutually exclusive.
>
> So do you have any thoughts about how we should actually do this?    
> What you're saying implies to me that the DHCP server doing the PD
> should somehow contact the correct router, which might be identified  
> by the relay agent, but that the relay agent oughtn't to do anything  
> more than identify which router to talk to.   But I am afraid I may  
> be reading too much into what you've said.

in the edge route injection case (there are many others), which if I
remember correctly is described loosely in RFC3633, the delegating
router must be the first L3 device. so in that case DHCP is kept only on
the edge of the ISP network.

a backend provisioning system can be used. the DHCP server/delegating
router on the edge device can synthesize DHCP replies based on
information from e.g a RADIUS server.

if an "end-to-end" DHCP infrastructure is wanted, I suppose one could
use a DHCP proxy on the edge device. server downstream, client upstream.
that should take care of the state maintenance issues that came up with
the RAAN proposal.

cheers,
Ole

---

From: "Woundy, Richard" <[email-masked]>
Date: Mon, 19 Feb 2007 14:32:21 -0500

>Just to clarify, I never suggested that this was a way to do things,
rather the contrary.

Please accept my apologies if I created any confusion about your
positions on this topic.

-- Rich

-----Original Message-----
From: Stig Venaas [mailto:[email-masked]] 
Sent: Monday, February 19, 2007 7:54 AM
To: Woundy, Richard
Cc: dhcwg
Subject: Re: [dhcwg] Background on CMTSs and routing

Woundy, Richard wrote:
[...]
> Stig raised the possibility that perhaps the DHCP server could use 
> dynamic routing protocols (particularly OSPF) to inject routes for 
> delegated prefixes. I took this idea seriously, thought about the 
> implications, and raised some concerns about whether "stale routes" 
> could/would be injected by the DHCP server. While I used an OSPF 
> example, the same concerns apply to iBGP route injection -- the DHCP

Just to clarify, I never suggested that this was a way to do things,
rather the contrary. What I said was that route injection by the DHCP
server generally is not possible (as also Ole mentioned later), but
pointed out that there was a theoretical possibility with OSPF. Then I
also pointed out the issue with "stale routes".

I brought this up in response to Ralph and someone else talking about
the possibility of the DHCP server doing injection. My view is that
injection by the DHCP server is not the way to go.

Stig

---

From: "Woundy, Richard" <[email-masked]>
Date: Mon, 19 Feb 2007 14:42:31 -0500

My apologies for my error.

I wish I had just said I didn't understand your use case; I thought I
said that in my email, but looking back I see I didn't. :(

-- Rich

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Thursday, February 15, 2007 10:12 AM
To: Woundy, Richard; dhcwg
Subject: RE: [dhcwg] Background on CMTSs and routing

> To be fair, Fred Templin has some other use case in mind, in which the

> relay agent is NOT a router, 
> <http://www1.ietf.org/mail-archive/web/dhcwg/current/msg06913.html>.

No - the relay agent is a router in my use case; it's just selective
about which routes it will inject into the IGP. But I'll agree that it
is a different use case - I didn't even know what CMTS stood for before
seeing some of the messages on this list.

Fred
[email-masked]