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 Fri, 6 Mar 2020 23:37:37 +0100,
Robert Raszuk <[e-mail]> wrote:

> But in the same time I hear from both SR folks as well as 6man AD that the
> current language of RFC8200 is purposely left to only say that only pure
> transit nodes can not mess with the the IPv6 headers in any way while in
> the same time node which address (/128 or less) is verbatim placed in
> destination address field of the outermost IPv6 header can.

Hmm, do you mean Suresh by "6man AD"?  Or do you mean 6mah WG chair(s)?
I didn't think Suresh said it was intentionally left ambiguous so that
it could allow a non-final destination node can remove an EH...Maybe
you're referring to this message?
https://mailarchive.ietf.org/arch/msg/ipv6/f-MzcHlmeklMXJ0E63TTzij4YQI/

On re-reading it now, it's actually subtle: "We ended up strengthening
some constraints while leaving some others open" or "it is impossible
to determine after the fact if a different text formulation would have
gotten consensus" could read as if this loophole was intentional, but
the wording is so nuanced and I'm not sure if that's his intent.

> I do not know if this is compliant with the IPv6 architecture spirit, but
> when we process drafts which refer to prior RFCs we must base them on the
> actual text and not the intentions of those who wrote it.

I agree if this were a discussion on a law in a court, and I also tend
to agree for an engineering discussion in general: after all
"intentions" are generally a subjective matter.  But, in this case, it
was clearly (to me) a bug of RFC8200, if only because this
interpretation could still allow breaking PMTUD.  Recalling we spent
hundreds if not thousands of email messages on whether we can allow
it, it's really a surprise to me if it's just not a wording bug but an
intentionally left loophole.  If my reading of this thread is correct,
it was not only me who were surprised at it.

>From this point of view, publishing another document with its
validity based on a bug will mean we're making another bug, and that's
unfortunate from an engineering point of view.  Hence my sketch
proposal: behavior-wise it's no different from network-programming-12
(the penultimate node can still remove the SRH), but just based on a
bug-fixed version of RFC8200 by updating it, thereby making
network-programming less buggy as well.  I sincerely thought it would
have a higher chance to be accepted: for the supporters of
network-programming there's no change for implementations and
operations; for those disagreeing it conforms to RFC8200, at least
there's now no such reason (some people may still disagree with the
update rationales, but I suspect that would be the same whether it
tries to claim conformance or update).

But, again, I expect not everyone agrees on this idea.  You probably
won't; then I'll respect that.  Sometimes we just have to agree to
disagree.

> So while we are at it what puzzles me more now is to clearly understand
> under what precise conditions the actual SRH insertion can take place since
> the advice from IPv6 community was to move it to a different draft. One was
> clearly articulated - assure the packets will not get dropped due to such
> SRH insertion. Valid. Is there something more ?
>
> Procedurally I understand that as long as this new spinned off draft
> updates RFC8200 we should be all ok. Is this a correct assumption ?

Sorry, I'm not sure how to interpret these two paragraph...is it
related to draft-ietf-spring-srv6-network-programming-12?

--
JINMEI, Tatuya