[Nsi-wg] STP lists and path ordering

[Henrik Thostrup Jensen]

Hi

On Wed, 2 May 2012, Jeroen van der Ham wrote:

> The main problem with the current STP List is I think that it is very 
> hard to relate it to a path.

Agreed. NSI topology and STPs are fairly abstract concept, while a path is 
something fairly concrete that must map to actual hardware in a precise 
manner (IMHO). There is definitely some shoehorning going on.

> The current query return format also is not a self-contained answer, in 
> that you need to have the NSI topology to interpret the result.

Good point.

> I think we should reconsider the information that NSI should be able to convey in a query result.
>
> So to translate your issues below to requirements and list some additional ones that I ran into:

> 1. Should the source and destination be part of the stp List? (not having them in there is a bit annoying)

I really don't think we should have any repeated information in the 
request.

However Johns proposed stpList constructing in itself is already partly 
redundant.

The list of A2, B1, B2, C1 could be reduced to two elements (A2/B2 + 
B2/C1).

But maybe the whole source, dest and stpList thing could be represented in 
one structure.

> 2. How should the STP List represent routing within domains?

Isn't this always encapsulated in NSI?

> 3. How do we represent SDPs in the STP List?

Not really sure. (see the second part in my reply to 1. as well).

> 4. How do we represent Domains / NSAs in the STP list? (in order to make 
> a query result self-contained)

What exactly is you want to have self-contained? The entire topology 
information to the path?


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet