Alex, > Alex Zinin wrote: > The problem or rather inconvenience with tieing site > boundaries and area/domain boundaries is that they > are driven by different factors. Imagine, for instance, > that your site that is currently implemented as an OSPF > area is growing so big that you need to split it into > multiple areas to give your routers a break. Because > your site boundaries are driven by non-routing > considerations (you just want your network to continue > working as it used to), you don't want to split the site > into two, so what you end up with is removing that big > site from the OSPF domain in a separate one and splitting > it into its own areas, while normally you would just have > one more area in the OSPF domain. Operationally, this > might be a headache.
Agreed. I don't like the word "area" myself in this context; I was simply quoting Margaret's words. There are plenty of other cases like this, for example using two different IGPs as the result of a merger-never-finished-the-cleanup or related; I have seen a site where half of it was EIGRP the other half OSPF with mutual bidirectional redistribution and eBGP in the middle. :-( Mmmm thinking about it, :-) job security. Anyway, I suggested earlier that the site boundaries should be the administrative control boundaries of the organization. It might not be the correct wording, but my feeling is that we could come with some text that will detail the position of site boundaries. I have made the point earlier many times that the definition of "site" is ambiguous and/or imprecise, there is some geographical connotation attached to the word, we need a good definition anyway. >> This is the way I would do it anyway. I understand that we >> should not put restrictions when there is no need for them, >> but if putting a restriction allows something to work there >> is nothing wrong with it. > I don't think this is _the_ problem. This only contributes > to the list of complications. Also count modifications to > RIB, FIB management, the forwarding process, making pings, > traceroutes, etc site-aware... It's not impossible, in fact > we know exactly how to do this, it just that complexity adds > up to one side of the equation, and you really want to avoid > extra complexity in routing and below... I agree, but the other side of this coin is that if the feature is not implemented in the architecture it will be implemented by the configuration at the site. In other words, if as a site administrator I am not happy about the way the site-local traffic flows I am going to tweak it using route-maps, prefix-lists, route tags and whatever I feel like doing for my intra-site traffic engineering. Each site will end up being configured differently. Although there still is a lot of work to be done on the topic, I think that the convexity of the site is a good idea to incorporate in the architecture. In short: - If site convexity is not built-in the architecture, it might or might not work depending on implementation, network topology, etc. This will lead in many cases to manual policy routing config to make it work the may it should. - If site convexity is built-in the architecture, the only case where it would require manual policy routing config is if the site administrator wants to break convexity. I can't think of a reason but I'm sure they are some valid ones. As some others have commented, IPv6 is not only IPv4 with more bits. The issue of "automatic site convexity" is definitively a pain to implement in router code, but is also a feature that simplifies the life of network administrators and as such a factor of success for IPv6. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
