Hi Jakob,
I mean it switches to P2, then to P3, then
back to P2. This does not happen when using add-path.
No one is trying to compare it to add-paths.
It causes churn if this router readvertises to external
peers and P2 has different atributes to P3.
What it needs to be compared against is current BGP deployments. You
best path from both RRs and when it fails you blackhole traffic till BGP
provides you a new path.
The external re-advertisement is also not really valid observation. One
main reason why EBGP MRAI is longer then IBGP MRAI is exactly to
mitigate those short lived BGP transitions from being visible in the
entire Internet.
The issue is not necessarily a problem. However, it needs
to be stated in the draft, so that operators can be
aware and avoid the problems.
If you have some text to propose which would first correctly describe
and clarify the issue I would be happy to incorporate it.
Just keep in mind that diverse-path is a very simple way, without need
to upgrade the client side to provide much better path switchover
results with no packet drop as compared to what is today.
That makes it a 3rd RR plane.
It means you are recommending at least as many RR planes
as possible paths for any destination.
Nope. I think you are drawing conclusions too quickly.
Second client-RR session would allow to advertise best and second best
from any given RR. That means that you would never transition to 3rd
best even for fraction of time as your R2 would still be there on the
client.
Keep in mind that some deployment proposal models from customers are
even today focused on sharing RRs and configuring some clients to get
best and some to get second best from a given RR even if RRs are in
pair. And this is just configuration as the diverse-path as will be
discussed in GROW meeting this week during the implementation report is
a per peer knob.
Many thx,
R.
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
