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