Re: [spring] RFC8200 update?

[Andrew Alston <[e-mail]>]

This is certainly an interesting idea - and I'd probably need to give this a whole lot more thought before commenting properly, but the first thought that comes to mind is - would we be able to standardize a way to instruct like this.

What I would not want to see is every extension header out there having a separate method of instructing the network to allow this behavior whenever they feel like it, because it would create a nightmare both in terms of seeing if something was requesting it, and I would imagine, implementing it.

So - my question is - what would be the standard way to introduce this - and to this I would say - if you wanted to do this you'd almost want to add a very short extension header that contains this instruction, that is easy to see and easy to parse - since I don't see anywhere in the v6 header itself that we could add this functionality as a flag of sorts.

Interesting ideas - but as I said - I'd argue that if we went this route - I'd want a standard shared way to do this by anything coming tomorrow - to avoid still further divergence.

Thanks

Andrew


> -----Original Message-----
> From: spring <[e-mail]> On Behalf Of Sander Steffann
> Sent: Friday, 28 February 2020 15:02
> To: SPRING WG List <[e-mail]>; 6man WG <[e-mail]>
> Subject: [spring] RFC8200 update?
> 
> 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