I'm sorry, but "in my gear I want an option to move some work around, so
I need a protocol behavior for that" is not usually, in and of itself,
enough reason to add an optional feature to a protocol.
At one point there was an argument that PSP was needed for compliant
devices that would not be able to process the packet. It has been
pointed out since that such devices would not comply to 8200 (not
because of PSP, but because being able to ignore an exhausted routing
header is required in 8200). Having an optional feature to take care of
devices which violate a standard again requires some strong evidence to
justify it.
So no, from where I sit I have not seen a clear explanation of the value
for PSP.
I also do not understand why the authors have resisted the usual
solution to this sort of disagreement, namely moving the feature to a
separate document. Given the structure of the network programming
draft, and that it is not exhaustive in either flavors or programming
behaviors, there is no violence done to the draft by removing this flavor.
Yours,
Joel
On 3/3/2020 10:49 AM, [email protected] wrote:
Fernando
From: spring [mailto:[email protected]] On Behalf Of Fernando Gont
Sent: Monday, March 2, 2020 9:23 PM
To: Martin Vigoureux; [email protected]
Cc: [email protected]; '[email protected]'; 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/
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/
So in the end, what we have is the statement "(1) reduce the load of final
destination.".
Thanks,
--Bruno
Thanks,
Fernando
On 2/3/20 15:53, Martin Vigoureux wrote:
WG,
as I had indicated in a previous message I am the one evaluating
consensus for this WG LC.
I have carefully read the discussions on the list. I acknowledge that
disagreements were expressed regarding what a particular piece of text
of RFC 8200 says, and on which this document builds to propose an
optional capability. Since RFC 8200 is not a product of the SPRING WG, I
have paid specific attention to the messages ([1], [2], and [3]) sent by
the responsible AD of 6MAN and of RFC8200.
My overall conclusion is that there is support and rough consensus to
move this document to the next stage.
Bruno will handle the immediate next steps.
Martin
[1]
https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso/
[2]
https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0/
[3]
https://mailarchive.ietf.org/arch/msg/spring/uBYpxPyyBY6bb86Y2iCh3jSIKBc/
Le 2019-12-05 à 18:15, [email protected] a écrit :
Hello SPRING,
This email starts a two weeks Working Group Last Call on
draft-ietf-spring-srv6-network-programming [1].
Please read this document if you haven't read the most recent version,
and send your comments to the SPRING WG list, no later than December 20.
You may copy the 6MAN WG for IPv6 related comment, but consider not
duplicating emails on the 6MAN mailing list for the comments which are
only spring specifics.
If you are raising a point which you expect will be specifically
debated on the mailing list, consider using a specific email/thread
for this point.
This may help avoiding that the thread become specific to this point
and that other points get forgotten (or that the thread get converted
into parallel independent discussions)
Thank you,
Bruno
[1]
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.
This message and its attachments may contain confidential or
privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
Thank you.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
.
--
Fernando Gont
e-mail: [email protected] || [email protected]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
