Les, > If you disagree please take things bullet-by-bullet: > > LSP input queue implementations are typically interface independent FIFOs
Very true. It would not be unreasonable for an implementation to report free space in the FIFO (in number of PDUs) divided by the number of active adjacencies. Everyone gets their fair share. [If dynamic flooding is enabled, this could be based on the number of adjacencies that should be actively flooding. That should be a much smaller number.] > Overloaded Receiver does not know which senders are disproportionately > causing the overflow This doesn’t matter. The receiver needs them all to slow down. > LSPs may be dropped at lower layers – IS-IS receiver may be unaware that the > overload condition exists That’s an implementation problem. The implementation NEEDS to be able to see its input queue plus input drops. > Updating hellos dynamically to alter flooding transmission rate is an OOB > signaling mechanism consuming resources at a time when routers are the most > busy > Consistent flooding rates will require updated hellos be sent to all > neighbors – exacerbating the cost on both sender and receiver This is why I suggest sending the feedback in PSNPs as well as in IIHs. Regardless of the details, we need to consider sending PSNPs back more frequently. I concur that optimizing the rate and triggers for sending more PSNPs is an open issue. Strictly speaking, sending a TLV inside of our protocol PDUs is an in-band signaling mechanism. The resources consumed by maintaining a running count of a queue in silicon or in process space is effectively zero. Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
