> On Feb 27, 2020, at 3:58 PM, Robert Raszuk <rob...@raszuk.net> wrote: > > > > What draft-ietf-spring-srv6-network-programming proposes is to remove a > > segment routing header (SRH) along the packet delivery path, before the > > packet arrives at the final destination. They call it PSP. > > That removal as it has been explained to you many times happens at the node > which is explicitly listed as DA of the packet. > > > Before, folks have also proposed to insert Extension Headers (EHs) while > > packets are en-route to their intended destination, etc. > > That has been moved to a separate draft to move fwd with the rest of the > work. > > Yes this is still useful for TI-LFA (as example). > > We need to ask ourselves what is more important ... quality of data plane for > end users with 10s of ms of connectivity restoration times upon failure or > keeping original IPv6 dogmas in place where folks never envisioned such needs > or technologies to be invented.
I don’t care about what you WANT to do; I care whether it breaks what everyone else expects. Any device along an IP path that makes a packet larger IN ANY WAY is ITSELF responsible for making sure that packet can continue forward. At a tunnel, that means work at BOTH the ingress (source fragmentation) and egress (reassembly). Now, if you add EHs to an IP packet and you’re in control of the ability to do source fragmentation AND reassembly ***IN THE PATH YOU MANAGE***, then you simply can’t do it. Because it WILL break PLPMTUD. So if you still WANT to do this(1), then YOU need to prove you can CLEAN UP YOUR MESS. Where is the draft that explains how PLPMTUD, among other things, will continue to work? Joe (1) this whole thing sounds a lot like Active Nets, which was a retread of SoftNet. So the cycle goes, every 20 years or so. Take the slowest thing a router does and expect it to do more of it, as Jon said. What is it Einstein said about the definition of insanity? _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
