datatracker.ietf.org
Sign in
Version 5.6.2.p5, 2014-08-04
Report a bug

Population Count Extensions to Protocol Independent Multicast (PIM)
draft-ietf-pim-pop-count-07

Note: This ballot was opened for revision 06 and is now closed.

Summary: Has enough positions to pass.

Barry Leiba

Comment (2012-06-14 for -06)

I had been wondering, at the start of reading this, why it was going to turn
out as Experimental, and thank you for explaining that.  I wish such
explanations were always there, and I think it helps a lot.

Benoit Claise

Comment (2012-06-20 for -06)

- Same question as Stephen on my side.
As an OPS A.D., I have to ask: Any connection with the PIM MIB, RFC5060? Or any
other MIB module? Or is the new information only available via a show command
in the routers (as a starting point because it's experimental)?

- I found that many acronyms are not expanded (IGMP, MLD, SSM, ASM, etc..), and
are missing references. Sure they're known if you know multicast. However, the
RFC-editor will flag those, so you might consider easing the RFC-editor lives
and at the end the reader not that familiar with multicast

Brian Haberman

Comment (2012-06-12 for -06)

I have no objection to the publication of this experimental document and only
have a few non-blocking comments.  Take them or leave them as you see fit.

1. The definition of the A/S flag pair seems incorrect.  If A=0 and S=1, that
does not mean that all receivers are "only SSM" receivers.  It means that all
receivers are SSM-capable.  The group joined will have an influence on whether
all receivers are operating in SSM mode.

2. The idea of tracking if an OIF list crosses a domain boundary is
interesting.  How would a router know that a particular OIF links to another
domain?  Is it driven by what protocol caused the OIF to be added (e.g., MSDP
in IPv4)?  It would be good to expand on how that is determined, if there is a
standard way to detect it.

3. Given the use of a PIM Join attribute, these statistics can aggregate up a
multicast distribution tree.  What I would be interested in seeing is *how* a
network operator accesses these stats.  Is it envisioned that a router's CLI
will be used since there is no defined way to push/pull the data out via a
management interface?

4. It is unclear to me how useful the time zone information will be.  As
mentioned in the draft, that information could be contained as an interface
attribute.  However, that may not be sufficient given multi-access interfaces. 
Is there more context that can be added as to how these time zone "boundaries"
are detected/configured/managed?

Stephen Farrell

Comment (2012-06-19 for -06)

Seems like a good experiment. I wondered if there are any MIB
modules for PIM and, if so, if the stats here are commensurate
with what the MIB calls for measuring.

[Russ Housley]

Comment (2012-06-20 for -06)

  The Gen-ART Review by Pete McCann on 19-Jun-2012 raised two questions
  that deserve a response.

   (1) The Transit and Stub oif-List counts are only 2 octets.  Will
       these fields be large enough to contain the totals for a large
       multicast distribution tree?

   (2) Are there any alignment constraints on the options?  It looks
       like all the two-octet options come first and the single-octet
       options come last.  However, is this a requirement for any
       future options that may be defined?

[Sean Turner]

Comment (2012-06-19 for -06)

s3: Any reason you decided to list the Flags in reverse order from the figure?