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

" Mingwei Xu " <> Wed, 20 April 2016 00:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C10112E8C1; Tue, 19 Apr 2016 17:47:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.921
X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p5RhEI5Lz0XM; Tue, 19 Apr 2016 17:47:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4705712E8BA; Tue, 19 Apr 2016 17:47:02 -0700 (PDT)
Received: from win7-PC (unknown []) by app5 (Coremail) with SMTP id DsxvpgAHDqZ40RZXPg5iAA--.1508S2; Wed, 20 Apr 2016 08:46:49 +0800 (CST)
Date: Wed, 20 Apr 2016 08:46:48 +0800
From: "=?utf-8?B?TWluZ3dlaSBYdQ==?=" <>
To: "=?utf-8?B?SWFuIEZhcnJlcg==?=" <>, "=?utf-8?B?ZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tZXNoLW11bHRpY2FzdA==?=" <>, "=?utf-8?B?c29mdHdpcmVz?=" <>
References: <>, <>
Message-ID: <>
X-mailer: Foxmail 6, 15, 201, 26 [cn]
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====003_Dragon748877752241_====="
X-CM-TRANSID: DsxvpgAHDqZ40RZXPg5iAA--.1508S2
X-Coremail-Antispam: 1UD129KBjvJXoWxXryrGFy7Xr45Xr1Uury7Awb_yoWrXr4xpF Z8KwnFkFn5JrW8Aa4kAw1j9F1FvrWfKrZxWFy5tw1UZ398Gryvqr109rZIqF4DGr4rAF10 vw4YkFW5JF1kZ3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUk0b7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_ Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E42I26xC2a48xMcIj6xIIjxv20xvE 14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2 IYc2Ij64vIr41lF7xvr2IYc2Ij64vIr40E4x8a64kEw24lFcxC0VAYjxAxZF0Ew4CEw7xC 0wCY02Avz4vE14v_twCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r106r1rMI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280 aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvj7UU6J5UUUUU
X-CM-SenderInfo: x0pzquphuqv3oohg3hdfq/
Archived-At: <>
Subject: Re: [Softwires] =?utf-8?q?Call_for_reviewers_draft-ietf-softwire-mesh?= =?utf-8?q?-multicast?=
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: softwires wg discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Apr 2016 00:47:07 -0000

Hi, Ian,

Thank you very much! We will modify the draft according to your valuable comments.



Mingwei Xu 

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

Here is my review of the draft.

Best regards,

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.

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


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?


Softwires mailing list