August 2005 - nm-wg - lists.ogf.org

Re: [I2G2-Proto] NMWG schema comments (mainly about IPv6 and multicast)
by Jason Zurawski 26 Aug '05

26 Aug '05

Jerome; I am cc'ing this to the nm-wg list as well to solicit additional comments. > COMMENT #1 > ---------- > As we discussed a bit in Paris, seems there is a problem in nmtopo.rnc > with: > Endpoint = > attribute value { xsd:string } & > attribute type { xsd:string } & > attribute port { xsd:int }? > > If the type is a hostname then you have no way to know if it's related > to an IPv4 or an IPv6 measurement. I propose instead: > > Endpoint = > attribute value { xsd:string } & > attribute type { "IPv4address" | "IPv6address" | "IPv4hostname" > | "IPv6hostname } & > attribute port { xsd:int }? In the past we have tried to avoid enumerations because of tooling issues (schema generation, conversion, validation) as well as not wishing to limit potential choices at the schema level. I feel that strict checking is best left to reference implementations that know what values they wish to accept and reject. Keeping the schema general allows for easy extension; more specific schemas can be build from our atoms to better fit the needs of designer. > > COMMENT #2 > ---------- > In nmtopo.rnc > > Address = > xsd:string & > attribute type { xsd:string } > > I think we should give a list instead of letting things flexible: > > Address = > xsd:string & > attribute type { "IPv4" | "IPv6" } > My previous statement applies here as well. It is true that there are probably not many choices that would be used in the type field, but limiting the field would still sacrifice the extensibility and generality we wanted in a base schema. > > COMMENT #3 > ---------- > Just a question. I don't understand InterfaceContent in nmwgtopo.rnc > > There is ipAddress and ifAddress. What is the difference? I guess > ipAddress is the address used to reach the router while ifAddress is > configured on the monitored interface? Maybe we should make that more > explicit? > The ipAddress more or less the address of the chassis; it is an administrative address that may be running some form of management software. The ifAddress is the particular address of an interface. We have kept both as a courtesy to implementation designers; this may prevent a forced lookup of an address saving valuable time and effort. > > COMMENT #4 > ---------- > Note an interface in IPv6 has by nature several IPv6 addresses. I mean > unicast addresses here. There are link-local addresses (often only one > derived from physical interface address) and one or more global > unicast addresses. > It is I think necessary that ifAddress in InterfaceContent of > nmwgtopo.rnc becomes a vector instead of just a single element? I > guess we should display as well the link-local address... maybe having > some type for it like "IPv6-LL") > We have only briefly dealt with ipv6 issues in the schemas, and we do hope to encompass more features in the future. It is possible to have a 'list' element in a schema, although i am unsure of what ramifications (if any) it would bring to the current design. This is something we should consider. > COMMENT #5 > ---------- > In iperf.rnc, we have > > element iperf:protocol { xsd:string }? & > > I would detail here as well the protocols allowed: > > element iperf:protocol { "IPv4" | "IPv6" }? & > > unless protocol refers to upper layer protocols? > This actually refers to the protocol iperf is using to test (udp, tcp). It refers directly to a command line argument in the program. > COMMENT #6 > ---------- > About multicast now to have more fun ! > Note that some stacks make it possible to send a ping to a multicast > address and then get all ICMP responses. Personnaly I really like this > feature: > > > ping6 ff1e::1:f00d:beac > PING6(56=40+8+8 bytes) 2001:660:3001:4001:2c0:4fff:fe95:b465 --> > ff1e::1:f00d:beac > 16 bytes from 2001:660:3001:4001:201:2ff:feb4:a3f8, icmp_seq=0 hlim=64 > time=0.421 ms > 16 bytes from 2001:660:3001:8002:2b0:d0ff:fe9a:4359, icmp_seq=0 > hlim=62 time=6.343 ms(DUP!) > 16 bytes from 2001:660:3302:2821:250:fcff:fe0b:9966, icmp_seq=0 > hlim=56 time=10.134 ms(DUP!) > > The problem is that it's now becoming a problem with the endPointpair > definition (that implies if I'm right that ICMP reply is sent by the > destination of the echo request...) > > We don't have this issue with traceroute (at least not now!) But we do > have this issue with iperf measurements. It's a cool feature to send > high volume of traffic using iperf and then to see how hosts who > joined the group receive the flow. The endPointPair thing might cause > problems here. > It is possible to define new subject types when something doesn't fit your needs, something such as mutlicastGroup (or even multicastGroupPing as a subject in the ping.rnc if it is extremely specific) would more than likely be needed in this situation. Using the base and examples as a road may we have always hoped that interested parties would add to our work. > What's your view here? Answers like "we don't care about multicast" > not being accepted :p > We feel that other measurements, mutlicast, and other situations not modeled in the the base schemas should (and will) be developed by interested members of the community; people who posses a lot more domain knowledge of particular situations than we do. We welcome all to submit proposals/fixes when something doest appear right. > Maybe more to come later. happy to receive some answers, as I'm quite > new in rnc, it's highly possible you need to correct me at some points. > > Jerome > -jason

3 4

[Fwd: Re: [I2G2-Proto] NMWG schema comments (mainly about IPv6 and multicast)]
by Jason Zurawski 26 Aug '05

26 Aug '05

FYI, this didn't make it to the list it seems. -jason

1 0

documents roadmap
by Leese, MJ (Mark) 17 Aug '05

17 Aug '05

Hi folks, You may recall that we were recently asked to give the Area Director an overview of any documents we had in the pipeline. The final details (that I've now submitted) are below. Please let me know if there's anything you'd like to see changed. Cheers, Mark. Deliverable: Network Measurement Request and Publication Schemas v1.0 Type: Experimental First Draft: Nov-05 Public Comment: Feb-06 Published: Apr-06 Adoption Level: N/A Dependent Specifications: N/A Grid Role: Provide historical record of past work Description: Targetted at Grid applications, middleware and network operators alike, the version 1 schemas were NM-WG's first pass at producing XML schemas to facilitate the unified requesting and sharing of network measurement data. The work highlighted some gaps in group thinking, which will be addressed in version 2. It should be noted that versions 1 and 2 are not backwards compatible. This deliverable documents 18-24 months of schema work, providing a historic record of the work and lessons learned. It also demonstrates that the group has been productive, even if the results will not be "brought to market". Deliverable: Network Measurement Schemas v2.0 Type: Experimental First Draft: Mar-06 Public Comment: May-06 Published: Sep-06 Adoption Level: To be implemented by DANTE, ESNet and Internet2 in the first instance Dependent Specifications: N/A Grid Role: Informs app and m/ware design. Recommendations hopefully adopted by network operators. Description: This deliverable will document NM-WG's version 2 schemas, and gather together comments on the sample software implementations (developed by group members) that will use them. It is hoped that after responding to the user and public comments (perhaps by further modifying the schemas) that the experimental document can be used as a basis for developing a full recommendation. Deliverable: Network Measurement Use Cases Type: Informational First Draft: Jun-06 Public Comment: Sep-06 Published: Dec-06 Adoption Level: N/A Dependent Specifications: N/A Grid Role: Informs, validates and justifies other NM-WG work Description: Complementing other NM-WG work and use case deliverables produced elsewhere in GGF, this document will identify and analyse ways in which network monitoring can be applied in the Grid domain. It is assumed that the use cases will have some relevance to the NM-WG schemas, although that not need be the case. Further, the use cases can be network/Grid operations or middleware focused.Long timescales exist due to a lack of additional effort to produce this document.

1 0

today's call
by Leese, MJ (Mark) 16 Aug '05

16 Aug '05

Hi folks, Notes on today's conference call are available here: http://nmwg.internet2.edu/minutes/2005/nmwg16Aug2005.txt Please let me know if there are any corrections to be made. As advance notification, we're planning to hold working sessions at GGF15 in Boston on 3rd-6th October, together with a session to demo relevant schema work from group members, and the usual open session to feedback progress to "nm-wg tourists". We'll aim to have a phone line available for those who can't make it in person. Eric or I will arrange the next call when there's progress to report or something to discuss :) Hope you're all well, Mark. Mark Leese Network Development Engineer tel: +44 (0)1925 603730 CCLRC, Daresbury Laboratory http://gridmon.dl.ac.uk/~mjl

1 0

current/planned documents, and WS tutorial
by Leese, MJ (Mark) 16 Aug '05

16 Aug '05

Hi folks, We were recently asked by the Area Director to provide an overview of any documents we have planned or are currently working on. In advance of tomorrow's conference call, and in case you would like to make any comments, the details I'm PROPOSING we return are at the bottom of this mail. The details for these TWO documents are based on several discussions we've had since the Seoul GGF in March. The only things I probably need to comment on: - For now I've left the "Adoption Level" field blank, as I'm not too sure about its purpose. - The second document's title refers simply to "Network Measurement Schemas". We're moving away from the the fixed request-response model, e.g. we could produce NM-WG schemas to allow people to register for event notifications. As a result, we drop "request and publication" from the title. - Sticking with the second document's title, do we want to include a version number? I've included "v2" but this is really something we do internally. Some might argue that we don't want to confuse people external to NM-WG (and indeed GGF) with this, and that what WE refer to internally as version 2 should be labelled as such externally, so that it appears as THE definitive NM-WG schemas. We were also asked to think about any holes or gaps in our Infrastrucure area. The area I'm not so sure about, but in terms of NM-WG I think we also need some kind of use-cases document. Whilst I think this is important, I don't think we have the effort to proceed with it right now. I think the effort we have would be better targetted elsewhere. Does anyone agree/disagree? Perhaps we can discuss a use-cases doc during tomorrow's call, and include something in our return to the Area Director. Following up on the interest shown during the last call, I'm looking at arranging for Marlon Pierce from Indiana to give us a Web Service tutorial at the next GGF (Boston, 3-6 October). To do this it looks like I will need to put together a proposal for a community track event. If anyone has any suggestions or specific issues they would like covered, please let me know asap. Speak to you tomorrow :) Mark. Deliverable: Network Measurement Request and Publication Schemas v1.0 First Draft: Nov-05 Public Comment: Feb-06 Published: Apr-06 Adoption Level: Dependent Specifications: NA Grid Role: Provide historical record of past work Description: Targetted at Grid applications, middleware and network operators alike, the version 1 schemas were NM-WG's first pass at producing XML schemas to facilitate the unified requesting and sharing of network measurement data. The work highlighted some gaps in group thinking, which will be addressed by the version 2 schemas. It should be noted that version 1 and version 2 are not backwards compatible. This deliverable documents 18-24 months of schema work, providing a historic record of that work, and in particular the lessons learned. As a slight aside, it also demonstrates that the group has been productive, even if the results will not be "brought to market". Deliverable: Network Measurement Schemas v2.0 Type: Experimental First Draft: Mar-06 Public Comment: May-06 Published: Sep-06 Adoption Level: Dependent Specifications: NA Grid Role: Informs app and m/ware design. Recommendations hopefully adopted by network operators. Description: This deliverable will document NM-WG's version 2 schemas, and gather together comments on the sample software implementations (developed by group members) that will use them. It is hoped that after responding to the user and public comments (perhaps by further modifying the schemas) that the experimental document can be used as a basis for developing a full recommendation.

2 1

reminder - call this afternoon
by Leese, MJ (Mark) 16 Aug '05

16 Aug '05

Hi folks, Just a reminder that we have a call this afternoon, at the usual time. Call in details are on the NM-WG website here: http://nmwg.internet2.edu/meetings.html Suggestions for things to discuss: - plans for NM-WG at GGF15 (Boston, 3-6 October) this would include the combined EGEE/perfSonar demo the deadline for requesting sessions is 2nd September - V2 progress and plans - brain teaser: what DAMED style metric names should be used to identify the results of a traceroute test? The EGEE guys and I were thinking of: + path.Hoplist for the path info, and + path.Hoplist.Delay.Round-trip for the test probes' RTT data (what we're asking for is the RTT of each hop in a path) Speak to you later :) Cheers, Mark.

1 0

[Fwd: [I2G2-Proto] Announcing the completion of phase 0 of prototype (finally :) )]
by Jason Zurawski 04 Aug '05

04 Aug '05

FYI. Anyone interested in downloading the code for demo purposes from the development CVS should contact Jeff Boote (boote(a)internet2.edu) for an account. -jason

2 1

***SPAM*** WINNING NOTICE
by lucky day 03 Aug '05

03 Aug '05

FROM: GOVERNMENT ACCREDITED LICENSED LOTTERY PROMOTERS. WINNING NOTICE . FOR CATEGORY \"A\" WINNER Dear Lucky Winner, RE: ELEKTRONIK LOTTO PROMOTION PRIZE AWARDS WINNING NOTIFICATION We are pleased to inform you of the result of the just concluded annual final draws of Lotto International Netherlands programs. The online cyber lotto draws was conducted from an exclusive list of 25,000 e-mail addresses of individual and corporate bodies picked by an advanced automated random computer search from the internet. No tickets were sold.After this automated computer ballot, your e-mail address emerged as one of two winners in the category \"A\" with the following: Ref Number: PC 390 ES 214 Batch Number: 26371545-LNI/2005 Ticket Number: PCP 002 871 You as well as the other winner are therefore to receive a cash prize of 1,500,000.00. (ONE MILLION, FIVE HUNDRED THOUSAND EURO ONLY) each from the total payout.Your prize award has been insured with your e-mail address and will be transferred to you upon meeting our requirements,statutory obligations, verifications, validations and satisfactory report. To begin the claims processing of your prize winnings you are advised to contact our licensed and accredited claims agent for category \"A\" winners with the information below: Barrister Evans Moore. Remittance Department Director, Tell: +0027 83- 511- 4244 E-mail barristerevansaz(a)yahoo.com , barristerevansmoore(a)webmail.co.za You are also advised to provide him with the under listed information as soon as possible: 1. Name in full 2. Address 3. Nationality 4. Age 5. Occupation 6. Phone/Fax 7.Account Details NOTE: All winnings must be claimed not later than 14 days. After this dateall unclaimed funds would be included in the next stake. Remember to quote your reference information in all correspondence. You are to keep all lotto information away from the general public especially your reference and ticket numbers. (This is important as a case of double claims will not be entertained).Members of the affiliate agencies are automatically not allowed to participate in this program. Thank you and congratulations!!! Yours faithfully, Mrs. Lynn Rowlands, Games/Lottery Coordinator. Lotto International Netherlands www.lotto.nl This email may contain information which is confidential and/or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient,be aware that any disclosure, copying, distribution or use of the contents is prohibited.If you have received this electronic transmission in error,please notify the sender by telephone or return email and delete the material from your computer.

