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]
