Re: [ovs-dev] [PATCH v7 3/7] ovn: Introduce "chassisredirect" port binding

[Mickey Spiegel]

On Fri, Jan 13, 2017 at 4:21 PM, Ben Pfaff  wrote:

> On Fri, Jan 13, 2017 at 02:19:21PM -0800, Mickey Spiegel wrote:
> > On Thu, Jan 12, 2017 at 5:12 PM, Mickey Spiegel 
> > wrote:
> >
> > >
> > > On Sun, Jan 8, 2017 at 10:30 PM, Mickey Spiegel  >
> > > wrote:
> > >
> > >>
> > >> On Fri, Jan 6, 2017 at 8:31 PM, Mickey Spiegel  >
> > >> wrote:
> > >>
> > >>>
> > >>> On Fri, Jan 6, 2017 at 4:21 PM, Mickey Spiegel <
> mickeys@gmail.com>
> > >>> wrote:
> > >>>
> > 
> >  On Fri, Jan 6, 2017 at 4:11 PM, Ben Pfaff  wrote:
> > 
> > > On Fri, Jan 06, 2017 at 03:47:03PM -0800, Mickey Spiegel wrote:
> > > > On Fri, Jan 6, 2017 at 3:20 PM, Ben Pfaff  wrote:
> > > >
> > > > > On Fri, Jan 06, 2017 at 12:00:30PM -0800, Mickey Spiegel wrote:
> > > > > > Currently OVN handles all logical router ports in a
> distributed
> > > manner,
> > > > > > creating instances on each chassis.  The logical router
> ingress
> > > and
> > > > > > egress pipelines are traversed locally on the source chassis.
> > > > > >
> > > > > > In order to support advanced features such as one-to-many NAT
> > > (aka IP
> > > > > > masquerading), where multiple private IP addresses spread
> across
> > > > > > multiple chassis are mapped to one public IP address, it
> will be
> > > > > > necessary to handle some of the logical router processing on
> a
> > > specific
> > > > > > chassis in a centralized manner.
> > > > > >
> > > > > > The goal of this patch is to develop abstractions that allow
> for
> > > a
> > > > > > subset of router gateway traffic to be handled in a
> centralized
> > > manner
> > > > > > (e.g. one-to-many NAT traffic), while allowing for other
> subsets
> > > of
> > > > > > router gateway traffic to be handled in a distributed manner
> > > (e.g.
> > > > > > floating IP traffic).
> > > > > >
> > > > > > This patch introduces a new type of SB port_binding called
> > > > > > "chassisredirect".  A "chassisredirect" port represents a
> > > particular
> > > > > > instance, bound to a specific chassis, of an otherwise
> > > distributed
> > > > > > port.  The ovn-controller on that chassis populates the
> "chassis"
> > > > > > column for this record as an indication for other
> > > ovn-controllers of
> > > > > > its physical location.  Other ovn-controllers do not treat
> this
> > > port
> > > > > > as a local port.
> > > > > >
> > > > > > A "chassisredirect" port should never be used as an "inport".
> > > When an
> > > > > > ingress pipeline sets the "outport", it may set the value to
> a
> > > logical
> > > > > > port of type "chassisredirect".  This will cause the packet
> to be
> > > > > > directed to a specific chassis to carry out the egress
> logical
> > > router
> > > > > > pipeline, in the same way that a logical switch forwards
> egress
> > > traffic
> > > > > > to a VIF port residing on a specific chassis.  At the
> beginning
> > > of the
> > > > > > egress pipeline, the "outport" will be reset to the value of
> the
> > > > > > distributed port.
> > > > > >
> > > > > > For outbound traffic to be handled in a centralized manner,
> the
> > > > > > "outport" should be set to the "chassisredirect" port
> > > representing
> > > > > > centralized gateway functionality in the otherwise
> distributed
> > > router.
> > > > > > For outbound traffic to be handled in a distributed manner,
> > > locally on
> > > > > > the source chassis, the "outport" should be set to the
> existing
> > > "patch"
> > > > > > port representing distributed gateway functionality.
> > > > > >
> > > > > > Inbound traffic will be directed to the appropriate chassis
> by
> > > > > > restricting source MAC address usage and ARP responses to
> that
> > > chassis,
> > > > > > or by running dynamic routing protocols.
> > > > > >
> > > > > > Note that "chassisredirect" ports have no associated IP or
> MAC
> > > addresses.
> > > > > > Any pipeline stages that depend on port specific IP or MAC
> > > addresses
> > > > > > should be carried out in the context of the distributed port.
> > > > > >
> > > > > > Although the abstraction represented by the "chassisredirect"
> > > port
> > > > > > binding is generalized, in this patch the "chassisredirect"
> port
> > > binding
> > > > > > is only created for NB logical router ports that specify the
> new
> > > > > > "redirect-chassis" option.  There is no explicit notion of a
> > > > > > "chassisredirect" port in the NB database.  The expectation
> is
> > > when
> > > > > > capabilities are implemented that take advantage of
> > > "chassisredirect"
> > > > > > 

