> I'm also inclined to think that some of the overloading
> in BGP isn't helping the overall stability of the routing system.
> If I were more awake (or had had coffee recently), I could likely
> create a long list of these. Instead, I'll select one *example*:
This certainly wouldn't have been my example, though it
does indeed suggest that seemingly, a large scalability
issue with BGP relates to it's inability to scope propagation
of attributes without resulting in forwarding or routing
information loops.
I'd have to complain about the various BGP extensions
(e.g. RFC2547 gunk) that presumably provide scalable
solutions to not-exactly BGP-related problems and employ
an already burdened BGP to do lots of other 'interesting'
stuff.
[Note: my intentions weren't to start off-topic dicussions
on BGP VPNs or related solutions, but rather, to address
BGP scalability and stability as it relates to the global
routing space. Please send comments re: BGP VPNs
and the like directly to me.]
Interestingly enough, said solutions are targeted at
deployment in networks that today contain routers that
often have 500K or more BGP paths, and already take on
the order of 300s or more to fully synchronize tables
with peers.
This does relate to your closing paragraph [wrt to much
gunk in BGP], I'd hope the IESG will remember this when
considering such solutions.
> - right now a number of ISPs prepend their AS several times
> ("AS padding") as a method of the originating AS to
> make their path to a customer less preferred than
> some other ISP's announcement of the identical customer
> prefix.
> - we could consider adding a variable to denote that a
> given path is less preferred so that the above practice
> weren't needed.
I believe both DPA and the 'AVOID_ME/PREFER_ME Communities"
attempt[ed] to address this very thing. Their success has
been, well, less than overwhelming. Of course, these are
today [IDR?] problems and probably don't belong in the IRTF-RR
group.
> Finally, and perhaps most radically, it might be helpful
> or clever to consider partial separation of the "topology
> discovery" mechanism from the "policy communication" mechanism.
> Right now, both are intermingled in BGP. Both are useful. The
> question is whether it might be useful to have both exist, but
> exist separately and distinctly.
I'd agree, though I don't have much useful input at the moment
either. Perhaps a good [inevitable] look @NIMROD would be
worthwhile as well, it certainly possesses a number of desirable
attributes. I'm not convinced a coupling with DUAL would be a
plus, however.
-danny
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT