I really encourage everyone to think about this from the *service*
perspective - i.e. what the network organization is willing to
offering as a NSI service feature and what the users
really *actually* want - Our NSI Services do not need to announce
internal topology at all, nor do they need to express or incorporate
every possible hardware capability. Keep it simple (!!!) A
simple connection delivered to/from a STP associated with a VLAN
tag. You get into a lot of unnecessary topology munging by trying
to expose and process every technical hardware capability. Don't
do this. Its not necessary. If you keep these topological details
internal to a local NRM, then the announced topology is vastly
simplified. Let the NRM deal with details internally, but the
inter-domain path finding should only need deal with *simple*
contiguous services. Don't try to make one NSI service capable of
everything under the sun...doing so makes it too complex.
Best regards
Jerry
On 10/31/13 9:37 AM, Henrik Thostrup
Jensen wrote:
Hi
On Wed, 30 Oct 2013, Jeroen van der Ham wrote:
This is the decision regarding encoding
and labeltype that was made for NML:
https://forge.ogf.org/sf/sfmain/do/go/artf6577 :
NML has currently a one-to-one relation
between the layer encoding (a URI to define the layer of
sublayer of a specific Port of Link) and the label type (a URI
to define the resource label of a technology).
Make sense. Thanks for clarifying the difference.
Right now we don't use the encoding in the NSI topology. Is this
something we should consider? I am not entirely sure what the
benefits are though.
There is not a one-to-one correlation,
because encodings (such as Ethernet) still allow traffic without
labels at all.
Shouldn't a switching service have an encoding AND a labelType? An
ethernet encoding could have both regular and VLAN and carrier
ethernet vlan (with q-in-q / s-tag+c-tag), and might only be
capable of changing one of them. How would I know which label
types can be swapped?
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net>
Software Developer, NORDUnet
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg