Hi, More of the same: 1. I have noticed that that the -03 revision of the draft has been posted 2 days before my previous email has been sent , so my comment/question about the draft expiration is not relevant. At the same time, I have not found any substantial differences between the current (-03) and previous (-02) versions 2. I have problems with understanding the following text in Section 3 of the draft:
A subsequent PE failure, link failure, or other event triggering the loss of all non-proxy MAC-IP state on a multihoming PE will cause that PE to start an aging timer for the proxy MAC-IP the PE had previously advertised. * A failed PE can hardly start any timers (or do anything else) * I do not see why failure of a local PE-CE link from which some MAC-IP state has been locally learned and advertised as non-proxy EVPN RT-2 should affect "proxy" MAC-IP state it has advertised * My guess (FWIW) that the intention is for other PEs attached to the same MH ES to start the aging timer for "the "proxy" states that have been created based on "original" advertisements by the PE that has experienced the event in question - is this correct? I repeat my proposal to hold a side meeting during the Dublin IETF for discussing these and, possibly, other issues with the draft. Regards, Sasha From: Alexander Vainshtein Sent: Sunday, October 20, 2024 6:28 PM To: draft-rbickhart-evpn-ip-mac-proxy-...@ietf.org Cc: bess@ietf.org Subject: Questions and comments on the Proxy MAC-IP Advertisement in EVPNs draft Importance: High Hi, I have read the Proxy MAC-IP Advertisement in EVPNs<https://datatracker.ietf.org/doc/html/draft-rbickhart-evpn-ip-mac-proxy-adv-02> draft and I see that it has expired almost 2 months ago. I wonder whether the authors plan to update the draft any time soon. IMHO and FWIW the most important use case for the advertisement of proxy EVPN RT-2 draft is described in Section 3.4 "Symmetric IRB Considerations" because: * Preservation of ARP/ND state in the PEs attached to the same MH ES from which a specific IP --> MAC pair has been locally learned can be provided without advertisement of Proxy EVPN RT-2 * The ARP/ND state maintenance sub-function defined in Section 3.5 of RFC 9161<https://datatracker.ietf.org/doc/html/rfc9161#section-3.5> guarantees fast restoration of this state in "remote" PEs * With Symmetric EVPN IRB fast recovery and/or load balancing of inter-subnet downstream (i.e. to destinations reachable via the MH ES) traffic cannot be achieved without advertisement of "proxy" EVPN Type 2 routes as described in the draft. I also think that in the scenarios in which Symmetric EVPN IRB is used in combination with Single-Active EVPN multi-homing, the proposal to use P/B flags in the Layer 2 Attributes Extended Community attached to the per-EVI Ethernet A-D routes (as suggested in 7432bis) will not work - because, generally speaking, the remote PEs sending downstream inter-subnet traffic towards destinations behind this MH ES, generally speaking, will not receive per-EVI Ethernet A-D routes in question. An alternative proposal could be advertisement of Proxy routes with decreased (relative to the original) Local Preference. I have noticed that some of the authors have registered for IETF-121 in Dublin. I will be attending this meeting remotely, and I would be glad if we could set up a side meeting for discussing the draft. Regards, and lots of thanks in advance, Sasha Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
