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]> 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]> 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]> >> wrote: >> >>> Erik, >>> >>> Reply inline @ [RP] >>> >>> On Thu, Oct 16, 2025 at 8:55 PM Erik Kline via Datatracker < >>> [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] >>>> To unsubscribe send an email to [email protected] >>>> >>>
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
