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: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379833A0B36 for <ipv6@ietfa.amsl.com>; Wed, 26 Feb 2020 08:38:14 -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=unavailable 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 tMmjXUJEzAVb for <ipv6@ietfa.amsl.com>; Wed, 26 Feb 2020 08:38:11 -0800 (PST)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 C2AAB3A0B55 for <ipv6@ietf.org>; Wed, 26 Feb 2020 08:38:10 -0800 (PST)
Received: by mail-ed1-x536.google.com with SMTP id m13so4555701edb.6 for <ipv6@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=Wv6NxN1DFE5DlbroAZ2mnAdDX5MKnDAgR9LXSshJmF37X9zfY0fi83UhqNlNwzs8xp 1sr4bQxRAmREKBglRSgR0VUT9UOhW+wXlIDLcftKfjcxSeORDhhEmkxtP2niv5PMacTk FAiLmx4VOkC1xNFfSKQ3+8fUlwEakDb1myHCR7HpjIwLx6+jPkru6OM8NZID4VzBDyks mqOXdJwCsgvq1i4CiT1NLPv9yKH+1C20plALtSGF2z3o73wkQYP+JOVKBKEaliDfzcYC TVLEqZkpgNHiE50QkbNL2WupxK7kFbzvNyQOSdbBJ2IoShf20iKKKzzufwFTnPaR1Nb3 440A==
X-Gm-Message-State: APjAAAXTSLpmLRmMkKNRXBc9a58FXhLffV3O1r2lu92Z7RPQVaxsmL+W z7mBZ+hlLRzlfRjxcUO3WYVPVrInnAZalTqjX3hIHG6c
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>
Subject: Re: [spring] Is srv6 PSP a good idea
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/ipv6/qh9o6Nl5Uhevouy30YTVaj939Qg>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2020 16:38:14 -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
> --------------------------------------------------------------------
>