Subject: [Supa] SUPA discussion on 2014-10-10

From: JF Tremblay <[email-masked]>
Date: Fri, 10 Oct 2014 13:15:59 -0400

Dear group, 
These are my notes from the supa discussion this morning. 

This is quite verbatim, but I missed a few comments from Tina and Andrew. 

-------------
Notes on SUPA follow-up discussion
2014/10/10, on webex
11:10 AM ~ 12:19 PM EDT

Participants (in alphabetical order): 
-------------
Andrew Qu (Call-in User_2)
Benoit Claise (host)
Eric Voit
Georgios Karagiannis
JF Tremblay
Luis Contreras
Parviz Yegani (Call-in User_3)
Tina Tsou

JFT agreed to be the notetaker.

--------------

Benoit Claise: 
- Five main comments from the IESG call were sent to the list
- What is not clear to the IESG: 
 + A lot of keywords, for example "networks interfaces", "restconf/netconf", protocol extensions, Service models, standard interfaces
 + Difficult to understand
 + The "unified and shared policies" was not understood too
 + The charter speak of interfaces […]
- Today: could present slides (but not for 30 minutes!)

Tina suggests we let an operator (Luis) talk first. 

Luis: 
- From my perspective an an operator
- We'd like to have a way to abstract topology to be consumed by service applications
- A lot of technologies in vendors and technologies in the network
- Several networks, some of them rented, leased, not completely under the provider control
- Heterogeneous infrastructure
- Common approach to the diversity. 
- Simplify and abstract the diversity to offer the infra for consuption to others and gain efficiencies. 
- Having the capability of handling diversity from vendors, technologies, etc.

Benoit: 
- To summarize: to have the topology for the network in a network and vendor-neutral way. 

Luis: 
- May not be completely possible. Vendors are too different.
- The first abstraction level [implementation?] could not be completely neutral.
- But it would improve over time. 
- As I see this, need different levels of complexity and details. 

Benoit
- Initially : a topology
- What to expect from this topology? 
  + First is only topology
  + Second is more about services, with more details. 
  + For example are nodes wireless or wired? 

Luis: 
- For example: quality requirements from the users. Characteristics such as SLAs, QoS depending of context. 
- In other scenarios, it does not matter. The level of abstraction depends on the service. 
- Need a unified view for unified management and operation. 
- The operator could go deep or not in abstraction depending of needs. 

Benoit:
- To summarize: 
 + Say a controller with an app. Simple use case: video demand from the app. 
 + There's a distinction between what the app want, above the controller
 + Bandwith, sla, path are below a controller. Topology is one of them, one element. 
 + Can I provide this demand for this customer? 
 + Need view of full network, bandwith implication and impacts. 
 + Whether this is a generic service is debatable. Could be a video on demand specific service. 
- Topology is granted. Then what else?

Georgios
- In terms of service: need boundaries [...], know what are the endpoints
- Need the path. Controllers has all details, but the app only needs the key points(such as available bandwidth, SLA)
- Another serivce would use the same topology, but may use a different abstraction level. 

Benoit
- This is my point. From an app point-of-view, different building blocks are needed beside the topology. 
- These blocks are provided by different models in IETF groups (BGP, SFC, etc)

Andrew Qu
- Came in late, sorry
- Abstraction model woule provide connectivity in real time. 
- Operators often need more than shortest paths, OSPF is not dynamic enough
- Supa come in handy  
- Topology can be seen as a matrix. 
- A topology is very useful to abstract services in the future. 

Benoit
- Yes a topology is required and is useful for services.
- I2RS is planning a a topology answer in the routing area

Georgios
- Network service model could be done in supa. 
- We are talking about network services. VPN services, Video-on-demand, TE between DC, not about application services. 
- Focus more on I2RS: other models than i2rs. 
- Could the mapping to service models and topology would be realized. 

Parviz: 
- This is a question that came up internally.
- I2RS charter does not cover the data model, correct?

Benoit
- I2RS covers data models for protocols 
- This was mentioned by the routing ADs during the call
[searching...]
- The I2RS charter says that they are not charted to develop protocols or data models

Parviz
- Information model is RFC3444 (protocol neutral), Data model (tied to a protocol) is yang. 
- Currently I2RS charter does not include data models. 
- The wisom of IETF can find how to handle this

Luis
- I2RS is limited in scope

Benoit
- Spoke with ISPs: is the IETF fast enough to standardize what you need? 
- By trying to standardize services, they will always be late.
- ISPs told us: give us the building blocks, we'll build the services

Luis
- The problem is handling the infra from a third party. 

Parviz
- Let's take NFC and infrastructure as a service. 
- Prime use case coming, people are saying: large ISPs own the infra.
- But MVNOs would like to access the topology they do not own. 

Luis
- Similar approch is possible for mobile backhaul, for infrastructure sharing. 
- This would be a tool to manage these. 

Parviz: 
- I'd be happy to send a link to these NFV use cases. 

Benoit:
- Looking at the charter proposal: L3VPN, TE, QoS
- Now I hear about NFV, VoD. 
- What is your scope? Granted the topology is needed. 
- The scope is just massive here. 

Georgios: 
- Would you recommend focusing one use case or two?

Benoit: 
- I wasn't suggesting anything. 
- I heard on the call that the supa guys were all over the place. 
- Topology has to be there. 
- Need access to everything a controller. But what do you need above?
- Reduce the scope (try to focus on a use case)

Parviz
- If you see the driver for SFC, there was a discussion about the same point.
- SFC leadership said they needed to scope down the use cases. 
- Can we limit to certain use cases? 

Benoit
- I understand you want services yang models
- But they go in all directions. There's no commonatlity between them
- Unified and shared? What is the common point?

Georgios:
- Unified: tried to reach Luis' goal
- Unified way to described service models.

Tina
[...]

Benoit:
- Thank you for your sentence: "network topology and config that can be used to map network services to yang models". 
- Thanks for this summary. 

Tina
Service models: are [..]

Benoit
- Could be L2VPN, SFC, L3VPN. The app is above that.
- Any of these things that requires multiple configuration point in the network
- Setup QOS for example. Could be modeled in yang. 
- Those are examples of service

Georgios
- We'll try to focus on one or two use cases. 
- Here are the slides. 
  + Apps running the network serivces. 
  + Controller and northbound interface. 
  + Interface between the controller and network elements. 
- Controller has all the configuration of the nodes. It provides a view.
- Different types of abstractions depending of application. 

Benoit: 
- Let me summarize 
  + The physical topology is under the controller
  + Above is a sub-topoogy specific to the application. 

<Luis Contreras left around this time>

Georgios
- Could scale to multiple controllers. It's in scope. 
- For example for the VPN service: needs specific information. 
- The service gets the abstract view of the network topology and say I'd like to have a vpn with these two endpoints. 
- Then the controller say it could do it, then implements (or map) the service to the topology configuration. 

Benoit: 
- Got a few question on service specific abstraction
  + How do you know you need to provide this specific filter to this app.
  + In such a case, what can we standardize?

Georgios
- We also use policies. The controller could map policies to configuration 
- Is this clear?

Benoit: 
- I think this is clear. 
- I have an open point to check with the routing area chairs about i2rs
- Not everybody will read the problem statement. You need clear text in the charter. 

Georgios
- Let's do the last slide, it's another service. 
- This service abstraction to adjust trafic going to links and somehow chage them based on the demands. 
- The policy would say go this way. 
- The controller would map this. 

Benoit
- Luis, is this what you want? 
  (But Luis has left earlier)

Parviz
- The question to Luis could be handled by [...]. 

Benoit
- You confused me.
- One one side, I heard the application gets a subset of the topology.
- I was aksing Luis if that's what he wanted. 
- You said, controller please provide a service between A and B
- Who has the full topology? 

Parviz
- Maybe we need a follow-up session

Georgios
- There are different ways of doing this. There are different options. 

Benoit
- You should just update your charter text with what you want to do.
- The words highlighted in red were not understood.

Georgios
- Is it more clear to you?

Benoit 
- It's clearer, but not not what my interpretation of the charter text would lead to. 
- Thanks. It's past the top of the hour now.

Andrew:
- Can we take a moment to make (....) clearer.
- [...]
- In this case, this is orchestration. 

Georgios
- This could be done, not sure we can have an orchestration use case. 
- Let's discuss this on the mailing list. 

Parviz
- We have a similar use case internally
- Takeaways for the call
 + First, I2RS is out of scope, the charter does not include data models. 
 + Second takeway: limit the use cases to two use cases. 
 + Third point: information model or data model? (information model is neutral, data is tied and is in yang)

Tina: 
- We're thinking yang models. 
- It's a data model. 

Parviz: 
- Next step would be a bar bof. Do you plan one? 

Georgios
- Next step is to make charter more clear 
- Describe which use cases to choose. 
- The intention is probably to have a bar bof
- Let's continue on the list

----------------------

JF

---

From: Tina TSOU <[email-masked]>
Date: Sat, 11 Oct 2014 03:59:49 +0000

Dear JF,

Thank you for taking notes.

Sorry about bad audio from WebEx China.

What I said was below.
We want to create YANG models of network topology and configuration, that we can use to map network service specific YANG models into device specific YANG models.

In the end of the day, the deliverables would be
1) Yang models of network topology
2) Yang models of network configuration
3) Mapping of network service specific yang models to device specific Yang models
4) Device specific yang models not covered by other existing WGs

I aslo said about the relationship of draft-contreras-supa-yang-network-topo and draft-hares-i2rs-info-model-service-topo had been discussed in the mailing list, see below.
http://www.ietf.org/mail-archive/web/supa/current/msg00093.html
Agreed with JF that the draft-hares is closer to physical topology. Draft-contreras is a view of topology.

Thank you,
Tina

From: Supa [mailto:[email-masked]] On Behalf Of JF Tremblay
Sent: Saturday, October 11, 2014 1:16 AM
To: [email-masked]
Subject: [Supa] SUPA discussion on 2014-10-10

Dear group,

-------------

--------------

Benoit Claise:
 + The charter speak of interfaces [...]

Luis:

Benoit:

Luis:

Benoit
- Initially : a topology

Luis:

Benoit:
- To summarize:

Georgios

Benoit

Andrew Qu
- Came in late, sorry

Benoit

Georgios

Parviz:

Benoit

Parviz

Luis

Benoit

Luis

Parviz

Luis

Parviz:

Benoit:

Georgios:

Benoit:

Parviz

Benoit

Georgios:

Tina
[...]

Benoit:

Tina
Service models: are [..]

Benoit

Georgios

Benoit:
- Let me summarize

Georgios

Benoit:

Georgios

Benoit:
- I think this is clear.

Georgios

Benoit

Parviz

Benoit
- You confused me.

Parviz

Georgios

Benoit

Georgios

Benoit

Andrew:

Georgios

Parviz

Tina:

Parviz:

Georgios

----------------------

JF

---

From: "Jun Bi" <[email-masked]>
Date: Sat, 11 Oct 2014 12:20:42 +0800

Hi All,

Sorry that I could not attend this meeting due to schedule conflict. 

Thanks for JF's notes, I can see the discussion.

Personally, I agree with Tina's suggestion on deliverables.

We may also add "examples" into the deliverable list.

Best Regards,

Jun

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tina
TSOU
Sent: Saturday, October 11, 2014 12:00 PM
To: JF Tremblay; [email-masked]
Subject: Re: [Supa] SUPA discussion on 2014-10-10

Dear JF,

What I said was below.

We want to create YANG models of network topology and configuration, that we
can use to map network service specific YANG models into device specific
YANG models.  

3) Mapping of network service specific yang models to device specific Yang
models

I aslo said about the relationship of draft-contreras-supa-yang-network-topo
and draft-hares-i2rs-info-model-service-topo had been discussed in the
mailing list, see below.

Agreed with JF that the draft-hares is closer to physical topology.
Draft-contreras is a view of topology.

Thank you,

Tina

From: Supa [mailto:[email-masked]] On Behalf Of JF Tremblay
Sent: Saturday, October 11, 2014 1:16 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [Supa] SUPA discussion on 2014-10-10

Dear group, 

-------------

2014/10/10, on webex

11:10 AM ~ 12:19 PM EDT

-------------

Benoit Claise (host)

Eric Voit

Georgios Karagiannis

JF Tremblay

Luis Contreras

Tina Tsou

--------------

Benoit Claise: 

 + A lot of keywords, for example "networks interfaces", "restconf/netconf",
protocol extensions, Service models, standard interfaces

 + The charter speak of interfaces [.]

Luis: 

- We'd like to have a way to abstract topology to be consumed by service
applications

- Several networks, some of them rented, leased, not completely under the
provider control

- Simplify and abstract the diversity to offer the infra for consuption to
others and gain efficiencies. 

- Having the capability of handling diversity from vendors, technologies,
etc.

Benoit: 

- To summarize: to have the topology for the network in a network and
vendor-neutral way. 

Luis: 

- The first abstraction level [implementation?] could not be completely
neutral.

Benoit

- Initially : a topology

  + First is only topology

Luis: 

- For example: quality requirements from the users. Characteristics such as
SLAs, QoS depending of context. 

- In other scenarios, it does not matter. The level of abstraction depends
on the service. 

Benoit:

- To summarize: 

 + Bandwith, sla, path are below a controller. Topology is one of them, one
element. 

 + Whether this is a generic service is debatable. Could be a video on
demand specific service. 

Georgios

- Need the path. Controllers has all details, but the app only needs the key
points(such as available bandwidth, SLA)

- Another serivce would use the same topology, but may use a different
abstraction level. 

Benoit

- This is my point. From an app point-of-view, different building blocks are
needed beside the topology. 

- These blocks are provided by different models in IETF groups (BGP, SFC,
etc)

Andrew Qu

- Came in late, sorry

- Supa come in handy  

Benoit

Georgios

- We are talking about network services. VPN services, Video-on-demand, TE
between DC, not about application services. 

Parviz: 

Benoit

[searching...]

- The I2RS charter says that they are not charted to develop protocols or
data models

Parviz

- Information model is RFC3444 (protocol neutral), Data model (tied to a
protocol) is yang. 

Luis

Benoit

Luis

