Subject: Re: OSPFv2 MIB draft

From: "Manral, Vishwas" <[email-masked]>
Date: Tue, 18 Mar 2003 01:52:27 -0500

Dan Joyal is at present working on the OSPFv2 MIB.

Thanks,
Vishwas

-----Original Message-----
From: Roy Jose [mailto:[email-masked]]
Sent: Tuesday, March 18, 2003 12:03 PM
To: [email-masked]
Subject: Re: OSPFv2 MIB draft

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" <[email-masked]>
> > > To: <[email-masked]>
> > > 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:[email-masked]]
> > > > > >>>Sent: Monday, February 10, 2003 3:01 PM
> > > > > >>>To: [email-masked]
> > > > > >>>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
> > >

---

From: Acee Lindem <[email-masked]>
Date: Tue, 18 Mar 2003 17:37:57 -0500

> Dan Joyal is at present working on the OSPFv2 MIB.

And the OSPFv3 MIB as well.

Thanks,
Acee

---

From: Roy Jose <[email-masked]>
Date: Wed, 19 Mar 2003 18:05:21 +0530

Thanks Manral, Acee.

Let me point out the open issues here from the original document I sent.
Joyal, please let me know if you need any clarifications.

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.
[WG - John Flick]
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.
[OPEN issue]
I think we need to investigate on this and add a section to the draft how it
can be applied to OSPF MIB .

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.

[WG - John Flick]
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.

[OPEN issue]
As I have pointed out earlier, by changing the INDICES we can reduce the
number of  SNMP GETNEXT reponses sent by the router considerably. The draft
standard MIB
is already widely deployed. But we need to deprecate an existing MIB and add
a new version, when it is required. I feel if everyone thinks what I pointed
out is a big advantange, still we can go ahead with this change.

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.

[OPEN issue] The above point is not addressed yet.

[OPEN issue] This is not addressed yet.

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?

[OPEN issue] This is not addressed yet.

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
-------------------

[OPEN issue] This is not addressed yet.

Do we need an error type for duplicate router id in the received messages?
Some times loop back
address can be misconfigured.

ospfSetTrap
-----------

[OPEN issue] This is not addressed yet.

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

ospfIfStateChange
-----------------
[OPEN issue] This is not addressed yet.

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
------------------

[OPEN issue] This is not addressed yet.

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.

Thanks,
Roy

---

From: Roy Jose <[email-masked]>
Date: Wed, 19 Mar 2003 18:08:59 +0530

Looks like Joyal's id is not reachable.

   ----- The following addresses had permanent fatal errors -----
<[email-masked]>
    (reason: 550 5.0.0 <[email-masked]>... User unknown)

-Roy

module,
information
> MAX-ACCESS value for INDICES of TABLES:
considerably
> Section : 4.3 Ignoring Initial Activity
monitoring
> Its also true with VirtIfStateChange, NbrStateChange and
VirtNbrStateChange.
> want to see ALL state TRAPS, they can suppress them by turning off the
multi-access
> > > > > > > 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
> > > > > > > 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
> > > > > > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft
shows
> > > > > > > > >>Multiple processes can have separate router IDs. It is
also
> true
> > > > > > > > >>separate MIB view for each process. But I don't think it
can
> be
> > > > > > > > >>table like this even if they are not-accessible. The
tables
> like
> > > > > > > > >>this is remove the INDICES from TRAP notification
messages.
> For
> > > > > > > > >>I am not sure if enabling OSPF on a router means enabling
it
> on
> > > > > > > > >>interface is up and it goes down before (2 * dead
interval).
> We
> > > > > > > > >>ospfNbrStateChange and ospfVirtNbrStateChange
notifications
> by
> > > > > > > > >>its better to redefine this MIB object like this to make
if
> more
> > > > > > > > >>                            "The BGPBackwardTransition
Event
> is
> > > > > > > > >>Our suggestion is to maintain ospfIfStateChange and use
that
> > > > > > > > >>I think here the intention is to reduce the number of
TRAPs
> as
> > > > > > > > >>NbrState becomes FULL in that case. There is a problem
with