From: Manral, Vishwas (VishwasMNETPLANE.COM)
Date: Wed Mar 19 2003 - 12:02:44 CST

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

Hi Roy,

I reread the OSPF-MIB and the issues you have. Though I do not know SNMP
well, I will try to let you know my view of things.

1. I think the issue of multiple instance support can be clarified in the
MIB.

2. Though I did observe that even in the ISIS-MIB, the MAX-ACCESS for
indicies is set to not-accesible, I am not sure we would want to deprecate
all the tables to get the slight benefit of saving SNMP messages.

3. I am not sure waiting for the neighbor to get to FULL state would be an
appropriate solution either. There are cases where neighbor gets stuck in
Exchange/Exstart state, we wouldn't be sending traps in that case either.

4. It can be done the way you say regarding the "throttling of traps", but I
do not see such a major issue with this.

5. I think we can know of duplicate router ID, as the adjacency would not
progress ahead of Exstart.

6. I think ok with any clarification.

Thanks,
Vishwas

-----Original Message-----
From: Roy Jose [mailto:rojoseCISCO.COM]
Sent: Wednesday, March 19, 2003 6:05 PM
To: OSPFDISCUSS.MICROSOFT.COM
Subject: Re: OSPFv2 MIB draft

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.

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

Section : 4.3 Ignoring Initial Activity
---------------------------------------

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

Section 4.4 Throttling Traps
----------------------------

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

> "Manral, Vishwas" wrote:
> >
> > Dan Joyal is at present working on the OSPFv2 MIB.
>
> And the OSPFv3 MIB as well.
>
>
> Thanks,
> Acee
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Roy Jose [mailto:rojoseCISCO.COM]
> > Sent: Tuesday, March 18, 2003 12:03 PM
> > To: OSPFDISCUSS.MICROSOFT.COM
> > 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" <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
> > > > >
>

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