| Message ID | 20211011180412.22781-1-justin.iurman@uliege.be (mailing list archive) |
|---|---|
| Headers | show |
| Series | Correct the IOAM behavior for undefined trace type bits | expand |
Hello: This series was applied to netdev/net.git (master) by David S. Miller <davem@davemloft.net>: On Mon, 11 Oct 2021 20:04:10 +0200 you wrote: > (@Jakub @David: there will be a conflict for #2 when merging net->net-next, due > to commit [1]. The conflict is only 5-10 lines for #2 (#1 should be fine) inside > the file tools/testing/selftests/net/ioam6.sh, so quite short though possibly > ugly. Sorry for that, I didn't expect to post this one... Had I known, I'd have > made the opposite.) > > Modify both the input and output behaviors regarding the trace type when one of > the undefined bits is set. The goal is to keep the interoperability when new > fields (aka new bits inside the range 12-21) will be defined. > > [...] Here is the summary with links: - [net,1/2] ipv6: ioam: move the check for undefined bits https://git.kernel.org/netdev/net/c/2bbc977ca689 - [net,2/2] selftests: net: modify IOAM tests for undef bits https://git.kernel.org/netdev/net/c/7b1700e009cc You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
On Mon, 11 Oct 2021 20:04:10 +0200 Justin Iurman wrote: > (@Jakub @David: there will be a conflict for #2 when merging net->net-next, due > to commit [1]. The conflict is only 5-10 lines for #2 (#1 should be fine) inside > the file tools/testing/selftests/net/ioam6.sh, so quite short though possibly > ugly. Sorry for that, I didn't expect to post this one... Had I known, I'd have > made the opposite.) Hi Justin, net was merged into net-next now, please double check the resolution. I think it's the same as Stephen's [1]. In the future please try to include a tree way diff or instructions on how to do the merge. Thanks! [1] https://lore.kernel.org/all/20211013104227.62c4d3af@canb.auug.org.au/
>> (@Jakub @David: there will be a conflict for #2 when merging net->net-next, due >> to commit [1]. The conflict is only 5-10 lines for #2 (#1 should be fine) inside >> the file tools/testing/selftests/net/ioam6.sh, so quite short though possibly >> ugly. Sorry for that, I didn't expect to post this one... Had I known, I'd have >> made the opposite.) Hi Jakub, > Hi Justin, net was merged into net-next now, please double check the > resolution. I think it's the same as Stephen's [1]. In the future please Thanks for that, I just checked and it's indeed OK. > try to include a tree way diff or instructions on how to do the merge. Noted, thanks again. > Thanks! > > [1] > https://lore.kernel.org/all/20211013104227.62c4d3af@canb.auug.org.au/
(@Jakub @David: there will be a conflict for #2 when merging net->net-next, due to commit [1]. The conflict is only 5-10 lines for #2 (#1 should be fine) inside the file tools/testing/selftests/net/ioam6.sh, so quite short though possibly ugly. Sorry for that, I didn't expect to post this one... Had I known, I'd have made the opposite.) Modify both the input and output behaviors regarding the trace type when one of the undefined bits is set. The goal is to keep the interoperability when new fields (aka new bits inside the range 12-21) will be defined. The draft [2] says the following: --------------------------------------------------------------- "Bit 12-21 Undefined. These values are available for future assignment in the IOAM Trace-Type Registry (Section 8.2). Every future node data field corresponding to one of these bits MUST be 4-octets long. An IOAM encapsulating node MUST set the value of each undefined bit to 0. If an IOAM transit node receives a packet with one or more of these bits set to 1, it MUST either: 1. Add corresponding node data filled with the reserved value 0xFFFFFFFF, after the node data fields for the IOAM-Trace-Type bits defined above, such that the total node data added by this node in units of 4-octets is equal to NodeLen, or 2. Not add any node data fields to the packet, even for the IOAM-Trace-Type bits defined above." --------------------------------------------------------------- The output behavior has been modified to respect the fact that "an IOAM encap node MUST set the value of each undefined bit to 0" (i.e., undefined bits can't be set anymore). As for the input behavior, current implementation is based on the second choice (i.e., "not add any data fields to the packet [...]"). With this solution, any interoperability is lost (i.e., if a new bit is defined, then an "old" kernel implementation wouldn't fill IOAM data when such new bit is set inside the trace type). The input behavior is therefore relaxed and these undefined bits are now allowed to be set. It is only possible thanks to the sentence "every future node data field corresponding to one of these bits MUST be 4-octets long". Indeed, the default empty value (the one for 4-octet fields) is inserted whenever an undefined bit is set. [1] cfbe9b002109621bf9a282a4a24f9415ef14b57b [2] https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data#section-5.4.1 Justin Iurman (2): ipv6: ioam: move the check for undefined bits selftests: net: modify IOAM tests for undef bits net/ipv6/ioam6.c | 70 ++++++++- net/ipv6/ioam6_iptunnel.c | 6 +- tools/testing/selftests/net/ioam6.sh | 26 +++- tools/testing/selftests/net/ioam6_parser.c | 164 ++++++++------------- 4 files changed, 148 insertions(+), 118 deletions(-)