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

[Fernando Gont <[e-mail]>]

On 3/3/20 12:49, [e-mail] wrote:
> Fernando
> 
>> From: spring [mailto:[e-mail]] On Behalf Of Fernando Gont
>> Sent: Monday, March 2, 2020 9:23 PM
>> To: Martin Vigoureux; [e-mail]
>> Cc: [e-mail]; '[e-mail]'; 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
>> https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/):
>>
>> ---- 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).
> https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/

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."
> https://mailarchive.ietf.org/arch/msg/spring/CMSX7ijacRdG8qHlla61ylJNggo/

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

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492