- Nmc-wg - lists.ogf.org

Fwd: [I2-perfSONAR] TS modification proposal
by Jeff W. Boote 28 Jan '11

28 Jan '11

Hi All, We are looking at simplifying the query protocol used to interact with our TS service. Currently, it is pretty much the same protocol as is used to the LS so it has some bearing on the discussions in NMC. I don't believe NMC has taken up the effort to standardize the TS interactions yet, but it is obviously something we should look at once the 'Base' docs have been submitted. In any case, it would be helpful to get feedback from you all on these ideas. jeff Begin forwarded message: > From: Roman Łapacz <romradz(a)man.poznan.pl> > Date: January 27, 2011 7:41:06 AM MST > To: Aaron Brown <aaron(a)internet2.edu> > Cc: Andrew Lake <andy(a)es.net>, i2-perfsonar(a)internet2.edu > Subject: Re: [I2-perfSONAR] TS modification proposal > > W dniu 2011-01-26 15:06, Aaron Brown pisze: >> On Jan 25, 2011, at 4:01 PM, Andrew Lake wrote: >> >>> Hi Aaron, >>> >>> I like the idea of condensing the protocol down to something simpler like XPath. If we are going to take a step like this, I think it might also be worth exploring non-XPath options as well. For example, could we break the queries down into a series of well-defined XML elements that compose the query? This could have the advantage that rather than our schema documents just having a string field where you stick the Xpath we'd have some elements defined to specify things like return type (e.g. domains, nodes, ports, or links), query constraints (e.g. id== x, bandwidth>= 3Gbps, etc). Those are just examples off the top of my head so we'd have to think through all the options. This could allow us to enforce a constrained set of queries easier and in a way more transparent to a user than coming up with an XPath subset. It may prove that our use cases make such a schema too complicated, but I think it might be worth thinking about as part this effort. > > This could be also suitable for LS queries. Could the OGF NMC mailing list be CCed in this discussion? > > Cheers, > Roman > > >> We could probably sit down and try to come up with use-cases and/or examples at Joint Techs. >> >> Cheers, >> Aaron >> >>> Andy >>> >>> On Jan 25, 2011, at 3:22 PM, Aaron Brown wrote: >>> >>>> All, >>>> >>>> As part of the circuit monitoring work, I'm making modifications to the topology service to support the new topology format. Currently, the query method is XQuery, but in looking at the types of requests that get sent to the TS, most are XPath, or could be handled by XPath. With that in mind, I was thinking it might make sense to modify the TS protocol to use a limited XPath instead of XQuery. Using XPath statements has the benefit that it is reasonably straight-forward to convert XPath statements to work against a different backend (e.g. a SQL backend, or whatever). Presumably, it'd make sense to only specifically support a subset of the XPath syntax to make it easier to use against different backends. >>>> >>>> In terms of changes to the TS, supporting XPath doesn't require any major changes. We'd need to change the protocol to accept the XPath statement, and then have a system to validate the XPath (to make sure it's only the subset or whatever). Sleepycat XML DB accepts XPath expressions directly so the TS wouldn't need any changes to handle that. >>>> >>>> As part of this modification, I was thinking of switching the query response slightly. Currently, the response to queries combines all the results into a single datum. By splitting them out, it makes it easier to differentiate non-XML results (e.g. give me the descriptions of all ports). Not a big change, and probably not all that big a deal either way. >>>> >>>> Cheers, >>>> Aaron > >

2 1

Next Call 1/6 16:00 UTC
by Jason Zurawski 17 Jan '11

17 Jan '11

Hi All; We will have our next NMC call this Thursday at 16:00 UTC (11am EST / 5pm CET) using the hungarnet MCU. The agenda and call details will be posted here: https://forge.gridforum.org/sf/wiki/do/viewPage/projects.nmc-wg/wiki/201101… Thanks; -jason

4 4

12/9 Meeting Canceled (?)
by Jason Zurawski 08 Dec '10

08 Dec '10

All; I will be unable to attend the meeting tomorrow, so I propose we cancel. If someone else would like to lead/take notes feel free to go on without me. Otherwise we can pick up again after the holidays (Thurs Jan 6th). Thanks; -jason

