Hi Rishabh, The DISCUSS from Erik is cleared according: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-sr-p2mp/ballot/
G/ From: Rishabh Parekh <[email protected]> Sent: Wednesday, November 12, 2025 7:16 PM To: Erik Kline <[email protected]> Cc: The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: [bess] Re: Erik Kline's Discuss on draft-ietf-bess-mvpn-evpn-sr-p2mp-15: (with DISCUSS) 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. Erik, Have you got a chance to look at revision 16 and check if it addresses your DISCUSS? Thanks, Rishabh. On Wed, Oct 29, 2025 at 7:57 AM Rishabh Parekh <[email protected]<mailto:[email protected]>> wrote: Erik, The new revision of the draft has the above change in the text. Can you please take a look and confirm if this addresses your DISCUSS? Thanks, Rishabh. On Sun, Oct 19, 2025 at 9:42 AM Rishabh Parekh <[email protected]<mailto:[email protected]>> wrote: Erik, This is an optional MAY behavior because an egress PE must be able to identify the ingress PE that sent the IPv6 encapsulated packet in order to determine the MVPN context from upstream assigned SID. This may not be feasible from examining the IPv6 source address of the packet, unless the egress PE knows what IPv6 address ingress PEs would use for encapsulation. So, on second thought, it is better to drop this text from the draft and just mandate that an egress PE must not forward the packet based on the End.DTMC4/6 SID in the SRH. Rishabh. On Sat, Oct 18, 2025 at 6:05 PM Erik Kline <[email protected]<mailto:[email protected]>> wrote: Thank you. Might another option be something in the RFC 9602 space? Or a new space from 5f00::/8 (minus the 9602 prefix)? On Sat, Oct 18, 2025 at 5:19 PM Rishabh Parekh <[email protected]<mailto:[email protected]>> wrote: Erik, Yes, the discard prefix 0100:64 from RFC 6666 can be used. My only concerns are in practice Locator prefixes are assigned from /32 or /48 prefix blocks, and I know some implementations may assume these prefix blocks for the LOC portion of SRv6 SIDs. The /64 discard prefix LOC will push the FUNCT further in SRv6 SID. That said, I can certainly add it as an option in addition to ULA. Rishabh. On Sat, Oct 18, 2025 at 3:28 PM Erik Kline <[email protected]<mailto:[email protected]>> wrote: This helps, thank you. A ULA is not necessarily non-routable, though. Would it be possible to use the RFC 6666 discard prefix? On Thu, Oct 16, 2025 at 9:48 PM Rishabh Parekh <[email protected]<mailto:[email protected]>> wrote: Erik, Reply inline @ [RP] On Thu, Oct 16, 2025 at 8:55 PM Erik Kline via Datatracker <[email protected]<mailto:[email protected]>> wrote: Erik Kline has entered the following ballot position for draft-ietf-bess-mvpn-evpn-sr-p2mp-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-sr-p2mp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Internet AD comments for draft-ietf-bess-mvpn-evpn-sr-p2mp-15 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Discuss ### S3.1.2 * "The advertising ingress PE MAY use a non-routable prefix as LOC of the SRv6 Multicast Service SID to prevent packets being routed to it based on the SID." Can you clarify what is intended here? I'm afraid I couldn't figure out what is meant by a non-routable prefix to prevent packets being routed to the advertising router. Possibly I just don't have the right mental model yet. Is this for some scenario where discarding traffic is desired? [RP] The use-case is when an SRv6 P2MP tree is shared across two or more MVPN contexts. In this case, the ingress PE advertises an upstream-assigned SID (one of End.DTMC4/6 specified in Section 5.21) to identify specific MVPN context for payload processing at an egress PE (which receives MVPN customer payload on the shared SRv6 P2MP tree). This upstream assigned SID is carried in SRH of an IPv6 encapsulated packet from the ingress PE. On the egress PE, this SID (or specifically FUNCT portion of the SID) should just be used to derive the MVPN context. If an egress PE mistakenly uses this SID to forward the packet (by setting it in the IPv6 DA header), the packet will incorrectly routed back to the ingress PE if the LOC portion of the SID identifies the ingress PE. To prevent incorrect re-routing using the SID, the ingress PE may use a non-routable IPv6 prefix (such as Unique Local Address prefix) as the LOC portion of End.DTMC4/6 SID. I hope this answers your question. _______________________________________________ BESS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