1 0

today's call, next call
by Leese, MJ (Mark) 02 Aug '05

02 Aug '05

Hi folks, Notes on today's conference call are available here: http://nmwg.internet2.edu/minutes/2005/nmwg02Aug2005.txt Please let me know if there are any corrections to be made. The next call will be in two weeks, Tuesday 16th August at the usual time. The latest phone number is now on the NM-WG website. Until further notice, we'll use this number everytime we have a call. During the upcoming call we'll discuss the proposed demos for GGF15 (Boston, 3-6 October). Please let me know if you have any additional agenda items. Look forward to speaking to you then! Mark. Mark Leese Network Development Engineer tel: +44 (0)1925 603730 CCLRC, Daresbury Laboratory http://gridmon.dl.ac.uk/~mjl

1 0

perfSonar Status
by Jason Zurawski 02 Aug '05

02 Aug '05

All; Here is a snapshot at the status of perfSonar: > The service has been deployed and rigorous testing is taking place. > the key request seems to be working fine but we are facing problems > reading rrd files in the tomcat environment! We hope to sort out this > issues as soon as possible. > > Deployment at GEANT: yes. I can say that prototype stages will be > deployed and GEANT data will be available even though the extent will > be very much limited. > > about Internet2 and other NRENs: By september end, we would like to > have data from many European NRENs and hope that prototype will be in > a stage acceptable to them. I am not sure about Internet2. I can ask > Eric in the next call. > > The main concern could be security (authentication and authorization) > which hasn't been implemented in the prototype. So data can be > accessed by anybody. But this should still be ok for demo purposes. > > Hope these answer your concerns. > > Loukik. -jason

1 0