Re: [I2G2-Proto] NMWG schema comments (mainly about IPv6 and multicast)
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
Hi there, I will add my two cents, with the caveats that I'm not very directly involved in this work any more and I'm only on my first cup of coffee.
Endpoint = attribute value { xsd:string } & attribute type { "IPv4address" | "IPv6address" | "IPv4hostname" | "IPv6hostname } & attribute port { xsd:int }?
Address = xsd:string & attribute type { "IPv4" | "IPv6" }
I agree with both of you here, so why not make a specialized sub-schema for IP addresses? In a new namespace, perhaps "http://ns.ggf.org/nmwg/topo/ip/" or whatever the current incantation is. At the risk of being a strict constructionist, I suggest you could even have "../ip/4/" and "../ip/6/" sub-schemas to describe specifics of each protocol version. Either way, I think it's great if someone tries to sub-class all these things that are intended as general, as it is often the case that something too specific has crept in, like a thief in the night.
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.
huh? if it's the "administrative" address, you should call it that. But I don't see this as generally applicable. Let caching be handled by the implementation. I would think that what you need is the interface name/index and addresses. Given the note below, organized as a list of (address, interface name) pairs, where either or both can be repeated. Imitating the brilliant representation of traceroute :-) -Dan
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.
Dan Gunter wrote:
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.
huh? if it's the "administrative" address, you should call it that. But I don't see this as generally applicable. Let caching be handled by the implementation.
I would think that what you need is the interface name/index and addresses. Given the note below, organized as a list of (address, interface name) pairs, where either or both can be repeated. Imitating the brilliant representation of traceroute :-)
Dan, It is not a caching issue. It is that ifName & IP Address are not sufficent to uniquely identify an interface in all cases. IP addresses are not guaranteed to be unique. Interface names are not unique. For example, we have plans to deploy around 4 different DNS servers using anycast. All will have the same IP address. All the different router interfaces connected to the different servers will have the same IP address. It is possible that they could all be on ge-1/0/0. The name of the router or chassis is required to distinguish between the connection to a DNS server in California vs one in New York. I think this concept is generally applicable. Especially if you consider deployment in networks that use nat or private address space where you could have lots of collisions, not just a couple per network. --Joe
-Dan
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.
Dan, It is not a caching issue. It is that ifName & IP Address are not sufficent to uniquely identify an interface in all cases.
OK, clearly I didn't understand this whole issue, sorry. What you're saying is that you need N additional identifiers in addition to IP and interface. So: is N=1 sufficiently general? Or should the model allow N=2+ as well? (IP=x,IF=y,chassis=z,...) -Dan
IP addresses are not guaranteed to be unique. Interface names are not unique. For example, we have plans to deploy around 4 different DNS servers using anycast. All will have the same IP address. All the different router interfaces connected to the different servers will have the same IP address. It is possible that they could all be on ge-1/0/0. The name of the router or chassis is required to distinguish between the connection to a DNS server in California vs one in New York.
I think this concept is generally applicable. Especially if you consider deployment in networks that use nat or private address space where you could have lots of collisions, not just a couple per network.
--Joe
Dan Gunter wrote:
Dan, It is not a caching issue. It is that ifName & IP Address are not sufficent to uniquely identify an interface in all cases.
OK, clearly I didn't understand this whole issue, sorry. What you're saying is that you need N additional identifiers in addition to IP and interface. So: is N=1 sufficiently general? Or should the model allow N=2+ as well? (IP=x,IF=y,chassis=z,...)
I can't think of any case where (IP,ifName,Chassis) does not uniquely identify an interface. However to be general, it probably makes sense to allow this to be extended. Thanks Joe
-Dan
IP addresses are not guaranteed to be unique. Interface names are not unique. For example, we have plans to deploy around 4 different DNS servers using anycast. All will have the same IP address. All the different router interfaces connected to the different servers will have the same IP address. It is possible that they could all be on ge-1/0/0. The name of the router or chassis is required to distinguish between the connection to a DNS server in California vs one in New York.
I think this concept is generally applicable. Especially if you consider deployment in networks that use nat or private address space where you could have lots of collisions, not just a couple per network.
--Joe
participants (3)
-
Dan Gunter -
Jason Zurawski -
Joe Metzger