On Thu, 3 Nov 2005, The IESG wrote:
> The IESG has received a request from the Protocol Independent Multicast WG to
> consider the following document:
>
> - 'Anycast-RP using PIM'
>   <draft-ietf-pim-anycast-rp-04.txt> as a Proposed Standard
...
> The implementation report can be obtained via
> http://www.ietf.org/IESG/Implementations/pim-anycast-rp-implementation-report.txt

When the topic got mentioned on the mailing list, and I got some airtime
(a longer flight), I decided to re-read the spec.  In general, the style is
a bit ... unconventional for a protocol specification, but it should be easy
enough for creating interoperable implementations, so it's OK.

What might possibly be worth spelling out in a separate section is what kind
of failures may happen if the Anycast-RP set is not consistent, but the
document may be able to live up as it is as well.

What I'd have liked to see in the implementation report is whether the 
implementations implement the TTL copying that's a SHOULD (and I say 
it should be a MUST) -- this is pretty important for loop avoidance 
when the anycast RP sets are misconfigured.

The first three issues are ones which are either procedural problems 
or sufficiently severe protocol problems that they (IMHO) will need to 
be addressed prior to the IESG review.

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

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in [RFC2119].

==> this ref is missing and should be added under normative refs (this is
a sufficient reason for the IESG to block the document).

    o An RP will send a copy of a Register only if the Register is
      received from an IP address not in the Anycast-RP list (i.e. the
      Register came from a DR and not another RP). An implementation
      SHOULD safeguard against inconsistently configured anycast-RP sets
      in each RP by copying the TTL from a Register message to the
      Register messages it copies and sends to other RPs.

==> it appears to me that this SHOULD should be a MUST.  Otherwise 
even with three RPs in the anycast RP set, you can get an infinite 
loop of packets (RP1 configures RPA to be just RP2; RP2 configures RPA 
to be just RP3; RP3 configures RPA to be just RP1) -- the result seems 
to be packets getting tossed back and forth until the routers go up in 
smoke.

7.0 Security Consideration

    This section describes the security consideration for Register and
    Register-Stop messages between Anycast-RPs.  For PIM messages between
    DR and RP, please see [I3].

==> I3 is reference to RFC2401.  It does not describe the security 
considerations between DR and RP -- did you actually mean to refer to 
something else, like the new PIM spec itself?

Similar but slightly more detailed text is in section 7.2.  The 
security area does not feel this is a sufficient description of how 
IPsec really works, and this will most likely result in a Discuss. See 
draft-bellovin-useipsec-04.txt for what needs to be specified if IPsec 
is to be used.  The new PIM spec may include the sufficient details (I 
didn't check); it may be sufficient to appropriately refer that here.

It might also be useful to be clearer which RP-to-RP vulnerabilities are
introduced or exacerbated by this specification (and how), and which
ones are really just carried over from DR-to-RP attacks but are not
any worse.

You may also want to consider adding an informative reference to 
draft-ietf-mboned-mroutesec-04.txt for further explanation of DR-to-RP 
attacks.

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

    o RP1 MAY join back to the source-tree by triggering a (S1,G) Join
      message toward S1. However, RP1 MUST create (S1,G) state.

==> for those less literate in PIM, adding a bit of detail to the last
sentence might help.  It's clear how a Join creates (S,G) state, but how
exactly (where does it point to?) do you create (S,G) without a Join?
[the same later in the spec as well]

    o RP2 sends a Register-Stop back to the RP1. RP2 MAY wait to send
      the Register-Stop if it decides to join the source-tree. RP2
      should wait until it has received data from the source on the
      source-tree before sending the Register-Stop. If RP2 decides to
      wait, the Register-Stop will be sent when the next Register is
      received. If RP2 decides not to wait, the Register-Stop is sent
      now.

==> the order of sentences does not seem logical, there seems to be a "MAY"
vs "should" conflict, and there is a bit of overlap; how about something
like:

    o RP2 sends a Register-Stop back to the RP1. RP2
      should wait until it has received data from the source on the
      source-tree before sending the Register-Stop; if so,
      the Register-Stop will be sent when the next Register is
      received. If RP2 decides not to wait, the Register-Stop is sent
      now.

purely editorial
----------------

    This specification allows Anycast-RP (Rendezvous Point) to be used
    inside a domain that runs Protocol Independent Multicast (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.

==> the abstract uses a bit of backward manner to say this, maybe instead:

    To increase reliability, networks using Protocol Independent
    Multicast - Sparse Mode (PIM-SM) have deployed Anycast-RPs
    (Rendezvous Points).  Traditionally, Anycast-RP has been achieved
    using Multicast Source Discovery Protocol (MSDP).  This memo specifies
    extensions to PIM-SM to support Anycast-RP without MSDP.

2.0 Requirements

==> maybe call it "Operational Requirements" ?

    Assume the above scenario is completely connected where R1, R1', and
    R2 are receivers for a group, and S1 and S3 send to that group.
    Assume RP1, RP2 and RP3 are all assigned the same IP address which is
    used as the Anycast-RP address (let's say the IP address is RPA).

    Note, the address used for the RP address in the domain (the
    Anycast-RP address) needs to be different than the addresses used by
    the Ancyast-RP routers to communicate with each other.

==> s/Ancy/Anyc/
==> duplication of assumptions with operatonal requirements, maybe just
simply say (removing the second paragraph):

    Assume the above scenario is completely connected where R1, R1', and
    R2 are receivers for a group, and S1 and S3 send to that group.
    RP1, RP2 and RP3 are all assigned the same IP address which is
    used as the Anycast-RP address RPA as described in Section 2.0.

...


      has occurred and it should be rate-limited logged.

==> "rate-limited logged" does not parse; you mean "logged in a rate-limited
manner", but is there a better way to say this?

The actual protection
    mechansim is implementation specific.

==> s/mechansim/mechanism/

    The authors would like to thank Thomas Morin from France Telecom for
    having an extensive discussion on Multicast the Registers to an SSM-
    based full mesh among the anycast-RP set.

==> "on Multicast the Registers" does not parse.  Did you mean
"multicasting" ?

  [I2] Estrin, et al., "Protocol Independent Multicast-Sparse Mode
         (PIM-SM): Protocol Specification", RFC 2362, June 1998.

==> this is not referred to in the spec, so will need to be removed.


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

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