As Tony L sagely said "reality is a harsh mistress". At scale large enough updating TED while massive amount of TE repair, re-engineering, flooding and other computations are going on is something that is RFC 1924 #4. And I think most people around the working group are not aware that some of those already large L2 backbones grew by factors 3 to 4x in terms of nodes in last 5+ years (let's not even talk about links) and complexity/load is not something that grows linear once you walk this curve).
So this is not just coming up with stuff because we're bored, this is reality for quite a few of very large customers and the (arguably few vendors) that purvey the stuff they need. And basically 99% of usecases of ISIS these days is precisely large backbones so this is a possibly good tool to stretch the envelope of what is viable a bit out or at least squeeze the convergence times down. and this WG still has it in its charter to deal with ISIS bolts and nuts to push this curve so far. -- tony On Fri, Nov 8, 2024 at 3:45 PM <[email protected]> wrote: > 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]> 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] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
