Hello Hans,

Thanks for you feedback on the NSI Policy document.

Could you please suggest a Wednesday that would you be available for call to discuss these questions?

Guy

From: nsi-wg [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Hans Trompert
Sent: 13 May 2016 11:52
To: OGF NSI Work Group
Subject: [Nsi-wg] review of draft-gfd-r-nsi-policy-public-commentv3_RHJ

Dear NSI WG colleagues,

I have read the version of the Policy document that was already reviewed by Richard and tried to assess if the document is sufficiently clear to actually implement the pathTrace extension in a aggregator or uPA. There are three things that are not completely clear to me yet.

I agree with Richard that it is not clear how a uPA can determine the order number for its segment, especially in the tree scenario. It is stated in the document that an AG that has done additional path finding must assemble the child path in topological order, that sounds reasonable because the AG is the only one aware of the order of the segments and not the uPA, and what about other AG down the tree that do additional path finding and will return traces with more then one segment, is any AG allowed to renumber segments or lists of segments from its childeren before it sends the trace upstream?

It is not clear to me if in any NSI deployment it is mandatory for all NSA to either do implement or do not implement the pathTrace extension or if it is allowed to have a mixed deployment. If the latter is allowed questions like the following come to mind:

• what if an uPA does not implement the pathTrace extension, does an AG has to check the reserve.cf coming up if it contains an expected pathTrace?
• what if an AG, not being the root AG, does not support the pathTrace extension, and lets assume that this AG does transparently forward all NSI header elements it does not know about, it cannot aggregate the pathTrace information from its childeren and can only at best collect all pathTrace's from its children and add them as separate traces to the reserve.cf going up
• What if the root AG does not support pathTrace but a sub tree with an AG with an associated set op uPA does, then that sub tree AG will act as root AG and the uPA of that sub tree will only see part of the path in the rsvcommit.rq coming down and not the complete end to end path

It is not clear to me if both an AG and uRA are allowed to terminate an reservation that has failed segments due to policy violations, or that we just trust on normal reserveCommit.fl processing and leave the termination of the request up to the uRA?

Cheers,
    HansT.