Minutes for L3SM at interim-2015-l3sm-1
L3VPN Service Model
||Minutes for L3SM at interim-2015-l3sm-1
L3SM Working Group Virtual Interim Meeting
Thursday December 5th, 2015. 8am East Coast Time (New York)
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 |
* Meting logiistics
* Meeting materials
* Etherpad for minutes (this page)
* Jabber using firstname.lastname@example.org
* Blue sheet
- Administrivia (Note Well, etc). a
- Open Issues for YANG Data Model for L3VPNservice delivery
o Open Issues discussion and resolution¨C
For a full list of issues and resolution proposals please see:
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
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:
Issue#3: M to N availability support
Resolution #3: Modeling sites using a list with a priority, so include access
list with a priority.
Discussion on #3:
Qin was asking that M to N availability is supported with access and priority
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
Status #5: Solution proposed.
Discussion on #5:
Stephane will proviode new property proposals will be provided to Eric for
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,
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
Duplicate transport constraints for unicast and multicast to give options for
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?
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"
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
- 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.