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.