Re: [sfc] Use of IPv6 EHs?

<mohamed.boucadair@orange.com> Thu, 27 March 2014 07:42 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771001A01F0 for <sfc@ietfa.amsl.com>; Thu, 27 Mar 2014 00:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.948
X-Spam-Level:
X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 p2FPlCC2__6n for <sfc@ietfa.amsl.com>; Thu, 27 Mar 2014 00:42:06 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1881A00FF for <sfc@ietf.org>; Thu, 27 Mar 2014 00:42:05 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 3628918C26C; Thu, 27 Mar 2014 08:42:03 +0100 (CET)
Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 0FC9A4C015; Thu, 27 Mar 2014 08:42:03 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 27 Mar 2014 08:42:02 +0100
From: mohamed.boucadair@orange.com
To: Tim Chown <tjc@ecs.soton.ac.uk>, "sfc@ietf.org" <sfc@ietf.org>
Date: Thu, 27 Mar 2014 08:42:01 +0100
Thread-Topic: Use of IPv6 EHs?
Thread-Index: Ac9I/O+gy+CMNZBiTMSp77tEdPFipQAkiMMg
Message-ID: <94C682931C08B048B7A8645303FDC9F36F54483E6B@PUEXCB1B.nanterre.francetelecom.fr>
References: <2691CE0099834E4A9C5044EEC662BB9D4535F337@dfweml701-chm.china.huawei.com> <CF574684.A63B%repenno@cisco.com> <94C682931C08B048B7A8645303FDC9F36F528DEB91@PUEXCB1B.nanterre.francetelecom.fr> <080093CE-B4B2-4ABF-B5C0-45FBDBC974F5@ecs.soton.ac.uk> <EMEW3|849d1c32430b208e32d5e78daa4947eeq2PE8o03tjc|ecs.soton.ac.uk|080093CE-B4B2-4ABF-B5C0-45FBDBC974F5@ecs.soton.ac.uk>
In-Reply-To: <EMEW3|849d1c32430b208e32d5e78daa4947eeq2PE8o03tjc|ecs.soton.ac.uk|080093CE-B4B2-4ABF-B5C0-45FBDBC974F5@ecs.soton.ac.uk>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36F54483E6BPUEXCB1Bnante_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.27.24215
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/yREaS_U-NF92sZf8h64TBcDeLvQ
Subject: Re: [sfc] Use of IPv6 EHs?
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Mar 2014 07:42:08 -0000

Hi Tim,

Thank you for this feedback.

If you have a pointer to cite, I can add it to the document. Note, that applying to conclusions of some experiments to the SFC use case is governed by this bullet:

   o  Despite it is widely known that routers and middleboxes filter IP
      options (e.g., drop IP packets with unknown IP options, strip
      unknown IP options, etc.), this concern does not apply for the
      Service Function Chaining case because the support of new IP
      options can be enabled within a domain operated by the same
      administrative domain.

As you rightfully said, assessing whether drops are due to "administrative policy, or implementation shortcomings." is key. This is exactly why the current text identifies the following items:

   | 1. Assess the impact on performance.                              |
   |                                                                   |
   | 2. Compare the impact of using the IPv4 option and the IPv6       |
   |    extension header vs. an encapsulation mode (i.e., in contexts  |
   |    where no encapsulation is required to reach the next SF hop).  |
   |                                                                   |
   | 3. Assess to what extent the use of an IPv4 option/IPv6 extension |
   |    header simplify internal tagging mechanisms specific to each SF|


Cheers,
Med

De : Tim Chown [mailto:tjc@ecs.soton.ac.uk]
Envoyé : mercredi 26 mars 2014 15:09
À : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Objet : Use of IPv6 EHs?

On 26 Mar 2014, at 12:23, <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:


Hi Reinaldo, all,

In addition to these two ones, other alternatives are discussed in http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02

Hi,

A couple of comments on the potential use of IPv6 EHs referenced in your design document.

Firstly, RFC6564 is being updated by draft-gont-6man-ipv6-universal-extension-header-00.

Secondly, some tests that we've run recently (to Alexa top1m IPv6-enabled sites) show the drop rate on packets with IPv6 EHs is quite significant. These were reported by ourselves and Fernando Gont in the IETF89 IEPG meeting. There have been a number of I-Ds discussing EH handling, but the results 'in the wild' are poor.  I understand that SFC is targeted at single domain environments, but it's not clear as yet whether drops are due to administrative policy, or implementation shortcomings. If the latter, then these may be an issue for at least some time for any SFC solution dependent on their use.

Tim