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

[Tina TSOU <[e-mail]>]

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:[e-mail]] On Behalf Of JF Tremblay
Sent: Saturday, October 11, 2014 1:16 AM
To: [e-mail]
Subject: [Supa] SUPA discussion on 2014-10-10

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