Okay, I will bite! What I am trying to do from a path finding perspective is take a detailed NML document and reduce it down to four objects: Network, TransferFunction, STP, and SDP in the context of each service request. Therefore, if I get a service request for an EVTS serviceType I must be able to do path finding in the context of network resources supporting the EVTS serviceType. In Madrid we agreed that we will associate a serviceType with an STP, so I can filter out all the STP not supporting the target serviceType. This then lets me determine the applicable SDP. So from a path computation perspective I have Networks (vertices) and SDP (edges) in my graph, however, this is not enough in that I also need the TransferFunction to determine if a Network can interconnect an ingress and egress SDP. These are the basics of the NSI architecture. I am not looking at any technology specifics. I am just using the defined components of the NSI connection services architecture as defined by the collective brain trust :-) Now comes the somewhat harder bit … How do I use the NML constructs to describe the NSI constructs of Network, TransferFunction, STP, and SDP in a correct and flexible way. This has been the discussion on calls and e-mail over the last few weeks. Here is what the group has almost agreed upon: 1. The NML Topology object maps to the NSI Network object. 2. The NML Port object maps to the unidirectional NSI STP object. 3. The NML PortGroup object maps to the underspecified unidirectional NSI STP object. 4. The NML BidirectionalPort object maps to both a bidirectional NSI STP object and an underspecified bidirectional NSI STP object. 5. The NML SwitchingService object maps to the NSI TransferFunction object. 6. For the NSI SDP object there are a number of NML objects available to do the modelling (Link and BidirectionalLink) but we are using the isAlias reference in the unidirectional Port/PortGroup to identify connectivity between networks. Now I understand your argument 100% (or at least my filtered version of it). I am building the simplified view you are looking for by using a more detailed NML view. I end up treating STP as an abstracted string and grouping them in the transfer service as follows: TransferService id="urn:ogf:network:netherlight.net:2013:topology:a-gole:testbed:evts" { urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1780 urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1781 urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1782 urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1783 urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:nordunet:1:vlan=1780 urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:nordunet::1:vlan=1781 urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:nordunet::1:vlan=1782 urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:nordunet::1:vlan=1783 } SDPs I create by concatenating their STP ids together: SDP id="urn:ogf:network:uvalight.net:2013:netherlight:vlan=1796::urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1796" { urn:ogf:network:uvalight.net:2013:netherlight:vlan=1796 urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1796 } STPs are the standard networkId, localId, and labelType, but I make the id using local and label: STP id="urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1780" { networkId = "urn:ogf:network:netherlight.net:2013:topology:a-gole:testbed" localId = "urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1" label (vlan = "1708") serviceType="EVTS.A-GOLE" directionality="bidirectional" other service related attributes … } And of course a network is a combination of all these: Network id="urn:ogf:network:netherlight.net:2013:topology:a-gole:testbed" { List of TransferService List of SDP List of STP } I have created this NSI view of topology for my path finder to help prove or disprove the current definitions within the NSI architecture. So far I have been able to do basic path finding, but we are only now drilling down into some of the technology hurdles we will face when trying to create this higher level abstraction. Yes we are discussing the technology specific details in the context of NML, but we are trying to understand how it would be modelled in detail so we can understand what we need, and how it relates back to our abstractions. Yes, I agree we could simply use NML to model no more than what we currently need in NSI, but I would like to make sure the standard if flexible enough to handle more detailed needs. John On 2013-11-05, at 2:12 AM, Jerry Sobieski <jerry@nordu.net> wrote:
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
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg