[rbridge] Back to "what is the problem" for SVL/private VLAN/proxyARP stuff

[Eric Gray (LO/EUS)]

Radia,

	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?

--
Eric Gray
Principal Engineer
Ericsson  

> -----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 
> different 
> things.
> 
> 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
> http://mailman.postel.org/mailman/listinfo/rbridge
>