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]> 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]> 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]
