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

Robert Raszuk <robert@raszuk.net> Thu, 27 February 2020 23:58 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AA23A08FA for <int-area@ietfa.amsl.com>; Thu, 27 Feb 2020 15:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 XG3l0NywRUWv for <int-area@ietfa.amsl.com>; Thu, 27 Feb 2020 15:58:22 -0800 (PST)
Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA54E3A0904 for <int-area@ietf.org>; Thu, 27 Feb 2020 15:58:22 -0800 (PST)
Received: by mail-oi1-x22e.google.com with SMTP id r16so1116630oie.6 for <int-area@ietf.org>; Thu, 27 Feb 2020 15:58:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gbFgz2Z6I9LvUieMphUsPZoJ9StwZIxZle6TOd4iIc0=; b=STi+v9HOefhB+5cwHq9xksKoj7Hiqiux2pBvuQ15QK/XcT3taSg2msHEBDE/TTDSA6 0Hf6uPUtUPN0TJmybCpJ6W4/pHI+g+RwEkBc2y85wzJBkenoFM8Bnzi7PbrXQVqDHHoy eImTsQjHpNWcTFeUUHGVGpxthtVhTmbrZ2Tkg4eKNhV9zdvY0ZKM+Rs7o7gvHmzENSp9 8Q/uFoNaNm3/oXzn8Zu3oKCcZXarV5y+tGqeMQCbLb4B0RuMhWxw3eyBmnapYbtpMPT1 +a+Zo78l/wlrFAR1ppA3fPmLal7ZqyTQ0BFsoi5aG0tEkWxF6VRn+Ja4AnQst5q5u2hq LGjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gbFgz2Z6I9LvUieMphUsPZoJ9StwZIxZle6TOd4iIc0=; b=BaWNX1xBsNYyWm3ld1nhQ94z0yzTK1SpL21JRQ5+wfGTvRLBS96vxXJh1BOUnU5bvX 7qwLk7AeW6iPjXXuhtYVAE2NTDuijw9FcarzaYG+7ApE+0hVN0joH8wDOpRQ5W0hFvIY lskoWeMRrAtrjZ+osSND0pGV4ycBJlgndfNdZjOFL956PCqjwr/pqfkAJiPkrCp16SWT /J3hTvrROCKHlnQC3/CLskobpnqisvJLnCFPg3gohX184bj0Da9Nsho1UKGdDKoyo61l gVD9bkV/t2naVNpTrSQH3bOs6MaaqwPAtPsMlrdqvUwKT4IUDzYbzMxXyJxf42SZiWxO /S7Q==
X-Gm-Message-State: APjAAAWadVeKaWbpA/LbEZ8PFMPfZb70Rfe3jzxpLZ3SMe2i72foVOf2 mjY9bNDByL0bHTUwVZR+nse4d9oqiQjgpZKy8j8f+w==
X-Google-Smtp-Source: APXvYqyaFSKSkamoJ3xLvcO/sVd430GJXEGqebLPgfb2qi069vJ2kCHMwi+MDNX6/GWq2I0RKi/feOU8epHu1VWf/A8=
X-Received: by 2002:a54:4510:: with SMTP id l16mr1219186oil.70.1582847901816; Thu, 27 Feb 2020 15:58:21 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <a24a3621-99f6-755d-c679-2061b9a67adf@si6networks.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 28 Feb 2020 00:58:11 +0100
Message-ID: <CAOj+MMGJ11CBCov=-jfZUtROJPwhQB3A=+0gMBhzZgxoF_9N1A@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: Joe Touch <touch@strayalpha.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-Type: multipart/alternative; boundary="000000000000ebf261059f977eb7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/yR7631QoadhlhrTCPUDhPF38eww>
Subject: Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2020 23:58:25 -0000

> 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.

Rgs,
R.


On Fri, Feb 28, 2020 at 12:37 AM Fernando Gont <fgont@si6networks.com>
wrote:

> Joe,
>
> 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.
>
> Before, folks have also proposed to insert Extension Headers (EHs) while
> packets are en-route to their intended destination, etc.
>
> Thanks,
> Fernando
>
>
>
>
> On 27/2/20 20:21, Joe Touch wrote:
> > EH isn't a HBH option or extension.
> >
> > Joe
> >
> > On 2020-02-27 15:06, Fernando Gont wrote:
> >
> >> On 27/2/20 19:52, Joe Touch wrote:
> >>> FWIW - there are separable issues here:
> >>>
> >>> - whether an IP header (or parts thereof) should be changed in transit
> >>>
> >>> AFAICT, the answer has always been yes, but limited to the
> >>> hopcount/ttl in the base header and hop-by-hop options in the
> >>> options/extension headers.
> >>>
> >>> - whether an IP header length can change in transit
> >>>
> >>> I see no reason why it can't become smaller, but if it can become
> >>> larger then PMTUD and PLPMTUD don't work.
> >>
> >> Besides AH (which obviously breaks), hosts typically try to validate
> >> that the error messages they receive correspond to something they
> >> actually sent.
> >>
> >> EH removal breaks that.
>
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>