Subject: [rbridge] VLAN tag for the encapsulated packets

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 14 Mar 2006 14:37:52 -0500

Saikat,

	I may have answered this question in my previous mail,
but let me make sure.  Please see in-line below...

--
Eric 

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Saikat Ray
--> Sent: Tuesday, March 14, 2006 1:55 PM
--> To: 'Radia Perlman'
--> Cc: 'Developing a hybrid router/bridge.'
--> Subject: Re: [rbridge] VLAN tag for the encapsulated packets
--> 
--> Saikat:
--> =======
--> > > I have a basic doubt about it. My understanding is (and 
--> > > this could be plain wrong; please correct me if that is 
--> > > so) that there is one instance of spanning tree per VLAN 
--> > > ID. Then do bridges also create another spanning tree
--> > > instance for the "blank ID"?
--> > >
--> Radia:
--> ======
--> > Just want to clear up this misunderstanding. There is one 
--> > spanning tree per ingress RBridge.

This is an "Ingress RBridge Tree".

--> > This spanning tree is then pruned according to VLANs, as 
--> > well as IP multicast addresses. 

Standard Disclaimers: 

VLAN optimization may require explicit configuration.

Multicast address pruning is an optional optimization.
Note that multicast address pruning - while driven by
an association between an IP multicast address and a
corresponding MAC multicast address - will hinge on a
MAC multicast address in forwarding.

--> 
--> Saikat:
--> =======
--> This is at the level of RBridges (i.e., viewing the legacy 
--> LANs as "links"), right? My concern was about a given legacy 
--> LAN segment (which is a single "link" at the level of RBridges). 
--> 
--> Suppose that there are two VLANs on this legacy LAN, VLAN1 and 
--> VLAN2. Now there are two RBridges, R1 and R2, connected to this 
--> legacy LAN. Moreover, suppose that the "physical link" that 
--> connects R2 to this legacy LAN (i.e., to some legacy bridge) is 
--> on VLAN2, but not on VLAN1. Then, what happens when R1 sends 
--> an encapsulated packet to R2 with
--> 
--> i) No VLAN ID, and
--> 
--> ii) With VLAN ID set to VLAN1?
-->

First, we should avoid the term "legacy LAN".  It is well known
that the term "legacy" carries a lot of undesirable freight.

In this case, you are talking about a LAN segment that is a
link between RBridges R1 and R2.  Presumably is has other
connectivity as well (hosts, routers, other RBridges, etc.).

R1 and R2 can be either VLAN aware or not.  In order to work
in this scenario, if either of these is VLAN unaware, MAC
addresses must be unique within the LAN context - but this is
the case whenever VLAN un-aware bridges are used in a VLAN 
context.

In scenarios like this, if the RBridges are intended to be
VLAN aware (and behave accordingly) then they require all of
the same VLAN association information that any other VLAN
aware bridge would require.  Similarly, if the RBridges are
not intended to be VLAN aware (and behave accordingly) then
they will deliver VLAN tagged frames on links they would not
if they were VLAN aware.

The same observation applies within the LAN segment.  VLAN
un-aware bridges may deliver frames to an RBridge that does 
not need to receive them.

This is a problem that exists with or without RBridges.  We
cannot prevent people from making errors - in configuration 
or deployment.

These "errors" result in sub-optimal performance - possibly
to the point of pathological failure - but are not themselves
inherently pathological.

--> 
--> And, finally what happens when R1 sends an encapsulated 
--> packet to R2 with no VLAN ID and the legacy bridges on this 
--> legacy LAN do not know about the location of R2?

R2 has a MAC address.

--> 
--> Isn't there a possibility that R2 would not get the packet 
--> in the previous scenarios?

No.

--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->

---

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Tue, 14 Mar 2006 14:52:50 -0500

> connectivity as well (hosts, routers, other RBridges, etc.).

First, how many spanning tree instances will there be in this LAN segment if
some physical links (ports of legacy bridges) are marked as VLAN1 and the
rest as VLAN2?

> the case whenever VLAN un-aware bridges are used in a VLAN

That's fine. I assume that each RBridge has a globally unique MAC address.

> aware bridge would require. 

More than that. They need to maintain separate "link-cost" (and thus
separate forwarding decisions) to the neighboring RBridges for different
VLAN IDs. The set of "neighboring RBridges" would be different depending on
the VLAN ID.

> Similarly, if the RBridges are

That's the problem. How do legacy handle a packet that has no VLAN ID?

[snip]

> --> legacy LAN do not know about the location of R2?

I understand that. But the legacy bridges may not yet have "learned" that
MAC address; i.e., in the forwarding databases of the legacy LANs, that MAC
address may not exist. In that case the legacy bridges must broadcast the
packet on to every port that belongs to "a spanning tree" except on the one
where it received the packet. Now this is the issue: the spanning tree, no
matter whichever it is, must be the same on every legacy bridge to avoid the
possibility of a loop. How is it done?

> --> in the previous scenarios?

There is a possibility if there are multiple spanning trees (one per VLAN
ID) in the LAN segment. Hopefully my previous example will make it clear.