Subject: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize

From: Jeff Parker <[email-masked]>
Date: Fri, 25 Apr 2003 09:13:03 -0400

> Jeff,
> 
> Could you please explain the use of this object?
> 
> It seems to me that if I receive a PDU which size
> is greater than isisSysReceiveLSPBufferSize 
> should be dropped. Is that correct?
> 
> I've a couple of  questions in this context.
> 
> 1) How come the major vendors don't allow
>    this object to be configured?
> 
> 2) What was the primary intention of this object?
>    
> Thanks
> Nagi.

Nagi -

The text below tries to capture the issues involved.  

Briefly, to take advantage of large MTU, and to allow
a system to generate more than 1492 x 256 bytes of
content, we may wish to increase the LSP buffer size. 
This option exists on boxes today, deployed in a
network near you.  

But when you use a non-standard buffer size, you
run the risk that some routers won't be able to store
all the data.  Since many configurations fit inside
a small PDU, it may take some time for the problem
to occur, and could take much longer for the problem 
to be diagnosed.  

This variable is one of many features used to
help track problems should this be deployed.  

So in response to your questions

	Q) Should I drop this?

	0) No, don't drop the packet.  As below:

      Do not discard large PDUs by default.  Storing and processing
      them as normal PDUs may help maintain coherence in a miscon-
      figured network.

	Q) Why isn't this configurable everywhere?

	1) For all the usual reasons.  This is a 'new' feature 
	that does not provide any new capability.  My marketing
	guy doesn't see any value in this, and I'm sure your's
	won't either.  And you know how much adding a knob as
	like this can disrupt a release.  

	Remember, that having this variable does not mean that it
	must be settable, from SNMP or from the CLI.  It just 
	provides a way to make your value visible from SNMP.  

	Q) What is this for?

	2) To allow you to assure that a network is well configured,
	and to debug problems if it isn't.

The text below describing the issue is up for review, so 
any suggestions in content or exposition are welcome.

- jeff parker

Internet Draft - draft-ietf-isis-iso-interoperable            Sept. 2002

9. 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
          often differs from the MTU available to IP clients.

   ISO 10589 defines 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. ISO 10589 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, resulting in
   routing loops and black holes.

   The steps below are recommended when changing ReceiveLSPBufferSize.

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

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

     (3)  Include an originatingLSPBufferSize TLV when generating LSPs,
          as described in section 9.8 of the 2001 revision of ISO 10589
          [2].

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

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Jeff Parker <[email-masked]>
Date: Mon, 28 Apr 2003 09:59:58 -0400

In response to Nagi's original question, I will add some text about the
meaning of this variable to the description clause in the document.

Once again, being able to see the value of this variable is useful, even if
we can't change it.  

- jeff parker
- axiowave networks

---

From: Jeff Parker <[email-masked]>
Date: Mon, 28 Apr 2003 10:14:56 -0400

> Why is that a major vendor... sends PDUs
> with size 1497 on Fast-Ethernet interfaces.
> (I don't think we have modified any default parameters.)
> 
> If that is true, Do you think we need to increase the
> default value of this object to 1492?
> 
> -Nagi.
  
Nagi -
	Now I'm confused.  Do you mean increast from 1492?
1492 is the current default value.  If someone is using 1497
packets after stipping the link level overhead, that is 
an error.  The size 1492 is based on the standard encapsulation
on ordinary ethernet, and isn't up for negotiation.  
	And even if this is going on, are 1497 byte LSPs being 
generated, or just Hello packets?  The rules are different.

	The new text is below.  I toyed with saying something
like "We will store LSPs of size isisSysReceiveLSPBufferSize 
unless we are in overload condition.  Larger LSPs will be 
saved as resources permit.  

- jeff parker

    isisSysReceiveLSPBufferSize OBJECT-TYPE
        SYNTAX Unsigned16TC (1492..65535)
        UNITS "bytes"
        MAX-ACCESS read-create
        STATUS current
        DESCRIPTION
            "Size of the largest Buffer we are designed or
             configured to store.  This should be at least 
             as big as the maximum isisSysOrigLSPBuffSize 
             supported by the system.

             If resources allow, we will store and flood LSPs
             larger than isisSysReceiveLSPBufferSize, as this
             can help avoid problems in networks with different
             values for isisSysOrigLSPBuffSize.

             We always store LSPs of size isisSysReceiveLSPBufferSize 
             unless we are in overload condition.  Larger LSPs 
             will be saved as resources permit."
        DEFVAL { 1492 }
    ::= { isisSysEntry 14 }
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Jeff Parker <[email-masked]>
Date: Mon, 28 Apr 2003 10:36:30 -0400

> Jeff,
>          My flaky memory prompts me to recall that the 
> value of 1492 is actually an anachronism caused by DEC's
> original use of a SNAP-SAP Ethernet encoding....

> Hence we COULD have used 1497 as the default, but since 
> we had deployed a bunch with a value of 1492 and it was
> then an architectural constant we didn't want to change 
> it. We figured nobody would worry about an odd 5 bytes.
> 
>          But I agree the standard says 1492 and that is  
> what it should be limited to.
> 
> Mike [Shand]

Mike -
	Shame on me for not looking at the encoding before
replying.  

Nagi -
	I'm still interested in hearing if anyone is using
1497 byte LSPs.  I suspect a lot of systems will break
if they do.  

- jeff parker

---

From: Les Ginsberg <[email-masked]>
Date: Mon, 28 Apr 2003 14:32:59 -0700

>saved as resources permit.

Jeff -

I think you are on slippery ground here.

The issue with larger LSPs is not whether the receiving system has enough 
memory to store them - but rather with whether the LSPs can be propagated 
successfully throughout the network (due to link layer MTU constraints). If 
a system can successfully receive the larger LSPs it should certainly NOT 
distinguish between the two sized LSPs as far as storage is concerned. To 
do so would introduce two potential interpretations for the OL bit without 
the ability to advertise which of the two meanings is correct. I also do 
not see how a selective storage policy helps achieve qualitatively better 
convergence.

We have provided mechanisms to advertise the local supported value for 
"originatingLxLSPBufferSize" to allow mismatches to be detected before they 
become a problem. We have also defined alarms to note when LSPs are 
actually received which are too big to propagate everywhere. Let that be 
enough.

    Les

---

From: Jeff Parker <[email-masked]>
Date: Tue, 29 Apr 2003 08:48:25 -0400

Les -
	If we do not distinguish between PDUs greater than 
isisSysReceiveLSPBufferSize and those less than or equal
to it, then there isn't much point in having the value.

	Are you proposing that we drop 
isisSysReceiveLSPBufferSize?

	I know of more than one implementation that uses
a buffer pool scheme to deal with memory fragmentation
issues.  Even if such implementations can deal with
large LSPs, there is a prefered size.  

- jeff parker

---

From: "Ramalingam, Swaminathan (Swaminathan)" <[email-masked]>
Date: Tue, 29 Apr 2003 18:41:42 +0530

Jeff -
I guess, Les trying to point out isisSysReceiveLSPBufferSize is more of
related to MTU, not how you store in the system. Even I am with Les, it
should more of MTU related constraint.

If it is related to storage problem, why let the user to configure that
variable?. It can be hard coded with a value, whichever vendor feels good
for its implementation.

I feel, isisSysReceiveLSPBufferSize should be maintained in the MIB with
description pointing out more of MTU constraint.

Thanks,
Swami

-----Original Message-----
From: Jeff Parker [mailto:[email-masked]]
Sent: Tuesday, April 29, 2003 6:18 PM
To: 'Les Ginsberg'
Cc: 'Jonnala, Nagi'; ISIS-WG (E-mail)
Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize

Les -

- jeff parker