[Nsi-wg] ERO

[John MacAuley]

All,

I had a long discussion with Chin on the request to bound internal topology element with the visible inter-domain STP (2a below).  He has a specific customer requirement where they only want to specify a source STP and a single internal link, but do not care about the rest of the path used.  This is done to manually guide traffic around different sides of a ring based on congestion.

I was worried about the external AG path finder choosing a less than optimal path with a lack of internal topology knowledge.  By forcing the specification of ingress and egress STP with the internal topology I thought we could avoid this issue.  It will be up to local uPA policies to decide if a proposed ingress or egress STP is non-optimal for the internal topology provided, rejecting the reservation request with an STP unavailable serviceException to force the selection of an alternative STP.

Revisiting the (2a) example to show Chin's user case, a user could specify the source and destination STP, plus a single internal topology element to guide the initial path:

urn:ogf:network:es.net:2013:production:ps:sunn:1?vlan=1779
urn:ogf:network:es.net:2013:production:internalA:1779
urn:ogf:network:netherlight.net:2013:production7:dlp01?vlan=1779

The AG path finder would then be responsible for stitching together a proposed end-to-end path that interconnects networks "urn:ogf:network:es.net:2013:production" to "urn:ogf:network:netherlight.net:2013:production7".

Another interesting side effect of this, and something I did not remember until after my discussion with Chin, is that none of the three STP listed above need to be in NML topology since the source and destination STP are UNI-N ports with no associated SDP.  More path finding goodness.

John

On 2014-10-16, at 1:24 PM, John MacAuley <macauley at es.net> wrote:

> Peoples,
> 
> I am going to implement the ERO capability in our path finder and want to make sure we are all on the same page for how members in the order list are handled.  I would also like to agree on some rules for handling both strict and loose ERO.  We do not differentiate between loose and strict in the schema, so it really comes down to whether a path finder needs to do any additional resolution to satisfy the request.
> 
> For this exercise I would like to use the following ports that form a valid path (I modified the ESnet ports to be compliant to the new STP format).  I will assume all networks support label swapping.
> 
> urn:ogf:network:es.net:2013:production:ps:sunn:1?vlan=1779-1799,3400-3499
> urn:ogf:network:es.net:2013:production:startap:star:1?vlan=1779-1799
> urn:ogf:network:icair.org:2013:topology:esnet?vlan=1779-1794,1797-1799
> urn:ogf:network:icair.org:2013:topology:netherlight?vlan=1779-1794,1797-1799
> urn:ogf:network:netherlight.net:2013:production7:starlight-1?vlan=1779-1794,1797-1799
> urn:ogf:network:netherlight.net:2013:production7:dlp01?vlan=1779-1794,1797-1799
> 
> 1. A strict ERO for this path would be the following (from source to destination):
> 
> urn:ogf:network:es.net:2013:production:ps:sunn:1?vlan=1779
> urn:ogf:network:es.net:2013:production:startap:star:1?vlan=1779
> urn:ogf:network:icair.org:2013:topology:esnet?vlan=1779
> urn:ogf:network:icair.org:2013:topology:netherlight?vlan=1779
> urn:ogf:network:netherlight.net:2013:production7:starlight-1?vlan=1779
> urn:ogf:network:netherlight.net:2013:production7:dlp01?vlan=1779
> 
> Each fully qualified STP identifier is provided from source to destination with no gaps.  In this case I would like to agree on a restriction that if a two edge ports on a single network are provided, path finders do not try to route with anything other than resources in the network (i.e. do not try to connect two ports in a single network together by routing out of the network and back into the network).  This will stop crazy routes from occurring if for any reasons those to ports cannot be connected by the domain (remember my label swapping solution on the A-GOLE).
> 
> 2. A ERO with internal topology not contained in NML:
> 
> urn:ogf:network:es.net:2013:production:ps:sunn:1?vlan=1779
> urn:ogf:network:es.net:2013:production:internalA?vlan=1779
> urn:ogf:network:es.net:2013:production:internalB?vlan=1779
> urn:ogf:network:es.net:2013:production:internalC?vlan=1779
> urn:ogf:network:es.net:2013:production:startap:star:1?vlan=1779
> urn:ogf:network:icair.org:2013:topology:esnet?vlan=1779
> urn:ogf:network:icair.org:2013:topology:netherlight?vlan=1779
> urn:ogf:network:netherlight.net:2013:production7:starlight-1?vlan=1779
> urn:ogf:network:netherlight.net:2013:production7:dlp01?vlan=1779
> 
> In this case I also have a strict ERO based on the NML topology, but for the ESnet segment I have also supplied internal topology based in information not known to NSI path finders.  In this case I would like to agree on two restrictions for this capability:
> 
> a) When specifying internal topology elements you must bound them by two valid edge STP for that network from within the NML topology.  In this case we have bounded the internal topology elements (internalA - internalC) by the STP in bold.
> 
> urn:ogf:network:es.net:2013:production:ps:sunn:1?vlan=1779
> urn:ogf:network:es.net:2013:production:internalA:1779
> urn:ogf:network:es.net:2013:production:internalB:1779
> urn:ogf:network:es.net:2013:production:internalC:1779
> urn:ogf:network:es.net:2013:production:startap:star:1?vlan=1779
> 
> This will allow path finders to perform inter domain routing to the boundary STP, and pass the remaining elements into the uPA for resolution.
> 
> b) When specifying internal topology elements not defined in your NML they must follow the standard STP format and be prefixed with the network Identifier for the network in which they are contained:
> 
> urn:ogf:network:es.net:2013:production:ps:sunn:1?vlan=1779
> urn:ogf:network:es.net:2013:production:internalA:1779
> urn:ogf:network:es.net:2013:production:internalB:1779
> urn:ogf:network:es.net:2013:production:internalC:1779
> urn:ogf:network:es.net:2013:production:startap:star:1?vlan=1779
> 
> Based on this rule path finders can determine the ports are members of the bounded network and since the internal STP are unknown, pass all internal STP plus the boundary STP as an ERO to the uPA.  The format of the internal STP's local part is left up to the managing network just so long as it does not violate the NURN character set.
> 
> 3. A loose ERO is consider "loose" for two reasons:
> 
> a) The ERO is not a complete end-to-end path when computed using the NML topology.  For example:
> 
> urn:ogf:network:es.net:2013:production:ps:sunn:1?vlan=1779
> urn:ogf:network:icair.org:2013:topology:netherlight?vlan=1779
> urn:ogf:network:netherlight.net:2013:production7:dlp01?vlan=1779
> 
> In this case the path finder will need to complete the path by selecting STP to filling in the gaps, specifically at the egress SDP on the ESnet/iCAIR segment.  The egress STP on the iCAIR segment actually forces selection of a single STP on the ingress to Netherlight, but is still considered loose as the STP must be selected by the path finder.
> 
> b) The ERO contains an underspecified STP.  For example, the following STP are all under specified:
> 
> i) Requires any STP from the range of 1779-1794 to be used in the reservation request.
> 
> 	urn:ogf:network:icair.org:2013:topology:esnet?vlan=1779-1794
> 
> ii)  Based on the EVTS service definition both these underspecified STP request any valid STP from the range 1779-1794,1797-1799.
> 
> 	urn:ogf:network:icair.org:2013:topology:esnet?vlan
> 	urn:ogf:network:icair.org:2013:topology:esnet
> 
> iii) When only the network identifier portion of the STP is provided it implies any valid STP within the network may be used.  This underspecified STP format ill be utilized when a user would like a specific network to be used within the path.  
> 
> 	urn:ogf:network:icair.org:2013:topology
> 
> For this case an ERO would be specified as follows: 
> 
> 	urn:ogf:network:es.net:2013:production:ps:sunn:1?vlan=1779
> 	urn:ogf:network:icair.org:2013:topology
> 	urn:ogf:network:netherlight.net:2013:production7:dlp01?vlan=1779
> 
> iv) Should we support the ability to specify a network and label but not a specific STP?
> 
> 	urn:ogf:network:icair.org:2013:topology?vlan=1779
> 
> 3) If either a strict or loose ERO can not be satisfied the reservation request fails and a serviceException information is returned identifying the constant(s) that caused the failure.
> 
> I assume I have missed some.  Can anyone think of additional ones we would need to support?
> 
> Thanks,
> John
> 
> _______________________________________________
> 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/20141017/a12585d5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1626 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20141017/a12585d5/attachment-0001.bin>