[Nsi-wg] detection of not participating uPA in pathTrace by AG
Guy Roberts
guy.roberts at geant.org
Thu Dec 1 11:43:08 EST 2016
John,
Attached is the version with post-Helsinki updates.
Guy
From: John MacAuley [mailto:macauley at es.net]
Sent: 01 December 2016 16:37
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
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
<mailto: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 <http://es.net> ]
Sent: 01 December 2016 16:22
To: Guy Roberts <guy.roberts at geant.org <mailto:guy.roberts at geant.org> >
Cc: Hans Trompert <hans.trompert at surfnet.nl
<mailto:hans.trompert at surfnet.nl> >; OGF NSI Work Group <nsi-wg at ogf.org
<mailto: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 < <mailto:guy.roberts at geant.org>
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- <mailto:wg-bounces at ogf.org> wg-bounces at ogf.org] On
Behalf Of John MacAuley
Sent: 01 December 2016 15:42
To: Hans Trompert < <mailto:hans.trompert at surfnet.nl>
hans.trompert at surfnet.nl>
Cc: OGF NSI Work Group < <mailto:nsi-wg at ogf.org> 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 < <mailto:hans.trompert at surfnet.nl>
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 < <mailto:hans.trompert at surfnet.nl>
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>
"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>
"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
<mailto:nsi-wg at ogf.org> nsi-wg at ogf.org
<https://www.ogf.org/mailman/listinfo/nsi-wg>
https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________
nsi-wg mailing list
<mailto:nsi-wg at ogf.org> nsi-wg at ogf.org
<https://www.ogf.org/mailman/listinfo/nsi-wg>
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/0ce9aeca/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gfd-r-nsi-policy-public-comment-v6.doc
Type: application/msword
Size: 2344960 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20161201/0ce9aeca/attachment-0001.doc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5388 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20161201/0ce9aeca/attachment-0001.bin>
More information about the nsi-wg
mailing list