Minutes for L3SM at interim-2015-l3sm-1
minutes-interim-2015-l3sm-1-1

L3SM Working Group Virtual Interim Meeting

Thursday December 5th, 2015. 8am East Coast Time (New York)

BLUE SHEET

Name                    | Affiliation

------------------------+-----------------------------------------------
------------------------+-

Adrian Farrel           | Old Dog Consulting

Qin Wu                  | Huawei Technologies

Stephane Litkowski      | Orange

Luis Tomotaki           | Verizon

Daniel King             | Old Dog Consulting

Susan Hares             | Huawei Technologies

Scott Mansfield         | Ericsson

Gu Rong                 | China Mobile

Kenichi Ogaki           | KDDI

Aijun Wang              | China Telecom

Victor Santos           | Ericsson

Ignas Bagdonas          |

MINUTES

* Meting logiistics
https://mailarchive.ietf.org/arch/msg/l3sm/SJub1aHVQGOQW6rWhthX0fB8Ac8

* Meeting materials
https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/proceedings.html

* Etherpad for minutes (this page)
http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03

* Jabber using l3sm@jabber.ietf.org

* Blue sheet
http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03-bluesheet

Agendaa

- Administrivia (Note Well, etc). a

- Introduction

- Open Issues for YANG Data Model for L3VPNservice delivery
(draft-ietf-l3sm-l3vpn-servicemodel)

o Open Issues discussion and resolution¨C
http://trac.tools.ietf.org/wg/l3sm/trac/report/1

For a full list of issues and resolution proposals please see:
https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/slides/slides-interim-2015-l3sm-1-2.pdf

Issue#1: When customer-nat-address is used

Resolution #1:  Leaf used when NAT is required to access cloud VPN and customer
wants to use its ownIP address. If provider provides the public IP,no need to
use the leaf

Status #1:  Closed Pending I-D text review.

Discussion on #1:

Aijun asks for more description in the YANG model itself

Stephane shows current model

Agreed OK

Issue#2 : Identify l3vpn svc using id or name or both

Resolution #2:  ID is a string, as per other properties in the model

Status #2: Closed

Discussion on #2:

Agreed OK

Issue#3: M to N availability support

Resolution #3: Modeling sites using a list with a priority, so include access
list with a priority.

Status #3:

Discussion on #3:

Qin was asking that M to N availability is supported with access and priority
number.

Stephane stated this is suppoted. This new proposal also supports multiple
sites, as a list.

Qin also asked if Group I-D was no longer needed, which it is not. Also good
solution supported by other operators.

Stephane asked if four priorities was enough, or if more were needed.

Re: Containers/Properties for Network Access Configuration - Conclusions?

o Location - Different site I-D?

o QoS Policy - Per network access link, or site information? Would QoS (cost)
be different per accesslink or site? Example of Primary and Backup links given.

o Bandwidth - Moved to access link group

o Maximum Routes -

Security, routing, and services are duplicated with inheritance

Issue#4: site-service-cloud access as grouping

Resolution #4 Already resilved as a separate grouping

Status #4: Closed

Discussion on #4:

Issue#5: Multicast support as raised by Eric Rosen

Resolution #5: : New "provider managed" property, and in Site Properties
"property-type"  added

Status #5: Solution proposed.

Discussion on #5:

Stephane will proviode new property proposals will be provided to Eric for
review.

Issue#6: Inventory operational state

Resolution #6: Include a new container for inventory state, or an RPC call
(sitting above the service orchestrator) to retrieve inventory state.

Status #6: Need to propose to the WG and agree solution.

Discussion on #6:

Luis asked would this info be collected from provision state? Stephane
suggested this would not be availible.

Adrian observed that the code used to convert the model into a service request
may not utilise this inventory information capability. Sue mentioned that
others have mentioned by a vendor that it would be useful to have the ability
to configure inventory state. This should be clarified by the operators.

Stephane to take proposals to list and ask anyone who is interested in having
the feature to suggest text.

Issue#7: Generic VAS - do we need to create a generic VAS container as VAS are
popular in L3VPNs?

Resolution #7: Separate from L3SM

Status #7: Closed

Discussion on #7:

Gu Rong highlighted Generic VAS model which was presented at IETF 94.

Issue#8: Who keeps site locationinformation?

Resolution #8: Text has been fixed

Status #8: Closed

Discussion on #8:

Issue#9: Do we need to model transport constraints, such as: jitter, disjoint,
path diversity?

Resolution #9:   Propose a "transport-constraint" group with "constraint-type",
"constraint-value" and "constraint-list" (composed of type and values)

Status #9: Authors to propose the resolution in the I-D and provide to the WG

Discussion on #9:

Luis mentioned that they have multicast transport (multiple sites) and
bi-directional traffic applications (financial) that will require transport
constraints

Duplicate transport constraints for unicast and multicast to give options for
separate configuration.

Keep single list entries for each src/dst pair even in the multicast variant.

DO we need to support multiple constraints or just have a single composite (of
multiple constraints), have the ability to specify a constraint-list?

Aijun prfers list of constraints and meeting agrees this is OK

What constraints to offer?

Latency

Path diversty

Site diversty

Jitter

Class of service was proposed but rejected

Luis highlighted they have a current implementation that uses the similar
proposal. Luis also mentioned that site diversity might also be required, would
this be achievable

Issue#10: VPN "merging"

Resolution #10:

Status #10:

Discussion on #10:

VPN is a per site property.

- A site can belong tomultiple VPNs

- How to handle merging of two VPNs?

- Is this an issue the service model has to deal with?

If VPN merging is required to be seamless, then this would be device specific
and not service model related.

"Merging" is a confusing term. The objective is NOT to merge VPN1 and VPN2.

The objective is to provide an extranet so that some sites in VPN1 can connect
to some sites in VPN2 for some traffic.

This can be solved using a per-site property.

Action: Need to update this issue to make it clear what function was being
discussed, also Stephane will send options to the working group- list.

We are specifically looking for people who offer extranet connection between
sites from different VPNs

== Other Issues ==

Modeling Customer Specific Info

- Create appropiate containers for Provider Edge and Customer Site routers

- The current  model contains routing parametres that refer to CE and PE
relationships

- General agreement is routing info should be split and current proposal will
be sent to the list for Kenichi, and working groups, review.

== Conclusions ==

- A number of resolutions have been agreed and will be updated in the I-D

- Chairs would like to see revised I-D based on the agreed points

- Plan to have another interim call at the end of January (2016)

- Chairs to add new tracker items, including security for future discussion.