Re: [mpls] Concerns about ISD

[Robert Raszuk <[e-mail]>]

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]> 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]>
> *Sent:* Wednesday, April 13, 2022 1:33 PM
> *To:* Haoyu Song <[e-mail]>
> *Cc:* John E Drake <[e-mail]>; Kireeti Kompella <
> [e-mail]>; [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.
>