[rbridge] Preview of changes for VLANs, etc.

[Eric Gray]

Anoop,

	When you talk of an implementation that allows for sending
and receiving frames for multiple VLANs in a single interface, I
strongly suspect that this is because your model for what "logical
interfaces" are is different.

	If you define a logical (Ethernet) interface as being - for 
example - qualified by the MAC address and a specific VID, than
it is non-sensical to talk about having multiple VLAN associations
via that logical interface.  Many implementers use the term logical
interface exactly this way.

	On the other hand, if you define logical (Ethernet) interfaces
by MAC address alone - or perhaps using some distinguishing factor,
other than VID - then what you are saying is not incorrect.  

	I wonder, though, how useful that model is from an implementer
perspective.  VID is - with the exception of the SVL case - integral
to the forwarding context associated with any frames received on any
interface (and - obviously - the same would apply when sending, since
there is a similar implied context at the next receiver).  

	Hence - from the perspective of making a forwarding decision -
receiving a frame on a different VLAN is not different from receiving
it on a completely different physical interface.

	What can an implementer gain from distinguishing "forwarding 
context" from "logical interface"?

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani
> Sent: Tuesday, November 06, 2007 8:39 PM
> To: Russ White
> Cc: Developing a hybrid router/bridge.; Radia Perlman
> Subject: Re: [rbridge] Preview of changes for VLANs, etc.
> 
>  
> 
> > -----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 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>