Subject: [Supa] Supa 2015-02-02 interim minutes

From: JF Tremblay <[email-masked]>
Date: Mon, 2 Feb 2015 12:53:49 -0500

------------------
SUPA Interim notes 
2015-02-02, 7:00 PST
------------------

Attendees: 
Alvaro Retana
Benoit Claise
Dan Romascanu
Georgios Karagiannis
Juergen Shoenwaelder
Jun Bi
Scott Bradner
Tina Tsou
Will Liu
Xiaorong Qu
Ying Cheng
Qiong Sun
Bob Natale
Luis Miguel Contreras Murillo 
James Huang
Marie-José Montpetit
Joel Jaeggli
Marc Blanchet

Tina Tsou (TT):
- Presented the agenda and the first slides. 
- Presented slides for option 1 and 2. 
- Option 2 shows are more detailed view. The service management data model is shown in two copies. 
- Supa focus on service management and network resource view, while other groups have a network element focused view. 
- Presented the related IDs currently available. 
- Also introduced the use cases. Ying Cheng will describe some use cases from China Unicom.

Ying Cheng (YC)
- Use cases for distributed data centers. 
- For the automated provisioning of datacenter services.
- Another usage is for VMs in the cloud used as PCs (university use case).

Luis Contreras (Telefonica)
- Presented the problem statement slide.
- To dynamically create, modify and delete services. 
- The rationale behing supa is to have the abstraction to properly do that in an automatical way. 
- Facilitate the programmability through this abstraction to mak automatic operations and configuration.
- Will work on making the problem statement more neutral, as a next step.

Jun Bi
- Adding another comment about campus networks from Tsinghua University. 
- There's a need to steer management traffic and the traffic for different projects in isolated ways.
- Usually this is done manually with vlans. However the number of projects and their dynamic nature makes it hard to manually configure it statically. 
- Having some policies to control this would greatly improve with this scenario. 
- Believe supa technology is very appropriate for campus networks. 

Juergen  
- Worked with Dan to make the charter text clearer. Quite a lot discussion on the list.
- First slide is motivation text, focus on software abstraction and programatic control. 
- Second slide shows that the idea is to follow a generic approach to express services at multple levels of abstraction while trying to be technology agnostic.
- Third slide is covering in more details what has to be done. 
- The first model to tackle is network topologies and resources that are available. 
- We are aware that topology comes up in a number of other places, but this is really key piece update we need to have.
generic network resource modeling. 
- The second YANG model is service specific. 
- The third is a policy-driven data model that can be extended. This were you bridge the gap between service-oriented and topology. 
- Slide four is to use datacenter inter-connect as a use case to evaluate this is feasible.

Qiong Sun from China telecom:
- Presented the framework, as it has been updated. 
- Still in the initial phase, has a lot of issues. 
- Removed references to PCE.

Will Liu on supa models
- This slide explains how the models are used to produce configuration for devices. 
- Once a service model is received, it can be mapped to protocol-specific configuration. 
- A detailed example of traffic-steering between datacenters is provided. 
- Comments from the list: should not be mapped with vendor-specific commands. Shoudl remain vendor neutral. 

Luis on topology data model
- This is a hierachy of topology information. 
- Each level has it's own meaning and data to handle.
- We need to move from one layer to another according to the service to implement. 

Dan R.: 
- The data models need to be layered, with relationships between them. 
- The Yang model has detailed information. 
- Could be enhanced, to discuss offline maybe. 

VPN service management, presented by Ying Cheng from China Unicom
- This draft has the information model for VPN.
- The second part is the supa management model. 
- L3VPN is the first model being tackled. Used to configure L3VPN.

Tina on network policy data model.
- Common data model for policies. 
- Was discussed on the supa mailing list. 
- Another one was more specific, for optimizing traffic services. 

Benoit: 
- Sent some questions on the list before the meeting.
- First question is, what is the connection with the topology effort in the ietf. 
- You seem to need the physical topology. Where do you see the physical topology being standardizd? 

