Re: [Softwires] Problem in draft-ietf-softwire-multicast-prefix-option

Ian Farrer <ianfarrer@gmx.com> Thu, 09 June 2016 07:44 UTC

Return-Path: <ianfarrer@gmx.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 ADE5612D147 for <softwires@ietfa.amsl.com>; Thu, 9 Jun 2016 00:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 GI5A-62V9PPt for <softwires@ietfa.amsl.com>; Thu, 9 Jun 2016 00:44:45 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C7F12B035 for <softwires@ietf.org>; Thu, 9 Jun 2016 00:44:44 -0700 (PDT)
Received: from ians-mbp.lan ([62.225.30.139]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LrqNe-1bazEU2ws2-013h3a; Thu, 09 Jun 2016 09:44:40 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_AAD1DC0F-BCCD-40E2-B6FD-829FF74B6EEB"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ian Farrer <ianfarrer@gmx.com>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933008DAF3A6@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Thu, 9 Jun 2016 09:44:39 +0200
Message-Id: <0B27AECD-13CD-4B05-A34C-70E901807D40@gmx.com>
References: <787AE7BB302AE849A7480A190F8B933008DAECE0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <D5ABB288-99F9-4038-9E13-A9FC2ADAC0EF@gmx.com> <787AE7BB302AE849A7480A190F8B933008DAF3A6@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.2104)
X-Provags-ID: V03:K0:58CtmtxOZqWLRfLVaeQa3iv02SZHFRaGtWTE15rE7IcXMVPoQvl pLeGFxRML4w7oTjbl65hcjyr2FPoHXLnJUVHcZd7/g236CfCStaN7xvYmZLkW1lX2I7y/jm AxBVdEGvrYdp0avajiZfXy6n0NwxqwgiPocV7Xrni5jhNgBarJMW82l0sFcFtG7PYqWs9QQ yaM30zvuOanmBc0iq0dng==
X-UI-Out-Filterresults: notjunk:1;V01:K0:89GrfwyV0Cw=:ekzRF9QupbIcok/Qo4tDoi uBCYsm4pm7YIwtnmxlo18qns4Z0yDmoV/awtBfSUgD5u7ATXTkFT+jr3g+sqY1yz+CSyIz1uF qDfyZ5Knab943+Twll6JUlfRWFDnMUXede8nN3vh0bXKPdntKbORBby7pfLa0erZji/6ASHip wipQtudT5LzoOD6Yo+HZel911gh03fdorSjwQrX7YKasl/O7UIr0az2FpgVx7yyoogiDeqUIT ZJJ7GDdthooEROYkEzjeU21G/f1VRJId0+JkrU21hXfncz3kD6UWD669C7nuvUWhdA54W9LUk lMJbCDG3AjXFTLKzxrOlB5zbmAw94PB89QSKh5wfYpt+EGeNftOY6l7Gz3hFp2Aqseiu1wA+T OCb8oG42XJ78OD1S2mHgNOG5PFmYVcbe4OcNjKzvXjizOz6TBQZ2+lsaCHoWOp2+PyC8C2DJ5 fbt47c3Z75KFEdsP6aGwB2E/XssOKzlwNPJH3QUBPQ9DcKapaxoVFY6YlSpb91zCCGzJETjbz pHmurmFkSqUcKLfYQyWz2iFZpkjOX63Jv5czJX6YYmyyi/aMcNNvPvYKPpFy2vt1tf4VQRtlW 5faKPF1ZZXFTrgyLZybSNXui8pQusHl8J/pNiyVXEddv+A8k3KkKFwR5MOJSozzRnegCbQcX5 tb1opq9hWTqv/ka9YdcO5rV4qRGOGBAXafJxRlifgtZuHfr8mXQ0q6P3C6xhFE+iwGw3dkv0/ 7B98+vpylaXhdGWam0o3aqWvLxzylP+RtgddP0sSZW11KQR+/SqdkeO4KT57+0m8ChMIJObmZ Vid0cuA
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/hXCWRFEHyuoDIQ10VEhCu7jBC08>
Cc: Softwires WG <softwires@ietf.org>, "dhcwg-chairs@ietf.org" <dhcwg-chairs@ietf.org>
Subject: Re: [Softwires] Problem in draft-ietf-softwire-multicast-prefix-option
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: Thu, 09 Jun 2016 07:44:48 -0000

Hi Med,

To be clear, both of the suggestions include the modification to the Section 5 client text? I think this is necessary. But is the error condition that all of the enclosed options are the same scope, or that two or more are?

Between the two, I would prefer (1) - a MUST NOT with an exception is a SHOULD NOT. An alternative wording that tries to get the best of both:

A server MUST NOT send more than on one instance of OPTION_V6_PREFIX64 per scope. Servers MAY send one instance of OPTION_V6_PREFIX64 for each distinct IPv6 multicast prefix with a distinct scope. 

Thanks,
Ian

