Pavan, Thanks for your answer.
* where the information for some links takes a few ms to get updated in the TED and for some others it takes tens of seconds to get updated in the TED “tens of seconds” to update the TED i.e. to flood across the area… woaw, not a duration I had in mind indeed. I now better understand the TE use case, thanks. Let’s hope that LSPs used by distributed SPT computations are flooded faster. Regards, --Bruno From: Vishnu Pavan Beeram <[email protected]> Sent: Friday, November 8, 2024 10:50 AM @Tony - Thanks for jumping in. Bruno, Hi! For the example application cited in my previous email, knowing the average time (something along the lines of the suggestion in Tony's response) it takes for a topological element specific update (originated on a TE node) to get reflected in the TED used by a TE Path Compute node would be useful. If you have a network where the link state information gets updated uniformly on all TE Path compute nodes within 50ms, then this example application doesn't apply for you. But if there is a network, where the information for some links takes a few ms to get updated in the TED and for some others it takes tens of seconds to get updated in the TED, then knowing the relative delay statistics is useful (to cater to the cited example application). Regards, -Pavan On Fri, Nov 8, 2024 at 3:26 PM Tony Li <[email protected]<mailto:[email protected]>> wrote: Hi Bruno, I haven't seen a reply from Pavan, so let me jump in... I can give a simple distributed TE application example (there are several, but this should give a general idea how this information can be leveraged). In RSVP-TE networks, a TE path computed using a specific snapshot of TED can get rejected during signaling by a transit node because of bandwidth unavailability on a specific link (link bandwidth information in the snapshot of TED used during computation cannot always be “current”). When ingress gets notified of this “error” via RSVP signaling, the link in question is avoided in the subsequent path computation and an alternate path is sought. Most implementations tend to use a configurable “hold time” to determine how long this link needs to be avoided. The awareness of the distribution delay statistics can potentially be used by implementations to dynamically determine an appropriate “hold time” for a given TE link (instead of using a blanket topology-wide configuration). By « delay » do you mean the IS-IS flooding time across the flooding domain or do you mean something else? Yes, the flooding time across the area. If this is the flooding time, what distribution delay statistics do you have in mind? Mean plus 2x std dev. would be a good guess at a cutoff. I reserve the right to update this based on future experience. In current deployment and as a goal in order to neglect this flooding time? e.g., if flooding time could be reduced to 50 ms would you still need this timestamp? We cannot guarantee that flooding time can be reduced to 50ms. While fast flooding is of course a good thing, reality is a harsh mistress. Other implementations might be in the flooding path. Old software will be in the network for a very long time. So measuring reality would be helpful. T ____________________________________________________________________________________________________________ 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.
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
