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

[Guntur Wiseno Putra <gsenopu@xxxxxxxxx>]

Dear Fernando, Robert &

architecture-discuss,

Change & Architectural Thinking and Planning...:

To add what was about D. Thaler's regarding with "proposals and changes" and R. Raszuk's "technology for real life uses", there are also

P. Nikander in "Reflections on Architecture" (2005) proposed

"What we perhaps don’t consider very often is the fact that there are huge asset values embedded in various parts of the network.

Any change requires a reason to overcome the associated hurdle. Consequently, I have found it very instructive to try to think about the network and protocols in terms of assets, incentives, costs, and benefits".

Nikander said that there are different types and sources of complexity as it is represented in the Internet system: emergent complexity & architectural complexity. "While we can at most work towards understanding emergent complexity in the first place, there is a great deal we can do about architectural complexity." And, he said, here we need visions..

https://www.ietfjournal.org/reflections-on-architecture/#

 

When technology is about human passions for beauty: By a second reading on Heidegger's via Boris Groys ("Art, Technology and Humanity, 2017), there is an understanding that "changes of/in technology" is made/engineered "precisely to immunize man against change, to liberate man from his dependency on physis, on fate, on accident."


https://www.e-flux.com/journal/82/127763/art-technology-and-humanism/

Regard,

Guntur Wiseno Putra

Pada Jumat, 28 Februari 2020, Robert Raszuk <robert@xxxxxxxxxx> menulis:

>  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 <touch@xxxxxxxxxxxxxx> wrote:

> On Feb 27, 2020, at 3:58 PM, Robert Raszuk <robert@xxxxxxxxxx> 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?