Re: [dhcwg] DHCP Options for Network-Assisted Multipath TCP (MPTCP)

<mohamed.boucadair@orange.com> Thu, 12 November 2015 13:28 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494B21A8955; Thu, 12 Nov 2015 05:28:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 blNdzLwXPBVW; Thu, 12 Nov 2015 05:28:11 -0800 (PST)
Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3241A896D; Thu, 12 Nov 2015 05:28:11 -0800 (PST)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 7FE4BC0130; Thu, 12 Nov 2015 14:28:09 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4DBE21A0054; Thu, 12 Nov 2015 14:28:09 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%19]) with mapi id 14.03.0248.002; Thu, 12 Nov 2015 14:28:09 +0100
From: mohamed.boucadair@orange.com
To: "Bernie Volz (volz)" <volz@cisco.com>
Thread-Topic: [dhcwg] DHCP Options for Network-Assisted Multipath TCP (MPTCP)
Thread-Index: AQHRG9LloIa0MQcdN0KDD9p3IjCBh56YUoWggAANzoiAAAJK8A==
Date: Thu, 12 Nov 2015 13:28:08 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008C9BA96@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <D2660C4C.7A833%dan.seibel@telus.com> <787AE7BB302AE849A7480A190F8B933008C9AC74@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <m2pozifd2f.wl-Niall.oReilly@ucd.ie> <787AE7BB302AE849A7480A190F8B933008C9AD6A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <D8E99AD3-A93A-4C43-9E6D-9E3015EF4670@thehobsons.co.uk> <787AE7BB302AE849A7480A190F8B933008C9AEFD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <F8FA02F0-952D-472B-8016-71C3B62DA04B@thehobsons.co.uk>, <787AE7BB302AE849A7480A190F8B933008C9BA1F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0705B986-C01F-49E8-AD15-14C7D14C74BD@cisco.com>
In-Reply-To: <0705B986-C01F-49E8-AD15-14C7D14C74BD@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.3]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008C9BA96OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/SwgLZT1-qBCUmdBhp4aAJHwgb2k>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>, "draft-boucadair-mptcp-dhc@ietf.org" <draft-boucadair-mptcp-dhc@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] DHCP Options for Network-Assisted Multipath TCP (MPTCP)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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 Nov 2015 13:28:16 -0000

Hi Bernie,

I'm on the same page as you.

The proposed text was to explicitly show to Simon the complexity induced by the request to handle broken implementations.

FWIW, the latest version of the draft is available at: https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-03

Cheers,
Med

De : Bernie Volz (volz) [mailto:volz@cisco.com]
Envoyé : jeudi 12 novembre 2015 14:14
À : BOUCADAIR Mohamed IMT/OLN
Cc : Simon Hobson; dhcwg@ietf.org; multipathtcp@ietf.org; draft-boucadair-mptcp-dhc@ietf.org
Objet : Re: [dhcwg] DHCP Options for Network-Assisted Multipath TCP (MPTCP)

Please don't over specify this.

If client wants option it MUST request it in the ORO / PRL. End of story.

Note that clients may receive options they didn't ask for (perhaps ones they don't even know) and proper action is to ignore those.

It also makes little sense for a client not to ask for something it supports (except in cases where it is being asked (by an application?) to get something (via Information-Request/Inform) that it didn't request in the past).

What does a statement like the following mean?

"The DHCP client MUST be prepared to receive the DHCP MPTCP Concentrator
  Option even if it didn't include it in the request."

What is "prepared"? Again, client should always be "prepared" to receive any option - that may just mean ignoring it.

We are working to update RFC3315bis text to clarify that clients and servers must be capable of receiving any option - but will ignore those that they do not care about or know about.

We really want "other configuration" options documents to say very little about option processing. State that client MUST include in ORO/PRL to have any chance to receive it.

- Bernie (from iPad)

On Nov 12, 2015, at 8:00 AM, "mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:
Hi Simon,

(adding mptcp to the discussion)

Please see inline.

Cheers,
Med


-----Message d'origine-----
De : dhcwg [mailto:dhcwg-bounces@ietf.org] De la part de Simon Hobson
Envoyé : mardi 10 novembre 2015 17:14
À : dhcwg@ietf.org<mailto:dhcwg@ietf.org>
Objet : Re: [dhcwg] DHCP Options for Network-Assisted Multipath TCP
(MPTCP)

mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote:

But, in addition to updating the client's behavior so that it must be
prepared to receive the option even if it didn't requested for it

I think the specific use case was that the client is expecting it, but
just doesn't ask for it.

[Med] Agree on the use case. BTW, this is governed by the following:

https://tools.ietf.org/html/rfc7227#section-19:

"  For some options, such as the options required for the functioning of
  DHCPv6 itself, it doesn't make sense to require that they be
  explicitly requested using the Option Request Option.  In all other
  cases, it is prudent to assume that any new option must be present on
  the relevant option request list if the client desires to receive it."

and https://tools.ietf.org/html/rfc7227#section-21:

"As a convenience to the reader, we
  mention here that the server will send option foo only if configured
  with specific values for foo and if the client requested it."

My initial comment was: if we allow the server to return an option a client didn't asked for, we need to add a sentence like this one in the client's behavior section:

"The DHCP client MUST be prepared to receive the DHCP MPTCP Concentrator
  Option even if it didn't include it in the request."

(I do personally think this adds extra complexity without any guarantee that a broken implementation will make use of an option it didn't asked for).

I'm no expert user, but I have come across stuff

where a vendor has built server and client, and makes the two work
together - but not in a standards compliant way. Since in some cases the
vendor has zero interest in working with anything but an "all mine and
nothing else" network environment, they may have no interest in fixing a
client that is broken according to the standards, but which is working
with their server which is also non-standards compliant in a way that
makes the pair work together.


[Med] That's the point. Does it really matter to have a "SHOULD NOT" instead of "MUST NOT" if the standard behavior will be broken anyway?


... the server must support a logic to decide which clients should be
supplied with the mptcp option.

Typically that would be done by the admin, classifying the clients by some
means, and then overriding the requested parameter list. This is certainly
possible with the ISC server.

[Med] Yes; that's implementation-specific. My point is not about "how" but that the sever should be able to do that using "some means".



I can't remember what it was for (it was a good few years ago with a
different hat on), but I know I've had to provide an option list override
for a problematic client in the past - it was most likely a done by adding
it to a "host" declaration with the ISC server.

Although I understand the arguments you raised, I'm not convinced the
text should be relaxed.

As Niall points out, it prohibits an admin faced with a broken client from
working around the issue.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org<mailto:dhcwg@ietf.org>
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org<mailto:dhcwg@ietf.org>
https://www.ietf.org/mailman/listinfo/dhcwg