From abdelkader.lahmadi@loria.fr Fri Dec 20 04:09:15 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC5E1AE239 for ; Fri, 20 Dec 2013 04:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.95 X-Spam-Level: X-Spam-Status: No, score=-5.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLz0zy_-dftB for ; Fri, 20 Dec 2013 04:09:12 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id C172F1AE22D for ; Fri, 20 Dec 2013 04:09:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,520,1384297200"; d="scan'208";a="41851952" Received: from zmbs2.inria.fr ([128.93.142.15]) by mail3-relais-sop.national.inria.fr with ESMTP; 20 Dec 2013 13:09:08 +0100 Date: Fri, 20 Dec 2013 13:09:08 +0100 (CET) From: Abdelkader Lahmadi To: Toerless Eckert Message-ID: <1646414089.4758486.1387541348581.JavaMail.root@loria.fr> In-Reply-To: <20131220081111.GG6467@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [152.81.2.106] X-Mailer: Zimbra 7.2.5_GA_2906 (ZimbraWebClient - GC31 (Mac)/7.2.5_GA_2906) X-Mailman-Approved-At: Thu, 02 Jan 2014 11:33:42 -0800 Cc: Isabelle CHRISMENT , olivier.festor@inria.fr, pim@ietf.org Subject: Re: [pim] release of a igmp/mld proxy X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 12:09:15 -0000 Dear all, Please also consider our implementation of an IGMPv3 proxy. It was integrat= ed in DD-WRT : http://svn.dd-wrt.com/browser/src/router/igmp-proxy?rev=3D8841&order=3Dname It acts as a daemon and supports IGMPv3. Best regards /Abdelkader Lahmadi ----- Mail original ----- > De: "Toerless Eckert" > =C0: "Sebastian Woelke" > Cc: pim@ietf.org > Envoy=E9: Vendredi 20 D=E9cembre 2013 09:11:11 > Objet: Re: [pim] release of a igmp/mld proxy >=20 > Thanks, Sebastian, sounds good! >=20 > On Fri, Dec 20, 2013 at 04:43:12AM +0100, Sebastian Woelke wrote: > > hi, > >=20 > > thank you for your questions, here are my answers: > >=20 > > >Q1: I am totally not up to date on the freeware linux development > > >side. How does > > >this mcproxy compare to any other linux software modules with > > >which > > >to build > > >eg: a linux router for multicast (what other options in SW are > > >available ?). > >=20 > > There are two notable linux multicast proxies: > > igmpproxy (http://sourceforge.net/projects/igmpproxy): > > - supports IGMPv2 > > - uses the multicast routing table of the linux kernel > >=20 > > ecmh (http://sourceforge.net/p/ecmh): > > - supports MLDv1/2 > > - independent of the linux kernel via userspace routing > >=20 > > igmpproxy doesn't support multiple instances and missing IGMPv3. > > And ecmh only supports the slower userspace routing. > >=20 > > >Q2: Any existing or future plans to incude this into common linux > > >router > > >distributions - DD-WRT or the like ? > >=20 > > The mcproxy is developed and tested only on ubuntu, but yes I want > > to > > porting it to the more relevant distributions in this field > > (OpenWRT, > > DD-WRT). > >=20 > > >Q3: How much will the implementation protect against killing SSM > > >by > > >ASM receivers ? Aka: If your proxy receives an IGMPv3 > > >INCLUDE(S,G1) > > >membership from host 1 and an IGMPv3 EXCLUDE({},G1) from host 2, > > >what > > >will it send out on the upstream interface ? > >=20 > > Very interesting question, I never thought about this problem. So > > the > > current version would sends unaware of any protection the report > > EXCLUDE({},G1) to the upstream. > > But I think I could update the proxy in the following way: > > Currently it is possible to define filter rules, for example > > ???forward > > only data of the channel (S,G1) to the downstream interface eth0 > > and > > ignore all other data???. In this case, if the proxy receives an > > IGMPv3 > > EXCLUDE({}, G1) on the downstream interface eth0, it could be > > easily > > converted to the report INCLUDE(S,G1). > >=20 > > Kind regards, > > Sebastian > >=20 > >=20 > > >On Thu, Dec 19, 2013 at 04:48:08PM +0100, Sebastian Woelke wrote: > > >>Hi, > > >> > > >>I would like to announce a new version of the mcproxy. It can be > > >>downloaded from our project page (http://mcproxy.realmv6.org/). > > >>The mcproxy complies the IGMP/MLD proxy standard (RFC 4605) and > > >>supports the group membership protocols IGMPv3 and MLDv2 as well. > > >>In additional it meets the requirements of the multicast source > > >>and > > >>listener support in proxy mobile IPv6 > > >>(draft-ietf-multimob-pmipv6-source-06 and RFC 6224). > > >> > > >>Key features: > > >> - supports IPv4 (IGMPv3) > > >> - supports IPv6 (MLDv2) > > >> - can be instantiated multiple times > > >> - dynamically configurable at runtime > > >> - can be configured to peer data between its instances > > >> - supports multiple upstreams > > >> > > >> > > >>For further questions and comments don't hesitate to contact me. > > >> > > >>Kind regards, > > >>Sebastian > > >>_______________________________________________ > > >>pim mailing list > > >>pim@ietf.org > > >>https://www.ietf.org/mailman/listinfo/pim >=20 > -- > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! >=20 > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > From adrian@olddog.co.uk Sat Jan 4 04:23:52 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3014E1ADF5F for ; Sat, 4 Jan 2014 04:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltBCTiFbEp4A for ; Sat, 4 Jan 2014 04:23:50 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 792851ADF5C for ; Sat, 4 Jan 2014 04:23:50 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s04CNfBH014021; Sat, 4 Jan 2014 12:23:41 GMT Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s04CNdMc014008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 4 Jan 2014 12:23:41 GMT From: "Adrian Farrel" To: References: <20131219184054.30062.29353.idtracker@ietfa.amsl.com> In-Reply-To: Date: Sat, 4 Jan 2014 12:23:40 -0000 Message-ID: <007601cf0947$cf10dab0$6d329010$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+uZDi2pAFIvk6Y1y5Tu1pzUPfVpoKljIggAqEonA= Content-Language: en-gb Cc: pim@ietf.org Subject: Re: [pim] updated by Cindy Morgan X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 12:23:52 -0000 All, re-sending this email in the hope of getting something more of a = response than the one private email that said "Yes, why was this = document ever changed from Informational to Standards Track?" To be clear, if we leave this as it is, the document will not get = published as an RFC! We must choose from options 1, 2, and 3 (or some other option as yet = undreamed of) and act.=20 The ideal timeline has an action completed by Tuesday of next week = (7th). Failure to get resolution by Thursday will result in the I-D = being returned to the working group and the working group having to sort = it out and make a new publication request later if it wants to continue. The stuckees for resolving this are the document authors under guidance = from the WG chairs and the whole WG. Thanks, Adrian > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 28 December 2013 19:51 > To: draft-ietf-pim-explicit-tracking.all@tools.ietf.org > Cc: 'pim@ietf.org' > Subject: RE: updated by = Cindy Morgan >=20 > Authors and chairs (WG copied for information), >=20 > This document had a bit of a lumpy ride when it was in front of the = IESG. A > number of ADs said words to the effect of "What is being standardised = here? > There is nothing that affects on-wire behavior, and there are many = ways that this > function could be implemented in a router." >=20 > I tried several approaches in discussion, mainly saying that while = this document > does not tell you how to achieve interoperability, it does tell you = how to not > break interoperability. That is, this document provides a core = (default) suggestion > of how the function can be achieved in a way that will not break PIM. = My > arguments fell, however, on stony ground since the document does not = say this. >=20 > Currently we have three Abstain positions and four ADs still to = ballot. We need > two more No Objection ballots to get the document through. I have put = the > document back on the agenda for the next telechat, but I think we = should take > some proactive steps. These could be any of: >=20 > 1. Downgrade to Informational and add a small piece of text explaining = how this > document describes a safe mechanism for achieving the function. >=20 > 2. Remain at Standards Track and add a more substantial piece of text = explaining > how this document ensure interoperability by describing the black-box = behavior > of an implementation and offering a safe mechanism for achieving the = function > while acknowledging that other methods of implementation exist. In = effect, this > text must say that interoperability will not be broken if the method = described is > used. >=20 > 3. Dig in our heals and say that the document is fine as it is (giving = reasons!). >=20 > Your thoughts? > Adrian >=20 >=20 > > -----Original Message----- > > From: DraftTracker Mail System [mailto:iesg-secretary@ietf.org] > > Sent: 19 December 2013 18:41 > > To: Adrian Farrel > > Subject: updated by Cindy = Morgan > > > > > > Please DO NOT reply to this email. > > > > I-D: > > ID Tracker URL: = http://datatracker.ietf.org/doc/draft-ietf-pim-explicit-tracking/ > > > > State changed to IESG Evaluation::AD Followup from IESG Evaluation From asaeda@sfc.wide.ad.jp Sat Jan 4 07:52:30 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C8F1ADF8E for ; Sat, 4 Jan 2014 07:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.45 X-Spam-Level: X-Spam-Status: No, score=-96.45 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.538, SPF_NEUTRAL=0.779, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INZLywDWjH99 for ; Sat, 4 Jan 2014 07:52:28 -0800 (PST) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEFF1ADFE2 for ; Sat, 4 Jan 2014 07:52:26 -0800 (PST) Received: from localhost (p1147-ipngn1101marunouchi.tokyo.ocn.ne.jp [118.22.204.147]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D458B27813B; Sun, 5 Jan 2014 00:52:16 +0900 (JST) Date: Sun, 05 Jan 2014 00:52:15 +0900 (JST) Message-Id: <20140105.005215.48829278.asaeda@sfc.wide.ad.jp> To: adrian@olddog.co.uk From: Hitoshi Asaeda In-Reply-To: <064b01cf0406$17444a20$45ccde60$@olddog.co.uk> References: <20131219184054.30062.29353.idtracker@ietfa.amsl.com> <064b01cf0406$17444a20$45ccde60$@olddog.co.uk> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pim@ietf.org Subject: Re: [pim] updated by Cindy Morgan X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 15:52:30 -0000 Adrian, I'm very sorry for my late response. > This document had a bit of a lumpy ride when it was in front of the > IESG. A number of ADs said words to the effect of "What is being > standardised here? There is nothing that affects on-wire behavior, > and there are many ways that this function could be implemented in a > router." > > I tried several approaches in discussion, mainly saying that while > this document does not tell you how to achieve interoperability, it > does tell you how to not break interoperability. That is, this > document provides a core (default) suggestion of how the function > can be achieved in a way that will not break PIM. My arguments fell, > however, on stony ground since the document does not say this. Traditional IGMP/MLD query/reply communication works well in a legacy LAN, ethernet, but gives serious scalability issues especially in a data center in which massive amounts of hosts connect to a logical LAN, or wireless and mobile network environments that are resource sensitive but a number of users attach to. These use cases are indispensable for our current communications but were not deeply considered when the traditional IGMP/MLD protocol suite was designed. In fact, in the recent PIM, MBONED, and multimob WGs, there are several drafts that have been discussed IGMP/MLD tuning and extension for wireless/mobility support and a data center IGMP/MLD. The objectives are how IGMP/MLD works well in a resource sensitive but robust link condition. The explicit tracking function significantly contributes to that situation, and hence will be necessarily their normative reference. It is true that the current document does not describe how it affects on-wire behavior. It is because the on-wire behavior corresponding to the explicit tracking function will depend on the multicast routing protocol, e.g., PIM, not IGMP/MLD, and this document does not include routing protocol dependent behavior. For instance, we discussed the case in which multiple multicast routers exist on a LAN and the querier router is not the forwarder router. In this document, we only say the "specific query suppression", which is part of the explicit tracking function, should be simply disabled in such case, as there are no IGMP/MLD messages defined to synchronize the membership information to the forwarder. This is the simplest way to avoid the interoperability issue. Some mechanism or message to synchonize the membership information with routers on a LAN will be defined in a router-to-router communication; potentially with a PIM extension. One might also say there are many ways that explicit tracking could be implemented in a router. However, it is not so simple. For instance, this document defines "specific query suppression". What's the effort? For what kind of situation we need it? What are the pros and cons of this sub function? What the standard track document must clarify is the minimum requirements; for the explicit tracking, what should be implemented as the standard and what (or which (sub)functions) should be optional. If no such definition, it's hard to make further protocol improvements for IP multicast. And the more important thing is that we agreed on the minimum requirements described in this document. > Currently we have three Abstain positions and four ADs still to > ballot. We need two more No Objection ballots to get the document > through. I have put the document back on the agenda for the next > telechat, but I think we should take some proactive steps. These > could be any of: > > 1. Downgrade to Informational and add a small piece of text > explaining how this document describes a safe mechanism for > achieving the function. > > 2. Remain at Standards Track and add a more substantial piece of > text explaining how this document ensure interoperability by > describing the black-box behavior of an implementation and offering > a safe mechanism for achieving the function while acknowledging that > other methods of implementation exist. In effect, this text must say > that interoperability will not be broken if the method described is > used. > > 3. Dig in our heals and say that the document is fine as it is > (giving reasons!). I'd say, 4, which is "Keep this as Standard Track. If necessary, we revise the draft and try to clarify the background why the explicit tracking function is nowadays indispensable. We'll also add some text (or paragraph? section?) for the interoperability, which will be discussed with a routing protocol extension, if needed." What do you think? Regards, -- Hitoshi Asaeda From stig@venaas.com Mon Jan 6 18:52:24 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7431AE3DC for ; Mon, 6 Jan 2014 18:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTQ_JnI9UVoQ for ; Mon, 6 Jan 2014 18:52:21 -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 2A01B1AE3D3 for ; Mon, 6 Jan 2014 18:52:20 -0800 (PST) Received: from [10.21.70.42] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 41DDB807B; Tue, 7 Jan 2014 03:52:10 +0100 (CET) Message-ID: <52CB6E17.2060901@venaas.com> Date: Mon, 06 Jan 2014 19:01:43 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, draft-ietf-pim-explicit-tracking.all@tools.ietf.org References: <20131219184054.30062.29353.idtracker@ietfa.amsl.com> <007601cf0947$cf10dab0$6d329010$@olddog.co.uk> In-Reply-To: <007601cf0947$cf10dab0$6d329010$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pim@ietf.org Subject: Re: [pim] updated by Cindy Morgan X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 02:52:24 -0000 On 04.01.2014 04:23, Adrian Farrel wrote: > All, re-sending this email in the hope of getting something more of a response than the one private email that said "Yes, why was this document ever changed from Informational to Standards Track?" > > To be clear, if we leave this as it is, the document will not get published as an RFC! > > We must choose from options 1, 2, and 3 (or some other option as yet undreamed of) and act. Option 1 is downgrading to informational. The document was initially informational, but before we started WGLC we decided to make it standards track. There were different opinions though. I wonder if people in the group have thoughts on standards track or informational now. RFC 4605 on IGMP/MLD proxying is standards track. I think in a similar way, explicit tracking may not require different routers to interoperate (although it may be an issue if querier and forwarder are different routers), but it must be done right for the IGMP/MLD protocol not to break. Here are the minutes from Atlanta where the decision to go for PS was made. Adrian, would you agree that the situation here is similar to 4605? draft-ietf-pim-explicit-tracking-02 Hitoshi Asaeda - IGMP/MLD-based explicit membership tracking function for multicast routers Stig: We should decide on the intended status before WGLC. Mike: WG adopted the draft because it was informational. We do not want to do bait-and-switch. Stig: Status change can happen but needs good support. (3 people have read this draft) (3 people say it should be standard) (0 people say it should be informational) Sue Hares: Why do you want to go to standard? Explicit tracking has some very valuable debugging stuff. Hitoshi: When other protocols want to refer to explicit tracking, they cannot do it as normative reference if it is informational. Sue: Why does that matter? Dino: The subject matter is IGMP/MLD explicit tracking. If it's compelling enough, why go halfway? Make it full standard. Adrian Farrell: Decide the track based on contents, not based on who wants to refer to it. If this is an implementable protocol, make it standard track. Dino: Explicit tracking is an importnat feature that we need to have. We should go full steam ahead (full standard). Sue: Yes, it should go for standard. Toerless: Default preference should be IGMPv3 + explicit tracking. Dino: Maybe we should do IGMPv4. Toerless: There once was IGMPv3 lite. (6 people want it to be standard) (0 people want it to be informational) (Will be asked on the list. If the people that wanted it adopted as informational don't speak up, then it will change to standard.) One argument is references, but I don't think that in itself should make us go for PS. But there are other arguments. Stig > The ideal timeline has an action completed by Tuesday of next week (7th). Failure to get resolution by Thursday will result in the I-D being returned to the working group and the working group having to sort it out and make a new publication request later if it wants to continue. > > The stuckees for resolving this are the document authors under guidance from the WG chairs and the whole WG. > > Thanks, > Adrian > >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: 28 December 2013 19:51 >> To: draft-ietf-pim-explicit-tracking.all@tools.ietf.org >> Cc: 'pim@ietf.org' >> Subject: RE: updated by Cindy Morgan >> >> Authors and chairs (WG copied for information), >> >> This document had a bit of a lumpy ride when it was in front of the IESG. A >> number of ADs said words to the effect of "What is being standardised here? >> There is nothing that affects on-wire behavior, and there are many ways that this >> function could be implemented in a router." >> >> I tried several approaches in discussion, mainly saying that while this document >> does not tell you how to achieve interoperability, it does tell you how to not >> break interoperability. That is, this document provides a core (default) suggestion >> of how the function can be achieved in a way that will not break PIM. My >> arguments fell, however, on stony ground since the document does not say this. >> >> Currently we have three Abstain positions and four ADs still to ballot. We need >> two more No Objection ballots to get the document through. I have put the >> document back on the agenda for the next telechat, but I think we should take >> some proactive steps. These could be any of: >> >> 1. Downgrade to Informational and add a small piece of text explaining how this >> document describes a safe mechanism for achieving the function. >> >> 2. Remain at Standards Track and add a more substantial piece of text explaining >> how this document ensure interoperability by describing the black-box behavior >> of an implementation and offering a safe mechanism for achieving the function >> while acknowledging that other methods of implementation exist. In effect, this >> text must say that interoperability will not be broken if the method described is >> used. >> >> 3. Dig in our heals and say that the document is fine as it is (giving reasons!). >> >> Your thoughts? >> Adrian >> >> >>> -----Original Message----- >>> From: DraftTracker Mail System [mailto:iesg-secretary@ietf.org] >>> Sent: 19 December 2013 18:41 >>> To: Adrian Farrel >>> Subject: updated by Cindy Morgan >>> >>> >>> Please DO NOT reply to this email. >>> >>> I-D: >>> ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-pim-explicit-tracking/ >>> >>> State changed to IESG Evaluation::AD Followup from IESG Evaluation > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > From adrian@olddog.co.uk Tue Jan 7 03:22:04 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0981AD9B8 for ; Tue, 7 Jan 2014 03:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mU3v1plqzwFO for ; Tue, 7 Jan 2014 03:22:02 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6251AD8DC for ; Tue, 7 Jan 2014 03:22:01 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s07BLp1T005854; Tue, 7 Jan 2014 11:21:52 GMT Received: from 950129200 (13.17.90.92.rev.sfr.net [92.90.17.13]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s07BLEkZ005079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Jan 2014 11:21:35 GMT From: "Adrian Farrel" To: "'Stig Venaas'" , References: <20131219184054.30062.29353.idtracker@ietfa.amsl.com> <007601cf0947$cf10dab0$6d329010$@olddog.co.uk> <52CB6E17.2060901@venaas.com> In-Reply-To: <52CB6E17.2060901@venaas.com> Date: Tue, 7 Jan 2014 11:21:19 -0000 Message-ID: <00d501cf0b9a$a6ea3630$f4bea290$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+uZDi2pAFIvk6Y1y5Tu1pzUPfVgGqODaBAksRAV+Z+hOTQA== Content-Language: en-gb X-TM-AS-MML: No Cc: pim@ietf.org Subject: Re: [pim] updated by Cindy Morgan X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 11:22:04 -0000 Hi Stig, Thanks or this explanation. I can appreciate the points you make. Indeed, one of the things I tried to explain to the IESG was that getting this wrong could break interoperability. The counter argument made to me was that there are many ways to achieve the function and that (as far as the ADs knew) none of the existing implementations (some of which are quite old) actually does what this draft describes. Maybe the issue here is that there is a difference between: - black-box behavior - principles of operation of the function - sample (example) mechanism. OK. It seems that there is history in the WG for considering this as Standards Track so we need to construct a message to the IESG about why this is reasonable. Anyone want to take a first cut at that or shall I? Adrian > -----Original Message----- > From: Stig Venaas [mailto:stig@venaas.com] > Sent: 07 January 2014 03:02 > To: adrian@olddog.co.uk; draft-ietf-pim-explicit-tracking.all@tools.ietf.org > Cc: pim@ietf.org > Subject: Re: [pim] updated by Cindy > Morgan > > On 04.01.2014 04:23, Adrian Farrel wrote: > > All, re-sending this email in the hope of getting something more of a response > than the one private email that said "Yes, why was this document ever changed > from Informational to Standards Track?" > > > > To be clear, if we leave this as it is, the document will not get published as an > RFC! > > > > We must choose from options 1, 2, and 3 (or some other option as yet > undreamed of) and act. > > Option 1 is downgrading to informational. The document was initially > informational, but before we started WGLC we decided to make it > standards track. There were different opinions though. I wonder if > people in the group have thoughts on standards track or informational > now. > > RFC 4605 on IGMP/MLD proxying is standards track. I think in a similar > way, explicit tracking may not require different routers to > interoperate (although it may be an issue if querier and forwarder are > different routers), but it must be done right for the IGMP/MLD protocol > not to break. Here are the minutes from Atlanta where the decision to > go for PS was made. > > Adrian, would you agree that the situation here is similar to 4605? > > draft-ietf-pim-explicit-tracking-02 > Hitoshi Asaeda > - IGMP/MLD-based explicit membership tracking function for multicast routers > Stig: We should decide on the intended status before WGLC. > Mike: WG adopted the draft because it was informational. We do not want > to do bait-and-switch. > Stig: Status change can happen but needs good support. > (3 people have read this draft) > (3 people say it should be standard) > (0 people say it should be informational) > Sue Hares: Why do you want to go to standard? Explicit tracking has some > very valuable debugging stuff. > Hitoshi: When other protocols want to refer to explicit tracking, they > cannot do it as normative reference if it is informational. > Sue: Why does that matter? > Dino: The subject matter is IGMP/MLD explicit tracking. If it's > compelling enough, why go halfway? Make it full standard. > Adrian Farrell: Decide the track based on contents, not based on who > wants to refer to it. If this is an implementable protocol, make it > standard track. > Dino: Explicit tracking is an importnat feature that we need to have. We > should go full steam ahead (full standard). > Sue: Yes, it should go for standard. > Toerless: Default preference should be IGMPv3 + explicit tracking. > Dino: Maybe we should do IGMPv4. > Toerless: There once was IGMPv3 lite. > (6 people want it to be standard) > (0 people want it to be informational) > (Will be asked on the list. If the people that wanted it adopted as > informational don't speak up, then it will change to standard.) > > One argument is references, but I don't think that in itself should > make us go for PS. But there are other arguments. > > Stig > > > The ideal timeline has an action completed by Tuesday of next week (7th). > Failure to get resolution by Thursday will result in the I-D being returned to the > working group and the working group having to sort it out and make a new > publication request later if it wants to continue. > > > > The stuckees for resolving this are the document authors under guidance from > the WG chairs and the whole WG. > > > > Thanks, > > Adrian > > > >> -----Original Message----- > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > >> Sent: 28 December 2013 19:51 > >> To: draft-ietf-pim-explicit-tracking.all@tools.ietf.org > >> Cc: 'pim@ietf.org' > >> Subject: RE: updated by Cindy Morgan > >> > >> Authors and chairs (WG copied for information), > >> > >> This document had a bit of a lumpy ride when it was in front of the IESG. A > >> number of ADs said words to the effect of "What is being standardised here? > >> There is nothing that affects on-wire behavior, and there are many ways that > this > >> function could be implemented in a router." > >> > >> I tried several approaches in discussion, mainly saying that while this > document > >> does not tell you how to achieve interoperability, it does tell you how to not > >> break interoperability. That is, this document provides a core (default) > suggestion > >> of how the function can be achieved in a way that will not break PIM. My > >> arguments fell, however, on stony ground since the document does not say > this. > >> > >> Currently we have three Abstain positions and four ADs still to ballot. We need > >> two more No Objection ballots to get the document through. I have put the > >> document back on the agenda for the next telechat, but I think we should > take > >> some proactive steps. These could be any of: > >> > >> 1. Downgrade to Informational and add a small piece of text explaining how > this > >> document describes a safe mechanism for achieving the function. > >> > >> 2. Remain at Standards Track and add a more substantial piece of text > explaining > >> how this document ensure interoperability by describing the black-box > behavior > >> of an implementation and offering a safe mechanism for achieving the > function > >> while acknowledging that other methods of implementation exist. In effect, > this > >> text must say that interoperability will not be broken if the method described > is > >> used. > >> > >> 3. Dig in our heals and say that the document is fine as it is (giving reasons!). > >> > >> Your thoughts? > >> Adrian > >> > >> > >>> -----Original Message----- > >>> From: DraftTracker Mail System [mailto:iesg-secretary@ietf.org] > >>> Sent: 19 December 2013 18:41 > >>> To: Adrian Farrel > >>> Subject: updated by Cindy Morgan > >>> > >>> > >>> Please DO NOT reply to this email. > >>> > >>> I-D: > >>> ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-pim-explicit- > tracking/ > >>> > >>> State changed to IESG Evaluation::AD Followup from IESG Evaluation > > > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www.ietf.org/mailman/listinfo/pim > > From sami.biz.email@gmail.com Mon Jan 6 14:48:02 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75CC1AE2AB for ; Mon, 6 Jan 2014 14:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.027 X-Spam-Level: X-Spam-Status: No, score=-0.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id advAKlEJpOyA for ; Mon, 6 Jan 2014 14:48:01 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 861761AE2A7 for ; Mon, 6 Jan 2014 14:48:01 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id q59so16615441wes.27 for ; Mon, 06 Jan 2014 14:47:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=jHc1oKeN0WH7P1zVPpTu229VbyHOpqW15ik+swQ1qqM=; b=LX4M1cOZ33X7Ub9eyDMRCTF/iiPwQRzTWTMsi9365Ivq+k/SAR4yMddbxDhOaVHoVg 8ugbSfrzlF2uzEzsQkRz2q8j3R+Q+UVmq5+tKHY5JcASdCb6dHmeej58xQGxI5+3o5Lq 1ReYNUV0a993x+ts+I8vHCbfwxKs5CMX92WG3jaBQdWN5jM7aFkZAbrn/J7LmcmOf4nI ERq/WrEU3OWnYErR3oCPdJBAqr0ayP4jEY1qK8mo2VTmGm9COEfFVvFO3jpMlaFEy0YM ZtiF60yvlAZ+2qfvFlWiWJtZl/uG2hyH4PqPuB7kYHJ0HDoHGj17DofSvHTujXCukFgo K8ag== X-Received: by 10.180.20.100 with SMTP id m4mr14240096wie.32.1389048472339; Mon, 06 Jan 2014 14:47:52 -0800 (PST) Received: from [192.168.1.2] ([178.253.59.19]) by mx.google.com with ESMTPSA id 11sm1926634wjo.23.2014.01.06.14.47.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jan 2014 14:47:51 -0800 (PST) Message-ID: <52CB321A.3070807@gmail.com> Date: Tue, 07 Jan 2014 02:15:46 +0330 From: saeed sami User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pim@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 07 Jan 2014 09:37:25 -0800 Subject: [pim] in regards to draft-sami-pim-ng-01 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 22:48:02 -0000 Dear Sir/Madam, Hi. My name is Saeed Sami and i recently submitted an ID named " draft-sami-pim-ng" to IETF. I just was guided by IESG secretary to contact you as the authority in control of PIM routing protocol area, so that the ID gets reviewed and possibly be forwarded to IESG. Please kindly guide me on this by, telling me what should i do next? should i resend the documents to you directly for review? Thanks for your help and professional guidance. Sincerely Saeed Sami From stig@venaas.com Tue Jan 7 10:27:40 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E861AE06D for ; Tue, 7 Jan 2014 10:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TEU-DzMH2P8 for ; Tue, 7 Jan 2014 10:27: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 BD6001AE04B for ; Tue, 7 Jan 2014 10:27:35 -0800 (PST) Received: from [IPv6:2001:420:301:1004:912b:441f:c8a1:8de4] (unknown [IPv6:2001:420:301:1004:912b:441f:c8a1:8de4]) by ufisa.uninett.no (Postfix) with ESMTPSA id 6CA3C8034; Tue, 7 Jan 2014 19:27:25 +0100 (CET) Message-ID: <52CC4707.2030200@venaas.com> Date: Tue, 07 Jan 2014 10:27:19 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, draft-ietf-pim-explicit-tracking.all@tools.ietf.org References: <20131219184054.30062.29353.idtracker@ietfa.amsl.com> <007601cf0947$cf10dab0$6d329010$@olddog.co.uk> <52CB6E17.2060901@venaas.com> <00d501cf0b9a$a6ea3630$f4bea290$@olddog.co.uk> In-Reply-To: <00d501cf0b9a$a6ea3630$f4bea290$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pim@ietf.org Subject: Re: [pim] updated by Cindy Morgan X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 18:27:40 -0000 Hi On 1/7/2014 3:21 AM, Adrian Farrel wrote: > Hi Stig, > > Thanks or this explanation. I can appreciate the points you make. Indeed, one of > the things I tried to explain to the IESG was that getting this wrong could > break interoperability. > > The counter argument made to me was that there are many ways to achieve the > function and that (as far as the ADs knew) none of the existing implementations > (some of which are quite old) actually does what this draft describes. Maybe the Yes, there are multiple ways of doing this. I think existing implementations are close to what the draft specifies (with some variations and not all that is mentioned here). This draft started out as informational, and my understanding of this was that we view this as important functionality and that it was worth describing how to implement it in a good way. That sounds like a typical informational draft to me. The main reasons it was changed to standards track are roughly: 1. It is a very useful feature and widely implemented and deployed. 2. Interoperability. IGMP/MLD may break if not implemented correctly. There have been examples of this done wrong I think (although I cannot remember for sure now. There have been issues with various snooping/proxy implementations where explicit tracking is one part). 3. There are other documents that are/were planned for standards track referencing it. I think 1 was the main argument brought up in the meeting (see the minutes included below), but IMO 2 is the strongest argument for PS. 3 is not that strong as it is still possible to reference it (just more difficult). > issue here is that there is a difference between: > - black-box behavior > - principles of operation of the function > - sample (example) mechanism. I guess the concern here might be that existing implementations might work fine, but not necessarily follow this draft, and that there are several valid ways to implement it. But a lot of what is described in the document is not required, it talks about several ways things can be done. It only uses requirements language in a few places where I think it is really needed. Note that there were key people from different vendors stating that they wanted it standards track. > OK. It seems that there is history in the WG for considering this as Standards > Track so we need to construct a message to the IESG about why this is > reasonable. I mentioned RFC 4605 here, which is PS and came out of magma with Brian as one of the authors. There are similarities between that document and this, and both have some normative language required to not break the IGMP/MLD protocols. Happy for input from others in the group, but I believe the WG wants it to be standards track. > Anyone want to take a first cut at that or shall I? I think it would be helpful if you can do at least a very rough first cut, giving us an idea what points are worth bringing up. Stig > Adrian > >> -----Original Message----- >> From: Stig Venaas [mailto:stig@venaas.com] >> Sent: 07 January 2014 03:02 >> To: adrian@olddog.co.uk; draft-ietf-pim-explicit-tracking.all@tools.ietf.org >> Cc: pim@ietf.org >> Subject: Re: [pim] updated by Cindy >> Morgan >> >> On 04.01.2014 04:23, Adrian Farrel wrote: >>> All, re-sending this email in the hope of getting something more of a > response >> than the one private email that said "Yes, why was this document ever changed >> from Informational to Standards Track?" >>> >>> To be clear, if we leave this as it is, the document will not get published > as an >> RFC! >>> >>> We must choose from options 1, 2, and 3 (or some other option as yet >> undreamed of) and act. >> >> Option 1 is downgrading to informational. The document was initially >> informational, but before we started WGLC we decided to make it >> standards track. There were different opinions though. I wonder if >> people in the group have thoughts on standards track or informational >> now. >> >> RFC 4605 on IGMP/MLD proxying is standards track. I think in a similar >> way, explicit tracking may not require different routers to >> interoperate (although it may be an issue if querier and forwarder are >> different routers), but it must be done right for the IGMP/MLD protocol >> not to break. Here are the minutes from Atlanta where the decision to >> go for PS was made. >> >> Adrian, would you agree that the situation here is similar to 4605? >> >> draft-ietf-pim-explicit-tracking-02 >> Hitoshi Asaeda >> - IGMP/MLD-based explicit membership tracking function for multicast routers >> Stig: We should decide on the intended status before WGLC. >> Mike: WG adopted the draft because it was informational. We do not want >> to do bait-and-switch. >> Stig: Status change can happen but needs good support. >> (3 people have read this draft) >> (3 people say it should be standard) >> (0 people say it should be informational) >> Sue Hares: Why do you want to go to standard? Explicit tracking has some >> very valuable debugging stuff. >> Hitoshi: When other protocols want to refer to explicit tracking, they >> cannot do it as normative reference if it is informational. >> Sue: Why does that matter? >> Dino: The subject matter is IGMP/MLD explicit tracking. If it's >> compelling enough, why go halfway? Make it full standard. >> Adrian Farrell: Decide the track based on contents, not based on who >> wants to refer to it. If this is an implementable protocol, make it >> standard track. >> Dino: Explicit tracking is an importnat feature that we need to have. We >> should go full steam ahead (full standard). >> Sue: Yes, it should go for standard. >> Toerless: Default preference should be IGMPv3 + explicit tracking. >> Dino: Maybe we should do IGMPv4. >> Toerless: There once was IGMPv3 lite. >> (6 people want it to be standard) >> (0 people want it to be informational) >> (Will be asked on the list. If the people that wanted it adopted as >> informational don't speak up, then it will change to standard.) >> >> One argument is references, but I don't think that in itself should >> make us go for PS. But there are other arguments. >> >> Stig >> >>> The ideal timeline has an action completed by Tuesday of next week (7th). >> Failure to get resolution by Thursday will result in the I-D being returned to > the >> working group and the working group having to sort it out and make a new >> publication request later if it wants to continue. >>> >>> The stuckees for resolving this are the document authors under guidance from >> the WG chairs and the whole WG. >>> >>> Thanks, >>> Adrian >>> >>>> -----Original Message----- >>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>> Sent: 28 December 2013 19:51 >>>> To: draft-ietf-pim-explicit-tracking.all@tools.ietf.org >>>> Cc: 'pim@ietf.org' >>>> Subject: RE: updated by Cindy > Morgan >>>> >>>> Authors and chairs (WG copied for information), >>>> >>>> This document had a bit of a lumpy ride when it was in front of the IESG. A >>>> number of ADs said words to the effect of "What is being standardised here? >>>> There is nothing that affects on-wire behavior, and there are many ways > that >> this >>>> function could be implemented in a router." >>>> >>>> I tried several approaches in discussion, mainly saying that while this >> document >>>> does not tell you how to achieve interoperability, it does tell you how to > not >>>> break interoperability. That is, this document provides a core (default) >> suggestion >>>> of how the function can be achieved in a way that will not break PIM. My >>>> arguments fell, however, on stony ground since the document does not say >> this. >>>> >>>> Currently we have three Abstain positions and four ADs still to ballot. We > need >>>> two more No Objection ballots to get the document through. I have put the >>>> document back on the agenda for the next telechat, but I think we should >> take >>>> some proactive steps. These could be any of: >>>> >>>> 1. Downgrade to Informational and add a small piece of text explaining how >> this >>>> document describes a safe mechanism for achieving the function. >>>> >>>> 2. Remain at Standards Track and add a more substantial piece of text >> explaining >>>> how this document ensure interoperability by describing the black-box >> behavior >>>> of an implementation and offering a safe mechanism for achieving the >> function >>>> while acknowledging that other methods of implementation exist. In effect, >> this >>>> text must say that interoperability will not be broken if the method > described >> is >>>> used. >>>> >>>> 3. Dig in our heals and say that the document is fine as it is (giving > reasons!). >>>> >>>> Your thoughts? >>>> Adrian >>>> >>>> >>>>> -----Original Message----- >>>>> From: DraftTracker Mail System [mailto:iesg-secretary@ietf.org] >>>>> Sent: 19 December 2013 18:41 >>>>> To: Adrian Farrel >>>>> Subject: updated by Cindy Morgan >>>>> >>>>> >>>>> Please DO NOT reply to this email. >>>>> >>>>> I-D: >>>>> ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-pim-explicit- >> tracking/ >>>>> >>>>> State changed to IESG Evaluation::AD Followup from IESG Evaluation >>> >>> _______________________________________________ >>> pim mailing list >>> pim@ietf.org >>> https://www.ietf.org/mailman/listinfo/pim >>> From adrian@olddog.co.uk Tue Jan 7 11:53:55 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774551AE154 for ; Tue, 7 Jan 2014 11:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDj4RKlZ7zyY for ; Tue, 7 Jan 2014 11:53:53 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 49E311ADF98 for ; Tue, 7 Jan 2014 11:53:53 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s07JrhSt012222; Tue, 7 Jan 2014 19:53:43 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s07JrchZ012189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Jan 2014 19:53:40 GMT From: "Adrian Farrel" To: "'Stig Venaas'" , References: <20131219184054.30062.29353.idtracker@ietfa.amsl.com> <007601cf0947$cf10dab0$6d329010$@olddog.co.uk> <52CB6E17.2060901@venaas.com> <00d501cf0b9a$a6ea3630$f4bea290$@olddog.co.uk> <52CC4707.2030200@venaas.com> In-Reply-To: <52CC4707.2030200@venaas.com> Date: Tue, 7 Jan 2014 19:53:41 -0000 Message-ID: <01c301cf0be2$2d0dd770$87298650$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+uZDi2pAFIvk6Y1y5Tu1pzUPfVgGqODaBAksRAV8CcqXTrgFLh571mdyxWkA= Content-Language: en-gb Cc: pim@ietf.org Subject: Re: [pim] updated by Cindy Morgan X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 19:53:55 -0000 Thanks again Stig, I'm going to play devil's advocate here because I know that various ADs will ask the hard questions. I also know that you are trying to represent what you heard in the WG (so we are both arguing representative corners rather than our own positions - perhaps we could get jobs playing lawyers on TV). > > Thanks or this explanation. I can appreciate the points you make. Indeed, > > one of the things I tried to explain to the IESG was that getting this wrong > > could break interoperability. > > > > The counter argument made to me was that there are many ways to > > achieve the function and that (as far as the ADs knew) none of the > > existing implementations (some of which are quite old) actually does > > what this draft describes. Maybe the > > Yes, there are multiple ways of doing this. I think existing > implementations are close to what the draft specifies (with > some variations and not all that is mentioned here). Hmmm. OK. So we have "Here is a document that describes something similar to what some implementations do to achieve this function." > This draft started out as informational, and my understanding of > this was that we view this as important functionality and that it > was worth describing how to implement it in a good way. That sounds > like a typical informational draft to me. Yes. So let's work though the reasoning below before I say "I agree. Let's make this Informational and be done with it." > The main reasons it was changed to standards track are roughly: > > 1. It is a very useful feature and widely implemented and deployed. That is without doubt. But that is not a reason for Standards Track especially since the document doesn't describe precisely what is implemented and deployed. > 2. Interoperability. IGMP/MLD may break if not implemented correctly. > There have been examples of this done wrong I think (although I > cannot remember for sure now. There have been issues with various > snooping/proxy implementations where explicit tracking is one part). I think this is the strongest claim. There are some uses of 2119 language (not many) in the I-D, and it is my take that ignoring those would break interop. We could improve the standing as Standards Track if we made a stronger case for this I-D setting guidelines that implementations of this function must follow. > 3. There are other documents that are/were planned for standards track > referencing it. That is pretty poor as a reason. Normative references can and are made to Informational RFCs from Standards Track documents. > I think 1 was the main argument brought up in the meeting (see the > minutes included below), but IMO 2 is the strongest argument for PS. > 3 is not that strong as it is still possible to reference it (just more > difficult). OK. We reached the same conclusions. > > issue here is that there is a difference between: > > - black-box behavior > > - principles of operation of the function > > - sample (example) mechanism. > > I guess the concern here might be that existing implementations might > work fine, but not necessarily follow this draft, and that there are > several valid ways to implement it. But a lot of what is described in > the document is not required, it talks about several ways things can > be done. It only uses requirements language in a few places where I > think it is really needed. Note that there were key people from > different vendors stating that they wanted it standards track. > > > OK. It seems that there is history in the WG for considering this as Standards > > Track so we need to construct a message to the IESG about why this is > > reasonable. > > I mentioned RFC 4605 here, which is PS and came out of magma with Brian > as one of the authors. There are similarities between that document and > this, and both have some normative language required to not break the > IGMP/MLD protocols. > > Happy for input from others in the group, but I believe the WG wants it > to be standards track. > > > Anyone want to take a first cut at that or shall I? > > I think it would be helpful if you can do at least a very rough first > cut, giving us an idea what points are worth bringing up. OK. That will follow. But I think it is also going to result in some reworking of the draft to make it clear what is necessary/advised to avoid breaking stuff, and what is a descriptive example of how the function could be achieved within that guidance. Cheers, Adrian From adrian@olddog.co.uk Tue Jan 7 12:09:51 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7711AE15D for ; Tue, 7 Jan 2014 12:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9vTIsdOKjAE for ; Tue, 7 Jan 2014 12:09:49 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id DEF141AE11F for ; Tue, 7 Jan 2014 12:09:48 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s07K9d3V007746; Tue, 7 Jan 2014 20:09:39 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s07K9ZDY007695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Jan 2014 20:09:37 GMT From: "Adrian Farrel" To: "'Stig Venaas'" , Date: Tue, 7 Jan 2014 20:09:36 -0000 Message-ID: <01d601cf0be4$66b06900$34113b00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8L5F4zsWYlo2cZTG69BawvUh1aZg== Content-Language: en-gb Cc: pim@ietf.org Subject: [pim] Draft email to IESG on draft-ietf-pim-explicit-tracking X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 20:09:51 -0000 Should probably come from the document shepherd once all is agreed. === Hi IESG, Thanks for your reviews and Comments on draft-ietf-pim-explicit-tracking. Adrian has brought these back to the PIM WG and we are concerned to address the cause of the Abstentions by discussing the situation with you and by making some modifications to the text. Firstly to let you know that although this I-D started off as Informational it was moved to Standards Track after some debate in the working group. Various reasons were advanced, but we consider the most important one to be that the document describes function that is important for the scalability of multicast networks, already widely implemented, and which could seriously break IGMP/MLD if not implemented correctly. In this respect, we see this work as similar to RFC 4605 which was also published as Standards Track. While we appreciate your concerns that there are many ways to implement this function (and, indeed, there are many different existing implementations), we believe that there is a core statement of what must and must not be done in order to avoid breaking interoperability. That is, although there is no description of on-wire behavior that must be implemented to achieve interoperability, this document describes things that must be done if this function is used and interoperability is to be retained. We think that the document could be clearer about this. In particular, we think that we should make a clearer distinction in the text between: - the description of the problem - the objective and overview of the function - statements about what implementations must/should/etc. do - an example set of procedures that an implementation could follow if it wants to be sure of being safe. We don't expect that this clarification work will result in substantial changes to the text, but will mean some changes to the sections, and a few clarifying sentences. But we do believe that the resulting document should continue as Standards Track. In view of this, we suggest that you delay your consideration of the document until we have produced a new revision. === Please note: I am floating this text, not dictating it! If the WG does not agree, then the WG needs to speak up. Cheers, Adrian > -----Original Message----- > From: pim [mailto:pim-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: 07 January 2014 19:54 > To: 'Stig Venaas'; draft-ietf-pim-explicit-tracking.all@tools.ietf.org > Cc: pim@ietf.org > Subject: Re: [pim] updated by Cindy > Morgan > > Thanks again Stig, > > I'm going to play devil's advocate here because I know that various ADs will ask > the hard questions. I also know that you are trying to represent what you heard > in the WG (so we are both arguing representative corners rather than our own > positions - perhaps we could get jobs playing lawyers on TV). > > > > Thanks or this explanation. I can appreciate the points you make. Indeed, > > > one of the things I tried to explain to the IESG was that getting this wrong > > > could break interoperability. > > > > > > The counter argument made to me was that there are many ways to > > > achieve the function and that (as far as the ADs knew) none of the > > > existing implementations (some of which are quite old) actually does > > > what this draft describes. Maybe the > > > > Yes, there are multiple ways of doing this. I think existing > > implementations are close to what the draft specifies (with > > some variations and not all that is mentioned here). > > Hmmm. OK. > So we have "Here is a document that describes something similar to what some > implementations do to achieve this function." > > > This draft started out as informational, and my understanding of > > this was that we view this as important functionality and that it > > was worth describing how to implement it in a good way. That sounds > > like a typical informational draft to me. > > Yes. > So let's work though the reasoning below before I say "I agree. Let's make this > Informational and be done with it." > > > The main reasons it was changed to standards track are roughly: > > > > 1. It is a very useful feature and widely implemented and deployed. > > That is without doubt. > But that is not a reason for Standards Track especially since the document > doesn't describe precisely what is implemented and deployed. > > > 2. Interoperability. IGMP/MLD may break if not implemented correctly. > > There have been examples of this done wrong I think (although I > > cannot remember for sure now. There have been issues with various > > snooping/proxy implementations where explicit tracking is one part). > > I think this is the strongest claim. > There are some uses of 2119 language (not many) in the I-D, and it is my take > that ignoring those would break interop. > We could improve the standing as Standards Track if we made a stronger case for > this I-D setting guidelines that implementations of this function must follow. > > > 3. There are other documents that are/were planned for standards track > > referencing it. > > That is pretty poor as a reason. > Normative references can and are made to Informational RFCs from Standards > Track > documents. > > > I think 1 was the main argument brought up in the meeting (see the > > minutes included below), but IMO 2 is the strongest argument for PS. > > 3 is not that strong as it is still possible to reference it (just more > > difficult). > > OK. > We reached the same conclusions. > > > > issue here is that there is a difference between: > > > - black-box behavior > > > - principles of operation of the function > > > - sample (example) mechanism. > > > > I guess the concern here might be that existing implementations might > > work fine, but not necessarily follow this draft, and that there are > > several valid ways to implement it. But a lot of what is described in > > the document is not required, it talks about several ways things can > > be done. It only uses requirements language in a few places where I > > think it is really needed. Note that there were key people from > > different vendors stating that they wanted it standards track. > > > > > OK. It seems that there is history in the WG for considering this as > Standards > > > Track so we need to construct a message to the IESG about why this is > > > reasonable. > > > > I mentioned RFC 4605 here, which is PS and came out of magma with Brian > > as one of the authors. There are similarities between that document and > > this, and both have some normative language required to not break the > > IGMP/MLD protocols. > > > > Happy for input from others in the group, but I believe the WG wants it > > to be standards track. > > > > > Anyone want to take a first cut at that or shall I? > > > > I think it would be helpful if you can do at least a very rough first > > cut, giving us an idea what points are worth bringing up. > > OK. That will follow. But I think it is also going to result in some reworking > of the draft to make it clear what is necessary/advised to avoid breaking stuff, > and what is a descriptive example of how the function could be achieved within > that guidance. > > Cheers, > Adrian > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From sami.biz.email@gmail.com Tue Jan 7 17:13:08 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8737A1AE279 for ; Tue, 7 Jan 2014 17:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.373 X-Spam-Level: * X-Spam-Status: No, score=1.373 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fo0pn9MfIpoI for ; Tue, 7 Jan 2014 17:13:07 -0800 (PST) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B3BE71AE270 for ; Tue, 7 Jan 2014 17:13:06 -0800 (PST) Received: by mail-ea0-f175.google.com with SMTP id z10so516263ead.6 for ; Tue, 07 Jan 2014 17:12:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=3OBtszWlglfaU8wo5XIpEnaYZDowjy84dZKOytdxRLM=; b=VtOORuoY1BTvecPkYYSpqfoKUoL28kv0ZiT8XrTXJhcp7fZfDlIIynQMx8lk+8/yJ6 or+d8ZQeY8lm0mhI/5BkXicBHC3Tgw4BJXunBldlJyZxiVsCb2tt7wKua20/N+yOqQ7J /8p6E7jVwM/5cDbpfnNv939CYgUJ0sIRhzzTwVgwPAhqNfvU54egPk72Y2It+NKH7VjZ G16O5xppBu+Rggo3a9jHvbyog/0TPpH5/MXBVOF61dM/ocMcDzaIPw9G59GXoFdNhCH7 TTASOsIqRpvDv8Us08YUYbukuXMurv0rtNaYp4/B00Y9N5cKdwH47LKADg+DgqwsvWN+ kHcQ== X-Received: by 10.14.179.130 with SMTP id h2mr43526786eem.34.1389143577303; Tue, 07 Jan 2014 17:12:57 -0800 (PST) Received: from [192.168.1.5] ([178.253.49.93]) by mx.google.com with ESMTPSA id e3sm184792594eeg.11.2014.01.07.17.12.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jan 2014 17:12:56 -0800 (PST) Message-ID: <52CCA597.6010004@gmail.com> Date: Wed, 08 Jan 2014 04:40:47 +0330 From: saeed sami User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 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-Sami-PIM-NG X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 01:13:08 -0000 Dear Sir/Madam, Hello. My name is Saeed Sami and am from IRAN. This email is in regards to an individual ID submission i recently made, under the name " draft-sami-pim-ng" with revision number "01". it will be updated with a new version, as one or 2 sections must be added to the current document and also some editing must be done. the intended status of the ID is "proposed standard" and is an individual submission. I was advised and instructed to contact the PIM working group to introduce my ID, so my submitted ID will be reviewed by the PIM working group experts. Now if you let me, i am going to briefly explain about the ID and talk about the motivation behind attempting to work on it and complete it as a Proposed Standard: PIM-NG stands for PIM-Next Generation . the name is chosen due to the fact that it can be the next generation of the current PIM routing protocol if approved . and if implemented correctly, through its processes can provide better and more enhanced multicast routing features . The idea formed at the CCIE course i attended here in IRAN. what motivated me and triggered the first thought was related to the process of, how a host finds and communicates with the source generating a desired multicast traffic. the process through which the host must first join the RPT rooted at the RP seemed to be a little time consuming , and also the role of RP and BSR or mapping agent as described in CISCO documents weren't as clear as possible at least to me. so the first thing that came to my mind as the general idea was to enhance the processes in a way that a host can communicate as fast as possible with the source and also make the role of RP and BSR or mapping agent a little bit more bold. one other thing that caused me to go even further with the design of PIM-NG specifications , was the fact that the current RPF check method used in PIM-SM implementations alongside MSDP makes it hard to have a good control over the propagation of the information related to the existing multicast sources. so new packet formats , which need the touch of PIM working group experts, alongside the new RPF check method unique to PIM-NG are designed and defined in a way that provides the possibility of having transitory Autonomous Systems or Multicast Domains in Multicast network designs. the new Domain definition, unique to PIM-NG, provides more security features and a much more robust and flexible control over Multicast Domains and also provides the capability of implementing transitory multicast domains or dividing a multicast domain to sub-domains and ... . The new definition of the ANYCAST RP used in PIM-NG provides more simplicity . And the overall related processes are designed and defined in a way which if implemented correctly , makes PIM-NG capable of doing most of the work automatically and on auto pilot to be more precise. Most of the processes are explained through many examples and scenarios illustrated and viewable in the PDF version to make the review process easier. also there are command lines used in this document which are only used to simplify the explanation process easier as this is my first time getting involved in something as big as this. and it is also mentioned in the document that any command line or ip address used in the document are only to be interpreted as examples and not the solid command lines or ip addresses that might be used. No implementations have been made based on PIM-NG specifications, due to the fact that i had been advised from the beginning that, as the intended status of the ID is proposed standard , it must be first be reviewed by PIM working group experts. The parts that really needs the touch of an expert, can be the parts related to the new packet format designs. and also as this is my first time working on an ID as a proposed standard, the parts related to the explanation of the processes through examples and scenarios using some command lines as an example( please be noted that it is written and mentioned in the document that any command line or IP address used in the document is only to simplify the explanation process and is used only as an example) may need corrections by PIM working group experts. the design and writing of the current PIM-NG specifications has been done over the past eight months under the supervision of my instructor, who is one the HUAWEI top network experts in IP department here in IRAN. but please be noted again that this ID is submitted as an individual submission and is not related to any entity company or enterprise. and finally this is done solely with the thought of repaying to the network society by making a positive change , and i hope that this ID " draft-sami-pim-ng-01" gets reviewed in the best possible way. and i hope that i will able to work with the experts in the PIM Area to make PIM-NG even better. link to the ID : http://datatracker.ietf.org/doc/draft-sami-pim-ng/ Thanks for giving me the chance of being part of the future. Sincerely Saeed Sami From stig@venaas.com Wed Jan 8 15:29:04 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC2D1ADBCE for ; Wed, 8 Jan 2014 15:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsNwcRqdLXk8 for ; Wed, 8 Jan 2014 15:29:00 -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 897B41ADBCD for ; Wed, 8 Jan 2014 15:29:00 -0800 (PST) Received: from [IPv6:2001:420:301:1004:987:33ee:a561:cf0f] (unknown [IPv6:2001:420:301:1004:987:33ee:a561:cf0f]) by ufisa.uninett.no (Postfix) with ESMTPSA id D1A40806A; Thu, 9 Jan 2014 00:28:49 +0100 (CET) Message-ID: <52CDDF2F.7040900@venaas.com> Date: Wed, 08 Jan 2014 15:28:47 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, draft-ietf-pim-explicit-tracking.all@tools.ietf.org References: <01d601cf0be4$66b06900$34113b00$@olddog.co.uk> In-Reply-To: <01d601cf0be4$66b06900$34113b00$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pim@ietf.org Subject: Re: [pim] Draft email to IESG on draft-ietf-pim-explicit-tracking X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 23:29:04 -0000 On 1/7/2014 12:09 PM, Adrian Farrel wrote: > Should probably come from the document shepherd once all is agreed. This looks reasonable to me. I agree that the draft can be improved as you suggest. Anyone else in the WG (including the author) got any comments? Should I as the document shepherd send this to the IESG? Stig > === > > Hi IESG, > > Thanks for your reviews and Comments on draft-ietf-pim-explicit-tracking. Adrian > has brought these back to the PIM WG and we are concerned to address the cause > of the Abstentions by discussing the situation with you and by making some > modifications to the text. > > Firstly to let you know that although this I-D started off as Informational it > was moved to Standards Track after some debate in the working group. Various > reasons were advanced, but we consider the most important one to be that the > document describes function that is important for the scalability of multicast > networks, already widely implemented, and which could seriously break IGMP/MLD > if not implemented correctly. In this respect, we see this work as similar to > RFC 4605 which was also published as Standards Track. > > While we appreciate your concerns that there are many ways to implement this > function (and, indeed, there are many different existing implementations), we > believe that there is a core statement of what must and must not be done in > order to avoid breaking interoperability. That is, although there is no > description of on-wire behavior that must be implemented to achieve > interoperability, this document describes things that must be done if this > function is used and interoperability is to be retained. > > We think that the document could be clearer about this. In particular, we think > that we should make a clearer distinction in the text between: > - the description of the problem > - the objective and overview of the function > - statements about what implementations must/should/etc. do > - an example set of procedures that an implementation could follow if it wants > to be sure of being safe. > We don't expect that this clarification work will result in substantial changes > to the text, but will mean some changes to the sections, and a few clarifying > sentences. But we do believe that the resulting document should continue as > Standards Track. > > In view of this, we suggest that you delay your consideration of the document > until we have produced a new revision. > > === > > Please note: I am floating this text, not dictating it! If the WG does not > agree, then the WG needs to speak up. > > Cheers, > Adrian > >> -----Original Message----- >> From: pim [mailto:pim-bounces@ietf.org] On Behalf Of Adrian Farrel >> Sent: 07 January 2014 19:54 >> To: 'Stig Venaas'; draft-ietf-pim-explicit-tracking.all@tools.ietf.org >> Cc: pim@ietf.org >> Subject: Re: [pim] updated by Cindy >> Morgan >> >> Thanks again Stig, >> >> I'm going to play devil's advocate here because I know that various ADs will > ask >> the hard questions. I also know that you are trying to represent what you > heard >> in the WG (so we are both arguing representative corners rather than our own >> positions - perhaps we could get jobs playing lawyers on TV). >> >>>> Thanks or this explanation. I can appreciate the points you make. Indeed, >>>> one of the things I tried to explain to the IESG was that getting this > wrong >>>> could break interoperability. >>>> >>>> The counter argument made to me was that there are many ways to >>>> achieve the function and that (as far as the ADs knew) none of the >>>> existing implementations (some of which are quite old) actually does >>>> what this draft describes. Maybe the >>> >>> Yes, there are multiple ways of doing this. I think existing >>> implementations are close to what the draft specifies (with >>> some variations and not all that is mentioned here). >> >> Hmmm. OK. >> So we have "Here is a document that describes something similar to what some >> implementations do to achieve this function." >> >>> This draft started out as informational, and my understanding of >>> this was that we view this as important functionality and that it >>> was worth describing how to implement it in a good way. That sounds >>> like a typical informational draft to me. >> >> Yes. >> So let's work though the reasoning below before I say "I agree. Let's make > this >> Informational and be done with it." >> >>> The main reasons it was changed to standards track are roughly: >>> >>> 1. It is a very useful feature and widely implemented and deployed. >> >> That is without doubt. >> But that is not a reason for Standards Track especially since the document >> doesn't describe precisely what is implemented and deployed. >> >>> 2. Interoperability. IGMP/MLD may break if not implemented correctly. >>> There have been examples of this done wrong I think (although I >>> cannot remember for sure now. There have been issues with various >>> snooping/proxy implementations where explicit tracking is one part). >> >> I think this is the strongest claim. >> There are some uses of 2119 language (not many) in the I-D, and it is my take >> that ignoring those would break interop. >> We could improve the standing as Standards Track if we made a stronger case > for >> this I-D setting guidelines that implementations of this function must follow. >> >>> 3. There are other documents that are/were planned for standards track >>> referencing it. >> >> That is pretty poor as a reason. >> Normative references can and are made to Informational RFCs from Standards >> Track >> documents. >> >>> I think 1 was the main argument brought up in the meeting (see the >>> minutes included below), but IMO 2 is the strongest argument for PS. >>> 3 is not that strong as it is still possible to reference it (just more >>> difficult). >> >> OK. >> We reached the same conclusions. >> >>>> issue here is that there is a difference between: >>>> - black-box behavior >>>> - principles of operation of the function >>>> - sample (example) mechanism. >>> >>> I guess the concern here might be that existing implementations might >>> work fine, but not necessarily follow this draft, and that there are >>> several valid ways to implement it. But a lot of what is described in >>> the document is not required, it talks about several ways things can >>> be done. It only uses requirements language in a few places where I >>> think it is really needed. Note that there were key people from >>> different vendors stating that they wanted it standards track. >>> >>>> OK. It seems that there is history in the WG for considering this as >> Standards >>>> Track so we need to construct a message to the IESG about why this is >>>> reasonable. >>> >>> I mentioned RFC 4605 here, which is PS and came out of magma with Brian >>> as one of the authors. There are similarities between that document and >>> this, and both have some normative language required to not break the >>> IGMP/MLD protocols. >>> >>> Happy for input from others in the group, but I believe the WG wants it >>> to be standards track. >>> >>>> Anyone want to take a first cut at that or shall I? >>> >>> I think it would be helpful if you can do at least a very rough first >>> cut, giving us an idea what points are worth bringing up. >> >> OK. That will follow. But I think it is also going to result in some reworking >> of the draft to make it clear what is necessary/advised to avoid breaking > stuff, >> and what is a descriptive example of how the function could be achieved within >> that guidance. >> >> Cheers, >> Adrian >> >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim From asaeda@sfc.wide.ad.jp Wed Jan 8 19:17:19 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C541AE051 for ; Wed, 8 Jan 2014 19:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.15 X-Spam-Level: X-Spam-Status: No, score=-99.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.538, SPF_NEUTRAL=0.779, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Meu7IXFmVsPR for ; Wed, 8 Jan 2014 19:17:16 -0800 (PST) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 316941AE0AB for ; Wed, 8 Jan 2014 19:17:15 -0800 (PST) Received: from localhost (unknown [133.69.35.12]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id CE814278119; Thu, 9 Jan 2014 12:17:05 +0900 (JST) Date: Thu, 09 Jan 2014 12:17:03 +0900 (JST) Message-Id: <20140109.121703.114947043.asaeda@sfc.wide.ad.jp> To: adrian@olddog.co.uk From: Hitoshi Asaeda In-Reply-To: <01d601cf0be4$66b06900$34113b00$@olddog.co.uk> References: <01d601cf0be4$66b06900$34113b00$@olddog.co.uk> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: draft-ietf-pim-explicit-tracking.all@tools.ietf.org, pim@ietf.org Subject: Re: [pim] Draft email to IESG on draft-ietf-pim-explicit-tracking X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 03:17:19 -0000 Hi Adrian and Stig, I greatly appreciate your efforts, and also agree to the following explanation. Thank you. Regards, -- Hitoshi Asaeda Subject: [pim] Draft email to IESG on draft-ietf-pim-explicit-tracking Date: Tue, 7 Jan 2014 20:09:36 -0000 > Should probably come from the document shepherd once all is agreed. > > === > > Hi IESG, > > Thanks for your reviews and Comments on draft-ietf-pim-explicit-tracking. Adrian > has brought these back to the PIM WG and we are concerned to address the cause > of the Abstentions by discussing the situation with you and by making some > modifications to the text. > > Firstly to let you know that although this I-D started off as Informational it > was moved to Standards Track after some debate in the working group. Various > reasons were advanced, but we consider the most important one to be that the > document describes function that is important for the scalability of multicast > networks, already widely implemented, and which could seriously break IGMP/MLD > if not implemented correctly. In this respect, we see this work as similar to > RFC 4605 which was also published as Standards Track. > > While we appreciate your concerns that there are many ways to implement this > function (and, indeed, there are many different existing implementations), we > believe that there is a core statement of what must and must not be done in > order to avoid breaking interoperability. That is, although there is no > description of on-wire behavior that must be implemented to achieve > interoperability, this document describes things that must be done if this > function is used and interoperability is to be retained. > > We think that the document could be clearer about this. In particular, we think > that we should make a clearer distinction in the text between: > - the description of the problem > - the objective and overview of the function > - statements about what implementations must/should/etc. do > - an example set of procedures that an implementation could follow if it wants > to be sure of being safe. > We don't expect that this clarification work will result in substantial changes > to the text, but will mean some changes to the sections, and a few clarifying > sentences. But we do believe that the resulting document should continue as > Standards Track. > > In view of this, we suggest that you delay your consideration of the document > until we have produced a new revision. > > === > > Please note: I am floating this text, not dictating it! If the WG does not > agree, then the WG needs to speak up. > > Cheers, > Adrian > >> -----Original Message----- >> From: pim [mailto:pim-bounces@ietf.org] On Behalf Of Adrian Farrel >> Sent: 07 January 2014 19:54 >> To: 'Stig Venaas'; draft-ietf-pim-explicit-tracking.all@tools.ietf.org >> Cc: pim@ietf.org >> Subject: Re: [pim] updated by Cindy >> Morgan >> >> Thanks again Stig, >> >> I'm going to play devil's advocate here because I know that various ADs will > ask >> the hard questions. I also know that you are trying to represent what you > heard >> in the WG (so we are both arguing representative corners rather than our own >> positions - perhaps we could get jobs playing lawyers on TV). >> >> > > Thanks or this explanation. I can appreciate the points you make. Indeed, >> > > one of the things I tried to explain to the IESG was that getting this > wrong >> > > could break interoperability. >> > > >> > > The counter argument made to me was that there are many ways to >> > > achieve the function and that (as far as the ADs knew) none of the >> > > existing implementations (some of which are quite old) actually does >> > > what this draft describes. Maybe the >> > >> > Yes, there are multiple ways of doing this. I think existing >> > implementations are close to what the draft specifies (with >> > some variations and not all that is mentioned here). >> >> Hmmm. OK. >> So we have "Here is a document that describes something similar to what some >> implementations do to achieve this function." >> >> > This draft started out as informational, and my understanding of >> > this was that we view this as important functionality and that it >> > was worth describing how to implement it in a good way. That sounds >> > like a typical informational draft to me. >> >> Yes. >> So let's work though the reasoning below before I say "I agree. Let's make > this >> Informational and be done with it." >> >> > The main reasons it was changed to standards track are roughly: >> > >> > 1. It is a very useful feature and widely implemented and deployed. >> >> That is without doubt. >> But that is not a reason for Standards Track especially since the document >> doesn't describe precisely what is implemented and deployed. >> >> > 2. Interoperability. IGMP/MLD may break if not implemented correctly. >> > There have been examples of this done wrong I think (although I >> > cannot remember for sure now. There have been issues with various >> > snooping/proxy implementations where explicit tracking is one part). >> >> I think this is the strongest claim. >> There are some uses of 2119 language (not many) in the I-D, and it is my take >> that ignoring those would break interop. >> We could improve the standing as Standards Track if we made a stronger case > for >> this I-D setting guidelines that implementations of this function must follow. >> >> > 3. There are other documents that are/were planned for standards track >> > referencing it. >> >> That is pretty poor as a reason. >> Normative references can and are made to Informational RFCs from Standards >> Track >> documents. >> >> > I think 1 was the main argument brought up in the meeting (see the >> > minutes included below), but IMO 2 is the strongest argument for PS. >> > 3 is not that strong as it is still possible to reference it (just more >> > difficult). >> >> OK. >> We reached the same conclusions. >> >> > > issue here is that there is a difference between: >> > > - black-box behavior >> > > - principles of operation of the function >> > > - sample (example) mechanism. >> > >> > I guess the concern here might be that existing implementations might >> > work fine, but not necessarily follow this draft, and that there are >> > several valid ways to implement it. But a lot of what is described in >> > the document is not required, it talks about several ways things can >> > be done. It only uses requirements language in a few places where I >> > think it is really needed. Note that there were key people from >> > different vendors stating that they wanted it standards track. >> > >> > > OK. It seems that there is history in the WG for considering this as >> Standards >> > > Track so we need to construct a message to the IESG about why this is >> > > reasonable. >> > >> > I mentioned RFC 4605 here, which is PS and came out of magma with Brian >> > as one of the authors. There are similarities between that document and >> > this, and both have some normative language required to not break the >> > IGMP/MLD protocols. >> > >> > Happy for input from others in the group, but I believe the WG wants it >> > to be standards track. >> > >> > > Anyone want to take a first cut at that or shall I? >> > >> > I think it would be helpful if you can do at least a very rough first >> > cut, giving us an idea what points are worth bringing up. >> >> OK. That will follow. But I think it is also going to result in some reworking >> of the draft to make it clear what is necessary/advised to avoid breaking > stuff, >> and what is a descriptive example of how the function could be achieved within >> that guidance. >> >> Cheers, >> Adrian >> >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From stig@venaas.com Thu Jan 9 10:17:42 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6431AE447 for ; Thu, 9 Jan 2014 10:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbbKskw8aLOI for ; Thu, 9 Jan 2014 10:17:38 -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 EFD481AE443 for ; Thu, 9 Jan 2014 10:17:37 -0800 (PST) Received: from [IPv6:2001:420:301:1004:c39:7238:774b:14e8] (unknown [IPv6:2001:420:301:1004:c39:7238:774b:14e8]) by ufisa.uninett.no (Postfix) with ESMTPSA id 8B71F7FB9; Thu, 9 Jan 2014 19:17:26 +0100 (CET) Message-ID: <52CEE7AF.7000300@venaas.com> Date: Thu, 09 Jan 2014 10:17:19 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Hitoshi Asaeda , adrian@olddog.co.uk References: <01d601cf0be4$66b06900$34113b00$@olddog.co.uk> <20140109.121703.114947043.asaeda@sfc.wide.ad.jp> In-Reply-To: <20140109.121703.114947043.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-pim-explicit-tracking.all@tools.ietf.org, pim@ietf.org Subject: Re: [pim] Draft email to IESG on draft-ietf-pim-explicit-tracking X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 18:17:42 -0000 On 1/8/2014 7:17 PM, Hitoshi Asaeda wrote: > Hi Adrian and Stig, > > I greatly appreciate your efforts, and also agree to the following > explanation. > Thank you. Good. Adrian, can I just send the text you wrote then? Thanks a lot for writing that, it looks good to me. Stig > > Regards, > -- > Hitoshi Asaeda > > > Subject: [pim] Draft email to IESG on draft-ietf-pim-explicit-tracking > Date: Tue, 7 Jan 2014 20:09:36 -0000 > >> Should probably come from the document shepherd once all is agreed. >> >> === >> >> Hi IESG, >> >> Thanks for your reviews and Comments on draft-ietf-pim-explicit-tracking. Adrian >> has brought these back to the PIM WG and we are concerned to address the cause >> of the Abstentions by discussing the situation with you and by making some >> modifications to the text. >> >> Firstly to let you know that although this I-D started off as Informational it >> was moved to Standards Track after some debate in the working group. Various >> reasons were advanced, but we consider the most important one to be that the >> document describes function that is important for the scalability of multicast >> networks, already widely implemented, and which could seriously break IGMP/MLD >> if not implemented correctly. In this respect, we see this work as similar to >> RFC 4605 which was also published as Standards Track. >> >> While we appreciate your concerns that there are many ways to implement this >> function (and, indeed, there are many different existing implementations), we >> believe that there is a core statement of what must and must not be done in >> order to avoid breaking interoperability. That is, although there is no >> description of on-wire behavior that must be implemented to achieve >> interoperability, this document describes things that must be done if this >> function is used and interoperability is to be retained. >> >> We think that the document could be clearer about this. In particular, we think >> that we should make a clearer distinction in the text between: >> - the description of the problem >> - the objective and overview of the function >> - statements about what implementations must/should/etc. do >> - an example set of procedures that an implementation could follow if it wants >> to be sure of being safe. >> We don't expect that this clarification work will result in substantial changes >> to the text, but will mean some changes to the sections, and a few clarifying >> sentences. But we do believe that the resulting document should continue as >> Standards Track. >> >> In view of this, we suggest that you delay your consideration of the document >> until we have produced a new revision. >> >> === >> >> Please note: I am floating this text, not dictating it! If the WG does not >> agree, then the WG needs to speak up. >> >> Cheers, >> Adrian >> >>> -----Original Message----- >>> From: pim [mailto:pim-bounces@ietf.org] On Behalf Of Adrian Farrel >>> Sent: 07 January 2014 19:54 >>> To: 'Stig Venaas'; draft-ietf-pim-explicit-tracking.all@tools.ietf.org >>> Cc: pim@ietf.org >>> Subject: Re: [pim] updated by Cindy >>> Morgan >>> >>> Thanks again Stig, >>> >>> I'm going to play devil's advocate here because I know that various ADs will >> ask >>> the hard questions. I also know that you are trying to represent what you >> heard >>> in the WG (so we are both arguing representative corners rather than our own >>> positions - perhaps we could get jobs playing lawyers on TV). >>> >>>>> Thanks or this explanation. I can appreciate the points you make. Indeed, >>>>> one of the things I tried to explain to the IESG was that getting this >> wrong >>>>> could break interoperability. >>>>> >>>>> The counter argument made to me was that there are many ways to >>>>> achieve the function and that (as far as the ADs knew) none of the >>>>> existing implementations (some of which are quite old) actually does >>>>> what this draft describes. Maybe the >>>> >>>> Yes, there are multiple ways of doing this. I think existing >>>> implementations are close to what the draft specifies (with >>>> some variations and not all that is mentioned here). >>> >>> Hmmm. OK. >>> So we have "Here is a document that describes something similar to what some >>> implementations do to achieve this function." >>> >>>> This draft started out as informational, and my understanding of >>>> this was that we view this as important functionality and that it >>>> was worth describing how to implement it in a good way. That sounds >>>> like a typical informational draft to me. >>> >>> Yes. >>> So let's work though the reasoning below before I say "I agree. Let's make >> this >>> Informational and be done with it." >>> >>>> The main reasons it was changed to standards track are roughly: >>>> >>>> 1. It is a very useful feature and widely implemented and deployed. >>> >>> That is without doubt. >>> But that is not a reason for Standards Track especially since the document >>> doesn't describe precisely what is implemented and deployed. >>> >>>> 2. Interoperability. IGMP/MLD may break if not implemented correctly. >>>> There have been examples of this done wrong I think (although I >>>> cannot remember for sure now. There have been issues with various >>>> snooping/proxy implementations where explicit tracking is one part). >>> >>> I think this is the strongest claim. >>> There are some uses of 2119 language (not many) in the I-D, and it is my take >>> that ignoring those would break interop. >>> We could improve the standing as Standards Track if we made a stronger case >> for >>> this I-D setting guidelines that implementations of this function must follow. >>> >>>> 3. There are other documents that are/were planned for standards track >>>> referencing it. >>> >>> That is pretty poor as a reason. >>> Normative references can and are made to Informational RFCs from Standards >>> Track >>> documents. >>> >>>> I think 1 was the main argument brought up in the meeting (see the >>>> minutes included below), but IMO 2 is the strongest argument for PS. >>>> 3 is not that strong as it is still possible to reference it (just more >>>> difficult). >>> >>> OK. >>> We reached the same conclusions. >>> >>>>> issue here is that there is a difference between: >>>>> - black-box behavior >>>>> - principles of operation of the function >>>>> - sample (example) mechanism. >>>> >>>> I guess the concern here might be that existing implementations might >>>> work fine, but not necessarily follow this draft, and that there are >>>> several valid ways to implement it. But a lot of what is described in >>>> the document is not required, it talks about several ways things can >>>> be done. It only uses requirements language in a few places where I >>>> think it is really needed. Note that there were key people from >>>> different vendors stating that they wanted it standards track. >>>> >>>>> OK. It seems that there is history in the WG for considering this as >>> Standards >>>>> Track so we need to construct a message to the IESG about why this is >>>>> reasonable. >>>> >>>> I mentioned RFC 4605 here, which is PS and came out of magma with Brian >>>> as one of the authors. There are similarities between that document and >>>> this, and both have some normative language required to not break the >>>> IGMP/MLD protocols. >>>> >>>> Happy for input from others in the group, but I believe the WG wants it >>>> to be standards track. >>>> >>>>> Anyone want to take a first cut at that or shall I? >>>> >>>> I think it would be helpful if you can do at least a very rough first >>>> cut, giving us an idea what points are worth bringing up. >>> >>> OK. That will follow. But I think it is also going to result in some reworking >>> of the draft to make it clear what is necessary/advised to avoid breaking >> stuff, >>> and what is a descriptive example of how the function could be achieved within >>> that guidance. >>> >>> Cheers, >>> Adrian >>> >>> _______________________________________________ >>> pim mailing list >>> pim@ietf.org >>> https://www.ietf.org/mailman/listinfo/pim >> >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim From adrian@olddog.co.uk Thu Jan 9 10:39:29 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4D21AE37A for ; Thu, 9 Jan 2014 10:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.217 X-Spam-Level: X-Spam-Status: No, score=0.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8MO8Ny6e6k6 for ; Thu, 9 Jan 2014 10:39:28 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 07B2C1AE0E7 for ; Thu, 9 Jan 2014 10:39:27 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s09IdEe4029977; Thu, 9 Jan 2014 18:39:15 GMT Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s09IdCOW029951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 18:39:13 GMT From: "Adrian Farrel" To: "'Stig Venaas'" , "'Hitoshi Asaeda'" References: <01d601cf0be4$66b06900$34113b00$@olddog.co.uk> <20140109.121703.114947043.asaeda@sfc.wide.ad.jp> <52CEE7AF.7000300@venaas.com> In-Reply-To: <52CEE7AF.7000300@venaas.com> Date: Thu, 9 Jan 2014 18:39:11 -0000 Message-ID: <035801cf0d6a$180ca4d0$4825ee70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHcXCCjyv/eB3CyBvN49UK8ctwlTgEbFl4kAc3DQraaStTYIA== Content-Language: en-gb Cc: draft-ietf-pim-explicit-tracking.all@tools.ietf.org, pim@ietf.org Subject: Re: [pim] Draft email to IESG on draft-ietf-pim-explicit-tracking X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 18:39:29 -0000 > Good. Adrian, can I just send the text you wrote then? > Thanks a lot for writing that, it looks good to me. I'm good with that (bearing in mind that it commits the WG/authors to do a little jiggling of the document - I'm happy to help with that). A From lucy.yong@huawei.com Wed Jan 15 14:54:35 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31A31AE2CA; Wed, 15 Jan 2014 14:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAQDfFPZCtGq; Wed, 15 Jan 2014 14:54:34 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DD03D1AE2B6; Wed, 15 Jan 2014 14:54:33 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZZ16023; Wed, 15 Jan 2014 22:54:21 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Jan 2014 22:53:26 +0000 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Jan 2014 22:54:20 +0000 Received: from DFWEML702-CHM.china.huawei.com ([169.254.4.231]) by dfweml705-chm.china.huawei.com ([169.254.7.245]) with mapi id 14.03.0158.001; Wed, 15 Jan 2014 14:54:17 -0800 From: Lucy yong To: "isis-wg@ietf.org list" , "pim@ietf.org" Thread-Topic: solicit comments on draft-yong-isis-4-distribution-tree Thread-Index: Ac8SRVrTnLNgGQtBQYyCYGAasvtLaQ== Date: Wed, 15 Jan 2014 22:54:16 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4531899E@dfweml702-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.147] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D4531899Edfweml702chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [pim] solicit comments on draft-yong-isis-4-distribution-tree X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 22:54:35 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D4531899Edfweml702chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, We like to hear the comments from the community on this draft. Abstract This document proposes an IS-IS protocol extension for automatically buildi= ng bi-directional distribution trees to transport multi-destination traffic in an IP network. Thanks, Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D4531899Edfweml702chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

We like to hear the comments from the community on t= his draft.

 

Abstract

This document proposes an IS-IS protocol extension f= or automatically building bi-directional distribution

trees to transport multi-destination traffic in an I= P network.

 

Thanks,

Lucy

 

--_000_2691CE0099834E4A9C5044EEC662BB9D4531899Edfweml702chmchi_-- From lucy.yong@huawei.com Thu Jan 16 08:09:10 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341A91AE4F4; Thu, 16 Jan 2014 08:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPNE81195pWq; Thu, 16 Jan 2014 08:09:09 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 11EFD1AE4F2; Thu, 16 Jan 2014 08:09:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAA31212; Thu, 16 Jan 2014 16:08:52 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Jan 2014 16:08:04 +0000 Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Jan 2014 16:08:50 +0000 Received: from DFWEML702-CHM.china.huawei.com ([169.254.4.231]) by dfweml703-chm.china.huawei.com ([169.254.5.188]) with mapi id 14.03.0158.001; Thu, 16 Jan 2014 08:08:37 -0800 From: Lucy yong To: "curtis@ipv6.occnc.com" Thread-Topic: [Isis-wg] solicit comments on draft-yong-isis-ext-4-distribution-tree Thread-Index: AQHPEtU2eILY1hwkBkKGqAQFauosZQ== Date: Thu, 16 Jan 2014 16:08:37 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45319D42@dfweml702-chm.china.huawei.com> References: Your message of "Wed, 15 Jan 2014 22:54:16 +0000." <2691CE0099834E4A9C5044EEC662BB9D4531899E@dfweml702-chm.china.huawei.com> <201401160051.s0G0p0rI025722@maildrop2.v6ds.occnc.com> In-Reply-To: <201401160051.s0G0p0rI025722@maildrop2.v6ds.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "isis-wg@ietf.org list" , "pim@ietf.org" Subject: Re: [pim] [Isis-wg] solicit comments on draft-yong-isis-ext-4-distribution-tree X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 16:09:10 -0000 Hi Curtis, Thank you for the observation. I modified the subject. [snip] First glance - for backward compatibility a capabilities indication would b= e nice to have. Without this a network with one incapable node could surpr= isingly fail to work for part of the topology. With it the trees can be bu= ilt around such a node. [Lucy] agreed. Building tunnels could be possible but require that a special type of link = be advertised (maybe an MPLS FA would do it). As you stated how to build t= he tunnels would be out of scope. I really have not yet looked at this closely. [Lucy] Please take a look and provide your additional comments and suggesti= ons. Regards, Lucy Curtis From otroan@employees.org Tue Jan 21 11:03:05 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2271A01D4; Tue, 21 Jan 2014 11:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkt9XlPumeIg; Tue, 21 Jan 2014 11:03:04 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id F19B61A01C3; Tue, 21 Jan 2014 11:03:03 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAB/E3lKQ/khL/2dsb2JhbABZgws4g1O4c4EVFnSCJQEBAQMBAQEBIEsLBQsJEwECAQIrAgInIgQCCAcSh30IDYsXm3GcJReObhENgmk1gRQEkDuJGZBmgy47 X-IronPort-AV: E=Sophos;i="4.95,697,1384300800"; d="asc'?scan'208";a="3299229" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 21 Jan 2014 19:03:03 +0000 Received: from dhcp-10-61-101-126.cisco.com (dhcp-10-61-101-126.cisco.com [10.61.101.126]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0LJ328C022676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Jan 2014 19:03:02 GMT From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_999A5E68-CB56-43C2-B74E-C9A359FCEFB8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Date: Tue, 21 Jan 2014 20:03:01 +0100 References: <0F5F4D9B-A5BD-4D6A-9A9D-B8D912816E7A@employees.org> To: pim@ietf.org, mboned@ietf.org X-Mailer: Apple Mail (2.1827) Cc: "6man Chairs \(6man-chairs@tools.ietf.org\)" <6man-chairs@tools.ietf.org> Subject: [pim] Fwd: WGLC: draft-ietf-6man-multicast-addr-arch-update-02 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 19:03:05 -0000 --Apple-Mail=_999A5E68-CB56-43C2-B74E-C9A359FCEFB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi, I just wanted to give you a heads up of a working group last call we are = having over in 6man. Review and comments from people with multicast clue would be greatly = appreciated. Best regards, Ole & Bob Begin forwarded message: > From: Ole Troan > Subject: WGLC: draft-ietf-6man-multicast-addr-arch-update-02 > Date: 16 Jan 2014 15:25:59 GMT+1 > To: 6man WG > Cc: "6man Chairs \(6man-chairs@tools.ietf.org\)" = <6man-chairs@tools.ietf.org> > Message-Id: <0F5F4D9B-A5BD-4D6A-9A9D-B8D912816E7A@employees.org> >=20 > All, >=20 > This message starts a two week 6MAN Working Group Last Call on = draft-ietf-6man-multicast-addr-arch-update-02: >=20 > Title : Updates to the IPv6 Multicast Addressing = Architecture > Author(s) : M. Boucadair, S. Venaas > Filename : draft-ietf-6man-multicast-addr-arch-update-02 > Pages : 8 > Date : 2013-10-18 >=20 > = http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-02 >=20 > as a Proposed Standard. Substantive comments and statements of = support for advancing this document should be directed to the mailing = list. Editorial suggestions can be sent to the authors. This last call = will end on January 30, 2014. >=20 > Suresh Krishnan and JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89= have volunteered to do a detailed review of the document. We would also = encourage volunteers to act as document shepherds. Please contact the = chairs directly. >=20 > Regards, >=20 > Bob Hinden & Ole Tr=C3=B8an >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_999A5E68-CB56-43C2-B74E-C9A359FCEFB8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS3sRlAAoJEFuJXizso86gPD4IAJ67GtqV9rqP4bBIntCxVKXw cquG4VvBWBvRITj/E6Srcd2t/mbiYhVFxrJZv1S3Ng8YZRXPLH0kNa0chOcZ3Pua 33l9Ox9rUjDfGo6zcd3WB1iCTPe7EsG0Xa3gwBRT3x/oCG8mQtZztbONve2FzbqU cGph/yQG1bWsnejYNKzG0ww8QtkPUtSG6Uo8Jl0pTPPZKNWC0wO/Cg1ZZNw5CXov hkjWY5s1mO5VEQbI9CGbgFZDxUxhMCF1YiCJUk9hphufjTXKXzbuoZlOoTA4ueRo wvQw6i1TLWtxTkcfB9A3WdkZQLZBuHtHBtoaeAbR1SPo3fn2x9Mi5ZsB6l6YYRE= =eYfS -----END PGP SIGNATURE----- --Apple-Mail=_999A5E68-CB56-43C2-B74E-C9A359FCEFB8-- From mike.mcbride@ericsson.com Tue Jan 21 12:33:43 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C291A0235 for ; Tue, 21 Jan 2014 12:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fb-IlrX-YgQy for ; Tue, 21 Jan 2014 12:33:39 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id AF7EB1A0221 for ; Tue, 21 Jan 2014 12:33:39 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-bb-52ded9a28d0e Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F1.80.11484.2A9DED25; Tue, 21 Jan 2014 21:33:39 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0387.000; Tue, 21 Jan 2014 15:33:37 -0500 From: Mike McBride To: "pim@ietf.org" Thread-Topic: Call for adoption of pim-join-attributes-for-lisp Thread-Index: Ac8W5kCJRewan2ErRqO+VSr8xJLTHg== Date: Tue, 21 Jan 2014 20:33:37 +0000 Message-ID: <6F5149063CE40341BE7953160A93C5A0E0F32D@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_6F5149063CE40341BE7953160A93C5A0E0F32Deusaamb109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyuXSPn+7im/eCDKaf5rH48vAmswOjx5Il P5kCGKO4bFJSczLLUov07RK4MhoObGAr2CRd8Xf1LqYGxiaJLkZODgkBE4lpJ5rZIWwxiQv3 1rN1MXJxCAkcYZQ4e+MyI4SznFFi3ccVbCBVbAJ6EqcXNrOC2CICihLtc1vAbGEBK4kX0xvZ IOL2EmsXt0HZehLHb0DEWQRUJU493gA0lIODV8BbYna7JkiYEWjx91NrmEBsZgFxiVtP5jNB HCQgsWTPeWYIW1Ti5eN/rBC2ksTH3/PZIerzJdZNvwpWwysgKHFy5hOWCYxCs5CMmoWkbBaS Moi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkaO0OLUsN93IcBMjMPCPSbA57mBc8Mny EKM0B4uSOO+Xt85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhi3dL1dr6XBrfei7ENS/1G+ fx1WOS8uKOYr6W799uX/hn+mZm/DTEJ1dFiU6hJnKbEV+tzx26SfzHB4eqnkea1U7+bpl4te pP8o/v3l/FWuObvjJGcIsrb/XSBR5OrJU7By+rxjc5T+VKzcdObrn5KX++ZtNenVYH8/R13O baZZ4YOA04XspQeUWIozEg21mIuKEwF/pMJDSgIAAA== Subject: [pim] Call for adoption of pim-join-attributes-for-lisp X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:33:43 -0000 --_000_6F5149063CE40341BE7953160A93C5A0E0F32Deusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The authors of this draft requested a call for adoption of their draft. At = our last meeting, in Vancouver, 5 people were in favor of adopting the draf= t. 3 were against. One of those against shared the opinion of there being t= oo much existing lisp work needing to be completed within the lisp wg and t= his additional work may muddy the water. Those in favor stated that the lis= p wg is supportive of this work being done within pim. What say you? http://tools.ietf.org/id/draft-arango-pim-join-attributes-for-lisp-00.txt thanks, mike --_000_6F5149063CE40341BE7953160A93C5A0E0F32Deusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The authors of this draft requested a call for adopt= ion of their draft. At our last meeting, in Vancouver, 5 people were in fav= or of adopting the draft. 3 were against. One of those against shared the o= pinion of there being too much existing lisp work needing to be completed within the lisp wg and this additional w= ork may muddy the water. Those in favor stated that the lisp wg is supporti= ve of this work being done within pim.

 

What say you?

 

http://tools.ietf.org/id/draft-arango-pim= -join-attributes-for-lisp-00.txt

 

thanks,

mike

--_000_6F5149063CE40341BE7953160A93C5A0E0F32Deusaamb109ericsso_-- From curtis@ipv6.occnc.com Wed Jan 15 16:51:18 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEB71AE473; Wed, 15 Jan 2014 16:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etR1ot6mElvK; Wed, 15 Jan 2014 16:51:17 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5E55F1AE453; Wed, 15 Jan 2014 16:51:17 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0G0p0rI025722; Wed, 15 Jan 2014 19:51:00 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401160051.s0G0p0rI025722@maildrop2.v6ds.occnc.com> To: Lucy yong From: Curtis Villamizar In-reply-to: Your message of "Wed, 15 Jan 2014 22:54:16 +0000." <2691CE0099834E4A9C5044EEC662BB9D4531899E@dfweml702-chm.china.huawei.com> Date: Wed, 15 Jan 2014 19:51:00 -0500 X-Mailman-Approved-At: Tue, 21 Jan 2014 12:46:05 -0800 Cc: "isis-wg@ietf.org list" , "pim@ietf.org" Subject: Re: [pim] [Isis-wg] solicit comments on draft-yong-isis-4-distribution-tree X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 00:51:19 -0000 In message <2691CE0099834E4A9C5044EEC662BB9D4531899E@dfweml702-chm.china.huawei.com> Lucy yong writes: > Hello, > > We like to hear the comments from the community on this draft. > > Abstract > > This document proposes an IS-IS protocol extension for automatically > building bi-directional distribution trees to transport > multi-destination traffic in an IP network. > > Thanks, > Lucy The document title is wrong in the subject line. Should be: draft-yong-isis-ext-4-distribution-tree-01 The "ext" was missing. Easier to find this way. First glance - for backward compatibility a capabilities indication would be nice to have. Without this a network with one incapable node could surprisingly fail to work for part of the topology. With it the trees can be built around such a node. Building tunnels could be possible but require that a special type of link be advertised (maybe an MPLS FA would do it). As you stated how to build the tunnels would be out of scope. I really have not yet looked at this closely. Curtis From william.atwood@concordia.ca Tue Jan 21 13:23:58 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2C61A0340 for ; Tue, 21 Jan 2014 13:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.129 X-Spam-Level: X-Spam-Status: No, score=0.129 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.535, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGOGaQjrN6wH for ; Tue, 21 Jan 2014 13:23:55 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7745C1A0356 for ; Tue, 21 Jan 2014 13:23:53 -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 s0LLNqeQ008115 for ; Tue, 21 Jan 2014 16:23:53 -0500 Message-ID: <52DEE56D.3070009@concordia.ca> Date: Tue, 21 Jan 2014 16:23:57 -0500 From: William Atwood Organization: Concordia University, Montreal User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pim@ietf.org References: <6F5149063CE40341BE7953160A93C5A0E0F32D@eusaamb109.ericsson.se> In-Reply-To: <6F5149063CE40341BE7953160A93C5A0E0F32D@eusaamb109.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2014/01/21 16:23:53 EST Subject: Re: [pim] Call for adoption of pim-join-attributes-for-lisp X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 21:23:58 -0000 I vote for adoption by the PIM WG. PIM is the right (indeed, only) place to do normative work on PIM. The draft makes the case for the need, and the solution fits into recent work on Hierarchical Join/Prune attributes. Bill On 21/01/2014 3:33 PM, Mike McBride wrote: > The authors of this draft requested a call for adoption of their draft. > At our last meeting, in Vancouver, 5 people were in favor of adopting > the draft. 3 were against. One of those against shared the opinion of > there being too much existing lisp work needing to be completed within > the lisp wg and this additional work may muddy the water. Those in favor > stated that the lisp wg is supportive of this work being done within pim. > > > > What say you? > > > > http://tools.ietf.org/id/draft-arango-pim-join-attributes-for-lisp-00.txt > > > > thanks, > > mike > > > > _______________________________________________ > 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 ice@cisco.com Fri Jan 24 00:34:15 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BC01A014B for ; Fri, 24 Jan 2014 00:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LjgdYmGq4Jp for ; Fri, 24 Jan 2014 00:34:11 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 00F131A01F4 for ; Fri, 24 Jan 2014 00:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=934; q=dns/txt; s=iport; t=1390552450; x=1391762050; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=9uw2jQqN10evWgjnJG1IQdHypxiNyVkneaVWoIDR7B0=; b=Q5qRPVGeYyTF4rCUi/cUVMy30fucQtexOHMjrXGWoMW84Itilz/zTCXY dovlkKNZSwEB/CR3aSO0EMnY20ec0UiMMaqxLm+4EQ2swIprT1ENcc//2 6ImZFzJfeHRx8Iq+xcYgb5NenzDj6nTS+tl8xfkMi90XlPaDVoapLzFkZ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAPgk4lKQ/khM/2dsb2JhbABagww4vQ6BDRZ0giUBAQEDAQEBARodNAsFCwtGJzAGE4d9CA3HXxeOTTMHgySBFASYJoEykGyDLjs X-IronPort-AV: E=Sophos;i="4.95,711,1384300800"; d="scan'208";a="4115994" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 24 Jan 2014 08:34:08 +0000 Received: from ams-iwijnand-87111.cisco.com (ams-iwijnand-87111.cisco.com [10.55.191.156]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0O8Y78O032099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Jan 2014 08:34:08 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: IJsbrand Wijnands In-Reply-To: <6F5149063CE40341BE7953160A93C5A0E0F32D@eusaamb109.ericsson.se> Date: Fri, 24 Jan 2014 09:34:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <426BAF6B-DAC0-42BC-BBAC-CDD9AEBDC007@cisco.com> References: <6F5149063CE40341BE7953160A93C5A0E0F32D@eusaamb109.ericsson.se> To: Mike McBride X-Mailer: Apple Mail (2.1510) Cc: "pim@ietf.org" Subject: Re: [pim] Call for adoption of pim-join-attributes-for-lisp X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 08:34:15 -0000 Dear WG, I support this draft and I believe these protocol extentions have to be = processed in the PIM WG.=20 Thx, Ice. On 21 Jan 2014, at 21:33, Mike McBride = wrote: > The authors of this draft requested a call for adoption of their = draft. At our last meeting, in Vancouver, 5 people were in favor of = adopting the draft. 3 were against. One of those against shared the = opinion of there being too much existing lisp work needing to be = completed within the lisp wg and this additional work may muddy the = water. Those in favor stated that the lisp wg is supportive of this work = being done within pim. > =20 > What say you? > =20 > = http://tools.ietf.org/id/draft-arango-pim-join-attributes-for-lisp-00.txt > =20 > thanks, > mike > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From adrian@olddog.co.uk Fri Jan 24 02:13:01 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394771A0218 for ; Fri, 24 Jan 2014 02:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.346 X-Spam-Level: * X-Spam-Status: No, score=1.346 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ocgBvuJrVmj for ; Fri, 24 Jan 2014 02:12:59 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6A29C1A018D for ; Fri, 24 Jan 2014 02:12:58 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0OACuhR000467 for ; Fri, 24 Jan 2014 10:12:57 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0OACnNq000308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 24 Jan 2014 10:12:52 GMT From: "Adrian Farrel" To: Date: Fri, 24 Jan 2014 10:12:51 -0000 Message-ID: <12b001cf18ec$da4fe010$8eefa030$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8Y7NPEEhFianCmSAi+Y+2faZNYUA== Content-Language: en-gb X-TM-AS-MML: No Subject: [pim] Question about PIM-DM and RFC 3973 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 10:13:01 -0000 Hi, I have a question... Has anyone an opinion on whether PIM-DM should: - remain Experimental - be archived - be moved onto the Standards Track Thanks, Adrian From eckert@cisco.com Fri Jan 24 02:35:46 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC971A01BA for ; Fri, 24 Jan 2014 02:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDPVEYW6EKMe for ; Fri, 24 Jan 2014 02:35:44 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id DAA871A018D for ; Fri, 24 Jan 2014 02:35:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1546; q=dns/txt; s=iport; t=1390559744; x=1391769344; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=HBo2r6Vk4hzLn1TRhgPWLxL/0GuAs6rBgRnaeYtfEJQ=; b=KbIngmOUZCzrRIzaJx1GxCMBHHnSjWnCOVl8pASo7R+79EVvgxorLF93 3pF3lVw4L3Ws5nhFjsGFogl9GH8U9yzK15huvUDhszvDVvfxjnsgTNWjB XuhAKrH/NRA1/K3b2GEFPP+ZAkhIQ0D04QJrG5NpHtp/hZtFQwM0dgJcZ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAN5A4lKrRDoG/2dsb2JhbABagww4vQ2BDhZ0giUBAQEEAQEBNzQLEAsSBgklDwUTIhQTiAQOx3ATBI8AB4Q4BIlIjl0Bkh6DThs X-IronPort-AV: E=Sophos;i="4.95,712,1384300800"; d="scan'208";a="103806881" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 24 Jan 2014 10:35:43 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0OAZh2Q013684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jan 2014 10:35:43 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s0OAZh8T026548; Fri, 24 Jan 2014 02:35:43 -0800 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s0OAZgdT026547; Fri, 24 Jan 2014 02:35:42 -0800 Date: Fri, 24 Jan 2014 02:35:42 -0800 From: Toerless Eckert To: Adrian Farrel Message-ID: <20140124103542.GV18251@cisco.com> References: <12b001cf18ec$da4fe010$8eefa030$@olddog.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12b001cf18ec$da4fe010$8eefa030$@olddog.co.uk> User-Agent: Mutt/1.4.2.2i Cc: pim@ietf.org Subject: Re: [pim] Question about PIM-DM and RFC 3973 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 10:35:46 -0000 Hmm... Where could i read up on process and practical implications of "archived" ? Haven't tried to understand those yet. Attempts to go standards track are IMHO totall unacceptable without a clearer description of the scope/applicability, eg: where it makes sense and it's limitations. I would hate to see cycles spent on improving PIM-DM without a lot more customers supporting that effort, so i would advise against opening up the PIM-DM spec for revision. If folks feel that they want to invest cycles into PIM-DM, there should be a separate deployment experience draft written plus proposals on how to define forthgoing its applicability, and if we can get that type of draft through as an RFC, then it will also point us to the right future status of the PIM-DM spec itself. Short of either understanding whether archive is an obvious good choice without further work, and short of work to set the applicability straight, i'd just stick with experimental. Cheers Toerless On Fri, Jan 24, 2014 at 10:12:51AM +0000, Adrian Farrel wrote: > Hi, > > I have a question... > > Has anyone an opinion on whether PIM-DM should: > - remain Experimental > - be archived > - be moved onto the Standards Track > > Thanks, > Adrian > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From farinacci@gmail.com Fri Jan 24 09:11:28 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9991A04A7 for ; Fri, 24 Jan 2014 09:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ctZa-fhcr0n for ; Fri, 24 Jan 2014 09:11:27 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E66D61A00C0 for ; Fri, 24 Jan 2014 09:11:26 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id p10so3356470pdj.17 for ; Fri, 24 Jan 2014 09:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+ptZMUR4BXtDPUDaB7DQDm0kixFFOndbcRVR/slTfec=; b=rS7By5UVzpnJVKeB7+e7QA+v7Epy6NJ6tj27kTqj17UHhODp3Qijdwktg2AHvcOA34 bWYJep/kr4otJCufUu4b1ghHMm6bDQmG9lyvlemBLWqN/6GDXe0Zt8yBiJALeo8zGreN yzcvNPbTfMQ011gZy8R9n85R+R4xmc/a2+r6lYO6W0OlqkNc81It6kCBNQs7RZxRYZjW ZCHxopzApcHadkAyBIwyE0ewKroc6tqgWYKzkAXQePp0EQValo6nZtbATZr1ZNMPhe8D lB10cGV4pHUrY4j1smv0R2GJU2mo3qMeDl3UqF2X1qsDbgdGIr4OCwiI7w3iMQmBXf8Q mGtA== X-Received: by 10.66.253.33 with SMTP id zx1mr15570787pac.28.1390583485867; Fri, 24 Jan 2014 09:11:25 -0800 (PST) Received: from [192.168.1.243] ([207.145.253.66]) by mx.google.com with ESMTPSA id sq7sm4835473pbc.19.2014.01.24.09.11.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Jan 2014 09:11:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Dino Farinacci In-Reply-To: <12b001cf18ec$da4fe010$8eefa030$@olddog.co.uk> Date: Fri, 24 Jan 2014 09:11:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <84E541E5-A1C1-4045-B5C5-EA69EAAC5FF7@gmail.com> References: <12b001cf18ec$da4fe010$8eefa030$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1827) Cc: pim@ietf.org Subject: Re: [pim] Question about PIM-DM and RFC 3973 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 17:11:28 -0000 > Has anyone an opinion on whether PIM-DM should: > - remain Experimental Absolutely. > - be archived Need a clear definition, like Toerless said. > - be moved onto the Standards Track Definitely not. There have been some thoughts going around for some time of doing = "stateless" multicast where most of the packet delivery would be to all = interfaces (modulo the one the source can be reached through) in = backbone systems where the trees are dense in that part of the network = where spareness occurs towards the tail of the network topology. Having said that dense-mode or simply non-pruned multicast could have a = come back. Dino From jasghar@cisco.com Fri Jan 24 12:04:52 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40071A007D for ; Fri, 24 Jan 2014 12:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40wk1MYJyPSl for ; Fri, 24 Jan 2014 12:04:49 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9971A001A for ; Fri, 24 Jan 2014 12:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6120; q=dns/txt; s=iport; t=1390593888; x=1391803488; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=vnRoHBn0WQcB14iZXMFc/Tb5J3aaqSCUW8XFdV7takU=; b=PdX5bKtqzjJDeN4qI4pLtvJgNyii/X4QFeFEETyS8MZs27Jzs/hYMqQJ pvMeBRp8O6UCwwIBrlqe5EL1a5rwURdJzJcWvdaPtc/2jgnOMr51msuZk eKCBQLLMXBHw7g/Ub+5IFe2K6QGGo+Gr+uqEd05VKfCwefsH4dQbgZJBh s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAOfG4lKtJXHB/2dsb2JhbABagww4Vrw1gQ0WdIIlAQEBAwEBAQEaHRQgEAcGAQgRAQIBAQEBCgISCSgGCgEUAwYJAQQTCBUEh1ADCQgNnGOmCw2FVheMdoE0EQEfPoMegRQEljuDHosrhUGDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,714,1384300800"; d="scan'208";a="299636459" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 24 Jan 2014 20:04:47 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0OK4lj3009132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 24 Jan 2014 20:04:47 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.10]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Fri, 24 Jan 2014 14:04:47 -0600 From: "Javed Asghar (jasghar)" To: "pim@ietf.org" Thread-Topic: pim-join-attributes-for-lisp adoption Thread-Index: Ac8ZP4bKc7TKq2ANSlKOBEKyvOIEQg== Date: Fri, 24 Jan 2014 20:04:46 +0000 Message-ID: <821A68DD0836474388430A1DAF0A982E01D27712@xmb-aln-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.95.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pim] pim-join-attributes-for-lisp adoption X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:04:52 -0000 I would like to vote to support the adoption of pim-join-attribute-for-lisp= in the PIM WG.=20 -Javed. -----Original Message----- From: pim [mailto:pim-bounces@ietf.org] On Behalf Of pim-request@ietf.org Sent: Friday, January 24, 2014 12:00 PM To: pim@ietf.org Subject: pim Digest, Vol 117, Issue 11 Send pim mailing list submissions to pim@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/pim or, via email, send a message with subject or body 'help' to pim-request@ietf.org You can reach the person managing the list at pim-owner@ietf.org When replying, please edit your Subject line so it is more specific than "R= e: Contents of pim digest..." Today's Topics: 1. Re: Call for adoption of pim-join-attributes-for-lisp (IJsbrand Wijnands) 2. Question about PIM-DM and RFC 3973 (Adrian Farrel) 3. Re: Question about PIM-DM and RFC 3973 (Toerless Eckert) 4. Re: Question about PIM-DM and RFC 3973 (Dino Farinacci) ---------------------------------------------------------------------- Message: 1 Date: Fri, 24 Jan 2014 09:34:09 +0100 From: IJsbrand Wijnands To: Mike McBride Cc: "pim@ietf.org" Subject: Re: [pim] Call for adoption of pim-join-attributes-for-lisp Message-ID: <426BAF6B-DAC0-42BC-BBAC-CDD9AEBDC007@cisco.com> Content-Type: text/plain; charset=3Dus-ascii Dear WG, I support this draft and I believe these protocol extentions have to be pro= cessed in the PIM WG.=20 Thx, Ice. On 21 Jan 2014, at 21:33, Mike McBride wrote: > The authors of this draft requested a call for adoption of their draft. A= t our last meeting, in Vancouver, 5 people were in favor of adopting the dr= aft. 3 were against. One of those against shared the opinion of there being= too much existing lisp work needing to be completed within the lisp wg and= this additional work may muddy the water. Those in favor stated that the l= isp wg is supportive of this work being done within pim. > =20 > What say you? > =20 > http://tools.ietf.org/id/draft-arango-pim-join-attributes-for-lisp-00. > txt > =20 > thanks, > mike > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim ------------------------------ Message: 2 Date: Fri, 24 Jan 2014 10:12:51 -0000 From: "Adrian Farrel" To: Subject: [pim] Question about PIM-DM and RFC 3973 Message-ID: <12b001cf18ec$da4fe010$8eefa030$@olddog.co.uk> Content-Type: text/plain; charset=3D"us-ascii" Hi, I have a question... Has anyone an opinion on whether PIM-DM should: - remain Experimental - be archived - be moved onto the Standards Track Thanks, Adrian ------------------------------ Message: 3 Date: Fri, 24 Jan 2014 02:35:42 -0800 From: Toerless Eckert To: Adrian Farrel Cc: pim@ietf.org Subject: Re: [pim] Question about PIM-DM and RFC 3973 Message-ID: <20140124103542.GV18251@cisco.com> Content-Type: text/plain; charset=3Dus-ascii Hmm... Where could i read up on process and practical implications of "archived" ? Haven't tried to understand those yet. Attempts to go standards track are IMHO totall unacceptable without a clear= er description of the scope/applicability, eg: where it makes sense and it'= s limitations. I would hate to see cycles spent on improving PIM-DM withou= t a lot more customers supporting that effort, so i would advise against op= ening up the PIM-DM spec for revision. If folks feel that they want to invest cycles into PIM-DM, there should be = a separate deployment experience draft written plus proposals on how to def= ine forthgoing its applicability, and if we can get that type of draft thro= ugh as an RFC, then it will also point us to the right future status of the= PIM-DM spec itself. Short of either understanding whether archive is an obvious good choice wit= hout further work, and short of work to set the applicability straight, i'd= just stick with experimental. Cheers Toerless On Fri, Jan 24, 2014 at 10:12:51AM +0000, Adrian Farrel wrote: > Hi, >=20 > I have a question... >=20 > Has anyone an opinion on whether PIM-DM should: > - remain Experimental > - be archived > - be moved onto the Standards Track >=20 > Thanks, > Adrian >=20 > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! ------------------------------ Message: 4 Date: Fri, 24 Jan 2014 09:11:23 -0800 From: Dino Farinacci To: adrian@olddog.co.uk Cc: pim@ietf.org Subject: Re: [pim] Question about PIM-DM and RFC 3973 Message-ID: <84E541E5-A1C1-4045-B5C5-EA69EAAC5FF7@gmail.com> Content-Type: text/plain; charset=3Dus-ascii > Has anyone an opinion on whether PIM-DM should: > - remain Experimental Absolutely. > - be archived Need a clear definition, like Toerless said. > - be moved onto the Standards Track Definitely not. There have been some thoughts going around for some time of doing "stateles= s" multicast where most of the packet delivery would be to all interfaces (= modulo the one the source can be reached through) in backbone systems where= the trees are dense in that part of the network where spareness occurs tow= ards the tail of the network topology. Having said that dense-mode or simply non-pruned multicast could have a com= e back. Dino ------------------------------ Subject: Digest Footer _______________________________________________ pim mailing list pim@ietf.org https://www.ietf.org/mailman/listinfo/pim ------------------------------ End of pim Digest, Vol 117, Issue 11 ************************************ From adrian@olddog.co.uk Sun Jan 26 03:22:52 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0E01A0131 for ; Sun, 26 Jan 2014 03:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ki-T2adDEv72 for ; Sun, 26 Jan 2014 03:22:50 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 064641A0132 for ; Sun, 26 Jan 2014 03:22:49 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0QBMjnO005270; Sun, 26 Jan 2014 11:22:45 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0QBMg3O005246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 26 Jan 2014 11:22:44 GMT From: "Adrian Farrel" To: Date: Sun, 26 Jan 2014 11:22:41 -0000 Message-ID: <008e01cf1a88$eefd3600$ccf7a200$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8aiOvK/D8w00SnR1OetJBvLk4u7Q== Content-Language: en-gb X-TM-AS-MML: No Cc: pim@ietf.org Subject: [pim] AD review of draft-ietf-pim-explicit-rpf-vector X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 11:22:52 -0000 Hi, I have done my usual AD review of this document after receiving the publication request. The purpose of the review is to catch and fix any issues that might otherwise show up in IETF last call or IESG review. This helps smooth the passage of the document later and also increases the quality text. This seems like a good and simple proposal, and I don't want to bog it down. But there are a number of small editorial issues and a couple of technical questions included below. I have put the document into "Revised I-D Needed" state and will wait to see an updated version before I start the IETF last call. But please feel free to debate any of these points with me. Thanks for the work. Adrian --- You need to fix the idnits before I can put this to IETF last call. - Missing page breaks - 2119 boilerplate broken (you have "SHALL" "NOT") - there is a line too long - missing reference for [draft-mofrr-karan] [Shepherd - Your write-up says no nits found. How come?] --- Conventionally we have used the term "strict" in counterpoint to "loose" to describe hops, and termed the whole path "explicit". I don't suppose this matters: you are defining your own terms for a new application in PIM. However, this has led to some confusion in the text because of the normal use of the English word "explicit". For example, the Abstract says: This document defines a new Reverse Path Forwarding (RPF) Vector TLV to build multicast trees via an explicit path sent in the PIM join. ...which doesn't give any clue to the distinction between this work and RFC 5496. You might be better with something like: The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496 can be included in a PIM Join Attribute to allow a leaf to apply controls to the path of a multicast tree. This document defines a new Vector Attribute type so that an RPF Vector TLV can be used to indicate that the unicast address indicated in the TLV must be used as the next hop in the multicast tree. This kind of language could usefully be repeated throughout the document. --- Section 1 For some applications, it might be useful to have a way to specify the explicit path along which the PIM join is propagated. Could you possibly be a little less vague? :-) If this is the level of certainty you have for the utility of your work then it shouldn't be on the Standards Track. Fortunately, you *do* have a good use case later in the document. I suggest re-ordering paragraphs: 3, 4, 2 ...and delete paragraph 1. --- Suggest to rename Section 3 "Motivation" --- Section 3 As noted above, you need to provide the reference for [draft-mofrr-karan]. But actually, I wonder whether you really need to include the citation as the text in the paragraph seems to hold up well without any further explanation. --- Section 3 It might be useful to have a way to specify the explicit path along which the PIM join is propagated. I think you established that it *is* useful in the previous text. --- Section 3 How the Explicit RPF Vector list is determined is outside the scope of this document. It may either be manually configured by the network operator or procedures may be implemented on the egress router to dynamically calculate the vector list based on a link state database protocol, like OSPF or IS-IS. I agree that this should be out of scope and you should say so. However, having said it is out of scope, why do you go on to discuss it? --- You should give more clarity as to why an RPF list using 5496 list entries would not be good enough. In Figure 1 it would appear that the list {R4, R3, R6, R5, R2, R1} would work just fine using 5496. --- Section 5 This draft uses PIM join attribute type 4 for specifying an Explicit RPF Vector. Please make this: This draft uses PIM join attribute type TBD by IANA for specifying an Explicit RPF Vector. --- Section 7 is describing, for example, simple network with source S and leafs R1 and R2... A R1 / \ / S C \ / \ B R2 ...where R1 sends explicit RPF TLVs {C, A} and that path is set up. Then R2 sends explicit RPF TLVs {C, B}. Section 3.3.3 of RFC 5384 is cited as the tie-breaker. This is OK, but it appears to say that the Explicit RPF is not mandatory. It would be nice to make it very clear that a receiver has no expectations that the explicit RPF list it supplies will actually be used. --- Section 10 This is important material to include, but I think it needs some work. The F bit MUST be set to 0 by a downstream router in the join that is sent to the upstream router that does not support Explicit RPF vector. But the downstream router doesn't know whether the upstream router supports the new vector or not! So I think you need... The F bit MUST be set to 0 in all Explicit RPF vectors in case the upstream router receiving the join does not support the TLV. As described in section 3.3.2 of [RFC5384], routers that do not understand the type of a particular attribute that has the F bit clear will discard it and continue to process the join. This processing is particularly important when the routers that do not support the Explicit RPF TLV are identified as hops in the explicit RPF list, because failing to remove the RPF vectors could cause upstream routers to send the join back toward these routers causing loops. However, this doesn't seem to be the only way that loops can be caused (referring back to section 9). I don't see this mentioned in RFC 5496 either, but surely: - the RPF list could contain an explicit loop - the use of loose hops with poorly ordered list entries could create a loop It is fine to note that this is caught by normal PIM processing, but you should say so, and you should say what happens to the join. It seems to me that 3.3.4 of 5496 only catches the case where join is targeting the same upstream neighbor. But the sequential list nature of the RPF list means that the loop might not be "endless" but could still be a loop. How is this caught and handled? --- Section 11 Please replace... OLD Type ---- The Vector Attribute type is 4. NEW Type ---- The Vector Attribute type is TBD by IANA. END --- Section 13 seems light! The RPF list (and especially the explicit RPF) provides a way to cause traffic to take different routes through the network. This could be used to cause traffic to take expensive paths, to be routed through hot parts of the network, or to be directed to snooping nodes. This means that the existence of the RPF TLV makes the use of security in PIM more important to prevent tampering with the RPF list. But it also raises a question of policy and authorization. Clearly, when a receiver seeks to join a multicast tree, it must be authenticated for that join. But additionally, you may want to note that the inclusion of an RPF list by a receiver should be subject to policy. From adrian@olddog.co.uk Tue Jan 28 11:36:46 2014 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B6C1A037F for ; Tue, 28 Jan 2014 11:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.217 X-Spam-Level: X-Spam-Status: No, score=0.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9S606shWo1hE for ; Tue, 28 Jan 2014 11:36:45 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4271A037C for ; Tue, 28 Jan 2014 11:36:45 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0SJaekL018834; Tue, 28 Jan 2014 19:36:41 GMT Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0SJaYCE018808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Jan 2014 19:36:36 GMT From: "Adrian Farrel" To: "'Dino Farinacci'" References: <12b001cf18ec$da4fe010$8eefa030$@olddog.co.uk> <84E541E5-A1C1-4045-B5C5-EA69EAAC5FF7@gmail.com> In-Reply-To: <84E541E5-A1C1-4045-B5C5-EA69EAAC5FF7@gmail.com> Date: Tue, 28 Jan 2014 19:36:33 -0000 Message-ID: <048b01cf1c60$43658ac0$ca30a040$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFEKjT9XsE5BBu+eHiTHH85qMNxMwKTmr92m5vOnWA= Content-Language: en-gb X-TM-AS-MML: No Cc: pim@ietf.org Subject: Re: [pim] Question about PIM-DM and RFC 3973 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 19:36:46 -0000 Thanks Dino and Toerless, My question is answered. Adrian > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: 24 January 2014 17:11 > To: adrian@olddog.co.uk > Cc: pim@ietf.org > Subject: Re: [pim] Question about PIM-DM and RFC 3973 > > > > Has anyone an opinion on whether PIM-DM should: > > - remain Experimental > > Absolutely. > > > - be archived > > Need a clear definition, like Toerless said. > > > - be moved onto the Standards Track > > Definitely not. > > There have been some thoughts going around for some time of doing "stateless" > multicast where most of the packet delivery would be to all interfaces (modulo > the one the source can be reached through) in backbone systems where the > trees are dense in that part of the network where spareness occurs towards the > tail of the network topology. > > Having said that dense-mode or simply non-pruned multicast could have a come > back. > > Dino