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

[Robert Raszuk <[e-mail]>]

Ahh ok .. then we are slowly getting more on the same page. Well at least
we are on the same bookshelf now :)

If this is your application why not use BGP Diagnostic Message for it now
part of BGP Operational Message draft which is an IDR WG doc ?

http://tools.ietf.org/html/draft-ietf-idr-operational-message-00

- -

Someone at the IDR I think asked in the room that this should be at least a
separate SAFI. But till we go there let's see if you see problems with
adding this functionality to Operational Message.

Thx,
R.




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

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