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

"Voyer, Daniel" <daniel.voyer@bell.ca> Wed, 15 March 2017 17:58 UTC

Return-Path: <daniel.voyer@bell.ca>
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 3600013175C; Wed, 15 Mar 2017 10:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.697
X-Spam-Level:
X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Q4GJHgzNIybm; Wed, 15 Mar 2017 10:57:58 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.141]) (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 93EDC13175A; Wed, 15 Mar 2017 10:57:57 -0700 (PDT)
Received: from [85.158.136.35] by server-5.bemta-5.messagelabs.com id 7D/D7-29481-3A089C85; Wed, 15 Mar 2017 17:57:55 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJKsWRWlGSWpSXmKPExsXi7PqsVXdxw8k Ig9X35Sxevb3GZvFs43wWi5dn3zNZrN/9iMlixpyf7A6sHlN+b2T1+PX1KpvHkiU/mQKYo1gz 85LyKxJYM6YtXsZa8E6s4vj59cwNjF+Euhg5OSQE/CR6L11j62Lk4hAS2MsoseHEGSYI5wajx PkLM1ghnNOMEuc6pgJlODjYBHQk5ryQB+kWETCVOD/jPDOIzSxwhFGi+bEHiC0s4CExadM1Fo gaT4l1Gw9D2VYSU14eZgWxWQRUJf5t/8kGMpIXKP5zgh1IWEigQGLp7LVg5ZwCthI3p3aBlTM KiEl8P7WGCWKVuMStJ/OZIB4QkFiyB+IECQFRiZeP/7FC2AYSW5fuY4GoN5B4f24+1JnaEssW vgazeQUEJU7OfMICUS8pcXDFDRaIGxQl5t16ywLx+jxGiYlb29ghiuwl/l/6wTiBUWoWkjtmI dkxC8mOWUh2LGBkWcWoUZxaVJZapGtooZdUlJmeUZKbmJmja2hgqpebWlycmJ6ak5hUrJecn7 uJERjlDECwg7Fpu+chRkkOJiVRXpXckxFCfEn5KZUZicUZ8UWlOanFhxhlODiUJHhL64FygkW p6akVaZk5wHQDk5bg4FES4bUHSfMWFyTmFmemQ6ROMSpKifOuBkkIgCQySvPg2mAp7hKjrJQw LyPQIUI8BalFuZklqPKvGMU5GJWEeUNApvBk5pXATX8FtJgJaPHbDydAFpckIqSkGhhNZROYU 1JV78450jDB7cKTSgvPrMvXF4nZ3quzbQ+10q0TO/T848GJZ/LULX7tiKuV/dDvKtG57OtPQb O9N1e9vqrjN1NpWW5FxFWR8v8tz+5P9arvCv8gcm/K0sMbvdyazTZK7pv0cOv0ytxvPfO0uaz yzpdnr5U4//ak9J2iGWYN7GaiO9cpsRRnJBpqMRcVJwIA2EU5Y2wDAAA=
X-Env-Sender: daniel.voyer@bell.ca
X-Msg-Ref: server-14.tower-125.messagelabs.com!1489600671!71930018!6
X-Originating-IP: [67.69.230.133]
X-StarScan-Received:
X-StarScan-Version: 9.2.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29394 invoked from network); 15 Mar 2017 17:57:55 -0000
Received: from tls.exchange.bell.ca (HELO Tls.exchange.bell.ca) (67.69.230.133) by server-14.tower-125.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 15 Mar 2017 17:57:55 -0000
X-CrossPremisesHeadersFilteredBySendConnector: EX13EDGE02-WYN.bell.corp.bce.ca
Received: from DG2MBX03-WYN.bell.corp.bce.ca (198.235.102.32) by EX13EDGE02-WYN.bell.corp.bce.ca (198.235.68.44) with Microsoft SMTP Server id 15.0.1210.3; Wed, 15 Mar 2017 13:57:31 -0400
Received: from DG2MBX03-WYN.bell.corp.bce.ca (2002:8eb6:1215::8eb6:1215) by DG2MBX03-WYN.bell.corp.bce.ca (2002:8eb6:1215::8eb6:1215) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 15 Mar 2017 13:57:37 -0400
Received: from DG2MBX03-WYN.bell.corp.bce.ca ([fe80::c841:4444:5043:4356]) by DG2MBX03-WYN.bell.corp.bce.ca ([fe80::c841:4444:5043:4356%23]) with mapi id 15.00.1210.000; Wed, 15 Mar 2017 13:57:37 -0400
From: "Voyer, Daniel" <daniel.voyer@bell.ca>
To: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
CC: Suresh Krishnan <suresh.krishnan@ericsson.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>
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: AQHSnTZv71giYAPcbUKK9ywM4gSjvqGWUaEA///fNVw=
Date: Wed, 15 Mar 2017 17:57:37 +0000
Message-ID: <F067FF8F-0D1D-4590-9618-90FE0706BC24@bell.ca>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com>, <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com>
In-Reply-To: <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Received-SPF: SoftFail (EX13EDGE02-WYN.bell.corp.bce.ca: domain of transitioning daniel.voyer@bell.ca discourages use of 198.235.102.32 as permitted sender)
X-OrganizationHeadersPreserved: EX13EDGE02-WYN.bell.corp.bce.ca
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/UTJ0VStvQDtHxvs1nZXLKFru0js>
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: Wed, 15 Mar 2017 17:58:01 -0000

> We do have today use cases where not only the source of a packet should be allowed to insert a header but also the source “domain” of a packet. I’ll try to explain.
> 
> In a domain controlled by a single organization (typically the set of ASs under control of the same operator) a packet enters at the edge where the ingress node applies a policy resulted into an additional outer ipv6 header that may or may not contain an extension header. Bottom line, the outer header means that now, it is a NEW packet, originated by the ingress node, with SA/DA representing the nodes that are inside the operator domain. Therefore, we can say that this new packet (formed by an outer header and encapsulated original packet) is now owned by the operator and whatever the operator does with this packet:
> 
> . The packet MUST leave the operator network in the exact same shape/format as it entered (i.e.: outer encapsulation removed).
> . The outer header MAY change while in transit in the operator’s domain. Moreover, a header MAY be inserted while inside the operator’s domain (knowing that outer header and any other inserted header would be removed at egress). This means that an SRH MAY be inserted at the same time the outer header is added but it can also be that the ingress adds the outer header and some other node inserts an SRH (e.g.: fast reroute within operator’s infrastructure).
> . While in transit, the operator network must handle aspects like MTU properly, taking into account the increased size of the packet.
DV: I concur with this explanation & needs.
> 
> Originally RFC2460 stated that only the source of the packet is entitled to add an EH. Now we’re going to propose that the source “domain” of the packet is allowed to insert EHs. The source domain being the set of nodes (including the ingress node adding the outer header) under common administration. This also implies that when the packet leaves the domain, it must recover its original format/shape.
> 
> In order to have a more productive discussion, we are writing a draft on header insertion that will be submitted as soon as the windows re-open (during ietf week).
> 
> In the mean time, I think it is way too premature to come to conclusion on what text should be used for RFC2460bis and I recommend that the current text is left unchanged until we figured out what to do with EH insertion.

DV: I support this recommendation, especially that there will be a document submitted in 2 weeks, stated here, that will add more context. Which position the WG good discussion.

> Thanks.
> s.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------