> From: Tony Li <tony...@tony.li>
>> 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 <sh...@castlepoint.net>
> 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
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
