Minutes IETF120: bess
minutes-120-bess-00

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.

------------------------------------------------------------------------------------