Subject: [pim] PIM MIB issues presented at the WG meeting

From: "James Lingard" <[email-masked]>
Date: Fri, 5 Aug 2005 19:21:01 +0100

At the PIM WG meeting on Tuesday, I gave a presentation about the current state of work on the PIM MIB.  During that presentation, I presented several major open issues for discussion.  This email summarises what I recall (based on notes taken during the meeting) of the discussion of each of those issues, and documents the resolutions that I am proposing based on that discussion.

If you have any further comments on these issues, or if you disagree that this is an accurate account of the discussion that took place at the meeting, please let me know.  However, please note that I will be away on vacation for the next four weeks and so won't be able to respond to any emails until September.

I hope to be able to continue work on the MIB, including working on resolving all these issues, shortly after I'm back.

Regards,
James.

----------------------------------------------------------------------

Issue: Should we move the BSR-specific tables and objects to a separate
MIB?

Discussion:
-  Tom asked if there were any objections to this, and there were none.

Result: We will move the BSR tables to a separate BSR MIB draft.

----------------------------------------------------------------------

Issue: Should we move the SSM Range table to a separate MIB?

Discussion:
-  There seemed to be a consensus that the PIM MIB was the wrong place
   for this table.
-  Various people suggested moving it to the IP Multicast Routing MIB,
   the IP MIB, a new SSM MIB, or a new IP Multicast MIB.
-  There seemed to be a consensus that the existing IPv4 Multicast
   Routing MIB should be updated, and that if that is actually going to
   happen, then changing that to a more general IP Multicast MIB to
   incorporate this table and other objects of interest to hosts would
   be a good plan.

Result: A team has already met to start working on a new IP Multicast
MIB to update and replace the existing IPv4 Multicast Routing MIB, and
this new MIB will also include the SSM Range table.  In addition,
Toerless and I have already discussed how to clarify the PIM MIB to make
sure that the meaning of the 'ssm' value of the PimMode TC means PIM-SSM
and not SSM in general.

----------------------------------------------------------------------

In general, there was consensus that all the below additions could be
done, but we don't want to stall the current progress on the MIB, and
it's better to leave things out and get something done than try to put
too much in and never get it finished.

----------------------------------------------------------------------

Issue: What should be done about MIB support for PIM-DM?

Discussion:
-  Bill said that having a normative reference to an experimental
   protocol would be OK if necessary (there's a process for doing this),
   so DM could be supported in the base PIM MIB.
-  But if a large amount of work would be required, it should be put
   somewhere separate so as not to hold up progress on the base MIB.

Result: We should look at whether or not it's significantly easier to
put PIM-DM support in the existing MIB over creating a separate
document.  If not, it's best just to put the PIM-DM MIB in a separate
document.  Making small changes to the core MIB to facilitate this
(e.g. adding a 'dm' value to the PimMode TC) is fine.

----------------------------------------------------------------------

Issue: Should we support explicit tracking of next-hop neighbors in the
tree state tables?

Discussion:
-  There was consensus that it would be desirable for the PIM MIB to
   support this.
-  Various people said that there are existing implementations, and that
   it would be quite easy to do.
-  Personally, I believe that this would require three new tables
   rather than an addition of an index field to the three existing
   (*,G), (S,G) and (S,G,rpt) state tables, because for example you
   don't need to track Assert state on a per-neighbor basis.  So
   therefore this could easily go in a separate MIB.

Result: We'll look into what would be necessary for this, and how much
work would be required.  If it's easy to add and we have time, then
we'll do it.

----------------------------------------------------------------------

Issue: Do we need support for 'Scope zones' or 'components'?

Discussion:
-  Multi-component support not necessary for virtual routers, since the
   Entity MIB enables this in a generic manner.
-  For BSR, Toerless requested 'single zone' scope support'.

Result:  Nothing to do for the base PIM MIB, since no need to support
multiple components.  We'll look in more detail at scoping within the
(now separate) BSR MIB.

----------------------------------------------------------------------

Issue: Do we need support for Anycast RP using PIM?

Discussion:
-  Consensus that we should do this, if possible.
-  It shouldn't be very difficult to add.

Result: We will add this to the base PIM MIB.  Dino and Raghava may be
able to help by contributing their experience from their
implementations.

----------------------------------------------------------------------

Issue: Should we add PIM message statistics collection?

Discussion:
-  Dave Thaler said that unless the counters are providing the answer to
   a specific question that may be asked by operators, they should be
   omitted.  Otherwise they add implementation complexity for no known
   benefit.
-  Dino said that although PIM message statistics can be interesting,
   protocol violations are much more useful, and there are hundreds of
   possible problems that we could potentially keep counters of.

Result: These may be useful, but we won't add them unless we get an
explicit requirement from operators.  Otherwise we could just be wasting
our time.

----------------------------------------------------------------------

Issue: Should we leave the I-D for a year, to wait for implementations
or operational experience, or move quickly to RFC?

Discussion:
-  Some in favour of one approach, some in favour of the other.

Result: No real consensus, but my recollection is that more seemed in
favour of moving to RFC quickly.

----------------------------------------------------------------------

Issue: How can we get more reviewing of the MIB?

Discussion:
-  Tom asked for three volunteers to review the MIB.

Result: Dave Thaler, Andy Kessler and Bill Fenner are going to review
it.

----------------------------------------------------------------------

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