RE: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

Vasilenko Eduard <vasilenko.eduard@huawei.com> Fri, 11 June 2021 18:28 UTC

Return-Path: <vasilenko.eduard@huawei.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 AC6A83A0E0E for <ipv6@ietfa.amsl.com>; Fri, 11 Jun 2021 11:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 VzZvnedzmvWX for <ipv6@ietfa.amsl.com>; Fri, 11 Jun 2021 11:28:37 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033503A0E0B for <ipv6@ietf.org>; Fri, 11 Jun 2021 11:28:37 -0700 (PDT)
Received: from fraeml740-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4G1q1P5Dvqz6F96H for <ipv6@ietf.org>; Sat, 12 Jun 2021 02:21:45 +0800 (CST)
Received: from msceml704-chm.china.huawei.com (10.219.141.143) by fraeml740-chm.china.huawei.com (10.206.15.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 11 Jun 2021 20:28:32 +0200
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml704-chm.china.huawei.com (10.219.141.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 11 Jun 2021 21:28:29 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.2176.012; Fri, 11 Jun 2021 21:28:29 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Tom Herbert <tom@herbertland.com>
CC: "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: New Version Notification for draft-hinden-6man-hbh-processing-01.txt
Thread-Topic: New Version Notification for draft-hinden-6man-hbh-processing-01.txt
Thread-Index: AQHXXn73aHmqKIlNK0iyWDK9rp6HY6sOE9yAgAAba4CAAHGugIAAEfmAgABtvJA=
Date: Fri, 11 Jun 2021 18:28:29 +0000
Message-ID: <0d3be0c9c2eb486b820bb3ecd2fd3383@huawei.com>
References: <162265842779.4095.2393609365780372735@ietfa.amsl.com> <E5A31CCD-104D-4B92-9730-4FCFBF191F46@gmail.com> <17adf4b21d428d051e390574e976e3f61aee33c0.camel@edgeuno.com> <CALx6S368ZavS5Ggv28XB1mW41sZML0Vv=DvBPMooFFhbWdpKUg@mail.gmail.com> <4e1c6c6a-1512-755e-a4e5-723e83b74b4c@gmail.com> <d2847bc077d1775b07642587758962dcb80e7690.camel@edgeuno.com> <F6288093-7141-4190-8541-DF96C0DE0CF7@cisco.com> <7c7a73ba2730696e40acd65c44036d2c0a17f9c2.camel@edgeuno.com> <CO1PR11MB48812CF3CB24EC9A3B18C453D8349@CO1PR11MB4881.namprd11.prod.outlook.com> <5f733909279347cbb8bd9de5dec29adf@huawei.com> <CALx6S352C9vag=ivyi7+SpD6Nmqi15hFsEru_i8Z_Hn5OBw6mw@mail.gmail.com>
In-Reply-To: <CALx6S352C9vag=ivyi7+SpD6Nmqi15hFsEru_i8Z_Hn5OBw6mw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.202.165]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/nxVrHIgXP6mjCjS1CjQZlMZxrcE>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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, 11 Jun 2021 18:28:43 -0000

Hi Tom,
I was probably not clear.
I do not propose to develop something special for "closed domains". The spec should be unified.
I am just doubtful that it makes sense to look at what is going on the public Internet. It does not matter.
It makes sense to look for advanced functionality to closed domains only.
One Carrier could be a valid use case too.
PS: I do not see any trouble now for 1 carrier to activate anything from EHs (including HbH). After Carrier would pay the price.
Eduard
-----Original Message-----
From: Tom Herbert [mailto:tom@herbertland.com] 
Sent: Friday, June 11, 2021 5:50 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: ipv6@ietf.org
Subject: Re: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

On Fri, Jun 11, 2021 at 4:13 AM Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
>
> Hi all,
> I was silent reading this discussion because it is pretty much a useless exercise.
> 95% of Telco traffic is the Best Effort (nobody pays a penny for additional services).
> Additional headers processing has the cost:
> - develop a new feature
> - test a new feature
> - implement a new feature
> - support a new feature
> And accept the responsibility for additional different risks (security, performance, interoperability).
>
> Never-ever EH would work on the Internet till the Telco business model would change. Dump pipe does not need it.
> It is true for half of the latest development in the IETF (especially for anything QoS-related).
>
> Hence, fancy IPv6 functionality should be convenient only for closed domains.
> It is primarily Enterprises where business case calculation for everything activated is not so strict.
> Enterprises have much more traffic that is considered important for many reasons.
>
> IMHO:
> HbH in its current specification is perfectly fine for a closed domain.

> If you would change it in any way that was discussed here - it would be still fine for a closed domain.
> Of course, I could be wrong here because IPv6 popularity in the Enterprise is still close to 0%.
> Hence, we do not know what Enterprise would need when they move to IPv6.
> Unfortunately, such discussion is not popular here. It is primarily here about how to fix what is not possible to fix.
>
Eduard,

The only thing we can possibly fix in this forum are the protocol specifications for IPv6. To that end, there's only one specification for IPv6 which applies to all use cases of the protocol in that the protocol does not distinguish between teco network, home networks, enterprise networks, the Internet as a whole, or closed networks (bifurcating the standard specifications between limited domains and the open Internet has thus far been rejected). Given this context of the WG, it is reasonable to try to update the protocols to address the apparent gap wrt to extension headers between the protocol standards and what is widely deployed. This is precisely what this draft and this discussion is attempting to do.

Tom

> PS: it makes sense to drop testing "best effort pipe" for fancy services for not to disappoint ourselves.
> Eduard
> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Pascal Thubert 
> (pthubert)
> Sent: Friday, June 11, 2021 9:59 AM
> To: Fernando Gont <fernando.gont=40edgeuno.com@dmarc.ietf.org>
> Cc: gorry@erg.abdn.ac.uk; ipv6@ietf.org; bob.hinden@gmail.com
> Subject: RE: New Version Notification for 
> draft-hinden-6man-hbh-processing-01.txt
>
> Hello Fernando
>
> How that that so different from the PMTUD problem? When the route changes, the end-to-end MTU may change too.
>
> Similarities:
>
> - there are places were you won't even try to guess; 6LoWPAN decided to use an MTU of 1280 and will not try PMTUD; for HbH, as Brian suggests, it might be that the Internet at large is the wrong place to try it.
>
> - there are flows and use cases that can really benefit from it, so keeping the lowest common denominator in all circumstances seems utterly wasteful.
>
> - the concept of domain that Brian mentioned is intuitively the thing we're after. But the domain scope is not always very clear. So exploration can help.
>
> Note that adding a HbH OH in an existing PMTUD / MSS exploration does not require a change in the intermediate routers and middle boxes. We do not need an RFC for that, anyone can try it already.
>
> draft-ietf-6man-mtu-option seems to serve the purpose as a side effect, though clarifying that other options can be placed in the HbH OH to experiment whether those options are also supported along the path seems like a good idea, e.g., for options with the leftmost bit set to 1 (act = 0b1O or act = 0b11).
>
> Keep safe;
>
> Pascal
>
> > -----Original Message-----
> > From: Fernando Gont <fernando.gont=40edgeuno.com@dmarc.ietf.org>
> > Sent: vendredi 11 juin 2021 7:21
> > To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> > Cc: brian.e.carpenter@gmail.com; gorry@erg.abdn.ac.uk; 
> > bob.hinden@gmail.com; ipv6@ietf.org; tom@herbertland.com
> > Subject: Re: New Version Notification for
> > draft-hinden-6man-hbh-processing- 01.txt
> >
> > Hi, Pascal,
> >
> > On Fri, 2021-06-11 at 05:00 +0000, Pascal Thubert (pthubert) wrote:
> > > This might need a solution be similar to the MTU problem; e.g., 
> > > during PMTUD a node might add the HbH Options that it needs to 
> > > check that the options make it through…
> >
> > Aside from a bunch of other evil details:
> >
> > WHat if, say, you employ this solution at, say, connection- 
> > establishment time, find that EHs actually "work" towards your 
> > destination, but them, sometime later, the path to your 
> > destinationchanges, and you find out that EHs no longer work?
> >
> >      Abort the transaction/connections?
> >      "Migrate" from EH-based mechansim to the fall back mechanism?
> >      Anything else?
> >
> > What about the impact on e.g. RTT for connection-establishment? What 
> > about the complexity of the mechanism? How many bugs/vulns before 
> > every implementation gets it right?
> >
> > Truth #3 of https://datatracker.ietf.org/doc/html/rfc1925 comes to mind...
> >
> > Thanks!
> >
> > Regards,
> > --
> > Fernando Gont
> > Director of Information Security
> > EdgeUno, Inc.
> > PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
> >
> >
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------