Re: [openstack-dev] [api][neutron][nova][Openstack-operators][interop] Time for a bikeshed - help me name types of networking

[PACHECO, RODOLFO J]

Monty

The one missing aspect in this network model, is the ability to identify 
/categorize a VNF VM, that i.e. Is using SRIOV and only cares about VLAN’s
Such VM’s would not have IP Addresses in some cases, and wouldn’t be 
describable with the external/internal address labels.

I feel you need some other mechanism or tag to capture that type of server. Or 
at least be able to account for them. (no-external-ip / or external-vlan , or 
something)

It’s possible that the case I mention is what you refer to here “ Again, there 
are more complex combinations possible. For now this is 
focused on the 80% case. I'm deliberately ignoring questions like vpn or 
tricircle-style intra-cloud networks for now. “



Regards
 

Rodolfo 

 

Home/Office 732 5337671

On 5/14/17, 1:02 PM, "Monty Taylor"  wrote:

Hey all!

LONG EMAIL WARNING

I'm working on a proposal to formalize a cloud profile document. (we 
keep and support these in os-client-config, but it's grown up ad-hoc and 
is hard for other languages to consume -so we're going to rev it and try 
to encode information in it more sanely) I need help in coming up with 
names for some things that we can, if not all agree on, at least not 
have pockets of violent dissent against.

tl;dr: What do we name some enum values?

First, some long-winded background

== Background ==

The profile document is where we keep information about a cloud that an 
API consumer needs to know to effectively use the cloud - and is stored 
in a machine readable manner so that libraries and tools (including but 
hopefully not limited to shade) can make appropriate choices.

Information in profiles is the information that's generally true for all 
normal users. OpenStack is flexible, and some API consumers have 
different access. That's fine - the cloud profiles are not for them. 
Cloud profiles define the qualities about a cloud that end users can 
safely expect to be true. Advanced use is never restricted by annotating 
the general case.

First off, we need to define two terms:
"external" - an address that can be used for north-south communication 
off the cloud
"internal" - an address that can be used for east-west communication 
with and only with other things on the same cloud

Again, there are more complex combinations possible. For now this is 
focused on the 80% case. I'm deliberately ignoring questions like vpn or 
tricircle-style intra-cloud networks for now. If we can agree on an 
outcome here - we can always come back and add words to describe more 
things.

** Bikeshed #1 **

Are "internal" and "external" ok with folks as terms for those two ideas?

We need a term for each - if we prefer different terms, replacing their 
use in the following is simple.

== Booting Servers ==

When booting a server, a typical user wants one of the following:

- Give me a server with an external address
- Give me a server with an internal address
- Give me a server with both
- Give me a server with very specific networking connections

The fourth doesn't need any help - it's the current state of the world 
today and is well served. It's the "I have a network I am aware of 
and/or a pre-existing floating ip, etc and I want to use them". This is 
not about those people - they're fine.

Related to the first three cases, depending on how the cloud is 
deployed, any of the following can be non-exclusively true:

- External addresses are provided via Fixed IPs
- External addresses are provided via Floating IPs
- Internal addresses are provided via Fixed IPs
- Internal addresses can be provided via Floating IPs
- Users can create and define their own internal networks

Additionally, External addresses can be IPv4 or IPv6

== Proposal - complete with Unpainted Sheds ==

I want to add information to the existing cloud profile telling the API 
user which of the models above are available.

The cloud profile will gain a field called "network-models" which will 
contain one or more names from an enum of pre-defined models. Multiple 
values can be listed, because some clouds provide more than one option.

** Bikeshed #2 **

Anybody have a problem with the key name "network-models"?

(Incidentally, the idea from this is borrowed from GCE's 
"compute#accessConfig" [0] - although they only have one model in their 
enum: "ONE_TO_ONE_NAT")

In a perfect future world where we have per-service capabilities 
discovery I'd love for such information to be exposed directly by 
neutron. Therefore, I'd LOVE if we can at agree that the concepts are 
concepts and on what to name them so that users who get the info from a 
  

Re: [openstack-dev] [api][neutron][nova][Openstack-operators][interop] Time for a bikeshed - help me name types of networking

[Monty Taylor]

On 05/15/2017 11:44 AM, Ian Wells wrote:

I'm coming to this cold, so apologies when I put my foot in my mouth.
But I'm trying to understand what you're actually getting at, here -
other than helpful simplicity - and I'm not following the detail of
you're thinking, so take this as a form of enquiry.


Thanks for diving in - no foot-mouth worries here. It's a hard topic.


On 14 May 2017 at 10:02, Monty Taylor > wrote:

First off, we need to define two terms:
"external" - an address that can be used for north-south
communication off the cloud
"internal" - an address that can be used for east-west communication
with and only with other things on the same cloud


I'm going through the network detail of this and picking out
shortcomings, so please understand that before you read on.

I think I see what you're trying to accomplish, but the details don't
add up for me.  The right answer might be 'you don't use this if you
want fine detailed network APIs' - and that's fine - but I think the
issue is not coming up with a model that contradicts the fine detail of
what you can do with a network today and how you can put it to use.


Yes. The _general_ answer is that this is not supposed to attempt to 
describe all of the networking possibilities - but also exactly what you 
sayd, we don't want to _contradict_ those things.



1. What if there are more domains of connectivity, since a cloud can be
connected to multiple domains?  I see this in its current form as
intended for public cloud providers as much as anything, in which case
there is probably only one definition of 'external', for instance, but
if you want to make it more widely useful you could define off-cloud
routing domain names, of which 'external' (or, in that context,
'internet') is one with a very specific meaning.


Right. So 'external' isn't intended to describe destination, as much as 
'does this go to other things' and 'if so how'.


You're totally right - if there are more than one "external" domain, 
this information will be insufficient. I'd expect each of the networks 
in question to be tagged as "external" - but the choice of where they go 
is a time when a user is going to need more information.


Related to an above reponse though - let's say a user has a cloud that 
connects to three network domains that are not in the cloud in question. 
A, B and C. At no point in that user's life is "I want a VM that has 
external connectivity" going to be a sensible request. They will, out of 
necessity, always need to say "I want a VM that can connect to domain A" 
- which is already very nicely handled.


This is definitely inspired by the Public Clouds, since this is one of 
the top 2 things it's super hard for users to figure out and that we 
currently have to paper over for them in client libraries. (image 
upload, fwiw, is the other) But I hope it degrades well for more complex 
private clouds. That is - the existence of (or lack of) such tags on a 
private cloud should not impact the existing experience for those users 
at all.



2. What is 'internal', precisely?  It seems to be in-cloud, though I
don't entirely understand how NAT comes into that.  What of a route to
the provider's internal network?  How does it apply when I have multiple
tenant networks that can't talk to each other, when they're provisioned
for me and I can't create them, and so on?  Why doesn't it apply to IPv6?


Yes, internal is intended to be in cloud. It's intended to handle the 
"please give me a server that can't talk to things that aren't in my 
personal private network" case. Similar to the external case, if a user 
has more than one project networks, there is no way "I want a VM that 
does not have external connectivity" will be a useful thing to say. 
They'll have to say "I want a VM that is attached to the network I 
created for my database tier" - and again that's currently handled nicely.


In the current proposal IPv6 isn't covered in more depth because the 
question with IPv6 is (in my experience - obviously could be wrong) - 
"can I get me some IPv6".


As for NAT - I included internal NAT for completeness because I heard 
that someone added the ability to neutron to be able to get floating ips 
from one neutron private network and use them to connect to a different 
neutron private network. I have not seen this in action myself, nor do I 
want it - but it seemed having an enum value to cover it wasn't expensive.


As to why we cover NAT at all - that's more to do with workloads running 
on the server. Some workloads like to be able to look at the IP stack on 
the server and see their own network information (kerberos comes to 
mind) while others don't care. And some folks may be designing apps that 
assume they're behind NAT of some sort. On some clouds both are 
available, so a user with a preference to form needs to be able to 
express that.



3. Why doesn't your format tell me how to 

Re: [openstack-dev] [api][neutron][nova][Openstack-operators][interop] Time for a bikeshed - help me name types of networking

[Monty Taylor]

On 05/15/2017 11:51 AM, Doug Hellmann wrote:

Excerpts from Jay Pipes's message of 2017-05-15 12:40:17 -0400:

On 05/14/2017 01:02 PM, Monty Taylor wrote:

** Bikeshed #1 **

Are "internal" and "external" ok with folks as terms for those two ideas?


Yup, ++ from me on the above.


** Bikeshed #2 **

Anybody have a problem with the key name "network-models"?


They're not network models. They're access/connectivity policies. :)


(Incidentally, the idea from this is borrowed from GCE's
"compute#accessConfig" [0] - although they only have one model in their
enum: "ONE_TO_ONE_NAT")

In a perfect future world where we have per-service capabilities
discovery I'd love for such information to be exposed directly by
neutron.


I actually don't see this as a Neutron thing. It's the *workload*
connectivity expectations that you're describing, not anything to do
with networks, subnets or ports.

So, I think actually Nova would be a better home for this capability
discovery, for similar reasons why get-me-a-network was mostly a Nova
user experience...

So, I suppose I'd prefer to call this thing an "access policy" or
"access model", optionally prefixing that with "network", i.e. "network
access policy".


We have enough things overloading the term "policy." Let's get out
a thesaurus for this one. ;-)


Good points from both of you - thank you.

Access Model would be fine by me - it's very similar to the GCE term 
which is "access config".





** Bikeshed #3 **

What do we call the general concepts represented by fixed and floating
ips? Do we use the words "fixed" and "floating"? Do we instead try
something else, such as "direct" and "nat"?

I have two proposals for the values in our enum:

#1 - using fixed / floating

ipv4-external-fixed
ipv4-external-floating
ipv4-internal-fixed
ipv4-internal-floating
ipv6-fixed


Definitely -1 on using fixed/floating.


#2 - using direct / nat

ipv4-external-direct
ipv4-external-nat
ipv4-internal-direct
ipv4-internal-nat
ipv6-direct


I'm good with direct and nat. +1 from me.


On the other hand, "direct" isn't exactly a commonly used word in this
context. I asked a ton of people at the Summit last week and nobody
could come up with a better term for "IP that is configured inside of
the server's network stack". "non-natted", "attached", "routed" and
"normal" were all suggested. I'm not sure any of those are super-great -
so I'm proposing "direct" - but please if you have a better suggestion
please make it.


The other problem with the term "direct" is that there is already a vNIC
type of the same name which refers to a guest's vNIC using a host
passthrough device.


We need more words. :)


So, maybe non-nat or no-nat would be better? Or hell, make it a boolean
is_nat or has_nat if we're really just referring to whether an IP is
NATted or not?


I think the questions are:

"Does this cloud support accessing this server using NAT?"
"Does this cloud support accessing this server without NAT?"

(which your suggestion would carry)

However, I'm skiddish on calling it "nat" and "not-nat" - because as a 
user not coming from a background where servers are accessed via nat - 
I'm not sure I'd think to express my desire as "can I have a not-nat 
please?" But maybe that's just the world we live in - where normal 
"Internet" connectivity is only known as "isn't natted"...


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api][neutron][nova][Openstack-operators][interop] Time for a bikeshed - help me name types of networking

[Doug Hellmann]

