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