Subject: Re: [pim] WG Last Call - draft-ietf-pim-anycast-rp-01

From: Dino Farinacci <[email-masked]>
Date: Tue, 8 Jun 2004 19:08:44 -0700

Pekka, et al, my responses inline. I have updated the draft and will 
    release a copy after the last call date (June 16th) so I can aggregate
    changes into the -02 draft.

>> And the aimed category is...?  Proposed Standard?

    I believe PS, but the coauthors should give final say.

>> ==> this doc is missing a security considerations section.  It must be
>> added.

    We added one.

>> ==> This seems to change the model slightly: register-stops are also
>> sent back to the anycast-RPs (not just DRs), which have to be capable
>> of processing them (of course, they are indistinguishable to the RPs).  
>> This spec doesn't mention RP1's processing of a received register-stop
>> at all, or what kind of state RP1 needs to maintain for the register
>> messages it forwards to the other RPs.  This should probably be added.

    I have added text to indicate a Anycast-PIM RP should process Register-
    Stop messages like it would acting as a DR.

>> ==> the draft uses RFC2119 keywords but doesn't define or refer to them. 
>> Add the regular paragraph at the end of section 1 ?
>> 
>> ==> there are a couple of lines longer than 72 chars/line, which is
>> forbidden.
>> 
>> ==> it also seems to be good practice to insert a dummy IANA considerations
>> section, like:
>> 
>> ===
>> IANA Considerations
>> 
>>   This document makes no request to IANA.
>> 
>>   Note to RFC Editor: this section may be removed on publication as an RFC.
>> ===

    Fixed all the above.

>> Status of this Memo
>> 
>>    This document is an Internet-Draft and is in full conformance with
>>    all provisions of Section 10 of RFC2026.
>> 
>> ==> this should be updated to the RFC3668, and you should also add the IPR
>> etc. boilerplates at the end of the draft.

    Fixed.

>>    o The DR directly attached to S1 will form a PIM Register message to
>>      send to RP1. The IP address to use is the Anycast-RP address.
>> 
>> ==> so shouldn't you just say s/RP1/RPA/ ?

    We want to be explicit where the register is going from the DR's 
    perspective.

>> 5. Possible Configuration Language
>> 
>> ==> move this to an Appendix, too vendor-specific, but still useful.

    Done.

>> 9. References
>> 
>>    [1] Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM-
>>        SM): Protocol Specification", RFC 2362, June 1998.
>> 
>>    [2] Kim, Meyer, Kilmer, Farinacci, "Anycast RP mechanism using PIM
>>        and MSDP", Internet Draft draft-ietf-mboned-anycast-rp-08.txt,
>>        May 2001.
>> 
>> ==> split to Normative ([1]?) and Informative ([2]?) References.  Update [2]
>> to be RFC3446.  Note that [2] cannot be normative if this is going for 
>> PS.

    I made them all Informative.  ;-)

>>                          Anycast-RP using PIM
>>   
>> ==> I guess this should be like:
>> 
>> Anycast Rendezvous Point (RP) using Protocol Independent Multicast (PIM)

    I made this more clear in the Abstract rather than in the title.

>> ==> s/proposal/specification/
>> ==> similar also later (e.g., s/draft/memo/) -- to make sure this continues to
>> be valid after RFC publication, implementation etc.) 

    Done. But did s/draft/specification/.

>> ==> also spell out RP, PIM and MSDP here.

    Did this up front in the Abstract.

>>    Anycast-RP as described in [2] is a mechanism ISP-based backbones
>>    have used to get fast convergence when a PIM Rendezvous Point (RP)
>>    router fails.
>> 
>> ==> 'ISP-based backbones' ??

    Yes, because originally Anycast-RP with MSDP was deployed in the backbones
    of ISPs (and not other backbones like corporate or university).

>> ==> s/MUST/must/ (isn't this an operational requirement?)
>> ==> s/, what/ what/ (or "which")

    I kept MUST because it is a strong requirement 

>>    o The source gets Registered to a single RP by the DR, it's the
>>      responsibility of the RP, the DR selects, to get the packet to all
>>      other RPs in the Anycast-RP set.
>> 
>> ==> the DR doesn't really "select" the RP, it's chosen by the routing
>> metrics.  Just remove ", the DR selects, " or reword to something like "the
>> RP closest to the DR"

    The RP is selected for the DR, yes, by the routing metrics. But the
    text is trying to say the original Register that goes to the RP (from the
    DR), must be forwarded to all other RPs. I clarified this by qualifying
    the metrics help the selection process.

>>    message as described in [2]. That means an SA for the same internal
>>  
>> ==> spell out SA, someone could mistake it for a Security Association ;-)

    I didn't make this change. There is enough context in this section for
    the reader to know we are not discussing security.

Thanks for your comments,
Dino/Yiqun

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