Re: [isis-update] ReceiveLSPBufferSize - first round

[Jeff Learman <jlearman@cisco.com>]

At 03:14 PM 4/8/2002, Jeff Parker wrote:
>- 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

"Ensure" would be better.

>   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

Since you don't refer to A below, you can drop it.

>   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.

Did we decide not to mention to ignore 10589 about treating too-large LSPs
by purging them, or is that covered under another topic?
I think this is another item where we can refer to ISIS:2001.

Jeff