From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: vyasevic@redhat.com, netdev@vger.kernel.org,
"David S . Miller" <davem@davemloft.net>,
bridge@lists.linux-foundation.org
Subject: Re: [PATCH net-next 3/4] bridge: Consider the Nearest Customer Bridge group addresses
Date: Wed, 11 Jun 2014 15:12:01 +0900 [thread overview]
Message-ID: <5397F331.5020608@lab.ntt.co.jp> (raw)
In-Reply-To: <20140610092127.5b4f528f@nehalam.linuxnetplumber.net>
(2014/06/11 1:21), Stephen Hemminger wrote:
> On Tue, 10 Jun 2014 16:05:07 +0900
> Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
>
>> (2014/06/10 7:33), Vlad Yasevich wrote:
>> ...
>>>>> Rather than special casing this around vlan filtering, I would prefer
>>>>> the code always forward these packets, or manipulate group_fwd_mask
>>>>> to allow it that way.
>>>>
>>>> These addresses must be forwarded only if the bridge is an S-VLAN
>>>> bridge. When it is a C-VLAN bridge or a .1D bridge, they may not be
>>>> forwarded. So, I don't think we can forward them always.
>>>>
>>>> Using group_fwd_mask is a bit complicated. If we use it to forward them,
>>>> user can optionally turn off forwarding ability of those addresses...
>>>> but we maybe need another information (named like group_fwd_mask_set)
>>>> that indicates which bit is set by user. (We have to set group_fwd_mask
>>>> automatically when we set vlan_proto to 88a8.)
>>>> Is this way acceptable?
>>>
>>> May be separate it into required mask and user mask. Set required
>>> mask when this is an S-VLAN bridge.
>>
>> Sounds like a good idea.
>> I'll give it a try, thank you for your suggestion.
>>
>> Thanks,
>> Toshiaki Makita
>>
>
> Looking again at the code.
>
> 1. If doing vlan then it should forward frames as defined in standard
> by default.
>
> 2. For compatiability, and for those users doing bump-on-wire, allow
> forwarding via group mask.
>
Thank you for reviewing. I sent v2 and I'm thinking it can satisfy these
two.
Thanks,
Toshiaki Makita
next prev parent reply other threads:[~2014-06-11 6:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-09 11:34 [PATCH net-next 0/4] bridge: 802.1ad vlan protocol support Toshiaki Makita
2014-06-09 11:34 ` [PATCH net-next 1/4] bridge: Add 802.1ad tx vlan acceleration Toshiaki Makita
2014-06-09 11:34 ` [PATCH net-next 2/4] bridge: Prepare for 802.1ad vlan filtering support Toshiaki Makita
2014-06-09 11:34 ` [PATCH net-next 3/4] bridge: Consider the Nearest Customer Bridge group addresses Toshiaki Makita
2014-06-09 15:52 ` Stephen Hemminger
2014-06-09 16:45 ` Toshiaki Makita
2014-06-09 22:33 ` Vlad Yasevich
2014-06-10 7:05 ` Toshiaki Makita
2014-06-10 16:21 ` Stephen Hemminger
2014-06-11 6:12 ` Toshiaki Makita [this message]
2014-06-09 11:34 ` [PATCH net-next 4/4] bridge: Support 802.1ad vlan filtering Toshiaki Makita
2014-06-10 0:50 ` Vlad Yasevich
2014-06-10 7:15 ` Toshiaki Makita
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=5397F331.5020608@lab.ntt.co.jp \
--to=makita.toshiaki@lab.ntt.co.jp \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
--cc=vyasevic@redhat.com \
/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).