Re: [spring] Is srv6 PSP a good idea

Tom Herbert <tom@herbertland.com> Wed, 26 February 2020 16:38 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 270343A0B45 for <spring@ietfa.amsl.com>; Wed, 26 Feb 2020 08:38:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 S5biZoPW6p37 for <spring@ietfa.amsl.com>; Wed, 26 Feb 2020 08:38:11 -0800 (PST)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 C2A153A0B4D for <spring@ietf.org>; Wed, 26 Feb 2020 08:38:10 -0800 (PST)
Received: by mail-ed1-x529.google.com with SMTP id p3so4539862edx.7 for <spring@ietf.org>; Wed, 26 Feb 2020 08:38:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1ZzYO49YfNLJcMnhMk3aXmtnC5mMGTBmduC6QOw7Co4=; b=FIzFn8VHHWbG83+CGC/YVAob9Ya0OFbr0ZquXIS9es8KHbEFbXQ+v3C3gt4VIa4sE7 tEdPTy7q963bNGZPbdHcq4EhG6tMtG6kF9sgS63jZFZ+CxSN/ihGPXt3HG3xXRF254e/ pUaelm3A3CnhtozqrBHEm8j47Gf44LvdD+vjllkPpUqQJlnDU29LEuJu9EmUnMfyi4Vd p5D15uHQ10P+lugXm05eDF5TVXvwTumNsbOecPBlwuxK26x+74bixPgRA8J+Jk5LZWCD I6eYYMU/PvHPjpTkkW7Kitr7uv/GG1FGSPwH2HmzLX0yDKicHjryc5nL5TV3LZVU4wtI vO0w==
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=1ZzYO49YfNLJcMnhMk3aXmtnC5mMGTBmduC6QOw7Co4=; b=cwQ9SMfl0ZaRTgquEYVockVr/AbPNIB00x29v46GGO2FxAB3b/RQg5zi9l2FW0fIOL zCp/4ExJJ/Y9J8Pd8hj1zC3JWvT90NWTxLVLYBXfEL6gJRlIPcM+LDBtRVz97uuJJ0EK DLOVcUdKaz89737wMlJCdpBJvoPV1foqT6Asx2TM64yfFkHz5dnkVS6SaUII33Hx/E5i 8TX0/DwteuQxh8SkAq1Zl9g278wae/PMSAORH1xolxOdod6fo2ZsdoHqmOJX/B8IJ4IQ El9HGHCTDMkkC9dHMt0VGMOUkTWkXXLguGoKoNUfJTXOzaZV9YyXGcdh50LtyoA3r7N+ ZjdQ==
X-Gm-Message-State: APjAAAXLgxoqhUL1TxRlSDKHcs2tA4I/QGKD7rZrcZutJfhQyhhgnBTo eVTz5iGGYJB/t9yuvCeLblNAja5KCtVbrRKRudG2kg==
X-Google-Smtp-Source: APXvYqzaV0kOWh7hLNQ5sa7Cd/g17R/8SUlatF9zIAlnUlAv42dwwPj7QihCoJz+pTXfIJ4e8TSOl9C3TPdZ707Qor0=
X-Received: by 2002:aa7:d9c2:: with SMTP id v2mr179248eds.88.1582735088961; Wed, 26 Feb 2020 08:38:08 -0800 (PST)
MIME-Version: 1.0
References: <5c2a4b36-0c59-709e-23eb-00f4aa1ce52f@joelhalpern.com> <9B89F4C2-5594-4D31-8893-21F3F4A0DF6C@cisco.com> <BN7PR05MB569969EE8D1929E7069E1BB0AE550@BN7PR05MB5699.namprd05.prod.outlook.com> <58ED78D3-9E0C-4556-8853-8754B361DF6D@cisco.com> <BN7PR05MB5699D79B1FC40662EE9E95B6AE500@BN7PR05MB5699.namprd05.prod.outlook.com> <81A30B25-9857-467E-85AE-1FE84B6F3197@cisco.com> <CAO42Z2zq0chKx08d10JBNkpa5e8J4MWAJWk+2Qs1DD7y_wkYUw@mail.gmail.com> <05981e2ea71c4b3083ed6e15c7e20641@huawei.com> <CAO42Z2wzk7W4_gy6j+sW=1z+xoyMMxsjnUbZkaf=jcG0zZqddg@mail.gmail.com> <CAOj+MMHE7XaWKSy=y5-0kz5aOT9vWgMCRmc=WURX12-LX1TOzg@mail.gmail.com> <7B51F0BE-CE40-42B8-9D87-0B764B6E00C5@steffann.nl> <DBBPR03MB541529B1A1859DC25E324E13EEEA0@DBBPR03MB5415.eurprd03.prod.outlook.com> <DBBPR03MB5415C910A5FE36C9769BB8B4EEEA0@DBBPR03MB5415.eurprd03.prod.outlook.com>
In-Reply-To: <DBBPR03MB5415C910A5FE36C9769BB8B4EEEA0@DBBPR03MB5415.eurprd03.prod.outlook.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 26 Feb 2020 08:37:58 -0800
Message-ID: <CALx6S354RBr9vS=LggDNmx7aeS=PsEeXjrxn086Jcb+0Tu8ftQ@mail.gmail.com>
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Cc: Sander Steffann <sander@steffann.nl>, Robert Raszuk <robert@raszuk.net>, "spring@ietf.org" <spring@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c061cb059f7d3a5b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/eIzKpQO3XqwXTDXEP-DStPoTSpM>
Subject: Re: [spring] Is srv6 PSP a good idea
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2020 16:38:13 -0000

On Wed, Feb 26, 2020, 6:26 AM Andrew Alston <Andrew.Alston@liquidtelecom.com>
wrote:

> Figured I’d add to this – as I continued to read the charter
>
>
>
> *SPRING WG should avoid modification to existing data planes that would*
>
>
>
>
>
>
>
>
> * make them incompatible with existing deployments. Where possible,
> existing control and management plane protocols must be used within
> existing architectures to implement the SPRING function. Any modification
> of -or extension to- existing architectures, data planes, or control or
> management plane protocols should be carried out in the WGs responsible for
> the architecture, data plane, or control or management plane protocol being
> modified and in coordination with the SPRING WG, but may be done in SPRING
> WG after agreement with all the relevant WG chairs and responsible Area
> Directors.*
>
>
>
> If SRv6 is not IPv6 – as is the contention – (which in my view is an
> absolutely false contention
>

+1

> designed to step around a specification because it simply doesn’t suite
> what you want) - well – then what exactly are we doing here – because by
> that claim – we are inventing a new control plane, a new data plane, and
> well, it’s a new protocol – so – do we have the agreement of the relevant
> WG chairs, Area Directors etc – to invent an entirely new everything.
>

That's already happened. SRH has reinvented both protocol options, TLVs, in
the network layer, as well as header authentication.

Tom

>
>
> Didn’t think so….
>
>
>
> Andrew
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>