Open Stack

>Then describing the 'segment ID' as a VLAN ID

Segment ID is not a VLAN ID. A segment ID is a UUID for a segment, which
can contain a segmentation ID of a VLAN ID or VXLAN VNI or it might even be
a flat network.

It is unfortunate that we have both segment ID and segmentation ID, which
is what let to your confusion. The first uniquely identifies the segment,
the second describes how things will be encapsulated on the wire. I think
updating the docs to refer to the first as segment UUID might go a long
ways to help disambiguate.

>Then using the same 'VLAN ID' for different segments (even though its a
segment ID) on different networks implies that they might even be the same
VLAN, which they are not.

With VLANs the segmentation ID can be re-used on different physical
networks because they are not wired to the same L2 domain. They will have
different segment UUIDs and different 'physical_network' values, but may
have the same VLAN ID (segmentation_id).

On Tue, May 23, 2017 at 6:31 AM, Chris Marino <chris at romana.io> wrote:

> Thanks Kevin, very helpful....other comments in line.
> CM
>
> On Mon, May 22, 2017 at 9:15 PM, Kevin Benton <kevin at benton.pub> wrote:
>
>> On May 22, 2017 9:34 AM, "Chris Marino" <chris at romana.io> wrote:
>>
>> I'm digging into how Routed Provider Networks work and have some
>> questions as well. I will presenting at the OpenStack Meetup
>> <https://www.meetup.com/openstack/events/239889735/>on Wed on this and
>> want to make sure I have my facts straight......
>>
>> From the doc page
>> <https://docs.openstack.org/ocata/networking-guide/config-routed-networks.html> it
>> shows a multi-segment network with segment 1 on 203.0.113.0/24 and
>> segment 2 on 198.51.100.0/24. It also suggests using the same VLAN ID
>> for these segments.
>>
>> I find both of these things really confusing.
>>
>>
>> What do you find confusing about this? It's a pretty standard L3 to ToR
>> and L2 in rack setup. L2 is limited to the rack so you can use or not use
>> whatever VLANs in that scope. We can fix the docs to clear up whatever
>> confusion you have.
>>
>
> My confusion was based on my somewhat narrow understanding of the use
> case. My thinking was that the current L2 provider networks would be cast
> as set of L2 segments (with contiguous CIDRs) on an L3 network. Seeing both
> the 203. and 198. networks getting consolidated into a single network is
> pretty disorienting. Together they are not a single network by the
> traditional definition of a network. Then describing the 'segment ID' as a
> VLAN ID was confusing for two reasons. First, it carries forward the idea
> that the segments are VLANs, which they might be, but don't have to be.
> Then using the same 'VLAN ID' for different segments (even though its a
> segment ID) on different networks implies that they might even be the same
> VLAN, which they are not.
>
>
>> But ignoring that for a minute, I'm more interested in the expected use
>> case for this feature. I see from the original spec/blueprint
>> <http://specs.openstack.org/openstack/neutron-specs/specs/newton/routed-networks.html>
>>  that the goal was to allow for a single Provider Network to be made up
>> from multiple network segments, where external routing provided
>> connectivity among the segments. And Routed Provider Networks provide
>> this.  Great.
>>
>> But the use cases I'm curious about are where the operator wants to take
>> their current L2/VLAN Provider Networks, but deploy it as an L3 Provider
>> Network. Same CIDR as the L2 provider network, but in a fully routed
>> deployment (i.e. no L2 adjacency). It might be L3 to the ToR and (untagged)
>> L2 to the host. Or L3 to the host.
>>
>> Both of these configurations are gaining popularity and wondering how
>> they would need to be configured. For the L3 to ToR, the network segments
>> would have to be split across the ToRs as described in the doc, but what
>> about L3 to host? Guessing a segment per host, but wondering how practical
>> that's going to be without better coordination of IP/segments with Nova?
>>
>>
>> L3 to the host and one segment per host is possible, but it's going to
>> have a severe limitation of not being able to migrate VMs without an IP
>> change. To get migration at that point you will need some form of dynamic
>> routing.
>>
>
> Yes, dynamic routing is going to help here as well as the config/setup.
>
>
>>
>> L3 to ToR and L2 in rack is definitely the target use case as of now.
>>
>
> Yes, I see that more clearly now.
>
>
>>
>> On May 22, 2017 9:34 AM, "Chris Marino" <chris at romana.io> wrote:
>>
>>> I'm digging into how Routed Provider Networks work and have some
>>> questions as well. I will presenting at the OpenStack Meetup
>>> <https://www.meetup.com/openstack/events/239889735/>on Wed on this and
>>> want to make sure I have my facts straight......
>>>
>>> From the doc page
>>> <https://docs.openstack.org/ocata/networking-guide/config-routed-networks.html> it
>>> shows a multi-segment network with segment 1 on 203.0.113.0/24 and
>>> segment 2 on 198.51.100.0/24. It also suggests using the same VLAN ID
>>> for these segments.
>>>
>>> I find both of these things really confusing. But ignoring that for a
>>> minute, I'm more interested in the expected use case for this feature. I
>>> see from the original spec/blueprint
>>> <http://specs.openstack.org/openstack/neutron-specs/specs/newton/routed-networks.html> that the
>>> goal was to allow for a single Provider Network to be made up from multiple
>>> network segments, where external routing provided connectivity among the
>>> segments. And Routed Provider Networks provide this.  Great.
>>>
>>> But the use cases I'm curious about are where the operator wants to take
>>> their current L2/VLAN Provider Networks, but deploy it as an L3 Provider
>>> Network. Same CIDR as the L2 provider network, but in a fully routed
>>> deployment (i.e. no L2 adjacency). It might be L3 to the ToR and (untagged)
>>> L2 to the host. Or L3 to the host.
>>>
>>> Both of these configurations are gaining popularity and wondering how
>>> they would need to be configured. For the L3 to ToR, the network segments
>>> would have to be split across the ToRs as described in the doc, but what
>>> about L3 to host? Guessing a segment per host, but wondering how practical
>>> that's going to be without better coordination of IP/segments with Nova?
>>>
>>> CM
>>> ᐧ
>>>
>>> On Sun, May 21, 2017 at 6:12 AM, Alex Evonosky <alex.evonosky at gmail.com>
>>> wrote:
>>>
>>>> Thank you Yura.
>>>>
>>>> A
>>>>
>>>> On Thu, May 18, 2017 at 3:24 AM, Yura Poltoratskiy <
>>>> yurapoltora at gmail.com> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> On 17.05.2017 21:56, Alex Evonosky wrote:
>>>>>
>>>>>> Hello fellow Openstackers-
>>>>>>
>>>>>> I have a quick question regarding routed provider networks.  I am
>>>>>> looking at this
>>>>>> page: https://docs.openstack.org/ocata/networking-guide/config-rou
>>>>>> ted-networks.html
>>>>>>
>>>>>> I configured the controller as stated in the docs, however this line
>>>>>> is
>>>>>> somewhat vaugue:
>>>>>>
>>>>>> "
>>>>>>
>>>>>>
>>>>>>       Network or compute nodes¶
>>>>>>       <https://docs.openstack.org/ocata/networking-guide/config-ro
>>>>>> uted-networks.html#network-or-compute-nodes>
>>>>>>
>>>>>>   * Configure the layer-2 agent on each node to map one or more
>>>>>> segments
>>>>>>     to the appropriate physical network bridge or interface and
>>>>>> restart
>>>>>>     the agent."
>>>>>>
>>>>>>
>>>>>> Which file am I editing on the compute nodes to answer the above
>>>>>> question?
>>>>>>
>>>>> If you are using OpenVSwitch agent, then on compute/network node you
>>>>> should modify:
>>>>> /etc/neutron/plugins/ml2/openvswitch_agent.ini
>>>>> /etc/neutron/plugins/ml2/ml2_conf.ini
>>>>>
>>>>>
>>>>>>
>>>>>> Thank you,
>>>>>> A
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: http://lists.openstack.org/cgi
>>>>>> -bin/mailman/listinfo/openstack
>>>>>> Post to     : openstack at lists.openstack.org
>>>>>> Unsubscribe : http://lists.openstack.org/cgi
>>>>>> -bin/mailman/listinfo/openstack
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: http://lists.openstack.org/cgi
>>>>> -bin/mailman/listinfo/openstack
>>>>> Post to     : openstack at lists.openstack.org
>>>>> Unsubscribe : http://lists.openstack.org/cgi
>>>>> -bin/mailman/listinfo/openstack
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: http://lists.openstack.org/cgi
>>>> -bin/mailman/listinfo/openstack
>>>> Post to     : openstack at lists.openstack.org
>>>> Unsubscribe : http://lists.openstack.org/cgi
>>>> -bin/mailman/listinfo/openstack
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Mailing list: http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>> Post to     : openstack at lists.openstack.org
>>> Unsubscribe : http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20170523/f61a183f/attachment.html>