Re: [v6ops] Call For Adoption: draft-ietf-v6ops-ipv6-deployment

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Fri, 11 June 2021 08:42 UTC

Return-Path: <giuseppe.fioccola@huawei.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5943A2F1F for <v6ops@ietfa.amsl.com>; Fri, 11 Jun 2021 01:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EGPFYSUI0PIg for <v6ops@ietfa.amsl.com>; Fri, 11 Jun 2021 01:42:03 -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 A9EB13A2F16 for <v6ops@ietf.org>; Fri, 11 Jun 2021 01:42:02 -0700 (PDT)
Received: from fraeml715-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4G1YsV3NHYz6H7t3; Fri, 11 Jun 2021 16:29:02 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml715-chm.china.huawei.com (10.206.15.34) 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 10:41:55 +0200
Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2176.012; Fri, 11 Jun 2021 10:41:55 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] Call For Adoption: draft-ietf-v6ops-ipv6-deployment
Thread-Index: AddX2o4yss3lfV/vTNa0CJEcfHLKgAEXoVAAAI/nsoAAAJjigAAAx4cAAALvngAABGkjIA==
Date: Fri, 11 Jun 2021 08:41:55 +0000
Message-ID: <f4473289ea064fa3817f618f675e7f37@huawei.com>
References: <BL0PR05MB5316B21F3D035339CEE892F0AE3D9@BL0PR05MB5316.namprd05.prod.outlook.com> <7211c26d-5fe4-cf8a-f24a-afd9bb09eb64@foobar.org> <4668_1623392252_60C2FFFC_4668_93_1_787AE7BB302AE849A7480A190F8B9330353A88FB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CABNhwV2m-pRpibd5K=eAx93prtzBE7oKePoDGe4TBOMz7BLVRQ@mail.gmail.com> <19625_1623394618_60C3093A_19625_189_14_787AE7BB302AE849A7480A190F8B9330353A8939@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1483f67a-1ae8-7d8b-f32f-2d7195baf032@gmail.com>
In-Reply-To: <1483f67a-1ae8-7d8b-f32f-2d7195baf032@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.217.202]
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/v6ops/vK8Wgo6XirfMnvPGDVrc07g9Qdo>
Subject: Re: [v6ops] Call For Adoption: draft-ietf-v6ops-ipv6-deployment
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2021 08:42:08 -0000

Hi Med, Alex,
Thank you for pointing that out.
Regarding Section 7.3, in the first paragraph it is stated that "In some cases, IPv6 behaving worse than IPv4" and later that "cases exist where IPv6 is faster than IPv4". So we don't take a definite position.
Anyway we can surely revise this section in the next version to avoid any misunderstanding.
I fully agree that this section could be the boost to develop methods in BMWG for better assessing performance.

Regards,

Giuseppe

-----Original Message-----
From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Alexandre Petrescu
Sent: Friday, June 11, 2021 10:21 AM
To: v6ops@ietf.org
Subject: Re: [v6ops] Call For Adoption: draft-ietf-v6ops-ipv6-deployment



Le 11/06/2021 à 08:56, mohamed.boucadair@orange.com a écrit :
> Re-,
> 
> Thanks, Gyan.
> 
> The part I was referring to is basically what you to start discuss in 
> Section 7.3: Performance issues. Not even the call for action.
> 
> I would avoid statements such as “IPvX is faster than IPvY” (also 
> echoed in the draft) as things are in general more subtle than that. 
> Let alone that local tweaking may infer observed behaviors 
> (recommendation followed by a CPE, how the interconnection is achieved, etc.).

YEs, I fully agree.  The things are more subtle than simple statements, and the experiences should be told.

For my part, I am surprised how fast.com consistently reports higher speeds for my IPv6 connection of my CPE, since several months now.  I cant stop myself from saying to myself that in this particular case I do prefer IPv6.

Somebody else reported that netflix users in some country also benefit for better experience if they are on IPv6, at least since the covid times.

These are rare events.  In earlier times I was preferring IPv4 under other circumstances because it was faster (ping 8.8.8.8 reported 10 times lower RTT than the correspond IPv6 ping).

These kinds of statements should be qualified by more data, for example which operator, which box, which country.  Or maybe by other data.

Alex

