Re: Fwd: Re: note from the iesg plenary

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

Hi Margaret,

Margaret Wasserman wrote:
> 
> Hi Brian,
> 
> >I know that this subject has been discussed several times.  I believe
> >the scenario that Margaret is concerned about is based on this
> >diagram she posted to IPNG several months ago (correct me if I am
> >wrong, Margaret):
> 
> This is one case that I am concerned about, yes.
> 
> You and Steve resolved this case by stating that a site must be
> "convex", and I am sure that the text explaining this will be in the next
> version of the document -- I do understand what it means, and I agree
> that it will solve the problem.

Good.  Now if I could get some cycles to actually edit the doc...

> 
> However, this does place several constraints on the concept of a site.
> For example, consider two office of the same company, both connected to
> the Internet, that are connected by a high-cost link (higher cost than
> traversing the Internet between the two locations).  These two
> locations could not be configured as a single site, although they
> would probably cross-pollinate their global addresses (for redundancy)
> and might be treated as a single routing AS.  This adds some complexity
> for routing purposes, as it clearly decouples the concept of sites
> (which must be convex) and routing ASes (which do not have that
> restriction).

This is true and I would state that it is a "good thing" to have the
routing ASes and the sites decoupled.  In your scenario, if the
sites had a cheaper connection via the Internet, I would not even
consider putting them in one site.

If it was necessary to have both locations in the same site, it
would still be possible with the use of IPSec tunnels and some
tweaked routing parameters.

> 
> Also it is possible that all of the subnets of a single global address
> allocation may not be in the same site, right?  So, it would probably
> not be acceptable for renumbering to be constrained by site boundaries.

I agree.  Renumbering is not constrained by site boundaries, it is
constrained by delegation of the prefix being renumbered.

> 
> Some other issues have been raised in my previous mail, but I forgot to
> raise two additional issues:
> 
> Default Routes:  Will multi-interface-hosts and non-default-free site border
> routers potentially have several different default routes (one for global
> traffic, one for each site, etc.)?

Sure.  I have that today in my v6 lab network.  There is a default
route per scope (global, site, etc.).  Works fine.  There may be an
issue of having multiple default routes per zone ID.

> 
> And in general, will we allow multi-site hosts?  Or, can only a router have
> interfaces in more than one site?

I would not make that restriction.

> 
> Just for the record, I think that I know the answers to many of the
> questions that I have posed.  I'm sure that several of you know the answers
> as well.  But, do we know the same answers?

Don't know.  What are your answers to these questions?

> 
> And, how can we standardize this behaviour well-enough for people to implement
> site-border, anycast-compatible, IPv6 hosts and routers without investing
> years of effort to understand IPv6?

I hope so.

> 
> One of the most disturbing issues (to me) is the widespread misconception
> that it should be possible to route IPv6 packets by looking at only the
> first 64-bits.  This may be true for the small number of addresses that
> we've already defined, but the IESG has been quite clear that we shouldn't
> rely on any hard internal boundaries in the addresses.  And this certainly
> wouldn't work for host routes.

That is correct.  I hope people start forgetting that misconception.

> 
> Also, site-local addressing and anycast addressing are the biggest changes in
> IPv6 from IPv4.  Basically, addressing == routing.  And, I think that it
> would be worth the investment of our time to make sure that we understand
> all of the routing implications of site-local and anycast addressing.  Also,
> we need to make sure that the appropriate semantics are included in the
> current IPv6 routing protocols (OSPFv3, BGP-4+, RIPv6, ??) to handle site-local
> addressing and the injection of anycast host routes (as we are suggesting in
> some drafts).

Agreed.  I happen to be working on both of these areas.  I am hoping
that once we get the scoped addressing architecture done, we can go
and look at making necessary changes to the routing docs.  The anycast
will take a little longer, but may not affect the routing RFCs.

> 
> I am not actually disagreeing with any of the work in this area, to date.
> It just isn't complete.

Agreed.

Brian