Subject: [pim] PIM MIB trap comments

From: "Andy Kessler \(kessler\)" <[email-masked]>
Date: Fri, 17 Feb 2006 10:16:12 -0800

Hi Dave, 

Some comments on the traps in the PIM MIB draft. 

1. The way the ciscoPimRPMappingChange defined in the 
   CISCO-PIM-MIB the router actually sends two separate traps
   for each mapping change - one with the old and one with the
   new RP mapping. Now this could get kinda crazy when there
   are hundreds of RP mapping changes and we generate all those
   traps.

   I like the approach you took with the pimRPMappingChange. 
   You will only send a trap that 'something has changed' and
   it can be rate limited. 

   We should consider two things: 

   a. Is there a way we can include information about which RP
      has changed its mapping information ? Maybe just another
      object that contains the RP of the last RP mapping change
      and that gets sent in the trap. This would at least help
      narrow down figuring out what has changed if you have many
      RP mappings. 

   b. Should the pimRPMappingChangeCount also increment if a static
      mapping has changed? Some people may argue that you know when
      a static mapping changes because you change it. Also it only 
      affects one router. But it is also nice to have a log of when
      a static mapping has changed especially when you have many 
      people working in operations. 

2. In the definition of the pimNeighborLoss trap you 
   list the rate limit as pimNeighborLossPeriod. It should
   be pimNeighborLossTrapPeriod. 

3. Minor typo:

   In the pimRPMappingChangeCount definition you have: 

   "Only changes to active mappings cause his count to be 
    incremented."

   I think you mean "... this count ..."

Andy

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: "David McWalter" <[email-masked]>
Date: Fri, 17 Feb 2006 18:47:33 -0000

Hi Andy.

Thanks for reviewing this - much appreciated.

1.a.  The RP address is present in the trap, hidden in the objects
pimGroupMappingPimMode and pimGroupMappingPrecedence.  These objects
drag their OID along with them, including pimGroupMappingRpAddress.  So
in effect, the trap hands you a whole pimGroupMappingEntry.

1.b.  Statically configured RPs are already included.  Local static RP
configuration may change entries with pimGroupMappingOrigin set to
configRp(2), and these can increment pimRPMappingChangeCount like any
other mapping change.  The description of pimRPMappingChangeCount says
that it includes them:
            ...
            Such changes may result from configuration of this device,
            or from automatic RP mapping discovery methods including
            the PIM Bootstrap Router (BSR) mechanism."

I could say 'static configuration of this device,' or 'manual
configuration of this device,' if that will make it clearer.  Let me
know what text you prefer.

2.  Thanks - will fix.

3.  Thanks - will fix.

DMcW.

-----Original Message-----
From: Andy Kessler (kessler) [mailto:[email-masked]]
Sent: 17 February 2006 18:16
To: David McWalter
Cc: [email-masked]
Subject: PIM MIB trap comments

Hi Dave, 

3. Minor typo:

Andy

---

From: "Andy Kessler \(kessler\)" <[email-masked]>
Date: Fri, 17 Feb 2006 11:08:48 -0800

Comments inline.  

> From: David McWalter [mailto:[email-masked]] 
> Sent: Friday, February 17, 2006 10:48 AM
> To: Andy Kessler (kessler)
> Cc: [email-masked]
> Subject: RE: PIM MIB trap comments
> 
> Hi Andy.
> 

Ok, I thought about that. I suppose its implied that the 
pimGroupMappingPimMode will apply to the mapping that has caused
pimRPMappingChangeCount to increment. There is a lot of implied
linkage in the mibs that I don't always follow. 

> know what text you prefer.

"manual configuration" would be fine. I was fixating on some of the 
language in the preceding paragraph. I re-read it and if you make the
'manual' change then its clear.

Andy