[nm-wg] Re: [I2G2-Proto] NMWG schema comments (mainly about IPv6 and multicast)

[Jason Zurawski]

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