Hi Freek/All; On 12/13/10 5:43 PM, Aaron Brown wrote:
On Dec 13, 2010, at 5:31 PM, Freek Dijkstra wrote:
Hey Jason,
Excellent discussion.
I attached the original example again, with one small change: segmentBC is now part of domain "example.org" instead of "example.net".
Remember, there are two distinct ways in the XML to "trace" the original path: - Using ports (if the sink of link A is port X, and the source of link B is also port X, you know that links A and B are connected in series) - Using explicit ordering (either order="1", order="2" or hop/nextHop).
Could you confirm that you want to see BOTH approaches in NML? (I think there are use cases for both.)
We're currently focussing on the second way. Let's continue that.
These two are not mutually exclusive, in fact I think that with Aaron's proposal both can exist happily. I would expect that within a domain the ports, nodes, and internal links would be well defined and utilizing the first method would be easier to do instead of relying on abstracted topology definitions. When instantiating cross domain communication there would be an increased need to exercise reference chasing (via on demand fetching), or to rely on pointers. Yes - I would want to see both approaches available, I would object to having multiple ways to implement the 2nd ('explicit' ordering) though. I can't speak to what is in use by the controlplane implementations, I was under the impression that it was path/hop. In the measurement world we do use the 'ordering' attributes for data from the traceroute tool but this is not for topology. I would prefer there be one accepted way to do such an operation instead of many. This simplifies implementation and removes confusion on the 'right' way to represent a concept. So my preference is to use the linked list method instead of using attributes to assign ids or orders.
I would vote for Aaron's proposal that I listed out in one of the first mails (no longer in this tread for some reason) to use pointer elements instead of count/type elements. I believe that respects the original hop/path idea a little closer. If the existing tooling can deal with a concept that 'follows' a path, that's a strong argument to remain with it even if the syntax changes slightly.
Could you rewrite the attached example to use the hop/nextHop approach? I think we should write both down in detail, and if we're happy with both examples, we should ask the group to vote (I currently have no preference).
Since I proffered the proposal, I'll take a cut at rewriting. The only big thing that would change is in the end-to-end "link" element:
Original:
<nml:link type="link" nm:id="urn:ogf:network:example.net:pathAC"> <nml:relation type="serialcompound" cl:count="3"> <nml:link nm:idRef="urn:ogf:network:example.net:segmentAB" cl:order="1"/> <nml:link nm:idRef="urn:ogf:network:example.net:crossconnect4-1_5-2" cl:order="2"/> <nml:link nm:idRef="urn:ogf:network:example.org:segmentBC" cl:order="3"/> </nml:relation> </nml:link>
Modified:
<nml:link type="link" nm:id="urn:ogf:network:example.net:pathAC"> <nml:relation type="serialcompound" cl:count="3"> <nml:link nm:id="l1" nm:idRef="urn:ogf:network:example.net:segmentAB"> <nml:relation type="next-hop"> <link nm:idRef="l2" /> </nml:relation> </nml:link> <nml:link nm:id="l2" nm:idRef="urn:ogf:network:example.net:crossconnect4-1_5-2"> <nml:relation type="next-hop"> <link nm:idRef="l3" /> </nml:relation> </nml:link> <nml:link nm:id="l3" nm:idRef="urn:ogf:network:example.org:segmentBC" /> </nml:relation> </nml:link>
This model could be extended beyond a simple ordered list to trees or other structures as well by introducing new relationships beyond "next-hop". I will note though that 'next-hop' is just an example name, and we should probably think about a more appropriate relation name.
I think that other ways to link the constructs together as Aaron mentions (beyond a simple list) addresses another NML need that was discussed at the last meeting: representation of broadcast and multicast.
Cheers, Aaron
Regarding the id/idRef distinction, I probably understand what you're saying in text, but I can't translate this to XML. Both statements below make sense, but they still seem to clash.
Instead of boring everyone with more prolonged discussions, its better for you to consult the documentation: https://forge.gridforum.org/sf/go/doc15644?nav=1 See the following sections for use cases: - 4.3.2.4 (use in the 'Metadata' element) - 4.3.2.8 (use in the 'Data' element) - 5 (basic explanation of chaining), specifically 5.1.3 for a 'merge' example and 5.2.1 for a 'operation' example. If you still have questions, lets take it offlist.
Typically 'id' is the definition of something, 'idRef' is used as a pointer to something previously defined. [...]
Let's take the example that domain example.org wants to say "urn:ogf:network:example.org:segmentBC is a segment of the end-to-end link urn:ogf:network:example.net:pathAC, but I don't know the names of other segments of this path".
If I follow the above statement, I'm inclined to write:
<nml:link id="urn:ogf:network:example.net:pathAC"> <nml:relation type="serialcompound"> <nml:link idRef="urn:ogf:network:example.org:segmentBC"/> </nml:relation> </nml:link>
<nml:link idRef="urn:ogf:network:example.org:segmentBC"> <!-- more properties of this link --> </nml:link>
What would 'more properties of this link' entail? You could also do it this way (in my opinion), but I am also not sure what you need to specify ...: <nml:link id="urn:ogf:network:example.net:pathAC"> <nml:relation type="serialcompound"> <nml:link idRef="urn:ogf:network:example.org:segmentBC"> <!-- more properties of this link --> </nml:link> </nml:relation> </nml:link>
Following these examples, I would claim that if some domain defines/owns an object, such as a link, they get to assign the 'id' field. If this is a GLIFesq definition I would assume this gives it a global scope.
For any other use that wishes to reference this original, there needs to be a clear semantic meaning that we are not trying to define (or re-define) the original. In the case of an end to end path that is using several links that belong to others (e.g. the control plane world), I am suggesting that if you intend to reference the individual components of the entire path, it is necessary to use idRefs instead of ids.
However, following the above text, example.org can only use the id attribute for it's own links, and should use idRef for the end-to-end link defined by example.net:
<nml:link idRef="urn:ogf:network:example.net:pathAC"> <nml:relation type="serialcompound"> <nml:link id="urn:ogf:network:example.org:segmentBC"/> </nml:relation> </nml:link>
(Obviously if example.net would announce the very same information, the id and idRef would flip in this example.)
Which one did you mean?
Since I am not an expert in the control plane world, so I will probably need to punt on this, but I would assume that the 'side' that imitated the end to end path gets to have the 'authoritative' copy (to borrow from the information distribution model used in the gLS), and thus would address it as 'id'. Other members of the path may want a copy ('non-authoratative') and would probably refer to it as 'idRef'. If example.net initiated, they call it by 'id'. If example.org has a copy, they use 'idRef'. Does this answer your question?
Regards, Freek
(PS: I trimmed the cc with people who are already on the NML mailing list. I also increased the cc limit, this should stop the bounces.) <serial_compound.xml><serial compound.png>
As for your attached topology/picture I maintain some of the same comments as prior: - Use of new elements seems unnecessary (hascrossconnect, hasport) when we have relations. - You still have not explained the difference between 'type=link' and 'type=crossconnect', and why this is necessary. I would like to understand this better. - I think all of the uses of org and net with id/idRef are correct, but the example is getting very long and hard to manage. Someone else should please verify. Thanks; -jason