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 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.
Happy Holidays,
Pablo.
-----Original Message-----
From: Ron Bonica <rbon...@juniper.net>
Date: Tuesday, 17 December 2019 at 16:06
To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>, "Joel M. Halpern"
<j...@joelhalpern.com>, "spring@ietf.org" <spring@ietf.org>
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) <pcama...@cisco.com>
Sent: Saturday, December 14, 2019 4:50 AM
To: Ron Bonica <rbon...@juniper.net>; Joel M. Halpern
<j...@joelhalpern.com>; spring@ietf.org
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 <rbon...@juniper.net>
Date: Thursday, 12 December 2019 at 21:50
To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>, "Joel M. Halpern"
<j...@joelhalpern.com>, "spring@ietf.org" <spring@ietf.org>
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 <spring-boun...@ietf.org> On Behalf Of Pablo Camarillo
(pcamaril)
Sent: Wednesday, December 11, 2019 3:12 PM
To: Joel M. Halpern <j...@joelhalpern.com>; spring@ietf.org
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 <spring-boun...@ietf.org> on behalf of "Joel M. Halpern"
<j...@joelhalpern.com>
Date: Wednesday, 11 December 2019 at 03:55
To: "spring@ietf.org" <spring@ietf.org>
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
spring@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r78vsFpWAHa8hW2$
_______________________________________________
spring mailing list
spring@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r78vsFpWAHa8hW2$
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
