Subject: RE: [Isis-wg] About MTU?

From: Jeff Parker <[email-masked]>
Date: Fri, 26 Apr 2002 10:27:33 -0400

> It was forwarded to this list or it's on my or  maybe 
> jeff's plate to get it forwarded to this list via a 
> liason if I'm not mistaken.  I better go and check my 
> to-do list ;-)
> 
>     - -tony

Right.  This is on the "update list"'s plate.  I should
have replied earlier.  Here is the text I have at present:
the major work is Les' while the errors are mine.  

- jdp

8.0 ReceiveLSPBufferSize

   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)  Available Link MTU for supported Circuits (MTU).  Note this
          may differ from the MTU available to IP clients.

   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 implementor 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
   system 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 Notifica-
          tions and Alarms.

     (5)  Report the receipt of a PDU larger than the local ReceiveL-
          SPBufferSize 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 misscon-
          figured network.

   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.

<EOT>

> SelvarajR wrote:
> 
> > Hi,
> > I guess the latest 10589v2 address this by defining new TLV.
> > But apologies in advance that I'm not well sure about that.
> > The idea is that all the ISIS process in the domain 
> agreeing upon for the
> > least MTU in the domain. All  ISIS process should advertise 
> their least
> > interface MTU(among on which ISIS is enabled, ofcourse) in 
> their LSPs. Then,
> > each ISIS process shall scan there LSP data base and select 
> the least MTU
> > among those advertised in the LSP, including its own LSP. 
> This least MTU
> > shall be used as the LSPBufferSize. If there is any change 
> in the current
> > LSPBufferSize then the ISIS process shall restart.
> >
> > For this all the ISIS process should support the new TLV.
> > This mechanism may have quite few number of ISIS process 
> restart as an
> > overhead.
> > No Pain No Gain ;)
> > I guess this may solve the problem.
> 
> yes, there is a proposal hanging, other people are better 
> informed than
> me. It was forwarded to this list or it's on my or  maybe 
> jeff's plate to
> get it forwarded to this list via a liason if I'm not mistaken.
> I better go and check my to-do list ;-)
> 
>     - -tony
> 
> 
> _______________________________________________
> Isis-wg mailing list  -  [email-masked]
> http://spider.juniper.net/mailman/listinfo/isis-wg
> 
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg