Re: Fwd: Re: note from the iesg plenary

["Brian Haberman" <haberman@nortelnetworks.com>]

Hi Margaret,
     Let me take a crack at answering some of these.

Margaret Wasserman wrote:

> >>(1)  The current addressing architecture defines all routable
> >>unicast addresses to include a 64-bit identifier.  Does that mean
> >>that it is reasonable for a router to only look at the first 64
> >>bits when making a routing decision?  Or should routers still treat
> >>these addresses as CIDR-like?

They still need to be treated as CIDR-like.  A longest prefix match
lookup may find a 16-bit or 48-bit entry, especially if the address
being looked up is outside that router's domain.

> >>
> >>(2) Site-local routing is particularly confusing on a site-border router.
> >>I don't know if anyone has really implemented one, but it seems likely
> >>that it will need to have multiple routing tables (one global table
> >>and one per attached site).  Even an intra-site router may need two
> >>conceptual routing tables (one global, one site).

I have begun implementing one.  And it does require having multiple
"conceptual" routing tables.  The reason for this is that on a site
boundary router, the zone IDs per interface determine which interfaces
are in each zone.  Since the site-local addresses do not contain any
of this information, the routing table needs to enforce the separation.

For example, a router that is a border between site A and site B may
find that it has entries for FEC0:0:0:ABCD:: in both sites.  If that
is the case, they can only be distinguished via the zone IDs assigned
to sites A and B.  This can be implemented as either separate route
tables per site or by including the zone ID in the route table
lookup.

> >>
> >>Also, some of the scoped addressing architecture assumptions only work
> >>if sites are "convex" (Steve's word).  Unfortunately, that assumption
> >>is not yet documented and the word "convex" has no currently defined
> >>meaning in terms of routing -- even though we understand what it means.
> >>Also, topologies change.  So, what happens if a site becomes
> >>"concave"?

So, I am partly at fault for not getting that text into the architecture
draft.  My working definition for a convex site is that for any two
points within the site, the shortest path between the points never
leaves the site.

As for topology changes, an event that turns a site from convex to
concave can be treated in the same manner as an event that fragments
a network.

> >>
> >>There is wording in a variety of IPv6 specs talking about how
> >>routers should (and shouldn't) pass site-local information, but I haven't
> >>looked to see if the current IPv6 routing protocols reflect this
> >>information (or even know that they may pass site-local routes).

To my knowledge, none of the v6 routing protocol specs have been
updated to reflect the information in the scoped address architecture.
I think that once the architecture is solidified, we can go and look
to see what needs to be done in the routing specs.

> >>
> >>Since there doesn't have to be a one-to-one mapping between sites
> >>and ASes, I need to figure out if there are any problems with propagating
> >>site information when a site contains two (or more) ASes or when two
> >>(or more, or parts of multiple) sites are contained in a single OSPF
> >>AS.  I have no clue how this would work yet...
> >>
> >>(3) IPv6 anycast is substantially different from the anycast hacks
> >>currently used in IPv4.  One big difference:  a global IPv6 anycast
> >>address would (probably?) not appear to be inside of anyone's AS.
> >>I don't know if this causes problems, as I haven't had time to look
> >>at how OSPF would handle a host route injection for a router outside
> >>the AS.

From discussions I have had, I don't think there is much interest
in global anycast.  The proposals I have heard have been for using
anycast within domains, so that the anycast address gets aggregated
into the global prefix for that domain.

> >>
> >>And, despite the fact that we are specifying the use of site-local
> >>anycast addresses in documents (like Dave Thaler's DNS stuff), we
> >>don't actually know what a site-local anycast would look like.  The
> >>latest verbal possibilities from Steve seem to indicate that we might
> >>artificially reserve one of the subnet numbers (all zeros or all
> >>ones?) as an area to assign site-local anycast addresses.  If so,
> >>the routing might be okay...?
> >>
> >>However, the IPv4 stuff has only been tried with BGP.  Do we know for
> >>sure that the OSPF tree will converge if it thinks that one host is
> >>actually located at two different places in the topology?  Maybe this
> >>would just work -- I don't know OSPF well enough to know for sure
> >>without closely reviewing the spec (or maybe trying it).
> >>
> >>Also, since a site doesn't actually map to an AS, and may not be
> >>handled by a single routing protocol (i.e. it may be running OSPF
> >>between some RIP networks, or something?), then it isn't clear
> >>exactly where and how you would "inject" a route into the routing
> >>system (or whatever loose wording we're using) and be sure that
> >>it would propogated to the entire site...
> >>
> >>(4) The current IPv6 routing table MIBs are based on the IPv4
> >>routing MIBs.  It isn't clear if they will be able to properly
> >>handle IPv6 routing tables, as they may be different.  Once we
> >>figure out the architecture and conceptual datastructures, I will
> >>closely review the MIBs to see if they match.

There are updates in the works on the v6 MIBs.  One of the topics
being discussed is the structure of the routing table MIB.  Take a
look at http://www.aciri.org/fenner/mibs/v6/

Brian