Re: [pim] What's the definition of "quick turnaround"?

In message <200508052124.j75LOF5W015642@dino-lnx.cisco.com> you write:
>    My idea was to get the one comment for draft-ietf-pim-anycast-rp-03.txt
>    by mid-week so I could generate -04 by end of week. But I have not recieve
>d
>    that comment. So much for quick turnaround.
>
>    This draft has gone through last-call twice and the authors thought the -0
>3
>    would be approved by Paris IETF. Since the draft date is April, we wasted
>    time. So based on what Bill said at the working group, "if we address
>    the one comment, we don't have to go through a complete last-call cycle
>    again".
>
>    So, Bill/Alex, if I don't get comments by next Friday, can we proceed with
>    -03 and be done with this?
>
>Discouraged,
>Dino

Dino,
	Here are the comments from Amit.

1.  If spec allows RP's to do register-stop caching then there's no
    reason for other anycast RP peer's to suppress register stop.
    So either spec should make the suppression knob mandatory or
    remove the register-stop caching functionality. Dino has mentioned
    that nobody is implementing register-stop caching.

    [ We found that it is not possible to implement based on the
    information in the current spec. There are many cases that are
    under specified.  We don't care if it is fully specified or
    removed but it can't stay like it is. We have pointed out in
    previous emails some of the ways that it is under specified.
    We came up with some solutions too but in the end, we couldn't
    make it work as long as some peers were suppressing register
    stops. - Tom ]

2.  I've always thought that it would be neat to have a bit in
    Register message to know if the register message is coming from
    Anycast-RP peer or DR. This could simplify the debugging as
    well as catching any mis-configuration errors easily without
    relying on TTL field to expire.

3.  Another thing which i wanted to discuss with you was in current
    form Anycast RP solution is not going to scale very well. Reason
    is that for each active source learned from DR/Direct/MSDP
    anycast RP replicate/generate a single NULL-register message
    to each anycast-RP peer. Why can't we change the NULL-register
    message format so that multiple <s,g>'s can be packed in a
    single message?

    Before Anycast RP came, this scaling issue wasn't there as DR
    sends these NULL-register messages and for each DR there may
    not be too many sources. But with Anycast-RP if you are advertising
    MSDP learned external sources as well as internal source
    information then soon we'll be generating tons and tons of these
    NULL-register messages periodically, which can be easily packed
    in single message.

4.  The spec should mention the scaling issues when MSDP learned
    sources are adverstised using Anycast RP.

Thanks Amit for your analysis and quick summary.

Tom

_______________________________________________
pim mailing list
pim@ietf.org
https://www1.ietf.org/mailman/listinfo/pim