Hello, Bruno,
On 2/3/20 10:19, bruno.decra...@orange.com wrote:
[....]
===============
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?
The PSP has two non-compliant behaviors:
1) EH removal:
In order to claim that IPv6 supports en-route EH insertion/removal, it
should address the issues that would introduce with:
* pmtud
* ipsec ah
* error reporting
And it doesn't. i.e., not only it was never the intent for ipv6 to
support eh insertion/removal, but also clearly couldn't do it without
addressing these three issues.
[...]
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?
My point is that, as part of declaring consensus on the network
programming draft, you based such decision (dismissing the non-compliant
behavior of PSP) on a fact that had not taken place. That doesn't seem
correct.
[...]
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.
My bad -- I didn't remember the sheperd's write-up had such question.
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.
Agreed.
[...]
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.
How can a working group ship a document it cannot evaluate?
If you're saying that the wg doesn't have the skills to evaluate a
document it is shipping, what's the value in your statement that this
document has wg consensus?
Seriously.... it is the wg shipping the document, not a vendor (at least
formally speaking).
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.
This is *terrible* reasoning. Really. To an extent that I'm even
surprised that you're saying it.
Several folks have raised questions on the need for PSP, which the
authors *failed* to respond or address.
If you want to ship a document, you should at least be able to make a
case for it.
===============
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.
Weren't you the one declaring consensus on this document? Weren't you
the one preparing the shepherd's write up?
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.
I'll repeat: conflict of interest refers to a situation where you're
"judge" and "part" at the same time. It doesn't argue that you have or
will be intentionally benefiting from such position.
Normally, such situations are avoided, because probing one thing or
another is, unfortunately, materially impossible,
So that's what my clarification was about. I would have made the same
comment if someone had flagged the same situation for any other
document, and a co-author/contributor was shepherding the document or
calling consensus.
As noted, I disagree with your declaring of consensus to move this
document forward. But I provided a rationale for my disagreement, and
never linked the outcome of the consensus call to the aforementioned
conflict of interest.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
