Re: [magma] Destination address in v2 leave message

Hitoshi Asaeda <asaeda@sfc.wide.ad.jp> Mon, 17 October 2011 07:17 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 29BC611E8082 for <magma@ietfa.amsl.com>; Mon, 17 Oct 2011 00:17:51 -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 Mvvhj6ZLzkfQ for <magma@ietfa.amsl.com>; Mon, 17 Oct 2011 00:17:50 -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 7473C21F8AA9 for <magma@ietf.org>; Mon, 17 Oct 2011 00:17:49 -0700 (PDT)
Received: from localhost (unknown [IPv6:2001:200:0:8801:129a:ddff:fe4f:16d2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0C44C27806E; Mon, 17 Oct 2011 16:17:17 +0900 (JST)
Date: Mon, 17 Oct 2011 16:17:16 +0900
Message-Id: <20111017.161716.48811104.asaeda@sfc.wide.ad.jp>
To: bharat_joshi@infosys.com
From: Hitoshi Asaeda <asaeda@sfc.wide.ad.jp>
In-Reply-To: <31D55C4D55BEED48A4459EB64567589A1186EB24F5@BLRKECMBX02.ad.infosys.com>
References: <31D55C4D55BEED48A4459EB64567589A1186EB24F2@BLRKECMBX02.ad.infosys.com> <20111016.014857.191479968.asaeda@sfc.wide.ad.jp> <31D55C4D55BEED48A4459EB64567589A1186EB24F5@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: Mon, 17 Oct 2011 07:17:51 -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.
>>
> 
> Though I understand what you are suggesting. But a router that is
> non-querier won't be able to take a decision of pruning a
> multicast path with just a leave message. There may be others who
> are still interested in this group on that LAN and until that is
> made sure, non-querier cannot prune the multicast path. This is
> done by lowering the group timer when non-querier sees a group
> specific query from querier and once it expires, non-querier can
> prune the multicast path.
> 
> There may be one case where this non-querier router can prune on its
> own and in that case this router will have to keep track of all
> hosts who had subscribed to this group. Once the last host sent a
> leave message, non-querier need not wait for the group-specific
> query or group timeout.

Yes, your description is correct. I didn't mean different things.

> I remember seeing a draft for explicit tracking in PIM working group
>  sometime back so until this functionality is available, non-querier
>  cannot prune on their own.

The explicit tracking contributes to the first leave, but the draft
does not mention that last member query count should be 0.
This means, whether the explicit tracking function is enabled or not,
group(-and-source)-specific query for the channel should be sent when
the router thinks the report sender is the last member according to
its member record, and a router having the routing state for the
channel will coordinate prune for that channel if the router confirms
the report sender is the last member.

>> >          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.)
> 
> I think with 'ignore' also things work pretty much fine as I explained above.

I still don't think "ignore" is appropriate here.

>> Anyway, we should refer RFC3376.
>> 
> 
> To me RFC 3376 also looks pretty much same. Do you see any
> difference in processing for the above case in RFC 3376?

RFC3376 does not say "Non-Queriers MUST ignore Leave Group messages or
other IGMP messages".
If a non-querier router has some routing states, it must also
recognize IGMP messages. This is what I understand.

Regards,
--
Hitoshi Asaeda