Excerpts from Jay Pipes's message of 2017-05-15 12:40:17 -0400:
> On 05/14/2017 01:02 PM, Monty Taylor wrote:
> > ** Bikeshed #1 **
> >
> > Are "internal" and "external" ok with folks as terms for those two ideas?
> 
> Yup, ++ from me on the above.
> 
> > ** Bikeshed #2 **
> >
> > Anybody have a problem with the key name "network-models"?
> 
> They're not network models. They're access/connectivity policies. :)
> 
> > (Incidentally, the idea from this is borrowed from GCE's
> > "compute#accessConfig" [0] - although they only have one model in their
> > enum: "ONE_TO_ONE_NAT")
> >
> > In a perfect future world where we have per-service capabilities
> > discovery I'd love for such information to be exposed directly by
> > neutron.
> 
> I actually don't see this as a Neutron thing. It's the *workload* 
> connectivity expectations that you're describing, not anything to do 
> with networks, subnets or ports.
> 
> So, I think actually Nova would be a better home for this capability 
> discovery, for similar reasons why get-me-a-network was mostly a Nova 
> user experience...
> 
> So, I suppose I'd prefer to call this thing an "access policy" or 
> "access model", optionally prefixing that with "network", i.e. "network 
> access policy".

We have enough things overloading the term "policy." Let's get out
a thesaurus for this one. ;-)

Doug

> 
> > ** Bikeshed #3 **
> >
> > What do we call the general concepts represented by fixed and floating
> > ips? Do we use the words "fixed" and "floating"? Do we instead try
> > something else, such as "direct" and "nat"?
> >
> > I have two proposals for the values in our enum:
> >
> > #1 - using fixed / floating
> >
> > ipv4-external-fixed
> > ipv4-external-floating
> > ipv4-internal-fixed
> > ipv4-internal-floating
> > ipv6-fixed
> 
> Definitely -1 on using fixed/floating.
> 
> > #2 - using direct / nat
> >
> > ipv4-external-direct
> > ipv4-external-nat
> > ipv4-internal-direct
> > ipv4-internal-nat
> > ipv6-direct
> 
> I'm good with direct and nat. +1 from me.
> 
> > On the other hand, "direct" isn't exactly a commonly used word in this
> > context. I asked a ton of people at the Summit last week and nobody
> > could come up with a better term for "IP that is configured inside of
> > the server's network stack". "non-natted", "attached", "routed" and
> > "normal" were all suggested. I'm not sure any of those are super-great -
> > so I'm proposing "direct" - but please if you have a better suggestion
> > please make it.
> 
> The other problem with the term "direct" is that there is already a vNIC 
> type of the same name which refers to a guest's vNIC using a host 
> passthrough device.
> 
> So, maybe non-nat or no-nat would be better? Or hell, make it a boolean 
> is_nat or has_nat if we're really just referring to whether an IP is 
> NATted or not?
> 
> Best,
> -jay
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api][neutron][nova][Openstack-operators][interop] Time for a bikeshed - help me name types of networking

[Ian Wells]

I'm coming to this cold, so apologies when I put my foot in my mouth.  But
I'm trying to understand what you're actually getting at, here - other than
helpful simplicity - and I'm not following the detail of you're thinking,
so take this as a form of enquiry.

On 14 May 2017 at 10:02, Monty Taylor  wrote:

> First off, we need to define two terms:
> "external" - an address that can be used for north-south communication off
> the cloud
> "internal" - an address that can be used for east-west communication with
> and only with other things on the same cloud
>

I'm going through the network detail of this and picking out shortcomings,
so please understand that before you read on.

I think I see what you're trying to accomplish, but the details don't add
up for me.  The right answer might be 'you don't use this if you want fine
detailed network APIs' - and that's fine - but I think the issue is not
coming up with a model that contradicts the fine detail of what you can do
with a network today and how you can put it to use.

1. What if there are more domains of connectivity, since a cloud can be
connected to multiple domains?  I see this in its current form as intended
for public cloud providers as much as anything, in which case there is
probably only one definition of 'external', for instance, but if you want
to make it more widely useful you could define off-cloud routing domain
names, of which 'external' (or, in that context, 'internet') is one with a
very specific meaning.

