Re: ANL/NREN Test Beacon (fwd)
Linda Winkler (lwinkler@anl.gov)
Thu, 30 Jul 1998 15:24:04 -0500
ANL is OK with Monday.
lw
At 11:43 AM 7/30/98 -0700, Joe Burrescia wrote:
>Shelly,
>
>We need really need the time to bring this up in our production
>environment. I would rather delay and get it running correctly
>rather than risk disturbing production services. The soonest
>I can see this happening is Monday, again this also relies on
>ANL's OK.
>
>--Joe
>
>> Joe:
>>
>> I was hoping to be able to discuss prliminary results of the test on a
>> weekly conference call held at 1:00 Central Time every Tuesday. Slipping a
>> day could have the potential of setting us back as much as one week. Is
>> there any way to accomodate us on this. If we must I could probably push
>> back to early Tuesday morning but that squeezes us on coordination between
>> several groups and still doesn't leave you folks too much time to fix much
>> if the conversion doesn't go very well.
>>
>> Shelly
>>
>> At 5:54 PM -0000 7/30/1998, Joe Burrescia wrote:
>> >Shelly,
>> >
>> >As a matter of fact... we in the process of bringing ANL into our
>> >PIM cloud. This should satisfy both your short and long term
>> >goals. I was hoping to configure this on Monday 8/3 (subject
>> >to ANL's approval). Any way to slip your test back a day or so
>> >that we can insure that this will work before then?
>> >
>> >--Joe
>> >
>> >FYI- I switched the cc line to : routing@es.net. This catches all the
>> >folks in the routing group, and is used for discussing routing issues
>> >of this sort.
>> >
>> >> Joe:
>> >>
>> >> As you have already seen, we would like to conduct a test of our
>> >> multicasting network. In the comming weeks and months we will probably
>> >> start stressing the networking with ever higher bitrates being multicast
>> >> out of Argonne National Labs. 1 Mb/s was chosen for this test simply
>> >> because it is a convient logical next step for the rest of us in this
>> >> experiment. Can you sugest a way to accomplish both the short term
goal to
>> >> enable the test that I would hope could run from about noon on Monday,
>> >> 8/3/98, untill Wednesday 8/5/98 noon (Times are Central time) and
provide
>> >> the long term soultion of letting us place a signal of this or even
greater
>> >> magnitude on the network without disrupting your other customers and
>> >> without having to coordinate every multicast we do.
>> >>
>> >> Thank You
>> >>
>> >> Shelly Deixler
>> >>
>> >> ___________________________________________________
>> >>
>> >> >Date: Thu, 30 Jul 1998 09:43:44 -0700 (PDT)
>> >> >From: Hugh LaMaster <lamaster@george.arc.nasa.gov>
>> >> >
>> >> >
>> >> >Well, I stand corrected on one point. Although ESnet can handle
>> >> >multicast streams as large or larger than 1 Mbps, because it is
>> >> >used heavily operationally, ESnet would rather *not* have us do
>> >> >ad hoc testing of 1 Mbps streams. They would like us to notify
>> >> >them in advance, and, in general, 1 Mbps is considered "antisocial"
>> >> >within ESnet. The reason for this, which doesn't surprise me,
>> >> >is that although they have the bandwidth, their mrouted-based
>> >> >mrouter infrastructure can't handle loads much larger than that,
>> >> >and they have lots of operational users.
>> >> >
>> >> >
>> >> >In short, they would rather work with us to enable a PIM-only path
>> >> >from ANL to NREN.
>> >> >
>> >> >------------------------------------------------------------------
>> >> >
>> >> >Joe Burrescia <joeb@es.net> writes:
>> >> >
>> >> >> [...] sourcing an unbounded megabit multicast stream is
>> >> >> pretty anti-social. We do have users that make daily production
use of
>> >> >> multicast (both on and off ESnet) and this would be disruptive to
them.
>> >> >:
>> >> >> We (ESnet) has been pushing PIM out into our production network,
but we
>> >> >> are not totally there yet. In the ANL path, we have PIM running from
>> >> >> AMES to LBL but then dvmrp to llnl, lanl and finally ANL. We
>> >> >:
>> >> >> We have run internal high bandwidth multicast streams in the past,
but
>> >> >> we used administrative scope to contain them. You are right, most of
>> >> >> our links can handle this traffic without a problem, but the fanout
>> >> >> of the mrouters is the limiting factors. Over running these mrouters
>> >> >> will adversely effect the folks who are using the service in a
>> >> >> production manner.
>> >> >>
>> >> >> If you want to run some high bandwith rate tests please let us know
>> >> >> before hand so we can monitor what's going on (trouble@es.net is a
>> >> >> good place to send this type of mail in case I'm out).
>> >> >
>> >> >------------------------------------------------------------------
>> >> >
>> >> >
>> >> >Therefore, before turning up the bandwidth from ANL, we need to
>> >> >notify Joe Burrescia <joeb@es.net> and <trouble@es.net>.
>> >> >
>> >> >And, we need to pursue the PIM-only path anyway; ESnet is willing
>> >> >to work with us to enable that.
>> >> >
>> >> >
>> >> >Further additions, corrections, and comments welcome!
>> >> >
>> >> >
>> >> >Regards,
>> >> >Hugh LaMaster
>> >> >
>> >>
>> >> ************************************************************
>> >> Shelly Deixler
>> >> Senior Engineer - NREN Applications
>> >> NASA Ames Research Center
>> >> Mail Stop 233-10
>> >> Moffett Field, CA 94035-1000
>> >> USA
>> >>
>> >> mailto:mdeixler@mail.arc.nasa.gov
>> >> http://www.nren.nasa.gov
>> >>
>> >> 650-604-1329 (voice)
>> >> 650-604-3080 (fax)
>> >> ************************************************************
>> >>
>> >>
>>
>>
>>
>