Re: [mpls] Concerns about ISD

[Haoyu Song <[e-mail]>]

Hi Robert,

What you said is true. It’s almost always possible to find control plane alternatives for the same problem.
But then should we discard the data plane-based solution altogether? Here’s some of my thoughts.

Some in-network header and metadata has been standardize or is in the process of standardization and there are also many ongoing works proposing to apply them in different types of networks, which means hardware will need to support these functions if these standards are actually to be adopted. If so, it would be nice to have MPLS-based solution accordingly for these functions (by then the only new work in data plane would be the new header parsing)
Further, this is even required if MPLS only covers a section of the network path while the other parts of the network running different protocols apply the new data plane functions, and the applications require E2E coverage.  In this case, MPLS needs to participate in using the similar data plane header and metadata.

My second point is that I find it’s hard for a control plane solution and its counterpart in data plane to maintain exactly the same semantics. I’m not familiar with Slice ID so I won’t comment on it. For IOAM, there are multiple possible options available, each with its own pros and cons. It’s better to let operators choose which option best suits their needs. For another example, MPLS SFC may need to pass some metadata between different SFs. This can only be done on a per-packet basis. I don’t see how control plane can do it.

I’m familiar with the capability of the state-of-the-art forwarding chips. Some tasks are challenging but some are doable or even preferred to be done in data plane. We need to evaluate the tradeoffs carefully case by case.

Best regards,
Haoyu

From: Robert Raszuk <[e-mail]>
Sent: Thursday, April 14, 2022 9:34 AM
To: Haoyu Song <[e-mail]>
Cc: [e-mail]
Subject: Re: [mpls] Concerns about ISD

Hi Haoyu,

> There are some use cases (e.g., slice ID, IOAM trace) which requires the user packets to carry some extra metadata.

I really do not think that examples you provide would require metadata in the data plane.

Take - slide ID - slices in my book are build end to end and there is no need for each node to make an independent decision. Flows are mapped to slice in ingress and travel through that slice to the egress. There are number of ways to construct such slices today. That said if there is some advantage for a set of flows to be recognized and routed hop by hop  forwarding behaviour identifier will be sufficient to make such hop by hop recognition and correct hop by hop forwarding.

Likewise IOAM trace postcard can also include any amount of information propagated to those networks elements which are to iOAM act on packets and such information can be again fetched by data plane from control plane (or pushed by control plane to data plane) based on the forwarding behaviour id. Not to mention that the reply itself can contain the entire mpls label stack and even bytes beyond that.

I am yet to see a case where the proposed forwarding behaviour ID (FBI) fails to map to control plane distributed actions, metadata etc .. which in turn will require to stuff such data to each and every packet. Note we are not talking lab here ... we are talking about forwarding efficiency of TB/s trunks full of data.  As you said in those cases every bit counts. In fact I hope most of those would be optical lambdas switched without going back to electrical at transit hops) in the not so distant future.

Regards,
R.

On Thu, 14 Apr 2022 at 18:13, Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

I’m glad we share the same view. I do believe we should try to keep the complexity in control plane as much as possible and meanwhile make the data plane as simple as possible. But I also realize that  this can be done only to certain extent until we can’t make it simpler. There are some use cases (e.g., slice ID, IOAM trace) which requires the user packets to carry some extra metadata. Chaining them after the MPLS label stack is the least intrusive and simplest way I can envision. In addition, keeping the data plane performance in mind, we should set a strict barrier on admitting use cases to this framework, and sometimes we may have to seek alternative methods. Look forward to your proposal.

Best regards,
Haoyu

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, April 13, 2022 1:33 PM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: John E Drake <[e-mail]<mailto:[e-mail]>>; Kireeti Kompella <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] Concerns about ISD

Hi Haoyu,

[HS] It’s not about easy or hard to implement, it’s about the tradeoff between performance, cost, flexibility, and extensibility. Unlike the control plane protocols, the design will run in high performance device data plane, so every clock tick counts. In this regard, “Easy” or “Hard” can be and should be evaluated based on a set of solid qualitative and quantitative criteria when we compare different schemes.  We should choose the best design to the best of our knowledge.

I believe this is very well said indeed.

What is apparently being worked on here for months is in my view merely a CPR for MPLS.

Instead IMO (and that is why I brought up the control plane assisted model) MPLS could way exceed capabilities of SR NP without any excessive load on packets or major surgery to MPLS architecture by encoding reference to forwarding behaviour itself instead of just a pile atomic "actions" (irrespective if those are stuffed into ISD or PSD).

So yes - no draft no proposal - I get this. I will write one. When I get to it.

Kind regards,
Robert.