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

Dear Jinmei-san,

Thank you for your efforts to explain the spirit of RFC8200. I think we all
agree now that those who worked on IPv6 from the start by ultimate
destination consider either the destination which src host's socket puts in
the packet or (which I admit I never realized before this thread) the
*final* source routed node.

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.

In that way I stated that PSP is compliant with current language of
RFC8200.

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.

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 ?

Many thx,
Robert.


On Fri, Mar 6, 2020 at 10:48 PM 神明達哉 <[e-mail]> wrote:

> At Thu, 5 Mar 2020 04:08:28 +0000,
> "Ketan Talaulikar (ketant)" <ketant=[e-mail]> wrote:
>
> > 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/
>
> This link's explanation is that RFC8200 does NOT mean "extension
> headers cannot be removed from a packet until it has arrived at its
> ultimate destination" (and therefore PSP doesn't violate it), isn't
> it?  Then please remember the context of this conversation - it
> started with this comment by Robert:
>
> >> 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.
>
> And I wondered about the logic how "it would *still* be not violate the
> RFC".  So this link's explanation isn't relevant to this specific
> discussion.
>
> As for that link's explanation, I already explained why that
> interpretation doesn't make sense, probably several times, so I won't
> repeat it again.  I know not everyone agrees with my explanation, and
> I'm pretty sure no further explanation can change the mind of people
> who firmly believe this link's argument, so there's no need for
> repeating the position.
>
> I guess that's the same for the rest of your response (sorry for not
> addressing these one by one but).  I knew not everyone would
> agree/support my arguments and suggestions.  From your response, it
> looks like I already made my points clear enough, you understood them
> correctly, and still disagreed with those.  At this point, I suspect
> we'll just have to agree to disagree than wasting everyone's time to
> keep making essentially the same points again and again.
>
> I guess the only feasible next move of mine is to bring my points to
> whatever next round of the process (another WGLC or IETF LC).
>
> --
> JINMEI, Tatuya
>