Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs
Gert Doering <gert@space.net> Wed, 29 July 2020 15:35 UTC
Return-Path: <gert@space.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB3F3A0B9B for <v6ops@ietfa.amsl.com>; Wed, 29 Jul 2020 08:35:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net
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 GP5qumG8TaBv for <v6ops@ietfa.amsl.com>; Wed, 29 Jul 2020 08:35:23 -0700 (PDT)
Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E403A0CE2 for <v6ops@ietf.org>; Wed, 29 Jul 2020 08:35:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1596036904; x=1627572904; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=hKvJUONBP3k2XZOEuX+pPuB6lxh5GX5tJ9uz1nn5rTM=; b=R03pZEnrIoNGMyt2UAUX7CJBB457OozeJvzTcooeeRoahVbC2mYQElSG /htcMMAwhJYZ3wuyu478T42sHJrtGhzXtD0CwShks4f2qAt5uztXhemra reFgjYvMbBvPQGnUKG7imagGLdFneqO4Vijo6DZz1nm9XDsyggi+FMZoE y9VjRxrTBSQ4XXVjEbbZ0qoskN6jYHImj1IBf2wZJSD13xo19mPAKZyJ5 XPIO2Q3v1uog6wNgmswTXx0FPZxiE5EKNGzMULrUPuZfrbNBZLjoxx0RY hGKRyMuhfi1IaDOVpowwGzzVbQgS9Uo/7ZSD7AJCr6SiZDxqzfVVHckbI g==;
IronPort-SDR: PA1yEephiuY4apcUI0J2yK9rJ6LBOSJAgDLvuXn/xsY21XaFpiGxPDRzRPAWnU75kk30hHONrF hJ5TRFWYvC0BfPRi/qbW1d0qbeLbeIjwacT1TKbp3sOIt67bdQOcMZXfcR3rwoGva/qVKmF+Qf /vyjy+UNY2jyJ76TofOdJ5IynFWoNpGJ1XsOTgpNNVhUU74jVF4VW/hxcAz+v21B7ByngWBePS jWBhQynA1l5JPY05G0W5YoGQ0pl1juf2XdThgggGvPi6dadcKla7OIUOSns3DRx7Ab/lH0ATR4 aEA=
X-SpaceNet-SBRS: None
Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2020 17:35:01 +0200
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0BF1F418BA for <v6ops@ietf.org>; Wed, 29 Jul 2020 17:35:01 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id B243240B9D; Wed, 29 Jul 2020 17:35:00 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id AC357193FA; Wed, 29 Jul 2020 17:35:00 +0200 (CEST)
Date: Wed, 29 Jul 2020 17:35:00 +0200
From: Gert Doering <gert@space.net>
To: Tom Herbert <tom@herbertland.com>
Cc: Gert Doering <gert@space.net>, Ole Troan <otroan@employees.org>, Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>
Message-ID: <20200729153500.GE2485@Space.Net>
References: <d8d59ce07f7f4031a545ff6e24fdbb88@huawei.com> <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> <a6ed89a8-c12e-b8d2-c720-5cc02e127a68@si6networks.com> <FCBD1043-A0B2-435A-9AB9-0FCE3566C769@employees.org> <20200729122622.GT2485@Space.Net> <CALx6S34kLn+n4TMQrO0YKncB_j2P5Z2M3-Sn1_81+eDaTONz1A@mail.gmail.com> <20200729145828.GX2485@Space.Net> <CALx6S34HSN1x9rmTnm88v3FrrPJKk8hPen-cTmSp0hfQQRxeYg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="pjzOFJWVSGBRI8Xq"
Content-Disposition: inline
In-Reply-To: <CALx6S34HSN1x9rmTnm88v3FrrPJKk8hPen-cTmSp0hfQQRxeYg@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/iTRmqF7Brr9aT9foF2eNFPhF4FE>
Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2020 15:35:26 -0000
Hi, On Wed, Jul 29, 2020 at 08:18:28AM -0700, Tom Herbert wrote: > > There is no incentive for network operators to make sure their network > > can transport EHs if it works "without". > > > > There is no incentive for application developers to code support for > > "anything with EH" if they have to assume "it will need to work across > > networks without". > > Then they won't be able to use segment routing, IOAM, or new QoS > signaling like Network Tokens that are now being developed and being > deployed. That's fine, it's their prerogative. And by that, you acknowledge that using "EH across the wide Internet" is not going to work. Nobody challenged that the use of EH in a closely controlled environment ("my network and all the partner networks that I have a contract that governs that we'll cooperate regarding these EHs") will work. [..] > but IMO if we apply the right techniques we can opportunistically > provide something that works and provides value to users. EH has turned out to be costly to people that have no way to recover these costs as their customers have no interst. Now, if Google would show up and say "all web sites that demonstrate use of the TurboEH are ranked up by 20%", you can bet that SEOs would be the first to demand working and fully transparent EH support, no matter the cost... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
- [v6ops] Operational Implications of IPv6 Packets … Vasilenko Eduard
- Re: [v6ops] Operational Implications of IPv6 Pack… Gert Doering
- Re: [v6ops] Operational Implications of IPv6 Pack… Vasilenko Eduard
- Re: [v6ops] Operational Implications of IPv6 Pack… Gert Doering
- Re: [v6ops] Operational Implications of IPv6 Pack… otroan
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Gert Doering
- Re: [v6ops] Operational Implications of IPv6 Pack… otroan
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Philip Homburg
- Re: [v6ops] Operational Implications of IPv6 Pack… Gert Doering
- Re: [v6ops] Operational Implications of IPv6 Pack… Tom Herbert
- Re: [v6ops] Operational Implications of IPv6 Pack… Gert Doering
- Re: [v6ops] Operational Implications of IPv6 Pack… Tom Herbert
- Re: [v6ops] Operational Implications of IPv6 Pack… Gert Doering
- Re: [v6ops] Operational Implications of IPv6 Pack… Joseph Touch
- Re: [v6ops] Operational Implications of IPv6 Pack… Tom Herbert
- Re: [v6ops] Operational Implications of IPv6 Pack… Owen DeLong
- Re: [v6ops] Operational Implications of IPv6 Pack… Joseph Touch
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Brian E Carpenter
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Fred Baker
- [v6ops] Operational Implications of IPv6 Packets … tom petch
- Re: [v6ops] Operational Implications of IPv6 Pack… Vasilenko Eduard
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Brian E Carpenter
- Re: [v6ops] Operational Implications of IPv6 Pack… tom petch
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… tom petch
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Gyan Mishra
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Ole Troan
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Gyan Mishra
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Gyan Mishra