Hi Tony/Vishnu, Would you really want to recompute your data plane TE of your choice only because control plane propagation was delayed, say even a few hundreds of ms ?
Thx, R. On Fri, Nov 8, 2024 at 10:57 AM 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] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
