[rbridge] Preview of changes for VLANs, etc.

[Anoop Ghanwani]

> -----Original Message-----
> From: Russ White [mailto:riw at cisco.com] 
> Sent: Wednesday, November 07, 2007 3:53 AM
> To: Anoop Ghanwani
> Cc: Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Preview of changes for VLANs, etc.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > The subinterfaces are there because an RBridge is also a 
> bridge.  Just 
> > like a bridge has VLANs configured on ports, an RBridge 
> will also have 
> > VLANs configured on ports.  The reason this is needed is because we 
> > have to know which VLANs are configured on a port when we receive a 
> > multicast packet from another RBridge that needs to be forwarded on 
> > the port.
> 
> I don't see where this matters.... All that matters is which 
> egress devices are within the correct vlan for the multicast 
> packet you've just received. You are forwarding to egress 
> devices, not along vlans within the cloud.
> 
> IMHO, this is why this entire confusion has arisen.... You 
> don't need to forward along a given tree, and along a given 
> vlan, and glue vlans together.... Choose one, not all three. 

We don't forward along a tree except for multicast.
We don't glue VLANs together unless they have the
same VID.  And there's no way around that either.

> The entire point of rbridges is that the entire "core" of the 
> rbridge network forwards towards egress bridges, rather than 
> mimicking the virtual topologies along the edge.
> You're now introducing requirements to do both--treat the 
> core as a vlan free space, and only forward along vlans 
> within the core.
> 
> It makes no sense.

I disagree.  What is the point in sending traffic to
an egress RBridge if it is going to discard it anyway?
 
> > We are not talking about putting a random number.
> > We are talking about putting some VLAN ID that is configured on the 
> > port.
> 
> The phrase "some random vlan number, just to get the packet 
> through the LAN," has been used multiple times on list. 

Well at least I have never used that, so I'll let
others who have proposed that I idea defend it.

> Second, restricting all traffic flowing between any set of 
> rbridges on a single link to one vlan across that link makes no sense.

Then you will have the problems for multicast pointed
out by Radia in an earlier email.
 
> >> Routers operate exactly as I described previously. If a router 
> >> receives a packet on an interface, it will:
> >>
> >> 1. Find the next hop, by looking at the tree.
> >> 2. Figure out the outbound interface.
> >> 3. Encap the packet with the correct layer 2 header for that 
> >> interface.
> >> 3a. If the outbound interface is a subinterface, the layer 
> 2 header 
> >> will include, of course, a vlan header.
> >> 3b. If the outbound interface is not a subinterface, the layer 2 
> >> header will not include a vlan header.
> > 
> > I agree with this.
> 
> Then you don't need all this vlan stuff in the middle. You 
> are forwarding through the underlying cloud to the address of 
> an egress device. That address should be in the tunnel encap 
> once the packet enters the cloud.

You deleted my nice picture with the routers discussing
the tagging/untagging issue.  You have to follow the
tag/untag rules of the intermediate bridged clouds.
You don't need it if there is no intermediate cloud.

> It appears we are creating different forwarding rules for 
> multicast than for unicast, without considering the 
> implications of such alternate rule sets on the forwarding 
> hardware, or the simplicity of managing and troubleshooting 
> this stuff.

If you have suggestions, we are all ears!  But
your proposal must be complete.  We have spent
_months_ on the list discussing these issues and
we're starting to revisit them all over again.

Anoop