Hi, In the IETF context I have always associated 'data plane' with packet forwarding, so I think Peter's suggestion is fine.
Yours Irrespectively, John Juniper Business Use Only From: Lsr <[email protected]> On Behalf Of Robert Raszuk Sent: Thursday, April 14, 2022 5:21 AM To: Peter Psenak <[email protected]> Cc: Ketan Talaulikar <[email protected]>; Acee Lindem (acee) <[email protected]>; [email protected]; [email protected] Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" [External Email. Be cautious of content] Hi Peter, Term "data-plane" usually means physical resources links, switch fabric, ASIC etc ... so I am afraid it will also generate confusion with default data plane. How about two alternatives: - custom/logical topology - logical-data-plane Thx, Robert. On Thu, Apr 14, 2022 at 9:27 AM Peter Psenak <[email protected]<mailto:[email protected]>> wrote: Hi Ketan, On 13/04/2022 15:56, Ketan Talaulikar wrote: > Hi Peter, > > I would still reiterate the need to clarify the usage of "application" > terminology in the base FlexAlgo spec. We don't need to call it > "data-plane", I was suggesting "forwarding mechanism" or it can be > something else as well. I will replace with data-plane. That's the best from what we have. thanks, Peter > > Just my 2c > > Thanks, > Ketan > > > On Wed, Apr 13, 2022 at 2:35 PM Peter Psenak > <[email protected]<mailto:[email protected]> > <mailto:[email protected]<mailto:[email protected]>>> wrote: > > Hi Ketan, > > please see inline (##PP4): > > > On 13/04/2022 10:52, Ketan Talaulikar wrote: > > Hi Peter, > > > > I will not press this point further if I am the only one that > finds this > > complexity without any benefit. :-) > > > > Please check inline below for some clarifications with KT3. > > > > > > On Wed, Apr 13, 2022 at 12:47 PM Peter Psenak > <[email protected]<mailto:[email protected]> > <mailto:[email protected]<mailto:[email protected]>> > > <mailto:[email protected]<mailto:[email protected]> > <mailto:[email protected]<mailto:[email protected]>>>> wrote: > > > > Hi Ketan, > > > > > > please see inline (##PP3): > > > > On 13/04/2022 06:00, Ketan Talaulikar wrote: > > > Hi Peter, > > > > > > Please check inline below with KT2. I am trimming everything > > other than > > > the one point of continuing debate. > > > > > > > > > > > > > 2) The relationship between the algo usage > for IP > > FlexAlgo > > > and other > > > > > data planes (e.g. FlexAlgo with SR) is not > very clear. > > > There arise > > > > > complications when the algo usage for IP > FlexAlgo > > overlap > > > with other > > > > > (say SR) data planes since the FAD is shared but > > the node > > > > participation > > > > > is not shared. While Sec 9 suggests that we > can work > > > through these > > > > > complications, I question the need for such > complexity. > > > The FlexAlgo > > > > > space is large enough to allow it to be > shared between > > > various data > > > > > planes without overlap. My suggestion would > be to > > neither > > > carve out > > > > > parallel algo spaces within IGPs for various > types of > > > FlexAlgo data > > > > > planes nor allow the same algo to be used by > both > > IP and > > > SR data > > > > planes. > > > > > So that we have a single topology computation in > > the IGP > > > for a given > > > > > algo based on its FAD and data plane > participation and > > > then when it > > > > > comes to prefix calculation, the results > could involve > > > > programming of > > > > > entries in respective forwarding planes > based on the > > > signaling of > > > > the > > > > > respective prefix reachabilities. The > coverage of these > > > aspects in a > > > > > dedicated section upfront will help. > > > > > > > > ##PP > > > > I strongly disagree. > > > > > > > > FAD is data-pane/app independent. Participation is > > data-plane/app > > > > dependent. Base flex-algo specification is very > clear > > about > > > that. That > > > > has advantages and we do not want to modify > that part. > > > > > > > > > > > > KT> No issue with this part. > > > > > > > > > > > > Topology calculation for algo/data-plane needs > to take > > both > > > FAD and > > > > participation into account. You need independent > > calculation > > > for each > > > > data-plane/app in the same algo. > > > > > > > > > > > > KT> So, an implementation now needs to potentially > support > > > performing > > > > multiple topology computations for each algo. This is a > > > complication for > > > > which I do not see the justification. Why not just pick > > different > > > > algorithms for different data planes for those (rare?) > > > deployments where > > > > someone wants multiple data planes? > > > > > > ##PP2 > > > flex-algo architecture supports multiple > apps/data-planes per > > algo, > > > with > > > unique participation per app/data-plane. That requires > > per-algo/per > > > app/data-plane calculation. What is complicated on it? > > > > > > > > > KT2> This specific and precise statement that you have > provided > > is not > > > covered in either draft-ietf-lsr-flex-algo or this > document. For > > > starters, this needs to be clarified and covered so that > it gets the > > > attention of any reader during the review. This has > implications for > > > implementations. > > > > ##PP3 > > sure we can add it explicitly there, but if you read the base > flex-algo > > draft carefully, it is quite clear. I will add that exact > statement in > > the next re-spin of the base spec. > > > > > > KT3> Thanks. I think we may also need to carefully scrub the use > of the > > term "application" since it seems to bring out different > interpretations > > thanks to the "application" in ASLA. It is better if we use the term > > "application" only in the same semantics as ASLA - this means that > > FlexAlgo is a single "application". We can perhaps use the term > "traffic > > flows" or "service flows" as an alternate for "application flows" > that > > are steered over or use a FlexAlgo. And then when it comes to Node > > Participation in a FlexAlgo, we could use the term "FlexAlgo > Forwarding > > Mechanism" instead of "Applications' Forwarding for FlexAlgo". > Thoughts? > > ##PP4 > the term application is used in the base flex-algo spec from day > one. It > was chosen because it was generic enough to describe whatever the > flex-algo may be used for down the road. We could have used > 'data-plane' > instead, but it could be quite restrictive IMHO. > > > > > > > > > > > > > If your implementation does not want to support it, > fine, but the > > > architecture allows it and there is/are implementation(s) > > that already > > > support it. This is not defined in this draft, it's > defined > > in base > > > flex-algo spec. > > > > > > > > > KT2> I am not sure if it is really an option for > implementation > > once it > > > is in the specification. And this is not about "my" > > implementation :-). > > > So it is not that because some implementations can do (or > does) > > it that > > > it should be in the specification. The determination on > whether it > > > should be in a specification needs to be based on the tradeoff > > between > > > requiring multiple computations per algo with the potential > > benefit or > > > use case that is enabled by it. > > > > ##PP3 > > again, this is how things have been defined from day one, and > for a > > good > > reason. Requiring per app flex-algo even though I want to use > the same > > metric and constraints for both app would be inefficient. > > > > > > KT3> For my understanding, the only inefficiency that you are > referring > > to with the "separate algo per FlexAlgo forwarding mechanism" is a > > duplicate FAD advertisement. Am I missing anything else? > > ##PP4 > right. But the point is there is nothing that prevents multiple apps > using the same algo in the architecture itself. And I see no good > reason > for such restriction. > > > > > > > > > > > > > > > > > > > > > > > > > The fact that the same FAD is shareable between all > > apps has it > > > > advantages and use cases - e.g. if the > participation > > for algo > > > X is the > > > > same in SR and IP data-planes, one can use SR to > > protect IP > > > in that > > > > algo. > > > > > > > > > > > > KT> Would this protection use case not violate the base > > FlexAlgo > > > rule > > > > that the protection has to remain within the specific > > topology. > > > If there > > > > is an SR data plane, then why would one want an IP data > > plane as > > > well? > > > > > > ##PP2 > > > if the participation in two app/data-planes is the > same for > > the algo, > > > the resulting topology is the same. If your > implementation is > > smart, it > > > can only run a single computation for that case. There > is no > > violation > > > here whatsoever. > > > > > > > > > KT2> If the resulting topology is the same between SR data > plane > > and IP > > > data plane, what is the need to enable the IP data plane? > Why not > > just > > > steer the IP traffic over the FlexAlgo data plane? And > when it is > > not > > > the same topology, then we cannot really do the protection > for IP > > > FlexAlgo using SR FlexAlgo. So what is really the use case or > > benefit > > > for enabling this? > > > > ##PP3 > > I just gave you an example where this might be useful. You > may not like > > it, but it will have no impact on the defined architecture. > > > > > > KT3> Ack - we can agree to disagree on this. > > > > > > > > > > > > > > > > > > > > IP forwarding can be steered over the SR-based FlexAlgo > > topology > > > along > > > > with the protection provided by it. Am I missing > something? > > > > > > ##PP2 > > > topology for both primary and backup computation must > be the > > same. > > > > > > > > > KT2> I see the primary use case for IP FlexAlgo (or > another data > > plane) > > > to be that the data plane is used by itself. In the > (rare?) case > > where > > > multiple data planes are required to coexist, it is > simpler both > > from > > > implementation and deployment POV to use different algos. It > > would be > > > good to have operator inputs here. The only cost that I > see for > > this is > > > that the same FAD may get advertised twice only in the > case where > > it is > > > identical for multiple data planes. So I am still not > seeing the > > benefit > > > of enabling multiple (i.e. per data plane) computations > for a single > > > algo rather than just keeping it a single computation per algo > > where a > > > single data plane is associated with a specific algo. > > > > ##PP3 > > I really do not see the problem. As you stated above > repeating the same > > FAD for multiple algos would be inefficient. The beauty of > FAD is that > > it is app independent and can be used by many of them. > > > > If you like to repeat it, fine it will still work. But we do not > > want to > > mandate that in the spec. > > > > > > KT3> There is currently no normative text in the draft-lsr-flex-algo > > that specifies that an implementation needs to support a "per > flexalgo > > forwarding mechanism" computation for each algo. So when this > > clarification is added, can this be a MAY or perhaps a SHOULD so > that an > > implementation has the choice to perhaps not do this and still > remain > > compliant to the spec? > > ##PP4 > I'm fine to make that optional. > > thanks, > Peter > > > > Thanks, > > Ketan > > > > > > > > thanks, > > Peter > > > > > > > > Thanks, > > > Ketan > > > _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!TzTdj43IFN6fAOGdIoLWLPVget9auoAEB4GEhK3-KKwX2ecau0S1IyKViY2p4BA$>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
