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 <[email protected]> On Behalf Of Sander Steffann > Sent: Friday, 28 February 2020 15:02 > To: SPRING WG List <[email protected]>; 6man WG <[email protected]> > 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 _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
