<div style="line-height:1.4">hi john and brain<br> thanks for your information, if we get patch[1],patch[2] merged,then fg can allocate private ip address. after that, we need consider floating ip dataplane, in current dvr implementation, fg is used to reachment testing for floating ip, now,with subnet types bp,fg has different subnet than floating ip address, from fg'subnet gateway point view, to reach floating ip, it need a routes entry, destination is some floating ip address, fg'ip address is the nexthop, and this routes entry need be populated at the event of floating ip creating, deleting when floating ip is dissociated. any comments?<br><br><br>发自网易邮箱手机版<br><br><br></div>On 2016-08-01 23:38 , <a href="mailto:John.Davidge@rackspace.com">John Davidge</a> Wrote: <br><br><blockquote id="ntes-andriodmail-quote" style="margin:0px;padding-left:1ex;border-left:#ccc 1px solid">Yes, as Brian says this will be covered by the follow-up patch to [2]
<br>which I¹m currently working on. Thanks for the question.
<br>
<br>John
<br>
<br>
<br>On 8/1/16, 3:17 PM, "Brian Haley" <brian.haley@hpe.com> wrote:
<br>
<br>>On 07/31/2016 06:27 AM, huangdenghui wrote:
<br>>> Hi
<br>>> Now we have spec named subnet service types, which provides a
<br>>>capability of
<br>>> allowing different port of a network to allocate ip address from
<br>>>different
<br>>> subnet. In current implementation of DVR, fip also is distributed on
<br>>>every
<br>>> compute node, floating ip and fg's ip are both allocated from external
<br>>>network's
<br>>> subnets. In large public cloud deployment, current implementation will
<br>>>consume
<br>>> lots of public ip address. Do we need a RFE to apply subnet service
<br>>>types spec
<br>>> to resolve this problem. Any thoughts?
<br>>
<br>>Hi,
<br>>
<br>>This is going to be covered in the existing RFE for subnet service types
<br>>[1].
<br>>We currently have two reviews in progress for CRUD [2] and CLI [3], the
<br>>IPAM
<br>>changes are next.
<br>>
<br>>-Brian
<br>>
<br>>[1] <a href="https://review.openstack.org/#/c/300207/">https://review.openstack.org/#/c/300207/</a>
<br>>[2] <a href="https://review.openstack.org/#/c/337851/">https://review.openstack.org/#/c/337851/</a>
<br>>[3] <a href="https://review.openstack.org/#/c/342976/">https://review.openstack.org/#/c/342976/</a>
<br>>
<br>>__________________________________________________________________________
<br>>OpenStack Development Mailing List (not for usage questions)
<br>>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<br>><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
<br>
<br>
<br>________________________________
<br>Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be viewed at <a href="www.rackspace.co.uk/legal/privacy-policy">www.rackspace.co.uk/legal/privacy-policy</a> - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse@rackspace.com and delete the original message. Your cooperation is appreciated.
<br>
<br>__________________________________________________________________________
<br>OpenStack Development Mailing List (not for usage questions)
<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
<br></blockquote><br><br>