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

Re: TE MIB





>I've finally posted the updated TE MIB.  Sorry for the long wait.
>
>Many thanks to Keith McCloghrie for his many and detailed comments;
>thanks too to several others who've sent in comments.  I've tried to
>incorporate as many of them as I could.
>
>Structurally, the MIB is pretty much the same.  The main differences:
>a) the mib now compiles! (there is a TBD for which I fill in a random
>    value; I use the Epilogue compiler, version 9.0, FWIW);

         Let me suggest that you run the SmicNG or SmiLint compilers
(in that order) over your MIB. Epilogue's compiler is weak in comparison to
either, and frequently compiles MIBs that have errors that violate the SMI.
For example, it ignores something as fundamental as the conformance
and compliance sections at  the end of the MIB. This is probably why
it compiled without your adding either (I see your TBD item below). *)

         --Tom



>b) the mib object names now reflect the fact that it is a TE MIB rather
>    than an MPLS LSP mib;
>c) there is a textual convention for hop addresses.
>
>There are lots of small changes, mostly pointed out by Keith -- either
>bugs or violations of SNMP conventions.  Any remaining (or new) ones
>are of course my fault.
>
>There are at least three things to be done:
>1) Add TE link information.  Keith pointed out that having the notion
>    of include/exclude constraints without being able to map links to
>    administrative groups via some MIB.  If this is followed, then
>    there might as well be link information in this mib.
>2) Do something meaningful with ERO/RROs (see below).
>3) Add conformance statements.
>
>ERO: currently, an ERO is an OCTET STRING.  It's extremely unaesthetic,
>but it gets around the problem that a table can't have an embedded
>table (as  I understand it).  An alternative is to have an index into
>another table; the corresponding entry then has an index for the next
>element, etc.  While that is less ugly, it means a lot of table accesses
>to get the full ERO.
>
>If anyone has bright ideas how to implement EROs (RROs are similar),
>please let me know.  Otherwise, indicate which of the above alternatives
>seem less heinous to you.
>
>Any other comments are also very welcome.
>
>Thanks,
>Kireeti.



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.