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.
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.
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@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.
I am unavailable this week as I am at a conference. Also, some people will be engaged with the Global Summit. I suggest Wednesday 25th. Guy From: Hans Trompert [mailto:hans.trompert@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@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.
Wednesday 25th is fine with me. Cheers, HansT. On 17/05/16 12:03, Guy Roberts wrote:
I am unavailable this week as I am at a conference. Also, some people will be engaged with the Global Summit.
I suggest Wednesday 25^th .
Guy
*From:*Hans Trompert [mailto:hans.trompert@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@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.
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 1st June work for you? Guy From: Hans Trompert [mailto:hans.trompert@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@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.
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@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@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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
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@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@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.
participants (3)
-
Guy Roberts -
Hans Trompert -
Jerry Sobieski