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
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