Hi Jinmei, allow me to address the two technical concerns you raise in this email, upon which it appears this interpretation of RFC8200 hinges for you. You state: > > 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
I know a lot of documentation and work has been done with SPRING and 6man since that debate. 1 - I expect everyone reviewing and commenting on draft-ietf-spring-srv6-network-programming (NETPGM) to have fully read draft-ietf-6man-segment-routing-header (SRH) as stated in section 1 NETPGM. 1.1 - remember SRH section 5 defines a deployment model for the SR domain applicable to both documents. 2 - AH is not defined for SRH (section 7.5 of SRH) so the question of how SRH with a PSP SID affects AH is not applicable to NETPGM. 3 - PMTUD within an SR domain is unaffected by PSP. 3.1 - Section 5.3 of SRH, provides recommendation on how MTU is handled within an SR Domain for traffic encapsulated for its journey within the SR domain. i.e. it is not reliant on PMTUD within the SR Domain. 3.2 - Regardless, as others have stated, performing PSP and reducing the size of a packet has no impact on PMTUD. I hope this helps clarify your understanding of the current state of the art vs what may have been assumed at some point in the past before this was clarified by 6man and SPRING. Thanks Darren > On Feb 27, 2020, at 3:11 PM, 神明達哉 <jin...@wide.ad.jp> wrote: > > 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 > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
