Re: [spring] Is srv6 PSP a good idea

[Gyan Mishra <[e-mail]>]

On Tue, Dec 17, 2019 at 10:05 AM Ron Bonica <rbonica=
[e-mail]> wrote:

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



> [Gyan].  Good point Joel.  So I think providing parity between SR-MPLS and
SRv6 being two completely different specifications like apple versus
orange.  SR-MPLS reuses the MPLS ldp data plane so PHP and UHP is popping
the traditional MPLS 4 byte shim.  So with SR-MPLS since you are reusing
the ldp data plane with new SRGB range 16000-23999 you are still doing
label swapping and not label stacking. Only when doing SR-TE are you
stacking the transport labels additional transport label per hop for the
traceroute.

My point is that SRV6 being a completely different animal from SR-MPLS we
don’t have to and should not carry over feature parity for the sake of
doing so if it’s unnecessary.  The main point here is PSP and USP are not
popping a transport header or topmost label as with SR-MPLS.  So with PSP
and USP the pseudocode is identical and repetitive with SL==0, pop SRH.
>From an SRV6 technical standpoint at the egress P PSP node or egress PE USP
node you would always only have a single SRH present

The only process that adds the additional SRH is TI-LFA and I believe we
decided that SRH would be part of a new 6in6 encapsulation done st the PLR
node.

If I am wrong, please correct me.

The only other scenario which I believe was brought up is if the SRH was so
large that it was fragmented and so have a fragmentation eh present as well
and then in that case instead of popping both SRHs now present on the USP
egress PE node which would be more processing you would pop the 1st EH on
the PSP node and the last EH fragment on the USP egress PE node.

I want to make sure I am not off on my thinking on USP and PSP as far as
when each happens.  So both USP and   PSP are the 1st two SIDs in the list
USP then PSP and the SL is processed in reverse order.  So am I wrong in my
thinking that in processing the SL as PSSI occurs at each hop along the
source routed path that when SL==0 you would process the 2nd to last
special  PSP SID and that would be the 2nd to last node in the SRv6 domain
which would in fact be the Penultimate hop node and you pop the SRH. Then
when SL==0 you you process the last special USP SID and that would be the
last node in the SRv6 domain which would be in fact the Ultimate hop PE
node and then you would pop the final SRH of present.

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

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: [phone]

Email: [e-mail]

www.linkedin.com/in/networking-technologies-consultant