[Nml-wg] Serial compound relations

[Jeff W. Boote]

On Dec 13, 2010, at 5:01 PM, Jason Zurawski wrote:

> 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 do not believe that should be a determination made in the context of NML. NML should be used to define valid syntax. Deciding when different specific uses of the syntax make the most sense should be done in the context of a specific application or protocol. Lets keep those discussions separate for now. NML should be flexible enough to support multiple use cases, and there is no reason to limit this at this level.

If we want to have the other discussion, lets do it using real examples, discussing semantic needs of specific applications and protocols.

jeff

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