Subject: Re: OSPFv2 MIB draft

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 19 Mar 2003 13:02:44 -0500

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:[email-masked]]
Sent: Wednesday, March 19, 2003 6:05 PM
To: [email-masked]
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:[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: Roy Jose <[email-masked]>
Date: Thu, 20 Mar 2003 14:22:10 +0530

Hi Manral,

Thanks.

> all the tables to get the slight benefit of saving SNMP messages.

I believe it can be a considerable benefit. Lets consider LsdbEntry where we
have four indices,
ospfLsdbAreaId, ospfLsdbType, ospfLsdbLsid and ospfLsdbRouterId . When we
try to access
entire Lsdb details on your router, you use a 'getmany' utility which issues
GETNEXT internally. This is what happens,
GETNEXT ospfLsdbTable : Response -> ospfLsdbAreaId.a1.t1.lsdbid1.rtrid1 = X.
GETNEXT ospfLsdbAreaId.a1.t1.lsdbid1.rtrid1 = X
                                         : Response ->
ospfLsdbType.a1.t1.lsdbid1.rtrid1 = Y
GETNEXT ospfLsdbType.a1.t1.lsdbid1.rtrid1 :
                                         : Response ->
ospfLsdbLsid.a1.t1.lsdbid1.rtrid1 = Z
GETNEXT ospfLsdbLsid.a1.t1.lsdbid1.rtrid1 :
                                         : Response ->
ospfLsdbRouterId.a1.t1.lsdbid1.rtrid1 = A
GETNEXT ospfLsdbRouterId.a1.t1.lsdbid1.rtrid1 :
                                         : Response ->
ospfLsdbSequence.a1.t1.lsdbid1.rtrid1 = B
.
.
If we can make the INDICES not-accessible, the first four messages need not
be sent. Suppose you have 100 entries, you save 400 messages. Probably we
can use GETBULK where you get N number of objects together. But its not
supported with SNMP v1.

> Exchange/Exstart state, we wouldn't be sending traps in that case either.

Good point. Thats why I am suggesting three different traps. Please see my
next mail to Dan for
more details.
NbrStateChange -> For all state changes
NbrStateTerminal
NbrStateBackwardTransition.

People, who are ready go with the risks as you are pointing out, can use the
last two notifications instead of the first.

> progress ahead of Exstart.

But isn't it better to inform the NMS about the error? It will be great if
someone can point out any other errors which we are missing.

Thanks,
Roy

information
> MAX-ACCESS value for INDICES of TABLES:
VirtNbrStateChange.

---

From: John Flick <[email-masked]>
Date: Mon, 24 Mar 2003 19:46:47 -0800

Hi Roy,

One datapoint is that the decision to make index objects not-accessible in SMIv2
has been somewhat controvertial.  Many management app developers loathe having
to parse out the indices from an OID.

That said, I believe the issue you raise really only matters if you are dealing
with a blind "get-next" sweep of a table.  An application that is trying to
upload this table could just as easily code its get-next requests to only
ask for the columns it needs, e.g.:

GETNEXT ospfLsdbSequence, ospfLsdbAge, ospfLsdbChecksum

in a single request, then feed the OIDs it got from that request back into
subsequent iterations.  In other words, if the app doesn't want the indices,
there is no need for it to ask for them.  I am less interested in optimizing
for a blind browser walk than I am in optimizing for a real monitoring
application, and I don't think that optimizing that blind MIB walk is a
very compelling reason for deprecating huge chunks of an existing, deployed
MIB.

As far as the rules for what is allowed in a MIB update are concerned, we
could define any tables that are new in this update with not-accessible
indices (e.g. the ospfLocalLsdbTable) if we are willing to tolerate the
inconsistency with the rest of the MIB.  But tables that were already
published in RFC 1850 would need to be deprecated and new tables defined
in order to change the MAX-ACCESS.  RFC 2578, section 10 contains the
detailed rules for what is allowed when updating a MIB module.  There is
a freely available tool called smidiff which will evaluate changes to
a MIB module for legality.  See http://www.ibr.cs.tu-bs.de/projects/libsmi/

John

---

From: Roy Jose <[email-masked]>
Date: Thu, 27 Mar 2003 14:57:14 +0530

Hi John,

> ask for the columns it needs, e.g.:

But, I don't know howmany management applications would do it. Having said
this, I agree this a very controversial point :) If WG is not confortable
with deprecating all the tables, better not to do it. But as you say, it is
a good idea to change the MAX-ACCESS values of the indices of new tables. I
think inconistency here is not a big issue.

Thanks,
Roy

> a MIB module for legality.  See
http://www.ibr.cs.tu-bs.de/projects/libsmi/