Re: comments on draft-ietf-6man-multicast-addr-arch-update-02

[Stig Venaas <[e-mail]>]

Hi

Thanks for the review.

I'm sorry I didn't find time to respond to this. Let's see what other
comments we get in the WGLC that is ongoing. I'll then try to address
this and any other comments afterwards.

Stig

On 11/13/2013 1:35 PM, 神明達哉 wrote:
> As promised in the Vancouver meeting, I reviewed the draft.  Overall,
> it looks good to me.  I have a few minor comments:
>
> - Allowing FFF0::/12 to be considered an embedded RP address seems to
>    me a semantics change, not just a clarification (as hinted in the
>    introduction), since RFC 3956 clearly states (and also as cited in
>    the draft itself):
>
>     the encoding and the
>     protocol mode used when the two high-order bits in "flgs" are set to
>     11 ("FFF0::/12") is intentionally unspecified until such time that
>     the highest-order bit is defined.
>
>    So does this mean "such time" has come?  I guess there was a
>    background discussion that I didn't follow and led to this change,
>    so I wouldn't oppose to the update per se.  But the rationale isn't
>    really clear from the updated text, and I think it should be
>    clarified.
>
> - Aside from the previous point, the updated text is generally quite
>    confusing to me:
>
>        R = 1 indicates a multicast address that embeds the address of the RP.
>        P MUST be set to 1, and consequently T MUST be set to 1, according
>        to [RFC3306], as this is a special case of
>        unicast-prefix based addresses. This implies that for instance prefixes
>        ff70::/12 and fff0::/12 are embedded RP prefixes, but all multicast
>        addresses with the R-bit set to 1 MUST be treated as Embedded RP
>        addresses. The behavior is unspecified if P or T is not set to 1. When the
>        R-bit is set, the last 4 bits of the previously reserved field are
>        interpreted as embedding the RP interface ID, as specified in this memo.
>
>    As explained in the first sentence, for any embedded-RP addresses
>    both P and T must be 1.  As a logical consequence, an address with P
>    or T being 0 cannot be an embedded-RP addresses, right?  Yet the
>    text states "all multicast addresses with the R-bit set to 1 MUST be
>    treated as Embedded RP addresses".  Maybe the "behavior is
>    unspecified if P or T is not set to 1" part in the subsequent
>    sentence tries to address the point, but it's still confusing to me
>    - specifically what does "MUST be treated as Embedded RP addresses"
>    mean, then?  I think some more clarification is necessary here.
>
> - In Section 4.1, I suspect the "NEW" format needs the new "flgs"
>    bits:
>
>     NEW:
>
>           |   8    |  4 |  4 |   8    |    8   |       64       |    32    |
>           +--------+----+----+--------+--------+----------------+----------+
>           |11111111|flgs|scop|reserved|  plen  | network prefix | group ID |
>           +--------+----+----+--------+--------+----------------+----------+
>                               ^^^^ <= should be "flgs"
>
>    And, with this change, the following part will become ambiguous:
>
>                                        +-+-+-+-+
>        flgs is a set of 4 flags:       |X|Y|P|T|
>                                        +-+-+-+-+
>
>    Since there are now 2 "flgs" fields.  The same comment applies to
>    the NEW formats shown in Section 4.2.
>
> - Also in the NEW format of Section 4.1, I'm not sure if [ADDRARCH] is
>    an appropriate reference, e.g., in:
>
>              o  P = 0 indicates a multicast address that is not assigned
>                 based on the network prefix.  This indicates a multicast
>                 address as defined in [ADDRARCH].
>
>    Since there's no such reference in this document.  For the OLD text
>    it's probably okay as it should be a verbatim copy of the original
>    text, but I'm not sure if it should apply to the new text.
>
> - (A very minor point) Also in the NEW format of Section 4.1, why
>    lower-cased letters are now used for the addresses?
>
>        If the flag bits are set to 0011, these settings create an SSM
>        range of ff3x::/32 (where 'x' is any valid scope value).  The
>
>    The policy isn't consistent either with the original RFC 3306 or
>    with other parts of the draft.
>
> - In the NEW format of Section 4.2, this sentence may need to be
>    revisited:
>
>        In this case, the last 4
>        bits of the previously reserved field are interpreted as embedding
>        the RP interface ID, as specified in this memo.
>
>    in that what "the previously reserved field" means is not really
>    clear as this document now also is revising RFC 3306.  To be very
>    clear, for example, I'd rephrase it as:
>
>        In this case, the last 4
>        bits of the field that were reserved in [RFC3306] are
>        interpreted as embedding the RP interface ID, as specified in
>        this memo.
>
> --
> JINMEI, Tatuya
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>