On Tue, Sep 20, 2016 at 3:52 AM, Jan Scheurich
wrote:
>> From: Jesse Gross [mailto:je...@kernel.org]
>> Sent: Friday, 16 September, 2016 01:38
>>
>> I think the main issue is that when packets are being tunneled and NSH is in
>> use, the encapsulation format (and therefore OVS port
>> type) is no
> From: Jesse Gross [mailto:je...@kernel.org]
> Sent: Friday, 16 September, 2016 01:38
>
> I think the main issue is that when packets are being tunneled and NSH is in
> use, the encapsulation format (and therefore OVS port
> type) is not NSH - it's typically VXLAN-GPE. This is conceptually simil
type-aware pipeline or is generalized otherwise, e.g. when
>> introducing support for P4.
>>
>> BR, Jan
>>
>> > -Original Message-
>> > From: Ben Pfaff [mailto:b...@ovn.org]
>> > Sent: Tuesday, 06 September, 2016 16:31
>> > To: Jesse Gr
-Original Message-
> > From: Ben Pfaff [mailto:b...@ovn.org]
> > Sent: Tuesday, 06 September, 2016 16:31
> > To: Jesse Gross
> > Cc: Jan Scheurich; Li, Johnson; Simon Horman; dev@openvswitch.org; Miguel
> > Angel Muñoz Gonzalez; Manuel Buil; László Sürü;
>
> Sent: Tuesday, 06 September, 2016 16:31
> To: Jesse Gross
> Cc: Jan Scheurich; Li, Johnson; Simon Horman; dev@openvswitch.org; Miguel
> Angel Muñoz Gonzalez; Manuel Buil; László Sürü;
> Multanen, Eric W
> Subject: Re: [ovs-dev] NSH Option 2 implementation
>
> On Tue, Aug 23, 2
On Tue, Aug 23, 2016 at 07:47:50PM -0700, Jesse Gross wrote:
> Ben mentioned that he had some comments on the "OVS philosophy" here
> vs. OpenFlow, so that might affect things. Hopefully it will end up
> simplifying things somewhat.
Basically, OVS has implemented tunnels in its own fashion for far
Hi Jesse and Ben,
Do you have some time to help us with our question how to cleanly model push
and pop actions for NSH and outer Ethernet headers in OVS (see
http://openvswitch.org/pipermail/dev/2016-August/077792.html for the original
post).
We would really like to have this resolved before w
> From: Jesse Gross [mailto:je...@kernel.org]
> Sent: Wednesday, 24 August, 2016 04:48
>
> >> I'm still not enthusiastic about having a combined push NSH/Ethernet
> >> action. I don't think that it even really supports the full NSH use
> >> case since at least some of the patches sent are not using
On Tue, Aug 23, 2016 at 9:12 AM, Jan Scheurich
wrote:
>> -Original Message-
>> From: Jesse Gross [mailto:je...@kernel.org]
>> Sent: Monday, 15 August, 2016 19:12
>>
>> On Fri, Aug 12, 2016 at 1:01 AM, Jan Scheurich
>> wrote:
>> > The only clean way to avoid that now would be to maintain
> -Original Message-
> From: Jesse Gross [mailto:je...@kernel.org]
> Sent: Monday, 15 August, 2016 19:12
>
> On Fri, Aug 12, 2016 at 1:01 AM, Jan Scheurich
> wrote:
> > The only clean way to avoid that now would be to maintain the monolithic
> > push/pop_nsh semantic of the Yi Yang patc
> ; Multanen, Eric W
>
> Subject: Re: [ovs-dev] NSH Option 2 implementation
>
> On Fri, Aug 12, 2016 at 1:01 AM, Jan Scheurich
> wrote:
> > The only clean way to avoid that now would be to maintain the
> monolithic push/pop_nsh semantic of the Yi Yang patch and always
>
On Fri, Aug 12, 2016 at 1:01 AM, Jan Scheurich
wrote:
> The only clean way to avoid that now would be to maintain the monolithic
> push/pop_nsh semantic of the Yi Yang patch and always push/pop NSH header and
> outer MAC header together. Together with Simon's patch we could still achieve
> NSH
Hi,
I still think that from an OpenFlow perspective it is conceptually broken to
have the same OXM or NXM fields refer to packet header fields in the case they
are part of the packet header and to some kind of "metadata" fields if they are
not. It's basically the same problem as I high-lighted
>
> Hi Jan,
>
> On Thu, Aug 11, 2016 at 12:58:44PM +, Jan Scheurich wrote:
> > Hi Simon
> >
> > > > The implicit push_eth action introduced by Simon in his L3 tunnel
> > > > port patch mainly ensures the presence of the 14 byte MAC header
> > > > on ports where this is a must for syntactic i
Hi Jan,
On Thu, Aug 11, 2016 at 12:58:44PM +, Jan Scheurich wrote:
> Hi Simon
>
> > > The implicit push_eth action introduced by Simon in his L3 tunnel port
> > > patch mainly ensures the presence of the 14 byte MAC header on ports
> > > where this is a must for syntactic interpretation of th
Hi Simon
> > The implicit push_eth action introduced by Simon in his L3 tunnel port
> > patch mainly ensures the presence of the 14 byte MAC header on ports
> > where this is a must for syntactic interpretation of the packet. It
> > did not worry about if the resulting packet was semantically usef
Hi Jan,
On Thu, Aug 11, 2016 at 11:04:22AM +, Jan Scheurich wrote:
> > > [Jan] Should sending a packet after push_nsh to an output port be
> > > allowed in general? For a VXLAN-GPE tunnel port this is OK, but my
> > > expectation was that one must explicitly do push_eth (followed by
> > > set_
> > [Jan] Should sending a packet after push_nsh to an output port be
> > allowed in general? For a VXLAN-GPE tunnel port this is OK, but my
> > expectation was that one must explicitly do push_eth (followed by
> > set_field for dl_src and dl_dst) to be able to transmit on a normal
> > Ethernet po
>
> + [ovs-dev]
>
> Further comments below.
>
> BR, Jan
>
> > -Original Message-
> > From: Li, Johnson [mailto:johnson...@intel.com]
> > Sent: Thursday, 11 August, 2016 03:36
> > Subject: RE: NSH Option 2 implementation
> >
> > >
> > > Hi Danny,
> > >
> > > thanks, for your quick respon
+ [ovs-dev]
Further comments below.
BR, Jan
> -Original Message-
> From: Li, Johnson [mailto:johnson...@intel.com]
> Sent: Thursday, 11 August, 2016 03:36
> Subject: RE: NSH Option 2 implementation
>
> >
> > Hi Danny,
> >
> > thanks, for your quick response. I look forward to hearing fr
20 matches
Mail list logo
