From mmcbride@cisco.com Mon Apr 4 12:52:01 2011 Return-Path: X-Original-To: pim@core3.amsl.com Delivered-To: pim@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4203A67A3 for ; Mon, 4 Apr 2011 12:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNmnfYZuSsys for ; Mon, 4 Apr 2011 12:51:58 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7B97A3A67B7 for ; Mon, 4 Apr 2011 12:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mmcbride@cisco.com; l=4710; q=dns/txt; s=iport; t=1301946821; x=1303156421; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=mbWuOdjOLHsJbhNtWfZvgxR8gmFBjxikuyQV4N4xBYA=; b=XvJnUUR4ogRHrRg6CahhFOghg6uyNg/l6y2pyKhqnMacuJsrNZOUwlxR DSn59ScYl3K4JlVX0LemhNQA415/qgmGHAEHc1sSNH9lpj8e0XXLYEa0/ lzrycyH3u+vhiIiFyeaqFInxM3QAXgZbbbOqzcg5eXnzO2tGTdQRUhyXC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAEhmk2rRDoJ/2dsb2JhbAClZHemM5wPgn2CbgSFR4s9 X-IronPort-AV: E=Sophos;i="4.63,299,1299456000"; d="scan'208";a="289095006" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 04 Apr 2011 19:53:41 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p34JrfFR021314 for ; Mon, 4 Apr 2011 19:53:41 GMT Received: from xmb-sjc-219.amer.cisco.com ([171.70.151.188]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Apr 2011 12:53:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Apr 2011 12:53:44 -0700 Message-ID: <47951CBFA6409B4C8916514FCB05BFBE0C51BCB9@xmb-sjc-219.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Prague wg meeting minutes thread-index: AcvtJwVzb032/bw4Q4W6j2FCHakqwQDd85FgAJiYjAA= From: "Mike McBride (mmcbride)" To: X-OriginalArrivalTime: 04 Apr 2011 19:53:41.0027 (UTC) FILETIME=[FF14EF30:01CBF301] Subject: [pim] Prague wg meeting minutes X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:52:01 -0000 Please review and offer corrections/additions where necessary before we post. Thanks to Greg Shepherd for the notes: PIM WG Minutes Prague, March 28th, 2011 Mike McBride Recharter Proposals -errata: "There is a significant number of errata that need to be addressed in order to advance RFC4601 to Draft Standard. The PIM WG will correct the errata, as necessary, and then update RFC4601." -igmp: "The working group primarily works on extensions to PIM, but may take on work related to IGMP/MLD." -No opposition in the room. Alias is next. Jeffrey Zhang 4601 Revision Address about 100 open errata -Three volunteers from cisco/huawei/juniper -00 draft in 2-3 weeks with all verified errata corrected -identify optional features that do not meet 2026 req's. -*,*,RP -explicit tracking -group to rp mappings (refer to pim-group-rp-mapping) -01 draft with optional features removed before July ietf -feedback please Stig Venaas pim-port-06 update Good feedback on the list after wglc#2 Many minor editorial issues fixed Changed format of port j/p message Added keepalive message Made interface ID a standalone pim hello option Is the draft ready for another last call? - yes Gorry Fairhurst getting back on keep alive. Do we need so many options? What's the motivation for so many options vs a few simple ones. Stig Hold time is needed... if there, why not other places. Flexibility is beneficial. Stig pim-hello-intid-00 if we take this out of PORT then PORT relies on this - both need same standards track ..covered other draft bits (see press) vote to room for adoption - 5 for, 0 against Gorry type field exchanging... can't have different levels of uniqueness Stig The way the draft is written now, can be zero if you don't care. Stig magma-msnip-06 History of draft.. started in MAGMA which closed down. Picked up last version and resubmitted to see if there is interest here. ASM support added to the draft Other draft bits presented (see preso/draft) Lenny Giuliano Lack of interest 10 years ago.. What's new? Stig There was interest in limiting traffic on first hop L2. Other proposals have come to address some of this Lenny If it didn't progress 10 years ago, just as little interest now. Mike Stig resurrected this in response to another proposal at the last WG meeting Thomas Schmidt Interest in the mobility area - pre-work to multimob Work in the IRTF to address overlay multicast - a common host API Hitoshi Asaeda We must take care when we proposed to changed the host stack. Stig=09 Is it worth working on or should we let it die? Shep I'd prefer to see this work focus on addressing real needs ie - mobility Thomas Could we let it progress then add use cases? Mike Who thinks msnip is work the group should take on? - 0 hands. Stig Who feels it still is interesting work? - 11 hands Gorry Two questions? Are we interested in source discovery, and are we interested in MSNIP? Hitoshi Explicit-tracking-02 Covering draft bits.. (see presentation) Mike What's the history of this draft? Why was it not adopted in the past? Lenny It didn't get far enough.. Mike Isn't explicit tracking covered in the IGMPv3/MLDv2 drafts? Hitoshi Yes, but it doesn't explain how. Shep would this be informational? Lenny Lots of interest in the WG a few meetings back Stig Protocol drafts don't detail how-to, so this work could clarify Pending charter changes, should we adopt this work? Gorry How will this document affect existing ET implementations? Mike Let's sort out the charter then we'll come back to evaluate this work. We should get some vendor involvement. Ice Wijnands hou-pim-ecmp - Presenting on the authors' behalf Covered draft bits (see press) Lenny How is this different than current PIM assert? Ice This is not data driven, and more deterministic. Lenny Assert has been a problem on peering LANs. It's always been a challenge. Many would consider assert to be broken - is this introducing the same mechanisms over multiple ifcs and making the problem worse? Ice No, this is addressing many of those issues as well. Perhaps we shouldn't call it "asserts". Sven Two comments - agreement that this is an uncommon topology the behavior you're trying to correct we are actually intentionally implementing. Ice This was proposed to address a customers need Sven I'm happy to work with you on this offline Mike Adoption 0 for, 0 against.. 0 participation in the room I guess.=20 taking it to the list Are the use cases in the draft? Ice Not explicitly at the moment. Wrap From stig@venaas.com Wed Apr 6 13:08:51 2011 Return-Path: X-Original-To: pim@core3.amsl.com Delivered-To: pim@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39BA3A6986 for ; Wed, 6 Apr 2011 13:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.881 X-Spam-Level: X-Spam-Status: No, score=-101.881 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, MISSING_HEADERS=1.292, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqzLUAuuKiVs for ; Wed, 6 Apr 2011 13:08:51 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id CD8BE3A67DA for ; Wed, 6 Apr 2011 13:08:50 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:889a:ddcc:4e4d:851e] (unknown [IPv6:2001:420:4:ea0c:889a:ddcc:4e4d:851e]) by ufisa.uninett.no (Postfix) with ESMTPSA id A3C6C8010 for ; Wed, 6 Apr 2011 22:10:32 +0200 (CEST) Message-ID: <4D9CC8B4.2020107@venaas.com> Date: Wed, 06 Apr 2011 13:10:28 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 CC: pim@ietf.org References: <4D91D22A.1030701@abdn.ac.uk> In-Reply-To: <4D91D22A.1030701@abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pim] Comments on draft-gulrajani-pim-hello-intid-00.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 20:08:51 -0000 On 3/29/2011 5:35 AM, G. Fairhurst wrote: > > i promised to read this and comment on the list. Thanks, I've made some changes now. I'll submit it shortly as 01 unless you have any further comments. > > This looks like a useful thing to publish as a PS. > > I have a few comments: > > S 2.2 > " it needs to be > unique depends on the protocol utilizing it." > - wording, is this better: > "The requirements for the scope in which it needs to be unique depend o > the protocol that utilises this." > - Actually this is the one point that I do not yet see. It seems that > without a default level of scope, there is no clear way that different > protocols can reliably use the same mechanism. Is it possible just to > say that the router should use an IPv4 unicast address assigned to the > router by default (preferably a public address if one is defined). There > is no problem allowing an operator to reassign the value, and it then > becomes a matter of correct implementation. I did some changes, but kept most of the old text. It now says: The 32 bit Router Identifier may be used to uniquely identify the router. It may be selected to be unique within some administrative domain, or possibly globally unique. The requirements for the scope in which it needs to be unique depend on the protocol that utilizes this. A router implementation MAY choose an IPv4 unicast address assigned to the router as the Router Identifer, but MUST allow the identifier to be configured manually. Protocols like BGP [RFC4271] and OSPFv2 [RFC2328] are other protocols making use of 32 bit identifiers for routers. One may use the same identifier to construct the Interface Identifier option, provided it meets the stability and uniqueness requirements of protocols making use of this option. > S 2.2 > "Routers often have such > an identifier derived from an IPv4 address or manual configuration." > - but if you want it to be useful to multiple protocols then it may need > more care. > > Security Considerations > > - The vulnerabilities discussed appear to be the same as for other PIM > usage. These relate to on-link attacks that spoof a Hello message. An > attacker able to do could also be able to manipulate other params to > disrupt operation of a PIM router. Are you suggesting removing most of it and just have kind of the standard PIM blanket statement? > > References: > "[I-D.ietf-pim-port]" > > - This doesn't need to be a normative reference to this draft to me, > although PORT needs to normatively cite this. Yes, not sure how it ended up as a reference, removed. Thanks, Stig > > Gorry From thomas.morin@orange-ftgroup.com Thu Apr 7 03:03:55 2011 Return-Path: X-Original-To: pim@core3.amsl.com Delivered-To: pim@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6623A69BE for ; Thu, 7 Apr 2011 03:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2leMSo8pjpQ for ; Thu, 7 Apr 2011 03:03:55 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id DFEDF3A68F7 for ; Thu, 7 Apr 2011 03:03:54 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A0D448C0010; Thu, 7 Apr 2011 12:06:10 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 970288B8001; Thu, 7 Apr 2011 12:06:10 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 12:05:38 +0200 Received: from [10.193.71.150] ([10.193.71.150]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 12:05:37 +0200 Message-ID: <4D9D8C71.2050000@orange-ftgroup.com> Date: Thu, 07 Apr 2011 12:05:37 +0200 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; ; ; ) Gecko/2010 Thunderbird/3.1.x MIME-Version: 1.0 To: pim@ietf.org, Greg Shepherd , dino@cisco.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Apr 2011 10:05:37.0317 (UTC) FILETIME=[57974D50:01CBF50B] Subject: [pim] PIM Pop Count - Allow more than 16 options ? X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 10:03:55 -0000 Hi working group, Greg, Dino, Wouldn't it be a good idea to arrange for the possibility of having more than 16 options? A possibility would be to give a special role to the last bit of the option bitmap: if set, it would mean that the next two bytes after the option bitmap would also carry an option bitmap (a second one for 15 additional options), and the first option would start after this second option bitmap. And if the last bit of this second bitmap was set, then there would be yet another option bitmap... Another possibility would be a TLV encoding for all the options... Comments ? -Thomas PS: by the way, "options" here is not a great name, what about "fields" or "metrics"...? From zzhang@juniper.net Thu Apr 7 03:26:19 2011 Return-Path: X-Original-To: pim@core3.amsl.com Delivered-To: pim@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA73428C0F9 for ; Thu, 7 Apr 2011 03:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLt44OwBPTwG for ; Thu, 7 Apr 2011 03:26:19 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id A9FA028C0F8 for ; Thu, 7 Apr 2011 03:26:18 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ2Rr6Q3CnMy4rw1ylGpeS+EXNW6ccQm@postini.com; Thu, 07 Apr 2011 03:28:03 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Apr 2011 03:23:18 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 7 Apr 2011 06:25:02 -0400 From: "Jeffrey (Zhaohui) Zhang" To: Thomas Morin , "pim@ietf.org" , Greg Shepherd , "dino@cisco.com" Date: Thu, 7 Apr 2011 06:25:11 -0400 Thread-Topic: [pim] PIM Pop Count - Allow more than 16 options ? Thread-Index: Acv1C1xDfpMokQ9SSDiGC9Jq9SKM4QAARZOA Message-ID: <13205C286662DE4387D9AF3AC30EF456D340B41ECD@EMBX01-WF.jnpr.net> References: <4D9D8C71.2050000@orange-ftgroup.com> In-Reply-To: <4D9D8C71.2050000@orange-ftgroup.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pim] PIM Pop Count - Allow more than 16 options ? X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 10:26:19 -0000 It might be easier to find the start of the first option if we have a lengt= h field to indicate how large the bitmap is, instead of relying on the last= bit of each extension of the bit map? That length field could be the first option itself. Jeffrey > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On=20 > Behalf Of Thomas Morin > Sent: Thursday, April 07, 2011 11:06 AM > To: pim@ietf.org; Greg Shepherd; dino@cisco.com > Subject: [pim] PIM Pop Count - Allow more than 16 options ? >=20 > Hi working group, Greg, Dino, >=20 > Wouldn't it be a good idea to arrange for the possibility of=20 > having more=20 > than 16 options? >=20 > A possibility would be to give a special role to the last bit of the=20 > option bitmap: if set, it would mean that the next two bytes=20 > after the=20 > option bitmap would also carry an option bitmap (a second one for 15=20 > additional options), and the first option would start after=20 > this second=20 > option bitmap. And if the last bit of this second bitmap was=20 > set, then=20 > there would be yet another option bitmap... >=20 > Another possibility would be a TLV encoding for all the options... >=20 > Comments ? >=20 > -Thomas >=20 > PS: by the way, "options" here is not a great name, what=20 > about "fields"=20 > or "metrics"...? > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > = From zzhang@juniper.net Thu Apr 7 05:29:48 2011 Return-Path: X-Original-To: pim@core3.amsl.com Delivered-To: pim@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BCBD3A690C for ; Thu, 7 Apr 2011 05:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlK1BoQ826fF for ; Thu, 7 Apr 2011 05:29:47 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id AD9D628C0FB for ; Thu, 7 Apr 2011 05:29:46 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ2uoJq6F8BlSPhSQkJ1SliaWAgVi0Ls@postini.com; Thu, 07 Apr 2011 05:31:31 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Apr 2011 05:28:59 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 7 Apr 2011 08:30:41 -0400 From: "Jeffrey (Zhaohui) Zhang" To: Thomas Morin , "pim@ietf.org" , Greg Shepherd , "dino@cisco.com" Date: Thu, 7 Apr 2011 08:30:44 -0400 Thread-Topic: [pim] PIM Pop Count - Allow more than 16 options ? Thread-Index: Acv1C1xDfpMokQ9SSDiGC9Jq9SKM4QAARZOAAAGfniA= Message-ID: <13205C286662DE4387D9AF3AC30EF456D340B41F27@EMBX01-WF.jnpr.net> References: <4D9D8C71.2050000@orange-ftgroup.com> <13205C286662DE4387D9AF3AC30EF456D340B41ECD@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D340B41ECD@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pim] PIM Pop Count - Allow more than 16 options ? X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 12:29:48 -0000 > That length field could be the first option itself. To clarify, I meant the length/size of the extended bitmap (that is separat= ed from the standard one), and it shoud come after (vs. before) all the st= andard options. And for that reason, it might be better for it to be the la= st standard option. Jeffrey > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On=20 > Behalf Of Jeffrey (Zhaohui) Zhang > Sent: Thursday, April 07, 2011 11:25 AM > To: Thomas Morin; pim@ietf.org; Greg Shepherd; dino@cisco.com > Subject: Re: [pim] PIM Pop Count - Allow more than 16 options ? >=20 > It might be easier to find the start of the first option if=20 > we have a length field to indicate how large the bitmap is,=20 > instead of relying on the last bit of each extension of the bit map? >=20 > That length field could be the first option itself. >=20 > Jeffrey >=20 > > -----Original Message----- > > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On=20 > > Behalf Of Thomas Morin > > Sent: Thursday, April 07, 2011 11:06 AM > > To: pim@ietf.org; Greg Shepherd; dino@cisco.com > > Subject: [pim] PIM Pop Count - Allow more than 16 options ? > >=20 > > Hi working group, Greg, Dino, > >=20 > > Wouldn't it be a good idea to arrange for the possibility of=20 > > having more=20 > > than 16 options? > >=20 > > A possibility would be to give a special role to the last=20 > bit of the=20 > > option bitmap: if set, it would mean that the next two bytes=20 > > after the=20 > > option bitmap would also carry an option bitmap (a second=20 > one for 15=20 > > additional options), and the first option would start after=20 > > this second=20 > > option bitmap. And if the last bit of this second bitmap was=20 > > set, then=20 > > there would be yet another option bitmap... > >=20 > > Another possibility would be a TLV encoding for all the options... > >=20 > > Comments ? > >=20 > > -Thomas > >=20 > > PS: by the way, "options" here is not a great name, what=20 > > about "fields"=20 > > or "metrics"...? > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www.ietf.org/mailman/listinfo/pim > >=20 > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > = From gorry@erg.abdn.ac.uk Thu Apr 7 00:28:13 2011 Return-Path: X-Original-To: pim@core3.amsl.com Delivered-To: pim@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 186883A6814 for ; Thu, 7 Apr 2011 00:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46UURSmltbK3 for ; Thu, 7 Apr 2011 00:28:11 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 530AF3A67F3 for ; Thu, 7 Apr 2011 00:28:09 -0700 (PDT) Received: from ra-gorry.erg.abdn.ac.uk (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p377Tj9h010591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Apr 2011 08:29:46 +0100 (BST) Message-ID: <4D9D67E9.4040009@erg.abdn.ac.uk> Date: Thu, 07 Apr 2011 08:29:45 +0100 From: Gorry Fairhurst User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Stig Venaas References: <4D91D22A.1030701@abdn.ac.uk> <4D9CC7D2.2090501@cisco.com> In-Reply-To: <4D9CC7D2.2090501@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Mailman-Approved-At: Thu, 07 Apr 2011 09:54:46 -0700 Cc: stig@cisco.com, "G. Fairhurst" , pim@ietf.org, sameerg@cisco.com Subject: Re: [pim] Comments on draft-gulrajani-pim-hello-intid-00.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 07:28:13 -0000 A few comments in line. On 06/04/2011 21:06, Stig Venaas wrote: > On 3/29/2011 5:35 AM, G. Fairhurst wrote: >> >> i promised to read this and comment on the list. > > Thanks, I've made some changes now. I'll submit it > shortly as 01 unless you have any further comments. > >> This looks like a useful thing to publish as a PS. >> >> I have a few comments: >> >> S 2.2 >> " it needs to be >> unique depends on the protocol utilizing it." >> - wording, is this better: >> "The requirements for the scope in which it needs to be unique depend o >> the protocol that utilises this." >> - Actually this is the one point that I do not yet see. It seems that >> without a default level of scope, there is no clear way that different >> protocols can reliably use the same mechanism. Is it possible just to >> say that the router should use an IPv4 unicast address assigned to the >> router by default (preferably a public address if one is defined). There >> is no problem allowing an operator to reassign the value, and it then >> becomes a matter of correct implementation. > > I did some changes, but kept most of the old text. It now says: > > The 32 bit Router Identifier may be used to uniquely identify > the router. It may be selected to be unique within some > administrative domain, or possibly globally unique. The > requirements for the scope in which it needs to be unique > depend on the protocol that utilizes this. A router > implementation MAY choose an IPv4 unicast address assigned > to the router as the Router Identifer, but MUST allow the > identifier to be configured manually. Protocols like BGP > [RFC4271] and OSPFv2 [RFC2328] are other protocols making > use of 32 bit identifiers for routers. One may use the same > identifier to construct the Interface Identifier option, > provided it meets the stability and uniqueness requirements > of protocols making use of this option. > Works for me. >> S 2.2 >> "Routers often have such >> an identifier derived from an IPv4 address or manual configuration." >> - but if you want it to be useful to multiple protocols then it may need >> more care. >> >> Security Considerations >> >> - The vulnerabilities discussed appear to be the same as for other PIM >> usage. These relate to on-link attacks that spoof a Hello message. An >> attacker able to do could also be able to manipulate other params to >> disrupt operation of a PIM router. > > Are you suggesting removing most of it and just have kind of the > standard PIM blanket statement? > I'm suggesting that you start by stating the vulnerability is the same as for other PIM protocol. These protocols are vulnerable to an on-link attack, etc. - you can then be as specific as you like. - my hope was this this effectively declares the group has thought and there are no important issues that need to be discussed. >> References: >> "[I-D.ietf-pim-port]" >> >> - This doesn't need to be a normative reference to this draft to me, >> although PORT needs to normatively cite this. > > Yes, not sure how it ended up as a reference, removed. > It may be OK as an INFORMATIVE reference to an example of use. > Stig > >> Gorry > > From stig@venaas.com Thu Apr 7 10:01:00 2011 Return-Path: X-Original-To: pim@core3.amsl.com Delivered-To: pim@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD503A6819 for ; Thu, 7 Apr 2011 10:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXRt+TrMXqJu for ; Thu, 7 Apr 2011 10:00:59 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 037483A67CF for ; Thu, 7 Apr 2011 10:00:59 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:59eb:abc:e659:1db7] (unknown [IPv6:2001:420:4:ea0c:59eb:abc:e659:1db7]) by ufisa.uninett.no (Postfix) with ESMTPSA id 97A2B7FE8; Thu, 7 Apr 2011 19:02:42 +0200 (CEST) Message-ID: <4D9DEE30.5090405@venaas.com> Date: Thu, 07 Apr 2011 10:02:40 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: pim@ietf.org, Thomas Morin References: <4D9D8C71.2050000@orange-ftgroup.com> In-Reply-To: <4D9D8C71.2050000@orange-ftgroup.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pim] PIM Pop Count - Allow more than 16 options ? X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 17:01:00 -0000 Hi Thomas On 4/7/2011 3:05 AM, Thomas Morin wrote: > Hi working group, Greg, Dino, > > Wouldn't it be a good idea to arrange for the possibility of having more > than 16 options? > > A possibility would be to give a special role to the last bit of the > option bitmap: if set, it would mean that the next two bytes after the > option bitmap would also carry an option bitmap (a second one for 15 > additional options), and the first option would start after this second > option bitmap. And if the last bit of this second bitmap was set, then > there would be yet another option bitmap... I have thought of this, and I think my idea is similar to yours. If we start running out, we define the last option (option 16) to be a bitmap option. At that time, we can define how big we want it, e.g. 2 bytes. Those 2 bytes would then be a bitmap showing which options follow. Following the current rules, that bitmap would then come after the currently known options in the packet. If we again run out, the last option in that bitmap can be a new bitmap option as well. But I don't think we should worry about this in the current draft. As long as we know we have a way to do it. Does this sound reasonable? > > Another possibility would be a TLV encoding for all the options... It would require a lot more space, making the J/P messages a lot bigger. Stig > Comments ? > > -Thomas > > PS: by the way, "options" here is not a great name, what about "fields" > or "metrics"...? > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From stig@venaas.com Thu Apr 7 10:23:57 2011 Return-Path: X-Original-To: pim@core3.amsl.com Delivered-To: pim@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3727E3A6954 for ; Thu, 7 Apr 2011 10:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPNG2Tje1Hua for ; Thu, 7 Apr 2011 10:23:56 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 90ACF3A694F for ; Thu, 7 Apr 2011 10:23:55 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:59eb:abc:e659:1db7] (unknown [IPv6:2001:420:4:ea0c:59eb:abc:e659:1db7]) by ufisa.uninett.no (Postfix) with ESMTPSA id 02F0D7FE7; Thu, 7 Apr 2011 19:25:36 +0200 (CEST) Message-ID: <4D9DF38B.6010600@venaas.com> Date: Thu, 07 Apr 2011 10:25:31 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Gorry Fairhurst References: <4D91D22A.1030701@abdn.ac.uk> <4D9CC7D2.2090501@cisco.com> <4D9D67E9.4040009@erg.abdn.ac.uk> In-Reply-To: <4D9D67E9.4040009@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "G. Fairhurst" , pim@ietf.org, sameerg Subject: Re: [pim] Comments on draft-gulrajani-pim-hello-intid-00.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 17:23:57 -0000 Thanks, see below. On 4/7/2011 12:29 AM, Gorry Fairhurst wrote: > A few comments in line. > > On 06/04/2011 21:06, Stig Venaas wrote: >> On 3/29/2011 5:35 AM, G. Fairhurst wrote: >>> >>> i promised to read this and comment on the list. >> >> Thanks, I've made some changes now. I'll submit it >> shortly as 01 unless you have any further comments. >> >>> This looks like a useful thing to publish as a PS. >>> >>> I have a few comments: >>> >>> S 2.2 >>> " it needs to be >>> unique depends on the protocol utilizing it." >>> - wording, is this better: >>> "The requirements for the scope in which it needs to be unique depend o >>> the protocol that utilises this." >>> - Actually this is the one point that I do not yet see. It seems that >>> without a default level of scope, there is no clear way that different >>> protocols can reliably use the same mechanism. Is it possible just to >>> say that the router should use an IPv4 unicast address assigned to the >>> router by default (preferably a public address if one is defined). There >>> is no problem allowing an operator to reassign the value, and it then >>> becomes a matter of correct implementation. >> >> I did some changes, but kept most of the old text. It now says: >> >> The 32 bit Router Identifier may be used to uniquely identify >> the router. It may be selected to be unique within some >> administrative domain, or possibly globally unique. The >> requirements for the scope in which it needs to be unique >> depend on the protocol that utilizes this. A router >> implementation MAY choose an IPv4 unicast address assigned >> to the router as the Router Identifer, but MUST allow the >> identifier to be configured manually. Protocols like BGP >> [RFC4271] and OSPFv2 [RFC2328] are other protocols making >> use of 32 bit identifiers for routers. One may use the same >> identifier to construct the Interface Identifier option, >> provided it meets the stability and uniqueness requirements >> of protocols making use of this option. >> > Works for me. > >>> S 2.2 >>> "Routers often have such >>> an identifier derived from an IPv4 address or manual configuration." >>> - but if you want it to be useful to multiple protocols then it may need >>> more care. >>> >>> Security Considerations >>> >>> - The vulnerabilities discussed appear to be the same as for other PIM >>> usage. These relate to on-link attacks that spoof a Hello message. An >>> attacker able to do could also be able to manipulate other params to >>> disrupt operation of a PIM router. >> >> Are you suggesting removing most of it and just have kind of the >> standard PIM blanket statement? >> > I'm suggesting that you start by stating the vulnerability is the same > as for other PIM protocol. These protocols are vulnerable to an on-link > attack, etc. The old text did this to some extent. I now changed to: The Interface Identifier is included in PIM Hello Messages. See [RFC4601] for security considerations regarding PIM Hello Messages. In particular, PIM Hello messages may be forged, and may include an arbitrary Interface Identifier, or it may be intentionally omitted. The effects of this depend on how the Interface Identifier is used by other protocols. > - you can then be as specific as you like. > - my hope was this this effectively declares the group has thought and > there are no important issues that need to be discussed. > >>> References: >>> "[I-D.ietf-pim-port]" >>> >>> - This doesn't need to be a normative reference to this draft to me, >>> although PORT needs to normatively cite this. >> >> Yes, not sure how it ended up as a reference, removed. >> > It may be OK as an INFORMATIVE reference to an example of use. You're right of course. I still had the example. Made it informative :) Stig >> Stig >> >>> Gorry >> >> > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From stig@venaas.com Thu Apr 7 12:04:03 2011 Return-Path: X-Original-To: pim@core3.amsl.com Delivered-To: pim@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E638528C0FD for ; Thu, 7 Apr 2011 12:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3We+OsjogOxF for ; Thu, 7 Apr 2011 12:04:03 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id AB4D228C0E5 for ; Thu, 7 Apr 2011 12:03:58 -0700 (PDT) Received: from [10.32.47.198] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id D4C177FE8; Thu, 7 Apr 2011 21:05:41 +0200 (CEST) Message-ID: <4D9E0B03.5000805@venaas.com> Date: Thu, 07 Apr 2011 12:05:39 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Gorry Fairhurst References: <4D91D22A.1030701@abdn.ac.uk> <4D9CC7D2.2090501@cisco.com> <4D9D67E9.4040009@erg.abdn.ac.uk> <4D9DF38B.6010600@venaas.com> <4D9E064C.1020901@erg.abdn.ac.uk> In-Reply-To: <4D9E064C.1020901@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "G. Fairhurst" , pim@ietf.org, sameerg Subject: Re: [pim] Comments on draft-gulrajani-pim-hello-intid-00.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 19:04:04 -0000 On 4/7/2011 11:45 AM, Gorry Fairhurst wrote: > Looks good Stig! Thanks, I've now submitted version 01 based on your comments, and the comments from the pim wg meeting. I hope this version can be considered for adoption by the wg then. Stig > Gorry From thomas.morin@orange-ftgroup.com Fri Apr 8 00:32:53 2011 Return-Path: X-Original-To: pim@core3.amsl.com Delivered-To: pim@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D92EA3A69F3 for ; Fri, 8 Apr 2011 00:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK4j9N5CYrvO for ; Fri, 8 Apr 2011 00:32:53 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id EC9E93A681B for ; Fri, 8 Apr 2011 00:32:52 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8E86A8B800D for ; Fri, 8 Apr 2011 09:35:10 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 89D4B8B8006 for ; Fri, 8 Apr 2011 09:35:10 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Apr 2011 09:34:37 +0200 Received: from [10.193.71.150] ([10.193.71.150]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Apr 2011 09:34:37 +0200 Message-ID: <4D9EBA8D.9040302@orange-ftgroup.com> Date: Fri, 08 Apr 2011 09:34:37 +0200 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; ; ; ) Gecko/2010 Thunderbird/3.1.x MIME-Version: 1.0 To: pim@ietf.org References: <4D9D8C71.2050000@orange-ftgroup.com> <4D9DEE30.5090405@venaas.com> In-Reply-To: <4D9DEE30.5090405@venaas.com> X-TagToolbar-Keys: D20110408093437018 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Apr 2011 07:34:37.0233 (UTC) FILETIME=[69C5F210:01CBF5BF] Subject: Re: [pim] PIM Pop Count - Allow more than 16 options ? X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 07:32:54 -0000 Hi Stig, Stig Venaas: > > On 4/7/2011 3:05 AM, Thomas Morin wrote: >> Hi working group, Greg, Dino, >> >> Wouldn't it be a good idea to arrange for the possibility of having more >> than 16 options? >> >> A possibility would be to give a special role to the last bit of the >> option bitmap: if set, it would mean that the next two bytes after the >> option bitmap would also carry an option bitmap (a second one for 15 >> additional options), and the first option would start after this second >> option bitmap. And if the last bit of this second bitmap was set, then >> there would be yet another option bitmap... > > I have thought of this, and I think my idea is similar to yours. If we > start running out, we define the last option (option 16) to be a > bitmap option. At that time, we can define how big we want it, e.g. > 2 bytes. Those 2 bytes would then be a bitmap showing which options > follow. Following the current rules, that bitmap would then come > after the currently known options in the packet. > > If we again run out, the last option in that bitmap can be a new bitmap > option as well. Yes, this is good (also quite close to what Jeffrey suggested). > But I don't think we should worry about this in the > current draft. As long as we know we have a way to do it. Does this > sound reasonable? Even though there is no rush to fully define that 16th special option yet, documenting in the draft that extensibility would be brought by the method you have in mind would be nice, and indicate that extensions to this draft must not use the 16th bit of the option map for another purpose. > >> >> Another possibility would be a TLV encoding for all the options... > > It would require a lot more space, making the J/P messages a lot > bigger. I Agree. -Thomas From gorry@erg.abdn.ac.uk Thu Apr 7 11:44:01 2011 Return-Path: X-Original-To: pim@core3.amsl.com Delivered-To: pim@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41C4C3A69DB for ; Thu, 7 Apr 2011 11:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDzknS2j301s for ; Thu, 7 Apr 2011 11:44:00 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 554D23A67B0 for ; Thu, 7 Apr 2011 11:43:57 -0700 (PDT) Received: from ra-gorry.erg.abdn.ac.uk (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p37IjVqq024107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Apr 2011 19:45:33 +0100 (BST) Message-ID: <4D9E064C.1020901@erg.abdn.ac.uk> Date: Thu, 07 Apr 2011 19:45:32 +0100 From: Gorry Fairhurst User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Stig Venaas References: <4D91D22A.1030701@abdn.ac.uk> <4D9CC7D2.2090501@cisco.com> <4D9D67E9.4040009@erg.abdn.ac.uk> <4D9DF38B.6010600@venaas.com> In-Reply-To: <4D9DF38B.6010600@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Mailman-Approved-At: Fri, 08 Apr 2011 09:32:02 -0700 Cc: "G. Fairhurst" , pim@ietf.org, sameerg Subject: Re: [pim] Comments on draft-gulrajani-pim-hello-intid-00.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 18:44:01 -0000 Looks good Stig! Gorry On 07/04/2011 18:25, Stig Venaas wrote: > Thanks, see below. > > On 4/7/2011 12:29 AM, Gorry Fairhurst wrote: >> A few comments in line. >> >> On 06/04/2011 21:06, Stig Venaas wrote: >>> On 3/29/2011 5:35 AM, G. Fairhurst wrote: >>>> >>>> i promised to read this and comment on the list. >>> >>> Thanks, I've made some changes now. I'll submit it >>> shortly as 01 unless you have any further comments. >>> >>>> This looks like a useful thing to publish as a PS. >>>> >>>> I have a few comments: >>>> >>>> S 2.2 >>>> " it needs to be >>>> unique depends on the protocol utilizing it." >>>> - wording, is this better: >>>> "The requirements for the scope in which it needs to be unique depend o >>>> the protocol that utilises this." >>>> - Actually this is the one point that I do not yet see. It seems that >>>> without a default level of scope, there is no clear way that different >>>> protocols can reliably use the same mechanism. Is it possible just to >>>> say that the router should use an IPv4 unicast address assigned to the >>>> router by default (preferably a public address if one is defined). >>>> There >>>> is no problem allowing an operator to reassign the value, and it then >>>> becomes a matter of correct implementation. >>> >>> I did some changes, but kept most of the old text. It now says: >>> >>> The 32 bit Router Identifier may be used to uniquely identify >>> the router. It may be selected to be unique within some >>> administrative domain, or possibly globally unique. The >>> requirements for the scope in which it needs to be unique >>> depend on the protocol that utilizes this. A router >>> implementation MAY choose an IPv4 unicast address assigned >>> to the router as the Router Identifer, but MUST allow the >>> identifier to be configured manually. Protocols like BGP >>> [RFC4271] and OSPFv2 [RFC2328] are other protocols making >>> use of 32 bit identifiers for routers. One may use the same >>> identifier to construct the Interface Identifier option, >>> provided it meets the stability and uniqueness requirements >>> of protocols making use of this option. >>> >> Works for me. >> >>>> S 2.2 >>>> "Routers often have such >>>> an identifier derived from an IPv4 address or manual configuration." >>>> - but if you want it to be useful to multiple protocols then it may >>>> need >>>> more care. >>>> >>>> Security Considerations >>>> >>>> - The vulnerabilities discussed appear to be the same as for other PIM >>>> usage. These relate to on-link attacks that spoof a Hello message. An >>>> attacker able to do could also be able to manipulate other params to >>>> disrupt operation of a PIM router. >>> >>> Are you suggesting removing most of it and just have kind of the >>> standard PIM blanket statement? >>> >> I'm suggesting that you start by stating the vulnerability is the same >> as for other PIM protocol. These protocols are vulnerable to an on-link >> attack, etc. > > The old text did this to some extent. I now changed to: > > The Interface Identifier is included in PIM Hello Messages. > See [RFC4601] for security considerations regarding PIM Hello > Messages. In particular, PIM Hello messages may be forged, and > may include an arbitrary Interface Identifier, or it may be > intentionally omitted. The effects of this depend on how the > Interface Identifier is used by other protocols. > >> - you can then be as specific as you like. >> - my hope was this this effectively declares the group has thought and >> there are no important issues that need to be discussed. >> >>>> References: >>>> "[I-D.ietf-pim-port]" >>>> >>>> - This doesn't need to be a normative reference to this draft to me, >>>> although PORT needs to normatively cite this. >>> >>> Yes, not sure how it ended up as a reference, removed. >>> >> It may be OK as an INFORMATIVE reference to an example of use. > > You're right of course. I still had the example. Made it informative :) > > Stig > >>> Stig >>> >>>> Gorry >>> >>> >> >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim > > From stig@venaas.com Fri Apr 8 09:43:49 2011 Return-Path: X-Original-To: pim@core3.amsl.com Delivered-To: pim@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC3C3A6910 for ; Fri, 8 Apr 2011 09:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFqz94LZQCUH for ; Fri, 8 Apr 2011 09:43:49 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id BF1D83A68D4 for ; Fri, 8 Apr 2011 09:43:48 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:754a:64f4:f2ce:25fb] (unknown [IPv6:2001:420:4:ea0c:754a:64f4:f2ce:25fb]) by ufisa.uninett.no (Postfix) with ESMTPSA id CBC907FD9; Fri, 8 Apr 2011 18:45:31 +0200 (CEST) Message-ID: <4D9F3BA9.3080107@venaas.com> Date: Fri, 08 Apr 2011 09:45:29 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Thomas Morin References: <4D9D8C71.2050000@orange-ftgroup.com> <4D9DEE30.5090405@venaas.com> <4D9EBA8D.9040302@orange-ftgroup.com> In-Reply-To: <4D9EBA8D.9040302@orange-ftgroup.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pim@ietf.org Subject: Re: [pim] PIM Pop Count - Allow more than 16 options ? X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 16:43:49 -0000 On 4/8/2011 12:34 AM, Thomas Morin wrote: [...] >> But I don't think we should worry about this in the >> current draft. As long as we know we have a way to do it. Does this >> sound reasonable? > > Even though there is no rush to fully define that 16th special option > yet, documenting in the draft that extensibility would be brought by the > method you have in mind would be nice, and indicate that extensions to > this draft must not use the 16th bit of the option map for another purpose. Yes, I think you are right :) Hopefully we are all around when it is needed and we can do it then, but it is good to put it in the draft. Will try to do an update soon. It would be great if you (and others too of course) can review this and see whether you think it's ready for wglc, or what other changes you would like to see. Thanks, Stig > >> >>> >>> Another possibility would be a TLV encoding for all the options... >> >> It would require a lot more space, making the J/P messages a lot >> bigger. > > > I Agree. > > -Thomas > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From tena@huawei.com Fri Apr 8 13:28:30 2011 Return-Path: X-Original-To: pim@core3.amsl.com Delivered-To: pim@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8664E3A6957; Fri, 8 Apr 2011 13:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.276 X-Spam-Level: X-Spam-Status: No, score=-106.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ft3TJl24cW9k; Fri, 8 Apr 2011 13:28:22 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 5B0CC3A68CB; Fri, 8 Apr 2011 13:28:22 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJC00CCNOY7YV@usaga02-in.huawei.com>; Fri, 08 Apr 2011 13:30:07 -0700 (PDT) Received: from TingZousc1 ([10.212.246.132]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJC005F4OY58P@usaga02-in.huawei.com>; Fri, 08 Apr 2011 13:30:07 -0700 (PDT) Date: Fri, 08 Apr 2011 13:30:05 -0700 From: Tina Tsou To: 'MBONED WG' , pim@ietf.org, 'IPv6 Ops WG' , behave@ietf.org, softwires@ietf.org Message-id: <010001cbf62b$bfc24e40$3f46eac0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AQEvzYA9JGDJgObGWqAS/HlE5dNRbJWMr2vQgAAKSVA= X-Mailman-Approved-At: Sat, 09 Apr 2011 08:29:21 -0700 Cc: multrans@ietf.org Subject: [pim] You are invited to subscribe to the multrans list X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 20:28:30 -0000 Hi all, You are invited to subscribe to the multrans list. https://www.ietf.org/mailman/listinfo/multrans You are invited to comment on https://datatracker.ietf.org/doc/draft-jaclee-behave-v4v6-mcast-ps/ to the multrans list. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: Steve Young [mailto:stevey@amsl.com] Sent: Friday, April 08, 2011 12:43 PM To: tena@huawei.com; tina.tsou.zouting@huawei.com Subject: Your new mailing list: multrans The mailing list `multrans' has just been created for you. The following is some basic information about your mailing list. Your mailing list password is: ... You need this password to configure your mailing list. You also need it to handle administrative requests, such as approving mail if you choose to run a moderated list. You can configure your mailing list at the following web page: https://www.ietf.org/mailman/admin/multrans The web page for users of your mailing list is: https://www.ietf.org/mailman/listinfo/multrans You can even customize these web pages from the list configuration page. However, you do need to know HTML to be able to do this. There is also an email-based interface for users (not administrators) of your list; you can get info about using it by sending a message with just the word `help' as subject or in the body, to: multrans-request@ietf.org To unsubscribe a user: from the mailing list 'listinfo' web page, click on or enter the user's email address as if you were that user. Where that user would put in their password to unsubscribe, put in your admin password. You can also use your password to change member's options, including digestification, delivery disabling, etc. Your mailing list is configured with a public archive which can be found at: http://www.ietf.org/mail-archive/web/multrans Please note: the archive will not be created until a message has been sent to the list and the archiving process has run (runs at 10, 30, 50 past each hour). Please address all questions to mailman-owner@ietf.org. From manav.bhatia@alcatel-lucent.com Wed Apr 13 10:58:01 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1EBC2E0899 for ; Wed, 13 Apr 2011 10:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.855 X-Spam-Level: X-Spam-Status: No, score=-5.855 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdjmvNLmFTqB for ; Wed, 13 Apr 2011 10:58:00 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfc.amsl.com (Postfix) with ESMTP id 7E51AE0848 for ; Wed, 13 Apr 2011 10:58:00 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3DHvvjT004217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 Apr 2011 12:57:59 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3DHvutk014987 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 13 Apr 2011 23:27:56 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 13 Apr 2011 23:27:56 +0530 From: "Bhatia, Manav (Manav)" To: "pim@ietf.org" Date: Wed, 13 Apr 2011 23:27:54 +0530 Thread-Topic: PIM-SM Gap Analysis Thread-Index: Acv6A6b8G1oy4Q3ZReGsuSvMmQuIfwAABk9g Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD0DE217@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [pim] FW: PIM-SM Gap Analysis X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:58:01 -0000 Hi, Would be great to hear some feedback on the PIM-SM gap analysis document fr= om the PIM WG. Cheers, Manav > -----Original Message----- > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On=20 > Behalf Of Bhatia, Manav (Manav) > Sent: Wednesday, April 13, 2011 11.23 PM > To: karp@ietf.org > Subject: [karp] PIM-SM Gap Analysis >=20 > Hi, >=20 > I have written a small draft that does security gap analysis=20 > for PIM-SM. I don't think its complete yet and could=20 > definitely do with some review from the KARP and the PIM WGs. >=20 > URL for the draft: > http://www.ietf.org/id/draft-bhatia-karp-pim-gap-analysis-00.txt >=20 > Cheers, Manav >=20 > -- > Manav Bhatia, > Service Router Product Group (SRPG) > Alcatel-Lucent, India > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > = From mmcbride@cisco.com Wed Apr 13 14:31:20 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AE71AE0742 for ; Wed, 13 Apr 2011 14:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsYqL4DDuS-M for ; Wed, 13 Apr 2011 14:31:20 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id C39D1E05F5 for ; Wed, 13 Apr 2011 14:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mmcbride@cisco.com; l=258; q=dns/txt; s=iport; t=1302730279; x=1303939879; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=zX2cAk6Gm0DHH7Gn32KwnM29JWRl7Rr+NVvnKLYy+Bg=; b=Ok3DVUx1GYo0Q8vJtAgOiKkPEBJYWivN1U2qRYDuSVybrBY7uETTcK96 FyF6TTmDY5QmzdBOzf8QT4M9dov7BnaroTX4iNUqDrW1ts2zlJ/mBKDPt 8LpbiEBJtMCOvYemyKenVmPB7K6Y06QKKTpICGWm7Gi78czPZqkRBxZLo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0HAAMWpk2rRDoG/2dsb2JhbACYbY00d6V6nQmFbgSFWowE X-IronPort-AV: E=Sophos;i="4.64,206,1301875200"; d="scan'208";a="429332759" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 13 Apr 2011 21:30:59 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3DLUwBp004123 for ; Wed, 13 Apr 2011 21:30:59 GMT Received: from xmb-sjc-219.amer.cisco.com ([171.70.151.188]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 14:30:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: 2T4= AEcI A6ac BUUk Bxqe DYIS EFGm GoCc GqYA HKEE HVQG Hr1X H0uW Jqnv KIaM KZJa; 1; cABpAG0AQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {E24B04B0-6C1B-4BF7-A682-492114090DE2}; bQBtAGMAYgByAGkAZABlAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Wed, 13 Apr 2011 21:30:50 GMT; dwBnACAAYQBkAG8AcAB0AGkAbwBuACAAbwBmACAAZAByAGEAZgB0AC0AZwB1AGwAcgBhAGoAYQBuAGkALQBwAGkAbQAtAGgAZQBsAGwAbwAtAGkAbgB0AGkAZAAtADAAMQA= MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {E24B04B0-6C1B-4BF7-A682-492114090DE2} Content-class: urn:content-classes:message Date: Wed, 13 Apr 2011 14:30:50 -0700 Message-ID: <47951CBFA6409B4C8916514FCB05BFBE0C688F56@xmb-sjc-219.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: wg adoption of draft-gulrajani-pim-hello-intid-01 Thread-Index: Acv6Ig9aRbcatpPdQMygqwOr0UZVBw== From: "Mike McBride (mmcbride)" To: X-OriginalArrivalTime: 13 Apr 2011 21:30:49.0486 (UTC) FILETIME=[0ED4F2E0:01CBFA22] Subject: [pim] wg adoption of draft-gulrajani-pim-hello-intid-01 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 21:31:20 -0000 We had 5 for and 0 against adopting draft-gulrajani-pim-hello-intid-01 as a wg document in Prague. What say the rest of you? You have one week to decide and say your peace. http://www.ietf.org/id/draft-gulrajani-pim-hello-intid-01.txt thanks, mike From bill@cse.concordia.ca Wed Apr 13 16:28:44 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A2F57E0679 for ; Wed, 13 Apr 2011 16:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFMirJzB9mKi for ; Wed, 13 Apr 2011 16:28:43 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.94]) by ietfc.amsl.com (Postfix) with ESMTP id BB968E061E for ; Wed, 13 Apr 2011 16:28:43 -0700 (PDT) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from bill@cse.concordia.ca) (8.13.7/8.13.7) with ESMTP id p3DNSgW8007538 for ; Wed, 13 Apr 2011 19:28:42 -0400 Message-ID: <4DA631AD.9030404@cse.concordia.ca> Date: Wed, 13 Apr 2011 19:28:45 -0400 From: Bill Atwood Organization: Concordia University, Department of Computer Science and Software Engineering User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: pim@ietf.org References: <47951CBFA6409B4C8916514FCB05BFBE0C688F56@xmb-sjc-219.amer.cisco.com> In-Reply-To: <47951CBFA6409B4C8916514FCB05BFBE0C688F56@xmb-sjc-219.amer.cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2011/04/13 19:28:43 EDT Subject: Re: [pim] wg adoption of draft-gulrajani-pim-hello-intid-01 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 23:28:44 -0000 I support adoption. Bill Atwood On 4/13/2011 5:30 PM, Mike McBride (mmcbride) wrote: > We had 5 for and 0 against adopting draft-gulrajani-pim-hello-intid-01 > as a wg document in Prague. What say the rest of you? You have one week > to decide and say your peace. > > http://www.ietf.org/id/draft-gulrajani-pim-hello-intid-01.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: bill@cse.concordia.ca 1455 de Maisonneuve Blvd. West http: //users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From jeff.tantsura@ericsson.com Wed Apr 13 21:31:18 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 03B71E076A for ; Wed, 13 Apr 2011 21:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.919 X-Spam-Level: X-Spam-Status: No, score=-4.919 tagged_above=-999 required=5 tests=[AWL=1.680, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iG3nD1tYeeqb for ; Wed, 13 Apr 2011 21:31:14 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id 16DABE0707 for ; Wed, 13 Apr 2011 21:31:14 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3E4VCrb000551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Apr 2011 23:31:12 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 14 Apr 2011 00:31:12 -0400 From: Jeff Tantsura To: "Mike McBride (mmcbride)" , "pim@ietf.org" Date: Thu, 14 Apr 2011 00:31:10 -0400 Thread-Topic: wg adoption of draft-gulrajani-pim-hello-intid-01 Thread-Index: Acv6Ig9aRbcatpPdQMygqwOr0UZVBwAOqzQA Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60CAB3EB0EC@EUSAACMS0701.eamcs.ericsson.se> References: <47951CBFA6409B4C8916514FCB05BFBE0C688F56@xmb-sjc-219.amer.cisco.com> In-Reply-To: <47951CBFA6409B4C8916514FCB05BFBE0C688F56@xmb-sjc-219.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pim] wg adoption of draft-gulrajani-pim-hello-intid-01 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 04:31:18 -0000 Yes/support Regards, Jeff =20 -----Original Message----- From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of Mike = McBride (mmcbride) Sent: Wednesday, April 13, 2011 14:31 To: pim@ietf.org Subject: [pim] wg adoption of draft-gulrajani-pim-hello-intid-01 We had 5 for and 0 against adopting draft-gulrajani-pim-hello-intid-01 as a wg document in Prague. What say the rest of you? You have one week to decide and say your peace. http://www.ietf.org/id/draft-gulrajani-pim-hello-intid-01.txt thanks, mike _______________________________________________ pim mailing list pim@ietf.org https://www.ietf.org/mailman/listinfo/pim From manav.bhatia@alcatel-lucent.com Wed Apr 13 21:33:37 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DBA13E076A for ; Wed, 13 Apr 2011 21:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.938 X-Spam-Level: X-Spam-Status: No, score=-5.938 tagged_above=-999 required=5 tests=[AWL=0.661, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8T0-k7lEpAjj for ; Wed, 13 Apr 2011 21:33:37 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfc.amsl.com (Postfix) with ESMTP id 27969E0764 for ; Wed, 13 Apr 2011 21:33:37 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3E4XXqu023826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 Apr 2011 23:33:36 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3E4XXnp025309 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 14 Apr 2011 10:03:33 +0530 Received: from [135.250.26.32] (135.250.19.8) by INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 14 Apr 2011 10:03:32 +0530 Message-ID: <4DA678E6.6050507@alcatel-lucent.com> Date: Thu, 14 Apr 2011 10:02:38 +0530 From: Manav Bhatia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: References: <47951CBFA6409B4C8916514FCB05BFBE0C688F56@xmb-sjc-219.amer.cisco.com> <0ED867EB33AB2B45AAB470D5A64CDBF60CAB3EB0EC@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF60CAB3EB0EC@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [pim] wg adoption of draft-gulrajani-pim-hello-intid-01 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 04:33:38 -0000 I support this as well. Manav On 4/14/2011 10:01 AM, Jeff Tantsura wrote: > Yes/support > > Regards, > Jeff > > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of Mike McBride (mmcbride) > Sent: Wednesday, April 13, 2011 14:31 > To: pim@ietf.org > Subject: [pim] wg adoption of draft-gulrajani-pim-hello-intid-01 > > We had 5 for and 0 against adopting draft-gulrajani-pim-hello-intid-01 > as a wg document in Prague. What say the rest of you? You have one week > to decide and say your peace. > > http://www.ietf.org/id/draft-gulrajani-pim-hello-intid-01.txt > > thanks, > mike > _______________________________________________ > 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 thomas.morin@orange-ftgroup.com Thu Apr 14 00:34:33 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CC832E07E8 for ; Thu, 14 Apr 2011 00:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONFGpQ0fSo3V for ; Thu, 14 Apr 2011 00:34:33 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfc.amsl.com (Postfix) with ESMTP id 4C13EE06D1 for ; Thu, 14 Apr 2011 00:34:33 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DF7126F8001 for ; Thu, 14 Apr 2011 09:35:06 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id D75136C8003 for ; Thu, 14 Apr 2011 09:35:06 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 09:34:31 +0200 Received: from [10.193.71.121] ([10.193.71.121]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 09:34:31 +0200 Message-ID: <4DA6A386.5050304@orange-ftgroup.com> Date: Thu, 14 Apr 2011 09:34:30 +0200 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; ; ; ) Gecko/2010 Thunderbird/3.1.x MIME-Version: 1.0 To: pim@ietf.org References: <47951CBFA6409B4C8916514FCB05BFBE0C688F56@xmb-sjc-219.amer.cisco.com> In-Reply-To: <47951CBFA6409B4C8916514FCB05BFBE0C688F56@xmb-sjc-219.amer.cisco.com> X-TagToolbar-Keys: D20110414093429926 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Apr 2011 07:34:31.0743 (UTC) FILETIME=[64FABCF0:01CBFA76] Subject: Re: [pim] wg adoption of draft-gulrajani-pim-hello-intid-01 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 07:34:33 -0000 Support. -Thomas Mike McBride (mmcbride) a écrit : > We had 5 for and 0 against adopting draft-gulrajani-pim-hello-intid-01 > as a wg document in Prague. What say the rest of you? You have one week > to decide and say your peace. > > http://www.ietf.org/id/draft-gulrajani-pim-hello-intid-01.txt > > thanks, > mike > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From christian.jacquenet@orange-ftgroup.com Thu Apr 14 01:12:24 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9236FE07E8 for ; Thu, 14 Apr 2011 01:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtH6n4S7HMns for ; Thu, 14 Apr 2011 01:12:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfc.amsl.com (Postfix) with ESMTP id 7437AE0732 for ; Thu, 14 Apr 2011 01:12:23 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 5DAF12AC61F for ; Thu, 14 Apr 2011 10:12:22 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 43431C8061; Thu, 14 Apr 2011 10:12:22 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 14 Apr 2011 10:12:22 +0200 From: To: MORIN Thomas RD-CORE , "pim@ietf.org" Date: Thu, 14 Apr 2011 10:12:20 +0200 Thread-Topic: [pim] wg adoption of draft-gulrajani-pim-hello-intid-01 Thread-Index: Acv6dmhdnWeKTSmYQJ+j69IkNPj2zQABTXtA Message-ID: <16673_1302768742_4DA6AC66_16673_33348_1_983A1D8DA0DA5F4EB747BF34CBEE5CD14AE413E13A@PUEXCB1C.nanterre.francetelecom.fr> References: <47951CBFA6409B4C8916514FCB05BFBE0C688F56@xmb-sjc-219.amer.cisco.com> <4DA6A386.5050304@orange-ftgroup.com> In-Reply-To: <4DA6A386.5050304@orange-ftgroup.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.14.71519 Subject: Re: [pim] wg adoption of draft-gulrajani-pim-hello-intid-01 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 08:12:24 -0000 Dear all, I also support the adoption of this draft as a pim WG document. Cheers, Christian.=20 -----Message d'origine----- De : pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] De la part de Thoma= s Morin Envoy=E9 : jeudi 14 avril 2011 09:35 =C0 : pim@ietf.org Objet : Re: [pim] wg adoption of draft-gulrajani-pim-hello-intid-01 Support. -Thomas Mike McBride (mmcbride) a =E9crit : > We had 5 for and 0 against adopting draft-gulrajani-pim-hello-intid-01 > as a wg document in Prague. What say the rest of you? You have one=20 > week to decide and say your peace. > > http://www.ietf.org/id/draft-gulrajani-pim-hello-intid-01.txt > > thanks, > mike > _______________________________________________ > 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 ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From mmcbride@cisco.com Fri Apr 22 10:56:36 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B5D1AE06AF for ; Fri, 22 Apr 2011 10:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQ4e-S24ngfm for ; Fri, 22 Apr 2011 10:56:36 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 19734E0691 for ; Fri, 22 Apr 2011 10:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mmcbride@cisco.com; l=625; q=dns/txt; s=iport; t=1303494996; x=1304704596; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=uliPnFRNUQkjuXJONEEdZhGlAgHhCRXyxZ0DTYRfPTA=; b=XdhjPlOcLM/B2MZhe2aIWbvuAtzaSkRJpRdWqM4mKKkyg0tenhPgWGK3 8HzgkOtczcszIbnR5lP5wCUwSoyJIvGzUVN1zNuAli+enPv4C5VnuosKa YbCyKYGeyDffQ7/pd68/bROwAmPj5Bh1+7qECAbPwrmE0D/Tkzq8jgx3h 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUIABDBsU2rRDoH/2dsb2JhbACYFI1Md6henFGFdgSFdIxH X-IronPort-AV: E=Sophos;i="4.64,254,1301875200"; d="scan'208";a="342884566" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 22 Apr 2011 17:56:35 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3MHuZNS029274 for ; Fri, 22 Apr 2011 17:56:35 GMT Received: from xmb-sjc-219.amer.cisco.com ([171.70.151.188]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 10:56:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Apr 2011 10:56:32 -0700 Message-ID: <47951CBFA6409B4C8916514FCB05BFBE0C7F0E5F@xmb-sjc-219.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: additions to the charter Thread-Index: AcwBFNjMb2FdADp5RgiNSRDv3F4XWwAAASjA From: "Mike McBride (mmcbride)" To: X-OriginalArrivalTime: 22 Apr 2011 17:56:35.0218 (UTC) FILETIME=[9ECF0F20:01CC0116] Subject: [pim] additions to the charter X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 17:56:36 -0000 We have two proposed additions to our charter: "There is a significant number of errata that need to be addressed in order to advance RFC4601 to Draft Standard. The PIM WG will correct the errata, as necessary, and update RFC4601." and "The working group primarily works on extensions to PIM, but may take on work related to IGMP/MLD." The igmp/mld addition is based upon a request from mboned wg. We either reopen MAGMA or we take igmp/mld on in pim. During the Prague pimwg meeting there was strong support to take on igmp/mld. Please provide a yay or nay or propose alternative text. Thanks, mike From mmcbride@cisco.com Fri Apr 22 11:03:00 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2E284E0655 for ; Fri, 22 Apr 2011 11:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfGKHAZtL+Rc for ; Fri, 22 Apr 2011 11:02:59 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 3A066E0611 for ; Fri, 22 Apr 2011 11:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mmcbride@cisco.com; l=808; q=dns/txt; s=iport; t=1303495379; x=1304704979; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Ao2tsncI98RRSB80XZihjBCh+tzRd/bo+YayPE5JOLc=; b=CDDEDOQ6F2MwTmM/RZqTmda1mTdHdg75pA6jiUSxrNjWrt6fA8BdFGm7 2AHArP54GPLi0/H38DUfjzguQg01dRLnfsQvgrwBSwQzX6dLCjIu8lZXY mWvdbl/BfCAsqFku+QavMP5Us9IW3a7ySLGP6w1qsAPe4lHdccmDiQgwr Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYBAELCsU2rRDoJ/2dsb2JhbACXVT+NTHeoTpxRhXYEhXSMRw X-IronPort-AV: E=Sophos;i="4.64,254,1301875200"; d="scan'208";a="342888328" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 22 Apr 2011 18:02:58 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3MI2wcc003784 for ; Fri, 22 Apr 2011 18:02:58 GMT Received: from xmb-sjc-219.amer.cisco.com ([171.70.151.188]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 11:02:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Apr 2011 11:02:56 -0700 Message-ID: <47951CBFA6409B4C8916514FCB05BFBE0C7F0E6B@xmb-sjc-219.amer.cisco.com> In-Reply-To: <47951CBFA6409B4C8916514FCB05BFBE0C688F56@xmb-sjc-219.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pim] wg adoption of draft-gulrajani-pim-hello-intid-01 Thread-Index: Acv6Ig9aRbcatpPdQMygqwOr0UZVBwG9RbAw References: <47951CBFA6409B4C8916514FCB05BFBE0C688F56@xmb-sjc-219.amer.cisco.com> From: "Mike McBride (mmcbride)" To: X-OriginalArrivalTime: 22 Apr 2011 18:02:58.0729 (UTC) FILETIME=[83663190:01CC0117] Subject: Re: [pim] wg adoption of draft-gulrajani-pim-hello-intid-01 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 18:03:00 -0000 We have wg consensus on adopting this draft. The authors will resubmit as a wg document. Thanks for the responses. mike > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of > Mike McBride (mmcbride) > Sent: Wednesday, April 13, 2011 2:31 PM > To: pim@ietf.org > Subject: [pim] wg adoption of draft-gulrajani-pim-hello-intid-01 >=20 > We had 5 for and 0 against adopting draft-gulrajani-pim-hello-intid-01 > as a wg document in Prague. What say the rest of you? You have one week > to decide and say your peace. >=20 > http://www.ietf.org/id/draft-gulrajani-pim-hello-intid-01.txt >=20 > thanks, > mike > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From bill@cse.concordia.ca Fri Apr 22 12:55:36 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CD53AE06C0 for ; Fri, 22 Apr 2011 12:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ru6x0jrejNB4 for ; Fri, 22 Apr 2011 12:55:34 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.94]) by ietfc.amsl.com (Postfix) with ESMTP id 6BFA1E0679 for ; Fri, 22 Apr 2011 12:55:34 -0700 (PDT) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from bill@cse.concordia.ca) (8.13.7/8.13.7) with ESMTP id p3MJtXAk029349 for ; Fri, 22 Apr 2011 15:55:33 -0400 Message-ID: <4DB1DD39.3050305@cse.concordia.ca> Date: Fri, 22 Apr 2011 15:55:37 -0400 From: Bill Atwood Organization: Concordia University, Department of Computer Science and Software Engineering User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: pim@ietf.org References: <47951CBFA6409B4C8916514FCB05BFBE0C7F0E5F@xmb-sjc-219.amer.cisco.com> In-Reply-To: <47951CBFA6409B4C8916514FCB05BFBE0C7F0E5F@xmb-sjc-219.amer.cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2011/04/22 15:55:33 EDT Subject: Re: [pim] additions to the charter X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 19:55:37 -0000 yay, yay. (or, if you prefer, yea, yea!!) Bill On 4/22/2011 1:56 PM, Mike McBride (mmcbride) wrote: > We have two proposed additions to our charter: > > "There is a significant number of errata that need to be addressed in > order to advance RFC4601 to Draft Standard. The PIM WG will correct the > errata, as necessary, and update RFC4601." > > and > > "The working group primarily works on extensions to PIM, but may take on > work related to IGMP/MLD." > > The igmp/mld addition is based upon a request from mboned wg. We either > reopen MAGMA or we take igmp/mld on in pim. During the Prague pimwg > meeting there was strong support to take on igmp/mld. > > Please provide a yay or nay or propose alternative text. > > 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: bill@cse.concordia.ca 1455 de Maisonneuve Blvd. West http: //users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From Adrian.Farrel@huawei.com Fri Apr 22 13:50:59 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 12DA0E07DD for ; Fri, 22 Apr 2011 13:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.899 X-Spam-Level: X-Spam-Status: No, score=-103.899 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLXuCGesTS0W for ; Fri, 22 Apr 2011 13:50:56 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by ietfc.amsl.com (Postfix) with ESMTP id B2E2EE067D for ; Fri, 22 Apr 2011 13:50:56 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LK200FR1N8WSZ@usaga01-in.huawei.com> for pim@ietf.org; Fri, 22 Apr 2011 15:50:56 -0500 (CDT) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LK200G22N8T2H@usaga01-in.huawei.com> for pim@ietf.org; Fri, 22 Apr 2011 15:50:56 -0500 (CDT) Date: Fri, 22 Apr 2011 21:50:53 +0100 From: Adrian Farrel To: draft-ietf-pim-mtid@tools.ietf.org Message-id: <0b9901cc012e$f9950c80$ecbf2580$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AcwBLqNePNSvAqjaTxqExg2kmxG45g== Cc: pim@ietf.org, pim-chairs@tools.ietf.org Subject: [pim] AD review of draft-ietf-pim-mtid-07.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 20:50:59 -0000 Hi, Don't panic! I have performed my AD review of your draft. The purpose of the review is to catch any nits or issues before the document goes forward to IETF last call and IESG review. By getting these issues out at this stage we can hope for a higher quality review and a smoother passage through the process. I don't have any major technical issues with your draft. The intention and solution are fine. However, I found a largish number of small issues and questions. These are mainly concerns with clarity, although I did have some more substantial concerns about the selection of the MT-ID. All of my comments are up for discussion, and you should not feel rail-roaded into making changes. But I do think my comments need to be addressed for this document to stand half a chance of getting through IESG review, and I would like you to have a look and see whether you can work to improve the text before I take it forward. Perhaps you should take some time to talk with the document shepherd and WG chairs to determine what the best course of action is. I have moved the draft into "AD-review:Revised-ID-needed" state in the datatracker, and I look forward to seeing the new revision which I can put forward for IETF last call. Thanks, Adrian --- idnits reports a warning that you need to fix. It should be simple. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - the value MUST not be 0. If it is 0, the PIM MT-ID attribute is ignored. Processing of the rest of the Join message, including the current (S,G) or (*,G) entry, continues as if the particular PIM MT-ID attribute weren't present in the packet. --- I had some real trouble with the Introduction. I tried various ways to make some comments that would help you, but found it really hard. So I have opted for giving you some text to look at and consider. Some unicast routing protocols, such as OSPF and IS-IS, allow a single network to be viewed as multiple topologies [RFC4915], [RFC5120]. Such multi-topology (MT) routing allows different paths through the network to be selected to support different traffic, or to offer protection paths in the event of failures. PIM [RFC4601] uses Reverse Path Forwarding (RFP) to leverage the unicast routing protocols and construct multcast distribution trees. If PIM was able to access the multiple topologies created by the unicast routing protocols, it would be possible to construct multicast distribution trees using separate network paths even when the roots of the trees are the same. This capability would facilitate an improvement to the resilience of multicast applications. For instance, a multicast stream could be duplicated and transported using two source trees, (S1, G1) and (S1, G2), simultneously. By using MT capable unicast routing protocols and procedures described in this document, it is possible to construct the two source trees in such a way that they do not share any transit network segment. As a result, a single network failure will not cause any loss to the stream. This document introducess a new type of PIM Join Attribute [RFC5384] to encode the identity of the topology PIM is to use when performing RPF for the source tree that is being joined. This document also specifies the procedures and rules to process the attribute and resolve conflicts arrising from mismatches in MT capabilities or identifiers. This document does not introduce any change to the RPF check procedure used to verify the incoming interface when a packet is forwarded as defined in [RFC4601]. For example, to use the capability described by this document, an application can choose to use group addresses, and/or source addresses, to identify a unique multicast stream. It might further need to perform the functions of splitting and merging. But the detailed processing is beyond the scope of the document. --- Please search the text for the word "draft" and replace it with "document". This makes the etxt easier to parse when the document becomes and RFC. --- In Section 3.1 To select the RPF topology for a particular multicast distribution tree, one or more of the following can be done. Your use of "can" implies that there are also other options. In other words you are also saying that it is possible to select the RPF topology using another mechanism not specified here. Whether you intend this or not, I would like you to be more explicit so that "can be done" causes no ambiguity. Either say "is done" or "could be done in addition other mechanisms that may be defined in other documents." In the end, this all starts to sound a bit vague! Perhaps it is better to turn it around and say up-front that... Selection of RPF topology can be made by configured policy. For example: - foo - bar This document describes a mechanims where the topology to select is encoded by the leaf in a new Join Attribute. --- I am worried about whether the RPF topology selection mechanism needs to be coordinated across the whole network, and what happens if it is not. Can you convince me that you will not build routing loops by having a mix of policies in the network? --- Section 3.2 For each PIM RPF topology created, a unique numerical ID is assigned per PIM domain. This ID is called PIM MT-ID. PIM MT-ID has the following property, s/PIM MT-ID/the PIM MT-ID/ twice s/property,/properties:/ - this value is not required to be the same as the MT-ID used by the unicast routing protocols that contribute routes to the topology. In practice, when only one unicast routing protocol (such as OSPF or IS-IS) is used, PIM MT-ID is recommended to be assigned using the same value as the IGP topology identifier. This is for the purpose of reducing management overhead and simplifying troubleshooting. Do you mean RECOMMENDED? --- Please select consistent terminology. I see - Join-Attribute - Join Attribute - join attribute --- I don't understand how a consistent PIM MT-ID will be generated. Each router will apply RPF on the various different IGP MT topologies to generate the set of RPF topologies. Isn't it the case that all routers need to assign the same PIM MT-ID to the same RPF topology, and also that the leaf nodes (issuing PIM messages containing Join Attributes) must select the RPF topology based on the same PIM MT-ID. To me, that means that some consistent naming policy is needed. Your reccommendation in section 3.2 is fine when (as you note) there is only one IGP instance present. How will you handle the other cases? It really is a cop-out to go on to say... - how to assign a PIM MT-ID to a topology is decided by the network administrator and is outside the scope of this document ...What is more, this seems to be in contradiction to the previous recommendation. Furter, this short note has major impacts for an implementation - I'm willing to bet that your implementation does not allow the full range of options that an administrator might want to impose. I also don't feel that it is enough to say... - this value must be unique and consistent within the network domain for the same topology. For actual deployment, one should have a means to detect inconsistency of the MT-ID configuration, but the detail of such mechanism is beyond the scope of this document. ...without some description of what "consistency" means and how to achieve it. I would also feel that your teaser about "a means to detect inconsistency" is a bit weak. If such a means is important for the deployment of your extension, then don't you need to work to define that means (or derive something like the previous recommendation that mean it is not necessary)? --- Section 3.3 The PIM MT-ID join attribute described in this draft applies to PIM Join/Assert packets used by PIM SM/SSM/Bidir. It is not used in any other PIM packets, such as Prune, Register, Register-Stop, Graft, Graft-ack, DF Election, Candidate-RP, and Bootstrap. As such, it can only be used to build shared or source trees for PIM SM/SSM and PIM- bidir downstream. I suggest removing the "such as Prune, ..." If it is not used in any otherPIM packets, no list is necessary. Furthermore, if you have accidentally lefta message out of the list, you have increased the ambiguity. --- Section 3.3 When this attribute is used in combination with RPF vectors defined in [RFC5496] [ID.ietf-l3vpn-2547bis-mcast], they are processed against the topology identified by the PIM MT-ID attribute. Need two small fixes to avoid ambiguity... When this attribute is used in combination with RPF vectors defined in [RFC5496] and [ID.ietf-l3vpn-2547bis-mcast], the vectors are processed against the topology identified by the PIM MT-ID attribute. --- Section 4.1 This took me a long while to parse. Can I suggest: 4.1. Indicating Support for MT A router that supports the functionality described by this document MUST include the PIM Hello Option in its PIM Hello packets and MUST include both the Join Attribute Option [RFC5384] and the new PIM MT-ID Option (see Section 5.1 of this document). --- Section 4.2.1 When a PIM router originates a PIM Join/Assert packet, it may choose to encode PIM MT-ID of the topology in which RPF lookup takes place s/takes place/is to take place/ for the corresponding (*,G) or (S,G) entry. The chosen PIM MT-ID MUST be the one decided by local topology selection configuration if it exists, or the one received from downstream routers after conflict resolution procedures are applied. Is "MUST" appropriate here? Especially as you have an "or" and some exceptions. How about "The PIM MT-ID identifies the topology chosen by local policy/configuration or is the value received from downstream routers after ID conflict resolution procedures have been applied (see Section 4.2.4)." --- Section 4.2.1 Please start the bullets with capital letters as they are sentences. - a router SHOULD NOT do so if the upstream router, or any of the routers on the LAN does not include "PIM Join Attribute" or "PIM MT-ID" option in its Hello packets. "SHOULD NOT" do what? Please expand the text. - a router SHOULD NOT encode PIM MT-ID for pruned sources. If encoded, the value is ignored. "is ignored" by whom? Maybe "will be ignored as described in ..." --- Section 4.2.2 Please start the bullets with capital letters as they are sentences. There are two cases missing from this section. 1. How will a node that does not recognise the MT-ID Join Attribute react? You need to state this with a reference to the RFC that defines how it will behave. 2. How will a node react if it recognises the attribute, but did not send both of the specific Hello Options and does not want to accept the MT-ID? You should define this behavior in this document. You may feel that the first paragraph of 4.2.3 belongs in this section to help address my second question. --- 4.2.3 You have... An upstream router must be known to support this draft in order for a ...I suspect you wanted "MUST" although it would be less clumsy to re- word the text so that you can use "MUST NOT". --- 4.2.3 Aren't you missing text for the case of pruned sources per 4.2.1? --- 4.2.4 On an upstream router, a conflict occurs when the router doesn't have local topology selection policy and it has received different PIM MT-ID from Join packets sent by its downstream routers or Assert packets from another forwarding router on the LAN. In another word, if an upstream router has a local configuration that specifies a different topology than that from an incoming Join/Assert packet, including the case PIM MT-ID is not encoded in the incoming packet, it does not apply the conflict resolution procedures. I *think* this paragraph is talking about two things. 1. The definition of conflict on an upstream router 2. A condition that is not consider to be conflict when it happens on an upstream router. The problem is with the conjunciton "in another word" which normally means that it is explaining the previous text, but in this case seems to be introducing a separate case. If I'm right about your intention, I think you could clarify the text quite a bit. For example: PIM MT-ID conflict arises on an upstream router when the router doesn't have a local topology selection policy and receives Join packets from downstream routers and/or Assert packets from other forwarding routers on the LAN, and those packets contain different PIM MT-IDs. However, if an upstream router has a local configuration that specifies PIM MT-IDs to identify RPF topologies, and those MT-IDs do not match the MT-ID on a received Join or Assert packet, this is not considered to be a conflict and the resolution procedures are not applied. This includes the case where there are local PIM MT-IDs, but there is no PIM MT-ID encoded in the incoming packet. In the final paragraph of the section you have... It MUST be noted that the MT-ID value being considered for comparison does not include the four reserved bits. That is, only the lower order 12 bits are used in resolving conflicting attributes. ...The "MUST" seems to be applied to the need to make an observation. You really want it to apply to the comparison rules... When two PIM MT-IDs are compared, only the 12-bit Value field (see Section 5.2) is compared. Other fields of the PIM MT-ID Join Attribute TLV Format (including the four reserved bits) MUST NOT be used in te comparison. --- 4.2.4.1 In order to minimize the chances of potential transient forwarding loops, an upstream router MAY choose to ignore the incoming PIM Join/Prune packets all together if it sees a conflict in PIM MT-ID attributes. This action may also be taken by an upstream router which has locally configured topology selection policy, as an exception to the rules described above. s/may/MAY/ Why do you say "Join/Prune"? Is it assumed that the PIM MT-ID from the other Join (the one that was discarded) will have been retained so that this decision can be made? --- 5.2 - Attr Type: 3. This should read: - Attr Type: --- 5.2 - Value: PIM MT-ID, 1 to 4095. Range 2048 to 4095 are for experimental and proprietary use. This was a surpise! We have already established that... In practice, when only one unicast routing protocol (such as OSPF or IS-IS) is used, PIM MT-ID is recommended to be assigned using the same value as the IGP topology identifier. ...and... - how to assign a PIM MT-ID to a topology is decided by the network administrator and is outside the scope of this document Section 3.7 of RFC 4915 gives a very different view of how MT-IDs might be numbered. I am not sure I understand what difference there is between a policy configuration value, and an experimental or proprietary value. In *all* cases, the operator will need to ensure that there is a uniform policy across the network, so reserving values for proprietary use doesn't seem to buy anything (and anyway, how would you avoid clashes?). RFC 4915 did observe that there might be purpose to reserving a (small) subset for IANA control. Can you have a look at this issue and work out the right guidance to include here? --- Section 6 The IANA section needs some work! 6.1. PIM MT-ID Hello Option The IANA maintains a registry of "Protocol Independent Multicast (PIM) Parameters" with a sub-registry called "PIM-Hello Options". The IANA assigned the PIM Hello Option type value 30 for the PIM MT-ID Hello Option according to the First Come First Served allocaiton policy. The IANA is requested to make that allocation permanent with reference to this document. Note that the option defined in Section 5.1 of this document has length 0. The IANA is requested to update the length value recorded in the registry. 6.2. PIM MT-ID Join Attribute The IANA maintains a registry of "Protocol Independent Multicast (PIM) Parameters" with a sub-registry called "PIM Join Attribute Types". The IANA is requested to assign the next available value for the PIM MT-ID Join Attribute defined in Section 5.2 of this document. --- Section 7 is a little thin. I know there is not much to say, but it might be helpful to pad it out a bit. For example: As described in [RFC5384], the security of the Join Attribute is only guaranteed by the security of the PIM packet that carries it. Similarly, the security of the Hello Options is only guaranteed by securing the whole Hello packet. In view of the fact that malicious alteration of the PIM MT-ID Hello Option or the PIM MT-ID carried in a packet might cause the PIM resiliency goals to be violated, the security considerations of [RFC4601] apply to the extensions described in this document. --- Section 11 You no longer need the reference [HELLO] From lenny@juniper.net Fri Apr 22 13:51:51 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6B744E07EF for ; Fri, 22 Apr 2011 13:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0kYd+KXw1oT for ; Fri, 22 Apr 2011 13:51:50 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfc.amsl.com (Postfix) with ESMTP id 81197E067D for ; Fri, 22 Apr 2011 13:51:50 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTbHqZVDLXy6r0WdwjCo1IbRZp40VMPWO@postini.com; Fri, 22 Apr 2011 13:51:50 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 22 Apr 2011 13:49:38 -0700 Received: from zircon.juniper.net (zircon.juniper.net [172.17.28.113]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p3MKncv56864; Fri, 22 Apr 2011 13:49:38 -0700 (PDT) (envelope-from lenny@juniper.net) Received: from zircon.juniper.net (localhost [127.0.0.1]) by zircon.juniper.net (8.12.11/8.12.3) with ESMTP id p3MKnbxR098254; Fri, 22 Apr 2011 13:49:37 -0700 (PDT) (envelope-from lenny@juniper.net) Received: from localhost (lenny@localhost) by zircon.juniper.net (8.12.11/8.12.3/Submit) with ESMTP id p3MKnbOS098251; Fri, 22 Apr 2011 13:49:37 -0700 (PDT) X-Authentication-Warning: zircon.juniper.net: lenny owned process doing -bs Date: Fri, 22 Apr 2011 13:49:37 -0700 From: Leonard Giuliano To: "Mike McBride (mmcbride)" In-Reply-To: <47951CBFA6409B4C8916514FCB05BFBE0C7F0E5F@xmb-sjc-219.amer.cisco.com> Message-ID: <20110422134913.N98023@zircon.juniper.net> References: <47951CBFA6409B4C8916514FCB05BFBE0C7F0E5F@xmb-sjc-219.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: pim@ietf.org Subject: Re: [pim] additions to the charter X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 20:51:51 -0000 Yay to both. On Fri, 22 Apr 2011, Mike McBride (mmcbride) wrote: -) We have two proposed additions to our charter: -) -) "There is a significant number of errata that need to be addressed in -) order to advance RFC4601 to Draft Standard. The PIM WG will correct the -) errata, as necessary, and update RFC4601." -) -) and -) -) "The working group primarily works on extensions to PIM, but may take on -) work related to IGMP/MLD." -) -) The igmp/mld addition is based upon a request from mboned wg. We either -) reopen MAGMA or we take igmp/mld on in pim. During the Prague pimwg -) meeting there was strong support to take on igmp/mld. -) -) Please provide a yay or nay or propose alternative text. -) -) Thanks, -) mike -) -) -) _______________________________________________ -) pim mailing list -) pim@ietf.org -) https://www.ietf.org/mailman/listinfo/pim -) From Internet-Drafts@ietf.org Fri Apr 22 14:30:05 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 43A3FE0742; Fri, 22 Apr 2011 14:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.133 X-Spam-Level: X-Spam-Status: No, score=-103.133 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMhSvrOsUofN; Fri, 22 Apr 2011 14:30:04 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B0618E07C6; Fri, 22 Apr 2011 14:30:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110422213004.21602.99410.idtracker@ietfc.amsl.com> Date: Fri, 22 Apr 2011 14:30:04 -0700 Cc: pim@ietf.org Subject: [pim] I-D Action:draft-ietf-pim-hello-intid-00.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 21:30:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : An Interface ID Hello Option for PIM Author(s) : S. Gulrajani, S. Venaas Filename : draft-ietf-pim-hello-intid-00.txt Pages : 11 Date : 2011-04-22 This document defines a new PIM Hello option to advertise an interface id that can be used by PIM protocols to uniquely identify an interface of a neighboring router. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-hello-intid-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pim-hello-intid-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-22141952.I-D@ietf.org> --NextPart-- From stig@venaas.com Fri Apr 22 14:49:18 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EEA2EE067D for ; Fri, 22 Apr 2011 14:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.375 X-Spam-Level: X-Spam-Status: No, score=-101.375 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMexvvSLzAUl for ; Fri, 22 Apr 2011 14:49:18 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfc.amsl.com (Postfix) with ESMTP id 6E733E0613 for ; Fri, 22 Apr 2011 14:49:18 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:4946:482d:324e:84c1] (unknown [IPv6:2001:420:4:ea0c:4946:482d:324e:84c1]) by ufisa.uninett.no (Postfix) with ESMTPSA id 568B17FCD for ; Fri, 22 Apr 2011 23:49:17 +0200 (CEST) Message-ID: <4DB1F7DA.2020906@venaas.com> Date: Fri, 22 Apr 2011 14:49:14 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: pim@ietf.org References: <20110422213004.21602.99410.idtracker@ietfc.amsl.com> In-Reply-To: <20110422213004.21602.99410.idtracker@ietfc.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pim] I-D Action:draft-ietf-pim-hello-intid-00.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 21:49:19 -0000 As just announced, this draft is now adopted as a wg document. Speaking as an individual, I am hoping this draft can go to wglc soon, since PORT relies on this, and it probably makes sense to have this through wglc, before doing the same for PORT. Could you guys please have a look at the draft and see whether you have any issues or see room for improvement? Stig From zzhang@juniper.net Fri Apr 22 15:39:08 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1282EE068E for ; Fri, 22 Apr 2011 15:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nk7ooz85-05w for ; Fri, 22 Apr 2011 15:39:07 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfc.amsl.com (Postfix) with ESMTP id 5858EE0685 for ; Fri, 22 Apr 2011 15:39:06 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTbIDiRw1fCihw3TXrvpQbBp13EEPx6Wo@postini.com; Fri, 22 Apr 2011 15:39:07 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 22 Apr 2011 15:37:49 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 22 Apr 2011 18:37:48 -0400 From: "Jeffrey (Zhaohui) Zhang" To: "Mike McBride (mmcbride)" Date: Fri, 22 Apr 2011 18:37:49 -0400 Thread-Topic: [pim] additions to the charter Thread-Index: AcwBLx+++m+2OdyJQSq72f6l3jGInwADrpBg Message-ID: <13205C286662DE4387D9AF3AC30EF456D342DB1027@EMBX01-WF.jnpr.net> References: <47951CBFA6409B4C8916514FCB05BFBE0C7F0E5F@xmb-sjc-219.amer.cisco.com> <20110422134913.N98023@zircon.juniper.net> In-Reply-To: <20110422134913.N98023@zircon.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pim@ietf.org" Subject: Re: [pim] additions to the charter X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 22:39:08 -0000 Yay to both. >=20 >=20 > On Fri, 22 Apr 2011, Mike McBride (mmcbride) wrote: >=20 > -) We have two proposed additions to our charter: > -)=20 > -) "There is a significant number of errata that need to be=20 > addressed in > -) order to advance RFC4601 to Draft Standard. The PIM WG=20 > will correct the > -) errata, as necessary, and update RFC4601." > -)=20 > -) and > -)=20 > -) "The working group primarily works on extensions to PIM,=20 > but may take on > -) work related to IGMP/MLD." > -)=20 > -) The igmp/mld addition is based upon a request from mboned=20 > wg. We either > -) reopen MAGMA or we take igmp/mld on in pim. During the Prague pimwg > -) meeting there was strong support to take on igmp/mld. > -)=20 > -) Please provide a yay or nay or propose alternative text. > -)=20 > -) Thanks, > -) mike > -)=20 > -)=20 > -) _______________________________________________ > -) pim mailing list > -) pim@ietf.org > -) https://www.ietf.org/mailman/listinfo/pim > -)=20 > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > = From rishabhp@gmail.com Fri Apr 22 20:37:54 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 29A47E06E2 for ; Fri, 22 Apr 2011 20:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0HaTSYCQxiw for ; Fri, 22 Apr 2011 20:37:53 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id 84F4EE065C for ; Fri, 22 Apr 2011 20:37:53 -0700 (PDT) Received: by iyn15 with SMTP id 15so242814iyn.31 for ; Fri, 22 Apr 2011 20:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Y08FoQbUlY1NoJkKZytGoWjxGzFg/1TR/ubZ+vsCEdk=; b=S6wMm6Ks71Tu4rct1J7qqfZXh9PBlHL7u0kJh7puUrTFFCcDk6tPHwMpFMitigrc2h YM1qHS+RyTQ8XydcjfwPk9pq+ymeChIhf76+1eHWs/puO5feDHeojBjeHSyNfDEfjQTq QfJI6BFO9G0S+F7/UroStBk/ed3a1X3mMqJB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vgupGenAaSiujTNbQXmYkzfPf1t4MXyiWTUOlZsJaI17dfAKkRTCa9V/c7BSErv5cA FSQo6F6s6JiY0OpwiBnpvs4CuI2KaSznf5Y/suFcbkNx4GkCuwDpLoiGI2R2R9Tb5q7i 8pAT2RsLlHaUNL8Q72XnF8nkZdbNJKnuzzFwY= MIME-Version: 1.0 Received: by 10.231.122.30 with SMTP id j30mr1291235ibr.37.1303529873139; Fri, 22 Apr 2011 20:37:53 -0700 (PDT) Received: by 10.231.205.145 with HTTP; Fri, 22 Apr 2011 20:37:53 -0700 (PDT) In-Reply-To: <47951CBFA6409B4C8916514FCB05BFBE0C7F0E5F@xmb-sjc-219.amer.cisco.com> References: <47951CBFA6409B4C8916514FCB05BFBE0C7F0E5F@xmb-sjc-219.amer.cisco.com> Date: Fri, 22 Apr 2011 20:37:53 -0700 Message-ID: From: Rishabh Parekh To: "Mike McBride (mmcbride)" Content-Type: multipart/alternative; boundary=0016e6471a2c0ae9bb04a18db391 Cc: pim@ietf.org Subject: Re: [pim] additions to the charter X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 03:37:54 -0000 --0016e6471a2c0ae9bb04a18db391 Content-Type: text/plain; charset=ISO-8859-1 Yay * 2 -Rishabh On Fri, Apr 22, 2011 at 10:56 AM, Mike McBride (mmcbride) < mmcbride@cisco.com> wrote: > We have two proposed additions to our charter: > > "There is a significant number of errata that need to be addressed in > order to advance RFC4601 to Draft Standard. The PIM WG will correct the > errata, as necessary, and update RFC4601." > > and > > "The working group primarily works on extensions to PIM, but may take on > work related to IGMP/MLD." > > The igmp/mld addition is based upon a request from mboned wg. We either > reopen MAGMA or we take igmp/mld on in pim. During the Prague pimwg > meeting there was strong support to take on igmp/mld. > > Please provide a yay or nay or propose alternative text. > > Thanks, > mike > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > --0016e6471a2c0ae9bb04a18db391 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yay * 2

-Rishabh

On Fri, Apr 22, 2= 011 at 10:56 AM, Mike McBride (mmcbride) <mmcbride@cisco.com> wrote:
We have two proposed additions to our charter:

"There is a significant number of errata that need to be addressed in<= br> order to advance RFC4601 to Draft Standard. The PIM WG will correct the
errata, as necessary, and update RFC4601."

and

"The working group primarily works on extensions to PIM, but may take = on
work related to IGMP/MLD."

The igmp/mld addition is based upon a request from mboned wg. We either
reopen MAGMA or we take igmp/mld on in pim. During the Prague pimwg
meeting there was strong support to take on igmp/mld.

Please provide a yay or nay or propose alternative text.

Thanks,
mike


_______________________________________________
pim mailing list
pim@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pim

--0016e6471a2c0ae9bb04a18db391-- From gall@switch.ch Sat Apr 23 02:32:38 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C84CEE06F9 for ; Sat, 23 Apr 2011 02:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.814 X-Spam-Level: * X-Spam-Status: No, score=1.814 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, GB_H_PHARMACY=1, GB_PHARMACY=1, NO_RELAYS=-0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0KgKj8wr1sf for ; Sat, 23 Apr 2011 02:32:38 -0700 (PDT) Received: from hadron.switch.ch (hadron.switch.ch [IPv6:2001:620:0:4:203:baff:fe4c:d99b]) by ietfc.amsl.com (Postfix) with ESMTP id 1D9C4E06A7 for ; Sat, 23 Apr 2011 02:32:37 -0700 (PDT) Received: from hadron.switch.ch (localhost [IPv6:::1]) by hadron.switch.ch (8.14.4+Sun/8.14.4) with ESMTP id p3N9WZVk017243 for ; Sat, 23 Apr 2011 11:32:35 +0200 (CEST) Received: (from gall@localhost) by hadron.switch.ch (8.14.4+Sun/8.14.4/Submit) id p3N9WZvD017238; Sat, 23 Apr 2011 11:32:35 +0200 (CEST) Date: Sat, 23 Apr 2011 11:32:35 +0200 (CEST) From: Alexander Gall Message-Id: <201104230932.p3N9WZvD017238@hadron.switch.ch> To: pim@ietf.org References: <20110422185626.2249.qmail@201-69-8-135.dial-up.telesp.net.br> In-Reply-To: <20110422185626.2249.qmail@201-69-8-135.dial-up.telesp.net.br> Precedence: junk X-Loop: gall@switch.ch Subject: Re: [pim] alexander.gall@switch.ch USA Pharmacy-Discount ID3515 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 09:32:38 -0000 I'm on leave of absence until the end of June. I will have very limited access to my email and cannot attend to business matters during this time. Please contact for any issues concerning the SWITCH network. Sincerely, Alexander Gall SWITCH From Adrian.Farrel@huawei.com Sat Apr 23 07:16:57 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0088FE06FC for ; Sat, 23 Apr 2011 07:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.11 X-Spam-Level: X-Spam-Status: No, score=-105.11 tagged_above=-999 required=5 tests=[AWL=1.489, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTSJlCP+fAhA for ; Sat, 23 Apr 2011 07:16:56 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by ietfc.amsl.com (Postfix) with ESMTP id 6E3D2E069C for ; Sat, 23 Apr 2011 07:16:56 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LK300KW1ZO7PV@usaga03-in.huawei.com> for pim@ietf.org; Sat, 23 Apr 2011 09:16:56 -0500 (CDT) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LK300A5LZO540@usaga03-in.huawei.com> for pim@ietf.org; Sat, 23 Apr 2011 09:16:55 -0500 (CDT) Date: Sat, 23 Apr 2011 15:16:53 +0100 From: Adrian Farrel To: pim@ietf.org Message-id: <0c7501cc01c1$1934d330$4b9e7990$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AcwBwMB3l9cltktbSH6SSUXLYqaqFA== Subject: [pim] FW: Last Call: X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 14:16:57 -0000 Hi PIM WG, With your potential new role caring for IGMP/MLD, please be aware of the IETF last call currently in progress for this document. All review comments (favorable and otherwise) should be sent to the IETF mailing list. Thanks, Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: 21 April 2011 22:55 > To: IETF-Announce > Cc: mboned@ietf.org > Subject: Last Call: (Requirements for > Multicast AAA coordinated between Content Provider(s) and Network Service > Provider(s)) to Informational RFC > > > The IESG has received a request from the MBONE Deployment WG (mboned) to > consider the following document: > - 'Requirements for Multicast AAA coordinated between Content Provider(s) > and Network Service Provider(s)' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-05-05. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mboned-maccnt-req/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mboned-maccnt-req/ > > > > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From asaeda@sfc.wide.ad.jp Sat Apr 23 23:25:32 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9D337E073D for ; Sat, 23 Apr 2011 23:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.588 X-Spam-Level: X-Spam-Status: No, score=-97.588 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_RECV_IP_222000=1.508, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tu2plUelnfl5 for ; Sat, 23 Apr 2011 23:25:32 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfc.amsl.com (Postfix) with ESMTP id BFCE7E06D0 for ; Sat, 23 Apr 2011 23:25:31 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id DF6FD27808D for ; Sun, 24 Apr 2011 15:25:24 +0900 (JST) Date: Sun, 24 Apr 2011 15:25:24 +0900 (JST) Message-Id: <20110424.152524.233323768.asaeda@sfc.wide.ad.jp> To: pim@ietf.org From: Hitoshi Asaeda In-Reply-To: <47951CBFA6409B4C8916514FCB05BFBE0C7F0E5F@xmb-sjc-219.amer.cisco.com> References: <47951CBFA6409B4C8916514FCB05BFBE0C7F0E5F@xmb-sjc-219.amer.cisco.com> X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [pim] additions to the charter X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 06:25:32 -0000 Yay! -- Hitoshi Asaeda From: "Mike McBride (mmcbride)" Subject: [pim] additions to the charter Date: Fri, 22 Apr 2011 10:56:32 -0700 > We have two proposed additions to our charter: > > "There is a significant number of errata that need to be addressed in > order to advance RFC4601 to Draft Standard. The PIM WG will correct the > errata, as necessary, and update RFC4601." > > and > > "The working group primarily works on extensions to PIM, but may take on > work related to IGMP/MLD." > > The igmp/mld addition is based upon a request from mboned wg. We either > reopen MAGMA or we take igmp/mld on in pim. During the Prague pimwg > meeting there was strong support to take on igmp/mld. > > Please provide a yay or nay or propose alternative text. > > Thanks, > mike > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From jeff.tantsura@ericsson.com Sun Apr 24 11:10:01 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4084DE06CD for ; Sun, 24 Apr 2011 11:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55bNdegjtASQ for ; Sun, 24 Apr 2011 11:10:00 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id AF306E06BD for ; Sun, 24 Apr 2011 11:10:00 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3OI9wRx018184; Sun, 24 Apr 2011 13:09:59 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 24 Apr 2011 14:09:52 -0400 From: Jeff Tantsura To: "Mike McBride (mmcbride)" Date: Sun, 24 Apr 2011 14:09:49 -0400 Thread-Topic: [pim] additions to the charter Thread-Index: AcwCqs5oyq6ziwQgQ4277F5YH16ndA== Message-ID: References: <47951CBFA6409B4C8916514FCB05BFBE0C7F0E5F@xmb-sjc-219.amer.cisco.com> In-Reply-To: <47951CBFA6409B4C8916514FCB05BFBE0C7F0E5F@xmb-sjc-219.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pim@ietf.org" Subject: Re: [pim] additions to the charter X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 18:10:01 -0000 Yay x2 Regards, Jeff On Apr 22, 2011, at 10:56, "Mike McBride (mmcbride)" w= rote: > We have two proposed additions to our charter: >=20 > "There is a significant number of errata that need to be addressed in > order to advance RFC4601 to Draft Standard. The PIM WG will correct the > errata, as necessary, and update RFC4601." >=20 > and >=20 > "The working group primarily works on extensions to PIM, but may take on > work related to IGMP/MLD." >=20 > The igmp/mld addition is based upon a request from mboned wg. We either > reopen MAGMA or we take igmp/mld on in pim. During the Prague pimwg > meeting there was strong support to take on igmp/mld. >=20 > Please provide a yay or nay or propose alternative text. >=20 > Thanks, > mike >=20 >=20 > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From wwwrun@rfc-editor.org Mon Apr 25 09:54:16 2011 Return-Path: X-Original-To: pim@ietfc.amsl.com Delivered-To: pim@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8D5C6E076B; Mon, 25 Apr 2011 09:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.027 X-Spam-Level: X-Spam-Status: No, score=-102.027 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0RZm0sEYUr6; Mon, 25 Apr 2011 09:54:16 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfc.amsl.com (Postfix) with ESMTP id EE2FEE076A; Mon, 25 Apr 2011 09:54:15 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 79A4BE0773; Mon, 25 Apr 2011 09:54:15 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110425165415.79A4BE0773@rfc-editor.org> Date: Mon, 25 Apr 2011 09:54:15 -0700 (PDT) Cc: pim@ietf.org, rfc-editor@rfc-editor.org Subject: [pim] RFC 6166 on A Registry for PIM Message Types X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 16:54:16 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6166 Title: A Registry for PIM Message Types Author: S. Venaas Status: Standards Track Stream: IETF Date: April 2011 Mailbox: stig@cisco.com Pages: 4 Characters: 7441 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pim-registry-04.txt URL: http://www.rfc-editor.org/rfc/rfc6166.txt This document provides instructions to IANA for the creation of a registry for PIM message types. It specifies the initial content of the registry, based on existing RFCs specifying PIM message types. It also specifies a procedure for registering new types. In addition to this, one message type is reserved, and may be used for a future extension of the message type space. [STANDARDS-TRACK] This document is a product of the Protocol Independent Multicast Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From thomas.morin@orange-ftgroup.com Tue Apr 26 01:00:10 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE33E069B for ; Tue, 26 Apr 2011 01:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 438bo8ma377J for ; Tue, 26 Apr 2011 01:00:09 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 86D55E067C for ; Tue, 26 Apr 2011 01:00:09 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4213D8B8005 for ; Tue, 26 Apr 2011 10:00:43 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 375578B8003 for ; Tue, 26 Apr 2011 10:00:43 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 10:00:07 +0200 Received: from [10.193.71.121] ([10.193.71.121]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 10:00:07 +0200 Message-ID: <4DB67B86.2070009@orange-ftgroup.com> Date: Tue, 26 Apr 2011 10:00:06 +0200 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; ; ; ) Gecko/2010 Thunderbird/3.1.x MIME-Version: 1.0 To: pim@ietf.org References: <47951CBFA6409B4C8916514FCB05BFBE0C7F0E5F@xmb-sjc-219.amer.cisco.com> In-Reply-To: <47951CBFA6409B4C8916514FCB05BFBE0C7F0E5F@xmb-sjc-219.amer.cisco.com> X-TagToolbar-Keys: D20110426100006629 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 26 Apr 2011 08:00:07.0087 (UTC) FILETIME=[F512A3F0:01CC03E7] Subject: Re: [pim] additions to the charter X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 08:00:10 -0000 Yes to both additions! -Thomas Mike McBride (mmcbride) a écrit : > We have two proposed additions to our charter: > > "There is a significant number of errata that need to be addressed in > order to advance RFC4601 to Draft Standard. The PIM WG will correct the > errata, as necessary, and update RFC4601." > > and > > "The working group primarily works on extensions to PIM, but may take on > work related to IGMP/MLD." > > The igmp/mld addition is based upon a request from mboned wg. We either > reopen MAGMA or we take igmp/mld on in pim. During the Prague pimwg > meeting there was strong support to take on igmp/mld. > > Please provide a yay or nay or propose alternative text. > > Thanks, > mike > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim