Subject: RE: [pim] Working Group Last Call: PIM MIB

From: "David McWalter" <[email-masked]>
Date: Thu, 9 Feb 2006 17:23:30 -0000

Hi Lori.

PIM mode and group-to-RP mapping are obtained in the same way.

So if we statically configure an RP for the group, the PIM mode gets configured along with it as pimStaticRPPimMode.  Or if RPs are discovered using BSR, we get an SM/BIDIR bit in the advertised group address.  I imagine Auto-RP and Embedded-RP must have similar mechanisms.

You're quite right that the following three read-only fields must now allow the value of dm(5).  Thanks for spotting that, I'll make sure it gets fixed.
pimStaticRPPimMode
pimStarGPimMode
pimSGPimMode

The field pimGroupMappingPimMode is fine, since we haven't declared a restricted syntax for it.

I guess that still leaves ambiguity in the case where we don't have an RP, so for groups in the SSM range, and perhaps if implementations are trying to cope with (S,G) membership for ASM G in the absence of an RP.  In these cases it's not clear from the MIB how an implementation should pick a PIM mode, and an administrator can't predict behavior by querying the MIB.

In practice this looks like a non-issue, because BIDIR always requires an RP, and I'm not expecting any hybrid SM/DM implementations ever.  We can also argue that DM is only experimental, and this MIB doesn't intend to support it fully.

However, if anyone needs this resolved then it's not that hard.  For example, we could add a read-only global object to specify whether DM/SM is used in the SSM range.  If anyone has a requirement here, let me know.

I've copied Jonathan because of his interest in getting DM support in PIM-MIB.

Ta,
DMcW.

-----Original Message-----
From: Lori Mickelson [mailto:[email-masked]]
Sent: 09 February 2006 16:38
To: David McWalter
Cc: [email-masked]; [email-masked]
Subject: Re: [pim] Working Group Last Call: PIM MIB

Hi Dave and John,

Ok. so if PIM mode is a property of the group, how do you get a particular
group to be used with dense mode?   If we could get an entry into
the pimGroupMappingEntry table with a mode of dense, this would explain
things for me, but I don't see anywhere in this MIB that allows
configuration for a particular group to be dense mode.  I'm obviously
missing something here.

pimStarGPimMode and pimSGPimMode are read-only and pimStaticRPPIMMode
only specifies ssm, asm or bidir as options.

Also, you only list { ssm(2), asm(3) } for pimSGPimMode.  Shouldn't you
add dm(5) to the list as well since you do include several DM only
objects in this table.

Thanks,
Lori

On Wed, Feb 08, 2006 at 10:50:44PM -0000, David McWalter wrote:
> Hi Lori.
> 
> Good question.  This is an interesting area.
> 
> I agree with John's answer - PIM mode should be a property of the Group, not the Interface.
> 
> PIM-MIB has four objects where PIM mode can be written/read, all below a particular Group.
> pimStaticRPPimMode
> pimGroupMappingPimMode
> pimStarGPimMode
> pimSGPimMode
> 
> So there's no way in PIM-MIB to set/read a particular PIM mode on an interface.
> 
> But looking outside of PIM-MIB, RFC2932 (IPMROUTE-STD-MIB) *does* have a value from IANAipMRouteProtocol readable on each interface.  See ipMRouteInterfaceProtocol in RFC2932.  I believe that's wrong.
> http://www.ietf.org/rfc/rfc2932.txt
> http://www.iana.org/assignments/ianaiprouteprotocol-mib
> 
> I'm planning some fixes to RFC2932, among them deprecating ~InterfaceProtocol.  If anyone would like details on that work, see the following draft and discussion of it in MBONED. (MBONED because it's not PIM-specific).
> http://www.ietf.org/internet-drafts/draft-mcwalter-ip-mcast-mib-01.txt
> 
> Hope that answers your concerns.
> Dave McW.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> John Zwiebel
> Sent: 08 February 2006 21:48
> To: Lori Mickelson
> Cc: [email-masked]
> Subject: Re: [pim] Working Group Last Call: PIM MIB
> 
> 
> 
> On Feb 8, 2006, at 1:33 PM, Lori Mickelson wrote:
> 
> >  Otherwise, how do you know if you're running
> > Sparse or Dense Mode on the interface?
> >
> 
> "sparseness" is a property of the group not the router interface.
> 
> This is why IOS recommends "sparse-dense" mode.
> 
> Procket did not support dense-mode and so the config command was just  
> "ip pim sparse"
> 
> Configuring "ip pim dense" is a holdover from PIMv1 where it was up  
> to the
> router to forward a group using whatever method (sparse or dense)  
> that it
> wanted to.  We quickly realized that was a mistake.
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pim

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

---

From: "David McWalter" <[email-masked]>
Date: Thu, 9 Feb 2006 20:19:27 -0000

Chris,

Thanks for all that.  New information for me.

John wrote:
> The information document would basically say:
> 
>    If there is no known RP for a multicast group, it is treated as a
>    dense-mode group - by _some_ implementations.

This behavior seems pretty interesting to administrators, so perhaps I should make it readable from the standard MIB.

