Meeting minutes Wednesday, 19 March 2025, Session II 1300-1500 Asia/Bangkok Room Name: Chitlada 1 [Breakout 7] Working group update Chairs 15 13:00 - 13:15 - RFC 9746, RFC 9744 published since last IETF - 6 Drafts in RFC editor queue - bgp-srv6-args draft in telechat - Susan : unequal lb, susan will be working on that. bess evpn geneve was reviewed in past. if there is some disconnect, BESS chairs to talk to Susan. - Jorge : waiting for sammy to reply, but if he does not . Jorge will look into it - Stephane : evpn ipvpn interworking , we need new working group last call. We need reply from each active author before moving to IESG. - Chairs : please keep document alive . many drafts have been expired. - Jeffery : bess-mvpn-ipv6-infras , specified solution is not right way to move forward. new solution will be proposed in RFC6514 bis. - Stephane - two document were discussed to merge in single. it will be good authors providing update. Process draft-hares-bess-idr-tea-templates Susan 10 13:15 - 13:25 - Keyur : we have used extended community to carry tunnel attributes. there must be good reason given why tunnel attributes not being used. - Jorge : It is useful document. Are you expecting us to have this template in draft ? or its only for new TLV . - Susan : if you are using your sub tlv from RFC 9012, even for tunnel, tunnel has to follow this format. - Keyur : its better to explain in new drafts , it will be helpful. - Susan : purpose is to have guideline so we can have review quickly. it will reduce review time. charter update Chairs 10 13:25 - 13:35 - charter is very old. We have been getting questions from IESG if draft belong to BESS or not. - Chairs are working with AD to recharter. - it is not ready yet, its work in progress. it will be posted in list for working group to review and provide comment. - Keyur : will you include services like mVPN here or it will be only L3VPN or L2VPN ? - Chair : we did inherit from L2VPN , L3vpn. - Keyur : will you keep VPN in charter ? not just L3VPN - Chairs : We will have for now. But if some new VPN being defined, may be it will be out of scope. - Keyur : as IDR chair, will you send it to IDR if new VPN service comes ? - Chairs : Not sure yet - Gunter : Speaking as AD, if new service comes then new line can be added in charter and taken it forward. - Keyur : will take it to mailing list. but i would request to keep flexibility in charter will be good. - Gunter : we will have to find balance between super restrictve Vs total open for any service. it efforts will be put in next few weeks. Working Group Draft Update : draft-ietf-bess-bgp-sdwan-usage Linda 10 13:35 - 13:45 - All comments have been discussed. - Need another WGLC. draft-ietf-bess-rfc7432bis Ali Sajassi 5 13:45 - 13:50 - some new text added based on discussion and comments. - WGLC requested. - Ketan : When 7432 came out, new address family was introduced. there was no text for error handling. Since new route types and NRLI changes being introduced. its good to add error handling. - Sandy : flow label usage ? there is conflict and needs some clarification for flow label. will be sending comment to list. - Ali : We had comments from john and went through that section line by line. will look into comment in list and reply . draft-ietf-bess-evpn-ip-aliasing Jorge 5 13:50 - 13:55 - ready for WGLC - Tool has sizable amount of people who have read the draft and think its ready to make progress. draft-ietf-bess-evpn-dpath Jorge 5 13:55 - 14:00 - There were some comments about example in draft, typos and reference has been added - There is an implementation, its ready for WGLC. - Chairs : how many people have red the draft ? - In tool good amount of people responded to have read it. Individual Rev 0 bis Drafts : draft-zzhang-bess-rfc6514bis Mankamana 8 14:00 - 14:08 - first time being presented - Need more discussion in WG. - Prasad : 6514 big document, we need to make sure it does not get too big. We need to add some extra work related to mLDP . - Sandy : We should be doing survey to see who has used it and there may be many vendors using it. so its good to find problem. - Mankamana : Chairs may take call about survey. drafts-sajassi-bess-rfc9251bis Mankamana 7 14:08 - 14:15 - presenting first time - expecting more discussion in list. Individual Drafts: draft-sr-bess-evpn-vpws-gateway Jorge 5 14:15 - 14:20 - implementation exist - Adoption requested. draft-rabnic-bess-evpn-mcast-eeg Jorge 5 14:20 - 14:25 - Implementation exist - Adoption requested draft-zzhang-bess-dynamic-overlay-lb Jeffery 10 14:25 - 14:35 - more feedback and comments needed from WG. - Himanushu : Does this work in reality. when you have multi point connection and all dual home PE sending traffic. and if all of them throttle back then other link may get overloaded. it does not seems that it will work. - Jeffery : This effects only how you do the load balancing. we are not switching traffic back and forth constantly. - Himanshu : you talking about remote PE . UDP traffic unicast or sent to all ? in reality i am not sure if this works. and moreover its transient problem in network only. - Ali : you are assuming link utilization is symmetric. from forward direction and reverse direction. - Jeffery : we have not used reverse matrices. will think over bi-directional. - Sandy : this work is really needed since we face problem in data center . draft-kriswamy-bess-evpn-perflow-df Krishnaswamy 10 14:35 - 14:45 - more detail will be added - Jorge : few comments will discuss later offline. its per BUM flow DF election ? - Krishna : yes - Jorge : we have per multicast flow DF election too , if we take care of per flow DF election then where will be this draft used ? since BU will not be too much of traffic. what is motivation for this. - Krishna : efficient load balancing. while router is booting and if ARP suppression is not enabled yet it will increase too much traffic. - Jorge : does it mean, in stable traffic this will not be use much ? - Krishna : kind of yes. - Himanshu : BUM traffic must not be sustained traffic. it may not be too useful if traffic is not more. draft-wang-bess-l3-accessible-evpn Aijun 5 14:45 - 14:50 - Ali : this draft problem statement is not clear. are you trying to backhaul traffic from CE to PE ? draft says something else and presentation says something else . In summary this draft problem statement is not valid. existing VXLAN encap can be used. there is no need to define LSI. after VXLAN header VLAN can be added . - chairs : we need to talk offline. - Ali : we have enough information for P2P EVPN. - Aijun : will reply to list. - Gunter : VXLAN is protocol not owned by IETF. we can not change anything in IETF . - Matthew: There is work on-going to bring the VXLAN header design in to scope of the IETF. We won’t adopt anything in BESS that changes it until that design ownership has been resolved.