1 0

urn:ogf syntax
by Freek Dijkstra 13 Nov '10

13 Nov '10

All, I'm cross-posting this to NM, NMC and NML, who are currently using the urn:ogf:network syntax. This namespace is currently not formalized. To this end, 3 documents will be created: - an Internet-Draft with syntax description and delegation of urn:ogf - a GFD with procedural description for subdelegations in urn:ogf - a GFD with syntax and subdelegation of urn:ogf:network The first document has been created, and is available at http://tools.ietf.org/html/draft-dijkstra-urn-ogf You can leave feedback at https://forge.gridforum.org/sf/go/artf6459 Or download the (XML) document source code at: https://forge.gridforum.org/sf/scm/do/listRepositories/projects.nml-wg/scm Regards, Freek Dijkstra

2 1

OGF 30 Notes + Next Meeting
by Jason Zurawski 08 Nov '10

08 Nov '10

Hi All; Notes from the OGF 30 sessions are posted: 1) https://forge.gridforum.org/sf/wiki/do/viewPage/projects.nmc-wg/wiki/201012… 2) https://forge.gridforum.org/sf/wiki/do/viewPage/projects.nmc-wg/wiki/201010… Due to SC10 taking ESnet and Internet2 employees, I propose the next meeting to be held Dec 9th. Thanks; -jason

2 1

Response codes:
by Michael Bischoff 05 Nov '10

05 Nov '10

Hello All, Ok to take in the things discussed at ogf30 with regards to capabilities: A very usefull comment was that SIP also modeled their response codes in a similar way as http does which we also basing ours off, so lets learn from both: http://en.wikipedia.org/wiki/List_of_SIP_response_codes Proposed changes from comments: > http://perfsonar.net/status/ > informational/ > too_busy > backend_service_not_available > protocol_bridge Too_busy, backend_service_not_available and protocol bridge seem like they are errors. informational seems to be used in http to advertise things that happened during the exchange but didn't have an effect upon successfully completing it. I'm guessing you could advertise deprecation here like "your still using version '1.0' please move to '1.1' as this service supports it" though the LS should iron this out. SIP's ringing, queued etc seems to indicate that they are dealing with more statefull connections. > successful/ > query_accepted/ > echo/ > registration/ > deregistration/ > keepalive/ Could probably suffice with just an 'ok' here as a client know what he sends he already knows what was succesfull > redirection/ not modified might be usefull for the LS, but thats completely subject to the architecture which there is no consensus upon. > clienterror/ > bad_request/ > unauthorized/ > method_not_allowed/ > not_acceptable/ > message_not_allowed/ > event_type_not_allowed/ > expected_response_tool_arge/ > servererror/ > internal_server_error/ the end of internal_server_error/ can probably be dropped as http://perfsonar.net/status/servererror/internal/ gives you the same amount of information as http://perfsonar.net/status/servererror/internal_server_error/ > service_unavailable/ not sure if we could just say unavailable, do we have the notion of more then one service at one spot? > protocol_not_supported/ > unknown_version/ > data_fetch_error/ Could probably be data_fetching or processing Categorizing should be like: https://docs.google.com/drawings/pub?id=1IXUZUSmy83cAJlpiHR96BGkBdgajXKu5IO… For every type of error one should assert if there is a usecase in which it is recoverable and if there is a usecae where it's unrecoverable. Should there be usecases for both recoverable and unrecoverable then there should also be two status codes for that single type of error, this to allow a client to take a appropriate action.

2 1

Capabilities
by Michael Bischoff 29 Oct '10

29 Oct '10

