Paul,
On 14 Dec 2015, at 7:11, Paul Jakma wrote:
On Mon, 14 Dec 2015, Daniel Walton wrote:
I'm not opposed to making things easier/safer on the operator but my
gut says IDR is going to look at this and say that it is up to the
operator to configure bestpath knobs consistently in their AS and
that a protocol change is not needed. This is based somewhat on the
pushback we received when trying to add something as simple as a
capability that allows BGP to tell his peers what his local hostname
is. We were able to acquire an open capability code # for hostname
exchange but it was not easy (I really thought it would be going in).
I could be completely wrong about how IDR will react to the idea of
listing bestpath order as a capability though. I think it would be
good to discuss on IDR before committing any code to quagga. My 2c.
IDR is hard to get stuff through, yes. Partly for bad reasons, but
also maybe for good reasons. ;)
If getting through means getting to RFC then yes. But partially on a
good side as well (i.e., not constant changes
on protocols).
But my idea is to have at least have a formal draft submitted and some
round(s) of discussion (and maybe a
2nd version draft based on feedback) to address the obvious issues and
concerns which may come up.
Ideally we need a global capability code for this. Otherwise we need
to make the initial capability handshake a little bit more convoluted
to be sure the vendor-private handshake is really the same on both
sides. (E.g. add a magic number).
Otherwise, we leave the decision-order alone forever more (and warn
users about the existing knobs and hide or deprecate). Which maybe'd
be a slight shame, as BGP could be made safer and better (e.g. better
able to balance load in more complex iBGP topologies) if it wasn't so
risky to change it.
Don’t forget that there is quite a bit of influence on the best path
based on filtering and route-maps and (I think) none
of this can or should be negotiated. I see the internal decision process
of order (and potential enable/disable some steps)
as just one part.
- Martin Winter
[email protected]
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
