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

From: Satish Dattatri <[email-masked]>
Date: Wed, 29 May 2002 12:02:10 -0700

Hi,
Please see inline ...
Thanks,
Satish

> -----Original Message-----
> From: Jeff Parker [mailto:[email-masked]]
> Sent: Friday, May 24, 2002 11:00 AM
> To: 'Joyal, Daniel R (Daniel)'; Jeff Parker
> Cc: IS-IS-WG (E-mail)
> Subject: RE: [Isis-wg] IS-IS MIB
> 
> 
> > >	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.
> 
> > 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.

> > 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
                            ^^^^^
Apart from being able to do a get is there something more this reqd ?

> > 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'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 ;-).

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