Subject: [pim] Comments on Section 4.8 of draft-ietf-pim-sm-v2-new-09.txt

From: James Lingard <[email-masked]>
Date: Fri, 16 Apr 2004 17:42:54 +0100

Hi,

I have the following comments on section 4.8 (PIM Bootstrap and RP
Discovery) of the latest PIM-SM draft.  These are mainly questions about
ambiguous statements within the draft, with some suggested clarifications.

Please feel free to ask me for clarification if any of these points are
unclear.

Thanks,
James.

==========================================================================
*   Throughout section 4.8

The phrase "group-to-RP mapping" is used with two separate meanings:

- As a description of the process of mapping from a group to an RP
  address (e.g. in the title of section 4.8.1).

- As the data structure that contains a group range and a candididate RP
  (e.g. in the phrase "A PIM router must support the static
  configuration of group-to-RP mappings."  (This is also referred to as
  a "group-range-to-RP mapping" in other places within the section).

This is slightly confusing.  I suggest changing all uses with the latter
meaning to "group-range-to-RP mapping".

==========================================================================
*   Section 4.8.1

>>    Using one of the mechanisms described above [...]

This wording seems to imply that

- a single mechanism must be used
- this mechanism must be one of the three described above.

Is this intended?  How about replacing this with something along the
lines of "Using one or a combination of the mechanisms described above,
or some alternative mechanism not described here"

==========================================================================
*   Section 4.8.1

If there is a combination of mappings configured statically and learned
via BSR, should the algorithm be applied to all mappings learned from
either mechanism, or should one mechanism be preferred over the other?

Note that this relates to a discussion about statically configured RPs
currently taking place on the pim-mib mailing list.

==========================================================================
*   Section 4.8.1

>>    Each mapping may also have an associated priority.
                   ^^^
How does the algorithm work if a group-to-RP-mapping *doesn't* have an
associated priority?  Should this read: "Each mapping also has an
associated priority."?

==========================================================================
*   Section 4.8.2

>>    The protocol requires that all routers hash to the same RP within a
>>    domain (except for transients).

This should say something like:  "The protocol requires that all routers
hash to the same RP within a domain or admin scope zone (except for
transients)."

==========================================================================
*   Section 4.8.2

>>  Value(G,M,C(i))=
>>   (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31

In the middle clause "(1103515245 * (G&M)+12345)", which operator is
supposed to take precedence, the '*' or the '+'?  Standard precedence
rules would say the '*', but the spacing suggests that the intention is
for the '+'.  Either way, should add brackets to avoid ambiguity.

==========================================================================
*   Section 4.8.2

Is the hash-mask REQUIRED to be a contiguous sequence of most-significant
1 bits?  If not, the description of the purpose of the hash-mask (namely 
"The hash-mask allows a small number of consecutive groups to always hash
to the same RP.") is not strictly accurate.

==========================================================================
*   Section 4.8.2

Why is the "digest" mechanism for an IPv6 RP address's C(i) value in the
hash algorithm "recommended" not mandated?  Since a common digest
algorithm is necessary for interoperability, I would have thought a
single algorithm should be mandated unless there's a very good reason not
to do so.

--
James Lingard
Data Connection Ltd (DCL)
http://www.dataconnection.com/

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