[Nsi-wg] detection of not participating uPA in pathTrace by AG
John MacAuley
macauley at es.net
Thu Dec 1 11:37:12 EST 2016
Pathtrace is the Policy document. I believe Chin modified some of the diagrams.
On 2016-12-01, at 11:28 AM, Guy Roberts <guy.roberts at geant.org> wrote:
> John,
>
> I only have a record of change to the Policy, Signalling and Pathfinding and the DDS docs.
>
> I don’t think we edited the CS doc in Helsinki?
>
> Guy
>
> From: John MacAuley [mailto:macauley at es.net]
> Sent: 01 December 2016 16:22
> To: Guy Roberts <guy.roberts at geant.org>
> Cc: Hans Trompert <hans.trompert at surfnet.nl>; OGF NSI Work Group <nsi-wg at ogf.org>
> Subject: Re: [Nsi-wg] detection of not participating uPA in pathTrace by AG
>
> Guy - Do you have a link to the version we modified in Helsinki?
>
> On 2016-12-01, at 11:07 AM, Guy Roberts <guy.roberts at geant.org> wrote:
>
>
> John,
>
> Can you please send the updated document to me when you are done?
>
> I will make sure the updates get in before publication.
>
> Guy
>
> From: nsi-wg [mailto:nsi-wg-bounces at ogf.org] On Behalf Of John MacAuley
> Sent: 01 December 2016 15:42
> To: Hans Trompert <hans.trompert at surfnet.nl>
> Cc: OGF NSI Work Group <nsi-wg at ogf.org>
> Subject: Re: [Nsi-wg] detection of not participating uPA in pathTrace by AG
>
> Hans,
>
> I will add an error section to the document capturing the agreed behaviour. We can then get people to review for correctness.
>
> John
>
> On 2016-12-01, at 3:57 AM, Hans Trompert <hans.trompert at surfnet.nl> wrote:
>
>
>
> Hi John,
>
> I didn't know you have been sick, I hope you start feeling better soon!
>
> I agree with your reasoning around the second option, I believe a partial trace is always better than no trace at all, you are able to determine if a trace is complete or not, and this will make it easier to identify the NSA that do not support the trace making it easier to get it deployed fully. This however would need some additional text in the document.
>
> Cheers,
> HansT.
>
> On 30/11/2016 22:24, John MacAuley wrote:
> 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 at 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 at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20161201/a2c58172/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1626 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20161201/a2c58172/attachment-0001.bin>
More information about the nsi-wg
mailing list