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

["Susan Hares" <[e-mail]>]

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