NACK.
This is just wrong.
With this on top of the update-delay patch, you're going to have either:
a) GR peers that are both in update-delay just immediately send EoR to
each other, and so go out of update-delay mode with each other.
b) Non-GR peers sit in update-delay mode until one or both send keepalives
to kick the other out of update-delay mode.
It is a basic tenet of convergence churn reduction to have the "more
converged" side (call it M) send its state /first/ to the "less converged"
side (L), so that the processing churn happens on L and transients are
hopefully confined to L and the sub-network on its side of the partition.
/Then/ have L send its result to M.
This implies:
1. You need some mechanism or heuristic to negotiate the "more converged"
and "less converged" properties, to decide who is L and who is M (if
any at all). The mechanism may be imperfect and not always produce the
optimal answer, but such is life.
2. You need an ordering mechanism to make the "M send first, then L" part
work.
These patches ignore this completely. You need some kind of assymetry and
ordering conditions in the protocol, but "Wait for everyone else to send
EoR or keepalive" is inherently symmetrical. Note: A timer is *not* an
ordering condition, other than by accident.
Who goes first with this patch set? No one and everyone. This is not GR.
I know why you're interested in this case, because it helps a route-server
with many peers, after the route-server restarts. However, these patches
also need to work for the general case.
Also, I have expertise elsewhere in network protocol analysis, convergence
optimisation and churn reduction, and formal verification of same.
Maybe we should try working with each other.
--paul
On Thu, 14 May 2015, David Lamparter wrote:
The R-bit is not intended to affect outgoing update sending like this;
the effect of not sending out updates is supposed to stem from bestpath
selection not being performed during the startup phase.
Untested.
Not-Signed-off-by: David Lamparter <[email protected]>
---
bgpd/bgp_open.c | 1 -
bgpd/bgp_packet.c | 15 +--------------
bgpd/bgpd.h | 3 +--
3 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/bgpd/bgp_open.c b/bgpd/bgp_open.c
index b9d6e93..cb7d1e0 100644
--- a/bgpd/bgp_open.c
+++ b/bgpd/bgp_open.c
@@ -1035,7 +1035,6 @@ bgp_open_capability (struct stream *s, struct peer *peer)
if (peer->bgp->t_startup)
{
SET_FLAG (restart_time, RESTART_R_BIT);
- SET_FLAG (peer->cap, PEER_CAP_RESTART_BIT_ADV);
}
stream_putw (s, restart_time);
diff --git a/bgpd/bgp_packet.c b/bgpd/bgp_packet.c
index f7af4ee..b39b5e9 100644
--- a/bgpd/bgp_packet.c
+++ b/bgpd/bgp_packet.c
@@ -617,20 +617,7 @@ bgp_write_packet (struct peer *peer)
{
if (adv->binfo && adv->binfo->uptime < peer->synctime)
{
- if (CHECK_FLAG (adv->binfo->peer->cap, PEER_CAP_RESTART_RCV)
- && CHECK_FLAG (adv->binfo->peer->cap, PEER_CAP_RESTART_ADV)
- && ! (CHECK_FLAG (adv->binfo->peer->cap,
- PEER_CAP_RESTART_BIT_RCV) &&
- CHECK_FLAG (adv->binfo->peer->cap,
- PEER_CAP_RESTART_BIT_ADV))
- && ! CHECK_FLAG (adv->binfo->flags, BGP_INFO_STALE)
- && safi != SAFI_MPLS_VPN)
- {
- if (CHECK_FLAG (adv->binfo->peer->af_sflags[afi][safi],
- PEER_STATUS_EOR_RECEIVED))
- s = bgp_update_packet (peer, afi, safi);
- }
- else
+ if (!CHECK_FLAG (adv->binfo->flags, BGP_INFO_STALE))
s = bgp_update_packet (peer, afi, safi);
}
diff --git a/bgpd/bgpd.h b/bgpd/bgpd.h
index dad5980..1586108 100644
--- a/bgpd/bgpd.h
+++ b/bgpd/bgpd.h
@@ -384,8 +384,7 @@ struct peer
#define PEER_CAP_RESTART_RCV (1 << 6) /* restart received */
#define PEER_CAP_AS4_ADV (1 << 7) /* as4 advertised */
#define PEER_CAP_AS4_RCV (1 << 8) /* as4 received */
-#define PEER_CAP_RESTART_BIT_ADV (1 << 9) /* sent restart state */
-#define PEER_CAP_RESTART_BIT_RCV (1 << 10) /* peer restart state */
+#define PEER_CAP_RESTART_BIT_RCV (1 << 9) /* peer restart state */
/* Capability flags (reset in bgp_stop) */
u_int16_t af_cap[AFI_MAX][SAFI_MAX];
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
Doubt is not a pleasant condition, but certainty is absurd.
- Voltaire
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
