[Nsi-wg] summary of Ad-hoc NSI f2f meeting at Joint Tech 2012 Winter:

[Tomohiro Kudoh]

Ad-hoc NSI f2f meeting at Joint Tech 2012 Winter:

Present:
Chin Guok
Hans Trompert
Jeroen van der Ham
Jerry Sobieski
John MacAuley
Tom Lehman
Tomohiro Kudoh
Xi Yang

There was consensus on the following:

1. An STP can have 0 or more <type,value> tuples  =>
STP (<network_id>, <local_id>, <type_1,value_1>, .. , <type_n,value_n>)
     - e.g. STP (NetA, EndPt1, port, 1000, vlan, 123)
     - open question on how tuples can relate to one another, e.g.
port  1-4 have vlans 1-4

The STP specification incorporating the <type,value> tuples is still
just a STP *identifier*.   I.e. this in itself does not imply that
these values are in any way related to specific technology or hardware
features.

On the other hand, <type,value> tuples can be used to define
capabilities. The capabilities can describe technology, hardware,
policy, or other limitations.

The value of the "type" string is not defined as part of the NSI CS
standard, i.e. it is defined as part of the service definition.  The
NSI CS standard only codifies the presence of <type,value> pairs as
part of the STP identifiers. It is up to the provider (PA) to define
them. However, we do expect that there will be a best-practices
document describing some <type,value> combinations and capabilities.

2. The <value> filled can be an individual value or a range
     - if a <value> is a range then it is a "STP_Bundle"
   I.e., these tuples may also be used to specify constraints that
identify a set of STPs.

3. Open question on how we can describe constrains for STPs, e.g.
     STP (NetA, EndPt1, <port, $1>, <vlan, $2>)
     STP (NetA, EndPt1, <port, $3>, <vlan, $4>)
     Capabilities: $1 != $3, $2 = $4  => no vlan translation

4. Open question on how we can describe and bundle SDP