[Nsi-wg] review of draft-gfd-r-nsi-policy-public-commentv3_RHJ

[Hans Trompert]

Hi Guy,

Wednesday 1st June is fine with me.

Cheers,
    HansT.

On 19/05/16 13:46, Guy Roberts wrote:
>
> Hi Hans,
>
>  
>
> Unfortunately the ESnet guys will be at the Ciena Vectors meeting next
> week and I will also be out of the office.
>
>  
>
> How would Wednesday 1^st June work for you?
>
>  
>
> Guy
>
>  
>
> *From:*Hans Trompert [mailto:hans.trompert at surfnet.nl]
> *Sent:* 17 May 2016 09:16
> *To:* Guy Roberts; OGF NSI Work Group
> *Subject:* Re: [Nsi-wg] review of
> draft-gfd-r-nsi-policy-public-commentv3_RHJ
>
>  
>
> Hi Guy,
>
> This Wednesday would be fine but I do not know if it clashes with the
> I2 Global Summit for other participants. Next Wednesday is fine as well.
>
> Cheers,
>     HansT.
>
> On 16/05/16 15:45, Guy Roberts wrote:
>
>     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 at 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.
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20160520/b24fc036/attachment.html>