Working Group Status: - No new RFC published since last IETF - Adrian need to provide comment which is coming form IESG about draft-ietf-bess-nsh-bgp-control-plane-04 Adrian: I will look and provide comment. - evpn-unequal-lb comments provided. they need to address the comment . - Data center gateway- Adrian - bouncing between chair and adrain. it would be best to meet in person and conclude . stephane - ok. - Yang model - There are no implementation of any yang model - not aware of any prototype - is it good to make it RFC without implementation. it may be risky to do so. - it would be good to wait at least for some prototype and implementation. Himanshu - at least from ciena partial implementation exist for l2vpn and evpn Yang models . There are interdependencies between draft. we need to resolve the issues . we would like to make progress. Stephane - if we publish, and we later figure out that something is broken, we would have to rework. Himanshu - it is not in broken state. we just need to work little to keep it in better shape. we need add some example about how to implement these models. Authors need to spend some time and finish it off. Patrice - We need to add example and agree with himanshu. it will give an opportunity to understand model better. Himanshu - it would help to get to know if there is any gap. Jeff - Have been helping little bit with model. these are built on top of BGP. BGP model itself is not in good shape yet. we are still working to fixing BGP model. we may be able to create model stand alone, but evpn and l2vpn does interact with BGP. so recommendation would be to work on interdependencies . Himanshu - we may not have too much inter dependencies with BGP. we would not go too deep into policies we just need to care about route target and BGP session related . if we keep too much of interdependencies we would not be able to complete the work. Jeff - it would be good to minimize interdependencies. EVPN does interact with policy, standard operational behavior is needed. Himanshu - comments are taken. we would come up with base EVPN , EVPN service has multiple features . Italo - do we need co-ordinate with other working group. Himanshu - Italo to send comment on list. Susan - Once you answer jeff question, how policy would be picked. draft-ietf-bess-srv6-services - document has becoming better , it was presented few IETF back . - many implementation and deployment exist - IANA early allocation requested. - implementation detail are present in SRv6 deployment status draft - authors would prepare document for WGLC towards IETF 108 - comments and review requested from WG. draft-dunbar-bess-bgp-sdwan-usage-06 - document is ready for WG adoption - waiting for WG comment as well - this document provides framework about how BGP can be used to scale SDWAN draft-www-bess-yang-vpn-service-pm - based on comment in IETF 103 and later this document have been updated. - all comments are addressed. stephane - your document defining lot of performance metric . can you leverage some existing work . it may not be specific to this use case. can some one other WG should define this PM metric. PM metric may not be defined in BESS. Author - we do not define any new performance metric. we just use existing metrics and monitor based on existing metric. Stephane - are you using Yang model coming from related working group. Author - we are using methodology Stephane - are you using all the leafs and container Author - we are just using the metric for monitoring. WG - you are proposing to extend topology yang model with ability to take some measurement and define kpi. is this general statistics . Authors - this is generic model, and it can be applied to other service model. WG- is this generic extension ? set of KPI ? for example different type of service can have different type of KPI. how can we make it generic. each of service may have different requirement. Authors - design principle remains same which can be extended . this applies to IP network and mPLS network as well. Draft-mishra-ipv4nlri-ipv6nh-use-cases - 0th version of draft - expecting more review and comment from WG draft-ietf-bess-evpn-igmp-mld-proxy-04 - post WGLC we found there is 4 byte field in EVPN route 8 which is not being used. - different veriation of implementation present - IETF106 John - this changes looks fine. and all his comments are taken care of Wen - current type should be kept as is. it better to have interop, it would be good to keep all fields of NLRI . and document it. John - Based on presentation NLRI would not change ? Mankamana - Yes, Seq number would be made to Reserved. and it would not be part of key. Wen - we can take care of this for future. but current implementation has kept it has part of key. Ali Sajassi - We moved Sequence number to reserve. does it make sense to keep reserve as part of key ? Wen - I agree , that reserve field should not be part of key. but we need to see how to take care of current implementation Ali - This value would be Zero. are you sending some other value ? Wen - if there are any vendor who may be using this field with non zero value . Ali - All changes is taking care of current implementation and resolve it with satisfying most of implementation. We already did poll with multiple vendors and open to have some more polling done. We already are aware of different implementation. based on all discussion with different vendors we decided to make it reserve . and if reserve is Zero then it does not make much difference whether its part of key or not. Acee - how does it make difference about whether its part of key or not. if value is zero its internal implementation . Ali - Jakob - it would be ignore on receiving side. it is not part of key. if in future, it does get used, we can redefine what we would be used for. and we can redefine whether its part of key or not. Jeff - I agree with every one, if every one setting it zero then we should not have issue. It may be good to add sentence which says that it must be zero. we can say some early implementation may have used as part of key. Ali - If john can reply to email in list it would be good . John - will respond to list.