Jinmei,
My apologies. I was writing my message as you posted yours.
I agree fully with both the spirit and letter of your message.
Ron
Juniper Business Use Only
-----Original Message-----
From: 神明達哉 <jin...@wide.ad.jp>
Sent: Thursday, February 27, 2020 5:18 PM
To: Ron Bonica <rbon...@juniper.net>
Cc: Fernando Gont <ferna...@gont.com.ar>; SPRING WG List <spring@ietf.org>;
6...@ietf.org; draft-ietf-spring-srv6-network-programming
<draft-ietf-spring-srv6-network-programm...@ietf.org>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC -
draft-ietf-spring-srv6-network-programming
At Thu, 27 Feb 2020 21:29:24 +0000,
Ron Bonica <rbonica=40juniper....@dmarc.ietf.org> wrote:
> The question is whether PSP violates the following clause from Section 4 of
> RFC 8200:
>
> "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."
>
> A literal reading of this text suggest that any segment endpoint (i.e., any
> node referenced in the Routing Header) can process, insert, or delete any
> extension header. This is because when a packet arrives at a segment
> endpoint, one of its addresses appears in the IPv6 Destination Address field.
Please see my response to my own message. Yes, purely "literally", it could
read that way (it's amazing human-written text can be always ambiguous to some
extent, no matter how hard we try to clarify it), but that doesn't make sense
if we recall a larger context. If the phrase "Destination Address field of the
IPv6 header" could justify the deletion (or even insertion, for that matter) of
an EH at a node like that, then changing this text in RFC2460
With one exception, extension headers are not examined or processed
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.
to the above one in RFC8200 shouldn't have caused the painful debate regarding
the implication of SRv6. We should have known this change would make the
SRv6-style insertion/deletion a violation of the RFC even more clearly than
RFC2460 at that time, and that's why we needed that discussion.
And that's why I'm surprised at seeing this argument now. Perhaps those making
this just because they forgot the previous discussion or simply weren't
involved in it. But combining this point and other signals that indicate the
reluctance to take on the tedious reconciliation between RFC8200 and this spec
(which would be most likely to require an update to the RFC), it wouldn't be
unreasonable if one suspects it may be an attempt of easily circumventing the
process rather than a genuine misunderstanding of the text. I guess this
suspicion is somewhat commonly shared by those raising concerns (including
myself).
--
JINMEI, Tatuya
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
