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

[<[e-mail]>]

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