Luis: 
- From a service point of view, do not need the physical topoly.
- We only need to know the service endpoints and transport capability. 
- We could allow different physical variations existing for a service. Only need the transport capacity. 

Benoit: 
- You want to abstract the service topology. 
- A pragmatic example: router and link IDs. Should be the same across topologies. 
- Endpoints must be identified too. I was assuming the service would have the same router and link ids. 

Juergen: 
- The way these models are coupled, for example for a virtual link between datacenters, the ip addresses are the end points. 
- The properties will identify the mappings. You want flexbility to switch with the mappings.  
- In an ideal world, we'd have a topology model to build on. 
- For the network layer, we need a data model. If it's done elsewhere it's fine, but we need it. 

JF
- The work in I2RS might restart soon, but has been stalled for over 18 months. All drafts are expired. 

Benoit: 
- Fair enough. To discuss with routing ADs.
- In the service model, you want the VPN between IP addresses? I would be looking for a service between for example Juergen and Benoit. 
- We could have multiple topologies with a mapping somewhere, but isn't it looking for trouble?

Juergen: 
- For datacenters, would have to ask. But we have mappings. Not something new or difficult. 
- Having a binding would does make it more complex when you need to move things. 

Benoit: 
- Not sure I agree with you here, Juergen. But we don't have to do the BoF here. 
- A next question is: you are discussing multiple use cases here (VPN, DDC). 
- I don't see a specific use case in the charter, to be implemented.  

TT: 
- The VPN is the main use case, we just didn't change the file, still called DDC. 

Benoit: 
- I understand the VPN is the use case, but what is the outcomes in the charter?
- Is it a YANG model for VPN? Or for DDC?

Scott: 
- Benoit was asking about the output of the working group. Are there specific use case documents to produce. Or is this noise producing the YNAG models?

Juergen: 
- We should have work items that are specific to the use cases. 
- But we would love to focus on the data model rather than producing multiple use case and problem statement documents. 
- I agree there should be a work item on how this is applied.  

Dan: 
- We're talking of a VPN sub-case of a DDC use case. 

Benoit: 
- It would be like anima. Pick one or two use case. It's up to you to choose. 
- Let's pretend we're in the future in 2 years. It would be great to say we've implemented use case X. 
- Should not go with a lot of problem statements.  

Joel: 
- The thing to avoid is having a voyage of self-discovery in the charter.  
- Should pick an item or two to show the utility of the model. 

Benoit: 
- The way I understand, this is a top-down approach. 
- You say APIs, but these are YANG models. 
- Looking south-bound, I see a lot of protocols. 
- Would this work going top-up? Without doing at the same time the configuraiton for the specific network elements. 

Juergen: 
- Yes, but that would happen in the protocol-specific wg. 

Benoit
- How would you synchronize this? This would make solutions specific to the CLI of specific manufacturers. 

Juergen
- The IETF would find ways to keep this under control and manage this. 
- With specific persons or position charter to synchronize these inter-wg relationships, this would work. 

Tina: 
- Look at page 3, we'll work together. 

Benoit: 
- From the slides, there's option 1 and 2 for the scope. 
- Which one do you want to target?

Tina: 
- To me, they are different ways to express the same thing. 

Benoit
- There's a bigger difference in option 2.
- In option 2, if you need L3VPN as a service for a DDC, for example. This needs a VRF. Would you work on configuring a VRF?
- Would that be in a different working group?
 
Tina: 
- For the management data model, it's only L3VPN and for service management, it's just the topology and inventory.  
- Maybe figure one is simpler... but saying the same thing, with different levels of details. 

Benoit: 
- If you go for a bof, the first slides are asking for an option 1 or 2 and I was wondering which one you preferred. 
- One extra question. The last line of the charter specifies policy rules controlling a network service. 
- Not sure what you mean by policies. 

Joel: 
- Are these constrained based, for example?

Tina: 
- For example, you have a virtual CE moving. When you move the service you move the policy. 

Benoit
- I'm not sure I understood your example. 

Will
- The policies can have different meanings for specific conditions. 
- For a DDC use case, the traffic may be routed to another link. 

Benoit 
- In your example, the policy is just for the service, it overloads the service.  

