Re: [magma] Destination address in v2 leave message

Hitoshi Asaeda <asaeda@sfc.wide.ad.jp> Sat, 15 October 2011 16:49 UTC

Return-Path: <asaeda@sfc.wide.ad.jp>
X-Original-To: magma@ietfa.amsl.com
Delivered-To: magma@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BAD21F8B00 for <magma@ietfa.amsl.com>; Sat, 15 Oct 2011 09:49:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.096
X-Spam-Level:
X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQwupdW5ivWw for <magma@ietfa.amsl.com>; Sat, 15 Oct 2011 09:49:31 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 5362321F8A95 for <magma@ietf.org>; Sat, 15 Oct 2011 09:49:30 -0700 (PDT)
Received: from localhost (p16206-ipngn201hodogaya.kanagawa.ocn.ne.jp [114.175.255.206]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 7DBBA2780B9; Sun, 16 Oct 2011 01:48:57 +0900 (JST)
Date: Sun, 16 Oct 2011 01:48:57 +0900 (JST)
Message-Id: <20111016.014857.191479968.asaeda@sfc.wide.ad.jp>
To: bharat_joshi@infosys.com
From: Hitoshi Asaeda <asaeda@sfc.wide.ad.jp>
In-Reply-To: <31D55C4D55BEED48A4459EB64567589A1186EB24F2@BLRKECMBX02.ad.infosys.com>
References: <31D55C4D55BEED48A4459EB64567589A1186EB24F1@BLRKECMBX02.ad.infosys.com> <20111014.123005.235216170.asaeda@sfc.wide.ad.jp> <31D55C4D55BEED48A4459EB64567589A1186EB24F2@BLRKECMBX02.ad.infosys.com>
X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: magma@ietf.org
Subject: Re: [magma] Destination address in v2 leave message
X-BeenThere: magma@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/magma>, <mailto:magma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/magma>
List-Post: <mailto:magma@ietf.org>
List-Help: <mailto:magma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Oct 2011 16:49:31 -0000

Hi Bharat,

>          Yes. Querier need not be a multicast data forwarder. But
> are you suggesting that a forwarder who is not a IGMP querier
> process the leave message? If yes, what action do they take?

If non-querier on the link has the forwaring state for the
corresponding channels, it should be able to hear IGMP report and
proceed to change its state if needed, while it does not send any IGMP
query. The action on the router whether sending prune or not is
coordinated by the routing protocol, PIM.
This is my understanding.

>          As per RFC 2236, non-querier should be using group specific
> queries to lower down the group timer instead of leave messages.

It seems not very precise. RFC2236 says;

   When a non-Querier receives a Group-Specific Query message, if its
   existing group membership timer is greater than [Last Member Query
   Count] times the Max Response Time specified in the message, it sets
   its group membership timer to that value.

BTW, I found the following statements in RFC2236;

   Non-Queriers MUST ignore Leave Group messages, and Queriers SHOULD
   ignore Leave Group messages for which there are no group members on
   the reception interface.

But I don't think above "ignore" is appropriate.
I interpret "Non-Queriers MUST ignore Leave Group messages" to mean
"Non-Queriers MUST NOT respond IGMP queries when it receives Leave
Group messages". (If I'm wrong, please correct me.)
Anyway, we should refer RFC3376.

Regards,
--
Hitoshi Asaeda