Subject: [Supa] SUPA questions

From: Benoit Claise <[email-masked]>
Date: Mon, 02 Feb 2015 15:53:01 +0100

Dear all,

I spent 2 hours preparing for this call today (reading some of the 
emails, some of the drafts, and the latest charter proposal). Here are 
some of my questions, posted to hopefully help structure the call, or 
follow up after the call.
Apologies if some of the questions have been answered on the mailing or 
during one of the weekly calls.

Regards, Benoit

=============================

_http://tools.ietf.org/html/draft-karagiannis-supa-problem-statement-04_
-

    Several working groups in IETF such as I2RS (L3/ routing topologies),
    ALTO (cost maps), SFC (service chain), have already defined various
    schemes for the configuration of network devices and specific network
    controllers. However, none of these efforts offer (1) a vendor-
    neutral standardized scheme for applications to transmit their needs
    to controllers and (2) a set of generic YANG-based data models that
    enable management and automation of services.

Same question as during the bar BoF: what is the connection with I2RS in 
terms of topology?
When I spoke to Alia Atlas some months ago, she mentioned that the 
topology would be done in I2RS.
- From

                   +-------+           +-------+
                   | OAMA  |           | OAMA  |
                   +-------+           +-------+
                       |                   |  <---SUPA data model
                       |                   |
                  --------------------------------- BUS
                       |                   |
                       |                   |
                +-------------+       +-------------+
                | Management  |       | Management  |
                |    Agent    |       |    Agent    |
                +-------------+       +-------------+
                   |   |   |             |   |   |
                   |   |   |             |   |   |
                   |   |   |             |   |   |
                  NE1 NE2 NEn           NE1 NE2 NEn

                 Figure 1: SUPA Framework overview

Btw, is this really a BUS? I thought it was RESCONF/NETCONF? Slide 4 
shows RESTCONF/NETCONF
I don't quite get the change from "applications" to "AOMA "(what is 
this?), and "controller" to "management agent" from previous draft 
versions?
 From the slides, I see

In a different picture, I see

I would be great if you could agree on a single set of terminology

_Question on the slides:_
- From your slide, do you target option 1 or option 2 for the charter?
- I still don't understand what "Shared Unified Policy Automation" means
     Shared between?
     Unified between?
Disclaimer: I recall proposing not to change the mailing list/draft 
names one more time ... but you would still need to explain what you mean.
-

Wrt the south-band interface, does SUPA limit its use cases to what I2RS 
can do? Btw, I2RS selected YANG.
I was thinking to have NETCONF there.

_http://tools.ietf.org/html/draft-pentikousis-supa-mapping-02_

    OAMA manages and programs the underlying network elements indirectly
    based on the abstract view of the network infrastructure. In
    practice, this means that OAMA can, among others, configure the
    underlying network as a whole rather than as a set of individual
    network elements. As a result, the diversity of the actual network
    elements in active operation is abstracted, which allows OAMA to
    manage and program the network in a simpler, more maintainable and
    efficient manner. On the other end of the spectrum, the NEs can
    continue their regular operation without having to become cognizant
    of the fact that configuration is applied at the network level.

It seems that you want to address the interface between an application 
and a controller?
Does this top down approach work without also standardizing the 
device/protocol specific interface/YANG models?
Or maybe you want to base the use cases on what the vendor CLIs can do 
today? Then how do we solve the multi-vendor/proprietary issues?
Having a L3VPN services model is not complex IMO, but translating to the 
PE configurations is what make challenging, specifically when from 
different vendors. It seems that SUPA completely hides this complexity.
IMO, this is however exactly where a SDO such as the IETF would add a 
lot of values.
Look at the different discussions on standardizing the routing-related 
YANG models.

_Questions on the cha__rter (next to the ones I asked above)_
- It seems that you discuss multiple use cases in different drafts but I 
don't see any in the charter as deliverable?
How would you know if you are successful?
On the other hand, I see in the charter text:

    The first use case that the working group will focus on will be VPN
    inter-datacenter traffic management, including the automated
    provisioning of site-to-site virtual private networks (VPNs) of
    various types (for example IPsec, tunnels, MPLS L2 and L3).

"VPN, IPSEC, tunneles, MPLS L2 or L3", they look to me as multiple use 
cases, at least multiple distinct technolgies, and therefore as a huge 
piece of work

-  "A set of policy rules is then defined to manage the service"
I don't know what you mean by "policy rules"? A new language? A set of 
YANG models, depending on the use case (Policy-based routing, QoS 
rate-limiting policy, ACL drop policy, etc...), something else?

---

From: JF Tremblay <[email-masked]>
Date: Tue, 3 Feb 2015 11:38:37 -0500

Benoit, 
Let me try to answer some of your questions below. These are definitely not “finalized” answers and might not reflect the consensus of the whole group. 

This is an effort to move the discussion forward on the points you raised. Comments inline. 

JF

> On Feb 2, 2015, at 9:53 AM, Benoit Claise <[email-masked]> wrote:
> 
> I spent 2 hours preparing for this call today (reading some of the emails, some of the drafts, and the latest charter proposal). Here are some of my questions, posted to hopefully help structure the call, or follow up after the call.
> Apologies if some of the questions have been answered on the mailing or during one of the weekly calls.
> 
> Regards, Benoit

Thanks for taking the time to comment. 

> http://tools.ietf.org/html/draft-karagiannis-supa-problem-statement-04 <http://tools.ietf.org/html/draft-karagiannis-supa-problem-statement-04>
> 
> Same question as during the bar BoF: what is the connection with I2RS in terms of topology?
> When I spoke to Alia Atlas some months ago, she mentioned that the topology would be done in I2RS.

Right. Alia said I2RS was willing to continue this work, but: 
- This wasn’t discussed in Hawaii (it wasn’t on the agenda and draft-clemm-i2rs-yang-network-topo-01 was expired at that time)
- There’s been very little discussions on this topic on the I2RS list for the past year. 

The good news is that topology work is on the agenda for the I2RS interim next Thursday (see http://trac.tools.ietf.org/wg/i2rs/trac/wiki/TopologyDesignTeams <http://trac.tools.ietf.org/wg/i2rs/trac/wiki/TopologyDesignTeams>). Supa participants are willing to re-use the work of other groups such as I2RS, as long as a timely completion envisioned. 

> Btw, is this really a BUS? I thought it was RESCONF/NETCONF? Slide 4 shows RESTCONF/NETCONF

My personal opinion would be to remove the BUS terminology from these drafts. A bus in computer engineers terms usually refers to some level of parallelization or serialization (at least according to Wikipedia). I don’t see how these concepts apply here. 

> I don't quite get the change from "applications" to "AOMA "(what is this?), and "controller" to "management agent" from previous draft versions? 

This was discussed on the list and during interim calls. Juergen suggested getting back to more classic terms such as management application and controller. I agree.  Juergen also mentioned “management agent” could be confused with a component of SNMP. 

> I would be great if you could agree on a single set of terminology

Agreed. 

> - From your slide, do you target option 1 or option 2 for the charter?

As Tina mentioned, these more or less show the same thing with different levels of details, they shouldn’t be called options. This will be updated in the slides. 

> Disclaimer: I recall proposing not to change the mailing list/draft names one more time ... but you would still need to explain what you mean.

As discussed yesterday, the list and the name are mostly placeholders at this point because the group wanted to avoid yet another renaming. 

> Wrt the south-band interface, does SUPA limit its use cases to what I2RS can do? Btw, I2RS selected YANG.

Supa would not be limited to I2RS behaviors on the southbound, for sure. 

> It seems that you want to address the interface between an application and a controller?

Yes. 

> Does this top down approach work without also standardizing the device/protocol specific interface/YANG models? 

Good point. It’s entirely true that supa is all about a top-down approach. 

> Or maybe you want to base the use cases on what the vendor CLIs can do today? Then how do we solve the multi-vendor/proprietary issues?

I believe this is what the wording around “mapping” was about. Connecting the top-down approach to proprietary implementations is definitely not is scope here. It has to connect to common, inter-operable concepts. 

> Having a L3VPN services model is not complex IMO, but translating to the PE configurations is what make challenging, specifically when from different vendors. It seems that SUPA completely hides this complexity.
> IMO, this is however exactly where a SDO such as the IETF would add a lot of values.
> Look at the different discussions on standardizing the routing-related YANG models.

I’ve taken a look at draft-zhuang-l3vpn-yang-cfg, for example. My understanding was that supa would provide a protocol-agnostic layer above that and use a model like l3vpn-yang to configure in the southbound direction (I use “direction” here because it would probably talk to a controller and not to devices directly). 

The advantage of such an abstraction is to hide the implementation details, including the fact it’s an L3VPN, form the higher-level apps. In my mind, a supa interface consumer would only get a high-level abstract topology information and then provision network resources over that topology. I’m not sure this view is shared amongst all group participants, some discussions on this would be welcome. 

> Questions on the charter (next to the ones I asked above)
> - It seems that you discuss multiple use cases in different drafts but I don't see any in the charter as deliverable?
> "VPN, IPSEC, tunneles, MPLS L2 or L3", they look to me as multiple use cases, at least multiple distinct technolgies, and therefore as a huge piece of work

Agreed, this has to be clarified and boiled down to a single well defined action item. 

> I don't know what you mean by "policy rules"? A new language? A set of YANG models, depending on the use case (Policy-based routing, QoS rate-limiting policy, ACL drop policy, etc...), something else?      

The policy side is also unclear to me. But again, this would be a high-level top-down approach. I like what’s described in draft-hares-i2rs-info-model-policy-02 (and the related presentation at http://tools.ietf.org/agenda/90/slides/slides-90-i2rs-2.pdf <http://tools.ietf.org/agenda/90/slides/slides-90-i2rs-2.pdf>), but again, that’s an I2RS document. 

JF

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Feb 2015 17:47:03 +0100

> The good news is that topology work is on the agenda for the I2RS interim next Thursday (see http://trac.tools.ietf.org/wg/i2rs/trac/wiki/TopologyDesignTeams <http://trac.tools.ietf.org/wg/i2rs/tra…

It seems that having means to express topologies at various layers is
essential if we want to move from managing devices to managing
networks.  For me, having a clear notion how we look at topologies is
as essential has having a clear notion how we look at interfaces when
we write device data models.

I2RS has topology work in their charter because they need to work with
routing topology. SUPA has topology work in their charter draft
because they need to work with network topologies and service
toplogies. I think there is topology work in some below IP working
groups as well.

I hope that the IESG looks into this issue and finds a way to address
it. One option could be to create a tightly focused short lived WG
that comes up with a generic topology model and to revise other WG
charters such that they work with the result produced by the WG. There
sure are other options one could consider/try. But I believe some
leadership action is needed here.

I assume SUPA will be happy to work with any solution the IESG seems
to be appropriate to address the need for topology data models. But
until there is a clear path, we thought to keep it in the charter as
an indication of "we need this" (and it helps to get IESG member
attention for this issue I guess).

> > - It seems that you discuss multiple use cases in different drafts but I don't see any in the charter as deliverable?

Yes, we will fix that.

> > "VPN, IPSEC, tunneles, MPLS L2 or L3", they look to me as multiple use cases, at least multiple distinct technolgies, and therefore as a huge piece of work

The idea was to try to be as much as possible agnostic to the VPN
technology. You think this won't be feasible?

> The policy side is also unclear to me. But again, this would be a high-level top-down approach. I like what’s described in draft-hares-i2rs-info-model-policy-02 (and the related presentation at htt…

I think the idea is that policy is expressed via a data model, not via
a new language. Some of the infrastructure should be generic
(e.g. binding a policy to date/time) but then there will be specific
extensions. SUPA is planning to focus on inter-datacenter traffic
management as a use-case via VPNs and hence the specific extension
will have to detail VPN properties, not QoS or access control or
generic policy routing properties.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 12 Feb 2015 13:54:02 +0100

Hi,
> attention for this issue I guess).
Fair enough.

Note: I believe the charter proposal is not clear on the network 
topology versus service topology

This working group introduces the concepts of multi-level (multiple
levels of abstraction) and multi-technology (e.g., IP, VPNs, MPLS)
network abstractions to address the current separation between
development and deployment operations.

> technology. You think this won't be feasible?
One one side, you want a service-specific topology, so "VPN, IPSEC, 
tunnels, MPLS L2 or L3" specific topologieS I guess.
One the other end you want a technology agnostic topology, like "VPN" I 
guess. Is this feasible, I don't know? Is this wanted? I guess the 
subset of the topology (what you called a service topology) is actually 
the view that an application (*) requires to monitor and manage his own 
set of services.
(*) in architecture composed of: an application <-> controller <-> 
network elements

> generic policy routing properties.
I guess I don't understand the connection between a policy and a service.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Thu, 12 Feb 2015 13:56:42 +0100

Thanks JF.

For the rest of the SUPA people, don't hesitate to jump in this discussion.

Regards, Benoit
> Benoit,
> Let me try to answer some of your questions below. These are 
> definitely not “finalized” answers and might not reflect the consensus 
> of the whole group.
>
>> On Feb 2, 2015, at 9:53 AM, Benoit Claise <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> emails, some of the drafts, and the latest charter proposal). Here 
>> are some of my questions, posted to hopefully help structure the 
>> call, or follow up after the call.
> - This wasn’t discussed in Hawaii (it wasn’t on the agenda and 
> draft-clemm-i2rs-yang-network-topo-01 was expired at that time)
> The good news is that topology work is on the agenda for the I2RS 
> interim next Thursday (see 
> http://trac.tools.ietf.org/wg/i2rs/trac/wiki/TopologyDesignTeams). 
> Supa participants are willing to re-use the work of other groups such 
> as I2RS, as long as a timely completion envisioned.
>
>
> My personal opinion would be to remove the BUS terminology from these 
> drafts. A bus in computer engineers terms usually refers to some level 
> of parallelization or serialization (at least according to Wikipedia). 
> I don’t see how these concepts apply here.
>
>
> This was discussed on the list and during interim calls. Juergen 
> suggested getting back to more classic terms such as management 
> application and controller. I agree.  Juergen also mentioned 
> “management agent” could be confused with a component of SNMP.
>
> As Tina mentioned, these more or less show the same thing with 
> different levels of details, they shouldn’t be called options. This 
> will be updated in the slides.
>
>
> As discussed yesterday, the list and the name are mostly placeholders 
> at this point because the group wanted to avoid yet another renaming.
>
>
>> Or maybe you want to base the use cases on what the vendor CLIs can 
>> do today? Then how do we solve the multi-vendor/proprietary issues?
>
> I believe this is what the wording around “mapping” was about. 
> Connecting the top-down approach to proprietary implementations is 
> definitely not is scope here. It has to connect to common, 
> inter-operable concepts.
>
>
>> Having a L3VPN services model is not complex IMO, but translating to 
>> the PE configurations is what make challenging, specifically when 
>> from different vendors. It seems that SUPA completely hides this 
>> complexity.
> I’ve taken a look at draft-zhuang-l3vpn-yang-cfg, for example. My 
> understanding was that supa would provide a protocol-agnostic layer 
> above that and use a model like l3vpn-yang to configure in the 
> southbound direction (I use “direction” here because it would probably 
> talk to a controller and not to devices directly).
>
> The advantage of such an abstraction is to hide the implementation 
> details, including the fact it’s an L3VPN, form the higher-level apps. 
> In my mind, a supa interface consumer would only get a high-level 
> abstract topology information and then provision network resources 
> over that topology. I’m not sure this view is shared amongst all group 
> participants, some discussions on this would be welcome.
>
>
>> - It seems that you discuss multiple use cases in different drafts 
>> but I don't see any in the charter as deliverable?
>> "VPN, IPSEC, tunneles, MPLS L2 or L3", they look to me as multiple 
>> use cases, at least multiple distinct technolgies, and therefore as a 
>> huge piece of work
>
>> I don't know what you mean by "policy rules"? A new language? A set 
>> of YANG models, depending on the use case (Policy-based routing, QoS 
> The policy side is also unclear to me. But again, this would be a 
> high-level top-down approach. I like what’s described 
> in draft-hares-i2rs-info-model-policy-02 (and the related presentation 
> at http://tools.ietf.org/agenda/90/slides/slides-90-i2rs-2.pdf), but 
> again, that’s an I2RS document.
>
> JF
>
>
>
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Feb 2015 14:19:16 +0100

On Thu, Feb 12, 2015 at 01:54:02PM +0100, Benoit Claise wrote:
> >>The good news is that topology work is on the agenda for the I2RS interim 
> >>next Thursday (see 
> >>http://trac.tools.ietf.org/wg/i2rs/trac/wiki/TopologyDesignTeams 
> >><http://trac.tools.ietf.org/wg/i2rs/trac/wiki/TopologyDesignTeams>). Supa 
> >>participants are willing to re-use the work of other groups such as I2RS, 
> >>as long as a timely completion envisioned.
> >>

Abstraction simply means you leave out details. Consider a customer
using servers located on a varying number of nodes in different data
centers and the service request is to have protected connectivity
between the nodes in the different data centers. The connectivity
needs to have certain properties in terms of throughput, latency,
availability, ...

This service model is too abstract to implement it directly by an
automated system. A network operator who wants to provide the service
requested by the customer has to map things to the infrastructure.
Policy-driven means that the mapping from the rather abstract service
to the network infrastructure is policy driven, e.g. by using policy
rules. This allows, for example, the operator to route traffic between
data centers different depending on time of day or the current
utilization of links etc.

> (*) in architecture composed of: an application <-> controller <-> 

You may call it application - it is the thing that manages the
services. In the slides we called it a service manager (I personally
find application a bit too opaque but perhaps I am just a bit old
fashioned).

> >>high-level top-down approach. I like what’s described in 
> >>draft-hares-i2rs-info-model-policy-02 (and the related presentation at 
> >>http://tools.ietf.org/agenda/90/slides/slides-90-i2rs-2.pdf 
> >><http://tools.ietf.org/agenda/90/slides/slides-90-i2rs-2.pdf>), but 

I tried to explain it above. The policy controls how an abstract
service request is mapped to the infrastructure and the goal is that
the mapping is dynamic (within the bounds of the policy) and not
static.

/js

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 13 Feb 2015 00:54:56 -0000

[Blind copying TEAS - please continue the discussion on the SUPA list]

I don't want to say "do it my way", but on the subject of abstraction and virtualisation, I hope you will look at http://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/

The topic of aggregation, abstraction, virtualisation, network layering, and so forth has been the subject of almost continual work in the routing area for the last 15 years. So I don't think it fair to say "This working group introduces...."

Juergen is right that "policy" is an important input to the automation of abstraction, and the interested people may be right that that policy needs to have a configuration method. I am not completely convinced that this is critical for standardisation because the point at which abstraction is achieved is likely to be a single point of "topology export" from a network and so the configuration is applied at that point and not at a variety of routers.

If (and this is not certain long-term) export of virtualised topology is via BGP-LS (which is how a number of implementations have done it) then policy is, of course, easily imposed via BGP export policies.

Thanks,
Adrian

---

From: John Strassner <[email-masked]>
Date: Fri, 20 Feb 2015 01:33:20 +0000

Juergen wrote: " I think the idea is that policy is expressed via a data model, not via a new language. Some of the infrastructure should be generic (e.g. binding a policy to date/time) but then there will be specific extensions. SUPA is planning to focus on inter-datacenter traffic management as a use-case via VPNs and hence the specific extension will have to detail VPN properties, not QoS or access control or generic policy routing properties."

I **almost** agree. :-)

I think that what is required is to express policy as an information model, and in a form more generic than that defined in RFC3060 and related drafts (since they only define one type of (limited) policy rule, of type condition-action).

Then, given a **single** information model, multiple data models could be derived from it that can interoperate because they are all using the same concepts. Without this single information model, the data models will likely be designed in a siloed fashion, and interoperability will suffer.

Finally, if we define an information model, then we can use its components to help define a language (intent-based or otherwise). Without the information model, then how do we define a technology-neutral grammar for the language? (Note: I am still assuming that the "P" in SUPA stands for policy, and that we still want to build a language. If this is indeed true, then the first step should be the information model, so as to make the language as generic and useful as possible. I am also assuming that we are talking a Domain-Specific Language, not Python^2.)

regards,
John

Dr. John Strassner, Ph.D.
CTO, Software Laboratory, CRD

Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050
  Office:  +1.408.330.4923
  Email:   [email-masked]

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, February 04, 2015 8:47 AM
To: Benoit Claise
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] SUPA questions

Yes, we will fix that.

/js

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Feb 2015 12:50:54 +0100

> Then, given a **single** information model, multiple data models could be derived from it that can interoperate because they are all using the same concepts. Without this single information model,…

Yes, but in the IETF we tend to skip the information model if there is
strong belief that there will be only one data model.

> Finally, if we define an information model, then we can use its components to help define a language (intent-based or otherwise). Without the information model, then how do we define a technology-n…

I think that the definition of a domain-specific language is very
different from the definition of an information / data model.

/js

---

From: "Natale, Bob" <[email-masked]>
Date: Fri, 20 Feb 2015 13:59:01 +0000

Hi Juergen,

The two points you make below are clearly valid, but:

- We already know (via SUPA charter objectives and marketplace experience) that we will need more than one data model ... and,
- While an IM is something different from a DSL, a well-designed IM would tend to support a well-designed DSL (should a DSL be developed).

Avanti,
BobN

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Friday, February 20, 2015 6:51 AM
To: John Strassner
Cc: Benoit Claise; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] SUPA questions

> Then, given a **single** information model, multiple data models could be derived from it that can interoperate because they are all using the same concepts. Without this single information model,…

Yes, but in the IETF we tend to skip the information model if there is strong belief that there will be only one data model.

> Finally, if we define an information model, then we can use its 
> components to help define a language (intent-based or otherwise). 
> Without the information model, then how do we define a 
> technology-neutral grammar for the language? (Note: I am still 
> assuming that the "P" in SUPA stands for policy, and that we still 
> want to build a language. If this is indeed true, then the first step 
> should be the information model, so as to make the language as generic 
> and useful as possible. I am also assuming that we are talking a 
> Domain-Specific Language, not Python^2.)
>

I think that the definition of a domain-specific language is very different from the definition of an information / data model.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Feb 2015 15:08:25 +0100

> - We already know (via SUPA charter objectives and marketplace experience) that we will need more than one data model ... and,

I do not recall where this is stated in the charter - I think it only
talks about YANG.

> - While an IM is something different from a DSL, a well-designed IM would tend to support a well-designed DSL (should a DSL be developed).

Sounds a bit abstract to me.

/js

---

From: John Strassner <[email-masked]>
Date: Fri, 20 Feb 2015 12:25:02 -0800

Please see inline

On Fri, Feb 20, 2015 at 01:33:20AM +0000, John Strassner wrote:
> Juergen wrote: " I think the idea is that policy is expressed via a data
model, not via a new language. Some of the infrastructure should be generic
(e.g. binding a policy to date/time) but then there will be specific
extensions. SUPA is planning to focus on inter-datacenter traffic
management as a use-case via VPNs and hence the specific extension will
have to detail VPN properties, not QoS or access control or generic policy
routing properties."
>
> I **almost** agree. :-)
>
> I think that what is required is to express policy as an information
model, and in a form more generic than that defined in RFC3060 and related
drafts (since they only define one type of (limited) policy rule, of type
condition-action).
>
> Then, given a **single** information model, multiple data models could be
derived from it that can interoperate because they are all using the same
concepts. Without this single information model, the data models will
likely be designed in a siloed fashion, and interoperability will suffer.

<jcs>
People tend to conflate "one data model" with "one technology used to build
the data model".
There will never be "one" data model. Most established management systems
interface with multiple types of repositories (e.g., directories, RDBMSs,
in-memory stores) that each have different protocols and data structures.
Just because I can represent a port as a row in a table or as an FQDN does
NOT mean that they are interoperable. Never mind the fact that the
protocols used to retrieve data vary widely in complexity.

Similarly, just because there are two Yang models (not modules) does NOT
mean that they can interoperate either. If the structure of the models are
different, and the tags used are different, how does one manager know that
a "foo" in model A is a "bar plus some added functionality" in model B?

So yes, I know that the IETF tends to skip info models (even though there
are a lot of drafts that claim to be info models), but for this WG to
succeed, I believe that we must consider info models and define a mapping
to Yang. Note that there could be multiple mappings to other technologies,
which is the point of having an info model in the first place.
</jcs>

> Finally, if we define an information model, then we can use its
components to help define a language (intent-based or otherwise). Without
the information model, then how do we define a technology-neutral grammar
for the language? (Note: I am still assuming that the "P" in SUPA stands
for policy, and that we still want to build a language. If this is indeed
true, then the first step should be the information model, so as to make
the language as generic and useful as possible. I am also assuming that we
are talking a Domain-Specific Language, not Python^2.)

<jcs>
Agreed. Perhaps I should have been clearer. Once an information model is
defined, then one has a solid definition of objects of interest. One could
then use those definitions to build a more useful grammar than without
having those definitions.

Taken a step further, if it was me, I would use the info model to define
abstract data types. This now defines the function (but not the
implementation) of the data structures necessary, as well as a set of
robust interfaces. See, for example, Prof. Bertrand Meyer's seminal book,
"Object-Oriented Software Construction" (2nd edition).
</jcs>

regards,
John

On Fri, Feb 20, 2015 at 3:50 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > Juergen wrote: " I think the idea is that policy is expressed via a data
> model, not via a new language. Some of the infrastructure should be generic
> management as a use-case via VPNs and hence the specific extension will
> have to detail VPN properties, not QoS or access control or generic policy
> routing properties."
> >
> > I **almost** agree. :-)
> >
> > I think that what is required is to express policy as an information
> model, and in a form more generic than that defined in RFC3060 and related
> drafts (since they only define one type of (limited) policy rule, of type
> condition-action).
> >
> > Then, given a **single** information model, multiple data models could
> be derived from it that can interoperate because they are all using the
> same concepts. Without this single information model, the data models will
> likely be designed in a siloed fashion, and interoperability will suffer.
> >
>
> components to help define a language (intent-based or otherwise). Without
> the information model, then how do we define a technology-neutral grammar
> for the language? (Note: I am still assuming that the "P" in SUPA stands
> for policy, and that we still want to build a language. If this is indeed
> true, then the first step should be the information model, so as to make
> the language as generic and useful as possible. I am also assuming that we
> are talking a Domain-Specific Language, not Python^2.)
> >
>

-- 
regards,
John

---

From: "Natale, Bob" <[email-masked]>
Date: Sat, 21 Feb 2015 07:43:05 +0000

Hi Juergen,

Referring to the draft SUPA charter per the 2015-02-06 version of the slide deck:

- Concerning an IM and multiple DMs: Slide #3 calls for "three types of DMs" and slide #5 identifies three specific DMs and a fourth set of extensions DMs addressing the inter-datacenter traffic management use case. That equates to multiple DMs in my book. The fact that those are all to be composed in the Yang data modeling language does not negate (IMHO) the value of an IM to facilitate effective and efficient DM development. Furthermore, as John has noted (or at least implied, IIRC), we would not want to rule out the use of (additional) other data modeling languages in the eventual set of tools supporting SUPA (and related efforts). I believe this interpretation is consistent with RFC3444.

- Concerning the potential value of an IM in facilitating development of a corresponding DLS being "a bit abstract": Perhaps. I think John has added some more concrete explanation (not that I think you really need it, however :-). And I would note that slides #1 and #2 of the charter summary acknowledge the positive role of abstraction in the SUPA work.

Just trying to ensure common understanding ... trying not to be argumentative.

Avanti,
BobN

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, February 20, 2015 9:08 AM
To: Natale, Bob
Cc: John Strassner; Benoit Claise; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] SUPA questions

On Fri, Feb 20, 2015 at 01:59:01PM +0000, Natale, Bob wrote:
> - We already know (via SUPA charter objectives and marketplace 
> experience) that we will need more than one data model ... and,

I do not recall where this is stated in the charter - I think it only talks about YANG.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 21 Feb 2015 10:00:19 +0100

> protocols used to retrieve data vary widely in complexity.

The IETF is not about internal implementation specific data
structures, it concentrates on the information exchanged over the
wire. And it is often desirable to have 1 protocol instead of N
protocols and it is often desirable to have 1 data model for a given
problem domain instead of having M data models for the same problem.

> a "foo" in model A is a "bar plus some added functionality" in model B?

Yes, this is why the IETF generally prefers to have 1 YANG data model
for a given problem domain.

> which is the point of having an info model in the first place.

There are people who write whatever they are told to write or they
label whatever they write in the term of the day. ;-)

More seriously, I2RS (for example) has information models in the
charter because the protocol / data modeling framework was initially
not selected (there other WGs like that). It seems to me that there
was also period where WGs were encouraged to write information models
since it was unclear what would be the data modeling language of the
future. Since YANG is getting traction in the industry, some people
start asking why they have to do both an information model and a YANG
model. That said, there are also examples of working groups that do
information models for a good reason. LMAP, for example, does an
information model because the model might be translated to an
extension of TR69 within BBF and say a YANG data model within the
IETF.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 21 Feb 2015 10:07:58 +0100

Bob,

I think there is likely some confusion here. The charter lists
multiple DMs where each DM has a separate scope. An IM is valuable of
you have multiple DMs with the same scope. An example to make things
clear.

  These are 3 DMs each having different scope:

   - ietf-interfaces.yang
   - ietf-ip.yang
   - ietf-system.yang

  These are 2 DMs having overlapping scope:

   - ietf-interfaces.yang
   - IF-MIB

  There is only an implicit information model for the interfaces
  abstraction here.

What the text in the charter talks about is the first case, N data
models for different scopes.

/js

---

From: John Strassner <[email-masked]>
Date: Mon, 23 Feb 2015 01:05:31 +0000

Please see inline...look for <jcs2>..</jcs2>

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Saturday, February 21, 2015 1:00 AM
To: John Strassner
Cc: John Strassner; Benoit Claise; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] SUPA questions

<jcs2>
You missed my point.

Of course it is more desirable to have one protocol. But one cannot have one data model unless one vendor supplied all of the network equipment, and even then, there are many examples of one vendor having multiple data models! In addition, please see the next comment.
</jcs2>

<jcs2>
Yang is a XML dialect. It can be used to produce data models. However, there is no ability to guarantee that one element of one Yang model does not conflict with another element in another Yang model. For example, there are multiple definitions of "node" in existing Yang models.

Therefore, unless common concepts are defined in a reusable manner that all Yang models can use, I fail to see how one can say that there is "ONE" Yang data model per domain.
</jcs2>

<jcs2>
Not all information models convey the same information. :-(

Let's start with the definition of an information model from RFC3198:
" An abstraction and representation of the entities in a managed environment, their properties, attributes and operations, and the way that they relate to each other. It is independent of any specific repository, software usage, protocol, or platform."

Note the phrase "...and the way that they relate to each other."

Now, let's take a simple example: draft-ietf-i2rs-rib-info-model-05. On page 6, this draft says:

A RIB is identified by its name and a RIB is contained within a routing instance (Section 2.2). The name MUST be unique within a routing instance. All routes in a given RIB MUST be of the same type (e.g. IPv4). Each RIB MUST belong to a routing instance.

This is a perfectly well-intentioned statement of what a RIB is and part of its behavior. However, the problem comes in how this is specified. This draft uses a simple grammar to specify its behavior, but the grammar itself does not have the ability to describe all of the different ways that different elements relate to each other. Specifically, we have (stating at page 16):

<routing-instance> ::= <INSTANCE_NAME>...    (1)
** elided **
<rib-list> ::= (<rib> ...)                   (2)
<rib> ::= <RIB_NAME> <rib-family>            (3)
          [<route> ... ]                     (4)
          ** elided **

In matching statements 1-4 to the above well-intentioned description of the RIB (i.e., "A RIB is...), how do you:
   a) guarantee that a given RIB's name is unique within a routing instance?
   b) guarantee that all routes are of the same type?

It is obvious what the goal of the grammar is, but it does not, by itself, satisfy the goals stated in the referenced paragraph.

So yes, this is well along the way to being a very useful information model. However, it does not yet satisfy the requirement to describe different types of relationships.
</jcs2>

/js

---

From: John Strassner <[email-masked]>
Date: Mon, 23 Feb 2015 01:31:26 +0000

Hi Juergen,

You wrote: " An IM is valuable of you have multiple DMs with the same scope." I have to disagree.

An IM is invaluable, period. Even if you have multiple DMs that are completely orthogonal, how do you tie the system together? How do you superimpose the model of managed entities that are not modeled in any of those DMs onto the collection of DMs? How do you make the set of currently orthogonal DMs extensible, so that new concepts may be added without conflicting with any of the existing concepts? This is what an IM provides you.

This is also why you only want one IM, not multiple.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Saturday, February 21, 2015 1:08 AM
To: Natale, Bob
Cc: John Strassner; Benoit Claise; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] SUPA questions

Bob,

   - ietf-interfaces.yang
   - ietf-ip.yang
   - ietf-system.yang

   - ietf-interfaces.yang
   - IF-MIB

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Feb 2015 17:20:39 +0100

Inline using good old traditional quoting...

> Of course it is more desirable to have one protocol. But one cannot have one data model unless one vendor supplied all of the network equipment, and even then, there are many examples of one vendor…

The IETF is about information exchanged over the wire and the general
goal is to have one data model for that. I do not think a standard
data model equates with having a single implementation/vendor.

> Therefore, unless common concepts are defined in a reusable manner that all Yang models can use, I fail to see how one can say that there is "ONE" Yang data model per domain.

YANG is a tool. UML is a tool. It all boils down to the way you use
tools and the way you can keep development process under reasonable
control.  The IETF does its work in a certain perhaps imperfect way
but I do not think SUPA is going to change that. I personally do not
expect a bug-free all encompasing information model coming out of the
IETF anytime soon.

> So yes, this is well along the way to being a very useful information model. However, it does not yet satisfy the requirement to describe different types of relationships.

You should consider sending this input to I2RS.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Feb 2015 17:30:27 +0100

> This is also why you only want one IM, not multiple.

If you want to create this one IM for the Internet, you probably need
to file a BOF request. I do not think SUPA was planned to take on this
task.

/js

---

From: John Strassner <[email-masked]>
Date: Mon, 23 Feb 2015 16:39:07 +0000

Inline using <jcs3>..</jcs3>

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Monday, February 23, 2015 8:21 AM
To: John Strassner
Cc: Benoit Claise; [email-masked]; [email-masked]; [email-masked]; John Strassner
Subject: Re: [Supa] SUPA questions

<jcs3>
This is orthogonal to my point.
You cannot have one data model for one domain, as there is already too much fragmentation in functionality in the industry.
</jcs3>

<jcs3>
No, it boils down to the **capabilities** of the tool, and whether the tool has the ability to enforce said capabilities. UML defines four basic types of relationships, any of which can be further restricted using OCL. Yang cannot do that.

This does not mean that UML is good or Yang is bad; it is a simple statement of facts. So, in the node example below, this would be easily enforceable in UML, or in other languages that can formally define relationships and constraints. It is not enforceable in Yang.
</jcs3>

You should consider sending this input to I2RS.
<jcs3>
I think it is a larger question than that. See above comments.
</jcs3>

/js

---

From: John Strassner <[email-masked]>
Date: Mon, 23 Feb 2015 16:40:30 +0000

Humorous, but this was not my point.

My point was that a DM per problem domain is not possible, and if we want interoperability, we need to build an IM that the DMs derive from.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, February 23, 2015 8:30 AM
To: John Strassner
Cc: Natale, Bob; Benoit Claise; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] SUPA questions

/js

---

From: "Natale, Bob" <[email-masked]>
Date: Mon, 23 Feb 2015 17:05:35 +0000

Yes ... What John asserts below is one of the (hard-earned) lessons I have learned over the decades as well.

