On Wed, Feb 26, 2020 at 1:31 AM Mark Smith <markzzzsm...@gmail.com> wrote:
> 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. > > 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 <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 >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
