Subject: [Supa] Review of draft-pentikousis-supa-mapping-00

From: JF Tremblay <[email-masked]>
Date: Mon, 29 Sep 2014 15:35:28 -0400

After reading draft-pentikousis-supa-mapping-00, some concepts of supa remain unclear to me. It’s not easy to put a finger on exactly what, but I’ll try to describe it below. 

From reading the other supa drafts, it seems a supa-compliant entity (controller?) expose a number of abstract models in an interfaces to “higher” applications (management or others). This is what the work in draft-contreras and draft-zaalouk seem to refer to. In that sense, I would expect a “mapping” to happen internally between these abstract models and a physical topology. This way, the supa entity would maintain consistency between different abstract topologies and the physical topology. 

However, according to this draft, there’s only one topology being maintained and it seemed to be the physical one (“...a topology module maintains the topology of the network infrastructure…”). This is reinforced in section 3.2: " ... the network service system acquires the topology information [...] if it needs some knowledge of the underlying network…”. And then in section 3.3: "...the NSS can decide…”. It seems the “network management and control system” is purely a physical controller and the NSS is actually making decisions. So, in the end, if the NSS accesses the underlying network topology only, where are the supa abstractions used? 

A few minor edits/comments: 
- Introduction: draft-zhou-supa-architecture-00 is referenced but does not seem to exist at that url.
- Introduction: in the last paragraph, an ABPD module is discussed, but does not appear in figure 1. 
- Page 8 and 9: s/quite/quit/ I guess… 

JF

---

From: linjunru <[email-masked]>
Date: Tue, 30 Sep 2014 09:19:23 +0000

Hi, JF:
	Thank you for your constructive comments. Please see in line

> 
> After reading draft-pentikousis-supa-mapping-00, some concepts of supa
> remain unclear to me. It’s not easy to put a finger on exactly what, but I’ll try
> to describe it below.
> 
> From reading the other supa drafts, it seems a supa-compliant entity
> (controller?) expose a number of abstract models in an interfaces to “higher”
> applications (management or others). This is what the work in draft-contreras
> and draft-zaalouk seem to refer to. In that sense, I would expect a “mapping”
> to happen internally between these abstract models and a physical topology.
> This way, the supa entity would maintain consistency between different
> abstract topologies and the physical topology.
> 
> However, according to this draft, there’s only one topology being maintained
> and it seemed to be the physical one (“...a topology module maintains the
> topology of the network infrastructure…”). This is reinforced in section 3.2: " ...
> the network service system acquires the topology information [...] if it needs
> some knowledge of the underlying network…”. And then in section 3.3: "...the
> NSS can decide…”. It seems the “network management and control system” is
> purely a physical controller and the NSS is actually making decisions. So, in the
> end, if the NSS accesses the underlying network topology only, where are the
> supa abstractions used?
> 
 [Junru] 
---"there’s only one topology being maintained and it seemed to be the physical one" is exactly what we are talking about. NSS may have its own "abstract view" of the physical topology, which is built based on the physical topology information maintained in the network management & control system, however this "abstract view" is network service/application-dependent and is not focused on by this draft.
---"if the NSS accesses the underlying network topology only" is not exactly right. The network management & control system also needs to access the underlying network topology, especially when mapping the NSS's configuration into device-level configuration, it needs the underlying network topology to decide where and how is the configuration deployed.
---" where are the supa abstractions used? ", they are used to configure the network services network-widely such as in L3vpn, IPTE...
---in section 3.3: "...the NSS can decide…” here the NSS's decision is more a configuration from high level, such as steering traffic away from a specific network element and steering traffic toward a path passes through a specific network element . In the example scenario, there may be several paths from A to B which also travel through C. But the NSS has no idea about these paths and it is not able to decide which path is better neither. So it sends the path constrains (bandwidth > 10Mb/s, through C, ingress node is A and egress node is B) to the network management & control system, and the network management & control system make the actual "decisions": the specific path (A,D,C,E,B) is the one. The expression here may cause confusion and "...the policy of the NSS' network service indicates that …”may be more appropriate than "...the NSS can decide…”.

> - Page 8 and 9: s/quite/quit/ I guess…

[Junru] Thanks, we will correct it in the new vision.

> 
> JF
> 
> 
> 
> 
> 
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa

Best Regards,
JR
--------------------------------------------------------------------------
Junru Lin
Integration Technology Research Dept
Huawei Technologies Co.,Ltd
--------------------------------------------------------------------------