Re: [mpls] Update to the bullets on the first page of my review of draft-song-mpls-extension-header-09

[Robert Raszuk <[e-mail]>]

Hi Tony,

> One cannot “allow” action independence.

I have a different opinion on this.

I thought the direction this effort is taking is to provide some light form
of network programming to the MPLS data plane.

Well if so actions should be like policy. Yes including hardware offload
when applicable.

You do not mandate fixed policy instructions nor do you put them into RFC.
You support the operator with tools to build any policy he feels like (even
overlapping and conflicting in clauses) if he feels like it.

Sure smart implementation may try to detect the issues and signal it ...
but not IETF nor RFCs.

What I am seeing here is like giving a network operator not a programming
language but a strict set of functions with more mandates on how those new
functions should be positioned against the old ones. IMHO not a very
flexible direction for true network programmability .. maybe just an
imitation of it at best :).

Cheers,
Robert

On Tue, 6 Sept 2022 at 16:14, Tony Li <[e-mail]> wrote:

> Hi Robert,
>
> > Each Network Action must specify how it interacts with all other
> previously defined Network Actions.
>
> So what happens if such definition is in odds with any previously defined
> action ?
>
>
>
> One hopefully detects that during the discussion around the action, as
> part of the RFC development process.
>
> If one has a network action that says “Turn Left at Albuquerque” hopefully
> we realize that that it conflicts with the action “Turn Right at
> Albuquerque”.
>
> Note that this does not mean that the two actions could not appear in the
> same substack. Both are clearly useful, but when found adjacent, would be
> confusing.  It would be incumbent on the RFC writers to explain the
> semantics of such an occurrence or to preclude it.
>
>
> How are you going to practically assure that original intention of
> previously defined action(s) are still maintained ?
>
>
>
> By writing good RFCs and rejected bad ones.
>
>
> I am afraid the only option here is to allow complete action
> independence and leave the sequencing and overlap to the operator to decide
> how it should be resolved by local ordering or tie breaking.
>
>
>
> One cannot “allow” action independence. You can try to ensure it, by
> designing actions that are wholly orthogonal, but experience shows that we
> are imperfect and that our (lack of) understanding will eventually lead us
> to create actions that will interact. The best that we can do then, is to
> document the semantics of the interaction. Even then, there are very likely
> to be unintended consequences (i.e., bugs).
>
> Regards,
> Tony
>
>
>