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

[Fernando Gont <[e-mail]>]

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. 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: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1