[spring] RFC8200 update?

[Sander Steffann <[e-mail]>]

Hi,

I have been thinking about SRv6 and the whole discussion around header removal at one of the SR nodes. While I strongly see the current network programming PSP function as a violation of RFC8200, one of the possible options is of course to update RFC8200 to allow some things that are currently not allowed.

Before you start throwing rotten tomatoes, hear me out :)

The most important argument against modifying a packet between the sender and the final receiver is that it can cause surprises for the sender. ICMP errors getting back to the sender about stuff the sender didn't do, pMTUd problems etc. And I think this is a very strong argument, and we shouldn't cause any surprises for the sender.

But, what if the sender *asks* the network to do things to its packets? Like in network programming. If the sender asks to have the network perform a certain function, it can't come as a surprise when it gets an ICMP error after the packet has been modified. It asked for that modification itself! And with that in mind, we might actually allow much more than just header removal in the network.

What if we update RFC8200 to allow packet manipulation in the network if and only if the sender of the packet explicitly asked for that? That would open the door for a whole range of innovation (PSP, WAN optimisation, payload compression etc), but only when requested. If the sender explicitly includes network programming instructions then there is no need anymore to forbid the execution of those instructions. No surprises, the possibility of smarts in the network, while still preserving the current semantics of an end-to-end network by default with strong rules about not messing with the packet.

Would this be a way forward that would accommodate everyones requirements?

Cheers,
Sander