From stig@venaas.com Fri Nov 2 13:37:58 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 EDDDA21F9A57 for ; Fri, 2 Nov 2012 13:37:58 -0700 (PDT) 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 wUP-i-VgRuql for ; Fri, 2 Nov 2012 13:37:58 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 5C28621F9A37 for ; Fri, 2 Nov 2012 13:37:58 -0700 (PDT) Received: from [10.21.66.49] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 887617FCE for ; Fri, 2 Nov 2012 21:37:56 +0100 (CET) Message-ID: <50942F1C.1080709@venaas.com> Date: Fri, 02 Nov 2012 13:37:48 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: pim@ietf.org References: <5081C52F.7000609@venaas.com> In-Reply-To: <5081C52F.7000609@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pim] pim agenda for IETF 85 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, 02 Nov 2012 20:37:59 -0000 Here is the latest agenda update. pim wg meeting Monday November 5, 2012 13-15 Title Presenter Minutes ========================================================================== WG Status Stig/Mike 10 draft-asghar-pim-explicit-rpf-vector-00 Vishal Arya 10 4601 update Stig 10 draft-ietf-pim-explicit-tracking-01 Hitoshi Asaeda 10 draft-liu-multimob-igmp-mld-wireless-mobile-02 Mike McBride 10 draft-zhou-pim-vrrp-00 Stig Venaas 20 draft-asaeda-pim-mldproxy-multif-00 Hitoshi Asaeda 10 draft-contreras-multimob-multiple-upstreams-00 Carlos J. Bernardos 10 The RPF vector presentation is moved up because the authors also need to attend another meeting in this slot. We have some spare time, so we'll let presentations go a bit over time as needed. Stig From stig@venaas.com Mon Nov 5 06:33:42 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 7FD4921F8582 for ; Mon, 5 Nov 2012 06:33:42 -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 Kv8zXfRPf2tB for ; Mon, 5 Nov 2012 06:33:42 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id E1E6F21F8554 for ; Mon, 5 Nov 2012 06:33:41 -0800 (PST) Received: from [10.21.83.45] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 320017FC2 for ; Mon, 5 Nov 2012 15:33:39 +0100 (CET) Message-ID: <5097CE3E.4050504@venaas.com> Date: Mon, 05 Nov 2012 06:33:34 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: pim@ietf.org References: <5081C52F.7000609@venaas.com> <50942F1C.1080709@venaas.com> In-Reply-To: <50942F1C.1080709@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pim] pim agenda for IETF 85 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, 05 Nov 2012 14:33:42 -0000 There are some very minor changes to the agenda. The latest is uploaded, but see also below. We now have the slides for all but one presentation. See you in a few hours, Stig pim wg meeting Monday November 5, 2012 13-15 Title Presenter Minutes ========================================================================== WG Status Stig/Mike 10 draft-asghar-pim-explicit-rpf-vector-00 Javed Asghar 10 4601 update Stig 10 draft-ietf-pim-explicit-tracking-01 Hitoshi Asaeda 10 draft-liu-multimob-igmp-mld-wireless-mobile-02 Mike McBride 10 draft-zhou-pim-vrrp-00 Stig Venaas 20 draft-asaeda-pim-mldproxy-multif-00 Hitoshi Asaeda 10 draft-contreras-multimob-multiple-upstreams-00 Carlos J. Bernardos 10 From simon.perreault@viagenie.ca Mon Nov 5 10:09:47 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 B7FA421F84FF for ; Mon, 5 Nov 2012 10:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, WEIRD_PORT=0.001] 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 a6xrA4uXNNSX for ; Mon, 5 Nov 2012 10:09:47 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAAC21F8793 for ; Mon, 5 Nov 2012 10:09:47 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:3d84:372:9328:b7f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 758ED415AF for ; Mon, 5 Nov 2012 13:09:46 -0500 (EST) Message-ID: <509800EA.9050207@viagenie.ca> Date: Mon, 05 Nov 2012 13:09:46 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: pim@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pim] Taking notes 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, 05 Nov 2012 18:09:47 -0000 http://etherpad.tools.ietf.org:9006/p/notes-ietf-85-pim?useMonospaceFont=true If anyone else wants to fill in the blanks... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From sfigueiredo@av.it.pt Tue Nov 6 02:47:54 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 0825E21F8889 for ; Tue, 6 Nov 2012 02:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.809 X-Spam-Level: X-Spam-Status: No, score=-0.809 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, 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 hl9702IMGYnr for ; Tue, 6 Nov 2012 02:47:53 -0800 (PST) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id A65ED21F8884 for ; Tue, 6 Nov 2012 02:47:49 -0800 (PST) Received: from [193.136.93.29] (account sfigueiredo@av.it.pt [193.136.93.29] verified) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 66928899 for pim@ietf.org; Tue, 06 Nov 2012 10:47:46 +0000 Message-ID: <5098EAD2.40600@av.it.pt> Date: Tue, 06 Nov 2012 10:47:46 +0000 From: =?ISO-8859-1?Q?S=E9rgio_Figueiredo?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: pim@ietf.org Content-Type: multipart/alternative; boundary="------------050203010906080900050603" 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, 06 Nov 2012 10:47:54 -0000 This is a multi-part message in MIME format. --------------050203010906080900050603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear authors, I am aware of the concept of explicit tracking function for some time and wanted to check its status. As such I went through your draft and provide a more or less thorough review. I am sorry if am doing a lot of "noise", but I didn't find any details from previous ML discussions on the issues I address: 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. 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". "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"? 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? "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? "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". 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? Q8 - How does the router's failed expectation that the sender is the sole member impact on the behaviour of other members? 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? Q10 - Why is there no reference to Multicast Address Listener Interval (MALI) from MLDv2 RFC? Doesn't it impact your assumptions? "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? 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? "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". 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? Overall, my impression is that the default operation (as well as any operation option) of the multicast router should be clearer. Best regards, Sérgio --------------050203010906080900050603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear authors,

