BESS working group minutes IETF 95 April 7th 2016 Volunteer minutes taker: Gunter Van de Velde Contributions to minutes by WG chairs. * WG Status Co-Chairs, 10 min Chairs asked if all expired documents will be refreshed... if no update, then two longest expired documents will be re-purposed by updated charter milestones and be removed Ali indicated that draft-ietf-bess-fat-pw-bgp would be refreshed soon. *Yang models * draft-shah-bess-l2vpn-yang-01 Patrice Himanshu Shah: couple of things came up in pals: pw model & service model on pw model, initial thought was to take on ethernet first and then ATM, TDM, FR etc. service model should be in this base L2VPN yang model, as it is subset Adrian Farrel(l3sm perspective): it is critically important that service model be driven by those who use (i.e. operators). vendors not best people to understand operator concerns recommend that the right people be involved whatever WG does it Himanshu: lot's of operators in the DT Also, service model has few delta with system model * draft-brissette-bess-evpn-yang Patrice (no comments) * draft-dhjain-bess-bgp-l3vpn-yang Patrice Dhanendra Jain: (explanation that the datamodel will have to be adapted because netmod abandoned routing-instance from draft-ietf-netmod-routing-cfg, and will use instead network instance container from draft-rtgyangdt-rtgwg-device-model) ?: netwmod-routing-cfg wasn't covering all VRF parameters, same for BGP in idr-bgp-model * draft-li-bess-4pe-01 Zhenqiang, 10 min Ali:if v4 islands were considered as ASes then you could do inter-AS option B, and it would work? Zhenqiang: yes Ali: so? Zhenqiang: this is not vpn based Keyur: agree that 5549 is sufficient as Eric said Wim: agree also, and mentions that it has been implemented already in vendor implementations. Zhenqiang: 4PE routers need IPv4 next hop information to install their IPv4 routing table Thomas: you should go to the list and clarify what you think is missing in RFC5549 * draft-zzhang-bess-evpn-bum-procedure-updates-01 Jeffrey, 15 min Thomas: who has read?: approx 10 people We encourage more people to read, especially evpn spec authors * draft-rabadan-bess-evpn-pref-df-00 Jorge, 10 min Thomas: who has read?: approx 7 people * draft-rabadan-bess-evpn-ac-df-03 Jorge, 5 min Ali: do you envision running ethernet oam on each every single vlan? Jorge: in single active / mh networks, yes Ali: now how would this work if run oam on not all vlan? Jorge: you can withdraw the AD route Ali: an optimization, if informational, then it is ok. Patrice: what is the benefit? Jorge: base specs would not cover failure of a single AC Patrice: is it dependent or not of virtual ES ? Jorge/Ali: not dependent Jorge: typically applies to ACs on physical ports, but could possibly apply to VLANs inside virtual ES * draft-rabadan-bess-vendor-evpn-route-00 Jorge, 10 min Keyur: sugest to have this draft read by IDR WG Keyur: should very clearly articulate the application, and maybe merge the proposal as seen in IDR on Opaque information exchange Thomas(chair): in IDR there is indeed already Opaque container draft discussed and need to be seen how this overlaps Jorge: having new Route-Type feels as easier to implement as a new AFI/SAFI, also EVPN is unified control plane Ali: good arguments, faster to implement, but if someone wants to do the same for another non-EVPN context they'll need to do it in their own AFI/SAFI Ali: clarify application otherwise we have concerns on for example the rate at which this will be sent on RRs John Scudder: agrees with Keyur/Ali. Suggests that new AFI/SAFI is easier to contain the distribution to a separate RR for scaling and functionality perspective * draft-boutros-bess-evpn-auto-provisoning-01 Sami, 10 min Jorge: what is FSOL? Sami: it a way for the EVN to glean the information based upon what is avialble Jorge> You try to define a new type of ESI, and there is no new type number Sami> yes, it willbe added in the draft if not in there yet Thomas (contributor)> please provide comparison between this solution and running an out-of-band solution... why using EVPN for this? why not Netconf... Sami> yes, we will add a comparison table Keyur: I agree with Thomas Keyur: this needs to be coordinated with IDR Thomas: Chairs have taken note on the need to coordinate with IDR Thomas: who has read? approx 3 * draft-boutros-bess-evpn-vpws-service-edge-gateway-02 Sami or Patrice, 10 min Sami> present the work and looking for comments on the work Jorge: sent already set of comments, but not all were addressed in the latest document as was proposed Jorge: The section on Multi-homing is not very clear and detailed and has loads of open ends Sami: agrees that the draft needs some updates in this area Jeffrey: there are two RT used, what is the exact purpose of that. Sami: one is the EVPN RT and the other is the overlay service. Jeffrey: is the 2th route-target used for route-import or not? Sami: one is , and the other is used for other purpose Jeffrey: Will follow up as the operational model is not full clear Jeffrey: What about benefits on where the services are provisioned Sami: No extra provisioning per device needed on the service PE Martin (chair)> in the interest of time, suggest to take the comments to the list * draft-lin-bess-evpn-irb-mcast-02 Wen, 10 min Erik N.: does it support multiple bridge domains? Wen: Most should be covered, however the text is work in progress Wen: Assumtion is that IRB is everywhere Ali: In the intend from Erik, what happens if different exclusive bridge groups are in place? Wen: As mentioned, section is work in progress Ali: what type of bridging is here symmetric or assymetric? not sure that any matches what is described here Martin (chair): can you take the question to list in interrest of time *draft-hu-bess-l2vpn-service-yang-00 Fangwei, 15 min (time given by chairs is 5 min due to previous overun) Adrian: for which interface is your model? Fangwei: between application and controler and between orchestrator and controler Adrian: you need to define better which part your datamodel is describing Thomas (Chair)> Can Adrian give his feeling about whether L2 service model might be undertaken in L3SM via rechartering? Adrian: no such plan. In l3sm seems unlikely. Should talk to ADs (RTG/OPS), OPS will say this must be driven by operators * draft-sajassi-bess-evpn-l3vpn-multihoming-01 Ali, 10 min (ot presented due to lack of time)