Subject: [lmap] A question about running actions in sequence

From: Fredrik Kers <[email-masked]>
Date: Tue, 16 May 2017 17:35:36 +0200

Hi!

I have a question about how running Actions in sequence is supposed to work
according to the LAMP information model.

Let's take a simple example. Say you have two actions that you want to run
in sequence, first a traceroute that finds all routers between the MA and a
remote peer, and after that a time limited ping to each of the routers.

It will not be possible to use the Schedule's duration to do the time
limiting of the ping since there is no way to have a second Schedule (doing
the ping) starting after the first Schedule (doing the traceroute) is
finished.

Also, you can not place both Actions in the same Schedule and use the
Schedule's duration since you don't know how long time the traceroute will
take.

The only way that I see is to make it possible to configure the duration in
the ping Actions itself. Is this how it's intended to be done? The
possibility to schedule arbitrary actions in a sequence would be quite
limited by this I think.

Regards,
Fredrik

-- 
*Fredrik Kers* | CTO
*Netrounds* | Storgatan 7 | 972 38 Luleå | Sweden | www.netrounds.com

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 May 2017 18:06:33 +0200

> the ping) starting after the first Schedule (doing the traceroute) is

Right, the schedule's duration is a limit on the duration of the whole
schedule, which may consist of multiple actions.

> Schedule's duration since you don't know how long time the traceroute will

Yes.

> the ping Actions itself. Is this how it's intended to be done?

It seems this is what you are looking for. Right now, the information
model does not support per action duration limits. This could be added
though, I think, without breaking anything.

> The possibility to schedule arbitrary actions in a sequence would be
> quite limited by this I think.

I am not sure this statement is right. But yes, if you want to have
per action duration limits, they are not part of this version of the
LMAP models. Whether this is a major omission or not - well I do not
know.

Perhaps a somewhat kludgy workaround could be a schedule that does
just the traceroute (with a duration set to cover the traceroutes)
where the traceroute action feeds into another schedule (with a
duration set to cover pings) that does the pings.

/js

PS: Personally, I find the concrete use case a bit surprising. If you
    want to probe the path for a certain time, why not run traceroute
    for a certain time; this causes roughly the same number of probe
    packets and your measurement adjusts to any path changes during
    the measurement itself. But perhaps you just picked this as an
    example to illustrate the question.

-- 
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: Fredrik Kers <[email-masked]>
Date: Wed, 17 May 2017 09:35:16 +0200

> duration set to cover pings) that does the pings.

Yes, if you give the first Action with uncertain runtime enough margin to
finish, the result will be that they run in sequence. But probably with
some delay.

>     example to illustrate the question.

Yes, it was just used as an example. You would face the same problem when
you combine any Action that runs until it's complete with an Action that
runs until it's stopped.

Thank you for your answer!

Regards,
Fredrik