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

From: "Don Goodspeed" <[email-masked]>
Date: Wed, 29 May 2002 18:24:05 -0400 (EDT)

My 2 cents,

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.

This is essentially how ospfLsdbAdvertisement is defined
(it includes the entire header, incidentally).  It is up
to the management application to do the parsing of the
TLVs to get out the needed info, so it's less work on 
the SNMP agent to track all this info.

Cheers,
Don

 --- On Wed 05/29, Joyal, Daniel R (Daniel)  wrote:
From: Joyal, Daniel R (Daniel) [mailto: [email-masked]]
To: [email-masked],[email-masked]
     Cc: [email-masked]
Date: Wed 05/29
Subject: RE: [Isis-wg] IS-IS MIB
> 
> 
> 
> 
> >> > > 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
> 

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