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

[Robert Raszuk <[e-mail]>]

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.
>
>