On Fri, 15 May 2015, David Lamparter wrote:
Ooooh. I think I found the source of our different approaches.
Yes, you're designing to minimise CPU churn. I had an eye on the network
churn, which is what GR was intended to do. From the introduction:
"Usually, when BGP on a router restarts, all the BGP peers detect that
the session went down and then came up. This "down/up" transition
results in a "routing flap" and causes BGP route re-computation,
generation of BGP routing updates, and unnecessary churn to the
forwarding tables. It could spread across multiple routing domains.
Such routing flaps may create transient forwarding blackholes and/or
transient forwarding loops. They also consume resources on the
control plane of the routers affected by the flap. As such, they are
detrimental to the overall network performance."
It has the side effect of doing something useful for startup, but it
isn't trying to combat generic churn from router outages.
The RFC does seem to be concerned with minimising network churn, see the
intro. The ordering of table dumps, and making the restarted router
converge first is intended to help with that. It also mentions unplanned
outages.
RFC 4724, Section 4.1:
[...] However, it MUST defer route
selection for an address family until it either (a) receives the
End-of-RIB marker from all its peers (excluding the ones with the
"Restart State" bit set in the received capability and excluding the
ones that do not advertise the graceful restart capability) or (b)
the Selection_Deferral_Timer referred to below has expired. It is
noted that prior to route selection, the speaker has no routes to
advertise to its peers and no routes to update the forwarding state.
Update-delay seems to be for all AFs at once, so we don't exactly do
this to the letter, but I'd argue "close enough" with possibility for a
future improvement.
What I would like is to defer UPDATEs only from the R-domain to S-domain
peers. This is what the current code does.
You're designing a different approach. I would suggest you take it to
the idr WG @ IETF.
Except that's what the code has now.
The update-delay removes a nice convergence feature.
I'm asking the same thing, you don't seem to be listening to me. You,
however, switched to a meta-argument that contributes nothing to the
matter at hand, instead being only useful to get one opinion a higher
weight than the other. That's not a valid move in a discussion between
equals.
After a (good) off-list discussion, and me posting a follow-up to
address a concern you raised, which you reply to again arguing the need
for a timer, you then post your own patch which, gosh, goes and removes
the startup timer and makes the R-bit timer be, gosh, dependent on
state, just as I had argued.
WTF dude? Is that working together?
WTF dude, the timer is still there, it's called t_update_delay.
+bgp_update_delay_active (struct bgp *bgp)
+{
+ if (bgp->t_update_delay)
+ return 1;
+ return 0;
+}
The timer is a max-delay (potentially quite long). Until then it acts as a
flag that may be disabled by changes to the state (sensible).
I don't have a problem with that. Behaving sensibly based on state is
precisely what I was arguing for. I don't think there's a good way to pick
the max-delay though, nor do I think it necessary to stall all UPDATEs.
then I really don't know what glasses you're reading my mails with.
The original timer wasn't sensible. Making it state-based is sensible to
me. I thought we were having a discussion about going in that direction.
I hadn't objected to integrating update-delay at all, later.
I'm still arguing we should implement RFC 4724. You seem to be arguing
we should try and design a new churn-reduction scheme.
It's not new - it's in the existing code. To remove it would be a
convergence regression.
RFC 4724 doesn't even care greatly about the restarted-restarted case.
Further, network RFCs are generally about the external behaviour.
Internals are usually an implementation detail. There is no way the
"Receiving Speaker" can tell whether or not the "Restarting Speaker"
deferred its route-selection globally.
What matters here is that on the wire the "Restarting Speaker" is seen to
wait for the EoR of the "Receiving Speaker", and that no speaker gets into
deferal dead-locks because of this feature.
So, it's cool stuff, but I would join Michael in thinking this needs
more time to develop outside of master to see the demand before
committing to it.
The difference is, the src-dst stuff has been looked at by a 2-digit
number of people @ IETF, and has been implemented by others. Your
churn-reduction protocol for BGP is completely new with no written
specification and no review at all.
The src-dest comment is on making it the default RIB lookup.
I made a comment asking about certain src-dest table lookup interactions
that are not covered by the described use-cases, nor anywhere else
(AFAICT) asking what the implications were, as it seems unclear and
potentially problematic. I'd tend to want those assuaged before making it
the default. Be it now (e.g. update an RFC?), or through wider experience
later.
Until then, add it as an optional thing and I have no issue. (And the API
for this will benefit other people doing extended routing lookups).
If you want to implement it in Quagga, sure - but implementing it in
Quagga doesn't get you any interop testing, doesn't result in adequate
feedback from other qualified people who either operate networks or have
written the other BGP implementations you need to interact with.
While a Quagga implementation can (maybe should) be part of the
creation process of a new protocol, it shouldn't be the very first
thing.
That's just abusing our users' networks for testbeds.
"Send UPDATEs without artificial delays when it's perfectly acceptable" is
abusing people's networks?
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
A star wars satellite accidently blew up the WAN.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
