Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Fernando Gont <> Tue, 03 March 2020 22:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE4503A07B8; Tue, 3 Mar 2020 14:59:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6sqzN8qoY2O2; Tue, 3 Mar 2020 14:59:04 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ADC463A078B; Tue, 3 Mar 2020 14:59:03 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1DB6180236; Tue, 3 Mar 2020 23:58:59 +0100 (CET)
To:, Fernando Gont <>, Martin Vigoureux <>, "" <>
Cc: "" <>, "''" <>, draft-ietf-spring-srv6-network-programming <>
References: =?utf-8?q?=3C17421=5F1575566127=5F5DE93B2F=5F17421=5F93=5F1=5F53?= =?utf-8?q?C29892C857584299CBF5D05346208A48D1A3DA=40OPEXCAUBM43=2Ecorporate?= =?utf-8?q?=2Eadroot=2Einfra=2Eftgroup=3E?= <> =?utf-8?q?=3C8259d37e-b460-5f76-1ce6-b0d026bccf6b=40gont=2Ecom=2Ear=3E_=3C2?= =?utf-8?q?0143=5F1583250558=5F5E5E7C7E=5F20143=5F390=5F3=5F53C29892C8575842?= =?utf-8?q?99CBF5D05346208A48DD80E6=40OPEXCAUBM43=2Ecorporate=2Eadroot=2Einf?= =?utf-8?q?ra=2Eftgroup=3E?=
From: Fernando Gont <>
Message-ID: <>
Date: Tue, 3 Mar 2020 19:58:52 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: =?utf-8?q?=3C20143=5F1583250558=5F5E5E7C7E=5F20143=5F390=5F3=5F?= =?utf-8?q?53C29892C857584299CBF5D05346208A48DD80E6=40OPEXCAUBM43=2Ecorporat?= =?utf-8?q?e=2Eadroot=2Einfra=2Eftgroup=3E?=
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
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: Tue, 03 Mar 2020 22:59:13 -0000

On 3/3/20 12:49, wrote:
> Fernando
>> From: spring [] On Behalf Of Fernando Gont
>> Sent: Monday, March 2, 2020 9:23 PM
>> To: Martin Vigoureux;
>> Cc:; ''org'; draft-ietf-spring-srv6-network-programming
>> Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
>> Martin,
>> As an Area Director, what are your thoughts regarding Bruno's claim that
>> this working group (Spring) doesn't have the necessary skills for
>> evaluating the need of a functionality (PSP) that this wg is including
>> in draft-ietf-spring-srv6-network-programming?
>> Specifically, Bruno has noted (in
>> ---- cut here ----
>> Independently of RFC 8200, the question has been raised with regards to
>> the benefit of PSP.
>> My take is that PSP is an optional data plane optimization. Judging its
>> level of usefulness is very hardware and implementation dependent. It
>> may range anywhere from "not needed" to "required for my platform"
>> (deployed if you are network operator, or been sold if you are a
>> vendor), with possible intermediate points along "n% packet processing
>> gain", or "required when combined with a specific other feature". I
>> don't think that the SPRING WG can really evaluate this point (lack of
>> hardware knowledge, lack of detailed information on the hardwares).
>> ---- cut here ----
>> Doesn't this sound a bit like a group is shipping something that it
>> cannot really understand?
> There have been replied and statement from the WG. E.g. From Dan (network operator) & Jingrong (vendor).

The motivation should be in the draft, not in the mail archive. And you 
declared consensus on a document that does not include such motivation.

> My comment is that a statement such as "(1) reduce the load of final destination.", while true in general, is difficult to evaluate, e.g. in term of packet processing gain, or NPU processing resource gain.
> One can say "not on my hardware", but nobody can say "not in your hardware".
> And I think that this is along Joel reply (although I would not want to speak for Joel)
> "Do you have any comments on what appears to be the significant increase
> in complexity on the device performing PSP?  The question I am trying to
> get at is about the tradeoff, which needs one to evaluate both sides."

You have to justify the included behavior, not the other way around:

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492