On 2/15/16, 11:24 AM, "dev on behalf of Kyle Mestery"
<dev-boun...@openvswitch.org on behalf of mest...@mestery.com> wrote:
>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
Just Catching up on e-mails
Thanks for the info. Kyle
I did not intend to suggest excluding Vxlan VNIs
IP tunnels mentioned in the type text, include Vxlan tunnels and
could include more than just Vxlan VNI encap
Is your requirement only for VNI specification or specifying a complete Vxlan
tunnel encap ?
>
>> 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
