Subject: Re: [pim] I-D ACTION:draft-farinacci-pim-pop-count-00.txt

From: Pavlin Radoslavov <[email-masked]>
Date: Mon, 26 Jul 2004 14:48:25 -0700

[Note: a reply to a very old email]

>     Folks, please comment.
> Dino

At the very high level I think it is a very good idea of having a
mechanism for multicast tree accounting, etc.

Implementation/design-wise I have few comments:

 * Have you looked into related work such as the following paper:
   "Tracetree: A Scalable Mechanism to Discover Multicast Tree
   Topologies in the Internet" by Kamil Sarac and Kevin Almeroth:
   http://www.nmsl.cs.ucsb.edu/publications.html
   It has a number of interesting ideas including a mechanism to
   deal with incremental deployment, it is not protocol-specific,
   etc.

 * We need to deal with incremental deployment, otherwise there is
   no initiative to even start deploying this new scheme. E.g.,
   ideas from the above paper can be helpful in this aspect.

 * In your proposal you overload the Join messages with accounting
   information.
   The advantage of doing that is that you save some network
   bandwidth and processing cycles, but the result solution becomes
   a bit too complicated and lacks flexibility. For example, if
   someone wants to define a new counter, adding such counter to the
   fixed  message format is impossible without redefining the whole
   format again.
   I would rather see those two functionalities separated:
   the tree management (i.e., the Join/Prune messages), and the
   tree accounting. By that I mean using a new type control message
   (for accounting purpose only) which is designed to have
   extensible format, etc. Then, each counter for example, can be
   added as an option to the message.

 * Currently, it appears that the mechanism is PIM-SM
   specific. Rather than redefining the mechanism for PIM-DM, etc,
   I'd prefer to have a protocol-independent mechanism.
   After all, it appears that the only major thing that currently
   ties the mechanism to PIM-SM is the message format overloading of
   the PIM-SM Join messages.

 * Some of the fields are probably not large enough. E.g.,
   max. value of 255 for "Node Count" is one that comes to mind.
   Another example is the link speed where everything below 1Mbps
   becomes 0. If we are to consider the last-mile multicast, then we
   need better granularity.

Thanks,
Pavlin

> 
> -------------------------------------------------------------------------------
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: Population Count Extensions to PIM
> 	Author(s)	: D. Farinacci, G. Shepherd
> 	Filename	: draft-farinacci-pim-pop-count-00.txt
> 	Pages		: 8
> 	Date		: 2004-5-18
> 	
> Performing an approximation in some form of multicast distribution
>    tree accounting proves to be useful for billing and debugging. The
>    Population Count extensions to PIM, documented in this draft,
>    provide an efficient method to achieve this.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-farinacci-pim-pop-count-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of the message.  
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with th
> -------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pim

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