Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

["Les Ginsberg (ginsberg)" <[e-mail]>]

Tony -

From: Tony Li <[e-mail]> On Behalf Of [e-mail]
Sent: Tuesday, February 18, 2020 10:16 PM
To: Les Ginsberg (ginsberg) <[e-mail]>
Cc: [e-mail]
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

The TX side flow control is purely based on performance on each interface – there are no implementation requirements imposed or implied as regards the receiver.

Then the LSP transmitter is operating without information from the LSP receiver. Additional information from the receiver can help the transmitter maintain a more accurate picture of reality and adapt to it more quickly.

[Les:] This is your claim – but you have not provided any specifics as to how information sent by the receiver would provide better adaptability than a Tx based flow control which is based on actual performance.
Nor have you addressed how the receiver would dynamically calculate the values it would send. For me how to do this is not at all obvious given common implementation issues such as:


  *   Sharing of a single punt path queue among many incoming protocols/incoming interfaces
  *   Single interface independent input queue to IS-IS itself, making it difficult to track the contribution of a single interface to the current backlog
  *   Distributed dataplanes

If we are to introduce new signaling/protocol extensions there needs to be good reason and it must be practical to implement – especially since we have an alternate solution which is practical to implement, dynamically responds to current state, and does not require any protocol extensions.

    Les