Hello All, Ok to take in the things discussed at ogf30 with regards to capabilities: (this time for real in my last email it should have said status/error codes) We touched upon Service types, for backwards compatibility reasons at least it was favored to have them around, this caused us to reiterate about nmc and fixing things that are in current use. It was suggested to have an appendix/supplement or attachment. With what we fixed and why we fixed it. I'm not sure how complete the consensus was but from what I could gather was that as long as there is still information offered that allows us to the things that we previously used the service types for they can be removed. So we need to make sure that we identify how they are used currently and make sure that we end up with a form of advertising capabilities that suffices for those usages. EventTypes(in requests) where touched upon I indicated that I completely ignored servicestypes and relied strictly upon event types. Now as commented in our calls: As clients and services should support whole scenario's which could entail more then one request/response, eventypes do not completely define the capabilities as you also need to define the message exchange patterns. The direction was that we could summarize both patterns and eventypes used in those patterns as a 'protocol'*. *should we come up with a different label for 'protocol' in this context? Fine graininess As such a 'protocol' would be extension of an other protocol(except for the base) you would end up with a tree now for the ls you'd probably have to advertise the whole path from root(base protocol) to leaf(protocol x) If you want to avoid adversing all of those one could mark protocols as abstract and concrete and not allow advertisement of abstract protocols and not allowing extending concrete ones. it probably depends on the fine-graininess what works here. as well as how well a tree structure works what if a protocol has a scenario where it want to combine two branches to enable something new - or is this too theoretical as we currently can fit everything in here then again there aren't many scenarios that go beyond request/response atm. Perhaps the following should be in a different email: (warning length) - thinking about it now though it might not be too much of a problem as you could just advertise: perfsonar/base/ma/rrd or http://personar.net/capability/ma/rrd or http://personar.net/capability/archive/rrd and http://personar.net/capability/archive/netflow http://personar.net/capability/real-time/netflow though I already notice again that the notion of mp ma is limiting us we should really view it as read/write/time context or perhaps better formulated query/store/time. Also our notion of rrd and sql service is perhaps the wrong perspective as it tells me nothing about the information I can obtain from it. You can store sales data in both of them which might not be network measurement data to begin with. Well what are you quering from a rrd service? it's trend data right? Perhaps we should rename the rrd to trendservice, at least that way we know something about the data we can obtain from it rather then how it gets stored. http://personar.net/capability/archive/trend Though trends are always about the past, so something we obtain from archives: http://personar.net/capability/trend though it's incomplete as we do not know what the trend is of, sure when we add a network element in the mix we know something more specific about it but it could still be ping data, netflow data, throughput, utilization http://personar.net/capability/trend/ping http://personar.net/capability/trend/netflow http://personar.net/capability/trend/utilization ping data an aspect of the of the characteristic 'responsiveness' http://personar.net/capability/trend/responsiveness netflow is probably dataflow http://personar.net/capability/trend/dataflow utilization can go unchanged. http://personar.net/capability/trend/utilization now is ping data the only aspect of responsiveness? should we add another level? http://personar.net/capability/trend/responsiveness/ping ? it gets fuzzy. same with the ordering you could also go: http://personar.net/capability/responsiveness/ping/trend I'le leave it up to you all to figure out what kind of issues present themselves here. Best regards, Michael

1 0

No Call Today
by Jason Zurawski 28 Oct '10

28 Oct '10

All; Reminder: due to OGF we will not have a weekly call. Thanks; -jason

1 0

Multilayer E2Emon
by Freek Dijkstra 26 Oct '10

26 Oct '10

Hi all, Would there be time at the OGF upcoming week to discuss how to deal with multilayer E2E monitoring? Basically, we have been trying to implement something like that, but got stuck, since the current XML was not going to work no matter how we bend it. Peter Tavenier (a colleague of mine) and I asked for opinions on the perfsonar-dev list, explaining our rational for doing this. See: https://lists.internet2.edu/sympa/arc/perfsonar-dev/2010-09/msg00010.html and more mails in that thread. Frankly, the discussion that followed in our group at SARA reminded me a bit on discussion we had on the NML list 3 years ago, and I'm not sure I want to repeat that. Also I prefer to have a slightly faster time progressing time. :~) So I was hoping to get some feedback how to proceed and if other share this interest. Regards, Freek

5 6

Call today - 10/14 15:00 UTC
by Jason Zurawski 14 Oct '10

14 Oct '10

Gang; Sorry for the late notice, but we will have a call today at 15:00UTC on the hungarnet MCU, agenda will be formed here: https://forge.gridforum.org/sf/wiki/do/viewPage/projects.nmc-wg/wiki/201010… Thanks; -jason

1 1