Subject: RE: [pim] draft-ietf-pim-mib-v2-04 feedback

From: "Andy Kessler \(kessler\)" <[email-masked]>
Date: Thu, 22 Dec 2005 10:39:17 -0800

Dave, 

The list looks good. If we add the counters for those errors
and still have the options for the traps we are in good shape. 

What about adding a way in the mib to enable/disable the trap?

There should also be defined an enumerated-INTEGER object to 
enable/disable the generation of those types of notification. 
If desired, a single enable/disable object can be defined to apply 
to several related notifications. 

Andy 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of David McWalter
> Sent: Friday, December 16, 2005 1:27 AM
> To: [email-masked]
> Subject: [pim] draft-ietf-pim-mib-v2-04 feedback
> 
> Folks,
> 
> I've received some good feedback on the PIM MIB -04 draft.  
> Thanks to all who've contributed.
> 
> Below are the actions I will take to generate -05.  If you 
> have further views or comments, I'd welcome them.
> 
> David McW.
> 
> 
> _Dense Mode_
> (1)  PIM MIB will change to support Dense Mode.  Jonathan 
> Nicholas suggested including Dense Mode in PIM MIB, and 
> outlined the changes required to do this.  Bharat raised some 
> questions, but he hasn't followed up with an objection.  
> Jonathan's changes are pretty straightforward, so I will just 
> apply them to the MIB.
> 
> _pimAnycastRpSetTable_
> (2)  I've heard concerns about this table causing PIM MIB to 
> normatively reference I-D.ietf-pim-anycast-rp.  No one has 
> expressed strong views, so I plan to leave it in PIM MIB.
> 
> _Trap pimDRElection_
> (3)  This trap will be broadened to include BIDIR DF 
> elections.  I'll call it pimInterfaceElection.
> (4)  Only the new election winner will trap.  I will change 
> the text so that old election winners do not trap when they 
> lose.  If administrators need notification of loss of DR/DF 
> status (for example, at CE/PE where other routers are not 
> under their control), then they must poll for it.
> 
> _Trap pimRPMappingChange_
> (5)  I will add an equivalent counter object to use as an 
> alternative to this trap.
> (6)  Must limit the frequency of this trap.  Therefore it can 
> only state that some mappings have changed; no longer one 
> trap per mapping change.
> (7)  The object pimRPMappingChangeType is way too complex.  
> I'll delete it.
> 
> _Trap pimUnexpectedRegister_
> (8)  I will add an equivalent counter object to use as an 
> alternative to this trap.
> (9)  A better name would be pimIllegalRegister or 
> pimInvalidRegister.  I'll change it [back] to pimInvalidRegister.
> (10)  There are serious DoS concerns with this trap.  Must 
> limit its frequency and place in a separate conformance group.
> 
> _Trap pimUnexpectedJoinPrune_
> (11)  I will add an equivalent counter object as an 
> alternative to this trap.
> (12)  A better name would be pimIllegalJoinPrune or 
> pimInvalidJoinPrune.  I'll change it to pimInvalidJoinPrune.
> (13)  There are some DoS concerns with this trap.  Must limit 
> its frequency and place in a separate conformance group.
> (14)  Needs better text explaining how this trap is generated 
> (bad group-to-RP mapping detected).
> 
> _Statistics_
> (15)  It would be useful to count Asserts sent/received.  I 
> will add this to the interface, (S,G,I) and (*,G,I) tables.  
> I think this is justified; there's no other way to get the 
> information.
> (16)  It would be useful to count Registers sent/received.   
> But I do not plan to add this.  Implementations can use 
> virtual encapsulation interfaces, and then existing interface 
> statistics do this job very well.
> 
> _Minor Stuff_
> (17) pimInterfaceHelloHoldtime and 
> pimInterfaceJoinPruneHoldtime should be read-create.  They're 
> currently read-only.
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pim
> 

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