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]
