Re: [v6ops] draft-vf-v6ops-ipv6-deployment

[Yannis Nikolopoulos <[e-mail]>]

Hello,

I can't speak for other operators, but we use netflow and BGP enrichment 
to analyse our traffic and its fairly trivial to break down IPv6/IPv4 
traffic going into / coming from CDNs/Caches/peers etc

regards,
Yannis

On 3/31/21 2:10 PM, Vasilenko Eduard wrote:
>
> Hi Jordi,
>
> The fact that something is going to CDN would not help you. Because 
> every CDN accelerates many Web sites.
>
> If the original Web site does not support it – then CDN could not help 
> here. It would continue to stream IPv4 for this request.
>
> For your question: “how much traffic could be IPv6 overnight” – we 
> need traffic per primary N Web sites.
>
> Sorry, the cheapest is cFlowd statistics for this. DPI is more expensive.
>
> Eduard
>
> *From:*v6ops [mailto:[e-mail]] *On Behalf Of *JORDI 
> PALET MARTINEZ
> *Sent:* Wednesday, March 31, 2021 1:44 PM
> *To:* [e-mail]
> *Subject:* Re: [v6ops] draft-vf-v6ops-ipv6-deployment
>
> Hi Eduard,
>
> All the customers I’ve worked with, even just for trainings, and also 
> operators that participated in “free/open trainings” for example in 
> RIR and NOG meetings, have answered this question “do you know how 
> much % of your traffic goes to CDNs/caches”? I’m talking about over 
> 75.000 engineers that I’ve trained since 2001, and I started asking 
> this question around 2010, so let’s say in the worst case only 1/3^rd 
> of them know the answer (because I did less trainings in the last 10 
> years than the first 10 ones).
>
> I guess this is something they can measure at the edge of the border, 
> peerings, etc., etc. I don’t really care how they do it, if it is 
> fairly close to reallity, otherwise, they will haven’t answered so 
> categorically. For example, they know how much traffic goes to the 
> self-hosted CDNs/caches or IX, in case they don’t host their own 
> CDNs/caches but the IXs offers them, etc.
>
> The response has been initially “more than 65%”, then I started to get 
> answers closer to 75%, 80-90%. I didn’t took note one by one to make 
> my own “stats”, but when I consintently get an answer over 65% and I 
> notice that, across the years that this response is going higher and 
> higher, I think we can have some conclusions and not be too much erred.
>
> We don’t need to “check” if the destination is IPv6 ready. Today, it 
> will be dificult to believe that **any** CDN/cache is not IPv6-ready. 
> We should not count if CDN “x” has disabled IPv6 for customer “y”, 
> because that means “that” customer is not yet IPv6-enabled or they did 
> a bad deployment and the CDN decided to turn it off to avoid issues.
>
> What we pretend to measure is “if you do a good IPv6 deployment in all 
> your customers (at least in the residential ones) how much traffic 
> will use the CDNs/caches with IPv6”. Just knowing how much IPv4 
> traffic today is going to the same CDNs/caches, provides a very good 
> anser to that question.
>
> Regards,
>
> Jordi
>
> @jordipalet
>
> El 31/3/21 12:22, "v6ops en nombre de Vasilenko Eduard" 
> <[e-mail] <mailto:[e-mail]> en nombre de 
> [e-mail] <mailto:[e-mail]>> 
> escribió:
>
> Hi Jordi,
>
> When I was on the big Carrier side
>
> We have collected cFlowd sampled statistics (for many reasons).
>
> Then it was possible to put it into some database
>
> And then get N biggest traffic directions out of it.
>
> It was a pure manual exercise in our case.
>
> The result has given many surprises to usJ
>
> The next option is to use DPI statistics that could be of the same 
> rich. DPI (PCEF) is available only on Mobile.
>
> I am not sure they have a pre-loaded template, but chances are good. 
> Just one problem: the discussion below was more about FBB, not MBB.
>
> Unfortunately, all off-line traffic engineering tools (I would not 
> mention 3 vendor’s names here) collect statistics only for MPLS LSPs. 
> That would not help here.
>
> One other big tool has a big collection of sampled cFlowd but it 
> refuses to let it out of a proprietary database.
>
> Hence, such statistics could not be collected for free in any other 
> process or tool.
>
> It is a specialized “project”.
>
> I am not sure that many Carriers could do what you want. This task was 
> not easy a few years ago.
>
> Staring from the fact that not all carriers collect sampled cFlowd 
> from all ports to general-purpose collector, then facing the problem 
> to aggregate it.
>
> Additionally, they need some check which one destination is IPv6 
> ready. It would be a manual process too.
>
> Eduard
>
> *From:*v6ops [mailto:[e-mail] 
> <mailto:[e-mail]>] *On Behalf Of *JORDI PALET MARTINEZ
> *Sent:* Wednesday, March 31, 2021 11:42 AM
> *To:* [e-mail] <mailto:[e-mail]>
> *Subject:* Re: [v6ops] draft-vf-v6ops-ipv6-deployment
>
> And more important than that … this site only shows “number” of 
> websites, but it doesn’t show “how” much % of traffic those web sites 
> are delivering vs. % worldwide.
>
> This is very simple. We can make a poll and evaluate the results in 
> the list. We can find a way to make it anonymous (no need to indicate 
> your email or name). People could respond the poll without telling 
> what is the ASN/network, just be honest when responding. What do you 
> think Fred/Ron?
>
> Each operator or people having details of one or more networks, to 
> tell us how much traffic in your network is going to caches and CDNs, 
> you don’t need to indicate which ones, just totals (so include all the 
> big ones such as video services, social networks, or other well-know 
> that have IPv6-enabled).
>
> It doesn’t matter if you don’t offer IPv6 to your customers. If you 
> know that (for example), 85% of your traffic is towards those 
> services, we know that turning IPv6 on to your customers will turn 
> your % of IPv6 traffic towards that figure.
>
> Even if we ignore “smaller” sites, the % of traffic to them is 
> probably negligible, even if an “important” service for an specific 
> operator is not there. This can compensate somehow the % of IPv4 
> traffic to video sources from older (non-IPv6 enabled) smartTVs or STBs.
>
> Regards,
>
> Jordi
>
> @jordipalet
>
> El 31/3/21 9:03, "Vasilenko Eduard" <[e-mail] 
> <mailto:[e-mail]>> escribió:
>
> Just small good news:
>
> Content is not “sitting steady at 15% IPv6”.
>
> It has healthy 23% CAGR by 
> https://w3techs.com/technologies/history_overview/site_element/all 
> <https://w3techs.com/technologies/history_overview/site_element/all>
>
> Chicken and egg are evolving one after another.
>
> Eduard
>
> *From:*v6ops [mailto:[e-mail] 
> <mailto:[e-mail]>] *On Behalf Of *Gyan Mishra
> *Sent:* Wednesday, March 31, 2021 9:00 AM
> *To:* JORDI PALET MARTINEZ 
> <jordi.palet=[e-mail] 
> <mailto:jordi.palet=[e-mail]>>
> *Cc:* [e-mail] <mailto:[e-mail]>
> *Subject:* Re: [v6ops] draft-vf-v6ops-ipv6-deployment
>
> In theory if you flipped a switch and all fixed broadband and wireless 
> 4G/5G access layer providers all around the world banded together and 
> ditched CGN and turned up IPv4AAS and so now all subscribers - all the 
> billions of subscribers around the world are now officially IPv6 only.
>
> However let’s say this happened tomorrow but our web content and 
> traffic volume is still sitting steady at 15% IPv6 and 85% IPv4.
>
> The needle would not have moved at all as we only fixed half the problem.
>
> We need to get all the web content to move to IPv6 and that’s an 
> problem of economics that we need to push the envelope on all web 
> content providers charge high for IPv4 premium $$ to incentivize 
> moving to IPv6 by forces of economy where money talks.
>
> Gyan
>
> On Tue, Mar 30, 2021 at 4:29 PM JORDI PALET MARTINEZ 
> <jordi.palet=[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     I will say that the “long” and “unpredictable” time for IPv4aaS is
>     an advantage, because you “stop” provisioning IPv4 now, so it is
>     one less problem to worry about.
>
>     You’re not longer worried about “how” much usage of IPv4 is done,
>     except for a single thing: reducing the number of IPv4 addresses
>     in the NAT64 (for example in the case of 464XLAT). You could even
>     ignore that, but of course, it is good to reduce the number of
>     IPv4 addresses if they are not used, because you can either
>     transfer them and get some money back or use in other parts of the
>     network.
>
>     The question is: Do you prefer to ged rid off IPv4 as in many
>     parts of the network as possible sooner or later?
>
>     El 30/3/21 22:21, "v6ops en nombre de Gyan Mishra"
>     <[e-mail] <mailto:[e-mail]> en nombre
>     de [e-mail] <mailto:[e-mail]>> escribió:
>
>     On Tue, Mar 30, 2021 at 2:34 PM Yannis Nikolopoulos
>     <[e-mail] <mailto:[e-mail]>> wrote:
>
>
>
>         On 3/28/21 9:47 PM, Brian E Carpenter wrote:
>         > Dual stack has no time limit
>         (for us ISPs) it has, it painfully has, if your user base is
>         still growing
>
>     Gyan> I think to your POV there is a flip side as dual stack is
>     simple and easy cannot get any simpler than that, however the
>     downside is the process of deployment can be painfully slow but it
>     all depends. If you are provisioning 1000s of sites for dual stack
>     that still can be done with ZTP even with complex DMVPN or other
>     overlay topologies dual stacked still not difficult.  I think
>     whenever manual configuration comes into play and you have even a
>     100 sites or devices that can be painful and lengthy process.
>
>     There are definite tradeoffs.
>
>     Dual stack is less complexity but then you have IPv4  provisioning
>     and numbering plan so you could say that in itself is complex.
>
>     If it’s fixed broadband BNG or 4G/5G mobile the drawback as well
>     with dual stack is IPv4 addressing numbering plan but having to
>     maintain configuration for both IPv4 and IPv6 could be considered
>     complex, even though the dual stack process is as simple as it gets.
>
>     With IPv4 AAS the attraction could be the minimum configuration
>     footprint number of lines of config.
>
>     Learning curve yes for operators but you could say that for any
>     technology their is a learning curve.
>
>     I think the bigger deal for operators is how long the timeframe to
>     maintain IPv4AAS is a bigger factor as that could be decades and
>     it could be almost like a permanent solution.
>
>
>
>         _______________________________________________
>         v6ops mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/v6ops
>         <https://www.ietf.org/mailman/listinfo/v6ops>
>
>     -- 
>
>     <http://www.verizon.com/>
>
>     *Gyan Mishra*
>
>     /Network Solutions Architect /
>
>     /Email [e-mail] <mailto:[e-mail]>/
>
>     /M 301 502-1347/
>
>     _______________________________________________ v6ops mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/v6ops
>     <https://www.ietf.org/mailman/listinfo/v6ops>
>
>
>     **********************************************
>     IPv4 is over
>     Are you ready for the new Internet ?
>     http://www.theipv6company.com <http://www.theipv6company.com>
>     The IPv6 Company
>
>     This electronic message contains information which may be
>     privileged or confidential. The information is intended to be for
>     the exclusive use of the individual(s) named above and further
>     non-explicilty authorized disclosure, copying, distribution or use
>     of the contents of this information, even if partially, including
>     attached files, is strictly prohibited and will be considered a
>     criminal offense. If you are not the intended recipient be aware
>     that any disclosure, copying, distribution or use of the contents
>     of this information, even if partially, including attached files,
>     is strictly prohibited, will be considered a criminal offense, so
>     you must reply to the original sender to inform about this
>     communication and delete it.
>
>     _______________________________________________
>     v6ops mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/v6ops
>     <https://www.ietf.org/mailman/listinfo/v6ops>
>
> -- 
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions Architect /
>
> /Email [e-mail] <mailto:[e-mail]>/
>
> /M 301 502-1347/
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com <http://www.theipv6company.com>
> The IPv6 Company
>
> This electronic message contains information which may be privileged 
> or confidential. The information is intended to be for the exclusive 
> use of the individual(s) named above and further non-explicilty 
> authorized disclosure, copying, distribution or use of the contents of 
> this information, even if partially, including attached files, is 
> strictly prohibited and will be considered a criminal offense. If you 
> are not the intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited, will be 
> considered a criminal offense, so you must reply to the original 
> sender to inform about this communication and delete it.
>
> _______________________________________________ v6ops mailing list 
> [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/v6ops 
> <https://www.ietf.org/mailman/listinfo/v6ops>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com <http://www.theipv6company.com>
> The IPv6 Company
>
> This electronic message contains information which may be privileged 
> or confidential. The information is intended to be for the exclusive 
> use of the individual(s) named above and further non-explicilty 
> authorized disclosure, copying, distribution or use of the contents of 
> this information, even if partially, including attached files, is 
> strictly prohibited and will be considered a criminal offense. If you 
> are not the intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited, will be 
> considered a criminal offense, so you must reply to the original 
> sender to inform about this communication and delete it.
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops