On Wed, Feb 26, 2020 at 11:39 AM <jin...@wide.ad.jp> wrote: > > So... is the plan to ship a document that violates RFC8200? > > Please forgive me asking some clarification question that seems to be > obvious for others: which part of > draft-ietf-spring-srv6-network-programming-10 violates RFC8200? From > a quick read of it, Section 4.16 seems to describe the removal of an > extension header from an IPv6 packet at a forwarding node. Is that > the one referenced as a violation? Or is it something else, or are > there others in addition to 4.16?
I've not seen any feedback, but according to the thread messages since then, it's now pretty clear to me that it's at least about Section 4.16 (or more specifically, 4.16.1, which describes "PSP"). In that case, I have to oppose moving this doc forward in its current form. First, as (I believe) Brian also pointed out, the description of this section is obscure. And, in fact, it wasn't immediately clear to me whether it's a violation of RFC8200 (hence the question). Secondly, with more accurate understanding of the intent of this section through the discussion of this thread, it's now clearer to me that it's a violation of the following part of RFC8200: 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. in that an intermediate node specified in a routing header with segment left > 0 deletes an extension header. So at least this document has to clearly declare updating RFC8200 and get consensus about it before moving on. It's not done yet. Hence my objection. It's surprising to me that some people seem to (still) argue it's not a violation because this node "is identified in the Destination Address field of the IPv6 header" (before swapping it with the next hop specified in the routing header). Aside from that this interpretation logically doesn't make sense as it's not compatible with AH or PMTUD, if it could be justified with that logic, we wouldn't have had to go through the long debate in promoting RFC2460 to RFC8200 in the first place. The conclusion at that time (I wouldn't call it a "consensus" as I know not everyone was happy about it) was that - Such kind of insertion and deletion is indeed a violation of RFC2460; that's why RFC8200 now clearly says "inserted, or deleted" while RFC2460 only states "examined or processed". - 6man and SPRING WGs will work together to see if we can define an exception to loosen the limitation so that a future version of SRv6 can validly coexist the base IPv6 standard. Until then, encapsulation/decapsulation is the only standard-compliant behavior. Now, beyond these technical points, I also have meta-level concerns. Here I share the frustration of Fernando, even if his word may be too blunt. After the hot debate on revising RFC2460, I expected us to "work together" towards the goal of seeking some middleground. Admittedly, this process wouldn't be easy - some people who opposed to the insertion/deletion at that time seem to believe there's no such middleground anyway. But some others seem more flexible, and, as far as I can see, at least everyone is open to have discussions. But, after nearly 3 years since the publication of RFC8200, we still seem to have the same easy circumvention: - Simply dismissing the concern by arguing this is not a violation - Labeling those who raise concerns as innovation blockers - Just blaming the IPv6 base protocol as being broken (because it doesn't accommodate a feature they want) - Insisting SRv6 just happens to use IPv6 packet format and some part of spec but is not IPv6, indicating it doesn't matter whether it violates the IPv6 standard - Pushing industry agenda instead of working together to reach consensus I'm sad, but if this doesn't change, the only thing I, as a poor individual, can make objections to last calls. At least in the purely technical sense, I've not seen any difference now and then. So, the history would suggest even if we blindly pass this WGLC we'll have a very long debate at the IETF last call and just reach the same conclusion. That would be a waste of time for everyone. I hope we can be more cooperative instead of that. -- JINMEI, Tatuya _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
