Subject: RE: [Isis-wg] IS-IS MIB

From: "Joyal, Daniel R (Daniel)" <[email-masked]>
Date: Fri, 24 May 2002 11:48:56 -0400

-----Original Message-----
From: Jeff Parker [mailto:[email-masked]]
Sent: Thursday, May 23, 2002 4:17 PM
To: 'Joyal, Daniel R (Daniel)'
Cc: IS-IS-WG (E-mail)
Subject: RE: [Isis-wg] IS-IS MIB

>> >	In your work on the OSPF mib, did you find 
>> >access to the LSAs to be useful?  Those are
>> >big uninterpreted octet strings, much longer 
>> >than the usual 255 bytes.
>> 
>> The OSPF LSDB table structure has been around a long time.
>> The tables break out the header information
>> into separate objects and define a single object
>> for the entire LSA (header and contents). If the
>> LSA gets 'too big', an SNMP agent may not be able to
>> satisfy a get/getnext request for the LSA object.
>>  
>> It's probably reasonable to at least define L1 and L2
>> LSP Header tables. A more complex implementation could
>> break out LSPs' TLVs into separate per LSP TLV tables
>> to enable the entire LSP to be retrieved in pieces.
>> 
>> -Dan
>
>Dan -
>	Can we rewind that, please?  I think you are
>reminding me of why this was a problem in the first
>place.  
>	An agent may not be able to satisfy a get request
>for the LSA object?  Is this due to a small SNMP buffer 
>size and the lack of a defined way to fragment payload?

Yes.
  
> 
>	If an IS has two non-pnode LSPs, one of them
>is bound to be over 1K.  If this is too big, we have 
>a problem.  We could split this into globs in the mib, 
>but there is no natural way to do this, other than 
>"first glob, second glob" etc.

One thought is to define L1 and L2 LSP Header tables
indexed by LSPID. These tables would contain only LSP header
information in small, fixed-sized objects and provide a summary of the LSP
database. I think this, by itself, is useful. 

For viewing the contents of LSPs, a second set of tables is defined which
contains, as row entries, the TLVs belonging to an LSP. If TLV
order is not important, the table index could be LSPID, TLV Type, Index
where Index is the instance of the TLV type in the LSP. 

TLV entries should be manageable by SNMP. The drawback is that
you don't get a snapshot of the complete LSP contents in one SNMP request,
so it is possible that the collection of TLVs returned reflect some
transitional state between an old and new LSP instance.
Does this scheme sound reasonable?

-Dan
   
>	I am uncomfortable with splitting this into tables
>based on the type, as I suspect this will mask issues
>that we might see.  I admit that the order shouldn't 
>matter, as long as we know which fragment a TLV sat in.  
>
>- jeff parker
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg