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

[Stig Venaas <[e-mail]>]

Hi, sorry for delay, but let me comment on this now.

On 1/22/2014 3:41 PM, Stig Venaas wrote:
> 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.

As part of this update we are trying to treat the flag bits as
individual bits. Hence it should still be embedded-RP if the most
significant flag bit is set.

>> - 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.

We can remove the sentence ", but all multicast addresses with the
R-bit set to 1 MUST be treated as Embedded RP addresses." It is a valid
statement, but not really needed.

>>    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.

Agree. So maybe should call them flag field 1 and flag field 2 and write
ff1 and ff2 in the diagram.

>> - 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.

Yes. I think we should change it to 4291.

>> - (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.

A lot of the OLD text has FF, but per recommendation in RFC 5952 we
use lower case in all the NEW text.

>> - 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.

OK, will try to improve this one.

Thanks for the review,

Stig

>> --
>> JINMEI, Tatuya
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------