> If we argue this behavior as not violating "extension headers cannot be > removed from a packet until it has arrived at its ultimate destination"
That is not, perhaps unfortunately, what RFC 8200 says. Regards Brian Carpenter On 05-Mar-20 17:08, Ketan Talaulikar (ketant) wrote: > Hi Jinmei, > > > > Please check inline below. > > > > -----Original Message----- > From: ipv6 <ipv6-boun...@ietf.org> On Behalf Of ???? > Sent: 05 March 2020 05:15 > To: Pablo Camarillo (pcamaril) <pcamaril=40cisco....@dmarc.ietf.org> > Cc: spring@ietf.org; 6...@ietf.org; Bob Hinden <bob.hin...@gmail.com>; Robert > Raszuk <rob...@raszuk.net> > Subject: Re: [spring] Suggest some text //RE: Request to close the LC and > move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming > > > > At Wed, 4 Mar 2020 12:17:07 +0000, > > "Pablo Camarillo (pcamaril)" <pcamaril=40cisco....@dmarc.ietf.org > <mailto:pcamaril=40cisco....@dmarc.ietf.org>> wrote: > > > >> Inline PC1. > > > > Thank you for the clarification. I'm not sure why you included the expanded > processing logic instead of just saying correct or incorrect > > here: > > */[KT] I believe Pablo might have done this as a hint on how to look at the > processing logic of the PSP flavor in the conjunction with the SID behavior > pseudocode./* > > > >> PC1: > >> > >> This is the exact processing at S2 combined End (4.1) with PSP (4.16.1): > > > > ....but I interpret the entire response as my understanding is correct. > > > > Then, going back to the message from Robert: > > > >>>> "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. > >>> Reason being is that we are dealing here with an *encapsulated* > >>> packet which has as its ultimate destination SR node X. That SR node > >>> X is to perform or not PSP. So it is still fully compliant with the >>> specification. > > > > This explanation is still cryptic to me, but based on the > now-hopefully-correct understanding of the PSP behavior, > > - We originally have (T, S1) (S3, S2, S1; SL=2) [payload=encapsulated > > IPv6 pakcet] > > There are 3 nodes in the routing header. > > - At the node identified by S2 (second node in the routing header), we > > remove the routing header, so we have (T, S3) [payload=encapsulated > > IPv6 pakcet] > > - Packet arrives at the node identified by S3, the payload is processed > > */[KT] This is correct at a high level. The last line is about processing per > the behaviour of the SID S3 – e.g. when it is End.DT6 it would be to decap, > perform lookup in the VRF associated with the SID and then forward the inner > IPv6 packet./* > > > > 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/ > > > > Overall, it seems so artificial, if not cheating, only for avoiding to be > told that it violates RFC8200. The PSP behavior essentially gives an > intermediate ("penultimate") node in the routing header an option to remove > the routing header from the packet. I can't think of a reason why we can't > just say so and say that it updates the corresponding part of RFC8200 > accordingly, than for cheaply avoiding the discussions involved in updates to > an existing standard. > > */[KT] Nothing artificial and no cheating. Things are clear as indicated in > the previous link. At least that is what the authors and (in my reading) a > significant number of other Spring WG members are saying. Please also check > the following:/* > > https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/ > > https://mailarchive.ietf.org/arch/msg/spring/CmT-8nSZs8O8i9N9dD8gHd6uHAo/ > */(and the links provided by Martin on his previous email on that same > thread)/* > > > > Now, I've noticed an argument whether or not this spec violates/updates > RFC8200 isn't important. In a sense I see the point: > > what matters is to discuss the effect of the proposed behavior and make sure > it doesn't cause unexpected problems; whether it updates the pre-exiting spec > is a matter of formality in some sense. But in this specific case, I still > believe that's a bad move for two reasons: > > */[KT] I see a significant amount of discussion on the WG to discuss and > conclude that there are no technical problems. In that same spirit, let us > also look at your “reasons”./* > > > > 1. (seemingly) as a result of trying to insist it's standard > > compliant, the processing logic becomes unnecessarily cryptic. > > There's essentially no need to decrease 'segment left' and then > > check if it is 0. A more explicit condition that it's the > > penultimate node is that 'segment left == 1' on receiving the > > packet; we can simply perform the special PSP behavior from there. > > If we're willing to say it updates RFC8200, we can simply say the > > penultimate node has an option to remove the routing header and > > show the more straightforward logic. > > */[KT] There is no technical problem being stated here. The logic is not > cryptic – please consider the hint from Pablo above i.e. to look at the > processing as whole. If the pseudocode is complicated for you to consume, > then please do refer to the recent text update that make things crystal clear > : > /*https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-12#section-4.16.1*//* > > */ /* > > SR Segment Endpoint Nodes receive the IPv6 packet with the > > Destination Address field of the IPv6 Header equal to its SID > > address. A penultimate SR Segment Endpoint Node is one that, as part > > of the SID processing, copies the last SID from the SRH into the IPv6 > > Destination Address and decrements Segments Left value from one to > > zero. > > > > The PSP operation only takes place at a penultimate SR Segment > > Endpoint Node and does not happen at any Transit Node. > > */ /* > > */And then/* > > */ /* > > This behavior does not contravene Section 4 of [RFC8200] > <https://tools.ietf.org/html/rfc8200#section-4> because the > > current destination address of the incoming packet is the address of > > the node executing the PSP behavior. > > */ /* > > */ /* > > > > 2. I'm afraid this would establish an unfortunate precedent for future > > protocol development to look for a wording loophole in existing > > standards and exploit it as an easy shortcut to publish something > > possibly controversial. Just as we saw, even a very carefully > > reviewed document like RFC8200 always has some glitches and > > ambiguities. If we allow casually exploiting these loopholes for > > the convenience of new protocol designers, more and more people > > will follow and we'll eventually have very inconsistent protocols > > and, in worse cases, loss of interoperabaility and other harm. On > > the other hand, we could use this opportunity for a good precedent > > to show no standard is set in stone and can be updated with new > > developments and proper discussions and justifications. > > > > For this reason, I disagree with this text of > > draft-ietf-spring-srv6-network-programming-12: > > > > This behavior does not contravene Section 4 of [RFC8200] because the > > current destination address of the incoming packet is the address of > > the node executing the PSP behavior. > > */[KT] Again, this is not a technical point. It arises out of our > disagreement on RFC8200 text./* > > > > If I were to offer something in order to be hopefully more constructive, that > would be something like this: > > > > - Add a tag of "Updates RFC8200 (if approved)" > > */[KT] There is no case for doing this. Again it is the same disagreement on > RFC8200 text./* > > > > - In Section 4.16.1, simply say something like: "A penultimate SR > > Segment Node MAY remove the SRH from the IPv6 packet it forwards, > > even if it is not the final (ultimate) destination in the path > > specified in the SRH". (I notice network-programming-12 is already > > pretty close to this) > > */[KT] What is there in the draft already is a much better text IMHO./* > > > > - Perhaps change the pseudo code as follows > > S11.1 If (Segments Left == 1) { /* meaning this is a penultimate node */ > > S11.2 Update IPv6 DA with Segment List[0] > > S12.3. Update the Next Header field in the preceding header to the > > Next Header value of the SRH > > S12.4. Decrease the IPv6 header Payload Length by the Hdr Ext Len > > value of the SRH > > S12.5. Remove the SRH from the IPv6 extension header chain > > S12.6. Go to S15 > > S12.7. } > > */[KT] Please look at the processing pseudocode for a SID behavior and the > PSP (as well as other non-PSP) flavors as a whole. At the end, any > implementer is free to code and implement the logic in their own way as long > as the behaviour and result is consistent./* > > > > - Clarify it's an update to RFC8200, e.g. as follows: > > > > This behavior formally updates Section 4 of [RFC8200], which does > > not allow deleting an extension header until the packet arrives at > > the destination. While the literal text of RFC8200 could read as > > if the deletion were allowed for an intermediate node specified in > > a routing header, this document takes a safer and tighter > > interpretation as described in [the expected draft by Ron here] > > and updates it. > > */[KT] I don’t need to repeat why not required …/* > > > > The update is believed to be sufficiently safe and worthwhile: > > [Justifications here: why we need PSP; explain it doesn't break > > PMTUD; add considerations on AH, etc] > > */[KT] These are covered already. Can you please re-check > /*https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-12#section-4.16.1 > > > > Like Brian's proposed text, whether such an update is acceptable is a > different question. But it's at least a fair game to me. I'd seriously > consider the justifications, and, depending on its details, it's quite > possible that it's something I can support. > > */[KT] Thanks for your review and feedback. I can only hope to have been able > to help clarify and look forward to your support./* > > */ /* > > */Thanks,/* > > */Ketan/* > > > > (Whether we really need such a hack as PSP may also be a question, as some > others have questioned. It seems cleaner to me if we could avoid the hack in > the first place, but I guess I don't have enough knowledge to judge how badly > it is needed and whether there's really no "cleaner" alternative, so I > wouldn't comment on it here). > > > > -- > > JINMEI, Tatuya > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > i...@ietf.org <mailto:i...@ietf.org> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > 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