Parviz

Luis

- Similar approch is possible for mobile backhaul, for infrastructure
sharing. 

Parviz: 

Benoit:

Georgios: 

Benoit: 

Parviz

- If you see the driver for SFC, there was a discussion about the same
point.

Benoit

Georgios:

Tina

[...]

Benoit:

- Thank you for your sentence: "network topology and config that can be used
to map network services to yang models". 

Tina

Service models: are [..]

Benoit

- Any of these things that requires multiple configuration point in the
network

Georgios

- Here are the slides. 

Benoit: 

- Let me summarize 

Georgios

- The service gets the abstract view of the network topology and say I'd
like to have a vpn with these two endpoints. 

- Then the controller say it could do it, then implements (or map) the
service to the topology configuration. 

Benoit: 

Georgios

- Is this clear?

Benoit: 

- I think this is clear. 

- Not everybody will read the problem statement. You need clear text in the
charter. 

Georgios

- This service abstraction to adjust trafic going to links and somehow chage
them based on the demands. 

Benoit

Parviz

Benoit

- You confused me.

Parviz

Georgios

Benoit

Georgios

Benoit 

- It's clearer, but not not what my interpretation of the charter text would
lead to. 

Andrew:

- [...]

Georgios

Parviz

- Takeaways for the call

 + Third point: information model or data model? (information model is
neutral, data is tied and is in yang)

Tina: 

- It's a data model. 

Parviz: 

Georgios

----------------------

JF

---

From: Benoit Claise <[email-masked]>
Date: Sat, 11 Oct 2014 14:04:24 +0200

Dear all,

Let me correct the meeting minutes.
See in line.
>  + A lot of keywords, for example "networks interfaces", 
> "restconf/netconf", protocol extensions, Service models, standard 
> interfaces
> - Simplify and abstract the diversity to offer the infra for 
> consuption to others and gain efficiencies.
NEW:
To summarize: to have the topology for the network in a technology and 
vendor-neutral way
>   + For example are nodes wireless or wired?
NEW:
- you want a topology, but what exactly do you want
     1. only the topology
     2 or the topology with the services mapping.

>  + Can I provide this demand for this customer?
OLD: Let's take Luis' use case: "Can I provide this demand for this 
customer?"
> - Need the path. Controllers has all details, but the app only needs 
> the key points(such as available bandwidth, SLA)
> - We are talking about network services. VPN services, 
> Video-on-demand, TE between DC, not about application services.
Will the IETF fast enough to standardize the services YANG models?
> - Looking at the charter proposal: L3VPN, TE, QoS
NEW: Looking at the charter proposal, I see diverse use cases: L3VPN, 
TE, QoS
> - Thank you for your sentence: "network topology and config that can 
> be used to map network services to yang models".
Tina's sentence was: We want to create YANG models of network topology 
and configuration that we can use to map network service specific YANG 
models into device specific YANG models.

Regards, Benoit
> - The service gets the abstract view of the network topology and say 
> I'd like to have a vpn with these two endpoints.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 11 Oct 2014 16:38:29 +0200

> 4) Device specific yang models not covered by other existing WGs

I do not understand why 4) since it is open ended nor do I understand
how it relates to the current NETMOD charter. And again, you need to
say which concrete service you want to tackle - 2) and 3) are too
general to be actionable.

/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: Tina TSOU <[email-masked]>
Date: Sun, 12 Oct 2014 03:00:06 +0000

Dear Juergen,

Good points.

How about

1) Yang models of views of L0-7 network topology

2) Yang models of VPN and DDC network configuration

3) Mapping of VPN and DDC network service specific Yang models to device specific Yang models

4) Device specific Yang models of Prefix list, Route Policy, Tunnel Policy, and QoS

Thank you,
Tina

> On Oct 11, 2014, at 6:38 PM, "Juergen Schoenwaelder" <[email-masked]> wrote:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 13 Oct 2014 08:21:06 +0200

> 1) Yang models of views of L0-7 network topology

This may or may not be coming out of I2RS. I assume that I2RS will do
at least a layer 3 topology model and ideally that work would give us
a generic topology model that can be augmented with technology / layer
specific extensions. I guess this will be sorted out once I2RS gets to
select between the proposals.

> 2) Yang models of VPN and DDC network configuration

Are you sure DDC network configuration experts are going to be working
in the IETF (whatever DDC means)? Perhaps restrict this to VPNs and be
more precise what kind of VPNs you have in mind.

> 3) Mapping of VPN and DDC network service specific Yang models to device specific Yang models

This assumes there are device specific YANG models to map to...

> 4) Device specific Yang models of Prefix list, Route Policy, Tunnel Policy, and QoS

There is quite some activity already in the routing area concerning
device specific YANG models.

And when I read "QoS" I am wondering whether we are again back to list
broad areas without a well defined scope.

/js