Hi Andrea, Thank you for the answers.
> On the placement, the new lwtunnel encap type you propose could be a way to > implement the seg6_mobile.c separation. Since this touches UAPI in > include/uapi/linux/lwtunnel.h beyond the SRv6 subsystem and cannot be > undone once merged, it needs careful design. [...] > As far as I can see, RFC 9433 has only one Headend behavior, and no L2 or > reduced variants. So a single LWTUNNEL_ENCAP_SEG6_MOBILE handling both > End.M.* and H.M.GTP4.D could be viable if accepting both input families > (ETH_P_IPV6 for End.M.*, ETH_P_IP for H.M.GTP4.D) is treated as a design > choice of the new encap type, not a stretching of the seg6_local endpoint > processing model. > > These trade-offs are worth weighing in the final design. [...] I think the > lwtunnel direction will need feedback and comments from its community and > maintainers. Agreed. The first per-behavior RFC series (End.MAP) will introduce the LWTUNNEL_ENCAP_SEG6_MOBILE encap type and the SEG6_MOBILE_* attribute namespace, and explain in its cover letter that this is the shared container for the RFC 9433 Section 6 behaviors, so the lwtunnel and routing folks can weigh in early. The dual input family (ETH_P_IPV6 for End.M.*, ETH_P_IP for H.M.GTP4.D) is specific to H.M.GTP4.D, so I will lay that out in the H.M.GTP4.D cover letter; keeping it last in the posting order gives that discussion time to converge. > If LWTUNNEL_ENCAP_SEG6_MOBILE is added, using SEG6_MOBILE_* attributes > instead of SEG6_LOCAL_* removes the NH6/SRH/OIF overload raised in v2. > After solving the above, additional issues remain in the patchset, > for example src is overloaded across MUP behaviors, and v4_mask_len > needs revision. These are independent of the lwtunnel decision. Both will be addressed in the rework; the details are in my replies to your patch 2 and patch 3 reviews. In short: v4_mask_len and the src template will be removed from End.M.GTP4.E entirely (full 32-bit IPv4 DA/SA recovery only), src will mean the verbatim outer IPv6 SA for the IPv6-emitting behaviors, and the H.M.GTP4.D "Source UPF Prefix" template can get its own attribute name in that series if you prefer. > I can lead it. I have been evaluating the SRv6 drop reasons with my > research group, alongside other pending SRv6 patches. > > We can sync offline on which SRv6 reasons fit your MUP behaviors, which > v2 MUP-specific reasons would fit better as SRv6 or generic, and what > stays MUP-specific. Thanks for taking the lead; happy to sync offline. Until the prep series lands, the per-behavior series will carry no MUP-specific drop reasons. > Thanks. Maybe also worth covering bad packets, like fragmented input or > malformed GTP-U extensions. Will do; the C-helper selftests will cover malformed and truncated GTP-U extension chains, a duplicated PDU Session Container, and fragmented outer input (which the behaviors will reject explicitly). > Works for me. What matters is that the upcoming patches are well structured > so NF_HOOK can be wired in cleanly in the follow-up. > > I am already working on the fix. Understood. Each behavior will keep a single strip / transform / push flow in its input handler, so the hook can later slot between strip and push without reintroducing the skb->cb context pattern. Thanks, Yuya
