Re: [Softwires] Call for reviewers draft-ietf-softwire-mesh-multicast

" Mingwei Xu " <xmw@cernet.edu.cn> Tue, 21 June 2016 02:45 UTC

Return-Path: <xmw@cernet.edu.cn>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A126B12D8A3; Mon, 20 Jun 2016 19:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.922
X-Spam-Level:
X-Spam-Status: No, score=-0.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no 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 hjV7AuQFXRPm; Mon, 20 Jun 2016 19:45:21 -0700 (PDT)
Received: from tsinghua.edu.cn (smtp38.tsinghua.edu.cn [166.111.204.62]) by ietfa.amsl.com (Postfix) with ESMTP id 2686212D888; Mon, 20 Jun 2016 19:45:16 -0700 (PDT)
Received: from win7-PC (unknown [166.111.71.59]) by app1 (Coremail) with SMTP id CsxvpgDHzEAxqmhX+XyRAA--.29683S2; Tue, 21 Jun 2016 10:45:05 +0800 (CST)
Date: Tue, 21 Jun 2016 10:45:05 +0800
From: "=?utf-8?B?TWluZ3dlaSBYdQ==?=" <xmw@cernet.edu.cn>
To: "=?utf-8?B?SWFuIEZhcnJlcg==?=" <ianfarrer@gmx.com>, "=?utf-8?B?ZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tZXNoLW11bHRpY2FzdA==?=" <draft-ietf-softwire-mesh-multicast@ietf.org>, "=?utf-8?B?c29mdHdpcmVz?=" <softwires@ietf.org>
References: <B5E05CB1-D4ED-457C-B383-824A52C99650@gmx.com>
Message-ID: <201606211045044291264@cernet.edu.cn>
X-mailer: Foxmail 6, 15, 201, 26 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
X-CM-TRANSID: CsxvpgDHzEAxqmhX+XyRAA--.29683S2
X-Coremail-Antispam: 1UD129KBjvJXoW3Gr1Uuw45XF17Aw1rWF1rWFg_yoW3Zw4rpF Z8KFnFkr4kJrW8A3W8Aw1j9F1Fvw4fGF9rWFy5Jw1UZ398Wry0qry0939IqFsrGr4rAFyj vw4a9FW5XF1kZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvvb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_ Cr1l84ACjcxK6I8E87Iv67AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJV WxJr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E 2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJV W8JwACjcxG0xvY0x0EwIxGrwACjcxG0xvY0x0EwIxGrVCF72vEw4AK0wACY4xI67k04243 AVAKzVAKj4xxMxkIecxEwVAFwVW8JwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r 1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij 64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr 0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Gr0_Cr1l IxAIcVC2z280aVCY1x0267AKxVW8JVW8Jr1l6VACY4xI67k04243AbIYCTnIWIevJa73Uj IFyTuYvj7UU6GPUUUUU
X-CM-SenderInfo: x0pzquphuqv3oohg3hdfq/
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/5DLqtXuhhzCg1_1It5aP9VYUCsg>
Subject: Re: [Softwires] =?utf-8?q?Call_for_reviewers_draft-ietf-softwire-mesh?= =?utf-8?q?-multicast?=
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: xmw@cernet.edu.cn
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jun 2016 02:45:24 -0000

Dear Ian,

Thank you for your suggestions, we have modified the draft and posted a new version in the WG, draft-ietf-softwire-mesh-multicast-13. The following is the reply to the review suggestions.

1. Pg 5 - states a 'dual-stack' router. The AFBR is not really dual-stack here. It has two single stack interfaces and implements a transition technology. Suggest removal of dual-stack.

Answer: We have removed the 'dual-stack'.

2. Section 4.1
The translation between the IPv4 and IPv6 PIM messages seems underspecified. It would be useful to provide some examples showing how the new addresses are used in the different translations into the PIM message formats (RFC7741 Section 4.1).

Answer: We have added some examples in Section 8.

3. Section 4.2
The term ‘MPREFIX64’ is not defined in RFC7371. As there are a number of different formats for multicast prefixes in RFC7371, it would be useful to point to the relevant section to avoid confusion.
Why was the name MPREFIX64 chosen for 4in6 multicast? In other Softwire docs (e.g. RFC7598), ’46’ is used to denote 4 in 6 functions and 64 for 6 in 4. As the addressing and mechanism for 4in6 differs for 6in4, it would make sense to differentiate this in the naming of the fields (i.e. use MPREFIX46, uPrefix46 for 4in6 and uPrefix64 for 6in4).

Answer: We have renamed them, using uPrefix46, uPrefix64 and mPrefix64, as denoted in Section 2.

4. Section 6.3
Section 6 overall defines requirements for the control plane. Sections 6.1. and 6.2 are MUST requirements. 6.3 uses ‘should’ in defining the behaviour. Can the mechanism work without implementing sec 6.3 and in which situations is it acceptable not to?

Answer: No, the mechanism can not work without implementing Sec 6.3. We have already changed the 'should' to 'MUST'. Thank you for your suggestions.

5. Section 6.5
This introduces the encapsulation of messages, but doesn’t provide any information about what type of encapsulation is used. Figure 7 shows UDP. Is this part of the encapsulation? As this is necessary for the mechanism to work and needs to be implemented on the AFBRs, there needs to be references and requirements language on what needs to be implemented.

Answer: In Section 6.5, we have added some words to illustrate that we take UDP as an example for encapsulation.

6. Section 7.2
Are there options on the kind of tunnel encapsulation that can be used? It would be useful to enumerate some of these and for interoperability one of them needs to be mandatory to implement.

Answer: We have added an paragraph in a new Section (Sec. 9), to state that the mechanism should accommodate a variety of encapsulation mechanism mentioned in RFC 4925 (Sec 3.5).

7. References
RFC2119 Needs to have a normative reference
RFC4601 has been obsoleted by RFC7761

Answer: We have modified the text.

8. General - 
The document doesn’t contain the ‘Conventions/Requirements Language’ boilerplate pointing to RFC2119 that needs to be in a standards track document. (The key words "MUST", "MUST NOT”, …)

Answer: We have contained the ‘Conventions/Requirements Language’ boilerplate pointing to RFC2119 in the new version.

9. The use of RFC2119 language and the case of the words throughout the document is not consistent (there are a number of lower case ‘must’ etc, that probably should be uppercase).
The term ‘should’ (lower case) is used in a number of places that make the functionality of the mechanism seem uncertain (e.g. Figure 1 - 'Multicast packets should get across the I-IP transit core'. Sec 4.1 'it should be translated back’).
There are some points that would seem to need MUST requirements that are missing - e.g. Section 4.4 'every uPrefix64 that AFBR announces should be different either, and uniquely identifies each AFBR’. If two AFBRs are announcing the same uPrefix64, surely there will be problems.
Suggest that the use of RFC2119 language is revised throughout the document to avoid these problems and to tighten up the specification as a whole.

Answer: We revised throughout the document to make the ‘Conventions/Requirements' words consistent.

10. The document needs the language and grammar checking throughout.

Answer: We have checked throughout the document and re-edited the language and grammar.


Best regards,

Mingwei



发件人: Ian Farrer 
发送时间: 2016-04-20  03:53:13 
收件人: draft-ietf-softwire-mesh-multicast; softwires 
抄送: 
主题: Re: [Softwires] Call for reviewers draft-ietf-softwire-mesh-multicast 
Hi,


Here is my review of the draft.


Best regards,
Ian


Pg 5 - states a 'dual-stack' router. The AFBR is not really dual-stack here. It has two single stack interfaces and implements a transition technology. Suggest removal of dual-stack.


Section 4.1
The translation between the IPv4 and IPv6 PIM messages seems underspecified. It would be useful to provide some examples showing how the new addresses are used in the different translations into the PIM message formats (RFC7741 Section 4.1).


Section 4.2
The term ‘MPREFIX64’ is not defined in RFC7371. As there are a number of different formats for multicast prefixes in RFC7371, it would be useful to point to the relevant section to avoid confusion.


Why was the name MPREFIX64 chosen for 4in6 multicast? In other Softwire docs (e.g. RFC7598), ’46’ is used to denote 4 in 6 functions and 64 for 6 in 4. As the addressing and mechanism for 4in6 differs for 6in4, it would make sense to differentiate this in the naming of the fields (i.e. use MPREFIX46, uPrefix46 for 4in6 and uPrefix64 for 6in4).


Section 6.3
Section 6 overall defines requirements for the control plane. Sections 6.1. and 6.2 are MUST requirements. 6.3 uses ‘should’ in defining the behaviour. Can the mechanism work without implementing sec 6.3 and in which situations is it acceptable not to?


Section 6.5
This introduces the encapsulation of messages, but doesn’t provide any information about what type of encapsulation is used. Figure 7 shows UDP. Is this part of the encapsulation? As this is necessary for the mechanism to work and needs to be implemented on the AFBRs, there needs to be references and requirements language on what needs to be implemented.


s/we do insure/it is ensured/


Section 7.2
Are there options on the kind of tunnel encapsulation that can be used? It would be useful to enumerate some of these and for interoperability one of them needs to be mandatory to implement.


References
RFC2119 Needs to have a normative reference
RFC4601 has been obsoleted by RFC7761


General - 
The document doesn’t contain the ‘Conventions/Requirements Language’ boilerplate pointing to RFC2119 that needs to be in a standards track document. (The key words "MUST", "MUST NOT”, …)


The use of RFC2119 language and the case of the words throughout the document is not consistent (there are a number of lower case ‘must’ etc, that probably should be uppercase).


The term ‘should’ (lower case) is used in a number of places that make the functionality of the mechanism seem uncertain (e.g. Figure 1 - 'Multicast packets should get across the I-IP transit core'. Sec 4.1 'it should be translated back’).


There are some points that would seem to need MUST requirements that are missing - e.g. Section 4.4 'every uPrefix64 that AFBR announces should be different either, and uniquely identifies each AFBR’. If two AFBRs are announcing the same uPrefix64, surely there will be problems.


Suggest that the use of RFC2119 language is revised throughout the document to avoid these problems and to tighten up the specification as a whole.


The document needs the language and grammar checking throughout.




On 7 Apr 2016, at 16:58, Ian Farrer <ianfarrer@gmx.com> wrote:


Hi,

This document has been around for some time, but has not received any substantive reviews. Can I ask for volunteers who are willing to provide reviews?

Thanks,
Ian


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires