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

[Tony Li <[e-mail]>]

Hi Robert,


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


It is indeed.  Note the word ‘programming’.


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


CPUs do not execute policy declarations. They execute instructions. We do not know how to execute ‘intent’, no matter how much marketing literature we consume.  We can and do write programs that take and implement intent, but we end up doing so by executing instructions.

MNA is attempting to encode instructions into the packet, not policy.  [Yes, your proposal is closer to that, but that’s orthogonal to this discussion.]


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


That does not match my understanding of the problem statement, as set forth in the use cases document.


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


The goal is closer to a programming language, tho we have little understanding of what the RISC approach in this space would be. Therefore, what we are doing is accumulating numerous CISC instructions in our instruction set.  Not surprising at this early stage of our understanding.

As we progress, we may get to a deeper understanding that will allow us to design a RISC instruction set, but I fear that we’re a long way off. Time and experience should help.

Tony