Re: [dhcwg] dhc wg last call on agentopt-delegateand srsn-optiondrafts
"David W. Hankins" <David_Hankins@isc.org> Wed, 14 February 2007 18:09 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOZ5-00020E-PO; Wed, 14 Feb 2007 13:09:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOZ4-000200-UB for dhcwg@ietf.org; Wed, 14 Feb 2007 13:09:10 -0500
Received: from mx.isc.org ([2001:4f8:0:2::1c]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHOZ4-0007zY-Cf for dhcwg@ietf.org; Wed, 14 Feb 2007 13:09:10 -0500
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id 051F1114029; Wed, 14 Feb 2007 18:09:06 +0000 (UTC) (envelope-from David_Hankins@isc.org)
Received: by farside.isc.org (Postfix, from userid 10200) id A2FFDE60C7; Wed, 14 Feb 2007 18:08:59 +0000 (UTC)
Date: Wed, 14 Feb 2007 18:08:59 +0000
From: "David W. Hankins" <David_Hankins@isc.org>
To: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegateand srsn-optiondrafts
Message-ID: <20070214180859.GF63508@isc.org>
References: <EF2F0EC839870F43A6637360BC12ABD4010B0EDE@PACDCEXCMB05.cable.comcast.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <EF2F0EC839870F43A6637360BC12ABD4010B0EDE@PACDCEXCMB05.cable.comcast.com>
User-Agent: Mutt/1.4.2.1i
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
Cc: dhcwg <dhcwg@ietf.org>
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Errors-To: dhcwg-bounces@ietf.org
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 dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- RE: [dhcwg] dhc wg last call on agentopt-delegate… Bernie Volz (volz)
- Re: [dhcwg] dhc wg last call on agentopt-delegate… David W. Hankins
- RE: [dhcwg] dhc wg last call on agentopt-delegate… Woundy, Richard
- Re: [dhcwg] dhc wg last call on agentopt-delegate… David W. Hankins
- Re: [dhcwg] dhc wg last call on agentopt-delegate… Markus Stenberg
- RE: [dhcwg] dhc wg last call on agentopt-delegate… Woundy, Richard