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

[Robert Raszuk <[e-mail]>]

Then why not use BGP Operational Message then ?

Seems like perfect fit to me if this is just a BGP control plane network
propagation speedometer.

Cheers,
R.


On Tue, Jul 22, 2014 at 10:06 PM, <[e-mail]> wrote:

>  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]> 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]] *On Behalf Of *
> [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]] *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]> 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]] *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.
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>