Subject: [pim] WG last call for draft-ietf-pim-bidir-06 - comments

From: Jonathan Hardwick <[email-masked]>
Date: Thu, 13 May 2004 13:16:41 +0100

Hi,

Here are my comments on draft-ietf-pim-bidir-06.  Apologies for slightly
missing the deadline for this.  I have divided my comments into
"technical" and "editorial" for the convenience of the reader.

Please let me know if anything I say needs clarification.

Thanks,
Jon

Technical comments
==================

Section 2.1, definition of RPA.
-------------------------------

1st sentence.  This gives the impression that the RPA is always
configured, but it may instead be dynamically learned e.g. using BSR.
I suggest rewording to say "An RPA is an address that is to be used...".

Section 3.1.4
-------------

Replace:

"The set "joins(G)" is the set of all interfaces on which the router has
 received (*,G) Joins".

With:

"The set "joins(G)" is the set of all interfaces on which the router has
been elected the DF for RPA(G) and has received (*,G) Joins".

Section 3.3.2
-------------

Last sentence: "doing so requires data driven events".  It's not clear
(to me at least) why storing per-group state requires data-driven events
in the control plane, but storing per-RPA state does not.  Please could
you add some more explanatory text here?

Section 3.4.1
-------------

(1) First sentence: s/must/MUST/

(2) "If the RP address in the message does not match RPA(G) the Join or
     Prune MUST be silently dropped."

    This is inconsistent with the PIM-SM draft, where if a Join (*,G) is
    received and an RP is not known for G, then the PIM-SM router MAY
    learn the G->RP mapping from the Join.  Why not allow this for
    BIDIR-PIM too?  Alternatively, please explain the reason for the
    inconsistency.

(3) Second paragraph under the table: "However on point-to-point links
    we also recommend...".  Recast this sentence as a SHOULD or
    RECOMMENDED.

    In general, I suggest doing an audit of the document to check for
    missing RFC 2119-style text.

(4) I think this FSM assumes that it is not possible to have a Join(*,G)
    or Prune(*,G) event if you are not the DF for RPA(G).

    I conclude this from the facts that (i) the FSM tranitions to NI state
    when the router stops being DF for RPA(G) on I, and (ii) there is
    nothing that keeps the FSM in NI state if a Join(*,G) is subsequently
    received.  Is my interpretation correct?

    If so, I suggest (i) modifying the text to state that the inputs are
    filtered if the router is not DF for RPA(G) on I, and (ii) rewording
    the description of the Join state to remove the implication that the
    router can be in Join state without being the DF.

    If not, please add some text to explain why the FSM transitions to
    NI state when the router stops being DF, but does not necessarily
    stay there.

Section 3.4.2
-------------

In state machine table for Joined state, the event labelled "Change of
RPF_DF(RPA(G))" ought to be "Change of RPF_interface(RPA(G))" - I think.

If I'm wrong, then please add some explanatory text to differentiate the
events labelled "RPF_DF(RPA(G)) changes" and "Change of RPF_DF(RPA(G))".

Section 3.5.2.3
---------------

Final paragraph (sending a single Winner message if the current Winner's
metric improves) is not mentioned in section 3.5.3.  This behaviour
should be incorporated into the DF election state machine as a new event
in Win state, labelled "Metric changes and is now better".

Editorial comments
==================

Section 2.1, definition of RPA.
-------------------------------

Typo in 4th sentence: s/that/which/

Section 3 - document structure
------------------------------

Why not list the sections in numerical order?  If they are numbered in
the wrong order, please renumber them.  (The existing numbering looks fine
to me.)

Section 3.3
-----------

In the pseudocode just before the start of section 3.3.1, "I_am_DF(RPA,
I)" should be "I_am_DF(RPA, iif)".

Section 3.3.1
-------------

s/RPA address/RPA/

Section 3.3.2
-------------

In last sentence, s/tha/the/

Section 3.4.1
-------------

The formatting of the table in the text-only version of the spec needs
to be tidied.

Section 3.5.2.4
---------------

I think you should delete this note, now that we're at last call.
There's no need to document ways in which the spec could work, but
doesn't.

Section 3.5.2.5
---------------

s/if its metric worse/if its metric is worse/

Section 3.5.3.1
---------------

In description of Lose state, s/RP/RPA/

In description of Best-Offer, sentence doesn't scan.  I suggest
rewording as follows:

"Used by the DF to record the identity and advertised metrics of the
router that has made the last offer, for use when sending the Path
message."

Section 3.5.3.2
---------------

Missing comma after "PIM control messages".

Section 3.6
-----------

Missing comma in section header (Timers, Counters and Constants).

In DFT table, value names should be OPlow and OPhigh (with lowercase 'l'
and 'h') for consistency with the rest of the text.

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