[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New draft: Now What?



Hi,

Anyone (else S Woodside :-) had time to read my "roadmap" document yet?
http://www.ietf.org/internet-drafts/draft-savola-multi6-nowwhat-00.txt

I'd be very interesteded in receiving feedback on it.

In particular, the document classifies the sites in 4 different 
categories, and makes a hypothesis on their multihoming requirements, 
like:

                        .--------------.------------.--------------.
                        | Independence | Redundancy | Load sharing |
         .--------------+--------------+------------+--------------+
         |Minimal       |      no      |     no     |      no      |
         |Small         |    maybe     |    maybe   |      no      |
         |Large         |  maybe/yes   |     yes    |     maybe    |
         |International |     yes      |     yes    |      yes     |
         '--------------'--------------'------------'--------------'

* Do the classifications seem close to reality? 
* Does the hypothesis on their typical requirements seem to be close to 
the mark?

As one another point that was raised was a way forward; basically, a short 
term goal being on multi-connecting, host-centric multihoming, multihoming 
at site exit routers and a PI-based addressing for the "International" and 
possibly even some "Large" site classifications.

An alternative to PI-based addressing might be a different concept of 
breaking such big "sites" into smaller pieces.

* Do these immediate/short term goals seem reasonable?
* Are there some short-term goals which I've missed?
* Do folks think that we need a PI-based (de facto) addressing/multihoming 
solutions for a class of sites (think "Cisco", "Nokia", "IBM", etc.)?
* Do folks think that actually defining a border between those which could 
use PI-based addressing and those who couldn't would be possible?
* Do folks agree that we should continue the work with host-centric 
multihoming/multihoming at site-exit routers -type solutions?  There 
missing pieces there (ingress filtering, tunneling overhead with RFC3178, 
etc.)

Some food for thought... 

On Fri, 25 Apr 2003, Pekka Savola wrote:
> As promised, here's a new draft which has been partially extracted from my 
> MSc (also plugged in here earlier):
> 
> http://www.netcore.fi/pekkas/ietf/draft-savola-multi6-nowwhat-00.txt
> 
> (It has also been submitted to the I-D repository, and will probably
> appear next week -- but I know you guys like spending time reading drafts
> during the weekend, so here we go.. :-)
> 
> In particular the goal is to make us able to focus our thoughts a bit and 
> try to break the site multihoming into a bit smaller pieces.
> 
> It's 15 pages; the abstract is below.  Have fun.
> 
> Abstract
> 
>    ROUTING ARCHITECT'S WARNING: flagrant IPv4 site multihoming practices
>    cause a significant increase the routing table size, change rates and
>    instability, the tragedy of the commons by encouraging selfish
>    routing practices, the exhaustion of the 16-bit AS number space, and
>    may collapse the Internet interdomain routing architecture.
> 
>    As there has been a desire to avoid similar problems as seen with
>    IPv4, the use of similar techniques to achieve site multihoming has
>    been prevented operationally in IPv6.  However, the long effort to
>    proceed with other IPv6 multihoming mechanisms has produced lots of
>    heat but little light.  This memo tries to list available techniques,
>    split the organizations to different types to separately examine
>    their multihoming needs, to look at the immediate and short-term
>    solutions for these organization types, and to list a few immediate
>    action items on how to proceed with IPv6 site multihoming.
> 
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings