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

[神明達哉 <[e-mail]>]

At Wed, 4 Mar 2020 12:17:07 +0000,
"Pablo Camarillo (pcamaril)" <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:

> 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

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.

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.

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:

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.
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.

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)"

- 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)

- 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.  }

- 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.

    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]

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.

(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