Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

Robert Raszuk <robert@raszuk.net> Fri, 17 March 2017 17:06 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440CC1294D7; Fri, 17 Mar 2017 10:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=gmail.com
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 Ci80OPErU3q3; Fri, 17 Mar 2017 10:06:52 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52BF1294E2; Fri, 17 Mar 2017 10:06:51 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id p64so69590993qke.1; Fri, 17 Mar 2017 10:06:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=huimbzT9igR/bgBFRaprpyktSNkywhaUOls6goEODII=; b=aYvZh/NEigMsn21ealOIviDnh2Jw4bqAs7w8ekDpX4CjYBgOzZ0qHKaQMvyxi0g04A goucK6da+ruFduj63TCb+vVC3iyY+x3sW4QPXC2UD79tstsH7g0f4biSWdos1REoGvyz xGBsEExDluTsw/1vSkRmpQnjBRVUpwXkhV7PR7Ke+nkbDtXOUD+RWpb0AY3YJ9i5lU2s geLemNQdnXdP9c1411eDsLK4M8AGNj1ljIiJiPBdqM2ffceClvTrUOKqsaZStlu3XdTW AQF8PQUHx23mLYxTIzdjfUl2YXPJN0t5n9YhoMwujynTtHi8m7D8j89F1BZJPId88CwL SiBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=huimbzT9igR/bgBFRaprpyktSNkywhaUOls6goEODII=; b=L5O0tEJnOwnRlKJchCNllTxI4BaBcD4XobYSAflDLWa5DreWp9+SW3lvm62rpyzvwZ Kt9FYexMhYGNMURznwgQ0xJy2baTkqcEwXIBVGhJKJIVweAY4vIAwe/X4dF8mmndFARN xxZjSZVtZtT4qa6oBSUxbUxftie9GJRtCs+bQJHuZ+RyUW5N5BlOHfMOvyFqXeM39xSs Ll7bp+daazwdku8ybtG3yEJsF1VJgu5g+WOhSuXTcHQFpwZzmlMOVUiMNqmRV5K9eojh 5dM0u3mI0PLQG0Xhh8Wv1T3+thV9i+0PNKSRDWmP7Ox852HPapMIfGelHOZULTVcBh2B iVPA==
X-Gm-Message-State: AFeK/H3V3G8e2xy998Emhi7u0NOfwadGysqnXQ3ZJOxSwFe0vvYJ9XE5itZadPACt06/7QMAF/VXDPbVjGH44A==
X-Received: by 10.55.18.158 with SMTP id 30mr15235848qks.123.1489770410840; Fri, 17 Mar 2017 10:06:50 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.42.181 with HTTP; Fri, 17 Mar 2017 10:06:50 -0700 (PDT)
In-Reply-To: <DE16D91D-AE7B-4D3C-B8EA-0CB644FB96BD@cable.comcast.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <A67E1C07-282B-4422-A2FF-86F6CACBD775@cable.comcast.com> <ab7c95a5-9776-24b5-7c26-4c5987d4c948@isi.edu> <ed2f5144-52fb-dda5-1fb4-62be1625b341@gmail.com> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> <DE16D91D-AE7B-4D3C-B8EA-0CB644FB96BD@cable.comcast.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 17 Mar 2017 18:06:50 +0100
X-Google-Sender-Auth: yQdN172Lkto47_f-fiWIUpf3rA4
Message-ID: <CA+b+ER=6dXLiwvLJa84uvpVeH0daGnZ-06P16JD0UutTrbUYyA@mail.gmail.com>
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: "Leddy, John" <John_Leddy@comcast.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, Tim Chown <Tim.Chown@jisc.ac.uk>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "draft-ietf-6man-rfc2460bis.all@ietf.org" <draft-ietf-6man-rfc2460bis.all@ietf.org>, 6man WG <ipv6@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="001a1146f48222a79f054af03437"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7UBvbveQgu4O9B37AwAi6jypczU>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Mar 2017 17:06:54 -0000

All,

This is very interesting thread indeed.

I think header insertion at *any* network element be it host, router,
service chain device is highly desired. IPv6 deployments will be much more
successful if we clear any obstacles which otherwise prevent it from
delivering required by customers and operators functionality.

And I would state that this should be not only limited to one's own IGP or
BGP domain. It should be legal Internet wide.

Today Internet as a entire system lacks tools to accomplish path
engineering, fast connectivity restoration, p2mp delivery of content etc
... Some of those are possible with MPLS based tools however as we all know
MPLS has no NNI and does not really work across domains. Here we stand very
close to have a chance to fix it.

And if one would forbid by spec the header insertion performed by network
elements what's the alternative ... IPv6 in IPv6 encapsulation which may
suffer with even more overhead yet will still require IANA allocation of
SRH type as well as TLV codepoints as effectively encapsulating network
element will be acting as IPv6 sender.

Concluding I do hope that we can try to collectively make IPv6 protocol
flexible enough to satisfy customer and operator's requirements what in
turn will enrich and speed up IPv6 global adoption.

Kind regards,
Robert.


On Thu, Mar 16, 2017 at 1:40 PM, Leddy, John <John_Leddy@comcast.com> wrote:

> Thanks Stewart,
>
> This really supports my point and hopefully not the intent or result of
> the discussions here.
>
> We are trying to work through the IETF process to come up with standards
> and solutions that address real operational challenges faced in
> deployments.  For operators, dealing with legacy and migrations are a big
> challenge.
>
> Wishing these issues away and as a result having non-standard
> functionality in “middle boxes” that are ignored in the architecture is not
> productive.  NATs are a way of life, dark space is being deployed by other
> operators, “Cloud”/NFV/ServiceChaining are active areas; tunnels, tunnels
> everywhere - PMTU is always an issue.  “Turtles and Tunnels all the way
> down”.
>
> We are very aggressively migrating to a V6 infrastructure, but there is a
> large amount of old legacy systems/applications/services that need to be
> addressed.  At the same time the allure of “Cloud” attracts systems that
> should never be moved without being re-architected and the virtualization
> environments fully supporting V6 (both Vendors and OpenSource) – but they
> do move and vendors help make that possible.
>
> Hopefully we can keep the discussions going and keep tools available until
> we know we have solutions to deal all the activity happening outside a
> clean end-to-end Architecture,
>
> John
>
>
>
> On 3/16/17, 6:44 AM, "Stewart Bryant" <stewart.bryant@gmail.com> wrote:
>
>     > In another form, the answer to John is that there are no protocol
> police,
>     > so what consenting adults do inside their own networks simply isn't
> an
>     > issue that an Internet-wide spec can or should address.
>
>     That is not quite true, the inability to gain an IANA allocated
>     codepoint can make long
>     term private deployments very difficult, either for the protocol
>     squatting on a codepoint
>     because they could not get one allocated, or to the deployment of a new
>     protocol
>     legitimately allocated a conflicting codepoint.
>
>     - Stewart
>
>
>
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>