From owner-idmr@cs.ucl.ac.uk  Wed May  3 04:54:28 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27655
	for <idmr-archive@lists.ietf.org>; Wed, 3 May 2000 04:54:27 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.12220-0@pan2.cs.ucl.ac.uk>;
          Wed, 3 May 2000 06:46:11 +0100
Received: from haig.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.12214-0@pan2.cs.ucl.ac.uk>; Wed, 3 May 2000 06:46:08 +0100
Received: from 208.178.29.198 by haig.cs.ucl.ac.uk with Internet SMTP 
          id <g.10275-0@haig.cs.ucl.ac.uk>; Wed, 3 May 2000 06:46:50 +0100
Received: from c1web02 (208.178.29.202) 
          by c1mailgw2.prontomail.com (NPlex 4.5.049) id 3908EB2800061C50 
          for idmr@cs.ucl.ac.uk; Tue, 2 May 2000 22:46:00 -0700
X-Version: indya 6.2.3 .2329.0
From: vijayc@indya.com
Message-Id: <B65491A238024D1178E30005B8E28024@vijayc.indya.com>
Date: Wed, 3 May 2000 11:26:17 +0530
X-Priority: Normal
Content-Type: text/plain; charset=iso-8859-1
To: idmr@cs.ucl.ac.uk
Subject: DVMRP:Prune retransmissions
X-Mailer: Web Based Pronto
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,
 I have a question regarding prune retransmission as stated in section 3.5.5. of dvmrp v3 draft 
(draft-ietf-idmr-dvmrp-v3-09.txt) dated September 1999.

As stated in the above document(section 3.5.5 para 3), on multiaccess networks, even if a 
prune is received by the upstream router, data may still be received due to other receivers on 
the network. Due to this there will be unnecessary retransmissions of the prune message. 
Can't this be avoided by having an ackowledgment for the prune(just like for the graft) on 
multiaccess network interfaces alone. If after the prune ack is received the downstream still 
receives multicast dgrams it can ignore them instead of retransmitting the prune.

This will also eliminate the need for maintaing the list of neighbors addresses on the 
downstream interfaces of the forwarding cache on the upstream router. Currently the above 
information might be needed to validate if the prune is from a downstream dependent DVMRP 
router. If prune is not retransmitted this validation can be simplified to just checking if the 
prune is from a downstream interface of the forwarding cache.

Regards,
Vijay


Enter your default signature here
Sent by Indya Messaging Service


From owner-idmr@cs.ucl.ac.uk  Wed May  3 14:23:50 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08367
	for <idmr-archive@lists.ietf.org>; Wed, 3 May 2000 14:23:49 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.12400-0@pan2.cs.ucl.ac.uk>;
          Wed, 3 May 2000 16:46:11 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.12394-0@pan2.cs.ucl.ac.uk>; Wed, 3 May 2000 16:46:08 +0100
Received: from 199.105.223.130 by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.16588-0@bells.cs.ucl.ac.uk>; Wed, 3 May 2000 16:46:46 +0100
Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21) 
          id <J2B23JLC>; Wed, 3 May 2000 11:49:10 -0400
Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C54B8AF@uniwest1.redstonecom.com>
From: "Shekhar, Ravi" <RShekhar@unispheresolutions.com>
To: vijayc@indya.com, idmr@cs.ucl.ac.uk
Subject: RE: DVMRP:Prune retransmissions
Date: Wed, 3 May 2000 11:49:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk

Vijay,

> This will also eliminate the need for maintaing the list of 
> neighbors addresses on the 
> downstream interfaces of the forwarding cache on the upstream 

  Its not required to maintain the list of downstream dependent nbrs
  on each forwarding cache entry even now. It can be obtained from the 
  the corresponding DVMRP unicast routing table entry (i.e. the route entry
  which matches the source of data).

> router. If prune is not retransmitted this validation can be 
> simplified to just checking if the 
> prune is from a downstream interface of the forwarding cache.

  I doubt that. You would still need to maintain the list of downstream
  nbrs who have pruned just to know if all the downstream nbrs on an
  interface have pruned or not before you can remove that downstream
  intf from the forwarding cache.

  - Ravi Shekhar.



From owner-idmr@cs.ucl.ac.uk  Wed May  3 14:23:57 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08382
	for <idmr-archive@lists.ietf.org>; Wed, 3 May 2000 14:23:55 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.12421-0@pan2.cs.ucl.ac.uk>;
          Wed, 3 May 2000 16:57:17 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.12415-0@pan2.cs.ucl.ac.uk>; Wed, 3 May 2000 16:57:13 +0100
Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk 
          with Internet SMTP id <g.17465-0@bells.cs.ucl.ac.uk>;
          Wed, 3 May 2000 16:57:47 +0100
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) 
          by mail-green.research.att.com (Postfix) with ESMTP id F142D1E01D;
          Wed, 3 May 2000 11:57:44 -0400 (EDT)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) 
          by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA16804;
          Wed, 3 May 2000 11:57:44 -0400 (EDT)
From: Bill Fenner <fenner@research.att.com>
Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) 
          id IAA01081; Wed, 3 May 2000 08:56:30 -0700 (PDT)
Message-Id: <200005031556.IAA01081@windsor.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: vijayc@indya.com
Subject: Re: DVMRP:Prune retransmissions
Cc: idmr@cs.ucl.ac.uk
Date: Wed, 3 May 2000 08:56:29 -0700
Versions: dmail (solaris) 2.2g/makemail 2.9a
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk


>As stated in the above document(section 3.5.5 para 3), on multiaccess
>networks, even if a prune is received by the upstream router, data
>may still be received due to other receivers on the network. Due to
>this there will be unnecessary retransmissions of the prune message.
>Can't this be avoided by having an ackowledgment for the prune(just
>like for the graft) on multiaccess network interfaces alone. If after
>the prune ack is received the downstream still receives multicast dgrams
>it can ignore them instead of retransmitting the prune.

However, due to the exponential backoff, there will be 11 retransmissions
of the prune.  Implementations that retransmit prunes can get benefit
from retransmitting prunes by themselves; implementations that require
prune-acks would need both routers to be upgraded before seeing any use.
The advantage of incremental deployment far outweighs the cost of 11
packets over 2 hours.

>This will also eliminate the need for maintaing the list of neighbors
>addresses on the downstream interfaces of the forwarding cache on the
>upstream router.  Currently the above information might be needed to
>validate if the prune is from a downstream dependent DVMRP router. If
>prune is not retransmitted this validation can be simplified to just
>checking if the prune is from a downstream interface of the forwarding
>cache.

How would the router know when to stop forwarding?  You can't stop
forwarding on the first prune that you ACK; if there are e.g. 5
downstream dependent neighbors you need to get prunes from each one.
However, you're advocating not tracking from whom prunes have been
received, so can you ever tell when you've gotten prunes from all 5?
(What about getting 5 prunes from one misbehaving neighbor?)

  Bill


From owner-idmr@cs.ucl.ac.uk  Thu May  4 03:34:16 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00574
	for <idmr-archive@lists.ietf.org>; Thu, 4 May 2000 03:34:16 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.13198-0@pan2.cs.ucl.ac.uk>;
          Thu, 4 May 2000 06:21:41 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.13192-0@pan2.cs.ucl.ac.uk>; Thu, 4 May 2000 06:21:37 +0100
Received: from c1mailgw1.prontomail.com by bells.cs.ucl.ac.uk 
          with Internet SMTP id <g.23353-0@bells.cs.ucl.ac.uk>;
          Thu, 4 May 2000 06:22:10 +0100
Received: from c1web02 (208.178.29.202) 
          by c1mailgw1.prontomail.com (NPlex 4.5.049) id 39089AB30007C859;
          Wed, 3 May 2000 22:22:04 -0700
X-Version: indya 6.2.3 .2329.0
From: vijayc@indya.com
Message-Id: <6B5BD78375124D1178E30005B8E28024@vijayc.indya.com>
Date: Thu, 4 May 2000 11:02:05 +0530
X-Priority: Normal
Content-Type: text/plain; charset=iso-8859-1
To: fenner@research.att.com
Subject: Re: Re: DVMRP:Prune retransmissions
CC: idmr@cs.ucl.ac.uk
X-Mailer: Web Based Pronto
Mime-Version: 1.0
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA00574


How would the router know when to stop forwarding?  You can't stop
forwarding on the first prune that you ACK; if there are e.g. 5
downstream dependent neighbors you need to get prunes from each one.
However, you're advocating not tracking from whom prunes have been
received, so can you ever tell when you've gotten prunes from all 5?
(What about getting 5 prunes from one misbehaving neighbor?)

Iam not considering  misbehaving routers, for that matter a misbehaving upstream router may 
jeoparadise downstream multicast traffic. I am just asking if it would be possible to simplify 
the information maintained by the protocol data structures and thus speed up the operation. 

Regards,
Vijay


Enter your default signature here
Sent by Indya Messaging Service


From owner-idmr@cs.ucl.ac.uk  Thu May  4 03:34:21 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00587
	for <idmr-archive@lists.ietf.org>; Thu, 4 May 2000 03:34:21 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.13179-0@pan2.cs.ucl.ac.uk>;
          Thu, 4 May 2000 06:20:33 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.13173-0@pan2.cs.ucl.ac.uk>; Thu, 4 May 2000 06:20:29 +0100
Received: from c1mailgw3.prontomail.com by bells.cs.ucl.ac.uk 
          with Internet SMTP id <g.23285-0@bells.cs.ucl.ac.uk>;
          Thu, 4 May 2000 06:21:12 +0100
Received: from c1web02 (208.178.29.202) 
          by c1mailgw3.prontomail.com (NPlex 4.5.049) id 3908C5120007B72F;
          Wed, 3 May 2000 22:20:59 -0700
X-Version: indya 6.2.3 .2329.0
From: vijayc@indya.com
Message-Id: <FA5BD78375124D1178E30005B8E28024@vijayc.indya.com>
Date: Thu, 4 May 2000 11:00:26 +0530
X-Priority: Normal
Content-Type: text/plain; charset=iso-8859-1
To: fenner@research.att.com
Subject: Re: Re: DVMRP:Prune retransmissions
CC: idmr@cs.ucl.ac.uk
X-Mailer: Web Based Pronto
Mime-Version: 1.0
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA00587


How would the router know when to stop forwarding?  You can't stop
forwarding on the first prune that you ACK; if there are e.g. 5
downstream dependent neighbors you need to get prunes from each one.
However, you're advocating not tracking from whom prunes have been
received, so can you ever tell when you've gotten prunes from all 5?
(What about getting 5 prunes from one misbehaving neighbor?)

Iam not considering  misbehaving routers, for that matter a misbehaving upstream router may 
totally jeoparadise multicast traffic. I am just asking if it would be possible to simplify the 
information maintained by the protocol data structures and thus speed up the operation. 

Regards,
Vijay


Enter your default signature here
Sent by Indya Messaging Service


From owner-idmr@cs.ucl.ac.uk  Thu May  4 12:25:10 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10131
	for <idmr-archive@lists.ietf.org>; Thu, 4 May 2000 12:25:08 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.13781-0@pan2.cs.ucl.ac.uk>;
          Thu, 4 May 2000 14:32:09 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.13775-0@pan2.cs.ucl.ac.uk>; Thu, 4 May 2000 14:32:05 +0100
Received: from prima.time.saic.com by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.28480-0@bells.cs.ucl.ac.uk>; Thu, 4 May 2000 14:32:47 +0100
Received: from degas.time.saic.com (degas.time.saic.com [205.153.241.32]) 
          by prima.time.saic.com (8.9.3/8.8.5) with ESMTP id JAA16904;
          Thu, 4 May 2000 09:32:56 -0400 (EDT)
Message-Id: <200005041332.JAA16904@prima.time.saic.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: vijayc@indya.com
cc: idmr@cs.ucl.ac.uk
Subject: Re: DVMRP:Prune retransmissions
In-Reply-To: Your message of "Thu, 04 May 2000 11:00:26 +0530." <FA5BD78375124D1178E30005B8E28024@vijayc.indya.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 04 May 2000 09:27:33 -0400
From: Ken Carlberg <carlberg@time.saic.com>
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk

Hello Vijay,

> I am just asking if it would be possible to simplify the information
> maintained by the protocol data structures and thus speed up the 
> operation. 

Could you provide some specifics?  How slow is your implementation
versus Bill's mrouted release (for that matter, what is the per-packet
forwarding speed of mrouted)?  

By discussing hypotheticals, the thread may go around and round in
circles.  It may be easier if you could provide a specific design
and quantifiable info (eg, amount of less state per <s,g>, reduced
number of control packets?,...) regarding changes you'd like to see.

Then it would be helpful to know how these changes work with the
installed base of DVMRP, or is it meant to be yet another interior
multicast routing protocol?

regards,

-ken





From owner-idmr@cs.ucl.ac.uk  Thu May  4 12:25:17 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10151
	for <idmr-archive@lists.ietf.org>; Thu, 4 May 2000 12:25:16 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.14111-0@pan2.cs.ucl.ac.uk>;
          Thu, 4 May 2000 16:54:53 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.14104-0@pan2.cs.ucl.ac.uk>; Thu, 4 May 2000 16:54:46 +0100
Received: from web.potato.ne.jp by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.11796-0@bells.cs.ucl.ac.uk>; Thu, 4 May 2000 16:55:18 +0100
Received: from (194.25.64.012]) [172.144.93.51] 
          by web.potato.ne.jp (SMTPD32-4.03a) id AF6911B50150;
          Fri, 05 May 2000 00:59:37 +0900
Message-ID: <0000481e6ab2$00002cd3$00000f8b@([193.25.48.54])>
To: Undisclosed <"Undisclosed Recipients"@cs.ucl.ac.uk>
From: zone11@bigfoot.com
Subject: The Contrarian - BUY ALERT,
Date: Tue, 02 May 2000 13:40:57 -0400
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: post10@21cn.com
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk

THE CONTRARIAN           
                                                        
BUY ALERT: 

RecycleNet Corp.
Symbol - GARM (OTCBB-pink sheets)      
Recent Price - $.35
52 Week Range - $.12 - .75
Estimated Float - 4 Million
Shares Outstanding - 78 Million
   
Now that Microsoft and other Internet stocks have fallen, it's time to 
sift through the wreckage and look for treasure. As Contrarian investors, 
we've been waiting for this dynamic group to fall out of favor temporarily, 
so we can buy at discounted prices.

The following stock should be purchased for long-term capital gains:
RecycleNet Corporation is hardly a new player in the dot.com game - 
they went electronic in May 1995, after many years in a print format.  
Their founder and current Chairman, Paul Roszel, has been in the 
recycling business for over 20 years, and has vast experience with 
every type of scrap commodity. 

Recyclenet is part of the booming "B2B" business to business portion 
of the Internet. It is estimated that B2B electronic commerce will soar 
from $17 Billion in sales in 1998 to $327 Billion by 2002. Electronic 
commerce gives GARM the ability to trade with other companies all over 
the world, at very low cost. They earn money from subscribers who pay 
a monthly fee to join their Recycler's Exchange.   

What is the reason to buy now? RecycleNet should be reporting excellent 
revenues and earnings in the next quarter, the floating supply of shares is 
small, and the financial community is just starting to discover GARM. They 
have filed their Form 10 to become a reporting company with the SEC, and 
they should be emerging from their pink sheet listing soon.
   
Meanwhile, traffic at their web site is hitting record numbers (almost 2 Million 
page views per month), and is growing at over 20% monthly. With the stock 
trading at half of its February peak, The Contrarian believes that GARM can 
reach the $1.50 level near-term, with even higher prices further out. Take a 
position now while RecycleNet is on the bargain shelf. 

Disclaimer: The Contrarian has no affiliation with the issuer, and has received 
no fee from RecycleNet for this report. The Contrarian and/or its affiliates currently 
own shares of RecycleNet, and may buy or sell shares at any time after the 
dissemination of this report.  Because the publisher owns this stock, there may 
be a conflict of interest in the Contrarian's statements and opinions. The Contrarian 
is not a registered investment advisor, broker or dealer. Purchase of this stock 
may be considered speculative, and may result in the loss of some or all of any 
investment made. 

To SUBSCRIBE to future announcements or request ADDTIONAL INFORMATION 
regarding the RecycleNet opportunity, please click on the appropriate link below 
and hit send.

mailto:stocks35@us.sina.com?subject=Subscribe

mailto:stocks35@us.sina.com?subject=Additional-Information


******************************************
If you wish to be deleted from inclusion 
any future mailing, please click on the 
link below and hit send.
******************************************

mailto:stocks35@us.sina.com?subject=delete 














THE CONTRARIAN           
                                                        
BUY ALERT: 

RecycleNet Corp.
Symbol - GARM (OTCBB-pink sheets)      
Recent Price - $.35
52 Week Range - $.12 - .75





From owner-idmr@cs.ucl.ac.uk  Thu May  4 12:25:27 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10162
	for <idmr-archive@lists.ietf.org>; Thu, 4 May 2000 12:25:23 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.13908-0@pan2.cs.ucl.ac.uk>;
          Thu, 4 May 2000 16:11:48 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.13901-0@pan2.cs.ucl.ac.uk>; Thu, 4 May 2000 16:11:44 +0100
Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk 
          with Internet SMTP id <g.07956-0@bells.cs.ucl.ac.uk>;
          Thu, 4 May 2000 16:12:23 +0100
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) 
          by mail-green.research.att.com (Postfix) with ESMTP id 826271E080;
          Thu, 4 May 2000 11:12:21 -0400 (EDT)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) 
          by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA16234;
          Thu, 4 May 2000 11:12:21 -0400 (EDT)
From: Bill Fenner <fenner@research.att.com>
Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) 
          id IAA11294; Thu, 4 May 2000 08:11:05 -0700 (PDT)
Message-Id: <200005041511.IAA11294@windsor.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: vijayc@indya.com
Subject: Re: Re: DVMRP:Prune retransmissions
Cc: idmr@cs.ucl.ac.uk
Date: Thu, 4 May 2000 08:11:04 -0700
Versions: dmail (solaris) 2.2g/makemail 2.9a
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk


>Iam not considering  misbehaving routers, for that matter a misbehaving
>upstream router may jeoparadise downstream multicast traffic.

However, if you can protect against certain types of misbehaving routers,
so much the better.

>I am just
>asking if it would be possible to simplify the information maintained
>by the protocol data structures and thus speed up the operation.

I still think that the upstream doesn't know when to stop forwarding
if it doesn't keep track, even if all downstreams are well-behaved.

  Bill


From owner-idmr@cs.ucl.ac.uk  Thu May  4 12:28:32 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10226
	for <idmr-archive@lists.ietf.org>; Thu, 4 May 2000 12:28:31 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.14037-0@pan2.cs.ucl.ac.uk>;
          Thu, 4 May 2000 16:40:07 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.14031-0@pan2.cs.ucl.ac.uk>; Thu, 4 May 2000 16:40:03 +0100
Received: from 199.105.223.130 by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.10639-0@bells.cs.ucl.ac.uk>; Thu, 4 May 2000 16:40:42 +0100
Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21) 
          id <J2B23NG0>; Thu, 4 May 2000 11:43:09 -0400
Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C67E7A6@uniwest1.redstonecom.com>
From: "Shekhar, Ravi" <RShekhar@unispheresolutions.com>
To: vijayc@indya.com, fenner@research.att.com
Cc: idmr@cs.ucl.ac.uk
Subject: RE: Re: DVMRP:Prune retransmissions
Date: Thu, 4 May 2000 11:43:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA10226



> 
> How would the router know when to stop forwarding?  You can't stop
> forwarding on the first prune that you ACK; if there are e.g. 5
> downstream dependent neighbors you need to get prunes from each one.
> However, you're advocating not tracking from whom prunes have been
> received, so can you ever tell when you've gotten prunes from all 5?
> (What about getting 5 prunes from one misbehaving neighbor?)
> 
> Iam not considering  misbehaving routers, for that matter a 
> misbehaving upstream router may 
> totally jeoparadise multicast traffic. I am just asking if it 
> would be possible to simplify the 
> information maintained by the protocol data structures and 
> thus speed up the operation. 


  Actually it appears to me that downstream dependent routers do not
necessarily
  have to be mis-behaving for this to not work. A prune-ACK could get lost
or received 
  after some delay at the downstream nbr and as a result it might have to
retransmit its 
  prune. If the upstream router is merely counting number of prunes (without
keeping 
  any state to identify from which nbr it has arrived), it will count both
these prunes 
  from the same nbr and as a result will have wrong information. 

  - Ravi Shekhar. 


From owner-idmr@cs.ucl.ac.uk  Mon May  8 19:00:51 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22102
	for <idmr-archive@lists.ietf.org>; Mon, 8 May 2000 19:00:50 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.16270-0@pan2.cs.ucl.ac.uk>;
          Mon, 8 May 2000 20:31:01 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.16264-0@pan2.cs.ucl.ac.uk>; Mon, 8 May 2000 20:30:57 +0100
Received: from gatemp.attlabs.att.com by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.12223-0@bells.cs.ucl.ac.uk>; Mon, 8 May 2000 20:31:26 +0100
Received: (from fenner@localhost) by nectar.attlabs.att.com (8.9.3/8.9.2) 
          id MAA01606 for idmr@cs.ucl.ac.uk;
          Mon, 8 May 2000 12:33:57 -0700 (PDT) (envelope-from fenner)
Date: Mon, 8 May 2000 12:33:57 -0700 (PDT)
From: Bill Fenner <fenner@research.att.com>
Message-Id: <200005081933.MAA01606@nectar.attlabs.att.com>
To: idmr@cs.ucl.ac.uk
Subject: IDMR meeting minutes
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk

The presentations are available online at
http://www.aciri.org/fenner/idmr/200003/

IDMR met in one session at the Adelaide IETF.  These minutes were
collected by Bill Fenner.

Bill Fenner spoke on IDMR document status.  The DVMRPv3 spec needs
an update for GenID per interface (and perhaps some others), and
DVMRPv3 needs an applicability statement.  The DVMRP MIB is ready
but is blocked on the spec.  Multicast Traceroute had a recent
update (presented later) and was going to be put to WG Last Call
except for a suggestion of an appendix on the heuristics that the
mtrace client currently uses to get good data from buggy sources.
The Multicast Router Discovery spec has expired and needs to be
updated.  IGMPv2 needs to be updated based on Erik Nordmark's MLD
spec comments in order to go to Draft Standard.  IGMPv3 was recently
updated (presented later) and a little more needs to be done.  The
IGMPv3 API spec is brand new and needs comments from the WG.

The Domain Wide Report and IGMP Proxying specs are in "working
group chair limbo" -- they both passed their WG Last Calls but the
chair never submitted them to the IESG.  The PIM, IPMROUTE and IGMP
MIBs are in the IESG black hole; Rob Coltun said something about
MIB compiler flags that I didn't understand but we decided to take
it offline.


Bill Fenner continued on the multicast traceroute document update.
These details are available both in the updated document and in
the slides; please refer to one or the other to find out what's
changed.  The document will be updated again to include known
implementation problems and workarounds in an appendix, and then
be submitted for Working Group Last Call.


Isidor Kouvelas then gave an update on the IGMPv3 spec.  Refer to
the slides for the details of the changes.  The comment was made
that the document says that reserved bits MUST be 0 when receiving;
this precludes certain types of forward compatibility so should be
changed.


Dave Thaler presented the new Multicast Source Filtering API; this
is a concrete API for both group membership and source filtering
in IPv4 (i.e. IGMPv1,v2 and v3) and IPv6 (i.e. MLD and ??).  The
original specification of the advanced API used a setsockopt() to
set the filter, and ioctl() to get the filter.  Dave made the
proposal to change them both to ioctl() for symmetry, and the WG
had no objections.

Dave Thaler then talked about treating IPv6 in the existing multicast
MIBs.  His plan is to submit protocol-independent IPMROUTE and PIM
MIBs; these will be useful for both IPv4 and IPv6.  IGMP and MLD
are similar but not the same protocol, so it doesn't necessarily
make sense to have a single MIB for IGMP (IPv4) and MLD (IPv6).


Hugh Holbrook then talked about IGMP and Source-Specific Multicast.
This is Appendix I of draft-holbrook-ssm-00.txt .  No changes to
host IP stacks are required; a normal IGMPv3 host stack can handle
the requirements of source-specific multicast.  Source-Specific
applications are required to only use the IGMPv3 API to join
source-specific sessions; if a host stack sends a 'join group'
(e.g. IGMPv2 membership or IGMPv3 exclude-none), it will simply be
ignored.

IGMP-speaking routers doing source-specific multicast are configured
with the group range (currently 232/8 but could change in the
future) that is to be used for source-specific sessions.  These
routers only pay attention to IGMPv3 'include'-style requests for
these groups; any request to join the entire group is ignored.

There was some discussion about whether or not it makes sense to
restrict the range in this way; the current IANA assignment says
that behavior is undefined if you join the whole group (e.g. a
router could do Internet Standard Multicast).  The assertion was
made that one of the reasons content providers want Source-Specific
multicast is to prevent reception of other sources, thus Internet
Standard Multicast is unacceptable.  No consensus was reached in
this discussion.


From owner-idmr@cs.ucl.ac.uk  Tue May  9 15:55:05 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29427
	for <idmr-archive@lists.ietf.org>; Tue, 9 May 2000 15:55:05 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.17040-0@pan2.cs.ucl.ac.uk>;
          Tue, 9 May 2000 18:37:19 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.17031-0@pan2.cs.ucl.ac.uk>; Tue, 9 May 2000 18:37:13 +0100
Received: from 194.75.152.224 by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.11701-0@bells.cs.ucl.ac.uk>; Tue, 9 May 2000 18:37:56 +0100
Received: from ukd ([195.171.177.9]) by scooby.lineone.net (8.9.3/8.9.3) 
          with SMTP id QAA21977; Tue, 9 May 2000 16:27:42 +0100 (BST)
Message-ID: <013c01bfb9cc$8f482480$09b1abc3@ukd>
From: "Charlie Fletcher - www.ukdata.com" <charlie@ukdata.com>
To: Finance Director <webmaster@ukdata.com>
Subject: Instant On-Line Credit Reports
Date: Tue, 9 May 2000 16:34:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk
Content-Transfer-Encoding: 7bit

Do you need fast accurate information to assist you when appraising
potential customers, and suppliers?

The UK Data internet website www.ukdata.com contains 28 million pages of
data with full information on every UK company!

Credit Reports-Director Searches-Accounts-Annual Returns

All of these products and many more are available to you immediately, and
can be downloaded to and printed from your personal computer.

Free samples of all reports are available at www.ukdata.com.

Please also visit www.formacompany.co.uk the on-line company formation
website

Thank You

Charles Fletcher
www.ukdata.com an instant report on every UK business
www.formacompany.co.uk the on-line company formation site
www.irishdata.ie - instant reports on all Irish companies













From owner-idmr@cs.ucl.ac.uk  Wed May 10 06:09:03 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21349
	for <idmr-archive@lists.ietf.org>; Wed, 10 May 2000 06:09:03 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.17226-0@pan2.cs.ucl.ac.uk>;
          Wed, 10 May 2000 08:19:23 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.17220-0@pan2.cs.ucl.ac.uk>; Wed, 10 May 2000 08:19:19 +0100
Received: from 208.178.29.198 by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.03147-0@bells.cs.ucl.ac.uk>; Wed, 10 May 2000 08:20:03 +0100
Received: from c1web02 (208.178.29.202) 
          by c1mailgw2.prontomail.com (NPlex 4.5.049) id 3908EB28000F8580 
          for idmr@cs.ucl.ac.uk; Wed, 10 May 2000 00:20:05 -0700
X-Version: indya 6.2.3 .2329.0
From: vijayc@indya.com
Message-Id: <FC2BFF0721624D1178E30005B8E28024@vijayc.indya.com>
Date: Wed, 10 May 2000 13:00:42 +0530
X-Priority: Normal
Content-Type: text/plain; charset=iso-8859-1
To: idmr@cs.ucl.ac.uk
Subject: Tries
X-Mailer: Web Based Pronto
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,
 Where can I find source-code library for ' Dynamic prefix tries ' which is used for address 
look-up based on longest prefix match?

Regards,
Vijay


Enter your default signature here
Sent by Indya Messaging Service


From owner-idmr@cs.ucl.ac.uk  Sat May 13 02:20:27 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05951
	for <idmr-archive@lists.ietf.org>; Sat, 13 May 2000 02:20:26 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.17908-0@pan2.cs.ucl.ac.uk>;
          Sat, 13 May 2000 04:13:36 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.17897-0@pan2.cs.ucl.ac.uk>; Sat, 13 May 2000 04:13:28 +0100
Received: from 209-164-194-211.iglobal.net by bells.cs.ucl.ac.uk 
          with Internet SMTP id <g.08216-0@bells.cs.ucl.ac.uk>;
          Sat, 13 May 2000 04:13:58 +0100
From: nrge2 <nrge2@www.IP-Email.com>
Subject: ADV: NuElectric Stock Profile
Date: Fri, 12 May 2000 18:37:26
Message-Id: <188.352879.266721@www.IP-Email.com>
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk
Apparently-To: idmr-pp

Stock Research 2000 May Profile

If you no longer wish to receive our Free Newsletter please
visit http://notify.aucom.com/remove.html

NuElectric Corporation - Trading Symbol OTCBB: NRGE
Shares Outstanding:    4.1 Mil
Est. Shares in Float:  500 K
Long Term Debt:        None
Recent Stock Price:    $1 1/2
52 Week Price Range:   $3/8 - 2 3/4

For more information, please visit http://notify.aucom.com

**** News Flash ****

NuElectric to Acquire Zorax Inc.

Johns Hopkins University Technology Extracts Cryptosporidium and Giardia from 
Drinking Water.

May 3, 2000--NuElectric Corp. (OTC BB:NRGE), an incubator for new technologies 
that conserve energy and protect the environment Wednesday announced that the 
company has signed a letter of intent to acquire Zorax Inc. and the exclusive 
worldwide license to manufacture and market a proprietary process technology that 
improves the extraction of Cryptosporidium and Giardia from drinking water.

Under terms of the agreement, NuElectric will acquire 100 percent of the issued 
and outstanding stock of Zorax in exchange for 1 million shares of NuElectric. 
Johns Hopkins University will also receive shares of NuElectric stock as part of 
the above transaction. A definitive merger agreement is scheduled to be signed by 
July 31, 2000, pending corporate review and approval. 

********************

Did you know that the EPA is about to dramatically lower the arsenic count in 
water? You may say, "well how in the world does this apply to me?" Well it does.  
Almost everything that you deal with has some link to water in some way shape or 
form. Refining water will become more expensive and the products that you buy that 
depend on water will become more costly. Imagine a company that will be able to 
remove the necessary amounts of arsenic at a fraction of the cost that other 
companies charge.

NuElectric is a company that will do just that. A lady by the name of Dagmar 
Bonnin, developed an innovative, versatile, and less expensive process while 
working as a professor at the University of South Florida. Her technology will 
easily reduce the contamination to a much lower level specified by the government, 
thereby helping to maintain safe water supplies at an affordable price.

Trace quantities of arsenic occur naturally in surface and groundwater supplies in 
many areas of the country; particularly in the Midwest. But that's not the major 
problem. Arsenic has many industrial uses, such as hardening of copper and lead 
alloys, pigmentation in paints and fireworks, and the manufacture of glass, cloth, 
and electrical semiconductors. In the past, it was also used in the production of 
agricultural pesticides including herbicides and insecticides, and in desiccants, 
wood preservatives, and feed additives. The runoff from these uses as well as the 
leaching of arsenic from waste generated by them has caused increased levels of 
soluble arsenic in the nation's water supplies.

Modified Zeolite Minerals

Dr. Bonnin's process of removing the arsenic uses modified Zeolite minerals, which 
are common, readily available alumina-silicate minerals. The modification involves 
exposing the zeolites to concentrated ferrous aqueous solutions to form an 
iron-laden Zeolite mineral, thereby increasing the zeolite's affinity for arsenic. 
When contact is made between contaminated water and the zeolites, the zeolites act 
as sorbents, chemically bonding with the arsenic, and are then removed. The 
minerals can be used in a column as a filter, or they can be prepared in powdered 
form and used in an existing water treatment plant.

Advantages over Other Processes

 - Bonnin's process is superior to existing methods in several ways.
 - The Zeolite process removes both forms of arsenate and arsenite.
 - No need for the additional steps and expenses of oxidation.
 - No expense for disposal.

When compared to other specific methods, Bonnin's process has a variety of 
advantages. For example, activated alumina is used in one such method, but in 
order to make it economically feasible, reconditioning of the sorbent for 
subsequent reuse is necessary. This process itself creates a hazardous solution 
that requires further treatment and, ultimately, the expense of disposal. 
Activated carbon and flyash can also be used, but activated carbon has a limited 
natural capacity for arsenic species and is expensive. In the case of flyash, a 
waste product produced in large quantities at coal power stations, the properties 
of any given batch of flyash depend on the particular fuel in use. As a result, 
quality control and the flyash's capacity for arsenic species are difficult to 
maintain. Also, because flyash is produced only in a powdered form, it has limited 
application in column separation.

One of the key advantages of Bonnin's method is related to both cost and safety. 
Because the zeolites are inexpensive, they do not have to be reused to make the 
process economically viable and because the arsenicladen zeolites that are the end 
product have passed the EPA's Toxicity Characteristic Leaching Procedure Test, 
they can be simply and safely disposed of in a non-hazardous waste landfill.

In summation, when looking at the alternatives, you realize that Dr. Bonnin has 
come up with the most realistic solution. NuElectric is positioning itself to 
accommodate the water industry’s needs. NRGE has also identified other potential 
technology acquisitions for the future.

Once again please visit http://notify.aucom.com

****** DISCLAIMER ******
This material is being provided by Stock Research 2000, an electronic newsletter 
paid by the issuer for publishing the information contained in this report. Euro 
Media, Inc. has paid a consideration of 6,700 free trading shares of common stock 
of NuElectric Corporation to Stock Research 2000 as payment for the publication of 
the information contained in this report. Stock Research 2000 and its affiliates 
have agreed not to sell the common stock received as payment for its services 
until May 23, 2000, which date is 15 days from the initial dissemination of this 
report. After such date, Stock Research 2000 may sell such shares. Because Stock 
Research 2000 is paid for its services, there is an inherent conflict of interest 
in Stock Research 2000's statements and opinions and such statements and opinions 
cannot be considered independent. The information contained in this publication is 
for informational purposes only, and not to be construed as an offer to sell or 
solicitation of an offer to buy any security. Please be advised that NuElectric 
Corporation is not offering securities for sale to persons in California or 
Minnesota. Stock Research 2000 makes no representation or warrant relating to the 
validity of the facts presented nor does Stock Research 2000 represent or warrant 
that all material facts necessary to make an investment decision are presented 
above. All statements of opinions are those of Stock Research 2000. Stock Research 
2000 relies exclusively on information gathered from public filings on featured 
companies, as well as, in certain circumstances, interviews conducted by Stock 
Research 2000 of management of featured companies. Investors should not rely 
solely on the information contained in this publication. Rather, investors should 
use the information contained in this publication as a starting point for 
conducting additional research on the featured companies in order to allow the 
investor to form his or her own opinion regarding the featured companies. Factual 
statements contained in this publication are made as of the date stated and they 
are subject to change without notice. Stock Research 2000 is not a registered 
investment adviser, broker or a dealer. Investment in the companies reviewed is 
speculative and extremely high-risk and may result in the loss of some or all of 
any investment made in NuElectric Corporation. Projections of future financial 
results are provided solely by NuElectric Corporation. No assurances are given 
that NuElectric Corporation will achieve said projections. This publication 
contains forward-looking statements that are subject to risk and uncertainties 
that could cause results to differ materially from those set forth in the 
forward-looking statements. These forward-looking statements represent the 
judgment of NuElectric Corporation as of the date of this publication. The Company 
disclaims any intent or obligation to update these forward-looking statements.
 
 
 
 
 
 
 
 
 
 


From owner-idmr@cs.ucl.ac.uk  Mon May 15 08:14:59 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02158
	for <idmr-archive@lists.ietf.org>; Mon, 15 May 2000 08:14:58 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.18570-0@pan2.cs.ucl.ac.uk>;
          Mon, 15 May 2000 10:00:33 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.18564-0@pan2.cs.ucl.ac.uk>; Mon, 15 May 2000 10:00:29 +0100
Received: from c1mailgw1.prontomail.com by bells.cs.ucl.ac.uk 
          with Internet SMTP id <g.07687-0@bells.cs.ucl.ac.uk>;
          Mon, 15 May 2000 10:01:13 +0100
Received: from c1web02 (208.178.29.202) 
          by c1mailgw1.prontomail.com (NPlex 4.5.049) id 39089AB300178581 
          for idmr@cs.ucl.ac.uk; Mon, 15 May 2000 02:01:08 -0700
X-Version: indya 6.2.3 .2329.0
From: vijayc@indya.com
Message-Id: <F2461D3672A24D1178E30005B8E28024@vijayc.indya.com>
Date: Mon, 15 May 2000 14:42:17 +0530
X-Priority: Normal
Content-Type: text/plain; charset=iso-8859-1
To: idmr@cs.ucl.ac.uk
Subject: DVMRP:Forwarding cache
X-Mailer: Web Based Pronto
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,
I have a question regarding forwarding cache maintenance in dvmrp as explained in DVMRPv3 
draft( draft-ietf-idmr-dvmrp-v3-09.txt ). 

How long will the forwarding cache be maintained? If an interface is removed from the 
forwarding cache upon receiving a prune and later the prune timer in the upstream expires 
should the interface be added back to the forwarding cache( if forwarding cache entry still 
exists).

Regards,
Vijay 

Sent by Indya Messaging Service


From owner-idmr@cs.ucl.ac.uk  Mon May 15 15:16:22 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08977
	for <idmr-archive@lists.ietf.org>; Mon, 15 May 2000 15:16:22 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.18892-0@pan2.cs.ucl.ac.uk>;
          Mon, 15 May 2000 18:08:49 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.18886-0@pan2.cs.ucl.ac.uk>; Mon, 15 May 2000 18:08:45 +0100
Received: from alpo.casc.com by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.16712-0@bells.cs.ucl.ac.uk>; Mon, 15 May 2000 18:09:11 +0100
Received: from msablic ([62.172.151.59]) by alpo.casc.com (8.9.1a/8.9.1) 
          with SMTP id NAA21918 for <idmr@cs.ucl.ac.uk>;
          Mon, 15 May 2000 13:09:08 -0400 (EDT)
Message-ID: <00ad01bfbe8f$c55d73a0$3b97ac3e@ukip>
From: Mladen Sablic <Mladen.Sablic@lucent.com>
To: idmr <idmr@cs.ucl.ac.uk>
Subject: Query Arrival Time calculation in traceroute draft.
Date: Mon, 15 May 2000 18:05:26 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk
Content-Transfer-Encoding: 7bit

I was looking at the formula for calculating 32-bit NTP stamp:
http://www.ietf.org/internet-drafts/draft-ietf-idmr-traceroute-ipm-06.txt
(Section 5.1):

    query_arrival_time = (tv.tv_sec + 32384)<<16+(tv.tv_usec<<10)/15625

And in the same section it is stated that:

    ((tv.tv_usec << 10) / 15625) is a reduction of
    ((tv.tv_usec / 100000000) << 16).

Shouldn't that be ((tv.tv_usec/ 1000000) << 16) ?

tv.tv_usec/10^6 << 16 = tv.tv_usec/(2^6*5^6)*2^16
                      = (tv.tv_usec*2^10)/5^6
                      = ((tv.tv_usec << 10)/15625)

Mladen



From owner-idmr@cs.ucl.ac.uk  Mon May 15 15:16:35 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08990
	for <idmr-archive@lists.ietf.org>; Mon, 15 May 2000 15:16:34 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.18981-0@pan2.cs.ucl.ac.uk>;
          Mon, 15 May 2000 20:03:28 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.18975-0@pan2.cs.ucl.ac.uk>; Mon, 15 May 2000 20:03:24 +0100
Received: from smtprch1.nortelnetworks.com by bells.cs.ucl.ac.uk 
          with Internet SMTP id <g.22433-0@bells.cs.ucl.ac.uk>;
          Mon, 15 May 2000 20:04:03 +0100
Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) 
          by smtprch1.nortel.com; Mon, 15 May 2000 12:06:49 -0500
Received: from zsc4c004.corpwest.baynetworks.com ([134.177.2.151]) 
          by zsc4c002.corpwest.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id K3ZDMV1J; Mon, 15 May 2000 10:01:26 -0700
Received: from hnguyen-nt (hnguyen-nt.corpwest.baynetworks.com [134.177.80.194]) 
          by zsc4c004.corpwest.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id JVH87ZR6; Mon, 15 May 2000 10:01:26 -0700
Message-Id: <3.0.32.20000515100200.00b20630@ZSC4C004.corpwest.baynetworks.com>
X-Sender: ssingatw@ZSC4C004.corpwest.baynetworks.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 15 May 2000 10:02:00 -0700
To: vijayc@indya.com, idmr@cs.ucl.ac.uk
X-Sybari-Space: 00000000 00000000 00000000
From: Sundeep Singatwaria <ssingatw@nortelnetworks.com>
Subject: Re: DVMRP:Forwarding cache
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk




At 02:42 PM 5/15/00 +0530, vijayc@indya.com wrote:
>Hi all,
>I have a question regarding forwarding cache maintenance in dvmrp as
explained in DVMRPv3 
>draft( draft-ietf-idmr-dvmrp-v3-09.txt ). 
>
>How long will the forwarding cache be maintained? If an interface is
removed from the 

In routed code, the lifetime is between 150 and 300s. I don't know the
rationale behind it but I'm sure the value would have been fine tuned from
real world deployment experience.

>forwarding cache upon receiving a prune and later the prune timer in the
upstream expires 
>should the interface be added back to the forwarding cache( if forwarding
cache entry still 
>exists).
>
yes, the intf. should be added back when the prune expires.

>Regards,
>Vijay 
>
>Sent by Indya Messaging Service
>


From owner-idmr@cs.ucl.ac.uk  Tue May 16 02:41:16 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28970
	for <idmr-archive@lists.ietf.org>; Tue, 16 May 2000 02:41:15 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.19149-0@pan2.cs.ucl.ac.uk>;
          Tue, 16 May 2000 05:18:32 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.19143-0@pan2.cs.ucl.ac.uk>; Tue, 16 May 2000 05:18:28 +0100
Received: from 202.54.69.9 by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.13815-0@bells.cs.ucl.ac.uk>; Tue, 16 May 2000 05:19:11 +0100
Received: by suraksha.wipsys.soft.net (8.8.8+Sun/SMI-SVR4) id JAA01513;
          Tue, 16 May 2000 09:46:23 +0530 (IST)
Received: from cdcvwall(192.168.160.23) by suraksha via smap (V2.0) 
          id xma001511; Tue, 16 May 00 09:46:16 +0530
