Les, > With respect, it is hard to know what you are proposing since there has never > been a public description.
With respect, I’ve said it many times, both in person and in email. You need to hear it again? Sure. > The draft on which you are a co-author does not discuss any sort of algorithm > to dynamically alter the advertised value based on current router state. In > fact it argues (or at least suggests) that this shouldn't be done. I’m suggesting being more dynamic than what that draft advocates. > Apparently you have a different idea, which maybe the next version of > draft-decraene will include, but right now all we have as a description is a > series of isolated sentences in multiple emails. You'll have to forgive me if > I am not always clear about what you intend but have yet to state. Again, what I’m suggesting is that the LSP receiver use a TLV (possibly Bruno’s, possibly tweaked) to tell the LSP transmitter the current space in the input packet queue. As previously described, we may want to consider oversubscription when advertising this value. This MAY be included in IIH’s and SNP’s, piggy backed on existing transmissions. The LSP transmitter MAY use this information, in conjunction with the knowledge of unacknowledged LSPs, to optimize the transmission rate. If no information is learned from the LSP receiver, the LSP transmitter is no worse off. If the information that was learned is old, then LSP transmitter is free to ignore it. If the LSP receiver can’t provide a useful value (e.g., if the PD layer hasn’t been implemented), it is free to provide either the static value or no value. As always, I am expecting that implementation experience and inter-operability testing will contribute to this effort, and I am not expecting the right answer in the first pass. Tony _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
