[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [15.193.32.64]) 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 [16.228.8.142]) 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 [16.180.154.163] (unknown [16.180.154.163]) 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:1.9.2.4) 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
Hello, 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 MALI. 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 transmitted. 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. regards, Balaji
- [magma] (Mldv2 ) Rfc 3810 clarifications/issues Balaji Sankaran