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

[Guntur Wiseno Putra <[e-mail]>]

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 <[e-mail]> 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 <[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?
>>
>>