[rbridge] Back to "what is the problem" for SVL/private VLAN/proxyARP stuff
Eric Gray (LO/EUS)
eric.gray at ericsson.com
Tue Apr 3 14:17:11 PDT 2007
I don't understand why you're asking this question.
It is - believe it or not - sufficient to say "we're doing
it that way because we like to, and we can."
Trying to analyze the specific problem that might, or might
not, be solved by using a specific technology is a mistake when
the technology is being used and nobody is especially interested
in hearing how their problems might be solved a different way.
I understand your frustration, but I don't see how getting
a grip on the problem is going to make any difference in what we
end up doing - so why waste our time on that particular subject?
> -----Original Message-----
> From: rbridge-bounces at postel.org
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Tuesday, April 03, 2007 3:23 PM
> To: rbridge at postel.org
> Subject: [rbridge] Back to "what is the problem" for
> SVL/private VLAN/proxyARP stuff
> I think the reason we are all so confused is that we
> (especially me) do
> not understand what problem
> we are solving. I wrote up in a previous note what I interpreted the
> problem to be. Let's be
> really tangible about it. I'll start. Correct me if you disagree. But
> don't use reference to other solutions
> or specs. It *can't* be that hard to actually describe it,
> rather than
> reference a spec, and without
> being explicit people won't realize when they are thinking of
> So...is this the problem?
> a) IP address block that has to be subdivided willy-nilly
> (not in clean
> sub-prefixes) among 4 customers
> b) desire separation of the customers. I'd like this
> expanded. Why? Is
> it because of not wanting
> to bother customer B with A's traffic, or that A doesn't want
> B to see
> A's traffic? Or both maybe.
> Do we know what these applications are?
> c) we want these communities to share some service node, say a DHCP
> server or an IP router
> d) we don't want modify the IP router to do anything special
> (I suspect
> this is not really true, and that
> the solutions people have in mind do require the IP router to
> know about
> this), or not much special
> e) (I'm throwing this one in). We don't want to have to configure
> anything (RBridges or IP routers) to know
> static mapping of IP addresses or MAC addresses to VLANs. The only
> configuration will be that an
> RBridge (or bridge) will be configured to say "this set of
> ports of mine
> are VLAN A, this set are VLAN B, ..."
> and it's by the tagging of packets transmitted from the port
> that other
> nodes learn which MAC addresses
> (or which IP addresses) are in which VLAN
> f) we want an IP endnode E_a in VLAN A to talk to an IP node
> E_b in VLAN
> B by being forwarded through the IP router. E_a and E_b are
> vanilla IP
> nodes and think they should be talking directly since they
> are in the same
> IP address block.
> g) maybe there are applications other than IP that want to have some
> sort of service node see all
> the traffic from all the VLANs, and be able to talk to all the VLANs,
> but not have the VLANs talk to each
> other. Is this true?
> rbridge mailing list
> rbridge at postel.org
More information about the rbridge