Subject: Re: [rrg] RRG to hibernation

From: Scott Brim <[email-masked]>
Date: Fri, 9 Nov 2012 22:40:05 -0500 (EST)

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

[email-masked] wrote:

    > From: Tony Li <[email-masked]>

    > 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
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 9 Nov 2012 22:55:15 -0500 (EST)

> From: Scott  Brim <[email-masked]>

    > this group's best accomplishment imho was to understand that and spread
    > the knowledge.

I didn't say the group had produced nothing of value. Clearly, the work on
location/identity was useful.

(Although it is regrettable that the IETF didn't take the concept on board
when RFC-1498 was produced, in 1993, instead of taking almost 20 years to
recognize the necessity of separating location and identity - the Internet
would be a lot further along at this point if it had.)

I just dispute the contention that it produced notable routing work - because
it didn't.

Which means that, since there _are_ needs for improved routing, we're now
going to see the same scenario as I referred to above, with loc-id-sep,
repeated in the area of routing - the IETF taking forever to grudgingly admit
that what one would hope are seemingly obvious improvements are, in fact,
necessary.

The only question is, are we again going to see very long delays before that
happen (perhaps two decades again)?

And better routing is an order of magnitude more complex, technically, than
loc-id-sep. So the pain/cost of upgrading _that_ will be that much greater.

	Noel

---

From: [email-masked]
Date: Sun, 11 Nov 2012 14:52:57 -0500 (EST)

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 <[email-masked]>
An: Noel Chiappa <[email-masked]>
Cc: rrg <[email-masked]>
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. 

Scott

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Sun, 11 Nov 2012 21:18:47 -0500 (EST)

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

    > Blatantly not true. There's this thing called NIMROD that has been
    > proposed to replace it. Perhaps you've heard of it? ;-)

In my original message, I meant 'here in the RRG, recently'. And you could
probably expand that to 'here in the I*, recently'.

I don't think there's been any serious work in routing since Unified and
Nimrod, right?

    > From: Shane Amante <[email-masked]>

    > let me try to take a step back and share with everyone a much broader
    > set of, potentially, architectural concerns
    > ...
    > if a downstream network does not have visibility into its upstream
    > network's routing policy is it practical/feasible for the downstream
    > network to understand the _intended_ propagation of reachability
    > information and, ultimately, connectivity? Furthermore, is it feasible
    > to carry such information within the control plane itself? Or, should
    > the control plane be relegated to carrying [strictly] reachability
    > information

You ask a series of very interesting questions, ones I don't have an
immediate answer to.

On the first, I have heard people say that providers don't want to tell
anyone anything about the policies, etc.

As to the second, there has been some thinking along those lines, although
I'm not sure it's all written down.

E.g. in the context of Nimrod, I thought about the possibility of separating
topology informtion from up/down information. E.g. a node might flood
topology information (i.e. long-term, permanent changes), but it would not
flood up/down information (i.e. short-term state changes). A distant node
would find out that an asset that was listed in the map was actually 'down'
when it tried to set up a path through it; the path setup would fail. I.e.
that information would be propogated in 'pull' mode, to try and reduce
overhead, and have that information only sent to those entities which
actually needed it. (There's a lot of complictions, e.g. what happens when an
asset fails when there's traffic using it, but I'm going to gloss over them
all for the moment.) But I'm not sure that stuff got written down... :-(

    > {A long series of other very interesing comments, which I don't have
    > the time to reply to.}

This is all very interesting stuff. Is there any chance you could expand this
into a short note (an RFC might be too much work, but perhaps there's some
other way to distribute it).

This sort of information, from the operational commmunity, is very valuable
to system architects. I personally am going to re-read this message several
times to make sure I have really absorbed everything in it.

    > Does anyone on this list share similar concerns wrt operational
    > robustness, time to recovery and (then) scalability of BGPv4?

Absolutely.

And I also have 'tussle' issues; which is to say, right now, the users have
little insight, and basically zero control (other than having multiple
providers, and picking the outbound provider) over paths. I'd like to see
the users have more insight and control, but the providers probably wouldn't
like that (hence the 'tussle' reference).

	Noel