[rbridge] Preview of changes for VLANs, etc.

[Anoop Ghanwani]

> -----Original Message-----
> From: Russ White [mailto:riw at cisco.com] 
> Sent: Tuesday, November 06, 2007 4:09 PM
> 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
> 
> 
> > - For ports that support both bridged and TRILL
> >   traffic we have to go with what 802.1 says
> >   (otherwise the traffic won't go through bridges).
> > 
> > Thus far, all RBridge ports are assumed to be 
> > of the last type.  That means the encapsulation has
> > to follow rules defined by 802.1 - i.e. you have
> > a set of VLANs on that port.  We only transmit
> > traffic on those VLANs.  Some of those VLANs belong
> > to the "tagged set" in which case we transmit frames
> > for those VLANs in tagged format; other VLANs belong
> > to the "untagged" set in which case we transmit 
> > frames without a tag.
> 
> In all implementations that I know of, such interfaces are always:
> 
> 1. Trunk ports, which I've already covered.
> 2. A single physical interface with multiple logical "subinterfaces."
> 
> Can you point to a single case where a device can send multiple vlan
> traffic on a single logical interface, or where it treats a single
> interface as a link with multiple vlans while not calling it 
> a "trunk,"
> and putting special operational rules around it (such as no end host
> devices)?

We must be talking past each other because I'm
not sure what the above comment is getting at.
Nowhere have I talked about "multiple VLAN
traffic on a single logical interface".  Please
give me the full context if possible.

By the way, trunk ports in one large, prominent
vendor's implementation is a subset of the 
standard.  The 802.1 document does not talk
about trunk ports at all, and on a given port
you can have any bunch of VLANs, some of which
are tagged and some of which are untagged.  
And this is different that the "trunk port".

> > I think what we have defined so far is fine.
> > There is no need to change it.  Making it optional
> > won't work.
> 
> What has been defined so far is very complex--you're recreating
> subinterfaces without subinterfaces, for no reason I can see.

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.
 
> > Even routers have to follow those rules or
> > their packets don't make it through the LAN!
> 
> Routers don't follow these rules.... They don't simply put 
> "some random
> vlan number" on any packet they are transmitting to "get the packet
> through the LAN." There is no "common vlan" assigned to each link to
> allow routers to communicate. There is no concept of a "single hello"
> for multiple virtual topologies on a single link, with all sorts of
> stuff added so everyone on the link knows which virtual 
> network everyone
> else is on.

We are not talking about putting a random number.
We are talking about putting some VLAN ID that is
configured on the port.

> 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.
 
> Whether or not there's a vlan tag that needs to be added plays no part
> in the forwarding decision.

That is correct...however, as you note in 3, 3a, 3b,
you have to know the interface that you're forwarding
the packet on.  That interface, in the RBridge world,
is a VLAN on a specific port (for unicast) or a \
VLAN on a set of ports (for multicast).

> IMHO, rbridges _should_ operate as much like routers as 
> possible, rather
> than using some new forwarding paradigm. Once the traffic is 
> placed in a
> tunnel, it should be carried--as much as possible--just like an IP
> packet is carried.

So if I have the following configuration:
(R1) <---(vlan1)---> (R2) <---(vlan1)---> (R3)
the packets between the routers could either
be tagging the frames or not and that depends
on the configuration of the port in question.
(In the implementation you are familiar with,
untagged would mean there is no subinterface,
and tagged means there is a subinterface with
a tag of 1.  Just because I have a subinterface
in the latter case, does not mean another 
subinterface must exist on that router port.)

Anoop