Received: from manib ([192.168.162.197]) 
          by bhairavi.wipsys.soft.net (Netscape Messaging Server 3.6) 
          with SMTP id AAA71DE for <idmr@cs.ucl.ac.uk>;
          Tue, 16 May 2000 09:46:54 +0530
Message-ID: <016901bfbeee$f277e1e0$c5a2a8c0@wipsys.soft.net>
From: Mani Manoharan Balaraman <mani.balaram@wipro.com>
To: idmr <idmr@cs.ucl.ac.uk>
Subject: IGMP-driver interface
Date: Tue, 16 May 2000 09:56:46 +0530
MIME-Version: 1.0
Content-Type: multipart/mixed ; 
              boundary="----=_NextPart_000_0166_01BFBF1D.0BFDC340"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0166_01BFBF1D.0BFDC340
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello all

when a host wants to join a multicast group, should the IGMP host =
register with the link layer and thereby enable the link layer to listen =
to the multicast group address

My doubt is should IGMP directly register with the link layer or should =
IP layer should do this ?

Thanks in advance
mani=20


------=_NextPart_000_0166_01BFBF1D.0BFDC340
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello all</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>when a host wants to join a multicast =
group, should=20
the IGMP&nbsp;host register with the link layer and thereby enable the =
link=20
layer to listen to the multicast group address</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>My doubt is should IGMP directly =
register with the=20
link layer or should IP layer should do this ?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks in advance</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>mani</FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0166_01BFBF1D.0BFDC340--



From owner-idmr@cs.ucl.ac.uk  Wed May 17 11:09:26 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05844
	for <idmr-archive@lists.ietf.org>; Wed, 17 May 2000 11:09:22 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.19747-0@pan2.cs.ucl.ac.uk>;
          Wed, 17 May 2000 12:26:58 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.19741-0@pan2.cs.ucl.ac.uk>; Wed, 17 May 2000 12:26:54 +0100
Received: from 207.42.183.121 by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.22313-0@bells.cs.ucl.ac.uk>; Wed, 17 May 2000 12:27:35 +0100
Received: from tigrei.prod.eesc.sc.udp.br ([144.117.239.199]) [168.191.88.94] 
          by terra.hn (SMTPD32-5.01) id A43D106C03F8;
          Tue, 16 May 2000 22:55:09 PST
Message-ID: <000070526058$0000282d$00003299@tigrei.prod.eesc.sc.udp.br ([144.117.239.199]) >
To: Undisclosed <"Undisclosed Recipients"@cs.ucl.ac.uk>
From: gs10@bigfoot.com
Subject: REVERSE THE AGING PROCESS 10-20 YEARS WITH GH!,
Date: Sun, 14 May 2000 19:06:53 -0400
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: post20@21cn.com
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk

HAVE YOU HEARD OF GROWTH HORMONE (GH)???

Released by your own pituitary gland, GH starts
declining in your 20s, even more in your 30s and 40s,
eventually resulting in the shrinkage of major organs--plus
all other symptoms related to old age.

THIS CAN NOW BE REVERSED!!! IN THOUSANDS OF CLINICAL
STUDIES, GH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING:

* Reduce Body Fat and Build Lean Muscle WITHOUT EXERCISE!

* Enhance Sexual Performance

* Remove Wrinkles and Cellulite

* Lower Blood Pressure and improve Cholesterol Profile

* Improve Sleep, Vision and Memory

* Restore Hair Color and Growth

* Strengthen the Immune System

* Increase Energy and Cardiac Output

* Turn back your body's Biological Time Clock 10-20
  years in 6 months of usage !!!


For MORE FREE INFORMATION or to order product,
call our 24 HR. HOTLINE, for a 2 minute "insight" on
how GROWTH HORMONE can "Reverse Your Aging Process":

Call 24 hrs. (recorded message): (888) 689-3097
                    or
http://home.earthlink.net/~ricast/index.html

[International Distributors Welcome]

===========================================
Reply with "delete" in the subject box 
to be excluded from future mailing.
=========================================== 



















HAVE YOU HEARD OF GROWTH HORMONE (GH)???







From owner-idmr@cs.ucl.ac.uk  Thu May 18 19:29:57 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14438
	for <idmr-archive@lists.ietf.org>; Thu, 18 May 2000 19:29:57 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.20312-0@pan2.cs.ucl.ac.uk>;
          Thu, 18 May 2000 22:11:32 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.20306-0@pan2.cs.ucl.ac.uk>; Thu, 18 May 2000 22:11:28 +0100
Received: from motgate.mot.com by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.20148-0@bells.cs.ucl.ac.uk>; Thu, 18 May 2000 22:12:11 +0100
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) 
          by motgate.mot.com (motgate 2.1) with ESMTP id OAA19408 
          for <idmr@cs.ucl.ac.uk>; Thu, 18 May 2000 14:12:10 -0700 (MST)]
Received: [from s-il02-e.comm.mot.com (s-il02-e.comm.mot.com [145.1.204.15]) 
          by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA11048 
          for <idmr@cs.ucl.ac.uk>; Thu, 18 May 2000 14:12:10 -0700 (MST)]
Received: by s-il02-e.comm.mot.com with Internet Mail Service (5.5.2650.21) 
          id <LCLR5AZ6>; Thu, 18 May 2000 16:12:10 -0500
Message-ID: <0F762B016151D2118F8900805FA795AF0216CE44@s-il02-n.comm.mot.com>
From: Narayanan Vidya-CVN065 <CVN065@lmpsil02.comm.mot.com>
To: "'idmr'" <idmr@cs.ucl.ac.uk>
Subject: IGMP Proxy draft
Date: Thu, 18 May 2000 16:12:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk

Hi,
I remember having read a draft on IGMP Proxy by Bill Fenner (I think it is
by Fenner, but I could be wrong here). I was wondering where I could find a
copy of that draft. I searched on the internet and it seems like the IETF
site has aged that draft out. I looked at Fenner's home page and didn't have
much luck finding it. I would really appreciate it if someone helps me find
it.

Thanks,
Vidya


From owner-idmr@cs.ucl.ac.uk  Thu May 18 19:30:05 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14453
	for <idmr-archive@lists.ietf.org>; Thu, 18 May 2000 19:30:04 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.20596-0@pan2.cs.ucl.ac.uk>;
          Fri, 19 May 2000 00:18:38 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.20590-0@pan2.cs.ucl.ac.uk>; Fri, 19 May 2000 00:18:31 +0100
Received: from sigma.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.00574-0@bells.cs.ucl.ac.uk>; Fri, 19 May 2000 00:19:04 +0100
Received: from localhost (jzwiebel@localhost) 
          by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP 
          id QAA04847; Thu, 18 May 2000 16:19:01 -0700 (PDT)
Message-Id: <200005182319.QAA04847@sigma.cisco.com>
To: Narayanan Vidya-CVN065 <CVN065@lmpsil02.comm.mot.com>
cc: "'idmr'" <idmr@cs.ucl.ac.uk>, "'pim'" <pim@catarina.usc.edu>
Subject: Re: IGMP Proxy and PIM-SM
In-reply-to: Your message of "Thu, 18 May 2000 16:24:07 CDT." <0F762B016151D2118F8900805FA795AF0216CE45@s-il02-n.comm.mot.com>
Date: Thu, 18 May 2000 16:19:01 -0700
From: "John M. Zwiebel" <jzwiebel@cisco.com>
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk

On the "are there any negatives" question only:
	Imagine a PIM domain running only dense-mode but with hundreds of
	sources.  Also, there have been problems with some failure
	topologies resulting in duplicate register packets arriving
	at the RP from different first-hop routers.

	It is better to specifically have to configure an interface
	to register for sources that are not directly connected.
	
	FWIW, IOS can do this.

 ^ Hi,
 ^ I have a question on the interaction of IGMP Proxy and PIM-SM. IGMP proxy is
 ^ meant to extend the tentacles of the host one hop away from the multicast
 ^ routing domain. It seems like it is really meant only for receivers, when we
 ^ take PIM-SM behavior into account. PIM-SM source DRs apparently do not
 ^ encapsulate packets that do not originate from the local subnet to the RP.
 ^ This means, if I have a router A running IGMP proxy connected to a router B
 ^ that is running PIM-SM and is connected to a bunch of other routers running
 ^ PIM-SM also, I can only hang multicast receivers off router A. Consider the
 ^ following scenario:
 ^ 
 ^ Host A ----- Router A (IGMP Proxy) ----- Router B (PIM-SM; non-RP) -----
 ^ Router C (PIM-SM; RP) ----- Downstreams running PIM-SM
 ^ 
 ^ Assume Router A is connected to Router B through a LAN. Also, assume the
 ^ host A is on a different LAN. Assume WAN connectivity between Routers B and
 ^ C. Now, if Host A was a receiver, everything works fine. If host A were to
 ^ send multicast UDP packets, then, the source address of the packets that hit
 ^ Router B will belong to a subnet different from its local subnet. It seems
 ^ from various implementations that Router B will not encapsulate these
 ^ packets to the RP and instead drop it, since the source address check fails
 ^ for PIM-SM. 
 ^ 
 ^ Are there any negatives for why Router B must not just encapsulate these
 ^ packets to the RP? In a very restricted network, where I don't worry about
 ^ security, what could be the disadvantages of doing this? I am not sure if
 ^ this was just not considered in the IGMP proxy model or was just left open. 
 ^ 
 ^ Any comments would be of great help.
 ^ 
 ^ Thanks,
 ^ Vidya
 ^ 

------------------------------------------------------------------------------
	John Zwiebel                       Phone: 408-526-5303
	Cisco Systems Inc.                 
	IP Multicast Group                   



From owner-idmr@cs.ucl.ac.uk  Thu May 18 19:31:35 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14530
	for <idmr-archive@lists.ietf.org>; Thu, 18 May 2000 19:31:34 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.20332-0@pan2.cs.ucl.ac.uk>;
          Thu, 18 May 2000 22:23:30 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.20326-0@pan2.cs.ucl.ac.uk>; Thu, 18 May 2000 22:23:26 +0100
Received: from motgate.mot.com by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.20800-0@bells.cs.ucl.ac.uk>; Thu, 18 May 2000 22:24:09 +0100
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) 
          by motgate.mot.com (motgate 2.1) with ESMTP id OAA27839 
          for <idmr@cs.ucl.ac.uk>; Thu, 18 May 2000 14:24:09 -0700 (MST)]
Received: [from il02exi01.comm.mot.com (il02exi01.comm.mot.com [145.1.204.40]) 
          by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA18638 
          for <idmr@cs.ucl.ac.uk>; Thu, 18 May 2000 14:24:09 -0700 (MST)]
Received: by il02exi01.comm.mot.com with Internet Mail Service (5.5.2650.21) 
          id <LCKSZ6H6>; Thu, 18 May 2000 16:24:09 -0500
Message-ID: <0F762B016151D2118F8900805FA795AF0216CE45@s-il02-n.comm.mot.com>
From: Narayanan Vidya-CVN065 <CVN065@lmpsil02.comm.mot.com>
To: "'idmr'" <idmr@cs.ucl.ac.uk>, "'pim'" <pim@catarina.usc.edu>
Subject: IGMP Proxy and PIM-SM
Date: Thu, 18 May 2000 16:24:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk

Hi,
I have a question on the interaction of IGMP Proxy and PIM-SM. IGMP proxy is
meant to extend the tentacles of the host one hop away from the multicast
routing domain. It seems like it is really meant only for receivers, when we
take PIM-SM behavior into account. PIM-SM source DRs apparently do not
encapsulate packets that do not originate from the local subnet to the RP.
This means, if I have a router A running IGMP proxy connected to a router B
that is running PIM-SM and is connected to a bunch of other routers running
PIM-SM also, I can only hang multicast receivers off router A. Consider the
following scenario:

Host A ----- Router A (IGMP Proxy) ----- Router B (PIM-SM; non-RP) -----
Router C (PIM-SM; RP) ----- Downstreams running PIM-SM

Assume Router A is connected to Router B through a LAN. Also, assume the
host A is on a different LAN. Assume WAN connectivity between Routers B and
C. Now, if Host A was a receiver, everything works fine. If host A were to
send multicast UDP packets, then, the source address of the packets that hit
Router B will belong to a subnet different from its local subnet. It seems
from various implementations that Router B will not encapsulate these
packets to the RP and instead drop it, since the source address check fails
for PIM-SM. 

Are there any negatives for why Router B must not just encapsulate these
packets to the RP? In a very restricted network, where I don't worry about
security, what could be the disadvantages of doing this? I am not sure if
this was just not considered in the IGMP proxy model or was just left open. 

Any comments would be of great help.

Thanks,
Vidya


From owner-idmr@cs.ucl.ac.uk  Fri May 19 13:37:50 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08714
	for <idmr-archive@lists.ietf.org>; Fri, 19 May 2000 13:37:49 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.20990-0@pan2.cs.ucl.ac.uk>;
          Fri, 19 May 2000 15:56:06 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.20984-0@pan2.cs.ucl.ac.uk>; Fri, 19 May 2000 15:56:02 +0100
Received: from 208.164.93.29 by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.28815-0@bells.cs.ucl.ac.uk>; Fri, 19 May 2000 15:56:47 +0100
Received: from ranalld (RANALL_D [208.164.89.189]) by dtctxexch8.ins.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id LDR1RNDG; Fri, 19 May 2000 09:56:43 -0500
Message-ID: <001101bfc1a1$aae4a5b0$bd59a4d0@ins.com>
Reply-To: mahagwa_makokha <mahagwa_makokha@ins.com>
From: mahagwa_makokha <mahagwa_makokha@ins.com>
To: idmr <idmr@cs.ucl.ac.uk>
Subject: remove
Date: Fri, 19 May 2000 09:51:08 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; 
              boundary="----=_NextPart_000_000E_01BFC177.C1F48600"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01BFC177.C1F48600
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

remove

------=_NextPart_000_000E_01BFC177.C1F48600
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2722.2800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>remove</FONT></DIV></BODY></HTML>

------=_NextPart_000_000E_01BFC177.C1F48600--



From owner-idmr@cs.ucl.ac.uk  Fri May 19 20:32:22 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12217
	for <idmr-archive@lists.ietf.org>; Fri, 19 May 2000 20:32:22 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.21269-0@pan2.cs.ucl.ac.uk>;
          Fri, 19 May 2000 23:34:41 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.21263-0@pan2.cs.ucl.ac.uk>; Fri, 19 May 2000 23:34:36 +0100
Received: from griffin.aciri.org by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.20601-0@bells.cs.ucl.ac.uk>; Fri, 19 May 2000 23:35:21 +0100
Received: from hetnet.nl (localhost.aciri.org [127.0.0.1]) 
          by griffin.aciri.org (8.9.3/8.9.3) with ESMTP id PAA25528;
          Fri, 19 May 2000 15:35:20 -0700 (PDT) (envelope-from wilbertdg@hetnet.nl)
Message-ID: <3925C1A7.321346E9@hetnet.nl>
Date: Fri, 19 May 2000 15:35:20 -0700
From: Wilbert de Graaf <wilbertdg@hetnet.nl>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.36 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "idmr@cs.ucl.ac.uk" <idmr@cs.ucl.ac.uk>
CC: wilbertdg@hetnet.nl
Subject: IGMPv3: response to source-and-group specific query when in EXCL mode
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hi,

The IGMPv3 draft v03 says (in the last table of $5.2 ) that when a host
receives an IGMPv3 source-and-group-specific query, and it's current
interface state is exclude, it has to send a report like this:

INCLUDE (all sources in the query - the sources it has in it's own
exclude list)

So if the exclude state is {a, b}, and the query asks me if I'm
interested for traffic from {c, d, e, f, g, ...} I have to store all of
these addresses until I can send the delayed response. Of course this
can be done but it has some overhead involved.

Why not just respond with your own exclude list ? Or is there some
practical limit on the number of sources that you would store ?

- Wilbert




From owner-idmr@cs.ucl.ac.uk  Fri May 19 22:39:06 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14610
	for <idmr-archive@lists.ietf.org>; Fri, 19 May 2000 22:39:05 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.21388-0@pan2.cs.ucl.ac.uk>;
          Sat, 20 May 2000 01:59:26 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.21382-0@pan2.cs.ucl.ac.uk>; Sat, 20 May 2000 01:59:22 +0100
Received: from sj-msg-core-1.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.27906-0@bells.cs.ucl.ac.uk>; Sat, 20 May 2000 02:00:07 +0100
Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) 
          by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA18294;
          Fri, 19 May 2000 18:00:13 -0700 (PDT)
Received: from localhost (kouvelas@localhost) 
          by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) 
          with ESMTP id SAA06832; Fri, 19 May 2000 18:00:03 -0700 (PDT)
Message-Id: <200005200100.SAA06832@kouvelas-u10.cisco.com>
X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing 
                          -bs
To: Wilbert de Graaf <wilbertdg@hetnet.nl>
cc: "idmr@cs.ucl.ac.uk" <idmr@cs.ucl.ac.uk>
Subject: Re: IGMPv3: response to source-and-group specific query when in EXCL 
         mode
Date: Fri, 19 May 2000 18:00:03 -0700
From: Isidor Kouvelas <kouvelas@cisco.com>
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk


Wilbert de Graaf writes:
>
>Hi,
>
>The IGMPv3 draft v03 says (in the last table of $5.2 ) that when a host
>receives an IGMPv3 source-and-group-specific query, and it's current
>interface state is exclude, it has to send a report like this:
>
>INCLUDE (all sources in the query - the sources it has in it's own
>exclude list)
>
>So if the exclude state is {a, b}, and the query asks me if I'm
>interested for traffic from {c, d, e, f, g, ...} I have to store all of
>these addresses until I can send the delayed response. Of course this
>can be done but it has some overhead involved.
>
>Why not just respond with your own exclude list ? Or is there some
>practical limit on the number of sources that you would store ?
>
>- Wilbert

I think that sending the full EXCLUDE state instead of requesting
reception of the queried sources will probably also work. This is
because current state reports do not trigger queries. Otherwise,
we could get into a query / report loop if the exclude lists from
two hosts contained different sources.

For example if two hosts switch from INCLUDE{} to:
Host1: EXCLUDE{A,B}
Host2: EXCLUDE{B,C}
and they start generating TO_EX reports, then the router will generate
source specific queries for sources A and C.

If a broken host implementation does not generate the correct reports in
response to the queries, and mixes the triggered TO_EX retransmissions
with the responses to the queries, then we can get into a loop where the
TO_EX reports trigger more queries and the queries more TO_EX reports.

I do not think this can happen with EXCLUDE reports but to be on the
safe side, a host implementation should respond to source-specific
queries with an IS_IN record.

thanks
Isidor



From owner-idmr@cs.ucl.ac.uk  Wed May 24 04:42:24 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01205
	for <idmr-archive@lists.ietf.org>; Wed, 24 May 2000 04:42:24 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.22154-0@pan2.cs.ucl.ac.uk>;
          Wed, 24 May 2000 06:53:50 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.22148-0@pan2.cs.ucl.ac.uk>; Wed, 24 May 2000 06:53:46 +0100
Received: from c1mailgw3.prontomail.com by bells.cs.ucl.ac.uk 
          with Internet SMTP id <g.00296-0@bells.cs.ucl.ac.uk>;
          Wed, 24 May 2000 06:54:31 +0100
Received: from c1web01 (208.178.29.201) 
          by c1mailgw3.prontomail.com (NPlex 4.5.049) id 3908C51200268EF4 
          for idmr@cs.ucl.ac.uk; Tue, 23 May 2000 22:54:05 -0700
X-Version: indya 6.2.3 .2329.0
From: vijayc@indya.com
Message-Id: <F45A2675F0134D1178130005B823A263@vijayc.indya.com>
Date: Wed, 24 May 2000 11:36:01 +0530
X-Priority: Normal
Content-Type: text/plain; charset=iso-8859-1
To: idmr@cs.ucl.ac.uk
Subject: IGMP packets and Multicast Dgrams
X-Mailer: Web Based Pronto
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,
 
I have a question regarding handling multicast datagrams and IGMP packets in TCP/IP stack 
which uses DVMRP in the routers.

All DVMRP messages come with protocol type(in IP header) as IGMP. Only after looking at 
the message type code IP layer can switch the message to DVMRP or IGMP. Can this 
decision be taken at the IP layer or can all IGMP type packets be given to either IGMP or 
DVMRP and then decide based on the message type? Also, on core routers where IGMP is 
not running should this decision be taken differently ,ie, to always give IGMP type packets to 
DVMRP. 

The IGMP rfc says that IGMP should enable multicast addresses in the link layer. If IGMP is 
not running as in core routers who is responsible for enabling multicasting in the interfaces. 

In a leaf router where DVMRP and IGMP may be present if a multicast datagram is received 
should IP layer make a copy and send to both IGMP and DVMRP or else how will it be done.

Regards,
Vijay





Enter your default signature here
Sent by Indya Messaging Service


From owner-idmr@cs.ucl.ac.uk  Wed May 24 16:49:20 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12887
	for <idmr-archive@lists.ietf.org>; Wed, 24 May 2000 16:49:19 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.22315-0@pan2.cs.ucl.ac.uk>;
          Wed, 24 May 2000 19:54:21 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.22309-0@pan2.cs.ucl.ac.uk>; Wed, 24 May 2000 19:54:16 +0100
Received: from ertpg14e1.nortelnetworks.com by bells.cs.ucl.ac.uk 
          with Internet SMTP id <g.16861-0@bells.cs.ucl.ac.uk>;
          Wed, 24 May 2000 19:55:02 +0100
Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) 
          by ertpg14e1.nortelnetworks.com; Wed, 24 May 2000 14:31:05 -0400
Received: from zsc4c004.corpwest.baynetworks.com ([134.177.2.151]) 
          by zsc4c002.corpwest.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id LP2MKRW0; Wed, 24 May 2000 11:31:02 -0700
Received: from hnguyen-nt (hnguyen-nt.corpwest.baynetworks.com [134.177.80.194]) 
          by zsc4c004.corpwest.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id LMBHJ7CM; Wed, 24 May 2000 11:31:01 -0700
Message-Id: <3.0.32.20000524113123.00a98530@ZSC4C004.corpwest.baynetworks.com>
X-Sender: ssingatw@ZSC4C004.corpwest.baynetworks.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 24 May 2000 11:31:23 -0700
To: vijayc@indya.com, idmr@cs.ucl.ac.uk
X-Sybari-Space: 00000000 00000000 00000000
From: Sundeep Singatwaria <ssingatw@nortelnetworks.com>
Subject: Re: IGMP packets and Multicast Dgrams
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk

At 11:36 AM 5/24/00 +0530, vijayc@indya.com wrote:
>Hi all,
> 
>I have a question regarding handling multicast datagrams and IGMP packets
in TCP/IP stack 
>which uses DVMRP in the routers.
>
>All DVMRP messages come with protocol type(in IP header) as IGMP. Only
after looking at 
>the message type code IP layer can switch the message to DVMRP or IGMP.
Can this 
>decision be taken at the IP layer or can all IGMP type packets be given to
either IGMP or 
>DVMRP and then decide based on the message type? Also, on core routers
where IGMP is 
>not running should this decision be taken differently ,ie, to always give
IGMP type packets to 
>DVMRP. 

I guess good software engineering practise require to have a single code
base which can be used at
different places.

>
>The IGMP rfc says that IGMP should enable multicast addresses in the link
layer. If IGMP is 
>not running as in core routers who is responsible for enabling
multicasting in the interfaces. 

Multicast protocols like DVMRP, PIM
>
>In a leaf router where DVMRP and IGMP may be present if a multicast
datagram is received 
>should IP layer make a copy and send to both IGMP and DVMRP or else how
will it be done.

I don't see a need to make copy of packets.
>
>Regards,
>Vijay
>
>
>
>
>
>Enter your default signature here
>Sent by Indya Messaging Service
>


From owner-idmr@cs.ucl.ac.uk  Thu May 25 14:01:38 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16405
	for <idmr-archive@lists.ietf.org>; Thu, 25 May 2000 14:01:37 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.22704-0@pan2.cs.ucl.ac.uk>;
          Thu, 25 May 2000 16:48:01 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.22697-0@pan2.cs.ucl.ac.uk>; Thu, 25 May 2000 16:47:57 +0100
Received: from 212.120.142.88 by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.08519-0@bells.cs.ucl.ac.uk>; Thu, 25 May 2000 16:48:40 +0100
Received: from devfw002.smartforce.com ([212.120.142.65]) 
          by eursmtp (Build 98 8.9.3/NT-8.9.3) with SMTP id QAA00349;
          Thu, 25 May 2000 16:53:00 +0100
Subject: IGMP query
To: fenner@parc.xerox.com, idmr@cs.ucl.ac.uk
From: paul_nash@smartforce.com
Date: Wed, 24 May 2000 12:50:47 +0100
Message-ID: <OF04DDF479.13536EA1-ON802568EA.0055A98F@smartforce.com>
X-MIMETrack: Serialize by Router on eurcsklm01/SmartForce(Release 5.0.2c 
             (Intl)|2 February 2000) at 25/05/2000 16:46:08
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk

Hi Mr Fenner and IDMR people,
I am an editor at SmartForce, the computer-based learning company, and
obtained your e-mail addresses from RFC 2236.
I would be very grateful if you could answer or assist with this query on
'stranded groups' in IGMP, which I can't find covered in the relevant RFCs
or Cisco documents.
The passage I am editing describes how IGMP deals with topology changes
such as 'disappearing endpoints and stranded groups'.
There is no problem about disappearing endpoints-- it is clear from the
context what happens here, but no description of a stranded group is
available.  I and my technical advisor both think it means a group whose
remote connection goes down, with the result that the creator node receives
no confirm responses from the stranded group and deletes it.
Can you confirm this-- and even better, can you indicate whether IGMP
provides an automatic mechanism for restoring such a group (assuming of
course that it is physically possible), or whether IGMP breaks down in such
a case.
Regards
Paul Nash



From owner-idmr@cs.ucl.ac.uk  Thu May 25 18:08:45 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21846
	for <idmr-archive@lists.ietf.org>; Thu, 25 May 2000 18:08:44 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.22857-0@pan2.cs.ucl.ac.uk>;
          Thu, 25 May 2000 21:03:23 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.22851-0@pan2.cs.ucl.ac.uk>; Thu, 25 May 2000 21:03:19 +0100
Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk 
          with Internet SMTP id <g.22941-0@bells.cs.ucl.ac.uk>;
          Thu, 25 May 2000 21:04:05 +0100
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) 
          by mail-green.research.att.com (Postfix) with ESMTP id DB58D1E010;
          Thu, 25 May 2000 16:04:04 -0400 (EDT)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) 
          by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA02244;
          Thu, 25 May 2000 16:04:04 -0400 (EDT)
From: Bill Fenner <fenner@research.att.com>
Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) 
          id NAA09560; Thu, 25 May 2000 13:02:32 -0700 (PDT)
Message-Id: <200005252002.NAA09560@windsor.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: paul_nash@smartforce.com
Subject: Re: IGMP query
Cc: idmr@cs.ucl.ac.uk
Date: Thu, 25 May 2000 13:02:32 -0700
Versions: dmail (solaris) 2.2g/makemail 2.9a
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk


I've never heard of a stranded group.  What's a creator node?
What's a confirm response?  Are we talking about the protocol
described in RFC2236, or something else?

  Bill


From owner-idmr@cs.ucl.ac.uk  Fri May 26 08:26:14 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13317
	for <idmr-archive@lists.ietf.org>; Fri, 26 May 2000 08:26:13 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.23076-0@pan2.cs.ucl.ac.uk>;
          Fri, 26 May 2000 10:48:35 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.23070-0@pan2.cs.ucl.ac.uk>; Fri, 26 May 2000 10:48:30 +0100
Received: from buffy.tpgi.com.au by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.10072-0@bells.cs.ucl.ac.uk>; Fri, 26 May 2000 10:49:15 +0100
Received: (from smtpd@localhost) by buffy.tpgi.com.au (8.9.3/8.9.3) id TAA01376 
          for <idmr@cs.ucl.ac.uk>; Fri, 26 May 2000 19:49:09 +1000
Date: Fri, 26 May 2000 19:49:09 +1000
From: info@animationallsorts.com
Message-Id: <200005260949.TAA01376@buffy.tpgi.com.au>
Received: from syd3-56k-150.tpgi.com.au(203.29.148.150), claiming to be "home" 
          via SMTP by buffy.tpgi.com.au, id smtpduGkqRE;
          Fri May 26 19:49:01 2000
To: idmr@cs.ucl.ac.uk
X-Mailer: 2F7F8788.41B09C4D.3bb45556acab7059ae7d0a28b1b16cfd
Subject: Open Mind
Organization: Animation Allsorts
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk

I have discovered your webside on the Internet and find it
really interesting.I do believe that you or your clients may
benefit from the information we are offering. 

There are a lot of people trying to get rich quick, without 
any interest in another human being whatsoever. Well, I 
doubt that they will succeed. There is a law in success like 
there is a law in physics.

You may not believe in gravity or not know about it, but it still works.

The Law of Success says: 
If you help enough people to get what they want, 
You will get what You want.

Therefore, if you think, that you may gain and discover a benefit
for yourself, click on:

http://www.animationallsorts.com/00-Main-Journey.htm

or you can have a look at our Newsletter to find out if you can
benefit from it:

http://www.animationallsorts.com/NEWSLETER/April-00/NLetter-index.htm

Don't hesitate to forward a copy of this newsletter to friends
and associates, but please ask for permission before reproducing
the content in any form -- we would like to know who you are.

Pavel Kyral
Director

Animation Allsorts - Open Mind
105/3 Bruce Street, Crows Nest, NSW, 2065, Australia 
Phone: 612 9955 7990 | Fax: 612 9955 0076 
Copyright © 1990-2000 All Rights Reserved

If you think, that you will not benefit from this corespondence, send

an email to:

remove@animationallsorts.com	Subject:Remove gravity



From owner-idmr@cs.ucl.ac.uk  Sun May 28 14:25:05 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09630
	for <idmr-archive@lists.ietf.org>; Sun, 28 May 2000 14:25:04 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.23451-0@pan2.cs.ucl.ac.uk>;
          Sun, 28 May 2000 17:11:22 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.23445-0@pan2.cs.ucl.ac.uk>; Sun, 28 May 2000 17:11:18 +0100
Received: from c1.h202052123.is.net.tw by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.11786-0@bells.cs.ucl.ac.uk>; Sun, 28 May 2000 17:12:04 +0100
Received: from mail.mindspring.com (FIREWALL [130.1.1.2]) 
          by basso-server.basso.com.tw 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) 
          id LQ5TS2BB; Mon, 29 May 2000 00:10:44 +0800
From: sdfjus <sdfjus@accessv.co>
To: idmr <idmr@cs.ucl.ac.uk>
Date: Sun, 28 May 2000 08:15:04
Message-Id: <567.492597.863624@mail.mindspring.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk
Content-Transfer-Encoding: 7bit

GET YOUR OWN 5 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY!

STOP PAYING $19.95 or more PER MONTH OR MORE TODAY for your web 
site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH!

DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE 
DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO 
GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A 
SIMPLE PHONE CALL OUR OFFICE.

YOU CAN CHANGE YOUR SITE AS MUCH AS YOU WANT with no extra 
charge!  UNLIMITED TRAFFIC -- no extra charge!


A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS.

ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP 
CHARGE.

FOR DETAILS CALL 1 888 248 0765  or fax 240 337 8325

PES WEB HOSTING -- Toronto, Ontario
_______________________________________________________________

Want to do bulk email?

Ask us how today!

For an investment of $395.00 for our Direct Mail mailing program 
and our highly prized email extractor program Nitro for $495.00,
you can be in business today!

If you manage your own mailing list, you somebody do your mailing 
for you, here is the way to do it your self!
Email 10,000 to 20,000 per hour with our programs!

Call 1888 248 0765 for a free demo today!
  or fax 240 337 8325

_________________________________________________________________

Get your own offshore trust! 
PROTECT YOUR PERSONAL ASSETS FROM LAWSUITS or Do SOME ESTATE 
PLANNING!
GET THAT OFFSHORE BANK ACCOUNT YOU ALWAYS WANTED!

For further information please fax 240 337 8325




THANK YOU


 
 
 
 
 
 
 
 
 


