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

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