[Nsi-wg] ERO

Mon Oct 20 08:02:25 EDT 2014

Hi John,

Not sure if this has been discussed before in the NSI WG. The ERO is a
great way of specifying resources to be included in the path, but is
there also a way of specifying resources to be excluded from a path? I'm
thinking about the avoidance of specific peering points or maybe whole
domains for example.

Cheers,
    HansT.

On 17/10/14 17:05, John MacAuley wrote:
> 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
> <mailto: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 <mailto:nsi-wg at ogf.org>
>> https://www.ogf.org/mailman/listinfo/nsi-wg
>
>
>
> _______________________________________________
> 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/20141020/8b1f3957/attachment-0001.html>