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 <s...@internet2.edu>
An: Noel Chiappa <j...@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
j...@mercury.lcs.mit.edu wrote:
> From: Tony Li <tony...@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
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
