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

[Tony Przygienda]

I was refering to RFC4960. Bruno, for all practical purposes I think that
seems to go down the path of trying to reinvent RFC4960 (or ultimately use
it). Or, changing the packet formats heavily to incorporate all the control
loop data you need to the point you have a different control channel along
those lines since you'll find most of the problems RFC4960 is describing
(minus stuff like multiple paths). Nothing wrong with that but it's
ambitious on a 30 years old anitque artefact we're nursing forward here ;-)
As entertaining footnote, I saw in last 20 years at least 3 attempts to
allow multiple TCP sessions in BGP between peers to speed/prioritize things
up. All failed, after the first one I helped to push I smarted up ;-)

As another footnote: I looked @ all the stuff in RIFT (tcp, quic, 4960,
more ephemeral stuff). I ended up adding to rift bunch very rudimentary
things and do roughly what Les/Peter/Acee started to write (modulo algorith
I contributed and bunch things that would be helpful but we can't fit into
existing packet format). This was as much decision as to "what's available
& well debugged" as well as "does it meet requirements" as "how complex is
that vs. rtx in flooding architecture  we have today + some feedback". Not
on powerpoint, in real production code ;-) rift draft shows you the outcome
of that as IMO best trade-off to achieve high flooding speeds ;-)

my 2c

-- tony

On Thu, Apr 23, 2020 at 10:15 AM  wrote:

> Tony,
>
> Thanks for engaging.
>
> Please inline [Bruno2]
>
>
>
>
>
>
>
> *From:* Tony Przygienda [mailto:tonysi...@gmail.com]
> *Sent:* Wednesday, April 22, 2020 9:25 PM
> *To:* DECRAENE Bruno TGI/OLN
> *Cc:* lsr@ietf.org; Les Ginsberg (ginsberg)
> *Subject:* Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
>
>
>
>
>
>
> On Wed, Apr 22, 2020 at 11:03 AM  wrote:
>
> Tony, all,
>
>
>
> Thanks Tony for the technical and constructive feedback.
>
> Please inline [Bruno]
>
>
>
> *From:* Tony Przygienda [mailto:tonysi...@gmail.com]
> *Sent:* Wednesday, April 22, 2020 1:19 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* DECRAENE Bruno TGI/OLN; lsr@ietf.org
> *Subject:* Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
>
>
> neither am I aware of anything like this (i.e. per platform/product
> flooding rate constants) in any major vendor stack for whatever that's
> worth. It's simply unmaintanable, point. All major vendors have extensive
> product lines over so many changing hardware configuration/setups it is
> simply not viable to attempt precise measurements (and even then, user
> changing config can throw the stuff off in a millisecond). There may have
> been here and there per deployment scenario some "recommended config"
> (not something I immediately recall either) but that means very fixed
> configuration of things & how they go into networks and even then I'm not
> aware of anyone having had a "precise model of the chain in the box". yes,
> probes to measure lots and lots of stuff in the boxes exist but again,
> those are chip/linecard/backplane/chassis/routing engine specific and
> mostly used in complex test/peformance scenarios and not to derive some
> kind of equations that can predict anything much ...
>
> [Bruno] Good points.
>
> Yet, one of the information that we propose to advertise by the LSP
> receiver to the LSP sender is the Receive Window.
>
> -  This is a very common parameter and algorithm. Nothing fancy
> nor reinvented. In particular it’s a parameter used by TCP.
>
> -  I would argue that TCP implementations also run on a variety
> of hardware and systems, must wider range than IS-IS platform. And those
> TCP implementations on all those platform manage to advertise this
> parameter (TCP window)
>
> -  I fail to understand that when some WG contributors proposed
> the use of TCP, nobody said that determining and advertising a Receive
> Window would be an issue, difficult or even impossible. But when we propose
> to advertise a Receive Window in an IS-IS TLV, this becomes difficult or
> even impossible for some platforms. Can anyone help me understand the
> technical difference?
>
>
>
>
>
> Bruno, I was waiting for that ;-)
>
> [Bruno2] Good ;-)
>
>
>
> Discounted for the fact that I'm not a major TCP expert: TCP is a very
> different beast. it has a 100-200msec fast timer & 500msec slow (which have
> to be quite accurate, it's really one timer for all connections + mbuf
> and other magic) and it sends a _lot_ of packets back and forth with window
> size indications so the negotiation can happen very quickly.  Also, TCP
> can detect losses based on sequence number received contrary to routing
> protocols (that's one of the things we added in RIFT BTW) and it can
> retransmit quickly when it sees a "hole". Contrary to that in ISIS ACKs may
> or may not come, they may be bundled, hellos may or may not come and we
> can't retransmit stuff on 100msec timers either. It's an utterly different
> transport channel.
>
> [Brun

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

[bruno.decraene]

Tony,
Thanks for engaging.
Please inline [Bruno2]



From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Wednesday, April 22, 2020 9:25 PM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org; Les Ginsberg (ginsberg)
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed



On Wed, Apr 22, 2020 at 11:03 AM 
mailto:bruno.decra...@orange.com>> wrote:
Tony, all,

Thanks Tony for the technical and constructive feedback.
Please inline [Bruno]

From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Wednesday, April 22, 2020 1:19 AM
To: Les Ginsberg (ginsberg)
Cc: DECRAENE Bruno TGI/OLN; lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

neither am I aware of anything like this (i.e. per platform/product flooding 
rate constants) in any major vendor stack for whatever that's worth. It's 
simply unmaintanable, point. All major vendors have extensive product lines 
over so many changing hardware configuration/setups it is simply not viable to 
attempt precise measurements (and even then, user changing config can throw the 
stuff off in a millisecond). There may have been here and there per deployment 
scenario some "recommended config" (not something I immediately recall either) 
but that means very fixed configuration of things & how they go into networks 
and even then I'm not aware of anyone having had a "precise model of the chain 
in the box". yes, probes to measure lots and lots of stuff in the boxes exist 
but again, those are chip/linecard/backplane/chassis/routing engine specific 
and mostly used in complex test/peformance scenarios and not to derive some 
kind of equations that can predict anything much ...
[Bruno] Good points.
Yet, one of the information that we propose to advertise by the LSP receiver to 
the LSP sender is the Receive Window.

-  This is a very common parameter and algorithm. Nothing fancy nor 
reinvented. In particular it’s a parameter used by TCP.

-  I would argue that TCP implementations also run on a variety of 
hardware and systems, must wider range than IS-IS platform. And those TCP 
implementations on all those platform manage to advertise this parameter (TCP 
window)

-  I fail to understand that when some WG contributors proposed the use 
of TCP, nobody said that determining and advertising a Receive Window would be 
an issue, difficult or even impossible. But when we propose to advertise a 
Receive Window in an IS-IS TLV, this becomes difficult or even impossible for 
some platforms. Can anyone help me understand the technical difference?


Bruno, I was waiting for that ;-)
[Bruno2] Good ;-)

Discounted for the fact that I'm not a major TCP expert: TCP is a very 
different beast. it has a 100-200msec fast timer & 500msec slow (which have to 
be quite accurate, it's really one timer for all connections + mbuf and other 
magic) and it sends a _lot_ of packets back and forth with window size 
indications so the negotiation can happen very quickly.  Also, TCP can detect 
losses based on sequence number received contrary to routing protocols (that's 
one of the things we added in RIFT BTW) and it can retransmit quickly when it 
sees a "hole". Contrary to that in ISIS ACKs may or may not come, they may be 
bundled, hellos may or may not come and we can't retransmit stuff on 100msec 
timers either. It's an utterly different transport channel.
[Bruno2] I would distinguish two things, which I think we have done in 
https://tools.ietf.org/html/draft-decraene-lsr-isis-flooding-speed-03

-  How fast you can adapt the sending rate. This seems mostly dependent 
on the speed of the feedback loop, rather than the format of message. E.g. In 
IS-IS the receiver can give a feedback more or less quickly (e.g. depending on 
how fast/bundled it sends the PSNP). In theory, I don’t see a major different. 
From an in implementation standpoint, I’m guessing that the difference is 
probably bigger (e.g. TCP is probably lower level/closer to the 
system/hardware, than IS-IS which is more user space and possibly Platform 
Independent in some organizations))

-  How fast you can detect packet loss. I agree that TCP & IS-IS are 
very different on this. We have proposed to improve this by allowing the 
receiver to advertise to the sender how fast it will ack the LSP. Currently the 
timer/behavior is known to receiver but no to the sender. Hence the sender 
needs to assume the wort case (ISO default).

In more abstract terms, TCP is a sliding N-window protocol (where N is adjusted 
all the time & losses can be efficiently detected) whereas LSR flooding is not 
a windowing protocol (or rather LSDB-size window protocol with selective 
retransmission but no detection of loss [or only very slow based on lack of ACK 
& CSNPs]). Disadvantage of something like TCP (I think I sent out the RFC with 
UDP control protocol work to make it more TCP like)
[Bruno2]  If you are referring to DCCP

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

[Peter Psenak]

Bruno,

On 23/04/2020 10:57, bruno.decra...@orange.com wrote:

Peter,
  

From: Peter Psenak [mailto:ppse...@cisco.com]

Bruno,

On 22/04/2020 20:04, bruno.decra...@orange.com wrote:

Les,

Pleasesee inline

*From:*Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
*Sent:* Tuesday, April 21, 2020 11:48 PM
*To:* DECRAENE Bruno TGI/OLN
*Cc:* lsr@ietf.org
*Subject:* RE: Flow Control Discussion for IS-IS Flooding Speed

Bruno –

You have made an assumption that historically vendors have tuned LSP
transmission rates to a platform specific value.

[Bruno] I don’t think so. What makes you think so?

In all cases, that is not my assumption, and for multiple reasons.

That certainly is not true in the case of my employer (happy to hear
what other vendors have been doing for the past 20 years).

The default value is based on minimumBroadcastLSPTransmissionInterval
specified in ISO10589.

A knob is available to allow tuning (faster or slower) in a given
deployment – though in my experience this knob is rarely used.

*//*[Bruno] I would agree on both. More interestingly is the why: why
aren’t those existing sending parameters tuned, while we agree that
default configuration are suboptimal?

My take is that:

-We don’t want to overload the receiver and create loss of LSP (as this
will delay the LSDB synchronization and decrease the goodput). Hence
this (the parameters) is receiver dependent (e.g., platform type, number
of IGP adjacencies, …).

-We don’t know which value to configure : difficult for the network
operator to evaluate without a significant knowledge of the receiver
implementation (in particular QoS parameters for incoming LSP), vendors
are not really proposing value or guidance, especially since the sending
behavior is not standardized and slightly different between vendors. So
everyone stay safe with default 20 years old values.

We already discuss in
https://tools.ietf.org/html/draft-ginsberg-lsr-isis-flooding-scale-02#section-2
that this common interpretation isn’t the most appropriate, but
historically the concern has been to avoid flooding too fast – not to
optimize flooding speed.

Obviously, we are revisiting that approach and saying it needs to change
– which is something I think we have consensus on.

I have provided a description in my recent response as to why it is
difficult to derive an optimal value on a per platform basis. You may
disagree – but please do not claim that we actually have been doing this
for years. We haven’t been.

*//*[Bruno] I’m not sure how to rephrase my below email so that we could
understand each other, have an answer from your side (I mean employer
side), and progress.

More succinctly: How do network operator correctly configure the
flooding parameters value on the implementation of your employer? In
particular given the variety of conditions on the LSP receiver side.


the answer is test and see which value fits best in your specific
environment.


I don't think that's good enough, or even feasible given the very diverse set 
of platforms and environments in large networks, and/or the availability of 
human resources in smaller networks.
Since Les is reporting that virtually nobody is changing the default value 
-although we now all agree that they are suboptimal- I think that this is an 
indication that this strategy is not working.
That's why I brought this to the LSR WG.


we agree on the problem and the solution, for most part anyway.

I responded with the only option that is available today with existing 
protocol behavior and parameters available today.


thanks,
Peter





We need the IS-IS protocol to work adequately without requiring constant or 
personalized tuning from the network operator. Coming back to TCP, general 
user/terminals are not been asked to run test per terminal and per 
destination/server. It just work relatively adequately.
  

One reason to have some sort of feedback mechanism (being it tx or rx
based) is to avoid the need to tune today's static parameters and flood
as fast as the receiver is able to consume and slow down if the receiver
is not able to cope with the rate we flood.


+1
  
Thanks,

Bruno


thanks,
Peter








--Bruno

Les

*From:*bruno.decra...@orange.com 
*Sent:* Monday, April 20, 2020 4:47 AM
*To:* Les Ginsberg (ginsberg) 
*Cc:* lsr@ietf.org
*Subject:* RE: Flow Control Discussion for IS-IS Flooding Speed

Les,

After nearly 2 months, can we expect an answer from your side?

More specifically, the below question

[Bruno] _Assuming_ that the parameters are static, the parameters
proposed in draft-decraene-lsr-isis-flooding-speed are the same as the
one implemented (configured) on multiple implementations, including the
one from your employer.

Now do you believe that those parameters can be determined?

§  If yes, how do you do _today_ on your implementation? (this seems to
contradict your statement that you have no way to figure out how to find
the right value)

§  If no, why did you implement those parameters, an

[Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-08.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : IS-IS Extension to Support Segment Routing over IPv6 
Dataplane
Authors : Peter Psenak
  Clarence Filsfils
  Ahmed Bashandy
  Bruno Decraene
  Zhibo Hu
Filename: draft-ietf-lsr-isis-srv6-extensions-08.txt
Pages   : 26
Date: 2020-04-23

Abstract:
   Segment Routing (SR) allows for a flexible definition of end-to-end
   paths by encoding paths as sequences of topological sub-paths, called
   "segments".  Segment routing architecture can be implemented over an
   MPLS data plane as well as an IPv6 data plane.  This draft describes
   the IS-IS extensions required to support Segment Routing over an IPv6
   data plane.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-08
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-srv6-extensions-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

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

[bruno.decraene]

Peter,
 
> From: Peter Psenak [mailto:ppse...@cisco.com] 
> 
> Bruno,
> 
> On 22/04/2020 20:04, bruno.decra...@orange.com wrote:
> > Les,
> > 
> > Pleasesee inline
> > 
> > *From:*Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> > *Sent:* Tuesday, April 21, 2020 11:48 PM
> > *To:* DECRAENE Bruno TGI/OLN
> > *Cc:* lsr@ietf.org
> > *Subject:* RE: Flow Control Discussion for IS-IS Flooding Speed
> > 
> > Bruno –
> > 
> > You have made an assumption that historically vendors have tuned LSP 
> > transmission rates to a platform specific value.
> > 
> > [Bruno] I don’t think so. What makes you think so?
> > 
> > In all cases, that is not my assumption, and for multiple reasons.
> > 
> > That certainly is not true in the case of my employer (happy to hear 
> > what other vendors have been doing for the past 20 years).
> > 
> > The default value is based on minimumBroadcastLSPTransmissionInterval 
> > specified in ISO10589.
> > 
> > A knob is available to allow tuning (faster or slower) in a given 
> > deployment – though in my experience this knob is rarely used.
> > 
> > *//*[Bruno] I would agree on both. More interestingly is the why: why 
> > aren’t those existing sending parameters tuned, while we agree that 
> > default configuration are suboptimal?
> > 
> > My take is that:
> > 
> > -We don’t want to overload the receiver and create loss of LSP (as this 
> > will delay the LSDB synchronization and decrease the goodput). Hence 
> > this (the parameters) is receiver dependent (e.g., platform type, number 
> > of IGP adjacencies, …).
> > 
> > -We don’t know which value to configure : difficult for the network 
> > operator to evaluate without a significant knowledge of the receiver 
> > implementation (in particular QoS parameters for incoming LSP), vendors 
> > are not really proposing value or guidance, especially since the sending 
> > behavior is not standardized and slightly different between vendors. So 
> > everyone stay safe with default 20 years old values.
> > 
> > We already discuss in 
> > https://tools.ietf.org/html/draft-ginsberg-lsr-isis-flooding-scale-02#section-2
> >  
> > that this common interpretation isn’t the most appropriate, but 
> > historically the concern has been to avoid flooding too fast – not to 
> > optimize flooding speed.
> > 
> > Obviously, we are revisiting that approach and saying it needs to change 
> > – which is something I think we have consensus on.
> > 
> > I have provided a description in my recent response as to why it is 
> > difficult to derive an optimal value on a per platform basis. You may 
> > disagree – but please do not claim that we actually have been doing this 
> > for years. We haven’t been.
> > 
> > *//*[Bruno] I’m not sure how to rephrase my below email so that we could 
> > understand each other, have an answer from your side (I mean employer 
> > side), and progress.
> > 
> > More succinctly: How do network operator correctly configure the 
> > flooding parameters value on the implementation of your employer? In 
> > particular given the variety of conditions on the LSP receiver side.
> 
> the answer is test and see which value fits best in your specific 
> environment.

I don't think that's good enough, or even feasible given the very diverse set 
of platforms and environments in large networks, and/or the availability of 
human resources in smaller networks.
Since Les is reporting that virtually nobody is changing the default value 
-although we now all agree that they are suboptimal- I think that this is an 
indication that this strategy is not working.
That's why I brought this to the LSR WG.

We need the IS-IS protocol to work adequately without requiring constant or 
personalized tuning from the network operator. Coming back to TCP, general 
user/terminals are not been asked to run test per terminal and per 
destination/server. It just work relatively adequately.
 
> One reason to have some sort of feedback mechanism (being it tx or rx 
> based) is to avoid the need to tune today's static parameters and flood 
> as fast as the receiver is able to consume and slow down if the receiver 
> is not able to cope with the rate we flood.

+1
 
Thanks,
Bruno

> thanks,
> Peter
> 
> 
> 
> 
> 
> 
> > 
> > --Bruno
> > 
> >Les
> > 
> > *From:*bruno.decra...@orange.com 
> > *Sent:* Monday, April 20, 2020 4:47 AM
> > *To:* Les Ginsberg (ginsberg) 
> > *Cc:* lsr@ietf.org
> > *Subject:* RE: Flow Control Discussion for IS-IS Flooding Speed
> > 
> > Les,
> > 
> > After nearly 2 months, can we expect an answer from your side?
> > 
> > More specifically, the below question
> > 
> > [Bruno] _Assuming_ that the parameters are static, the parameters 
> > proposed in draft-decraene-lsr-isis-flooding-speed are the same as the 
> > one implemented (configured) on multiple implementations, including the 
> > one from your employer.
> > 
> > Now do you believe that those parameters can be determined?
> > 
> > §  If yes, how do you do _today_ on your implementatio

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

[Peter Psenak]

Bruno,

On 22/04/2020 20:04, bruno.decra...@orange.com wrote:

Les,

Pleasesee inline

*From:*Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
*Sent:* Tuesday, April 21, 2020 11:48 PM
*To:* DECRAENE Bruno TGI/OLN
*Cc:* lsr@ietf.org
*Subject:* RE: Flow Control Discussion for IS-IS Flooding Speed

Bruno –

You have made an assumption that historically vendors have tuned LSP 
transmission rates to a platform specific value.


[Bruno] I don’t think so. What makes you think so?

In all cases, that is not my assumption, and for multiple reasons.

That certainly is not true in the case of my employer (happy to hear 
what other vendors have been doing for the past 20 years).


The default value is based on minimumBroadcastLSPTransmissionInterval 
specified in ISO10589.


A knob is available to allow tuning (faster or slower) in a given 
deployment – though in my experience this knob is rarely used.


*//*[Bruno] I would agree on both. More interestingly is the why: why 
aren’t those existing sending parameters tuned, while we agree that 
default configuration are suboptimal?


My take is that:

-We don’t want to overload the receiver and create loss of LSP (as this 
will delay the LSDB synchronization and decrease the goodput). Hence 
this (the parameters) is receiver dependent (e.g., platform type, number 
of IGP adjacencies, …).


-We don’t know which value to configure : difficult for the network 
operator to evaluate without a significant knowledge of the receiver 
implementation (in particular QoS parameters for incoming LSP), vendors 
are not really proposing value or guidance, especially since the sending 
behavior is not standardized and slightly different between vendors. So 
everyone stay safe with default 20 years old values.


We already discuss in 
https://tools.ietf.org/html/draft-ginsberg-lsr-isis-flooding-scale-02#section-2 
that this common interpretation isn’t the most appropriate, but 
historically the concern has been to avoid flooding too fast – not to 
optimize flooding speed.


Obviously, we are revisiting that approach and saying it needs to change 
– which is something I think we have consensus on.


I have provided a description in my recent response as to why it is 
difficult to derive an optimal value on a per platform basis. You may 
disagree – but please do not claim that we actually have been doing this 
for years. We haven’t been.


*//*[Bruno] I’m not sure how to rephrase my below email so that we could 
understand each other, have an answer from your side (I mean employer 
side), and progress.


More succinctly: How do network operator correctly configure the 
flooding parameters value on the implementation of your employer? In 
particular given the variety of conditions on the LSP receiver side.


the answer is test and see which value fits best in your specific 
environment.


One reason to have some sort of feedback mechanism (being it tx or rx 
based) is to avoid the need to tune today's static parameters and flood 
as fast as the receiver is able to consume and slow down if the receiver 
is not able to cope with the rate we flood.


thanks,
Peter








--Bruno

   Les

*From:*bruno.decra...@orange.com 
*Sent:* Monday, April 20, 2020 4:47 AM
*To:* Les Ginsberg (ginsberg) 
*Cc:* lsr@ietf.org
*Subject:* RE: Flow Control Discussion for IS-IS Flooding Speed

Les,

After nearly 2 months, can we expect an answer from your side?

More specifically, the below question

[Bruno] _Assuming_ that the parameters are static, the parameters 
proposed in draft-decraene-lsr-isis-flooding-speed are the same as the 
one implemented (configured) on multiple implementations, including the 
one from your employer.


Now do you believe that those parameters can be determined?

§  If yes, how do you do _today_ on your implementation? (this seems to 
contradict your statement that you have no way to figure out how to find 
the right value)


§  If no, why did you implement those parameters, and ask network 
operator to configure them?


Thank you,

--Bruno

*From:*DECRAENE Bruno TGI/OLN
*Sent:* Wednesday, February 26, 2020 8:03 PM
*To:* 'Les Ginsberg (ginsberg)'
*Cc:* lsr@ietf.org 
*Subject:* RE: Flow Control Discussion for IS-IS Flooding Speed

Les,

Please see inline[Bruno]

*From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Les Ginsberg 
(ginsberg)

*Sent:* Wednesday, February 19, 2020 3:32 AM
*To:* lsr@ietf.org 
*Subject:* Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Base protocol operation of the Update process tracks the flooding of

LSPs/interface and guarantees timer-based retransmission on P2P interfaces

until an acknowledgment is received.

Using this base protocol mechanism in combination with exponential 
backoff of the


retransmission timer provides flow control in the event of temporary 
overload


of the receiver.

This mechanism works without protocol extensions, is dynamic, operates

independent of the reason for de