Subject: Re: OSPFv2 MIB draft

From: Roy Jose <[email-masked]>
Date: Fri, 14 Mar 2003 20:16:34 +0530

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

---

From: Acee Lindem <[email-masked]>
Date: Fri, 14 Mar 2003 17:56:51 -0500

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

---

From: Manikantan Srinivasan <[email-masked]>
Date: Fri, 14 Mar 2003 16:33:51 -0800

Acee

I agree with you for adding OSPF instance ID as an index.
This approach is simple and elegant.

I have worked on an implementation with the same approach,
using enterprise MIB.

cheers
mani
====================================
Manikantan Srinivasan
Future Communications Software
====================================

#-----Original Message-----
#From: Mailing List [mailto:[email-masked]]On Behalf Of Acee
#Lindem
#Sent: Friday, March 14, 2003 2:57 PM
#To: [email-masked]
#Subject: Re: OSPFv2 MIB draft
#
#
#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
#>>
#>>
#>>
#>>
#>>
#>>
#>>
#>
#
#
#--
#Acee
#

---

From: John Flick <[email-masked]>
Date: Fri, 14 Mar 2003 16:49:50 -0800

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.

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.

John

---

From: Roy Jose <[email-masked]>
Date: Mon, 17 Mar 2003 15:11:23 +0530

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

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

> 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

---

From: Roy Jose <[email-masked]>
Date: Mon, 17 Mar 2003 15:17:52 +0530

One more point I would like to add. Please see below.

> from a particular routing instance.

Other confusion can be, how can the NMS interpret the routing instance from
the TRAP messages it receives.

-Roy

> > > >>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
> > > >>separate MIB view for each process. But I don't think it can be
easily
> implemented.
> > > >>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
> > > >>separately. By removing these MIB objects, we can reduce the size
and
> processing time of TRAP
> > > >>The section states "The majority of critical events occur when OSPF
is
> enabled on a
> > > >>I think there will be some problems if the dead interval value is
too
> long. We may end up
> > > >>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
> > > >>state changes and backward tansition. Do we really need to ignore
them
> during the initial activity?.
> > > >>
> > > >>timer with the smallest value." Here whats the meaning of "dead
timer
> with smallest value"? Is it
> > > >>Do we need to provide MIB objects corresponding to window size and
the
> number of TRAPs sent during
> > > >>t". We can add some common extra paratmeters to these notifications
to
> facilitate the NMS to query
> > > >>>From the definition it looks like this TRAP should be generated
only
> for terminal states(when state
> > > >>implementations. I think we can also follow the approach taken in
BGP
> MIB(rfc1657).
> > > >>want to see ALL state TRAPS, they can suppress them by turning off
the
> corresponding bit in
> > > >>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
> > > >>NbrState becomes FULL in that case. There is a problem with the
second
> part of above statments

---

From: Acee Lindem <[email-masked]>
Date: Mon, 17 Mar 2003 12:57:07 -0500

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
     do this, we'll never finish the MIB update.

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Mon, 17 Mar 2003 13:06:24 -0500

One small correction.

>      may not ever reach draft standard status. If we don't
                          ~~~~~~~~~~~~~~
   Meant to say "proposed standard" here.

---

From: kajol pattnaik <[email-masked]>
Date: Mon, 17 Mar 2003 13:02:18 -0800

Hello,
  Are there any IETF standard/document  for IGP/OSPF
 fast reroute as has been presented by alex zinin and
chenigz in their presentation :"IGP Fast Reroute" ,
slides can be found at
http://www.packetdesign.com/news/presentations.html

This seems to be a good alternative to IGP fast
convergence, to achive sub-second re-routing wit IGPs,
by generating a two(or a fixed number of) best routes
rather than one best route.

If there are any IETF standards on this or, any work
in progress in IETF, please point me to the documents.
or, is this completely implementation specific.

Are there any vendor /academic implementation that
supports IGP/OSPF fast rerouting as presented above??

thanks,
kajol.

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

---

From: Roy Jose <[email-masked]>
Date: Tue, 18 Mar 2003 12:03:10 +0530

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

> > > > Yep, adding an index would require deprecating everything and
starting
> > > over.
> > > > of an existing object is not allowed, you would need to deprecated
the
> > > index
> > > > to not-accessible is not required, since SMIv2 allows read-only
indices
> > > for
> > > > read-only indices.  The OSPFv2 MIB started life in RFC 1248 as an
SMIv1
> > > MIB
> > > > > > I have some comments on draft-ietf-ospf-mib-update-05.txt. I
would
> > > also like
> > > > > >>We raised this issue some time back in WG. Currently MIB
supports only
with
> > > other MIB objects
> > > > > >>like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution
we
> > > got was to use a
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
> > > > > >>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
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
> > > > > >>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
> > > > > >>Here we don't actually need ospfIfIpAddress and
ospfAddressLessIf.
> > > When we send TRAP
> > > > > >>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
> > > > > >>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
> > > > > >>Other statement is "To avoid unnecessary traps, a router should
not
> > > originate expected OSPF
> > > > > >>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
can't
interface
> > > > > >>state changes and backward tansition. Do we really need to
ignore them
> > > > > >>Other statement is "Additionally, ospfMaxAgeLsa and
ospfOriginateLsa
> > > traps  should not be originated
timer
> > > > > >>Do we need to provide MIB objects corresponding to window size
and the
> > > > > >>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
> > > > > >>The definition of this is little complicated. Any reasons for
going
> > > for last bit to first. We think
only
> > > > > >>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
> > > > > >>                            "The BGP Established event is
generated
> > > when
> > > > > >>want to see ALL state TRAPS, they can suppress them by turning
off the
> > > > > >> networks, the trap should be generated  by the designated
router. A
> > > designated router
> > > > > >>I think here the intention is to reduce the number of TRAPs as
much as
possibility
> > > that osfpNbrStateChange
> > > > > >>notification is disabled on DR and enabled on DR other or BDR.
NMS
> > > won't receive TRAPs when
second
> > > part of above statments
> > > > > >>as well. Suppose ospfIfStateChange is disabled on the router,
then
> > > again NMS won't know when
> > > > > >>Are you going to provide support for sham links? We may need
these
> > > tables and notifications,
> > > > > >>ShamLinkTable
> > > > > >>ShamLinkNbrTable