Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Brian E Carpenter <[e-mail]>]

> 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 <[e-mail]> On Behalf Of ????
> Sent: 05 March 2020 05:15
> To: Pablo Camarillo (pcamaril) <pcamaril=[e-mail]>
> Cc: [e-mail]; [e-mail]; Bob Hinden <[e-mail]>; Robert Raszuk <[e-mail]>
> 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=[e-mail] <mailto:pcamaril=[e-mail]>> 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
> 
> [e-mail] <mailto:[e-mail]>
> 
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> 
> --------------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>