Subject: [pim] WG Query: draft-farinacci-pim-pop-count-00.txt

From: Tom Pusateri <[email-masked]>
Date: Mon, 18 Oct 2004 11:32:45 -0700

Dino had asked at the last IETF meeting if we would accept
the following draft, draft-farinacci-pim-pop-count-00.txt as a PIM
working group document.

I never sent out the question to the mailing list and Mike reminded
me today.

Please read the draft if you haven't and send your thoughts to
the list by next Monday, Oct. 25th at 5:00 pm PST.

Justification for your opinion is preferred.

Thanks,
Tom

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

---

From: Pavlin Radoslavov <[email-masked]>
Date: Mon, 18 Oct 2004 12:42:57 -0700

> Justification for your opinion is preferred.

Few months ago I sent an email to the list with some comments about
the I-D, but so far I haven't seen any replies. Shall I resend them?

Pavlin

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 18 Oct 2004 13:50:59 -0700

>> the I-D, but so far I haven't seen any replies. Shall I resend them?

    I probably missed them since I was in corporate transition. Can you please
    resend them. Thanks. I had no idea.

Dino

---

From: Pavlin Radoslavov <[email-masked]>
Date: Mon, 18 Oct 2004 14:00:17 -0700

>     resend them. Thanks. I had no idea.

Original comments from July 26 2004 included below.

Thanks,
Pavlin

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

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 21 Oct 2004 12:20:44 -0400

Hello;

I would basically agree with Pavlin - should this really be a PIM-SM
overlay, or a separate
protocol describing accounting messages and use ?

And, of course, if its decided NOT to overlay the PIM join message,
shouldn't  this
be done by a separate WG, such as MAGMA ? So I would support moving this
forward, but maybe not in PIM.

A suggestion

- I did not see a mechanism to provide feedback if certain trees
downstream do NOT support the protocol.
There should be a flag propagated upstream, I think, to indicate that
"this tree has partial
information because routers below me do not support accounting."
This would be very useful I think in real world partial deployment
scenarios (and
in debugging deployments), and is only a bit.

Also, (a pet peeve) " it's Join/Prune messages" and "it's accounting"
should be "its".

Regards
Marshall Eubanks

---

From: Tony Speakman <[email-masked]>
Date: Mon, 25 Oct 2004 09:37:36 -0700

> forward, but maybe not in PIM.

RMT did some related work which was a lot of fun, but
is currently inactive:

http://www.ietf.org/proceedings/01aug/I-D/draft-ietf-rmt-gra-arch-02.txt
http://www.ietf.org/proceedings/01aug/I-D/draft-ietf-rmt-gra-fspec-00.txt
http://www.ietf.org/proceedings/03jul/I-D/draft-ietf-rmt-bb-gra-signalling-01.txt

Tony S

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Oct 2004 19:27:35 +0300 (EEST)

Hi,

> the list by next Monday, Oct. 25th at 5:00 pm PST.

This is coming late, but if it matters..

I'm uncomfortable with the approach.  We need to make multicast 
routing less, not more complex.  This seems to be putting a external, 
though useful, function in the protocol where it shouldn't be.

Hence, I'd rather see that we tried to address the problems in a more 
'conventional' manner.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings