Re: [mpls] Concerns about ISD

[Robert Raszuk <[e-mail]>]

Hi Haoyu,


> 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.
>

Well I am not sure what is your definition of discard above. In all cases
the line rate processing will better to happen in data plane. But dry
actions how to process given packet do not need to be part of every single
one of them. Control plane should provide that information.

And for 100% clarity control plane can be configuration, controller or
dynamic pub-sub protocol driven.



> 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)
>

Well from what I have learned in the past we are never done with
extensibility. So what is defined in one draft/rfc today will likely be
extended tomorrow. If we take approach of explicit signalling in the data
plane networks will have a hard time to keep up with it. That is why
indirection helps.

And unlike Kireeti's crystal ball which is temporarily kaput - I never had
one - so I would not even attempt to predict the future. I would try to
prepare for it the best way we can.


> 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.
>

Well let's not forget that MPLS runs on IP networks. There is no pure MPLS
only networks. So if there is need for end to end solution and the "other
part " of the network is not MPLS capable I would rather not even try to
run it with MPLS to start with.



>  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.
>

Ok - but I do not see that MPLS transport is specifically capable of
carrying such opaque data as part of MPLS stack. Those should be carried
outside of it if needed. And by outside I mean behind lable stack or in the
front of the lable stack (in the front means by additional encap between SF
nodes).

Best,
Robert