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

Mark Smith <markzzzsmith@gmail.com> Thu, 30 March 2017 20:24 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335F3126B72; Thu, 30 Mar 2017 13:24:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level:
X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 R9zm9G5niDAr; Thu, 30 Mar 2017 13:24:50 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 AE20812943B; Thu, 30 Mar 2017 13:24:47 -0700 (PDT)
Received: by mail-vk0-x234.google.com with SMTP id s68so68800442vke.3; Thu, 30 Mar 2017 13:24:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9UCmQ5KLq8wk+DPwCIEXLbXkwUyMyI/eyt2KZvPu1Zk=; b=UHQ0Yt57+zbj0RYo3gWnYNGd9zw0cY3hYHYWIoQqrqsMU0AYb+R0IzszdPeLHwYRzD ruHpSIO/vGC2c3+fAXsz3L0+peN8c8MOKRshmSQcvwvRGoHHyt1YulMM7Jt6xVQC7ddl bJjzzFcUsod3v0AxhS/mlXqY6wCv3tdNvrATOnbUtu9qhpwTP2rNiYDei+AjjdsFQwt7 3nhFLHtFWXAfQaB80mXLTPPqJU6ZdmonoNsTnG1vksTAY+q9CcNs81lm3ULbFbX22wsI xSo3kf7t51rT24xFth42PCzIgaD2U50xrbY37MdD8zR9MwxLc5NI9tr3b+Q7Gw9wbw01 lUag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9UCmQ5KLq8wk+DPwCIEXLbXkwUyMyI/eyt2KZvPu1Zk=; b=cHdqXJXGgk+cN6S/UcTz53mMvzJMjVmXWxa8FQjirALUGLMdm8m4Bfue9TsXwfDk3B yjC6Ad+5CTdMo0aV5LfVFBk7r6EwoDbDvpCwJx2g8X+fVTAsoXgSVAuqrnjyViO8x5J/ z0Li6c/L+5LmPOTI9xwFNC04HKikxV8AfaJr+nvFAt7jHiUWSjzRfZodEiZo6+izHJv3 /U2SYnd3wljbNB+CwLYmEMftWO7C7i6Vt4LuZBBi9VzTFbKDrzWOlDs/TlNiI89u0o5/ mNmdyc+viHY1BAKCMzg7t/IIEqvGHuA8MVZLnBBxIVZZCOW5guOomRi4hNmmqtfCyK8L DDHg==
X-Gm-Message-State: AFeK/H1w0DYSp1YCyKqdxrU4SvE/IDhTivNNt9a8ZSQ3X6rBOjfrKQt/WuoUIWjjJCdOcy0eMrsIwj6h9IkJdQ==
X-Received: by 10.176.64.34 with SMTP id h31mr910460uad.89.1490905486642; Thu, 30 Mar 2017 13:24:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.181 with HTTP; Thu, 30 Mar 2017 13:24:16 -0700 (PDT)
In-Reply-To: <CY4PR14MB1368118932BAB02AE83C781FD7340@CY4PR14MB1368.namprd14.prod.outlook.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <CC4FF04D-0712-4304-BD5F-3D9F57E533A3@ericsson.com> <CY4PR14MB1368118932BAB02AE83C781FD7340@CY4PR14MB1368.namprd14.prod.outlook.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Fri, 31 Mar 2017 07:24:16 +1100
Message-ID: <CAO42Z2x-wVez3A36dDSEVLWN1z5YXkLjb5Vx7b9KJzv7KTVcZg@mail.gmail.com>
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: "Ackermann, Michael" <MAckermann@bcbsm.com>
Cc: Suresh Krishnan <suresh.krishnan@ericsson.com>, "Leddy, John" <John_Leddy@comcast.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: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/6GC0s-ONdhZvRjJEKYXS-490okA>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 20:24:53 -0000

The thing to keep in mind is that enterprises use technology to solve
business problems. Technology is a means to an end, not the end
itself.

For general Internet or internal networking problems, IPv6 doesn't
solve the problem any better than IPv4 does. That is why Enterprises
haven't adopted it for their Internet or general internal networks.
Adding IPv6 is actually worse - it just increases their capex and opex
for no business benefit.

I've heard SR recently called the next MPLS. So how many Enterprises
have adopted MPLS?

When Enterprises need to access IPv6 Internet services, they'll just
IPv6 enable their boundary Internet access security devices and mail
servers.

IPv6 will be used by Enterprises when it either provides a compelling
advantage over IPv4, or where a vendor's "turn key" solution uses it.
I've seen that recently with AMI smartmeter mesh networks.

Here in Victoria, AU, there are probably in the order of 1M+ IPv6 AMI
smart meters across multiple electricity distributors. They're using
IPv6 for that because that is what the vendor's end-to-end AMI
solution uses. They use IPv4 to access the OSS and servers that are
used to troubleshoot that network, and there is no real benefit for
the organisation to deploy IPv6 on their internal LANs to access those
servers.

Inventing a new IPv6 feature just to try to encourage adoption isn't
going to be that successful. The new feature has to be a compelling
solution to a problem that the enterprise has, that justifies the
additional and typically very large expense of deploying IPv6 to get
it.

Regards,
Mark.



On 31 March 2017 at 03:54, Ackermann, Michael <MAckermann@bcbsm.com> wrote:
> This is something I tried to say at the mic today, but I was too late.
> If we put potentially valuable use cases into the bucket of "Exceptions",  this becomes yet another excuse to delay or avoid adoption of IPv6 by the very large percentage of Enterprises who have yet to do so (and have no serious plans) today.
>
> I am hopeful that work in the IETF will provide features and hence motivation for us sadly delinquent Enterprises to begin actually using IPv6.    I am concerned that perception of solutions being "Exceptions" or non standard, will cause consternation (warranted or not) and avoidance.
>
>
> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Suresh Krishnan
> Sent: Thursday, March 30, 2017 9:30 AM
> To: Leddy, John <John_Leddy@comcast.com>
> Cc: draft-ietf-6man-rfc2460bis.all@ietf.org; 6man WG <ipv6@ietf.org>rg>; ietf@ietf.org
> Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
>
> Hi John,
>   Thanks for chiming in. I recognize that you might have use cases that might be better off with header insertion but I think they should be handled as and when they come up for consideration (e.g. in the SRv6 discussions). Holding up this document is not going to help in any way in reinterpreting what RFC2460 intended. My suggestion for proponents of safe header insertion to write up how it is expected to work and have the discussion then.
>
> Thanks
> Suresh
>
>> On Mar 29, 2017, at 9:59 PM, Leddy, John <John_Leddy@comcast.com> wrote:
>>
>>> On Mar 14, 2017, at 9:47 PM, Suresh Krishnan <suresh.krishnan@ericsson.com> wrote:
>>>
>>> NEW:
>>>
>>> With one exception, extension headers are not examined, processed,
>>> inserted, or deleted by any node along a packet's delivery path,
>>> until the packet reaches the node (or each of the set of nodes, in
>>> the case of multicast) identified in the Destination Address field of
>>> the IPv6 header...
>>>
>>> Please feel free to comment either privately or on list if you have any concerns with this resolution going forward.
>>
>>
>> Suresh,
>>
>> I still have concerns that we are eliminating a tool that may prove very helpful in migrations without understanding its value.
>>
>> The Internet transition of IPV4 -> Dual Stack V4/V6 -> IPV6 Only; has been long, operationally complex and full of unexpected challenges.
>> We are only now starting to make the transition from Dual Stack to IPV6 Only, there are still many unknowns on how to complete this migration.
>>
>> As we contemplate finishing this major Network shift – We find ourselves in the early stages of another.
>>
>> The transition from Physical to Virtual Infrastructure.  Again, the migration will be long, operationally complex and full of unexpected challenges.
>>
>> In the old world with Servers running Applications in Physical locations designed for very predictable loads; using an encap/decap tunnel to emulate a physical circuit between locations has many attractive properties – but that is compared to actually ordering and provisioning real circuits between locations.
>>
>> In the new world of dynamic resources spun up on demand in distributed environments across multiple providers, Applications having the Intelligence and State to bring up their own required connectivity is very natural.  This is where we are putting the majority of our efforts.  SRv6 enables very attractive solutions by Applications building their own headers.
>>
>> The challenges come as we try to migrate and require these two infrastructures to Interoperate for a long time.
>> Burdening the new Virtual world with Old, Static circuit paradigms is not optimal.
>> Supplementing the legacy infrastructure with an assist function seems
>> a reasonable solution.  (Ext Hdr insertion/deletion or encap/decap
>> tunnels)
>>
>> The preferred assist mechanism seems to be the one that allows the New
>> World to operate in its final preferred state, sending and receiving packets with their own headers. (SRv6) But what does an Application in the new world due when it is attempting to communicate with an Application in the Old World?
>> Shouldn’t it build an SRv6 header?  That would mean that the assist function would need to be the last SID in the Segment List and be capable of removing the SRH.
>> Wouldn’t it make sense for the assist function to do the same thing in the reverse direction; an Old World Server talking to a New Virtual World Application?  Insert an SRH.
>>
>> If this insert/delete of an SRH is prematurely prohibited;  What is a recommended solution to the Real World problem above.  Not use case, we are implementing.
>>
>> Again; I’m worried we are eliminating a tool that may prove very
>> helpful, preclude its use in future IETF work and shutdown a path for
>> Innovation in Networking,
>>
>> Thank you for asking and listening to my concerns,
>>
>> John Leddy
>> Comcast
>>
>>
>>
>>
>>
>>
>
>
>
> The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
>
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------