From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA456C43381 for ; Fri, 22 Feb 2019 07:57:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B704B20818 for ; Fri, 22 Feb 2019 07:57:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dM0970wl" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726254AbfBVH5S (ORCPT ); Fri, 22 Feb 2019 02:57:18 -0500 Received: from mail-pf1-f193.google.com ([209.85.210.193]:42183 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725855AbfBVH5S (ORCPT ); Fri, 22 Feb 2019 02:57:18 -0500 Received: by mail-pf1-f193.google.com with SMTP id n74so739554pfi.9 for ; Thu, 21 Feb 2019 23:57:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ML/U6GeUuR8T3SyeUgFEK2FTyyJf1genMhIvuiP8ZaI=; b=dM0970wlvHxnA2o2DJTtZuZ8MeVNEOwpGesMQfblX6hKXz5kZm/UKnzJ+QbflkhPdm kKg9HcJYD/l+PVIDmIxHqxrQv0HihUhWBOyrOS8/+j8L8y9VJuOch7UzpcS7IXnpDwxc fx6WhGYaMvKPofJlc3T8DEFEAg7NSUAxibEAAJXuFzLLrmiAwIvmBDX7woiyumpRczrl RZHT9BC6r4xbR9qol7hZxui7f603yNmo+06zd2jWzr7oYgK3k1XsQOh3toOk9eeUV1NE z5JZf+brOE0Lr/zf17OFGBoi8aZUPLSA8PSgCj5FWuUlp1SHLGAmpgrnSU/WZ7SDfw0r cBfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ML/U6GeUuR8T3SyeUgFEK2FTyyJf1genMhIvuiP8ZaI=; b=ms3esGVyRkSJntJxmK93zehQtip0OE0fwU4ZAyPcZLhOWZJZAXD9Df3yzuE27ITvir Ut/NyDKXEzh5Hlu1I/XPD876eAIgsAYk2ySvyYuRzwTHnqc6srrErbteWqZM8HG5i4dp 9OqkEeoz2KsT1nWZi9TKTTu2EQlI1kfueuuQ0n4F/WOEP2xyLC5sLF0jhLN2/ew3SGXe M0vEMT6eSqykSMCcaeWf0ztMS3EhHnePu1mfg+SLEsYpQMN1dwUac97A+O19dBFyDX06 vzeu3N95jyeT0SO3OqAq+/ggpgZrf7pGTnTipvPtwJ0Xsxo73Bq4Tabo2hAAgdRXRcdf W99Q== X-Gm-Message-State: AHQUAubtIIIWKKszvrJuu9ijkJK4FV3km4qRr1vw9t66nEz/zsorL7Go zyQLRjNe2Sc7PrBqM9vw6kA= X-Google-Smtp-Source: AHgI3IYDv5n2hO2/jXXpC43F01cp/iHqo+CYBBGejG2V9nfnJ++7tseQ7TXrj7lxZCs3idh8o4JlaQ== X-Received: by 2002:a63:2882:: with SMTP id o124mr2779075pgo.446.1550822236964; Thu, 21 Feb 2019 23:57:16 -0800 (PST) Received: from dhcp-12-139.nay.redhat.com ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id l64sm2910737pga.87.2019.02.21.23.57.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 21 Feb 2019 23:57:16 -0800 (PST) Date: Fri, 22 Feb 2019 15:57:05 +0800 From: Hangbin Liu To: Nikolay Aleksandrov Cc: Linus =?iso-8859-1?Q?L=FCssing?= , netdev@vger.kernel.org, roopa@cumulusnetworks.com, bridge@lists.linux-foundation.org, davem@davemloft.net, yinxu@redhat.com, Sebastian Gottschall Subject: Re: [Bridge] [PATCH net] net: bridge: remove ipv6 zero address check in mcast queries Message-ID: <20190222075705.GN10051@dhcp-12-139.nay.redhat.com> References: <90c5f2fe-1743-6b17-2e44-eba58cdbbb35@cumulusnetworks.com> <20181027090747.22104-1-nikolay@cumulusnetworks.com> <20181029013316.GK24677@leo.usersys.redhat.com> <20181213161027.GC1713@otheros> <20190221080114.GL10051@dhcp-12-139.nay.redhat.com> <9db055dd-6486-1d6e-7dce-edc511650af9@cumulusnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9db055dd-6486-1d6e-7dce-edc511650af9@cumulusnetworks.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi Nikolay, On Thu, Feb 21, 2019 at 03:20:14PM +0200, Nikolay Aleksandrov wrote: > > > > Yes, I agree. But this "regression" could be fixed by setting up correct > > switch configuration. See more explains below. > > > > That is irrelevant, if the setup once worked we should not break it unless > it's in RFC requirement violation and RFC 4541 is only suggestive, not required. Thanks for your reply. I just noticed the RFC4541 category is informational. > > "because this would cause the Queries to be seen as coming from a newly > > elected Querier" means other address could be elected as a Querier but > > "0.0.0.0" should not. > > > > But this change hasn't been incorporated, has it ? A 0.0.0.0 address currently > will always win the election and silence all of the rest. Current bridge state > is simply broken for some cases because of that. Yes. I agree. I realized linus also said """ However, one of the two options seems to be necessary. Either reverting the patch for the IGMP part, too. Or Ignoring 0.0.0.0 sources for querier eletcion and presence detection. """ > > Removing 0.0.0.0 from the election will effectively disable snooping even if there's > a configured bridge unless it has an address. You can see that this will end up in > people having suddenly their multicast flooded with current setups, right ? Yes > Any big behaviour change like that should be optional, but I don't think we need > another option as this is not so big of a deal because we're not breaking any > required behaviour. Just a little curious, RFC 3376 said the General Queries are sent from multicast routers. I think a router *should* has a IP address, isn't it? RFC 4541 also suggested: If the switch is not the Querier, it should use the 'all-zeros' IP Source Address in these proxy queries (even though some hosts may elect to not process queries with a 0.0.0.0 IP Source Address). When such proxy queries are received, they must not be included in the Querier election process. And what I got is most vendors apply this suggestion. > In case you decide to follow the option path, please use the new boolopt api to avoid > adding new fields to the bridge, this should be an on/off thing. I still vote for a > revert though. For consistency with other vendors and rfc, I would prefer to remove zero address election. For compatibility with previous users, I'm also OK to revert it. Regards Hangbin