Michel, > Agreed. I don't like the word "area" myself in this context; I was > simply quoting Margaret's words.
Well, it's not that I don't like the word "area" here, in fact it would not be unreasonable to assume that people would want to map sites to areas... > 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. Sounds really bad. Mutual redistribution is a very risky thing, but if done properly does not need eBGP... anyways, it's a mess and we don't want the architecture to encourage this... > 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. I don't think a "better" definition is going to help here. No matter what we say a site should be, the day people start deploying them we'll hear back from the customers smiling at the definition and giving us their reasons why they have to ignore it (e.g. my organization has just become a department within a bigger one, what should I consider a site now?) Again, there is a disconnect between the driving factors defining site boundaries and those defining routing hierarchy elements. > 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. I think there might be some confusion here. Even if site support was introduced into routing, SL topology and global one would be congruent (making them non-congruent would be too much complexity), which means that the path taken by packets that belong to a connection within a site would be the same regardless of whether SL or public addresses are used. So, SL do not add anything here at all. > 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. If you are interested in convexity as a feature (rather than a requirement to make SLs work), we already have a similar notion in routing, but it is applied to areas and AS'es--for example, OSPF area are logically convex, i.e., traffic between hosts within the same area will be contained within the area because routers prefer intra-area routes over inter-area ones. You don't need the notion of sites here. > 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. I guess we disagree on the "simplifies" part here :) Alex -------------------------------------------------------------------- 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] --------------------------------------------------------------------
