[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IS-IS MIB



Bert W. has suggested I take the following question to the mibs group.

ISIS defines an object called a Link State PDU (Protocol Data Unit) or LSP.
Since ISIS does not fragment, the LSP is designed to be as big at the MTU
will allow.  The max size of LSPs is often 1492, though there are provisions
to make the MTU large in networks with all point-2-point links, so the LSP
can be 4K or larger.  

The LSP is a fundamental object in the IS-IS world, and many systems provide
a command that shows the user the LSP broken down into components.  Thus
there is interest in providing an SNMP get for the LSP.  (Set is not
appropriate)  The question before us is

	Can we in good conscience define an SNMP object that is bigger than
1472 bytes? 

	If so, and applying the salami principle, does 4K break things? 9K?


- jeff parker
- axiowave networks
- All those who believe in psychokinesis, raise my hand.


-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Thursday, May 30, 2002 4:56 AM
To: dgoodspe@excite.com; jparker@axiowave.com; joyal@lucent.com;
satish@pluris.com
Cc: jhalpin@charter.net; bwijnen@lucent.com
Subject: RE: IS-IS MIB


So, as you found in the SMI document, the formal restriction for SMI OCTET
STRINGs
is 64K as per:
   -- OCTET STRINGs with a more restrictive size 
   -- may also be used 
   string-value  
   OCTET STRING (SIZE (0..65535)), 

Now, we have the SNMP max Message Size (see also RFC2571), and long time ago
(SNMPv1 days) we basically allowed SNMP compliant implementations to limit
SNMP
packets to fit in 484 octets (RFC1906, sect 3.1). But we do encourage to
support larger
packets. This was/is to ensure no fragmentation was/is needed in certain 
environments. These days the limit is probably OK at 1472 octets (RFC2571).

So in many environments larger packets will just work, it is just not always
guaranteed.

Does this help.. I have not checked yet what exactly it is that you want to
do, after I do 
that, I may be able to say more. But I am tied up right now.

These types of questions are also good for the mibs@ops.ietf.org mailing
list
(must be a subscriber to post)

Bert 
-----Original Message-----
From: Don Goodspeed [mailto:dgoodspe@excite.com]
Sent: Thursday, May 30, 2002 1:21 AM
To: jparker@axiowave.com; dgoodspe@excite.com; jparker@axiowave.com;
joyal@lucent.com; satish@pluris.com
Cc: jhalpin@charter.net; bwijnen@lucent.com
Subject: RE: IS-IS MIB


Jeff, 

Here's the ASN.1 definition included in RFC-1902 (SMIv2), 
found on pages 4 and 5: 

-- built-in ASN.1 types 

SimpleSyntax ::= 
CHOICE { 
-- INTEGERs with a more restrictive range 
-- may also be used 
integer-value -- includes Integer32 
INTEGER (-2147483648..2147483647), 
(snip) 

-- OCTET STRINGs with a more restrictive size 
-- may also be used 
string-value 
OCTET STRING (SIZE (0..65535)), 

objectID-value 
OBJECT IDENTIFIER 
} 

Then, later on page 17, there's this paragraph: 

7.1.2. OCTET STRING 

The OCTET STRING type represents arbitrary binary or textual data. 
Although there is no SMI-specified size limitation for this type, MIB 
designers should realize that there may be implementation and 
interoperability limitations for sizes in excess of 255 octets. 

My interpretation is that since the SMI defines no bound, it falls 
back to the ASN.1 definition of the primitive type. I don't know 
why they included the 255 octet warning, but it could have been 
due to common code limitations on string lengths. 

I cannot find in any SNMP reference or book a hard limitation on the 
size of a Get-Response PDU. Since it's all running on top of 
IP and UDP, IP should be able to fragment the UDP datagram just 
like any other packet. 

Maybe Bert or one of the others can shed some more light on this 
for us, 
Don 

--- On Wed 05/29, Jeff Parker < jparker@axiowave.com > wrote: 
From: Jeff Parker [mailto: jparker@axiowave.com] 
To:
dgoodspe@excite.com,jparker@axiowave.com,joyal@lucent.com,satish@pluris.com 
Cc: jhalpin@charter.net,bwijnen@lucent.com 
Date: Wed 05/29 
Subject: RE: [Isis-wg] IS-IS MIB 
> Don - 
> 
> I've removed the work group to spare them the sight of my ugly 
> ignorance. 
> 
> Is the warning a warning or a prohibition? If a prohibition, what 
> alternative to octet strings do we have for our large objects? 
> 
> - jeff parker 
> - axiowave networks 
> - All those who believe in psychokinesis, raise my hand. 
> 
> 
> -----Original Message----- 
> From: Don Goodspeed [mailto:dgoodspe@excite.com] 
> Sent: Wednesday, May 29, 2002 7:00 PM 
> To: jparker@axiowave.com; dgoodspe@excite.com; joyal@lucent.com; 
> jparker@axiowave.com; satish@pluris.com 
> Cc: isis-wg@spider.juniper.net; jhalpin@charter.net; bwijnen@lucent.com 
> Subject: RE: [Isis-wg] IS-IS MIB 
> 
> 
> If supported, IP can fragment the SNMP Response PDU if it's 
> larger than the MTU. I've tested this before with large OSPF 
> router LSAs. (I test both IGP protocols and SNMP, btw). 
> 
> The only references to large PDUs in SMIv2 I can find are a 
> warning on any octet string over 255 characters, and having the 
> ability to give a "tooBig" error if a local constraint is 
> exceeded 
> on the agent. 
> 
> -don 
> 
> --- On Wed 05/29, Jeff Parker < jparker@axiowave.com > wrote: 
> From: Jeff Parker [mailto: jparker@axiowave.com] 
> To: 
>
dgoodspe@excite.com,joyal@lucent.com,jparker@axiowave.com,satish@pluris.com 
> 
> Cc: isis-wg@spider.juniper.net,jhalpin@charter.net,bwijnen@lucent.com 
> Date: Wed 05/29 
> Subject: RE: [Isis-wg] IS-IS MIB 
> > > Index by the level and the LSP ID. Have an attribute for each 
> > > of the fixed fields. Have an OCTET-STRING defined attribute 
> > > as the last entry in the table that contains either: 
> > > a. The hex dump of the entire LSP, or 
> > > b. The hex dump of just the variable length fields. 
> > 
> > > The upper bound on the size probably needs to be 65535. Don't 
> > > worry, SNMP can fragment SNMP replies for the large one. 
> > 
> > > Don 
> > 
> > Don - 
> > I was under the impression that SNMP couldn't deal with 
> > 1492 byte or larger objects. If it can, I would be happy to 
> > package up the whole LSP and ship it over so that the clients 
> > can do what they like. 
> > But Dan suggested last week that this is not possible. 
> > 
> > Is there a MIB Doctor in the house? Can we get a ruling 
> > on shiping 1492 to 4K to larger yet blobs as one object? 
> > 
> > - jeff parker 
> > 
> 
> 
> Join Excite! - http://www.excite.com 
> The most personalized portal on the Web! 
> 


Join Excite! - http://www.excite.com
The most personalized portal on the Web!