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]
