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

[Robert Raszuk <[e-mail]>]

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

Well perhaps to your surprise I am all for clarity in the specifications.
So I have nothing against this spec (or any other spec) to formally update
RFC8200. But correct me if I am wrong - but this would require also 6man
WGLC if I am not mistaken in the process ?

But as you just mentioned there was "hundreds if not thousands of email
messages" regarding header insertion/deletion in flight on 6man and that is
why some authors may be actually resisting to take that path - just to keep
the pandora box closed.

Maybe a compromise is to either start a parallel effort to issue RFC8200bis
or just propose a one page new 6man draft with clear statement that routing
headers can be removed by nodes listed in the SRH segment list and move fwd
?

Many thx,
R.

On Sat, Mar 7, 2020 at 3:21 AM 神明達哉 <[e-mail]> wrote:

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