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

[[e-mail]]

Fernando,

> -----Original Message-----
> From: Fernando Gont [mailto:[e-mail]] 
> Sent: Friday, February 28, 2020 8:28 PM
> To: DECRAENE Bruno TGI/OLN; 'SPRING WG List'
> Cc: draft-ietf-spring-srv6-network-programming; rtg-ads
> Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
> 
> Bruno,
> 
> On 28/2/20 13:53, [e-mail] wrote:
> > Hello SPRING WG,
> > 
> > Please find below some status on the main points of this WG LC.
> > 
> > ===============
> > 
> > A) PSP [1] & RFC 8200 [2]
> > 
> > ===============
> > 
> > This point is whether SRH removal by the penultimate SR end point (aka 
> > PSP) is allowed by RFC 8200.
> > 
> > More specifically
> > 
> > " S14.4.Remove the SRH from the IPv6 extension header chain"
> > 
> > Vs
> > 
> > "Extension headers (except for the Hop-by-Hop Options header) are not
> > processed, inserted, or deleted by any node along a packet's delivery
> > path, until the packet reaches the node (or each of the set of nodes,
> > in the case of multicast) identified in the Destination Address field
> > of the IPv6 header."
> > 
> > On this text, what is been discussed is "the node (or each of the set of 
> > nodes,
> > 
> > in the case of multicast) identified in the Destination Address field
> > 
> > of the IPv6 header."
> > 
> > More specifically whether "Destination Address field of the IPv6 header" 
> > means the "final Destination Address" or the "Destination Address" as 
> > seen in the packet that the node received.
> 
> If it meant "Destination Address", that would mean multicast addresses, 
> would be allowed in routing headers.

I don't think so. 
I'll try to reorganize the sentence to try to highlight the point:

until the packet reaches the node identified in the Destination Address field of the IPv6 header.
(or each of the set of nodes [identified by that Destination Address] ,in the case of multicast)

In the case that we are discussing, there is one single node, identified by the Destination Address. This is not multicast.

> Do you think htat's the case?
>
> 
> 
> [...]
> > Finally, the responsible AD has not accepted the related errata. 
> > https://mailarchive.ietf.org/arch/msg/ipv6/yVKxBF3VnJQkIRuM8lgWN4_G3-o/
> 
> The status of this erratum is found here: 
> https://www.rfc-editor.org/errata/eid5933   -- not on the mailing-list 
> archive. And the erratum is marked as "reported", not as "rejected".
> 
> Suresh may well go ahead and reject it. BUt so far the status has not 
> changed since I've reported it.

The email from Suresh seems crystal clear, including to you given your reaction. Even after you said you would appeal, Suresh said that he were standing by his decision. 
" > As such, I will formally Appeal your decision.
Please do go ahead. I stand by my assessment that this is a misuse of the Errata process and it is not a simple clarification as you claim."


Also, I have never sent that the errata was rejected. Please don't put words in my mouth. I said "not accepted".

Finally, the errata status has now change. So what's you point, now?

> 
> 
> > Based on this, the plan is to flag this point of debate in the shepherd 
> > report, and leave this for the IESG to decide on how to read RFC 8200 
> > (which represented 6MAN consensus and which the IESG approved). The 
> > threat to appeal will also be explicitly indicated (shepherd write up, 
> > point 10).
> 
> I have *noted* a number of times that I would appeal (so *please* do 
> note that a number of people felt that the specs were being violated 
> *and* that our processes were being circumvented).
> 
> But I've never *threatened* to appeal.
> 
> A quick lookup in a dictionary says:
> "threat"
> 
> noun
> 1.
> a statement of an intention to inflict pain, injury, damage, or other 
> hostile action on someone in retribution for something done or not done.
> 2.
> a person or thing likely to cause damage or danger.
> 
> 
> Clearly, there was no "threat". I did indicate that one of our specs was 
> being violated, and that our processes were being circumvented (in the 
> same way that I'm quite curious how you can claim consensus on this 
> document, but.. ).  That says, appeals are part of our processes.
> 
> I have no idea whatsoever how, sticking to our processes could be 
> considered a threat.

I used the wording from the official shepherd write up.
" (10) Has anyone threatened an appeal"
https://www.ietf.org/chairs/document-writeups/document-writeup-working-group-documents/

I you have an issue with this term, please raise it to the IESG.

I fully agree that appeal is part of the process (so does errata). I would go further that IMHO this is definitely a required part of the process.
Making an appeal is your right. I don't want discourage or encourage you do use it in any way.


> Quite the contrary, the intention is for our existing specs and 
> procedures to be respected. If *that* is considered a threat, that's a 
> different question.
> 
> 
> > 
> > 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). 
> 
> Am I reading correctly? Are you kind of stating that the same working 
> group that is shipoing this document doesn't have enough of a clue to 
> analyze the benefits (or lack thereof) of PSP?
> 
> And, because of that, you make the assessment yourself?
 
On the mailing list, multiple persons stated that it was implemented in their implementation or useful for their deployment.
I'm saying that the performance gain cannot be evaluated by the working group.
>From a logical standpoint, to prove that this is useful, it's enough to have one implementation/deployment case to benefit from it. This has been stated on the mailing list.
To prove that this is not useful, one need to prove that this is not useful some any one/any case. This is much harder. No one has even tried to make that demonstration.


> 
> 
> > ===============
> > 
> > I'm listed as a contributor on this document (among 23 contributors).
> > 
> > Even though I have zero specific write/modification privilege on the 
> > text in this document, and I'm not part of the authors email alias, this 
> > would not be ideal for me to take the decision to forward this document 
> > to the IESG. I've discussed this with our AD (Martin) and he agreed to 
> > make the formal decision to send the document to the next level. Thank 
> > you Martin.
> 
> Indeed, this could be seen as a possible conflict of interests.

That's why both myself and Martin have stated that the decision would be taken my Martin.

That been said, "conflict of interest" is about "interest". I'm not working for a vendor who may have an interest to push, or delay or stop a work based on it's hardware and software capability. I'm not working for an operator who is deploying it.
My only interest would be to be listed as an contributor on a document. Really? I'm fine with been removed from the list of contributors. I have not proposed that because doing so would be borderline with regards to IPR declaration, and could be seen an trying to hide this. Trying very hard to see a remote conflict of interest, it would be to slow down SRv6 to avoid the competitors of my employer to use it. So quite the opposite direction.

--Bruno
 
> Thanks,
> -- 
> Fernando Gont
> e-mail: [e-mail] || [e-mail]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



_________________________________________________________________________________________________________________________

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.