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
