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

Re: [RRG] Moving forward...



    > From: Lixia Zhang <lixia@CS.UCLA.EDU>

    > IPv4/v6 share the same architecture; the only major fundamental
    > difference is their address space size.
    > [M]y notion of the RRG task is to develop an architectural
    > solution to routing scalability.
    > We should step up a level from looking specific versions of
    > IP at this stage of solution development. Our solution has to be
    > an architectural change, and should work for either version.

One observation triggered by reading this: 99.2% of the discussion to date
has not been about a new routing (aka path-selection) architecture. Nowhere
have we been talking about the selection of paths. (Don't get me wrong, I'm
not throwing rocks here, I just want to make sure people are aware of this
point.)

Rather, discussion to date has been about how something new might be grafted
onto the side of the existing architecture, and in particular, about the
subset of that topic which is 'how we can escape the problem of the existing
overloaded semantics on IPv4/6 addresses'. I.e. how can we incrementally/
interoperably deploy a new namespace alongside the existing one.

I don't know for certain why this focus on this particular aspect of the
problem is happening: perhaps people want to get a decision on how to extend
the foundation extended before they start talking about how to the build
walls; or perhaps people think something like the existing path-selection
architecture (BGP, with all its warts) will be fine, if it has its own
namespace to play with; or perhaps people are just street-lighting. Dunno;
and no doubt different mixes of reasons apply to different people.


However, unless people do think that the existing BGP architecture is fine,
eventually we will have to talk about routing too, if we are to fulfil the
goal that Lixia laid out. I.e. what functionality the routing
(path-selection) system should/would have, how that system should/would be
broken up into subsystems, how the subsystems should/would communicate with
each other, what data they would need, how users would interact with it, etc,
etc, etc.

A long road lies ahead...

	Noel

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg