Wednesday, July 24, 2024 09:30-11:30 Local Time (Canada EST), Room Regency A/B ------------------------------------------------------------------------------------ Topic Presenter Time clock ------------------------------------------------------------------------------------ Working group update Chairs 15 min 9:30 Matthew and Jeffrey go through the slides. IAB helpdesk is helping participants with new work, and help with the process 4 new RFCs published since last IETF couple of drafts in RFC ed queue some in AD and IESG review. thanks to Gunter to help moving forward multiple drafts the data tracker show the status and it is a great tool, Matthew recommends people to check it out frequently a few docs in WG LC mcast redundancy - mankamana to do the write up. Weighted Multi-Path Procedures for EVPN Multi-Homing (draft-ietf-bess-evpnunequal-lb-21) - concern raised by Jeffrey that needs to be addressed. Requested review by IDR. EVPN geneve - moved as experimental since there are no implementations evpn ipvpn interworking draft - comments addressed and ready to progress. Jeff confirms. Sue comments on the bgp-multicast controller draft - reviews going. the queue for WG adoption is long 3rd and 4th drafts on the slides on multicast - Jeffrey says they should be considered together. The scenarios and solutions overlap. Lots of discussions on the mailing list. Jeffrey says that the solutions in the enhancements draft solves it better. If no comments, we should go ahead and complete the enhancements draft. Also RFC6514bis (MVPN) draft should address some of the issues. ----------------------------------- draft-ietf-bess-evpn-dpath-01 Jorge 10 min 9:45 Jorge presents the draft. Changes driven by feedback from Jeff Haas. Keyur asked about why DPATH is needed and what happens if a router strips off the dpath in a route. Jorge recommends reading the original evpn-ipvpn draft to see all the rules. Jeff also explains that this attribute was conceived first for propagation between ISF families. Keyur will provide feedback on more security comments on the security considerations section. He's especially concerned about things like stripping the dpath and have other things broken. ----------------------------------- draft-ietf-bess-secure-evpn-00 Ali Sajassi 10 min 9:55 Ali presents. Linda: there are some proposals in ipsec to add things after the ESP header. The proposal was to add another protocol like ESP1 or something. Ali: we are keeping IPsec intact, we don't want to impact on the existing IPSec headers. Linda: section 4 on key management - should be taken to the IPSec group to seek for feedback. Ali: key management is a function of p2mp BGP signaling, you can't take it out since it is tied to p2mp BGP signaling. ----------------------------------- draft-ietf-bess-rfc7432bis-09 Ali sajassi 10 min 10:05 Ali presents all changes since March last year. Sasha: says section 6.2.1 is fine. Section 6.3.1 he has have some doubts, because the handling of tag traffic in IEEE says you don't need additional bridge table. Ali responds explaining why minimum changes should be made in these sections Comments on change 9 - frame ordering. Lengthy discussion about using CW in all instances, if entropy label is used, then CW may not be used. This includes all the PE and P nodes. Matthew - the issue if that you can't know beforehand if all nodes support entropy label or not. Ali - we water it down to CW may not be used. Jeffrey - need to change to MAY NOT to be normative. Ali – ok Next steps: all comments addressed. Requesting WG LC. Gyan: change log can be added? also there are many new route types, maybe they can be collected here. Ali: all those route types are registered against other documents so it is better not to. Ali: about the change log, we kept it and then moved to appendix, but it'll be stripped off before publication. ----------------------------------- draft-sajassi-bess-evpn-fabric-migration-00 Ali Sajassi 10 min 10:15 Ali presents. Seamless migration is the key word. John and Sue express some disagreement with the use of RFC9012 in the draft to encode the IPv6 VTEP. Sue: IDR chair - can you go back to the discussion about encaps? why you are breaking RFC9012? it explicitly denied this case. You shouldn't do this. Ali - we are not breaking anything we can use the bgp encap ext community to convey the encapsulation. Sue and John still in disagreement Jorge: originating IP issue with DF election and AC-DF capability. Ali: agreed, pls send the comments offline. Sasha: what about AR? Ali: it is a good point. At this point it is IR. But this has implications on AR or p2mp as well, so this has to be addressed. Pls send me an email on that. Reshad: can it work for other encaps? Ali: should apply to other encaps too Wen: same comment as Jorge with Originating IP for DF election. Asking to address the seamless part. Ali: Jorge context was for clarification for DF election and AC-DF clarification, your comment is for what? Wen: the seamless part has to be revised and see if we have issues with the seamless integration. Ali: the idea of keeping the originating IP was to enforce the seamless integration. If you modify it, you will have different routes and may impact on the forwarding. During the process you need to keep it. Once the migration is complete and you go to single stack you can change. John on RFC9012 again: RFC9012 has a bunch of semantics that you are ignoring. So it doesn't seem like a interoperable or clean way to do it. Only you need to add a IPv6 address, probably better to use something that does not have existing semantics. We can discuss it offline. Ali: I'll check with you Keyur: stretching Jorge's point about make before break aspect of the solution ----------------------------------- draft-levyabegnoli-bess-evpn-savi-03 Ratko Kovacina 5 min 10:25 Ratko can’t present due to some audio issues ----------------------------------- draft-liu-bess-srv6-evpn-validation-00 Yao Liu 10 min 10:35 Yao Liu presents. The key part of the draft is to do what RFC9489 does for MPLS now in SRv6. Jorge: PBB-EVPN should not be here since it is not covered by RFC9252 for SRv6. Yao: we'll check. Zafar: there is some work to be done in 6man Ali: about jorge's comment, this is because the original RFC was MPLS. Also this document is probably not needed, since the context of RFC9489 does not say that it is not applicable to SRv6. So there is really not new things, but the entire thing for RFC9489 might be dealt with as an errata. For IPv6 transport it needs work in ICMPv6, once that's done, then putting the context is cookie cutter from the RFC. ----------------------------------- Discussion on MRT timer RFC 9251 Jorge 10 min 10:45 Jorge presents issues found in RFC9251 with route type 8. Ali: thanks for raising this. How to document this depends on the length of the description, we can do different things. Mankamana: depends on the burden we want to put on the procedures. In cisco we just use the LMQI (only) in the route. Jeffrey: we use the LMQI as well. More discussion needed. ----------------------------------- draft-ietf-bess-v4-v6-pe-all-safi-00 Gyan Mishra 5 min 10:55 Gyan presents. Testing Juniper Nokia fully tested, Arista will be removed from the draft. MPLS WG next year we can show the results of testing, and how this draft is relevant. 4 cases as per the slides. Matthew: what do we want to do with this draft? it is very unusual to publish an RFC with so much info about testing something in other specs. ------------------------------------------------------------------------------------