2. What is 'internal', precisely?  It seems to be in-cloud, though I don't
entirely understand how NAT comes into that.  What of a route to the
provider's internal network?  How does it apply when I have multiple tenant
networks that can't talk to each other, when they're provisioned for me and
I can't create them, and so on?  Why doesn't it apply to IPv6?

3. Why doesn't your format tell me how to get a port/address of the type in
question?  Do you feel that everything will be consistent in that regard?
To my mind it's more useful - at the least - to tell me the *identity* of
the network I should be using rather than saying 'such a thing is possible
in the abstract'.

[...]

"get me a server with only an internal ipv4 and please fail if that isn't
> possible"
>
>   create_server(
>   'my-server', external_network=False, internal_network=True)
>

A comment on all of these: are you considering this to be an argument that
is acted upon in the library, or available on the server?

Doing this in the library makes more sense to me.  I prefer the idea of
documenting in machine-readable form how to use the APIs, because it means
I can use a cloud without the cloud supporting the API.  For many clouds,
the description could be a static file, but for more complex situations it
would be possible to generate it programmatically per tenant.

Doing it the other way could also lead to cloud-specific code, and without
some clearer specification it might also lead to cloud-specific behaviour.

It's also complexity that simply doesn't need to be in the cloud; putting
it in the application gives an application with a newer library the
opportunity to use an older cloud.

2) As information on networks themselves:
>
> GET /networks.json
> {
>   "networks": [
> {
>   "status": "ACTIVE",
>   "name": "GATEWAY_NET_V6",
>   "id": "54753d2c-0a58-4928-9b32-084c59dd20a6",
>   "network-models": [
> "ipv4-internal-direct",
> "ipv6-direct"
>   ]
> },
>

[...]

I think the problem with this as a concept, if this is what you're
eventually driving towards, is how you would enumerate this for a network.

IPv6 may be routed to the internet (or other domains) or it may not, but if
it is it's not currently optional to be locally routed and not internet
routed on a given network as it is for a v4 address to be fixed without a
floating component.  (You've skipped this by listing only ipv6-direct, I
think, as an option, where you have ipv4-fixed).

ipv4 may be routed to the internet if a router is connected, but I can
connect a router after the fact and I can add a floating IP to a port after
the fact too.  If you're just thinking in terms of 'when starting a VM, at
this instant in time' then that might not be quite so much of an issue.

I'm not suggesting putting info on subnets, since one requests connectivity
> from a network, not a subnet.
>

Not accurate - I can select a subnet on a network, and it can change who I
can talk to based on routes.  Neutron routers are attached to subnets, not
networks.

On a final note, this is really more about 'how do I make a port with this
sort of connectivity' with the next logical step being that many VMs only
need one port.
-- 
Ian.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [api][neutron][nova][Openstack-operators][interop] Time for a bikeshed - help me name types of networking

[Jay Pipes]

On 05/14/2017 01:02 PM, Monty Taylor wrote:

** Bikeshed #1 **

Are "internal" and "external" ok with folks as terms for those two ideas?


Yup, ++ from me on the above.


** Bikeshed #2 **

Anybody have a problem with the key name "network-models"?


They're not network models. They're access/connectivity policies. :)


(Incidentally, the idea from this is borrowed from GCE's
"compute#accessConfig" [0] - although they only have one model in their
enum: "ONE_TO_ONE_NAT")

In a perfect future world where we have per-service capabilities
discovery I'd love for such information to be exposed directly by
neutron.


I actually don't see this as a Neutron thing. It's the *workload* 
connectivity expectations that you're describing, not anything to do 
with networks, subnets or ports.


So, I think actually Nova would be a better home for this capability 
discovery, for similar reasons why get-me-a-network was mostly a Nova 
user experience...


So, I suppose I'd prefer to call this thing an "access policy" or 
"access model", optionally prefixing that with "network", i.e. "network 
access policy".



** Bikeshed #3 **

What do we call the general concepts represented by fixed and floating
ips? Do we use the words "fixed" and "floating"? Do we instead try
something else, such as "direct" and "nat"?

I have two proposals for the values in our enum:

#1 - using fixed / floating

ipv4-external-fixed
ipv4-external-floating
ipv4-internal-fixed
ipv4-internal-floating
ipv6-fixed


Definitely -1 on using fixed/floating.


#2 - using direct / nat

ipv4-external-direct
ipv4-external-nat
ipv4-internal-direct
ipv4-internal-nat
ipv6-direct


I'm good with direct and nat. +1 from me.


On the other hand, "direct" isn't exactly a commonly used word in this
context. I asked a ton of people at the Summit last week and nobody
could come up with a better term for "IP that is configured inside of
the server's network stack". "non-natted", "attached", "routed" and
"normal" were all suggested. I'm not sure any of those are super-great -
so I'm proposing "direct" - but please if you have a better suggestion
please make it.


The other problem with the term "direct" is that there is already a vNIC 
type of the same name which refers to a guest's vNIC using a host 
passthrough device.


So, maybe non-nat or no-nat would be better? Or hell, make it a boolean 
is_nat or has_nat if we're really just referring to whether an IP is 
NATted or not?


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api][neutron][nova][Openstack-operators][interop] Time for a bikeshed - help me name types of networking

[Neil Jerram]

On Sun, May 14, 2017 at 6:02 PM Monty Taylor  wrote:

> Are "internal" and "external" ok with folks as terms for those two ideas?
>

Yes, I think so.  Slight worry that 'external' is also used in
'router:external' - but I think it will be clear that your proposed context
is different.


> - External addresses are provided via Fixed IPs
> - External addresses are provided via Floating IPs
> - Internal addresses are provided via Fixed IPs
> - Internal addresses can be provided via Floating IPs
>

FWIW, I don't think I've ever heard of this last one.


> Anybody have a problem with the key name "network-models"?
>

No; sounds good.


> What do we call the general concepts represented by fixed and floating
> ips? Do we use the words "fixed" and "floating"? Do we instead try
> something else, such as "direct" and "nat"?
>
> I have two proposals for the values in our enum:
>
> #1 - using fixed / floating
>
> ipv4-external-fixed
> ipv4-external-floating
> ipv4-internal-fixed
> ipv4-internal-floating
> ipv6-fixed
>
> #2 - using direct / nat
>
> ipv4-external-direct
> ipv4-external-nat
> ipv4-internal-direct
> ipv4-internal-nat
> ipv6-direct
>
> Does anyone have strong feelings one way or the other?
>

Not strong, no.  I feel as though anyone in or close to OpenStack would be
familiar already with the floating and fixed terms - and so why risk the
bother and churn of changing to something else?  But also appreciate that
other clouds do not use those terms.


>
> My personal preference is direct/nat. "floating" has a tendency to imply
> different things to different people (just watch, we're going to have at
> least one rabbit hole that will be an argument about the meaning of
> floating ips) ... while anyone with a background in IT knows what "nat"
> is. It's also a characteristic from a server/workload perspective that
> is related to a choice the user might want to make:
>
>   Does the workload need the server to know its own IP?
>   Does the workload prefer to be behind NAT?
>   Does the workload not care and just wants connectivity?
>
> On the other hand, "direct" isn't exactly a commonly used word in this
> context. I asked a ton of people at the Summit last week and nobody
> could come up with a better term for "IP that is configured inside of
> the server's network stack". "non-natted", "attached", "routed" and
> "normal" were all suggested. I'm not sure any of those are super-great -
> so I'm proposing "direct" - but please if you have a better suggestion
> please make it.
>

Not sure it's better, but "Internet address space" or something else that
conveys the idea that the address given to the VM is in the same address
space (aka scope) as things outside the cluster.

Regards - Neil
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev