Open Stack

Yes, the L2 semantics apply to the external network as well (at least with
ML2).

One example of the special casing is the external_network_bridge option in
the L3 agent. That would cause the agent to plug directly into a bridge so
none of the normal L2 agent wiring would occur. With the L2 bridge_mappings
option there is no reason for this to exist anymore because it ignoring
network attributes makes debugging a nightmare.

>Yes, that makes sense.  Clearly the core semantic there is IP.  I can
imagine reasonable variation on less core details, e.g. L2 broadcast vs.
NBMA.  Perhaps it would be acceptable, if use cases need it, for such
details to be described by flags on the external network object.

An external network object is just a regular network object with a
router:external flag set to true. Any changes to it would have to make
sense in the context of all networks. That's why I want to make sure that
whatever we come up with makes sense in all contexts and isn't just a bolt
on corner case.
On Sep 17, 2015 8:21 AM, "Neil Jerram" <Neil.Jerram at metaswitch.com> wrote:

> Thanks, Kevin.  Some further queries, then:
>
> On 17/09/15 15:49, Kevin Benton wrote:
> >
> > It's not true for all plugins, but an external network should provide
> > the same semantics of a normal network.
> >
> Yes, that makes sense.  Clearly the core semantic there is IP.  I can
> imagine reasonable variation on less core details, e.g. L2 broadcast vs.
> NBMA.  Perhaps it would be acceptable, if use cases need it, for such
> details to be described by flags on the external network object.
>
> I'm also wondering about what you wrote in the recent thread with Carl
> about representing a network connected by routers.  I think you were
> arguing that a L3-only network should not be represented by a kind of
> Neutron network object, because a Neutron network has so many L2
> properties/semantics that it just doesn't make sense, and better to have
> a different kind of object for L3-only.  Do those L2
> properties/semantics apply to an external network too?
>
> > The only difference is that it allows router gateway interfaces to be
> > attached to it.
> >
> Right.  From a networking-calico perspective, I think that means that
> the implementation should (eventually) support that, and hence allow
> interconnection between the external network and private Neutron networks.
>
> > We want to get rid of as much special casing as possible for the
> > external network.
> >
> I don't understand here.  What 'special casing' do you mean?
>
> Regards,
>     Neil
>
> > On Sep 17, 2015 7:02 AM, "Neil Jerram" <Neil.Jerram at metaswitch.com
> > <mailto:Neil.Jerram at metaswitch.com>> wrote:
> >
> >     Thanks to the interesting 'default network model' thread, I now know
> >     that Neutron allows booting a VM on an external network. :-)  I
> didn't
> >     realize that before!
> >
> >     So, I'm now wondering what connectivity semantics are expected (or
> >     even
> >     specified!) for such VMs, and whether they're the same as - or very
> >     similar to - the 'routed' networking semantics I've described at [1].
> >
> >     [1]
> >
> https://review.openstack.org/#/c/198439/5/doc/source/devref/routed_networks.rst
> >
> >     Specifically I wonder if VM's attached to an external network
> >     expect any
> >     particular L2 characteristics, such as being able to L2 broadcast to
> >     each other?
> >
> >     By way of context - i.e. why am I asking this?...   The
> >     networking-calico project [2] provides an implementation of the
> >     'routed'
> >     semantics at [1], but only if one suspends belief in some of the
> >     Neutron
> >     semantics associated with non-external networks, such as needing a
> >     virtual router to provide connectivity to the outside world.
> (Because
> >     networking-calico provides that external connectivity without any
> >     virtual router.)  Therefore we believe that we need to propose some
> >     enhancement of the Neutron API and data model, so that Neutron can
> >     describe 'routed' semantics as well as all the traditional ones.
> But,
> >     if what we are doing is semantically equivalent to 'attaching to an
> >     external network', perhaps no such enhancement is needed...
> >
> >     [2] https://git.openstack.org/cgit/openstack/networking-calico
> >     <https://git.openstack.org/cgit/openstack/networking-calico>
> >
> >     Many thanks for any input!
> >
> >         Neil
> >
> >
> >
>  __________________________________________________________________________
> >     OpenStack Development Mailing List (not for usage questions)
> >     Unsubscribe:
> >     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >     <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/7b76bab5/attachment.html>