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