[Nsi-wg] detection of not participating uPA in pathTrace by AG

Hans Trompert hans.trompert at surfnet.nl
Mon Nov 28 08:19:04 EST 2016


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20161128/004e4b8a/attachment-0001.html>


More information about the nsi-wg mailing list