From stig@venaas.com Thu Jun 2 09:47:59 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 CF0FFE081D for ; Thu, 2 Jun 2011 09:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vs8wEEu4hpu for ; Thu, 2 Jun 2011 09:47:58 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA93E081C for ; Thu, 2 Jun 2011 09:47:58 -0700 (PDT) Received: from [10.82.217.166] (rtp-isp-nat1.cisco.com [64.102.254.33]) by ufisa.uninett.no (Postfix) with ESMTPSA id 0A72E7FF7; Thu, 2 Jun 2011 18:47:55 +0200 (CEST) Message-ID: <4DE7BE15.50604@venaas.com> Date: Thu, 02 Jun 2011 09:45:09 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Mike McBride (mmcbride)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pim@ietf.org Subject: Re: [pim] draft-ietf-pim-hello-intid-00 wglc 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, 02 Jun 2011 16:47:59 -0000 On 20.05.2011 10:59, Mike McBride (mmcbride) wrote: > Today begins a two week wglc for draft-ietf-pim-hello-intid-00. Please > review the draft. Then indicate to us if its worthy, or not, of being > sent to the iesg. This wglc ends tomorrow and we only had one person responding so far. Could some of you please be so kind and say whether you think it's ready (also speak up if ready). Or let us know if anything should be changed. You guys have been really good at responding to wglc lately... Stig > > http://www.ietf.org/id/draft-ietf-pim-hello-intid-00.txt > > thanks, > mike > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From bill@cse.concordia.ca Thu Jun 2 10:39:58 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 81BEFE076F for ; Thu, 2 Jun 2011 10:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 7d5bBpTeNdx3 for ; Thu, 2 Jun 2011 10:39:57 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.94]) by ietfa.amsl.com (Postfix) with ESMTP id B8F53E0693 for ; Thu, 2 Jun 2011 10:39:55 -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 p52Hdr1T009193; Thu, 2 Jun 2011 13:39:54 -0400 Message-ID: <4DE7CAE9.9080606@cse.concordia.ca> Date: Thu, 02 Jun 2011 13:39:53 -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: Stig Venaas References: <4DE7BE15.50604@venaas.com> In-Reply-To: <4DE7BE15.50604@venaas.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/06/02 13:39:54 EDT Cc: pim@ietf.org Subject: Re: [pim] draft-ietf-pim-hello-intid-00 wglc 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, 02 Jun 2011 17:39:58 -0000 Stig, I agree that this draft is ready for the IESG, with the exception of two minor grammatical issues, and one ambiguity that I believe is worth correcting before it goes forward. Bill Section 2.1, para 1, line 6. "systems makes" -> "systems make" Section 2.2, para 1, line 7. "like" -> "such as" ("like" is for comparisons, "such as" introduces a list.") (Yes, I know, most North Americans don't know the difference, but I do...) :-) Section 4, para 1, line 4. What does "it" refer to? If it refers to "Hello messages", it should be "they". If it refers to "Interface Identifier", then replace "or it" with "which". On 6/2/2011 12:45 PM, Stig Venaas wrote: > On 20.05.2011 10:59, Mike McBride (mmcbride) wrote: >> Today begins a two week wglc for draft-ietf-pim-hello-intid-00. Please >> review the draft. Then indicate to us if its worthy, or not, of being >> sent to the iesg. > > This wglc ends tomorrow and we only had one person responding > so far. Could some of you please be so kind and say whether you > think it's ready (also speak up if ready). Or let us know if > anything should be changed. > > You guys have been really good at responding to wglc lately... > > Stig > >> >> http://www.ietf.org/id/draft-ietf-pim-hello-intid-00.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 -- 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 Thu Jun 2 10:47:25 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 5F035E0801 for ; Thu, 2 Jun 2011 10:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4OR3jmYGeoe for ; Thu, 2 Jun 2011 10:47:24 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF31E06FB for ; Thu, 2 Jun 2011 10:47:16 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p52HlE4u012714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Jun 2011 12:47:14 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 2 Jun 2011 13:47:13 -0400 From: Jeff Tantsura To: Stig Venaas , "Mike McBride (mmcbride)" Date: Thu, 2 Jun 2011 13:47:12 -0400 Thread-Topic: [pim] draft-ietf-pim-hello-intid-00 wglc Thread-Index: AcwhRNeo6+AAdBthRSyDZL5A68pT1wACCSNg Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60CAC308C09@EUSAACMS0701.eamcs.ericsson.se> References: <4DE7BE15.50604@venaas.com> In-Reply-To: <4DE7BE15.50604@venaas.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] draft-ietf-pim-hello-intid-00 wglc 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, 02 Jun 2011 17:47:25 -0000 Stig, I think it is ready for the IESG. Regards, Jeff =20 -----Original Message----- From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of Stig = Venaas Sent: Thursday, June 02, 2011 09:45 To: Mike McBride (mmcbride) Cc: pim@ietf.org Subject: Re: [pim] draft-ietf-pim-hello-intid-00 wglc On 20.05.2011 10:59, Mike McBride (mmcbride) wrote: > Today begins a two week wglc for draft-ietf-pim-hello-intid-00. Please > review the draft. Then indicate to us if its worthy, or not, of being > sent to the iesg. This wglc ends tomorrow and we only had one person responding so far. Could some of you please be so kind and say whether you think it's ready (also speak up if ready). Or let us know if anything should be changed. You guys have been really good at responding to wglc lately... Stig > > http://www.ietf.org/id/draft-ietf-pim-hello-intid-00.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 xiajinwei@huawei.com Wed Jun 1 02:24:32 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 30D83E0694 for ; Wed, 1 Jun 2011 02:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hf2cN4UnLzDj for ; Wed, 1 Jun 2011 02:24:31 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF54E073B for ; Wed, 1 Jun 2011 02:24:30 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LM300KICU4NH9@szxga05-in.huawei.com> for pim@ietf.org; Wed, 01 Jun 2011 17:24:24 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LM3006GBU4NV1@szxga05-in.huawei.com> for pim@ietf.org; Wed, 01 Jun 2011 17:24:23 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 01 Jun 2011 17:24:19 +0800 Received: from x65217 (10.138.41.84) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 01 Jun 2011 17:24:22 +0800 Date: Wed, 01 Jun 2011 17:24:22 +0800 From: Jinwei Xia X-Originating-IP: [10.138.41.84] To: 'Stig Venaas' Message-id: <002d01cc203d$b13869e0$54298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_czGHRxkAv3LWH4FoUK3qBg)" Thread-index: AcwgPbDU+LLkHPZeSAGdjVaopcIWag== X-Mailman-Approved-At: Thu, 02 Jun 2011 11:03:56 -0700 Cc: pim@ietf.org Subject: Re: [pim] Adoption of draft-asaeda-mboned-explicit-tracking-02 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, 01 Jun 2011 09:24:32 -0000 --Boundary_(ID_czGHRxkAv3LWH4FoUK3qBg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I support this work to be adopted! BR Jinwei >We seem to be in full agreement on adding the text allowing some IGMP >work to our charter. While we haven't officially rechartered yet, we >would like to hear from you whether you believe >draft-asaeda-mboned-explicit-tracking-02 >should be adopted, pending the charter update. > >Please let us know by the end of next week (June 3rd) whether it should >be adopted. > >If you have any concerns about the draft, please let us know what those >are as well. > >Stig > --Boundary_(ID_czGHRxkAv3LWH4FoUK3qBg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT 
 
I support this work to be adopted!
 
 
BR
Jinwei
 
>We seem to be in full agreement on adding the text allowing some IGMP
>work to our charter. While we haven't officially rechartered yet, we
>would like to hear from you whether you believe
>draft-asaeda-mboned-explicit-tracking-02
>should be adopted, pending the charter update.
>
>Please let us know by the end of next week (June 3rd) whether it should
>be adopted.
>
>If you have any concerns about the draft, please let us know what those
>are as well.
>
>Stig
>
--Boundary_(ID_czGHRxkAv3LWH4FoUK3qBg)-- From michael.brig@mda.mil Wed Jun 1 06:46:51 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 D9EBBE0835 for ; Wed, 1 Jun 2011 06:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fisDePcdi5L9 for ; Wed, 1 Jun 2011 06:46:51 -0700 (PDT) Received: from sce-uth30.mda.mil (sce-uth30.mda.mil [140.32.120.156]) by ietfa.amsl.com (Postfix) with ESMTP id 59830E06F6 for ; Wed, 1 Jun 2011 06:46:51 -0700 (PDT) Received: from SCE-CHA30.one.mda.mil (sce-cha30 [10.14.128.41]) by sce-uth30.mda.mil (Postfix) with ESMTP id DBB4A4896 for ; Wed, 1 Jun 2011 13:46:44 +0000 (GMT) Received: from ONE-ALL30.one.mda.mil ([10.14.128.11]) by SCE-CHA30.one.mda.mil ([10.14.128.41]) with mapi; Wed, 1 Jun 2011 07:46:43 -0600 From: "Brig, Michael P CIV MDA/AB" To: "pim@ietf.org" Date: Wed, 1 Jun 2011 07:46:41 -0600 Thread-Topic: https://datatracker.ietf.org/doc/draft-brigm-deterministicrp/ Thread-Index: AcwgYlWHrg5L8d2RTL+9i/b5MyOZAA== Message-ID: <56CBEF6EA3217F48921C855DFD77822114D644343E@ONE-ALL30.one.mda.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_09A2_01CC2040.CE7CE870" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 02 Jun 2011 11:03:56 -0700 Cc: "Schlise, Charles A LCDR MDA/AB" , "Chaney, Jeffrey L CIV MDA/AB" Subject: [pim] https://datatracker.ietf.org/doc/draft-brigm-deterministicrp/ 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, 01 Jun 2011 13:49:44 -0000 ------=_NextPart_000_09A2_01CC2040.CE7CE870 Content-Type: multipart/alternative; boundary="----=_NextPart_001_09A3_01CC2040.CE7CE870" ------=_NextPart_001_09A3_01CC2040.CE7CE870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please accept the following Internet Draft (ID) as a potential candidate for IETF standardization with the PIM WG. Comments for improvement would be greatly appreciated. Respectfully, Michael Brig BMC4I Engineer AEGIS BMD 540-663-1919 Michael.brig@mda.mil ------=_NextPart_001_09A3_01CC2040.CE7CE870 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please = accept the following Internet Draft (ID) as a potential candidate for = IETF standardization with the PIM WG.  Comments for improvement = would be greatly appreciated.

 

Respectfully,

 

Michael = Brig

BMC4I Engineer

AEGIS BMD

540-663-1919

Michael.brig@mda.mil

------=_NextPart_001_09A3_01CC2040.CE7CE870-- ------=_NextPart_000_09A2_01CC2040.CE7CE870 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISwjCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtDCCA5ygAwIBAgIDCjPMMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjYwHhcNMTAxMDEyMDAwMDAwWhcN MTMxMDExMjM1OTU5WjB7MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNOMSgwJgYDVQQDEx9CUklHLk1J Q0hBRUwuUEFUUklDSy4xMDY4NDY0Nzg4MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA x6QmDoe/8fZWAo4wOzi6Z9uTwA2DRnP6yhgOj1dWKMo38kNczxSHmGRE8VVxZ5frzNmh3lSDnNT5 OnHjDMrH9Cz5AyEEXQpkhQGWwDoOm0+nRfIFrF7c6Fl9Uv5OtR46o2tZQVwtQnv7OcuOz4ITR58N SUbmCKslHcMU27S6muzCT/7SqbatDL+z3LzPLMCsI15rpqwQU+g9OfgD+8v1RCsg9lM0PCEmNWyj qpoDrdtcZJhtS+7GRO0KZHT3iqQRUE9d/pAumHBHbKlqMK+dSAzO0iT9BpeT+MXDWtJgyoH9F4/i tDAsC2q9MHJ+HPLXH4UyLKfPpKRe1HF9WdZq7QIDAQABo4IBXTCCAVkwHwYDVR0jBBgwFoAUMt/I bfP/Pin96QyXKVDwohAsbi8wOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2NybC5kaXNhLm1pbC9j cmwvRE9ERU1BSUxDQV8yNi5jcmwwDgYDVR0PAQH/BAQDAgUgMCMGA1UdIAQcMBowCwYJYIZIAWUC AQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUNq1knigraBlb7urxRe+1PbDc7RUwaAYIKwYBBQUH AQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24vRE9ERU1BSUxDQV8y Ni5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMB8GA1UdEQQYMBaBFG1pY2hh ZWwuYnJpZ0BtZGEubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcNAQEF BQADggEBAFVN7R4UGN3WU1RJQ4hnOrsqAROGBmVKW8YyOVxTc2s+B7KYu93kINr/vYdbsNF93s4W CZ1gV1Y1rdavY/bYogZETYTl00ZNhFq1tEf/HjuxlxACvSh6Xa9DBZ1Q5mrt94Ls4lkGG9rRQIzJ ZTfA/8YafvgQFtErsYJ+UQx1UW8vK69mgzcN7UqVoKidfqJHH7zEK0H9zc8vXS+9UiU4uniqDbK/ i5so3nrE+UJtcNCpYxznHBGCgJfhCfwjDbXCzKY3hV/s7g9nRUPpR7fG2rrpVfWZ293snnx0G5/6 la0hmlEBXveo8v+JcW63clXgyy3Rza+NBBwWms7CYvJNqEowggT/MIID56ADAgECAgMKM8cwDQYJ KoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoG A1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yNjAeFw0xMDEw MTIwMDAwMDBaFw0xMzEwMTEyMzU5NTlaMHsxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU04xKDAmBgNV BAMTH0JSSUcuTUlDSEFFTC5QQVRSSUNLLjEwNjg0NjQ3ODgwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC4B3gnMgMohV307MCtx349xCQzb+4TjPXPsdNezPUx15YZkvyU96+RuCymXBXW 2ofG9ADJNbZFGFllg7lXaQV8hwNBgqKKIbOngko0nUR5v/JwOuIyiANoClYv8FGv2CKrMYYcMiEB e1k1RqfVLp5E5+c+5pMnxJjGj9yzHXVjt6veJawSE1bZNeF6ahRcjOsbSd6WLXTuOLcAtKqdIXUI Q6cj130N2Fou+l2l3MeJeS/8hOicO8Hg98TViAsEvP2xtMwcII9Ww2bM+IfZwGfw4Pfs4zVWaaK1 WAqU607LPPd07LDKFQ1eOHVnieOHcr5GYZUL1OgR+RPjReZ2lRIlAgMBAAGjggGoMIIBpDAfBgNV HSMEGDAWgBQy38ht8/8+Kf3pDJcpUPCiECxuLzA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3Js LmRpc2EubWlsL2NybC9ET0RFTUFJTENBXzI2LmNybDAOBgNVHQ8BAf8EBAMCBsAwIwYDVR0gBBww GjALBglghkgBZQIBCwkwCwYJYIZIAWUCAQsTMB0GA1UdDgQWBBSqkUh9jDsMVeP94/GMvsvtFvJA KDBoBggrBgEFBQcBAQRcMFowNgYIKwYBBQUHMAKGKmh0dHA6Ly9jcmwuZGlzYS5taWwvc2lnbi9E T0RFTUFJTENBXzI2LmNlcjAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwPwYDVR0R BDgwNoEUbWljaGFlbC5icmlnQG1kYS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMDY4NDY0Nzg4QG1p bDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEARR8Pjd/p6h8cfMa88qvbnjr3Z9r5 EFxhg5ZWjQOfDZ7czF3ouD7OBaOfpxuNPHIGf+fe6GASflkAclsQYAQkQ9aKmLlfUfgacDpkCuV0 imnvXe4QgzmuSI8L2ffxj+aTJIOy+ZEB5XiMFrSJdny6fYdz6nZ7+/cLo1oEwLLO3mzz9AtWJnkv x4Su3pctsVGtLsJ4f0VnORrEAfPDvKKm0yw9SypTfsR3N6lJBF6G4VUig2uX/y6ZfqGORfCwNO58 NkF4fByF7utN5xXDhBYKTnugvRYE5AK/eLhWiIX5ONOCFz37Lycyyk7qEIs6pAfvO9FztDsn6gfS gezuqkbRcjCCBY8wggR3oAMCAQICAVEwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAW BgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNV BAMTDURvRCBSb290IENBIDIwHhcNMTAwMTE0MTczOTI3WhcNMTYwMTE0MTczOTI3WjBdMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsT A1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTI2MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArF8QWz0qB/3uz07GsE49WqAAYFB5wgJFZk84NIFcHL8nYGp5zKaXC9aJ5tjblXxXOgfu RuVkKhMXjx0w/C36Nn83YSTlFKL9IlccYa5NLgNQZlVG3Won+Kl5q1wq5SVdXBv7cQ+1uBWPX5R7 A8/uq5IICuS9o6Fdg9c9x5/URBA6ol9f5IaUbwOgNfOD2OG4GZ96unXPAAXQ2yOkaiXXaXBFxl14 iwdfRayd1qNLXRjPj0wKEaHZEdv5nKXVj5zqD0e9JYKU+WCSShT4upupbN/KFRGhizm++hlNvLsU b91gfbKckAd8gEe5hYy4PqN1ua5ed5FzwXWJVbpNhuStuwIDAQABo4ICWjCCAlYwDgYDVR0PAQH/ BAQDAgGGMB8GA1UdIwQYMBaAFEl0uwxeunr+AlTve6DGlcYJgHCWMB0GA1UdDgQWBBQy38ht8/8+ Kf3pDJcpUPCiECxuLzAMBgNVHSQEBTADgAEAMBIGA1UdEwEB/wQIMAYBAf8CAQAwgZ8GA1UdIASB lzCBlDALBglghkgBZQIBCwUwCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELCjALBglghkgBZQIBCxIw CwYJYIZIAWUCAQsTMAsGCWCGSAFlAgELFDAMBgpghkgBZQMCAQMGMAwGCmCGSAFlAwIBAwcwDAYK YIZIAWUDAgEDCDAMBgpghkgBZQMCAQMNMAwGCmCGSAFlAwIBAxEwPwYDVR0fBDgwNjA0oDKgMIYu aHR0cDovL2NybC5kaXNhLm1pbC9nZXRjcmw/RG9EJTIwUm9vdCUyMENBJTIwMjCB/gYIKwYBBQUH AQEEgfEwge4wPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0SXNzdWVkVG8/RG9E JTIwUm9vdCUyMENBJTIwMjAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgYgGCCsG AQUFBzAChnxsZGFwOi8vY3JsLmdkcy5kaXNhLm1pbC9jbiUzZERvRCUyMFJvb3QlMjBDQSUyMDIl MmNvdSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2NB Q2VydGlmaWNhdGU7YmluYXJ5MA0GCSqGSIb3DQEBBQUAA4IBAQBqwFAphPjcZxOxlu66XNTlkvnN ZGUzhSgLoBqrUx2MQBeRumbaa2u8rI5hAcNnNRFZUoVwXaGG53rBHMPYXst3u8xc3BrdBF/6iO2z brW0RMs6NZ2gThzARbX21M0GedIaOewlJnGc2bhvk2zWOzQ7Z5mqX6W4bUzHCerJwHSZ2VmLKYmQ K4GV2Yf9VfhYdVKmfyJobYXWfa6KDS80v9cobMZbrbz/GzrGZIWknH2ElZ+oA2Xkf03MDHV6SgVE WICLOTRPMz8rRPHWdO/vfJrY3AsYPfLlnVA7Iynl9M9g6mBPHGDBGrKcWgIEsHzByRVq2yqvCwi7 PnF6pjzlHUQiMYIDMjCCAy4CAQEwZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zl cm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENB LTI2AgMKM8cwCQYFKw4DAhoFAKCCAaMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTEwNjAxMTM0NjQwWjAjBgkqhkiG9w0BCQQxFgQUiizGvDLMRxRs1HLRN564DL33 0/kwWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwcwYJKwYBBAGCNxAEMWYwZDBdMQsw CQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNV BAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTI2AgMKM8wwdQYLKoZIhvcNAQkQAgsxZqBk MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjYCAwozzDANBgkqhkiG9w0BAQEF AASCAQCwlDLtFaW9/H+spPoQ4FVggkuuGev/9tWOuKvJQx1Vfv2YjFJrZOL5m4SOhccdiWEVc8mc Xm8qHq8pyCSv6/YNo/xVZCOTouS9b/sIghP8dZOqYER3WMI+qQ1Om/PSZr6G5lsJSKqCtCyRj5fb uvdF2YARd+xDGHwzMx5MXZO0BPIcxj4hpAbobwdfOrx5F3+E/8i1btxrEOQRBe9bt0qsp23knkwN 6PujPgyZccfunu7oUbNgI4AqR+HsxGGcrKzgnT+avdhHj4+KdNi/mDKWqrwrkm4QY83PrRIjef5N d50bc1GW5RR8wsJDJvdPn2RIUHQ1x7Wijj+3RhGaX771AAAAAAAA ------=_NextPart_000_09A2_01CC2040.CE7CE870-- From stig@venaas.com Mon Jun 6 13:30:57 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 A324F11E817D for ; Mon, 6 Jun 2011 13:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2fREFgUnbrc for ; Mon, 6 Jun 2011 13:30:57 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDBC11E8071 for ; Mon, 6 Jun 2011 13:30:56 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:d5b1:a9d0:69ef:c62e] (unknown [IPv6:2001:420:4:ea0c:d5b1:a9d0:69ef:c62e]) by ufisa.uninett.no (Postfix) with ESMTPSA id 39C757FC2; Mon, 6 Jun 2011 22:30:54 +0200 (CEST) Message-ID: <4DED38FB.2090802@venaas.com> Date: Mon, 06 Jun 2011 13:30:51 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bill Atwood References: <4DE7BE15.50604@venaas.com> <4DE7CAE9.9080606@cse.concordia.ca> In-Reply-To: <4DE7CAE9.9080606@cse.concordia.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pim@ietf.org Subject: Re: [pim] draft-ietf-pim-hello-intid-00 wglc 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, 06 Jun 2011 20:30:57 -0000 Hi Bill On 6/2/2011 10:39 AM, Bill Atwood wrote: > Stig, > > I agree that this draft is ready for the IESG, with the exception of two > minor grammatical issues, and one ambiguity that I believe is worth > correcting before it goes forward. > > Bill > > Section 2.1, para 1, line 6. "systems makes" -> "systems make" > > Section 2.2, para 1, line 7. "like" -> "such as" ("like" is for > comparisons, "such as" introduces a list.") (Yes, I know, most North > Americans don't know the difference, but I do...) :-) You're right. And I'm aware of it, although I'm so used to abusing "like". > Section 4, para 1, line 4. What does "it" refer to? If it refers to > "Hello messages", it should be "they". If it refers to "Interface > Identifier", then replace "or it" with "which". Since it says "it" and not "they" I thought it was clear it was the identifier... Using "which" is not what I want. I'm trying to say that someone might try to do an attack where they send hello messages that either may contain some arbitrary interface ID value, or they may omit the value, when a hello with a value is expected. Although it doesn't read so well I've now replaced that "it" with "the Interface Identifier". The sentence is now In particular, PIM Hello messages may be forged, and may include an arbitrary Interface Identifier, or the Interface Identifier may be intentionally omitted. Maybe this sentence should be a bit different? Should "intentionally" be replaced? Maybe "intentionally" can be omitted? Thanks for your review Bill, appreciated. Stig > > On 6/2/2011 12:45 PM, Stig Venaas wrote: >> On 20.05.2011 10:59, Mike McBride (mmcbride) wrote: >>> Today begins a two week wglc for draft-ietf-pim-hello-intid-00. Please >>> review the draft. Then indicate to us if its worthy, or not, of being >>> sent to the iesg. >> >> This wglc ends tomorrow and we only had one person responding >> so far. Could some of you please be so kind and say whether you >> think it's ready (also speak up if ready). Or let us know if >> anything should be changed. >> >> You guys have been really good at responding to wglc lately... >> >> Stig >> >>> >>> http://www.ietf.org/id/draft-ietf-pim-hello-intid-00.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 tom111.taylor@bell.net Mon Jun 6 13:44:06 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 2E82D11E81AB for ; Mon, 6 Jun 2011 13:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.796 X-Spam-Level: X-Spam-Status: No, score=-101.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, 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 XHe8J9art5cm for ; Mon, 6 Jun 2011 13:44:05 -0700 (PDT) Received: from blu0-omc4-s27.blu0.hotmail.com (blu0-omc4-s27.blu0.hotmail.com [65.55.111.166]) by ietfa.amsl.com (Postfix) with ESMTP id 22DF611E8191 for ; Mon, 6 Jun 2011 13:44:05 -0700 (PDT) Received: from BLU0-SMTP17 ([65.55.111.136]) by blu0-omc4-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Jun 2011 13:44:04 -0700 X-Originating-IP: [76.70.76.63] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([76.70.76.63]) by BLU0-SMTP17.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Jun 2011 13:44:03 -0700 Date: Mon, 6 Jun 2011 16:44:03 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: pim@ietf.org References: <4DE7BE15.50604@venaas.com> <4DE7CAE9.9080606@cse.concordia.ca> <4DED38FB.2090802@venaas.com> In-Reply-To: <4DED38FB.2090802@venaas.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jun 2011 20:44:03.0872 (UTC) FILETIME=[78DCBA00:01CC248A] Subject: Re: [pim] draft-ietf-pim-hello-intid-00 wglc 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, 06 Jun 2011 20:44:06 -0000 I think your new phrasing is good, even if it seems redundant to your ear. On 06/06/2011 4:30 PM, Stig Venaas wrote: > Hi Bill > > On 6/2/2011 10:39 AM, Bill Atwood wrote: >> Stig, >> >> I agree that this draft is ready for the IESG, with the exception of two >> minor grammatical issues, and one ambiguity that I believe is worth >> correcting before it goes forward. >> >> Bill >> >> Section 2.1, para 1, line 6. "systems makes" -> "systems make" >> >> Section 2.2, para 1, line 7. "like" -> "such as" ("like" is for >> comparisons, "such as" introduces a list.") (Yes, I know, most North >> Americans don't know the difference, but I do...) :-) > > You're right. And I'm aware of it, although I'm so used to abusing > "like". > >> Section 4, para 1, line 4. What does "it" refer to? If it refers to >> "Hello messages", it should be "they". If it refers to "Interface >> Identifier", then replace "or it" with "which". > > Since it says "it" and not "they" I thought it was clear it was the > identifier... Using "which" is not what I want. I'm trying to say that > someone might try to do an attack where they send hello messages that > either may contain some arbitrary interface ID value, or they may omit > the value, when a hello with a value is expected. Although it doesn't > read so well I've now replaced that "it" with "the Interface Identifier". > > The sentence is now > > In particular, PIM Hello messages may be forged, and may include an > arbitrary Interface Identifier, or the Interface Identifier may be > intentionally omitted. > > Maybe this sentence should be a bit different? Should "intentionally" > be replaced? Maybe "intentionally" can be omitted? > > Thanks for your review Bill, appreciated. > > Stig > >> >> On 6/2/2011 12:45 PM, Stig Venaas wrote: >>> On 20.05.2011 10:59, Mike McBride (mmcbride) wrote: >>>> Today begins a two week wglc for draft-ietf-pim-hello-intid-00. Please >>>> review the draft. Then indicate to us if its worthy, or not, of being >>>> sent to the iesg. >>> >>> This wglc ends tomorrow and we only had one person responding >>> so far. Could some of you please be so kind and say whether you >>> think it's ready (also speak up if ready). Or let us know if >>> anything should be changed. >>> >>> You guys have been really good at responding to wglc lately... >>> >>> Stig >>> >>>> >>>> http://www.ietf.org/id/draft-ietf-pim-hello-intid-00.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 >> > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > > From bill@cse.concordia.ca Mon Jun 6 15:55:12 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 1F0CB21F84AF for ; Mon, 6 Jun 2011 15:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 X7naKfvStGg0 for ; Mon, 6 Jun 2011 15:55:11 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.94]) by ietfa.amsl.com (Postfix) with ESMTP id D90A121F84AC for ; Mon, 6 Jun 2011 15:55:10 -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 p56Mt839019653; Mon, 6 Jun 2011 18:55:08 -0400 Message-ID: <4DED5ACD.5060105@cse.concordia.ca> Date: Mon, 06 Jun 2011 18:55:09 -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: Stig Venaas References: <4DE7BE15.50604@venaas.com> <4DE7CAE9.9080606@cse.concordia.ca> <4DED38FB.2090802@venaas.com> In-Reply-To: <4DED38FB.2090802@venaas.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/06/06 18:55:09 EDT Cc: pim@ietf.org Subject: Re: [pim] draft-ietf-pim-hello-intid-00 wglc 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, 06 Jun 2011 22:55:12 -0000 Stig, I agree, my change did not express what you wanted to express. However, your new version does, and the "intentionally" is also important, since it emphasizes the "bad behavior" aspect. So, I agree with Tom, your phrasing is good. Bill On 6/6/2011 4:30 PM, Stig Venaas wrote: > Hi Bill > > On 6/2/2011 10:39 AM, Bill Atwood wrote: >> Stig, >> >> I agree that this draft is ready for the IESG, with the exception of two >> minor grammatical issues, and one ambiguity that I believe is worth >> correcting before it goes forward. >> >> Bill >> >> Section 2.1, para 1, line 6. "systems makes" -> "systems make" >> >> Section 2.2, para 1, line 7. "like" -> "such as" ("like" is for >> comparisons, "such as" introduces a list.") (Yes, I know, most North >> Americans don't know the difference, but I do...) :-) > > You're right. And I'm aware of it, although I'm so used to abusing > "like". > >> Section 4, para 1, line 4. What does "it" refer to? If it refers to >> "Hello messages", it should be "they". If it refers to "Interface >> Identifier", then replace "or it" with "which". > > Since it says "it" and not "they" I thought it was clear it was the > identifier... Using "which" is not what I want. I'm trying to say that > someone might try to do an attack where they send hello messages that > either may contain some arbitrary interface ID value, or they may omit > the value, when a hello with a value is expected. Although it doesn't > read so well I've now replaced that "it" with "the Interface Identifier". > > The sentence is now > > In particular, PIM Hello messages may be forged, and may include an > arbitrary Interface Identifier, or the Interface Identifier may be > intentionally omitted. > > Maybe this sentence should be a bit different? Should "intentionally" > be replaced? Maybe "intentionally" can be omitted? > > Thanks for your review Bill, appreciated. > > Stig > >> >> On 6/2/2011 12:45 PM, Stig Venaas wrote: >>> On 20.05.2011 10:59, Mike McBride (mmcbride) wrote: >>>> Today begins a two week wglc for draft-ietf-pim-hello-intid-00. Please >>>> review the draft. Then indicate to us if its worthy, or not, of being >>>> sent to the iesg. >>> >>> This wglc ends tomorrow and we only had one person responding >>> so far. Could some of you please be so kind and say whether you >>> think it's ready (also speak up if ready). Or let us know if >>> anything should be changed. >>> >>> You guys have been really good at responding to wglc lately... >>> >>> Stig >>> >>>> >>>> http://www.ietf.org/id/draft-ietf-pim-hello-intid-00.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 >> -- 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 stig@venaas.com Tue Jun 7 13:17:03 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 DE68011E8150 for ; Tue, 7 Jun 2011 13:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csdQcdo7AWZy for ; Tue, 7 Jun 2011 13:17:02 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id E88C111E8131 for ; Tue, 7 Jun 2011 13:17:00 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:45e6:5479:4d1c:d9ae] (unknown [IPv6:2001:420:4:ea0c:45e6:5479:4d1c:d9ae]) by ufisa.uninett.no (Postfix) with ESMTPSA id E4E4F8018; Tue, 7 Jun 2011 22:16:56 +0200 (CEST) Message-ID: <4DEE8740.4010106@venaas.com> Date: Tue, 07 Jun 2011 13:17:04 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bharat Joshi References: <31D55C4D55BEED48A4459EB64567589A115E3C9ED3@BLRKECMBX02.ad.infosys.com> In-Reply-To: <31D55C4D55BEED48A4459EB64567589A115E3C9ED3@BLRKECMBX02.ad.infosys.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "Mike McBride \(mmcbride\)" , "pim@ietf.org" Subject: Re: [pim] draft-ietf-pim-hello-intid-00 wglc 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, 07 Jun 2011 20:17:03 -0000 On 5/23/2011 8:54 AM, Bharat Joshi wrote: > Hi Stig, > > I have few suggestions below, almost all minors on this draft. > > Mike, > I think this is ready for the next level. > > Thanks, > Bharat > > • Should we use "interface id" or "interface identifier" in Abstract? Identifier seems better, fixed. > • In following sentence in Introduction: > > The identifiers can optionally be generated so that they are unique within, e.g., an administrative domain. > > will 'such that' instead of 'so that' be better? Yes, think so. Changed that a couple of places. > • Should we move the second part of introduction to another section called 'Use cases'? I think I'll leave it as it is. The introduction is fairly short anyway. > • In following statement: > > It is assumed that different protocols may have different minimum requirements for stability and uniqueness, but that they have no maximum requirement. > > Can we use 'Interface identifier' as follows: > > It is assumed that different protocols may have different minimum requirements for stability and uniqueness of the interface identifier, but that they have no maximum requirement. Better, thanks. > • Following statement: > > If an interface goes down and up, the router SHOULD use the same Identifier. > > to > > If an interface goes down and comes up, the router SHOULD use the same Identifier. Yes > • In Message format, can we move explanation of 'Router Identifier' before 'Local Interface Identifier' to keep it consistent with format? Yes > • Should not PIM-Port be normative reference for this work? I'm keeping it as an informative reference. It helps understand why this option is needed, but it is not needed for implementing this option. Thanks, I'll submit a new version based on this right away. Stig > ________________________________________ > From: pim-bounces@ietf.org [pim-bounces@ietf.org] On Behalf Of Mike McBride (mmcbride) [mmcbride@cisco.com] > Sent: Friday, May 20, 2011 11:29 PM > To: pim@ietf.org > Subject: [pim] draft-ietf-pim-hello-intid-00 wglc > > Today begins a two week wglc for draft-ietf-pim-hello-intid-00. Please > review the draft. Then indicate to us if its worthy, or not, of being > sent to the iesg. > > http://www.ietf.org/id/draft-ietf-pim-hello-intid-00.txt > > thanks, > mike > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely > for the use of the addressee(s). If you are not the intended recipient, please > notify the sender by e-mail and delete the original message. Further, you are not > to copy, disclose, or distribute this e-mail or its contents to any other person and > any such actions are unlawful. This e-mail may contain viruses. Infosys has taken > every reasonable precaution to minimize this risk, but is not liable for any damage > you may sustain as a result of any virus in this e-mail. You should carry out your > own virus checks before opening the e-mail or attachment. Infosys reserves the > right to monitor and review the content of all messages sent to or from this e-mail > address. Messages sent to or from this e-mail address may be stored on the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From internet-drafts@ietf.org Tue Jun 7 13:30:25 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 50FBD11E8202; Tue, 7 Jun 2011 13:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hqPBKWRbo-7; Tue, 7 Jun 2011 13:30:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BAE11E8131; Tue, 7 Jun 2011 13:30:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110607203024.24711.79227.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2011 13:30:24 -0700 Cc: pim@ietf.org Subject: [pim] I-D Action: draft-ietf-pim-hello-intid-01.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 20:30:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol Independent Multicast Workin= g Group of the IETF. Title : An Interface ID Hello Option for PIM Author(s) : Sameer Gulrajani Stig Venaas Filename : draft-ietf-pim-hello-intid-01.txt Pages : 11 Date : 2011-06-07 This document defines a new PIM Hello option to advertise an interface identifier 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-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pim-hello-intid-01.txt From stig@venaas.com Tue Jun 7 13:35:24 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 F36CF11E81C4 for ; Tue, 7 Jun 2011 13:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PTR8NXXPwrq for ; Tue, 7 Jun 2011 13:35:23 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 0A73811E81A5 for ; Tue, 7 Jun 2011 13:35:23 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:45e6:5479:4d1c:d9ae] (unknown [IPv6:2001:420:4:ea0c:45e6:5479:4d1c:d9ae]) by ufisa.uninett.no (Postfix) with ESMTPSA id 131D07FC9 for ; Tue, 7 Jun 2011 22:35:20 +0200 (CEST) Message-ID: <4DEE8B85.3070609@venaas.com> Date: Tue, 07 Jun 2011 13:35:17 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: pim@ietf.org References: <20110607203024.24711.79227.idtracker@ietfa.amsl.com> In-Reply-To: <20110607203024.24711.79227.idtracker@ietfa.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-01.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 20:35:24 -0000 This new version has editorial changes based on the review comments from Bharat and Bill in the last call. The only other changes are the acknowledgments, and the IANA considerations. The IANA considerations are now: IANA has temporarily assigned the value 31 for the Interface Identifier Hello option defined in this document. IANA is requested to make this assignment permanent. In a few minutes when the tools database is updated, you can see the document and get a diff of the changes at http://tools.ietf.org/wg/pim/draft-ietf-pim-hello-intid/ Stig From internet-drafts@ietf.org Thu Jun 9 18:58:55 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 5036A11E811D; Thu, 9 Jun 2011 18:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6IrIpTVa5eP; Thu, 9 Jun 2011 18:58:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA38C11E8073; Thu, 9 Jun 2011 18:58:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110610015854.4480.13823.idtracker@ietfa.amsl.com> Date: Thu, 09 Jun 2011 18:58:54 -0700 Cc: pim@ietf.org Subject: [pim] I-D Action: draft-ietf-pim-mtid-08.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, 10 Jun 2011 01:58:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol Independent Multicast Workin= g Group of the IETF. Title : PIM Multi-Topology ID (MT-ID) Join Attribute Author(s) : Yiqun Cai Heidi Ou Filename : draft-ietf-pim-mtid-08.txt Pages : 13 Date : 2011-06-09 This document introduces a new type of PIM Join Attribute that extends PIM signaling to identify a topology that should be used when constructing a particular multicast distribution tree. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-mtid-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pim-mtid-08.txt From ycai@cisco.com Thu Jun 9 19:28:12 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 3962911E814B for ; Thu, 9 Jun 2011 19:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 YHGTDSXwCFWp for ; Thu, 9 Jun 2011 19:28:10 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9DE11E80E3 for ; Thu, 9 Jun 2011 19:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ycai@cisco.com; l=16981; q=dns/txt; s=iport; t=1307672890; x=1308882490; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=sny4L0mOLtDe4Y0Dz7+mB9aYIEINjziL2eCme3KB5yQ=; b=enSCE2JUsMky+gaErIHABOmmzRK4Y55V2d2tGwzzAvhWUX7tOvSh7ro6 OrqNJRIMfqjjDuW5z2QZloE6HXrn2Km5DF1mF8pmj/6lbzH+8422XQCfS hPPqpKN40wI1AkAjTF2qBLDMle4RXUHjWdnltb+pIRSpgbQX2zK7Ho8x+ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4GABuA8U2rRDoJ/2dsb2JhbABTiRKdLgJ3iHGgHp4NhiMEhwiKI4RXhyCDfw X-IronPort-AV: E=Sophos;i="4.65,344,1304294400"; d="scan'208";a="373917078" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 10 Jun 2011 02:28:09 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5A2SAlw015372; Fri, 10 Jun 2011 02:28:10 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Jun 2011 19:28:09 -0700 Received: from 128.107.161.228 ([128.107.161.228]) by xmb-sjc-216.amer.cisco.com ([171.70.151.184]) with Microsoft Exchange Server HTTP-DAV ; Fri, 10 Jun 2011 02:28:09 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Thu, 09 Jun 2011 19:28:06 -0700 From: Yiqun Cai To: , Message-ID: Thread-Topic: AD review of draft-ietf-pim-mtid-07.txt Thread-Index: AcwBLqNePNSvAqjaTxqExg2kmxG45gl52RmH In-Reply-To: <0b9901cc012e$f9950c80$ecbf2580$@huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Jun 2011 02:28:09.0988 (UTC) FILETIME=[0A254440:01CC2716] Cc: pim@ietf.org, pim-chairs@tools.ietf.org Subject: Re: [pim] AD review of draft-ietf-pim-mtid-07.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, 10 Jun 2011 02:28:12 -0000 Adrian, Many thanks for the detailed comment. We have studied carefully and updated the document accordingly. A new version, -08, has been uploaded. More inline. On 4/22/11 1:50 PM, "Adrian Farrel" wrote: > --- > > 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. > > --- Done. > > 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. We have incorporated most of the text (the wording might be slightly different in a few places). Having a native speaker reviewing and suggesting text is greatly appreciated. In fact, many text that you supplied was taken "literally" in the -08 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. > Done > --- > > 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. > The comment was accepted. This section was also expanded significantly. An example was added too. The purpose of the modification is to clarify the relationship between PIM MT-ID and IGP MT-ID, and describe possible use of PIM MT-ID. Some of the description was communicated at Minneapolis IETF (the first IETF the idea was presented) and San Francisco IETF. But it wasn't captured in text, which we are doing now, hoping to clarify the confusions. > --- > > 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? No I can't. In fact, the issue of inconsistency exists today with PIM, and without the use of MT. That is due to the very nature of PIM which doesn't build its own topology like DVMRP or MOSPF does. The only thing that can be guaranteed is that the IGP routes imported in the RPF topology is loop-free. However, different routers may use different policies to build their own RPF topology, the potential of something bad happening is always there, with or without MT. We had lots of discussion on this topic on the mailing list last year. Some text in the draft was a result of contribution (and compromise) made by several of us, including Dimitri, Thomas and Hui. > > --- > > 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? Done. > > > --- > > Please select consistent terminology. I see > - Join-Attribute > - Join Attribute > - join attribute > Done. > --- > > 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? PIM MT-ID is assigned by operators, not generated automatically. The revised section 3.1 describes an example how it can be done. Hope that helps. > > 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. > Done. > --- > > 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. > Done > --- > > 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). > > Modified the text as suggested. > --- > > 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)." Done as suggested. > > --- > > Section 4.2.1 > > Please start the bullets with capital letters as they are sentences. > Done. > - 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 ..." > More text has been added in -08 to clarify the point. > --- > > 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. > The description has been added to -08. > 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. > The description has also been added. However, it is different than 4.2.3. This paragraph is about a router which can parse the attribute but choose not to tell others it can. While 4.2.3 is about a router who can parse the attribute but receive the attribute from another router which doesn't claim it supports this document. So we still keep the text in 4.2.3 where it is. > 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". > Yes it is MUST. > --- > > 4.2.3 > > Aren't you missing text for the case of pruned sources per 4.2.1? > The description for handling MT-ID in the pruned sources was added to 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. > Thanks for the suggestion. The text is used in -08. > > > 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. > > --- Done. > > 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? > We usually say Join/Prune together because they use the same message type. However we did make an attempt in -08 to be clear about whether we are dealing with a Join source or a Prune source. > --- > > 5.2 > > - Attr Type: 3. > > This should read: > > - Attr Type: Done. > > --- > > 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 > We discussed a little bit among us and decided to remove "experimental and proprietary use". The use case we initially discussed doesn't mandate the use of a "private" range. And having it creates more problems than it solves. > 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? You caught a very good point here. The use of mt-topology for "multicast" has been evolving quite a bit since MT came to the world maybe 10 years ago. If I understand properly, the multicast topology specified by RFC4915 means that topology SHOULD NOT be used by unicast. I'm not sure if all implementations honor that rule. On the other hand, MT for PIM doesn't depend on this particular "multicast topology" described in 4915. Routes in any topology can be used for RPF. And this is explained in the new Section 3.1. Please let us know if it is still not clear. > > --- > > Section 6 > > The IANA section needs some work! > > Thanks for the text. They are taken "literally" ;) > --- > > 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: > > Same as above. > --- > > Section 11 > > You no longer need the reference [HELLO] > Done. Thanks again. -- Yiqun From stig@venaas.com Fri Jun 10 10:50:46 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 3402411E8173 for ; Fri, 10 Jun 2011 10:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1pkDOMLAoKf for ; Fri, 10 Jun 2011 10:50:44 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 6C51A11E8138 for ; Fri, 10 Jun 2011 10:50:43 -0700 (PDT) Received: from [10.21.78.24] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id 79CCA7FF0; Fri, 10 Jun 2011 19:50:38 +0200 (CEST) Message-ID: <4DF258D4.2070907@venaas.com> Date: Fri, 10 Jun 2011 10:48:04 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Yiqun Cai References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-pim-mtid@tools.ietf.org, pim@ietf.org, pim-chairs@tools.ietf.org Subject: Re: [pim] AD review of draft-ietf-pim-mtid-07.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, 10 Jun 2011 17:50:46 -0000 On 09.06.2011 19:28, Yiqun Cai wrote: > Adrian, > > Many thanks for the detailed comment. We have studied carefully and updated > the document accordingly. A new version, -08, has been uploaded. > > More inline. [...] Folks, as you can tell from Yiqun's email, there are a lot of changes to the draft, although I believe they are fine and don't actually change how mtid works. Please look at the changes though, and speak up if you have any concerns. You can find the new draft, old draft, and a diff at http://tools.ietf.org/wg/pim/draft-ietf-pim-mtid/ For just the diff, you might go directly to http://tools.ietf.org/wg/pim/draft-ietf-pim-mtid/draft-ietf-pim-mtid-08-from-07.diff.html Stig From Sundara.Moorthy@aricent.com Mon Jun 13 06:25:39 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 4E8CA9E800C for ; Mon, 13 Jun 2011 06:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHwxin0S3nso for ; Mon, 13 Jun 2011 06:25:38 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by ietfa.amsl.com (Postfix) with ESMTP id 454D49E8007 for ; Mon, 13 Jun 2011 06:25:37 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 63D5E36BBD for ; Mon, 13 Jun 2011 18:51:08 +0530 (IST) Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id 4DFB936BB7 for ; Mon, 13 Jun 2011 18:51:08 +0530 (IST) Received: from GUREXMB02.ASIAN.AD.ARICENT.COM ([10.203.171.134]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Mon, 13 Jun 2011 18:55:34 +0530 From: Sundara Moorthy M To: "pim@ietf.org" Date: Mon, 13 Jun 2011 18:55:32 +0530 Thread-Topic: Reg - I Need some clarification regarding PIM RPF vector implementation Thread-Index: AcwpzV6dHq69UKZ8TYGfyah/189VPg== Message-ID: <50F4072463B8464890B6051A13E6F7BC05A93C4949@GUREXMB02.ASIAN.AD.ARICENT.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_50F4072463B8464890B6051A13E6F7BC05A93C4949GUREXMB02ASIA_" MIME-Version: 1.0 Subject: [pim] Reg - I Need some clarification regarding PIM RPF vector implementation 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, 13 Jun 2011 13:25:39 -0000 --_000_50F4072463B8464890B6051A13E6F7BC05A93C4949GUREXMB02ASIA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In RFC5496 (PIM RPF Vector), they have discussed with a scenario as shown b= elow. ------------------ BGP ------------------------------ | | [S]---( Edge 1)--(Core 1)---( Core )--(Core 2)---( Edge 2 )---[R] <--- (S,G) Join In this case, it is discussed that (S,G) join from Edge2 to Edge1. Point1 : --------------- They haven't discussed about (S,G) join from any core router. My doubt is that if suppose the RP/Last Hop Router is the core router (cons= ider Core2) in the above figure. What will be vector attribute to be added in PIM JOIN format in this scenar= io?? Because the Vector Attribute to be added in PIM JOIN packet is the IP addre= ss of EDGE router. But the core router doesn't know about the destination(S) and also the EDGE= router to reach that destination(S). May I know that if there is any rule that RP should be one of the edge rout= ers ?? If not, how should we solve the above mentioned problem? Point 2: ------------------- What should the core router do with the received RPF vector if its neighbor= is not capable of handling the RPF vector.?? Should it send JOIN with RPF vector or not?? Thanks and Regards, Sundara Moorthy M =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D --_000_50F4072463B8464890B6051A13E6F7BC05A93C4949GUREXMB02ASIA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 
Hi,
 
In RFC5496 (PIM RPF Vector), they have discussed with= a scenario as shown below.
 
------------------ BGP -= -----------------------------
|    =             &nb= sp;            =             &nb= sp;           |
[S]---( Edge 1)--(Core 1)= ---( Core )--(Core 2)---( Edge 2 )---[R]
 
    &= nbsp;           &nbs= p;      <--- (S,G) Join
 
 
 
In this case, it is discussed that = (S,G) join from Edge2  to Edge1.
 
Point1 :
---------------
They haven't discussed about (S,G) = join from any core router.
My doubt is that if suppose the RP/= Last Hop Router is the core router (consider Core2) in the above figure.
 
 
What will be vector attribute to be= added in PIM JOIN format in this scenario??
Because the Vector Attribute to be = added in PIM JOIN packet is the IP address of EDGE router.
But the core router doesn't know ab= out the destination(S) and also the EDGE router to reach that destination(S= ).
 
May I know that if there is any rul= e that RP should be one of the edge routers ??
If not, how should we solve the abo= ve mentioned problem?
 
 
Point 2:
-------------------
What should the core router do with= the received RPF vector if its neighbor is not capable of handling the RPF= vector.??
Should it send JOIN with RPF vector= or not??
 
 
 
 
 
Thanks and Regards,
 Sundara Moorthy M
 

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Please= refer to http://www.aricent.com/legal/email_disclaimer.html
for im= portant disclosures regarding this electronic communication.
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
 --_000_50F4072463B8464890B6051A13E6F7BC05A93C4949GUREXMB02ASIA_-- From iesg-secretary@ietf.org Mon Jun 13 06:32:36 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 F045B9E8028; Mon, 13 Jun 2011 06:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7xaEdaEdZDb; Mon, 13 Jun 2011 06:32:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA2C9E8015; Mon, 13 Jun 2011 06:32:31 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110613133231.10123.60405.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2011 06:32:31 -0700 Cc: pim@ietf.org Subject: [pim] Last Call: (PIM Multi-Topology ID (MT-ID) Join Attribute) to Proposed Standard X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 13:32:37 -0000 The IESG has received a request from the Protocol Independent Multicast WG (pim) to consider the following document: - 'PIM Multi-Topology ID (MT-ID) Join Attribute' as a Proposed Standard 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-06-27. 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. Abstract This document introduces a new type of PIM Join Attribute that extends PIM signaling to identify a topology that should be used when constructing a particular multicast distribution tree. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pim-mtid/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pim-mtid/ No IPR declarations have been submitted directly on this I-D. From gf@erg.abdn.ac.uk Wed Jun 15 09:17:45 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 D5FF821F84FD for ; Wed, 15 Jun 2011 09:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 SyI+ZP7s8Mm4 for ; Wed, 15 Jun 2011 09:17:45 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id C633A21F84FE for ; Wed, 15 Jun 2011 09:17:43 -0700 (PDT) Received: from Gorry.local (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 p5FGHZmT023944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Jun 2011 17:17:36 +0100 (BST) Message-ID: <4DF8DB20.4040802@erg.abdn.ac.uk> Date: Wed, 15 Jun 2011 17:17:36 +0100 From: Gorry Organization: University of Aberdeen, UK 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: pim@ietf.org References: In-Reply-To: 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: gf@erg.abdn.ac.uk Cc: Stig Venaas Subject: Re: [pim] draft-ietf-pim-hello-intid-00 wglc X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 16:17:45 -0000 On 20/05/2011 18:59, Mike McBride (mmcbride) wrote: > Today begins a two week wglc for draft-ietf-pim-hello-intid-00. Please > review the draft. Then indicate to us if its worthy, or not, of being > sent to the iesg. > > http://www.ietf.org/id/draft-ietf-pim-hello-intid-00.txt > > thanks, > mike > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > draft-ietf-pim-hello-intid-01.txt appears to have addressed the technical issues I raised earlier. I have two editorial comments: * Section 2 - Minor comment that this sentence appears hard to parse. - Current " The Interface Identifier option is used to identify which interface of a neighboring router a PIM Hello [RFC4601] is sent on." - Suggested " The Interface Identifier option is used to identify the interface used to send a PIM Hello [RFC4601] to a neighboring router." * The abstract is very short. It does not include the words "Protocol Independent Multicast", which I would have expected. Sorry for the very late reply, Best wishes, Gorry From stig@venaas.com Wed Jun 15 09:32:15 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 D94DD11E813E for ; Wed, 15 Jun 2011 09:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tPKy-PY-gcH for ; Wed, 15 Jun 2011 09:32:15 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id A303411E808D for ; Wed, 15 Jun 2011 09:32:08 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:8d94:27f0:a6c1:d69] (unknown [IPv6:2001:420:4:ea0c:8d94:27f0:a6c1:d69]) by ufisa.uninett.no (Postfix) with ESMTPSA id AB90A7FDB; Wed, 15 Jun 2011 18:32:06 +0200 (CEST) Message-ID: <4DF8DE84.6010000@venaas.com> Date: Wed, 15 Jun 2011 09:32:04 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <4DF8DB20.4040802@erg.abdn.ac.uk> In-Reply-To: <4DF8DB20.4040802@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pim@ietf.org Subject: Re: [pim] draft-ietf-pim-hello-intid-00 wglc 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, 15 Jun 2011 16:32:16 -0000 On 6/15/2011 9:17 AM, Gorry wrote: > On 20/05/2011 18:59, Mike McBride (mmcbride) wrote: >> Today begins a two week wglc for draft-ietf-pim-hello-intid-00. Please >> review the draft. Then indicate to us if its worthy, or not, of being >> sent to the iesg. >> >> http://www.ietf.org/id/draft-ietf-pim-hello-intid-00.txt >> >> thanks, >> mike >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim >> > > draft-ietf-pim-hello-intid-01.txt appears to have addressed the > technical issues I raised earlier. > > I have two editorial comments: > > * Section 2 > - Minor comment that this sentence appears hard to parse. > - Current > " The Interface Identifier option is used to identify which interface > of a neighboring router a PIM Hello [RFC4601] is sent on." > - Suggested > " The Interface Identifier option is used to identify the interface > used to send a PIM Hello [RFC4601] to a neighboring router." Maybe, not sure. One minor thing perhaps is that a Hello is not usually sent to a specific neighboring router, and there may be multiple. "Identify the" seems more correct than "identify which". So one possibility is also to just do: The Interface Identifier option is used to identify the interface of a neighboring router that a PIM Hello [RFC4601] is sent on." I also added the word "that". It seems better to me. > * The abstract is very short. It does not include the words "Protocol > Independent Multicast", which I would have expected. PIM is now on the list of terms that don't need to be expanded. I won't update the draft right now, but there is likely to be another edit based on AD input or IETF last call, and this can then be addressed. Thanks, Stig > Sorry for the very late reply, > > Best wishes, > > Gorry > > From gorry@erg.abdn.ac.uk Wed Jun 15 10:12:01 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 17D9621F8525 for ; Wed, 15 Jun 2011 10:12: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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shJ6Mdf0+ZwT for ; Wed, 15 Jun 2011 10:11:56 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id EB22321F846D for ; Wed, 15 Jun 2011 10:11:55 -0700 (PDT) Received: from don.erg.abdn.ac.uk (don.erg.abdn.ac.uk [139.133.204.83]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p5FHBnvc024761; Wed, 15 Jun 2011 18:11:49 +0100 (BST) Date: Wed, 15 Jun 2011 18:11:49 +0100 (BST) From: Gorry Fairhurst To: Stig Venaas In-Reply-To: <4DF8DE84.6010000@venaas.com> Message-ID: References: <4DF8DB20.4040802@erg.abdn.ac.uk> <4DF8DE84.6010000@venaas.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: pim@ietf.org Subject: Re: [pim] draft-ietf-pim-hello-intid-00 wglc 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, 15 Jun 2011 17:12:01 -0000 On Wed, 15 Jun 2011, Stig Venaas wrote: > On 6/15/2011 9:17 AM, Gorry wrote: >> On 20/05/2011 18:59, Mike McBride (mmcbride) wrote: >>> Today begins a two week wglc for draft-ietf-pim-hello-intid-00. Please >>> review the draft. Then indicate to us if its worthy, or not, of being >>> sent to the iesg. >>> >>> http://www.ietf.org/id/draft-ietf-pim-hello-intid-00.txt >>> >>> thanks, >>> mike >>> _______________________________________________ >>> pim mailing list >>> pim@ietf.org >>> https://www.ietf.org/mailman/listinfo/pim >>> >> >> draft-ietf-pim-hello-intid-01.txt appears to have addressed the >> technical issues I raised earlier. >> >> I have two editorial comments: >> >> * Section 2 >> - Minor comment that this sentence appears hard to parse. >> - Current >> " The Interface Identifier option is used to identify which interface >> of a neighboring router a PIM Hello [RFC4601] is sent on." >> - Suggested >> " The Interface Identifier option is used to identify the interface >> used to send a PIM Hello [RFC4601] to a neighboring router." > > Maybe, not sure. One minor thing perhaps is that a Hello is not usually > sent to a specific neighboring router, and there may be multiple. > > "Identify the" seems more correct than "identify which". So one > possibility is also to just do: > > The Interface Identifier option is used to identify the interface > of a neighboring router that a PIM Hello [RFC4601] is sent on." > To me this still reads bad, but perhaps it is only word order? Would this work: The Interface Identifier option is used to identify the interface on which a neighboring router sends a PIM Hello [RFC4601] message." > I also added the word "that". It seems better to me. > >> * The abstract is very short. It does not include the words "Protocol >> Independent Multicast", which I would have expected. > > PIM is now on the list of terms that don't need to be expanded. > > I won't update the draft right now, but there is likely to be > another edit based on AD input or IETF last call, and this can > then be addressed. > OK - There's nothing here that would obstruct publication. Best wishes, Gorry > Thanks, > > Stig > >> Sorry for the very late reply, >> >> Best wishes, >> >> Gorry >> >> > From stig@venaas.com Wed Jun 15 10:14:09 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 0057D21F84B5 for ; Wed, 15 Jun 2011 10:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4FuN2wFZcdp for ; Wed, 15 Jun 2011 10:14:08 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 2177221F846D for ; Wed, 15 Jun 2011 10:14:08 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:8d94:27f0:a6c1:d69] (unknown [IPv6:2001:420:4:ea0c:8d94:27f0:a6c1:d69]) by ufisa.uninett.no (Postfix) with ESMTPSA id 380C97FDB; Wed, 15 Jun 2011 19:14:06 +0200 (CEST) Message-ID: <4DF8E85C.5090903@venaas.com> Date: Wed, 15 Jun 2011 10:14:04 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Gorry Fairhurst References: <4DF8DB20.4040802@erg.abdn.ac.uk> <4DF8DE84.6010000@venaas.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pim@ietf.org Subject: Re: [pim] draft-ietf-pim-hello-intid-00 wglc 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, 15 Jun 2011 17:14:09 -0000 On 6/15/2011 10:11 AM, Gorry Fairhurst wrote: > > > On Wed, 15 Jun 2011, Stig Venaas wrote: > >> On 6/15/2011 9:17 AM, Gorry wrote: >>> On 20/05/2011 18:59, Mike McBride (mmcbride) wrote: >>>> Today begins a two week wglc for draft-ietf-pim-hello-intid-00. Please >>>> review the draft. Then indicate to us if its worthy, or not, of being >>>> sent to the iesg. >>>> >>>> http://www.ietf.org/id/draft-ietf-pim-hello-intid-00.txt >>>> >>>> thanks, >>>> mike >>>> _______________________________________________ >>>> pim mailing list >>>> pim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pim >>>> >>> >>> draft-ietf-pim-hello-intid-01.txt appears to have addressed the >>> technical issues I raised earlier. >>> >>> I have two editorial comments: >>> >>> * Section 2 >>> - Minor comment that this sentence appears hard to parse. >>> - Current >>> " The Interface Identifier option is used to identify which interface >>> of a neighboring router a PIM Hello [RFC4601] is sent on." >>> - Suggested >>> " The Interface Identifier option is used to identify the interface >>> used to send a PIM Hello [RFC4601] to a neighboring router." >> >> Maybe, not sure. One minor thing perhaps is that a Hello is not usually >> sent to a specific neighboring router, and there may be multiple. >> >> "Identify the" seems more correct than "identify which". So one >> possibility is also to just do: >> >> The Interface Identifier option is used to identify the interface >> of a neighboring router that a PIM Hello [RFC4601] is sent on." >> > To me this still reads bad, but perhaps it is only word order? > > Would this work: > > The Interface Identifier option is used to identify the interface > on which a neighboring router sends a PIM Hello [RFC4601] message." That sounds good to me, thanks! Stig >> I also added the word "that". It seems better to me. >> >>> * The abstract is very short. It does not include the words "Protocol >>> Independent Multicast", which I would have expected. >> >> PIM is now on the list of terms that don't need to be expanded. >> >> I won't update the draft right now, but there is likely to be >> another edit based on AD input or IETF last call, and this can >> then be addressed. >> > OK - There's nothing here that would obstruct publication. > > Best wishes, > > Gorry > >> Thanks, >> >> Stig >> >>> Sorry for the very late reply, >>> >>> Best wishes, >>> >>> Gorry >>> >>> >> From Sundara.Moorthy@aricent.com Thu Jun 16 05:34:07 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 BA26711E80C8 for ; Thu, 16 Jun 2011 05:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCXJMOGfDlPI for ; Thu, 16 Jun 2011 05:34:07 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4B01211E80BF for ; Thu, 16 Jun 2011 05:34:06 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 9457536BBD; Thu, 16 Jun 2011 17:59:34 +0530 (IST) Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id 7D20E36BA3; Thu, 16 Jun 2011 17:59:34 +0530 (IST) Received: from GUREXMB02.ASIAN.AD.ARICENT.COM ([10.203.171.134]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Thu, 16 Jun 2011 18:04:02 +0530 From: Sundara Moorthy M To: "pim@ietf.org" Date: Thu, 16 Jun 2011 18:04:00 +0530 Thread-Topic: [pim] Reg - I Need some clarification regarding PIM RPF vector implementation Thread-Index: Acwp/ByfgVGWWqJZQHWOgtywJcEW4gCJWZbg Message-ID: <50F4072463B8464890B6051A13E6F7BC05A9A66E2B@GUREXMB02.ASIAN.AD.ARICENT.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_50F4072463B8464890B6051A13E6F7BC05A9A66E2BGUREXMB02ASIA_" MIME-Version: 1.0 Cc: "iwijnand@cisco.com" Subject: [pim] Reg - I Need some clarification regarding PIM RPF vector implementation 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, 16 Jun 2011 12:34:07 -0000 --_000_50F4072463B8464890B6051A13E6F7BC05A9A66E2BGUREXMB02ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In RFC5496 (PIM RPF Vector), they have discussed with a scenario as shown b= elow. ------------------ BGP ------------------------------ | | [S]---( Edge 1)--(Core 1)---( Core )--(Core 2)---( Edge 2 )---[R] <--- (S,G) Join In this case, it is discussed that (S,G) join from Edge2 to Edge1. Point1 : --------------- They haven't discussed about (S,G) join from any core router. My doubt is that if suppose the RP/Last Hop Router is the core router (cons= ider Core2) in the above figure. What will be vector attribute to be added in PIM JOIN format in this scenar= io?? Because the Vector Attribute to be added in PIM JOIN packet is the IP addre= ss of EDGE router. But the core router doesn't know about the destination(S) and also the EDGE= router to reach that destination(S). May I know that if there is any rule that RP should be one of the edge rout= ers ?? If not, how should we solve the above mentioned problem? Point 2: ------------------- What should the core router do with the received RPF vector if its neighbor= is not capable of handling the RPF vector.?? Should it send JOIN with RPF vector or not?? Thanks and Regards, Sundara Moorthy M =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D --_000_50F4072463B8464890B6051A13E6F7BC05A9A66E2BGUREXMB02ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
In RFC5496 (PIM RPF Vector), they have discussed with= a scenario as shown below.
 
------------------ BGP --= ----------------------------
|    =             &nb= sp;            =             &nb= sp;           |
[S]---( Edge 1)--(Core 1)= ---( Core )--(Core 2)---( Edge 2 )---[R]
 
    &= nbsp;           &nbs= p;      <--- (S,G) Join
 
 
 
In this case, it is discussed that = (S,G) join from Edge2  to Edge1.
 
Point1 :
---------------
They haven't discussed about (S,G) = join from any core router.
My doubt is that if suppose the RP/= Last Hop Router is the core router (consider Core2) in the above figure.
 
 
What will be vector attribute to be= added in PIM JOIN format in this scenario??
Because the Vector Attribute to be = added in PIM JOIN packet is the IP address of EDGE router.
But the core router doesn't know ab= out the destination(S) and also the EDGE router to reach that destination(S= ).
 
May I know that if there is any rul= e that RP should be one of the edge routers ??
If not, how should we solve the abo= ve mentioned problem?
 
 
Point 2:
-------------------
What should the core router do with= the received RPF vector if its neighbor is not capable of handling the RPF= vector.??
Should it send JOIN with RPF vector= or not??
 
 
 
 
 
Thanks and Regards,
 Sundara Moorthy M
 

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Please= refer to http://www.aricent.com/legal/email_disclaimer.html
for im= portant disclosures regarding this electronic communication.
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
 --_000_50F4072463B8464890B6051A13E6F7BC05A9A66E2BGUREXMB02ASIA_-- From ice@cisco.com Thu Jun 16 06:17:25 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 A51CA11E80BD for ; Thu, 16 Jun 2011 06:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 UmKwVONlAO+h for ; Thu, 16 Jun 2011 06:17:23 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9EE11E8071 for ; Thu, 16 Jun 2011 06:17:23 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p5GDHDki021591; Thu, 16 Jun 2011 15:17:13 +0200 (CEST) Received: from ams-iwijnand-8715.cisco.com (ams-iwijnand-8715.cisco.com [10.55.191.150]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p5GDHCGP011901; Thu, 16 Jun 2011 15:17:12 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: IJsbrand Wijnands In-Reply-To: <50F4072463B8464890B6051A13E6F7BC05A9A66E2B@GUREXMB02.ASIAN.AD.ARICENT.COM> Date: Thu, 16 Jun 2011 15:17:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1E82A2DE-89B1-42B7-93F4-3BD3131C931D@cisco.com> References: <50F4072463B8464890B6051A13E6F7BC05A9A66E2B@GUREXMB02.ASIAN.AD.ARICENT.COM> To: Sundara Moorthy M X-Mailer: Apple Mail (2.1081) Cc: pim@ietf.org Subject: Re: [pim] Reg - I Need some clarification regarding PIM RPF vector implementation 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, 16 Jun 2011 13:17:25 -0000 Hi Sundara, > In RFC5496 (PIM RPF Vector), they have discussed with a scenario as = shown below. > =20 > ------------------ BGP ------------------------------ > | | > [S]---( Edge 1)--(Core 1)---( Core )--(Core 2)---( Edge 2 )---[R] > =20 > <--- (S,G) Join > =20 > =20 > =20 > In this case, it is discussed that (S,G) join from Edge2 to Edge1. > =20 > Point1 : > --------------- > They haven't discussed about (S,G) join from any core router. > My doubt is that if suppose the RP/Last Hop Router is the core router = (consider Core2) in the above figure. > =20 > =20 > What will be vector attribute to be added in PIM JOIN format in this = scenario?? > Because the Vector Attribute to be added in PIM JOIN packet is the IP = address of EDGE router. > But the core router doesn't know about the destination(S) and also the = EDGE router to reach that destination(S). > =20 > May I know that if there is any rule that RP should be one of the edge = routers ?? > If not, how should we solve the above mentioned problem? If Core2 is the last hop router, then its not a Core router any more but = an Edge router. So you would need to make sure this router is also = connected to BGP to get the right routes. > Point 2: > ------------------- > What should the core router do with the received RPF vector if its = neighbor is not capable of handling the RPF vector.?? > Should it send JOIN with RPF vector or not?? It should send a Join without RPF vector. Thx, Ice. > =20 > =20 > =20 > =20 > =20 > Thanks and Regards, > Sundara Moorthy M > =20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Please refer to http://www.aricent.com/legal/email_disclaimer.html > for important disclosures regarding this electronic communication. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Please refer to http://www.aricent.com/legal/email_disclaimer.html > for important disclosures regarding this electronic communication. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From internet-drafts@ietf.org Thu Jun 16 14:41:57 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 3712811E81A5; Thu, 16 Jun 2011 14:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1x3k1oJ1SmOs; Thu, 16 Jun 2011 14:41:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936A711E81A4; Thu, 16 Jun 2011 14:41:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110616214156.1992.43743.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2011 14:41:56 -0700 Cc: pim@ietf.org Subject: [pim] I-D Action: draft-ietf-pim-port-07.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: Thu, 16 Jun 2011 21:41:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol Independent Multicast Workin= g Group of the IETF. Title : A Reliable Transport Mechanism for PIM Author(s) : Dino Farinacci IJsbrand Wijnands Stig Venaas Maria Napierala Filename : draft-ietf-pim-port-07.txt Pages : 33 Date : 2011-06-16 This draft describes how a reliable transport mechanism can be used by the PIM protocol to optimize CPU and bandwidth resource utilization by eliminating periodic Join/Prune message transmission. This draft proposes a modular extension to PIM to use either the TCP or SCTP transport protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-port-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pim-port-07.txt From stig@venaas.com Thu Jun 16 14:46:39 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 12AD811E830B for ; Thu, 16 Jun 2011 14:46:39 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGAipq+V9O8o for ; Thu, 16 Jun 2011 14:46:38 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2A011E80CF for ; Thu, 16 Jun 2011 14:46:38 -0700 (PDT) Received: from [10.33.12.67] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id EE5177FE7 for ; Thu, 16 Jun 2011 23:46:35 +0200 (CEST) Message-ID: <4DFA79B4.20308@venaas.com> Date: Thu, 16 Jun 2011 14:46:28 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "pim@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pim] PORT update (posted rev 7) 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, 16 Jun 2011 21:46:39 -0000 I just posted revision 7 of PORT, see announcement that just got sent to the list. This should address all the comments received during the last WGLC and also comments I received from Gorry afterwords. Basically I posted revision 6 based on discussion during and shortly after the 2nd WGLC. I got more input after that, mainly from Gorry, which revision 7 addresses. With that I hope we may finally be done with this document... If anyone has any issues with revision 7, please speak up. Stig From Sundara.Moorthy@aricent.com Thu Jun 16 22:52:53 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 D23D51F0C48 for ; Thu, 16 Jun 2011 22:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QFPloHy1mIE for ; Thu, 16 Jun 2011 22:52:52 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8D51F1F0C36 for ; Thu, 16 Jun 2011 22:52:51 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id D473B36BA0; Fri, 17 Jun 2011 11:18:18 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id BD52136B2C; Fri, 17 Jun 2011 11:18:18 +0530 (IST) Received: from GUREXMB02.ASIAN.AD.ARICENT.COM ([10.203.171.134]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Fri, 17 Jun 2011 11:22:47 +0530 From: Sundara Moorthy M To: IJsbrand Wijnands Date: Fri, 17 Jun 2011 11:22:45 +0530 Thread-Topic: [pim] Reg - I Need some clarification regarding PIM RPF vector implementation Thread-Index: AcwsJ7pQqNoKbh0vTUKHQ10cl6URHQAiWhJQ Message-ID: <50F4072463B8464890B6051A13E6F7BC05A9A67063@GUREXMB02.ASIAN.AD.ARICENT.COM> References: <50F4072463B8464890B6051A13E6F7BC05A9A66E2B@GUREXMB02.ASIAN.AD.ARICENT.COM> <1E82A2DE-89B1-42B7-93F4-3BD3131C931D@cisco.com> In-Reply-To: <1E82A2DE-89B1-42B7-93F4-3BD3131C931D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_50F4072463B8464890B6051A13E6F7BC05A9A67063GUREXMB02ASIA_" MIME-Version: 1.0 Cc: "pim@ietf.org" Subject: Re: [pim] Reg - I Need some clarification regarding PIM RPF vector implementation 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, 17 Jun 2011 05:52:53 -0000 --_000_50F4072463B8464890B6051A13E6F7BC05A9A67063GUREXMB02ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ice, >From your reply, I have understood that the core router can't be a Last Hop= router(LHR). But I haven't get the solution for my doubt RP as a core router. Is that condition applies for RP also? If not, will you please revisit th= e problem POINT1, that I mentioned in the below mail thread ? Thanks and Regards, Sundara Moorthy M -----Original Message----- From: IJsbrand Wijnands [mailto:ice@cisco.com] Sent: Thursday, June 16, 2011 6:47 PM To: Sundara Moorthy M Cc: pim@ietf.org Subject: Re: [pim] Reg - I Need some clarification regarding PIM RPF vector= implementation Hi Sundara, > In RFC5496 (PIM RPF Vector), they have discussed with a scenario as shown= below. > > ------------------ BGP ------------------------------ > | | > [S]---( Edge 1)--(Core 1)---( Core )--(Core 2)---( Edge 2 )---[R] > > <--- (S,G) Join > > > > In this case, it is discussed that (S,G) join from Edge2 to Edge1. > > Point1 : > --------------- > They haven't discussed about (S,G) join from any core router. > My doubt is that if suppose the RP / Last Hop Router is the core router (= consider Core2) in the above figure. > > > What will be vector attribute to be added in PIM JOIN format in this scen= ario?? > Because the Vector Attribute to be added in PIM JOIN packet is the IP add= ress of EDGE router. > But the core router doesn't know about the destination(S) and also the ED= GE router to reach that destination(S). > > May I know that if there is any rule that RP should be one of the edge ro= uters ?? > If not, how should we solve the above mentioned problem? If Core2 is the last hop router, then its not a Core router any more but an= Edge router. So you would need to make sure this router is also connected = to BGP to get the right routes. > Point 2: > ------------------- > What should the core router do with the received RPF vector if its neighb= or is not capable of handling the RPF vector.?? > Should it send JOIN with RPF vector or not?? It should send a Join without RPF vector. Thx, Ice. > > > > > > Thanks and Regards, > Sundara Moorthy M > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D Please refer to > http://www.aricent.com/legal/email_disclaimer.html > for important disclosures regarding this electronic communication. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D Please refer to > http://www.aricent.com/legal/email_disclaimer.html > for important disclosures regarding this electronic communication. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D _____________________________________________= __ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D --_000_50F4072463B8464890B6051A13E6F7BC05A9A67063GUREXMB02ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Ice,
 
From your reply, I have understood that the core router can't be a Las= t Hop router(LHR).
 
But I haven't get the solution for my doubt RP= as a core router. 
Is that condition applies for RP also?  If  not, will you pl= ease revisit the problem POINT1, that I mentioned in the below mail thread = ?
 
 
 
Thanks and Regards,=
Sundara Moorthy M<= /div>
 
-----Original Message-----=
From: IJsbrand Wijnands [<= a href=3D"mailto:ice@cisco.com">mailto:ice@cisco= .com]
Sent: Thursday, June 16, 2= 011 6:47 PM
To: Sundara Moorthy M
Cc: pim@ietf.org
Subject: Re: [pim] Reg - I= Need some clarification regarding PIM RPF vector implementation
 
Hi Sundara,
 
> In RFC5496 (PIM RPF V= ector), they have discussed with a scenario as shown below.
> 
> ------------------ BG= P ------------------------------
> |   &n= bsp;            = ;            &n= bsp;            = ;            |
> [S]---( Edge 1)--(Cor= e 1)---( Core )--(Core 2)---( Edge 2 )---[R]
> 
>   &nbs= p;            &= nbsp;       <--- (S,G) Join
> 
> 
> 
> In this case, it is d= iscussed that (S,G) join from Edge2  to Edge1.
> 
> Point1 :
> ---------------
> They haven't discusse= d about (S,G) join from any core router.
> My doubt is that if s= uppose the RP / Last Hop Router is the core router (consider Core2) in the above figure.<= /div>
> 
> 
> What will be vector a= ttribute to be added in PIM JOIN format in this scenario??
> Because the Vector At= tribute to be added in PIM JOIN packet is the IP address of EDGE router.
> But the core router d= oesn't know about the destination(S) and also the EDGE router to reach that= destination(S).
> 
> May I know that if th= ere is any rule that RP should be one of the edge routers ??
> If not, how should we= solve the above mentioned problem?
 
If Core2 is the last hop r= outer, then its not a Core router any more but an Edge router. So you would= need to make sure this router is also connected to BGP to get the right ro= utes.
 
> Point 2:
> -------------------
> What should the core = router do with the received RPF vector if its neighbor is not capable of ha= ndling the RPF vector.??
> Should it send JOIN w= ith RPF vector or not??
 
It should send a Join with= out RPF vector.
 
Thx,
 
Ice.
 
> 
> 
> 
> 
> 
> Thanks and Regards,
>  Sundara Moorthy= M
> 
>
> =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D= =3D=3D Please refer to
> for important disclos= ures regarding this electronic communication.
> =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D= =3D=3D
>
> =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D= =3D=3D Please refer to
> for important disclos= ures regarding this electronic communication.
> =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D= =3D=3D _______________________________________________
> pim mailing list
> pim@ietf.org
 

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Please= refer to http://www.aricent.com/legal/email_disclaimer.html
for im= portant disclosures regarding this electronic communication.
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
 --_000_50F4072463B8464890B6051A13E6F7BC05A9A67063GUREXMB02ASIA_-- From mmcbride@cisco.com Tue Jun 21 10:40:56 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 C129011E82C5 for ; Tue, 21 Jun 2011 10:40:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkkMqW97uqEo for ; Tue, 21 Jun 2011 10:40:56 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1986B11E82C0 for ; Tue, 21 Jun 2011 10:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mmcbride@cisco.com; l=1082; q=dns/txt; s=iport; t=1308678056; x=1309887656; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=JTNLKJcaMilvNRyZivr3cIppGgFJbzNgIXBAw2NviOI=; b=BTe43HZDk6DUdhr41qm0PEedkI5BwAsfO8MEik4Pl+llT9VvTQdDhFjk YuQROfap0XDu42bFISouE4r/S391miMr9Ire5ZGITDKm++QVAHOdtjz3U NnYhDAItABGoAP++34ehACPrNS4zlcIf54YatN2VVFe1jlvF3cUV7BGyv k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAAjXAE6rRDoG/2dsb2JhbABUl12PFHeqKp45hioEhyKPL4s7 X-IronPort-AV: E=Sophos;i="4.65,402,1304294400"; d="scan'208";a="466334176" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 21 Jun 2011 17:40:55 +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 p5LHetED016862; Tue, 21 Jun 2011 17:40:55 GMT Received: from xmb-sjc-21d.amer.cisco.com ([171.70.151.140]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Jun 2011 10:40:55 -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: Tue, 21 Jun 2011 10:40:44 -0700 Message-ID: In-reply-to: <4DFA79B4.20308@venaas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pim] PORT update (posted rev 7) Thread-Index: AcwsbupwkN51d7+/Tu+h1QXbhg6SXwDyrg0Q References: <4DFA79B4.20308@venaas.com> From: "Mike McBride (mmcbride)" To: "Stig Venaas" , X-OriginalArrivalTime: 21 Jun 2011 17:40:55.0578 (UTC) FILETIME=[5F865FA0:01CC303A] Subject: Re: [pim] PORT update (posted rev 7) 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, 21 Jun 2011 17:40:56 -0000 I will be sending this draft to the ADs this Friday. Please speak up if you feel the authors have not resolved all wglc concerns. Thanks for the comments. mike > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of > Stig Venaas > Sent: Thursday, June 16, 2011 2:46 PM > To: pim@ietf.org > Subject: [pim] PORT update (posted rev 7) >=20 > I just posted revision 7 of PORT, see announcement that just got sent > to > the list. This should address all the comments received during the last > WGLC and also comments I received from Gorry afterwords. >=20 > Basically I posted revision 6 based on discussion during and shortly > after the 2nd WGLC. >=20 > I got more input after that, mainly from Gorry, which revision 7 > addresses. >=20 > With that I hope we may finally be done with this document... If anyone > has any issues with revision 7, please speak up. >=20 > Stig > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From stig@venaas.com Fri Jun 24 13:56:22 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 CEEFD11E8255 for ; Fri, 24 Jun 2011 13:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPapc5IVxJst for ; Fri, 24 Jun 2011 13:56:22 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 37039228006 for ; Fri, 24 Jun 2011 13:55:44 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:75dc:7fe4:3ee4:3869] (unknown [IPv6:2001:420:4:ea0c:75dc:7fe4:3ee4:3869]) by ufisa.uninett.no (Postfix) with ESMTPSA id 8A86B7FF8 for ; Fri, 24 Jun 2011 22:55:42 +0200 (CEST) Message-ID: <4E04F9CC.2010903@venaas.com> Date: Fri, 24 Jun 2011 13:55:40 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "pim@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [pim] Fwd: Please help the Nomcom 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, 24 Jun 2011 20:56:22 -0000 Nomcom is looking for more volunteers. It's a good way to serve the community and learn more about how the IETF works. Stig -------- Original Message -------- Subject: Please help the Nomcom Date: Fri, 24 Jun 2011 11:35:13 -0700 (PDT) From: NomCom Chair To: Working Group Chairs Hi WG chairs, We have had a good response to the first call for volunteers but the rate at which new volunteers are coming in is slowing down. The Nomcom process is best served by a large pool of volunteers drawn from a wide spectrum of IETF attendees. Where else would we find this wide spectrum if not in the WG mailing lists. I would really appreciate it if you can forward the message onto your working group mailing lists. The latest volunteer status and the second call for volunteers can be found at https://datatracker.ietf.org/ann/nomcom/2964/ Thanks in advance for your help. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com From stig@venaas.com Fri Jun 24 14:00:04 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 4AE2711E8192 for ; Fri, 24 Jun 2011 14:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vi5w62ew9E-e for ; Fri, 24 Jun 2011 14:00:04 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 41ACC11E824E for ; Fri, 24 Jun 2011 14:00:03 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:75dc:7fe4:3ee4:3869] (unknown [IPv6:2001:420:4:ea0c:75dc:7fe4:3ee4:3869]) by ufisa.uninett.no (Postfix) with ESMTPSA id 952687FF7; Fri, 24 Jun 2011 23:00:01 +0200 (CEST) Message-ID: <4E04FACF.2030202@venaas.com> Date: Fri, 24 Jun 2011 13:59:59 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "pim@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Mike McBride \(mmcbride\)" Subject: [pim] Submission deadlines and agenda items 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, 24 Jun 2011 21:00:04 -0000 Please let Mike and I know if you have anything you would like to present in Quebec. The draft submission deadlines are: 2011-07-04 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (00:00 UTC) 2011-07-11 (Monday): Internet Draft final submission cut-off by 17:00 PT (00:00 UTC) Stig From stig@venaas.com Wed Jun 29 10:31:56 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 0AB8F9E8052 for ; Wed, 29 Jun 2011 10:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UC9tkydDHaIS for ; Wed, 29 Jun 2011 10:31:55 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 7535D9E804F for ; Wed, 29 Jun 2011 10:31:54 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:4c16:c11f:bb59:6a29] (unknown [IPv6:2001:420:4:ea0c:4c16:c11f:bb59:6a29]) by ufisa.uninett.no (Postfix) with ESMTPSA id A8CAE8069 for ; Wed, 29 Jun 2011 19:31:46 +0200 (CEST) Message-ID: <4E0B617F.1060503@venaas.com> Date: Wed, 29 Jun 2011 10:31:43 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "pim@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pim] Fwd: Nomcom 2011-2012: Second Call for Volunteers 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, 29 Jun 2011 17:31:56 -0000 This is the email I should have forwarded. This has the info you need if you want to volunteer. Stig -------- Original Message -------- Subject: Nomcom 2011-2012: Second Call for Volunteers Date: Fri, 24 Jun 2011 11:14:22 -0700 (PDT) From: NomCom Chair To: IETF Announcement list This is the Second call for Volunteers for the 2011-12 Nomcom. We are just about halfway through the volunteer period so if you are considering volunteering, please do so very soon. We have had a very good response to the initial call for volunteers and I am pleased to report that we have 50 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. However, we would like to have many more volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. You have until 11:59 pm EDT July 10, 2011 to volunteer for Nomcom but it would be much better if you can volunteer as early as possible. If you volunteered before 21:00 EDT on June 21 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! Details about the process for volunteering for the Nomcom and the list of open positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2938/ The 50 volunteers who have thus far been qualified by the secretariat are: Alia Atlas , Juniper Networks Lixia Zhang , UCLA Wassim Haddad , Ericsson Glen Zorn , Network Zen Richard Barnes , BBN Technologies Stephen Kent , BBN Technologies Scott Mansfield , Ericsson Tina TSOU , FutureWei Technologies Fernando Gont , UTN/FRH Karen Seo , BBN Technologies Jie Dong , Huawei Technologies Mach Chen , Huawei Technologies Co. Sheng Jiang , Huawei Technologies Co. Ltd. Dimitri Papadimitriou , Alcatel-Lucent Thomas D. Nadeau , CA Technologies David Meyer , Cisco Systems/University of Oregon Wesley George , Time Warner Cable Cullen Jennings , Cisco Stephen Hanna , Juniper Networks Stephan Wenger , Bidyo Keyur Patel , Cisco Systems Michael Hamilton , BreakingPoint Systems Behcet Sarikaya , Huawei USA Mark Townsley , Cisco Systems Fred Baker , Cisco Systems Brian Trammell , ETH Zurich Sam Hartman , Painless Security Chris Griffiths , Comcast George Michaelson , APNIC Jiankang Yao , CNNIC Sohel Khan , Comcast Dacheng Zhang , Huawei Lianshu Zheng , Huawei Technologies Hui Deng , China Mobile Gang Chen , China Mobile Mirja Kuhlewind , University of Stuttgart John E Drake , Juniper Networks Matt Lepinski , BBN Technologies Subir Das , Telcordia Technologies Inc Yi Zhao , Huawei John Scudder , Juniper Networks Christer Holmberg , LM Ericsson Teemu Savolainen , Nokia Samita Chakrabarti , Ericsson Jaap Akkerhuis , NLnet labs Jason Weil , Time Warner Cable Randy Bush , Internet Initiative Japan Christian Schmidt , Nokia Siemens Networks Sean Shen , CNNIC Lou Berger , LabN Consulting The primary activity for this nomcom will begin during IETF-81 in Quebec City and should be completed by January 2012. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email to me before 11:59 pm EDT July 10, 2011 as follows: To: suresh.krishnan@ericsson.com Subject: Nomcom 2011-12 Volunteer Please include the following information in the body of the mail: Full Name: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name Current Primary Affiliation: // typically what goes in the Company // field in the IETF Registration Form Email Address(es): // all email addresses used to Register for the // past 5 IETF meetings // Please designate a Preferred email address for // contact if there is more than one email address Telephone number: // With country code (for confirmation if selected) Please expect an email response from me within 3 business days stating whether or not you are qualified. If you do not receive a response in this timeframe, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that Nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the Nomcom is a good way of contributing in that direction. I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process within the next few days. Thank you in advance for your participation. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From marshall.eubanks@gmail.com Thu Jun 30 07:22:07 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 D8FEF21F8531; Thu, 30 Jun 2011 07:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ZZgjdK0SJiiD; Thu, 30 Jun 2011 07:22:06 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5E321F8532; Thu, 30 Jun 2011 07:22:06 -0700 (PDT) Received: by gwb20 with SMTP id 20so1126387gwb.31 for ; Thu, 30 Jun 2011 07:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=04dPZxIj9j4wlqky9j5N8MIkchDQJ6iy7bhFUzg2VZ8=; b=O0Z8EKbHZ+m7DUTMIrVhdQTH1UomU+mj+sIthxa6+//PnPYarVn+o6NNJ79DhRECVe LfpVMwhHTpn2WzAluiiwjYnv6VKs/fDB8PC8iaEnlBtPkg5R8JIwS//wiSK9UtSpDbhx VbQUa8Wit9LoJYcLkx0sqNMLveyLooM/e/OTE= Received: by 10.150.12.10 with SMTP id 10mr1892145ybl.77.1309443725596; Thu, 30 Jun 2011 07:22:05 -0700 (PDT) Received: from [10.0.1.14] (c-67-188-32-245.hsd1.ca.comcast.net [67.188.32.245]) by mx.google.com with ESMTPS id i30sm1667452yhm.21.2011.06.30.07.22.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Jun 2011 07:22:05 -0700 (PDT) From: Marshall Eubanks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Jun 2011 10:22:02 -0400 Message-Id: To: IETF Discussion Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: TSV Area , pim@ietf.org, Transport Directorate Subject: [pim] tsv-dir review of draft-ietf-pim-mtid-08 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, 30 Jun 2011 14:22:08 -0000 I've reviewed this document as part of the transport area directorate's = ongoing effort to review key IETF documents. These comments were written = primarily for the transport area directors, but are copied to the = document's authors for their information and to allow them to address = any issues raised. The authors should consider this review together with = any other last-call comments they receive. Please always CC = tsv-dir@ietf.org if you reply to or forward this review. Note : I also reviewed the WG mailing list discussions for this = document.=20 This draft is basically ready for publication, but has some issues that = in my opinion should be fixed before publication. There are, however, some issues that I think that should be addressed, = either in a follow-on document, or a revision of this document.=20 draft-ietf-pim-mtid introduces a new type of PIM Join Attribute = [RFC5384], the MT-ID Join Attribute, that extends PIM signaling to cover multiple topologies and to enable the = identification of which topology should be used when constructing a particular multicast distribution tree.=20 Multiple topologies have been used for some time in unicast (they are = supported by IS-IS and OSPF), and also in multicast. The most common = multicast requirement for multiple topologies is for video transport, = where important or expensive video streams (say, of sporting events) are = protected from disruption by multiple transport on completely different = network paths. In that use, if a network link goes down or becomes = congested or otherwise suboptimal, another source of the video data is = already present and the display can be seamlessly switched to the other = copy of the stream. This use case is alluded to in the document.=20 Another use case for multiple-topologies is to separate out different = types of traffic (say, latency sensitive traffic from larger, bulk, = flows). This is not alluded to in this document, and it is not clear to = what extent this was intended. These multiple topologies may or may not = result in the replication of data, and so may not be intended by the author. = However, I would say that this could be used to support this, and so it = will be. If there is some reason NOT to use this mechanism for this = purpose, some description of the reasons why would be in order.=20 This document sets up a numerical variable, the MT-ID Join Attribute, = to assign to multicast topologies, to be used to separate different = topologies for different paths. This number for a given multicast = topology need not be the same as any unicast multiple topology = identifiers, and similarly the multicast topologies and the underlying = unicast topologies may be different.=20 This document is sort, straight-forward, and relatively well-written. I = had a few non-fatal issues. (I would be glad to suggest some text for = any of these issues to the authors if they interested.)=20 Minor Issues : Section 3.2=20 "- As shown earlier, 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, the PIM MT-ID is RECOMMENDED to be assigned = using the same value as the IGP topology identifier. Using the same = example presented earlier, if every route in PIM 500 is contributed by OSPF 1000, it is RECOMMENDED to = name this RPF topology as PIM 1000 instead of PIM 500. This is for the = purpose of reducing management overhead and simplifying = troubleshooting." In the actual example, PIM 500 is not the same network topology as OSPF = 1000 (it has an extra link, to the source, obtained by MBGP). This is = specifically mentioned previously in the text. So, this is NOT the same = example as presented earlier and it is NOT clear that this = recommendation applies here.=20 If this is left as is, it will certainly confuse some people. I would = suggest adding text to clarify this, or creating another example where = the unicast and multicast topologies are the same. Section 4.2.3=20 "- There is at most 1 PIM MT-ID attribute encoded. If there are multiple = PIM MT-ID Join Attributes included, only the last one is accepted for = this particular source. Processing of the rest of the Join message = continues." Is this a typo ?=20 s/at most/at least/=20 would seem to be appropriate. (It says, "at most" 1, and then describes = what do to if there is more than 1.) Otherwise, please explain what is = meant. Section 6. The Labels for Section 6.1 and 6.2 are the same. I suspect this is just = a typo, and they should be 6.1. PIM-Hello Options 6.2. PIM Join Attribute Types More Substantive Issues : I had two substantive issues with this document.=20 1.) The range for the topologies. It is highly likely that the users of = this capability would want to use multiple topologies differently for = different multicast address ranges. For example, use of two topologies = is likely to be an expensive customer option, that not all customers = would pay for, and so would not apply to all multicast addresses. Or, = the backup typologies may (probably will be) tailored differently for = different customers in different locations. Or, topologies might be = tailored for different data types (different backups for real time video = conferencing versus TV broadcast transmissions, say). This is very = briefly alluded to in Section 3.1, but no consideration is given to = issues arising from this. For example, suppose I have two customers, and I wish to have one basic = topology (say, PIM 100) for 239.10/16, and I wish to have two backup = topologies for the two customers (say, PIM 1001 for 239.10.1/24 and PIM = 1002 for 239.10.2/24.) Can I have PIM 100 cover both the PIM 1001 and = PIM 1002 range ? Are there issues with this ? Would it be better to = split PIM 100 into pieces to match 1001 and 1002 ? Nothing like this is = discussed I can easily see interoperability issues arising from this (i.e., vendor = A might allow PIM 100 to overlap PIM 1001 and PIM 1002, and vendor B = might not). I think that some text to discuss the entire issue of = ranging (presumably, that they can be allowed and overlaps SHOULD be = supported) is needed. Again, this could be out of scope here, but, then, where will it appear = ?=20 2.) There is very little discussion as to how to use this capability. = Now, this might be considered out of scope for this document, but there = will be issues, and I do not see a follow-on in the pipeline.=20 Issues include sharing of links and the general connections between = topologies. It is likely that in real uses, a portion of the multiple = topologies may be either physically shared or directly linked. It may = not be possible to engineer out all single points of failure, for = example an undersea cable. This is possible with the first use case = (independent topologies for video) and likely with the second (different = topologies for different types of content).=20 Issues I see here include - the actual multicast data will not include any PIM attributes. How, = then, is a midpoint router receiving two copies of every packet know = that it shouldn't just drop one, and only populate one of the = downstreams ? Or, should it replicate one input into both downstream = topologies ? I can easily see interop issues here, and possibly even = more basic transport issues from replicated data.=20 - if at any point the two multicast topologies go through a shared LAN = or switch or any sort of multiple access network, how are the = topological flows going to be kept distinct. (This is similar to the = above, but the actual routers might be kept separate.)=20 - what happens with failovers ? If a link fails, SHOULD the backup links = not collapse the topologies ? Again, I think some thought and text would = be useful. If there is a solution to this, it may be simple (you MUST use tunnels) = or it may be complicated. In either case, some text here would be good.=20= Regards Marshall=20=