From owner-idmr@cs.ucl.ac.uk  Mon May 29 07:44:34 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29576
	for <idmr-archive@lists.ietf.org>; Mon, 29 May 2000 07:44:33 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.23655-0@pan2.cs.ucl.ac.uk>;
          Mon, 29 May 2000 09:56:31 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.23649-0@pan2.cs.ucl.ac.uk>; Mon, 29 May 2000 09:56:27 +0100
Received: from c1.h202052123.is.net.tw by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.04943-0@bells.cs.ucl.ac.uk>; Mon, 29 May 2000 09:57:11 +0100
Received: from lwu8I9F85 (FIREWALL [130.1.1.2]) by basso-server.basso.com.tw 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) 
          id LQ5T4488; Mon, 29 May 2000 16:36:59 +0800
DATE: 29 May 00 4:51:24 AM
FROM: 1Jp4rC5wW@altu.net.au
Message-ID: <jl87O34Y38>
SUBJECT: great web hosting deals gghy
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk
Apparently-To: idmr-pp

GET YOUR OWN 5 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY!

STOP PAYING $19.95 or more PER MONTH OR MORE TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH!

DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL OUR OFFICE.

YOU CAN CHANGE YOUR SITE AS MUCH AS YOU WANT with no extra charge!  UNLIMITED TRAFFIC -- no extra charge!


A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS.

ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE.

FOR DETAILS CALL 1 888 248 0765  or fax 240 337 8325

PES WEB HOSTING -- 

____________________________________________________

WE do bulk email for you!
Call 888 248 0765 to promote your business today!
Half million email blast $495.00.
One million email blast $1275.00
Two million email blast $2500.00
For further information if you are outside the USA fax 240 337 8325
________________________________________________________

Get your estate planned today!
Avoid the prying eyes of the public!
Creditor proof your assets from those who want to get your 
money!
For further details fax 240 337 8325                                      




From owner-idmr@cs.ucl.ac.uk  Mon May 29 10:20:47 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00625
	for <idmr-archive@lists.ietf.org>; Mon, 29 May 2000 10:20:46 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.23720-0@pan2.cs.ucl.ac.uk>;
          Mon, 29 May 2000 13:20:34 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.23714-0@pan2.cs.ucl.ac.uk>; Mon, 29 May 2000 13:20:29 +0100
Received: from suraksha.wipsys.soft.net by bells.cs.ucl.ac.uk 
          with Internet SMTP id <g.10891-0@bells.cs.ucl.ac.uk>;
          Mon, 29 May 2000 13:20:59 +0100
Received: by suraksha.wipsys.soft.net (8.8.8+Sun/SMI-SVR4) id RAA11604;
          Mon, 29 May 2000 17:48:09 +0530 (IST)
Received: from cdcvwall(192.168.160.23) by suraksha via smap (V2.0) 
          id xma011602; Mon, 29 May 00 17:48:02 +0530
Received: from shivak ([192.168.162.103]) 
          by bhairavi.wipsys.soft.net (Netscape Messaging Server 3.6) 
          with SMTP id AAA251D for <idmr@cs.ucl.ac.uk>;
          Mon, 29 May 2000 17:48:24 +0530
From: Sivakumar Kuppusamy <sivakumar.kuppusamy@wipro.com>
To: idmr <idmr@cs.ucl.ac.uk>
Subject: IGMPV2
Date: Mon, 29 May 2000 18:02:27 +0530
Message-ID: <NEBBLHFNMLEFOEJLKOFPEEMBCDAA.sivakumar.kuppusamy@wipro.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi All,
I am in the process of implementing IGMPV2.
As per the RFC 2236 if any Router in a Subnet is of Version 1 then the other
routers should be explicitly configured as v1 routers.
In this case which State Machine has to be followed.
The one given in 2236 or is it implementation specific?
Thankx in advance.

Cheers
Siva




From owner-idmr@cs.ucl.ac.uk  Mon May 29 18:17:33 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04357
	for <idmr-archive@lists.ietf.org>; Mon, 29 May 2000 18:17:32 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.23946-0@pan2.cs.ucl.ac.uk>;
          Mon, 29 May 2000 20:54:47 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.23940-0@pan2.cs.ucl.ac.uk>; Mon, 29 May 2000 20:54:43 +0100
Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk 
          with Internet SMTP id <g.23960-0@bells.cs.ucl.ac.uk>;
          Mon, 29 May 2000 20:55:29 +0100
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) 
          by mail-blue.research.att.com (Postfix) with ESMTP id 4FA814CE05;
          Mon, 29 May 2000 15:55:29 -0400 (EDT)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) 
          by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA14599;
          Mon, 29 May 2000 15:55:28 -0400 (EDT)
From: Bill Fenner <fenner@research.att.com>
Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) 
          id MAA02454; Mon, 29 May 2000 12:53:55 -0700 (PDT)
Message-Id: <200005291953.MAA02454@windsor.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: sivakumar.kuppusamy@wipro.com
Subject: Re: IGMPV2
Cc: idmr@cs.ucl.ac.uk
Date: Mon, 29 May 2000 12:53:55 -0700
Versions: dmail (solaris) 2.2g/makemail 2.9a
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk


>As per the RFC 2236 if any Router in a Subnet is of Version 1 then the other
>routers should be explicitly configured as v1 routers.
>In this case which State Machine has to be followed.

See Appendix A of RFC 1112.

  Bill


From owner-idmr@cs.ucl.ac.uk  Tue May 30 09:33:33 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28464
	for <idmr-archive@lists.ietf.org>; Tue, 30 May 2000 09:33:32 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.24198-0@pan2.cs.ucl.ac.uk>;
          Tue, 30 May 2000 12:15:50 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.24192-0@pan2.cs.ucl.ac.uk>; Tue, 30 May 2000 12:15:46 +0100
Received: from suraksha.wipsys.soft.net by bells.cs.ucl.ac.uk 
          with Internet SMTP id <g.19709-0@bells.cs.ucl.ac.uk>;
          Tue, 30 May 2000 12:16:29 +0100
Received: by suraksha.wipsys.soft.net (8.8.8+Sun/SMI-SVR4) id QAA24402;
          Tue, 30 May 2000 16:43:37 +0530 (IST)
Received: from cdcvwall(192.168.160.23) by suraksha via smap (V2.0) 
          id xma024398; Tue, 30 May 00 16:43:15 +0530
Received: from shivak ([192.168.162.103]) 
          by bhairavi.wipsys.soft.net (Netscape Messaging Server 3.6) 
          with SMTP id AAA5A9D for <idmr@cs.ucl.ac.uk>;
          Tue, 30 May 2000 16:43:34 +0530
From: Sivakumar Kuppusamy <sivakumar.kuppusamy@wipro.com>
To: idmr <idmr@cs.ucl.ac.uk>
Subject: Performance of DVMRP...
Date: Tue, 30 May 2000 16:57:55 +0530
Message-ID: <NEBBLHFNMLEFOEJLKOFPEEMOCDAA.sivakumar.kuppusamy@wipro.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,

I want to know the performance of the mrouted code under Linux.
Specifically can anyone tell me the time taken to process each DVMRP packet
and also the number of packets forwarded by DVMRP module per second by the
mrouted(DVMRP)code.

Is there any standards or bench marks available for DVMRP/Multicast routing
protocols under Linux.

Thankx in advance.

Cheers
Siva




From owner-idmr@cs.ucl.ac.uk  Wed May 31 17:40:37 2000
Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25530
	for <idmr-archive@lists.ietf.org>; Wed, 31 May 2000 17:40:36 -0400 (EDT)
Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk 
          via Local Delivery channel id <g.24799-0@pan2.cs.ucl.ac.uk>;
          Wed, 31 May 2000 20:09:20 +0100
Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP 
          id <g.24793-0@pan2.cs.ucl.ac.uk>; Wed, 31 May 2000 20:09:16 +0100
Received: from ns.stardust.com by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.22653-0@bells.cs.ucl.ac.uk>; Wed, 31 May 2000 20:10:03 +0100
Received: from WHITESTAR (dhcp204-106.stardust.com [205.184.204.106]) 
          by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA13169 
          for <idmr@cs.ucl.ac.uk>; Wed, 31 May 2000 12:09:59 -0700
Message-Id: <3.0.5.32.20000531120841.03185760@stardust.com>
X-Sender: martinb@stardust.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 31 May 2000 12:08:41 -0700
To: idmr@cs.ucl.ac.uk
From: Marty Bickford <martinb@stardust.com>
Subject: iBAND4: Free Educational Passes & QoS Demonstration
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-idmr@cs.ucl.ac.uk
Precedence: bulk

-----------------------------------------------------------
iBAND4 - Internet Traffic Management & Service Provisioning
         for IP Network Engineers & Techno-Savvy Colleagues
         San Francisco Airport Marriott Hotel
         Conference: June 11-13 + Workshops: June 14
         http://www.stardust.com/iband4/
-----------------------------------------------------------

Free Educational Passes
-----------------------

Stardust.com is happy to offer a limited number of free conference passes
to educators and non-commercial researchers. If you are interested in
obtaining a pass, please email Marty Bickford <marty@stardust.com>.

iBAND4 is the fourth in the only series of events focused on bandwidth
management, traffic engineering and service provisioning. iBAND is your
chance to explore the latest thinking about smart bandwidth. Learn about
the new standards and technologies, deployment strategies, and business
opportunities. Get access to information, insight, knowledge and experts
not available at less-focused industry shows.


QoS Network Showcase
--------------------

The iBAND4 Showcase is the third in a series of networks engineered by
members of the QoS Forum. This time around, the showcase features solutions
to two substantial classes of problem being confronted by managers of IP
networks:

- Napster/MP3-based traffic saturation 
- Denial of Service Attacks

Within this showcase, you can see new Quality of Service and Policy
Management capabilities in hosts, applications, routers, switches and
network analysis tools. Engineered into several different network
topologies, these interoperable products harness new protocol standards and
show how network managers can use them to address real problems confronting
their IP networks.


Keynotes outline QoS-enabled, Policy-based B2B networks!
--------------------------------------------------------

   Evan Kaplan, ceo of Aventail:
   "B2B Models & the Fundamental Need for Policy-based Networking"

   Tony Naughtin, ceo of InterNAP: 
   "The Real-World Marriage of QoS and Policy"

   Brian Carpenter, dir of Internet technology & standards for IBM:
   "The Evolution and Integration of Emerging Standards"


IPv6 and IP Multicast Workshops
-------------------------------

Attend one of these advanced technology workshops to understand how the
protocols work and how they can be integrated into your network.

 IP Multicast at a Crossroads
 http://www.stardust.com/iband4/multicast.htm

 IPv6 - Understanding the Next Generation
 http://www.stardust.com/iband4/ipv6.htm

The iBAND workshops will be taught on June 14th. Space is very limited. For
more information call (408)879-8080 or visit http://www.stardust.com/iband4/


Sign-up Now and Save Money 
--------------------------

The price will move to $1,395 after June 2nd. 
Register today at http://www.stardust.com/iband4/ or call (408)879-8080.


---
Marty Bickford  - 408.879.8080 (8081-fax)
Stardust.com - http://www.stardust.com