[Nml-wg] Serial compound relations

[Aaron Brown]

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

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.
> 
>> 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.)
> <serial_compound.xml><serial compound.png>_______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nml-wg