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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/3/20 12:49, bruno.decraene@xxxxxxxxxx wrote:
Fernando

From: spring [mailto:spring-bounces@xxxxxxxx] On Behalf Of Fernando Gont
Sent: Monday, March 2, 2020 9:23 PM
To: Martin Vigoureux; spring@xxxxxxxx
Cc: 6man@xxxxxxxx; 'ietf@xxxxxxxx'; 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: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux