It doesn't matter. I was just confused. :-) --Justin
> On Jan 29, 2016, at 10:02 PM, Darrell Ball <db...@vmware.com> wrote: > > I noticed the sender issue Justin, but was busy in early evening, so did not > fix it > > Thanks > Darrell Ball > > > > > >> On 1/29/16, 7:23 PM, "dev on behalf of Justin Pettit" >> <dev-boun...@openvswitch.org on behalf of jpet...@ovn.org> wrote: >> >> This seems to be coming from "Darrell Lu"? Is that on purpose? It looks like >> you may have added your own "OVS-dev", but that's not necessary--Mailman >> will take care of it. >> >> --Justin >> >> >>> On Jan 29, 2016, at 6: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. >>> 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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
