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

From: Ron Bonica <[email-masked]>
Date: Wed, 2 Jun 2021 18:11:24 +0000

Folks,

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.

                                                                                                                          Ron

Juniper Business Use Only

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Jun 2021 15:20:43 +1200

Hi,

My opinion on adoption is at the end of my comments.

Clearly, this is interesting work. What I am really not sure about is whether the ideal publication method is as an RFC. (And yes, I was a co-author of RFC6036, and I'm not sure that was ideal either.) So I have a question for the authors:

Did you consider publishing this work in a more "traditional" format such 
as an IEEE or ACM journal?

If it stays as a draft RFC, I think one important fix is to look carefully for any phrase that has a marketing "smell" to it, and delete it. There's an example right in the Abstract:

"This means that the networking industry is selecting IPv6 for the future."

Just delete it and the whole document becomes more serious.

In the Introduction:

"This testifies that most of the industry players have decided to invest and deploy IPv6 in large-scale."

Adds no technical information. Delete it. If you want to affect management attitudes to investing in IPv6, an RFC is the wrong place to do it. We do better in the IETF if we stick to technical issues and hard data.

Speaking of hard data, in section 6 "IPv6 incentives" I see:

"There are example of governments already adopting policies to encourage IPv6 utilization or enforce increased security on IPv4."

Please give references for more examples. US & China is a good start, but 
only a start.

Section 7 "Call for action" needs a lot of work IMHO. Firstly, it isn't at all clear who is asked to do what. For each topic, this should be laid out very clearly: we suggest that X needs to do A, B and C.

Secondly, there are just too many words in section 7. I don't thank many people will read this section closely. So in clarifying it as just suggested, I think a lot of words should be deleted too.

Thirdly, there are topics in here that I think the IETF is not qualified to give advice on. I alerted on (for example):

"The problem may be that of "First Mover Disadvantage".... " (the whole paragraph).

"7.1.6.  Government and Regulators" (the whole sub-section).

We do technical stuff much better than we do business or political stuff.

I tend to believe that if this is to be an RFC, Section 7 should be limited to what the IETF should do, and what manufacturers and operators should do *technically*.

****************

Now, my opinion about adoption. I think we should definitely adopt the topic, and this draft is a good start with a lot of data. But I would like to see the scope and the call for action limited to strictly technical issues where we are competent.

Regards,
    Brian

Regards
   Brian Carpenter

On 03-Jun-21 06:11, Ron Bonica wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Giuseppe Fioccola <[email-masked]>
Date: Thu, 3 Jun 2021 06:08:21 +0000

Hi Brian,
Thanks for the support and for the review.
We will definitely address your suggestions in the next version.
Please find my answers inline tagged as [GF].

Regards,

Giuseppe

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Thursday, June 3, 2021 5:21 AM
To: Ron Bonica <[email-masked]>; [email-masked]
Subject: Re: [v6ops] Call For Adoption: draft-ietf-v6ops-ipv6-deployment

Hi,

Did you consider publishing this work in a more "traditional" format such as an IEEE or ACM journal?

[GF]: We submitted a paper to NoF 2021 but with a different content (less statistics, no surveys, more details on the transition technologies). I believe that it is good to have an RFC on the global deployment status of IPv6 and this also seems in line with the V6OPS charter. Indeed the main objective of our draft is to report the surveys from network operators and enterprises in order to identify the common open issues and challenges and therefore, make the community aware of them. So this informational document on the global picture of IPv6 can be considered a starting point to stimulate more inputs from the IETF on the points emerged from the surveys among operators/enterprises (e.g. IPv6 performance, IPv6 security,...)

[GF]: Sure, will do.

In the Introduction:

[GF]: Agree, I will delete. We already tried to polish the draft from this perspective but sometimes you forgot something.

Please give references for more examples. US & China is a good start, but only a start.

[GF]: It is ok. Jordi already provided more references in an offline discussion. We will revise and add in the next revision.

[GF]: This section includes mainly the challenges that emerged from the surveys. Maybe we can also consider to change the title from "Call for action" to "Common IPv6 challenges". The key message for each topic can certainly be highlighted, but we would avoid recommendations since it is an Informational document.

[GF]: Good suggestion. I will revise. Less words to make the message more effective.

[GF]: I think we can revise and omit the considerations that are not in the IETF scope.

****************

Regards,
    Brian

Regards
   Brian Carpenter

---

From: Gábor LENCSE <[email-masked]>
Date: Fri, 4 Jun 2021 10:17:01 +0200

Dear Ron,

I have found this daft useful and I support its adoption.

Unfortunately, I do not have time to review it now, but I have added it 
to my task list.

Best regards,

Gábor

2021.06.02. 20:11 keltezéssel, Ron Bonica írta:
>
> Folks,
>
> 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.
>
>                                                                       Ron
>
>

---

From: Xipengxiao <[email-masked]>
Date: Fri, 4 Jun 2021 09:19:42 +0000

Hi Folks,

I also support the adoption of this draft, as it provides many useful data/information/advices that some people are not aware of. It will help to convince more people to adopt IPv6.

XiPeng

From: v6ops [mailto:[email-masked]] On Behalf Of Gábor LENCSE
Sent: Friday, June 4, 2021 10:17 AM
To: [email-masked]
Subject: Re: [v6ops] Call For Adoption: draft-ietf-v6ops-ipv6-deployment

Dear Ron,

Unfortunately, I do not have time to review it now, but I have added it to my task list.

Best regards,

Gábor

                                                                                                                          Ron

v6ops mailing list

[email-masked]<mailto:[email-masked]>

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 8 Jun 2021 10:37:04 +0100

> 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

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 8 Jun 2021 15:41:37 +0000

Hi Nick,
Thanks for sharing your opinion.
First of all, let me clarify the scope of this document since it seems you missed it. An RFC on the global deployment status of IPv6 is in line with the V6OPS charter and this draft aims to update old IETF RFCs on IPv6 deployment such as RFC6036, RFC7381, RFC6883. 
In this regard, the surveys from network operators and enterprises are reported in order to identify common open issues and challenges and therefore, make the community aware of them and stimulate more inputs. 
We know that the document can be improved but it can be considered a good starting point.
I would really appreciate more constructive comments.

Please find my specific answers inline as [GF].

Regards,

Giuseppe

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Nick Hilliard
Sent: Tuesday, June 8, 2021 11:37 AM
To: Ron Bonica <rbonica=[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] Call For Adoption: draft-ietf-v6ops-ipv6-deployment

> 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.

[GF]: As co-author of ETSI White Paper 35, let me disagree indeed there are a lot of differences. There is no survey in the ETSI WP 35. The ETSI WP 35 reports the statistics on the transition technologies based on public research. In this draft these statistics are not copied but referred. There is a big difference between "copy" and "reference". The polls among operators and enterprises and the relative findings are reported only in this draft. 

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.

[GF]: Regarding the methodology for the survey, it is just a questionnaire (see Appendix of the draft) and we can surely add more details on this. Regarding the sample size of the survey, note that we are considering 50 relevant operators. If we calculate the total number of customers served by these operators, you can immediately realize that the results are not anecdotal. We will add this information in the next version.

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.

[GF]: We are thinking to change the title from "Call for action" to "Common IPv6 challenges". I agree that the list looks disparate, but our idea is to make this section more effective and highlight only the key message for each topic. Note that this list comes from the inputs from the IETF community. If you look at all the versions of this document, you can see how the Call for action section was extended over time due to the comments received.

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.

[GF]: The data are collected from relevant references (e.g. ISOC, RIPE, APNIC,...). We tried to avoid data that cannot be verified. Could you please be more specific so we can improve?

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.

[GF]: As said, this section will be reviewed to be more effective. Agree, it can be considered a starting point and inspire even more than one document on the different topics.

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.

[GF]: An operator will not give you a lot of detail. There are some information that operators do not share. And again, note that the sample size is representative. We can make the calculation of the total customers served by the operators/enterprises which participated in the poll.

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.

[GF]: I agree that the document needs to be improved but I disagree that this is not in scope of V6OPS WG. As a matter of fact there was already a relevant consensus in the previous call for comments/adoption (please see the mail archive) and a large majority finds this work useful.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 8 Jun 2021 17:30:07 +0100

Giuseppe Fioccola wrote on 08/06/2021 16:41:
> [GF]: I agree that the document needs to be improved but I disagree
> that this is not in scope of V6OPS WG.

The issue is not whether the content area is in scope for v6ops (clearly 
it is), just that there were enough fundamental problems with the 
structure and content of the document such that it isn't appropriate for 
adoption at the moment.  Specifically, 1. there seem to be three main 
strands in the document which don't fit together well, and 2. there's no 
beginning, middle and end to the document - after reading the document, 
I didn't have a clear picture of what it was trying to say.

I can't see a way of fixing this without complete restructuring from the 
beginning.  Maybe the individual strands could be made to work as 
standalone documents?  Possibly if the document started out with a 
formal design and was rewritten from scratch to fit inside this design, 
it would become more cohesive?  Either way, these are issues that need 
to be sorted before the document is adopted rather than after.

Nick

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 8 Jun 2021 17:23:03 +0000

Hi Nick,
The goal of the adoption is also to understand if the WG considers this work useful and in scope. In this way the WG can start to spend more effort and resources on it. As a matter of fact, the WG adoption does not necessarily mean that the document will be published as RFC as it is now. It can be changed in the future. Also, there are several examples of adopted drafts that did not become RFCs.

Having said that, we can surely restructure the draft and improve its readability after the possible adoption. Note that in the last version we made a lot of changes to address the high number of inputs and, this may also have affected the fluency of the text. We are open to collaborate and it would be great if you have specific suggestions on a possible new document structure.

Regards,

Giuseppe

-----Original Message-----
From: Nick Hilliard <[email-masked]> 
Sent: Tuesday, June 8, 2021 6:30 PM
To: Giuseppe Fioccola <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>; [email-masked]
Subject: Re: [v6ops] Call For Adoption: draft-ietf-v6ops-ipv6-deployment

> that this is not in scope of V6OPS WG.

The issue is not whether the content area is in scope for v6ops (clearly it is), just that there were enough fundamental problems with the structure and content of the document such that it isn't appropriate for adoption at the moment.  Specifically, 1. there seem to be three main strands in the document which don't fit together well, and 2. there's no beginning, middle and end to the document - after reading the document, I didn't have a clear picture of what it was trying to say.

I can't see a way of fixing this without complete restructuring from the beginning.  Maybe the individual strands could be made to work as standalone documents?  Possibly if the document started out with a formal design and was rewritten from scratch to fit inside this design, it would become more cohesive?  Either way, these are issues that need to be sorted before the document is adopted rather than after.

Nick

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 8 Jun 2021 13:36:10 -0400

While neither you nor I speak for the WG chairs, my understanding of the 
expectation for adoption has an important additional aspect you do not 
mention below.

That is that in addition to being a topic that is within scope and 
something the WG desires to work on, the given document is seen by the 
WG participants as a good starting points for the work.

Nick's comments seem to my reading to saay that he does not see the 
document, in it's current form, as a good starting point for the working 
group effort.  That seems to me to be a legitimate concern to raise 
during an adoption call.

Yours,
Joel

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 8 Jun 2021 18:02:23 +0000

Hi Joel,
Agree with you. These are the aspects to consider for the adoption.
I highlighted the first aspect since Nick mentioned only the second aspect.
And many people already expressed their support on both aspects.

Thanks,

Giuseppe

-----Original Message-----
From: Joel M. Halpern <[email-masked]> 
Sent: Tuesday, June 8, 2021 7:36 PM
To: Giuseppe Fioccola <[email-masked]>; Nick Hilliard <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] Call For Adoption: draft-ietf-v6ops-ipv6-deployment

