From wwwrun@rfc-editor.org Wed Dec 5 17:29:09 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC4121F8CF3; Wed, 5 Dec 2012 17:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.894 X-Spam-Level: X-Spam-Status: No, score=-101.894 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUVC96hCQ7C6; Wed, 5 Dec 2012 17:29:08 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D4BE721F8CE9; Wed, 5 Dec 2012 17:29:08 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 116F972F4F2; Wed, 5 Dec 2012 17:20:52 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121206012052.116F972F4F2@rfc-editor.org> Date: Wed, 5 Dec 2012 17:20:52 -0800 (PST) Cc: pim@ietf.org, rfc-editor@rfc-editor.org Subject: [pim] RFC 6807 on Population Count Extensions to Protocol Independent Multicast (PIM) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 01:29:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6807 Title: Population Count Extensions to Protocol Independent Multicast (PIM) Author: D. Farinacci, G. Shepherd, S. Venaas, Y. Cai Status: Experimental Stream: IETF Date: December 2012 Mailbox: dino@cisco.com, gjshep@gmail.com, stig@cisco.com, yiqunc@microsoft.com Pages: 15 Characters: 32114 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pim-pop-count-07.txt URL: http://www.rfc-editor.org/rfc/rfc6807.txt This specification defines a method for providing multicast distribution-tree accounting data. Simple extensions to the Protocol Independent Multicast (PIM) protocol allow a rough approximation of tree-based data in a scalable fashion. This document defines an Experimental Protocol for the Internet community. This document is a product of the Protocol Independent Multicast Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From vero.zheng@huawei.com Mon Dec 10 01:12:30 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D778721F8D9C for ; Mon, 10 Dec 2012 01:12:30 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8muelgH+ej3 for ; Mon, 10 Dec 2012 01:12:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDF821F899F for ; Mon, 10 Dec 2012 01:12:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANQ57491; Mon, 10 Dec 2012 09:12:27 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Dec 2012 09:11:44 +0000 Received: from SZXEML425-HUB.china.huawei.com (10.72.61.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Dec 2012 09:12:25 +0000 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.142]) by szxeml425-hub.china.huawei.com ([10.72.61.33]) with mapi id 14.01.0323.003; Mon, 10 Dec 2012 17:12:20 +0800 From: Vero Zheng To: "pim@ietf.org" Thread-Topic: [pim] New Version Notification for draft-zzp-pim-rfc4601-update-survey-report-00.txt (Survey Report on PIM-SM Implementations and Deployment) Thread-Index: AQHN1rZ1y5KXReW8tkOR6ENaaNZbdQ== Date: Mon, 10 Dec 2012 09:12:19 +0000 Message-ID: <2EEA459CD95CCB4988BFAFC0F2287B5C35549A3C@SZXEML552-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.115] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Mike McBride , "Rishabh Parekh \(riparekh\)" , Stig Venaas Subject: [pim] New Version Notification for draft-zzp-pim-rfc4601-update-survey-report-00.txt (Survey Report on PIM-SM Implementations and Deployment) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 09:12:31 -0000 SGkgYWxsLA0KDQpXZSd2ZSBiZWVuIHdvcmtpbmcgb24gdGhlIFJGQzQ2MDEgdXBkYXRlIGZvciBh IHdoaWxlLg0KDQpTdGlnIGhhZCBnaXZlbiB0aGUgUkZDNDYwMS1iaXMgc3VydmV5IHByZWxpbWlu YXJ5IHJlcG9ydCBvbiBBdGxhbnRhIG1lZXRpbmcsIGFuZCBoZXJlIGlzIHRoZSBkZXRhaWwgc3Vy dmV5IHJlcG9ydC4NClRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gZW5jb3VyYWdlIHlvdSB0byBy ZWFkIGl0IGFuZCBmZWVkYmFjay4NCg0KQ2hlZXJzLA0KUmlzaGFiaCwgSmVmZmVyeSBhbmQgVmVy bw0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6 IDIwMTLlubQxMuaciDEw5pelIDE1OjAxDQrmlLbku7bkuro6IFZlcm8gWmhlbmcNCuaKhOmAgTog enpoYW5nQGp1bmlwZXIubmV0OyByaXBhcmVraEBjaXNjby5jb20NCuS4u+mimDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16enAtcGltLXJmYzQ2MDEtdXBkYXRlLXN1cnZleS1y ZXBvcnQtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXp6cC1waW0tcmZj NDYwMS11cGRhdGUtc3VydmV5LXJlcG9ydC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgTGlhbnNodSBaaGVuZyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0 b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXp6cC1waW0tcmZjNDYwMS11cGRhdGUtc3VydmV5LXJl cG9ydA0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgU3VydmV5IFJlcG9ydCBvbiBQSU0tU00gSW1w bGVtZW50YXRpb25zIGFuZCBEZXBsb3ltZW50cw0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMTItMTAN CldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxNQ0KVVJM OiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16 enAtcGltLXJmYzQ2MDEtdXBkYXRlLXN1cnZleS1yZXBvcnQtMDAudHh0DQpTdGF0dXM6ICAgICAg ICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtenpwLXBpbS1yZmM0NjAx LXVwZGF0ZS1zdXJ2ZXktcmVwb3J0DQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXp6cC1waW0tcmZjNDYwMS11cGRhdGUtc3VydmV5LXJlcG9ydC0wMA0K DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBzdXBwb3J0aW5nIGRvY3Vt ZW50YXRpb24gdG8gYWR2YW5jZSB0aGUNCiAgIFByb3RvY29sIEluZGVwZW5kZW50IE11bHRpY2Fz dCAtIFNwYXJzZSBNb2RlIChQSU0tU00pIHJvdXRpbmcNCiAgIHByb3RvY29sIGZyb20gSUVURiBQ cm9wb3NlZCBTdGFuZGFyZCB0byBJbnRlcm5ldCBTdGFuZGFyZC4NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From internet-drafts@ietf.org Mon Dec 10 21:58:30 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CCE21F878F; Mon, 10 Dec 2012 21:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8F+Kd1dxODI9; Mon, 10 Dec 2012 21:58:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C30C21F8568; Mon, 10 Dec 2012 21:58:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121211055814.410.35377.idtracker@ietfa.amsl.com> Date: Mon, 10 Dec 2012 21:58:14 -0800 Cc: pim@ietf.org Subject: [pim] I-D Action: draft-ietf-pim-explicit-tracking-03.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 05:58:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol Independent Multicast Working Gr= oup of the IETF. Title : IGMP/MLD-Based Explicit Membership Tracking Function for= Multicast Routers Author(s) : Hitoshi Asaeda Filename : draft-ietf-pim-explicit-tracking-03.txt Pages : 10 Date : 2012-12-10 Abstract: This document describes the IGMP/MLD-based explicit membership tracking function for multicast routers. The explicit tracking function contributes to saving network resources and fast leaves (i.e. shortening leave latency). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pim-explicit-tracking There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pim-explicit-tracking-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pim-explicit-tracking-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From asaeda@sfc.wide.ad.jp Mon Dec 10 22:00:03 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3623421F8593 for ; Mon, 10 Dec 2012 22:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id js5KNa+zIHlp for ; Mon, 10 Dec 2012 22:00:01 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id BAF7621F882E for ; Mon, 10 Dec 2012 22:00:00 -0800 (PST) Received: from localhost (unknown [202.249.37.10]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B2D0E27811E; Tue, 11 Dec 2012 14:59:58 +0900 (JST) Date: Tue, 11 Dec 2012 15:00:00 +0900 (JST) Message-Id: <20121211.150000.148200244.asaeda@sfc.wide.ad.jp> To: sfigueiredo@av.it.pt From: Hitoshi Asaeda In-Reply-To: <5098EAD2.40600@av.it.pt> References: <5098EAD2.40600@av.it.pt> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pim@ietf.org Subject: Re: [pim] I-D Action: draft-ietf-pim-explicit-tracking-02.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 06:00:03 -0000 Hi S=E9rgio, Thank you for your comments. I also found several editorial ambiguities and duplicate sentenses inside the previous draft. I've just submitted the revised draft. Please read it. I also write some comments below. > Section 1: > "This function implements the following requirements (... ) where thi= s > document mainly focuses on the above second and third bullets in the > following sections." > Q1 - It seems the described list mixes features with > requirements. Alternatively, if these are in fact requirements, I > don't think it is acceptable that only 2 of them are described, at > least not with justifying why the others are negligible. Ok, we change the statement to "This function enables the following" and remove "where this document mainly focuses on the above first and second bullets in the following sections" as it's not a necessary message for this specification. > Section 2: > - The organization of Section 2 could be improved, or at least an > - introduction for what is described within it should be placed; > = > Section 2.1 > "This mechanism is called "specific query surpression mechanism." > Q2 - It seems that what you refer to as a mechanism is more of an > advantage of the explicit tracking function itself: i.e. reduction of= > number of group / channel specific Query messages plus Current-State > Report messages). Also, it should be corrected it to "suppression". Ok, we can eliminate the word, "mechanism", so now it is smiply "specific query suppression". > "If a router enables the explicit tracking function, it does not need= > to always ask Current-State Report message transmission to the member= > hosts whenever it receives the State- Change Report." > Q3 - Do you mean it does not send a group or channel specific Query b= y > default whenever it receives the State-Change Report"? No. The router sends a specific query as the default. > Q4 - Why is it stated "it does not need to"? Is a decision involved > and when does it apply? Which one and based on what information? Specific queries are used to confirm whether the State-Change report sender is the sole member of that session/channel or not. But a router turning on the explicit tracking function can expect the report sender is the sole member or not. So, it does not need to do so. Anyway I've changed the corresponding statement a little as follows; "If a router enables the explicit tracking function with "specific query suppression", it suppresses specific query transmission and transmits specific query messages only when the router expects that the State-Change Report sender is the sole member of the channel, based on its membership state information." When it applies? It applies when a router enables the explicit tracking function and spe= cific query suppression. > "This is because the explicit tracking function works with the > expectation that the State-Change Report sender is the last remaining= > member of the channel." > Q5 - I am sorry but I am puzzled by this sentence. Shouldn't this be > only assumed after checking whether the list of "receiver records" fo= r > a group / channel is limited to one member? When the router expects the report sender is the sole member. > "Even if this expectation is wrong (i.e., the State-Change Report > sender was not the sole member), other members remaining in the same > channel will reply with identical Report messages, so the end result > is the same and no problem occurs. (Section 3 > > details the point.)" > Q6 - reading this sentence makes me realize that probably the word > "assumption" should be used instead of "expectation". I believe "expectation" is better. Because existance of remaining active members is not assumed, but expected. > Q7 - related to the previous point, I can't understand why the router= > always expects this, disregarding the membership records for which th= e > Explicit Tracking Function is introduced. More concerning is that I > can't find any justification or correlation to this on section > 3. Should it be Section 2.3? Section 4 in the revised draft clarifies it. > Q8 - How does the router's failed expectation that the sender is the > sole member impact on the behaviour of other members? Section 4 explains it. > Q9 - What do you mean by "identical Report messages"? If you're > talking about State-Change Reports, why would these other interested > members send State-Change Reports if they're still subscribing the > group / channel? How is it assured that the multicast router doesn't > remove a state for a group / channel being received by other > members? It is standard behavior defined in rfc3376 and 3810. > Q10 - Why is there no reference to Multicast Address Listener Interva= l > (MALI) from MLDv2 RFC? Doesn't it impact your assumptions? MALI does not impact fast leave. Fast leave is realized by tuning LMQI/LLQI and LMQC/LLQC (and hence LMQT/LLQT). > "When the querier surpresses the specific query message transmission,= > if it recognizes that the State-Change Report sender is not the sole > member of the channel, (...)" > Q11 - How does it recognize the Report sender is not the sole member > of the channel It is stated several times that it expects the mobile > host to be the last member so in which cases is this verified > against? Routers enabling the function maintain the "membership state information". By referring the membership state information, they can expect the report sender is the sole member of the channel or not. Whether the report sender is a mobile host or not is not important. > When reading the document it seems that the router expects any > State-Change Report sender to be the last member of a > subscription. Just to be sure, is this correct or am I missing > something? The membership state information consists of (S, G, number of receivers, (receiver records)). Routers maintain this record and expect who are now active and whether the state-change report sender is the sole member or not. > "he [Last Member Query Interval] (LMQI) and [Last Listener Query > Interval] (LLQI) values specify the maximum time allowed before > sending a responding Report." > Q12 - It should be corrected to "(...) before sending a responding > Query". No. "... before sending a responding Report" is correct. > Section 2.3 > "IGMP/MLD messages are non-reliable and may be lost in the > transmission, therefore routers need to confirm the membership by > sending Query messages" > Q13 - does the text refer to General Queries only? No, this "Query messages" means any kinds of query messages. > Overall, my impression is that the default operation (as well as any > operation option) of the multicast router should be clearer. Thanks. I believe the revised one clearly mentioned it. Regards, -- Hitoshi Asaeda From stbryant@cisco.com Mon Dec 17 10:29:50 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C83121F8BBB; Mon, 17 Dec 2012 10:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.573 X-Spam-Level: X-Spam-Status: No, score=-110.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLaiBuWbibVH; Mon, 17 Dec 2012 10:29:49 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 24D7B21F8B77; Mon, 17 Dec 2012 10:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=512; q=dns/txt; s=iport; t=1355768985; x=1356978585; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=dck+bk0rjEv/+grlwx0T65yVNVJXXdWaTcqbnH0isYw=; b=Y/7BHA3L7q6Mhyqqc9OS+cYhKtkLWmvHTBb0MFokJeWMcTc9KW7YR4S+ XdBU0GaKOWvdA4NlzJGUoikq6+m5tdO0lekh9XQipor7t7WvOwTmKAOKH WTYM+L1PfdwmoU0tuIdJHUPwobJzgFDs+USmB6Bax4uVayfpKfWsCY4rC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYHADZiz1CQ/khR/2dsb2JhbABFg0i6axZzgl1AATwWGAMCAQIBSwEMAQcBAYgPn0aaRZEgA5YKkEiCcw X-IronPort-AV: E=Sophos;i="4.84,303,1355097600"; d="scan'208";a="148473663" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 17 Dec 2012 18:29:43 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBHITgJR017592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Dec 2012 18:29:42 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id qBHITftV009601; Mon, 17 Dec 2012 18:29:41 GMT Message-ID: <50CF64A3.8060208@cisco.com> Date: Mon, 17 Dec 2012 18:29:55 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: idr mailing list , "mpls@ietf.org" , pce@ietf.org, pim@ietf.org, "idr-chairs@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , pce-chairs@tools.ietf.org, pim-chairs@toosl.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtg-ads@tools.ietf.org" Subject: [pim] draft-ietf-karp-routing-tcp-analysis review requested X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 18:29:50 -0000 Hi all, draft-ietf-karp-routing-tcp-analysis is on the IESG agenda for 10/Jan. It has been through IETF LC, but we realize that it would be useful for the IDR, MPLS, PCE and PIM working groups to pay special attention to the draft review the sections of this draft that are relevant to their (your) work. I would appreciate feedback from anyone in the WG, but it would be helpful if the WG Chairs could nominate at least one person to review the draft on behalf of the WG. Thanks Stewart From sfigueiredo@av.it.pt Fri Dec 21 09:45:41 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D267C21F871A for ; Fri, 21 Dec 2012 09:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaOyhbcjPMix for ; Fri, 21 Dec 2012 09:45:41 -0800 (PST) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 65FD221F86A1 for ; Fri, 21 Dec 2012 09:45:39 -0800 (PST) Received: from [193.136.93.217] (account sfigueiredo@av.it.pt [193.136.93.217] verified) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 67410597; Fri, 21 Dec 2012 17:45:37 +0000 Message-ID: <50D4A044.3000006@av.it.pt> Date: Fri, 21 Dec 2012 17:45:40 +0000 From: =?ISO-8859-1?Q?S=E9rgio_Figueiredo?= User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Hitoshi Asaeda References: <5098EAD2.40600@av.it.pt> <20121211.150000.148200244.asaeda@sfc.wide.ad.jp> In-Reply-To: <20121211.150000.148200244.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pim@ietf.org Subject: Re: [pim] I-D Action: draft-ietf-pim-explicit-tracking-02.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 17:45:42 -0000 Hi Hitoshi, Thank you for the detailed answers and clarifications, and for taking into account all my comments. Please refer to my answers below. Em 11-12-2012 06:00, Hitoshi Asaeda escreveu: > Hi Sérgio, > > Thank you for your comments. I also found several editorial > ambiguities and duplicate sentenses inside the previous draft. > I've just submitted the revised draft. Please read it. > > I also write some comments below. > >> Section 1: >> "This function implements the following requirements (... ) where this >> document mainly focuses on the above second and third bullets in the >> following sections." >> Q1 - It seems the described list mixes features with >> requirements. Alternatively, if these are in fact requirements, I >> don't think it is acceptable that only 2 of them are described, at >> least not with justifying why the others are negligible. > Ok, we change the statement to "This function enables the following" > and remove "where this document mainly focuses on the above first and > second bullets in the following sections" as it's not a necessary > message for this specification. SF: Ok. > >> Section 2: >> - The organization of Section 2 could be improved, or at least an >> - introduction for what is described within it should be placed; >> >> Section 2.1 >> "This mechanism is called "specific query surpression mechanism." >> Q2 - It seems that what you refer to as a mechanism is more of an >> advantage of the explicit tracking function itself: i.e. reduction of >> number of group / channel specific Query messages plus Current-State >> Report messages). Also, it should be corrected it to "suppression". > Ok, we can eliminate the word, "mechanism", so now it is smiply > "specific query suppression". SF: Ok. Now that it is much clearer to me, I see no problem with the usage of "mechanism". What was not clear before was that "specific query suppression" was something that could be enabled / activated when using Explicit tracking function for the goal of achieving better efficiency; on the other hand Explicit tracking can be used for per-host accounting or other functions which are independent of this suppression mechanism. > >> "If a router enables the explicit tracking function, it does not need >> to always ask Current-State Report message transmission to the member >> hosts whenever it receives the State- Change Report." >> Q3 - Do you mean it does not send a group or channel specific Query by >> default whenever it receives the State-Change Report"? > No. The router sends a specific query as the default. SF: Ok, I see you improved the text significantly, good to see. > >> Q4 - Why is it stated "it does not need to"? Is a decision involved >> and when does it apply? Which one and based on what information? > Specific queries are used to confirm whether the State-Change report > sender is the sole member of that session/channel or not. But a router > turning on the explicit tracking function can expect the report sender > is the sole member or not. So, it does not need to do so. > > Anyway I've changed the corresponding statement a little as follows; > "If a router enables the explicit tracking function with "specific > query suppression", it suppresses specific query transmission and > transmits specific query messages only when the router expects that > the State-Change Report sender is the sole member of the channel, > based on its membership state information." > > When it applies? > It applies when a router enables the explicit tracking function and specific > query suppression. SF: Ok. Again, now it is more clear to me in which cases specific query suppression may not be activated. > >> "This is because the explicit tracking function works with the >> expectation that the State-Change Report sender is the last remaining >> member of the channel." >> Q5 - I am sorry but I am puzzled by this sentence. Shouldn't this be >> only assumed after checking whether the list of "receiver records" for >> a group / channel is limited to one member? > When the router expects the report sender is the sole member. SF: Ok, understood from previous text. > >> "Even if this expectation is wrong (i.e., the State-Change Report >> sender was not the sole member), other members remaining in the same >> channel will reply with identical Report messages, so the end result >> is the same and no problem occurs. (Section 3 >> >> details the point.)" >> Q6 - reading this sentence makes me realize that probably the word >> "assumption" should be used instead of "expectation". > I believe "expectation" is better. Because existance of remaining > active members is not assumed, but expected. SF: Ok, clarified. > >> Q7 - related to the previous point, I can't understand why the router >> always expects this, disregarding the membership records for which the >> Explicit Tracking Function is introduced. More concerning is that I >> can't find any justification or correlation to this on section >> 3. Should it be Section 2.3? > Section 4 in the revised draft clarifies it. SF: Cleared, most issues were in fact related :) > >> Q8 - How does the router's failed expectation that the sender is the >> sole member impact on the behaviour of other members? > Section 4 explains it. SF: Ok. > >> Q9 - What do you mean by "identical Report messages"? If you're >> talking about State-Change Reports, why would these other interested >> members send State-Change Reports if they're still subscribing the >> group / channel? How is it assured that the multicast router doesn't >> remove a state for a group / channel being received by other >> members? > It is standard behavior defined in rfc3376 and 3810. Sure, but my point is, if you activate the suppression mechanism, no query will be sent in case the router expects the report sender to be the sole member of the subscription. Consequently, the other receivers will not send "identical report messages". Anyway, I see you removed this from current text so it's ok now. > >> Q10 - Why is there no reference to Multicast Address Listener Interval >> (MALI) from MLDv2 RFC? Doesn't it impact your assumptions? > MALI does not impact fast leave. Fast leave is realized by tuning > LMQI/LLQI and LMQC/LLQC (and hence LMQT/LLQT). SF: Ok. > >> "When the querier surpresses the specific query message transmission, >> if it recognizes that the State-Change Report sender is not the sole >> member of the channel, (...)" >> Q11 - How does it recognize the Report sender is not the sole member >> of the channel It is stated several times that it expects the mobile >> host to be the last member so in which cases is this verified >> against? > Routers enabling the function maintain the "membership state > information". By referring the membership state information, they can > expect the report sender is the sole member of the channel or > not. Whether the report sender is a mobile host or not is not > important. SF: Ok. > >> When reading the document it seems that the router expects any >> State-Change Report sender to be the last member of a >> subscription. Just to be sure, is this correct or am I missing >> something? > The membership state information consists of (S, G, number of > receivers, (receiver records)). Routers maintain this record and > expect who are now active and whether the state-change report sender > is the sole member or not. SF: Ok. > >> "he [Last Member Query Interval] (LMQI) and [Last Listener Query >> Interval] (LLQI) values specify the maximum time allowed before >> sending a responding Report." >> Q12 - It should be corrected to "(...) before sending a responding >> Query". > No. "... before sending a responding Report" is correct. SF: The usage of "before sending a responding Report" leads to the notion that we're referring to the router side. I would suggest that you explicitly state "allowed for a subscription member to send a responding Report before the router prunes the group or sources from the network". > >> Section 2.3 >> "IGMP/MLD messages are non-reliable and may be lost in the >> transmission, therefore routers need to confirm the membership by >> sending Query messages" >> Q13 - does the text refer to General Queries only? > No, this "Query messages" means any kinds of query messages. SF: Ok, thank you. Additionally, I have one more suggestion: - In section 1, when it is stated "To resolve the problem", I think that "To alleviate the problem" would fit better. The reason for this is that in case of a lost "report", there are still lost data packets during the interval between the lost IGMP/MLD Report and the next General Query. - correct small typo in section 1: "may not reached" -> "reach". Best regards, Sérgio > >> Overall, my impression is that the default operation (as well as any >> operation option) of the multicast router should be clearer. > Thanks. I believe the revised one clearly mentioned it. > > Regards, > -- > Hitoshi Asaeda