Re: [ovs-dev] [PATCH v7 3/7] ovn: Introduce "chassisredirect" port binding

[Ben Pfaff]

On Fri, Jan 13, 2017 at 02:19:21PM -0800, Mickey Spiegel wrote:
> On Thu, Jan 12, 2017 at 5:12 PM, Mickey Spiegel 
> wrote:
> 
> >
> > On Sun, Jan 8, 2017 at 10:30 PM, Mickey Spiegel 
> > wrote:
> >
> >>
> >> On Fri, Jan 6, 2017 at 8:31 PM, Mickey Spiegel 
> >> wrote:
> >>
> >>>
> >>> On Fri, Jan 6, 2017 at 4:21 PM, Mickey Spiegel 
> >>> wrote:
> >>>
> 
>  On Fri, Jan 6, 2017 at 4:11 PM, Ben Pfaff  wrote:
> 
> > On Fri, Jan 06, 2017 at 03:47:03PM -0800, Mickey Spiegel wrote:
> > > On Fri, Jan 6, 2017 at 3:20 PM, Ben Pfaff  wrote:
> > >
> > > > On Fri, Jan 06, 2017 at 12:00:30PM -0800, Mickey Spiegel wrote:
> > > > > Currently OVN handles all logical router ports in a distributed
> > manner,
> > > > > creating instances on each chassis.  The logical router ingress
> > and
> > > > > egress pipelines are traversed locally on the source chassis.
> > > > >
> > > > > In order to support advanced features such as one-to-many NAT
> > (aka IP
> > > > > masquerading), where multiple private IP addresses spread across
> > > > > multiple chassis are mapped to one public IP address, it will be
> > > > > necessary to handle some of the logical router processing on a
> > specific
> > > > > chassis in a centralized manner.
> > > > >
> > > > > The goal of this patch is to develop abstractions that allow for
> > a
> > > > > subset of router gateway traffic to be handled in a centralized
> > manner
> > > > > (e.g. one-to-many NAT traffic), while allowing for other subsets
> > of
> > > > > router gateway traffic to be handled in a distributed manner
> > (e.g.
> > > > > floating IP traffic).
> > > > >
> > > > > This patch introduces a new type of SB port_binding called
> > > > > "chassisredirect".  A "chassisredirect" port represents a
> > particular
> > > > > instance, bound to a specific chassis, of an otherwise
> > distributed
> > > > > port.  The ovn-controller on that chassis populates the "chassis"
> > > > > column for this record as an indication for other
> > ovn-controllers of
> > > > > its physical location.  Other ovn-controllers do not treat this
> > port
> > > > > as a local port.
> > > > >
> > > > > A "chassisredirect" port should never be used as an "inport".
> > When an
> > > > > ingress pipeline sets the "outport", it may set the value to a
> > logical
> > > > > port of type "chassisredirect".  This will cause the packet to be
> > > > > directed to a specific chassis to carry out the egress logical
> > router
> > > > > pipeline, in the same way that a logical switch forwards egress
> > traffic
> > > > > to a VIF port residing on a specific chassis.  At the beginning
> > of the
> > > > > egress pipeline, the "outport" will be reset to the value of the
> > > > > distributed port.
> > > > >
> > > > > For outbound traffic to be handled in a centralized manner, the
> > > > > "outport" should be set to the "chassisredirect" port
> > representing
> > > > > centralized gateway functionality in the otherwise distributed
> > router.
> > > > > For outbound traffic to be handled in a distributed manner,
> > locally on
> > > > > the source chassis, the "outport" should be set to the existing
> > "patch"
> > > > > port representing distributed gateway functionality.
> > > > >
> > > > > Inbound traffic will be directed to the appropriate chassis by
> > > > > restricting source MAC address usage and ARP responses to that
> > chassis,
> > > > > or by running dynamic routing protocols.
> > > > >
> > > > > Note that "chassisredirect" ports have no associated IP or MAC
> > addresses.
> > > > > Any pipeline stages that depend on port specific IP or MAC
> > addresses
> > > > > should be carried out in the context of the distributed port.
> > > > >
> > > > > Although the abstraction represented by the "chassisredirect"
> > port
> > > > > binding is generalized, in this patch the "chassisredirect" port
> > binding
> > > > > is only created for NB logical router ports that specify the new
> > > > > "redirect-chassis" option.  There is no explicit notion of a
> > > > > "chassisredirect" port in the NB database.  The expectation is
> > when
> > > > > capabilities are implemented that take advantage of
> > "chassisredirect"
> > > > > ports (e.g. NAT), the addition of flows specifying a
> > "chassisredirect"
> > > > > port as the outport will also be triggered by the presence of the
> > > > > "redirect-chassis" option.  Such flows are added for NB logical
> > router
> > > > > ports that specify the "redirect-chassis" option.
> > > > >
> > 

Re: [ovs-dev] [PATCH v7 3/7] ovn: Introduce "chassisredirect" port binding

[Mickey Spiegel]

On Thu, Jan 12, 2017 at 5:12 PM, Mickey Spiegel 
wrote:

>
> On Sun, Jan 8, 2017 at 10:30 PM, Mickey Spiegel 
> wrote:
>
>>
>> On Fri, Jan 6, 2017 at 8:31 PM, Mickey Spiegel 
>> wrote:
>>
>>>
>>> On Fri, Jan 6, 2017 at 4:21 PM, Mickey Spiegel 
>>> wrote:
>>>

 On Fri, Jan 6, 2017 at 4:11 PM, Ben Pfaff  wrote:

> On Fri, Jan 06, 2017 at 03:47:03PM -0800, Mickey Spiegel wrote:
> > On Fri, Jan 6, 2017 at 3:20 PM, Ben Pfaff  wrote:
> >
> > > On Fri, Jan 06, 2017 at 12:00:30PM -0800, Mickey Spiegel wrote:
> > > > Currently OVN handles all logical router ports in a distributed
> manner,
> > > > creating instances on each chassis.  The logical router ingress
> and
> > > > egress pipelines are traversed locally on the source chassis.
> > > >
> > > > In order to support advanced features such as one-to-many NAT
> (aka IP
> > > > masquerading), where multiple private IP addresses spread across
> > > > multiple chassis are mapped to one public IP address, it will be
> > > > necessary to handle some of the logical router processing on a
> specific
> > > > chassis in a centralized manner.
> > > >
> > > > The goal of this patch is to develop abstractions that allow for
> a
> > > > subset of router gateway traffic to be handled in a centralized
> manner
> > > > (e.g. one-to-many NAT traffic), while allowing for other subsets
> of
> > > > router gateway traffic to be handled in a distributed manner
> (e.g.
> > > > floating IP traffic).
> > > >
> > > > This patch introduces a new type of SB port_binding called
> > > > "chassisredirect".  A "chassisredirect" port represents a
> particular
> > > > instance, bound to a specific chassis, of an otherwise
> distributed
> > > > port.  The ovn-controller on that chassis populates the "chassis"
> > > > column for this record as an indication for other
> ovn-controllers of
> > > > its physical location.  Other ovn-controllers do not treat this
> port
> > > > as a local port.
> > > >
> > > > A "chassisredirect" port should never be used as an "inport".
> When an
> > > > ingress pipeline sets the "outport", it may set the value to a
> logical
> > > > port of type "chassisredirect".  This will cause the packet to be
> > > > directed to a specific chassis to carry out the egress logical
> router
> > > > pipeline, in the same way that a logical switch forwards egress
> traffic
> > > > to a VIF port residing on a specific chassis.  At the beginning
> of the
> > > > egress pipeline, the "outport" will be reset to the value of the
> > > > distributed port.
> > > >
> > > > For outbound traffic to be handled in a centralized manner, the
> > > > "outport" should be set to the "chassisredirect" port
> representing
> > > > centralized gateway functionality in the otherwise distributed
> router.
> > > > For outbound traffic to be handled in a distributed manner,
> locally on
> > > > the source chassis, the "outport" should be set to the existing
> "patch"
> > > > port representing distributed gateway functionality.
> > > >
> > > > Inbound traffic will be directed to the appropriate chassis by
> > > > restricting source MAC address usage and ARP responses to that
> chassis,
> > > > or by running dynamic routing protocols.
> > > >
> > > > Note that "chassisredirect" ports have no associated IP or MAC
> addresses.
> > > > Any pipeline stages that depend on port specific IP or MAC
> addresses
> > > > should be carried out in the context of the distributed port.
> > > >
> > > > Although the abstraction represented by the "chassisredirect"
> port
> > > > binding is generalized, in this patch the "chassisredirect" port
> binding
> > > > is only created for NB logical router ports that specify the new
> > > > "redirect-chassis" option.  There is no explicit notion of a
> > > > "chassisredirect" port in the NB database.  The expectation is
> when
> > > > capabilities are implemented that take advantage of
> "chassisredirect"
> > > > ports (e.g. NAT), the addition of flows specifying a
> "chassisredirect"
> > > > port as the outport will also be triggered by the presence of the
> > > > "redirect-chassis" option.  Such flows are added for NB logical
> router
> > > > ports that specify the "redirect-chassis" option.
> > > >
> > > > Signed-off-by: Mickey Spiegel 
> > >
> > > chassisredirect ports seem incredibly similar to vif ports.  Is
> the only
> > > difference that the output port is changed at the beginning of the
> > > egress pipeline?  That's something that 

Re: [ovs-dev] [PATCH v7 3/7] ovn: Introduce "chassisredirect" port binding

[Mickey Spiegel]

On Fri, Jan 6, 2017 at 8:31 PM, Mickey Spiegel 
wrote:

>
> On Fri, Jan 6, 2017 at 4:21 PM, Mickey Spiegel 
> wrote:
>
>>
>> On Fri, Jan 6, 2017 at 4:11 PM, Ben Pfaff  wrote:
>>
>>> On Fri, Jan 06, 2017 at 03:47:03PM -0800, Mickey Spiegel wrote:
>>> > On Fri, Jan 6, 2017 at 3:20 PM, Ben Pfaff  wrote:
>>> >
>>> > > On Fri, Jan 06, 2017 at 12:00:30PM -0800, Mickey Spiegel wrote:
>>> > > > Currently OVN handles all logical router ports in a distributed
>>> manner,
>>> > > > creating instances on each chassis.  The logical router ingress and
>>> > > > egress pipelines are traversed locally on the source chassis.
>>> > > >
>>> > > > In order to support advanced features such as one-to-many NAT (aka
>>> IP
>>> > > > masquerading), where multiple private IP addresses spread across
>>> > > > multiple chassis are mapped to one public IP address, it will be
>>> > > > necessary to handle some of the logical router processing on a
>>> specific
>>> > > > chassis in a centralized manner.
>>> > > >
>>> > > > The goal of this patch is to develop abstractions that allow for a
>>> > > > subset of router gateway traffic to be handled in a centralized
>>> manner
>>> > > > (e.g. one-to-many NAT traffic), while allowing for other subsets of
>>> > > > router gateway traffic to be handled in a distributed manner (e.g.
>>> > > > floating IP traffic).
>>> > > >
>>> > > > This patch introduces a new type of SB port_binding called
>>> > > > "chassisredirect".  A "chassisredirect" port represents a
>>> particular
>>> > > > instance, bound to a specific chassis, of an otherwise distributed
>>> > > > port.  The ovn-controller on that chassis populates the "chassis"
>>> > > > column for this record as an indication for other ovn-controllers
>>> of
>>> > > > its physical location.  Other ovn-controllers do not treat this
>>> port
>>> > > > as a local port.
>>> > > >
>>> > > > A "chassisredirect" port should never be used as an "inport".
>>> When an
>>> > > > ingress pipeline sets the "outport", it may set the value to a
>>> logical
>>> > > > port of type "chassisredirect".  This will cause the packet to be
>>> > > > directed to a specific chassis to carry out the egress logical
>>> router
>>> > > > pipeline, in the same way that a logical switch forwards egress
>>> traffic
>>> > > > to a VIF port residing on a specific chassis.  At the beginning of
>>> the
>>> > > > egress pipeline, the "outport" will be reset to the value of the
>>> > > > distributed port.
>>> > > >
>>> > > > For outbound traffic to be handled in a centralized manner, the
>>> > > > "outport" should be set to the "chassisredirect" port representing
>>> > > > centralized gateway functionality in the otherwise distributed
>>> router.
>>> > > > For outbound traffic to be handled in a distributed manner,
>>> locally on
>>> > > > the source chassis, the "outport" should be set to the existing
>>> "patch"
>>> > > > port representing distributed gateway functionality.
>>> > > >
>>> > > > Inbound traffic will be directed to the appropriate chassis by
>>> > > > restricting source MAC address usage and ARP responses to that
>>> chassis,
>>> > > > or by running dynamic routing protocols.
>>> > > >
>>> > > > Note that "chassisredirect" ports have no associated IP or MAC
>>> addresses.
>>> > > > Any pipeline stages that depend on port specific IP or MAC
>>> addresses
>>> > > > should be carried out in the context of the distributed port.
>>> > > >
>>> > > > Although the abstraction represented by the "chassisredirect" port
>>> > > > binding is generalized, in this patch the "chassisredirect" port
>>> binding
>>> > > > is only created for NB logical router ports that specify the new
>>> > > > "redirect-chassis" option.  There is no explicit notion of a
>>> > > > "chassisredirect" port in the NB database.  The expectation is when
>>> > > > capabilities are implemented that take advantage of
>>> "chassisredirect"
>>> > > > ports (e.g. NAT), the addition of flows specifying a
>>> "chassisredirect"
>>> > > > port as the outport will also be triggered by the presence of the
>>> > > > "redirect-chassis" option.  Such flows are added for NB logical
>>> router
>>> > > > ports that specify the "redirect-chassis" option.
>>> > > >
>>> > > > Signed-off-by: Mickey Spiegel 
>>> > >
>>> > > chassisredirect ports seem incredibly similar to vif ports.  Is the
>>> only
>>> > > difference that the output port is changed at the beginning of the
>>> > > egress pipeline?  That's something that could be implemented in the
>>> > > logical egress pipeline with 'outport = "...";'.  We do say that the
>>> > > outport isn't supposed to be modified in an egress pipeline, but
>>> nothing
>>> > > enforces that and if it's actually useful then we could just change
>>> the
>>> > > documentation.
>>> > >
>>> >
>>> > I don't get the similarity to vif ports.
>>> >
>>> > I need to create two different ports for each logical 

Re: [ovs-dev] [PATCH v7 3/7] ovn: Introduce "chassisredirect" port binding

[Mickey Spiegel]

On Fri, Jan 6, 2017 at 4:21 PM, Mickey Spiegel 
wrote:

>
> On Fri, Jan 6, 2017 at 4:11 PM, Ben Pfaff  wrote:
>
>> On Fri, Jan 06, 2017 at 03:47:03PM -0800, Mickey Spiegel wrote:
>> > On Fri, Jan 6, 2017 at 3:20 PM, Ben Pfaff  wrote:
>> >
>> > > On Fri, Jan 06, 2017 at 12:00:30PM -0800, Mickey Spiegel wrote:
>> > > > Currently OVN handles all logical router ports in a distributed
>> manner,
>> > > > creating instances on each chassis.  The logical router ingress and
>> > > > egress pipelines are traversed locally on the source chassis.
>> > > >
>> > > > In order to support advanced features such as one-to-many NAT (aka
>> IP
>> > > > masquerading), where multiple private IP addresses spread across
>> > > > multiple chassis are mapped to one public IP address, it will be
>> > > > necessary to handle some of the logical router processing on a
>> specific
>> > > > chassis in a centralized manner.
>> > > >
>> > > > The goal of this patch is to develop abstractions that allow for a
>> > > > subset of router gateway traffic to be handled in a centralized
>> manner
>> > > > (e.g. one-to-many NAT traffic), while allowing for other subsets of
>> > > > router gateway traffic to be handled in a distributed manner (e.g.
>> > > > floating IP traffic).
>> > > >
>> > > > This patch introduces a new type of SB port_binding called
>> > > > "chassisredirect".  A "chassisredirect" port represents a particular
>> > > > instance, bound to a specific chassis, of an otherwise distributed
>> > > > port.  The ovn-controller on that chassis populates the "chassis"
>> > > > column for this record as an indication for other ovn-controllers of
>> > > > its physical location.  Other ovn-controllers do not treat this port
>> > > > as a local port.
>> > > >
>> > > > A "chassisredirect" port should never be used as an "inport".  When
>> an
>> > > > ingress pipeline sets the "outport", it may set the value to a
>> logical
>> > > > port of type "chassisredirect".  This will cause the packet to be
>> > > > directed to a specific chassis to carry out the egress logical
>> router
>> > > > pipeline, in the same way that a logical switch forwards egress
>> traffic
>> > > > to a VIF port residing on a specific chassis.  At the beginning of
>> the
>> > > > egress pipeline, the "outport" will be reset to the value of the
>> > > > distributed port.
>> > > >
>> > > > For outbound traffic to be handled in a centralized manner, the
>> > > > "outport" should be set to the "chassisredirect" port representing
>> > > > centralized gateway functionality in the otherwise distributed
>> router.
>> > > > For outbound traffic to be handled in a distributed manner, locally
>> on
>> > > > the source chassis, the "outport" should be set to the existing
>> "patch"
>> > > > port representing distributed gateway functionality.
>> > > >
>> > > > Inbound traffic will be directed to the appropriate chassis by
>> > > > restricting source MAC address usage and ARP responses to that
>> chassis,
>> > > > or by running dynamic routing protocols.
>> > > >
>> > > > Note that "chassisredirect" ports have no associated IP or MAC
>> addresses.
>> > > > Any pipeline stages that depend on port specific IP or MAC addresses
>> > > > should be carried out in the context of the distributed port.
>> > > >
>> > > > Although the abstraction represented by the "chassisredirect" port
>> > > > binding is generalized, in this patch the "chassisredirect" port
>> binding
>> > > > is only created for NB logical router ports that specify the new
>> > > > "redirect-chassis" option.  There is no explicit notion of a
>> > > > "chassisredirect" port in the NB database.  The expectation is when
>> > > > capabilities are implemented that take advantage of
>> "chassisredirect"
>> > > > ports (e.g. NAT), the addition of flows specifying a
>> "chassisredirect"
>> > > > port as the outport will also be triggered by the presence of the
>> > > > "redirect-chassis" option.  Such flows are added for NB logical
>> router
>> > > > ports that specify the "redirect-chassis" option.
>> > > >
>> > > > Signed-off-by: Mickey Spiegel 
>> > >
>> > > chassisredirect ports seem incredibly similar to vif ports.  Is the
>> only
>> > > difference that the output port is changed at the beginning of the
>> > > egress pipeline?  That's something that could be implemented in the
>> > > logical egress pipeline with 'outport = "...";'.  We do say that the
>> > > outport isn't supposed to be modified in an egress pipeline, but
>> nothing
>> > > enforces that and if it's actually useful then we could just change
>> the
>> > > documentation.
>> > >
>> >
>> > I don't get the similarity to vif ports.
>> >
>> > I need to create two different ports for each logical router port
>> > specifying a "redirect-chassis". One represents the centralized
>> > instance, for traffic that needs to be centralized. The other
>> > represents the distributed instance, i.e. just 

Re: [ovs-dev] [PATCH v7 3/7] ovn: Introduce "chassisredirect" port binding

[Ben Pfaff]

On Fri, Jan 06, 2017 at 03:47:03PM -0800, Mickey Spiegel wrote:
> On Fri, Jan 6, 2017 at 3:20 PM, Ben Pfaff  wrote:
> 
> > On Fri, Jan 06, 2017 at 12:00:30PM -0800, Mickey Spiegel wrote:
> > > Currently OVN handles all logical router ports in a distributed manner,
> > > creating instances on each chassis.  The logical router ingress and
> > > egress pipelines are traversed locally on the source chassis.
> > >
> > > In order to support advanced features such as one-to-many NAT (aka IP
> > > masquerading), where multiple private IP addresses spread across
> > > multiple chassis are mapped to one public IP address, it will be
> > > necessary to handle some of the logical router processing on a specific
> > > chassis in a centralized manner.
> > >
> > > The goal of this patch is to develop abstractions that allow for a
> > > subset of router gateway traffic to be handled in a centralized manner
> > > (e.g. one-to-many NAT traffic), while allowing for other subsets of
> > > router gateway traffic to be handled in a distributed manner (e.g.
> > > floating IP traffic).
> > >
> > > This patch introduces a new type of SB port_binding called
> > > "chassisredirect".  A "chassisredirect" port represents a particular
> > > instance, bound to a specific chassis, of an otherwise distributed
> > > port.  The ovn-controller on that chassis populates the "chassis"
> > > column for this record as an indication for other ovn-controllers of
> > > its physical location.  Other ovn-controllers do not treat this port
> > > as a local port.
> > >
> > > A "chassisredirect" port should never be used as an "inport".  When an
> > > ingress pipeline sets the "outport", it may set the value to a logical
> > > port of type "chassisredirect".  This will cause the packet to be
> > > directed to a specific chassis to carry out the egress logical router
> > > pipeline, in the same way that a logical switch forwards egress traffic
> > > to a VIF port residing on a specific chassis.  At the beginning of the
> > > egress pipeline, the "outport" will be reset to the value of the
> > > distributed port.
> > >
> > > For outbound traffic to be handled in a centralized manner, the
> > > "outport" should be set to the "chassisredirect" port representing
> > > centralized gateway functionality in the otherwise distributed router.
> > > For outbound traffic to be handled in a distributed manner, locally on
> > > the source chassis, the "outport" should be set to the existing "patch"
> > > port representing distributed gateway functionality.
> > >
> > > Inbound traffic will be directed to the appropriate chassis by
> > > restricting source MAC address usage and ARP responses to that chassis,
> > > or by running dynamic routing protocols.
> > >
> > > Note that "chassisredirect" ports have no associated IP or MAC addresses.
> > > Any pipeline stages that depend on port specific IP or MAC addresses
> > > should be carried out in the context of the distributed port.
> > >
> > > Although the abstraction represented by the "chassisredirect" port
> > > binding is generalized, in this patch the "chassisredirect" port binding
> > > is only created for NB logical router ports that specify the new
> > > "redirect-chassis" option.  There is no explicit notion of a
> > > "chassisredirect" port in the NB database.  The expectation is when
> > > capabilities are implemented that take advantage of "chassisredirect"
> > > ports (e.g. NAT), the addition of flows specifying a "chassisredirect"
> > > port as the outport will also be triggered by the presence of the
> > > "redirect-chassis" option.  Such flows are added for NB logical router
> > > ports that specify the "redirect-chassis" option.
> > >
> > > Signed-off-by: Mickey Spiegel 
> >
> > chassisredirect ports seem incredibly similar to vif ports.  Is the only
> > difference that the output port is changed at the beginning of the
> > egress pipeline?  That's something that could be implemented in the
> > logical egress pipeline with 'outport = "...";'.  We do say that the
> > outport isn't supposed to be modified in an egress pipeline, but nothing
> > enforces that and if it's actually useful then we could just change the
> > documentation.
> >
> 
> I don't get the similarity to vif ports.
> 
> I need to create two different ports for each logical router port
> specifying a "redirect-chassis". One represents the centralized
> instance, for traffic that needs to be centralized. The other
> represents the distributed instance, i.e. just take the local patch
> port and go to/from the local logical router instance. I wanted the
> egress pipeline processing to be the same regardless of whether
> the packet arrived at the egress pipeline on the port representing
> the centralized instance, or whether the packet arrived at the
> egress pipeline on the port representing the distributed instance.
> 
> There is no pipeline processing of the chassisredirect port,
> except as the outport 

Re: [ovs-dev] [PATCH v7 3/7] ovn: Introduce "chassisredirect" port binding

[Mickey Spiegel]

On Fri, Jan 6, 2017 at 3:47 PM, Mickey Spiegel 
wrote:

>
>
> On Fri, Jan 6, 2017 at 3:20 PM, Ben Pfaff  wrote:
>
>> On Fri, Jan 06, 2017 at 12:00:30PM -0800, Mickey Spiegel wrote:
>> > Currently OVN handles all logical router ports in a distributed manner,
>> > creating instances on each chassis.  The logical router ingress and
>> > egress pipelines are traversed locally on the source chassis.
>> >
>> > In order to support advanced features such as one-to-many NAT (aka IP
>> > masquerading), where multiple private IP addresses spread across
>> > multiple chassis are mapped to one public IP address, it will be
>> > necessary to handle some of the logical router processing on a specific
>> > chassis in a centralized manner.
>> >
>> > The goal of this patch is to develop abstractions that allow for a
>> > subset of router gateway traffic to be handled in a centralized manner
>> > (e.g. one-to-many NAT traffic), while allowing for other subsets of
>> > router gateway traffic to be handled in a distributed manner (e.g.
>> > floating IP traffic).
>> >
>> > This patch introduces a new type of SB port_binding called
>> > "chassisredirect".  A "chassisredirect" port represents a particular
>> > instance, bound to a specific chassis, of an otherwise distributed
>> > port.  The ovn-controller on that chassis populates the "chassis"
>> > column for this record as an indication for other ovn-controllers of
>> > its physical location.  Other ovn-controllers do not treat this port
>> > as a local port.
>> >
>> > A "chassisredirect" port should never be used as an "inport".  When an
>> > ingress pipeline sets the "outport", it may set the value to a logical
>> > port of type "chassisredirect".  This will cause the packet to be
>> > directed to a specific chassis to carry out the egress logical router
>> > pipeline, in the same way that a logical switch forwards egress traffic
>> > to a VIF port residing on a specific chassis.  At the beginning of the
>> > egress pipeline, the "outport" will be reset to the value of the
>> > distributed port.
>> >
>> > For outbound traffic to be handled in a centralized manner, the
>> > "outport" should be set to the "chassisredirect" port representing
>> > centralized gateway functionality in the otherwise distributed router.
>> > For outbound traffic to be handled in a distributed manner, locally on
>> > the source chassis, the "outport" should be set to the existing "patch"
>> > port representing distributed gateway functionality.
>> >
>> > Inbound traffic will be directed to the appropriate chassis by
>> > restricting source MAC address usage and ARP responses to that chassis,
>> > or by running dynamic routing protocols.
>> >
>> > Note that "chassisredirect" ports have no associated IP or MAC
>> addresses.
>> > Any pipeline stages that depend on port specific IP or MAC addresses
>> > should be carried out in the context of the distributed port.
>> >
>> > Although the abstraction represented by the "chassisredirect" port
>> > binding is generalized, in this patch the "chassisredirect" port binding
>> > is only created for NB logical router ports that specify the new
>> > "redirect-chassis" option.  There is no explicit notion of a
>> > "chassisredirect" port in the NB database.  The expectation is when
>> > capabilities are implemented that take advantage of "chassisredirect"
>> > ports (e.g. NAT), the addition of flows specifying a "chassisredirect"
>> > port as the outport will also be triggered by the presence of the
>> > "redirect-chassis" option.  Such flows are added for NB logical router
>> > ports that specify the "redirect-chassis" option.
>> >
>> > Signed-off-by: Mickey Spiegel 
>>
>> chassisredirect ports seem incredibly similar to vif ports.  Is the only
>> difference that the output port is changed at the beginning of the
>> egress pipeline?  That's something that could be implemented in the
>> logical egress pipeline with 'outport = "...";'.  We do say that the
>> outport isn't supposed to be modified in an egress pipeline, but nothing
>> enforces that and if it's actually useful then we could just change the
>> documentation.
>>
>
> I don't get the similarity to vif ports.
>
> I need to create two different ports for each logical router port
> specifying a "redirect-chassis". One represents the centralized
> instance, for traffic that needs to be centralized. The other
> represents the distributed instance, i.e. just take the local patch
> port and go to/from the local logical router instance. I wanted the
> egress pipeline processing to be the same regardless of whether
> the packet arrived at the egress pipeline on the port representing
> the centralized instance, or whether the packet arrived at the
> egress pipeline on the port representing the distributed instance.
>
> There is no pipeline processing of the chassisredirect port,
> except as the outport in the ingress pipeline. Everything else
> happens in 

[ovs-dev] [PATCH v7 3/7] ovn: Introduce "chassisredirect" port binding

[Mickey Spiegel]

Currently OVN handles all logical router ports in a distributed manner,
creating instances on each chassis.  The logical router ingress and
egress pipelines are traversed locally on the source chassis.

In order to support advanced features such as one-to-many NAT (aka IP
masquerading), where multiple private IP addresses spread across
multiple chassis are mapped to one public IP address, it will be
necessary to handle some of the logical router processing on a specific
chassis in a centralized manner.

The goal of this patch is to develop abstractions that allow for a
subset of router gateway traffic to be handled in a centralized manner
(e.g. one-to-many NAT traffic), while allowing for other subsets of
router gateway traffic to be handled in a distributed manner (e.g.
floating IP traffic).

This patch introduces a new type of SB port_binding called
"chassisredirect".  A "chassisredirect" port represents a particular
instance, bound to a specific chassis, of an otherwise distributed
port.  The ovn-controller on that chassis populates the "chassis"
column for this record as an indication for other ovn-controllers of
its physical location.  Other ovn-controllers do not treat this port
as a local port.

A "chassisredirect" port should never be used as an "inport".  When an
ingress pipeline sets the "outport", it may set the value to a logical
port of type "chassisredirect".  This will cause the packet to be
directed to a specific chassis to carry out the egress logical router
pipeline, in the same way that a logical switch forwards egress traffic
to a VIF port residing on a specific chassis.  At the beginning of the
egress pipeline, the "outport" will be reset to the value of the
distributed port.

For outbound traffic to be handled in a centralized manner, the
"outport" should be set to the "chassisredirect" port representing
centralized gateway functionality in the otherwise distributed router.
For outbound traffic to be handled in a distributed manner, locally on
the source chassis, the "outport" should be set to the existing "patch"
port representing distributed gateway functionality.

Inbound traffic will be directed to the appropriate chassis by
restricting source MAC address usage and ARP responses to that chassis,
or by running dynamic routing protocols.

Note that "chassisredirect" ports have no associated IP or MAC addresses.
Any pipeline stages that depend on port specific IP or MAC addresses
should be carried out in the context of the distributed port.

Although the abstraction represented by the "chassisredirect" port
binding is generalized, in this patch the "chassisredirect" port binding
is only created for NB logical router ports that specify the new
"redirect-chassis" option.  There is no explicit notion of a
"chassisredirect" port in the NB database.  The expectation is when
capabilities are implemented that take advantage of "chassisredirect"
ports (e.g. NAT), the addition of flows specifying a "chassisredirect"
port as the outport will also be triggered by the presence of the
"redirect-chassis" option.  Such flows are added for NB logical router
ports that specify the "redirect-chassis" option.

Signed-off-by: Mickey Spiegel 
---
 ovn/controller/binding.c|   8 +
 ovn/controller/ovn-controller.c |   4 +
 ovn/controller/physical.c   |  63 
 ovn/northd/ovn-northd.8.xml | 100 +++-
 ovn/northd/ovn-northd.c | 203 ++--
 ovn/ovn-nb.ovsschema|   9 +-
 ovn/ovn-nb.xml  |  38 +
 ovn/ovn-sb.xml  |  35 +
 ovn/utilities/ovn-trace.c   |  43 +-
 tests/ovn.at| 334 
 10 files changed, 816 insertions(+), 21 deletions(-)

diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
index 2f24e9d..25592c2 100644
--- a/ovn/controller/binding.c
+++ b/ovn/controller/binding.c
@@ -355,6 +355,14 @@ consider_local_datapath(struct controller_ctx *ctx,
 add_local_datapath(ldatapaths, lports, binding_rec->datapath,
false, local_datapaths);
 }
+} else if (!strcmp(binding_rec->type, "chassisredirect")) {
+const char *chassis_id = smap_get(_rec->options,
+  "redirect-chassis");
+our_chassis = chassis_id && !strcmp(chassis_id, chassis_rec->name);
+if (our_chassis) {
+add_local_datapath(ldatapaths, lports, binding_rec->datapath,
+   false, local_datapaths);
+}
 } else if (!strcmp(binding_rec->type, "l3gateway")) {
 const char *chassis_id = smap_get(_rec->options,
   "l3gateway-chassis");
diff --git a/ovn/controller/ovn-controller.c b/ovn/controller/ovn-controller.c
index a28e5f6..7cef3f8 100644
--- a/ovn/controller/ovn-controller.c
+++ b/ovn/controller/ovn-controller.c
@@ -163,6 +163,10 @@