[magma] (Mldv2 ) Rfc 3810 clarifications/issues

Balaji Sankaran <sankaran.balaji@hp.com> Wed, 10 November 2010 07:13 UTC

Return-Path: <sankaran.balaji@hp.com>
X-Original-To: magma@core3.amsl.com
Delivered-To: magma@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 5A7AA3A6864 for <magma@core3.amsl.com>; Tue, 9 Nov 2010 23:13:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.099
X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4sO1D6yjWD3M for <magma@core3.amsl.com>; Tue, 9 Nov 2010 23:13:16 -0800 (PST)
Received: from g6t0187.atlanta.hp.com (g6t0187.atlanta.hp.com []) by core3.amsl.com (Postfix) with ESMTP id D78143A69BA for <magma@ietf.org>; Tue, 9 Nov 2010 23:13:14 -0800 (PST)
Received: from g5t0030.atlanta.hp.com (g5t0030.atlanta.hp.com []) by g6t0187.atlanta.hp.com (Postfix) with ESMTP id 903B82863A for <magma@ietf.org>; Wed, 10 Nov 2010 07:13:40 +0000 (UTC)
Received: from [] (unknown []) by g5t0030.atlanta.hp.com (Postfix) with ESMTP id 7480714122 for <magma@ietf.org>; Wed, 10 Nov 2010 07:13:38 +0000 (UTC)
Message-ID: <4CDA4621.8060704@hp.com>
Date: Wed, 10 Nov 2010 12:43:37 +0530
From: Balaji Sankaran <sankaran.balaji@hp.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1
MIME-Version: 1.0
To: "magma@ietf.org" <magma@ietf.org>
Content-Type: multipart/alternative; boundary="------------080005090304070501040804"
Subject: [magma] (Mldv2 ) Rfc 3810 clarifications/issues
X-BeenThere: magma@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 10 Nov 2010 07:13:30 -0000


I need a couple of clarifications in MldV2 Rfc 3810.

1)  In section 7.4,1 "Reception of Current State Records", I see the 
following operation

  EXCLUDE (X,Y)     IS_EX (A)     EXCLUDE (A-Y, Y*A) (A-X-Y)=MALI
                                                       Delete (X-A)
                                                       Delete (Y-A)
                                                       Filter Timer=MALI

Whether the src timer (A-X-Y) should be set to Filter timer instead of 
MALI.  Why we need
to set the src Timer for these srcs to MALI ?.  Setting it to MALI will 
take longer time for  these
srcs to get excluded.

Note that  TO_EXC report handling sets them to Filter timer instead of 

EXCLUDE (X,Y)   TO_EX (A)      EXCLUDE (A-Y,Y*A)    (A-X-Y) =
                                                             Filter Timer
                                                        Delete (X-A)
                                                        Delete (Y-A)
                                                        Send Q(MA,A-Y)
                                                        Filter Timer=MALI

2)  Regarding src deletion when there is a GSSQ retransmission scheduled 
for it:

Lets take the following reports:

Report A  { M1, IS_IN (S1, S2)  }
Report B  { M1, TO_EX (S1,S2) }
Report C { M1, IS_EX ( S1,S3) }

Step 1)* Send Report A *
Router will have following information for Multicast address M1,

State -           Include
src-include-list  -  S1, S2

Step 2) *Send Report B *
After handling Report B, following will be the state information for M1

State - Exclude
Src-Req-list : S1,S2
Src-Exc-List: Empty
There will be a GSSQ packet send for S1 and S2 with Sbit Unset.
There will be another GSSQ packet scheduled for these srcs (S1 and
S2)  later at LLQT interval.

Step 3) *Send Report C* before the scheduled GSSQ for S1 and S2 is 
According to the state  table, Report C handling will   delete the src 
S2 (Delete
(X-A) ).

EXCLUDE (X,Y)   TO_EX (A)      EXCLUDE (A-Y,Y*A)    (A-X-Y) =
                                                             Filter Timer
                                                        Delete (X-A)
                                                        Delete (Y-A)
                                                        Send Q(MA,A-Y)
                                                        Filter Timer=MALI

However there is an GSSQ pending for the src S2.  So what we do now ?  
Delete the src S2 and cancel the
retransmission ?  Or delete the src but do not cancel the retransmission 
?. If we are not canceling the
retransmission, whether Sbit should be True for this query ?.    I 
believe we should delete the src
and this in turn should cancel the GSSQ retransmission for this src as 
well. Let me know
if anybody has any thoughts on this.