Anycast-RP Using Protocol Independent Multicast (PIM)
RFC 4610

[Ballot discuss]
I received the following comment from Pekka Savola from the Ops Directorate:

I reviewed -04 during IETF last call, but I didn't see any response or         
follow-ups.  I checked -05 and it only changes security considerations         
text.  The mail is at:                                                         
                                                                               
http://www1.ietf.org/mail-archive/web/pim/current/msg00651.html               
                                                                               
I think the TTL copying issue (preventing infinite loops due to               
misconfiguration) could be serious.  Sooner or later, those anycast-RP         
sets _are_ going to be misconfigured, and it would be good if the             
failure mode didn't melt the network.

Is there a reason why his Last Call comment was not dealt with ?

[Ballot comment]
Section 3.0 says:
  >
  > RP1 is configured with RP2 and RP3's IP address.
  >
  I suggest the following rewording:
  >
  > RP1 is configured with the IP addresses of RP2 and RP3.

[Ballot comment]
The draft says :

  o An IP address is chosen to use as the RP address. This address is
    statically configured, or distributed using a dynamic protocol, to
    all PIM routers throughout the domain.


Later requirements indicate that this is inserted into the unicast
routing system, so this is a unicast address.  It might be useful to
specify that here. 

It might also be useful to specify whether any events
in the unicast routing system have an impact on this mechanism
either in set-up or in later operation.

[Ballot comment]
Non-blocking comments from Gen-ART review by Joel Halpern:

minor:
    I am not sure calling section 2.0 "Requirements" is a good use of naming.  Section 2 is a really useful section.  It describes what you are trying to do nicely and clearly.  But "requirements" it isn't.  "Overview"would do nicely as a title.

    It seems to require interesting management control to achieve the conditions required to mix non-supporting RPs into this, as described in section 4.0.  I understand that technically, as long as the non-supporting RP has only receivers, it works.  But a little more explication as to when / how this can be ensured might be appropriate.

    Isn't it a bit odd for the authors to thank themselves?  The work they are acknowledging is worth noting (the authors did two prototypes of the draft.)  But different wording might be nice.

[BC: "The authors thank each other..."?]

[Note]: 'A -05 is coming to fix the Security Considerations to point just to pim-sm-v2-new and to fix some minor reference issues.' added by Bill Fenner

  I'm curious about the description of the actions.  In particular,
why do RP1 and RP2, which have receivers attached, send Register-Stop
messages before they've set up the source tree?  For example, it
says that RP1 always sends a Register-Stop, then MAY join back to
the source.  If it doesn't join back to the source, but sends the
Register-Stop anyway, that creates a black hole, right?  I would think
the sending of the Register-Stop would wait for the SPT to be set up,
at least on RPs with a non-empty inherited_olist(S,G).
 
  Also, I think the description of handling Register-Stop at an
RP is a little light; "just like it would if it was a DR" doesn't
seem like enough given that a DR never sends to multiple RPs.
It seems like (in the terms of the new pim spec) each RP maintains
one (S,G) Register State and one Register-Stop Timer per (S,G) and
other RP, and only sends a copy of a Register message to another
RP if the (S,G) Register State machine for the (S,G) of the Register
and the RP being sent to is in Join state.

  To be honest, I'd really rather see a description of what a
router has to do with packets than an example -- e.g., I think an
RP has to decide whether a Register is from a DR or another RP,
to decide whether to forward it to other RPs; to do that the source
address of the packet has to be one that it knows, so the other RP
has to send with the source address that's configured in all the
other RPs.  That could cause reorigination loops which won't even
be stopped by TTL, if RP1 sent to RP2 but RP2 thought it came from
a DR so sent it to RP1 and RP1 thought it came from a DR so sent it
to RP2... so it's fine to have the example, but I think you should
also spell out
- What an RP does when it gets a Register, including how it
  decides whether or not to send it to the other RPs and what
  source address it uses when it reoriginates it;
- What an RP does when it gets a Register-Stop, and what state
  it needs to keep per-RP.

  I have some terminology suggestions that might make the document
more clear.  Instead of saying that the RP that receives the Register
"forward"s it to the other RPs, perhaps could you say "sends a copy of"
the Register message to each other RP?  Forwarding a packet feels
like it should be sending it towards the packet's destination, either
unicast or multicast, but in this case it's really replicating the
packet and reoriginating it - i.e., you're not keeping the old source
or destination addresses.

  In the 2nd bullet of #4, I think it's unclear to say that the DR
sends to its closet RP address -- it sends to the anycast RP address,
right, which then results in the packet getting to the closest RP.
On the same point, in the 4th bullet, I think it'd be more clear to
say "..responsibility of the RP the DR *reaches*", not "selects", since
the DR is not selecting anything.