Re: [dhcwg] Review of draft-ietf-softwire-multicast-prefix-option-11
<mohamed.boucadair@orange.com> Thu, 12 January 2017 14:29 UTC
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B3E1293EB; Thu, 12 Jan 2017 06:29:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.118
X-Spam-Level:
X-Spam-Status: No, score=-5.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 GzL4qV6M5esf; Thu, 12 Jan 2017 06:29:22 -0800 (PST)
Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2BF71293F0; Thu, 12 Jan 2017 06:29:21 -0800 (PST)
Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 123D41C06EE; Thu, 12 Jan 2017 15:29:20 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id D7DCB60064; Thu, 12 Jan 2017 15:29:19 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0319.002; Thu, 12 Jan 2017 15:29:19 +0100
From: mohamed.boucadair@orange.com
To: "Bernie Volz (volz)" <volz@cisco.com>, "draft-ietf-softwire-multicast-prefix-option.all@ietf.org" <draft-ietf-softwire-multicast-prefix-option.all@ietf.org>
Thread-Topic: Review of draft-ietf-softwire-multicast-prefix-option-11
Thread-Index: AQHSavVcUBePv434J0OSD7BXQp4GqKE08DeA///weJA=
Date: Thu, 12 Jan 2017 14:29:18 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DE35CD@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <148402050186.25046.4223816824977657511.idtracker@ietfa.amsl.com> <FAF4B12B-398D-47AA-B666-25C191ABDAC3@cisco.com>
In-Reply-To: <FAF4B12B-398D-47AA-B666-25C191ABDAC3@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/A67FsMDRKoC2NAg6MEDheBwVAf8>
Cc: "softwires@ietf.org" <softwires@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] Review of draft-ietf-softwire-multicast-prefix-option-11
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jan 2017 14:29:23 -0000
Hi Bernie, Thank you for the review. Please see inline. Cheers, Med > -----Message d'origine----- > De : Bernie Volz (volz) [mailto:volz@cisco.com] > Envoyé : jeudi 12 janvier 2017 14:49 > À : draft-ietf-softwire-multicast-prefix-option.all@ietf.org > Cc : softwires@ietf.org; dhcwg@ietf.org; Terry Manderson > Objet : Review of draft-ietf-softwire-multicast-prefix-option-11 > > Hi: > > A few comments on this draft. > > Section 2: > > The dslite-multicast draft uses uPrefix64 instead of U_PREFIX64? > Consistency between the various softwire documents might be useful? [Med] Works for me. > > Nit: SSM_PREFIX64 has an extra closing parenthesis (after the RFC4607 > reference). [Med] Fixed. > > Section 3: > > I am not sure that the *-length fields are correctly documented? Can they > really be 0-128. I understand 0 if there is none, and I can see 1-96 > potentially, but does more than 96 make sense? It seems that the other > documents referenced typically say to use the prefix (96 bits – perhaps > zero extended if needed to make 96 bits) and then add 32-bits IPv4 for > multicast (unicast is a bit more complex when prefix is not 96). But none > of this other text seems to imply that the prefix length can be > 96? [Med] As mentioned in Section 5, only 96 is allowed. I already fixed Section 3 accordingly. > > Also, while 2001::/96 could be sent as 2001::/16 in terms of the option > encoding (as bits 17 to 96 are 0), the two are vastly different in terms > of what they might mean (if the prefix is always mapped to /96 it may not > matter). I just wonder if this needs to be clarified some? I believe the > first encoding (2001::/96 is always intended as that communicate the true > prefix length). > > Is the reference to “Section 6 of RFC7051” correct? Was this intended to > be RFC 7227 (Section 6 there is titled “Avoid Conditional Formatting”). [Med] Section 6 of RFC7051 is correct. It documents the use of Well-known DNS name for the unicast-only case. I updated the text to make this explicit. NEW: Such side effect conflicts with the recommendation to support the Well-Known DNS Name heuristic discovery-based method for unicast-only environments (Section 6 of [RFC7051]). > > I think it would be useful to clearly state that multiple instances of > this option are allowed. Yes, if you carefully read the text (in Section 4 > & 5) this is evident, but it is useful to state this explicitly when > defining the option! [Med] Happily. I added to NEW text to section 3: "Multiple instances of OPTION_V6_PREFIX64 may be returned to a DHCPv6 client." > > Section 5: > > Nit: There are two “Pv4 mulitcast” instances; are these supposed to be > “IPv4 multicast”? [Med] Fixed. > > Note here that the text for ASM and SSM says to insert last 32-bits. This > would imply that a prefix length > 96 does not work. (See comments above > for section 3.) [Med] Yes, only 96 is allowed. See above. > > And, there is talk here about scope selection and adding the same > reference as in Section 4 (to RFC7346) might be useful? Client > implementers may not read the server section, so duplicating the reference > here would be useful. [Med] Works for me. Done! > > - Bernie > > >
- [dhcwg] Review of draft-ietf-softwire-multicast-p… Bernie Volz (volz)
- Re: [dhcwg] Review of draft-ietf-softwire-multica… mohamed.boucadair