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

Joseph Touch <touch@strayalpha.com> Fri, 28 February 2020 04:34 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849B13A0F1F; Thu, 27 Feb 2020 20:34:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Level:
X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPPyZH3FiLla; Thu, 27 Feb 2020 20:34:03 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AADD93A0F1A; Thu, 27 Feb 2020 20:34:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ifSxmR067gT7iwrCN6LjKwH98bcIjxK/GHfrFnxeQvA=; b=v6XAXkYRa8eW9rWdA4yyJYdap fzmipUgvr1hKRkdHZipZJw9z83xI/EtBtti0pDnQQSNiwwPGlDEZjaARRhP/S7lVhyoNMZdtF0DEJ q3Wtx1/7ffmrFM7Vehx1YLtwIALKy6tsTdFT5Q2MsZX/8/UhLElYPdRb/FXK2wP+TWMurxcDFVqf4 oewPir2s8qnnTo8zI/OjjQOnXc7wDWUNUs3URserdlhgtLP6v9sw2VEoW/mnrBnd67fR9Vrl8zGgk AFXa9wkTkc+x/idYQVg1EOWaNiANO7UWxoF5S3T4LsKs6Ix69DftlIPAP4Z3tkl8fwr5LY8oMPeGF sQUwqxhaw==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:58091 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1j7XLa-002iCI-GA; Thu, 27 Feb 2020 23:34:02 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <CAOj+MMGJ11CBCov=-jfZUtROJPwhQB3A=+0gMBhzZgxoF_9N1A@mail.gmail.com>
Date: Thu, 27 Feb 2020 20:33:57 -0800
Cc: Fernando Gont <fgont@si6networks.com>, Tom Herbert <tom@herbertland.com>, Internet Architecture Board <iab@iab.org>, architecture-discuss@iab.org, Internet Area <int-area@ietf.org>, IETF <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A83D4788-AD7B-490C-B74E-2548A1345C47@strayalpha.com>
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com> <CALx6S36wN7VEi_rxLC1ETcTvkGaPhs20KhQrGWAGGTrCL5OT+g@mail.gmail.com> <d41a94f5ede994b9e14605871f9f7140@strayalpha.com> <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com> <a24a3621-99f6-755d-c679-2061b9a67adf@si6networks.com> <CAOj+MMGJ11CBCov=-jfZUtROJPwhQB3A=+0gMBhzZgxoF_9N1A@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - iab.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/5HhV91qQ3nAZhJFj_SsNvx7o2iY>
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2020 04:34:06 -0000


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