Fwd: Re: note from the iesg plenary

[Margaret Wasserman <mrw@windriver.com>]

Hi All,

Sean Doran and Thomas Narten asked that I send a summary of my routing 
issues to the multi6 list.  

This is not a very well-developed list.  I'm working on a draft for the 
IPv6 group that will answer these questions as well as I can, and hopefully 
serve as a discussion tool for closing the other questions.

In the meantime, please let me know if you have any of the answers.
I don't think that any of these particular issues related directly to
multi-homing, but I could be wrong -- everything seems to related to
multi-homing these days. :-).

Thanks,
Margaret



>>Basically, I have four issues:
>>
>>         (1) Boundaries for regular route lookups.
>>         (2) Site-local routing.
>>         (3) Anycast routing.
>>         (4) Routing table MIBs.
>>
>>(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?
>>
>>(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).
>>
>>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"?
>>
>>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).
>>
>>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.  
>>
>>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.
>>
>>So, those are basically my issues.  Some of these may be non-issues,
>>but I won't know for sure until I investigate (much) further.  I had
>>been hoping that some actual routing person was looking at these 
>>issues, but alas...I guess that I will be forced to play a routing 
>>person on TV (or on the mbone, anyway).  I will try to write something 
>>up in the next several weeks for the IPv6 WG.
>>
>>Sean, I doubt that this answers any of your questions.  But, feel
>>free to let me know if you have specific issues or questions.  I'll
>>also try to read the multi6 list next week.
>>
>>I'm glad that someone was listening...  :-).
>>
>>Margaret
>>
>>
>>
>>
>>At 06:28 AM 8/10/01 , Thomas Narten wrote:
>>>Hi Sean.
>>>
>>>Margaret Wasserman was the person who raised the issues from the
>>>floor during the plenary..
>>>
>>>Margaret, are you on the multi6 list?
>>>
>>>Thomas
>>>
>>>smd@ebone.net (Sean Doran) writes:
>>>
>>> > it was noted that there has been little attention payed in the ietf
>>> > to scoped addresses of various types in the ipv6 standard (e.g., link
>>> > or anycast addresses).  
>>>
>>> > for our wg (from me, not from the floor): can these different address
>>> > varities, when a host uses them, be considered as a form of multiple-address
>>> > multihoming?    likewise, those approaches which change the routing system
>>> > in some fashion: how can/do they deal with such addressing types?
>>>
>>> >       Sean.
>>>
>>> > ps - several questions are coming up and unfortunately i am too slow a typist:
>>> > how does one choose and forward addresses for anycast objects, how does
>>> > one deal with sites which are not convex, how does one scope addresses
>>> > beyond a site boundary.  there were others.  if someone can identify
>>> > the questioner from the floor, i would like to invite her to ask the
>>> > same questions here.   as noted, with my other hat, irtf-rr is a reasonable
>>> > place to ask (not necessarily ipv6-specific) similar questions, but
>>> > note well that the irtf is *NOT* the ietf, whereas this is.