Subject: [Isis-wg] Use of isisSysReceiveLSPBufferSize

From: Jeff Parker <[email-masked]>
Date: Tue, 29 Apr 2003 14:07:32 -0400

Les and I have been having a back-channel discussion on this

> >My reading of this focuses on "by default".  Don't discard
> >this -if you have a choice-.  That is, we make a best effort
> >attempt to keep the large ones.  The regular size ones we always
> >keep - unless we are overloaded.
> 
> If you can't allocate memory to store the larger LSP, then 
> obviously you must discard it - and you should not acknowledge 
> receipt of the LSP either. 
> This is equivalent to having a link MTU too small except the limiting 
> factor here is the L3 buffer size. I have no problem with 
> this because it 
> is an implementation issue.

Good.  I suspect that fixed size LSP buffers are a common 
implementation.  This variable just recognizes the fact, 
and may help diagnose things.  

How about dropping the last paragraph?  It still gives 
me the "resources allow" escape hatch.  

> > >     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." 
> > >         DEFVAL { 1492 }
> > >     ::= { isisSysEntry 14 }

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

---

From: Les Ginsberg <[email-masked]>
Date: Tue, 29 Apr 2003 11:29:51 -0700

> > > >              values for isisSysOrigLSPBuffSize."

The correct behavior for handling receipt of an LSP which is too large to 
store is specified in ISO 10589 7.3.14.2:

The maximum size control PDU (Link State PDU or Sequence Numbers PDU) which 
a system expects to receive shall be ReceiveLSPBufferSize octets. (i.e. the 
Update process must provide buffers of at least this size for the 
reception, storage and forwarding of received Link State PDUs and Sequence 
Numbers PDUs.) If a control PDU larger than this size is received, it shall 
be treated as if it had an invalid checksum (i.e. ignored by the Update 
Process and a corruptedLSPReceived event generated).

If you can store an LSP, then you should ACK reception, store it, and flood 
it. If you can't store it then you behave as described in 10589. There is 
no need for additional specification.

    Les

---

From: "Don Goodspeed" <[email-masked]>
Date: Tue, 29 Apr 2003 15:00:22 -0400 (EDT)

Jeff,

Shouldn't these both be defined as Unsigned32 (along with any
of the other LSP Buffer attributes)?

-don

 --- On Tue 04/29, Jeff Parker < [email-masked] > wrote:
From: Jeff Parker [mailto: [email-masked]]
To: [email-masked]
Date: Tue, 29 Apr 2003 13:52:28 -0400
Subject: FW: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize

> From: Les Ginsberg [mailto:[email-masked]]
> Sent: Tuesday, April 29, 2003 1:37 PM
> To: Jeff Parker
> Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize
>
> I haven't been following the MIB as closely lately.

It isn't something everyone scans over breakfast, is it?

> In looking at it today I see:
>
> isisOriginatingBufferSize OBJECT-TYPE
> SYNTAX Integer32 (1..2147483647)
>
> So why is one variable 16 bits and the other 32 bits??

Thanks. It now reads

isisOriginatingBufferSize OBJECT-TYPE
SYNTAX Integer32 (512..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Holds the size of isisSysOrigLSPBuffSize
advertised by peer in TLV."
::= { isisNotificationEntry 9 }

- jeff

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Jeff Parker <[email-masked]>
Date: Tue, 29 Apr 2003 15:02:52 -0400

> of the other LSP Buffer attributes)?

There was an effort awhile back to reduce the range on
things to allow more error checking.  Do you anticipate
LSP's bigger than 16K?  Bigger than 64K?  

- jeff parker

---

From: "Don Goodspeed" <[email-masked]>
Date: Tue, 29 Apr 2003 15:18:15 -0400 (EDT)

Jeff,

No, this was not a range issue.  I was just suggesting that since
these values would never be negative to change them to Unsigned
Integer values rather than Signed Integer values.

-don

P.S. My silly excite email messes up on HTML email messages when I
reply to them, so apologies in advance if the original text below
is "garbled".

 --- On Tue 04/29, Jeff Parker < [email-masked] > wrote:
From: Jeff Parker [mailto: [email-masked]]
To: [email-masked], [email-masked]
Date: Tue, 29 Apr 2003 15:02:52 -0400
Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize

 <br>> Jeff,<br>> <br>> Shouldn't these both be defined as Unsigned32 (along with any<br>> of the other LSP Buffer attributes)?<br>> <br>> -don<br><br>There was an effort awhile back to reduce the range on<br>things to allow more error checking.  Do you anticipate<br>LSP's bigger than 16K?  Bigger than 64K?  <br><br>- jeff parker<br>_______________________________________________<br>Isis-wg mailing list<br>[email-masked]<br>https://www1.ietf.org/mailman/listinfo/isis-wg<br>

---

From: Jeff Parker <[email-masked]>
Date: Tue, 29 Apr 2003 15:24:02 -0400

> reply to them, so apologies in advance if the original text below
 
Don -
	With Les' help, I have just changed these to Unsigned 16.

- jeff parker

---

From: "Don Goodspeed" <[email-masked]>
Date: Tue, 29 Apr 2003 16:04:15 -0400 (EDT)

Jeff, Les,

Thanks!  That will work just fine.  

-don
"U16? You sank my battleship!"

Date: Tue, 29 Apr 2003 15:24:02 -0400

---

From: "Jonnala, Nagi" <[email-masked]>
Date: Wed, 30 Apr 2003 09:38:33 -0400

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

Yes, I have seen a box using 1497 Hello PDUs but not LSPs. It seems
to me that LSPs are confined to 1492.

My questions are:

1) Why is that 1497 Hellos are being generated. Does the difference
   between Ethernet and IEEE 802.3 packet sizes have any impact?
 
2) You said rules are different for LSPs and Hellos. What are those?

Thanks
Nagi.

---

From: Jeff Parker <[email-masked]>
Date: Wed, 30 Apr 2003 09:48:59 -0400

> 2) You said rules are different for LSPs and Hellos. What are those?

Nagi -
	Hellos may be padded to the MTU (or close to it) to discover
misconfigurations: networks where one side thinks the MTU is
bigger than the other.  In part, this is to assure the network
can carry the LSPs, but it is also to check these limits for
ordinary traffic.  
	The goal of the Hello packet is to get as close to the 
configured limit as possible.  Mike Shand has filled us in 
on why there is some wiggle room between the size of the 
'normal' LSP and the largest possible IS-IS packet on
ethernet.  

- jeff parker

---

From: Jeff Learman <[email-masked]>
Date: Wed, 30 Apr 2003 10:16:33 -0400

>'normal' LSP and the largest possible IS-IS packet on

It's simply because the smallest padding option is two bytes.
So if you encoded your IIH and it happened to fill up to the
MTU size minus one, you can't pad to the full length.

---

From: Jeff Parker <[email-masked]>
Date: Wed, 30 Apr 2003 10:27:23 -0400

> MTU size minus one, you can't pad to the full length.

Jeff L -
	But with a modicum of inginuity, you could pad the
previous TLV with 253 bytes, so you have the room you need.  
It has always amused me that the spec calls for great 
cleverness in some spots, and assumes you are an idiot here.

- jeff P

---

From: Les Ginsberg <[email-masked]>
Date: Wed, 30 Apr 2003 10:38:56 -0700

>    between Ethernet and IEEE 802.3 packet sizes have any impact?

Yes. The ethernet MTU is 1500 bytes. But since IS-IS PDUs are always sent 
in 802.3 format, a three byte LLC1 header is always present. This makes the 
network layer MTU 1497.

>2) You said rules are different for LSPs and Hellos. What are those?

As Mike Shand has recounted, it was thought that a SNAP header might be 
used for LSPs. This would consume 5 bytes -> 1497-5 = 1492. I don't know of 
anyone that uses a SNAP header, so in theory we could use 1497 as the 
default maximum LSP size, but given the legacy problems this could cause 
and the rather minuscule extension to the LSP space, there is no reason to 
consider this.

    Les