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

<mohamed.boucadair@orange.com> Mon, 25 April 2016 08:32 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 59C1D12D1E9; Mon, 25 Apr 2016 01:32:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Level:
X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 OvBmiX0B9k_V; Mon, 25 Apr 2016 01:32:30 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0286312D4FB; Mon, 25 Apr 2016 01:32:30 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 5880922C4A0; Mon, 25 Apr 2016 10:32:28 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.60]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 329F023806E; Mon, 25 Apr 2016 10:32:28 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0279.002; Mon, 25 Apr 2016 10:32:27 +0200
From: <mohamed.boucadair@orange.com>
To: Ian Farrer <ianfarrer@gmx.com>, "draft-ietf-softwire-mesh-multicast@ietf.org" <draft-ietf-softwire-mesh-multicast@ietf.org>, "softwires@ietf.org" <softwires@ietf.org>
Thread-Topic: [Softwires] Call for reviewers draft-ietf-softwire-mesh-multicast
Thread-Index: AQHRmnUrMQU7r+7MjEiSPnsbMSH3e5+aX2DQ
Date: Mon, 25 Apr 2016 08:32:27 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008D5F139@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <B5E05CB1-D4ED-457C-B383-824A52C99650@gmx.com> <E3A95CC1-A3EE-48F7-A010-2117292216CE@gmx.com>
In-Reply-To: <E3A95CC1-A3EE-48F7-A010-2117292216CE@gmx.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.3]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D5F139OPEXCLILMA3corp_"
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.14.165416
Archived-At: <http://mailarchive.ietf.org/arch/msg/softwires/SuG_J0R4UU4bv16QVXPlTeXpHT8>
Subject: Re: [Softwires] Call for reviewers draft-ietf-softwire-mesh-multicast
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: Mon, 25 Apr 2016 08:32:32 -0000

Hi Ian,

I agree with your comment «The term ‘MPREFIX64’ is not defined in RFC7371.”. FWIW, MPREFIX64 was defined in https://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-06#section-3

Also,
* The set of multicast-related provisioning parameters for the IPv4-over-IPv6 delivery case are defined in https://tools.ietf.org/html/rfc7678#section-2.5, not RFC7371.
* These parameters are consistent with those defined in https://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix-option-10 (that passed the WGLC).

Note that having a dependency on the mboned draft is not required.

Cheers,
Med

De : Softwires [mailto:softwires-bounces@ietf.org] De la part de Ian Farrer
Envoyé : mardi 19 avril 2016 21:53
À : draft-ietf-softwire-mesh-multicast@ietf.org; softwires@ietf.org
Objet : 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<mailto: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<mailto:Softwires@ietf.org>
https://www.ietf.org/mailman/listinfo/softwires