Subject: [lmap] Question on multiple outstanding suppressions

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Thu, 24 Mar 2016 14:56:39 +0000

Team,

I noticed that the information model has support for multiple suppressions.
With the current definition in the information model, it looks like there isn't any constraints on multiple suppression requests that can be active at the same time.

I just wanted to a confirmation on this. We used to have just 1 suppression object in an instruction. It looks like this changed in draft-07.

This actually conflicts with BBF TR-304 Section 5.2 where the text says:
Suppression is the temporary cessation of all or a subset of measurement-related tasks. A Measurement Controller can send a suppress message to the MA that instructs the MA to temporarily suspend some or all of its scheduled measurement-related tasks. Suppression ends either in response to an explicit unsuppress message or at the time indicated in the suppress message. Suppression might be used when the measurement system wants to minimize inessential traffic, for example after a major network incident. Only one suppression message can exist at a time in a given MA. A new suppression message completely replaces the previous one.

So TR-304 would expect 1 suppression with an enable; this is quite different from the behavior that changed last November.

Looking for guidance.

BR,
Tim

---

From: KEN KO <[email-masked]>
Date: Thu, 24 Mar 2016 15:00:27 +0000

Tim, thanks for catching this. I'd also like to understand why lmap has changed it.
Ken

From: Carey, Timothy (Nokia - US) [mailto:[email-masked]]
Sent: Thursday, March 24, 2016 9:57 AM
To: [email-masked]
Cc: KEN KO; [email-masked]
Subject: Question on multiple outstanding suppressions

Team,

Looking for guidance.

BR,
Tim

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Mar 2016 10:48:14 +0200

The original reasoning can be found here:

https://mailarchive.ietf.org/arch/msg/lmap/ptg-TcdfMuVHM93PWisj4u-tbFI

Not being able to provision multiple suppressions seems a major
limitation to me.

/js

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Tue, 29 Mar 2016 16:58:26 +0000

Juergen,

I suspect it was with good reason that the BBF wanted this as a single instance active at a time. 

Possibly Ken or Barbara could provide the reasoning.

Minimally I would think we would need to be able administratively enable/disable a suppression object; that at least lets me shut them down temporarily.

BR,
Tim

-----Original Message-----
From: EXT Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2016 3:48 AM
To: KEN KO
Cc: Carey, Timothy (Nokia - US); [email-masked]; [email-masked]
Subject: Re: [lmap] Question on multiple outstanding suppressions

Not being able to provision multiple suppressions seems a major limitation to me.

/js

---

From: KEN KO <[email-masked]>
Date: Tue, 29 Mar 2016 17:22:55 +0000

TR-304 (from BBF) and RFC 7594 both document suppression as a single instance. It is intended to be used as a fairly blunt instrument, for instance to prevent measurement traffic from exacerbating network congestion during an unusual event.

>From TR-304 section 5.2: "Suppression might be used when the measurement system wants to minimize inessential traffic, for example after a major network incident. Only one suppression message can exist at a time in a given MA. A new suppression message completely replaces the previous one."

>From RFC 7594 section 5.2.2.1: "The main motivation for Suppression is to enable the Measurement System to eliminate Measurement Traffic, because there is some unexpected network issue, for example.  There may be other circumstances when Suppression is useful, for example, to eliminate inessential Reporting traffic (even if there is no Measurement Traffic).

>From RFC 7594 section 5.2.2: "However, Suppression information always replaces (rather than adds to) any previous Suppression information."

The idea in both documents was to provide a mechanism that was flexible in how tasks could be configured to react to it, but simple in how the "panic button" would be pushed in the case of a network event. 

>From the archive link Juergen provided, it looks like the purpose of suppression in the information model has changed fairly dramatically, and that it is now a more generic capability to disable tasks according to any of multiple schedules. I'm concerned that it may no longer provide the simple "panic button" that was intended. Do we really want to deviate in this way from something that was defined specifically in the framework documents, which after all are intended to provide guidance for more detailed documentation?

Ken