> On 9 Jun 2016, at 08:49, mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> wrote:
> 
> Hi Ian,
>  
> There are two options:
>  
> (1)
>  
> Maintain the current text in the draft but add the following text to Section 4:
>  
>    Servers SHOULD NOT send more than one instance of OPTION_V6_PREFIX64,
>    except if distinct IPv6 multicast prefixes with distinct scopes are
>    configured.
>  
> This is the behavior defined in https://tools.ietf.org/html/rfc6334#section-5/ <https://tools.ietf.org/html/rfc6334#section-5/>.
>  
> (2)
>  
> Add this text in Section 4:
>  
>    Servers MUST NOT send more than one instance of OPTION_V6_PREFIX64,
>    except if distinct IPv6 multicast prefixes with distinct scopes are
>    configured.
>  
> And modify the text in Section 5 to indicate that the client must discard the options if all enclosed addresses are of the same scope.
>  
> I agree with you that (2) will help to identify a server error, but with a risk to induce service disruptions.
>  
> Which one do you prefer to be implemented in the draft?
>  
> Thank you.
>  
> Cheers,
> Med
>  
> De : Ian Farrer [mailto:ianfarrer@gmx.com <mailto:ianfarrer@gmx.com>] 
> Envoyé : mercredi 8 juin 2016 19:10
> À : BOUCADAIR Mohamed IMT/OLN; Softwires WG
> Cc : dhcwg-chairs@ietf.org <mailto:dhcwg-chairs@ietf.org>
> Objet : Fwd: Problem in draft-ietf-softwire-multicast-prefix-option
>  
> Hi Med,
>  
> Forwarding this to the list (the left group mailing addresses were not working earlier).
>  
> Please see inline below.
>  
> Thanks,
> Ian
> 
> 
> Begin forwarded message:
>  
> From: <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>
> Subject: RE: Problem in draft-ietf-softwire-multicast-prefix-option
> Date: 8 June 2016 16:50:51 CEST
> To: ian Farrer <ianfarrer@gmx.com <mailto:ianfarrer@gmx.com>>, "softwires@ietf.org <mailto:softwires@ietf.org>" <softwires@ietf.org <mailto:softwires@ietf.org>>, Jacni Qin <jacni@jacni.com <mailto:jacni@jacni.com>>, "dxhbupt@gmail.com <mailto:dxhbupt@gmail.com>" <dxhbupt@gmail.com <mailto:dxhbupt@gmail.com>>
> Cc: "dhcwg-chairs@ietf.org <mailto:dhcwg-chairs@ietf.org>" <dhcwg-chairs@ietf.org <mailto:dhcwg-chairs@ietf.org>>
>  
> Hi Ian,
>  
> Please see inline.
>  
> Cheers,
> Med
>  
> De : ian Farrer [mailto:ianfarrer@gmx.com <mailto:ianfarrer@gmx.com>] 
> Envoyé : mercredi 8 juin 2016 16:11
> À : softwires@ietf.org <mailto:softwires@ietf.org>; BOUCADAIR Mohamed IMT/OLN; Jacni Qin; dxhbupt@gmail.com <mailto:dxhbupt@gmail.com>
> Cc : dhcwg-chairs@ietf.org <mailto:dhcwg-chairs@ietf.org>
> Objet : Problem in draft-ietf-softwire-multicast-prefix-option
>  
> Hi,
>  
> On reviewing this draft I would like to raise a problem with section 5 of the draft. The text is:
>  
> "If all the enclosed IPv4-embedded IPv6 multicast prefixes have the same scope, the first instance of the option MUST be used."
>  
> The problem is that this contravenes section 17 of RFC7227:
> Option order, either the order among many DHCPv6 options or the order
>    of multiple instances of the same option, SHOULD NOT be significant.
>    New documents MUST NOT assume any specific option processing order.
>  
> [Med] That sentence does not assume any (preference) order. It does only provide one way to select one instance among that list. As a reminder, the server is supposed to return one instance (per scope).
>  
> [if - If the client is taking the first occurrence within the option and attempting to configure it, then it is preferring this option over other instances based on the order in which it occurs in the message.
>  
> The current text which describes the server behaviour (section 4) does not mention scope at all and does not specify any limitations on the number of instances or criteria for which they may be included - see RFC7227 sec 16.
>  
> If the server is meant to only return a single instance of the option per scope, but it is sending more than one, then this is a server configuration error. A quasi-random mechanism for the client to try and work around this just means that the configuration error may get masked.
>  
> As a suggestion, wouldn’t it be better to specify what the valid cases for the server including multiple option instances are and are not (with normative language). The client’s behaviour can then be defined to discard the options if they do not meet this criteria?]
> 
> 
>  
>  
> I raised this with the DHC WG chairs, and they have a couple of suggestions:
>  
> 1. Define an encapsulating option - as the data inside an option can be order dependent.
> 2. Add a “preference” (octet?) and then a client can sort them based on this preference.
>  
> Thanks,
> Ian