Brian is right, the approaches for dealing with independent routing multiple scopes are fairly straight forward. At the same time I suspect that the majority of sites that will use SL, will simply treat them as a set of prefixes to be passed around in their IGP. Since it will require both parties to misconfigure BGP to get those prefixes leaked between enterprises, they will feel more secure about using them (note: I did not say they would have better security, just that they would 'feel more secure'). For this simple reason we need to meet the network manager at his comfort zone and provide a fimilar tool.
Yes that appears to create a problem for multi-party apps, but the problem of disconnectedness exists without a defined SL. Since SL makes it clear that there are places where the network will be disconnected, there should be a note to application developers stating what the pitfalls are, along with any known work arounds. Having a clearly defined prefix should make that task easier. Tony > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:owner-ipng@;sunroof.eng.sun.com] On Behalf Of Brian Haberman > Sent: Thursday, October 31, 2002 7:41 AM > To: [EMAIL PROTECTED] > Subject: Re: Default site-local behavior for routers > > > Margaret Wasserman wrote: > > >> What doesn't really exist is the filtering of prefixes > being put into > >> route exchange messages based on an arbitrary index (zone id). > >> > >> The other big issue is how the routing table(s) are built and > >> managed. That can be a big hit on memory/storage space. > > > > > > Brian, could you elaborate on these things? > > Sure. One of the issues that I had to deal with in the > scoped addr arch was how to represent the concept that > multiple RIBs are needed to support site-locals. The > conceptual model is that you have a RIB for globals and RIB > for each unique site-local zone id in the box. > > These tables can be implemented in several ways. One way > would be to add a zone id entry to a monolithic RIB. This > means that uniqueness is based on (prefix,zone id) rather > than just on prefix. Another way would be to have separate > RIBs (perhaps as an array). Then the lookup entails finding > the table that matches the incoming zone id and then the > prefix in that table. > > So, right there we have a more complex indexing structure, > but it is not too bad. It looks similar to how some products > do VPN support. > > Another hit is taken in each routing protocol. When the > protocol builds its advertisement packet, it must do this > selectively. The zone id of the outgoing interface is > retrieved and the routing protocol then builds its > advertisement using the global RIB and the site-local RIB > corresponding to the zone id. This process has to be done > for each interface. > > Does anyone want to hear the gory details on the forwarding > plane or is the explanation in the scoped addr arch enough? > > Brian > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
