Ack I’m good
From: Lin, Wen <[email protected]> Sent: Wednesday, November 11, 2026 8:56 PM To: [email protected]; 'Wen Lin' <[email protected]>; 'Stephane Litkowski (slitkows)' <[email protected]>; [email protected]; 'BESS' <[email protected]> Cc: [email protected] Subject: Re: Shepherd's review of draft-ietf-bess-extended-evpn-optimized-ir Hi Stephane, Thanks for taking the time to review my responses, and thanks again for raising the point regarding the term "Extended-MH". I haven't explained the rationale behind the "Extended-MH" terminology very well. Unlike the regular AR-REPLICATOR, the Extended-MH AR-REPLICATOR explicitly tracks and takes into account the multihoming status of the AR-LEAF for which it performs assisted replication, and follow the required forwarding procedures to support EVPN multihoming. I would prefer to retain the name "Extended-MH" as it reflects this extended procedure and forwarding behavior that AR-REPLICATOR follows to support AR-LEAF multihoming, and also considering that the implementation using this term has been in place for many years. I further updated as the draft as follow. I hope the additional clarification in the text will help make the intended meaning clearer. Original: We call such an AR-REPLICATOR an Extended-MH AR-REPLICATOR. Changed to: We call such an AR-REPLICATOR an Extended-MH AR-REPLICATOR. The term "Extended-MH" refers to the extended EVPN multihoming procedures supported by the AR-REPLICATOR. Specifically, AR-REPLICATOR becomes aware of the multihoming status of the AR-LEAF for which it performs assisted replication and follows the forwarding procedures needed to support EVPN multihoming for that AR-LEAF. The term "Extended-MH" does not imply additional multihoming-assisted replication capabilities. I will publish version 10 after the I-D submission tool is reopened. Thanks, Wen From: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > Date: Tuesday, November 10, 2026 at 5:14 AM To: 'Wen Lin' <[email protected] <mailto:[email protected]> >; 'Stephane Litkowski (slitkows)' <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> >; 'BESS' <[email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > Subject: RE: Shepherd's review of draft-ietf-bess-extended-evpn-optimized-ir Hi Wen, Thanks for your reply. I agree with your replies, and will check final text in v10. The only one that I have still concerns on is the name Extended-MH. Thanks for proposing to add some precision on what it means, but I personally like to have names that are “self-explanative” in most of the cases and using “MH” brings confusion IMO. I’ll not block on that, just asking. From: Wen Lin <[email protected] <mailto:[email protected]> > Sent: Monday, November 9, 2026 1:00 AM To: Stephane Litkowski (slitkows) <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; BESS <[email protected] <mailto:[email protected]> > Cc: '[email protected]' <[email protected] <mailto:[email protected]> > Subject: Re: Shepherd's review of draft-ietf-bess-extended-evpn-optimized-ir Hi Stephane, Thank you very much for the review and comments. Please see replies inline below. If you are good with the changes, we will submit them in version 10. Thanks, Wen Juniper Business Use Only From: Stephane Litkowski (slitkows) < <mailto:[email protected]> [email protected]> Date: Monday, November 2, 2026 at 9:17 AM To: <mailto:[email protected]> [email protected] < <mailto:[email protected]> [email protected]>; BESS < <mailto:[email protected]> [email protected]> Cc: '[email protected]' < <mailto:[email protected]> [email protected]> Subject: [bess] Shepherd's review of draft-ietf-bess-extended-evpn-optimized-ir [External Email. Be cautious of content] Hi authors, I’ll be the shepherd of this document, please find some comments related to current text: §2.2: “To support EVPN all-active multihoming based on local-bias procedures, when an AR-REPLICATOR performs assisted replication on behalf of a multihomed AR-LEAF, the AR-REPLICATOR MUST use the source IP address of the ingress AR-LEAF for packet received on the AR-IP tunnel. “ I think the sentence is missing something. “the AR-REPLICATOR MUST use the source IP address…”, but it does not say when. Reader could guess, but it’s better to make the text more explicit, something like “when replicating …” Also, the “MUST” does not match the “MAY” from RFC9574 Section 9.1. It is fine to have this draft changing the MAY to a MUST or probably SHOULD (as you are pointing to limitations) but I don’t think this should be done in Section 2.2. Wen: Good point. The MUST applies specifically to replication toward the peer AR-LEAF on the same Ethernet Segment (ES), where preserving the originating AR-LEAF's source IP address is required to maintain the multihoming information. RFC 9574 Section 9.1's MAY addresses replication to remote AR-LEAFs or RNVEs, including AR-LEAFs may not be on the same ES. To make it clear I updated the draft. Original: "To support EVPN all-active multihoming based on local-bias procedures, when an AR-REPLICATOR performs assisted replication on behalf of a multihomed AR-LEAF, the AR-REPLICATOR MUST use the source IP address of the ingress AR-LEAF for packet received on the AR-IP tunnel. “ Changed to: To support EVPN all-active multihoming based on local-bias procedures, when an AR-REPLICATOR performs assisted replication on behalf of a multihomed AR-LEAF, the AR-REPLICATOR MUST use the source IP address of the ingress AR-LEAF as the source IP address in the outer IP header when replicating a BM packet received over the AR-IP tunnel to another AR-LEAF attached to the same Ethernet Segment as the ingress AR-LEAF. §3.1: “Extended-MH” name looks a bit misleading. Shouldn’t it tell that this AR Replicator doesn’t support MH ? “Extended” makes me think that it has more capabilities (or special capabilities) than a regular AR replicator, but in fact it has less. Wen: I understand your concern about the naming. Let me clarify what 'Extended-MH' is intended and also clarify it in the draft. The intention is that "Extended-MH" refers to the AR-REPLICATOR's support for the extended Optimized-IR procedures for EVPN multihoming defined in this draft, rather than additional multihoming-assisted replication capabilities. It is a coordinated forwarding procedure between the AR-LEAF and AR-REPLICATOR that enables EVPN multihoming to coexist with optimized ingress replication: The AR-REPLICATOR continues to play an important role in assisted replication for multihomed AR-LEAFs, providing replication toward NVEs that do not share a multihomed ES with the AR-LEAF, while skipping peer NVEs that do. The ingress AR-LEAF uses regular ingress replication toward those peer NVEs, allowing them to apply the existing EVPN split-horizon procedures correctly. I added the following clarification to Section 3.1 of the draft, at the end of the first paragraph: Original: We call such an AR-REPLICATOR an Extended-MH AR-REPLICATOR. Changed to: We call such an AR-REPLICATOR an Extended-MH AR-REPLICATOR, where "Extended-MH" refers to the extended EVPN multihoming procedures supported by the AR-REPLICATOR, rather than implying additional multihoming-assisted replication capabilities §3.2: “the multihomed AR-LEAF follows the extended Optimized-IR procedures specified in this document.” Please point to the proper section of the document where the procedure is defined. Wen: Good suggestion. I changed it to: the multihomed AR-LEAF follows the extended Optimized-IR procedures specified in Section 4. “The extended procedures required for an AR-LEAF is further specified in detail in section 5.” Isn’t it section 4 ? When reading this section, I was thinking that it was defining the procedures. This sentence should probably go at the beginning of the section so the reader knows that this section is an overview of the solution, not the detailed procedures. Wen: Good catch. I changed it to: The extended procedures required for an AR-LEAF is further specified in detail in section 4. §4.1.1: “If selective assistant-replication is used for the EVI, selective AR- LEAFs that share the same multihomed ES MUST select the same primary AR-REPLICATOR and the same backup AR-REPLICATOR, if there is one.” Is it new vs RFC9574 ? Wen: Thanks for raising this question. I'll elaborate on the reason behind this requirement to make it clearer why consistent AR-REPLICATOR selection is needed for the extended-MH procedures. I replaced the above with the following: The selective AR procedures defined in RFC 9574 allow multiple AR-LEAF sets within an EVPN BD. They build single-hop trees among AR-LEAFs belonging to the same set (AR-LEAF → AR-REPLICATOR → AR-LEAF) and two-hop trees among AR-LEAFs belonging to different sets (AR-LEAF → AR-REPLICATOR → AR-REPLICATOR → AR-LEAF). However, the two-hop replication procedure does not work with the extended-MH procedures. When the first AR-REPLICATOR forwards BM traffic to the second AR-REPLICATOR, it uses its own IP address as the source IP address, causing the second AR-REPLICATOR to lose the original AR-LEAF's identity and the multihoming information associated with it. Therefore, to support the extended-MH procedures, selective AR-LEAFs sharing the same multihomed ES MUST select the same primary AR-REPLICATOR and the same backup AR-REPLICATOR, if one is configured. This ensures that BM traffic between these AR-LEAFs is handled through a single-hop replication tree, preserving the originating AR-LEAF's identity and the information needed for correct EVPN multihoming forwarding. §5 “All multihomed AR-LEAFs and all AR-REPLICATORs within the same EVI MUST use the same scheme to keep track of the common multihomed ES that an AR-LEAF shares with other remote NVEs. “ What do you mean this “use the same scheme” ? Are you referring to what you mention in next paragraph about tracking per EVI or per BD ? Enforcing by config is always dangerous, what happens if there is disprecancy in config across the devices ? This should be highlighted. But I’m not really following what needs to be configured. I’m wondering if it would be cleaner to have the text of §5 introduced in §4 so the reader as all the data in one place regarding the procedures of the AR-LEAF. Wen: Thanks for the questions and suggestion. To make it clear, I changed the requirement and its implications in the text and moved it to Section 4. This is to ensures that all participating AR-LEAFs and AR-REPLICATORs use a consistent tracking scope. Original: "For the extended Optimized-IR procedures specified in this document, a multihomed AR-LEAF MAY keep track of the common multihomed ES it shares with other remote NVEs on a per BD specific scope or on a per EVI scope. Correspondingly, an Extended-MH AR-REPLICATOR MUST also use the same scheme to keep track of the common multihomed ES that its AR-LEAF shares with other remote NVEs. All multihomed AR-LEAFs and all AR-REPLICATORs within the same EVI MUST use the same scheme to keep track of the common multihomed ES that an AR-LEAF shares with other remote NVEs. This consistency can be enforced through a manual configuration" Changed to: All multihomed AR-LEAFs and AR-REPLICATORs within the same EVI MUST use the same tracking scope to identify the common multihomed ES that an AR-LEAF shares with other remote NVEs. The tracking scope determines whether the common multihomed ES is tracked on a per-EVI or per-BD basis. In other words, if an AR-LEAF uses per-EVI tracking, the corresponding AR-REPLICATORs and other participating multihomed AR-LEAFs MUST also use per-EVI tracking. Similarly, if per-BD tracking is used, all participating devices MUST use per-BD tracking. This consistency is necessary to ensure that the AR-LEAF and AR-REPLICATOR make consistent forwarding decisions. A mismatch in the configured tracking scope may result in incorrect BM traffic replication." §10: RFC9746 is mentioned in the text but not in the references Wen: Good catch. Fixed. Brgds, Stephane
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