While neither you nor I speak for the WG chairs, my understanding of the expectation for adoption has an important additional aspect you do not mention below.

That is that in addition to being a topic that is within scope and something the WG desires to work on, the given document is seen by the WG participants as a good starting points for the work.

Nick's comments seem to my reading to saay that he does not see the document, in it's current form, as a good starting point for the working group effort.  That seems to me to be a legitimate concern to raise during an adoption call.

Yours,
Joel

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 9 Jun 2021 03:48:12 -0400

As co-author I support WG adoption of this draft.

This draft provides valuable data on IPv6 deployments in all vertical
markets as well as challenges with transition to IPv6.

Thank you

Gyan

On Tue, Jun 8, 2021 at 2:03 PM Giuseppe Fioccola <
[email-masked]> wrote:

> something the WG desires to work on, the given document is seen by the WG
> participants as a good starting points for the work.
>
> group effort.  That seems to me to be a legitimate concern to raise during
> an adoption call.
>
> Yours,
> Joel
>
> > The goal of the adoption is also to understand if the WG considers this
> work useful and in scope. In this way the WG can start to spend more effort
> and resources on it. As a matter of fact, the WG adoption does not
> necessarily mean that the document will be published as RFC as it is now.
> It can be changed in the future. Also, there are several examples of
> adopted drafts that did not become RFCs.
> >
> > Having said that, we can surely restructure the draft and improve its
> readability after the possible adoption. Note that in the last version we
> made a lot of changes to address the high number of inputs and, this may
> also have affected the fluency of the text. We are open to collaborate and
> it would be great if you have specific suggestions on a possible new
> document structure.
> >
> > Regards,
> >
> > Giuseppe
> >
> >
> it is), just that there were enough fundamental problems with the structure
> and content of the document such that it isn't appropriate for adoption at
> the moment.  Specifically, 1. there seem to be three main strands in the
> document which don't fit together well, and 2. there's no beginning, middle
> and end to the document - after reading the document, I didn't have a clear
> picture of what it was trying to say.
> >
> standalone documents?  Possibly if the document started out with a formal
> design and was rewritten from scratch to fit inside this design, it would
> become more cohesive?  Either way, these are issues that need to be sorted
> before the document is adopted rather than after.
> >
> > Nick
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 9 Jun 2021 04:00:16 -0400

