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]
