Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenStack: Netstack

L3/IPAM summit discussion follow-up...

 

 

OpenStack netstack RSS feed   Index | Next | Previous | View Threaded


snaiksat at cisco

Apr 24, 2012, 7:12 AM

Post #1 of 6 (597 views)
Permalink
L3/IPAM summit discussion follow-up...

Hi All,

Thanks for your feedback on the L3 (forwarding) proposal during the
summit and also prior to that. The action item coming out of the summit
session was to further discuss this with the Melange/IPAM team to
identify points of overlap and/or what are the additional requirements.
Accordingly, after focused discussions with many folks including Troy,
Jason, and Trey from the Melange team, it seems that we are pretty much
on the same page in terms of what the L3 (forwarding) proposal wants to
achieve and how IPAM will support the data-store aspects of this.

There are constructs like the ip_block in (former) Melange which map to
the Subnet (in the L3 forwarding proposal). There are others like the
route-table and targets which might not have a direct mapping, and which
might need to be realized separately. These in turn might drive further
requirements on the IPAM component, but this will be clearer once we
start implementing the L3 forwarding proposal. Also, realizing the
target abstraction will need plugin-level support which might differ
based on the type of the target being realized and the underlying
network infrastructure. So the plan is to go forward with the
implementation of both IPAM and L3 route-table/target API, with both
going into the trunk branch. The work on L3 will hopefully drive any
further needs on the IPAM component.

Specifically on the ip_block/subnet construct, the current thought is to
call it a Subnet. Also, this is better modeled as a separate construct,
rather than an attribute in the virtual network resource, since we
should be able to model 1:n and n:1 relationships between L3 and L2
networks.

Please let us know if you have any further thoughts on this. If you
missed this session during the summit, the slides are posted here:
http://www.slideshare.net/sumit_naik/summit-prepquantuml3modelsumit9

Thanks,
~Sumit.

--
Mailing list: https://launchpad.net/~netstack
Post to : netstack [at] lists
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp


rkukura at redhat

Apr 24, 2012, 12:08 PM

Post #2 of 6 (568 views)
Permalink
Re: L3/IPAM summit discussion follow-up... [In reply to]

On 04/24/2012 10:12 AM, Sumit Naiksatam (snaiksat) wrote:
> Hi All,
>
> Thanks for your feedback on the L3 (forwarding) proposal during the
> summit and also prior to that. The action item coming out of the summit
> session was to further discuss this with the Melange/IPAM team to
> identify points of overlap and/or what are the additional requirements.
> Accordingly, after focused discussions with many folks including Troy,
> Jason, and Trey from the Melange team, it seems that we are pretty much
> on the same page in terms of what the L3 (forwarding) proposal wants to
> achieve and how IPAM will support the data-store aspects of this.
>
> There are constructs like the ip_block in (former) Melange which map to
> the Subnet (in the L3 forwarding proposal). There are others like the
> route-table and targets which might not have a direct mapping, and which
> might need to be realized separately. These in turn might drive further
> requirements on the IPAM component, but this will be clearer once we
> start implementing the L3 forwarding proposal. Also, realizing the
> target abstraction will need plugin-level support which might differ
> based on the type of the target being realized and the underlying
> network infrastructure. So the plan is to go forward with the
> implementation of both IPAM and L3 route-table/target API, with both
> going into the trunk branch. The work on L3 will hopefully drive any
> further needs on the IPAM component.
>
> Specifically on the ip_block/subnet construct, the current thought is to
> call it a Subnet. Also, this is better modeled as a separate construct,
> rather than an attribute in the virtual network resource, since we
> should be able to model 1:n and n:1 relationships between L3 and L2
> networks.
>
> Please let us know if you have any further thoughts on this. If you
> missed this session during the summit, the slides are posted here:
> http://www.slideshare.net/sumit_naik/summit-prepquantuml3modelsumit9
>
> Thanks,
> ~Sumit.
>

This all sounds reasonable to me, as far as it goes. I was at the
quantum summit sessions and re-read the slides and proposal, but I'm
still not at all clear on how the melange and L3-forwarding
functionality will relate to quantum plugins:

1) Is the merge of melange into quantum going to be pluggable, or is the
IPAM implementation going to be built directly into quantum-server (or a
separate server)?

2) If the IPAM functionality is going to be pluggable, will this be part
of the same plugin handling L2, or will it be a separate plugin that can
be configured independently of the the L2 plugin?

3) I expect that the L3-forwarding functionality will be pluggable. Will
this be handled by the same plugin as L2 and/or IPAM, or as a separate
L3 plugin?

Thanks,

-Bob

--
Mailing list: https://launchpad.net/~netstack
Post to : netstack [at] lists
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp


dan at nicira

Apr 24, 2012, 1:38 PM

Post #3 of 6 (579 views)
Permalink
Re: L3/IPAM summit discussion follow-up... [In reply to]

I think we're having a bit of a terminology clash here, at least according
to what I intended by the definitions posted on the etherpad:
http://etherpad.openstack.org/quantum-folsom . The existing definitions
for "IPAM" and "L3 Forwarding" are below.

I believe that at the end of Sumit's presentation we decided that his
proposal was a higher-level abstraction on top of our existing "IPAM" plan
from merging Melange. In particularly, the "route-table" was about what
routes that would be injected into the VM such that the VM would have
different next hops (route information injected into the VM is within the
scope of Melange IPAM). I believe we concluded that these route-tables
were NOT about implementing "L3 forwarding" between two different "L2
Quantum Networks".

We talked separately about an "L3 forwarding" implementation, that would
allow pluggable implementations of a logical L3 forwarding element capable
of achieving nova-parity, namely: basic L3 forwarding, SNAT, and DNAT
(i.e., what is already implemented in linux_net.py). This L3 forwarding
element would be able to route between multiple Quantum L2 networks (one
might call it a "router", but apparently that's discouraged :P ).

I'm REALLY hoping that we're all on the same page here, otherwise, we may
need to start back at square one :)

Dan



- IP Address Management (IPAM):
* How virtual servers as allocated IP addresses based on their network
connectivity (http://en.wikipedia.org/wiki/IP_address_management)
* Often includes other network identifiers that are also configured on a
virtual server, including MAC address, subnet mask gateways, routes, DNS
servers, etc.
* This type of functionality is currently provided by Melange, which will
be integrated into Quantum during Folsom.
* IPAM is needed even if VMs are only connected to L2 Quantum networks
(i.e., it does not required "L3 forwarding" or other logical features
described below).
* Note: this does NOT specify how these identifiers are "injected" into
the server itself (could be via disk injections, DHCP, cloud-init+metadata,
statically configured by admin)


- L3 Forwarding
* Quantum "networks" provide an L2 service model. There are use cases
that require connecting virtual servers that are not on the same L2 network
+ subnets, and are therefore connected only by an element performing L3
forwarding.
* Note: this L3 forwarding element is a logical abstraction. We make no
statement how how it is implemented (e.g., by a VM appliance, a physical
router, or something else).
* These L3 forwarding elements would likely expose some kind of a "routing
table" to describe the rules used to forward between different L2-subnets.
* A common use case is that an L2-network/subnet is a trust domain
(private tenant networks, tier of a web application), yet communication is
required between trust domains.
* We separate out firewall and NAT into a separate discussion, below.
* L3 forwarding has a dependency on understanding the IPAM data for a
particular subnet that it is connected to (e.g., network address/mask,
gateway address)
* Note: the primary focus of this is defining L3 forwarding between
endpoints WITHIN a Quantum deployment. Connectivity between different
Quantum deployments, or to remote datacenters not running Quantum is viewed
many as a separate service (e.g., L3VPN-service).



On Tue, Apr 24, 2012 at 12:08 PM, Robert Kukura <rkukura [at] redhat> wrote:

> On 04/24/2012 10:12 AM, Sumit Naiksatam (snaiksat) wrote:
> > Hi All,
> >
> > Thanks for your feedback on the L3 (forwarding) proposal during the
> > summit and also prior to that. The action item coming out of the summit
> > session was to further discuss this with the Melange/IPAM team to
> > identify points of overlap and/or what are the additional requirements.
> > Accordingly, after focused discussions with many folks including Troy,
> > Jason, and Trey from the Melange team, it seems that we are pretty much
> > on the same page in terms of what the L3 (forwarding) proposal wants to
> > achieve and how IPAM will support the data-store aspects of this.
> >
> > There are constructs like the ip_block in (former) Melange which map to
> > the Subnet (in the L3 forwarding proposal). There are others like the
> > route-table and targets which might not have a direct mapping, and which
> > might need to be realized separately. These in turn might drive further
> > requirements on the IPAM component, but this will be clearer once we
> > start implementing the L3 forwarding proposal. Also, realizing the
> > target abstraction will need plugin-level support which might differ
> > based on the type of the target being realized and the underlying
> > network infrastructure. So the plan is to go forward with the
> > implementation of both IPAM and L3 route-table/target API, with both
> > going into the trunk branch. The work on L3 will hopefully drive any
> > further needs on the IPAM component.
> >
> > Specifically on the ip_block/subnet construct, the current thought is to
> > call it a Subnet. Also, this is better modeled as a separate construct,
> > rather than an attribute in the virtual network resource, since we
> > should be able to model 1:n and n:1 relationships between L3 and L2
> > networks.
> >
> > Please let us know if you have any further thoughts on this. If you
> > missed this session during the summit, the slides are posted here:
> > http://www.slideshare.net/sumit_naik/summit-prepquantuml3modelsumit9
> >
> > Thanks,
> > ~Sumit.
> >
>
> This all sounds reasonable to me, as far as it goes. I was at the
> quantum summit sessions and re-read the slides and proposal, but I'm
> still not at all clear on how the melange and L3-forwarding
> functionality will relate to quantum plugins:
>
> 1) Is the merge of melange into quantum going to be pluggable, or is the
> IPAM implementation going to be built directly into quantum-server (or a
> separate server)?
>
> 2) If the IPAM functionality is going to be pluggable, will this be part
> of the same plugin handling L2, or will it be a separate plugin that can
> be configured independently of the the L2 plugin?
>
> 3) I expect that the L3-forwarding functionality will be pluggable. Will
> this be handled by the same plugin as L2 and/or IPAM, or as a separate
> L3 plugin?
>
> Thanks,
>
> -Bob
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack [at] lists
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp
>



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~


snaiksat at cisco

Apr 25, 2012, 11:52 PM

Post #4 of 6 (572 views)
Permalink
Re: L3/IPAM summit discussion follow-up... [In reply to]

> -----Original Message-----
> From: netstack-bounces+snaiksat=cisco.com [at] lists
> [mailto:netstack-bounces+snaiksat=cisco.com [at] lists] On
> Behalf Of Robert Kukura
> Sent: Tuesday, April 24, 2012 12:09 PM
> To: netstack [at] lists
> Subject: Re: [Netstack] L3/IPAM summit discussion follow-up...
>
> On 04/24/2012 10:12 AM, Sumit Naiksatam (snaiksat) wrote:
> > Hi All,
> >
> > Thanks for your feedback on the L3 (forwarding) proposal during the
> > summit and also prior to that. The action item coming out of the
> summit
> > session was to further discuss this with the Melange/IPAM team to
> > identify points of overlap and/or what are the additional
> requirements.
> > Accordingly, after focused discussions with many folks including
> Troy,
> > Jason, and Trey from the Melange team, it seems that we are pretty
> much
> > on the same page in terms of what the L3 (forwarding) proposal wants
> to
> > achieve and how IPAM will support the data-store aspects of this.
> >
> > There are constructs like the ip_block in (former) Melange which map
> to
> > the Subnet (in the L3 forwarding proposal). There are others like
the
> > route-table and targets which might not have a direct mapping, and
> which
> > might need to be realized separately. These in turn might drive
> further
> > requirements on the IPAM component, but this will be clearer once we
> > start implementing the L3 forwarding proposal. Also, realizing the
> > target abstraction will need plugin-level support which might differ
> > based on the type of the target being realized and the underlying
> > network infrastructure. So the plan is to go forward with the
> > implementation of both IPAM and L3 route-table/target API, with both
> > going into the trunk branch. The work on L3 will hopefully drive any
> > further needs on the IPAM component.
> >
> > Specifically on the ip_block/subnet construct, the current thought
is
> to
> > call it a Subnet. Also, this is better modeled as a separate
> construct,
> > rather than an attribute in the virtual network resource, since we
> > should be able to model 1:n and n:1 relationships between L3 and L2
> > networks.
> >
> > Please let us know if you have any further thoughts on this. If you
> > missed this session during the summit, the slides are posted here:
> > http://www.slideshare.net/sumit_naik/summit-prepquantuml3modelsumit9
> >
> > Thanks,
> > ~Sumit.
> >
>
> This all sounds reasonable to me, as far as it goes. I was at the
> quantum summit sessions and re-read the slides and proposal, but I'm
> still not at all clear on how the melange and L3-forwarding
> functionality will relate to quantum plugins:
>
> 1) Is the merge of melange into quantum going to be pluggable, or is
> the
> IPAM implementation going to be built directly into quantum-server (or
> a
> separate server)?
>
> 2) If the IPAM functionality is going to be pluggable, will this be
> part
> of the same plugin handling L2, or will it be a separate plugin that
> can
> be configured independently of the the L2 plugin?
>
> 3) I expect that the L3-forwarding functionality will be pluggable.
> Will
> this be handled by the same plugin as L2 and/or IPAM, or as a separate
> L3 plugin?
>
> Thanks,
>
> -Bob