I am aware of the concept of explicit tracking function for some time and wanted to check its status. As such I went through your draft and provide a more or less thorough review. I am sorry if am doing a lot of "noise", but I didn't find any details from previous ML discussions on the issues I address:

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.

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

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

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

"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".
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?
Q8 - How does the router's failed expectation that the sender is the sole member impact on the behaviour of other members?
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?
Q10 - Why is there no reference to Multicast Address Listener Interval (MALI) from MLDv2 RFC? Doesn't it impact your assumptions?

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

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

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?

Overall, my impression is that the default operation (as well as any operation option) of the multicast router should be clearer.

Best regards,
Sérgio
--------------050203010906080900050603-- From sfigueiredo@av.it.pt Tue Nov 6 07:48:11 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 A210021F84A7 for ; Tue, 6 Nov 2012 07:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=0.745, 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 Q8tw+n4lXjXX for ; Tue, 6 Nov 2012 07:48:11 -0800 (PST) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3C80321F853C for ; Tue, 6 Nov 2012 07:48:09 -0800 (PST) Received: from [193.136.93.29] (account sfigueiredo@av.it.pt [193.136.93.29] verified) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 66932630 for pim@ietf.org; Tue, 06 Nov 2012 15:48:07 +0000 Message-ID: <50993137.9050709@av.it.pt> Date: Tue, 06 Nov 2012 15:48:07 +0000 From: =?ISO-8859-1?Q?S=E9rgio_Figueiredo?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: pim@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pim] I-D Action: draft-asaeda-pim-mldproxy-multif-00.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, 06 Nov 2012 15:48:11 -0000 Hi all, I went through this draft, which I found interesting and a logical step for MLD Proxy evolution, as it might be a simple answer to the support of several new scenarios. I will try to review the "Extension of the MLD proxy functionality to support multiple upstream interfaces" as well when I find the time. For now, please check my comments below: Abstract: "an IGMP/MLD proxy device receives multicast packets through multiple upstream interfaces, so that it is useful for multihoming support". P1 => It's interesting that you apply the term multihoming here. This mean the proposal could actually be termed as "Multihomed MLD Proxy", right? Section 1: "same IGMP/MLD records MUST NOT be transmitted from different upstream interfaces simultaneously" P2 => As it is not the records which are transmitted, I propose writing this as: "the multicast traffic pertaining to any IGMP/MLD record MUST NOT be transmitted from different upstream interfaces simultaneously". "On the other hand, there are requirements that an IGMP/MLD proxy device allows to use multiple upstream interfaces." P3 => Should be rewritten as: "On the other hand, there are scenarios which require a IGMP/MLD proxy device enabled with multiple upstream interfaces". "For example, a proxy device having more than two interfaces may want to access to different networks, such as Internet and Intranet" P4 => Probably should be corrected to "(...) a proxy device in a machine connected to multiple networks, such as (...)" "This document describes the way of supporting the scenario in which an IGMP/MLD proxy device enables to configure "multiple upstream interfaces" and receives multicast packets through these interfaces". P5 => Ok, so this defines the scope of the document. Does it also means that scenarios where both the upstream interfaces are used to send traffic are excluded? I don't think so, at least after looking to section 3.1. Section 3.1: "Regarding the case that a proxy device receives multicast packets on its downstream interface, it forwards the packets to each downstream interface based on the downstream interface's subscriptions. A proxy device forwards packets received on any downstream interface to the configured upstream interfaces, and to each downstream interface other than the incoming interface based upon the downstream interfaces' subscriptions." P6 => The same point is repeated. This should be shortened to: "When a proxy device receives multicast packets on its downstream interface, it forwards the packets to the configured upstream interface and to each downstream interface based on the downstream interfaces' subscriptions." Section 3.2: "When the proxy device transmits an IGMP/ MLD report message, it examines the source and multicast addresses in the IGMP/MLD records of the report message and transmits the appropriate IGMP/MLD report message(s) from the selected upstream interface(s) that are configured with the range of the supported source and multicast address prefixes." P7 => Should be corrected to "Before transmitting an IGMP / MLD Report (...)". P8 => Besides, the sentence is too long and a bit confusing. I would propose ""Before transmitting IGMP/ MLD Report messages, the MLD Proxy examines the source and multicast addresses of each of the IGMP/MLD records contained in the received IGMP/MLD Report messages. Based on the verified multicast group and source prefixes, It then selects the appropriate upstream interface, in a per-record basis.". Moreoever, I would add: "The IGMP/MLD Report sent through each upstream interface is the aggregation of all downstream group membership fitting the designated prefixes." I.e. The Proxy will build its aggregated Reports based on the G and S prefixes of each record in received IGMP/MLD Reports. Or in other words, Multicast Address Prefix and Source Prefix will act as filters to select the upstream interface to be used for the subscription. Best regards, Sérgio From stig@venaas.com Fri Nov 16 09:55:05 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 5838021F8A22 for ; Fri, 16 Nov 2012 09:55:05 -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=[AWL=0.000, 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 N0cXOkMoOmCP for ; Fri, 16 Nov 2012 09:55:04 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id BB95121F89E3 for ; Fri, 16 Nov 2012 09:55:04 -0800 (PST) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 715517FC7 for ; Fri, 16 Nov 2012 18:54:59 +0100 (CET) Message-ID: <50A67DED.3060508@venaas.com> Date: Fri, 16 Nov 2012 09:54:53 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "pim@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pim] Minor technical change in pop-count 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, 16 Nov 2012 17:55:05 -0000 During AUTH48 for draft-ietf-pim-pop-count-07.txt I realized one minor technical issue that I would like to address. Since this is a technical change, I would like to see if anyone in the WG has any concerns. We got two flags regarding tunneling defined as follows: t flag: This flag is set if there are any tunnels on the distribution tree. If a tunnel is in the oif-list, a router should set this bit in its Join/Prune messages. Otherwise, it propagates the bit setting from downstream joiners. a flag: This flag is set if there are any auto-tunnels on the distribution tree. If an auto-tunnel is in the oif-list, a router should set this bit in its Join/Prune messages. Otherwise, it propagates the bit setting from downstream joiners. An example of an auto-tunnel is a tunnel set up by the Automatic Multicast Tunneling [AMT] protocol. It is not clear whether the "t" flag applies to all tunnels or all tunnels except auto-tunnels. Or rather, by reading the description of "t" by itself it would seem obvious that it is all tunnels, but the fact that there is a separate flag for auto-tunnels makes it seem more reasonable that the two flags are for disjoint types of tunnels. I would like to change the description of "t" slightly to talk about manually configured tunnels. How about this text: t flag: This flag is set if there are any manually configured tunnels on the distribution tree. This means any tunnel that is not an auto-tunnel. If a tunnel is in the oif-list, a router should set this bit in its Join/Prune messages. Otherwise, it propagates the bit setting from downstream joiners. I hope you agree this is reasonable. There is no point in having the flags overlap. If we want to check if any type of tunneling is involved, we just check if either of the flags are set. Stig From william.atwood@concordia.ca Fri Nov 16 10:30:46 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 36AFC21F8858 for ; Fri, 16 Nov 2012 10:30:46 -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 fSoTFvsiIqlF for ; Fri, 16 Nov 2012 10:30:45 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.94]) by ietfa.amsl.com (Postfix) with ESMTP id 586C721F86AB for ; Fri, 16 Nov 2012 10:30:44 -0800 (PST) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id qAGIUheD011235 for ; Fri, 16 Nov 2012 13:30:43 -0500 Message-ID: <50A6865D.90007@concordia.ca> Date: Fri, 16 Nov 2012 13:30:53 -0500 From: John William Atwood Organization: Concordia University, Montreal User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: pim@ietf.org References: <50A67DED.3060508@venaas.com> In-Reply-To: <50A67DED.3060508@venaas.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2012/11/16 13:30:43 EST Subject: Re: [pim] Minor technical change in pop-count 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, 16 Nov 2012 18:30:46 -0000 Stig, I agree that the disjoint specification is better. I would add two words to the proposed definition---see inline for where. Bill On 11/16/2012 12:54 PM, Stig Venaas wrote: > During AUTH48 for draft-ietf-pim-pop-count-07.txt I realized one minor > technical issue that I would like to address. Since this is a technical > change, I would like to see if anyone in the WG has any concerns. > > We got two flags regarding tunneling defined as follows: > > t flag: This flag is set if there are any tunnels on the > distribution tree. If a tunnel is in the oif-list, a router > should set this bit in its Join/Prune messages. Otherwise, it > propagates the bit setting from downstream joiners. > > a flag: This flag is set if there are any auto-tunnels on the > distribution tree. If an auto-tunnel is in the oif-list, a > router should set this bit in its Join/Prune messages. > Otherwise, it propagates the bit setting from downstream > joiners. An example of an auto-tunnel is a tunnel set up by > the Automatic Multicast Tunneling [AMT] protocol. > > It is not clear whether the "t" flag applies to all tunnels or all > tunnels except auto-tunnels. Or rather, by reading the description of > "t" by itself it would seem obvious that it is all tunnels, but the > fact that there is a separate flag for auto-tunnels makes it seem more > reasonable that the two flags are for disjoint types of tunnels. > > I would like to change the description of "t" slightly to talk about > manually configured tunnels. How about this text: > > t flag: This flag is set if there are any manually configured > tunnels on the distribution tree. This means any tunnel that > is not an auto-tunnel. If a tunnel is in the oif-list, a ^manually configured > router should set this bit in its Join/Prune messages. > Otherwise, it propagates the bit setting from downstream > joiners. > > I hope you agree this is reasonable. There is no point in having the > flags overlap. If we want to check if any type of tunneling is > involved, we just check if either of the flags are set. > > Stig > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From stig@venaas.com Fri Nov 16 10:44:37 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 5140921F8769 for ; Fri, 16 Nov 2012 10:44:37 -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 0w2gkayq0hFz for ; Fri, 16 Nov 2012 10:44:36 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD1C21F8715 for ; Fri, 16 Nov 2012 10:44:36 -0800 (PST) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 881267FC7; Fri, 16 Nov 2012 19:44:33 +0100 (CET) Message-ID: <50A6898E.2040700@venaas.com> Date: Fri, 16 Nov 2012 10:44:30 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: John William Atwood References: <50A67DED.3060508@venaas.com> <50A6865D.90007@concordia.ca> In-Reply-To: <50A6865D.90007@concordia.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pim@ietf.org Subject: Re: [pim] Minor technical change in pop-count 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, 16 Nov 2012 18:44:37 -0000 On 11/16/2012 10:30 AM, John William Atwood wrote: > Stig, > > I agree that the disjoint specification is better. > > I would add two words to the proposed definition---see inline for where. > > Bill > > > On 11/16/2012 12:54 PM, Stig Venaas wrote: >> During AUTH48 for draft-ietf-pim-pop-count-07.txt I realized one minor >> technical issue that I would like to address. Since this is a technical >> change, I would like to see if anyone in the WG has any concerns. >> >> We got two flags regarding tunneling defined as follows: >> >> t flag: This flag is set if there are any tunnels on the >> distribution tree. If a tunnel is in the oif-list, a router >> should set this bit in its Join/Prune messages. Otherwise, it >> propagates the bit setting from downstream joiners. >> >> a flag: This flag is set if there are any auto-tunnels on the >> distribution tree. If an auto-tunnel is in the oif-list, a >> router should set this bit in its Join/Prune messages. >> Otherwise, it propagates the bit setting from downstream >> joiners. An example of an auto-tunnel is a tunnel set up by >> the Automatic Multicast Tunneling [AMT] protocol. >> >> It is not clear whether the "t" flag applies to all tunnels or all >> tunnels except auto-tunnels. Or rather, by reading the description of >> "t" by itself it would seem obvious that it is all tunnels, but the >> fact that there is a separate flag for auto-tunnels makes it seem more >> reasonable that the two flags are for disjoint types of tunnels. >> >> I would like to change the description of "t" slightly to talk about >> manually configured tunnels. How about this text: >> >> t flag: This flag is set if there are any manually configured >> tunnels on the distribution tree. This means any tunnel that >> is not an auto-tunnel. If a tunnel is in the oif-list, a > ^manually configured Great catch! I'm suggesting the below text to the RFC Editor then. We'll wait and see for a few days if there are any objections though. t flag: This flag is set if there are any manually configured tunnels on the distribution tree. This means any tunnel that is not an auto-tunnel. If a manually configured tunnel is in the oif-list, a router sets this bit in its Join/Prune messages. Otherwise, it propagates the bit setting from downstream joiners. a flag: This flag is set if there are any auto-tunnels on the distribution tree. If an auto-tunnel is in the oif-list, a router sets this bit in its Join/Prune messages. Otherwise, it propagates the bit setting from downstream joiners. An example of an auto-tunnel is a tunnel set up by the Automatic Multicast Tunneling [AMT] protocol. Stig >> router should set this bit in its Join/Prune messages. >> Otherwise, it propagates the bit setting from downstream >> joiners. >> >> I hope you agree this is reasonable. There is no point in having the >> flags overlap. If we want to check if any type of tunneling is >> involved, we just check if either of the flags are set. >> >> Stig >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim > From stig@venaas.com Mon Nov 19 12:54:42 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 99BB521F8754 for ; Mon, 19 Nov 2012 12:54:42 -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=[AWL=0.000, 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 EOsy+fYiv16K for ; Mon, 19 Nov 2012 12:54:42 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id EC31821F8750 for ; Mon, 19 Nov 2012 12:54:41 -0800 (PST) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id E660C7FD4 for ; Mon, 19 Nov 2012 21:54:39 +0100 (CET) Message-ID: <50AA9C89.5050506@venaas.com> Date: Mon, 19 Nov 2012 12:54:33 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: pim@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pim] Draft minutes for pim at IETF85 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, 19 Nov 2012 20:54:42 -0000 The draft minutes are available at http://www.ietf.org/proceedings/85/minutes/minutes-85-pim Thanks to Simon for the minutes. The names are missing for a couple of people commenting on the last slot (draft-contreras-multimob-multiple-upstreams-00). It would be good if those who spoke (or whoever know who they were) can let us know. Also of course let us know if there are other corrections to be made. Stig