Re: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt

Andrew Alston <> Fri, 20 November 2020 08:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C6F63A13CD for <>; Fri, 20 Nov 2020 00:50:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2RGlpQvTI6Ue for <>; Fri, 20 Nov 2020 00:50:04 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 320E73A1187 for <>; Fri, 20 Nov 2020 00:50:03 -0800 (PST)
Received: from ( []) (Using TLS) by with ESMTP id uk-mta-275-jTNFOEsENzKWnqZ04oWM9g-1; Fri, 20 Nov 2020 08:48:23 +0000
X-MC-Unique: jTNFOEsENzKWnqZ04oWM9g-1
Received: from (2603:10a6:803:bf::31) by (2603:10a6:800:27::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.28; Fri, 20 Nov 2020 08:48:20 +0000
Received: from ([fe80::fd6d:5942:84f5:3812]) by ([fe80::fd6d:5942:84f5:3812%3]) with mapi id 15.20.3589.022; Fri, 20 Nov 2020 08:48:19 +0000
From: Andrew Alston <>
To: Stefano Salsano <>, =?utf-8?B?56iL5Lyf5by6?= <>, spring <>
CC: srcomp <>, "spring-chairs@ietf.o" <>
Thread-Topic: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt
Thread-Index: AQHWu2PuFICPFR6pS021bMx5A3Wn6KnQf8+AgAA7TzA=
Date: Fri, 20 Nov 2020 08:48:19 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
x-originating-ip: [2c0f:fe40:3:1:f8be:7f98:1be6:db6]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 619197b7-4399-49d3-9981-08d88d3107e3
x-ms-traffictypediagnostic: VI1PR0301MB2253:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0
x-microsoft-antispam-message-info: XOuACTtvTmOl/N/cm7fky34xkZwrm/Q1qbU0140FRKXrA+W7R9XK5/JWmbkkz6ZHEtrYV5ge7wbhlLHzx4s/s/wO/a9qCduiqpGwwqvQ6szWigJowmxs0hNjtl2nOtgxotkjMbVDKuxtBkhaM/Qczsbf91PbgLj0s61GhQ9dSnaOLesBSENTFzYInpd6fy6B8l+TEfLAFQ+boeBk/hbGednIoAC/akd9222qwKpC/z0jbosIBtCu2ny3jEk3JOWc4bOZ2xnl5LHIwbE9CfdTD96XBNlpsl1sf12JZqx3UZCTAE5yEoLxS8WDlpG8mCE1LM6t6OgK2PqYer2XwZgLSqWvnTu9aCwXM1yCqRS0zD2/N+tQ9Aaz+klN9R4XlBTcYDYYqFQuVhGpGoGp3kR1xA==
x-forefront-antispam-report: CIP:; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM;; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(366004)(136003)(346002)(39860400002)(15650500001)(7696005)(52536014)(86362001)(9686003)(8676002)(55016002)(5660300002)(166002)(83380400001)(33656002)(4326008)(966005)(186003)(478600001)(6506007)(8936002)(53546011)(2906002)(316002)(76116006)(4001150100001)(66946007)(66556008)(64756008)(66476007)(66446008)(110136005)(54906003)(71200400001); DIR:OUT; SFP:1102
x-ms-exchange-antispam-messagedata: y8QdKc7SbaaEF+KmqQV3NzKEjntcUX3hJDFKjsdgDwGDyhfGutEKTwYM63Tx4T2CB/HbSog9tSAVeo9QNqowBSjFWjyIjo9s2bwsouCSjaGfvmkAxFtSkxSKFaic2ntQer3yxSQcNv/gK8DgI8xt160WLb5cRu70TwkvgWimrtYRjwumdaqHGpd0wjXoBrldbb0BS2+fWHAXQc2GXYgcf3EmkDXawnEBquo25yUKGPaSh9Z6g8v+dl6wi9x3K0dTEVjML3EfvD8sVjWyyraqHuvIn2emjGo655Aqn2618H6CX4SNUMPSFOZyZ76ZbUSA2QrVTsgdYLp6dosdpo0CFzhk1okA2Jw+HsWj83KkxjYdzNDZ0xAn93QJhfQ7EMW/fEaAU4ukei8dAH3pOOZddzmbaiJPANgfSY58PUWf0HuSO8omnatLcZaoImYfPVcLI/MAg5Z98LYu8SzAvr9bou04aVa0IS7HA4R0UarF9t9ta9KeNGxuUh62OEU2gWJU5DRF400ugEVkXs4mT1BZHVG8wjT92YcCKn84wuQRTlmMhIphVEVyNqmUPqE5J48ccejK7Uq+NIcbK77TaNZOgvZQCgfYX3PHoneI3jbUTwcPlBa0mMqAI2d3SnG0UoSeWMje9yj13qFtzckMZqbBiMzUedJ4nQk69wFCqqi/In0ifRojf97WJQEwHMq+nZj7C3U4x1HeDeCOc+1ixjJBrQpd9mLcP2m+vK21tETodwmqmiArfcIwtZA+VFS77OKVSmMLAwJMBB5ol2wdk+szO6r0CXR9Vpb2wiO6JV78cKbT8DEZKjN32F52kB88z5B5DyeKMgtaHuOqmSX9p1Llnr28txhRkI4NxLa/Ow47H18rn0SoWMdqpZI8RWm7wNE/6Udck1XTNQXeqLmuVoEYpQPiazljYxX4cc+/NrUT3+PLBArKk6nofx1gus2okHc9
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-Network-Message-Id: 619197b7-4399-49d3-9981-08d88d3107e3
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2020 08:48:19.7525 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: GfOT/LgmGP+o11R0oGCeFC1shAOqJtCSPN9mvl8lW3rJqbI3+gpHKbwk/5wzlvNNpXAF63cVVk2ajwDkJI5kTnLIbpszDWdkiF8uEU0eQJI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0301MB2253
Authentication-Results:; auth=pass smtp.auth=C82A168
X-Mimecast-Spam-Score: 0
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_VI1PR03MB5056F05B67207E094D0DD14DEEFF0VI1PR03MB5056eurp_"
Archived-At: <>
Subject: Re: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Nov 2020 08:50:06 -0000

From: spring <> On Behalf Of Stefano Salsano
Sent: Friday, 20 November 2020 08:09
To: 程伟强 <>om>; spring <>
Cc: srcomp <>rg>; spring-chairs@ietf.o <>
Subject: Re: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt

Il 2020-11-15 16:27, 程伟强 ha scritto:
> Hi Group,
> SR compression design team have submitted a new version of compression
> requirement draft.
> Main changes as follows:
> - added 3 items about scalibility with agreement within the design team
> - added an appendix including 3 items without without unanimous
> consensus within the design team

Hi all,

the the appendix A of latest draft version includes three items that
should be taken into consideration, in particular:

Requirement A.2.1. SRv6 Based
Requirement A.2.2. SRv6 Functionality

"A solution to compress SRv6 SID Lists SHOULD be based on the SRv6
architecture, control plane and data plane" and "A solution to compress
an SRv6 SID list MUST support the functionality of SRv6"

I've been working in the last 4 years on the open source ecosystem
supporting SRv6, including the support of SRv6 in the Linux kernel

a lot of effort has been spent in this ecosystem that now offers a
feature set comparable to vendors' implementation of SRv6

it is very important for the research community to have such ecosystem
and it will be painful to rebuild the support for a new solution outside
of the current SRv6 architecture... one of the problem of the MPLS
architecture (from the research comunity point of wiew) was that the
support in Linux has never been comparable to vendors's solution (e.g.
for the control plane), for this reason the research work diverged a lot
from production solutions, I really would like to avoid such gap again

My issue with this is that there are operators – who have requirements today – that encompass a solution that has already shipped – requirements that are built on something entirely outside of the SRH – and I fail to see why such a solution should not be catered for – or alternatively – should not be considered entirely outside of the scope of spring (which would be just fine by me) so that the work can proceed within the context of the IETF – rather than forcing it outside of the IETF because of stalling and this view that some how there can only be one solution to every problem.  By the time we get anything done here, we will be 10 months into this – and I point out that in the meeting I stated 6 months and it was disputed.  The design team was first muted in May – it took 2 months to get going – but this has actually been 6 months, and now we are looking at another 4 months before we meet again.

This is on top of the stalling that has taken place since IETF 106 on moving forward on anything that the srv6 pundits seem to view as some kinda competition to them.  This is having very real world consequences for certain operators – and I can also state flatly, this is beginning to impact on my decisions as regards to vendor purchasing – and that is also the message I will be taking to the operators I work with – that there are competing solutions to certain very specific problems – one of those solutions is shipping in code today – it was developed outside of IETF adoption because there was no alternative to that – we hope one day to get the IETF to be willing to work on this to refine it and take it forward – but until then – if you want it – this is what you are going to have to buy.