Subject: [v6ops] draft-xie-v6ops-network-happyeyeballs

From: Ron Bonica <[email-masked]>
Date: Mon, 26 Nov 2018 14:22:58 +0000

Folks,

Each week between now and IETF 104, we will review and discuss one draft with an eye towards progressing it.

This week, please review and comment on draft-xie-v6ops-network-happyeyeballs.

                                                             Fred and Ron

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 26 Nov 2018 14:40:59 +0000

Ron Bonica wrote on 26/11/2018 14:22:
> Each week between now and IETF 104, we will review and discuss one
> draft with an eye towards progressing it.
> 

what's outlined in the draft sounds interesting, and it would be useful 
to see code published which implements what's suggested.  But I don't 
see a compelling case to publish this as an RFC.  Sometimes running code 
is better.

Nick

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 27 Nov 2018 12:44:48 +0100 (CET)

> draft-xie-v6ops-network-happyeyeballs.

I think it's a great idea to tell the operator about problems, that kind 
of telemetry can really help in operating the network.

However, the proposed method of doing it (syslog) and the information it 
reports (IP addresses and domains the user is communicating with) has huge 
privacy implications. Also you have no idea who might be grabbing this 
information before it even makes it to the ISP).

I think at a minimum there needs to be an encrypted and verified mechanism 
(https perhaps?) for doing the reporting, so you know where the report 
goes.

I see three entities that have interest in this information, it's the ISP, 
the operating system manufacturer, and the web site which is having 
problems. If HE fails, I see very little harm (privacy) in telling the 
website about it using the address family that actually did work. So that 
could be included. For the device manufacturer, they have "send 
diagnostics information to vendor", so here customers can opt in. For the 
ISP, I have no idea. Here it might be better to define an API between the 
device vendor and the ISP, so that the device vendor can report problems 
seen, at an aggregate? I have personally been involved in getting 
operational people from my employer talking to device vendors to figure 
out what might be wrong, and automating this would be great.

Also, the DNSSEC implications are glossed over grossly. We should take for 
granted that end devices are running validating resolvers and handle that 
use-case.

So I'm supportive of the problem statement and it would help ISPs greatly 
if they could get telemetry from end devices, I just have great concerns 
over the method proposed in this draft.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 27 Nov 2018 14:22:16 +0100

Hi Mikael,

I got the impression that when I originally proposed this, syslog was a privacy issue because it is sending data from "customers traffic" from their own devices to the ISP.

But in the actual proposal, the data is NOT from any customer, neither identifying the customer at all.

So not sure to understand if we have failed to clearly describe the way we are measuring, or you'd in mind the previous document?

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Mikael Abrahamsson <[email-masked]>
Organización: People's Front Against WWW
Fecha: martes, 27 de noviembre de 2018, 12:45
Para: Ron Bonica <[email-masked]>
CC: "[email-masked] list" <[email-masked]>
Asunto: Re: [v6ops] draft-xie-v6ops-network-happyeyeballs

    

    

    
    
    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
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.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 27 Nov 2018 14:28:43 +0100 (CET)

> So not sure to understand if we have failed to clearly describe the way we are measuring, or you'd in mind the previous document?

https://tools.ietf.org/html/draft-xie-v6ops-network-happyeyeballs-01#section-4

4.  Reporting IPv6 failures using syslog

    In order to simplify the reporting of the NHE failures, syslog
    ([RFC5424]) over UDP ([RFC5426]), MUST be used, by means of the
    default port (514) with IPv6-only.

What is this then? When I re-read it it's not clear if this is for 
operator-operator communication or between client HE and operator. If it's 
for operator-operator, how is this address discovered?

The reference to 4.1 about this doesn't make sense to me from a NHE 
perspective? Why is this conflating things with the NAT64 prefix?

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 27 Nov 2018 14:50:01 +0100

We can make the text clearer, but it mentions NHE (Network Happy Eyeballs). So, the reporting is done "internally" in the ISP network.

We believe that if the operator want to have multiple syslog servers, 4.1 will help to avoid configuring the operator probes, and of course, we are assuming that the operator has an IPv6-enabled network.

Regards,
Jordi

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 27 Nov 2018 14:54:38 +0100 (CET)

> We believe that if the operator want to have multiple syslog servers, 4.1 will help to avoid configuring the operator probes, and of course, we are assuming that the operator has an IPv6-enabled ne…

So this isn't even between operators, it's within a single operator?

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 27 Nov 2018 16:38:35 +0100

Yes, is within a specific network.

If they decide later on to tell other ISPs "traffic from our network to your address xxx" is not working ... that's not handled by this document.

Regards,
Jordi

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 27 Nov 2018 15:41:17 +0000

JORDI PALET MARTINEZ wrote on 27/11/2018 15:38:
> If they decide later on to tell other ISPs "traffic from our network
> to your address xxx" is not working ... that's not handled by this
> document.
O/S software to do this would be great.  There's no need for IETF 
involvement.

Nick

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 27 Nov 2018 16:52:41 +0100

In the previous related work, I was told otherwise: let's the ISPs do it, not the O/S vendors ...

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Nick Hilliard <[email-masked]>
Fecha: martes, 27 de noviembre de 2018, 16:42
Para: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
CC: "[email-masked] list" <[email-masked]>
Asunto: Re: [v6ops] draft-xie-v6ops-network-happyeyeballs

    Nick

---

From: <[email-masked]>
Date: Tue, 27 Nov 2018 16:05:18 +0000

Jordi, 

It is not unusual that operators deploying IPv6 monitor both IPv4/IPv6 performance metrics to track and detect severe gaps. 

Nevertheless, that probing does not allow to ** deterministically ** conclude that the root of the problem is at the server side (proxy, CDN, etc.). 

Gaps in v4/v6 metrics is used as one of the problem detection triggers among others: the problem may be caused by a misbehaving router/node on IPv6 packets, local forwarding issues, congestionned links with a peer/transit providers, etc. Of course, in some cases the content provider is contacted to solve the problem by tuning, for example, how the traffic is delivered to the network provider. 

So, sending an automatic report to some server may not help solving the problem.

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:[email-masked]] De la part de JORDI PALET MARTINEZ
> Envoyé : mardi 27 novembre 2018 16:53
> À : Nick Hilliard
> Cc : [email-masked] list
> Objet : Re: [v6ops] draft-xie-v6ops-network-happyeyeballs
> 
> 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.
> 
> 
>

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 29 Nov 2018 14:53:44 -0800

> On Nov 27, 2018, at 7:52 AM, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 

I think the point being made here is that open source software can be created and distributed to ISPs to run in their networks; it doesn't necessarily require any standard or draft to do it.

Thanks,
Tommy

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 29 Nov 2018 15:00:50 -0800

Even with non-customer traffic, is syslog really the state of the art for sending data back to servers? Do you want anyone and everyone to see this information?

Regarding the active measurements themselves, I think the draft would benefit from referencing some of the RFCs and drafts from the IPPM Working Group. We have various documents on one-way and two-way active measurements (OWAMP/TWAMP). You can also take a look at some standard ways of reporting the metrics themselves, as described here: draft-ietf-ippm-initial-registry-08.

Thanks,
Tommy

> On Nov 27, 2018, at 5:22 AM, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 
> Hi Mikael,
>

---

From: Lencse Gábor <[email-masked]>
Date: Fri, 30 Nov 2018 17:55:16 +0100

> I think the point being made here is that open source software can be created and distributed to ISPs to run in their networks; it doesn't necessarily require any standard or draft to do it.

I think you are completely right that the software can be written 
without an I-D, however, I think that its specification would benefit 
from a matured draft.

Gábor