From: Roy Jose (rojoseCISCO.COM)
Date: Tue Mar 18 2003 - 00:33:10 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi Acee,

I agree with you. Till it becomes a standard draft, vendors have to go with
some proprietory MIB I guess. Btw, who is working on the MIB update
currently?

Thanks,
Roy

> One small correction.
>
> Acee Lindem wrote:
> >
> > Roy,
> >
> > There are 3 reasons why I don't think Sham Links should
> > be included in this MIB udpate:
> >
> > 1. I don't think they are sufficiently specified in the
> > Internet Draft describing them. My experience implementing
> > the Sham Link feature required some reverse
> > engineering (Consult RFC 1264 for specification
> > requirements).
> > 2. The document describing them is not an OSPF WG
> > document. In fact, it is not even an PPVPN
> > document (although it could become one).
> > 3. At some point, we have to close the door on adding
> > MIB variables that are in all the drafts that may or
> > may not ever reach draft standard status. If we don't
> ~~~~~~~~~~~~~~
> Meant to say "proposed standard" here.
>
> > do this, we'll never finish the MIB update.
> >
> > Thanks,
> > Acee
> >
> > Roy Jose wrote:
> > >
> > > Thanks Jeff, Acee, Mani and John for your responses. How about other
> > > points?:)
> > >
> > > ----- Original Message -----
> > > From: "John Flick" <johnfROSE.HP.COM>
> > > To: <OSPFDISCUSS.MICROSOFT.COM>
> > > Sent: Saturday, March 15, 2003 6:19 AM
> > > Subject: Re: OSPFv2 MIB draft
> > >
> > > > Yep, adding an index would require deprecating everything and
starting
> > > over.
> > > > Since this is an existing, widely deployed, Draft Standard MIB, this
> > > should
> > > > not be done lightly.
> > > >
> > > > You would have the same problem if you tried changing MAX-ACCESS on
the
> > > > table indices (as was also suggested below). Since a change to
MAX-ACCESS
> > > > of an existing object is not allowed, you would need to deprecated
the
> > > index
> > > > objects, which would require deprecating the tables that they index.
> > > Changing
> > > > to not-accessible is not required, since SMIv2 allows read-only
indices
> > > for
> > > > MIB modules that were translated from SMIv1 and therefore already
had
> > > > read-only indices. The OSPFv2 MIB started life in RFC 1248 as an
SMIv1
> > > MIB
> > > > module, so this exception applies.
> > >
> > > How about tables which were added later?: ospfAreaAggregateTable,
> > > ExtLsdbTable, etc.
> > > My worry is not if its allowed or not. I am trying to point out the
extra
> > > processing routers and
> > > NMS have to do with the increased number of messages.
> > >
> > > > As far as finding a generic solution for multiple instances of a MIB
> > > module,
> > > > the standard solution is to use contexts (note: this is not the same
as a
> > > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was done
in a
> > > > somewhat ad-hoc way by using different community names for each
instance
> > > > of the OSPF MIB. In SNMPv3, it is more formally defined using the
> > > > contextName. The Entity MIB entLogicalTable (RFC 2737) provides
> > > information
> > > > about what contexts exist in an agent, and how to get to them.
> > >
> > > After having a glance at rfc2737, I also think this is the way. I
think we
> > > need to specify it clearly how it can be achieved using
entLogicalTable. For
> > > example, how we need to represent the SNMP community string to
retrieve info
> > > from a particular routing instance.
> > >
> > > Thanks,
> > > Roy
> > >
> > > >
> > > > John
> > > >
> > > > Acee Lindem wrote:
> > > > >
> > > > > Roy,
> > > > >
> > > > > I can appreciate your points since our product supports both
multiple
> > > > > virtual router instances and multiple routing protocol instances
> > > > > within a particular virtual router. However, I think we'd
> > > > > essentially have to deprecate everything in the current MIB and
define
> > > > > new tables in order to add OSPF instance ID as an index. Can
someone
> > > > > who has more MIB definition experience comment?
> > > > >
> > > > > Additionally, the multiple instance problem is not unique to the
> > > > > OSPF MIB. Maybe a generic solution could be developed.
> > > > >
> > > > > Roy Jose wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I have some comments on draft-ietf-ospf-mib-update-05.txt. I
would
> > > also like
> > > > > > to have some clarifications. Please see the attached document.
> > > > > >
> > > > > > Thanks,
> > > > > > Roy
> > > > > >
> > > > > >
> > > > > >>Yes. An update is in the works.
> > > > > >>
> > > > > >>-Dan
> > > > > >>
> > > > > >>
> > > > > >>>-----Original Message-----
> > > > > >>>From: Banerjee, Gargi [mailto:Gargi.BanerjeeMARCONI.COM]
> > > > > >>>Sent: Monday, February 10, 2003 3:01 PM
> > > > > >>>To: OSPFDISCUSS.MICROSOFT.COM
> > > > > >>>Subject: OSPFv2 MIB draft
> > > > > >>>
> > > > > >>>
> > > > > >>>Hi all:
> > > > > >>>I would like to know the status of the working group
> > > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft shows an
> > > > > >>>expiry date of
> > > > > >>>May 2001.
> > > > > >>>Is there any plan to update the draft ?
> > > > > >>>
> > > > > >>>Thanks
> > > > > >>>Gargi
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > >
> > >
>>------------------------------------------------------------------------
> > > > > >>
> > > > > >>Support for multiple OSPF processes:
> > > > > >>-----------------------------------
> > > > > >>
> > > > > >>We raised this issue some time back in WG. Currently MIB
supports only
> > > one Router ID.
> > > > > >>Multiple processes can have separate router IDs. It is also true
with
> > > other MIB objects
> > > > > >>like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution
we
> > > got was to use a
> > > > > >>separate MIB view for each process. But I don't think it can be
easily
> > > implemented.
> > > > > >>We suggest to form a new table to group scalar objects related
to an
> > > OSPF process and have
> > > > > >>Process Id as its INDEX. We also suggest to add Process Id as
one of
> > > the INDICES of all
> > > > > >>tables.
> > > > > >>
> > > > > >>
> > > > > >>MAX-ACCESS value for INDICES of TABLES:
> > > > > >>--------------------------------------
> > > > > >>I see MAX-ACCESS value of all TABLEs are read-only. Normally
INDICES
> > > of a table are
> > > > > >>put as not-accesssible to reduce the number of SNMP messages.
When an
> > > SNMP GET or
> > > > > >>GETNEXT is issued on a non-INDEX object, we can extract the
values of
> > > INDICES from
> > > > > >>the object ID returned. For example, let us consider
ospfAreaLsaCount.
> > > When we query
> > > > > >>the value for this, we get something like
ospfAreaLsaCount.0.0.0.1,
> > > where 0.0.0.1 is
> > > > > >>the AreaId, which is the INDEX of the ospfAreaTable. We can
extract
> > > the INDICES of
> > > > > >>table like this even if they are not-accessible. The tables like
> > > LsdbTable has many
> > > > > >>number of INDICES and we can reduce the number of SNMP messages
> > > considerably by changing
> > > > > >>them to not-accessible.
> > > > > >>
> > > > > >>If the MAX-ACCESS of INDICES are put as read-only to include
them in
> > > the TRAP
> > > > > >>notification messages, they can be changed as
accessible-for-notify.
> > > Other approach to
> > > > > >>this is remove the INDICES from TRAP notification messages. For
> > > example if you take the
> > > > > >>case of IfStateChange TRAP,
> > > > > >>
> > > > > >> ospfIfStateChange NOTIFICATION-TYPE^M
> > > > > >> OBJECTS { ospfRouterId, -- The originator of the trap^M
> > > > > >> ospfIfIpAddress,^M
> > > > > >> ospfAddressLessIf,^M
> > > > > >> ospfIfState -- The new state^M
> > > > > >> }^M
> > > > > >>Here we don't actually need ospfIfIpAddress and
ospfAddressLessIf.
> > > When we send TRAP
> > > > > >>notification, we can just send ospfIfState.<ospfIfIpAddress
> > > value>.<ospfAddressLessIf value> .
> > > > > >>Also I am not sure why ospfRouterId is included here. An NMS
station
> > > can always query ospfRouterId
> > > > > >>separately. By removing these MIB objects, we can reduce the
size and
> > > processing time of TRAP
> > > > > >>messages considerably.
> > > > > >>
> > > > > >>Section : 4.3 Ignoring Initial Activity
> > > > > >>---------------------------------------
> > > > > >>The section states "The majority of critical events occur when
OSPF is
> > > enabled on a
> > > > > >>router, at which time the designated router is elected and
neighbor
> > > adjacencies are formed" .
> > > > > >>I am not sure if enabling OSPF on a router means enabling it on
an
> > > interface. I think it will
> > > > > >>be better to make the text clearer.
> > > > > >>
> > > > > >>Other statement is "To avoid unnecessary traps, a router should
not
> > > originate expected OSPF
> > > > > >>interface related traps until two of that interface's dead timer
> > > intervals have elapsed."
> > > > > >>I think there will be some problems if the dead interval value
is too
> > > long. We may end up
> > > > > >>not sending any of the expected TRAPS for a long time. Btw,
could I
> > > please know the reason
> > > > > >>for selecting 2 * dead interval value for this purpose?. There
might
> > > be some case where an
> > > > > >>interface is up and it goes down before (2 * dead interval). We
can't
> > > take it as an 'expected
> > > > > >>event'. Probably we can ignore the expected events till the
interface
> > > reaches terminal state
> > > > > >>(FULL or 2WAY) for the first time after enabling OSPF.
> > > > > >>
> > > > > >>
> > > > > >>One more point is we are already limiting ospfIfStateChange,
> > > ospfVirtIfStateChange,
> > > > > >>ospfNbrStateChange and ospfVirtNbrStateChange notifications by
> > > generating them only for terminal
> > > > > >>state changes and backward tansition. Do we really need to
ignore them
> > > during the initial activity?.
> > > > > >>
> > > > > >>Other statement is "Additionally, ospfMaxAgeLsa and
ospfOriginateLsa
> > > traps should not be originated
> > > > > >>until two dead timer intervals have elapsed where the deadtimer
> > > interval used should be the dead
> > > > > >>timer with the smallest value." Here whats the meaning of "dead
timer
> > > with smallest value"? Is it
> > > > > >>the smallest interval value among all the interfaces?
> > > > > >>
> > > > > >>
> > > > > >>Section 4.4 Throttling Traps
> > > > > >>----------------------------
> > > > > >>Do we need to provide MIB objects corresponding to window size
and the
> > > number of TRAPs sent during
> > > > > >>the window time? Will the TRAPs other than ospfTxRetransmit,
> > > OrginateLsa and MaxAgeLsa really cause
> > > > > >>a TRAP flood? Probably we need to throttle only the above three
TRAPS?
> > > > > >>
> > > > > >>I think the normal practice is to inform the NMS using some
other
> > > notification at the end of a
> > > > > >>particular interval when the TRAPs are dropped like this, "Trap
N
> > > dropped n times in an interval
> > > > > >>t". We can add some common extra paratmeters to these
notifications to
> > > facilitate the NMS to query
> > > > > >>the router to retrieve some values and find out whats happening.
> > > > > >>
> > > > > >>ospfConfigErrorType
> > > > > >>-------------------
> > > > > >>Do we need an error type for duplicate router id in the received
> > > messages? Some times loop back
> > > > > >>address can be misconfigured.
> > > > > >>
> > > > > >>ospfSetTrap
> > > > > >>-----------
> > > > > >>The definition of this is little complicated. Any reasons for
going
> > > for last bit to first. We think
> > > > > >>its better to redefine this MIB object like this to make if more
> > > clear.
> > > > > >>
> > > > > >> cospfSetTrap OBJECT-TYPE
> > > > > >> SYNTAX BITS {
> > > > > >> ifConfigError (0),
> > > > > >> virtIfConfigError (1),
> > > > > >> ospfNbrStateChange (2),
> > > > > >> .
> > > > > >> .
> > > > > >> .
> > > > > >> }
> > > > > >> MAX-ACCESS read-write
> > > > > >> STATUS current
> > > > > >> DESCRIPTION
> > > > > >> "A One-octet string serving as a bit map for
> > > > > >> the trap events defined by the OSPF traps in
> > > > > >> this MIB. This object is used to enable and
> > > > > >> disable specific OSPF traps where a 1
> > > > > >> in the corresponding bit field represents
> > > > > >> enabled."
> > > > > >> ::= { cospfTrapControl 1 }
> > > > > >>
> > > > > >>This definition enables the NMS to interpret the bit map easily.
> > > > > >>
> > > > > >>
> > > > > >>ospfIfStateChange
> > > > > >>-----------------
> > > > > >>
> > > > > >>>From the definition it looks like this TRAP should be generated
only
> > > for terminal states(when state
> > > > > >>progresses) and for backward transition. Infact the name
> > > ospfIfStateChange simply suggests to
> > > > > >>generate TRAPs for all state transitions. The general tendency
is to
> > > ignore the DESCRIPTION when
> > > > > >>"StateChange" is read and assume its for all the state changes.
It
> > > might lead to wrong
> > > > > >>implementations. I think we can also follow the approach taken
in BGP
> > > MIB(rfc1657).
> > > > > >>There they have notifications like this,
> > > > > >> bgpEstablished NOTIFICATION-TYPE
> > > > > >> OBJECTS { bgpPeerLastError,
> > > > > >> bgpPeerState }
> > > > > >> STATUS current
> > > > > >> DESCRIPTION
> > > > > >> "The BGP Established event is
generated
> > > when
> > > > > >> the BGP FSM enters the ESTABLISHED
state."
> > > > > >> ::= { bgpTraps 1 }
> > > > > >>
> > > > > >> bgpBackwardTransition NOTIFICATION-TYPE
> > > > > >> OBJECTS { bgpPeerLastError,
> > > > > >> bgpPeerState }
> > > > > >> STATUS current
> > > > > >> DESCRIPTION
> > > > > >> "The BGPBackwardTransition Event is
> > > generated
> > > > > >> when the BGP FSM moves from a higher
> > > numbered
> > > > > >> state to a lower numbered state."
> > > > > >> ::= { bgpTraps 2 }
> > > > > >>
> > > > > >>Our suggestion is to maintain ospfIfStateChange and use that for
> > > monitoring all the states
> > > > > >>(some people may want that) and additionally have notifications
> > > similar to the BGP notifications.
> > > > > >>Its also true with VirtIfStateChange, NbrStateChange and
> > > VirtNbrStateChange. If somebody doesn't
> > > > > >>want to see ALL state TRAPS, they can suppress them by turning
off the
> > > corresponding bit in
> > > > > >>ospfSetTrap.
> > > > > >>
> > > > > >>
> > > > > >>ospfNbrStateChange
> > > > > >>------------------
> > > > > >>The DECRIPTION clause states
> > > > > >>"When an neighbor transitions from or to Full on non-broadcast
> > > multi-access and broadcast
> > > > > >> networks, the trap should be generated by the designated
router. A
> > > designated router
> > > > > >>transitioning to Down will be noted by ospfIfStateChange."
> > > > > >>I think here the intention is to reduce the number of TRAPs as
much as
> > > possible by making
> > > > > >>only DR sending out this TRAP for a subnet. But there is a
possibility
> > > that osfpNbrStateChange
> > > > > >>notification is disabled on DR and enabled on DR other or BDR.
NMS
> > > won't receive TRAPs when
> > > > > >>NbrState becomes FULL in that case. There is a problem with the
second
> > > part of above statments
> > > > > >>as well. Suppose ospfIfStateChange is disabled on the router,
then
> > > again NMS won't know when
> > > > > >>neighbor goes down. Probably its better to remove these two
clauses.
> > > > > >>
> > > > > >>
> > > > > >>Support for sham links:
> > > > > >>-----------------------
> > > > > >>Are you going to provide support for sham links? We may need
these
> > > tables and notifications,
> > > > > >>ShamLinkTable
> > > > > >>ShamLinkNbrTable
> > > > > >>ShamLinkStateChange notification
> > > > > >>ShamLinkNbrStateChange notification
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >
> > > > >
> > > > > --
> > > > > Acee
> > > >
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]