Meeting: IETF116, Friday 31 March 2023 Location: Pacifico Yokohama North, G412-G413, 12:00-13:30 Chairs: Shep , Tony Secretary: Sandy Minutes: Sandy 0. WG states, WG chairs, 10 minutes draft-ietf-bier-ospfv3-extensions document in IESG and draft-ietf-bier-evpn Andrew : Question to tony about OSPF v3 drafts, and we are waiting on update and write up Tony : it has been completed. Andrew : Did not get any notification . shephered needed for some of the document in WG. As WG we still need to deliver the OAM work based on our charter. Tony : there is lot of work needs to be produced as working group 1. BIER OAM WG drafts, Gregory Mirsky, 10 minutes ---we have four WG document in BIER. BIER Ping need to move forward as other drafts are depending on this. BIER Ping document is ready and all the comment has been addressed. Tony : Does BIER ping document had major change which need one more WGLC ? Greg : No it was editorial changes ---BIER path MTU discovery ready for next step. It requires BIER PING document to make progress. ---BIER BFD ready for WGLC. Andrew: Early RTG review needs to be initiated. Tony : Early review would be initiated. Andrew : if we can finish early directorate review it would progress faster Tony : is RTG review mandatory ? Andrew : Yes ---Hybrid Performance Measurement in BIER.Ready to move forward. Tony : Has IPR been disclosed ? Greg : Need to check on that Tony : requirement and framework document are expired, are we going to just let it go or do last call ? Greg: WG to decide. document has served it purpose already. Andrew : if there is requirement document which helped to generate new work in WG. it would be good to revive and publish. people would have track record for why something was done ? Tony : Greg M to revive the work. and we would do WGLC and there is no need to more review. Toerless: if requirement document is informational then we may not need to publish. Is there any implementation. Greg M : there is one vendor who has implemented LSP ping. 2. BIER Prefix Redistribute, Sandy Zhang, 5 minutes ---new update from last version ---document is ready for WGLC Siyu Chen: question about prefix whether its single address or it is multiple BFR. Sandy : you can use both method. Tony : it would be good to add section clarifying it. Siyu: base RFC BIER says prefix has to be address. We can take discussion to list. Tony : does BGP summarization violates that ? Siyu : Yes Tony :please take the discussion to mailing list so we have documentation. 3. BIER Anycast, Jeffrey Zhang, 15 minutes ---BIER RFC8279 did not cover anycast. so this draft is to close the gap. Toerless: document is not clear whether anycast is talking about source or receiver. Jeffery: it does cover both of the case. Toerless: it would good to clear up the draft talking about different cases. ---two drafts in this area Toerless : will receiver anycast work ? Jeffery : it need to be implemented with MoFRR Tony: we would need to think of capability somehow. it will help to deploy multi-vendor network. Siyu: for same PE multi-home to two different CE then draft says we can have two BFR prefix. does it mean overlay and underlay being co-related or tightly coupled ? Jeffery: we can look at base RFC and see if things need to be changed. 4. Update on RBS and related work, Toerless Eckert 10 minutes Ice : have sent question in list and currently it has not been solved. it is really needed where we can have sniffer in network and being able to encode the packet any time. Toerless: MPLS also has same analogy. Ice : sniffer on wire can always decode the encoding. and it is not true statement for MPLS Toerless : we dont need to really see the whole packet. or decode the packet for better forwarding.I may not agree that we really to be able to decode the packet . and just to add this capabilities we would not be efficient in forwarding. so its better to be efficient Tony : does it not boils down to argument that first field which we decode is length indication. Toerless: i do not think we should be really able to decode whole tree which has been encoded in packet. same way you do not decode the stack of protocols which you are processing and do not care about . Ice : just because of its hard we can not discard the fact that protocol need to be reliable and something which can be troubleshooted. Andrew : speaking as individual , for vendor its critical to be able to decode the packet. as its being used for different application in network. so it is going to be important for any operation. Toerless : but we can not decode encrypted packet without key.not all has to be solved in forwarding plane. Andrew: accounting really need basic information without knowing full semantics. Tony : its good progress related to RBS work and it can be used to solve the use case which being discussed as part of presentation later . As WG we would have to see if we can work on this area. Ice : it would be good to first work on foundation before spending time in implementation to avoid re-testing. Toerless: P4 community may play without it being standard as part of research. Ice : do we want only this to be part of research ? Toerless: No, we want it to be deployed too. Andrew : as AD , if WG thinks that this work needed in this WG. then it is ok to add in charter. and i feel it would fit in overall framework. we would need to find if there is enough interest to work on this. Poll Who would contribute to work on RBS in BIER WG Yes 8 No 7 Need more discussion in mailing list. 5. BIER-TE PCE&IDR, Ran Chen, 10 minutes Dhruv : Do we need to have adoption in PCE working group Tony : need to provide some time to WG Jeffery: i think it is useful work. adding BIER would be good option in PCE. Email discussion can happen with other relevant drafts. 6. BIER-TE BIFT-ID advertisement, Sandy Zhang, 10 minutes Siyu : The Max SI field may need to be added. Sandy: The BIFT-ID allocation for BIER-TE is different with BIER, the BIFT-ID of BIER-TE is per SD and BSL, so the number may not be too large. But it can be added for alignment. 7. BIER Multicast use cases in DC, Weiqiang Cheng, 10 minutes Tony: to summarize, if BIER can be used with sub-domain and other options. we can accommodate. But if there is frequent join and leave , we need to work on addressing the gap in this working group. RBS could be one of the possible solution and may be some alternate solution Existing multicast solution can not satisfy this requirement. From china mobile : this requirement can not be served by current protocols because scale would keep changing. are we going to change the charter again and again. Tony : it would be productive if authors discuss what is needed from working group. If mind has been made that this WG group can not solve this, then we have nothing to discuss. Andrew : There is requirement. and may be some work needed. Its good to see if we could get work done in BIER WG. if there is need to modify charter of WG , i am ready to do that. WG group need to find way to work here so that it can speed up. exploring within this forum would be good option. It is good to see requirement has been presented. and hearing WG , it looks like we have way to solve it here in this working group. Weiqiang Cheng: DC requirement are totally different Andrew : DC portion and multicast portion are two area we can see in this requirement. but for DC portion there is discussion going on. and it is going to take time and it is not blocker for exploring if multicast work can be solved in this WG. Weiqiang Cheng: if we start working with legacy technologies we may not move fast Tony : this is one of the fast WG. within 8 years we have multi-vendor solution. If authors think that we can have proprietary solution then WG can not help. Hooman: it would be good to have example of application. what about cross Data center ? are they going to different data center using some link between DC. I agree to tony, if you look something quick then we have to use existing one. Weiqiang Cheng: If we want to use BIER, we do not have silicon which can support it. BIER failed because of its very larg network. DC is new model, you can deploy new solution. Hooman: if we come up with brand new silicon , it would take 10 years Weiqiang Cheng : we are looking for new solution even if it takes time Andrew : please keep the discussion in mailing list and keep it restricted to requirement. 8. BIER-TE BP advertisement, Huaimo Chen, 10 minutes Not presented because the session run out of time.