From: Acee Lindem (aceeREDBACK.COM)
Date: Fri Mar 14 2003 - 16:56:51 CST

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

Roy,

I can appreciate your points since our product supports both multiple
virtual router instances and multiple routing protocol instances
within a particular virtual router. However, I think we'd
essentially have to deprecate everything in the current MIB and define
new tables in order to add OSPF instance ID as an index. Can someone
who has more MIB definition experience comment?

Additionally, the multiple instance problem is not unique to the
OSPF MIB. Maybe a generic solution could be developed.

Roy Jose wrote:
> Hi,
>
> I have some comments on draft-ietf-ospf-mib-update-05.txt. I would also like
> to have some clarifications. Please see the attached document.
>
> Thanks,
> Roy
>
>
>>Yes. An update is in the works.
>>
>>-Dan
>>
>>
>>>-----Original Message-----
>>>From: Banerjee, Gargi [mailto:Gargi.BanerjeeMARCONI.COM]
>>>Sent: Monday, February 10, 2003 3:01 PM
>>>To: OSPFDISCUSS.MICROSOFT.COM
>>>Subject: OSPFv2 MIB draft
>>>
>>>
>>>Hi all:
>>>I would like to know the status of the working group
>>>draft-ietf-ospf-mib-update-05.txt. The current draft shows an
>>>expiry date of
>>>May 2001.
>>>Is there any plan to update the draft ?
>>>
>>>Thanks
>>>Gargi
>>>
>>
>>
>>------------------------------------------------------------------------
>>
>>Support for multiple OSPF processes:
>>-----------------------------------
>>
>>We raised this issue some time back in WG. Currently MIB supports only one Router ID.
>>Multiple processes can have separate router IDs. It is also true with other MIB objects
>>like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution we got was to use a
>>separate MIB view for each process. But I don't think it can be easily implemented.
>>We suggest to form a new table to group scalar objects related to an OSPF process and have
>>Process Id as its INDEX. We also suggest to add Process Id as one of the INDICES of all
>>tables.
>>
>>
>>MAX-ACCESS value for INDICES of TABLES:
>>--------------------------------------
>>I see MAX-ACCESS value of all TABLEs are read-only. Normally INDICES of a table are
>>put as not-accesssible to reduce the number of SNMP messages. When an SNMP GET or
>>GETNEXT is issued on a non-INDEX object, we can extract the values of INDICES from
>>the object ID returned. For example, let us consider ospfAreaLsaCount. When we query
>>the value for this, we get something like ospfAreaLsaCount.0.0.0.1, where 0.0.0.1 is
>>the AreaId, which is the INDEX of the ospfAreaTable. We can extract the INDICES of
>>table like this even if they are not-accessible. The tables like LsdbTable has many
>>number of INDICES and we can reduce the number of SNMP messages considerably by changing
>>them to not-accessible.
>>
>>If the MAX-ACCESS of INDICES are put as read-only to include them in the TRAP
>>notification messages, they can be changed as accessible-for-notify. Other approach to
>>this is remove the INDICES from TRAP notification messages. For example if you take the
>>case of IfStateChange TRAP,
>>
>> ospfIfStateChange NOTIFICATION-TYPE^M
>> OBJECTS { ospfRouterId, -- The originator of the trap^M
>> ospfIfIpAddress,^M
>> ospfAddressLessIf,^M
>> ospfIfState -- The new state^M
>> }^M
>>Here we don't actually need ospfIfIpAddress and ospfAddressLessIf. When we send TRAP
>>notification, we can just send ospfIfState.<ospfIfIpAddress value>.<ospfAddressLessIf value> .
>>Also I am not sure why ospfRouterId is included here. An NMS station can always query ospfRouterId
>>separately. By removing these MIB objects, we can reduce the size and processing time of TRAP
>>messages considerably.
>>
>>Section : 4.3 Ignoring Initial Activity
>>---------------------------------------
>>The section states "The majority of critical events occur when OSPF is enabled on a
>>router, at which time the designated router is elected and neighbor adjacencies are formed" .
>>I am not sure if enabling OSPF on a router means enabling it on an interface. I think it will
>>be better to make the text clearer.
>>
>>Other statement is "To avoid unnecessary traps, a router should not originate expected OSPF
>>interface related traps until two of that interface's dead timer intervals have elapsed."
>>I think there will be some problems if the dead interval value is too long. We may end up
>>not sending any of the expected TRAPS for a long time. Btw, could I please know the reason
>>for selecting 2 * dead interval value for this purpose?. There might be some case where an
>>interface is up and it goes down before (2 * dead interval). We can't take it as an 'expected
>>event'. Probably we can ignore the expected events till the interface reaches terminal state
>>(FULL or 2WAY) for the first time after enabling OSPF.
>>
>>
>>One more point is we are already limiting ospfIfStateChange, ospfVirtIfStateChange,
>>ospfNbrStateChange and ospfVirtNbrStateChange notifications by generating them only for terminal
>>state changes and backward tansition. Do we really need to ignore them during the initial activity?.
>>
>>Other statement is "Additionally, ospfMaxAgeLsa and ospfOriginateLsa traps should not be originated
>>until two dead timer intervals have elapsed where the deadtimer interval used should be the dead
>>timer with the smallest value." Here whats the meaning of "dead timer with smallest value"? Is it
>>the smallest interval value among all the interfaces?
>>
>>
>>Section 4.4 Throttling Traps
>>----------------------------
>>Do we need to provide MIB objects corresponding to window size and the number of TRAPs sent during
>>the window time? Will the TRAPs other than ospfTxRetransmit, OrginateLsa and MaxAgeLsa really cause
>>a TRAP flood? Probably we need to throttle only the above three TRAPS?
>>
>>I think the normal practice is to inform the NMS using some other notification at the end of a
>>particular interval when the TRAPs are dropped like this, "Trap N dropped n times in an interval
>>t". We can add some common extra paratmeters to these notifications to facilitate the NMS to query
>>the router to retrieve some values and find out whats happening.
>>
>>ospfConfigErrorType
>>-------------------
>>Do we need an error type for duplicate router id in the received messages? Some times loop back
>>address can be misconfigured.
>>
>>ospfSetTrap
>>-----------
>>The definition of this is little complicated. Any reasons for going for last bit to first. We think
>>its better to redefine this MIB object like this to make if more clear.
>>
>> cospfSetTrap OBJECT-TYPE
>> SYNTAX BITS {
>> ifConfigError (0),
>> virtIfConfigError (1),
>> ospfNbrStateChange (2),
>> .
>> .
>> .
>> }
>> MAX-ACCESS read-write
>> STATUS current
>> DESCRIPTION
>> "A One-octet string serving as a bit map for
>> the trap events defined by the OSPF traps in
>> this MIB. This object is used to enable and
>> disable specific OSPF traps where a 1
>> in the corresponding bit field represents
>> enabled."
>> ::= { cospfTrapControl 1 }
>>
>>This definition enables the NMS to interpret the bit map easily.
>>
>>
>>ospfIfStateChange
>>-----------------
>>
>>>From the definition it looks like this TRAP should be generated only for terminal states(when state
>>progresses) and for backward transition. Infact the name ospfIfStateChange simply suggests to
>>generate TRAPs for all state transitions. The general tendency is to ignore the DESCRIPTION when
>>"StateChange" is read and assume its for all the state changes. It might lead to wrong
>>implementations. I think we can also follow the approach taken in BGP MIB(rfc1657).
>>There they have notifications like this,
>> bgpEstablished NOTIFICATION-TYPE
>> OBJECTS { bgpPeerLastError,
>> bgpPeerState }
>> STATUS current
>> DESCRIPTION
>> "The BGP Established event is generated when
>> the BGP FSM enters the ESTABLISHED state."
>> ::= { bgpTraps 1 }
>>
>> bgpBackwardTransition NOTIFICATION-TYPE
>> OBJECTS { bgpPeerLastError,
>> bgpPeerState }
>> STATUS current
>> DESCRIPTION
>> "The BGPBackwardTransition Event is generated
>> when the BGP FSM moves from a higher numbered
>> state to a lower numbered state."
>> ::= { bgpTraps 2 }
>>
>>Our suggestion is to maintain ospfIfStateChange and use that for monitoring all the states
>>(some people may want that) and additionally have notifications similar to the BGP notifications.
>>Its also true with VirtIfStateChange, NbrStateChange and VirtNbrStateChange. If somebody doesn't
>>want to see ALL state TRAPS, they can suppress them by turning off the corresponding bit in
>>ospfSetTrap.
>>
>>
>>ospfNbrStateChange
>>------------------
>>The DECRIPTION clause states
>>"When an neighbor transitions from or to Full on non-broadcast multi-access and broadcast
>> networks, the trap should be generated by the designated router. A designated router
>>transitioning to Down will be noted by ospfIfStateChange."
>>I think here the intention is to reduce the number of TRAPs as much as possible by making
>>only DR sending out this TRAP for a subnet. But there is a possibility that osfpNbrStateChange
>>notification is disabled on DR and enabled on DR other or BDR. NMS won't receive TRAPs when
>>NbrState becomes FULL in that case. There is a problem with the second part of above statments
>>as well. Suppose ospfIfStateChange is disabled on the router, then again NMS won't know when
>>neighbor goes down. Probably its better to remove these two clauses.
>>
>>
>>Support for sham links:
>>-----------------------
>>Are you going to provide support for sham links? We may need these tables and notifications,
>>ShamLinkTable
>>ShamLinkNbrTable
>>ShamLinkStateChange notification
>>ShamLinkNbrStateChange notification
>>
>>
>>
>>
>>
>>
>>
>

--
Acee

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