Robert,

> For per peer flow control I do not get how receiver's ISIS process is to come 
> up with per peer timer if it may never see under congestion given peer's LSPs 
> (being dropped on the single RE cp queue or at the interface). 


I’m sorry, but I can’t parse this comment.  The intent is not for the receiver 
to specify a timer value.  The point is for the receiver to provider the LSP 
sender with feedback about available resources on the receiver. This can inform 
the sender’s computation of a reasonable transmit bandwidth.


> Perhaps such flag to "slow down guys" could be send by receiver uniformly to 
> all peers when under LSP flooding congestion ?


That’s effectively what we’re proposing, tho it need not be a binary flag.  It 
allows us to do simpler things saying “we’re running out of buffer space, 
please slow down a bit”. Again the goal is to find the optimal goodput.  
Granularity in the feedback will be helpful.

Tony


_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to