Re: comments on draft-ietf-6man-multicast-addr-arch-update-02
Stig Venaas <stig@venaas.com> Mon, 10 February 2014 21:16 UTC
Return-Path: <stig@venaas.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33A81A05D6 for <ipv6@ietfa.amsl.com>; Mon, 10 Feb 2014 13:16:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.6
X-Spam-Level:
X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tW-da5B7I0Dl for <ipv6@ietfa.amsl.com>; Mon, 10 Feb 2014 13:16:27 -0800 (PST)
Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 92BD81A0564 for <ipv6@ietf.org>; Mon, 10 Feb 2014 13:16:26 -0800 (PST)
Received: from [IPv6:2001:420:301:1004:9c1c:c7c0:5307:24f8] (unknown [IPv6:2001:420:301:1004:9c1c:c7c0:5307:24f8]) by ufisa.uninett.no (Postfix) with ESMTPSA id 8924F8025; Mon, 10 Feb 2014 22:16:24 +0100 (CET)
Message-ID: <52F941A5.6040103@venaas.com>
Date: Mon, 10 Feb 2014 13:16:21 -0800
From: Stig Venaas <stig@venaas.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: 神明達哉 <jinmei@wide.ad.jp>, draft-ietf-6man-multicast-addr-arch-update@tools.ietf.org
Subject: Re: comments on draft-ietf-6man-multicast-addr-arch-update-02
References: <CAJE_bqdUiQznZDUDsQ3d1niuRE=q1YqYp9=mNMm8Bo8QzB6xiQ@mail.gmail.com> <52E0570D.4040403@venaas.com>
In-Reply-To: <52E0570D.4040403@venaas.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: IPv6 IPv6 List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Feb 2014 21:16:29 -0000
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 >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------