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

Dear Jinmei,

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

IMHO the only grey area as pointed by Brian is if RFC8200 section 4.4
really mandates you to look at segments_left before processing the packet
or it is equally legal to look at that value after local processing occurs.
Definition says:

      Segments Left       8-bit unsigned integer.  Number of route
                          segments remaining, i.e., number of explicitly
                          listed intermediate nodes still to be visited
                          before reaching the final destination.

which to me really means that as long as you recognize given routing header
type you can decrement this value and if zero remove it.

Besides that is a minor detail - as NPG draft could be updated to say:

 S14.1.   If (Segments Left Before Local Decrement == 1) {
 S14.2.      Update the Next Header field in the preceding header to the
                Next Header value of the SRH
 S14.3.      Decrease the IPv6 header Payload Length by the Hdr Ext Len
                value of the SRH
 S14.4.      Remove the SRH from the IPv6 extension header chain
 S14.5.   }

Many thx,
R.

On Sat, Feb 29, 2020 at 2:28 AM 神明達哉 <jinmei@wide.ad.jp> wrote:

> At Fri, 28 Feb 2020 07:54:28 +0000,
> "Xiejingrong (Jingrong)" <xiejingrong@huawei.com> wrote:
>
> > The design of PSP for the benefits of deployment is based on the
> understanding
> > that it does not violate section 4 of RFC8200. In case the RFC8200 text
> may be
> > modified in the future, the PSP may also need to change accordingly.
>
> No, it violates Section 4 of RFC8200.  It's a pity that we have to
> discuss it at this level due to the poor editorial work then (I was
> also responsible for that as one of those reviewing the bis draft),
> but anyone who involved the discussion should know the intent of this
> text intended to say (borrowing from Ron's text) "Extension headers
> cannot be added to a packet after it has left the its source node and
> extension headers cannot be removed from a packet until it has arrived
> at its ultimate destination".  It might look "an attempt of blocking
> an innovation by a small group of vocal fundamentalists", but if you
> see the responses without a bias, you'd notice that even some of those
> who seem neutral about the underlying SRv6 matter interpret the text
> that way.
>
> I'd also note that simply because PSP violates RFC8200 doesn't
> immediately mean it (PSP) "needs to change".  It can update RFC8200 with
> explaining why it's necessary and justified.  That's what I
> requested as you summarized:
>
> > Jinmei: it should say it updates this part of RFC8200 and explain why
> it's justified.
>
> And, since PSP at least wouldn't break PMTUD, I guess the update
> proposal will have much more chance to be accepted than a proposal
> including EH insertion.  On the other hand, pretending there's no
> violation will certainly trigger many appeals and objections at the
> IETF last call (I'll certainly object to it).  In the end, it can
> easily take much longer, or even fail, than formally claiming an
> update to RFC8200.
>
> --
> JINMEI, Tatuya
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>