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