Hi Mark, Just to clarify, the SRv6 control plane is not being extended beyond the SRv6 data plane. Let me explain.
The legacy egress PE which does not have SRH processing capabilities is still instantiating the SRv6 End.DT/DX SID [ref net-pgm draft sec 4.4-8] in its FIB. That is still SRv6. Note https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-4.1.1 Glad to see the sympathy for PSP developing in you as you start looking closer at the use-cases 😊 Thanks, Ketan -----Original Message----- From: spring <spring-boun...@ietf.org> On Behalf Of Mark Smith Sent: 28 February 2020 04:35 To: Pablo Camarillo (pcamaril) <pcama...@cisco.com> Cc: Xiejingrong (Jingrong) <xiejingr...@huawei.com>; spring@ietf.org; Voyer, Daniel <daniel.vo...@bell.ca> Subject: Re: [spring] A permanent change to/violation of RFC8200 for a temporary situation. (Re: Is srv6 PSP a good idea) Hi Pablo, On Fri, 28 Feb 2020 at 07:51, Pablo Camarillo (pcamaril) <pcama...@cisco.com> wrote: > > Mark, > > Both the SRv6 control plane and dataplane operate between PEs. The legacy > egress PE only executes End.DT/End.DX and is not capable of doing SRH > processing at linerate in the use-case described by Dan. I understand that. It would never occur to me to extend a control plane domain past the edge of the forwarding plane domain that it controls. That is something I've never seen before in any control plane/forwarding plane protocol pair scenario. So I'm wondering why do it when it is so unconventional. What value does it add? What was the thinking behind doing that? >And as a reminder this is only one of the use-cases of PSP. > This is the only one that makes me slightly sympathetic to the idea of PSP. Regards, Mark. > Cheers, > Pablo. > > -----Original Message----- > From: spring <spring-boun...@ietf.org> on behalf of Mark Smith > <markzzzsm...@gmail.com> > Date: Thursday, 27 February 2020 at 11:43 > To: "Voyer, Daniel" <daniel.vo...@bell.ca> > Cc: "Xiejingrong (Jingrong)" <xiejingr...@huawei.com>, > "spring@ietf.org" <spring@ietf.org> > Subject: [spring] A permanent change to/violation of RFC8200 for a > temporary situation. (Re: Is srv6 PSP a good idea) > > On Sat, 14 Dec 2019 at 09:14, Voyer, Daniel <daniel.vo...@bell.ca> wrote: > > > > I agree 100% with Jingrong, > > > > PSP allows us to bring SRv6 to legacy PE devices that are not capable > of processing the SRH in the dataplane, but are capable of supporting SRv6 in > the control plane. > > > > See this example: > > I am streaming traffic from a server to a customer; > > The ingress PE (near the server) encapsulates the packet and adds an > SRH with a low-latency list of segments; > > The penultimate node in the SRH executes PSP; > > The egress PE (near the customer) decapsulates the IPv6 header and > forwards the inner packet to the customer. > > > > I want to understand this example better, because it sounds very strange > to me. > > So the SRv6 control plane is extended past the edge of the SRv6 > forwarding plane? > > In all other protocols and networks I'm aware of, the control plane > domain and devices, and the forwarding plane domain and devices > it/they controls are either congruent, or the control plane is > "smaller" than the forwarding plane e.g. a couple of BGP Route > Reflectors controlling a cluster of many more routers. > > What value is an SRv6 control plane on a router/PE that doesn't > implement the SRv6 forwarding plane? > > This value would only exist during a temporary period until the router > forwarding plane could be upgraded to an SRv6 forwarding plane, > returning to the common convention of congruent control and forwarding > planes. > > So it seems in this case that RFC 8200 is being violated with the PSP > proposal to accommodate extending an SRv6 control plane past a > network's SRv6 forwarding plane for a relatively short temporary > period, for any particular network, perhaps no more than 2 to 3 years > maximum. > > Why not have the SRv6 control and forwarding domains always match, as > is usual and conventional for other matched pairs of control and > forwarding plane protocols and deployments, including new > protocol/forwarding plane deployments, and entirely avoid the issue of > fundamental violations of or making fundamental changes to a full > Internet standard protocol? > > > We can include SLA unidirectionally from the server to the customer > even though that the egress PE has a legacy ASIC. Legacy equipment are a > reality and are not easy to replace, hence interoperability with brownfield > is key for any innovative approach. > > > > This is exactly the fundamental justification for not violating RFC > 8200, and only minimally extending it where necessary and permitted, > fitting within the architecture rather than trying to change it. As > much SR magic as possible should be put into the much easier to > upgrade control plane, ideally avoiding or at least minimising > forwarding IPv6 plane changes. > > Regards, > Mark. > > > > > > dan > > > > On 2019-12-10, 11:15 PM, "spring on behalf of Xiejingrong (Jingrong)" > <spring-boun...@ietf.org on behalf of xiejingr...@huawei.com> wrote: > > > > I think it's a good idea. > > Nothing new, but benefits that people have already said seems > notable to me. > > > > (1) reduce the load of final destination. This benefit can be > notable for the following sub reasons. > > (1.1) final destination tends to have heavy load. It need to handle > all the EHs and do the delivery/demultiplex the packet to the right overlay > service. > > (1.2) example 1, the final destination may need to handle the DOH > after the RH. > > (1.3) example 2, the final destination may need to do the assembly > of fragmented packets. > > (1.4) example 3, the final destination may need to do AH/ESP after > the Fragmentation Header. > > (1.5) example 4, the final destination may need to deliver the > packet to the right overlay service. > > > > (2) support the incremental deployment when final destination(s) do > not process/recognize SRH. This benefit can be notable for the following sub > reasons. > > (2.1) A core router may (fan-out) connected with a big number of > low-end routers that do not support SRH but support > tunnel-end/service-demultiplex function of SRv6. > > > > Thanks > > Jingrong > > > > -----Original Message----- > > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Joel M. > Halpern > > Sent: Wednesday, December 11, 2019 10:55 AM > > To: 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://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > ------------------------------------------------------------------------------ > > External Email: Please use caution when opening links and > attachments / Courriel externe: Soyez prudent avec les liens et documents > joints > > > > > > > > _______________________________________________ > > 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 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
