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)
> >> ************************************************************
> >>
> >>
>
>
>