Thanks for replying, Neeraj. Looking forward to reading your next version. Thx Jorge
From: Neeraj Malhotra (nmalhotr) <nmalh...@cisco.com> Date: Thursday, November 9, 2023 at 4:01 PM To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, draft-malhotra-bess-evpn-centralized-anycast...@ietf.org <draft-malhotra-bess-evpn-centralized-anycast...@ietf.org> Cc: bess@ietf.org <bess@ietf.org> Subject: Re: Comments on draft-malhotra-bess-evpn-centralized-anycast-gw CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Jorge, Many thanks for the review. Please see inline: # Major comment: I believe section 5.1 is not correct: “... GW MAC/IP MUST be advertised with a higher sequence number. ...” And as per draft 7432bis: “MAC Mobility extended community SHALL NOT be attached to routes which also have Default Gateway extended community on the sending side and SHALL be ignored on the receiving side.” And section 7.13.1 in the 7432bis takes care of the GW MAC/IPs being protected and not subject to mobility. So IMHO the entire section 5.1 is not needed. [NM]: Thanks for pointing me to this section. I do see that the need for sequence number can be avoided as per 7432bis. However, while 7432bis takes care of BGP best path selection, arbitration across local, bgp, and static route producers for the purpose of selecting the route to be installed in forwarding usually happens outside of BGP (in L2RIB). Section 5.1 is intended to ensure that a locally learnt MAC will not take precedence over BGP produced GW MAC route in the forwarding table. That said, one could arguably assume that the BGP best path selection in 7432bis implies forwarding route selection across bgp and local producers as well. Let me discuss with other co-authors and try to align this section with 7432bis in the next revision. # Minor comments: ## If section 5.1 was the only new extension to EVPN, then it is not needed and the draft can be Informational? [NM]: Besides section 5.1, there are procedures for L2 PE and CAG PE specified in section 3, for e.g., use of ARP snooping on L2 PEs to avoid ARP/ND sync. As well as re-origination procedures between L2-only fabric and Symmetric IRB fabric in section 6.1.1. While there isn’t any new specification for anything on the wire, L2-PE and CAG PE need to locally implement these procedures for the solution to work end to end. That seems like a standards track to me, but open to more input – will also discuss with co-authors. ## The following text: ”Optionally, the CAG IRB nodes may also have directly connected end-points.” And this one: “In case of VXLAN encapsulation, set of redundant CAG PEs provisioned as FHR for a common set of subnets MAY advertise the anycast GW MAC/IP RT-2 with an anycast VTEP IP as the next-hop.” Are not really compatible. So you should consider to explain that single-homed local CAG ACs are only possible if anycast VTEPs are NOT used. [NM]: Sure, makes sense. will clarify in the next revision that single homed local end-points are advertised with PIP as the next-hop VTEP. ## section 6.1.3 on split horizon groups on the CAGs should just follow RFC9014. I don’t think there is any new procedure here? [NM]: ack. Will add a reference to RFC9014. Thanks, Neeraj
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
