The solution presented so far breaks OVN current and planned features. If you have a solution that doesn't break OVN current or planned features, let's talk about it. Until then, it is not interesting.
On Tue, May 09, 2017 at 09:29:07AM +0800, [email protected] wrote: > Hi Ben and Mikey, thank you for your review and analysis. > > As we discribed below, vxlan is used very common, and the use case that we > mentioned below is typical architecture of telecom operators' networks. > So, we think it is very necessary to support vxlan between ovs and HW > switch. If ovn does not support the use case we discribed before, we think > the the > ovn features may be imperfect. For this reason, we do the changes as this > patch. > > Because vxlan tunnel can not carry enough information like genev to > fulfill ovn current pipeline, so we do some assumptions. As Michkey and > Ben said, > these assumptions may not hold going forward, such as S_SWITCH_IN_L2_LKUP > and more than one chassisredirect ports and so on. > > We think these incompatibles are not impossibly hard problems. If we have > the consensus of the necessity to support vxlan, we think we could > together > to talk over a blueprint that less influence of current planning features > and more effective to solve the problem we mentioned. > > Waiting for your suggestions,Thanks > > > > > > > Mickey Spiegel <[email protected]> > 发件人： [email protected] > 2017/05/08 04:58 > > 收件人： [email protected], > 抄送： ovs dev <[email protected]>, > [email protected] > 主题： Re: [ovs-dev] 答复: Re: 答复: Re: [PATCH] > ovn-controller: Support vxlan tunnel in ovn > > > There are some assumptions that you are making which need to be called > out. > These assumptions may not hold going forward. In fact I refer to two > different patches below that are currently under review, that break your > assumptions. > > On Fri, May 5, 2017 at 7:18 PM, <[email protected]> wrote: > > > Hi,Russell > > > > We think vxlan is the most commonly used tunnel encapsulation in the > > overlay network openstack,ovn should better consider it. > > > > As my workmate wang qianyu said,we would consider computer node connect > > with existing hardware switches which associates with SR-IOV as VTEP. > > > > After discussion, we feel that as long as the following changes for > vxlan > > tunnel in the table0: > > > > 1.For local switch, move MFF_TUN_ID to MFF_LOG_DATAPATH, resubmit to > > OFTABLE_ETH_UCAST(table29) > > > > It looks like you are overloading OFTABLE_ETH_UCAST that you define here > with S_SWITCH_IN_L2_LKUP in ovn/northd/ovn-northd.c. Hardcoding the value > to 29 in ovn/controller/lflow.h is not the way to do this. This pipeline > stage does move back as new features are added. In fact it is now table 31 > due to the recent addition of 2 tables for DNS lookup. > > > > //---In table29, we can find out dst port based on dst mac > > > > You are assuming that outport determination is only based on > S_SWITCH_IN_L2_LKUP with no impact from any other ingress pipeline stages. > This may not always be true, which I think is the point of Ben's > complaint. > For example the SFC patch that is currently under review ( > http://patchwork.ozlabs.org/patch/754427/) may set outport and then do > "output" in the ingress pipeline, in a pipeline stage other than > S_SWITCH_IN_L2_LKUP. > > The alternative is to go through the entire ingress pipeline, but here you > have a problem since you do not know the inport. The current VTEP-centric > VXLAN code assumes that there is only one port binding per datapath from > the VTEP chassis. For the general case that you are trying to address, > this > assumption does not hold, so you cannot properly determine the inport. The > inport may affect the ultimate decision on outport. This is certainly the > case for the SFC patch currently under review. > > You are also assuming that inport does not affect anything in the egress > pipeline. This seems to be true at the moment, but this might not always > be > true as features are added. > > The existing VTEP functionality does not rely on the assumptions that you > made, but since you changed the logic to determine inport in case of > VXLAN, > you are changing existing functionality. > > > > 2.For local chassisredirect port, move MFF_TUN_ID to MFF_LOG_DATAPATH, > set > > port tunnel_key to MFF_LOG_OUTPORT and then resubmit to > > OFTABLE_LOCAL_OUTPUT. > > //---In table 33, we can find out dst local sw and sw patch port based > on > > the local chassisredirect port,and then follow the exsiting flows. > > > > At the moment, the only case where a tunnel is used for a datapath > representing a logical router is when the outport is a chassisredirect > port. Your code assumes that will always be the case. If we do what you > are > suggesting, then that becomes a restriction for all logical router > features > going forward. > > This code also assumes that there can only be one chassisredirect port per > datapath per chassis. There is a patch that has not yet been reviewed ( > http://patchwork.ozlabs.org/patch/732815/) that proposes multiple > distributed gateway ports (and correspondingly chassisredirect ports) on > one datapath. I am not sure what the use case is, but if that feature were > added and more than one distributed gateway port on one datapath specified > the same redirect-chassis, it would break this code. > > This version of the code is better than the original version, which was > based on a hack that used table 29 on a datapath for a logical router > (!!!), adding contrived flows that matched VXLAN tunnel bit, metadata == > datapath->tunnel_key, and MAC address from the SB MAC_Binding table in > order to set the outport to a chassisredirect port, based on the > assumption > that tunnels are only used for logical routers when the outport is a > chassisredirect port. > > Mickey > > > > > Next step, we will consider how ovn-controller-hw manages SR-IOV as > well. > > > > Waiting for your suggestions,Thanks. > > > > --- > > ovn/controller/lflow.h | 1 + > > ovn/controller/physical.c | 17 +++++++++++++---- > > 2 files changed, 14 insertions(+), 4 deletions(-) > > > > diff --git a/ovn/controller/lflow.h b/ovn/controller/lflow.h > > index 4f284a0..418f59e 100644 > > --- a/ovn/controller/lflow.h > > +++ b/ovn/controller/lflow.h > > @@ -50,6 +50,7 @@ struct uuid; > > * you make any changes. */ > > #define OFTABLE_PHY_TO_LOG 0 > > #define OFTABLE_LOG_INGRESS_PIPELINE 16 /* First of LOG_PIPELINE_LEN > > tables. */ > > +#define OFTABLE_ETH_UCAST 29 > > #define OFTABLE_REMOTE_OUTPUT 32 > > #define OFTABLE_LOCAL_OUTPUT 33 > > #define OFTABLE_CHECK_LOOPBACK 34 > > diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c > > index 0f1aa63..d34140f 100644 > > --- a/ovn/controller/physical.c > > +++ b/ovn/controller/physical.c > > @@ -963,9 +963,9 @@ physical_run(struct controller_ctx *ctx, enum > > mf_field_id mff_ovn_geneve, > > > > SBREC_PORT_BINDING_FOR_EACH (binding, ctx->ovnsb_idl) { > > struct match match = MATCH_CATCHALL_INITIALIZER; > > - > > + /* here need to optimize to do only once for every datapath > > */ > > if (!binding->chassis || > > - strcmp(tun->chassis_id, binding->chassis->name)) { > > + binding->chassis != chassis) { > > continue; > > } > > > > @@ -974,11 +974,20 @@ physical_run(struct controller_ctx *ctx, enum > > mf_field_id mff_ovn_geneve, > > > > ofpbuf_clear(&ofpacts); > > put_move(MFF_TUN_ID, 0, MFF_LOG_DATAPATH, 0, 24, > &ofpacts); > > - put_load(binding->tunnel_key, MFF_LOG_INPORT, 0, 15, > > &ofpacts); > > /* For packets received from a vxlan tunnel, set a flag to > > that > > * effect. */ > > put_load(1, MFF_LOG_FLAGS, MLF_RCV_FROM_VXLAN_BIT, 1, > > &ofpacts); > > - put_resubmit(OFTABLE_LOG_INGRESS_PIPELINE, &ofpacts); > > + if (!strcmp(binding->type, "chassisredirect")) > > + { > > + put_load(binding->tunnel_key, MFF_LOG_OUTPORT, 0, 16, > > &ofpacts); > > + put_resubmit(OFTABLE_LOCAL_OUTPUT, &ofpacts); > > + } > > + else > > + { > > + put_resubmit(OFTABLE_ETH_UCAST, &ofpacts); > > + } > > > > ofctrl_add_flow(flow_table, OFTABLE_PHY_TO_LOG, 100, 0, > > &match, > > &ofpacts); > > -- > > > > > > > > > > > > 发件人: 王前宇10110202/user/zte_ltd > > 收件人: Russell Bryant <[email protected]>, > > 抄送: Ben Pfaff <[email protected]>, ovs dev <[email protected]>, > > [email protected], xurong00037997 <[email protected]> > > 日期: 2017/05/05 09:30 > > 主题: 答复: Re: [ovs-dev] 答复: Re: [PATCH] ovn-controller: Support > > vxlan tunnel in ovn > > > > > > We want to use ovn in the scenary that ovs-computer node and sriov > > computer node all managed by openstack. > > However, in our analysis that ovn-controller-vtep could only be used to > > forwards traffic between networks managed by openstack and physical > > network openstack not managed. > > Do we misunderstand of the use of ovn-controller-vtep? > > Thanks, > > > > > > > > > > > > > > Russell Bryant <[email protected]> > > 2017/05/05 02:12 > > > > 收件人： Ben Pfaff <[email protected]>, > > 抄送： [email protected], ovs dev <[email protected]>, > > xurong00037997 <[email protected]>, [email protected] > > 主题： Re: [ovs-dev] 答复: Re: [PATCH] ovn-controller: Support > > vxlan tunnel in ovn > > > > > > ovn-controller-vtep is discussed in the "Life Cycle of a VTEP Gateway" > > section in ovn-architecture(7). > > > > http://openvswitch.org/support/dist-docs/ovn-architecture.7.html > > > > On Thu, May 4, 2017 at 12:41 PM, Ben Pfaff <[email protected]> wrote: > > > OVS already has a VXLAN hardware switch story via ovn-controller-vtep. > > > > > > On Thu, May 04, 2017 at 07:51:01PM +0800, [email protected] > wrote: > > >> In most telecom carriers network architecture, they may demand > hardware > > >> switches for performance consideration. > > >> The network architecture is as follow: > > >> > > >> --------------- > > >> | ovn-sb | > > >> --------------- > > >> | | > > >> | | > > >> -------------- ----------------- > > >> |ovn-controller| |ovn-controller-hw| > > >> --------------- ------------------ > > >> | | | > > >> ---------------- ------------------ > > >> | | | hardware switch | > > >> | | ------------------- > > >> | ovs | | > > >> |computer node | |----------------| > > >> | | | sriov | > > >> | | | | > > >> |--------------| | computer node | > > >> ------------------ > > >> Now, most hardware switches only support vxlan encapsulation. So we > > think > > >> if ovn could support vxlan > > >> encapsulation will be better. this is the reason that why we do the > > modify > > >> as the patch. > > >> Now, ovn used for the scenary of hardware-switches link to sriov > > >> network-card is very difficult, > > >> and we want do more works for ovn-controller-hw to support hardware > > >> switch. > > >> Do have some good idea about this scenary? > > >> Thanks > > >> > > >> > > >> > > >> > > >> > > >> Russell Bryant <[email protected]> > > >> 发件人： [email protected] > > >> 2017/05/04 10:57 > > >> > > >> 收件人： xurong00037997 <[email protected]>, > > >> 抄送： ovs dev <[email protected]> > > >> 主题： Re: [ovs-dev] [PATCH] ovn-controller: Support vxlan > > tunnel > > >> in ovn > > >> > > >> > > >> On Wed, May 3, 2017 at 10:17 PM, xurong00037997 <[email protected]> > > >> wrote: > > >> > Because vxlan envelope have no enough fields to carry pipeline > > >> information > > >> > between ovs, so current ovn version do not support vxlan tunnel. > > >> > However, may only vxlan tunnel can be used in some special > scenario. > > so > > >> we > > >> > think it is necessary to implement the function of vxlan. For this > > >> > purpose, we do the modifications as follow: > > >> > 1. packets received from vxlan jump to table 29 for outport > > finding > > >> > 2. add mac-binding information to table 29 > > >> > --- > > >> > ovn/controller/lflow.c | 51 > > >> +++++++++++++++++++++++++++++++++++++++++++++++ > > >> > ovn/controller/lflow.h | 1 + > > >> > ovn/controller/physical.c | 9 +++++---- > > >> > 3 files changed, 57 insertions(+), 4 deletions(-) > > >> > mode change 100644 => 100755 ovn/controller/lflow.c > > >> > mode change 100644 => 100755 ovn/controller/lflow.h > > >> > mode change 100644 => 100755 ovn/controller/physical.c > > >> > > > >> > > >> I'm interested in how you concluded that VXLAN support was needed. > > >> I've been looking at this question pretty extensively and have not > > >> been able to find any good justification for why VXLAN support should > > >> be added to OVN. > > >> > > >> Can you expand on what special scenarios you have in mind? > > >> > > >> Thanks, > > >> > > >> -- > > >> Russell Bryant > > >> _______________________________________________ > > >> dev mailing list > > >> [email protected] > > >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > >> > > >> > > >> > > >> _______________________________________________ > > >> dev mailing list > > >> [email protected] > > >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > > _______________________________________________ > > > dev mailing list > > > [email protected] > > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > > > > > > > -- > > Russell Bryant > > > > > > > > _______________________________________________ > > dev mailing list > > [email protected] > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