-----Original Message-----
From: Carey, Timothy (Nokia - US) [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2016 12:58 PM
To: Juergen Schoenwaelder; KEN KO
Cc: [email-masked]; [email-masked]
Subject: RE: [lmap] Question on multiple outstanding suppressions

Juergen,

BR,
Tim

-----Original Message-----
From: EXT Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2016 3:48 AM
To: KEN KO
Cc: Carey, Timothy (Nokia - US); [email-masked]; [email-masked]
Subject: Re: [lmap] Question on multiple outstanding suppressions

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Mar 2016 19:23:41 +0200

> Minimally I would think we would need to be able administratively enable/disable a suppression object; that at least lets me shut them down temporarily.

Simply set the match to something that does not match anything or
delete and recreate the suppression or ... If we start to add
enable/disable knobs here, we will end having them everywhere.

In the NETCONF world, there once was a proposal to have a generic
enable/disable mechanism but it did run out of steam. But I would
prefer to have a general mechanism for this instead of enable/disable
knobs everywhere.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Mar 2016 19:32:57 +0200

You can still use suppressions as a panic button. You can have
multiple panic buttons if you want to (but you do not have to use it
in that way). You can have automatic pre-configured panic buttons (the
new years evening example) but you do not have to use it that way.

If you read the emails, you will note that we had not only panic
buttons but also a second mechanism to handle the loss of the
controller. Instead of having multiple hardwired mechanisms to disable
'things', the proposal back then was to generalize _one_ mechanism so
that it can do it all. The suppressions we have now makes code
simpler, extensible and more powerful at the same time. I do not see a
good reason to go back.

/js

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Tue, 29 Mar 2016 20:31:06 +0000

Juergen,

Looking at the text of section 3.3 
The new multi-instance model doesn't seem to support this text.

For example - can't just turn-on/turn-off suppression by setting enabled to false and the unsuppression.

Honestly it worked better when it was a single object with an enable and/or endtime...

BR,
Tim

-----Original Message-----
From: EXT Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2016 12:33 PM
To: KEN KO
Cc: Carey, Timothy (Nokia - US); [email-masked]; [email-masked]
Subject: Re: [lmap] Question on multiple outstanding suppressions

You can still use suppressions as a panic button. You can have multiple panic buttons if you want to (but you do not have to use it in that way). You can have automatic pre-configured panic buttons (the new years evening example) but you do not have to use it that way.

If you read the emails, you will note that we had not only panic buttons but also a second mechanism to handle the loss of the controller. Instead of having multiple hardwired mechanisms to disable 'things', the proposal back then was to generalize _one_ mechanism so that it can do it all. The suppressions we have now makes code simpler, extensible and more powerful at the same time. I do not see a good reason to go back.

/js

On Tue, Mar 29, 2016 at 05:22:55PM +0000, KEN KO wrote:
> From: EXT Juergen Schoenwaelder 
> [mailto:[email-masked]]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Mar 2016 09:49:56 +0200

> The new multi-instance model doesn't seem to support this text.

I disagree.
 
> For example - can't just turn-on/turn-off suppression by setting enabled to false and the unsuppression.

This question is orthogonal to the question whether there are multiple
suppressions or just effectively two.

> Honestly it worked better when it was a single object with an enable and/or endtime...

Why? There were two mechanisms, the traditional suppression and the
reaction to loss of the controller. We now have a single mechanism
that covers both cases and at the same time is more flexible and
supports provisioned suppressions.

The question whether we add enable/disable leafs in random places or
everywhere is a separate question. When it comes to YANG, I am not a
big fan, I rather would like to see a generic solution for this
problem.

/js

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Wed, 30 Mar 2016 12:04:59 +0000

Juergen,

Controller timeout and a temporary suppression might need to suppress different actions/tasks - correct? Is this why you added suppression as multi-instance object?

BR,
Tim

-----Original Message-----
From: EXT Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, March 30, 2016 2:50 AM
To: Carey, Timothy (Nokia - US)
Cc: KEN KO; [email-masked]; [email-masked]
Subject: Re: [lmap] Question on multiple outstanding suppressions

I disagree.
 
> For example - can't just turn-on/turn-off suppression by setting enabled to false and the unsuppression.

This question is orthogonal to the question whether there are multiple suppressions or just effectively two.

> Honestly it worked better when it was a single object with an enable and/or endtime...

Why? There were two mechanisms, the traditional suppression and the reaction to loss of the controller. We now have a single mechanism that covers both cases and at the same time is more flexible and supports provisioned suppressions.

The question whether we add enable/disable leafs in random places or everywhere is a separate question. When it comes to YANG, I am not a big fan, I rather would like to see a generic solution for this problem.

/js

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Wed, 30 Mar 2016 13:59:25 +0000

It would be nice if we made "suppression" extensible.

  Operationally when finding something has been "taken out of service" - one often what's to know ... WHY - before turning on the water again.

To that end it would be very "operationally" valuable to have some TLV or even standard "why it's suppressed" tracking.

A few examples I have run into in the field (used when I was Op's)...

1) Network Op's suppression - Meaning the network guys shut this done, and they should be the only one to open it up...
2) The tester shut itself down -  multiple reason why it might, but it's more important to know the end point decided to stop..
3) Single test suppressed (maybe I tested to a point, and it failed hard and I just want to stop doing worthless sequential testing).
                        -  Here if I'm testing a path, and can't even get a good test I my own network, well maybe I should stop trying to test past a failure.

Not sure how this might help, but knowing those 3 scenarios makes Op's work much more effective... so having these types of "states" of knowledge about why things stopped are rather valuable...

    Not sure if there is one, but a "suppression state machine" picture that had these types of things would be pretty cool..

Regards,
Mike

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Carey, Timothy (Nokia - US)
Sent: Tuesday, March 29, 2016 3:31 PM
To: Juergen Schoenwaelder; KEN KO
Cc: [email-masked]; [email-masked]
Subject: Re: [lmap] Question on multiple outstanding suppressions

Juergen,

BR,
Tim

-----Original Message-----
From: EXT Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Tuesday, March 29, 2016 12:33 PM
To: KEN KO
Cc: Carey, Timothy (Nokia - US); [email-masked]; [email-masked]
Subject: Re: [lmap] Question on multiple outstanding suppressions

/js

_______________________________________________
lmap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lmap
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.