Re: [Dots] DOTS telemetry Issues picked up in Interop Testing

[Jon Shallow <[e-mail]>]

Hi all,

 

A further thought on the use of Uri-Queries to clarify the AND/OR usage.

 

If you only allow one query per query type and put the match list in an
array, then this will be an OR of the array list (the same as we do for the
target* definitions right now.  E.G. :-

 

Uri-Query: target_prefix=[1.2.3.4/32,4.3.2.1/32]

Gives either 1.2.3.4 or 4.3.2.1 as a valid match.

 

And 

Uri-Query: target-prefix=[1.2.3.4/32,4.3.2.1/32]

Uri-Query: lower-port=[80,443]

Gives (either 1.2.3.4 or 4.3.2.1) and (either port 80 or 443)

 

[] should not include spaces and comma used as a separator.

 

Not sure about :-  If [] are not used, then it should be treated as a single
item to match.

 

The list of valid Uri-Queries may need to be extended.

 

A Uri-Query option can include the following

   parameters: target-prefix, lower-port, upper-port, target-protocol,

   target-fqdn, target-uri, alias-name.

 

should include mid and content (‘c’).   Do we need to be able to filter on
source attributes as well?

 

Regards

 

Jon

 

 

 

From: Dots [mailto: [e-mail]] On Behalf Of Jon Shallow
Sent: 20 April 2020 14:47
To: [e-mail]; [e-mail]
Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing

 

Hi Med,

 

See inline.

 

Regards

 

Jon

 

From: Dots [mailto: [e-mail]] On Behalf Of
[e-mail]
Sent: 20 April 2020 13:54
To: Jon Shallow; [e-mail]
Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing

 

Hi Jon, 

 

Thank you for sharing the comments. 

 

Please see

 

De : Dots [mailto:[e-mail]] De la part de Jon Shallow
Envoyé : lundi 20 avril 2020 14:07
À : [e-mail]
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