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]
--------------------------------------------------------------------
