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

From: "Joyal, Daniel R (Daniel)" <[email-masked]>
Date: Wed, 29 May 2002 15:36:14 -0400

>> > > 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. 
>> > 
>> > An index of the 8 byte LSPID and the sequence number 
>> > should do the trick.  The sequence number addresses
>> > the issue you raise below in almost all cases.  (the
>> > corner case is when a router reboots, and issues
>> > a new version of an LSP that is still in circulation.
>> > This is a transitory event) 
>>
>> I am not sure why we need the sequence number to be in the index?
>> As far as outside is concerned there is either LSPID A with seq
>> s1 or s2 is part of the LSDB but not *both* s1 and s2. The table
>> needs to have a level-index and the LSPID. The entry that we get
>> will have the LSP header and for display/analysis purposes that
>> can be used.
>
>Satish -
>	You are right.  There is no need for the sequence number
>to be in the index.  If we return the seq #, we can avoid Dan's
>issue of mixing parts from different versions of LSP frag X.
>
> 
>> > > TLV entries should be manageable by SNMP. The drawback is that
>>                             ^^^^^
>> Apart from being able to do a get is there something more this reqd ?
>
>I agree that it wuold be a mistake for anything other than get.

Bad word choice on my part. I meant the *size* of TLVs should be small
enough to fit into SNMP buffers as opposed to the entire LSP fragment.
These should be read-only tables.

>
>
>> > I'm uncomfortable with splitting an LSP into unordered
>> > components, though I don't have a compelling argument.
>> 
>> too much of housekeeping, depending on how an implementation stores
>> an LSP. On the other hand most implementations have a way to display
>> the LSP in detail, which needs the above table. Is there a way to
>> specify in MIB terms saying optional so that an implementation can
>> be conforming to standard yet not have this table implemented ;-).
>
>Yes, there is a way to mark some things as optional.  The MIB 
>today has required tables and optional tables.

I agree that these tables should be optional.

-Dan
>- jeff parker
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg