[Nml-wg] Serial compound relations

[Freek Dijkstra]

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.

> 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).




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.

> 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>

> 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?

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.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: serial_compound.xml
Type: text/xml
Size: 2788 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nml-wg/attachments/20101213/568f3b29/attachment-0001.xml 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: serial compound.png
Type: image/png
Size: 66539 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nml-wg/attachments/20101213/568f3b29/attachment-0001.png