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

From: Stig Venaas <[email-masked]>
Date: Mon, 10 Feb 2014 13:16:21 -0800

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
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: 神明達哉 <[email-masked]>
Date: Tue, 11 Feb 2014 11:55:29 -0800

At Mon, 10 Feb 2014 13:16:21 -0800,

> >>    introduction), since RFC 3956 clearly states (and also as cited in
[...]
> significant flag bit is set.

I guess I was not clear/accurate enough.  My point is that (at least
technically) Section 3.1 is not just a "clarification" as this draft
claims in Section 1:

   [...]  The document provides also some clarifications related
   to the use of these flag bits (Section 3.1).

since as a result of this the definition of embedded-RP addresses is
changed (extended).  Maybe revising the last sentence of Section 1
addresses my concern:

   This document updates [RFC3956], [RFC3306], and [RFC4291].  Some of
   the updates are logical consequences of the clarification on the
   flag bits.

> statement, but not really needed.

I think that works for me, although it looks a bit awkward that we can
simply remove a statement containing a "MUST" while believing it's not
a semantics change.

> use lower case in all the NEW text.

Ah, okay.  Maybe it's a distraction, but I'd consider adding a
"TERMINOLOGY" section or something, where we clarify the point (i.e.,
the draft generally follows RFC 5952 to represent IPv6 addresses
except in citation of already published documents).  But I'd leave it
to you.

--
JINMEI, Tatuya