Subject: Re: draft-ietf-idmr-pim-mib-07.txt

From: Dave Thaler <[email-masked]>
Date: Fri, 17 Sep 1999 17:59:54 -0700 (PDT)

> I was looking through draft-ietf-idmr-pim-mib-07.txt and didn't see
> anything about sending traps for neighbor state changes. I seemed
> to remember requesting this a long time ago but it either fell
> through the cracks or must have been rejected. Anyone else think
> this is useful?
> 
> Another trap when the BSR changes or when you have no RP's might
> also be useful.
> 
> Thanks,
> Tom

I just submitted draft-ietf-idmr-pim-mib-08.txt.
The changes from -07 are:

1) Module name changed to PIM-STD-MIB and root id changed
   to pimStdMib, by request of Keith, to avoid clash with
   PIM-MIB under experimental space.
2) Changed root oid to { mib-2 XX } in preparation for
   moving to Proposed Std.  Also closed holes in the OID
   space by changing the oids for two tables since the root
   oid will change anyway.
3) Added pimNeighborLoss trap, mentioned by Tom in email above.
   Text is roughly the same as in the DVMRP MIB, just with
   the appropriate PIM wording.  Specifically:
      "A pimNeighborLoss trap signifies the loss of an adjacency
      with a neighbor.  This trap should be generated when the
      neighbor timer expires, and the router has no other
      neighbors on the same interface with a lower IP address than
      itself."
4) Fixed up overview section to add mention of tables that
   were in the MIB but missing from the overview.

Did NOT add trap when the BSR changes since this may cause
a trap implosion, and there is no simple rule (that I could
think of anyway) to suppress these like there is for neighbor loss.

Did NOT add trap for when you have no RPs for the same reason,
and because it's recommended (in the PIM deployment guidelines)
that the BSR become an RP automatically in this case.  If
someone is going to write code to detect no RPs, they could just
as well write code to become one instead of sending a trap.

-Dave