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

From: "David McWalter" <[email-masked]>
Date: Fri, 16 Dec 2005 09:26:31 -0000

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

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 16 Dec 2005 15:06:00 +0530

Hi David,

> (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 has…

I did not object because I feel its not big enough changes to stop our
progress and no one else seems to be worrying about it.

Does anyone have implemented any version [greater than 2] of this MIB?
We can get some feedback from such people as well.

Thanks & Regards,
Bharat

> (17) pimInterfaceHelloHoldtime and pimInterfaceJoinPruneHoldtime should be read-create.  They're currently read-only.

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***