Subject: [rbridge] VLAN tag for the encapsulated packets

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

Saikat,

	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:32 PM
--> To: 'Radia Perlman'; 'Developing a hybrid router/bridge.'
--> Subject: Re: [rbridge] VLAN tag for the encapsulated packets
--> 
--> > -----Original Message-----
--> > From: Radia Perlman [mailto:Radia.Perlman at sun.com]
--> > Sent: Tuesday, March 14, 2006 1:08 PM
--> > To: saikat at seas.upenn.edu; Developing a hybrid router/bridge.
--> > Subject: Re: [rbridge] VLAN tag for the encapsulated packets
--> > 
--> > Do you mean on the outside header? 
--> 
--> Yes.
--> 
--> > I was assuming no tag. We want all bridges that might be on an
--> > intermediate link to be willing to forward the packet.
--> 
--> 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"? If they do not, which spanning 
--> tree would they use for a packet with no VLAN tag? The issue 
--> is that if there is no entry in the forwarding tables for 
--> the legacy bridges, then the encapsulated packet needs to be 
--> broadcast; in that case in order to avoid a loop, one perhaps
--> needs to ensure that either (i) the broadcast packet is 
--> carrying a VLAN ID (which could be put in by the legacy 
--> bridges) so that the packet always goes along a given 
--> spanning tree, or (ii) the superposition of the different
--> spanning trees is still a spanning tree. Otherwise if the 
--> packet goes from one spanning to another spanning tree, then 
--> loops are possible.

It is because of this kind of discussion that we have decided
to use some term other than "spanning tree" for the way that
frames are forwarded between RBridges in flooding, multicast
and broadcast cases.

The term we are currently using (and encouraging others to use)
is "Ingress RBridge Tree".

What happens is that each RBridge along the path has forwarding 
entries determined for distinguishable frames.  The basic entry
is simply determined from the Link-State Routing protocol and
the local RBridge's current view of topology and shortest paths.
In the flooding, multicast and broadcast cases, distinguishing 
factors include the ingress RBridge (the source MAC in the outer 
header) and the VLAN context (tag, most likely) - at least 
primarily.

For multicast optimization, a local RBridge will likely also
include the multicast destination as a part of the look-up
and corresponding forwarding entries will be pruned based on 
some approach that is not in scope for this working group (but 
will likely involve snooping of multicast control protocol 
exchanges).

For Flooding Optimization, a local RBridge may decide to peek
inside the outer header to determine if it has a unicast entry
for the MAC destination of the inner MAC header.

Optimizations are not required behavior. However, the ability
to form and use the "Ingress RBridge Tree" mechanism is.

--> 
--> > 
--> > But now that you asked...I suppose it's possible that 
--> > there might be a link where bridges might do something 
--> > weird if there is no tag (as in, add a tag, or refuse
--> > to forward it).
--> > I guess on a link like that, there would have to be a tag.
--> 
--> Isn't there a significant configuration burden (at least 
--> similar to VLAN configuration)? E.g., how will an RBridge 
--> know which VLANs are present in the legacy LAN it is 
--> connected to? The second problem is  that a given VLAN
--> may not connect two RBridges and thus, depending up on the 
--> next hop, the current RBridge may need to choose different 
--> VLAN IDs.  Which then means that RBridges need to maintain 
--> different forwarding tables (e.g., for "link-cost") per 
--> VLAN. Is that how the system work?

The fact that VLAN configuration may be required is endemic
in your question about support for VLAN tags.  VLAN tags are
not required in the RBridge solution, except to support VLANs.
To the extent that configuration is already required for this,
it is still required for RBridges.

Either we want to avoid configuration and hence - most likely
- we avoid VLANs, or we want to support VLANs and we accept
that doing so requires no less configuration that it has in
the past.

--> 
--> > The outer header is really a hop-by-hop header, so it 
--> > should be whatever is appopriate to that hop. In theory 
--> > we could mix media, and have an intermediate link which 
--> > isn't even Ethernet, say it is link type L, in which 
--> > case the outer header would be an L header.
--> 
--> I agree.
--> 
--> > At any rate, if an intermediate bridge really did 
--> > decide to add a VLAN tag to the outer header, the
--> > next RBridge will remove the outer header anyway, 
--> > and generate a new outer header for the next hop.
--> > 
--> > Radia
--> > 
--> 
--> Yes, but the issue is with connectivity. If an intermediate 
--> legacy bridge adds a VLAN ID, is it guaranteed that the next 
--> RBridge would get the (encapsulated) packet (i.e., is it 
--> possible that the legacy bridge puts in a VLAN ID whose span 
--> does not include the next RBridge?)?

This is no more likely than it would be in a deployment that
only includes VLAN bridges.  This is a configuration error.
It is generally accepted that it is impossible (or at least
very difficult) to protect against arbitrary configuration 
errors in a protocol.

--> 
--> Thanks.
--> 
--> Saikat
--> 
--> > 
--> > Saikat Ray wrote:
--> > 
--> > >Hi All,
--> > >
--> > >I was wondering which VLAN tag will there be (if there 
--> will be any) on
--> > the
--> > >encapsulated packets.
--> > >
--> > >Thanks in advance for your answers.
--> > >
--> > >With regards,
--> > >
--> > >Saikat
--> > >
--> > >_______________________________________________
--> > >rbridge mailing list
--> > >rbridge at postel.org
--> > >http://www.postel.org/mailman/listinfo/rbridge
--> > >
--> > >
--> 
--> _______________________________________________
--> 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:31:22 -0500

> 	Please see in-line below...

Please see my next email. I am not talking about the "Ingress RBridge Tree"
that is built by viewing each legacy LAN as a "link"; I am talking about a
single given legacy LAN (which is a single "link" at the level of RBridges)
and the spanning tree(s) in that legacy LAN.

To rephrase my question: Consider a legacy LAN (and for the moment, forget
about RBridges). Suppose that some "physical" links of this legacy LAN are
marked as VLAN1 and the rest are marked as VLAN2. Then my first question was
how many instances of spanning trees will there be in this legacy LAN? Just
one? One per VLAN (i.e., two)? One per VLAN + one for the packets with no
VLAN ID (i.e. three)? I have been told that the right answer is one per VLAN
(i.e., two); but I do not know for sure and want to confirm.

Now consider two RBridges attached to this legacy LAN, R1 and R2. Now
consider the case when R1 sends the first packet to R2 which have no VLAN
ID. At that time the legacy bridges on this legacy LAN do not have an entry
for the MAC address of R2 on their forwarding database. Thus they need to
broadcast on the legacy LAN. Which spanning tree will they use (I am
assuming that there are two instances of the spanning tree, one for VLAN1
and the other for VLAN2)? Now suppose that VLAN1 does not connect R1 and R2.
Then if R1 sends a packet for R2 with VLAN ID set to VLAN1, or if the legacy
bridges use VLAN1 for sending a packet with empty VLAN tag, then how will R2
get the (encapsulated) packet from R1? Put it differently, how will R1 know
that it must use VLAN2 as the VLAN ID to reach R2?