Hi Mark,
Thank you for your feedback. Please see inline [PC1].
Cheers,
Pablo.
-----Original Message-----
From: Mark Smith <markzzzsm...@gmail.com>
Date: Wednesday, 26 February 2020 at 01:31
To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>
Cc: Ron Bonica <rbon...@juniper.net>, "Joel M. Halpern" <j...@joelhalpern.com>,
"spring@ietf.org" <spring@ietf.org>
Subject: Re: [spring] Is srv6 PSP a good idea
Hi Pablo,
On Sat, 21 Dec 2019 at 04:38, Pablo Camarillo (pcamaril)
<pcama...@cisco.com> 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.
[PC1]: Did you just make this up? ;-) RFC8200 does not talk about mutability.
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.
[PC1]: I disagree with you. As a matter of fact RFC8200 allows the deletion of
an extension header at a node identified in the destination address of the
packet (page 8 paragraph 2).
Please see these emails from other people who state the opposite from you:
https://mailarchive.ietf.org/arch/msg/ipv6/Ypnpw-oneCb7W6s41dVZGMok0Nw/
https://mailarchive.ietf.org/arch/msg/spring/pGS5O53VTDSt2tpc7mm3FVVd0Xk/
https://mailarchive.ietf.org/arch/msg/spring/i0faTfqB-NduzI2VyMyQ6R60dQw/
https://mailarchive.ietf.org/arch/msg/spring/JdpSLS7ax0VUZLG6SINxnOWJzbY/
https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0/
https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso/
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.
[PC1]: Did you also just make up this “quality assurance” thing? I have not
found a reference to it in RFC4302 or RFC4301. RFC4301 contains a good section
2.1 describing the Design Objectives. It only talks about interoperable
cryptographically-based security.
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.
[PC1]:
- As described in
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-7.5
, AH is not required to secure the SR Domain. For this reason, the use of AH
at the SR source node is out of the scope of this document.
- Regardless of the above, please keep in mind that the PSP flavor is indicated
in the control-plane advertisement of the SID (e.g., in ISIS), as part of the
behavior identifier. A source node using AH in combination with SRv6 can thus
ensure that the SRH will remain in the packet until the final destination by
selecting a penultimate SID that does not have the PSP flavor.
> 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."
[PC1]: Is this a technical argument?
[PC1]: Operators can freely choose what to do in their network. PSP is
optional. They have stated the benefits of PSP, and we know that at least half
of the public SRv6 deployments are using it.
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].
And additionally, operators have expressed their value in [4] and [5].
[1].- https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0
[2].- https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c
[3].- https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0
[4].- https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk
[5].- https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI
How much troubleshooting experience have they had with this?
[PC1] Operators who have deployed stated that this is not operationally complex.
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.
[PC1] Please take a look at the list of operators that have deployed this in
their production network that is so core to their business. You seem to be
raising doubts about operational aspects of their network. This doesn’t look
like a technical argument. If you are questioning their experience and
deployment decision; well, up to you to do it.
Regards,
Mark.
> 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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
