So now we have one more to Pablo's list: "Let's not use it as it is hard to troubleshoot" ...
Clearly each new tool has a learning curve and no doubt not everyone will know how to use it. But does this mean we should stop inventing new things ? IMO for someone who is starting to use SRv6 PHP is the least complex operational behaviour. Thx, R. 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