> 
> The challenge of your draft is to extract ** technical issues ** and
> (hopefully) provide actionable recommendations to make things better. 
> This can be for example to develop methods in bmwg for better 
> assessing performance.
> 
> Cheers,
> 
> Med
> 
> *De :*Gyan Mishra [mailto:hayabusagsm@gmail.com] *Envoyé :* vendredi 
> 11 juin 2021 08:35 *À :* BOUCADAIR Mohamed INNOV/NET 
> <mohamed.boucadair@orange.com> *Cc :* Nick Hilliard <nick@foobar.org>; 
> Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>; v6ops@ietf.org 
> *Objet :* Re: [v6ops] Call For Adoption: 
> draft-ietf-v6ops-ipv6-deployment
> 
> Hi Med
> 
> Understood and we appreciate all the feedback to help improve the draft.
> 
> Myself as well as other authors have thoughts on how we can improve 
> the draft as it stands but we want to make sure we are in sync with 
> the WG feedback as to changes proposed.
> 
> Can you provide some details as to what you propose as to sections 
> that need to be shuffled and or verbiage that need improvement. Your 
> proposal may not be identical to Nicks so we would like to see yours 
> and Nicks as well as others and incorporate any and all feedback as 
> best we can to improve the draft.
> 
> Many thanks
> 
> Gyan
> 
> On Fri, Jun 11, 2021 at 2:18 AM <mohamed.boucadair@orange.com 
> <mailto:mohamed.boucadair@orange.com>> wrote:
> 
>     Hi all,
> 
>     Nick made valid points. I agree with many of them.
> 
>     I would extract only parts that identify/discuss issues/hurldes and
>     enrich them with some recommendations.
> 
>     Other material can be published in other forms better than an RFC.
> 
>     I don't support adopting with the current content.
> 
>     Cheers,
>     Med
> 
>      > -----Message d'origine-----
>      > De : v6ops [mailto:v6ops-bounces@ietf.org
>     <mailto:v6ops-bounces@ietf.org>] De la part de Nick
>      > Hilliard
>      > Envoyé : mardi 8 juin 2021 11:37
>      > À : Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org
>     <mailto:40juniper.net@dmarc.ietf.org>>
>      > Cc : v6ops@ietf.org <mailto:v6ops@ietf.org>
>      > Objet : Re: [v6ops] Call For Adoption: draft-ietf-v6ops-ipv6-
>      > deployment
>      >
>      > Ron Bonica wrote on 02/06/2021 19:11:
>      > > This message initiates a call for adoption on
>      > > draft-ietf-v6ops-ipv6-deployment. Please post messages expressing
>      > your
>      > > position on adoption and rationale by 6/16/2021.
>      >
>      > I'm struggling with this document. It looks like an aggregation of
>      > three separate things: a copy / rewording of chunks of ETSI White
>      > Paper 35, an operator survey with some results and the "Call for
>      > action" section, a set of suggestions on how to improve matters.
>      >
>      > Regarding the survey, no methodology was provided and the sample
>      > size was too small to infer statistical significance.  Survey
>      > results are potentially interesting, but the results in this case
>      > are anecdotal.
>      >
>      > The Call for Action consists of a disparate list of technical and
>      > policy issues, ranging from "Government and Regulators" to
>      > "Oversized IPv6 packets".  There is no clear indication of how any
>      > particular topic made it into this list, or why other topics may
>      > have been excluded.
>      >
>      > Overall the document doesn't sit together happily; it draws
>      > conclusions in different areas based on insufficient data; many
>      > topics are presented without enough depth to provide sufficient
>      > justification for the claims that are made; there are a lot of
>      > unattributed statistics which could be misinterpreted as data.  I
>      > would be concerned that if it were published, many of the statistics
>      > could be requoted elsewhere using this as a primary document, and as
>      > it stands, the data quality isn't good enough to justify this.
>      >
>      > The "Call for action" section has potential promise and would
>      > benefit from being moved to a separate document which discusses
>      > considerations for / impediments to IPv6 adoption.
>      >
>      > The operator poll needs examination in a separate document. There's
>      > insufficient detail at this point to work out whether there's enough
>      > material for an ID.
>      >
>      > The ID would be better to settle on a cohesive and well-defined set
>      > of goals and then cover those comprehensively rather than providing
>      > a sparse overview of a wide selection of disparate topics.  There is
>      > material in there which is potentially interesting, but there is no
>      > clear path from where the document currently is to making a
>      > publishable rfc.  So at the moment there isn't a basis for the WG to
>      > adopt the ID.
>      >
>      > Nick
>      >
>      > _______________________________________________
>      > v6ops mailing list
>      > v6ops@ietf.org <mailto:v6ops@ietf.org>
>      > https://www.ietf.org/mailman/listinfo/v6ops
>     <https://www.ietf.org/mailman/listinfo/v6ops>
> 
>     
> ______________________________________________________________________
> ___________________________________________________
> 
>     Ce message et ses pieces jointes peuvent contenir des informations
>     confidentielles ou privilegiees et ne doivent donc
>     pas etre diffuses, exploites ou copies sans autorisation. Si vous
>     avez recu ce message par erreur, veuillez le signaler
>     a l'expediteur et le detruire ainsi que les pieces jointes. Les
>     messages electroniques etant susceptibles d'alteration,
>     Orange decline toute responsabilite si ce message a ete altere,
>     deforme ou falsifie. Merci.
> 
>     This message and its attachments may contain confidential or
>     privileged information that may be protected by law;
>     they should not be distributed, used or copied without authorisation.
>     If you have received this email in error, please notify the sender
>     and delete this message and its attachments.
>     As emails may be altered, Orange is not liable for messages that
>     have been modified, changed or falsified.
>     Thank you.
> 
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org <mailto:v6ops@ietf.org>
>     https://www.ietf.org/mailman/listinfo/v6ops
>     <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> --
> 
> <http://www.verizon.com/>
> 
> *Gyan Mishra*
> 
> /Network Solutions Architect /
> 
> /Email gyan.s.mishra@verizon.com <mailto:gyan.s.mishra@verizon.com>/
> 
> /M 301 502-1347/
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops