Hi all, Here are the slide of SwitchingService for my presentation. -- Takahiro Miyamoto <tk-miyamoto@kddi.com> KDDI Corporation TEL: +81-80-5945-9004
Hi all, Here are the slides on "A Proposal of NSI CS Client REST I/F" that I was presented today. Atsuko 2013/3/13 Takahiro Miyamoto <tk-miyamoto@kddilabs.jp>:
Hi all,
Here are the slide of SwitchingService for my presentation.
-- Takahiro Miyamoto <tk-miyamoto@kddi.com> KDDI Corporation TEL: +81-80-5945-9004
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
A little clarification of my comments yesterday. NML already contains a Switching Service, which is able to describe the topological function for both a NSI Switching Service (SS) and NSI (Connection Service) CS. It is not able to describe NSI functions, like Policy and how to make the available changes. Chin mentioned that the difference between the two is that NSI CS is able to create services, but after a short discussion with Guy we found that this comment is based on confusion on the term (NSI, unfortunately, uses the same term for both a "transport service" -a Link in NML- as well as for the SOAP service that provides the "connection service" -a SwitchingService in NML-). Here is a description of the NML SwitchingService: * It is an object describing the capability to dynamically create Links between Ports. * It has an associated list of ingress Ports and egress Ports * This includes "virtual" or "non-instantiated" Ports that are dynamically created by a Adaptation Service (aka: it can create connection between two VLAN Ports, even if that VLAN does not yet exist) * It keeps a list of created Links * You can associate a SwitchingService either to a Node (for a NSI SwitchingService) or to a whole Topology (for a NSI ConnectionService) And that's all it can. Nothing really fancy, but just what is needed to described a Switching Service on the data plane. As an easy way forward, I recommend to make sure that the NSI CS and NSI SS have a pointer to the NML SwitchingService. Hopefully mandatory, but if that is easier for quick adoption, optional. Thanks, Freek
Hi Freek, Thank you for the clarification. Could you tell me any documents to refer NML SwitchingService? Do you have any idea to avoid confusing terms, e.g. rename of NSI SwitchingService? Or is it acceptable for you to call NML SwitchingService and NSI SwitchingService to distinguish them? Regards, Takahiro On 2013/03/14 3:46, Freek Dijkstra wrote:
A little clarification of my comments yesterday.
NML already contains a Switching Service, which is able to describe the topological function for both a NSI Switching Service (SS) and NSI (Connection Service) CS. It is not able to describe NSI functions, like Policy and how to make the available changes.
Chin mentioned that the difference between the two is that NSI CS is able to create services, but after a short discussion with Guy we found that this comment is based on confusion on the term (NSI, unfortunately, uses the same term for both a "transport service" -a Link in NML- as well as for the SOAP service that provides the "connection service" -a SwitchingService in NML-).
Here is a description of the NML SwitchingService: * It is an object describing the capability to dynamically create Links between Ports. * It has an associated list of ingress Ports and egress Ports * This includes "virtual" or "non-instantiated" Ports that are dynamically created by a Adaptation Service (aka: it can create connection between two VLAN Ports, even if that VLAN does not yet exist) * It keeps a list of created Links * You can associate a SwitchingService either to a Node (for a NSI SwitchingService) or to a whole Topology (for a NSI ConnectionService)
And that's all it can. Nothing really fancy, but just what is needed to described a Switching Service on the data plane.
As an easy way forward, I recommend to make sure that the NSI CS and NSI SS have a pointer to the NML SwitchingService. Hopefully mandatory, but if that is easier for quick adoption, optional.
Thanks, Freek _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
-- Takahiro Miyamoto <tk-miyamoto@kddi.com> KDDI Corporation TEL: +81-80-5945-9004
participants (3)
-
Atsuko Takefusa -
Freek Dijkstra -
Takahiro Miyamoto