Robert, Hi! I don't understand the question (there is no suggestion of recomputing the data plane TE of choice). Please refer to the example application cited in the email that started this thread for context.
Regards, -Pavan On Fri, Nov 8, 2024 at 4:23 PM Robert Raszuk <rob...@raszuk.net> wrote: > > 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 <tony1ath...@gmail.com> 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 -- lsr@ietf.org >> To unsubscribe send an email to lsr-le...@ietf.org >> >
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