Georgios
- Exceeding could also be another policy. 

Benoit: 
- Any other question?
- The thing to do is to fill in the bof wiki. Who will take the lead on that?

Tina:
- I can do that. 

Benoit
- We'll have a call with IESG and IAB, Thursday next week, with feedback on different bofs. 
- Feel free to update any document. That will be discussed during that plan. 
- Sounds like a plan? 

Joel: 
- Update the wiki, this is what will be discussed. 

Georgios: 
- Did we answer questions to your satifsfaction?

Benoit
- Yes, to an extent. 
- There are still descrepancies, in terminology and in the diagrams.
- It would be great if you could align all these.  
- IT would be great if you could update the charter with a specific use case. 
- Anything in that direction would help. 
- A bof is trying to make a clear problem statement. 

Tina: 
- Other issues or questions to communicate with Benoit and Joel?

Juergen: 
- It all depends on what gets put in the wiki. 
- Make sure the answers are clear, and the proposal. 

Dan: 
- Focusing on a manageable work item in the charter is important. 
- Allows Benoit to support the proposal. 

Benoit
- If you could summarize what automated and summary means in SUPA. There will be some questions about it. 

JS: 
- There were some discussions about this acronym. 
- We decided that changing this acronym is way more confusing than keeping it. 
- We need something better, but for the time being we just call it supa. 

Benoit: 
- Mention this in the wiki, that you're using supa because there's a list and there was a bof.
- Mention that you'd like to use name "X".
- Describe in one sentence or two. IT would prevent people reading the wiki from reading too much frmo the supa name. 

Benoit: 
- Fill the wiki and I could provide feedback there. 

Dan: 
- Is the bar bof template sufficient to start with? 

Benoit: 
- It's generally accurate for what bof need. You can look at what the previous one. 
- It's a good model for what it looks like. Link to the slides for people to review. 

Adjourned at 8:09 PST.

JF Tremblay, ing
Senior Network Engineer, Viagénie
[email-masked]
246 rue Aberdeen, Québec (QC) Canada G1R 2E1

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 3 Feb 2015 16:47:44 +0800

Many thanks for the meeting minutes.

What I mentioned is not only from Tsinghua University, it is also an observation on common requirements at campus networks of CERNET (education related network).

Best Regards,

Jun Bi

From: [email-masked] [mailto:[email-masked]] On Behalf Of JF Tremblay
Sent: Tuesday, February 3, 2015 1:54 AM
To: [email-masked]
Subject: [Supa] Supa 2015-02-02 interim minutes

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

SUPA Interim notes 

2015-02-02, 7:00 PST

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

Attendees: 

Alvaro Retana

Benoit Claise

Dan Romascanu

Georgios Karagiannis

Juergen Shoenwaelder

Jun Bi

Scott Bradner

Tina Tsou

Will Liu

Xiaorong Qu

Ying Cheng

Qiong Sun

Bob Natale

James Huang

Marie-José Montpetit

Joel Jaeggli

Marc Blanchet

Tina Tsou (TT):

Ying Cheng (YC)

Jun Bi

Juergen  

Will Liu on supa models

Dan R.: 

Benoit: 

Luis: 

Benoit: 

Juergen: 

JF

Benoit: 

Juergen: 

Benoit: 

TT: 

Benoit: 

Scott: 

Juergen: 

Dan: 

Benoit: 

Joel: 

Benoit: 

Juergen: 

Benoit

Juergen

Tina: 

Benoit: 

Tina: 

Benoit

Tina: 

Benoit: 

Joel: 

Tina: 

Benoit

Will

Benoit 

Georgios

Benoit: 

- Any other question?

Tina:

- I can do that. 

Benoit

- Sounds like a plan? 

Joel: 

Georgios: 

Benoit

- Yes, to an extent. 

Tina: 

Juergen: 

Dan: 

Benoit

JS: 

Benoit: 

Benoit: 

Dan: 

Benoit: 

Adjourned at 8:09 PST.

JF Tremblay, ing

[email-masked] <mailto:[email-masked]>