Re: [GROW] Potential route flap with bgp-diverse-path

[Robert Raszuk]

Hi Jakob,

I have discussed this proposed text with other diverse-path co-authors 
and we concluded that such additional constrain is not required.

The reason is that BGP implementations deployed today can easily delay 
reaction by BGP to IGP bad events flooding while in the same time 
switchover of the data plane to a pre-installed backup path will happen 
instantaneously in FIB. This will result in no data plane traffic drop 
as well as no BGP churn of any kind.

Many thx,
R.

I propose to add this text to the draft:

Advertisements of multiple paths by multiple
planes of advertisers are received asynchronously.
It is not possible to order the messages reliably
from different planes. This may cause churn in
route selection when paths change.

To address this issue, a speaker that advertises the
Nth best path, where N>1, SHOULD delay its advertisement
by MRAI plus (N-1) times X. X SHOULD be a small
value that is greater than the message delivery
time between BGP speakers. Such a speaker should not
add its own MRAI timer to this delay.

A speaker that advertises the Nth best path shall
initially advertise nothing if an Nth best path
does not exist. Once the Nth best path changes,
it should apply the above delay before sending
the changed advertisement. The change may be a
withdrawal.

--
Jakob Heitz.


-----Original Message-----
From: Robert Raszuk [mailto:ras...@cisco.com]
Sent: Sunday, March 27, 2011 3:06 PM
To: Jakob Heitz
Cc: grow@ietf.org; IETF IDR
Subject: Re: [GROW] Potential route flap with bgp-diverse-path

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
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow