Sorry Hans, I have been sick since Monday and squeezing in work while I am able.  This one required some thinking so I had hoped to get back to it when I was feeling a bit better.

The intention of pathTrace was that all NSA in the network must participate or it would not function correctly.  This would make your situation a deployment issue.  Although I did not write anything down specifically, I assumed no pathTrace would be returned by an NSA unless all child NSA involved in the connection returned a pathTrace successfully.  

I do not like the first solution you proposed below because unless I look in network topology (or more specifically a uPA) I would not know there was a segment missing, and therefore, I may incorrect apply policy to the resulting pathTrace.

You second solution provides us with a way to proceed that identifies there are segments with information missing.  This will allow an aggregator to identify a child NSA did not support the pathTrace capability, as well as a uPA performing policy enforcement to decide if this missing information should result in a rejection of the reservation request.  In the case of CHAIN you will lose all pathTrace downstream of a non-participating NSA, or in TREE all branches below the non-participating NSA.

It looks like we have two valid options:

1. If a child NSA involved in a reservation does not return a populated pathTrace element then the aggregator NSA should also not return the pathTrace up the tree, thereby invalidating the feature.  The root aggregator would get partial results and treat this as if the feature is not implemented in the network containing the connection segment involved, so no pathTrace would be send down in the commit request.  Each uPA would then apply whatever policy they can for the condition where no pathTrace is provided.

2. If we allow for the incomplete elements to be added to the pathTrace then the aggregator can determine there are parts of the network not supporting pathTrace, and still allow partial trace information to be sent to the uPA as part of the commit.  This would provide more detail than no pathTrace, but still allow the uPA to see some information is missing.

#2 also allows you to determine the NSA not supporting pathTrace while #1 does not.

Thoughts?

John

On 2016-11-30, at 4:13 AM, Hans Trompert <hans.trompert@surfnet.nl> wrote:

Hi,

We just finished the implementation of pathTrace in our BoD uPA and Safnari aggregator and decided to leave out any segment information for NSA that do not support pathTrace, like in the first example, as this most closely follows the behavior description in the "Applying Policy in the NSI environment" document.

My personal choice would be to implement the behavior as described by the second example ...

Cheers,
    HansT.

On 28/11/2016 14:19, Hans Trompert wrote:

Hi,

While implementing the pathTrace as described in gfd-r-nsi-policy-public-comment-v6 I stumbled on the following. If an uPA does not support pathTrace it is possible for an AG to detect this if it receives a pathTrace without a path element in the reserve.cf. The text states:

If an AG has done additional path finding on the reserve.rq it MUST assemble the child path within the pathTrace element in topological order.  The order number in the segment MUST start at zero (0) and MUST be incremented by one (1) for each new segment.

Does this mean that the AG should only number the segments from path elements that were actually returned by its children and ignore empty pathTrace elements, or should the AG detect an empty pathTrace element and add an empty segment to the trace?

For example, if the uPA of aruba and bonaire do support pathTrace and curacao does not, should it return:

<tns:pathTrace xmlns:tns="http://schemas.ogf.org/nsi/2015/04/connection/pathtrace"
        id="urn:ogf:network:grenada.net:2013:nsa-aggr">
    <connectionId>urn:uuid:59d6c0b2-a8e0-4583-ae8a-0fc84eb89f07</connectionId>
    <path>
        <segment id="urn:ogf:network:aruba.net:2013:nsa" order="0">
            <connectionId>urn:uuid:71d30ed8-f130-4522-a5c5-3d6d2e96fb1e</connectionId>
            <stp order="0">urn:ogf:network:aruba.net:2013::stpA?vlan=1790</stp>
            <stp order="1">urn:ogf:network:aruba.net:2013::curacao?vlan=1790</stp>
        </segment>
        <segment id="urn:ogf:network:bonaire.net:2013:nsa" order="1">
            <connectionId>urn:uuid:b1f0277d-63d5-4e5e-85e8-acd11a5baab9</connectionId>
            <stp order="0">urn:ogf:network:bonaire.net:2013::curacao?vlan=1790</stp>
            <stp order="1">urn:ogf:network:bonaire.net:2013::stpZ?vlan=1790</stp>
        </segment>
    </path>
</tns:pathTrace>

Or should it return:

<tns:pathTrace xmlns:tns="http://schemas.ogf.org/nsi/2015/04/connection/pathtrace"
        id="urn:ogf:network:grenada.net:2013:nsa-aggr">
    <connectionId>urn:uuid:59d6c0b2-a8e0-4583-ae8a-0fc84eb89f07</connectionId>
    <path>
        <segment id="urn:ogf:network:aruba.net:2013:nsa" order="0">
            <connectionId>urn:uuid:71d30ed8-f130-4522-a5c5-3d6d2e96fb1e</connectionId>
            <stp order="0">urn:ogf:network:aruba.net:2013::stpA?vlan=1790</stp>
            <stp order="1">urn:ogf:network:aruba.net:2013::curacao?vlan=1790</stp>
        </segment>
        <segment id="urn:ogf:network:curacao.net:2013:nsa" order="1">
            <connectionId>urn:uuid:aa4e5d68-4004-48c3-a99e-07bc7ae911fc</connectionId>
        </segment>
        <segment id="urn:ogf:network:bonaire.net:2013:nsa" order="2">
            <connectionId>urn:uuid:b1f0277d-63d5-4e5e-85e8-acd11a5baab9</connectionId>
            <stp order="0">urn:ogf:network:bonaire.net:2013::curacao?vlan=1790</stp>
            <stp order="1">urn:ogf:network:bonaire.net:2013::stpZ?vlan=1790</stp>
        </segment>
    </path>
</tns:pathTrace>

Furthermore, if an uPA that does not support pathTrace and is hidden from the AG by another AG downstream then it is possible that this uPA will stay hidden if the AG downstream does not add an empty segment element for this uPA. Aggregators that do not support pathTrace can be detected as well this way.

Cheers,
    HansT.

_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg