Peoples, I was quite excited yesterday to be able to discover five of the deployed NSA. Some didn't return version information, but at least the endpoints were available. I spent some time running tests and realized that using the discovery interface is a simple way of determining NSA availability for management of connectivity. I was easily able to determine those NSA that were up or down. Obviously, this capability would be useful in production implementations. Further thinking on this topic has me considering adding a simple "hello" or "ping" type message to Discovery that could be used to determine NSA availability without the need to retrieve the interface versions document. We could also add simple information to the hello such as NSA uptime or a last restart token to permit a peer to determine if perhaps an audit should be performed. Pretty standard capabilities in production systems. Comments? John.
version 3...+ J On 10/11/12 11:14 AM, John MacAuley wrote:
Peoples,
I was quite excited yesterday to be able to discover five of the deployed NSA. Some didn't return version information, but at least the endpoints were available. I spent some time running tests and realized that using the discovery interface is a simple way of determining NSA availability for management of connectivity. I was easily able to determine those NSA that were up or down. Obviously, this capability would be useful in production implementations.
Further thinking on this topic has me considering adding a simple "hello" or "ping" type message to Discovery that could be used to determine NSA availability without the need to retrieve the interface versions document. We could also add simple information to the hello such as NSA uptime or a last restart token to permit a peer to determine if perhaps an audit should be performed. Pretty standard capabilities in production systems.
Comments?
John. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
LOL - I can add it is 30 seconds. On 2012-10-11, at 12:11 PM, Jerry Sobieski <jerry@nordu.net> wrote:
version 3...+ J On 10/11/12 11:14 AM, John MacAuley wrote:
Peoples,
I was quite excited yesterday to be able to discover five of the deployed NSA. Some didn't return version information, but at least the endpoints were available. I spent some time running tests and realized that using the discovery interface is a simple way of determining NSA availability for management of connectivity. I was easily able to determine those NSA that were up or down. Obviously, this capability would be useful in production implementations.
Further thinking on this topic has me considering adding a simple "hello" or "ping" type message to Discovery that could be used to determine NSA availability without the need to retrieve the interface versions document. We could also add simple information to the hello such as NSA uptime or a last restart token to permit a peer to determine if perhaps an audit should be performed. Pretty standard capabilities in production systems.
Comments?
John. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Not the point - we don't add things just because they are easy. We add them after we have thorough understanding and consensus. J On 10/11/12 12:19 PM, John MacAuley wrote:
LOL - I can add it is 30 seconds.
On 2012-10-11, at 12:11 PM, Jerry Sobieski <jerry@nordu.net> wrote:
version 3...+ J On 10/11/12 11:14 AM, John MacAuley wrote:
Peoples,
I was quite excited yesterday to be able to discover five of the deployed NSA. Some didn't return version information, but at least the endpoints were available. I spent some time running tests and realized that using the discovery interface is a simple way of determining NSA availability for management of connectivity. I was easily able to determine those NSA that were up or down. Obviously, this capability would be useful in production implementations.
Further thinking on this topic has me considering adding a simple "hello" or "ping" type message to Discovery that could be used to determine NSA availability without the need to retrieve the interface versions document. We could also add simple information to the hello such as NSA uptime or a last restart token to permit a peer to determine if perhaps an audit should be performed. Pretty standard capabilities in production systems.
Comments?
John. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi, On 11 Oct 2012, at 10:14, John MacAuley <john.macauley@surfnet.nl> wrote:
Peoples,
I was quite excited yesterday to be able to discover five of the deployed NSA. Some didn't return version information, but at least the endpoints were available. I spent some time running tests and realized that using the discovery interface is a simple way of determining NSA availability for management of connectivity. I was easily able to determine those NSA that were up or down. Obviously, this capability would be useful in production implementations.
Awesome :) I've been doing that by sending and cancelling a reservation, which worked a little bit, but this seems a better basic non-intrusive approach.
Further thinking on this topic has me considering adding a simple "hello" or "ping" type message to Discovery that could be used to determine NSA availability without the need to retrieve the interface versions document. We could also add simple information to the hello such as NSA uptime or a last restart token to permit a peer to determine if perhaps an audit should be performed. Pretty standard capabilities in production systems.
Sounds like a good idea. Perhaps also some info on the last time the topology was updated? Jeroen.
Hi On Thu, 11 Oct 2012, John MacAuley wrote:
Further thinking on this topic has me considering adding a simple "hello" or "ping" type message to Discovery that could be used to determine NSA availability without the need to retrieve the interface versions document. We could also add simple information to the hello such as NSA uptime or a last restart token to permit a peer to determine if perhaps an audit should be performed. Pretty standard capabilities in production systems.
Sure, I've seen similar stuff in several systems. What the heck is a restart token? I'd suggest the following: Current time in UTC format (time offsets in protocols is bad idea). - Makes it easy to detect clock skew (which can be a major pain). Time since started / uptime - In seconds, to make it independant of clock skew Time since last topology update (Jeroens proposal) - In seconds, to make it independant of clock skew Software and version (e.g. OpenNSA-git20121012) - Handy for figuring out if certain behaviour is due an odd version, etc. There could probably a couple of more things which could be handy. I'd restrict to things which can be found internally in process state or with really simple syscalls (btw. current time is usually not a syscall these days). So no going out to the hardware backend and seeing if it is alive or anything. Could potentially have something like "time since last successful backend interaction", which could be kept track off on the side. Please tell me this will be a perfectly normal RPC call without callback stuff. I think we should wait just a bit with adding this (now is better than never, but never is often better that right now). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
What the heck is a restart token?
System uptime really only applies to a single server, and becomes ambiguous when using multiple servers within a solution for either load balancing or redundancy. I the last system I designed we introduced a token that was returned through our system monitoring WSDL. If the token changed then there was either a system restart (in the unprotected case) or an activity switch in the protected case. The token only needed to change if the activity switch resulted in the possibility of lost data such as notification registration or service requests. The token was managed by the system and generated using whatever mechanism desired to provide uniqueness.
Please tell me this will be a perfectly normal RPC call without callback stuff.
Yes, it would be a synchronous call just like discovery.
I think we should wait just a bit with adding this (now is better than never, but never is often better that right now).
We have two options: 1. I add it to the discovery interface now so it is in version 1.0 and I never change it. 2. If we wait then it goes in a new service defined later. Currently the comments seem to be a 50-50 split on do it now or leave it until later. It was nice this week to have an independent way to monitor NSA availability, but I am easy on what we do. John.
I'm planning on implementing a multi domain path finder based on the new
topology description format and using the (probably experimental)
dynamic topology exchange in the first half of next year, and would
welcome the ability to have a health check mechanism in the first
version of the discovery service. So I vote to include this in 1.0.
HansT.
On 10/12/12 5:01 PM, John MacAuley wrote:
>> What the heck is a restart token?
> System uptime really only applies to a single server, and becomes ambiguous when using multiple servers within a solution for either load balancing or redundancy. I the last system I designed we introduced a token that was returned through our system monitoring WSDL. If the token changed then there was either a system restart (in the unprotected case) or an activity switch in the protected case. The token only needed to change if the activity switch resulted in the possibility of lost data such as notification registration or service requests. The token was managed by the system and generated using whatever mechanism desired to provide uniqueness.
>
>> Please tell me this will be a perfectly normal RPC call without callback stuff.
> Yes, it would be a synchronous call just like discovery.
>
>> I think we should wait just a bit with adding this (now is better than never, but never is often better that right now).
> We have two options:
> 1. I add it to the discovery interface now so it is in version 1.0 and I never change it.
> 2. If we wait then it goes in a new service defined later.
>
> Currently the comments seem to be a 50-50 split on do it now or leave it until later. It was nice this week to have an independent way to monitor NSA availability, but I am easy on what we do.
>
> John.
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg@ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
participants (5)
-
Hans Trompert -
Henrik Thostrup Jensen -
Jeroen van der Ham -
Jerry Sobieski -
John MacAuley