Re: [Dots] DOTS telemetry Issues picked up in Interop Testing
mohamed.boucadair@orange.com Mon, 20 April 2020 15:49 UTC
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1C03A098A for <dots@ietfa.amsl.com>; Mon, 20 Apr 2020 08:49:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_SGhgCmhI72 for <dots@ietfa.amsl.com>; Mon, 20 Apr 2020 08:48:55 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9D73A09CB for <dots@ietf.org>; Mon, 20 Apr 2020 08:46:52 -0700 (PDT)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 495WK52nTyz8vsb; Mon, 20 Apr 2020 17:46:49 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1587397609; bh=tSMXv5mpPkP6Lrt4LeMcv6/KD2hS7BPYCy4K0F8unB0=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=uW7URgTVPFA8nAH0xuM4xeP0jpMmgWOV0eq9NuIaO+0GISiSdZo3/Pj9sWSQATDz/ yVy+cr84a5iNPAjaro+gPliJLFNScbF6RVQfhOg7mSN9K+HrOkNSiUBxhSHM0gEAT5 ronb0dkGSRIdeFmTO47rFbdJFgwjanPcM0rMKqTzUvFY3+JCdNu/YGklklhRHdZwrl dcidnSZ7hXiAzrBSli0r84ahKEQJm7BWSPrIbvs8zPT8ZULogKSxT+IOB4QXhTlRLY oTlOtIOd2CgSg8qr2rXJQo0q0uExC5CBlPv/lFDA4Ptrlz2c74rlzASB/1fMFskjtV Dj5LWykvplMlA==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 495WK51t4szCqkV; Mon, 20 Apr 2020 17:46:49 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: Jon Shallow <supjps-ietf@jpshallow.com>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] DOTS telemetry Issues picked up in Interop Testing
Thread-Index: AQIP9ThI7DkLoYVsg/jsxFxzT+JmLAHYmGmap/+EM3CAACIu0A==
Date: Mon, 20 Apr 2020 15:46:48 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933031499A6F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <102501d6170c$2be45900$83ad0b00$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031499776@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <105901d6171a$1a132860$4e397920$@jpshallow.com>
In-Reply-To: <105901d6171a$1a132860$4e397920$@jpshallow.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933031499A6FOPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/qkUwiL3rYREJ7jMYquwYufIK614>
Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Apr 2020 15:49:01 -0000
Re-, FWIW, I implemented the agreed changes at: https://github.com/boucadair/draft-dots-telemetry/blob/master/draft-ietf-dots-telemetry-07.txt Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoyé : lundi 20 avril 2020 15:47 À : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing Hi Med, See inline. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of iemohamed.boucadair@orange.com Sent: 20 April 2020 13:54 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing Hi Jon, Thank you for sharing the comments. Please see De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoyé : lundi 20 avril 2020 14:07 À : dots@ietf.org Objet : [Dots] DOTS telemetry Issues picked up in Interop Testing Hi All, 1) DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry messages to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1). If I do a PUT /tm-setup, followed immediately by a GET /tm-setup, should the GET fail based on the telemetry-notify-interval, or should telemetry-notify-interval apply individually to PUT. GET and DELETE? [I may want to do a DELETE (no tsid) followed by a GET to get suitable max/min information and telemetry-notify-interval can easily be more than 1 second. ] [Med] This rate limit does not apply to these messages; it applies only for notifications; == leaf telemetry-notify-interval { type uint32 { range "1 .. 3600"; } must '. >= ../../min-config-values/telemetry-notify-interval' { error-message "The value must be greater than or equal to the telemetry-notify-interval in the min-config-values"; } units "seconds"; description "Minimum number of seconds between successive telemetry notifications."; } === We can make the text clear: OLD: DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry messages to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1<https://tools.ietf.org/html/draft-ietf-dots-telemetry-07#section-6.1>). If a telemetry notification is sent using a block-like transfer mechanism (e.g., [I-D.bosh-core-new-block<https://tools.ietf.org/html/draft-ietf-dots-telemetry-07#ref-I-D.bosh-core-new-block>]), this rate limit policy MUST NOT consider these individual blocks as separate notifications, but as a single notification. NEW: DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry notifications to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1<https://tools.ietf.org/html/draft-ietf-dots-telemetry-07#section-6.1>). If a telemetry notification is sent using a block-like transfer mechanism (e.g., [I-D.bosh-core-new-block<https://tools.ietf.org/html/draft-ietf-dots-telemetry-07#ref-I-D.bosh-core-new-block>]), this rate limit policy MUST NOT consider these individual blocks as separate notifications, but as a single notification. Jon> This change works for me. 2) Use of multiple Uri-Query: Uri-Query: target_prefix=[1.2..3.4] Uri-Query: target_prefix=[2.3..4.5] I think this should be OR [Med] Yes, this is the same interpretation when we include target-prefix in the message body. Uri-Query: target_prefix=[1.2..3.4] Uri-Query: target_port=[80] I think this should be an AND. [Med] Yes, because the target-port is specifying a subset of ports bound to the target-prefix. Perhaps we should have operator queries Uri-Query: target_prefix=[1.2..3.4] Uri-Query: op=OR Uri-Query: target_prefix=[2.3..4.5] Uri-Query: target_prefix=[1.2..3.4] Uri-Query: op=AND Uri-Query: target_port=[80] [Med] I don't think this is needed. We don't specify the operator when we include the target clauses in the message body. The same rules apply. We can clarify this in the text If you think this is needed. Jon> I think that it is worth stating that the same rules apply for clarification. Thoughts? 3) What happens if a Query cannot be supported. E.g. Uri-Query: target_port=[80] and statistics on the server by a port basis is not supported. Do we want to either error out with a 4.0X responses, or should we include a (new additional) YANG body response indicating which Uri-Query is not supported? [Med] Good point. The client can retrieve during telemetry setup the supported query types + server replies with 4.00 when an invalid query type is used. Jon> I think the server stating what Queries are supported is a good idea. Regards Jon
- [Dots] DOTS telemetry Issues picked up in Interop… Jon Shallow
- Re: [Dots] DOTS telemetry Issues picked up in Int… mohamed.boucadair
- Re: [Dots] DOTS telemetry Issues picked up in Int… Jon Shallow
- Re: [Dots] DOTS telemetry Issues picked up in Int… mohamed.boucadair
- Re: [Dots] DOTS telemetry Issues picked up in Int… Jon Shallow
- Re: [Dots] DOTS telemetry Issues picked up in Int… mohamed.boucadair
- Re: [Dots] DOTS telemetry Issues picked up in Int… Jon Shallow