[31851] in North American Network Operators' Group
Re: Service Provider Exchange requirements
daemon@ATHENA.MIT.EDU (Christian Kuhtz)
Tue Oct 24 05:56:10 2000
Date: Tue, 24 Oct 2000 05:54:14 -0400
From: Christian Kuhtz <ck@arch.bellsouth.net>
To: nanog@merit.edu
Message-ID: <20001024055414.D6868@ns1.arch.bellsouth.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <200010231253.FAA28571@nemo.corp.equinix.com>; from hardie@equinix.com on Mon, Oct 23, 2000 at 05:53:17AM -0700
Errors-To: owner-nanog-outgoing@merit.edu
On Mon, Oct 23, 2000 at 05:53:17AM -0700, hardie@equinix.com wrote:
> One reason we've looked at is the ability to seperate multicast
> traffic from unicast traffic without having to have seperate physical
> media. In general, it can be used whenever you want to keep some
> traffic out of the way of other traffic. Another possible reason
> along those lines for ethernet based exchanges would be allowing jumbo
> frames on some VLAN seperate from the basic shared-media exchange.
> regards,
> Ted Hardie
And aside from the other thread that spun off from this about the technological
pro's and con's around mcast, perhaps there's another line of thinking to
consider...
Having seperate VLANs or otherwise "planes" may help a great deal
operationally, by being able to introduce a ucastv4, mcastv4, ucastv6,
mcastv6, etc etc.. place. (as long as you can keep the overhead down of
actually running the "planes" themselves). Has anyone gone thru the exercise
of worrying about such a thing/beast?
Cheers,
Chris
(and before anyone flames me for not saying it, imho, the point about jumbo
frames is moot. no flame intended.)
--
Christian Kuhtz Architecture, BellSouth.net
<ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Atlanta, GA
"Speaking for myself only."
