Minutes interim-2020-bess-01: Tue 07:00
minutes-interim-2020-bess-01-202004280700-00

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.