On Tue, Aug 9, 2016 at 7:52 AM, Simon Horman wrote:
> Hi Jesse,
>
> On Wed, Jul 13, 2016 at 07:35:59AM -0700, Jesse Gross wrote:
>> On Wed, Jul 13, 2016 at 4:04 AM, Brady Allen Johnson
>> wrote:
>> > I wanted to mention though, currently the type 2 metadata (MD2) isnt a top
>> > priority for us.
Hi Jesse,
On Wed, Jul 13, 2016 at 07:35:59AM -0700, Jesse Gross wrote:
> On Wed, Jul 13, 2016 at 4:04 AM, Brady Allen Johnson
> wrote:
> > I wanted to mention though, currently the type 2 metadata (MD2) isnt a top
> > priority for us. It looks like its already been investigated how to use some
>
On Thu, Jul 21, 2016 at 3:40 PM, Jan Scheurich
wrote:
> 1. The pending question whether to model NSH headers as packet header match
> fields, metadata fields, or both applies in particular to the MD2 TLVs.
>
> We have three main OpenFlow use cases for the MD2 TLVs:
> a) Match on an MD2 TLV of an
Hi,
I agree that we should go ahead with implementing support for MD2 while we are
doing NSH. There are planned use cases that will depend on MD2, like an SFF
load-sharing between SF instances based on an entropy TLV option.
But there are in fact a number of technical issues that need to be sor
AM
To: Paul Quinn (paulq)
Cc: dev@openvswitch.org; Manuel Buil; Wei Su (Su); Jiri Benc; László Sürü;
Thomas F Herbert; nick.tausanovi...@netronome.com
Subject: Re: [ovs-dev] [RFC PATCH v2 00/13] Add Network Service Header Support
On Wed, Jul 20, 2016 at 5:06 PM, Paul Quinn (paulq) wrote:
>
>
On Wed, Jul 20, 2016 at 5:06 PM, Paul Quinn (paulq) wrote:
>
>> On Jul 14, 2016, at 11:39 AM, Jesse Gross wrote:
>>
>> On Wed, Jul 13, 2016 at 10:44 PM, Elzur, Uri wrote:
>>> +1 on starting w MD Type = 1
>>>
>>> Not sure I understand the concern expressed with " implementations that
>>> don't i
hnson; dev@openvswitch.org
> Cc: Manuel Buil; László Sürü
> Subject: RE: [ovs-dev] [RFC PATCH v2 00/13] Add Network Service Header
> Support
>
> Jan, although NSH isn't tunnel, but we still need to do some matches after
> pop_nsh, this is similar to vxlan tunnel, we still c
> On Jul 14, 2016, at 11:39 AM, Jesse Gross wrote:
>
> On Wed, Jul 13, 2016 at 10:44 PM, Elzur, Uri wrote:
>> +1 on starting w MD Type = 1
>>
>> Not sure I understand the concern expressed with " implementations that
>> don't implement TLVs will become deployed and then when there is a use f
ields.
-Original Message-
From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Jan Scheurich
Sent: Friday, July 15, 2016 6:27 PM
To: Jan Scheurich ; Li, Johnson
; dev@openvswitch.org
Cc: Manuel Buil ; László Sürü
Subject: Re: [ovs-dev] [RFC PATCH v2 00/13] Add Network Service Header Su
ch
> Cc: dev@openvswitch.org
> Subject: Re: [ovs-dev] [RFC PATCH v2 00/13] Add Network Service Header
> Support
>
> On Tue, Jul 19, 2016 at 5:48 PM, Jan Scheurich
> wrote:
> > I hate to be pestering but I believe the answer to the question below will
> have significant impact on
On Tue, Jul 19, 2016 at 5:48 PM, Jan Scheurich
wrote:
> I hate to be pestering but I believe the answer to the question below will
> have significant impact on the design of the NSH patch as well as the way SDN
> controllers can use NSH. So could the OVS maintainers please have a look and
> pro
I hate to be pestering but I believe the answer to the question below will have
significant impact on the design of the NSH patch as well as the way SDN
controllers can use NSH. So could the OVS maintainers please have a look and
provide feedback?
Thanks a lot, Jan
> -Original Message-
It would be great if we could get guidance by the OVS committers on below
question whether to model NSH fields as packet header match fields or as metada
fields or both.
Right now patch v2 mixes those and uses the same set of NXM fields both when
matching packet headers of an NSH packet and as
On Thu, Jul 14, 2016 at 07:45:06AM -0700, Jesse Gross wrote:
> >
> > Currently, struct tun_metadata in struct flow_tnl.
> >
> > /* Tunnel information used in flow key and metadata. */
> > struct flow_tnl {
> > ovs_be32 ip_dst;
> > struct in6_addr ipv6_dst;
> > ovs_be32 ip_src;
> > s
On Thu, Jul 14, 2016 at 10:53 AM, Elzur, Uri wrote:
> Jesse
>
> So maybe it is just me, but I really don't get the similarity w IPv4 options.
> Both Geneve and NSH have TLV options. I have not seen a definition of the
> Geneve TLV format either (pls excuse me if I have missed it, and pls point m
l.org]
Sent: Thursday, July 14, 2016 8:40 AM
To: Elzur, Uri
Cc: Thomas F Herbert ; Jiri Benc ;
dev@openvswitch.org; Manuel Buil ; su@huawei.com;
László Sürü ; Paul Quinn (paulq) ;
nick.tausanovi...@netronome.com
Subject: Re: [ovs-dev] [RFC PATCH v2 00/13] Add Network Service Header Suppor
On Wed, Jul 13, 2016 at 10:44 PM, Elzur, Uri wrote:
> +1 on starting w MD Type = 1
>
> Not sure I understand the concern expressed with " implementations that don't
> implement TLVs will become deployed and then when there is a use for them
> it's no longer possible." - why will it not be possi
On Wed, Jul 13, 2016 at 7:56 PM, Yang, Yi wrote:
> On Wed, Jul 13, 2016 at 07:22:39PM -0700, Jesse Gross wrote:
>> >>
>> >> In any case, I don't think this is a fundamental issue, just a matter
>> >> of timing. Since the premise of the original question was that MD type
>> >> 2 shouldn't be too mu
q)
; nick.tausanovi...@netronome.com
Subject: Re: [ovs-dev] [RFC PATCH v2 00/13] Add Network Service Header Support
On 7/13/16 10:55 AM, Jiri Benc wrote:
> On Wed, 13 Jul 2016 07:35:59 -0700, Jesse Gross wrote:
>> I think history tells us how this will end - similar to IPv4 options,
>> implem
>
> Please see previous comments in this thread, such as this one:
> http://openvswitch.org/pipermail/dev/2016-July/074980.html
>
We are trying to remove the dependency on Simon's patch set, but we have
similar implementation for the datapath, this is duplicated effort.
So we have to wait for Si
On Wed, Jul 13, 2016 at 07:22:39PM -0700, Jesse Gross wrote:
> >>
> >> In any case, I don't think this is a fundamental issue, just a matter
> >> of timing. Since the premise of the original question was that MD type
> >> 2 shouldn't be too much additional work and the series is currently
> >> depe
On Wed, Jul 13, 2016 at 6:38 PM, Yang, Yi wrote:
> On Wed, Jul 13, 2016 at 09:59:34AM -0700, Jesse Gross wrote:
>> On Wed, Jul 13, 2016 at 7:55 AM, Jiri Benc wrote:
>> > On Wed, 13 Jul 2016 07:35:59 -0700, Jesse Gross wrote:
>> >> I think history tells us how this will end - similar to IPv4 optio
On Wed, Jul 13, 2016 at 09:59:34AM -0700, Jesse Gross wrote:
> On Wed, Jul 13, 2016 at 7:55 AM, Jiri Benc wrote:
> > On Wed, 13 Jul 2016 07:35:59 -0700, Jesse Gross wrote:
> >> I think history tells us how this will end - similar to IPv4 options,
> >> implementations that don't implement TLVs will
The push_nsh action creates a non-Ethernet packet in the OF pipeline, which is
not at all supported by OVS prior to Simon's patch. It is not good enough to
promise that an SFC controller will always send a push_eth action right next to
fix this.
A new action in OVS must be sane in the sense tha
Please see previous comments in this thread, such as this one:
http://openvswitch.org/pipermail/dev/2016-July/074980.html
On Wed, Jul 13, 2016 at 10:06 AM, Brady Allen Johnson
wrote:
> Is the current implementation really dependent on Simon's patch?
>
> I understood that the current implementatio
Is the current implementation really dependent on Simon's patch?
I understood that the current implementation is for ethernet+NSH and
VXLAN+ethernet+NSH which doesnt require Simon's patch. Simon's patch
would be needed for VXLAN-GPE+NSH, which is not in this implementation.
Maybe the authors c
On Wed, Jul 13, 2016 at 7:55 AM, Jiri Benc wrote:
> On Wed, 13 Jul 2016 07:35:59 -0700, Jesse Gross wrote:
>> I think history tells us how this will end - similar to IPv4 options,
>> implementations that don't implement TLVs will become deployed and
>> then when there is a use for them it's no lon
On 7/13/16 10:55 AM, Jiri Benc wrote:
On Wed, 13 Jul 2016 07:35:59 -0700, Jesse Gross wrote:
I think history tells us how this will end - similar to IPv4 options,
implementations that don't implement TLVs will become deployed and
then when there is a use for them it's no longer possible. Since
On Wed, 13 Jul 2016 07:35:59 -0700, Jesse Gross wrote:
> I think history tells us how this will end - similar to IPv4 options,
> implementations that don't implement TLVs will become deployed and
> then when there is a use for them it's no longer possible. Since I
> don't want OVS to have a half im
On Wed, Jul 13, 2016 at 4:04 AM, Brady Allen Johnson
wrote:
> I wanted to mention though, currently the type 2 metadata (MD2) isnt a top
> priority for us. It looks like its already been investigated how to use some
> existing OVS TLV code to implement this, so it should be easy to add MD2 in
> th
y comments are welcome.
Regards, Jan
-Original Message-
From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Johnson Li
Sent: Tuesday, 12 July, 2016 19:26
To:dev@openvswitch.org
Subject: [ovs-dev] [RFC PATCH v2 00/13] Add Network Service Header
Support
IETF draft at:
https://t
>eth_dst,output:4
Any comments are welcome.
Regards, Jan
> -Original Message-
> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Johnson Li
> Sent: Tuesday, 12 July, 2016 19:26
> To: dev@openvswitch.org
> Subject: [ovs-dev] [RFC PATCH v2 00/13] Add
On Wed, 13 Jul 2016 01:25:45 +0800, Johnson Li wrote:
> In order to support NSH without depending on Simon's patch, we
> introduced new flow actions push_eth and pop_eth to support the
> Ethernet as a NSH transport.
That doesn't make any sense. Please build this on top of Simon's
patchset.
Jiri
> -Original Message-
> From: Li, Johnson
> Sent: Wednesday, July 13, 2016 1:26 AM
> To: dev@openvswitch.org
> Cc: Li, Johnson
> Subject: [RFC PATCH v2 00/13] Add Network Service Header Support
>
> ---
> Change Log:
> V1->V2: 1. Add prototype for MD type 2 support. Since the MD type 2
>
IETF draft at:
https://tools.ietf.org/html/draft-ietf-sfc-nsh-01
defines a new protocol named Network Service Header (NSH) for
Service Function Chaining. The NSH format looks like below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|C|R|R|R|R|R|R|Length |
35 matches
Mail list logo