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

["Woundy, Richard" <[e-mail]>]

>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:[e-mail]] 
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" <[e-mail]> 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: [phone]
>> F: [phone]
>> E: [e-mail]
>>  
>> www.incognito.com
>>
>> -----Original Message-----
>> From: Ralph Droms [mailto:[e-mail]]
>> 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" <[e-mail]> 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
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/dhcwg
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg


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

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