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

[Dino Farinacci <[e-mail]>]

    This response will address the comments from each of Pavlin, Marshall,
    and Pekka, respectively. See my responses inline.

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

    Thanks Pavlin.

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

    No, we did not see this. But both Shep and I will have a look at it.
    Ditto for the GRA stuff too. Thanks Tony for the reference.
   
Pavlin>> 
Pavlin>>  * We need to deal with incremental deployment, otherwise there is
Pavlin>>    no initiative to even start deploying this new scheme. E.g.,
Pavlin>>    ideas from the above paper can be helpful in this aspect.

    People can deploy this when they get new software releases. And since
    the accounting can be obtained per sub-tree, within a domain, you can
    acquire some information about your relative fanout. So we never believe
    it's an all or nothing situation.

Pavlin>>  * In your proposal you overload the Join messages with accounting
Pavlin>>    information.

    We augmented the Encoded Source Address. And yes, since the Joins are
    already going upstream, we piggyback to reduce CPU overhead and an
    addition of new protocols.

Pavlin>>    The advantage of doing that is that you save some network
Pavlin>>    bandwidth and processing cycles, but the result solution becomes
Pavlin>>    a bit too complicated and lacks flexibility. For example, if

    It is not complicated, you simply fill in the fields per route you insert
    in the Join (fields that are stored in the multicast route).

    In terms of a inflexible encoding, that was done on purpose. If we 
    generalized it, then implementations could drastic increase Join sizes
    which would affect tree building. We want it lean and mean. Remember this
    mechanism is not precise in obtaining accounting data. It gives a rough
    feel of "tree attributes". A more comprehensive/precise could be put on
    top of this in the management plane.

Pavlin>>    someone wants to define a new counter, adding such counter to the
Pavlin>>    fixed  message format is impossible without redefining the whole
Pavlin>>    format again.
Pavlin>>    I would rather see those two functionalities separated:
Pavlin>>    the tree management (i.e., the Join/Prune messages), and the
Pavlin>>    tree accounting. By that I mean using a new type control message
Pavlin>>    (for accounting purpose only) which is designed to have
Pavlin>>    extensible format, etc. Then, each counter for example, can be
Pavlin>>    added as an option to the message.

    We did consider another message type but would require using a set of
    resources which are already used for sending periodic JP messages. That
    will certainly use more CPU for traversing the routing table another time
    more messages, more receive processing, etc. 

    I've done some meaurements for 100K routes being periodically joined on
    10 interfaces with 10 neighbors on each (i.e. 100 RPF neighbors 
    distributed eveningly across 100K routes). With either a preemptive or run-
    to-completion scheduling model for your PIM process, it can take up to 10
    seconds to get all the data out. This is assuming a set of routes which
    are all ASM based ((*,G,join-list & prune-list) entries as well as (S,G,
    join-list) entries).

    So we felt the piggybacking would give a better performance/benefit ratio.

Pavlin>> 
Pavlin>>  * Currently, it appears that the mechanism is PIM-SM
Pavlin>>    specific. Rather than redefining the mechanism for PIM-DM, etc,

    I tried to be practical and concluded there is so much more deployment 
    of SM then as DM. But if you needed to send Joins in DM mode for sake of 
    accounting, than, in essence, is your seperate protocol.

    I did this for Multicast Tagswitching a long time ago. That is, for DM
    groups, Joins could be sent for purposes of label binding.

Pavlin>>    I'd prefer to have a protocol-independent mechanism.
Pavlin>>    After all, it appears that the only major thing that currently
Pavlin>>    ties the mechanism to PIM-SM is the message format overloading of
Pavlin>>    the PIM-SM Join messages.

    It's a performance/benefit tradeoff. We chose to have this highly
    performing.

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

    I didn't think we needed that much granularity for link-speed. For node
    count we can increase the size. That was the reason for review, to get
    opinions from people about the types of accounting data they would see
    useful.

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

    Same comment as above.

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

    I think it all depends where the solution goes. We decided PIM was the
    right place to put the functionality so hence bringing it to the PIM
    working group was the obvious choice.

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

    I think this is a good idea. I can add this in the next rev of the draft.
    Thanks Marshall.

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

    Will fix. Thanks.  ;-)

Pekka>> This is coming late, but if it matters..

    It sure does to me (and Shep). Thanks Pekka.

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

    The proposal does not change the elements of operation for the protocol.
    There is a strong attempt to make this inline with the protocol so it is
    easy to deploy without having to plan deployment for a new mechanism as
    well as not affecting the performance of the control plane of the system.

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

    If "a more conventional manner" is SNMP, we'd like to see it perform a bit
    better. Don't you think it's more scalable to poll a single router to find 
    information for a tree at that point in the topology? Versus, having to
    find all branches and poll each one, compile the data, and then display it.

    For the NOC guys who want a quick and easy way to find some tree 
    accounting, all they would have to do is ssh to one of their routers and
    do a show command.

    Of course, once the proposal is more widely accepted, we could MIB the
    new accounting data so you can get SNMP access to the *single* router.

    All, thanks for your comments.

Dino   





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