11/06/2018 13:03, Ori Kam:
> Due to the very short release cycle for this
> 18.08 release, and the need for good discussions,
> It is more reasonable to target 18.11 for this proposal.
I agree the timeframe is too short in 18.08 to accept such
a new generic API.
> The intent is to have a good gen
Due to the very short release cycle for this
18.08 release, and the need for good discussions,
It is more reasonable to target 18.11 for this proposal.
The intent is to have a good generic API for all tunnel encapsulation
and working well with all HW constraints.
So please let's start the multi-v
On Mon, Jun 11, 2018 at 07:27:22AM +, Ori Kam wrote:
> Hi
>
> No you shouldn't understand this.
> I still think that the [1] proposal is the correct
> approach, but due to a very short time frame for this
> release I suggest this as intermediate solution.
>
> I want to get comments and open d
Hi
No you shouldn't understand this.
I still think that the [1] proposal is the correct
approach, but due to a very short time frame for this
release I suggest this as intermediate solution.
I want to get comments and open discussion regarding
the proposal and in worst case add it to next releas
Hi Ori,
Should we understand this proposal is nacked by [1] you have also
proposed?
If yes, answer to this one with a self-nack to make it clear.
Thanks,
On Tue, Jun 05, 2018 at 06:48:28PM +0300, Ori Kam wrote:
> This RFC contain proposal to add generic support for tunnel
> encapsulation/decaps
This RFC contain proposal to add generic support for tunnel
encapsulation/decapsulation.
Due to the fact that there are many possible tunnel types
and each tunnel type has number of header variations, there
is a need for some generic command.
example for tunnel headers in case of MPLSoGRE:
ETH /
6 matches
Mail list logo
