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

Hans Trompert hans.trompert at surfnet.nl
Wed Nov 30 04:13:30 EST 2016


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.
>

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


More information about the nsi-wg mailing list