Network Working Group                                        B. Decraene
Internet-Draft                                                    Orange
Intended status: Standards Track                               C. Bowers
Expires: September 10, 2020                                    Jayesh. J
                                                  Juniper Networks, Inc.
                                                                   T. Li
                                                         Arista Networks
                                                         G. Van de Velde
                                                                   Nokia
                                                           March 9, 2020


                IS-IS Flooding Parameters advertisement
               draft-decraene-lsr-isis-flooding-speed-03

Abstract

   This document proposes a mechanism that can be used to increase the
   speed at which link state information is exchanged between two
   routers when multiple LSPs need to be flooded, such as in case of a
   node failure.  It also reduces the likelihood of overloading the
   router receiving the LSPs.  This document defines a new TLV to be
   advertised in SNP and or Hello messages.  This TLV may carry a set of
   parameters indicating the performance capacity to receive LSPs: the
   number of LSPs which can the received back to back, the minimum delay
   between further two consecutive LSPs and the minimum delay before
   retransmission of an LSP.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 10, 2020.







Decraene, et al.       Expires September 10, 2020               [Page 1]


Internet-Draft   IS-IS Flooding Parameters advertisement      March 2020


Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Flooding Parameters TLV . . . . . . . . . . . . . . . . . . .   4
     2.1.  InterfaceLSPReceiveWindow sub-TLV . . . . . . . . . . . .   5
     2.2.  minimumInterfaceLSPTransmissionInterval sub-TLV . . . . .   5
     2.3.  minimumLSPTransmissionInterval sub-TLV  . . . . . . . . .   5
   3.  Operation on a point to point interface . . . . . . . . . . .   6
   4.  Faster acknowledgments of LSPs  . . . . . . . . . . . . . . .   6
   5.  Faster retransmission of lost LSPs  . . . . . . . . . . . . .   7
   6.  Operation on a LAN interface  . . . . . . . . . . . . . . . .   8
   7.  Interaction with other LSP rate limiting mechanisms . . . . .   9
   8.  Determining values to be advertised in the Flooding
       Parameters TLV  . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  10
     10.1.  Acknowledgments  . . . . . . . . . . . . . . . . . . . .  11
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     11.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Appendix A.  Changes / Author Notes . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   IGP flooding is paramount for Link State IGP as routing computations
   assume that the Link State DataBases (LSDBs) are always in sync
   across all nodes in the flooding domain.

   Slow flooding directly translates to delayed network reaction to
   failure and LSDB inconsistencies across nodes.  The former increases
   packet loss.  The latter translates to routing inconsistencies and



Decraene, et al.       Expires September 10, 2020               [Page 2]


Internet-Draft   IS-IS Flooding Parameters advertisement      March 2020


   possibly micro-loops leading to packet loss, link overload, and
   jitter for all classes of service.  Note that across the network,
   multiple links may be affected by these forwarding issues, even in
   the case of a single link failure.

   In addition, one single event in the network can require the flooding
   of multiple LSPs.  The typical case is a node failure which requires
   the flooding of at least one LSP per neighbor of the failed node.
   Hence, if a node has N IGP neighbors, the failure of this node
   requires the advertisement and flooding of at least N LSPs.  The
   network won't be able to converge to the new topology until all N
   LSPs are received by all nodes.  Hence there is a need to be able to
   quickly exchange N LSPs.  This document addresses this requirement by
   allowing the fast flooding of some number of consecutive LSPs.

   IGP flooding is hard.  One would want fast flooding when the network
   is stable and slow enough flooding to not overload the neighbor(s)
   when the network is less stable.  Since flooding is performed hop by
   hop, not overloading the adjacent receiver is sufficient.  This
   document addresses these requirements by having the receiving node
   advertise the rate at which it can receive LSPs, using a TLV in SNP
   and/or IS-IS Hello (IIH) messages.  This allows the LSP transmitter
   to adapt to the receiver capability and to send LSP quickly, but not
   too quickly.  This avoids both unnecessary transmission delays and
   overloading the receiving IS.  Multiple flooding parameters may be
   advertised through the use of sub-TLVs.

   One parameter in the advertisement is the LSP receive window.  This
   is the number of un-acknowledged LSPs that the IS transmitter may
   send at any rate, including back to back.

   Another parameter in the advertisement is the shaping delay between
   two consecutive LSPs, once the received window is full.

   Note that this parameterization of flooding behavior is aligned with
   existing implementations: with an LSP receive window of 1, most
   implementations already implement the shaping between LSPs.  And some
   implementations allows for the fast sending of N LSPs with no shaping
   delay.  Existing implementations rely on parameters statically
   configured on the transmitter to control the transmission rate.
   However, the need is to prevent overloading the receiver.  In theory,
   the transmission rate parameter could be configured on each IS
   transmitter using the knowledge of each of its neighbor in the
   topology and the receiving capabilities of those neighbors.  However,
   in practice, this configuration is difficult to maintain over time as
   the network topology change.  In addition, as things currently stand,
   each network operator needs to evaluate the receiving capacity of
   each type of platform, depending on its hardware, software version



Decraene, et al.       Expires September 10, 2020               [Page 3]


Internet-Draft   IS-IS Flooding Parameters advertisement      March 2020


   and number of IS-IS adjacencies.  Such platform performance is better
   known by its designer (the vendor).  Even if validation tests are
   required, one single validation test by the vendor is more effective
   than N validations from N network providers.  Finally, the reasoning
   behind the original choices of default value is not clear.  Default
   values have largely remained unchanged over many years, despite very
   large increases in interface speeds and processing speed.  This has
   resulted in default values that are very sub-optimal.  For example,
   typical default values are one LSP per 33ms or 100ms, resulting in
   the ability to only send 30 or 10 LSPs per second.  In contrast, the
   same vendors recommend setting a BGP DDoS policer to 10,000 packets
   per second, which is two or three order of magnitude higher.

   A third parameter in the advertisement is the minimum delay before
   re-transmitting a lost LSP.

   Improving the communication speed and efficiency between IS-IS
   neighbhors improves IS-IS scaling.  These extensions do not compete
   with proposed extensions to reduce LSP flooding traffic by reducing
   the flooding topology such as [I-D.ietf-lsr-dynamic-flooding].
   Instead, the extensions complement those proposals.  Indeed reducing
   the flooding topology does not reduce the size of the LSDB or the
   total number of LSPs to exchange between two nodes.  So increasing
   the overall flooding speed can be beneficial for nodes implementing
   dynamic flooding.  The reverse is also true: as dynamic flooding
   reduces the number of neighbhors with flooding enabled, this allows
   nodes implementing the flooding parameter extensions to focus their
   flooding resources on those neighbhors by sending better parameters
   to the selected flooding nodes and worse parameters to non-selected
   flooding nodes.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
   appear in all capitals, as shown here.

2.  Flooding Parameters TLV

   This document defines a new TLV called "Flooding Parameters TLV" that
   may be included in SNP and/or IIH PDUs.

   Type: TBD1.

   Length: variable, the size in octet of the Value field.




Decraene, et al.       Expires September 10, 2020               [Page 4]


Internet-Draft   IS-IS Flooding Parameters advertisement      March 2020


   Value: a list of sub-TLVs.

   Three sub-TLVs are defined in this document.

2.1.  InterfaceLSPReceiveWindow sub-TLV

   The sub-TLV InterfaceLSPReceiveWindow advertises the maximum number
   of un-acknowledged LSPs that the node can receive/process with no
   separation interval between LSPs.

   Type: 1.

   Length: 4 octets.

   Value: number of un-acknowledged LSPs which can be sent back to back
   .

2.2.  minimumInterfaceLSPTransmissionInterval sub-TLV

   The sub-TLV minimumInterfaceLSPTransmissionInterval advertises the
   minimum interval, in micro-seconds, between LSPs arrivals which can
   be processed/received on this interface, once the maximum number of
   un-acknowledged LSPs has been sent.

   Type: 2.

   Length: 4 octets.

   Value: minimum interval, in micro-seconds, between two consecutive
   LSPs sent after the receive window has been used.

2.3.  minimumLSPTransmissionInterval sub-TLV

   The sub-TLV minimumLSPTransmissionInterval advertises the ISO
   minimumLSPTransmissionInterval, in micro-seconds, that the LSP
   transmitter may use.

   Type: 3.

   Length: 4 octets.

   Value: minimum interval, in micro-seconds, before further propagating
   another Link State PDU from the same source system.








Decraene, et al.       Expires September 10, 2020               [Page 5]


Internet-Draft   IS-IS Flooding Parameters advertisement      March 2020


3.  Operation on a point to point interface

   By sending the InterfaceLSPReceiveWindow sub-TLV with a value N1, the
   node advertises to its IS-IS neighbor, its ability to receive, over
   that interface, a maximum of N1 un-acknowledged LSPs with no
   separation interval.  This is akin to a reception window or sliding
   window in flow control.

   By sending the minimumInterfaceLSPTransmissionInterval sub-TLV with a
   value N2, the node advertises to its IS-IS neighbor, its ability to
   receive, over that interface, after the receive window is full, LSPs
   separated by at least N2 micro-seconds.

   The IS transmitter MUST NOT exceed these parameters.  After having
   send N1 un-acknowledged LSPs, it MUST send the following LSPs with an
   interval of at least N2 micro-seconds between each LSP.

   Note however that if either the LSP transmitter or receiver does not
   adhere to these parameters, for example because of transient
   conditions, this causes no fatal condition to the operation of IS-IS.
   The worst case, the loss of LSP on the IS receiver, is already
   accounted for in [ISO10589].  As per [ISO10589], after a few seconds,
   respectively 2 and 10 by default in [ISO10589], neighbors will
   exchange PSNP (for point to point interface) or CSNP (for broadcast
   interface) and recover from the lost LSPs.  This worst case,
   overrunning the receiver, should however be avoided as those
   additional seconds are impacting the network and the traffic as the
   LSDB in not fully synchronized.  Hence it is better to err on the
   conservative side and to underun the receiver rather then overrun it.

   For a given IS-IS adjacency, the Flooding Parameters TLV does not
   need to be advertised in each SNP and IIS.  The IS transmitter uses
   the latest value received of each parameter (sub-TLV) until a new
   value is advertised by the IS receiver.  Note however that CSNP and
   IIH are not reliability exchanged, hence some PDU may never be
   received.  For a parameter which has never been advertised, the IS
   transmitter use its local default value.  That value SHOULD be
   configurable on a per node basis and MAY be configurable on a per
   interface basis.

4.  Faster acknowledgments of LSPs

   As per [ISO10589], on point to point interfaces, the LSP receiver
   dynamically acknowledges the received LSPs by sending PSNP messages.
   By acknowledging the LSPs before the InterfaceLSPReceiveWindow is
   exhausted, the receiver can achieve dynamic flow control and increase
   the flooding speed without risking to overload any IS-IS router.  If
   the InterfaceLSPReceiveWindow is large enough, the downstream



Decraene, et al.       Expires September 10, 2020               [Page 6]


Internet-Draft   IS-IS Flooding Parameters advertisement      March 2020


   flooding node can acknowledge a set of multiple LSPs up to the
   maximum size of a PSNP (90 LSPs) which allows dynamic flow control
   with limited or even no increasing in the number of PSNPs.

   The way LSPs are acknowledged faster is a local decision on the
   receiving IS.  Without limiting the possibilities, there are at least
   two options:

   o  Reduce partialSNPInterval.  Possibly reduce it even further when
      the IS-IS adjacency initially transitions to the UP state, when a
      large number of LSPs need to be received quickly, until the LSDB
      has been synchronized.  The choice of this lower value is a local
      choice.  It may depends on the (available) processing power of the
      node, the number of adjacencies been brought up at the same time,
      the requirement to synchronise the LSDB more quickly.

   o  Track the number of received and un-acknowledged LSP per interface
      and level, and send a PSNP when the number reaches 90 (max per
      PSNP) or is significant enough e.g., 10 or
      InterfaceLSPReceiveWindow/2.


5.  Faster retransmission of lost LSPs

   As per [ISO10589], an IS transmitter resends a un-acknowledged LSP no
   sooner than minimumLSPTransmissionInterval, which is 5 seconds by
   default.  As this document allows the faster transmission of LSP
   acknoledgement, the transmitter should be able to retransmit faster,
   with a delay compatible (higher) than the partialSNPInterval or the
   delay needed to acknowledge the received LSPs.

   The reception of the parameter minimumLSPTransmissionInterval means
   that the IS transmitter MAY set its minimumLSPTransmissionInterval to
   this value or higher.

   The interval advertised in minimumLSPTransmissionInterval MUST be
   higher than the effective partialSNPInterval of the receiver plus the
   Round Trip Time (RTT) of the interface.  The effective
   partialSNPInterval of the receiver is the maximum amount of time that
   the receiver is expected to take to acknowledge the LSP.  This would
   be the partialSNPInterval on a receiver following only [ISO10589], or
   an effective value if the receiver has implemented a faster method to
   acknowledge LSPs faster, as discussed in Section 4 .  The goal is
   that the receiver should not be telling the transmitter to resend un-
   acknowledged LSPs after waiting for a time shorter than the receiver
   is planning acknowledge LSPs it has actually received.





Decraene, et al.       Expires September 10, 2020               [Page 7]


Internet-Draft   IS-IS Flooding Parameters advertisement      March 2020


   An IS receiver MAY update this value depending on certain conditions.
   For example, it can advertise a higher minimumLSPTransmissionInterval
   value when a large number of LSPs are been received and hence it is
   busy.  Or it can advertise a lower value when an LSP storm has
   passed, especially if there is reason to believe that some LSPs may
   have been lost.

6.  Operation on a LAN interface

   On a LAN interface an IS receiver will generally receive LSPs from
   many IS transmitters.  And the LSPs sent by a given IS transmitter
   will be received by all of the IS receivers.  In this section, we
   clarify how the flooding paramaters should be interpretted in the
   context of a LAN.

   An IS receiver on a LAN will communicate its desired flooding
   paramaters using a single Flooding Parameters TLV, copies of which
   will be received by all N transmitters.  The flooding parameters sent
   by the IS receiver MUST be understood as instructions from the
   receiver to each transmitter about the desired maximum transmit
   characteristics of each transmitter.  For example, the receiver will
   be aware that there are N transmitters that can send LSPs to the
   receiver LAN interface.  In this example, the receiver might want to
   take that into account by advertising a higher value of
   InterfaceLSPTransmissionInterval on this LAN interface than what it
   would advertise on a point to point interface.  When the transmitters
   receive the InterfaceLSPTransmissionInterval value advertised by the
   DIS receiver, the transmitters should rate limit LSPs according to
   the advertised flooding parameters.  They should not apply any
   further interpretation to the flooding parameters advertised by the
   receiver.

   On the other hand, a given IS trasmitter will receive flooding
   paramater advertisements using N different Flooding Parameters TLVs,
   which could carry different flooding parameter values.  A given
   transmitter SHOULD adjust the flooding behavior on this LAN interface
   such that none of the receivers receives more un-acknowledged LSPs or
   LSPs at a higher rate than indicated by their individual flooding
   parameter advertisements.

   In order for the InterfaceLSPReceiveWindow to be a useful parameter,
   an IS transmitter needs to be able to keep track of the number of un-
   acknowledged LSPs it has sent to a given IS receiver.  On a LAN there
   is no explicit acknowledgement of the reciept of LSPs between a given
   IS transmitter and a given IS receiver.  However, an IS transmitter
   on a LAN can infer whether or not any IS receivers on the LAN have
   requested retransmission of LSPs from the DIS by monitoring PSNPs
   generated on the LAN.  If no PSNPs have been generated on the LAN for



Decraene, et al.       Expires September 10, 2020               [Page 8]


Internet-Draft   IS-IS Flooding Parameters advertisement      March 2020


   a suitable period of time, then an IS transmitter can safely set the
   number of un-acknowledged LSPs to zero.

7.  Interaction with other LSP rate limiting mechanisms

   [ISO10589] describes a mechanism that limits the rate at which LSPs
   from the same source system are sent out on interfaces.  (See the
   description of the parameter
   minimumBroadcastLSPTranLSPTransmissionInterval in section 7.3.15.6 of
   [ISO10589] .) In practice, however, router vendors have implemented
   mechanisms that limit the rate of LSPs sent on a given interface.
   This is often configurable on a per-interface basis using 'lsp-
   interval' or 'lsp-pacing-interval' CLI configuration.)  The mechanism
   described in the current document extends the practice of limiting
   the rate of LSPs sent on a given interface, by using parameters
   advertised by the LSP receiver.  When the mechanism described in the
   current document is used, the mechanism described in section 7.3.15.6
   of [ISO10589] is not used.

8.  Determining values to be advertised in the Flooding Parameters TLV

   The values that a receiving IS advertises do not need to be close to
   perfection.  It is OK to be too low and hence not to use the full
   bandwidth or CPU resources.  It is OK to be too high during some
   situation and hence have the receiver drop some LSPs as the IS-IS
   protocol has mechanisms to recover.  What is not OK is to flood
   multiple order of magnitudes slower than both nodes can achieve, or
   to consistently overload the receiver.

   The values may not need to be dynamic as a form of dynamicity is
   provided by the dynamic acknowledgment of LSPs in SNP messages which
   provides a feedback loop on how fast/slower the LSPs are processed by
   the receiver.  By advertising relatively static parameters, we expect
   to produce overall flooding behavior similar to what might be
   achieved by manually configuring per-interface LSP rate limiting on
   all interfaces in the network.  The advertised values may be based,
   for example, on an off line tests of the overall LSP processing speed
   for a particular set of hardware and the number of interfaces
   configured for IS-IS.  With such a formula, the values advertised in
   the Flooding Parameters TLV would only change when additional IS-IS
   interfaces are configured.

   Nevertheless, the values may also be changed dynamically.  In this
   case, care must be taken when choosing the parameters influencing the
   values, in order to avoid undesirable feedback loops.  It would be
   undesirable to use a formula that depends, for example, on an active
   measurement of the instantaneous CPU load to modify the values
   advertised in the Flooding Parameters TLV.  This could introduce



Decraene, et al.       Expires September 10, 2020               [Page 9]


Internet-Draft   IS-IS Flooding Parameters advertisement      March 2020


   feedback into the IGP flooding process that could produce unexpected
   behavior.  The value may also be based on average measured flooding
   statistics: if LSPs are regularly dropped, or the queue regularly
   comes close to being filled, then values may be too high.  On the
   other hand, if the queue is barely used (by IS-IS), then values may
   be too low.

9.  IANA Considerations

   IANA is requested to allocate one TLV from the IS-IS TLV codepoint
   registry.

        Type    Description                    IIH   LSP   SNP   Purge
        ----    ---------------------------    ---   ---   ---   ---
        TBD     Flooding Parameters TLV         y     n     y     n

                                 Figure 1

   TBD: registry for sub-TLVs of the Flooding Parameters TLV.

10.  Security Considerations

   Any new security issues raised by the procedures in this document
   depend upon the ability of an attacker to inject a false but
   apparently valid SNP, the ease/difficulty of which has not been
   altered.

   As with others TLV advertisements, the use of a cryptographic
   authentication as defined in [RFC5304] or [RFC5310] allows the
   authentication of the peer and the integrity of the message.  As this
   document defines a TLV for SNP message, the relevant cryptographic
   authentication is for SNP message.

   In the absence of cryptographic authentication, as IS-IS does not run
   over IP but directly over the link layer, it's considered difficult
   to inject false SNP without having access to the link layer.

   If a false SNP is sent with a Flooding Parameters TLV set to low
   values, the attacker can reduce the flooding speed between the two
   adjacent neighbors which can result in LSDB inconsistencies and
   transient forwarding loops.  However, is not significantly different
   than filtering or altering LSPDUs which would also be possible with
   access to the link layer.  In addition, if the downstream flooding
   neighbor has multiple IGP neighbors, which is typically the case for
   reliability or topological reasons, it would receive LSPs at a
   regular speed from its other neighbors and hence would maintain LSDB
   consistency.




Decraene, et al.       Expires September 10, 2020              [Page 10]


Internet-Draft   IS-IS Flooding Parameters advertisement      March 2020


   If a false SNP is sent with a Flooding Parameters TLV set to high
   values, the attacker can increase the flooding speed which can either
   overload a node or more likely generate loss of LSPs.  However, it is
   not significantly different than sending many LSPs which would also
   be possible with access to the link layer, even with cryptographic
   authentication enabled.  In addition, IS-IS has procedures to detect
   the loss of LSPs and recover.

   This TLV advertisement is not flooded across the network but only
   sent between adjacent IS-IS neighbors.  This would limit the
   consequences in case of forged messages, and also limits the
   dissemination of such information.

10.1.  Acknowledgments

   The authors would like to thank Henk Smit for his review and
   comments.

11.  References

11.1.  Normative References

   [ISO10589]
              International Organization for Standardization,
              "Intermediate system to Intermediate system intra-domain
              routeing information exchange protocol for use in
              conjunction with the protocol for providing the
              connectionless-mode Network Service (ISO 8473)", ISO/
              IEC 10589:2002, Second Edition, Nov 2002.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
              Authentication", RFC 5304, DOI 10.17487/RFC5304, October
              2008, <https://www.rfc-editor.org/info/rfc5304>.

   [RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
              and M. Fanto, "IS-IS Generic Cryptographic
              Authentication", RFC 5310, DOI 10.17487/RFC5310, February
              2009, <https://www.rfc-editor.org/info/rfc5310>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.




Decraene, et al.       Expires September 10, 2020              [Page 11]


Internet-Draft   IS-IS Flooding Parameters advertisement      March 2020


11.2.  Informative References

   [I-D.ietf-lsr-dynamic-flooding]
              Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda,
              T., Cooper, D., Jalil, L., and S. Dontula, "Dynamic
              Flooding on Dense Graphs", draft-ietf-lsr-dynamic-
              flooding-04 (work in progress), November 2019.

Appendix A.  Changes / Author Notes

   [RFC Editor: Please remove this section before publication]

   00: Initial version.

   01: Two notes added in section 3 "Operation".

   02: Refresh, no technical change.

   03: Flooding Parameters TLV: name changed, moved to SNP rather than
   Hello, contains sub-TLVs, parameters encoded in 4 octets.

   Terminology: upstream/downstream terms removed, in favor of terms
   from ISO specification (transmitter, receiver); burst-size rename to
   receive-window.

   Significant editorials changes.

   New section on the faster acknowledgment of LSPs.

   New section on the faster retransmission of lost LSPs.

Authors' Addresses

   Bruno Decraene
   Orange

   Email: bruno.decraene@orange.com


   Chris Bowers
   Juniper Networks, Inc.
   1194 N.  Mathilda Avenue
   Sunnyvale, CA  94089
   USA

   Email: cbowers@juniper.net





Decraene, et al.       Expires September 10, 2020              [Page 12]


Internet-Draft   IS-IS Flooding Parameters advertisement      March 2020


   Jayesh J
   Juniper Networks, Inc.
   1194 N.  Mathilda Avenue
   Sunnyvale, CA  94089
   USA

   Email: jayeshj@juniper.net


   Tony Li
   Arista Networks
   5453 Great America Parkway
   Santa Clara, California  95054
   USA

   Email: tony.li@tony.li


   Gunter Van de Velde
   Nokia
   Copernicuslaan 50
   Antwerp  2018
   Belgium

   Email: gunter.van_de_velde@nokia.com


























Decraene, et al.       Expires September 10, 2020              [Page 13]