Re: [rrg] RRG to hibernation

I an not pleased ether.
One group goes ahead with LISP-DDT, which is doomed to fail ! With drums and trumpets! As sure as the Amen in church ! With no rescuing trick in sight! 
The other group believes in IPv6. I admit, I don't know what is special about IPv6. All I know is that the inventors came up with a crazy address space and I do remember voices from many many years ago which proclaimed the advent of the internet for our galaxy.I am sure, IPv6 would only create additional scalability problems. Imagine a future where we have only IPv6. Hereby imagine New York at New Year's Eve and several hundred thousand people operating as mobile sender's of  IPv6-multicast instances with multicast receivers far away (which may as well be mobile) !  We wouldn't not only have a scalability problem wrt forwarding but as well with respect to identifying the individual entities. How many IPv6-addresses are needed to identify one single mobile multicast instance? 1? 2? 3? How should it be retrieved by software?

Loc/id-split:  
Obviously what is a locator and whether there are several components thereof or not hasn't been understood.
A unicast locator MUST BE location-indicating! A multicast -locator CANNOT but this doesn't mean that there can't be any.

Topology-aware BGP:
Distance Vector versus Dijsktra.
DV will never tell you about the upstream network (see also Shane Amante's email). This is a disaster if you want to manage traffic load (balance/ dissolve congestion) :-(
Reachability: We don't need reachability. we only need to know where is the indicated location !!!  Location based routing means no user reachability dissemination,  only location reachability dissemination!

Whenever I addressed these issues it was like I had sinned against some holy paradigm.

And we are far away from better routing:
I you only know the ALL-Nodes-Spanning-Tree (and not the All-Links-Spanning-Tree) then you call it Spanning Tree per se.
If you only know the Unicast-FIB (and not a Multicast-FIB, nor a Anycast-FIB)  then you call it FIB per se.

To reach a higher level you must view things from a greater distance and sometimes leave the old trails behind you.

Ich habe fertig
Heiner

-----Ursprüngliche Mitteilung----- 
Von: Scott Brim <swb@internet2.edu>
An: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Cc: rrg <rrg@irtf.org>
Verschickt: Sa, 10 Nov 2012 4:40 am
Betreff: Re: [rrg] RRG to hibernation

Well, this will be fun. Yes Noel, you're right, this group didn't produce any 
routing revolutions, and loc/id separation is about problems on the identity 
function side, not routing ... but this group's best accomplishment imho was to 
understand that and spread the knowledge. 

Now I'll go back to doing good things with higher layer identities.  Ciao.

Scott

jnc@mercury.lcs.mit.edu wrote:

    > From: Tony Li <tony.li@tony.li>

    > The publication of these RFCs concludes our long standing work item on
    > a revised routing architecture.

Separation of location and identity is very desirable, but it has basically
nothing to do with routing (other than removing identity functionality from
the names used for routing, making them a bit more tractable).

We still have the same old kludgy BGP global routing system we always had,
and _nothing_ has been proposed to improve/replace it.

    > The group has ... helped push the boundaries of routing farther
    > forward.

Nonsense. It has produced no routing work at all.

	Noel
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg