Erik, The new revision of the draft has the above change in the text. Can you please take a look and confirm if this addresses your DISCUSS?
Thanks, Rishabh. On Sun, Oct 19, 2025 at 9:42 AM Rishabh Parekh <[email protected]> wrote: > 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]