[ALERT -- Total editorial, FWIW: I am wondering whether the apparent disconnect on this point derives from a propensity to work "bottom-up and opportunistically", on the one hand, versus "top-down and architecturally", on the other. As a gross generalization, the IETF _seems_ more inclined toward the former while organizations like ETSI _seem_ more inclined toward the latter. My personal bias is toward the latter until the point at which the former can provide the interoperable functional parts to make the bigger picture solution work, especially when addressing a transformation on the scale of network virtualization (and all its constituent technologies) ... YMMV, of course. There are some SDOs and equivalent initiatives that fall somewhere in between those two poles ... I find ATIS to be one such body and often benefit from their work (but my employer is not a member organization, sadly). It can be counter-productive to pursue, beyond a certain point, the top-down/architectural approach when working in a bottom-up/opportunistic venue -- and vice-versa -- if a practical consensus does not surface and polar positions start to crystallize.]

Avanti,
BobN

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Monday, February 23, 2015 11:41 AM
To: Juergen Schoenwaelder; John Strassner
Cc: Benoit Claise; Natale, Bob; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] SUPA questions

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Monday, February 23, 2015 8:30 AM
To: John Strassner
Cc: Natale, Bob; Benoit Claise; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] SUPA questions

> This is also why you only want one IM, not multiple.

If you want to create this one IM for the Internet, you probably need to file a BOF request. I do not think SUPA was planned to take on this task.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Feb 2015 19:53:29 +0100

On Mon, Feb 23, 2015 at 05:05:35PM +0000, Natale, Bob wrote:
> 
> FWIW: I am wondering whether the apparent disconnect on this point
> derives from a propensity to work "bottom-up and opportunistically",
> on the one hand, versus "top-down and architecturally", on the
> other.
>

Yes, this is the key difference and trying to prove one approach to be
better than the other is a pointless waste of time. They both fail in
their extremes.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Feb 2015 19:53:49 +0100

> You cannot have one data model for one domain, as there is already too much fragmentation in functionality in the industry.

Lets simply disagree.
 
> This does not mean that UML is good or Yang is bad; it is a simple statement of facts. So, in the node example below, this would be easily enforceable in UML, or in other languages that can formall…

I may disagree here as well. Lets keep it that way.

> I think it is a larger question than that. See above comments.

Up to you, but perhaps too bad for I2RS.

/js

---

From: John Strassner <[email-masked]>
Date: Mon, 23 Feb 2015 19:12:00 +0000

I would like to know the technical reasons why you disagree. In addition, you wrote "Up to you, but perhaps too bad for I2RS." I did NOT mean that I wouldn't tell I2RS; I am simply saying that this is a systemic problem with Yang.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, February 23, 2015 10:54 AM
To: John Strassner
Cc: Benoit Claise; John Strassner; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] SUPA questions

Lets simply disagree.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Feb 2015 20:45:00 +0100

John,

I am not interested to discuss further since we talk past each other
in the best case. If you write

  You cannot have one data model for one domain, as there is already
  too much fragmentation in functionality in the industry.

then I can only accept this as your opinion. There is either a
fundamental disconnect about the semantics of the terms we use or
there is a disconnect about what is feasible to achieve or some other
fundamental disconnect.

And the thing you quoted in the context of I2RS has nothing to do with
YANG. That said, I believe you can screw up with any tool, including
YANG.

/js

---

From: John Strassner <[email-masked]>
Date: Mon, 23 Feb 2015 20:37:53 +0000

Juergen,

Fine on the disconnect, thought I would be happy to talk at the IETF if you want.

However, I disagree on you last statement:
> And the thing you quoted in the context of I2RS has nothing to do with YANG. That said, I 
> believe you can screw up with any tool, including YANG.

This has everything to do with Yang, because Yang does not have a way to enforce these types of constraints. At least as far as I know. And I hope I'm wrong. :-)

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Monday, February 23, 2015 11:45 AM
To: John Strassner
Cc: Benoit Claise; [email-masked]; [email-masked]; [email-masked]; John Strassner
Subject: Re: [Supa] SUPA questions

John,

/js