comments on draft-ietf-6man-multicast-addr-arch-update-02
神明達哉 <jinmei@wide.ad.jp> Wed, 13 November 2013 21:35 UTC
Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC1A11E8136 for <ipv6@ietfa.amsl.com>; Wed, 13 Nov 2013 13:35:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.222
X-Spam-Level:
X-Spam-Status: No, score=0.222 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DThZ1FpvMAfO for <ipv6@ietfa.amsl.com>; Wed, 13 Nov 2013 13:35:02 -0800 (PST)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB4311E8107 for <ipv6@ietf.org>; Wed, 13 Nov 2013 13:35:01 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id hq4so1506970wib.4 for <ipv6@ietf.org>; Wed, 13 Nov 2013 13:35:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=b8kXXJWxXwe7ubbfLCGtrbSVCtertu5JTILkzhr9w74=; b=Dv3Rf+oWkiePJt+8oLGPnoKOeiOFeK9gIgo84r2F8Re92cRVjny8EqesMe+sjN7EvM LNhufZaZbxTB34BXw80olvKxR3xtjTOZYDt9Ey78Bifj7urSISEjXPmAa7pI+ETdcHGG 5T1a6h8o/1oll40v6C7WIqWE8RzGaM4Te4VyDdEQvgugsfoOfhpNfW2d+u6XGgmCcTCl wGiAtPxAJ9/asVwfM67Tlfscw8TCvXSj0xhpaks0353CgF3iJq914b11EgiF0lqHfwFT 48TmtFDMuazBXtdl63aLYeWwOoQMFmcbUmyCS1R+3HiFCOvZy8L8O/p+SNye9QfiRMgR 75VA==
MIME-Version: 1.0
X-Received: by 10.180.79.163 with SMTP id k3mr19936567wix.34.1384378500282; Wed, 13 Nov 2013 13:35:00 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.120.167 with HTTP; Wed, 13 Nov 2013 13:35:00 -0800 (PST)
Date: Wed, 13 Nov 2013 13:35:00 -0800
X-Google-Sender-Auth: -DKjNmttcC8a9HF5hEsmxYbqhZ4
Message-ID: <CAJE_bqdUiQznZDUDsQ3d1niuRE=q1YqYp9=mNMm8Bo8QzB6xiQ@mail.gmail.com>
Subject: comments on draft-ietf-6man-multicast-addr-arch-update-02
From: 神明達哉 <jinmei@wide.ad.jp>
To: draft-ietf-6man-multicast-addr-arch-update@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Cc: IPv6 IPv6 List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 13 Nov 2013 21:35:06 -0000
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