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

[Greg Mirsky <[e-mail]>]

Hi Brian,
you've said

 Also, answering
your question "what harm does it do?" I think the answer objectively is
"none, unless
you want to use AH".

On the other thread Ron and I have pointed that PSP does have decremental
effect on the ability to perform OAM, particularly performance monitoring,
and the use of the O-bit proposed in draft-ietf-6man-spring-srv6-oam
<https://tools.ietf.org/html/draft-ietf-6man-spring-srv6-oam-03>is
questionable. Though these may not be veied as harmful consequences of PSP
but they clearly, in my opinion, are benefitial either.

Regards,
Greg

On Sat, Feb 29, 2020 at 11:25 AM Brian E Carpenter <
[e-mail]> wrote:

> On 01-Mar-20 07:25, Robert Raszuk wrote:
> > Hi John,
> >
> > I respectfully will disagree with your assessment.
> >
> > Reason #1 - IPv6 can be encapsulated in IPv6 - RFC2473. This is base of
> SRv6 operation. If this would be deprecated, moved to historic or made
> illegal - games over. But if this is still legal then ultimate destination
> for a packet is what it listed in outer IPv6 header DA. That's pretty
> basic. Now what the destination in the header will do with the packet is
> completely different story.
> >
> > Reason #2 - "a node can’t be both the penultimate, and the ultimate,
> node." Of course it can. You are looking flat ..
>
> But I've been told by several people that this is not the use case. I
> believe
> the little diagram I sent yesterday is the use case. And the trick in the
> description
> of PSP is what I pointed out yesterday too: deleting the header when
> segments-left == 0
> but the destination address is not yet set to the final one:
>
> https://mailarchive.ietf.org/arch/msg/spring/n46VuroVGvRurIgGNLZxFbAHvIo/
>
> The thing is, it can be coded and I fully believe there is running code.
> Also, answering
> your question "what harm does it do?" I think the answer objectively is
> "none, unless
> you want to use AH". Making a packet smaller on the last hop cannot break
> PMTUD.
>
> So I think the text needs to admit the trick it's playing on RFC 8200.
> Then the IETF
> can choose whether to let that trick pass.
>
>    Brian
>
>
> > If you look at different layers the same node is in fact acting in
> multiple roles - I can easily count 3 but with TI-LFA it could be  even
> more.
> >
> > The same node is ultimate destination for the outer header
> > in the same time
> > The same node is penultimate destination for SR path
> > in the same time
> > The same node is just regular IPv6 transit from the perspective of the
> original non encapsulated packet
> >
> > Kind regards,
> > R.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Sat, Feb 29, 2020 at 6:46 PM John Scudder <[e-mail] <mailto:
> [e-mail]>> wrote:
> >
> >     Robert,
> >
> >     I think your comment (emphasis added):
> >
> >>     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.
> >
> >     Is wrong. It contradicts everything else that’s been said in the
> hundreds of messages that have gone before, not to mention the plain
> language of draft-ietf-spring-srv6-network-programming-10. The word
> “penultimate” itself is enough to prove this: by definition a node can’t be
> both the penultimate, and the ultimate, node. It’s a contradiction in
> terms, like saying 0 equals 1.
> >
> >     Now, if node X were to remove the RH /and perform the decapsulation/
> that would be a different story, but the whole point of PSP is that X
> removes the RH and then sends the encapsulated packet on to Y which
> performs the decapsulation. (This point was made in one of the other
> threads recently, but I’ve lost track of by whom and which thread.) As far
> as I can tell, this non-controversial behavior is described in 4.16.3 of
> the draft and referred to as “USD”.
> >
> >     —John
> >
> >>     On Feb 29, 2020, at 6:06 AM, Robert Raszuk <[e-mail]
> <mailto:[e-mail]>> wrote:
> >>
> >>     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 神明達哉 <[e-mail] <mailto:
> [e-mail]>> wrote:
> >>
> >>         At Fri, 28 Feb 2020 07:54:28 +0000,
> >>         "Xiejingrong (Jingrong)" <[e-mail] <mailto:
> 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
> >>         [e-mail] <mailto:[e-mail]>
> >>         https://www.ietf.org/mailman/listinfo/spring <
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3UdazBorQ$
> >
> >>
> >>     --------------------------------------------------------------------
> >>     IETF IPv6 working group mailing list
> >>     [e-mail] <mailto:[e-mail]>
> >>     Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3X18TtwYw$
> <
> https://urldefense.com/v3/__https://www..ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3X18TtwYw$
> >
> >>     --------------------------------------------------------------------
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>