Michel, Thursday, April 3, 2003, 3:53:08 PM, Michel Py wrote: >> Margaret Wasserman wrote: >> Bill Fenner, Alex Zinin, Steve Deering, Bob Hinden and I >> (along with a variety of other folks) spent a long time >> discussing this in various fora of the past two years, >> and we have not come up with any way to ensure that the >> internal path will be the shortest path (== site is >> "convex") without requiring that site boundaries be on >> routing area or AS boundaries.
> Why don't you simply make this a requirement? I have heard many times > that issue about the convexity although I don't remember opposition to > coupling the site boundaries with the AS or routing area. You can't oppose it--it just won't work otherwise (RIP being an exception) :) 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. > 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... 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] --------------------------------------------------------------------
