Bruno,
On 28/2/20 13:53, bruno.decra...@orange.com 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. 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.
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.
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?
===============
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.
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
