From mailman-admin@ietf.org Sun Feb 1 09:09:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12508 for ; Sun, 1 Feb 2004 09:09:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnIHj-0001Me-Um for pim-archive@lists.ietf.org; Sun, 01 Feb 2004 09:09:15 -0500 Date: Sun, 01 Feb 2004 09:09:15 -0500 Message-ID: <20040201140915.1364.89534.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-admin@ietf.org Mon Feb 2 12:38:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23960 for ; Mon, 2 Feb 2004 12:38:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ani1K-00039H-6A; Mon, 02 Feb 2004 12:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alkk1-0000AF-2y for pim@optimus.ietf.org; Wed, 28 Jan 2004 03:08:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18584 for ; Wed, 28 Jan 2004 03:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alkjx-0004YO-00 for pim@ietf.org; Wed, 28 Jan 2004 03:08:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alkii-0004Ol-00 for pim@ietf.org; Wed, 28 Jan 2004 03:06:45 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1Alkhe-0004E3-00 for pim@ietf.org; Wed, 28 Jan 2004 03:05:38 -0500 Received: (qmail 3367 invoked from network); 28 Jan 2004 08:05:09 -0000 Received: from c-24-19-2-172.client.comcast.net (HELO ?192.168.0.107?) (ben@24.19.2.172) by layer8.net with SMTP; 28 Jan 2004 08:05:09 -0000 In-Reply-To: <20040128075405.27D1A8AE91@xprdmailfe2.nwk.excite.com> References: <20040128075405.27D1A8AE91@xprdmailfe2.nwk.excite.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: jzwiebel@procket.com, pim@ietf.org From: Benjamin Black Subject: Re: [pim] I Date: Wed, 28 Jan 2004 00:05:10 -0800 To: aruts@excite.com X-Mailer: Apple Mail (2.612) 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,HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit certainly, but not quite the point. a single PIM message can be larger than 2^16 bytes, which won't fit in a single IP datagram. assuming you were communicating across a link that had an MTU of 2^16, such a PIM message would _still_ be too large to fit in a single IP datagram. in this case the PIM message would be fragmented across multiple IP datagrams which would not themselves be fragmented. here's a picture: [ really big PIM message that is like 200,000 bytes ] [ 65535 byte IP packet ] <-- PIM message above won't fit here ben On Jan 27, 2004, at 11:54 PM, "" wrote: > > Hi, > > IP actually does reassembly before it gives it to PIM and > PIM receives the complete packet intact.I have seen it work! > > So, I don`t understand the need for a fragmentation flag! > > Thanks, > Arut > > > > > --- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote: > From: Benjamin Black [mailto: ben@layer8.net] > To: jzwiebel@procket.com > Cc: aruts@excite.com, pim@ietf.org > Date: Tue, 27 Jan 2004 19:54:05 -0800 > Subject: Re: [pim] PIM BSM fragmentation > > put a slightly different way:

PIM can generate a message larger > than the maximum size for a single IP
packet, so it must be able > to reassemble things when a single PIM
message is fragmented over > multiple IP packets.


ben

On Jan 27, 2004, at 5:25 > PM, John Zwiebel wrote:

>
> On Jan 27, 2004, at 5:16 PM, "" > wrote:
>
>>
>> I would like to know why > fragmentation support (read fragmentation
>> tag) is required at > PIM level when IP is already doing it.
>>
>
> Because if IP > does it, it may not include all the source for a given
> group > within the same
> packet.
>
>
> > _______________________________________________
> pim mailing > list
> pim@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pim
>
>

> > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > > _______________________________________________ > 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 exim@www1.ietf.org Mon Feb 2 12:49:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25742 for ; Mon, 2 Feb 2004 12:49:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniCB-0004b0-5j for pim-archive@odin.ietf.org; Mon, 02 Feb 2004 12:49:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12HnFDp017666 for pim-archive@odin.ietf.org; Mon, 2 Feb 2004 12:49:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniCA-0004ar-Tn for pim-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 12:49:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25619 for ; Mon, 2 Feb 2004 12:49:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniC9-0007LQ-00 for pim-web-archive@ietf.org; Mon, 02 Feb 2004 12:49:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ani81-0006Kh-00 for pim-web-archive@ietf.org; Mon, 02 Feb 2004 12:45:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ani1h-0004kK-00 for pim-web-archive@ietf.org; Mon, 02 Feb 2004 12:38:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ani1K-00039H-6A; Mon, 02 Feb 2004 12:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alkk1-0000AF-2y for pim@optimus.ietf.org; Wed, 28 Jan 2004 03:08:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18584 for ; Wed, 28 Jan 2004 03:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alkjx-0004YO-00 for pim@ietf.org; Wed, 28 Jan 2004 03:08:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alkii-0004Ol-00 for pim@ietf.org; Wed, 28 Jan 2004 03:06:45 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1Alkhe-0004E3-00 for pim@ietf.org; Wed, 28 Jan 2004 03:05:38 -0500 Received: (qmail 3367 invoked from network); 28 Jan 2004 08:05:09 -0000 Received: from c-24-19-2-172.client.comcast.net (HELO ?192.168.0.107?) (ben@24.19.2.172) by layer8.net with SMTP; 28 Jan 2004 08:05:09 -0000 In-Reply-To: <20040128075405.27D1A8AE91@xprdmailfe2.nwk.excite.com> References: <20040128075405.27D1A8AE91@xprdmailfe2.nwk.excite.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: jzwiebel@procket.com, pim@ietf.org From: Benjamin Black Subject: Re: [pim] I Date: Wed, 28 Jan 2004 00:05:10 -0800 To: aruts@excite.com X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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,HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit certainly, but not quite the point. a single PIM message can be larger than 2^16 bytes, which won't fit in a single IP datagram. assuming you were communicating across a link that had an MTU of 2^16, such a PIM message would _still_ be too large to fit in a single IP datagram. in this case the PIM message would be fragmented across multiple IP datagrams which would not themselves be fragmented. here's a picture: [ really big PIM message that is like 200,000 bytes ] [ 65535 byte IP packet ] <-- PIM message above won't fit here ben On Jan 27, 2004, at 11:54 PM, "" wrote: > > Hi, > > IP actually does reassembly before it gives it to PIM and > PIM receives the complete packet intact.I have seen it work! > > So, I don`t understand the need for a fragmentation flag! > > Thanks, > Arut > > > > > --- On Tue 01/27, Benjamin Black < ben@layer8.net > wrote: > From: Benjamin Black [mailto: ben@layer8.net] > To: jzwiebel@procket.com > Cc: aruts@excite.com, pim@ietf.org > Date: Tue, 27 Jan 2004 19:54:05 -0800 > Subject: Re: [pim] PIM BSM fragmentation > > put a slightly different way:

PIM can generate a message larger > than the maximum size for a single IP
packet, so it must be able > to reassemble things when a single PIM
message is fragmented over > multiple IP packets.


ben

On Jan 27, 2004, at 5:25 > PM, John Zwiebel wrote:

>
> On Jan 27, 2004, at 5:16 PM, "" > wrote:
>
>>
>> I would like to know why > fragmentation support (read fragmentation
>> tag) is required at > PIM level when IP is already doing it.
>>
>
> Because if IP > does it, it may not include all the source for a given
> group > within the same
> packet.
>
>
> > _______________________________________________
> pim mailing > list
> pim@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pim
>
>

> > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > > _______________________________________________ > 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-admin@ietf.org Mon Feb 2 13:26:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23959 for ; Mon, 2 Feb 2004 12:38:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ani1J-000397-5b; Mon, 02 Feb 2004 12:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlgoG-000205-Lp for pim@optimus.ietf.org; Tue, 27 Jan 2004 22:56:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14555 for ; Tue, 27 Jan 2004 22:56:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlgoD-0002DV-00 for pim@ietf.org; Tue, 27 Jan 2004 22:56:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlgnM-0002Ar-00 for pim@ietf.org; Tue, 27 Jan 2004 22:55:17 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1Algmz-00027w-00 for pim@ietf.org; Tue, 27 Jan 2004 22:54:53 -0500 Received: (qmail 419 invoked from network); 28 Jan 2004 03:54:19 -0000 Received: from c-24-19-2-172.client.comcast.net (HELO ?192.168.0.107?) (ben@24.19.2.172) by layer8.net with SMTP; 28 Jan 2004 03:54:19 -0000 In-Reply-To: References: <20040128011643.F240B8AEAF@xprdmailfe2.nwk.excite.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9E2891A4-5145-11D8-85AD-000A95DA7468@layer8.net> Content-Transfer-Encoding: 7bit Cc: aruts@excite.com, pim@ietf.org From: Benjamin Black Subject: Re: [pim] PIM BSM fragmentation Date: Tue, 27 Jan 2004 19:54:05 -0800 To: John Zwiebel X-Mailer: Apple Mail (2.612) 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit put a slightly different way: PIM can generate a message larger than the maximum size for a single IP packet, so it must be able to reassemble things when a single PIM message is fragmented over multiple IP packets. ben On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote: > > On Jan 27, 2004, at 5:16 PM, "" wrote: > >> >> I would like to know why fragmentation support (read fragmentation >> tag) is required at PIM level when IP is already doing it. >> > > Because if IP does it, it may not include all the source for a given > group within the same > packet. > > > _______________________________________________ > 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 exim@www1.ietf.org Mon Feb 2 13:36:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25741 for ; Mon, 2 Feb 2004 12:49:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniCB-0004bM-NM for pim-archive@odin.ietf.org; Mon, 02 Feb 2004 12:49:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12HnF2R017682 for pim-archive@odin.ietf.org; Mon, 2 Feb 2004 12:49:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniCB-0004b7-HX for pim-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 12:49:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25622 for ; Mon, 2 Feb 2004 12:49:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniC9-0007Lc-00 for pim-web-archive@ietf.org; Mon, 02 Feb 2004 12:49:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ani82-0006Ks-00 for pim-web-archive@ietf.org; Mon, 02 Feb 2004 12:45:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ani1h-0004kL-00 for pim-web-archive@ietf.org; Mon, 02 Feb 2004 12:38:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ani1J-000397-5b; Mon, 02 Feb 2004 12:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlgoG-000205-Lp for pim@optimus.ietf.org; Tue, 27 Jan 2004 22:56:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14555 for ; Tue, 27 Jan 2004 22:56:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlgoD-0002DV-00 for pim@ietf.org; Tue, 27 Jan 2004 22:56:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlgnM-0002Ar-00 for pim@ietf.org; Tue, 27 Jan 2004 22:55:17 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1Algmz-00027w-00 for pim@ietf.org; Tue, 27 Jan 2004 22:54:53 -0500 Received: (qmail 419 invoked from network); 28 Jan 2004 03:54:19 -0000 Received: from c-24-19-2-172.client.comcast.net (HELO ?192.168.0.107?) (ben@24.19.2.172) by layer8.net with SMTP; 28 Jan 2004 03:54:19 -0000 In-Reply-To: References: <20040128011643.F240B8AEAF@xprdmailfe2.nwk.excite.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9E2891A4-5145-11D8-85AD-000A95DA7468@layer8.net> Content-Transfer-Encoding: 7bit Cc: aruts@excite.com, pim@ietf.org From: Benjamin Black Subject: Re: [pim] PIM BSM fragmentation Date: Tue, 27 Jan 2004 19:54:05 -0800 To: John Zwiebel X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit put a slightly different way: PIM can generate a message larger than the maximum size for a single IP packet, so it must be able to reassemble things when a single PIM message is fragmented over multiple IP packets. ben On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote: > > On Jan 27, 2004, at 5:16 PM, "" wrote: > >> >> I would like to know why fragmentation support (read fragmentation >> tag) is required at PIM level when IP is already doing it. >> > > Because if IP does it, it may not include all the source for a given > group within the same > packet. > > > _______________________________________________ > 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-admin@ietf.org Mon Feb 2 15:00:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05277 for ; Mon, 2 Feb 2004 15:00:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkEk-0000jH-UJ; Mon, 02 Feb 2004 15:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkEV-0000iE-Vf for pim@optimus.ietf.org; Mon, 02 Feb 2004 14:59:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05219 for ; Mon, 2 Feb 2004 14:59:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnkET-0002qO-00 for pim@ietf.org; Mon, 02 Feb 2004 14:59:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnkDU-0002l7-00 for pim@ietf.org; Mon, 02 Feb 2004 14:58:45 -0500 Received: from smtp1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 1AnkCW-0002br-00 for pim@ietf.org; Mon, 02 Feb 2004 14:57:44 -0500 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 i12M67pL027120; Mon, 2 Feb 2004 14:06:08 -0800 (PST) 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 i12Jv4YB011979; Mon, 2 Feb 2004 11:57:04 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i12Jv43R012229; Mon, 2 Feb 2004 11:57:04 -0800 Date: Mon, 2 Feb 2004 11:57:04 -0800 Message-Id: <200402021957.i12Jv43R012229@dino-pc.procket.com> From: Dino Farinacci To: ben@layer8.net CC: jzwiebel@procket.com, aruts@excite.com, pim@ietf.org In-reply-to: <9E2891A4-5145-11D8-85AD-000A95DA7468@layer8.net> (message from Benjamin Black on Tue, 27 Jan 2004 19:54:05 -0800) Subject: Re: [pim] PIM BSM fragmentation References: <20040128011643.F240B8AEAF@xprdmailfe2.nwk.excite.com> <9E2891A4-5145-11D8-85AD-000A95DA7468@layer8.net> 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , >> PIM can generate a message larger than the maximum size for a single IP >> packet, so it must be able to reassemble things when a single PIM >> message is fragmented over multiple IP packets. No, PIM cannot. And a PIM implementation should not or else IP will either 1) drop the packet or 2) erroneously truncate the packet. Since PIM has no explicit capability in general to fragment packets and it is an IP client protocol, it follows the maximum packet size oft IP which is 0xffff. Dino _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Mon Feb 2 15:02:15 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05337 for ; Mon, 2 Feb 2004 15:02:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkGS-0003LT-JL for pim-archive@odin.ietf.org; Mon, 02 Feb 2004 15:01:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12K1mVx012858 for pim-archive@odin.ietf.org; Mon, 2 Feb 2004 15:01:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkGS-0003LA-Dc for pim-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 15:01:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05325 for ; Mon, 2 Feb 2004 15:01:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnkGP-00030R-00 for pim-web-archive@ietf.org; Mon, 02 Feb 2004 15:01:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnkFU-0002wD-00 for pim-web-archive@ietf.org; Mon, 02 Feb 2004 15:00:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnkEy-0002rl-00 for pim-web-archive@ietf.org; Mon, 02 Feb 2004 15:00:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkEk-0000jH-UJ; Mon, 02 Feb 2004 15:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkEV-0000iE-Vf for pim@optimus.ietf.org; Mon, 02 Feb 2004 14:59:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05219 for ; Mon, 2 Feb 2004 14:59:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnkET-0002qO-00 for pim@ietf.org; Mon, 02 Feb 2004 14:59:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnkDU-0002l7-00 for pim@ietf.org; Mon, 02 Feb 2004 14:58:45 -0500 Received: from smtp1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 1AnkCW-0002br-00 for pim@ietf.org; Mon, 02 Feb 2004 14:57:44 -0500 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 i12M67pL027120; Mon, 2 Feb 2004 14:06:08 -0800 (PST) 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 i12Jv4YB011979; Mon, 2 Feb 2004 11:57:04 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i12Jv43R012229; Mon, 2 Feb 2004 11:57:04 -0800 Date: Mon, 2 Feb 2004 11:57:04 -0800 Message-Id: <200402021957.i12Jv43R012229@dino-pc.procket.com> From: Dino Farinacci To: ben@layer8.net CC: jzwiebel@procket.com, aruts@excite.com, pim@ietf.org In-reply-to: <9E2891A4-5145-11D8-85AD-000A95DA7468@layer8.net> (message from Benjamin Black on Tue, 27 Jan 2004 19:54:05 -0800) Subject: Re: [pim] PIM BSM fragmentation References: <20040128011643.F240B8AEAF@xprdmailfe2.nwk.excite.com> <9E2891A4-5145-11D8-85AD-000A95DA7468@layer8.net> Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 >> PIM can generate a message larger than the maximum size for a single IP >> packet, so it must be able to reassemble things when a single PIM >> message is fragmented over multiple IP packets. No, PIM cannot. And a PIM implementation should not or else IP will either 1) drop the packet or 2) erroneously truncate the packet. Since PIM has no explicit capability in general to fragment packets and it is an IP client protocol, it follows the maximum packet size oft IP which is 0xffff. Dino _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Tue Feb 3 18:17:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12512 for ; Tue, 3 Feb 2004 18:17:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9mv-0007re-FT; Tue, 03 Feb 2004 18:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9ml-0007p6-3k for pim@optimus.ietf.org; Tue, 03 Feb 2004 18:16:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12380 for ; Tue, 3 Feb 2004 18:16:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9mi-0006I7-00 for pim@ietf.org; Tue, 03 Feb 2004 18:16:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao9lf-0006D1-00 for pim@ietf.org; Tue, 03 Feb 2004 18:15:43 -0500 Received: from catarina.usc.edu ([204.57.0.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9kw-00063C-00 for pim@ietf.org; Tue, 03 Feb 2004 18:14:58 -0500 Received: from colo-dns-ext1.juniper.net (colo-dns-ext1.juniper.net [207.17.137.57]) by catarina.usc.edu (8.12.9/8.12.9) with ESMTP id i13NES7J083287 for ; Tue, 3 Feb 2004 15:14:28 -0800 (PST) (envelope-from pusateri@juniper.net) 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 i13NENl52992 for ; Tue, 3 Feb 2004 15:14:23 -0800 (PST) (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 i13NEIh96882 for ; Tue, 3 Feb 2004 15:14:18 -0800 (PST) (envelope-from pusateri@juniper.net) Message-Id: <200402032314.i13NEIh96882@merlot.juniper.net> To: pim@catarina.usc.edu MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <40213.1075850058.1@juniper.net> Date: Tue, 03 Feb 2004 15:14:18 -0800 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 Subject: [pim] No Seoul PIM meeting scheduled Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Currently, we have not requested a slot for a PIM WG meeting in Seoul. Neither Liming nor myself will be attending. If you have agenda items that you would like to discuss, Alex or Bill has agreed to chair the meeting if we feel there is a need to get together face to face. A current status update is: 1. Isidor and the PIM authors have been working hard on addressing Pavlin's concerns during the last call and are about ready to release a new version of the sparse mode spec. 2. As soon as the Sparse mode spec passes WG last call, we'll do a last call on the BiDir spec. 3. The dense mode spec was submitted to the IESG as an Experimental RFC and feedback is provided below. There are some formatting nits and some concern about the security section. https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1161&filename=draft-ietf-pim-dm-new-v2 4. Liming and I are working on updating the charter milestone dates so the working group doesn't get shut down (sorry...) Thanks, Tom _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Tue Feb 3 18:19:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12690 for ; Tue, 3 Feb 2004 18:19:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9od-0008KE-Hb for pim-archive@odin.ietf.org; Tue, 03 Feb 2004 18:18:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13NIlr5032001 for pim-archive@odin.ietf.org; Tue, 3 Feb 2004 18:18:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9od-0008Jt-9y for pim-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 18:18:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12617 for ; Tue, 3 Feb 2004 18:18:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9oa-0006VH-00 for pim-web-archive@ietf.org; Tue, 03 Feb 2004 18:18:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao9ne-0006Ou-00 for pim-web-archive@ietf.org; Tue, 03 Feb 2004 18:17:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9n7-0006J8-00 for pim-web-archive@ietf.org; Tue, 03 Feb 2004 18:17:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9mv-0007re-FT; Tue, 03 Feb 2004 18:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9ml-0007p6-3k for pim@optimus.ietf.org; Tue, 03 Feb 2004 18:16:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12380 for ; Tue, 3 Feb 2004 18:16:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9mi-0006I7-00 for pim@ietf.org; Tue, 03 Feb 2004 18:16:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao9lf-0006D1-00 for pim@ietf.org; Tue, 03 Feb 2004 18:15:43 -0500 Received: from catarina.usc.edu ([204.57.0.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9kw-00063C-00 for pim@ietf.org; Tue, 03 Feb 2004 18:14:58 -0500 Received: from colo-dns-ext1.juniper.net (colo-dns-ext1.juniper.net [207.17.137.57]) by catarina.usc.edu (8.12.9/8.12.9) with ESMTP id i13NES7J083287 for ; Tue, 3 Feb 2004 15:14:28 -0800 (PST) (envelope-from pusateri@juniper.net) 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 i13NENl52992 for ; Tue, 3 Feb 2004 15:14:23 -0800 (PST) (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 i13NEIh96882 for ; Tue, 3 Feb 2004 15:14:18 -0800 (PST) (envelope-from pusateri@juniper.net) Message-Id: <200402032314.i13NEIh96882@merlot.juniper.net> To: pim@catarina.usc.edu MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <40213.1075850058.1@juniper.net> Date: Tue, 03 Feb 2004 15:14:18 -0800 From: Tom Pusateri Subject: [pim] No Seoul PIM meeting scheduled Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 Currently, we have not requested a slot for a PIM WG meeting in Seoul. Neither Liming nor myself will be attending. If you have agenda items that you would like to discuss, Alex or Bill has agreed to chair the meeting if we feel there is a need to get together face to face. A current status update is: 1. Isidor and the PIM authors have been working hard on addressing Pavlin's concerns during the last call and are about ready to release a new version of the sparse mode spec. 2. As soon as the Sparse mode spec passes WG last call, we'll do a last call on the BiDir spec. 3. The dense mode spec was submitted to the IESG as an Experimental RFC and feedback is provided below. There are some formatting nits and some concern about the security section. https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1161&filename=draft-ietf-pim-dm-new-v2 4. Liming and I are working on updating the charter milestone dates so the working group doesn't get shut down (sorry...) Thanks, Tom _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Tue Feb 3 18:33:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13013 for ; Tue, 3 Feb 2004 18:33:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoA2P-0001bj-79; Tue, 03 Feb 2004 18:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoA29-0001bM-Ee for pim@optimus.ietf.org; Tue, 03 Feb 2004 18:32:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13010 for ; Tue, 3 Feb 2004 18:32:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoA26-0007iC-00 for pim@ietf.org; Tue, 03 Feb 2004 18:32:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoA1E-0007dM-00 for pim@ietf.org; Tue, 03 Feb 2004 18:31:48 -0500 Received: from catarina.usc.edu ([204.57.0.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoA0f-0007Wg-00 for pim@ietf.org; Tue, 03 Feb 2004 18:31:13 -0500 Received: from possum.icir.org (possum.icir.org [192.150.187.67]) by catarina.usc.edu (8.12.9/8.12.9) with ESMTP id i13NUh7J083357 for ; Tue, 3 Feb 2004 15:30:43 -0800 (PST) (envelope-from pavlin@icir.org) Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i13NUh8N059542; Tue, 3 Feb 2004 15:30:43 -0800 (PST) (envelope-from pavlin@possum.icir.org) Message-Id: <200402032330.i13NUh8N059542@possum.icir.org> To: Tom Pusateri cc: pim@catarina.usc.edu Subject: Re: [pim] No Seoul PIM meeting scheduled In-Reply-To: Message from Tom Pusateri of "Tue, 03 Feb 2004 15:14:18 PST." <200402032314.i13NEIh96882@merlot.juniper.net> Date: Tue, 03 Feb 2004 15:30:43 -0800 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , > Currently, we have not requested a slot for a PIM WG meeting in Seoul. > Neither Liming nor myself will be attending. If you have agenda items > that you would like to discuss, Alex or Bill has agreed to chair > the meeting if we feel there is a need to get together face to face. > > A current status update is: > > 1. Isidor and the PIM authors have been working hard on addressing > Pavlin's concerns during the last call and are about ready to > release a new version of the sparse mode spec. While on the subject. I believe that James Lingard's recent email to the mailing list "Error in PIM-SM forwarding rules" from January 23, 2004 has a valid point (unless I am missing something). Could the new draft address that issue as well (or could someone send a rebuttal why this is not really an issue). Thanks, Pavlin _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Tue Feb 3 18:35:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13056 for ; Tue, 3 Feb 2004 18:35:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoA44-0001i0-DB for pim-archive@odin.ietf.org; Tue, 03 Feb 2004 18:34:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13NYi5q006567 for pim-archive@odin.ietf.org; Tue, 3 Feb 2004 18:34:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoA44-0001hq-8i for pim-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 18:34:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13047 for ; Tue, 3 Feb 2004 18:34:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoA41-00006H-00 for pim-web-archive@ietf.org; Tue, 03 Feb 2004 18:34:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoA38-00000x-00 for pim-web-archive@ietf.org; Tue, 03 Feb 2004 18:33:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoA2T-0007jn-00 for pim-web-archive@ietf.org; Tue, 03 Feb 2004 18:33:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoA2P-0001bj-79; Tue, 03 Feb 2004 18:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoA29-0001bM-Ee for pim@optimus.ietf.org; Tue, 03 Feb 2004 18:32:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13010 for ; Tue, 3 Feb 2004 18:32:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoA26-0007iC-00 for pim@ietf.org; Tue, 03 Feb 2004 18:32:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoA1E-0007dM-00 for pim@ietf.org; Tue, 03 Feb 2004 18:31:48 -0500 Received: from catarina.usc.edu ([204.57.0.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoA0f-0007Wg-00 for pim@ietf.org; Tue, 03 Feb 2004 18:31:13 -0500 Received: from possum.icir.org (possum.icir.org [192.150.187.67]) by catarina.usc.edu (8.12.9/8.12.9) with ESMTP id i13NUh7J083357 for ; Tue, 3 Feb 2004 15:30:43 -0800 (PST) (envelope-from pavlin@icir.org) Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i13NUh8N059542; Tue, 3 Feb 2004 15:30:43 -0800 (PST) (envelope-from pavlin@possum.icir.org) Message-Id: <200402032330.i13NUh8N059542@possum.icir.org> To: Tom Pusateri cc: pim@catarina.usc.edu Subject: Re: [pim] No Seoul PIM meeting scheduled In-Reply-To: Message from Tom Pusateri of "Tue, 03 Feb 2004 15:14:18 PST." <200402032314.i13NEIh96882@merlot.juniper.net> Date: Tue, 03 Feb 2004 15:30:43 -0800 From: Pavlin Radoslavov Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 > Currently, we have not requested a slot for a PIM WG meeting in Seoul. > Neither Liming nor myself will be attending. If you have agenda items > that you would like to discuss, Alex or Bill has agreed to chair > the meeting if we feel there is a need to get together face to face. > > A current status update is: > > 1. Isidor and the PIM authors have been working hard on addressing > Pavlin's concerns during the last call and are about ready to > release a new version of the sparse mode spec. While on the subject. I believe that James Lingard's recent email to the mailing list "Error in PIM-SM forwarding rules" from January 23, 2004 has a valid point (unless I am missing something). Could the new draft address that issue as well (or could someone send a rebuttal why this is not really an issue). Thanks, Pavlin _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Wed Feb 4 11:32:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13440 for ; Wed, 4 Feb 2004 11:32:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPva-00084w-O9; Wed, 04 Feb 2004 11:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPuz-0007tL-RV for pim@optimus.ietf.org; Wed, 04 Feb 2004 11:30:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13242 for ; Wed, 4 Feb 2004 11:30:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPuy-0006yi-00 for pim@ietf.org; Wed, 04 Feb 2004 11:30:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPu0-0006pz-00 for pim@ietf.org; Wed, 04 Feb 2004 11:29:25 -0500 Received: from smtp.dataconnection.com ([192.91.191.4] helo=coltrane.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 1AoPtB-0006cn-00 for pim@ietf.org; Wed, 04 Feb 2004 11:28:33 -0500 Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2656.59) id <1JJBGWNC>; Wed, 4 Feb 2004 16:27:49 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803580F10@baker.datcon.co.uk> From: James Lingard To: "'pim@ietf.org'" Date: Wed, 4 Feb 2004 16:27:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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 Subject: [pim] Minor errors and typos in draft-ietf-pim-sm-v2-new-08.txt Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Hi, I have several comments on the current PIM-SM draft (draft-ietf-pim-sm-v2-new-08.txt), which I've listed below. Most of these are very minor errors or typos. I apologise for my lateness in sending these comments, but I have only fairly recently begun looking at PIM in detail. Hopefully, as they are mostly very minor, there will still be time to make the necessary changes before the next revision of the draft. Please feel free to ask me for clarification if anything is unclear. Thanks, James. ========================================================================== Note: all page numbers refer to the "plain text" version of the draft. ========================================================================== * Throughout. Inconsistent use of AND, OR vs. &&, || in pseudo-code. ========================================================================== * Section 4.1.4. At a DR, a router also needs to store the Register state-machine state and the Register-Stop timer per (S,G). ========================================================================== * Section 4.1.6 (page 21). >> The inherited_olist(S,G,rpt) is [...] a strict subset of >> immediate_olist(*,G). It might not be a strict subset if joins(*,*,RP(G)) is not NULL. ========================================================================== * Section 4.1.6 (page 24). >> return NBR( RPF_interface(S), MRIB.next_hop( S ) ) ) ^ Typo: unmatched close-bracket. ========================================================================== * Section 4.2 (page 26). >> On receipt of data from S to G on interface iif: >> >> if( DirectlyConnected(S) == TRUE ) { I believe it would make more sense if this test were replaced with '(DirectlyConnected(S) == TRUE) AND (iif == RPF_interface(S))'. ========================================================================== * Section 4.4.1 (page 38). In the register state-machine, in the two transitions from the Join-Pending or Prune states to the NoInfo state, the action 'remove reg tunnel' should be removed as the register tunnel can only exist in the Join state. ========================================================================== * Section 4.4.1 (page 40, last paragraph). >> A Register-Stop(*,G) should be treated as a Register-Stop(S,G) for >> all existing (S,G) Register state machines. What is really meant is '[...] all (S,G) Register state machines that are not in NoInfo state.' We should avoid making the implementation-specific assumption that state-machines in NoInfo state 'don't exist'. ========================================================================== * Section 4.4.2 (page 41). >> if( outer.dst is not one of my addresses ) { >> drop the packet silently. >> # note that this should not happen if the lower layer is working >> } I suggest removing this clause. Should we not be able to assume that the lower layer _is_ working? ========================================================================== * Section 4.4.2 (page 41). >> decapsulate and pass the inner packet to the normal >> forwarding path for forwarding on the (*,G) tree. Does this phrase mean 'decapsulate and forward the inner packet to all interfaces in inherited_olist(S,G,rpt)'? If so, it should say this explicitly. If not, what does it mean? ========================================================================== * Section 4.5 (page 42). There are two references to the 'PIM Destination field' in a Join/Prune message, but there isn't a field of this name. I believe this should be replaced with 'Upstream Neighbor Address'. ========================================================================== * Sections 4.5.1, 4.5.2 and 4.5.3. In PP state, if the PP timer expires, the action must include cancelling the Expiry timer. In PP state, if the Expiry timer expires, the action must include cancelling the PP timer. ========================================================================== * Section 4.5.2 (page 48). >> Figure 3: Downstream per-interfacce (*,G) state-machine in tabular ^^^^^^^^^^ Typo: should be 'interface'. ========================================================================== * Section 4.5.4 (page 55). The difference between 'n/a', '-' and 'error' in the FSM table should be explained more clearly. ========================================================================== * Section 4.5.4. In P state, when the ET expires, delete the text that says 'ET and PPT are cancelled' (since neither can be running). In P' state, on reaching EOM, the action must not include cancelling the PPT (as it cannot be running). In PP' state, on reaching EOM, the action must include cancelling the ET and PPT. ========================================================================== * Section 4.5.6 (page 63). The description of the Not Joined state is missing the phrase 'and local membership information' (from the corresponding text in Section 4.5.7). ========================================================================== * Section 4.5.6 (page 66) and Section 4.5.7 (page 71). >> JoinDesired(*,G) becomes True >> The downstream state for (*,G) has changed so that at least >> one interface is in immediate_olist(*,G), making >> JoinDesired(*,G) become True. Not strictly correct. See the definition of JoinDesired(*,G) - it can be TRUE even if immediate_olist(*,G) is NULL. Same comment applies to "JoinDesired(*,G) becomes False" further down the page, and to the equivalent paragraphs in Section 4.5.7. ========================================================================== * Section 4.5.7 (page 68). >> If a (S,G) Assert occurs on the upstream interface, and this changes >> the this router's idea of the upstream neighbor, it should be [...] ^^^ Typo: delete superfluous "the". ========================================================================== * Section 4.5.8 (page 73). >> This section describes the rules for including an Prune(S,G,rpt) ^^ Typo: should be "a". ========================================================================== * Section 4.5.9 (page 74). >> RPTNotJoined(G) >> neither (*,G) nor (*,*,RP(G)) has not been joined. ^^^ Typo: delete superfluous "not". ========================================================================== * Section 4.5.9 (page 75). In the table describing transitions from the NotPruned(S,G,rpt) state, the actions taken when OT expires should not include "Cancel OT". ========================================================================== * Section 4.5.9 (page 75). In the table describing transitions from the NotPruned(S,G,rpt) state, the notation 'OT = min(OT, t_override)' is inconsistent with the notation for the same thing in Sections 4.5.5 - 4.5.7 (e.g. 'Decrease Join Timer to t_override'). Is there supposed to be a difference? ========================================================================== * Section 4.6.1 (page 81 and page 84). When in NoInfo state, there is an event 'Receive Preferred Assert with RPTbit clear and AssTrDes(S,G,I)'. But you can't have a 'Preferred Assert' in NoInfo state since there is no current Assert winner. I believe this should be 'Acceptable Assert'. ========================================================================== * Section 4.6.1. Should clarify in each case whether a received assert may be a (*,G) Assert or whether it must be an (S,G) Assert. ========================================================================== * Section 4.6.1 (page 84). >> Receive Preferred Assert with RPT bit clear AND >> AssertTrackingDesired(S,G,I)==TRUE >> [...] >> The received assert that has a better metric than our own [...] ^^^^ Typo: delete superfluous "that". ========================================================================== * Section 4.6.2 (page 88). >> [...] unless the (S,G) assert state machine for the relevant S and G >> is in the "NoInfo" state [...] What if there is no 'relevant S', i.e. if the Source-Address field is INADDR_ANY? ========================================================================== * Section 4.6.2 (page 90). In the definition of AssertTrackingDesired(*,G,I), 'CouldAssert(*,G)' should be 'CouldAssert(*,G,I)'. ========================================================================== * Section 4.6.3 (page 94). Should clarify the ordering to be used for IP addresses. ========================================================================== * Section 4.6.4 (page 96). For an AssertCancel(*,G), why should the source be set to RP(G) and not INADDR_ANY? ========================================================================== * Section 4.6.5 (page 97). >> AssertWinner(S,G,I) is the IP source address of the Assert(S,G) >> packet that won an Assert. Couldn't it actually be an Assert(*,G) packet that has won the (S,G) Assert? ========================================================================== * Section 4.7 (page 99). >> >From the point of view of PIM-SM, a PMBR has two tasks: ^ Typo: delete ">". ========================================================================== * Section 4.7.1 (page 100). >> were the DR for this source (see Section 4.4.1 with the following ^ Typo: missing close bracket. ========================================================================== * Section 4.7.2 (page 100). >> In the former case, the PMBR will need to issue send a Join(*,*,RP) ^^^^^ Typo: delete superfluous "issue". ========================================================================== * Section 4.7.2 (page 101). >> o If the PMBR has joined on the (*,*,RP) tree, then it should set >> DownstreamJPState(*,G,I) to TRUE on the discard interface for all ^^^^ Typo: should be "Join". ========================================================================== * Section 4.8.1 (page 104). >> However of the implementations we are are of, [...] ^^^ Typo: should be "aware". ========================================================================== * Section 4.10.5.1 (page 123). In the table of Join/Prune rules, the cell 'Join(S,G,rpt) x Prune(S,G)' should be '?' and the cell 'Prune(S,G,rpt) x Prune(S,G)' should be 'yes'. ========================================================================== * Section 4.10.5.2 (page 124). >> [...] may result in packets that are larger in the maximum IP [...] ^^ Typo: should be "than". --- James Lingard Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: James.Lingard@dataconnection.com Web: http://www.dataconnection.com/ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Wed Feb 4 11:34:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13529 for ; Wed, 4 Feb 2004 11:34:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPy8-0008LG-VG for pim-archive@odin.ietf.org; Wed, 04 Feb 2004 11:33:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14GXeRi032060 for pim-archive@odin.ietf.org; Wed, 4 Feb 2004 11:33:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPy8-0008L1-Nk for pim-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 11:33:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13516 for ; Wed, 4 Feb 2004 11:33:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPy7-0007Oh-00 for pim-web-archive@ietf.org; Wed, 04 Feb 2004 11:33:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPx8-0007Gu-00 for pim-web-archive@ietf.org; Wed, 04 Feb 2004 11:32:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoPwT-00079P-00 for pim-web-archive@ietf.org; Wed, 04 Feb 2004 11:31:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPva-00084w-O9; Wed, 04 Feb 2004 11:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPuz-0007tL-RV for pim@optimus.ietf.org; Wed, 04 Feb 2004 11:30:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13242 for ; Wed, 4 Feb 2004 11:30:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPuy-0006yi-00 for pim@ietf.org; Wed, 04 Feb 2004 11:30:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPu0-0006pz-00 for pim@ietf.org; Wed, 04 Feb 2004 11:29:25 -0500 Received: from smtp.dataconnection.com ([192.91.191.4] helo=coltrane.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 1AoPtB-0006cn-00 for pim@ietf.org; Wed, 04 Feb 2004 11:28:33 -0500 Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2656.59) id <1JJBGWNC>; Wed, 4 Feb 2004 16:27:49 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803580F10@baker.datcon.co.uk> From: James Lingard To: "'pim@ietf.org'" Date: Wed, 4 Feb 2004 16:27:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [pim] Minor errors and typos in draft-ietf-pim-sm-v2-new-08.txt Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 Hi, I have several comments on the current PIM-SM draft (draft-ietf-pim-sm-v2-new-08.txt), which I've listed below. Most of these are very minor errors or typos. I apologise for my lateness in sending these comments, but I have only fairly recently begun looking at PIM in detail. Hopefully, as they are mostly very minor, there will still be time to make the necessary changes before the next revision of the draft. Please feel free to ask me for clarification if anything is unclear. Thanks, James. ========================================================================== Note: all page numbers refer to the "plain text" version of the draft. ========================================================================== * Throughout. Inconsistent use of AND, OR vs. &&, || in pseudo-code. ========================================================================== * Section 4.1.4. At a DR, a router also needs to store the Register state-machine state and the Register-Stop timer per (S,G). ========================================================================== * Section 4.1.6 (page 21). >> The inherited_olist(S,G,rpt) is [...] a strict subset of >> immediate_olist(*,G). It might not be a strict subset if joins(*,*,RP(G)) is not NULL. ========================================================================== * Section 4.1.6 (page 24). >> return NBR( RPF_interface(S), MRIB.next_hop( S ) ) ) ^ Typo: unmatched close-bracket. ========================================================================== * Section 4.2 (page 26). >> On receipt of data from S to G on interface iif: >> >> if( DirectlyConnected(S) == TRUE ) { I believe it would make more sense if this test were replaced with '(DirectlyConnected(S) == TRUE) AND (iif == RPF_interface(S))'. ========================================================================== * Section 4.4.1 (page 38). In the register state-machine, in the two transitions from the Join-Pending or Prune states to the NoInfo state, the action 'remove reg tunnel' should be removed as the register tunnel can only exist in the Join state. ========================================================================== * Section 4.4.1 (page 40, last paragraph). >> A Register-Stop(*,G) should be treated as a Register-Stop(S,G) for >> all existing (S,G) Register state machines. What is really meant is '[...] all (S,G) Register state machines that are not in NoInfo state.' We should avoid making the implementation-specific assumption that state-machines in NoInfo state 'don't exist'. ========================================================================== * Section 4.4.2 (page 41). >> if( outer.dst is not one of my addresses ) { >> drop the packet silently. >> # note that this should not happen if the lower layer is working >> } I suggest removing this clause. Should we not be able to assume that the lower layer _is_ working? ========================================================================== * Section 4.4.2 (page 41). >> decapsulate and pass the inner packet to the normal >> forwarding path for forwarding on the (*,G) tree. Does this phrase mean 'decapsulate and forward the inner packet to all interfaces in inherited_olist(S,G,rpt)'? If so, it should say this explicitly. If not, what does it mean? ========================================================================== * Section 4.5 (page 42). There are two references to the 'PIM Destination field' in a Join/Prune message, but there isn't a field of this name. I believe this should be replaced with 'Upstream Neighbor Address'. ========================================================================== * Sections 4.5.1, 4.5.2 and 4.5.3. In PP state, if the PP timer expires, the action must include cancelling the Expiry timer. In PP state, if the Expiry timer expires, the action must include cancelling the PP timer. ========================================================================== * Section 4.5.2 (page 48). >> Figure 3: Downstream per-interfacce (*,G) state-machine in tabular ^^^^^^^^^^ Typo: should be 'interface'. ========================================================================== * Section 4.5.4 (page 55). The difference between 'n/a', '-' and 'error' in the FSM table should be explained more clearly. ========================================================================== * Section 4.5.4. In P state, when the ET expires, delete the text that says 'ET and PPT are cancelled' (since neither can be running). In P' state, on reaching EOM, the action must not include cancelling the PPT (as it cannot be running). In PP' state, on reaching EOM, the action must include cancelling the ET and PPT. ========================================================================== * Section 4.5.6 (page 63). The description of the Not Joined state is missing the phrase 'and local membership information' (from the corresponding text in Section 4.5.7). ========================================================================== * Section 4.5.6 (page 66) and Section 4.5.7 (page 71). >> JoinDesired(*,G) becomes True >> The downstream state for (*,G) has changed so that at least >> one interface is in immediate_olist(*,G), making >> JoinDesired(*,G) become True. Not strictly correct. See the definition of JoinDesired(*,G) - it can be TRUE even if immediate_olist(*,G) is NULL. Same comment applies to "JoinDesired(*,G) becomes False" further down the page, and to the equivalent paragraphs in Section 4.5.7. ========================================================================== * Section 4.5.7 (page 68). >> If a (S,G) Assert occurs on the upstream interface, and this changes >> the this router's idea of the upstream neighbor, it should be [...] ^^^ Typo: delete superfluous "the". ========================================================================== * Section 4.5.8 (page 73). >> This section describes the rules for including an Prune(S,G,rpt) ^^ Typo: should be "a". ========================================================================== * Section 4.5.9 (page 74). >> RPTNotJoined(G) >> neither (*,G) nor (*,*,RP(G)) has not been joined. ^^^ Typo: delete superfluous "not". ========================================================================== * Section 4.5.9 (page 75). In the table describing transitions from the NotPruned(S,G,rpt) state, the actions taken when OT expires should not include "Cancel OT". ========================================================================== * Section 4.5.9 (page 75). In the table describing transitions from the NotPruned(S,G,rpt) state, the notation 'OT = min(OT, t_override)' is inconsistent with the notation for the same thing in Sections 4.5.5 - 4.5.7 (e.g. 'Decrease Join Timer to t_override'). Is there supposed to be a difference? ========================================================================== * Section 4.6.1 (page 81 and page 84). When in NoInfo state, there is an event 'Receive Preferred Assert with RPTbit clear and AssTrDes(S,G,I)'. But you can't have a 'Preferred Assert' in NoInfo state since there is no current Assert winner. I believe this should be 'Acceptable Assert'. ========================================================================== * Section 4.6.1. Should clarify in each case whether a received assert may be a (*,G) Assert or whether it must be an (S,G) Assert. ========================================================================== * Section 4.6.1 (page 84). >> Receive Preferred Assert with RPT bit clear AND >> AssertTrackingDesired(S,G,I)==TRUE >> [...] >> The received assert that has a better metric than our own [...] ^^^^ Typo: delete superfluous "that". ========================================================================== * Section 4.6.2 (page 88). >> [...] unless the (S,G) assert state machine for the relevant S and G >> is in the "NoInfo" state [...] What if there is no 'relevant S', i.e. if the Source-Address field is INADDR_ANY? ========================================================================== * Section 4.6.2 (page 90). In the definition of AssertTrackingDesired(*,G,I), 'CouldAssert(*,G)' should be 'CouldAssert(*,G,I)'. ========================================================================== * Section 4.6.3 (page 94). Should clarify the ordering to be used for IP addresses. ========================================================================== * Section 4.6.4 (page 96). For an AssertCancel(*,G), why should the source be set to RP(G) and not INADDR_ANY? ========================================================================== * Section 4.6.5 (page 97). >> AssertWinner(S,G,I) is the IP source address of the Assert(S,G) >> packet that won an Assert. Couldn't it actually be an Assert(*,G) packet that has won the (S,G) Assert? ========================================================================== * Section 4.7 (page 99). >> >From the point of view of PIM-SM, a PMBR has two tasks: ^ Typo: delete ">". ========================================================================== * Section 4.7.1 (page 100). >> were the DR for this source (see Section 4.4.1 with the following ^ Typo: missing close bracket. ========================================================================== * Section 4.7.2 (page 100). >> In the former case, the PMBR will need to issue send a Join(*,*,RP) ^^^^^ Typo: delete superfluous "issue". ========================================================================== * Section 4.7.2 (page 101). >> o If the PMBR has joined on the (*,*,RP) tree, then it should set >> DownstreamJPState(*,G,I) to TRUE on the discard interface for all ^^^^ Typo: should be "Join". ========================================================================== * Section 4.8.1 (page 104). >> However of the implementations we are are of, [...] ^^^ Typo: should be "aware". ========================================================================== * Section 4.10.5.1 (page 123). In the table of Join/Prune rules, the cell 'Join(S,G,rpt) x Prune(S,G)' should be '?' and the cell 'Prune(S,G,rpt) x Prune(S,G)' should be 'yes'. ========================================================================== * Section 4.10.5.2 (page 124). >> [...] may result in packets that are larger in the maximum IP [...] ^^ Typo: should be "than". --- James Lingard Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: James.Lingard@dataconnection.com Web: http://www.dataconnection.com/ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Thu Feb 5 15:18:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03745 for ; Thu, 5 Feb 2004 15:18:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aopwm-0003fR-RG; Thu, 05 Feb 2004 15:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aopw4-0003VG-P9 for pim@optimus.ietf.org; Thu, 05 Feb 2004 15:17:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03578 for ; Thu, 5 Feb 2004 15:17:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aopw3-0001fn-00 for pim@ietf.org; Thu, 05 Feb 2004 15:17:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AopvA-0001aM-00 for pim@ietf.org; Thu, 05 Feb 2004 15:16:21 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AopuP-0001NL-00 for pim@ietf.org; Thu, 05 Feb 2004 15:15:33 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i15KF2K19582 for ; Thu, 5 Feb 2004 12:15:02 -0800 X-mProtect: <200402052015> Nokia Silicon Valley Messaging Protection Received: from dadhcp-172019074117.americas.nokia.com (172.19.74.117) by darkstar.iprg.nokia.com smtpdBWx2kt; Thu, 05 Feb 2004 12:15:00 PST From: Rahul Bahadur To: pim@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 05 Feb 2004 12:14:49 -0800 Message-Id: <1076012100.2306.16.camel@dadhcp-172019074117.americas.nokia.com> Mime-Version: 1.0 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 Subject: [pim] register messages vs. the SPT Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, I have a question about register-encapsulation vs. the SPT. Assume the following topology: source - DR - PIMrtr - RP -------- receiver(s)? The source is constantly sending traffic. Initially the DR has no state and sends a register packet to the RP that replies with a register-stop. The DR stops encapsulation starts the register-suppression timer. Now (for some reason) the SPT gets built, i.e., the DR receives an (S,G) join from PIMrtr. The DR starts forwarding data natively. When the register-suppression timer expires, should encapsulation re-start? Thanks, Rahul _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Thu Feb 5 15:20:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03900 for ; Thu, 5 Feb 2004 15:20:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aopyu-0004HH-FW for pim-archive@odin.ietf.org; Thu, 05 Feb 2004 15:20:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15KKBqm016423 for pim-archive@odin.ietf.org; Thu, 5 Feb 2004 15:20:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aopyr-0004Gc-Gx for pim-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 15:20:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03850 for ; Thu, 5 Feb 2004 15:20:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aopyq-0001vF-00 for pim-web-archive@ietf.org; Thu, 05 Feb 2004 15:20:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aopxu-0001q4-00 for pim-web-archive@ietf.org; Thu, 05 Feb 2004 15:19:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AopxE-0001lH-00 for pim-web-archive@ietf.org; Thu, 05 Feb 2004 15:18:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aopwm-0003fR-RG; Thu, 05 Feb 2004 15:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aopw4-0003VG-P9 for pim@optimus.ietf.org; Thu, 05 Feb 2004 15:17:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03578 for ; Thu, 5 Feb 2004 15:17:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aopw3-0001fn-00 for pim@ietf.org; Thu, 05 Feb 2004 15:17:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AopvA-0001aM-00 for pim@ietf.org; Thu, 05 Feb 2004 15:16:21 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AopuP-0001NL-00 for pim@ietf.org; Thu, 05 Feb 2004 15:15:33 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i15KF2K19582 for ; Thu, 5 Feb 2004 12:15:02 -0800 X-mProtect: <200402052015> Nokia Silicon Valley Messaging Protection Received: from dadhcp-172019074117.americas.nokia.com (172.19.74.117) by darkstar.iprg.nokia.com smtpdBWx2kt; Thu, 05 Feb 2004 12:15:00 PST From: Rahul Bahadur To: pim@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 05 Feb 2004 12:14:49 -0800 Message-Id: <1076012100.2306.16.camel@dadhcp-172019074117.americas.nokia.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [pim] register messages vs. the SPT Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit Hello, I have a question about register-encapsulation vs. the SPT. Assume the following topology: source - DR - PIMrtr - RP -------- receiver(s)? The source is constantly sending traffic. Initially the DR has no state and sends a register packet to the RP that replies with a register-stop. The DR stops encapsulation starts the register-suppression timer. Now (for some reason) the SPT gets built, i.e., the DR receives an (S,G) join from PIMrtr. The DR starts forwarding data natively. When the register-suppression timer expires, should encapsulation re-start? Thanks, Rahul _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Thu Feb 5 15:44:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05391 for ; Thu, 5 Feb 2004 15:44:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqLw-0006RF-0O; Thu, 05 Feb 2004 15:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqL8-0006PQ-1r for pim@optimus.ietf.org; Thu, 05 Feb 2004 15:43:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05102 for ; Thu, 5 Feb 2004 15:43:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoqL6-00043f-00 for pim@ietf.org; Thu, 05 Feb 2004 15:43:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoqK9-0003xy-00 for pim@ietf.org; Thu, 05 Feb 2004 15:42:09 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AoqJC-0003t4-00 for pim@ietf.org; Thu, 05 Feb 2004 15:41:10 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i15KfAAH024090 for ; Thu, 5 Feb 2004 13:41:10 -0700 (MST) Received: from il06exm10.corp.mot.com (il06exm10.corp.mot.com [10.0.111.10]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i15KePSC008375 for ; Thu, 5 Feb 2004 14:40:54 -0600 Received: by il06exm10 with Internet Mail Service (5.5.2657.2) id ; Thu, 5 Feb 2004 14:40:25 -0600 Message-ID: <370596D46C9BD711B61A00065BF3658803D0FDB8@il06exm12> From: Mathur Sonum-CSM109 To: "'Rahul Bahadur'" , pim@ietf.org Subject: RE: [pim] register messages vs. the SPT Date: Thu, 5 Feb 2004 14:40:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , No, after register-suppression timer expires, DR should send Null Register packet to the RP (it is to inform RP that Sender is till active and to refresh the (S,G) state on RP without sending data). Moreover, SPT should not have been built as there are no receivers so far (hope that's what you meant). Even if the receiver had joined, then also DR should just send Null Register packet to RP after the reg-suppression timer expires. In that case, (S,G) state on RP and PIMrtr would be constantly refreshed by data. -- Sonum -----Original Message----- From: pim-admin@ietf.org [mailto:pim-admin@ietf.org] On Behalf Of Rahul Bahadur Sent: Thursday, February 05, 2004 12:15 PM To: pim@ietf.org Subject: [pim] register messages vs. the SPT Hello, I have a question about register-encapsulation vs. the SPT. Assume the following topology: source - DR - PIMrtr - RP -------- receiver(s)? The source is constantly sending traffic. Initially the DR has no state and sends a register packet to the RP that replies with a register-stop. The DR stops encapsulation starts the register-suppression timer. Now (for some reason) the SPT gets built, i.e., the DR receives an (S,G) join from PIMrtr. The DR starts forwarding data natively. When the register-suppression timer expires, should encapsulation re-start? Thanks, Rahul _______________________________________________ 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 exim@www1.ietf.org Thu Feb 5 15:46:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05540 for ; Thu, 5 Feb 2004 15:46:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqO3-0006wR-35 for pim-archive@odin.ietf.org; Thu, 05 Feb 2004 15:46:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15KkB0L026677 for pim-archive@odin.ietf.org; Thu, 5 Feb 2004 15:46:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqO2-0006wC-Ur for pim-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 15:46:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05495 for ; Thu, 5 Feb 2004 15:46:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoqO1-0004Ly-00 for pim-web-archive@ietf.org; Thu, 05 Feb 2004 15:46:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoqN1-0004FB-00 for pim-web-archive@ietf.org; Thu, 05 Feb 2004 15:45:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoqM5-00049m-00 for pim-web-archive@ietf.org; Thu, 05 Feb 2004 15:44:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqLw-0006RF-0O; Thu, 05 Feb 2004 15:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqL8-0006PQ-1r for pim@optimus.ietf.org; Thu, 05 Feb 2004 15:43:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05102 for ; Thu, 5 Feb 2004 15:43:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoqL6-00043f-00 for pim@ietf.org; Thu, 05 Feb 2004 15:43:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoqK9-0003xy-00 for pim@ietf.org; Thu, 05 Feb 2004 15:42:09 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AoqJC-0003t4-00 for pim@ietf.org; Thu, 05 Feb 2004 15:41:10 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i15KfAAH024090 for ; Thu, 5 Feb 2004 13:41:10 -0700 (MST) Received: from il06exm10.corp.mot.com (il06exm10.corp.mot.com [10.0.111.10]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i15KePSC008375 for ; Thu, 5 Feb 2004 14:40:54 -0600 Received: by il06exm10 with Internet Mail Service (5.5.2657.2) id ; Thu, 5 Feb 2004 14:40:25 -0600 Message-ID: <370596D46C9BD711B61A00065BF3658803D0FDB8@il06exm12> From: Mathur Sonum-CSM109 To: "'Rahul Bahadur'" , pim@ietf.org Subject: RE: [pim] register messages vs. the SPT Date: Thu, 5 Feb 2004 14:40:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 No, after register-suppression timer expires, DR should send Null Register packet to the RP (it is to inform RP that Sender is till active and to refresh the (S,G) state on RP without sending data). Moreover, SPT should not have been built as there are no receivers so far (hope that's what you meant). Even if the receiver had joined, then also DR should just send Null Register packet to RP after the reg-suppression timer expires. In that case, (S,G) state on RP and PIMrtr would be constantly refreshed by data. -- Sonum -----Original Message----- From: pim-admin@ietf.org [mailto:pim-admin@ietf.org] On Behalf Of Rahul Bahadur Sent: Thursday, February 05, 2004 12:15 PM To: pim@ietf.org Subject: [pim] register messages vs. the SPT Hello, I have a question about register-encapsulation vs. the SPT. Assume the following topology: source - DR - PIMrtr - RP -------- receiver(s)? The source is constantly sending traffic. Initially the DR has no state and sends a register packet to the RP that replies with a register-stop. The DR stops encapsulation starts the register-suppression timer. Now (for some reason) the SPT gets built, i.e., the DR receives an (S,G) join from PIMrtr. The DR starts forwarding data natively. When the register-suppression timer expires, should encapsulation re-start? Thanks, Rahul _______________________________________________ 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-admin@ietf.org Thu Feb 5 16:41:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12481 for ; Thu, 5 Feb 2004 16:41:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorEB-00038m-Gg; Thu, 05 Feb 2004 16:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorDP-000366-PH for pim@optimus.ietf.org; Thu, 05 Feb 2004 16:39:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12351 for ; Thu, 5 Feb 2004 16:39:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AorDN-0005xA-00 for pim@ietf.org; Thu, 05 Feb 2004 16:39:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AorCX-0005vS-00 for pim@ietf.org; Thu, 05 Feb 2004 16:38:21 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AorCD-0005sd-00 for pim@ietf.org; Thu, 05 Feb 2004 16:38:02 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i15Laor01445; Thu, 5 Feb 2004 13:36:50 -0800 X-mProtect: <200402052136> Nokia Silicon Valley Messaging Protection Received: from dadhcp-172019074117.americas.nokia.com (172.19.74.117) by darkstar.iprg.nokia.com smtpdajRZh5; Thu, 05 Feb 2004 13:36:48 PST Subject: RE: [pim] register messages vs. the SPT From: Rahul Bahadur To: ext Mathur Sonum-CSM109 Cc: pim@ietf.org In-Reply-To: <370596D46C9BD711B61A00065BF3658803D0FDB8@il06exm12> References: <370596D46C9BD711B61A00065BF3658803D0FDB8@il06exm12> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 05 Feb 2004 13:36:38 -0800 Message-Id: <1076017008.2306.30.camel@dadhcp-172019074117.americas.nokia.com> Mime-Version: 1.0 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I apologize but I did not state two aspects clearly: 1) no, there are no active receivers initially, which is why the RP sends a register-stop. 2) after register-suppr. timer expires, a NULL-register would be sent. I believe I understand the behaviour properly now - even if the DR receives an SPT-join from PIMrtr while the register-suppr. timer is running (and is consequently forwarding data natively) it should still send a NULL register packet to the RP after the timer expires. Thanks again, Rahul On Thu, 2004-02-05 at 12:40, ext Mathur Sonum-CSM109 wrote: > > No, after register-suppression timer expires, DR should send Null Register packet to the RP (it is to inform RP that Sender is till active and to refresh the (S,G) state on RP without sending data). Moreover, SPT should not have been built as there are no receivers so far (hope that's what you meant). Even if the receiver had joined, then also DR should just send Null Register packet to RP after the reg-suppression timer expires. In that case, (S,G) state on RP and PIMrtr would be constantly refreshed by data. > > -- > Sonum > > -----Original Message----- > From: pim-admin@ietf.org [mailto:pim-admin@ietf.org] On Behalf Of Rahul Bahadur > Sent: Thursday, February 05, 2004 12:15 PM > To: pim@ietf.org > Subject: [pim] register messages vs. the SPT > > > > Hello, > > I have a question about register-encapsulation vs. the SPT. Assume the following topology: > > source - DR - PIMrtr - RP -------- receiver(s)? > > The source is constantly sending traffic. > > Initially the DR has no state and sends a register packet to the RP that replies with a register-stop. The DR stops encapsulation starts the > register-suppression timer. > > Now (for some reason) the SPT gets built, i.e., the DR receives an (S,G) join from PIMrtr. The DR starts forwarding data natively. > > When the register-suppression timer expires, should encapsulation re-start? > > Thanks, > Rahul > > > _______________________________________________ > 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 exim@www1.ietf.org Thu Feb 5 16:44:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12836 for ; Thu, 5 Feb 2004 16:44:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorIV-0003VT-Q6 for pim-archive@odin.ietf.org; Thu, 05 Feb 2004 16:44:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15LiVlq013474 for pim-archive@odin.ietf.org; Thu, 5 Feb 2004 16:44:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorIV-0003VF-Jx for pim-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 16:44:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12713 for ; Thu, 5 Feb 2004 16:44:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AorIT-0006d2-00 for pim-web-archive@ietf.org; Thu, 05 Feb 2004 16:44:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AorGB-0006DP-00 for pim-web-archive@ietf.org; Thu, 05 Feb 2004 16:42:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AorEs-00062k-00 for pim-web-archive@ietf.org; Thu, 05 Feb 2004 16:40:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorEB-00038m-Gg; Thu, 05 Feb 2004 16:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorDP-000366-PH for pim@optimus.ietf.org; Thu, 05 Feb 2004 16:39:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12351 for ; Thu, 5 Feb 2004 16:39:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AorDN-0005xA-00 for pim@ietf.org; Thu, 05 Feb 2004 16:39:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AorCX-0005vS-00 for pim@ietf.org; Thu, 05 Feb 2004 16:38:21 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AorCD-0005sd-00 for pim@ietf.org; Thu, 05 Feb 2004 16:38:02 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i15Laor01445; Thu, 5 Feb 2004 13:36:50 -0800 X-mProtect: <200402052136> Nokia Silicon Valley Messaging Protection Received: from dadhcp-172019074117.americas.nokia.com (172.19.74.117) by darkstar.iprg.nokia.com smtpdajRZh5; Thu, 05 Feb 2004 13:36:48 PST Subject: RE: [pim] register messages vs. the SPT From: Rahul Bahadur To: ext Mathur Sonum-CSM109 Cc: pim@ietf.org In-Reply-To: <370596D46C9BD711B61A00065BF3658803D0FDB8@il06exm12> References: <370596D46C9BD711B61A00065BF3658803D0FDB8@il06exm12> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 05 Feb 2004 13:36:38 -0800 Message-Id: <1076017008.2306.30.camel@dadhcp-172019074117.americas.nokia.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit I apologize but I did not state two aspects clearly: 1) no, there are no active receivers initially, which is why the RP sends a register-stop. 2) after register-suppr. timer expires, a NULL-register would be sent. I believe I understand the behaviour properly now - even if the DR receives an SPT-join from PIMrtr while the register-suppr. timer is running (and is consequently forwarding data natively) it should still send a NULL register packet to the RP after the timer expires. Thanks again, Rahul On Thu, 2004-02-05 at 12:40, ext Mathur Sonum-CSM109 wrote: > > No, after register-suppression timer expires, DR should send Null Register packet to the RP (it is to inform RP that Sender is till active and to refresh the (S,G) state on RP without sending data). Moreover, SPT should not have been built as there are no receivers so far (hope that's what you meant). Even if the receiver had joined, then also DR should just send Null Register packet to RP after the reg-suppression timer expires. In that case, (S,G) state on RP and PIMrtr would be constantly refreshed by data. > > -- > Sonum > > -----Original Message----- > From: pim-admin@ietf.org [mailto:pim-admin@ietf.org] On Behalf Of Rahul Bahadur > Sent: Thursday, February 05, 2004 12:15 PM > To: pim@ietf.org > Subject: [pim] register messages vs. the SPT > > > > Hello, > > I have a question about register-encapsulation vs. the SPT. Assume the following topology: > > source - DR - PIMrtr - RP -------- receiver(s)? > > The source is constantly sending traffic. > > Initially the DR has no state and sends a register packet to the RP that replies with a register-stop. The DR stops encapsulation starts the > register-suppression timer. > > Now (for some reason) the SPT gets built, i.e., the DR receives an (S,G) join from PIMrtr. The DR starts forwarding data natively. > > When the register-suppression timer expires, should encapsulation re-start? > > Thanks, > Rahul > > > _______________________________________________ > 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-admin@ietf.org Thu Feb 5 18:44:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19603 for ; Thu, 5 Feb 2004 18:44:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aot9B-0001oM-DM; Thu, 05 Feb 2004 18:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aot8R-0001mq-Vr for pim@optimus.ietf.org; Thu, 05 Feb 2004 18:42:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19520 for ; Thu, 5 Feb 2004 18:42:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aot8O-0004zd-00 for pim@ietf.org; Thu, 05 Feb 2004 18:42:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aot7U-0004xp-00 for pim@ietf.org; Thu, 05 Feb 2004 18:41:17 -0500 Received: from smtp2.procket.com ([65.174.124.37] helo=dmz2.procket.com) by ietf-mx with esmtp (Exim 4.12) id 1Aot6Y-0004ul-00 for pim@ietf.org; Thu, 05 Feb 2004 18:40:19 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (8.12.8p1/8.12.1) with ESMTP id i161jwOt058952; Thu, 5 Feb 2004 17:45:59 -0800 (PST) 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 i15NdbYB029880; Thu, 5 Feb 2004 15:39:37 -0800 (PST) Received: from [10.1.5.19] ([10.1.5.19]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Feb 2004 15:39:37 -0800 In-Reply-To: <370596D46C9BD711B61A00065BF3658803D0FDB8@il06exm12> References: <370596D46C9BD711B61A00065BF3658803D0FDB8@il06exm12> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8E94E6E4-5834-11D8-AE17-00039307689E@procket.com> Content-Transfer-Encoding: 7bit Cc: John Zwiebel , "'Rahul Bahadur'" , pim@ietf.org From: John Zwiebel Subject: Re: [pim] register messages vs. the SPT Date: Thu, 5 Feb 2004 15:39:36 -0800 To: Mathur Sonum-CSM109 X-Mailer: Apple Mail (2.609) X-OriginalArrivalTime: 05 Feb 2004 23:39:37.0017 (UTC) FILETIME=[50DC9A90:01C3EC41] 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Feb 5, 2004, at 12:40 PM, Mathur Sonum-CSM109 wrote: > > No, after register-suppression timer expires, DR should send Null > Register packet to the RP (it is to inform RP that Sender is till > active and to refresh the (S,G) state on RP without sending data). > Moreover, SPT should not have been built as there are no receivers so > far (hope that's what you meant). Even if the receiver had joined, > then also DR should just send Null Register packet to RP after the > reg-suppression timer expires. In that case, (S,G) state on RP and > PIMrtr would be constantly refreshed by data. > > -- First the spec then reality... Not quite true or there would be no need for the N-bit: N The Null-Register bit. Set to 1 by a DR that is probing the RP before expiring its local Register-Suppression timer. Set to 0 otherwise. However, this is a case of following the spec to the letter vs doing somthing that is "good enough" to accomplish the job. By this I mean that the spec defines a "rp-probe time" Timer Name: Register Stop Timer (RST(S,G)) +---------------------------+---------------------- +--------------------+ |Value Name |Value | Explanation | +---------------------------+---------------------- +--------------------+ |Register_Suppression_Time |Default: 60 seconds | Period during | | | | which a DR stops | | | | sending Register- | | | | encapsulated data | | | | to the RP after | | | | receiving a | | | | RegisterStop | +---------------------------+---------------------- +--------------------+ |Register_Probe_Time |Default: 5 seconds | Time before RST | | | | expires when a DR | | | | may send a Null- | | | | Register to the RP | | | | to cause it to | | | | resend a | | | | RegisterStop | | | | message. | +---------------------------+---------------------- +--------------------+ But what is the register used for? To create state in the PIM-RP. I'm going to cover lots of possibilities but not recommend anything in particular, However, if I were implementing a new PIM, I'd want to make sure I met all the following. So back to creating state on the RP, that can easily be done with just a NULL register to create (S,G) state. Yes, that means that there will not be a data packet to send down the shared-path, but consider that if the RP does not have (*,G) state you'll have done all that encapsulating for no reason. How expensive that encapsulating is, I don't care to debate. OK, if you -do- have (*,G) state, what is the first-thing the RP is suppose to do? Yes, decapsulate and send the packet down the shared-tree, but then -also- join immediately to the shortest-path to create the X-line getting data to flow up to the RP. Now, you have to worry about sending your register-stop. If you wait as required by the spec for data to arrive natively, you could end up with the first-hop and the rp having full forwarding queues in their Route Processor (since data encap and decap happens on the route processor -- let us not get into worrying about whether or not a vendor can install a separate processor to take care of this encapsulation since I agree it can be done, but I would question why one would want/need to do it as you will see.) So, I submit to you that sending a single register to the RP and having the RP join to the SPT (X-line) would be "good enough". Not according to the spec, but definitely "good enough". Arguments about how this decision will result in lost packets to the receiver are valid, but considering how horrible PIM ASM is at delivering all the packets anyway -- who cares. Now, there is the question about whether or not an encapped data packet is required in the register. Remember the RP is going to join to the SPT and once the X-line is set up packets will get forwarded down the shared tree at all intersections with the X-line. (ie, all these turn-around routers are going to get set up). This happens according to the spec now so it isn't like its an either/or situation. So, I submit that including an encapsulated packet could be considered another over-engineered aspect of PIM-SM. Now, remember that the last-hop router is going to join to the SPT anyway. It has been shown that PIM-ASM, although designed to do so, can not effectively switch between the shared-tree and shortest-path in a manner that is reliable enough to not drop packets (or deliver duplicate packets, if not both). The PIM-RP is used for source discovery. In a more well-developed protocol and if we hadn't been on drugs for the last 10 years, we would have realized that having the network do source discovery -- especially when talking about interdomain multicast -- is insane. (Now is when this discussion will drift off into the SSM/Bidir vs Sparse mode argument. Do understand that we -must- get there and we have to do whatever it takes to get there and all objections to the contrary which insist that ASM is working are moot because ASM requires too many resources from the network and it always will -- but that doesn't mean that we can drop ASM today. So we need to keep (S,G) alive on the PIM-RP for source discovery. PIM registers are the only way this can be accomplished. AFAIC, I don't care if they are encapsulated, or NULL registers just as long as they get there every 3 minutes. NOTE, the spec specifies that NULL registers are sent as a "probe" and that if a register-stop isn't received that an encapsulated register is sent. In practice this "should" mean that the encapsulated register should never get sent. It isn't clear to me why an RP that receives a NULL register but doesn't respond with a register stop will do any better with an encapsulated register, but I suppose an implementation might drop NULL registers (because of CRC errors or whatever) and not drop encaped registers. So, bottom line, NULL registers _should_ be "good enough" for most implementations. Make sure your NULL registers work. Make sure that you can deal with a checksum over just the pim header and over the entire packet since some implementations do one and some do the other. Now your ASM is "good enough" and you can move on to getting SSM/Bidir developed and deployed and use your political skills to get switches to support IGMPv3 snooping (or get GARP developed) and get applications to support SSM and Bidir and get some reliable source discovery system that doesn't require the network to store those sources. Oh, and finally, find a way to deal with Beau's SSM DOS attack. Pretending that ASM is going to work to get multicast to move beyond what it is now is putting our heads in the sand. (Caveat, certain equipment vendors have a bounded network problem for which ASM may quite nicely meet all their requirements and for which SSM and Bidir may not add any functionality. Great. No argument. But if your multicast is suppose to run across the internet or even in a large enterprise with large BW requirements, its time to move on.) > Sonum > > -----Original Message----- > From: pim-admin@ietf.org [mailto:pim-admin@ietf.org] On Behalf Of > Rahul Bahadur > Sent: Thursday, February 05, 2004 12:15 PM > To: pim@ietf.org > Subject: [pim] register messages vs. the SPT > > > > Hello, > > I have a question about register-encapsulation vs. the SPT. Assume the > following topology: > > source - DR - PIMrtr - RP -------- receiver(s)? > > The source is constantly sending traffic. > > Initially the DR has no state and sends a register packet to the RP > that replies with a register-stop. The DR stops encapsulation starts > the > register-suppression timer. > > Now (for some reason) the SPT gets built, i.e., the DR receives an > (S,G) join from PIMrtr. The DR starts forwarding data natively. > > When the register-suppression timer expires, should encapsulation > re-start? > > Thanks, > Rahul > > > _______________________________________________ > 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 _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Thu Feb 5 18:45:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19629 for ; Thu, 5 Feb 2004 18:45:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AotBR-0001uP-60 for pim-archive@odin.ietf.org; Thu, 05 Feb 2004 18:45:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15NjL89007333 for pim-archive@odin.ietf.org; Thu, 5 Feb 2004 18:45:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AotBQ-0001uC-Uz for pim-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 18:45:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19624 for ; Thu, 5 Feb 2004 18:45:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AotBN-00057J-00 for pim-web-archive@ietf.org; Thu, 05 Feb 2004 18:45:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AotAV-000566-00 for pim-web-archive@ietf.org; Thu, 05 Feb 2004 18:44:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AotAF-00053w-00 for pim-web-archive@ietf.org; Thu, 05 Feb 2004 18:44:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aot9B-0001oM-DM; Thu, 05 Feb 2004 18:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aot8R-0001mq-Vr for pim@optimus.ietf.org; Thu, 05 Feb 2004 18:42:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19520 for ; Thu, 5 Feb 2004 18:42:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aot8O-0004zd-00 for pim@ietf.org; Thu, 05 Feb 2004 18:42:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aot7U-0004xp-00 for pim@ietf.org; Thu, 05 Feb 2004 18:41:17 -0500 Received: from smtp2.procket.com ([65.174.124.37] helo=dmz2.procket.com) by ietf-mx with esmtp (Exim 4.12) id 1Aot6Y-0004ul-00 for pim@ietf.org; Thu, 05 Feb 2004 18:40:19 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (8.12.8p1/8.12.1) with ESMTP id i161jwOt058952; Thu, 5 Feb 2004 17:45:59 -0800 (PST) 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 i15NdbYB029880; Thu, 5 Feb 2004 15:39:37 -0800 (PST) Received: from [10.1.5.19] ([10.1.5.19]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Feb 2004 15:39:37 -0800 In-Reply-To: <370596D46C9BD711B61A00065BF3658803D0FDB8@il06exm12> References: <370596D46C9BD711B61A00065BF3658803D0FDB8@il06exm12> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8E94E6E4-5834-11D8-AE17-00039307689E@procket.com> Content-Transfer-Encoding: 7bit Cc: John Zwiebel , "'Rahul Bahadur'" , pim@ietf.org From: John Zwiebel Subject: Re: [pim] register messages vs. the SPT Date: Thu, 5 Feb 2004 15:39:36 -0800 To: Mathur Sonum-CSM109 X-Mailer: Apple Mail (2.609) X-OriginalArrivalTime: 05 Feb 2004 23:39:37.0017 (UTC) FILETIME=[50DC9A90:01C3EC41] Content-Transfer-Encoding: 7bit Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit On Feb 5, 2004, at 12:40 PM, Mathur Sonum-CSM109 wrote: > > No, after register-suppression timer expires, DR should send Null > Register packet to the RP (it is to inform RP that Sender is till > active and to refresh the (S,G) state on RP without sending data). > Moreover, SPT should not have been built as there are no receivers so > far (hope that's what you meant). Even if the receiver had joined, > then also DR should just send Null Register packet to RP after the > reg-suppression timer expires. In that case, (S,G) state on RP and > PIMrtr would be constantly refreshed by data. > > -- First the spec then reality... Not quite true or there would be no need for the N-bit: N The Null-Register bit. Set to 1 by a DR that is probing the RP before expiring its local Register-Suppression timer. Set to 0 otherwise. However, this is a case of following the spec to the letter vs doing somthing that is "good enough" to accomplish the job. By this I mean that the spec defines a "rp-probe time" Timer Name: Register Stop Timer (RST(S,G)) +---------------------------+---------------------- +--------------------+ |Value Name |Value | Explanation | +---------------------------+---------------------- +--------------------+ |Register_Suppression_Time |Default: 60 seconds | Period during | | | | which a DR stops | | | | sending Register- | | | | encapsulated data | | | | to the RP after | | | | receiving a | | | | RegisterStop | +---------------------------+---------------------- +--------------------+ |Register_Probe_Time |Default: 5 seconds | Time before RST | | | | expires when a DR | | | | may send a Null- | | | | Register to the RP | | | | to cause it to | | | | resend a | | | | RegisterStop | | | | message. | +---------------------------+---------------------- +--------------------+ But what is the register used for? To create state in the PIM-RP. I'm going to cover lots of possibilities but not recommend anything in particular, However, if I were implementing a new PIM, I'd want to make sure I met all the following. So back to creating state on the RP, that can easily be done with just a NULL register to create (S,G) state. Yes, that means that there will not be a data packet to send down the shared-path, but consider that if the RP does not have (*,G) state you'll have done all that encapsulating for no reason. How expensive that encapsulating is, I don't care to debate. OK, if you -do- have (*,G) state, what is the first-thing the RP is suppose to do? Yes, decapsulate and send the packet down the shared-tree, but then -also- join immediately to the shortest-path to create the X-line getting data to flow up to the RP. Now, you have to worry about sending your register-stop. If you wait as required by the spec for data to arrive natively, you could end up with the first-hop and the rp having full forwarding queues in their Route Processor (since data encap and decap happens on the route processor -- let us not get into worrying about whether or not a vendor can install a separate processor to take care of this encapsulation since I agree it can be done, but I would question why one would want/need to do it as you will see.) So, I submit to you that sending a single register to the RP and having the RP join to the SPT (X-line) would be "good enough". Not according to the spec, but definitely "good enough". Arguments about how this decision will result in lost packets to the receiver are valid, but considering how horrible PIM ASM is at delivering all the packets anyway -- who cares. Now, there is the question about whether or not an encapped data packet is required in the register. Remember the RP is going to join to the SPT and once the X-line is set up packets will get forwarded down the shared tree at all intersections with the X-line. (ie, all these turn-around routers are going to get set up). This happens according to the spec now so it isn't like its an either/or situation. So, I submit that including an encapsulated packet could be considered another over-engineered aspect of PIM-SM. Now, remember that the last-hop router is going to join to the SPT anyway. It has been shown that PIM-ASM, although designed to do so, can not effectively switch between the shared-tree and shortest-path in a manner that is reliable enough to not drop packets (or deliver duplicate packets, if not both). The PIM-RP is used for source discovery. In a more well-developed protocol and if we hadn't been on drugs for the last 10 years, we would have realized that having the network do source discovery -- especially when talking about interdomain multicast -- is insane. (Now is when this discussion will drift off into the SSM/Bidir vs Sparse mode argument. Do understand that we -must- get there and we have to do whatever it takes to get there and all objections to the contrary which insist that ASM is working are moot because ASM requires too many resources from the network and it always will -- but that doesn't mean that we can drop ASM today. So we need to keep (S,G) alive on the PIM-RP for source discovery. PIM registers are the only way this can be accomplished. AFAIC, I don't care if they are encapsulated, or NULL registers just as long as they get there every 3 minutes. NOTE, the spec specifies that NULL registers are sent as a "probe" and that if a register-stop isn't received that an encapsulated register is sent. In practice this "should" mean that the encapsulated register should never get sent. It isn't clear to me why an RP that receives a NULL register but doesn't respond with a register stop will do any better with an encapsulated register, but I suppose an implementation might drop NULL registers (because of CRC errors or whatever) and not drop encaped registers. So, bottom line, NULL registers _should_ be "good enough" for most implementations. Make sure your NULL registers work. Make sure that you can deal with a checksum over just the pim header and over the entire packet since some implementations do one and some do the other. Now your ASM is "good enough" and you can move on to getting SSM/Bidir developed and deployed and use your political skills to get switches to support IGMPv3 snooping (or get GARP developed) and get applications to support SSM and Bidir and get some reliable source discovery system that doesn't require the network to store those sources. Oh, and finally, find a way to deal with Beau's SSM DOS attack. Pretending that ASM is going to work to get multicast to move beyond what it is now is putting our heads in the sand. (Caveat, certain equipment vendors have a bounded network problem for which ASM may quite nicely meet all their requirements and for which SSM and Bidir may not add any functionality. Great. No argument. But if your multicast is suppose to run across the internet or even in a large enterprise with large BW requirements, its time to move on.) > Sonum > > -----Original Message----- > From: pim-admin@ietf.org [mailto:pim-admin@ietf.org] On Behalf Of > Rahul Bahadur > Sent: Thursday, February 05, 2004 12:15 PM > To: pim@ietf.org > Subject: [pim] register messages vs. the SPT > > > > Hello, > > I have a question about register-encapsulation vs. the SPT. Assume the > following topology: > > source - DR - PIMrtr - RP -------- receiver(s)? > > The source is constantly sending traffic. > > Initially the DR has no state and sends a register packet to the RP > that replies with a register-stop. The DR stops encapsulation starts > the > register-suppression timer. > > Now (for some reason) the SPT gets built, i.e., the DR receives an > (S,G) join from PIMrtr. The DR starts forwarding data natively. > > When the register-suppression timer expires, should encapsulation > re-start? > > Thanks, > Rahul > > > _______________________________________________ > 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 _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Fri Feb 6 19:26:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01311 for ; Fri, 6 Feb 2004 19:26:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApGIL-000229-NJ; Fri, 06 Feb 2004 19:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApGHO-0001zz-Nr for pim@optimus.ietf.org; Fri, 06 Feb 2004 19:25:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01283 for ; Fri, 6 Feb 2004 19:24:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApGHN-0007Pm-00 for pim@ietf.org; Fri, 06 Feb 2004 19:25:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApGGO-0007MC-00 for pim@ietf.org; Fri, 06 Feb 2004 19:24:01 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1ApGFH-0007Gf-00 for pim@ietf.org; Fri, 06 Feb 2004 19:23:01 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i170MWAH018335 for ; Fri, 6 Feb 2004 17:22:42 -0700 (MST) Received: from il06exm10.corp.mot.com (il06exm10.corp.mot.com [10.0.111.10]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i170MUlH008543 for ; Fri, 6 Feb 2004 18:22:30 -0600 Received: by il06exm10 with Internet Mail Service (5.5.2657.2) id ; Fri, 6 Feb 2004 18:22:30 -0600 Message-ID: <370596D46C9BD711B61A00065BF3658803D0FDBF@il06exm12> From: Mathur Sonum-CSM109 To: "'John Zwiebel'" Cc: "'Rahul Bahadur'" , pim@ietf.org Subject: RE: [pim] register messages vs. the SPT Date: Fri, 6 Feb 2004 18:22:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , > So, I submit to you that sending a single register to the RP > and having > the > RP join to the SPT (X-line) would be "good enough". Not > according to > the > spec, but definitely "good enough". > > Arguments about how this decision will result in lost packets to the > receiver > are valid, but considering how horrible PIM ASM is at delivering all > the packets > anyway -- who cares. From what I understand, you are suggesting that Sender's DR should be sending just one Null Register packet and no further Null/Encap Registers at all. This would be ok with the receivers who are ready to miss few initial packets (for the time duration of getting native path established - (S,G) Join reaching Sender's DR from the RP). Moreover, if this Null Register packet gets dropped, then RP will not be aware of the new source at all. What is the gain in doing this ? I believe that sending Registers encapsulating data is worth the effort and overhead for minimizing lost packets for the receivers. > NOTE, the spec specifies that NULL registers are sent as a "probe" > and that if a register-stop isn't received that an encapsulated > register is sent. In practice this "should" mean that the > encapsulated register should never get sent. It isn't clear to > me why an RP that receives a NULL register but doesn't respond > with a register stop will do any better with an encapsulated > register, but I suppose an implementation might drop NULL registers > (because of CRC errors or whatever) and not drop encaped registers. That's true. If RP is not responding to Register-Stop, then it is highly likely that it will not respond to encapsulated register also. Only advantage in doing this could be that receivers can get decapsulated data (that also is based on the assumption that native tree is broken). -- Sonum > -----Original Message----- > From: John Zwiebel [mailto:jzwiebel@procket.com] > Sent: Thursday, February 05, 2004 3:40 PM > To: Mathur Sonum-CSM109 > Cc: John Zwiebel; 'Rahul Bahadur'; pim@ietf.org > Subject: Re: [pim] register messages vs. the SPT > > > > > On Feb 5, 2004, at 12:40 PM, Mathur Sonum-CSM109 wrote: > > > > > No, after register-suppression timer expires, DR should send Null > > Register packet to the RP (it is to inform RP that Sender is till > > active and to refresh the (S,G) state on RP without sending data). > > Moreover, SPT should not have been built as there are no > receivers so > > far (hope that's what you meant). Even if the receiver had joined, > > then also DR should just send Null Register packet to RP after the > > reg-suppression timer expires. In that case, (S,G) state on RP and > > PIMrtr would be constantly refreshed by data. > > > > -- > > First the spec then reality... > Not quite true or there would be no need for the N-bit: > > N The Null-Register bit. Set to 1 by a DR that is probing the RP > before expiring its local Register-Suppression timer. Set to 0 > otherwise. > > However, this is a case of following the spec to the letter vs doing > somthing > that is "good enough" to accomplish the job. > > By this I mean that the spec defines a "rp-probe time" > > > Timer Name: Register Stop Timer (RST(S,G)) > > > > +---------------------------+---------------------- > +--------------------+ > |Value Name |Value | > Explanation > | > > +---------------------------+---------------------- > +--------------------+ > |Register_Suppression_Time |Default: 60 seconds | > Period during > | > | | | which > a DR stops > | > | | | sending > Register- | > | | | encapsulated > data | > | | | to > the RP after > | > | | | > receiving a > | > | | | > RegisterStop > | > > +---------------------------+---------------------- > +--------------------+ > |Register_Probe_Time |Default: 5 seconds | Time > before RST > | > | | | > expires when a > DR | > | | | may > send a Null- > | > | | | > Register to the > RP | > | | | to > cause it to > | > | | | > resend a > | > | | | > RegisterStop > | > | | | > message. > | > > +---------------------------+---------------------- > +--------------------+ > > > But what is the register used for? To create state in the PIM-RP. > > I'm going to cover lots of possibilities but not recommend anything in > particular, However, if I were implementing a new PIM, I'd > want to make > sure > I met all the following. > > So back to creating state on the RP, that can easily be done > with just a > NULL register to create (S,G) state. Yes, that means that > there will > not > be a data packet to send down the shared-path, but consider > that if the > RP does not have (*,G) state you'll have done all that > encapsulating for > no reason. How expensive that encapsulating is, I don't care > to debate. > > OK, if you -do- have (*,G) state, what is the first-thing the RP is > suppose > to do? Yes, decapsulate and send the packet down the > shared-tree, but > then > -also- join immediately to the shortest-path to create the X-line > getting > data to flow up to the RP. > > Now, you have to worry about sending your register-stop. If > you wait as > required by the spec for data to arrive natively, you could > end up with > the first-hop and the rp having full forwarding queues in > their Route > Processor > (since data encap and decap happens on the route processor -- > let us not > get into worrying about whether or not a vendor can install a separate > processor to take care of this encapsulation since I agree it can be > done, > but I would question why one would want/need to do it as you > will see.) > > So, I submit to you that sending a single register to the RP > and having > the > RP join to the SPT (X-line) would be "good enough". Not > according to > the > spec, but definitely "good enough". > > Arguments about how this decision will result in lost packets to the > receiver > are valid, but considering how horrible PIM ASM is at delivering all > the packets > anyway -- who cares. > > Now, there is the question about whether or not an encapped > data packet > is > required in the register. Remember the RP is going to join to the SPT > and once the X-line is set up packets will get forwarded down > the shared > tree at all intersections with the X-line. (ie, all these turn-around > routers are going to get set up). This happens according to > the spec > now > so it isn't like its an either/or situation. > > So, I submit that including an encapsulated packet could be considered > another over-engineered aspect of PIM-SM. > > Now, remember that the last-hop router is going to join to the SPT > anyway. > It has been shown that PIM-ASM, although designed to do so, can not > effectively switch between the shared-tree and shortest-path in a > manner that is reliable enough to not drop packets (or deliver > duplicate packets, if not both). > > The PIM-RP is used for source discovery. In a more well-developed > protocol and if we hadn't been on drugs for the last 10 > years, we would > have realized that having the network do source discovery -- > especially > when talking about interdomain multicast -- is insane. (Now is when > this discussion will drift off into the SSM/Bidir vs Sparse mode > argument. > Do understand that we -must- get there and we have to do whatever it > takes to get there and all objections to the contrary which > insist that > ASM is working are moot because ASM requires too many resources from > the network and it always will -- but that doesn't mean that we can > drop ASM today. > > So we need to keep (S,G) alive on the PIM-RP for source discovery. > PIM registers are the only way this can be accomplished. > > AFAIC, I don't care if they are encapsulated, or NULL registers > just as long as they get there every 3 minutes. > > NOTE, the spec specifies that NULL registers are sent as a "probe" > and that if a register-stop isn't received that an encapsulated > register is sent. In practice this "should" mean that the > encapsulated register should never get sent. It isn't clear to > me why an RP that receives a NULL register but doesn't respond > with a register stop will do any better with an encapsulated > register, but I suppose an implementation might drop NULL registers > (because of CRC errors or whatever) and not drop encaped registers. > > So, bottom line, NULL registers _should_ be "good enough" for most > implementations. Make sure your NULL registers work. Make sure > that you can deal with a checksum over just the pim header and > over the entire packet since some implementations do one and > some do the other. > > Now your ASM is "good enough" and you can move on to getting > SSM/Bidir developed and deployed and use your political skills > to get switches to support IGMPv3 snooping (or get GARP developed) > and get applications to support SSM and Bidir and get some reliable > source discovery system that doesn't require the network to store > those sources. > > Oh, and finally, find a way to deal with Beau's SSM DOS attack. > > Pretending that ASM is going to work to get multicast to move beyond > what it is now is putting our heads in the sand. > > (Caveat, certain equipment vendors have a bounded network problem > for which ASM may quite nicely meet all their requirements and for > which SSM and Bidir may not add any functionality. Great. No > argument. But if your multicast is suppose to run across the internet > or even in a large enterprise with large BW requirements, its time > to move on.) > > > > Sonum > > > > -----Original Message----- > > From: pim-admin@ietf.org [mailto:pim-admin@ietf.org] On Behalf Of > > Rahul Bahadur > > Sent: Thursday, February 05, 2004 12:15 PM > > To: pim@ietf.org > > Subject: [pim] register messages vs. the SPT > > > > > > > > Hello, > > > > I have a question about register-encapsulation vs. the SPT. > Assume the > > following topology: > > > > source - DR - PIMrtr - RP -------- receiver(s)? > > > > The source is constantly sending traffic. > > > > Initially the DR has no state and sends a register packet > to the RP > > that replies with a register-stop. The DR stops > encapsulation starts > > the > > register-suppression timer. > > > > Now (for some reason) the SPT gets built, i.e., the DR receives an > > (S,G) join from PIMrtr. The DR starts forwarding data natively. > > > > When the register-suppression timer expires, should encapsulation > > re-start? > > > > Thanks, > > Rahul > > > > > > _______________________________________________ > > 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 > _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Fri Feb 6 19:28:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01376 for ; Fri, 6 Feb 2004 19:28:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApGKL-0002Js-W0 for pim-archive@odin.ietf.org; Fri, 06 Feb 2004 19:28:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i170S5Vg008912 for pim-archive@odin.ietf.org; Fri, 6 Feb 2004 19:28:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApGKL-0002Jf-PL for pim-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 19:28:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01362 for ; Fri, 6 Feb 2004 19:28:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApGKK-0007Zw-00 for pim-web-archive@ietf.org; Fri, 06 Feb 2004 19:28:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApGJP-0007Wj-00 for pim-web-archive@ietf.org; Fri, 06 Feb 2004 19:27:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApGIb-0007Ti-00 for pim-web-archive@ietf.org; Fri, 06 Feb 2004 19:26:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApGIL-000229-NJ; Fri, 06 Feb 2004 19:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApGHO-0001zz-Nr for pim@optimus.ietf.org; Fri, 06 Feb 2004 19:25:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01283 for ; Fri, 6 Feb 2004 19:24:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApGHN-0007Pm-00 for pim@ietf.org; Fri, 06 Feb 2004 19:25:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApGGO-0007MC-00 for pim@ietf.org; Fri, 06 Feb 2004 19:24:01 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1ApGFH-0007Gf-00 for pim@ietf.org; Fri, 06 Feb 2004 19:23:01 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i170MWAH018335 for ; Fri, 6 Feb 2004 17:22:42 -0700 (MST) Received: from il06exm10.corp.mot.com (il06exm10.corp.mot.com [10.0.111.10]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i170MUlH008543 for ; Fri, 6 Feb 2004 18:22:30 -0600 Received: by il06exm10 with Internet Mail Service (5.5.2657.2) id ; Fri, 6 Feb 2004 18:22:30 -0600 Message-ID: <370596D46C9BD711B61A00065BF3658803D0FDBF@il06exm12> From: Mathur Sonum-CSM109 To: "'John Zwiebel'" Cc: "'Rahul Bahadur'" , pim@ietf.org Subject: RE: [pim] register messages vs. the SPT Date: Fri, 6 Feb 2004 18:22:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 > So, I submit to you that sending a single register to the RP > and having > the > RP join to the SPT (X-line) would be "good enough". Not > according to > the > spec, but definitely "good enough". > > Arguments about how this decision will result in lost packets to the > receiver > are valid, but considering how horrible PIM ASM is at delivering all > the packets > anyway -- who cares. From what I understand, you are suggesting that Sender's DR should be sending just one Null Register packet and no further Null/Encap Registers at all. This would be ok with the receivers who are ready to miss few initial packets (for the time duration of getting native path established - (S,G) Join reaching Sender's DR from the RP). Moreover, if this Null Register packet gets dropped, then RP will not be aware of the new source at all. What is the gain in doing this ? I believe that sending Registers encapsulating data is worth the effort and overhead for minimizing lost packets for the receivers. > NOTE, the spec specifies that NULL registers are sent as a "probe" > and that if a register-stop isn't received that an encapsulated > register is sent. In practice this "should" mean that the > encapsulated register should never get sent. It isn't clear to > me why an RP that receives a NULL register but doesn't respond > with a register stop will do any better with an encapsulated > register, but I suppose an implementation might drop NULL registers > (because of CRC errors or whatever) and not drop encaped registers. That's true. If RP is not responding to Register-Stop, then it is highly likely that it will not respond to encapsulated register also. Only advantage in doing this could be that receivers can get decapsulated data (that also is based on the assumption that native tree is broken). -- Sonum > -----Original Message----- > From: John Zwiebel [mailto:jzwiebel@procket.com] > Sent: Thursday, February 05, 2004 3:40 PM > To: Mathur Sonum-CSM109 > Cc: John Zwiebel; 'Rahul Bahadur'; pim@ietf.org > Subject: Re: [pim] register messages vs. the SPT > > > > > On Feb 5, 2004, at 12:40 PM, Mathur Sonum-CSM109 wrote: > > > > > No, after register-suppression timer expires, DR should send Null > > Register packet to the RP (it is to inform RP that Sender is till > > active and to refresh the (S,G) state on RP without sending data). > > Moreover, SPT should not have been built as there are no > receivers so > > far (hope that's what you meant). Even if the receiver had joined, > > then also DR should just send Null Register packet to RP after the > > reg-suppression timer expires. In that case, (S,G) state on RP and > > PIMrtr would be constantly refreshed by data. > > > > -- > > First the spec then reality... > Not quite true or there would be no need for the N-bit: > > N The Null-Register bit. Set to 1 by a DR that is probing the RP > before expiring its local Register-Suppression timer. Set to 0 > otherwise. > > However, this is a case of following the spec to the letter vs doing > somthing > that is "good enough" to accomplish the job. > > By this I mean that the spec defines a "rp-probe time" > > > Timer Name: Register Stop Timer (RST(S,G)) > > > > +---------------------------+---------------------- > +--------------------+ > |Value Name |Value | > Explanation > | > > +---------------------------+---------------------- > +--------------------+ > |Register_Suppression_Time |Default: 60 seconds | > Period during > | > | | | which > a DR stops > | > | | | sending > Register- | > | | | encapsulated > data | > | | | to > the RP after > | > | | | > receiving a > | > | | | > RegisterStop > | > > +---------------------------+---------------------- > +--------------------+ > |Register_Probe_Time |Default: 5 seconds | Time > before RST > | > | | | > expires when a > DR | > | | | may > send a Null- > | > | | | > Register to the > RP | > | | | to > cause it to > | > | | | > resend a > | > | | | > RegisterStop > | > | | | > message. > | > > +---------------------------+---------------------- > +--------------------+ > > > But what is the register used for? To create state in the PIM-RP. > > I'm going to cover lots of possibilities but not recommend anything in > particular, However, if I were implementing a new PIM, I'd > want to make > sure > I met all the following. > > So back to creating state on the RP, that can easily be done > with just a > NULL register to create (S,G) state. Yes, that means that > there will > not > be a data packet to send down the shared-path, but consider > that if the > RP does not have (*,G) state you'll have done all that > encapsulating for > no reason. How expensive that encapsulating is, I don't care > to debate. > > OK, if you -do- have (*,G) state, what is the first-thing the RP is > suppose > to do? Yes, decapsulate and send the packet down the > shared-tree, but > then > -also- join immediately to the shortest-path to create the X-line > getting > data to flow up to the RP. > > Now, you have to worry about sending your register-stop. If > you wait as > required by the spec for data to arrive natively, you could > end up with > the first-hop and the rp having full forwarding queues in > their Route > Processor > (since data encap and decap happens on the route processor -- > let us not > get into worrying about whether or not a vendor can install a separate > processor to take care of this encapsulation since I agree it can be > done, > but I would question why one would want/need to do it as you > will see.) > > So, I submit to you that sending a single register to the RP > and having > the > RP join to the SPT (X-line) would be "good enough". Not > according to > the > spec, but definitely "good enough". > > Arguments about how this decision will result in lost packets to the > receiver > are valid, but considering how horrible PIM ASM is at delivering all > the packets > anyway -- who cares. > > Now, there is the question about whether or not an encapped > data packet > is > required in the register. Remember the RP is going to join to the SPT > and once the X-line is set up packets will get forwarded down > the shared > tree at all intersections with the X-line. (ie, all these turn-around > routers are going to get set up). This happens according to > the spec > now > so it isn't like its an either/or situation. > > So, I submit that including an encapsulated packet could be considered > another over-engineered aspect of PIM-SM. > > Now, remember that the last-hop router is going to join to the SPT > anyway. > It has been shown that PIM-ASM, although designed to do so, can not > effectively switch between the shared-tree and shortest-path in a > manner that is reliable enough to not drop packets (or deliver > duplicate packets, if not both). > > The PIM-RP is used for source discovery. In a more well-developed > protocol and if we hadn't been on drugs for the last 10 > years, we would > have realized that having the network do source discovery -- > especially > when talking about interdomain multicast -- is insane. (Now is when > this discussion will drift off into the SSM/Bidir vs Sparse mode > argument. > Do understand that we -must- get there and we have to do whatever it > takes to get there and all objections to the contrary which > insist that > ASM is working are moot because ASM requires too many resources from > the network and it always will -- but that doesn't mean that we can > drop ASM today. > > So we need to keep (S,G) alive on the PIM-RP for source discovery. > PIM registers are the only way this can be accomplished. > > AFAIC, I don't care if they are encapsulated, or NULL registers > just as long as they get there every 3 minutes. > > NOTE, the spec specifies that NULL registers are sent as a "probe" > and that if a register-stop isn't received that an encapsulated > register is sent. In practice this "should" mean that the > encapsulated register should never get sent. It isn't clear to > me why an RP that receives a NULL register but doesn't respond > with a register stop will do any better with an encapsulated > register, but I suppose an implementation might drop NULL registers > (because of CRC errors or whatever) and not drop encaped registers. > > So, bottom line, NULL registers _should_ be "good enough" for most > implementations. Make sure your NULL registers work. Make sure > that you can deal with a checksum over just the pim header and > over the entire packet since some implementations do one and > some do the other. > > Now your ASM is "good enough" and you can move on to getting > SSM/Bidir developed and deployed and use your political skills > to get switches to support IGMPv3 snooping (or get GARP developed) > and get applications to support SSM and Bidir and get some reliable > source discovery system that doesn't require the network to store > those sources. > > Oh, and finally, find a way to deal with Beau's SSM DOS attack. > > Pretending that ASM is going to work to get multicast to move beyond > what it is now is putting our heads in the sand. > > (Caveat, certain equipment vendors have a bounded network problem > for which ASM may quite nicely meet all their requirements and for > which SSM and Bidir may not add any functionality. Great. No > argument. But if your multicast is suppose to run across the internet > or even in a large enterprise with large BW requirements, its time > to move on.) > > > > Sonum > > > > -----Original Message----- > > From: pim-admin@ietf.org [mailto:pim-admin@ietf.org] On Behalf Of > > Rahul Bahadur > > Sent: Thursday, February 05, 2004 12:15 PM > > To: pim@ietf.org > > Subject: [pim] register messages vs. the SPT > > > > > > > > Hello, > > > > I have a question about register-encapsulation vs. the SPT. > Assume the > > following topology: > > > > source - DR - PIMrtr - RP -------- receiver(s)? > > > > The source is constantly sending traffic. > > > > Initially the DR has no state and sends a register packet > to the RP > > that replies with a register-stop. The DR stops > encapsulation starts > > the > > register-suppression timer. > > > > Now (for some reason) the SPT gets built, i.e., the DR receives an > > (S,G) join from PIMrtr. The DR starts forwarding data natively. > > > > When the register-suppression timer expires, should encapsulation > > re-start? > > > > Thanks, > > Rahul > > > > > > _______________________________________________ > > 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 > _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Fri Feb 6 20:13:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03258 for ; Fri, 6 Feb 2004 20:13:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApH1o-0005ab-PW; Fri, 06 Feb 2004 20:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApH10-0005Vo-8N for pim@optimus.ietf.org; Fri, 06 Feb 2004 20:12:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03205 for ; Fri, 6 Feb 2004 20:12:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApH0y-0002qK-00 for pim@ietf.org; Fri, 06 Feb 2004 20:12:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApH06-0002mT-00 for pim@ietf.org; Fri, 06 Feb 2004 20:11:15 -0500 Received: from smtp2.procket.com ([65.174.124.37] helo=dmz2.procket.com) by ietf-mx with esmtp (Exim 4.12) id 1ApGzL-0002c4-00 for pim@ietf.org; Fri, 06 Feb 2004 20:10:27 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (8.12.8p1/8.12.1) with ESMTP id i173GEOt071318; Fri, 6 Feb 2004 19:16:14 -0800 (PST) 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 i1719qYB024279; Fri, 6 Feb 2004 17:09:52 -0800 (PST) Received: from [10.1.5.25] ([10.1.5.25]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 6 Feb 2004 17:09:52 -0800 In-Reply-To: <370596D46C9BD711B61A00065BF3658803D0FDBF@il06exm12> References: <370596D46C9BD711B61A00065BF3658803D0FDBF@il06exm12> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3AF57360-590A-11D8-B6E1-0003936A6062@procket.com> Content-Transfer-Encoding: 7bit Cc: "'Rahul Bahadur'" , pim@ietf.org From: John Zwiebel Subject: Re: [pim] register messages vs. the SPT Date: Fri, 6 Feb 2004 17:09:08 -0800 To: Mathur Sonum-CSM109 X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 07 Feb 2004 01:09:52.0205 (UTC) FILETIME=[16FA77D0:01C3ED17] 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Feb 6, 2004, at 4:22 PM, Mathur Sonum-CSM109 wrote: > > What is the gain in doing this ? I believe that sending Registers > encapsulating data is worth the effort and overhead for minimizing > lost packets for the receivers. > > 5 years ago I would have completely agreed with you. Things have changed. I gave a presentation to I2 in Hawaii 2 weeks ago outlining the problem since they are (were?) happy with ASM since they had spent a lot of time getting it to work. In summary, which hopefully provides you with all you need to understand my point, when PIM was first thought up it was suppose to address all the different multicast forwarding models that anyone had ever thought of. (Sparse, Dense, Shortest-Path, Shared) When every packet had to be examined by the CPU anyway, there was no additional cost to making this happen. Now, experience has shown us that dense-mode just isn't all that useful. Experience has shown us that RFC1112 which expects the network to "just handle it" is not realistic -- especially when talking about multicast around the world. Experience has taught us that ISPs love to blame each other for any problems (actually, that is rather harsh. Its more like they just don't want to have to explain to their customers that something that they have no control over is broken and they have to wait for some other ISP to fix it before it will work. I can't blame them for that since I have the same attitude.) And technical advances have allowed routers to separate the control-plane from the data-forwarding plane. Well, -right-now- (meaning next year it may change) even though high-end routers can do a good job of making PIM work, it takes a lot of router resources. Those resources could be used for lots of other things (even MPLS if you really want to be retro -- this is an opinion and should be overlooked if you really want to get where I'm going) So, shortest-path trees and shared-trees have shown themselves to be useful. Having a combination of SPT and shared has -not- shown itself to be useful. (ie, the idea that a last-hop might put low bw sources on the shared-tree but join to the SPT for high bw source has proven to be a nightmare. It does not work.) Its time to apply the KISS (keep it simple stupid) principle to multicast. SSM and Bidir PIM. One laments the fact that EXPRESS was never deployed, but then the recognition that it would have made shared-trees difficult comforts one. So this is a long way of saying, PIM registers are left-overs from the last decade. The idea of making the network responsible for source discovery needs to have a wooden stake driven through its heart. Now, please understand that I'm much more concerned with interdomain multicast or large enterprise multicast. In this environment, registering with the RP, delivering data down the shared tree, switching to the shortest-path, and -not- dropping a packet is impossible. Your deployment and your application may be completely different. You may have found that ASM works extremely well for you. I am not advocating that you dump something that works for something that will work just as good. (I have a dim feeling of what motorola is doing with multicast and given the small diameter of the network I think you are dealing with, ASM will work just great.) Finally, WRT PIM registers, I wasn't advocating changing the spec nor am I telling you to avoid dealing with the spec. Its a good spec. They put a lot of work into it and should be proud of it. With ASM, the PIM-RP (note I have to say PIM-RP because RP is often mistaken for the Route Processor which is the brains of a high-end router.) -must- be able to maintain (S,G) state for every source that is sending. You can use NULL (data-header) registers or encapsulated registers to keep this state alive. My point was that as long as the state is alive on the RP, you shouldn't have to implement all the different parts of the spec to be able to deliver mpackets. And since the only way to ensure you don't drop packets is to use SSM/Bidir (well, actually I should say that ASM is nearly guaranteed to drop packets in the environment I'm interested in) I am trying to encourage you to say "my asm is good enough, its time to figure out how to do SSM/Bidir". SSM needs IGMPv3 in the host. That means we need lots of folks banging on the OS guys asking for their IGMPv3. Heck, you might want to spend time getting IGMPv3 into your favorite OS. A new directory system that lets hosts discover sources without having to depend on sdr and PIM registers is another area that needs some new ideas. Making your PIM implementation comply totally with the current PIM spec isn't necessarily a bad idea. Its just an idea that has passed. (Like ATM, and MPLS -- OK maybe MPLS hasn't died yet, but its just another way to do ATM so I believe it will.) I want to encourage you to solve the big problem, not show that you can comply with an old wet-dream that's 10 years old. See my point? _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Fri Feb 6 20:15:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03322 for ; Fri, 6 Feb 2004 20:15:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApH3q-0005nF-Kd for pim-archive@odin.ietf.org; Fri, 06 Feb 2004 20:15:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i171F6xq022263 for pim-archive@odin.ietf.org; Fri, 6 Feb 2004 20:15:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApH3q-0005n0-Di for pim-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 20:15:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03290 for ; Fri, 6 Feb 2004 20:15:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApH3o-00031T-00 for pim-web-archive@ietf.org; Fri, 06 Feb 2004 20:15:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApH2q-0002xN-00 for pim-web-archive@ietf.org; Fri, 06 Feb 2004 20:14:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApH1u-0002tz-00 for pim-web-archive@ietf.org; Fri, 06 Feb 2004 20:13:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApH1o-0005ab-PW; Fri, 06 Feb 2004 20:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApH10-0005Vo-8N for pim@optimus.ietf.org; Fri, 06 Feb 2004 20:12:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03205 for ; Fri, 6 Feb 2004 20:12:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApH0y-0002qK-00 for pim@ietf.org; Fri, 06 Feb 2004 20:12:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApH06-0002mT-00 for pim@ietf.org; Fri, 06 Feb 2004 20:11:15 -0500 Received: from smtp2.procket.com ([65.174.124.37] helo=dmz2.procket.com) by ietf-mx with esmtp (Exim 4.12) id 1ApGzL-0002c4-00 for pim@ietf.org; Fri, 06 Feb 2004 20:10:27 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (8.12.8p1/8.12.1) with ESMTP id i173GEOt071318; Fri, 6 Feb 2004 19:16:14 -0800 (PST) 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 i1719qYB024279; Fri, 6 Feb 2004 17:09:52 -0800 (PST) Received: from [10.1.5.25] ([10.1.5.25]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 6 Feb 2004 17:09:52 -0800 In-Reply-To: <370596D46C9BD711B61A00065BF3658803D0FDBF@il06exm12> References: <370596D46C9BD711B61A00065BF3658803D0FDBF@il06exm12> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3AF57360-590A-11D8-B6E1-0003936A6062@procket.com> Content-Transfer-Encoding: 7bit Cc: "'Rahul Bahadur'" , pim@ietf.org From: John Zwiebel Subject: Re: [pim] register messages vs. the SPT Date: Fri, 6 Feb 2004 17:09:08 -0800 To: Mathur Sonum-CSM109 X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 07 Feb 2004 01:09:52.0205 (UTC) FILETIME=[16FA77D0:01C3ED17] Content-Transfer-Encoding: 7bit Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit On Feb 6, 2004, at 4:22 PM, Mathur Sonum-CSM109 wrote: > > What is the gain in doing this ? I believe that sending Registers > encapsulating data is worth the effort and overhead for minimizing > lost packets for the receivers. > > 5 years ago I would have completely agreed with you. Things have changed. I gave a presentation to I2 in Hawaii 2 weeks ago outlining the problem since they are (were?) happy with ASM since they had spent a lot of time getting it to work. In summary, which hopefully provides you with all you need to understand my point, when PIM was first thought up it was suppose to address all the different multicast forwarding models that anyone had ever thought of. (Sparse, Dense, Shortest-Path, Shared) When every packet had to be examined by the CPU anyway, there was no additional cost to making this happen. Now, experience has shown us that dense-mode just isn't all that useful. Experience has shown us that RFC1112 which expects the network to "just handle it" is not realistic -- especially when talking about multicast around the world. Experience has taught us that ISPs love to blame each other for any problems (actually, that is rather harsh. Its more like they just don't want to have to explain to their customers that something that they have no control over is broken and they have to wait for some other ISP to fix it before it will work. I can't blame them for that since I have the same attitude.) And technical advances have allowed routers to separate the control-plane from the data-forwarding plane. Well, -right-now- (meaning next year it may change) even though high-end routers can do a good job of making PIM work, it takes a lot of router resources. Those resources could be used for lots of other things (even MPLS if you really want to be retro -- this is an opinion and should be overlooked if you really want to get where I'm going) So, shortest-path trees and shared-trees have shown themselves to be useful. Having a combination of SPT and shared has -not- shown itself to be useful. (ie, the idea that a last-hop might put low bw sources on the shared-tree but join to the SPT for high bw source has proven to be a nightmare. It does not work.) Its time to apply the KISS (keep it simple stupid) principle to multicast. SSM and Bidir PIM. One laments the fact that EXPRESS was never deployed, but then the recognition that it would have made shared-trees difficult comforts one. So this is a long way of saying, PIM registers are left-overs from the last decade. The idea of making the network responsible for source discovery needs to have a wooden stake driven through its heart. Now, please understand that I'm much more concerned with interdomain multicast or large enterprise multicast. In this environment, registering with the RP, delivering data down the shared tree, switching to the shortest-path, and -not- dropping a packet is impossible. Your deployment and your application may be completely different. You may have found that ASM works extremely well for you. I am not advocating that you dump something that works for something that will work just as good. (I have a dim feeling of what motorola is doing with multicast and given the small diameter of the network I think you are dealing with, ASM will work just great.) Finally, WRT PIM registers, I wasn't advocating changing the spec nor am I telling you to avoid dealing with the spec. Its a good spec. They put a lot of work into it and should be proud of it. With ASM, the PIM-RP (note I have to say PIM-RP because RP is often mistaken for the Route Processor which is the brains of a high-end router.) -must- be able to maintain (S,G) state for every source that is sending. You can use NULL (data-header) registers or encapsulated registers to keep this state alive. My point was that as long as the state is alive on the RP, you shouldn't have to implement all the different parts of the spec to be able to deliver mpackets. And since the only way to ensure you don't drop packets is to use SSM/Bidir (well, actually I should say that ASM is nearly guaranteed to drop packets in the environment I'm interested in) I am trying to encourage you to say "my asm is good enough, its time to figure out how to do SSM/Bidir". SSM needs IGMPv3 in the host. That means we need lots of folks banging on the OS guys asking for their IGMPv3. Heck, you might want to spend time getting IGMPv3 into your favorite OS. A new directory system that lets hosts discover sources without having to depend on sdr and PIM registers is another area that needs some new ideas. Making your PIM implementation comply totally with the current PIM spec isn't necessarily a bad idea. Its just an idea that has passed. (Like ATM, and MPLS -- OK maybe MPLS hasn't died yet, but its just another way to do ATM so I believe it will.) I want to encourage you to solve the big problem, not show that you can comply with an old wet-dream that's 10 years old. See my point? _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Sun Feb 8 13:44:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27953 for ; Sun, 8 Feb 2004 13:44:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AptuS-0001pO-Np; Sun, 08 Feb 2004 13:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anpu0-00007K-W4 for pim@optimus.ietf.org; Mon, 02 Feb 2004 21:03:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00617 for ; Mon, 2 Feb 2004 21:02:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anpty-0007dH-00 for pim@ietf.org; Mon, 02 Feb 2004 21:02:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anpt9-0007Yq-00 for pim@ietf.org; Mon, 02 Feb 2004 21:02:08 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1Anpsv-0007UE-00 for pim@ietf.org; Mon, 02 Feb 2004 21:01:53 -0500 Received: (qmail 21463 invoked from network); 3 Feb 2004 02:01:20 -0000 Received: from dsl254-061-246.sea1.dsl.speakeasy.net (HELO ?192.168.2.142?) (ben@216.254.61.246) by layer8.net with SMTP; 3 Feb 2004 02:01:20 -0000 In-Reply-To: <200402021957.i12Jv43R012229@dino-pc.procket.com> References: <20040128011643.F240B8AEAF@xprdmailfe2.nwk.excite.com> <9E2891A4-5145-11D8-85AD-000A95DA7468@layer8.net> <200402021957.i12Jv43R012229@dino-pc.procket.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: jzwiebel@procket.com, aruts@excite.com, pim@ietf.org From: Benjamin Black Subject: Re: [pim] PIM BSM fragmentation Date: Mon, 2 Feb 2004 18:01:23 -0800 To: Dino Farinacci X-Mailer: Apple Mail (2.612) 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Perhaps that information should be added to future revisions of the specs. Ben On Feb 2, 2004, at 11:57 AM, Dino Farinacci wrote: >>> PIM can generate a message larger than the maximum size for a single >>> IP >>> packet, so it must be able to reassemble things when a single PIM >>> message is fragmented over multiple IP packets. > > No, PIM cannot. And a PIM implementation should not or else IP > will either > 1) drop the packet or 2) erroneously truncate the packet. > > Since PIM has no explicit capability in general to fragment > packets and > it is an IP client protocol, it follows the maximum packet size > oft IP > which is 0xffff. > > Dino > > _______________________________________________ > 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 exim@www1.ietf.org Sun Feb 8 13:46:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27999 for ; Sun, 8 Feb 2004 13:46:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aptwn-0001yi-KN for pim-archive@odin.ietf.org; Sun, 08 Feb 2004 13:46:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18IkPUb007600 for pim-archive@odin.ietf.org; Sun, 8 Feb 2004 13:46:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aptwn-0001yV-Et for pim-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 13:46:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27978 for ; Sun, 8 Feb 2004 13:46:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aptwl-0007Ew-00 for pim-web-archive@ietf.org; Sun, 08 Feb 2004 13:46:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aptvm-0007Ag-00 for pim-web-archive@ietf.org; Sun, 08 Feb 2004 13:45:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aptup-000775-00 for pim-web-archive@ietf.org; Sun, 08 Feb 2004 13:44:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AptuS-0001pO-Np; Sun, 08 Feb 2004 13:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anpu0-00007K-W4 for pim@optimus.ietf.org; Mon, 02 Feb 2004 21:03:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00617 for ; Mon, 2 Feb 2004 21:02:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anpty-0007dH-00 for pim@ietf.org; Mon, 02 Feb 2004 21:02:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anpt9-0007Yq-00 for pim@ietf.org; Mon, 02 Feb 2004 21:02:08 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1Anpsv-0007UE-00 for pim@ietf.org; Mon, 02 Feb 2004 21:01:53 -0500 Received: (qmail 21463 invoked from network); 3 Feb 2004 02:01:20 -0000 Received: from dsl254-061-246.sea1.dsl.speakeasy.net (HELO ?192.168.2.142?) (ben@216.254.61.246) by layer8.net with SMTP; 3 Feb 2004 02:01:20 -0000 In-Reply-To: <200402021957.i12Jv43R012229@dino-pc.procket.com> References: <20040128011643.F240B8AEAF@xprdmailfe2.nwk.excite.com> <9E2891A4-5145-11D8-85AD-000A95DA7468@layer8.net> <200402021957.i12Jv43R012229@dino-pc.procket.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: jzwiebel@procket.com, aruts@excite.com, pim@ietf.org From: Benjamin Black Subject: Re: [pim] PIM BSM fragmentation Date: Mon, 2 Feb 2004 18:01:23 -0800 To: Dino Farinacci X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit Perhaps that information should be added to future revisions of the specs. Ben On Feb 2, 2004, at 11:57 AM, Dino Farinacci wrote: >>> PIM can generate a message larger than the maximum size for a single >>> IP >>> packet, so it must be able to reassemble things when a single PIM >>> message is fragmented over multiple IP packets. > > No, PIM cannot. And a PIM implementation should not or else IP > will either > 1) drop the packet or 2) erroneously truncate the packet. > > Since PIM has no explicit capability in general to fragment > packets and > it is an IP client protocol, it follows the maximum packet size > oft IP > which is 0xffff. > > Dino > > _______________________________________________ > 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-admin@ietf.org Mon Feb 9 13:34:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03082 for ; Mon, 9 Feb 2004 13:34:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGEL-0005dl-0s; Mon, 09 Feb 2004 13:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGDh-0005bP-QS for pim@optimus.ietf.org; Mon, 09 Feb 2004 13:33:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03045 for ; Mon, 9 Feb 2004 13:33:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGDf-00039J-00 for pim@ietf.org; Mon, 09 Feb 2004 13:33:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGCs-00033i-00 for pim@ietf.org; Mon, 09 Feb 2004 13:32:30 -0500 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 1AqGCE-0002vS-00 for pim@ietf.org; Mon, 09 Feb 2004 13:31:50 -0500 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i19ISK9302110; Mon, 9 Feb 2004 12:28:20 -0600 Message-Id: <5.2.0.9.2.20040209120934.034426d0@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 09 Feb 2004 12:28:14 -0600 To: John Zwiebel From: Bill Nickless Subject: Re: [pim] register messages vs. the SPT Cc: Mathur Sonum-CSM109 , "'Rahul Bahadur'" , pim@ietf.org In-Reply-To: <3AF57360-590A-11D8-B6E1-0003936A6062@procket.com> References: <370596D46C9BD711B61A00065BF3658803D0FDBF@il06exm12> <370596D46C9BD711B61A00065BF3658803D0FDBF@il06exm12> Mime-Version: 1.0 Content-Type: text/plain 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 05:09 PM 2/6/2004 -0800, John Zwiebel wrote: >Now, experience has shown us that dense-mode just isn't all that useful. >Experience has shown us that RFC1112 which expects the network to >"just handle it" is not realistic -- especially when talking about >multicast around the world. >SSM needs IGMPv3 in the host. That means we need lots of folks >banging on the OS guys asking for their IGMPv3. Heck, you might >want to spend time getting IGMPv3 into your favorite OS. (Thwapping the expired equine one more time....) Fixing router code to do SSM is easy. It's merely a software upgrade to tell the router *not* to do PIM Registers and (*,G) joins within certain group address ranges. OK, adding IGMPv3 support on the edge, perhaps. Fixing operating systems to do SSM is moderately difficult. There are more operating systems deployed out there than routers. But the good news is that operating systems are a lot more extensible than in years past. Also, applications can do things that traditional operating systems couldn't/wouldn't do--just look at the Microsoft model where application writers distribute Microsoft-written .DLL files to get new functionality or fix bugs in Windows itself. Heck, when I install Visio from Microsoft, it installs a complete SQL-based relational database! Fixing edge IEEE 802 networks to do IGMPv3 snooping properly is simply not going to happen, especially when the only driver is that SSM absolutely requires it. And do you really think that the commodity IEEE 802.1 vendors are going to do MLD snooping at all, much less MLDv2? I'm not privy to Linksys's product roadmap, but don't have much hope it's there. >I want to encourage you to solve the big problem, not show that >you can comply with an old wet-dream that's 10 years old. SSM will not take off until applications can take advantage of it without requiring massive fork-lift upgrades of IEEE 802 edge/customer networks or adding much more IP routing smarts to their networks. This probably means re-engineering the mapping of IP packets to IEEE 802 frames, perhaps to the point of not trying to leverage the IEEE multicast facility to do IP multicast replication on the LAN. (The message-passing supercomputing software community has been doing collective operations without a LAN multicast facility for many years.) It also means automatic transition mechanisms (like the IPv6 community is having to build and deploy). And finally, it means applications taking responsibility for providing whatever facilities are needed, even if that means carrying along little bits of code that we would wish were already in the underlying operating systems. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP: 021D EB98 03B3 2E83 3D71 0397 251D 819A D0BE EA32 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQCfRRyUdgZrQvuoyEQLpAACg+mhM+R+En1u2KVxDou5fwIyV+HMAn3AK qVP7QTDV0v1g8NocqHPI28NJ =P8Xo -----END PGP SIGNATURE----- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Mon Feb 9 13:36:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03175 for ; Mon, 9 Feb 2004 13:36:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGGU-0005vN-Mc for pim-archive@odin.ietf.org; Mon, 09 Feb 2004 13:36:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19IaEdv022769 for pim-archive@odin.ietf.org; Mon, 9 Feb 2004 13:36:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGGU-0005vA-H6 for pim-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 13:36:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03126 for ; Mon, 9 Feb 2004 13:36:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGGS-0003PI-00 for pim-web-archive@ietf.org; Mon, 09 Feb 2004 13:36:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGFb-0003Jz-00 for pim-web-archive@ietf.org; Mon, 09 Feb 2004 13:35:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqGEc-0003FC-00 for pim-web-archive@ietf.org; Mon, 09 Feb 2004 13:34:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGEL-0005dl-0s; Mon, 09 Feb 2004 13:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGDh-0005bP-QS for pim@optimus.ietf.org; Mon, 09 Feb 2004 13:33:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03045 for ; Mon, 9 Feb 2004 13:33:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGDf-00039J-00 for pim@ietf.org; Mon, 09 Feb 2004 13:33:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGCs-00033i-00 for pim@ietf.org; Mon, 09 Feb 2004 13:32:30 -0500 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 1AqGCE-0002vS-00 for pim@ietf.org; Mon, 09 Feb 2004 13:31:50 -0500 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i19ISK9302110; Mon, 9 Feb 2004 12:28:20 -0600 Message-Id: <5.2.0.9.2.20040209120934.034426d0@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 09 Feb 2004 12:28:14 -0600 To: John Zwiebel From: Bill Nickless Subject: Re: [pim] register messages vs. the SPT Cc: Mathur Sonum-CSM109 , "'Rahul Bahadur'" , pim@ietf.org In-Reply-To: <3AF57360-590A-11D8-B6E1-0003936A6062@procket.com> References: <370596D46C9BD711B61A00065BF3658803D0FDBF@il06exm12> <370596D46C9BD711B61A00065BF3658803D0FDBF@il06exm12> Mime-Version: 1.0 Content-Type: text/plain Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 05:09 PM 2/6/2004 -0800, John Zwiebel wrote: >Now, experience has shown us that dense-mode just isn't all that useful. >Experience has shown us that RFC1112 which expects the network to >"just handle it" is not realistic -- especially when talking about >multicast around the world. >SSM needs IGMPv3 in the host. That means we need lots of folks >banging on the OS guys asking for their IGMPv3. Heck, you might >want to spend time getting IGMPv3 into your favorite OS. (Thwapping the expired equine one more time....) Fixing router code to do SSM is easy. It's merely a software upgrade to tell the router *not* to do PIM Registers and (*,G) joins within certain group address ranges. OK, adding IGMPv3 support on the edge, perhaps. Fixing operating systems to do SSM is moderately difficult. There are more operating systems deployed out there than routers. But the good news is that operating systems are a lot more extensible than in years past. Also, applications can do things that traditional operating systems couldn't/wouldn't do--just look at the Microsoft model where application writers distribute Microsoft-written .DLL files to get new functionality or fix bugs in Windows itself. Heck, when I install Visio from Microsoft, it installs a complete SQL-based relational database! Fixing edge IEEE 802 networks to do IGMPv3 snooping properly is simply not going to happen, especially when the only driver is that SSM absolutely requires it. And do you really think that the commodity IEEE 802.1 vendors are going to do MLD snooping at all, much less MLDv2? I'm not privy to Linksys's product roadmap, but don't have much hope it's there. >I want to encourage you to solve the big problem, not show that >you can comply with an old wet-dream that's 10 years old. SSM will not take off until applications can take advantage of it without requiring massive fork-lift upgrades of IEEE 802 edge/customer networks or adding much more IP routing smarts to their networks. This probably means re-engineering the mapping of IP packets to IEEE 802 frames, perhaps to the point of not trying to leverage the IEEE multicast facility to do IP multicast replication on the LAN. (The message-passing supercomputing software community has been doing collective operations without a LAN multicast facility for many years.) It also means automatic transition mechanisms (like the IPv6 community is having to build and deploy). And finally, it means applications taking responsibility for providing whatever facilities are needed, even if that means carrying along little bits of code that we would wish were already in the underlying operating systems. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP: 021D EB98 03B3 2E83 3D71 0397 251D 819A D0BE EA32 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQCfRRyUdgZrQvuoyEQLpAACg+mhM+R+En1u2KVxDou5fwIyV+HMAn3AK qVP7QTDV0v1g8NocqHPI28NJ =P8Xo -----END PGP SIGNATURE----- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Mon Feb 9 14:33:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06118 for ; Mon, 9 Feb 2004 14:33:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqH9R-00029A-1m; Mon, 09 Feb 2004 14:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqH8h-00021E-Ry for pim@optimus.ietf.org; Mon, 09 Feb 2004 14:32:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06009 for ; Mon, 9 Feb 2004 14:32:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqH8f-0001FX-00 for pim@ietf.org; Mon, 09 Feb 2004 14:32:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqH7n-0001An-00 for pim@ietf.org; Mon, 09 Feb 2004 14:31:20 -0500 Received: from catarina.usc.edu ([204.57.0.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqH7C-00014C-00 for pim@ietf.org; Mon, 09 Feb 2004 14:30:42 -0500 Received: from colo-dns-ext1.juniper.net (colo-dns-ext1.juniper.net [207.17.137.57]) by catarina.usc.edu (8.12.9/8.12.9) with ESMTP id i19JUC7J011878 for ; Mon, 9 Feb 2004 11:30:12 -0800 (PST) (envelope-from pusateri@juniper.net) 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 i19JU7l86431 for ; Mon, 9 Feb 2004 11:30:07 -0800 (PST) (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 i19JU2h83396 for ; Mon, 9 Feb 2004 11:30:02 -0800 (PST) (envelope-from pusateri@juniper.net) Message-Id: <200402091930.i19JU2h83396@merlot.juniper.net> To: pim@catarina.usc.edu MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <51758.1076355001.1@juniper.net> Date: Mon, 09 Feb 2004 11:30:02 -0800 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 Subject: [pim] Updated charter Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Here is an updated charter for the working group. We can't easily change work items but these changes do reflect new dates for the milestones. Thanks, Tom Aug 98 Hold the first Working Group meeting and discuss the charter and the state of progress on the chartered items. Dec 03 Update the PIM-DM version 2 Internet-draft. Go to WG last call. Submision to IESG for considerations as proposed standard. Mar 04 Resubmit the latest PIM-SM version 2 specification to IESG for consideration as a proposed standard RFC Mar 04 Submit Internet-Draft describing use of IP security with PIM. (This is now integragted into the sparse mode spec) Aug 04 Submit updated PIM-SM and PIM-DM internet-drafts, clarifying any inconsistencies or ambiguities in the previous drafts. Nov 04 Submit PIM-SM version 2 and PIM-DM version 2 specifications to IESG for consideration as Draft Standards. Aug 04 Submit PIM-SM and PIM-DM Applicability Statements Aug 04 Submit PIMv2 MIB to IESG for consideration as proposed standard. Mar 05 Submit PIMv2 MIB to IESG for consideration as draft standard. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Mon Feb 9 14:35:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06271 for ; Mon, 9 Feb 2004 14:35:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHBa-0002MX-HF for pim-archive@odin.ietf.org; Mon, 09 Feb 2004 14:35:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19JZErE009081 for pim-archive@odin.ietf.org; Mon, 9 Feb 2004 14:35:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHBa-0002MO-CP for pim-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 14:35:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06221 for ; Mon, 9 Feb 2004 14:35:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqHBX-0001XA-00 for pim-web-archive@ietf.org; Mon, 09 Feb 2004 14:35:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqHAZ-0001RP-00 for pim-web-archive@ietf.org; Mon, 09 Feb 2004 14:34:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqH9a-0001KN-00 for pim-web-archive@ietf.org; Mon, 09 Feb 2004 14:33:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqH9R-00029A-1m; Mon, 09 Feb 2004 14:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqH8h-00021E-Ry for pim@optimus.ietf.org; Mon, 09 Feb 2004 14:32:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06009 for ; Mon, 9 Feb 2004 14:32:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqH8f-0001FX-00 for pim@ietf.org; Mon, 09 Feb 2004 14:32:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqH7n-0001An-00 for pim@ietf.org; Mon, 09 Feb 2004 14:31:20 -0500 Received: from catarina.usc.edu ([204.57.0.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqH7C-00014C-00 for pim@ietf.org; Mon, 09 Feb 2004 14:30:42 -0500 Received: from colo-dns-ext1.juniper.net (colo-dns-ext1.juniper.net [207.17.137.57]) by catarina.usc.edu (8.12.9/8.12.9) with ESMTP id i19JUC7J011878 for ; Mon, 9 Feb 2004 11:30:12 -0800 (PST) (envelope-from pusateri@juniper.net) 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 i19JU7l86431 for ; Mon, 9 Feb 2004 11:30:07 -0800 (PST) (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 i19JU2h83396 for ; Mon, 9 Feb 2004 11:30:02 -0800 (PST) (envelope-from pusateri@juniper.net) Message-Id: <200402091930.i19JU2h83396@merlot.juniper.net> To: pim@catarina.usc.edu MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <51758.1076355001.1@juniper.net> Date: Mon, 09 Feb 2004 11:30:02 -0800 From: Tom Pusateri Subject: [pim] Updated charter Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 Here is an updated charter for the working group. We can't easily change work items but these changes do reflect new dates for the milestones. Thanks, Tom Aug 98 Hold the first Working Group meeting and discuss the charter and the state of progress on the chartered items. Dec 03 Update the PIM-DM version 2 Internet-draft. Go to WG last call. Submision to IESG for considerations as proposed standard. Mar 04 Resubmit the latest PIM-SM version 2 specification to IESG for consideration as a proposed standard RFC Mar 04 Submit Internet-Draft describing use of IP security with PIM. (This is now integragted into the sparse mode spec) Aug 04 Submit updated PIM-SM and PIM-DM internet-drafts, clarifying any inconsistencies or ambiguities in the previous drafts. Nov 04 Submit PIM-SM version 2 and PIM-DM version 2 specifications to IESG for consideration as Draft Standards. Aug 04 Submit PIM-SM and PIM-DM Applicability Statements Aug 04 Submit PIMv2 MIB to IESG for consideration as proposed standard. Mar 05 Submit PIMv2 MIB to IESG for consideration as draft standard. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Mon Feb 9 14:47:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06857 for ; Mon, 9 Feb 2004 14:47:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHMx-0003Je-Sh; Mon, 09 Feb 2004 14:46:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHMH-0003Ir-Ci for pim@optimus.ietf.org; Mon, 09 Feb 2004 14:46:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06800 for ; Mon, 9 Feb 2004 14:46:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqHME-0002Ub-00 for pim@ietf.org; Mon, 09 Feb 2004 14:46:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqHLM-0002QD-00 for pim@ietf.org; Mon, 09 Feb 2004 14:45:21 -0500 Received: from catarina.usc.edu ([204.57.0.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqHKl-0002JG-00 for pim@ietf.org; Mon, 09 Feb 2004 14:44:43 -0500 Received: from fwetgfw2r.itt.com (gate12.itt.com [151.190.254.107]) by catarina.usc.edu (8.12.9/8.12.9) with ESMTP id i19JiB7J012018 for ; Mon, 9 Feb 2004 11:44:11 -0800 (PST) (envelope-from Jonathan.Nicholas@itt.com) Received: from no.name.available by fwetgfw2r.itt.com via smtpd (for catarina.usc.edu [204.57.0.1]) with ESMTP; Mon, 9 Feb 2004 14:44:11 -0500 Received: from njbridge.avionics.de.ittind.com ([151.190.100.204]) by fwdcmail5.fwdc.de.ittind.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 9 Feb 2004 14:44:20 -0500 Received: from ACDNJMAILSRV02.acd.de.ittind.com ([151.190.3.218]) by njbridge.avionics.de.ittind.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 9 Feb 2004 14:43:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [pim] Updated charter Date: Mon, 9 Feb 2004 14:43:42 -0500 Message-ID: <2CA4524FA012F14BAE5D896D492B3868101880@ACDNJMAILSRV02.acd.de.ittind.com> Thread-Topic: [pim] Updated charter Thread-Index: AcPvQ5Qq5EcvEn3kTsCN53x/Hko/lwAASeEg From: "Nicholas, Jonathan" To: "Tom Pusateri" , X-OriginalArrivalTime: 09 Feb 2004 19:43:42.0921 (UTC) FILETIME=[0603F390:01C3EF45] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable While I would like to see PIM-DM go to proposed standard, the draft was= submitted as experimental. Jonathan Nicholas Network Systems Engineer ITT Aerospace/Communications Division > -----Original Message----- > From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of Tom > Pusateri > Sent: Monday, February 09, 2004 2:30 PM > To: pim@catarina.usc.edu > Subject: [pim] Updated charter >=0D >=0D > Here is an updated charter for the working group. We can't easily > change work items but these changes do reflect new dates for the > milestones. >=0D > Thanks, > Tom >=0D > Aug 98 > Hold the first Working Group meeting and discuss the charter and > the state of progress on the chartered items. >=0D > Dec 03 > Update the PIM-DM version 2 Internet-draft. Go to WG last call. > Submision to IESG for considerations as proposed standard. >=0D > Mar 04 > Resubmit the latest PIM-SM version 2 specification to IESG for > consideration as a proposed standard RFC >=0D > Mar 04 > Submit Internet-Draft describing use of IP security with PIM. > (This is now integragted into the sparse mode spec) >=0D > Aug 04 > Submit updated PIM-SM and PIM-DM internet-drafts, clarifying any > inconsistencies or ambiguities in the previous drafts. >=0D > Nov 04 > Submit PIM-SM version 2 and PIM-DM version 2 specifications to IESG > for consideration as Draft Standards. >=0D > Aug 04 > Submit PIM-SM and PIM-DM Applicability Statements >=0D > Aug 04 > Submit PIMv2 MIB to IESG for consideration as proposed standard. >=0D > Mar 05 > Submit PIMv2 MIB to IESG for consideration as draft standard. >=0D > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim >=0D ************************************ This email and any files transmitted with it are proprietary and intended= solely for the use of the individual or entity to whom they are addressed.= If you have received this email in error please notify the sender. Please note that any views or opinions= presented in this email are solely those of the author and do not= necessarily represent those of ITT Industries, Inc. The recipient should check this email and any attachments for the presence= of viruses. ITT Industries accepts no liability for any damage caused by= any virus transmitted by this email. ************************************ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Mon Feb 9 14:48:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06903 for ; Mon, 9 Feb 2004 14:48:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHOI-0003Qu-U3 for pim-archive@odin.ietf.org; Mon, 09 Feb 2004 14:48:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19JmMJk013190 for pim-archive@odin.ietf.org; Mon, 9 Feb 2004 14:48:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHOI-0003Qf-PT for pim-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 14:48:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06897 for ; Mon, 9 Feb 2004 14:48:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqHOG-0002fm-00 for pim-web-archive@ietf.org; Mon, 09 Feb 2004 14:48:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqHNL-0002av-00 for pim-web-archive@ietf.org; Mon, 09 Feb 2004 14:47:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqHN4-0002Vk-00 for pim-web-archive@ietf.org; Mon, 09 Feb 2004 14:47:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHMx-0003Je-Sh; Mon, 09 Feb 2004 14:46:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqHMH-0003Ir-Ci for pim@optimus.ietf.org; Mon, 09 Feb 2004 14:46:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06800 for ; Mon, 9 Feb 2004 14:46:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqHME-0002Ub-00 for pim@ietf.org; Mon, 09 Feb 2004 14:46:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqHLM-0002QD-00 for pim@ietf.org; Mon, 09 Feb 2004 14:45:21 -0500 Received: from catarina.usc.edu ([204.57.0.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqHKl-0002JG-00 for pim@ietf.org; Mon, 09 Feb 2004 14:44:43 -0500 Received: from fwetgfw2r.itt.com (gate12.itt.com [151.190.254.107]) by catarina.usc.edu (8.12.9/8.12.9) with ESMTP id i19JiB7J012018 for ; Mon, 9 Feb 2004 11:44:11 -0800 (PST) (envelope-from Jonathan.Nicholas@itt.com) Received: from no.name.available by fwetgfw2r.itt.com via smtpd (for catarina.usc.edu [204.57.0.1]) with ESMTP; Mon, 9 Feb 2004 14:44:11 -0500 Received: from njbridge.avionics.de.ittind.com ([151.190.100.204]) by fwdcmail5.fwdc.de.ittind.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 9 Feb 2004 14:44:20 -0500 Received: from ACDNJMAILSRV02.acd.de.ittind.com ([151.190.3.218]) by njbridge.avionics.de.ittind.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 9 Feb 2004 14:43:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [pim] Updated charter Date: Mon, 9 Feb 2004 14:43:42 -0500 Message-ID: <2CA4524FA012F14BAE5D896D492B3868101880@ACDNJMAILSRV02.acd.de.ittind.com> Thread-Topic: [pim] Updated charter Thread-Index: AcPvQ5Qq5EcvEn3kTsCN53x/Hko/lwAASeEg From: "Nicholas, Jonathan" To: "Tom Pusateri" , X-OriginalArrivalTime: 09 Feb 2004 19:43:42.0921 (UTC) FILETIME=[0603F390:01C3EF45] Content-Transfer-Encoding: quoted-printable Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable While I would like to see PIM-DM go to proposed standard, the draft was= submitted as experimental. Jonathan Nicholas Network Systems Engineer ITT Aerospace/Communications Division > -----Original Message----- > From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of Tom > Pusateri > Sent: Monday, February 09, 2004 2:30 PM > To: pim@catarina.usc.edu > Subject: [pim] Updated charter >=0D >=0D > Here is an updated charter for the working group. We can't easily > change work items but these changes do reflect new dates for the > milestones. >=0D > Thanks, > Tom >=0D > Aug 98 > Hold the first Working Group meeting and discuss the charter and > the state of progress on the chartered items. >=0D > Dec 03 > Update the PIM-DM version 2 Internet-draft. Go to WG last call. > Submision to IESG for considerations as proposed standard. >=0D > Mar 04 > Resubmit the latest PIM-SM version 2 specification to IESG for > consideration as a proposed standard RFC >=0D > Mar 04 > Submit Internet-Draft describing use of IP security with PIM. > (This is now integragted into the sparse mode spec) >=0D > Aug 04 > Submit updated PIM-SM and PIM-DM internet-drafts, clarifying any > inconsistencies or ambiguities in the previous drafts. >=0D > Nov 04 > Submit PIM-SM version 2 and PIM-DM version 2 specifications to IESG > for consideration as Draft Standards. >=0D > Aug 04 > Submit PIM-SM and PIM-DM Applicability Statements >=0D > Aug 04 > Submit PIMv2 MIB to IESG for consideration as proposed standard. >=0D > Mar 05 > Submit PIMv2 MIB to IESG for consideration as draft standard. >=0D > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim >=0D ************************************ This email and any files transmitted with it are proprietary and intended= solely for the use of the individual or entity to whom they are addressed.= If you have received this email in error please notify the sender. Please note that any views or opinions= presented in this email are solely those of the author and do not= necessarily represent those of ITT Industries, Inc. The recipient should check this email and any attachments for the presence= of viruses. ITT Industries accepts no liability for any damage caused by= any virus transmitted by this email. ************************************ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Mon Feb 9 16:40:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17012 for ; Mon, 9 Feb 2004 16:40:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJ8M-0006WA-Il; Mon, 09 Feb 2004 16:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJ83-0006Uz-Gs for pim@optimus.ietf.org; Mon, 09 Feb 2004 16:39:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16883 for ; Mon, 9 Feb 2004 16:39:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJ81-00075n-00 for pim@ietf.org; Mon, 09 Feb 2004 16:39:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJ76-0006yw-00 for pim@ietf.org; Mon, 09 Feb 2004 16:38:45 -0500 Received: from smtp2.procket.com ([65.174.124.37] helo=dmz2.procket.com) by ietf-mx with esmtp (Exim 4.12) id 1AqJ6U-0006pX-00 for pim@ietf.org; Mon, 09 Feb 2004 16:38:06 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (8.12.8p1/8.12.1) with ESMTP id i19NhnOt099922; Mon, 9 Feb 2004 15:43:49 -0800 (PST) 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 i19LbOd1016168; Mon, 9 Feb 2004 13:37:24 -0800 (PST) Received: from [10.1.5.115] ([10.1.5.115]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Feb 2004 13:37:24 -0800 In-Reply-To: <5.2.0.9.2.20040209120934.034426d0@pop.mcs.anl.gov> References: <370596D46C9BD711B61A00065BF3658803D0FDBF@il06exm12> <370596D46C9BD711B61A00065BF3658803D0FDBF@il06exm12> <5.2.0.9.2.20040209120934.034426d0@pop.mcs.anl.gov> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <254C7DEE-5B48-11D8-889C-00039307689E@procket.com> Content-Transfer-Encoding: 7bit Cc: pim@ietf.org, John Zwiebel , "'Rahul Bahadur'" , Mathur Sonum-CSM109 From: John Zwiebel Date: Mon, 9 Feb 2004 13:37:22 -0800 To: Bill Nickless X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 09 Feb 2004 21:37:24.0107 (UTC) FILETIME=[E7C255B0:01C3EF54] 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 Subject: [pim] SSM at layer 2 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bill: I can not disagree with any of the points you make. > > SSM will not take off until applications can take advantage of it > without > requiring massive fork-lift upgrades of IEEE 802 edge/customer > networks or > adding much more IP routing smarts to their networks. Let me ask a stupid question... GARP? Would it make things happen faster? There are GARP switches out there, are there enough that if routers and hosts all took advantage of it that we could move to the SSM/Bidir without having to snoop IGMPv3? Or, can we just turn off all the snooping and layer2 filtering for multicast packets and have multicast packets sent to every port. I only ask these questions to transition to another question that we need to look at. We can't 'push' multicast on anyone. If they don't want it they won't take it. If they do want it, then its a question of how badly they want it and how much it costs to make that transition. In other words, if GARP or flooding aren't viable alternatives and a fork-lift upgrade is required, then if folks want it they will bite the bullet and they will upgrade. It will happen, it just may not happen as fast as we would like it to happen. Switches have -never- been very good at handling multicast. (If someone wants to spin off a separate discussion on this so I might learn something, I'd appreciate it.) They've always assumed that they could just broadcast it everywhere. And when you talk about a lynxsys, well, I don't care if its capable of doing IGMPv3 snooping or not as long as it passes the multicast packet to the receivers. I'm not trying to suggest that there is no need for CGMP/RGMP or snooping, I'm saying that customers have to make a choice. Do they want multicast or not? Allowing a dumb switch to be the barrier to realizing the full potential of multicast will cause the deployment to be delayed, but it isn't going to stop it completely. > This probably means re-engineering the mapping of IP packets to IEEE > 802 > frames, perhaps to the point of not trying to leverage the IEEE > multicast > facility to do IP multicast replication on the LAN. > I may not understand what you are suggesting, but I don't believe this is going to happen. It -sounds- to me like you are suggesting something which is similar to the way ATM implements multicast by opening a separate VC from the head-end to each tail end. Having watched that fail over and over again (well, it was never "good enough" for me -- I don't mean you weren't successful to a limited extent) I wouldn't go down that path again. > It also means automatic transition mechanisms (like the IPv6 community > is > having to build and deploy). It isn't clear to me what you mean here. 6to4 tunnels? AMAP is being proposed to provide a way of transition a multicast stream to a unicast stream and setting up this tunnel automatically. However, this is going to require application development and there are objections to how to deploy it also. (Not saying we shouldn't, but UDLR didn't go anywhere.) finally, there is IGMPv2 to v3 translation. The host joins just the group, but the router translates that join to a (S,G) and sends a pim join for that specific channel. Lots of problems here also. > And finally, it means applications taking responsibility for providing > whatever facilities are needed, even if that means carrying along > little > bits of code that we would wish were already in the underlying > operating > systems. > And obviously, that is what we need to do. For too long now, separate organizations have been waiting for the "other guys" to solve the problem. Certainly a lot of that is understandable since each group gets their part to work within their limited environment and no one has the global responsibility for making this all work. We can argue forever about whether we need content first or infrastructure first. The NANOG presentations I'm watching right now just said something about how the most efficient networking can be accomplished by making sure that the router was directly connected to the fiber without anything in the way. Folks are upgrading routers, perhaps they won't buy switches. My point in this discussion is to get folks to recognize that there is a problem, that if they want to solve the problem they need to look beyond the limited area over which they currently have control and recognize the problems that the other areas are having. ie, switches need to do -something- to deal with multicast as it is. GARP was their solution, but is it "good enough"? If it is, why isn't it being implemented in routers and hosts? I tried to outline the problem from a router perspective. Routers -can- do ASM and they do it well, but ASM is difficult to get right and because it is data-driven and -not- just control plane driven, it uses tons of resources on the router that could be used more efficiently for other functions. You have a choice in how you want to allocate that processing power. So the question for you is, what are we going to do about it? I want efficient and reliable distribution of multicast packets. For routers, that means dumping ASM and moving on to Bidir and SSM. Routers have already done ASM, and things aren't moving forward. Part of the problem is because of the nature of ASM. I'm beginning to repeat myself so I'll see ya later. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Mon Feb 9 16:43:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17184 for ; Mon, 9 Feb 2004 16:43:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJAo-0006lM-9l for pim-archive@odin.ietf.org; Mon, 09 Feb 2004 16:42:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19LgYsP025990 for pim-archive@odin.ietf.org; Mon, 9 Feb 2004 16:42:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJAo-0006l7-0z for pim-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 16:42:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17150 for ; Mon, 9 Feb 2004 16:42:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJAm-0007PT-00 for pim-web-archive@ietf.org; Mon, 09 Feb 2004 16:42:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJ9d-0007Gs-00 for pim-web-archive@ietf.org; Mon, 09 Feb 2004 16:41:23 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqJ8g-0007AX-00 for pim-web-archive@ietf.org; Mon, 09 Feb 2004 16:40:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqJ8g-00019p-9l for pim-web-archive@ietf.org; Mon, 09 Feb 2004 16:40:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJ8M-0006WA-Il; Mon, 09 Feb 2004 16:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJ83-0006Uz-Gs for pim@optimus.ietf.org; Mon, 09 Feb 2004 16:39:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16883 for ; Mon, 9 Feb 2004 16:39:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJ81-00075n-00 for pim@ietf.org; Mon, 09 Feb 2004 16:39:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJ76-0006yw-00 for pim@ietf.org; Mon, 09 Feb 2004 16:38:45 -0500 Received: from smtp2.procket.com ([65.174.124.37] helo=dmz2.procket.com) by ietf-mx with esmtp (Exim 4.12) id 1AqJ6U-0006pX-00 for pim@ietf.org; Mon, 09 Feb 2004 16:38:06 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (8.12.8p1/8.12.1) with ESMTP id i19NhnOt099922; Mon, 9 Feb 2004 15:43:49 -0800 (PST) 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 i19LbOd1016168; Mon, 9 Feb 2004 13:37:24 -0800 (PST) Received: from [10.1.5.115] ([10.1.5.115]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Feb 2004 13:37:24 -0800 In-Reply-To: <5.2.0.9.2.20040209120934.034426d0@pop.mcs.anl.gov> References: <370596D46C9BD711B61A00065BF3658803D0FDBF@il06exm12> <370596D46C9BD711B61A00065BF3658803D0FDBF@il06exm12> <5.2.0.9.2.20040209120934.034426d0@pop.mcs.anl.gov> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <254C7DEE-5B48-11D8-889C-00039307689E@procket.com> Content-Transfer-Encoding: 7bit Cc: pim@ietf.org, John Zwiebel , "'Rahul Bahadur'" , Mathur Sonum-CSM109 From: John Zwiebel Date: Mon, 9 Feb 2004 13:37:22 -0800 To: Bill Nickless X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 09 Feb 2004 21:37:24.0107 (UTC) FILETIME=[E7C255B0:01C3EF54] Content-Transfer-Encoding: 7bit Subject: [pim] SSM at layer 2 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit Bill: I can not disagree with any of the points you make. > > SSM will not take off until applications can take advantage of it > without > requiring massive fork-lift upgrades of IEEE 802 edge/customer > networks or > adding much more IP routing smarts to their networks. Let me ask a stupid question... GARP? Would it make things happen faster? There are GARP switches out there, are there enough that if routers and hosts all took advantage of it that we could move to the SSM/Bidir without having to snoop IGMPv3? Or, can we just turn off all the snooping and layer2 filtering for multicast packets and have multicast packets sent to every port. I only ask these questions to transition to another question that we need to look at. We can't 'push' multicast on anyone. If they don't want it they won't take it. If they do want it, then its a question of how badly they want it and how much it costs to make that transition. In other words, if GARP or flooding aren't viable alternatives and a fork-lift upgrade is required, then if folks want it they will bite the bullet and they will upgrade. It will happen, it just may not happen as fast as we would like it to happen. Switches have -never- been very good at handling multicast. (If someone wants to spin off a separate discussion on this so I might learn something, I'd appreciate it.) They've always assumed that they could just broadcast it everywhere. And when you talk about a lynxsys, well, I don't care if its capable of doing IGMPv3 snooping or not as long as it passes the multicast packet to the receivers. I'm not trying to suggest that there is no need for CGMP/RGMP or snooping, I'm saying that customers have to make a choice. Do they want multicast or not? Allowing a dumb switch to be the barrier to realizing the full potential of multicast will cause the deployment to be delayed, but it isn't going to stop it completely. > This probably means re-engineering the mapping of IP packets to IEEE > 802 > frames, perhaps to the point of not trying to leverage the IEEE > multicast > facility to do IP multicast replication on the LAN. > I may not understand what you are suggesting, but I don't believe this is going to happen. It -sounds- to me like you are suggesting something which is similar to the way ATM implements multicast by opening a separate VC from the head-end to each tail end. Having watched that fail over and over again (well, it was never "good enough" for me -- I don't mean you weren't successful to a limited extent) I wouldn't go down that path again. > It also means automatic transition mechanisms (like the IPv6 community > is > having to build and deploy). It isn't clear to me what you mean here. 6to4 tunnels? AMAP is being proposed to provide a way of transition a multicast stream to a unicast stream and setting up this tunnel automatically. However, this is going to require application development and there are objections to how to deploy it also. (Not saying we shouldn't, but UDLR didn't go anywhere.) finally, there is IGMPv2 to v3 translation. The host joins just the group, but the router translates that join to a (S,G) and sends a pim join for that specific channel. Lots of problems here also. > And finally, it means applications taking responsibility for providing > whatever facilities are needed, even if that means carrying along > little > bits of code that we would wish were already in the underlying > operating > systems. > And obviously, that is what we need to do. For too long now, separate organizations have been waiting for the "other guys" to solve the problem. Certainly a lot of that is understandable since each group gets their part to work within their limited environment and no one has the global responsibility for making this all work. We can argue forever about whether we need content first or infrastructure first. The NANOG presentations I'm watching right now just said something about how the most efficient networking can be accomplished by making sure that the router was directly connected to the fiber without anything in the way. Folks are upgrading routers, perhaps they won't buy switches. My point in this discussion is to get folks to recognize that there is a problem, that if they want to solve the problem they need to look beyond the limited area over which they currently have control and recognize the problems that the other areas are having. ie, switches need to do -something- to deal with multicast as it is. GARP was their solution, but is it "good enough"? If it is, why isn't it being implemented in routers and hosts? I tried to outline the problem from a router perspective. Routers -can- do ASM and they do it well, but ASM is difficult to get right and because it is data-driven and -not- just control plane driven, it uses tons of resources on the router that could be used more efficiently for other functions. You have a choice in how you want to allocate that processing power. So the question for you is, what are we going to do about it? I want efficient and reliable distribution of multicast packets. For routers, that means dumping ASM and moving on to Bidir and SSM. Routers have already done ASM, and things aren't moving forward. Part of the problem is because of the nature of ASM. I'm beginning to repeat myself so I'll see ya later. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Tue Feb 17 03:35:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16763 for ; Tue, 17 Feb 2004 03:35:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At0h4-0005G7-0E; Tue, 17 Feb 2004 03:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At0gZ-0005Et-Py for pim@optimus.ietf.org; Tue, 17 Feb 2004 03:34:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16687 for ; Tue, 17 Feb 2004 03:34:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At0gX-0001sy-00 for pim@ietf.org; Tue, 17 Feb 2004 03:34:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At0fU-0001jM-00 for pim@ietf.org; Tue, 17 Feb 2004 03:33:24 -0500 Received: from cosmos.kaist.ac.kr ([192.249.24.2]) by ietf-mx with esmtp (Exim 4.12) id 1At0ef-0001br-00 for pim@ietf.org; Tue, 17 Feb 2004 03:32:33 -0500 Received: from cosmos.kaist.ac.kr (localhost.kaist.ac.kr [127.0.0.1]) by cosmos.kaist.ac.kr (8.12.2/8.9.3) with ESMTP id i1H8HwSD002999; Tue, 17 Feb 2004 17:17:58 +0900 (KST) Received: (from hkpark@localhost) by cosmos.kaist.ac.kr (8.12.2/8.12.2/Submit) id i1H8HwJv002998; Tue, 17 Feb 2004 17:17:58 +0900 (KST) (envelope-from hkpark) Message-ID: <20040217171758.G2599@cosmos.kaist.ac.kr> Date: Tue, 17 Feb 2004 17:17:58 +0900 From: Heonkyu Park To: pim@ietf.org Cc: Heonkyu Park Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i 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 Subject: [pim] unscribe this maillist Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , unscribe this maillist, thank you. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Tue Feb 17 03:37:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16955 for ; Tue, 17 Feb 2004 03:37:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At0j4-0005VP-5N for pim-archive@odin.ietf.org; Tue, 17 Feb 2004 03:37:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H8b6gJ021154 for pim-archive@odin.ietf.org; Tue, 17 Feb 2004 03:37:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At0j3-0005Uw-Bg for pim-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 03:37:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16912 for ; Tue, 17 Feb 2004 03:37:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At0j1-0002DC-00 for pim-web-archive@ietf.org; Tue, 17 Feb 2004 03:37:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At0i9-00027C-00 for pim-web-archive@ietf.org; Tue, 17 Feb 2004 03:36:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At0hC-0001zu-00 for pim-web-archive@ietf.org; Tue, 17 Feb 2004 03:35:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At0h4-0005G7-0E; Tue, 17 Feb 2004 03:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At0gZ-0005Et-Py for pim@optimus.ietf.org; Tue, 17 Feb 2004 03:34:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16687 for ; Tue, 17 Feb 2004 03:34:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At0gX-0001sy-00 for pim@ietf.org; Tue, 17 Feb 2004 03:34:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At0fU-0001jM-00 for pim@ietf.org; Tue, 17 Feb 2004 03:33:24 -0500 Received: from cosmos.kaist.ac.kr ([192.249.24.2]) by ietf-mx with esmtp (Exim 4.12) id 1At0ef-0001br-00 for pim@ietf.org; Tue, 17 Feb 2004 03:32:33 -0500 Received: from cosmos.kaist.ac.kr (localhost.kaist.ac.kr [127.0.0.1]) by cosmos.kaist.ac.kr (8.12.2/8.9.3) with ESMTP id i1H8HwSD002999; Tue, 17 Feb 2004 17:17:58 +0900 (KST) Received: (from hkpark@localhost) by cosmos.kaist.ac.kr (8.12.2/8.12.2/Submit) id i1H8HwJv002998; Tue, 17 Feb 2004 17:17:58 +0900 (KST) (envelope-from hkpark) Message-ID: <20040217171758.G2599@cosmos.kaist.ac.kr> Date: Tue, 17 Feb 2004 17:17:58 +0900 From: Heonkyu Park To: pim@ietf.org Cc: Heonkyu Park Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i Subject: [pim] unscribe this maillist Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 unscribe this maillist, thank you. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Wed Feb 18 10:05:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17047 for ; Wed, 18 Feb 2004 10:05:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTG1-0000eZ-33; Wed, 18 Feb 2004 10:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTF3-0008Me-Li for pim@optimus.ietf.org; Wed, 18 Feb 2004 10:04:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16698; Wed, 18 Feb 2004 10:03:57 -0500 (EST) Message-Id: <200402181503.KAA16698@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: pim@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 18 Feb 2004 10:03:57 -0500 Subject: [pim] I-D ACTION:draft-ietf-pim-sm-v2-new-09.txt,.ps Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , --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 - Sparse Mode PIM-SM): Protocol Specification (Revised) Author(s) : B. Fenner, M. Handley, H. Holbrook, I. Kouvelas Filename : draft-ietf-pim-sm-v2-new-09.txt,.ps Pages : 147 Date : 2004-2-18 This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sm-v2-new-09.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-sm-v2-new-09.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-2-18101820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-sm-v2-new-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-sm-v2-new-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18101820.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Wed Feb 18 10:11:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18084 for ; Wed, 18 Feb 2004 10:11:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTLe-0002eZ-N8 for pim-archive@odin.ietf.org; Wed, 18 Feb 2004 10:10:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IFAol2010191 for pim-archive@odin.ietf.org; Wed, 18 Feb 2004 10:10:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTLe-0002eF-G8 for pim-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 10:10:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18006 for ; Wed, 18 Feb 2004 10:10:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTLc-000732-00 for pim-web-archive@ietf.org; Wed, 18 Feb 2004 10:10:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTK7-0006rg-00 for pim-web-archive@ietf.org; Wed, 18 Feb 2004 10:09:16 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AtTJY-0006lO-00 for pim-web-archive@ietf.org; Wed, 18 Feb 2004 10:08:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AtTGi-0005Is-HT for pim-web-archive@ietf.org; Wed, 18 Feb 2004 10:05:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTG1-0000eZ-33; Wed, 18 Feb 2004 10:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTF3-0008Me-Li for pim@optimus.ietf.org; Wed, 18 Feb 2004 10:04:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16698; Wed, 18 Feb 2004 10:03:57 -0500 (EST) Message-Id: <200402181503.KAA16698@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: pim@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 18 Feb 2004 10:03:57 -0500 Subject: [pim] I-D ACTION:draft-ietf-pim-sm-v2-new-09.txt,.ps Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 - Sparse Mode PIM-SM): Protocol Specification (Revised) Author(s) : B. Fenner, M. Handley, H. Holbrook, I. Kouvelas Filename : draft-ietf-pim-sm-v2-new-09.txt,.ps Pages : 147 Date : 2004-2-18 This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sm-v2-new-09.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-sm-v2-new-09.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-2-18101820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-sm-v2-new-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-sm-v2-new-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18101820.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Mon Feb 23 17:26:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27596 for ; Mon, 23 Feb 2004 17:26:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOWX-0007ym-KN; Mon, 23 Feb 2004 17:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOWB-0007xt-Q4 for pim@optimus.ietf.org; Mon, 23 Feb 2004 17:25:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27461 for ; Mon, 23 Feb 2004 17:25:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvOW9-0004YZ-00 for pim@ietf.org; Mon, 23 Feb 2004 17:25:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvOVN-0004Ro-00 for pim@ietf.org; Mon, 23 Feb 2004 17:24:50 -0500 Received: from catarina.usc.edu ([204.57.0.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvOUJ-0004IT-00 for pim@ietf.org; Mon, 23 Feb 2004 17:23:43 -0500 Received: from hotmail.com (bay13-f97.bay13.hotmail.com [64.4.31.97]) by catarina.usc.edu (8.12.9/8.12.9) with ESMTP id i1NMND7J040610 for ; Mon, 23 Feb 2004 14:23:13 -0800 (PST) (envelope-from dsa0000@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 23 Feb 2004 14:23:08 -0800 Received: from 64.161.3.6 by by13fd.bay13.hotmail.msn.com with HTTP; Mon, 23 Feb 2004 22:23:08 GMT X-Originating-IP: [64.161.3.6] X-Originating-Email: [dsa0000@hotmail.com] X-Sender: dsa0000@hotmail.com From: "dsa main" To: pim@catarina.usc.edu Date: Mon, 23 Feb 2004 22:23:08 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Feb 2004 22:23:08.0796 (UTC) FILETIME=[9D8123C0:01C3FA5B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Subject: [pim] Doubt abt Assert Message Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Hi All, I have a doubt regarding Assert message sending. Assume a router became an "assert winner" on an interface and it starts sending assert messages. Later if the router dont see any "hello" messages on the interface whether it should stop sending assert messages ? Regards dsa _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Mon Feb 23 17:28:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27677 for ; Mon, 23 Feb 2004 17:28:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOY9-0008FU-AT for pim-archive@odin.ietf.org; Mon, 23 Feb 2004 17:27:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NMRf4E031702 for pim-archive@odin.ietf.org; Mon, 23 Feb 2004 17:27:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOY9-0008FF-3u for pim-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 17:27:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27658 for ; Mon, 23 Feb 2004 17:27:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvOY6-0004mc-00 for pim-web-archive@ietf.org; Mon, 23 Feb 2004 17:27:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvOXJ-0004hh-00 for pim-web-archive@ietf.org; Mon, 23 Feb 2004 17:26:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvOWu-0004bs-00 for pim-web-archive@ietf.org; Mon, 23 Feb 2004 17:26:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOWX-0007ym-KN; Mon, 23 Feb 2004 17:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOWB-0007xt-Q4 for pim@optimus.ietf.org; Mon, 23 Feb 2004 17:25:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27461 for ; Mon, 23 Feb 2004 17:25:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvOW9-0004YZ-00 for pim@ietf.org; Mon, 23 Feb 2004 17:25:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvOVN-0004Ro-00 for pim@ietf.org; Mon, 23 Feb 2004 17:24:50 -0500 Received: from catarina.usc.edu ([204.57.0.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvOUJ-0004IT-00 for pim@ietf.org; Mon, 23 Feb 2004 17:23:43 -0500 Received: from hotmail.com (bay13-f97.bay13.hotmail.com [64.4.31.97]) by catarina.usc.edu (8.12.9/8.12.9) with ESMTP id i1NMND7J040610 for ; Mon, 23 Feb 2004 14:23:13 -0800 (PST) (envelope-from dsa0000@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 23 Feb 2004 14:23:08 -0800 Received: from 64.161.3.6 by by13fd.bay13.hotmail.msn.com with HTTP; Mon, 23 Feb 2004 22:23:08 GMT X-Originating-IP: [64.161.3.6] X-Originating-Email: [dsa0000@hotmail.com] X-Sender: dsa0000@hotmail.com From: "dsa main" To: pim@catarina.usc.edu Date: Mon, 23 Feb 2004 22:23:08 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Feb 2004 22:23:08.0796 (UTC) FILETIME=[9D8123C0:01C3FA5B] Subject: [pim] Doubt abt Assert Message Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Hi All, I have a doubt regarding Assert message sending. Assume a router became an "assert winner" on an interface and it starts sending assert messages. Later if the router dont see any "hello" messages on the interface whether it should stop sending assert messages ? Regards dsa _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Mon Feb 23 18:11:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00230 for ; Mon, 23 Feb 2004 18:11:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvPE6-0006vL-Mc; Mon, 23 Feb 2004 18:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvPDc-0006nY-CF for pim@optimus.ietf.org; Mon, 23 Feb 2004 18:10:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00121 for ; Mon, 23 Feb 2004 18:10:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvPDZ-0000WG-00 for pim@ietf.org; Mon, 23 Feb 2004 18:10:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvPCe-0000SU-00 for pim@ietf.org; Mon, 23 Feb 2004 18:09:33 -0500 Received: from possum.icir.org ([192.150.187.67]) by ietf-mx with esmtp (Exim 4.12) id 1AvPCL-0000PQ-00 for pim@ietf.org; Mon, 23 Feb 2004 18:09:13 -0500 Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i1NN9B8N038801; Mon, 23 Feb 2004 15:09:11 -0800 (PST) (envelope-from pavlin@possum.icir.org) Message-Id: <200402232309.i1NN9B8N038801@possum.icir.org> To: "dsa main" cc: pim@ietf.org Subject: Re: [pim] Doubt abt Assert Message In-Reply-To: Message from "dsa main" of "Mon, 23 Feb 2004 22:23:08 GMT." Date: Mon, 23 Feb 2004 15:09:11 -0800 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , [Response redirected to the new pim@ietf.org address instead because the old address pim@catarina.usc.edu is not valid]. > Hi All, > > I have a doubt regarding Assert message sending. > > Assume a router became an "assert winner" on an interface and it starts > sending assert messages. Later if the router dont see any "hello" messages > on the interface whether it should stop sending > assert messages ? > > Regards > dsa The answer is that the Assert winner will keep transmitting Assert messages on an interface until the CouldAssert() macro is true, or until it becomes an Assert loser. Hence, it may look like that the Assert winner will keep transmitting Assert messages even if there are no neighbors on an interface. However, if there are no more Hello messages on an interface, all the neighbors will eventually timeout. As a result of this timeout the PIM join state on that interface will timeout as well, and eventually CouldAssert() for that interface will become false. Indeed, if you look closely into the CouldAssert() definition you can notice that if there are receivers on the LAN for that interface, then CouldAssert() would still be true so the router will keep transmitting the Assert messages even if there are no PIM neighbors. Whether it is worth optimizing this corner case, I don't know. But such optimization will make the Assert state machine look even more complicated. A strawman solution could be "If I am in Assert Winner state and if Assert Timer Expires and if there are no more PIM neighbors, then the assert state-machine should transitinto NoInfo state". Such optimization could be left to the implementation itself. Pavlin _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Mon Feb 23 18:13:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00550 for ; Mon, 23 Feb 2004 18:13:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvPFx-0007h4-8P for pim-archive@odin.ietf.org; Mon, 23 Feb 2004 18:12:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NNCvep029565 for pim-archive@odin.ietf.org; Mon, 23 Feb 2004 18:12:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvPFw-0007gZ-P2 for pim-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 18:12:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00489 for ; Mon, 23 Feb 2004 18:12:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvPFu-0000ox-00 for pim-web-archive@ietf.org; Mon, 23 Feb 2004 18:12:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvPF9-0000hl-00 for pim-web-archive@ietf.org; Mon, 23 Feb 2004 18:12:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvPED-0000Zd-00 for pim-web-archive@ietf.org; Mon, 23 Feb 2004 18:11:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvPE6-0006vL-Mc; Mon, 23 Feb 2004 18:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvPDc-0006nY-CF for pim@optimus.ietf.org; Mon, 23 Feb 2004 18:10:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00121 for ; Mon, 23 Feb 2004 18:10:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvPDZ-0000WG-00 for pim@ietf.org; Mon, 23 Feb 2004 18:10:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvPCe-0000SU-00 for pim@ietf.org; Mon, 23 Feb 2004 18:09:33 -0500 Received: from possum.icir.org ([192.150.187.67]) by ietf-mx with esmtp (Exim 4.12) id 1AvPCL-0000PQ-00 for pim@ietf.org; Mon, 23 Feb 2004 18:09:13 -0500 Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i1NN9B8N038801; Mon, 23 Feb 2004 15:09:11 -0800 (PST) (envelope-from pavlin@possum.icir.org) Message-Id: <200402232309.i1NN9B8N038801@possum.icir.org> To: "dsa main" cc: pim@ietf.org Subject: Re: [pim] Doubt abt Assert Message In-Reply-To: Message from "dsa main" of "Mon, 23 Feb 2004 22:23:08 GMT." Date: Mon, 23 Feb 2004 15:09:11 -0800 From: Pavlin Radoslavov Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 [Response redirected to the new pim@ietf.org address instead because the old address pim@catarina.usc.edu is not valid]. > Hi All, > > I have a doubt regarding Assert message sending. > > Assume a router became an "assert winner" on an interface and it starts > sending assert messages. Later if the router dont see any "hello" messages > on the interface whether it should stop sending > assert messages ? > > Regards > dsa The answer is that the Assert winner will keep transmitting Assert messages on an interface until the CouldAssert() macro is true, or until it becomes an Assert loser. Hence, it may look like that the Assert winner will keep transmitting Assert messages even if there are no neighbors on an interface. However, if there are no more Hello messages on an interface, all the neighbors will eventually timeout. As a result of this timeout the PIM join state on that interface will timeout as well, and eventually CouldAssert() for that interface will become false. Indeed, if you look closely into the CouldAssert() definition you can notice that if there are receivers on the LAN for that interface, then CouldAssert() would still be true so the router will keep transmitting the Assert messages even if there are no PIM neighbors. Whether it is worth optimizing this corner case, I don't know. But such optimization will make the Assert state machine look even more complicated. A strawman solution could be "If I am in Assert Winner state and if Assert Timer Expires and if there are no more PIM neighbors, then the assert state-machine should transitinto NoInfo state". Such optimization could be left to the implementation itself. Pavlin _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim