Erik, Have you got a chance to look at revision 16 and check if it addresses your DISCUSS?
Thanks, Rishabh. On Wed, Oct 29, 2025 at 7:57 AM Rishabh Parekh <[email protected]> wrote: > 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]
