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
