netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Štefan Gula" <steweg@ynet.sk>
To: Jesse Gross <jesse@nicira.com>
Cc: David Miller <davem@davemloft.net>,
	joseph.glanville@orionvm.com.au, eric.dumazet@gmail.com,
	kuznet@ms2.inr.ac.ru, jmorris@namei.org, yoshfuji@linux-ipv6.org,
	kaber@trash.net, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [patch v4, kernel version 3.2.1] net/ipv4/ip_gre: Ethernet multipoint GRE over IP
Date: Wed, 25 Jan 2012 08:38:15 +0100	[thread overview]
Message-ID: <CAGsizzJqNgos89pp-0ivw6ZmUd3+SehwdAnPY7FuGG+xvPWxAg@mail.gmail.com> (raw)
In-Reply-To: <CAEP_g=9H9dV9=qtFPh4YeTNQ-t+UZGw-YqZ6hFWVNXjFy+GCZg@mail.gmail.com>

2012/1/25 Jesse Gross <jesse@nicira.com>:
> On Tue, Jan 24, 2012 at 8:02 PM, David Miller <davem@davemloft.net> wrote:
>> From: Joseph Glanville <joseph.glanville@orionvm.com.au>
>> Date: Wed, 25 Jan 2012 14:48:37 +1100
>>
>>> The reason why this patch is useful is that it stands to be the only
>>> true mulitpoint L2 VPN with a kernel space forwarding plane.
>>
>> So what you're telling me is that I added this huge openvswitch
>> thing essentially for nothing?
>
> I think it's actually the opposite - Open vSwitch can be used to
> implement this type of thing as well as for many other use cases.  On
> the other hand, even when implementing a multipoint L2 solution it can
> be useful to have additional levels of control but you can't do that
> with this patch because it essentially statically glues together
> tunneling and bridging.
Yes, those methods are glued together. If you are speaking about
additional level of controls. What kind of control is missing?

As if I compare it to standard bridge, it is missing:
-  STP code, which is not relevant here as the topology inside the
gretap bridge never reaches loops - it represent more one shared link
than box with multiple links from STP point of view. On the other hand
STP can be tunneled inside of that tunnel by putting gretap interface
as part of some bridge e.g. "brctl addif br0 gretap0".
- IGMP/MLD snooping. IGMP/MLD snooping are useful features, but due
the encapsulation rules, the only one optimalization can be done and
that's if in ONLY ONE gretap enabled nodes requires to join some
multicast group inside the gretap and one node has source behind. In
that case those frames can be forwarded to only that gretap node. In
case of two or more, the encapsulation process will result in using
multicast as underlying technology so any one of the gretap nodes will
received the frames regardless of state if IGMP/MLD. On the other hand
such multicast optimalizations are missing from whole GRE tunnels code
(PIM/MLD/IGMP snooping, using something like cisco Multicast Domain
Trees/MDT....), so if somebody wants to optimize that feel free, but
don't blame this patch for missing those.
- did I miss something?

  reply	other threads:[~2012-01-25  7:38 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <18947389.2811326843064500.JavaMail.root@5-MeO-DMT.ynet.sk>
2012-01-17 23:33 ` [patch v4, kernel version 3.2.1] net/ipv4/ip_gre: Ethernet multipoint GRE over IP Stefan Gula
2012-01-23 13:12   ` Štefan Gula
2012-01-23 14:13     ` Eric Dumazet
2012-01-23 18:43       ` David Miller
2012-01-23 22:23         ` Štefan Gula
2012-01-25  3:48           ` Joseph Glanville
2012-01-25  4:02             ` David Miller
2012-01-25  7:11               ` Jesse Gross
2012-01-25  7:38                 ` Štefan Gula [this message]
2012-01-25  8:37                 ` Eric Dumazet
2012-01-25  9:17                   ` Štefan Gula
2012-01-25 15:25                 ` Joseph Glanville
2012-01-25 21:55                 ` David Miller
2012-01-25 22:57                   ` Štefan Gula
2012-01-25 23:18                     ` Dave Taht
2012-01-26  1:37                     ` David Miller
2012-01-26 10:57                       ` Štefan Gula
2012-01-26 18:30                         ` David Miller
2012-01-26 22:24                           ` Joseph Glanville
2012-01-27  5:59                             ` Eric Dumazet
2012-01-27 10:54                               ` Joseph Glanville
2012-01-27 21:55                                 ` Jesse Gross
2012-01-27 21:50                               ` Jesse Gross
2012-01-25  5:53   ` Eric Dumazet
2012-01-25 16:57   ` Stephen Hemminger
2012-01-25 21:01     ` Štefan Gula
2012-01-25 21:49       ` David Miller
2012-01-25 22:30         ` Štefan Gula

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGsizzJqNgos89pp-0ivw6ZmUd3+SehwdAnPY7FuGG+xvPWxAg@mail.gmail.com \
    --to=steweg@ynet.sk \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=jesse@nicira.com \
    --cc=jmorris@namei.org \
    --cc=joseph.glanville@orionvm.com.au \
    --cc=kaber@trash.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).