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

"Leddy, John" <John_Leddy@comcast.com> Thu, 16 March 2017 12:41 UTC

Return-Path: <John_Leddy@comcast.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 79589129482; Thu, 16 Mar 2017 05:41:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ApmzxNyddbHB; Thu, 16 Mar 2017 05:40:59 -0700 (PDT)
Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (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 BC39C129464; Thu, 16 Mar 2017 05:40:57 -0700 (PDT)
X-AuditID: 60721c4b-93fff700000006b0-67-58ca87d6b9bc
Received: from VAADCEX48.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by (SMTP Gateway) with SMTP id 86.69.01712.7D78AC85; Thu, 16 Mar 2017 08:40:56 -0400 (EDT)
Received: from VAADCEX41.cable.comcast.com (147.191.103.218) by VAADCEX48.cable.comcast.com (147.191.103.225) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 16 Mar 2017 08:40:54 -0400
Received: from VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268]) by VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268%19]) with mapi id 15.00.1263.000; Thu, 16 Mar 2017 08:40:53 -0400
From: "Leddy, John" <John_Leddy@comcast.com>
To: Stewart Bryant <stewart.bryant@gmail.com>, Tim Chown <Tim.Chown@jisc.ac.uk>, Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: 6man WG <ipv6@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>, "draft-ietf-6man-rfc2460bis.all@ietf.org" <draft-ietf-6man-rfc2460bis.all@ietf.org>
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Index: AQHSnaSAxRLtjcu1EUaNXmYCyEu8g6GWVuWAgAABTAD//8BKAIAAXywAgAAMrICAAEuugIAAvF6A///dbwA=
Date: Thu, 16 Mar 2017 12:40:53 +0000
Message-ID: <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>
In-Reply-To: <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [96.115.73.252]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9DBCF6E95FD0C846BD8BD6D2A9CC8E6C@cable.comcast.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsWSUOxpoXuj/VSEwaaV6hZtF/cxWbx6e43N 4tnG+SwWL8++Z7JYv/sRk8WpB4kWfT8fszmwe0z5vZHVY+esu+weS5b8ZPJY+fsKWwBLFJdN SmpOZllqkb5dAlfG2ju7GAveiFa8/yTVwLhEtIuRg0NCwETi1AueLkYuDiGBmUwSU1/8YINw DjFKLLjzjAXCOckocbN5D3MXIycHm4COxIxp11hBEiICTYwSn8/3MIM4zAInGCWm3WtlBKkS FvCQmLTpGguILSLgKbFu42EWkH0iAkkSL/5Wg4RZBFQlXi97xgZi8wq4SHTebWMCsYUE7jNL LH8oDGJzCthKbG/aCjaSUUBM4vupNWA1zALiEreezAezJQQEJJbsOc8MYYtKvHz8jxXEFhXQ k3h47yYrRFxH4uz1J4wQtoHE1qX7WCBsRYl/s9eDncYsoCmxfpc+xHgHiZs9DewQtqLElO6H 7BBnCkqcnPkEqlVc4vCRHawTGKVnIbloFsKkWUgmzUIyaRaSSQsYWVcxypUlJqYk52bkl5YY GOolJyblpOol5+cmJxaXgOhNjKAUUSTjvYNx3U/3Q4wCHIxKPLzu4acihFgTy4orc4FRxcGs JMLrlgoU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzntJZHWEkEB6YklqdmpqQWoRTJaJgxOYFswj i/SdJU9Nn23r0PItfdP12y9XxG5zjjVvP1X7ZR6joHx3wGTVbSVSe+fIpoTsC+h+XsW/Z7nd /wP266f/YZL+P/vchXV3PeIrnjREbvLZ2j9XJnvpk5rlz1gu/mncc/jjpOTCkhchjOcOaUvd Wit52knOdaP51/0skwo2X499orC08vm/x0FKLMUZiYZazEXFiQAS/JsdDQMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/a8rQG8GINvJI3fOrmRGSXh0iPpw>
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, 16 Mar 2017 12:41:01 -0000

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