Hi Bob,

Those are good questions, and I am not completely clear on this as well
(I don't recall a discussion on this during the summit either). I
believe that the team implementing the IPAM functionality has a plan
around how to integrate this functionality, possibly as libraries which
the Quantum plugins can use?

On the implementation of the L3 functionality (with reference to our
proposal), our earlier suggestion was that it be implemented as a
separate plugin from that of a L2 plugin. It seemed like a more modular
approach with the advantage of being able to use different combination
of plugins. I do recall reading some concerns in this list around
ensuring the compatibility of L3 and L2 plugins. This is a valid
concern, however, plugin configuration is a cloud-operator/SP activity,
who will probably have good knowledge of the plugin behavior and hence
can ensure the configuration of compatible plugins. Of course, if one
wants to implement everything in the same plugin, that should still be
possible.

Thanks,
~Sumit.



>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack [at] lists
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp

--
Mailing list: https://launchpad.net/~netstack
Post to : netstack [at] lists
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp


snaiksat at cisco

Apr 26, 2012, 12:57 AM

Post #5 of 6 (571 views)
Permalink
Re: L3/IPAM summit discussion follow-up... [In reply to]

From: netstack-bounces+snaiksat=cisco.com [at] lists
[mailto:netstack-bounces+snaiksat=cisco.com [at] lists] On
Behalf Of Dan Wendlandt
Sent: Tuesday, April 24, 2012 1:38 PM
To: Robert Kukura
Cc: netstack [at] lists
Subject: Re: [Netstack] L3/IPAM summit discussion follow-up...



I think we're having a bit of a terminology clash here, at least
according to what I intended by the definitions posted on the etherpad:
http://etherpad.openstack.org/quantum-folsom . The existing definitions
for "IPAM" and "L3 Forwarding" are below.



<Sumit> During the summit we called the proposal - "L3 Tenant-facing
Abstractions/Model". I don't recall any differences of opinion on this,
is everyone comfortable with this? </Sumit>



I believe that at the end of Sumit's presentation we decided that his
proposal was a higher-level abstraction on top of our existing "IPAM"
plan from merging Melange. In particularly, the "route-table" was about
what routes that would be injected into the VM such that the VM would
have different next hops (route information injected into the VM is
within the scope of Melange IPAM). I believe we concluded that these
route-tables were NOT about implementing "L3 forwarding" between two
different "L2 Quantum Networks".



<Sumit> The route-tables (and the entries therein) are proposed as an
abstraction for the tenant to request forwarding between subnets (and
also to service-gateways, referred to as "targets"). The underlying
implementation (realizing the abstraction) could implicitly/explicitly
map the subnets to L2 networks and achieve the L3 forwarding as
required. I believe this was fairly well understood. In that context, I
am having trouble understanding the above explanation.</Sumit>



We talked separately about an "L3 forwarding" implementation, that would
allow pluggable implementations of a logical L3 forwarding element
capable of achieving nova-parity, namely: basic L3 forwarding, SNAT, and
DNAT (i.e., what is already implemented in linux_net.py). This L3
forwarding element would be able to route between multiple Quantum L2
networks (one might call it a "router", but apparently that's
discouraged :P ).



<Sumit> It will be helpful if you can please point us to the
session/slides where this "L3 forwarding element" was discussed?
</Sumit>



I'm REALLY hoping that we're all on the same page here, otherwise, we
may need to start back at square one :)



Dan







- IP Address Management (IPAM):

* How virtual servers as allocated IP addresses based on their network
connectivity (http://en.wikipedia.org/wiki/IP_address_management)

* Often includes other network identifiers that are also configured on
a virtual server, including MAC address, subnet mask gateways, routes,
DNS servers, etc.

* This type of functionality is currently provided by Melange, which
will be integrated into Quantum during Folsom.

* IPAM is needed even if VMs are only connected to L2 Quantum networks
(i.e., it does not required "L3 forwarding" or other logical features
described below).

* Note: this does NOT specify how these identifiers are "injected" into
the server itself (could be via disk injections, DHCP,
cloud-init+metadata, statically configured by admin)





- L3 Forwarding

* Quantum "networks" provide an L2 service model. There are use cases
that require connecting virtual servers that are not on the same L2
network + subnets, and are therefore connected only by an element
performing L3 forwarding.

* Note: this L3 forwarding element is a logical abstraction. We make
no statement how how it is implemented (e.g., by a VM appliance, a
physical router, or something else).

* These L3 forwarding elements would likely expose some kind of a
"routing table" to describe the rules used to forward between different
L2-subnets.

* A common use case is that an L2-network/subnet is a trust domain
(private tenant networks, tier of a web application), yet communication
is required between trust domains.

* We separate out firewall and NAT into a separate discussion, below.

* L3 forwarding has a dependency on understanding the IPAM data for a
particular subnet that it is connected to (e.g., network address/mask,
gateway address)

* Note: the primary focus of this is defining L3 forwarding between
endpoints WITHIN a Quantum deployment. Connectivity between different
Quantum deployments, or to remote datacenters not running Quantum is
viewed many as a separate service (e.g., L3VPN-service).







On Tue, Apr 24, 2012 at 12:08 PM, Robert Kukura <rkukura [at] redhat>
wrote:

On 04/24/2012 10:12 AM, Sumit Naiksatam (snaiksat) wrote:
> Hi All,
>
> Thanks for your feedback on the L3 (forwarding) proposal during the
> summit and also prior to that. The action item coming out of the
summit
> session was to further discuss this with the Melange/IPAM team to
> identify points of overlap and/or what are the additional
requirements.
> Accordingly, after focused discussions with many folks including Troy,
> Jason, and Trey from the Melange team, it seems that we are pretty
much
> on the same page in terms of what the L3 (forwarding) proposal wants
to
> achieve and how IPAM will support the data-store aspects of this.
>
> There are constructs like the ip_block in (former) Melange which map
to
> the Subnet (in the L3 forwarding proposal). There are others like the
> route-table and targets which might not have a direct mapping, and
which
> might need to be realized separately. These in turn might drive
further
> requirements on the IPAM component, but this will be clearer once we
> start implementing the L3 forwarding proposal. Also, realizing the
> target abstraction will need plugin-level support which might differ
> based on the type of the target being realized and the underlying
> network infrastructure. So the plan is to go forward with the
> implementation of both IPAM and L3 route-table/target API, with both
> going into the trunk branch. The work on L3 will hopefully drive any
> further needs on the IPAM component.
>
> Specifically on the ip_block/subnet construct, the current thought is
to
> call it a Subnet. Also, this is better modeled as a separate
construct,
> rather than an attribute in the virtual network resource, since we
> should be able to model 1:n and n:1 relationships between L3 and L2
> networks.
>
> Please let us know if you have any further thoughts on this. If you
> missed this session during the summit, the slides are posted here:
> http://www.slideshare.net/sumit_naik/summit-prepquantuml3modelsumit9
>
> Thanks,
> ~Sumit.
>

This all sounds reasonable to me, as far as it goes. I was at the
quantum summit sessions and re-read the slides and proposal, but I'm
still not at all clear on how the melange and L3-forwarding
functionality will relate to quantum plugins:

1) Is the merge of melange into quantum going to be pluggable, or is the
IPAM implementation going to be built directly into quantum-server (or a
separate server)?

2) If the IPAM functionality is going to be pluggable, will this be part
of the same plugin handling L2, or will it be a separate plugin that can
be configured independently of the the L2 plugin?

3) I expect that the L3-forwarding functionality will be pluggable. Will
this be handled by the same plugin as L2 and/or IPAM, or as a separate
L3 plugin?

Thanks,

-Bob


--
Mailing list: https://launchpad.net/~netstack
Post to : netstack [at] lists
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp







--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt

Nicira, Inc: www.nicira.com

twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~


dan at nicira

Apr 28, 2012, 12:19 PM

Post #6 of 6 (561 views)
Permalink
Re: L3/IPAM summit discussion follow-up... [In reply to]

Ok, I don't want to get into a long email thread about terminology here, so
I think my main take away is there may be two different approaches for
using Quantum to describe connectivity between VMs on different subnets.
The good news is that I believe everyone thinks that they can implement
their proposals as API extensions on top of the base of a merged Quantum +
Melange API, so I think we can just move forward on implementing these
proposals as extensions. I think once we have concrete implementations,
any salient differences will become clear. That's exactly how the API
extension mechanism is supposed to work.

I think our next steps need to focus on how existing Melange constructs of
"subnets/ip-blocks" and "ip allocations" are folded into the Quantum API.
Having sketched out all of the work we need to do in Folsom, this seems
like the item that all other work depends on. We just need to make sure
that this base API is sufficient to support API extensions exposing your
route-table + target constructs, as well as the work that I was referring
to when I used the term "L3 forwarding" (for context, check out the
etherpad notes from the IPAM/L3 forwarding discussion, as well as the " L3
forwarding + NAT implementation" section of the nova-parity discussion we
had the next morning).

Dan


On Thu, Apr 26, 2012 at 12:57 AM, Sumit Naiksatam (snaiksat) <
snaiksat [at] cisco> wrote:

> ** **
>
> ** **
>
> *From:* netstack-bounces+snaiksat=cisco.com [at] lists [mailto:
> netstack-bounces+snaiksat=cisco.com [at] lists] *On Behalf Of *Dan
> Wendlandt
> *Sent:* Tuesday, April 24, 2012 1:38 PM
> *To:* Robert Kukura
> *Cc:* netstack [at] lists
>
> *Subject:* Re: [Netstack] L3/IPAM summit discussion follow-up...****
>
> ** **
>
> I think we're having a bit of a terminology clash here, at least according
> to what I intended by the definitions posted on the etherpad:
> http://etherpad.openstack.org/quantum-folsom . The existing definitions
> for "IPAM" and "L3 Forwarding" are below. ****
>
> ** **
>
> <Sumit> During the summit we called the proposal – “L3 Tenant-facing
> Abstractions/Model”. I don’t recall any differences of opinion on this, is
> everyone comfortable with this? </Sumit> ****
>
> ** **
>
> I believe that at the end of Sumit's presentation we decided that his
> proposal was a higher-level abstraction on top of our existing "IPAM" plan
> from merging Melange. In particularly, the "route-table" was about what
> routes that would be injected into the VM such that the VM would have
> different next hops (route information injected into the VM is within the
> scope of Melange IPAM). I believe we concluded that these route-tables
> were NOT about implementing "L3 forwarding" between two different "L2
> Quantum Networks".****
>
> ** **
>
> <Sumit> The route-tables (and the entries therein) are proposed as an
> abstraction for the tenant to request forwarding between subnets (and also
> to service-gateways, referred to as “targets”). The underlying
> implementation (realizing the abstraction) could implicitly/explicitly map
> the subnets to L2 networks and achieve the L3 forwarding as required. I
> believe this was fairly well understood. In that context, I am having
> trouble understanding the above explanation.</Sumit> ****
>
> ** **
>
> We talked separately about an "L3 forwarding" implementation, that would
> allow pluggable implementations of a logical L3 forwarding element capable
> of achieving nova-parity, namely: basic L3 forwarding, SNAT, and DNAT
> (i.e., what is already implemented in linux_net.py). This L3 forwarding
> element would be able to route between multiple Quantum L2 networks (one
> might call it a "router", but apparently that's discouraged :P ). ****
>
> ** **
>
> <Sumit> It will be helpful if you can please point us to the
> session/slides where this “L3 forwarding element” was discussed? </Sumit>*
> ***
>
> ** **
>
> I'm REALLY hoping that we're all on the same page here, otherwise, we may
> need to start back at square one :)****
>
> ** **
>
> Dan****
>
> ** **
>
> ** **
>
> ** **
>
> - IP Address Management (IPAM): ****
>
> * How virtual servers as allocated IP addresses based on their network
> connectivity (http://en.wikipedia.org/wiki/IP_address_management)****
>
> * Often includes other network identifiers that are also configured on a
> virtual server, including MAC address, subnet mask gateways, routes, DNS
> servers, etc. ****
>
> * This type of functionality is currently provided by Melange, which will
> be integrated into Quantum during Folsom. ****
>
> * IPAM is needed even if VMs are only connected to L2 Quantum networks
> (i.e., it does not required "L3 forwarding" or other logical features
> described below). ****
>
> * Note: this does NOT specify how these identifiers are "injected" into
> the server itself (could be via disk injections, DHCP, cloud-init+metadata,
> statically configured by admin)****
>
> ** **
>
> ** **
>
> - L3 Forwarding ****
>
> * Quantum "networks" provide an L2 service model. There are use cases
> that require connecting virtual servers that are not on the same L2 network
> + subnets, and are therefore connected only by an element performing L3
> forwarding. ****
>
> * Note: this L3 forwarding element is a logical abstraction. We make no
> statement how how it is implemented (e.g., by a VM appliance, a physical
> router, or something else). ****
>
> * These L3 forwarding elements would likely expose some kind of a
> "routing table" to describe the rules used to forward between different
> L2-subnets. ****
>
> * A common use case is that an L2-network/subnet is a trust domain
> (private tenant networks, tier of a web application), yet communication is
> required between trust domains. ****
>
> * We separate out firewall and NAT into a separate discussion, below. **
> **
>
> * L3 forwarding has a dependency on understanding the IPAM data for a
> particular subnet that it is connected to (e.g., network address/mask,
> gateway address) ****
>
> * Note: the primary focus of this is defining L3 forwarding between
> endpoints WITHIN a Quantum deployment. Connectivity between different
> Quantum deployments, or to remote datacenters not running Quantum is viewed
> many as a separate service (e.g., L3VPN-service). ****
>
> ** **
>
> ** **
>
> ** **
>
> On Tue, Apr 24, 2012 at 12:08 PM, Robert Kukura <rkukura [at] redhat>
> wrote:****
>
> On 04/24/2012 10:12 AM, Sumit Naiksatam (snaiksat) wrote:
> > Hi All,
> >
> > Thanks for your feedback on the L3 (forwarding) proposal during the
> > summit and also prior to that. The action item coming out of the summit
> > session was to further discuss this with the Melange/IPAM team to
> > identify points of overlap and/or what are the additional requirements.
> > Accordingly, after focused discussions with many folks including Troy,
> > Jason, and Trey from the Melange team, it seems that we are pretty much
> > on the same page in terms of what the L3 (forwarding) proposal wants to
> > achieve and how IPAM will support the data-store aspects of this.
> >
> > There are constructs like the ip_block in (former) Melange which map to
> > the Subnet (in the L3 forwarding proposal). There are others like the
> > route-table and targets which might not have a direct mapping, and which
> > might need to be realized separately. These in turn might drive further
> > requirements on the IPAM component, but this will be clearer once we
> > start implementing the L3 forwarding proposal. Also, realizing the
> > target abstraction will need plugin-level support which might differ
> > based on the type of the target being realized and the underlying
> > network infrastructure. So the plan is to go forward with the
> > implementation of both IPAM and L3 route-table/target API, with both
> > going into the trunk branch. The work on L3 will hopefully drive any
> > further needs on the IPAM component.
> >
> > Specifically on the ip_block/subnet construct, the current thought is to
> > call it a Subnet. Also, this is better modeled as a separate construct,
> > rather than an attribute in the virtual network resource, since we
> > should be able to model 1:n and n:1 relationships between L3 and L2
> > networks.
> >
> > Please let us know if you have any further thoughts on this. If you
> > missed this session during the summit, the slides are posted here:
> > http://www.slideshare.net/sumit_naik/summit-prepquantuml3modelsumit9
> >
> > Thanks,
> > ~Sumit.
> >****
>
> This all sounds reasonable to me, as far as it goes. I was at the
> quantum summit sessions and re-read the slides and proposal, but I'm
> still not at all clear on how the melange and L3-forwarding
> functionality will relate to quantum plugins:
>
> 1) Is the merge of melange into quantum going to be pluggable, or is the
> IPAM implementation going to be built directly into quantum-server (or a
> separate server)?
>
> 2) If the IPAM functionality is going to be pluggable, will this be part
> of the same plugin handling L2, or will it be a separate plugin that can
> be configured independently of the the L2 plugin?
>
> 3) I expect that the L3-forwarding functionality will be pluggable. Will
> this be handled by the same plugin as L2 and/or IPAM, or as a separate
> L3 plugin?
>
> Thanks,
>
> -Bob****
>
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack [at] lists
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp****
>
>
>
> ****
>
> ** **
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt ****
>
> Nicira, Inc: www.nicira.com****
>
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~****
>
> ** **
>



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

OpenStack netstack RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.