Subject: Re: OSPFv2 MIB draft

From: Daniel Joyal <[email-masked]>
Date: Wed, 19 Mar 2003 17:21:59 -0500

Comments in-line below.

-Dan

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

This issue is not unique to the OSPF MIBs. I would prefer
to just reference the RFCs that deal with SNMP contexts that
John Flick mentioned.

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

I think there would need to be a strong WG consensus that deprecating the
entire MIB for this is worth it.

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

I think the intent of the original authors of the MIB was
to give some guidelines (hence the wording "should not" rather
than "must not") for when or when not to generate traps. I don't
know how closely real world implementations follow these guidelines.

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

Easy to add if required.

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

Changing to a non-equivalent syntax would require creation of a new object.

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

OK. Could you list the new BGP-like notifications for OSPF?

>
> 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 15:29:37 +0530

Hi Dan,

Thanks. Please see inline.

> to just reference the RFCs that deal with SNMP contexts that

I would let John comment on this. Do we need to add any thing extra? My
point is different implementations should have the same behavior to avoid
interoperability issues. Also we need to think about modifying TRAP messages
to facilitate the NMS interpret the routing instance. Probably we can add a
new MIB object like OspfRoutingIstanceId to the notification messages.

> entire MIB for this is worth it.

I agree. Please see my previous mail to Manral.

> know how closely real world implementations follow these guidelines.

I am sure many people would like to reduce the number of  TRAPs during the
initial activity. Imagine a case where OrinateLsaTrap TRAPs are flooded like
anything during initial activity. In our implementation we are suppressing
traps during initial activity, but not exactly in the same way taking
advantage of  "should not" :) I feel the guidelines here should be clear and
worth to implement.

> > received messages? Some times loop back address can be misconfigured.

As I said in the earlier, we need to check if we are missing any other
errors.

> Changing to a non-equivalent syntax would require creation of a new
object.

This is a critical MIB object to control the TRAPs. I feel its important to
make it easily interpreted.

> OK. Could you list the new BGP-like notifications for OSPF?

Sure. I have defined them in a rough way. Let me reiterate one point. Here
the first TRAP in each step for people who are interested in knowing all
state changes. The next two(Terminal and Backward transition are for those
who want to limit the TRAP messages). Please note that I have added
ospfConfigErrorType to make the NMS know the error which caused backward
transition.

    ospfIfStateChange NOTIFICATION-TYPE
        OBJECTS {
                    ospfRouterId, -- The originator of the trap
                    ospfIfState,   -- The new state
                    ospfConfigErrorType
                  }
        STATUS             current
        DESCRIPTION
           "An ospfIfStateChange trap signifies that there
           has been a change in the state of a non-virtual
           OSPF interface. The ospfIfIpAddress and
           ospfAddressLessIf  values must be attached to ospfIfState
           object identifier. ospfConfigErrorType is set to a non-zero
           value when state change is due to some error.
           The notifications ospfIfStateTerminal and
          ospfIfStateBackwardTransition should be generated
           instead of ospfIfStateChange if the network manager  is
           not interested in knowing the intermediate states."
   ::= { ospfTraps X }

    ospfIfStateTerminal NOTIFICATION-TYPE
        OBJECTS {
                    ospfRouterId, -- The originator of the trap
                    ospfIfState   -- The terminal state
                  }
        STATUS             current
        DESCRIPTION
           "An ospfIfStateTerminal notification signifies that a
            non-virtual OSPF interface reaches a terminal
           state  (i.e.,  Point-to-Point, DR Other, Dr, or
           Backup). ospfIfIpAddress and ospfAddressLessIf
           values are attached to ospfIfState object identifier."
   ::= { ospfTraps X }

    ospfIfStateBackwardTransition NOTIFICATION-TYPE
        OBJECTS {
                    ospfRouterId, -- The originator of the trap
                    ospfIfState,   -- The new state
                    ospfConfigErrorType
                 }
        STATUS             current
        DESCRIPTION
           "An ospfIfStateBackwardTransition notification signifies that a
            non-virtual OSPF interface state  regresses (e.g., goes
           from Dr to Down). ospfIfIpAddress and ospfAddressLessIf
           values are attached to the ospfIfState object identifier.
           ospfConfigErrorType is set to a non-zero value when the state
           regresses due to an error."
   ::= { ospfTraps X }

    ospfVirtIfStateChange NOTIFICATION-TYPE
        OBJECTS {
                    ospfRouterId, -- The originator of the trap
                    ospfVirtIfState,   -- The new state
                    ospfConfigErrorType
                  }
        STATUS             current
        DESCRIPTION
           "An ospfVirtIfStateChange trap signifies that there
           has been a change in the state of a virtual
           OSPF interface. The ospfVirtIfAreaId and
            ospfVirtIfNeighbor values must be attached to the
ospfVirtIfState
           object identifier. ospfConfigErrorType is set to a non-zero
           value when state change is due to some error.
           The notifications ospfIfStateTerminal and
          ospfIfStateBackwardTransition should be generated
           instead of ospfIfStateChange if the network manager  is
           not interested in knowing the intermediate states."
   ::= { ospfTraps X }

    ospfVirtIfStateTerminal NOTIFICATION-TYPE
        OBJECTS {
                    ospfRouterId, -- The originator of the trap
                    ospfVirtIfState   -- The terminal state
                  }
        STATUS             current
        DESCRIPTION
           "An ospfVirtIfStateTerminal notification signifies that a
            virtual OSPF interface reaches a terminal
           state  (i.e.,  Point-to-Point). The ospfVirtIfAreaId and
            ospfVirtIfNeighbor values must be attached to the
ospfVirtIfState
           object identifier.."
   ::= { ospfTraps X }

    ospfVirtIfStateBackwardTransition NOTIFICATION-TYPE
        OBJECTS {
                    ospfRouterId, -- The originator of the trap
                    ospfVirtIfState,   -- The new state
                    ospfConfigErrorType
                 }
        STATUS             current
        DESCRIPTION
           "An ospfVirtIfStateBackwardTransition notification signifies that
a
            virtual OSPF interface state  regresses (e.g., goes from
           Point-to-Point to Down). The ospfVirtIfAreaId and
           ospfVirtIfNeighbor values must be attached to the ospfVirtIfState
           object identifier. ospfConfigErrorType  is set to a non-zero
value
            when the state regresses due to an error."
   ::= { ospfTraps X }

    ospfNbrStateChange NOTIFICATION-TYPE
        OBJECTS {
                    ospfRouterId, -- The originator of the trap
                     ospfNbrState,  -- The new state
                     ospfConfigErrorType
                  }
        STATUS             current
        DESCRIPTION
           "An  ospfNbrStateChange  trap  signifies   that
           there  has been a change in the state of a non-
           virtual OSPF neighbor. The ospfNbrIpAddr,
          ospfNbrAddressLessIndex and  ospfNbrRtrId
           value are attached to the ospfNbrState object
           identifier. ospfConfigErrorType is set to a non-zero
           value when state change is due to some error.
           The notifications ospfNbrStateTerminal and
          ospfNbrStateBackwardTransition should be generated
           instead of ospfNbrStateChange if the network manager  is
           not interested in knowing the intermediate states."

   ::= { ospfTraps X }

    ospfNbrStateTerminal NOTIFICATION-TYPE
        OBJECTS {
                    ospfRouterId, -- The originator of the trap
                    ospfNbrState  -- The new state
                  }
        STATUS             current
        DESCRIPTION
           "An  ospfNbrStateTerminal  notification  signifies
           that  the  neighbor  state reaches to a terminal state
           (e.g., 2-Way, when adjacency not formed with
            the neighbor, or Full). The ospfNbrIpAddr,
           ospfNbrAddressLessIndex and  ospfNbrRtrId
           value are attached to the ospfNbrState object
           identifier."

     ospfNbrStateBackwardTransition NOTIFICATION-TYPE
        OBJECTS {
                    ospfRouterId, -- The originator of the trap
                    ospfNbrState,  -- The new state
                    ospfConfigErrorType
                  }
        STATUS             current
        DESCRIPTION
           "An  ospfNbrStateBackwardTransition notification
           signifies  that the state regresses (e.g., goes from
           Attempt or Full  to  1-Way  or  Down).  The
           ospfNbrIpAddr,  ospfNbrAddressLessIndex and
           ospfNbrRtrId  value are attached to the ospfNbrState
           object  identifier. ospfConfigErrorType is set to a non-zero
           value when state change is due to some error."

    ospfVirtNbrStateChange NOTIFICATION-TYPE
        OBJECTS {
                    ospfRouterId, -- The originator of the trap
                     ospfVirtNbrState,  -- The new state
                     ospfConfigErrorType
                  }
        STATUS             current
        DESCRIPTION
           "An  ospfVirtNbrStateChange  trap  signifies   that
           there  has been a change in the state of a non-
           virtual OSPF neighbor. The ospfVirtNbrArea and
           ospfVirtNbrRtrId values are attached to the ospfVirtNbrState
           object  identifier. ospfConfigErrorType is set to a non-zero
           value when state change is due to some error.
           The notifications ospfVirtNbrStateTerminal and
          ospfVirtNbrStateBackwardTransition should be generated
           instead of ospfVirtNbrStateChange if the network manager  is
           not interested in knowing the intermediate states."

   ::= { ospfTraps X }

    ospfVirtNbrStateTerminal NOTIFICATION-TYPE
        OBJECTS {
                    ospfRouterId, -- The originator of the trap
                    ospfVirtNbrState  -- The new state
                  }
        STATUS             current
        DESCRIPTION
           "An  ospfVirtNbrStateTerminal  notification  signifies
           that  the  neighbor  state reaches to a terminal state
           (e.g.,  Full).  The ospfVirtNbrArea and ospfVirtNbrRtrId
           values are attached to the ospfVirtNbrState object  identifier."
   ::= { ospfTraps X }

     ospfVirtNbrStateBackwardTransition NOTIFICATION-TYPE
        OBJECTS {
                    ospfRouterId, -- The originator of the trap
                    ospfVirtNbrState,  -- The new state
                    ospfConfigErrorType
                  }
        STATUS             current
        DESCRIPTION
           "An  ospfVirtNbrStateBackwardTransition notification
           signifies  that the state regresses (e.g., goes from
           Attempt or Full  to  1-Way  or  Down).   The ospfVirtNbrArea and
           ospfVirtNbrRtrId values are attached to the ospfVirtNbrState
           object  identifier. ospfConfigErrorType is set to a non-zero
           value when state change is due to some error."
   ::= { ospfTraps X }

Thanks,
Roy

---

From: Roy Jose <[email-masked]>
Date: Thu, 20 Mar 2003 16:21:19 +0530

One correction inline,

> the first TRAP in each step for people who are interested in knowing all

I meant each set by "step", for eg., ospfIfStateChange, ospfIfStateTerminal
and ospfIfStateBackwardTransition.

-Roy

ospfVirtIfState

---

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

Hi Roy,

I do think it is probably a good idea to mention contexts and add a
pointer to the Entity MIB.  However, we need to be careful how far we
go in specifying how multiple instances of OSPF are identified.  In
some routers, you can have multiple instances of OSPF that are feeding
routes into a common FIB using administrative distance or some other
preference mechanism to select a single route to each destination subnet
from among the multiple instances.  In this case, contexts that just
identify the instance of OSPF are adequate.

However, if you need to deal with the notion of a virtual router, where
there could be multiple FIBs, you would probably want contexts that
reference an entire virtual device, where one of the MIBs supported by
that device is the OSPF MIB, but each virtual device probably has its
own instance of the IP MIB, the FIB MIB, and whatever other MIBs that
virtual device supports.

In short, add a reference to the appropriate RFCs for contexts, but
don't try to overspecify.

As far as the trap message is concerned, with SNMPv3, the trap also
carries a contextName which maps back to the context that generated
the notification.  For SNMPv1/SNMPv2c, you would use the same community
in the trap message that you would use in a get or set to identify
the instance.  (However, we should be careful about spending too much
time/text in this document talking about SNMPv1, since as of RFC 3410,
it has been classified as historic.)

Short answer: identify the OSPF instance in the trap the same way you
do in the get/set message.

John

---

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

Hi John,

> pointer to the Entity MIB.  However, we need to be careful how far we

Right. Probably we can add a reference to section 3.3 of RFC 3411 as well
where a picture shows  multiple contexts for "bridge MIB" (Courtesey to
Keith McCloghrie to point this out)

> own instance of the IP MIB, the FIB MIB, and whatever other MIBs that

I think the above case also can be supported using ENTITY MIB where they can
have multiple logical entities for entire MIB view relevant to the virtual
router.

> don't try to overspecify.

Right. A reference will do.

> it has been classified as historic.)

Still we can mention about V1 and V2c for backward compatibility I guess.

Thanks,
Roy