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

[<[e-mail]>]

No no … this have nothing to deal with best path selection … timestamp are just informations to be used by external tool.
TS attribute is not part of path comparison.

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


I do see very crisp what you are trying to accomplish.

I am concerned that you are proposing wrong tool for it. At least even if there is some merit to timestamp as an indicator (which I am not that convinced) I think just new attribute to be added when operator seems fit to current UPDATEs seems not perfect.

To make the decision of which paths to choose I would consider other information like CPU usage of RR ? Or free RAM to be able to easily tell that one RR may have some memory leak etc ... and those information are (I hope) already being collected by your monitoring stations.

How timestamps are going to ignore all of those and replace to hit best path selection ?

​r.​

On Tue, Jul 22, 2014 at 9:43 PM, <[e-mail]<mailto:[e-mail]>> wrote:
And just to add something else linked to dataplane protection …
Even if we implement a dataplane protection (PE-CE, or even CORE), we are using OAMs to verify that it works fine and does its job correctly … because maybe in 95% of the cases it would work and you will have 50msec of traffic loss, but in some conditions you may fall into a bug or corner case that will put you at some seconds or more.

Here it’s the same, we have some mechanic in place (BGP), we want an OAM (simple probing) to ensure that it does it’s job correctly …

Hope the comparison clarifies my position.


From: Idr [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Tuesday, July 22, 2014 15:39
To: Robert Raszuk

Cc: Jeffrey Haas; idr wg
Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp

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]> [mailto:[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.

_________________________________________________________________________________________________________________________



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.