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

[Robert Raszuk <[e-mail]>]

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