[Nml-wg] Serial compound relations

Roman Łapacz romradz at man.poznan.pl
Tue Dec 14 06:51:46 CST 2010 

W dniu 2010-12-13 23:43, Aaron Brown pisze:
> 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>
>

I like that modified example because it gives solutions for ordering and 
grouping the links of the circuit. Just one comment: I don't think we 
need 'id' attribute for ordering. Both attributes (id and idRef) in 
'link' element may confuse. One can use real id references (they are 
unique). See below (I removed the namespace for 'id' and 'idRef' 
attributes as I support dropping them; I also removed the type of link 
as its 'link' value may be default):


<nml:link id="urn:ogf:network:example.net:pathAC">
<nml:relation type="serialcompound">
<nml:link idRef="urn:ogf:network:example.net:segmentAB">
<nml:relation type="next-hop">
<link idRef="urn:ogf:network:example.net:crossconnect4-1_5-2" />
</nml:relation>
</nml:link>
<nml:link idRef="urn:ogf:network:example.net:crossconnect4-1_5-2">
<nml:relation type="next-hop">
<link idRef="urn:ogf:network:example.org:segmentBC" />
</nml:relation>
</nml:link>
<nml:link idRef="urn:ogf:network:example.org:segmentBC" />
</nml:relation>
</nml:link>


Cheers,
Roman




> 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
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nml-wg

More information about the nml-wg mailing list