Re: [PATCH iproute2-next] lwt: ioam6: allow options in any order

[Hangbin Liu <hangbin.liu@linux.dev>]

Hi Justin,
On Sat, Oct 24, 2026 at 05:26:28PM +0200, Justin Iurman wrote:
> On 10/22/26 04:53, Hangbin Liu wrote:
> > From: Hangbin Liu <liuhangbin@kylinos.cn>
> > 
> > The ioam6 encap options must be given in a fixed order (freq, mode,
> > tunsrc, tundst, trace, prealloc, type, ns, size). If a user uses a
> > different order, the command fails with a misleading error even
> > though every option is present:
> > 
> >    # ip -6 route change 2001:db8:2:1::/64 encap ioam6 mode encap \
> >        trace prealloc tundst 2001:db8:2:1::2 type 0x800000 ns 0 size 12 \
> >        via 2001:db8:1::3 dev dummy0
> >    Error: argument "tundst" is required
> > 
> > Parse all options in a single while loop instead, then run the
> > cross-option and missing-argument checks after the loop, reporting
> > the missing arguments in the order the options are documented in
> > ip-route(8).
> 
> The current order is not arbitrary by intent:
> 
> 1. freq
> 2. mode
> 3. tunsrc
> 4. tundst
> 5. trace
> 6. prealloc
> 7. type|ns|size
> 
> While I agree some could be swappable and the above order is too strict,
> most are dependent on context (i.e., a previous keyword). For example,
> (type|ns|size) are only valid in a 'prealloc' context, which one is only
> valid in a 'trace' context. They form a group and their current order should
> remain inside this group.
> 
> OTOH, as mentioned, some could be swapped. For example, both tunsrc and
> tundst could come in whatever order. However, they are only valid in a
> specific 'mode' context, so they should appear after it. With 'mode', they
> form another group. 'freq' forms another group by itself.
> 
> So, I guess a new accepted (relaxed) order should accept groups in whatever
> order, but the order inside a same group should remain. That said, I'd be
> open to this proposal if other iproute2 commands also accept parameters in
> any order, regardless of their scope or dependencies.

Thanks for the reply. I agree your explanation about the ordering makes sense.
Personally, though, I still think the ordering constraint is too strict. And
the new patch also validates for mode mismatches and missing parameters.

I’ve checked all encap types: only mpls and ila require the address to be the
first parameter, seg6 has an error info about the tunsrc order. All others allow
arbitrary order.

I’m fine with keeping the existing behavior, as I can read the source code and
know the order is fixed. But new users will likely hit this same issue again.

Thanks
Hangbin