Re: [magma] Destination address in v2 leave message

Bharat Joshi <bharat_joshi@infosys.com> Mon, 17 October 2011 06:52 UTC

Return-Path: <bharat_joshi@infosys.com>
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 74E3C21F8672 for <magma@ietfa.amsl.com>; Sun, 16 Oct 2011 23:52:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 ZqkGaYrF1N6M for <magma@ietfa.amsl.com>; Sun, 16 Oct 2011 23:52:35 -0700 (PDT)
Received: from KECGATE08.infosys.com (kecgate08.infosysconsulting.com [122.98.10.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1916121F85D1 for <magma@ietf.org>; Sun, 16 Oct 2011 23:52:34 -0700 (PDT)
X-TM-IMSS-Message-ID: <6b85fd800007dae1@infosys.com>
Received: from blrkechub02.ad.infosys.com ([10.66.236.42]) by infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 6b85fd800007dae1 ; Mon, 17 Oct 2011 12:29:14 +0530
Received: from blrkechub12.ad.infosys.com (10.66.236.47) by blrkechub02.ad.infosys.com (10.66.236.42) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 Oct 2011 12:21:07 +0530
Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub12.ad.infosys.com ([10.66.236.47]) with mapi; Mon, 17 Oct 2011 12:21:07 +0530
From: Bharat Joshi <bharat_joshi@infosys.com>
To: Hitoshi Asaeda <asaeda@sfc.wide.ad.jp>
Date: Mon, 17 Oct 2011 12:21:06 +0530
Thread-Topic: [magma] Destination address in v2 leave message
Thread-Index: AcyLWjCNCDHxPfOrRX+vOsGgxKw51ABPPrav
Message-ID: <31D55C4D55BEED48A4459EB64567589A1186EB24F5@BLRKECMBX02.ad.infosys.com>
References: <31D55C4D55BEED48A4459EB64567589A1186EB24F1@BLRKECMBX02.ad.infosys.com> <20111014.123005.235216170.asaeda@sfc.wide.ad.jp> <31D55C4D55BEED48A4459EB64567589A1186EB24F2@BLRKECMBX02.ad.infosys.com>, <20111016.014857.191479968.asaeda@sfc.wide.ad.jp>
In-Reply-To: <20111016.014857.191479968.asaeda@sfc.wide.ad.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "magma@ietf.org" <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 06:52:36 -0000

Hi Hitoshi,

> >          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.

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.
 
> >          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.

> 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?

Regards,
Bharat

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***