[isis-update] ReceiveLSPBufferSize - first round

[Jeff Parker <jparker@axiowave.com>]

- I have hashed this over a bit with Les G. and Neal C this weekend.
  They had helpful comments.

- jdp

7.0 Assuring a Common Buffer Size

   Since IS-IS does not allow segmentation of protocol PDUs, Link State
   PDUs (LSPs) must be propagated without modification on all IS-IS
   enabled links throughout the area/domain. Thus it is essential to
   configure a maximum size that all routers can forward, receive, and
   store.

   This affects three aspects, which we discuss in turn:

(1)  The largest LSP we can receive (ReceiveLSPBufferSize)

(2)  The size of the largest LSP we can generate
     (originatingL1LSPBufferSize and originatingL2LSPBufferSize)

(3)  Link MTU for supported Circuits

   The protocol provides the architectural constant ReceiveLSPBufferSize
   with value 1492 bytes, and two private management parameters,
   originatingL1LSPBufferSize for level 1 PDUs and
   originatingL2LSPBufferSize for level 2 PDUs. The originating Buffer
   Size parameters define the maximum size of an LSP that a router can
   generate.  The protocol directs the implementer to treat a PDU larger
   than ReceiveLSPBufferSize as an error.

   It is crucial that
          originatingL1LSPBufferSize <= ReceiveLSPBufferSize
          originatingL2LSPBufferSize <= ReceiveLSPBufferSize
   and that for all L1 links in the area
          originatingL1LSPBufferSize <= MTU
   and for all L2 links in the domain
          originatingL2LSPBufferSize <= MTU
   The original thought was that operators could decrease the originat-
   ing Buffer size when dealing with smaller MTUs, but would not need to
   increase ReceiveLSPBufferSize beyond 1492.

   With the definition of new information to be advertised in LSPs, such
   as the Traffic Engineering TLVs, the limited space of the LSP data-
   base which may be generated by each router (256 * 1492 bytes at each
   level) has become an issue. Given that modern networks with MTUs
   larger than 1492 on all links are not uncommon, one method which can
   be used to expand the LSP database size is to allow values of
   ReceiveLSPBufferSize greater than 1492.

   Allowing ReceiveLSPBUfferSize to become a configurable parameter
   rather than an architectural constant must be done with care: if any
   router A in the network does not support values larger than 1492 or
   one or more link MTUs used by IS-IS anywhere in the area/domain is
   smaller than the largest LSP which may be generated by any router,
   then full propagation of all LSPs may not be possible.

   The steps below are recommended when changing ReceiveLSPBufferSize.

(1)  Set the ReceiveLSPBufferSize to a consistent value throughout the
     network.

(2)  The implementation should not enable IS-IS on circuits which do not
     support an MTU at least as large as the originating BufferSize at
     the appropriate level.

(3)  Include a originatingLSPBufferSize TLV when generating LSPs, as
     described in section 9.8 of [3].

(4)  When receiving LSPs, check for an originatingLSPBufferSize TLV, and
     report the receipt of values larger than the local value of
     ReceiveLSPBufferSize through the defined Notifications and Alarms.

(5)  Report the receipt of a PDU larger than the local ReceiveLSPBuffer-
     Size through the defined Notifications and Alarms.

(6)  Do not discard large PDUs by default.  Storing and processing them
     as normal PDUs may help maintain coherence in a missconfigured net-
     work.

   Steps 1 and 2 are enough by themselves, but the consequences of
   mismatch are serious enough and difficult enough to detect, that
   steps 3-6 are recommended to help track down and correct problems.