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

["Ketan Talaulikar (ketant)" <[e-mail]>]

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

--------------------------------------------------------------------