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

From: "David McWalter" <[email-masked]>
Date: Wed, 8 Feb 2006 22:50:44 -0000

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: Lori Mickelson <[email-masked]>
Date: Thu, 9 Feb 2006 09:37:37 -0700

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

---

From: "Christopher Thomas Brown" <[email-masked]>
Date: Thu, 9 Feb 2006 12:20:57 -0500

> configuration for a particular group to be dense mode.  I'm obviously

In 'sparse-dense' a group is sparse if an RP is known for the group;
otherwise it is dense.  This shouldn't be something that is directly
settable on the group object. Its a dynamic property.

> add dm(5) to the list as well since you do include several DM only

If I'm not mistaken tehn asm = sparse-dense.

I'm getting the feeling that maybe the working group should publish
a document (informational?) on sparse-dense.  There are implementations
of PIM out there where sparse and dense are mutually exclusive on an
interface.

Chris

---

From: "Jonathan Natale" <[email-masked]>
Date: Thu, 9 Feb 2006 12:29:37 -0500

see inline

> Christopher Thomas Brown
> Sent: Thursday, February 09, 2006 12:21 PM
> To: [email-masked]
> a document (informational?) on sparse-dense. 
I agree.

> There are implementations

---

From: John Zwiebel <[email-masked]>
Date: Thu, 9 Feb 2006 11:00:59 -0800

>> a document (informational?) on sparse-dense.

Perhaps, but be aware that "sparse-dense" is a cisco specific way of
configuring its router, is only there because that was how the  
transition
from pimv1 to pimv2 was supported, and isn't a term used in any IETF
document that I'm aware of.

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.

I say "some" because not all vendors implement dense-mode.  It has
proven to be problematic and any application can use sparse or
bidir just as easily.

I'm not saying that no one uses dense-mode, just that AFAIK the
amount of deployed dense-mode is quite low.

2cents follows...
IMHO, ssm and bidir are where the community should be placing its
focus.  I agree that there are some applications where it is "nice"
to be able to use sparse-mode so receivers don't have to know the
specific source, but I think it would be "better" to implement
an alternate "source DNS" capability that is outside of PIM and
does not involve the network in storing source information.  (ie
it should be in a real database somewhere on a real server.)
That way receivers can control which sources they want to receive
from using more information than just the multicast group.  For
example, a DNS-like source-name server (for want of a better term)
could cache all the SAP information available on a specific source.
Receivers would join to just those sources that were providing exactly
what the receiver desired (using SSM).

In those cases where you know that the multicast group is tightly
controlled such that there is no way that sources will be sending
anything but the desired information, use bidir.

---

From: "Christopher Thomas Brown" <[email-masked]>
Date: Thu, 9 Feb 2006 14:49:57 -0500

> document that I'm aware of.

Not only Cisco has implemented this.  If I'm not mistaken then
Juniper implements this,  I've encountered customer interest in it
from time to time.

>    dense-mode group - by _some_ implementations.

Yeah, it would be fairly short. It might be nice to have some text
on how a sparse-to-dense or dense-to-sparse transition should be
handled.

Chris

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 09 Feb 2006 15:43:57 -0500

If people want to implement Dense mode, that is their choice.  But
as far as the PIM WG is concerned, we have no further interest in
it.  That was clear by how hard it was to progress the dense mode
document.  No one would even review it. If it wasn't for Jonathan,
the document would have just died.  There is maybe a handful of
people in the world who care.

Those small number of people who have interest in dense mode can
spend their time working on it as private submissions but unless
the feelings of the majority of the PIM working group change
drastically in the future, Dense mode is now outside the scope of
the working group.

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.

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.

Thanks,
Tom

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Feb 2006 12:52:34 -0800

> Juniper implements this,  I've encountered customer interest in it

There's no IETF definition for what this "sparse-dense" mode means,
and if one where to write one you would first figure out that word
was badly choosen anyhow ("all-modes" would have been more appropriate)
and/or it would conflight with the IETF defined behavior of sparse mode.

There's a lot of customer interest in stuff they have read in old
manual and don't understand. Which typically isn't really a customer issue
but a bad-vendor-documentation issue. It only becomes a mess when the
feedback loop closes by which stuff the customer didn't understand is
now being put as input into cfuture vendor work. So let's not do this.

Cheers
    Toerless

---

From: "Christopher Thomas Brown" <[email-masked]>
Date: Thu, 9 Feb 2006 19:26:26 -0500

> to Proposed Standard since the Dense Mode document is an

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.

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

Chris

---

From: "Jonathan Natale" <[email-masked]>
Date: Fri, 10 Feb 2006 06:58:41 -0500

I agree that spare mode is and should be the main and maybe the only focus.
my only point is that sparse-dense behavior should maybe have a brief
historical/info rfc--does one exist? is there only one vendor that supports
it?  ...has it gone from the 'recommended' to
'never mind that man behind the curtain' status ????  -$0.02

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Tom
> Pusateri
> Sent: Thursday, February 09, 2006 3:44 PM
> To: [email-masked]