Hi Nick

If you have certain sections within the draft that need rearrangement or
restructuring so the draft flows better for readability, we can certainly
take your comments as well as any others and update the draft well before
the end of the adoption call as well so the draft is in a reasonable state
to be taken on by the WG once adopted.

Please let us know the details.

We really appreciate yours as well as others feedback to help improved and
advance the document.

Kind Regards

Gyan

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: <[email-masked]>
Date: Fri, 11 Jun 2021 06:17:31 +0000

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:[email-masked]] De la part de Nick
> Hilliard
> Envoyé : mardi 8 juin 2021 11:37
> À : Ron Bonica <rbonica=[email-masked]>
> Cc : [email-masked]
> Objet : Re: [v6ops] Call For Adoption: draft-ietf-v6ops-ipv6-
> deployment
> 
> 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 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
> 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
> 

_________________________________________________________________________________________________________________________

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.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 11 Jun 2021 02:34:37 -0400

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 <[email-masked]> wrote:

> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: <[email-masked]>
Date: Fri, 11 Jun 2021 06:56:56 +0000

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.).

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:[email-masked]]
Envoyé : vendredi 11 juin 2021 08:35
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : Nick Hilliard <[email-masked]>; Ron Bonica <rbonica=[email-masked]>; [email-masked]
Objet : Re: [v6ops] Call For Adoption: draft-ietf-v6ops-ipv6-deployment

