Re: [Dots] Questions about draft-doron-dots-telemetry-00

[Ehud Doron <[e-mail]>]

Susan

I believe the telemetry needs by DOTS is not relates to "flow based" information, the DOTS telemetry is more "higher" and mainly describes the ongoing attacks and their attributes.

Thanks, Ehud 

-----Original Message-----
From: Susan Hares [mailto:[e-mail]] 
Sent: Thursday, November 17, 2016 12:58 AM
To: Ehud Doron <[e-mail]>; 'Roland Dobbins' <[e-mail]>; 'dots' <[e-mail]>; [e-mail]
Subject: RE: [Dots] Questions about draft-doron-dots-telemetry-00

Ehud:

Can you indicate what additional features the telemetry that you propose for DOTS needs over the telemetry provided by IPFIX? 

Sue 

-----Original Message-----
From: Dots [mailto:[e-mail]] On Behalf Of Ehud Doron
Sent: Wednesday, November 16, 2016 11:31 AM
To: Roland Dobbins; dots; [e-mail]
Cc: Ehud Doron
Subject: Re: [Dots] Questions about draft-doron-dots-telemetry-00

Ronald, Flemming and all

Thanks for your comments. 

I appreciate the standpoints you present in your comments, however I really believe the DOTS WG must also look and consider others views of the
challenges DOTS has with regards to DOTS telemetry.   

No doubt that for the world of DDoS services the "security visibility" is a major concern to both the anti-DoS service providers and consumers. In all cases where the DOTS Client will be implemented in an organizations with a sustainable SOC/NOC teams, the ability to have "customer portal" with visibility into the on-going attacks is a critical part of the service.
Likewise, anti-DoS service providers need visibility into their customers view on the on-going attacks and other sort of views relates to the service and its fulfillments. These are critical parts of the service. 

Getting deeper, having comprehensive telemetry about the ongoing attacks will improve the overall mitigation accomplished, in terms of time to mitigate, accuracy, false-negative, false-positive, and other measures. We must keep in our minds the value gained here.  

I see all these as a major points and really want to get your view on that, as well as the view of others at the WG.

Obviously, I agree with your points that there are many cases where telemetry is with less relevance, mainly since DOTS agents will be integrated in " radically different paradigms, capabilities, and 'worldviews'...." (which for my opinion is the right architecture). Having say all that, we must consider environments where DOTS Client has DoS/DDoS detection and mitigation capabilities and can practically signal valuable telemetry. These are definitely not rear use cases that must be considered as well. 

For my mind, after we will get to a consensus about WG view on the needs for telemetry, we can define the best way to standardize it (in which doc and
how) and also consider the right time to do. Then we can define the baseline set of telemetry we believe are adequate, or the bare minimum, to standardize.  

I am looking forward to continue this discussion with you and the entire the WG.

Please see also my comments inline. 

Best wishes,
Ehud Doron |  Senior Architect, Radware CTO office | M: [phone] |
T: [phone]



-----Original Message-----
From: Dots [mailto:[e-mail]] On Behalf Of Roland Dobbins
Sent: Monday, November 14, 2016 11:02 AM
To: dots <[e-mail]>
Subject: Re: [Dots] Questions about draft-doron-dots-telemetry-00

On 14 Nov 2016, at 15:14, Ehud Doron wrote:

> Essentially we would like to build a "Telemetry" extension standard to 
> the basic DOTS protocol, and this document would define that.

This may make sense at some future date; initially, since we're dealing with devices/software/systems which have radically different paradigms, capabilities, and 'worldviews', the initial focus of DOTS should be on signaling and status only, as the ins are universal functions which are readily understood by most any type of node/service/application which could participate in DOTS.
[ED] See my view in the body of the mail.

> Keeping the telemetry specification in a separate draft is good 
> approach for future extensibility.

> For this goal, we as the DOTS WG first need to better understand (and 
> agree in the group) what we see as baseline mandatory capabilities 
> other DOTS draft should benefit the DOTS Telemetry.

We've already held extensive discussions on this topic; initially, we need a minimum viable capability to allow signaling and status information to be passed between DOTS participants.
[ED] I was not part of this discussions, sorry for that. For my mind, we need to truly define (or re-define...) the needs for DOTS Telemetry for the actual users (SP, MSSP, Enterprises, carrier and so on) of DOTS, and also the baseline set of this telemetry. 


> (1) Is there an undocumented telemetry use case that needs to be added 
> to the use case WG document?  Section 4.0 suggests that.
>      Yes. We want to DOTS use cases, the existing and maybe new 
> others, to be enriched with Telemetry related items.

This can come at a later state, if the group believes it to be important.

It's sub-optimal to duplicate the work done on IPFIX, I2NSF, I2RS, et. 
al. in DOTS.  By leaving mitigation technique specifics and telemetry specifics to one side, we can concentrate on signaling and status, which is all that's actually required for successful inter- and intra-domain DOTS-enabled DDoS mitigation assistance and provisioning.

[ED] Agree, we shouldn't duplicate any work done at IPFIX, I2NSF.

It's important to get to an initial operating capability with the requisite baseline capability before we expand the scope of DOTS itself, IMHO.

[ED] Agree, we just need to define and get to the mutual understanding about the " baseline capability" in term of telemetry. Mainly for the users and customers of the actual anti-DoS service.
 
-----------------------------------
Roland Dobbins <[e-mail]>

_______________________________________________
Dots mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dots

_______________________________________________
Dots mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dots