Re: [Idr] draft-litkowski-idr-bgp-timestamp

[<[e-mail]>]

I think we are inline …
But not all of the customers requires 50msec or < 1sec convergence time. For most of the traffic, some seconds is acceptable and there is no need to deploy dataplane protection for such purpose. But anyway, we have to track abnormal behaviors of the controlplane (race conditions, corner cases …) where it does not do its job correctly …

I was also thinking about propagation time of C-multicast route (at least type 5/6/7) which is critical … and customer cannot wait 30/50 seconds (or some hours … don’t laugh, it’s not a joke …) to receive the group membership …

Our proposal does not prone in anyway to use controlplane or dataplane to manage any redundancy …

There is a need to monitor BGP controlplane behavior and especially update propagation time : the basic use case is really to ensure that everything goes well … compared to the base line we evaluated in labs or theory.


From: [e-mail] [mailto:[e-mail]] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 15:30
To: LITKOWSKI Stephane SCE/IBNF
Cc: Jeffrey Haas; idr wg
Subject: Re: draft-litkowski-idr-bgp-timestamp

Stephane,

If you build your service counting on control plane convergence I think you are doing bad thing :) Sorry.

If this draft is to further help with such designs I would clearly switch to "no support" immediately. I had other use cases in mind which did not sound negative.

Specifically in your case if one PE of multihomed site looses PE-CE you locally protect the site (10s ms max) and take all time it needs for BGP to converge regardless how long it takes. Of course I am assuming basic rules like unique RD per VRF in place.

The most important is to maintain data plane connectivity.

Besides I am not sure how timestamp will help you in this case. Leave alone that timestamp may never catch the refresh max CPU load peak so you may incorrectly consider RR as sound when it is really not.

Cheers,
R.


On Tue, Jul 22, 2014 at 9:19 PM, <[e-mail]<mailto:[e-mail]>> wrote:
[Renamed topic]

Hi Robert,

> Your results may actually in the above case casue more problems then gains unfortunately.

I don’t really understand why … even if RR are not in the dataplane (which would be the case for VPN environment), RR behavior is really important to track.

Consider a MPLS VPN scenario, some PEs connected to RR clusters and meshing between clusters.
Consider that one of the RR is getting stuck because of Route-refresh processing of 2M of routes or just busy to do something else due to bad scheduling in the implemention … if a PE lose a customer connection, and customer has a backup connection and backup PE has to send a new BGP update to propagate the new path. The time for RR to propagate the BGP update is critical to track because this will condition convergence time for the customer …

Thoughts ?


Stephane


From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 11:15
To: LITKOWSKI Stephane SCE/IBNF; Jeffrey Haas
Cc: idr wg
Subject: draft-litkowski-idr-rtc-interas

Stephane,

I have one fundamental question on this ...

You have focused on making sure that BGP control plane works fast and solid etc. That is great and timestamp idea at each BGP hop would help.

However let's observe that BGP control plane is NOT congruent with data plane. In other words you may have a case where someone may have slow and overloaded RR but uses 40 GB pipes for data plane while other AS installed super-hyper x86 RRs and has 1 GB links for data plane.

Your results may actually in the above case casue more problems then gains unfortunately.

The possible simple fix is to mandate that timestamp is ONLY added when your change next hop to self or that you can have a new flag "N" - Next Hop Set which will help a lot to make more use cases for this proposal.

Best,
R.




_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.