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

From: Mike McBride <[email-masked]>
Date: Tue, 1 Jun 2004 23:47:14 -0700 (PDT)

Today begins a Working Group Last Call for the Anycast-RP using PIM draft.
The Last Call runs 2 weeks from Wednesday, June 2nd, 2004 to Wednesday,
June 16, 2004.

Please review this document and send comments either to the list or
directly to the authors.

The document can be found here:

http://www.ietf.org/internet-drafts/draft-ietf-pim-anycast-rp-01.txt

thanks,
Tom and Mike

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 2 Jun 2004 13:31:56 +0300 (EEST)

> http://www.ietf.org/internet-drafts/draft-ietf-pim-anycast-rp-01.txt

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

In any case, here are a few comments on the draft.  The approach seems
straightforward, even though slightly underspecified, relying on the
implementations just "getting it right".

substantial
-----------

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

...

   o RP2 receives the Register message from RP1, decapsulates it, and
     also sends the packet down the shared-tree to get the packet to
     receiver R2.
                                                                                            
   o RP2 sends a Register-Stop back to the RP1.

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

semi-editorial
--------------

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

...

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.

   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/ ?

5. Possible Configuration Language

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

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.

editorial
---------

                         Anycast-RP using PIM
  
==> I guess this should be like:

Anycast Rendezvous Point (RP) using Protocol Independent Multicast (PIM)

...

Abstract

   This proposal allows Anycast-RP to be used inside a domain, which
   runs PIM only. There are no other multicast protocols required to
   support Anycast-RP, such as MSDP, which has been used traditionally
   to solve this problem.

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

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

   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' ??

   o Each router acting as an RP MUST be configured with a loopback
     interface using the same (shared) IP address. This address is used to
     tell other routers in the PIM domain, what IP address to use for the
     RP address.

==> s/MUST/must/ (isn't this an operational requirement?)
==> s/, what/ what/ (or "which")
 
   o RP1 is configured with RP2 and RP3's IP address. It will forward the
     Register message from S1's DR to both of them. RP1 will include
     it's own IP address as the source address for the PIM Register
     message.

==> s/include/use/ (or 'replace'), s/it's/its/ (same elsewhere)

   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"

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

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