Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

[Robert Raszuk <[e-mail]>]

>  I don’t care about what you WANT to do; I care whether it breaks what
everyone else expects.

I see many folks on this colorful thread simply forgot what networks are
for. To deliver packets in the most robust and resilient way to end user
applications.

As links and node fails there is established need to quickly repair when
the failure occurs to minimize packet loss.

I see that even among "routing experts" there is still false believe that
when a failure happens let's crunk up OSPF or ISIS or BGP to repair control
plane end to end to go around broken link or node. They call it "network
convergence".

In the same time for over 20 years now it has been well established that
above model is wrong approach to fast repair. Repair must happen at the
point of failure or just next to it. The terminology we use to describe
this in contrast to network convergence is connectivity restoration. With
that network protocols do not need to be stressed any more and they can
take as much time (in realistic scale) as they need to converge while user
packets bypass the failure.

And to accomplish such model in a loop free fashion *bits are added on the
fly to the packets. *If operator would do it in a way that end users suffer
he will loose revenue or job. So this is not IETF business to say - no you
can not do it as it may sometimes fail say due to MTU. If ingress to ones
network is 4K and his network can carry 9K MTU - the issues would never
cause any problems during said repair.

Sometimes bits are added in a form of new MPLS label(s) MPLS-FRR, sometimes
in a form of new encapsulation IP-FRR. Here while we are at the SR debate
such addition can be something in between. That is in my view enhancement
of IPv6 to make it more attractive to be deployed and used. I find it very
surprising that those who should promote the technology the most are
spending hours to make it less attractive for real life use.

- - -

As stated in the other thread I think SR folks were just trying to be good
IETF citizens and went towards the path of IPv6 "extension". I would just
go as building on prior art approach without even talking to 6man WG :)

Kind regards,
R.

On Fri, Feb 28, 2020 at 5:34 AM Joseph Touch <[e-mail]> wrote:

>
>
> > On Feb 27, 2020, at 3:58 PM, Robert Raszuk <[e-mail]> 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?
>
>