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

[Jerry Sobieski]

This is why you don't put "options" into a standard.   If its required, 
it should be specified and everyone implements it the same way.   If it 
is "optional" then it is not part of the standard (..or should be part 
of a *separate* standard that may or may not be implemented by a provider.)

ultimately, the protocol will have problems if any provider's actions 
are dependent on other domains "doing the right thing" - you cannot 
always depend upon that and so the protocol should be as self contained 
as possible.  At the very least the relaibility and stability of a 
service in one domain should never be reliant on the service in another 
domain working properly (or imprperly.)   Thus trace information is 
inherently unreliable and IMO should not be part of the protocol.  (It 
should be a separate service/standard.)

But perhaps these issues - and how we might resolve them in a simpler 
manner - should be on an agenda item for version 3 discussion...?

Best regards
J


On 5/19/16 6:46 AM, 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.
>
>
>
> _______________________________________________
> 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/20160519/d2e3ca2c/attachment-0001.html>