Hi Med

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Cheers,
Med

> De : v6ops [mailto:[email-masked]<mailto:[email-masked]>] De la part de Nick
> Hilliard
> À : Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>>
> Cc : [email-masked]<mailto:[email-masked]>

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 11 Jun 2021 10:21:00 +0200

Le 11/06/2021 à 08:56, [email-masked] 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:[email-masked]]
> *Envoyé :* vendredi 11 juin 2021 08:35
> *À :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> *Cc :* Nick Hilliard <[email-masked]>; Ron Bonica 
> <rbonica=[email-masked]>; [email-masked]
> *Objet :* Re: [v6ops] Call For Adoption: draft-ietf-v6ops-ipv6-deployment
> 
> Hi Med
> 
> On Fri, Jun 11, 2021 at 2:18 AM <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi all,
> 
>      > De : v6ops [mailto:[email-masked]
>     <mailto:[email-masked]>] De la part de Nick
>      > Hilliard
>      > Cc : [email-masked] <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/v6ops>
> 
>     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,
>     This message and its attachments may contain confidential or
>     privileged information that may be protected by law;
>     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.
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> -- 
> 
> /Network Solutions Architect /
> 
> /Email [email-masked] <mailto:[email-masked]>/
> 
> /M 301 502-1347/
>

---

From: Giuseppe Fioccola <[email-masked]>
Date: Fri, 11 Jun 2021 08:41:55 +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 <[email-masked]> On Behalf Of Alexandre Petrescu
Sent: Friday, June 11, 2021 10:21 AM
To: [email-masked]
Subject: Re: [v6ops] Call For Adoption: draft-ietf-v6ops-ipv6-deployment

Le 11/06/2021 à 08:56, [email-masked] a écrit :
> 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

> This can be for example to develop methods in bmwg for better 
> assessing performance.
> 
> Cheers,
> 
> Med
> 
> *De :*Gyan Mishra [mailto:[email-masked]] *Envoyé :* vendredi 
> 11 juin 2021 08:35 *À :* BOUCADAIR Mohamed INNOV/NET 
> <[email-masked]> *Cc :* Nick Hilliard <[email-masked]>; 
> Ron Bonica <rbonica=[email-masked]>; [email-masked] 
> 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
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> 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.
> 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

---

From: Gabor LENCSE <[email-masked]>
Date: Fri, 11 Jun 2021 14:37:11 +0200

Hi Med, All,

On 6/11/2021 8:56 AM, [email-masked] wrote:
[...]
>  This can be for example to develop methods in bmwg for better 
To that end, our draft titled "Benchmarking Methodology for Stateful 
NATxy Gateways using RFC 4814 Pseudorandom Port Numbers"  ( 
https://datatracker.ietf.org/doc/html/draft-lencse-bmwg-benchmarking-stateful 
) is now under discussion at the BMWG mailing list.

Any comments are welcome!

Best regards,

Gábor

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 11 Jun 2021 09:35:23 -0400

Hi Med,

Responses in-line

Many thanks

Gyan

On Fri, Jun 11, 2021 at 2:56 AM <[email-masked]> wrote:

> Gyan> Ack I think what we need to do is clearly document issues and then
> recommendations but without using biased opinions and create a list
>
of actionable recommendations at the end of section 7.
Also section 7 maybe change the name “call for action” to “IPv6 transition
> challenges”.
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.).
>
> Gyan> Agreed.
>
> (hopefully) provide actionable recommendations to make things better. This
> can be for example to develop methods in bmwg for better assessing
> performance.
>
> Gyan> This draft has a lot of content but now we have to try to make it
> useful content by providing an actionable list at the end that could help
> IPv6 transition for operators.
>

Gyan> Thanks for all the feedback

