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 Robert,
s/OEM/OAM/ ;)
True, active OAM should not generate excessive number of test packets and
that might make selective non-use of PSP on these packets acceptable. But
some have made a use case for PSP by describing environment where the
ultimate tunnel endpoint is not capable to process SRH. If that is the
practical case, then how SRv6 OAM will work at all?

Regards,
Greg

On Sat, Feb 29, 2020 at 12:36 PM Robert Raszuk <[e-mail]> wrote:

> Greg,
>
> You are thinking of PSP like MPLS PHP to apply to all packets towards the
> guy who advertised implicit-null label.
>
> That is not the case here at all.
>
> You apply PSP when you like on a per segment endpoint basis. OEM as we
> have all agreed will not be subject to PSP. Is there a value to keep
> repeating that every day :) ?
>
> Cheers,
> R.
>
>
>
> On Sat, Feb 29, 2020 at 8:57 PM Greg Mirsky <[e-mail]> wrote:
>
>> 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
>>>
>>