On Fri, Jan 29, 2016 at 8:36 PM, Darrell Lu <dlu...@gmail.com> wrote: > The following is a proposal regarding how to allow logical > and physical endpoint contexts for OVN to stay separated, from > a CMS POV. > > A logical endpoint has the form: ls1-port1. > A physical endpoint has the general form: > chassis/physical port or location on chassis/encapsulation. > > Some advantages for cleanly separating logical and physical > layers are: > > 1) Logical and physical domains can be managed separately; for > example, by different companies or business units, with minimal > interaction overhead. > > 2)The physical layer details can change without needing to > change the logical layer; for example, a physical endpoint > vlan can change without needing to change the logical layer, > which in OVN resides in the NB DB. > The physical endpoint encapsulations can even change in future, > without needing to update the NB DB supported options and/or > churning the NB DB. > > 3) The logical configuration remains simple in that it just needs > to concern itself with tasks such linking users to services, > without too much concern about where the services > or users are presently located. > > > A physical topology CMS or sub-component of a CMS can be > used to configure physical endpoints in the SB DB directly, > bypassing the NB DB and northd processing. > > > A new Physical_Endpoint table describes endpoints used to reach a > physical network only, including localnet and gateway cases. > > > This physical topology CMS would write to this new table. > > Physical_Endpoint TABLE > > Summary: > Core Features: > name string (must be unique within table) > chassis chassis record > chassis_port string > type string > ingress_encap string > egress_encap string > > > Details: > Core Features: > name: string (must be unique within table) > A physical_endpoint name which can be used to describe > its > connection role. > chassis: chassis record. > chassis_port: string > Physical port with the context the associated chassis. > type: string, can be single vlan, which is presently supported. > In future, a tunnel type such as MPLS/IP tunnels or > multiple vlans might be used. Nomenclature is TBD.
Is there any reason to restrict this to a VLAN from the start? If we allow it to be a VXLAN VNI, we could in theory make use of VXLAN tunnels for these as well as VLANs. This would help us to solve this requested feature in Neutron [1] for example, which is to support VXLAN encap for external routers in addition to VLANs. [1] https://bugs.launchpad.net/neutron/+bug/1525059 > ingress_encap: string > Encapsulation expected for packets received on this > physical endpoint. Incorrect encapsulation will > result in packet drop. > egress_encap: string > Encapsulation used for packets transmitted on this > physical endpoint. > If type is vlan, ingress_encap == egress_encap as > per existing OVN expected behavior. > > A new ovn-sbctl command can be used in lieu of CMS support. > > ovn-sbctl phys-endpt-add phys_endpt_name chassis_name chassis_port type > ingress_encap egress_encap > > > The existing Port Binding table is modified for localnet and gateway cases. > options : phys_endpt was added for gateways. > options : phys_endpt replaces tag for localnet. > Note that there is some redundancy in information, as phys_endpt > includes chassis and there is a separate column for chassis in the > Port Binding table. > > Port_Binding TABLE > . > . > . > > Summary: > Core Features: > datapath Datapath_Binding > logical_port string (must be unique within table) > chassis optional weak reference to Chassis > tunnel_key integer, in range 1 to 32,767 > mac set of strings > type string > Patch Options: > options : peer optional string > Localnet Options: > options : network_name optional string > options : phys_endpt optional physical endpoint record > VTEP Options: > options : vtep-physical-switch > optional string > options : vtep-logical-switch > optional string > options : phys_endpt optional physical endpoint record > Nested Containers: > parent_port optional string > tag optional integer, in range 1 to 4,095 > . > . > . > Details: > Localnet Options: > These options apply to logical ports with type of localnet. > > options : phys_endpt: optional physical endpoint record > Used to derive physical port, ingress encapsulations > and egress encapsulations. > . > . > VTEP Options: > These options apply to logical ports with type of vtep. > > options : phys_endpt: optional physical endpoint record > Used to derive physical port, ingress encapsulations > and egress encapsulations. > . > . > . > > The existing ovn-sbctl lport-bind command syntax is not modified so as not > to impact existing HV support. This may be TBD. > > A new ovn-sbctl command is added for use in localnet and gateway cases. > The below command should be used in place of ovn-sbctl lport-bind for > localnet and gateway cases. > > ovn-sbctl lport-bind-phys-endpt logical-port phys-endpt-name > > [--may-exist] lport-bind-phys-endpt logical-port phys-endpt-name > Binds the logical port named logical-port to phys-endpt. > > Without --may-exist, attempting to bind a logical port that > has > already been bound is an error. With --may-exist, this > command > does nothing if logical-port has already been bound to a > phys-endpt. > > [--if-exists] lport-unbind-phys-endpt logical-port phys-endpt-name > Resets the binding of logical-port to NULL. > > Without --if-exists, attempting to unbind a logical port that > is > not bound is an error. With --if-exists, attempting to > unbind > logical port that is not bound has no effect. > > Darrell > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