How about I add a read-only field (per-interface?) that specifies what pim mode the router will use in the absence of RP config.  If some implementations want to use the object as a read-write, then fine, they can.  The description can also explain that the usual source of the PIM mode is from the RP configuration, by pointing at pimGroupMappingPimMode.

Would that standardize the behavior (and get this information published) in an acceptable way?
Dave McW.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Christopher Thomas Brown
Sent: 09 February 2006 19:37
To: [email-masked]
Subject: Re: [pim] Working Group Last Call: PIM MIB

David McWalter initiated a hyperspace jump with:
> Hi Christopher.
> 
> As far as I know, sparse-dense means 'PIMv1'.  Here's the IANA definition:

The two leading brands of router vendors (and probably others) implement a
hybrid sparse-dense with PIMv2.  In this mode a group is sparse (or
Bi-dir) if an RP is known for the group; otherwise, it is dense.

> 
> We're no longer doing PIMv1.  PIM-MIB is for PIMv2, and so makes no mention of sparse-dense.

Yeah, but several vendors implement a sparse-dense. Which was my main
point. Should the WG document this type of use at least as informational?

> So asm != sparse-dense.  PIM-MIB is clear on this point:
>             asm(3)       Any Source Multicast (ASM), with PIM Sparse
>                          Mode.

I don't think the bare word 'asm' should be used here. Dense and DVMRP are
ASM protocols as well. Even though you explicitly define it you will
have people like me that glance over it and get confused when seeing a
word like 'asm'. Maybe renaming 'ssm' to 'sparse-ssm' and 'asm' to
'sparse-asm' make things clearer and consistent?

> 
> PIM DM was experimental, and I don't think the PIM WG has any plans to do anything more with DM.
> 
> The *minimal* support for DM in PIM-MIB is an exception we are making, because this appears very easy and people tell me there are significant benefits for them.

The benefit is that its better than writing an enterprise mib for dm. :)

Chris

---

From: "bharat_joshi" <[email-masked]>
Date: Fri, 10 Feb 2006 09:00:27 +0530

Please see in line.

>
> Tom Pusateri initiated a hyperspace jump with:
> > I struggle with any support at all for Dense mode in the MIB.
> > I suspect it will have to be taken out in order to advance it
> > to Proposed Standard since the Dense Mode document is an
> > Experimental Standard.
>
> Is this the relavant constraint?
> RFC 2026 s4.2.4:
> "Note: Standards track specifications normally must not depend on
> other standards track specifications which are at a lower maturity
> level or on non standards track specifications other than
> referenced specifications from other standards bodies."
>
> So what qualifies for abnormal?
>
> It would be nice if those of us who implement dm don't have to
> rewrite some of the pim mib as an enterprise mib for a few objects.
> Just nice, not really a necessity though.
>
> > We need to be looking forward and not back. We certainly don't
> > need to write any new documents about things like sparse-dense
> > mode. Those are implementation choices and the vendors can
> > document those as they see fit.
> >
> > Sorry if this sounds harsh. We just need to move on.
>
> So I take it that you don't want anyone to volunteer for this. :)
>
> I only brought this up because the MIB seems to be going in the
direction
> that the sparseness-bidirness vs denseness of a group is a property of
> the group, which is only true if there is such a thing as
'sparse-dense'.
> Nothing this wg has produced documents this except for potentially
this
> MIB,
> which is a poor place to do that.
>
> With dm, sm and bidir documented as they currently are by this wg,
> one could have a pmbr which serviced both a 'dense-mode-only' domain
and
> a 'sparse&bidir-only' domain.  On such a mythical router, groups would
be
> sparse or bidir on the later set of interfaces and dense on the
former.
>
> Upon further reflection the way I see it is that sparse vs dense
> interactions are an undocumented confusing mess. As much as I would
> like to see dm values in the mib, I would not like to see the mib
> further some interpretation of the mess without documenting that
> interpretation.  Lacking such documentation, I think it would
> just be better if dm support is dropped from the mib.

Hi,

    I think we have completed a full circle on whether we want to
support PIM DM objects in this MIB or not.

    When we started, Jonathan had added PIM DM objects to the first PIM
MIB draft. Later we removed it thinking that this may not be the right
place to add these objects and should be moved to another MIB draft.

    We again added it after seeing Jonathan's PIM DM Objects as they
were very small in numbers and no one objected to it.

    So let us figure out whether someone would really want this before
deciding anything on this.

Thanks & Regards,
Bharat

**************** 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***

---

From: "Nicholas, Jonathan - ACD " <[email-masked]>
Date: Wed, 15 Feb 2006 10:53:22 -0500

All,

For the DM Conformance group, the descriptive text should be changed to
read,

"A collection of objects required for management of PIM Dense Mode
(PIM-DM) function.  The groups pimSsmGroup and pimSmGroup are also
required."

Jonathan Nicholas
************************************
This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Industries, Inc. The recipient should check this e-mail and any attachments for the presence of viruses. ITT Industries accepts no liability for any damage caused by any virus transmitted by this e-mail.
************************************