At Thu, 5 Mar 2020 04:08:28 +0000, "Ketan Talaulikar (ketant)" <ketant=40cisco....@dmarc.ietf.org> wrote:
> If we argue this behavior as not violating "extension headers cannot be > removed from a packet until it has arrived at its ultimate destination" > because "segment left" is 0 at that point (and therefore > S2 is the "final destination"), that's a very innovative interpretation of > the specification (not really surprisingly, given how "innovative" SRv6 > people are:-). In fact, with that kind of logic, we could write a > specification which allows any intermediate node in a routing header > decreases the segment left to 0 (regardless of the previous value of it) at > its own discretion, and then claim it's the final (ultimate) destination and > does whatever is allowed for the final destination node. > > [KT] This is definitely not the argument. Please check this link for the > explanation of the logic : > https://mailarchive.ietf.org/arch/msg/spring/kV6By4pnvbURdU1O7khwPbk_saM/ This link's explanation is that RFC8200 does NOT mean "extension headers cannot be removed from a packet until it has arrived at its ultimate destination" (and therefore PSP doesn't violate it), isn't it? Then please remember the context of this conversation - it started with this comment by Robert: >> Even if RFC8200 section 4 text would say: >> "Extension headers cannot be added to a packet after it has left >> its source node and extension headers cannot be removed from a >> packet until it has arrived at its ultimate destination". >> PSP would be still not be violating anything said in this >> sentence. And I wondered about the logic how "it would *still* be not violate the RFC". So this link's explanation isn't relevant to this specific discussion. As for that link's explanation, I already explained why that interpretation doesn't make sense, probably several times, so I won't repeat it again. I know not everyone agrees with my explanation, and I'm pretty sure no further explanation can change the mind of people who firmly believe this link's argument, so there's no need for repeating the position. I guess that's the same for the rest of your response (sorry for not addressing these one by one but). I knew not everyone would agree/support my arguments and suggestions. From your response, it looks like I already made my points clear enough, you understood them correctly, and still disagreed with those. At this point, I suspect we'll just have to agree to disagree than wasting everyone's time to keep making essentially the same points again and again. I guess the only feasible next move of mine is to bring my points to whatever next round of the process (another WGLC or IETF LC). -- JINMEI, Tatuya _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
