[Nml-wg] Serial compound relations

[Jason Zurawski]

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