@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 > > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
