Re: [spring] Is srv6 PSP a good idea

["Joel M. Halpern" <[e-mail]>]

Robert, given that PSP either pushes the envelop of what is permitted by 
RFC 8200 or outright violates it (which applies seems to depend upon the 
reader) it would seem that there ought to be a good reason for including 
PSP, rather than claiming that objectors need to motivate removing it.

I have seen only minimal descriptions of value for PSP.
We know that adding optional behaviors is undesirable in the abstract.
Adding optional behaviors that push or violate the standards seems 
significantly worse.

Yours,
Joel

On 2/26/2020 5:06 AM, Robert Raszuk wrote:
> 
> So now we have one more to Pablo's list: "Let's not use it as it is hard 
> to troubleshoot" ...
> 
> Clearly each new tool has a learning curve and no doubt not everyone 
> will know how to use it. But does this mean we should stop inventing new 
> things ? IMO for someone who is starting to use SRv6 PHP is the least 
> complex operational behaviour.
> 
> Thx,
> R.
> 
> 
>     On Wed, Feb 26, 2020 at 1:31 AM Mark Smith <[e-mail]
>     <mailto:[e-mail]>> wrote:
> 
>         Hi Pablo,
> 
>         On Sat, 21 Dec 2019 at 04:38, Pablo Camarillo (pcamaril)
>         <[e-mail] <mailto:[e-mail]>> wrote:
>          >
>          >  Hi Ron,
>          >
>          > I guess we are making some progress here but going in some
>         circles. So far we have moved from “this violates RFC8200” to
>         “there are no use-cases or benefits” to “this is complex for an
>         ASIC” to “what is the benefit again” and now back to “this is
>         complex for an ASIC”.
>          >
> 
>         As far as I know, the next header field in both the IPv6 fixed
>         header
>         and in extension headers is immutable while the packet is travelling
>         within the network, as is the payload length field in the IPv6 base
>         fixed header.
> 
>         Nothing in RFC 8200 modifies those fields while the packet is in
>         flight between the packet's original source and final
>         destination, nor
>         is there anything in RFC 8200 that specifies how to do those
>         modifications and any other discussion about the consequences and
>         considerations when doing so.
> 
> 
>         The IPsec AH header is providing integrity checking over fields
>         in the
>         IPv6 packet that shouldn't be being modified while the packet is
>         within the network. What is and isn't protected by AH can be seen to
>         be a specification of what processing on a packet can and cannot
>         occur
>         while it is in flight across the network towards its final
>         destination.
> 
>         Therefore, AH is really a quality assurance mechanism for the
>         network
>         packet processing that RFC 8200 specifies. The processing of the
>         packet by the network with or without the use of AH should be the
>         same. AH should really only be necessary if there is a belief
>         that the
>         network is likely not to be processing packets in accordance to RFC
>         8200, either accidentally or intentionally.
> 
> 
>         Per RFC4302 (IPsec AH),  the following section explicitly states
>         which
>         fields in the IPv6 header are immutable and are to be protected
>         by AH:
> 
> 
>         3.3.3.1.2.  ICV Computation for IPv6
> 
>         3.3.3.1.2.1.  Base Header Fields
> 
>             The IPv6 base header fields are classified as follows:
> 
>         Immutable
>                     Version
>                     Payload Length
>                     Next Header
>                     Source Address
>                     Destination Address (without Routing Extension Header)
> 
>             Mutable but predictable
>                     Destination Address (with Routing Extension Header)
> 
>             Mutable (zeroed prior to ICV calculation)
>                     DSCP (6 bits, see RFC2474 [NBBB98])
>                     ECN (2 bits, see RFC3168 [RFB01])
>                     Flow Label (*)
>                     Hop Limit
> 
>                  (*) The flow label described in AHv1 was mutable, and in
>                      RFC 2460 [DH98] was potentially mutable.  To retain
>                      compatibility with existing AH implementations, the
>                      flow label is not included in the ICV in AHv2.
> 
> 
> 
> 
>          > As for how easy or not something is, the PSP behavior has
>         been implemented and deployed (running code). The use-cases have
>         been described and positively reinforced by operators. I don't
>         think there is any further explanation to provide.
>          >
> 
>         "Just because you can do something, doesn't mean you should."
> 
>         How much troubleshooting experience have they had with this?
> 
>         I think a very important factor is how easy something is to
>         troubleshoot - how obvious is the mechanism works; is the mechanism
>         consistent with existing behaviours i.e. the principle of least
>         surprise (removing EHs at an intermediary hop certainly isn't in
>         IPv6,
>         even if the intermediary hop as the packet's current DA); when it
>         inevitably fails, how obvious is it where the fault is likely to be;
>         and how quickly can a typical fault be rectified.
> 
> 
> 
>         Regards,
>         Mark.
> 
> 
> 
> 
>          > Happy Holidays,
>          > Pablo.
>          >
>          >
>          > -----Original Message-----
>          > From: Ron Bonica <[e-mail]
>         <mailto:[e-mail]>>
>          > Date: Tuesday, 17 December 2019 at 16:06
>          > To: "Pablo Camarillo (pcamaril)" <[e-mail]
>         <mailto:[e-mail]>>, "Joel M. Halpern"
>         <[e-mail] <mailto:[e-mail]>>,
>         "[e-mail] <mailto:[e-mail]>" <[e-mail]
>         <mailto:[e-mail]>>
>          > Subject: RE: [spring] Is srv6 PSP a good idea
>          >
>          >     Pablo,
>          >
>          >     In your message below, are you arguing that it is easier
>         for the penultimate node to remove the SRH than it is for the
>         ultimate node to ignore it? I think that would be a stretch.
>          >
>          >                                                             
>                               Ron
>          >
>          >
>          >
>          >     Juniper Business Use Only
>          >
>          >     -----Original Message-----
>          >     From: Pablo Camarillo (pcamaril) <[e-mail]
>         <mailto:[e-mail]>>
>          >     Sent: Saturday, December 14, 2019 4:50 AM
>          >     To: Ron Bonica <[e-mail]
>         <mailto:[e-mail]>>; Joel M. Halpern
>         <[e-mail] <mailto:[e-mail]>>;
>         [e-mail] <mailto:[e-mail]>
>          >     Subject: Re: [spring] Is srv6 PSP a good idea
>          >
>          >     Ron,
>          >
>          >     What is the "price paid by the penultimate segment"? All
>         the current implementations do this at linerate with no
>         performance degradation as I have explained in my email before.
>          >
>          >     There is substantial benefit. Four operators have
>         deployed PSP, which proves the benefit.
>          >     It enables new use-cases that have been provided by other
>         members in the list. [1], [2] and [5].
>          >     From operational perspective it is not complex as
>         explained in [3].
>          >     Operators have expressed their value in [4] and [5].
>          >
>          >     [1].-
>         https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcdXeBzk_$
>          >     [2].-
>         https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcU9bihBc$
>          >     [3].-
>         https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4Icc_wo902$
>          >     [4].-
>         https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcRXo_q-1$
>          >     [5].-
>         https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IceGPpSab$
>          >
>          >     Cheers,
>          >     Pablo.
>          >
>          >     -----Original Message-----
>          >     From: Ron Bonica <[e-mail]
>         <mailto:[e-mail]>>
>          >     Date: Thursday, 12 December 2019 at 21:50
>          >     To: "Pablo Camarillo (pcamaril)" <[e-mail]
>         <mailto:[e-mail]>>, "Joel M. Halpern"
>         <[e-mail] <mailto:[e-mail]>>,
>         "[e-mail] <mailto:[e-mail]>" <[e-mail]
>         <mailto:[e-mail]>>
>          >     Subject: RE: [spring] Is srv6 PSP a good idea
>          >
>          >         Pablo,
>          >
>          >         I am not convinced the benefit derived by the
>         ultimate segment justifies the price paid by the penultimate
>         segment. Specifically,
>          >
>          >         - the ultimate segment benefits because it doesn't
>         have to skip over the SRH with SL == 0
>          >         - in order for the ultimate segment to derive this
>         benefit, the penultimate segment needs to remove bytes from the
>         middle of the packet and update two fields in the IPv6 header
>          >
>          >         As Joel said, we typically don't add options (i.e.,
>         complexity) to a specification unless there is substantial benefit.
>          >
>          >                                                             Ron
>          >
>          >
>          >
>          >
>          >         Juniper Business Use Only
>          >
>          >         -----Original Message-----
>          >         From: spring <[e-mail]
>         <mailto:[e-mail]>> On Behalf Of Pablo Camarillo
>         (pcamaril)
>          >         Sent: Wednesday, December 11, 2019 3:12 PM
>          >         To: Joel M. Halpern <[e-mail]
>         <mailto:[e-mail]>>; [e-mail]
>         <mailto:[e-mail]>
>          >         Subject: Re: [spring] Is srv6 PSP a good idea
>          >
>          >         Joel,
>          >
>          >         1.- The use-case for PSP has already been provided at
>         the mailer. There are scenarios where it provides benefits to
>         operators.
>          >
>          >         2.- The PSP behavior is optional. It is up to the
>         operator in his deployment to decide whether to enable it or not
>         at one particular router.
>          >         Similarly, a vendor may decide not to implement it.
>         The PSP behavior has been implemented by several vendors and
>         deployed (see the srv6 deployment draft).
>          >
>          >         3.- A network may have PSP enabled at some nodes and
>         not at others.  Everything is still interoperable and works fine.
>          >
>          >         4.- PSP is not a complex operation in hardware
>         (doable at linerate on existing merchant silicon).
>          >         Example: It has been implemented and deployed on
>         Broadcom J/J+. If I recall correctly Broadcom Jericho+ started
>         shipping in March 2016! PSP is supported on this platform at
>         linerate with no performance degradation (neither PPPS nor BW).
>          >         Given that this is doable in a platform from more
>         than 3 years ago, I fail to see how you need "very special
>         provision" to do this.
>          >
>          >         Is it really something that horrible to provide
>         freedom of choice to the operators deploying?
>          >
>          >         In summary, it can be implemented without any burden
>         in hardware and deployment experience prove this is beneficial
>         to operators.
>          >
>          >         Thanks,
>          >         Pablo.
>          >
>          >         -----Original Message-----
>          >         From: spring <[e-mail]
>         <mailto:[e-mail]>> on behalf of "Joel M. Halpern"
>         <[e-mail] <mailto:[e-mail]>>
>          >         Date: Wednesday, 11 December 2019 at 03:55
>          >         To: "[e-mail] <mailto:[e-mail]>"
>         <[e-mail] <mailto:[e-mail]>>
>          >         Subject: [spring] Is srv6 PSP a good idea
>          >
>          >             For purposes of this thread, even if you think
>         PSP violates RFC 8200,
>          >             let us assume that it is legal.
>          >
>          >             As I understand it, the PSP situation is:
>          >             o the packet arrives at the place (let's not
>         argue about whether SIDs
>          >             are locators) identified by the SID in the
>         destination address field
>          >             o that SID is the next to last SID in the SID list
>          >             o that sid is marked as / known to be PSP
>          >             o at the intended place in the processing
>         pseudocode, the last (first)
>          >             entry in the SRH is copied into the destination
>         IPv6 address field of
>          >             the packet
>          >             -> The SRH being used is then removed from the
>         packet.
>          >
>          >             In order to evaluate whether this is a good idea,
>         we have to have some
>          >             idea of the benefit.  It may be that I am missing
>         some of the benefit,
>          >             and I would appreciate clarification.
>          >             As far as I can tell, the benefit of this removal
>         is that in exchange
>          >             for this node doing the work of removing the SRH,
>         the final node in the
>          >             SRH does not have to process the SRH at all, as
>         it has been removed.
>          >
>          >             I have trouble seeing how that work tradeoff can
>         be beneficial.
>          >             Removing bytes from the middle of a packet is a
>         complex operation.
>          >             Doing so in Silicon (we expect this to be done in
>         the fast path of
>          >             significant forwarders as I understand it)
>         requires very special
>          >             provision.  Even in software, removing bytes from
>         the middle of a packet
>          >             requires somewhere between some and a lot of
>         extra work.  It is
>          >             distinctly NOT free.
>          >
>          >             In contrast, we have assumed that the work of
>         processing SRH itself is
>          >             tractable, since otherwise all of SRv6 would be
>         problematic.  So why is
>          >             this necessary.
>          >
>          >             Yours,
>          >             Joel
>          >
>          >             PS: Note that both the MPLS case and the
>         encapsulation case are very
>          >             different in that the material being removed is
>         at the front of the IP
>          >             packet.  Pop or prepend are MUCH easier than
>         middle-removal (or
>          >             middle-insertion).
>          >
>          >             _______________________________________________
>          >             spring mailing list
>          > [e-mail] <mailto:[e-mail]>
>          >
>         https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r78vsFpWAHa8hW2$
>          >
>          >
>          >         _______________________________________________
>          >         spring mailing list
>          > [e-mail] <mailto:[e-mail]>
>          >
>         https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r78vsFpWAHa8hW2$
>          >
>          >
>          >
>          > _______________________________________________
>          > spring mailing list
>          > [e-mail] <mailto:[e-mail]>
>          > https://www.ietf.org/mailman/listinfo/spring
> 
>         _______________________________________________
>         spring mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/spring
>