> Cheers,
>
> Med
>
>
>
> *De :* Gyan Mishra [mailto:[email-masked]]
> *Cc :* Nick Hilliard <[email-masked]>; Ron Bonica <rbonica=
> [email-masked]>; [email-masked]
>
>
> *Network Solutions Architect *
>

*Gyan Mishra*

*M 301 502-1347*

---

From: "Dale W. Carder" <[email-masked]>
Date: Mon, 14 Jun 2021 10:57:10 -0500

Thus spake Nick Hilliard ([email-masked]) on Tue, Jun 08, 2021 at 10:37:04AM +0100:
> operator survey with some results and the "Call for action" section, a set
> of suggestions on how to improve matters.

That was my observation from last October as well, and I think it still 
applies for me as I take another read pass through it.
https://mailarchive.ietf.org/arch/msg/v6ops/Wokx6bH3Xvf0sAwqV3Q7JhGRgME/

from Nick,
> 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.

I would agree, but to pull this off effectively, I would expect that
there would be adequate citations and references to back up the claims.

In it's current form, I still don't see the purpose of the document as
abundantly clear, and I don't see this draft progressing through the WG
in any sort of timely manner.  Perhaps splitting it up could help but I
am not sure.

Dale

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 14 Jun 2021 18:35:26 +0000

Hi Dale,
Thanks for your feedback.
Please find my answers inline tagged as [GF].
Regards,

Giuseppe

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Dale W. Carder
Sent: Monday, June 14, 2021 5:57 PM
To: Nick Hilliard <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>; [email-masked]
Subject: Re: [v6ops] Call For Adoption: draft-ietf-v6ops-ipv6-deployment

Thus spake Nick Hilliard ([email-masked]) on Tue, Jun 08, 2021 at 10:37:04AM +0100:
> > draft-ietf-v6ops-ipv6-deployment. Please post messages expressing 
> > your position on adoption and rationale by 6/16/2021.
> 

That was my observation from last October as well, and I think it still applies for me as I take another read pass through it.
https://mailarchive.ietf.org/arch/msg/v6ops/Wokx6bH3Xvf0sAwqV3Q7JhGRgME/

[GF]: As co-author of ETSI WP 35, I disagree. To avoid repeating myself, I already highlighted in the two emails below the differences:
https://mailarchive.ietf.org/arch/msg/v6ops/DTM96W0CyA6n-6NIIw5Iaiwh9Cg/
https://mailarchive.ietf.org/arch/msg/v6ops/IxijU1psR6uqTDYJDcMfbValUg0/

from Nick,
> for / impediments to IPv6 adoption.

I would agree, but to pull this off effectively, I would expect that there would be adequate citations and references to back up the claims.

[GF]: As said when answering the previous email, we would thoroughly revise this section and, consequently, change the title into "common challenges of the IPv6 transition". Since this section was extended over time due to the comments from the IETF community, our idea is to make it more effective and highlight only the key message for each topic.  

In it's current form, I still don't see the purpose of the document as abundantly clear, and I don't see this draft progressing through the WG in any sort of timely manner.  Perhaps splitting it up could help but I am not sure.

[GF]: Let me clarify the purpose of the document. The authors would like to describe the current status of the IPv6 deployment globally. The idea is to report both public data and statistically meaningful surveys among operators/enterprises. All this allows to identify the common challenges and therefore, make the community aware and stimulate more contribution. Considering the concerns, it seems not clear. We can surely restructure the draft (sometimes less is more) and improve its readability in the next versions. In the last version we made a lot of changes to address the number of inputs from the community and, this may also have affected the clarity.

Dale

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 15 Jun 2021 03:30:11 +0000

Some brief comments in support of this Draft.

As an enterprise operator,  we need more information such as contained in this document.   As a whole, we are NOT moving in the IPv6 direction.   INMO this unfortunate.  

The primary reasons appear to be. 
 
* Lack of knowledge and information about IPv6.
* Not being aware of technical or business reasons to deploy IPv6.
* If/when we deploy, not knowing where the major challenges will be nor how to deal with them. 
* No experience with transition technologies 

This draft addresses all those areas and more.  

If we want enterprises to successfully move to IPv6, and I think/hope we all do, then documents such as this will help greatly.  
I hope the working group supports this draft and can collectively help make it even better than it already is, as we enterprises need all the assistance we can get in these areas.  

As a side benefit,  drafts such as this serve to help IETF better understand enterprise environments and perspectives in general, where major disconnects and misunderstandings exist today.  

Thanks

Mike

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Giuseppe Fioccola
Sent: Monday, June 14, 2021 2:35 PM
To: Dale W. Carder <[email-masked]>; Nick Hilliard <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>; [email-masked]
Subject: Re: [v6ops] Call For Adoption: draft-ietf-v6ops-ipv6-deployment

[External email]

Hi Dale,

Giuseppe

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Dale W. Carder
Sent: Monday, June 14, 2021 5:57 PM
To: Nick Hilliard <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>; [email-masked]
Subject: Re: [v6ops] Call For Adoption: draft-ietf-v6ops-ipv6-deployment

from Nick,

Dale

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.

This message was secured by Zix(R).

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 15 Jun 2021 00:40:29 -0400

Thanks Michael!!

+1

As a solutions architect and protocol designer for Verizon, a Tier 1
Service Provider, fully IPv6 enabled, with one of the largest enterprise
networks in the world that is fully IPv6 deployed for over 10 years, as
co-author I support adoption and advancement of this draft.

This draft provides crucial industry feedback and deployment challenges
that are faced by operators for both enterprises & service providers, as
well as feedback on successful deployment strategies to aid in the further
proliferation of IPv6 worldwide.  I will be providing some additional
feedback on both service provider and enterprise side both lessons learned
and success stories to help improve the draft.

As Giuseppe has mentioned we are working on revising the draft, coalescing
all the feedback provided thus far during the adoption call.

Kind Regards

Gyan

On Mon, Jun 14, 2021 at 11:30 PM Ackermann, Michael <[email-masked]>
wrote:

> Some brief comments insupport of this Draft.
>
> As an enterprise operator,  we need more information such as contained in
> this document.   As a whole, we are NOT moving in the IPv6 direction.
>  INMO this unfortunate.
>
> If we want enterprises to successfully move to IPv6, and I think/hope we
> all do, then documents such as this will help greatly.
> I hope the working group supports this draft and can collectively help
> make it even better than it already is, as we enterprises need all the
> assistance we can get in these areas.
>
> As a side benefit,  drafts such as this serve to help IETF better
> understand enterprise environments and perspectives in general, where major
> disconnects and misunderstandings exist today.
>
> Thanks
>
> Mike
>
>
> [GF]: As co-author of ETSI WP 35, I disagree. To avoid repeating myself, I
> already highlighted in the two emails below the differences:
> I would agree, but to pull this off effectively, I would expect that there
> would be adequate citations and references to back up the claims.
>
> [GF]: As said when answering the previous email, we would thoroughly
> revise this section and, consequently, change the title into "common
> challenges of the IPv6 transition". Since this section was extended over
> time due to the comments from the IETF community, our idea is to make it
> more effective and highlight only the key message for each topic.
>
> abundantly clear, and I don't see this draft progressing through the WG in
> any sort of timely manner.  Perhaps splitting it up could help but I am not
> sure.
>
> [GF]: Let me clarify the purpose of the document. The authors would like
> to describe the current status of the IPv6 deployment globally. The idea is
> to report both public data and statistically meaningful surveys among
> operators/enterprises. All this allows to identify the common challenges
> and therefore, make the community aware and stimulate more contribution.
> Considering the concerns, it seems not clear. We can surely restructure the
> draft (sometimes less is more) and improve its readability in the next
> versions. In the last version we made a lot of changes to address the
> number of inputs from the community and, this may also have affected the
> clarity.
>
>
> Dale
>
> 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.
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*