From mailman-bounces@ietf.org Tue Jun 1 06:43:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14746 for ; Tue, 1 Jun 2004 06:43:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV5SQ-0000uZ-BC for pim-archive@lists.ietf.org; Tue, 01 Jun 2004 05:21:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: pim-archive@ietf.org X-No-Archive: yes Message-ID: Date: Tue, 01 Jun 2004 05:03:36 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for pim-archive@lists.ietf.org: List Password // URL ---- -------- pim@ietf.org urahne https://www1.ietf.org/mailman/options/pim/pim-archive%40lists.ietf.org From mailman-admin@ietf.org Tue Jun 1 10:54:51 2004 Received: from optimus.ietf.org ([132.151.1.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10719 for ; Tue, 1 Jun 2004 10:54:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BV90T-0005JB-RX for pim-archive@lists.ietf.org; Tue, 01 Jun 2004 09:08:41 -0400 Date: Tue, 01 Jun 2004 09:08:41 -0400 Message-ID: <20040601130841.26555.48269.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: pim-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, pim-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for pim-archive@lists.ietf.org: List Password // URL ---- -------- pim@ietf.org urahne https://www1.ietf.org/mailman/options/pim/pim-archive%40lists.ietf.org From pim-bounces@ietf.org Wed Jun 2 03:32:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05157 for ; Wed, 2 Jun 2004 03:32:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVQ2r-0006cr-HF; Wed, 02 Jun 2004 03:20:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVPaS-0003K0-Pl for pim@megatron.ietf.org; Wed, 02 Jun 2004 02:50:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02901 for ; Wed, 2 Jun 2004 02:50:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVPaQ-0002ku-A9 for pim@ietf.org; Wed, 02 Jun 2004 02:50:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVPYa-0001ne-00 for pim@ietf.org; Wed, 02 Jun 2004 02:49:01 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BVPXO-0000od-00 for pim@ietf.org; Wed, 02 Jun 2004 02:47:46 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 01 Jun 2004 23:46:22 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i526lFXl000230 for ; Tue, 1 Jun 2004 23:47:16 -0700 (PDT) Received: from irp-view6.cisco.com (irp-view6.cisco.com [171.70.65.143]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATU34438; Tue, 1 Jun 2004 23:46:04 -0700 (PDT) Date: Tue, 1 Jun 2004 23:47:14 -0700 (PDT) From: Mike McBride To: pim@ietf.org Subject: [pim] WG Last Call - draft-ietf-pim-anycast-rp-01 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Today begins a Working Group Last Call for the Anycast-RP using PIM draft. The Last Call runs 2 weeks from Wednesday, June 2nd, 2004 to Wednesday, June 16, 2004. Please review this document and send comments either to the list or directly to the authors. The document can be found here: http://www.ietf.org/internet-drafts/draft-ietf-pim-anycast-rp-01.txt thanks, Tom and Mike _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Wed Jun 2 10:06:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22846 for ; Wed, 2 Jun 2004 10:06:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVVqz-00014p-Vn; Wed, 02 Jun 2004 09:32:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVT5H-0008Nl-FN for pim@megatron.ietf.org; Wed, 02 Jun 2004 06:34:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13790 for ; Wed, 2 Jun 2004 06:34:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVT57-0007O7-AA for pim@ietf.org; Wed, 02 Jun 2004 06:34:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVT43-0006qX-00 for pim@ietf.org; Wed, 02 Jun 2004 06:33:44 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BVT2x-0005lQ-00 for pim@ietf.org; Wed, 02 Jun 2004 06:32:35 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i52AVu806105; Wed, 2 Jun 2004 13:31:56 +0300 Date: Wed, 2 Jun 2004 13:31:56 +0300 (EEST) From: Pekka Savola To: Mike McBride Subject: Re: [pim] WG Last Call - draft-ietf-pim-anycast-rp-01 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org On Tue, 1 Jun 2004, Mike McBride wrote: > Today begins a Working Group Last Call for the Anycast-RP using PIM draft. > The Last Call runs 2 weeks from Wednesday, June 2nd, 2004 to Wednesday, > June 16, 2004. > > Please review this document and send comments either to the list or > directly to the authors. > > The document can be found here: > > http://www.ietf.org/internet-drafts/draft-ietf-pim-anycast-rp-01.txt And the aimed category is...? Proposed Standard? In any case, here are a few comments on the draft. The approach seems straightforward, even though slightly underspecified, relying on the implementations just "getting it right". substantial ----------- ==> this doc is missing a security considerations section. It must be added. ... o RP2 receives the Register message from RP1, decapsulates it, and also sends the packet down the shared-tree to get the packet to receiver R2. o RP2 sends a Register-Stop back to the RP1. ==> This seems to change the model slightly: register-stops are also sent back to the anycast-RPs (not just DRs), which have to be capable of processing them (of course, they are indistinguishable to the RPs). This spec doesn't mention RP1's processing of a received register-stop at all, or what kind of state RP1 needs to maintain for the register messages it forwards to the other RPs. This should probably be added. semi-editorial -------------- ==> the draft uses RFC2119 keywords but doesn't define or refer to them. Add the regular paragraph at the end of section 1 ? ==> there are a couple of lines longer than 72 chars/line, which is forbidden. ==> it also seems to be good practice to insert a dummy IANA considerations section, like: === IANA Considerations This document makes no request to IANA. Note to RFC Editor: this section may be removed on publication as an RFC. === ... Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. ==> this should be updated to the RFC3668, and you should also add the IPR etc. boilerplates at the end of the draft. o The DR directly attached to S1 will form a PIM Register message to send to RP1. The IP address to use is the Anycast-RP address. ==> so shouldn't you just say s/RP1/RPA/ ? 5. Possible Configuration Language ==> move this to an Appendix, too vendor-specific, but still useful. 9. References [1] Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM- SM): Protocol Specification", RFC 2362, June 1998. [2] Kim, Meyer, Kilmer, Farinacci, "Anycast RP mechanism using PIM and MSDP", Internet Draft draft-ietf-mboned-anycast-rp-08.txt, May 2001. ==> split to Normative ([1]?) and Informative ([2]?) References. Update [2] to be RFC3446. Note that [2] cannot be normative if this is going for PS. editorial --------- Anycast-RP using PIM ==> I guess this should be like: Anycast Rendezvous Point (RP) using Protocol Independent Multicast (PIM) ... Abstract This proposal allows Anycast-RP to be used inside a domain, which runs PIM only. There are no other multicast protocols required to support Anycast-RP, such as MSDP, which has been used traditionally to solve this problem. ==> s/proposal/specification/ ==> similar also later (e.g., s/draft/memo/) -- to make sure this continues to be valid after RFC publication, implementation etc.) ==> also spell out RP, PIM and MSDP here. Anycast-RP as described in [2] is a mechanism ISP-based backbones have used to get fast convergence when a PIM Rendezvous Point (RP) router fails. ==> 'ISP-based backbones' ?? o Each router acting as an RP MUST be configured with a loopback interface using the same (shared) IP address. This address is used to tell other routers in the PIM domain, what IP address to use for the RP address. ==> s/MUST/must/ (isn't this an operational requirement?) ==> s/, what/ what/ (or "which") o RP1 is configured with RP2 and RP3's IP address. It will forward the Register message from S1's DR to both of them. RP1 will include it's own IP address as the source address for the PIM Register message. ==> s/include/use/ (or 'replace'), s/it's/its/ (same elsewhere) o The source gets Registered to a single RP by the DR, it's the responsibility of the RP, the DR selects, to get the packet to all other RPs in the Anycast-RP set. ==> the DR doesn't really "select" the RP, it's chosen by the routing metrics. Just remove ", the DR selects, " or reword to something like "the RP closest to the DR" message as described in [2]. That means an SA for the same internal ==> spell out SA, someone could mistake it for a Security Association ;-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Tue Jun 8 22:33:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20461 for ; Tue, 8 Jun 2004 22:33:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXsiD-0008EB-T2; Tue, 08 Jun 2004 22:21:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXsZO-0004nh-E7 for pim@megatron.ietf.org; Tue, 08 Jun 2004 22:12:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18987 for ; Tue, 8 Jun 2004 22:12:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXsZM-0003mf-Fk for pim@ietf.org; Tue, 08 Jun 2004 22:12:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXsYO-0002uk-00 for pim@ietf.org; Tue, 08 Jun 2004 22:11:01 -0400 Received: from smtp1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 1BXsX3-0001Bf-00 for pim@ietf.org; Tue, 08 Jun 2004 22:09:37 -0400 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp1.procket.com (8.12.8p1/8.12.1) with ESMTP id i594KmpL088982; Tue, 8 Jun 2004 21:20:48 -0700 (PDT) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i5928jd1029679; Tue, 8 Jun 2004 19:08:45 -0700 (PDT) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i5928iZO018900; Tue, 8 Jun 2004 19:08:44 -0700 Date: Tue, 8 Jun 2004 19:08:44 -0700 Message-Id: <200406090208.i5928iZO018900@dino-pc.procket.com> From: Dino Farinacci To: pekkas@netcore.fi In-reply-to: message from Pekka Savola on Wed, 2 Jun 2004 13:31:56 +0300 (EEST) Subject: Re: [pim] WG Last Call - draft-ietf-pim-anycast-rp-01 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: mmcbride@cisco.com, pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Pekka, et al, my responses inline. I have updated the draft and will release a copy after the last call date (June 16th) so I can aggregate changes into the -02 draft. >> And the aimed category is...? Proposed Standard? I believe PS, but the coauthors should give final say. >> ==> this doc is missing a security considerations section. It must be >> added. We added one. >> ==> This seems to change the model slightly: register-stops are also >> sent back to the anycast-RPs (not just DRs), which have to be capable >> of processing them (of course, they are indistinguishable to the RPs). >> This spec doesn't mention RP1's processing of a received register-stop >> at all, or what kind of state RP1 needs to maintain for the register >> messages it forwards to the other RPs. This should probably be added. I have added text to indicate a Anycast-PIM RP should process Register- Stop messages like it would acting as a DR. >> ==> the draft uses RFC2119 keywords but doesn't define or refer to them. >> Add the regular paragraph at the end of section 1 ? >> >> ==> there are a couple of lines longer than 72 chars/line, which is >> forbidden. >> >> ==> it also seems to be good practice to insert a dummy IANA considerations >> section, like: >> >> === >> IANA Considerations >> >> This document makes no request to IANA. >> >> Note to RFC Editor: this section may be removed on publication as an RFC. >> === Fixed all the above. >> Status of this Memo >> >> This document is an Internet-Draft and is in full conformance with >> all provisions of Section 10 of RFC2026. >> >> ==> this should be updated to the RFC3668, and you should also add the IPR >> etc. boilerplates at the end of the draft. Fixed. >> o The DR directly attached to S1 will form a PIM Register message to >> send to RP1. The IP address to use is the Anycast-RP address. >> >> ==> so shouldn't you just say s/RP1/RPA/ ? We want to be explicit where the register is going from the DR's perspective. >> 5. Possible Configuration Language >> >> ==> move this to an Appendix, too vendor-specific, but still useful. Done. >> 9. References >> >> [1] Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM- >> SM): Protocol Specification", RFC 2362, June 1998. >> >> [2] Kim, Meyer, Kilmer, Farinacci, "Anycast RP mechanism using PIM >> and MSDP", Internet Draft draft-ietf-mboned-anycast-rp-08.txt, >> May 2001. >> >> ==> split to Normative ([1]?) and Informative ([2]?) References. Update [2] >> to be RFC3446. Note that [2] cannot be normative if this is going for >> PS. I made them all Informative. ;-) >> Anycast-RP using PIM >> >> ==> I guess this should be like: >> >> Anycast Rendezvous Point (RP) using Protocol Independent Multicast (PIM) I made this more clear in the Abstract rather than in the title. >> ==> s/proposal/specification/ >> ==> similar also later (e.g., s/draft/memo/) -- to make sure this continues to >> be valid after RFC publication, implementation etc.) Done. But did s/draft/specification/. >> ==> also spell out RP, PIM and MSDP here. Did this up front in the Abstract. >> Anycast-RP as described in [2] is a mechanism ISP-based backbones >> have used to get fast convergence when a PIM Rendezvous Point (RP) >> router fails. >> >> ==> 'ISP-based backbones' ?? Yes, because originally Anycast-RP with MSDP was deployed in the backbones of ISPs (and not other backbones like corporate or university). >> ==> s/MUST/must/ (isn't this an operational requirement?) >> ==> s/, what/ what/ (or "which") I kept MUST because it is a strong requirement >> o The source gets Registered to a single RP by the DR, it's the >> responsibility of the RP, the DR selects, to get the packet to all >> other RPs in the Anycast-RP set. >> >> ==> the DR doesn't really "select" the RP, it's chosen by the routing >> metrics. Just remove ", the DR selects, " or reword to something like "the >> RP closest to the DR" The RP is selected for the DR, yes, by the routing metrics. But the text is trying to say the original Register that goes to the RP (from the DR), must be forwarded to all other RPs. I clarified this by qualifying the metrics help the selection process. >> message as described in [2]. That means an SA for the same internal >> >> ==> spell out SA, someone could mistake it for a Security Association ;-) I didn't make this change. There is enough context in this section for the reader to know we are not discussing security. Thanks for your comments, Dino/Yiqun _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Fri Jun 18 02:02:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18129 for ; Fri, 18 Jun 2004 02:02:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbCN7-0001KX-L4; Fri, 18 Jun 2004 01:57:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbCCq-0007ts-KQ for pim@megatron.ietf.org; Fri, 18 Jun 2004 01:46:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14762 for ; Fri, 18 Jun 2004 01:46:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbCCo-0001AY-KP for pim@ietf.org; Fri, 18 Jun 2004 01:46:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbCBo-0000pF-00 for pim@ietf.org; Fri, 18 Jun 2004 01:45:26 -0400 Received: from smtp1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 1BbCAn-0000AI-00 for pim@ietf.org; Fri, 18 Jun 2004 01:44:21 -0400 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp1.procket.com (8.12.8p1/8.12.1) with ESMTP id i5I7tuuH099712 for ; Fri, 18 Jun 2004 00:55:57 -0700 (PDT) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i5I5hfd1026046 for ; Thu, 17 Jun 2004 22:43:41 -0700 (PDT) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i5I5hf5q011254; Thu, 17 Jun 2004 22:43:41 -0700 Date: Thu, 17 Jun 2004 22:43:41 -0700 Message-Id: <200406180543.i5I5hf5q011254@dino-pc.procket.com> From: Dino Farinacci To: pim@ietf.org Subject: [mmcbride@cisco.com: [pim] WG Last Call - draft-ietf-pim-anycast-rp-01] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org We have hit the last-call deadline. I received only one set of comments from Pekka. I responded to his email and the enclosed updated draft is ready. I will wait one day to repost in the ID directory as the -02 revision. Thanks, Dino ------------------------------------------------------------------------------- ------- Start of forwarded message ------- X-BrightmailFiltered: true Date: Tue, 1 Jun 2004 23:47:14 -0700 (PDT) From: Mike McBride To: pim@ietf.org Subject: [pim] WG Last Call - draft-ietf-pim-anycast-rp-01 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Today begins a Working Group Last Call for the Anycast-RP using PIM draft. The Last Call runs 2 weeks from Wednesday, June 2nd, 2004 to Wednesday, June 16, 2004. Please review this document and send comments either to the list or directly to the authors. The document can be found here: http://www.ietf.org/internet-drafts/draft-ietf-pim-anycast-rp-01.txt thanks, Tom and Mike _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim ------- End of forwarded message ------- ------------------------------------------------------------------------------- Network Working Group Dino Farinacci INTERNET-DRAFT Procket Networks Expiration Date: December 2004 Yiqun Cai cisco Systems June 17, 2004 Anycast-RP using PIM Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain, which runs Protocol Independent Multicast (PIM) only. There are no other multicast protocols required to support Anycast-RP, such as MSDP, which has been used traditionally to solve this problem. Farinacci, Cai [Page 1] Internet Draft Anycast-RP using PIM June 17, 2004 1.0 Introduction Anycast-RP as described in [2] is a mechanism ISP-based backbones have used to get fast convergence when a PIM Rendezvous Point (RP) router fails. To allow receivers and sources to Rendezvous to the closest RP, the packets from a source needs to get to all RPs to find joined receivers. This notion of receivers finding sources is the fundamental problem of source discovery which MSDP was intended to solve. However, if one would like to retain the Anycast-RP benefits from [2] with less protocol machinery, removing MSDP from the solution space is an option. This memo extends the Register mechanism in PIM so Anycast-RP functionality can be retained without using MSDP. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.0 Requirements o Each router acting as an RP MUST be configured with a loopback interface using the same (shared) IP address. This address is used to tell other routers in the PIM domain what IP address to use for the RP address. o The RP address or a prefix that covers the RP address is injected into the unicast routing system inside of the domain. o Each RP configures all other RPs used in the Anycast-RP set. This must be consistently configured in all RPs in the set. Farinacci, Cai [Page 2] Internet Draft Anycast-RP using PIM June 17, 2004 3.0 Mechanism The following diagram illustrates a domain using 3 RPs where receivers are joining to the closest RP according to where unicast routing metrics take them and 2 sources sending packets to their respective RPs. S1-----RP1 RP2 RP3------S3 / \ | / \ | R1 R1' R2 Assume the above scenario is completely connected where R1, R1', and R2 are receivers for a group, and S1 and S2 send to that group. Assume RP1, RP2 and RP3 are all assigned the same IP address which is used as the Anycast-RP address (let's say the IP address is RPA). Note, the address used for the RP address in the domain (the Anycast- RP address) needs to be a different than the addresses used by the Ancyast-RP routers to communicate with each other. The following procedure is used when S1 starts sourcing traffic: o S1 sends a multicast packet. o The DR directly attached to S1 will form a PIM Register message to send to RP1. The IP address to use is the Anycast-RP address. o RP1 will receive the PIM Register message, decapsulate it, send the packet down the shared-tree to get the packet to receivers R1 and R1'. o RP1 is configured with RP2 and RP3's IP address. It will forward the Register message from S1's DR to both of them. RP1 will use its own IP address as the source address for the PIM Register message. o RP1 sends a Register-Stop back to the DR. o RP1 MAY join back to the source-tree by triggering a (S1,G) Join message toward S1. However, RP1 MUST create (S1,G) state. o RP2 receives the Register message from RP1, decapsulates it, and also sends the packet down the shared-tree to get the packet to receiver R2. o RP2 sends a Register-Stop back to the RP1. RP1 processes the Register-Stop just like it would if it was a DR. Farinacci, Cai [Page 3] Internet Draft Anycast-RP using PIM June 17, 2004 o RP2 MAY join back to the source-tree by triggering a (S1,G) Join message toward S1. However, RP2 MUST create (S1,G) state. o RP3 receives the Register message from RP1, decapsulates it, but since there are no receivers joined for the group, it can discard the packet. o RP3 sends a Register-Stop back to the RP1. o RP3 creates (S1,G) state so when a receiver joins after S1 starts sending, RP3 can join quickly to the source-tree for S1. The procedure for S3 sending follows the same as above but it is RP3 which forwards the Register originated by S3's DR to RP1 and RP2. Therefore, this example shows how sources anywhere in the domain, associated with different RPs, can reach all receivers, also associated with different RPs, in the same domain. 4.0 Observations and Guidelines about this Proposal o An RP will forward a Register only if the Register is received from an IP address not in the Anycast-RP list (i.e. the Register came from a DR and not another RP). o Each DR that PIM registers for a source will send the message to it's closest RP address. Therefore there are no changes to the DR logic. o Packets flow to all receivers no matter what RP they have joined to. o The source gets Registered to a single RP by the DR, it's the responsibility of the RP, the DR selects (based on routing metrics), to get the packet to all other RPs in the Anycast-RP set. o Logic is changed only in the RPs. The logic change is for forwarding Register messages. Register-Stop processing is unchanged. However, an implementation MAY suppress sending Register-Stop messages in response to a Register received from an RP. o The rate-limiting of Register and Register-Stop messages are done end-to-end. That is from DR -> RP1 -> {RP2 and RP3}. There is no need for specific rate-limiting logic between the RPs. o When topology changes occur, the existing source-tree adjusts as it Farinacci, Cai [Page 4] Internet Draft Anycast-RP using PIM June 17, 2004 does today according to [1]. The existing shared-trees, as well, adjust as it does today according to [1]. o Physical RP changes are as fast as unicast route convergence. Retaining the benefit of [2]. o An RP that doesn't support this specification can be mixed with RPs that do support this specification. However, the non-supporter RPs should not have sources registering to it but may have receivers joined to it. o If Null Registers are sent (Registers with an IP header and no IP payload), they MUST be replicated to all of the RPs in the Anycast- RP set so that source state remains alive for active sources. o The number of RPs in the Anycast-RP set should remain small so the amount of non-native replication is kept to a minimum. 5.0 Interaction with MSDP running in an Anycast-PIM Router The objective of this Anycast-PIM proposal is to remove the dependence on using MSDP. This can be achieved by removing MSDP peering between the Anycast RPs. However, to advertise internal sources to routers outside of a PIM routing domain and to learn external sources from other routing domains, MSDP may still be required. 5.1 Anycast-PIM Stub Domain Functionality In this capacity, when there are internal sources that need to be advertised externally, an Anycast-RP which receives a Register message, either from a DR or an Anycast-RP, should process it as described in this specification as well as how to process a Register message as described in [2]. That means an SA for the same internal source could be originated by multiple Anycast-RPs doing the MSDP peering. There is nothing inherently wrong with this other than the source is being advertised into the MSDP infrastructure from multiple places from the source domain. However, if this is not desirable, configuration of one or more (rather than all) Anycast-RP MSDP routers would allow only those routers to originate SAs for the internal source. And in some situations, there is a good possibility Farinacci, Cai [Page 5] Internet Draft Anycast-RP using PIM June 17, 2004 not all Anycast-RPs in the set will have MSDP peering sessions so this issue can be mitigated to a certain extent. From an Anycast-RP perspective, a source should be considered internal to a domain, when it is discovered by an Anycast-RP through a received Register message. Regardless, if the Register message was sent by a DR, another Anycast-RP member, or the router itself. For learning sources external to a domain, the MSDP SA messages could arrive at multiple MSDP-peering Anycast-RPs. The rules for processing an SA, according to [2], should be followed. That is, if G is joined in the domain, an (S,G) join is sent towards the source. And if data accompanies the SA, each Anycast-PIM RP doing MSDP peering will forward the data down each of their respective shared-trees. The above assumes each Anycast-RP has external MSDP peering connections. If this is not the case, the Anycast-PIM routers with the MSDP peering connections would follow the same procedure as if a Data-Register or Null-Register was received from either a DR or another Anycast-RP. That is, they would send Registers to the other members of the Anycast-RP set. If there is a mix of Anycast-RPs that do and do not have external MSDP peering connections, then the ones that do must be configured with the set that do not. So Register messages are sent only to the members of the Anycast-RP set that do not have external MSDP peering connections. 5.2 Anycast-PIM Transit Domain Functionality Within a routing domain, it is recommended that an Anycast-RP set defined in this specification should not be mixed with MSDP peering among the members. In some cases, the source discovery will work but it may not be obvious to the implementations what sources are local to the domain and which are not. This may affect external MSDP advertisement of internal sources. Having said that, this draft makes no attempt to connect MSDP peering domains together by using Anycast-PIM inside a transit domain. 6.0 IANA Considerations This document makes no request to IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Farinacci, Cai [Page 6] Internet Draft Anycast-RP using PIM June 17, 2004 7.0 Security Consideration This section describes the security consideration for Register and Register-Stop messages between Anycast-RPs. For PIM messages between DR and RP, please see [3]. 7.1 Attack Based On Forged Messages An attacker may forge a Register message using one of the addresses in the Anycast-RP list in order to achieve one or more of the following effects: 1. Overwhelm the target RP in a denial-of-service attack 2. Inject unauthorized data to receivers served by the RP 3. Inject unauthorized data and create bogus SA entries in other PIM domains if the target RP has external MSDP peerings An attacker may also forge a Register-Stop message using one of the addresses in the Anycast-RP list. However, besides denial-of- service, the effect of such an attack is limited because an RP usually ignores Register-Stop messages. 7.2 Protect Register and Register-Stop Messages The DOS attack using forged Register or Register-Stop messages can not be prevented. But the RP can still be protected. For example, the RP can rate-limit incoming messages. It can also choose to refuse to process any Register-Stop messages. The actual protection mechansim is implementation specific. The distribution of unauthorized data and bogus SA entries can be prevented using the method recommended in [3]. That is IPsec [4] transport mode using the Authentication Header (AH). There are two options a network administrator can choose from. An RP can be configured using a unique SA and SPI for traffic (Registers or Register-Stops) to each member of Anycast-RPs in the list. Alternatively, a single authentication algorithm and associated parameters can be used for the entire Anycast-RP set in order to reduce the overhead of key distribution. Farinacci, Cai [Page 7] Internet Draft Anycast-RP using PIM June 17, 2004 8.0 Acknowledgments The authors would like to thank Yiqun Cai and Dino Farinacci for prototyping this draft in the cisco IOS and Procket implementations, respectively. The authors would like to thank John Zwiebel for doing interoperability testing of the two prototype implementations. And finally, the authors would like to thank Greg Shepard from Procket Networks, Lenny Giuliano from Juniper Networks, Prashant Jhingran from Huawei Technologies, and Pekka Savola from Netcore Oy, for their comments on earlier drafts. 9.0 Author Information Dino Farinacci Procket Networks dino@procket.com Yiqun Cai cisco Systems ycai@cisco.com 10.0 Informative References [1] Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM- SM): Protocol Specification", RFC 2362, June 1998. [2] Kim, Meyer, Kilmer, Farinacci, "Anycast RP mechanism using PIM and MSDP", Internet Draft draft-ietf-mboned-anycast-rp-08.txt, May 2001. [3] Fenner, Handley, Holbrook, Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM):Protocol Specification (Revised)", Internet Draft draft-ietf-pim-sm-v2-new-09.txt, February 2004. [4] Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. Farinacci, Cai [Page 8] Internet Draft Anycast-RP using PIM June 17, 2004 Appendix A - Possible Configuration Language A possible set of commands to be used could be: ip pim anycast-rp Where: describes the Anycast-RP set for the RP which is assigned to the group range. This IP address is the address that first-hop and last-hop PIM routers use to register and join to. describes the IP address where Register messages are forwarded to. This IP address is any address assigned to the RP router not including the . Example: From the illustration above, the configuration commands would be: ip pim anycast-rp RPA RP1 ip pim anycast-rp RPA RP2 ip pim anycast-rp RPA RP3 Comment: It may be useful to include the local router's IP address in the command set so the above lines can be cut-and-pasted or scripted into all the RPs in the Anycast-RP set. But the implementation would have to be aware of it's own address and not inadvertently send a Register to itself. Farinacci, Cai [Page 9] ------------------------------------------------------------------------------- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Mon Jun 21 15:32:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20170 for ; Mon, 21 Jun 2004 15:32:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcUMP-0007k0-Nu; Mon, 21 Jun 2004 15:21:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcSNk-0002w5-6K for pim@megatron.ietf.org; Mon, 21 Jun 2004 13:14:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06560 for ; Mon, 21 Jun 2004 13:14:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcSNj-0006HT-7J for pim@ietf.org; Mon, 21 Jun 2004 13:14:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcS5x-0002zK-00 for pim@ietf.org; Mon, 21 Jun 2004 12:56:36 -0400 Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1BcRXM-0006NW-00 for pim@ietf.org; Mon, 21 Jun 2004 12:20:48 -0400 Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jun 2004 17:20:15 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803581074@baker.datcon.co.uk> From: James Lingard To: "'nbhaskar@cisco.com'" Date: Mon, 21 Jun 2004 17:19:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: "'pim@ietf.org'" Subject: [pim] Comments on draft-ietf-pim-sm-bsr-03.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Hi, I have the following comments on the last version of the BSR draft. I don't know at what stage of production the next version of the draft is, but I hope that at least some of my suggestions will be able to make their way into it. Since there are rather a lot of comments, I've grouped them into four categories: - Major comments - Other substantial comments - Editorial comments - Minor editorial comments (typos, etc.) If anything is unclear, or if you require any further clarifications, please let me know. Thanks, James. ========================================================================== Major Comments (in rough order of importance) ========================================================================== Semantic fragmentation ---------------------- 1) The document needs to distinguish more clearly between a single PIM control packet of type 4, and the collection of such packets from the same BSR with the same Fragment ID. At the moment, the document calls the former both a "Bootstrap message", a "semantic fragment" and a "BSMF", while the latter is called a "Bootstrap message". My comments are: - Consistent, unambiguous terminology should be used throughout. I suggest "semantic fragment" and "Bootstrap message" respectively for the cases above - and I have used this terminology in the rest of this mail. - The concepts and terminology relating to semantic fragmentation of Bootstrap messages should be introduced in section 1 of the document, not in section 4, because much of sections 2 and 3 depend on it. 2) It is not clear how semantic fragmentation interacts with the rest of the protocol, for example the state machines. The events in the state machines are described in terms of receiving Bootstrap messages. However, I assume this actually means semantic fragment (since we can never know when we've received a complete Bootstrap message). 3) Using semantic fragmentation to separate Bootstrap messages for different admin scopes complicates the description of the protocol further. I suggest simplifying things by mandating that a different Fragment Tag be used for any semantic fragments that belong to different admin scopes. Therefore, a single Bootstrap message would apply to a single admin scope. --- Some questions about the mechanics of fragment reassembly. Please could you clarify the document to answer these questions. - How long should a BSMF be held pending receipt of another BSMF necessary to complete the group-prefix information in the first BSMF? - Do we carry out actions in the state machines on receiving a BSMF even if we have to wait for matching BSMFs to arrive for some or all group-prefixes? - What should a router do if while waiting for a subsequent BSMF it receives another BSMF from the same BSR for the same admin scope with a different Fragment Tag? Discard the old BSMF? - How does this interact with the storing of Bootstrap messages for forwarding to new neighbors? Do we throw away the stored Bootstrap message every time we receive a new one (for the same admin scope) with a different Fragment Tag? This would mess things up if the second Fragment Tag is actually an older one arriving out of sequence. --- The document is inconsistent in its description of the purpose of semantic fragmentation. Is its purpose - to prevent IP fragmentation being done on Bootstrap packets larger than the link MTU size (as suggested by section 4.1.1), or - just to handle Bootstrap messages larger than the maximum IP packet size (as suggested at the start of section 4.1). If the former, then routers that forward Bootstrap messages potentially need to perform semantic fragmentation of the packets they forward, which isn't stated anywhere in the draft. Relationship of BSR with BIDIR-PIM ---------------------------------- Assuming that the relationship of BIDIR-PIM with BSR is within the scope of the document: - the draft should be renamed to make it not Sparse Mode specific, and references to PIM-SM should be replaced with PIM - the draft needs a discussion of how the BIDIR bit is to be used in C-RP-Adv and Bootstrap messages - the draft needs to explain how Bootstrap Routers resolve conflicts between group ranges advertised for BIDIR and SM in different C-RP-Adv messages, and how other routers resolve such conflicts in received Bootstrap messages. Bootstrap messages originated by a new Bootstrap Router ------------------------------------------------------- This may be due to a misreading on my part, but the draft seems to imply that when a new Bootstrap Router is first elected, its Bootstrap messages will have an empty RP-Set (since it will not yet have received any C-RP-Adv messages). This would break all routing temporarily until the new BSR sends another Bootstrap message, as the empty RP-Set would replace the RP-Set previously in use by the recipients. Is there intended to be a mechanism for either - new Bootstrap Routers to send Bootstrap messages that are non-empty (for example, do they send out the same RP-Set that they received from the previously elected Bootstrap Router?) - recipients of a Bootstrap message from a newly elected Bootstrap Router to continue to use the RP-Set advertised by the previously elected Bootstrap Router? Administrative scoping and RP election -------------------------------------- How does administrative scoping interact with RP election? Some questions, which don't seem to be clearly answered by the draft. - Does a C-RP send the same C-RP-Adv messages to each elected BSR? Or does it restrict the contents of the C-RP-Adv message sent to a scope zone's BSR to contain only group-ranges contained within (or intersecting?) the scoped range? - When a router does a group-to-RP lookup for a group within a scoped range, how exactly does this work? Is the algorithm in the PIM-SM specification applied to the union of all RP information received from all elected BSRs? Or is a longest-prefix match performed on the administrative scope zone ranges first, and only those RPs received in the Bootstrap message from the longest matching scope zone's BSR used? Accepting unicast messages at startup ------------------------------------- The pseudo-code for checking received Bootstrap messages (section 3, page 15) says if (Any previous BSM for this scope has been accepted) ... This in strictly unimplementable in its present form, since it would require the router to store the list of scopes for which it had recevied a BSM indefinitely, resulting in a memory leak. There is also the problem of how this would interact with semantic fragmentation, as the router needs to accept every fragment of the message, not just the first. I would suggest a simple timer-based mechanism instead. Candidate-RP Holdtime --------------------- Why is the RP Holdtime transmitted in Bootstrap messages? There doesn't seem to be any reason for it at all. In fact, why does the Bootstrap Router even need to store the RP Holdtime, since it should only be used on receipt of a C-RP-Adv message to initialize the C-RP Expiry Timer? If the RP Holdtime field is present purely for backwards compatibility then the document should explicity say so, to prevent readers from wasting time trying to work out its intended use. Timer values ------------ In section 5 (Default Values for Timers), we should be clear about which timer durations - are configurable, with a fixed default - are configurable, with a default which is based on the current values of other timer durations - are REQUIRED to be determined in terms of other timers. In particular, there are a couple of inconsistencies between section 5 and the rest of the document. - Section 3 (page 16) says that BS Timeout defaults to "2 times the BS Period plus 10 seconds, which is 130 seconds". Section 5 (page 29) says that the value of BS Timeout is "2 * BSPeriod + 10 seconds". - Section 3 (page 17) says that SZ Timeout defaults to "ten times the BS Timeout, which is 1300 seconds". Section 5 (page 30) says that the value of SZ Timeout is 1300 seconds. ============================================================================ === Other Substantial Comments (in document order) ============================================================================ === Section 3, page 11. The Candidate-BSR state machine is missing the event 'reveive non-preferred BSM from a router that isn't the Elected BSR', when in the C-BSR state. Presumably the action is simply to stay in the C-BSR state (and not forward the message, and not restart the BS Timer). Section 3, page 13. In the Non-Candidate-BSR state machine, when is the SZ Timer restarted? Presumably this should happen every time the BS timer is restarted. Section 3, page 15. The list of 'BS State-machine Transition Events' is missing descriptions of several other events. Section 3, page 17/18. When forwarding or originating a Bootstrap message, the source IP address of the message should be the *primary* IP address on the interface, as used with the PIM Hello protocol. Section 3, page 18. The unicasting of Bootstrap messages to new neighbors should also be done when the neighbor's GenID changes, and should be done for the Bootstrap messages for each Elected BSR. Section 3.1, page 19. Does a Bootstrap Router issue a triggered Bootstrap message when it receives a C-RP-Adv message with a Holdtime of 0? This section implies that this is the case, but this isn't mentioned anywhere else in the document. Section 3.2, page 19. Is all C-RP state deleted on receipt of a new C-RP-Adv message with the same RP Address? Or is the old state kept as well until its Holdtime has expired? If the former, is there any way for a C-RP to split C-RP state across multiple C-RP-Adv messages? Section 3.4, page 21. I assume the intention of this section is to say that whenever a new RP-Set is receieved, for each group for which there is PIM state, if the RP that would be computed using the new RP-Set is different from the RP that was computed using the old RP-Set, the new RP should be used by PIM for that group. However, this isn't what it says. For example, if the same collection of RPs appear in the new RP-Set but with different priority values, or if a new RP with a higher priority or a more specific prefix match is received, the algorithm described in this section won't tell you to use the new RP. Section 4.1, page 25. What BSR Address should be used when originating a Bootstrap message? Does it have to be the primary address on a PIM interface? I believe it can be any of the router's non-local unicast addresses, but it's worth saying. Section 4.1.1, page 26. Semantic fragmenation is only strictly necessary for packets over the maximum IP packet size, not the link MTU as stated in this section, since we could let the IP stack perform IP fragmentation. Section 4.2, page 28. Is there an upper limit on the size of a Candidate-RP-Advertisement message? ========================================================================== Editorial Comments (in document order) ========================================================================== Section 2, page 9. This section is missing various pieces of state that need to be stored, for example those mentioned in section 3.2. Section 2, page 9. Note that 'Per Scope Zone' also includes the global scope. Section 2, page 10. It's confusing to have timers separated from other state. Section 3, page 13. In the 'Receive BSM for unknown Admin Scope' event of the Non-Candidate-BSR state machine, the phrase 'for unknown Admin Scope' is redundant, since by definition the admin scope is unknown if we're in the NoInfo state. (Compare the PIM-SM draft, where the events don't say, for example, 'Receive Join(*,G) for unknown G'.) Section 3, page 15. The meaning of each of the terms in the pseudo-code should be explained briefly. Section 3, page 16. It seems rather odd to have the algorithm for 'randomized override interval' in the body of the text. Perhaps this should be moved to an appendix, or to the timers section (section 5). Also, an explanation of the rationale behind the algorithm would be interesting. Section 3, page 18. Sending Bootstrap messages by unicast to new neighbors seems like quite a significant protocol element to be tucked away at the end of this section and not really mentioned anywhere else. Section 3.1, page 19. When we say that 'zero is the highest possible priority' we should explain that this means in general that lower priority values mean higher priority. It's explained clearly on the following page, but not here. Section 4, page 23. Why explicitly specify the size of the Mask Len field, but not any of the other fields? Section 4.1, page 25. In the description of the Group Address field, we should also state that the Admin Scope bit may _only_ be set in the first group address field of a semantic fragment. ========================================================================== Minor Editorial Comments (typos, etc.) ========================================================================== The following pieces of terminology are used inconsistently throughout the document, with respect to capitalization, punctuation and abbreviations. These are listed as (suggested versions | synonyms): - Bootstrap message; BSM | Bootstrap Message; BSR message; BS message - C-RP-Advertisement; C-RP-Adv | C-RP advertisement - RP-Set | RPset; RP Set - BSR Priority | BSR priority; BSR-priority - RP Priority | RP priority - Candidate-RP; C-RP | candidate-RP; Candidate RP; candidate RP - Holdtime | HoldTime - PIM Sparse Mode | PIM Sparse-mode - state machine | state-machine Simple typos (please let me know if you need more context): - Section 1.1, page 5, last para. s/them/then/ - Section 1.1, page 5, last para. s/the/be/ - Section 3, page 15, pseudo-code. s/if ( (Any/if (Any/ - Section 3.1, page 19, second para. s/must/MUST/ - Section 4, page 21. s/4 Bootstrap Message/4 Bootstrap/ - Section 4.1, page 25. s/BSR priority priority/BSR priority/ - Section 4.1, page 25. s/Unicast BSR Address/BSR Address/ - Section 4.1, page 26. s/Frag RP-Cnt/Frag RP Cnt/ - Section 6.3, page 32, second para. s/principle/principal/ - Section 6.3, page 32, third para. s/BootStrap/Bootstrap/ - Section 6.3, page 32, last para. s/than/that/ Other simple editorial errors: - Section 2, page 9/10. Inconsistent bulleting style. - Section 3, page 15. "or the router must have no BSR state" Should say: "no BSR state for that admin scope" - Section 3, page 16. "setting the BS timer" Should say: "setting the BS timer and SZ timer" - Section 3.2, page 19. "If the router is not the elected BSR" Should say: "if the router is not the elected BSR for any scope zone" - Section 4.1, page 25. Missing newline between "Type" and "PIM Message Type". - Section 4.2, page 28. Should use "Prefix Count" not "Prefix Cnt". - Section 5, page 29. "Period between bootstrap messages". Should say: "Period between originating bootstrap messages" - Section 5, page 30. Table headings messed up. --- James Lingard Data Connection Ltd (DCL) http://www.dataconnection.com/ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Tue Jun 22 20:00:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14251 for ; Tue, 22 Jun 2004 20:00:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BctoX-0008Hv-4m; Tue, 22 Jun 2004 18:32:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcrPk-0006k0-UF; Tue, 22 Jun 2004 15:58:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24561; Tue, 22 Jun 2004 15:58:38 -0400 (EDT) Message-Id: <200406221958.PAA24561@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Jun 2004 15:58:38 -0400 Cc: pim@ietf.org Subject: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-02.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Anycast-RP using PIM Author(s) : D. Farinacci, Y. Cai Filename : draft-ietf-pim-anycast-rp-02.txt Pages : 9 Date : 2004-6-22 This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain, which runs Protocol Independent Multicast (PIM) only. There are no other multicast protocols required to support Anycast-RP, such as MSDP, which has been used traditionally to solve this problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-anycast-rp-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-anycast-rp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-anycast-rp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-22152313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-anycast-rp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-anycast-rp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-22152313.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --NextPart-- From pim-bounces@ietf.org Tue Jun 22 20:24:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16751 for ; Tue, 22 Jun 2004 20:24:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BctwG-0001Q3-50; Tue, 22 Jun 2004 18:40:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb05s-0003Us-AX for pim@megatron.ietf.org; Thu, 17 Jun 2004 12:50:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19551 for ; Thu, 17 Jun 2004 12:50:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb05r-0005XR-CW for pim@ietf.org; Thu, 17 Jun 2004 12:50:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bazzn-0004GU-00 for pim@ietf.org; Thu, 17 Jun 2004 12:44:12 -0400 Received: from io.iol.unh.edu ([132.177.123.82]) by ietf-mx with esmtp (Exim 4.12) id 1Bazs3-0002KI-00 for pim@ietf.org; Thu, 17 Jun 2004 12:36:11 -0400 Received: from [132.177.118.43] (palm.iol.unh.edu [132.177.118.43]) by io.iol.unh.edu (8.12.11/8.12.11) with ESMTP id i5HGZSln009128 for ; Thu, 17 Jun 2004 12:35:28 -0400 From: Greg Schwendimann To: pim@ietf.org Content-Type: text/plain Message-Id: <1087490128.998.3.camel@palm> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 17 Jun 2004 12:35:29 -0400 Content-Transfer-Encoding: 7bit X-UNH-IOL-MailScanner-Information: Please contact systems@iol.unh.edu for more information X-UNH-IOL-MailScanner: Found to be clean X-MailScanner-From: gregs@iol.unh.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 22 Jun 2004 18:38:23 -0400 Subject: [pim] Unknown Pim Hello options X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello, I have read the pim spec but cannot find out what a router should do with an unknown pim hello option. The spec says I may ignore the option. Does that mean the routers should become neighbors or ignore each others hello messages? Thanks Greg _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Thu Jun 24 14:13:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08042 for ; Thu, 24 Jun 2004 14:13:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXNu-0002yE-Nh; Thu, 24 Jun 2004 12:47:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdDCy-0005Om-Co for pim@megatron.ietf.org; Wed, 23 Jun 2004 15:14:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07356 for ; Wed, 23 Jun 2004 15:14:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdDCw-0004Ds-NF for pim@ietf.org; Wed, 23 Jun 2004 15:14:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdDBs-0003n7-00 for pim@ietf.org; Wed, 23 Jun 2004 15:13:49 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BdDAn-000320-00 for pim@ietf.org; Wed, 23 Jun 2004 15:12:41 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i5NJCB913473; Wed, 23 Jun 2004 12:12:11 -0700 (PDT) (envelope-from pusateri@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i5NJC6J29090; Wed, 23 Jun 2004 12:12:06 -0700 (PDT) (envelope-from pusateri@juniper.net) Message-Id: <200406231912.i5NJC6J29090@merlot.juniper.net> To: Greg Schwendimann Subject: Re: [pim] Unknown Pim Hello options In-Reply-To: Message from Greg Schwendimann of "Thu, 17 Jun 2004 12:35:29 EDT." <1087490128.998.3.camel@palm> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17551.1088017926.1@juniper.net> Date: Wed, 23 Jun 2004 12:12:06 -0700 From: Tom Pusateri X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: pusateri@juniper.net, pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org I would log the option and then ignore it. You should still treat the sender as a neighbor. Tom In message <1087490128.998.3.camel@palm> you write: >Hello, > I have read the pim spec but cannot find out what a router should do >with an unknown pim hello option. The spec says I may ignore the >option. Does that mean the routers should become neighbors or ignore >each others hello messages? > > >Thanks >Greg > > >_______________________________________________ >pim mailing list >pim@ietf.org >https://www1.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Thu Jun 24 15:45:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20276 for ; Thu, 24 Jun 2004 15:45:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXQ1-0003gW-Qd; Thu, 24 Jun 2004 12:49:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdI92-0004xa-9H for pim@megatron.ietf.org; Wed, 23 Jun 2004 20:31:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00809 for ; Wed, 23 Jun 2004 20:31:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdI90-0001D9-C3 for pim@ietf.org; Wed, 23 Jun 2004 20:31:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdI82-0000oO-00 for pim@ietf.org; Wed, 23 Jun 2004 20:30:11 -0400 Received: from possum.icir.org ([192.150.187.67]) by ietf-mx with esmtp (Exim 4.12) id 1BdI7C-0000S0-00 for pim@ietf.org; Wed, 23 Jun 2004 20:29:18 -0400 Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i5O0TEKh083244; Wed, 23 Jun 2004 17:29:14 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Message-Id: <200406240029.i5O0TEKh083244@possum.icir.org> To: Greg Schwendimann Subject: Re: [pim] Unknown Pim Hello options In-Reply-To: Message from Greg Schwendimann of "Thu, 17 Jun 2004 12:35:29 EDT." <1087490128.998.3.camel@palm> Date: Wed, 23 Jun 2004 17:29:14 -0700 From: Pavlin Radoslavov X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org > I have read the pim spec but cannot find out what a router should do > with an unknown pim hello option. The spec says I may ignore the > option. Does that mean the routers should become neighbors or ignore > each others hello messages? I believe the answer is that if one of the routers includes a Hello option that the other router(s) don't understand, but the rest of the message is fine (e.g., it contains the HoldTime option, etc), then the routers still should become neighbors. If you have several PIM routers on a LAN and some of them ignore each other's Hello messages, bad things can happen. E.g., the PIM Assert messages will be rejected with all negative result of that (duplicate traffic, etc). Indeed, the spec doesn't say explicitly that the routers still should be neighbors, so I'd be interested to know if other people have different interpretations. Pavlin _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Thu Jun 24 16:29:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26363 for ; Thu, 24 Jun 2004 16:29:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXUg-0005E3-Ql; Thu, 24 Jun 2004 12:54:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdW8g-0005uz-Bb for pim@megatron.ietf.org; Thu, 24 Jun 2004 11:27:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21384 for ; Thu, 24 Jun 2004 11:27:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdW8f-0000iJ-7H for pim@ietf.org; Thu, 24 Jun 2004 11:27:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdW7n-0000Lg-00 for pim@ietf.org; Thu, 24 Jun 2004 11:26:51 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BdW76-0007iW-00 for pim@ietf.org; Thu, 24 Jun 2004 11:26:08 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 4C04C2D4959; Thu, 24 Jun 2004 11:25:38 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03228-01-44; Thu, 24 Jun 2004 11:25:36 -0400 (EDT) Received: from nexthop.com (ctbrown.nexthop.com [65.247.36.75]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 6751B2D48E8; Thu, 24 Jun 2004 11:25:36 -0400 (EDT) From: Christopher Thomas Brown Subject: Re: [pim] Unknown Pim Hello options To: Greg Schwendimann In-Reply-To: Your message of "Thu, 17 Jun 2004 12:35:29 EDT." <1087490128.998.3.camel@palm> Date: Thu, 24 Jun 2004 11:16:34 -0400 Message-Id: <20040624152536.6751B2D48E8@aa-mx1.nexthop.com> X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org On Thu, 17 Jun 2004 12:35:29 EDT Greg Schwendimann wrote: >Hello, > I have read the pim spec but cannot find out what a router should do >with an unknown pim hello option. The spec says I may ignore the >option. Does that mean the routers should become neighbors or ignore >each others hello messages? It means the option may be ignored. If an implementation does ignore such options then yes they would become neighbors. If an implementation does not ignore such options then it depends on what it does do (eg drop or log or ???). Chris _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Thu Jun 24 18:21:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21724 for ; Thu, 24 Jun 2004 18:21:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdc8D-0008AB-1B; Thu, 24 Jun 2004 17:51:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdbns-0003Ch-5g for pim@megatron.ietf.org; Thu, 24 Jun 2004 17:30:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14031 for ; Thu, 24 Jun 2004 17:30:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdbnq-0003uG-PE for pim@ietf.org; Thu, 24 Jun 2004 17:30:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdb8w-00045e-00 for pim@ietf.org; Thu, 24 Jun 2004 16:48:23 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdaUE-0004Gc-03 for pim@ietf.org; Thu, 24 Jun 2004 16:06:18 -0400 Received: from smtp1.procket.com ([65.174.124.36]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdaIj-0008JR-8n for pim@ietf.org; Thu, 24 Jun 2004 15:54:25 -0400 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp1.procket.com (8.12.8p1/8.12.1) with ESMTP id i5OM6AuH070378; Thu, 24 Jun 2004 15:06:10 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i5OJrkd1029518; Thu, 24 Jun 2004 12:53:46 -0700 (PDT) Received: from [10.1.5.104] ([10.1.5.104]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jun 2004 12:53:45 -0700 In-Reply-To: <200406240029.i5O0TEKh083244@possum.icir.org> References: <200406240029.i5O0TEKh083244@possum.icir.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <32A496B0-C618-11D8-8D08-0003936A6062@procket.com> Content-Transfer-Encoding: 7bit From: John Zwiebel Subject: Re: [pim] Unknown Pim Hello options Date: Thu, 24 Jun 2004 12:53:43 -0700 To: Pavlin Radoslavov X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 24 Jun 2004 19:53:45.0917 (UTC) FILETIME=[F59BD6D0:01C45A24] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: Greg Schwendimann , pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Content-Transfer-Encoding: 7bit On Jun 23, 2004, at 5:29 PM, Pavlin Radoslavov wrote: > Indeed, the spec doesn't say explicitly that the routers still > should be neighbors, so I'd be interested to know if other people > have different interpretations. > 2cents Yes, still become neighbors, but let's say that one of the routers on the LAN does not support bi-dir (as an example) then none of the routers on the LAN should do bi-dir. There is no 'hello-ack' so its possible to have asymmetrical neighborliness ;-) A prescription for disaster. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Fri Jun 25 10:56:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06928 for ; Fri, 25 Jun 2004 10:56:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdrO9-00060B-J5; Fri, 25 Jun 2004 10:09:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdrKB-0003If-Eu; Fri, 25 Jun 2004 10:05:03 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01213; Fri, 25 Jun 2004 10:05:01 -0400 (EDT) Message-Id: <200406251405.KAA01213@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 25 Jun 2004 10:05:01 -0400 Cc: pim@ietf.org Subject: [pim] I-D ACTION:draft-ietf-pim-dm-new-v2-05.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) Author(s) : A. Adams, et al. Filename : draft-ietf-pim-dm-new-v2-05.txt Pages : 55 Date : 2004-6-24 This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers with no group membership information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-dm-new-v2-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-dm-new-v2-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-dm-new-v2-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-25102546.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-dm-new-v2-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-dm-new-v2-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-25102546.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --NextPart-- From pim-bounces@ietf.org Fri Jun 25 13:59:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28556 for ; Fri, 25 Jun 2004 13:59:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdur6-0004rb-RX; Fri, 25 Jun 2004 13:51:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bduh0-0001DH-A6 for pim@megatron.ietf.org; Fri, 25 Jun 2004 13:40:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27137 for ; Fri, 25 Jun 2004 13:40:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdugz-0000mH-DI for pim@ietf.org; Fri, 25 Jun 2004 13:40:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdufZ-000076-00 for pim@ietf.org; Fri, 25 Jun 2004 13:39:21 -0400 Received: from [24.248.74.254] (helo=hatl0ms22.CORP.COX.COM) by ietf-mx with esmtp (Exim 4.12) id 1BdueK-0007TP-00; Fri, 25 Jun 2004 13:38:04 -0400 Received: from mail pickup service by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC; Fri, 25 Jun 2004 13:37:25 -0400 Received: from cox.com ([10.62.198.41]) by hatl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 25 Jun 2004 11:15:09 -0400 Received: from ([132.151.6.71]) by post5.cox.com with SMTP id KP-GYX41.26387055; Fri, 25 Jun 2004 10:57:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdrOB-00060S-Al; Fri, 25 Jun 2004 10:09:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdrKB-0003If-Eu; Fri, 25 Jun 2004 10:05:03 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01213; Fri, 25 Jun 2004 10:05:01 -0400 (EDT) Message-Id: <200406251405.KAA01213@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 25 Jun 2004 10:05:01 -0400 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-esp: ESP<15>=RBL:<0> RDNS:<0> SHA:<0> UHA:<0> SLS:<0> BAYES:<15> SPF:<0> X-OriginalArrivalTime: 25 Jun 2004 15:15:10.0609 (UTC) FILETIME=[34EC0010:01C45AC7] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Cc: pim@ietf.org Subject: [pim] I-D ACTION:draft-ietf-pim-dm-new-v2-05.txt X-BeenThere: pim@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) Author(s) : A. Adams, et al. Filename : draft-ietf-pim-dm-new-v2-05.txt Pages : 55 Date : 2004-6-24 This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers with no group membership information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-dm-new-v2-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-dm-new-v2-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-dm-new-v2-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-25102546.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-dm-new-v2-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-dm-new-v2-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-25102546.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --NextPart-- From pim-bounces@ietf.org Fri Jun 25 16:33:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10680 for ; Fri, 25 Jun 2004 16:33:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdxDf-0000kv-Mz; Fri, 25 Jun 2004 16:22:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdx5n-0006DG-AV for pim@megatron.ietf.org; Fri, 25 Jun 2004 16:14:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07988 for ; Fri, 25 Jun 2004 16:14:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdx5l-0000cB-U8 for pim@ietf.org; Fri, 25 Jun 2004 16:14:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdx46-000042-00 for pim@ietf.org; Fri, 25 Jun 2004 16:12:51 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bdx2n-0007Qp-00; Fri, 25 Jun 2004 16:11:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bdx2l-0006X9-AZ; Fri, 25 Jun 2004 16:11:27 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1Bdwpv-0008Ox-Dr; Fri, 25 Jun 2004 15:58:11 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 25 Jun 2004 15:58:11 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Cc: Internet Architecture Board , pim, pim chair , RFC Editor , pim mailing list , chair Subject: [pim] Document Action: 'Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)' to Experimental RFC X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org The IESG has approved the following document: - 'Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) ' as an Experimental RFC This document is the product of the Protocol Independent Multicast Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers with no group membership information. Working Group Summary The WG has a consensus on this document. Protocol Quality The document has been reviewed for the IESG by Alex Zinin. RFC Editor Note: Section 7.3, 2nd paragraph, 1st sentence: OLD: To use IPSec, the administrator of a PIM network configures each PIM router with one or more Security Associations and associated Security Parameters Indices that are used by senders to sign PIM protocol ^^^^^ messages and are used by receivers to authenticate received PIM protocol messages. NEW: To use IPSec, the administrator of a PIM network configures each PIM router with one or more Security Associations and associated Security Parameters Indices that are used by senders to authenticate PIM protocol messages and are used by receivers to authenticate received PIM protocol messages. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Sun Jun 27 10:05:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19199 for ; Sun, 27 Jun 2004 10:05:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeaEv-0006Aw-8a; Sun, 27 Jun 2004 10:02:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeaBw-0003Xk-4V for pim@megatron.ietf.org; Sun, 27 Jun 2004 09:59:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18748 for ; Sun, 27 Jun 2004 09:59:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeaBv-0005uJ-Bv for pim@ietf.org; Sun, 27 Jun 2004 09:59:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeaB3-0005gf-00 for pim@ietf.org; Sun, 27 Jun 2004 09:58:37 -0400 Received: from spaceboyz.net ([217.160.179.236] ident=mail) by ietf-mx with esmtp (Exim 4.12) id 1BeaA3-0005SU-00 for pim@ietf.org; Sun, 27 Jun 2004 09:57:35 -0400 Received: from [2001:8d8:81:5c2::1] (helo=mercury.n2.diac24.net) by spaceboyz.net with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.32) id 1BeaA2-0007HD-CT for pim@ietf.org; Sun, 27 Jun 2004 15:57:34 +0200 Received: from eth0.pluto.n2.diac24.net ([3ffe:400:c00:2:2a0:24ff:fe72:7666] helo=diac24.net) by mercury.n2.diac24.net with esmtp (TLSv1:RC4-MD5:128) (Exim 4.22) id 1BeaAx-0003n5-OJ for pim@ietf.org; Sun, 27 Jun 2004 15:58:31 +0200 Message-ID: <40DED23C.7030703@diac24.net> Date: Sun, 27 Jun 2004 15:57:16 +0200 From: David Lamparter User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.6a) Gecko/20031030 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: pim@ietf.org References: <200406240029.i5O0TEKh083244@possum.icir.org> <32A496B0-C618-11D8-8D08-0003936A6062@procket.com> In-Reply-To: <32A496B0-C618-11D8-8D08-0003936A6062@procket.com> X-SA-Exim-Mail-From: lists@diac24.net Subject: Re: [pim] Unknown Pim Hello options Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Version: 3.1 (built Wed Sep 24 18:01:27 CEST 2003) X-SA-Exim-Scanned: Yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Content-Transfer-Encoding: 7bit 1 euro-cent... The "right thing to do" would be to have ignoring unknown Hello Options be a MUST and require logging of this (once per neighbor and GenID). Things will end up with a bulkload of compatibility configuration options on more advanced PIM routers otherwise, which, in turn, SHOULD of course log what they do on noticing some neighbors don't support extension abc. Specifications for extensions on their side should state what to do on receiving Hellos not indicating support for the specified extension. (for example, bidir should state "if a hello without Bidir-Capable option is received, bidir has to be disabled on the interface..."; other extensions [popcount, nnhop, ...] may add rules for interaction with unsupporting routers) There really is no "hello-ack", but there are the other router's hellos with some options present and some options not present. David P.S.: in case it got lost in my bad english, I meant to say "change the draft, make ignore a MUST" John Zwiebel wrote: > > On Jun 23, 2004, at 5:29 PM, Pavlin Radoslavov wrote: > >> Indeed, the spec doesn't say explicitly that the routers still >> should be neighbors, so I'd be interested to know if other people >> have different interpretations. >> > > Yes, still become neighbors, but let's say that one of > the routers on the LAN does not support bi-dir (as > an example) then none of the routers on the LAN should > do bi-dir. > > There is no 'hello-ack' so its possible to have > asymmetrical neighborliness ;-) A prescription for > disaster. > _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Tue Jun 29 14:08:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05749 for ; Tue, 29 Jun 2004 14:08:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfMus-0007t8-FH; Tue, 29 Jun 2004 14:01:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfMrC-0007NN-Im for pim@megatron.ietf.org; Tue, 29 Jun 2004 13:57:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05000 for ; Tue, 29 Jun 2004 13:57:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfMrB-0001qZ-JA for pim@ietf.org; Tue, 29 Jun 2004 13:57:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfMqC-0001TV-00 for pim@ietf.org; Tue, 29 Jun 2004 13:56:20 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BfMp5-0000oc-00 for pim@ietf.org; Tue, 29 Jun 2004 13:55:11 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 29 Jun 2004 10:54:23 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5THsD4N016009 for ; Tue, 29 Jun 2004 10:54:13 -0700 (PDT) Received: from irp-view6.cisco.com (irp-view6.cisco.com [171.70.65.143]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AUT72253; Tue, 29 Jun 2004 10:53:02 -0700 (PDT) Date: Tue, 29 Jun 2004 10:54:11 -0700 (PDT) From: Mike McBride To: pim@ietf.org Subject: [pim] PIM WG Agenda for IETF 60 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Please let us know if there are other drafts we need to discuss. Status: draft-ietf-pim-sm-v2-new-09.txt Isidor draft-ietf-pim-bidir-06.txt Isidor draft-ietf-pim-dm-new-v2-04.txt Mike draft-ietf-pim-mib-v2-02.txt Bharat draft-ietf-pim-sm-bsr-04.txt Alex draft-ietf-pim-anycast-rp-01.txt Dino New: draft-farinacci-pim-pop-count-00 Dino draft-wijnands-pim-proxy-00 Ice Thanks, Tom & Mike _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim