Re: [spring] Is srv6 PSP a good idea

[Robert Raszuk <[e-mail]>]

On Wed, Feb 26, 2020 at 1:31 AM Mark Smith <[e-mail]> wrote:

> Hi Pablo,
>
> On Sat, 21 Dec 2019 at 04:38, Pablo Camarillo (pcamaril)
> <[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]>
> > Date: Tuesday, 17 December 2019 at 16:06
> > To: "Pablo Camarillo (pcamaril)" <[e-mail]>, "Joel M.
> Halpern" <[e-mail]>, "[e-mail]" <[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]>
> >     Sent: Saturday, December 14, 2019 4:50 AM
> >     To: Ron Bonica <[e-mail]>; Joel M. Halpern <
> [e-mail]>; [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]>
> >     Date: Thursday, 12 December 2019 at 21:50
> >     To: "Pablo Camarillo (pcamaril)" <[e-mail]>, "Joel M.
> Halpern" <[e-mail]>, "[e-mail]" <[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]> On Behalf Of Pablo
> Camarillo (pcamaril)
> >         Sent: Wednesday, December 11, 2019 3:12 PM
> >         To: Joel M. Halpern <[e-mail]>; [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]> on behalf of "Joel M.
> Halpern" <[e-mail]>
> >         Date: Wednesday, 11 December 2019 at 03:55
> >         To: "[e-mail]" <[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]
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r78vsFpWAHa8hW2$
> >
> >
> >         _______________________________________________
> >         spring mailing list
> >         [e-mail]
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r78vsFpWAHa8hW2$
> >
> >
> >
> > _______________________________________________
> > spring mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/spring
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>