[rbridge] Orphaned endnodes with partitioned VLANs on a cloud

[Eastlake III Donald-LDE008]

Hi Russ,

See below at @@@

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Russ White
Sent: Sunday, December 09, 2007 2:27 PM
To: Radia.Perlman at sun.com
Cc: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a
cloud

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Russ, I think a way of thinking about it that might be clearer is
first to pretend there are no VLANs.
> We want there to be just a single RBridge that forwards traffic
to/from the link. 

What you're talking about here is edge ports, though, not links in the
middle of the cloud--I think there's a radical difference between the
two. The edge case can be solved more easily than what you describe
below--I'm waiting on some validation from some other folks before
sending out a list of ideas to the list.

As for the link in the cloud, I don't think this is a case that we
should worry about.

@@@ First, I think Rbridges should work for general topologies. Second,
our charter speaks of incrementally deployablity. You may be
incrementally deploying Rbridges into what was a bridged network. You
could eventually end up with all Rbridges. But many intermediate states
would have bridged LANs between the Rbridges. Some phrases extracted
from our charter: "... arbitrary topologies ... ensure that the solution
can interwork with bridges in a flexible manner ... incremental
deployment into LANs ...". So I think we do need to worry about that
case, although I don't see anything wrong with being able to configure a
link to be a point-to-point link between Rbridges, provided you also
include some reasonable sanity checks so if you receive frames
inconsistent with the link being a direct point-to-point connection
between Rbridges you will notice and take appropriate action.

> But anyway, now let's look at VLANs on the link. Because of bridges,
any VLAN might be partitioned with
> respect to data traffic, for various reasons.  The WG discussed this
at length, and it looked to me, and I strongly
> agree with this -- that TRILL should consider partitioned VLANs on a
link as a misconfiguration, and should
> make sure they are defensive against it (not creating loops), but
should not worry about healing
> all the partitions.

The current proposal heals partitioned VLANs, from what I understand of
it, intentionally--at least on the links in the cloud. This is what I
specifically think we should avoid doing.

@@@ It's not that simple. Healing partitioned VLANs can mean two things:
partitioned on a link or partitioned between different links, where
"link" may be a bridged LAN.

@@@ The current proposal does not heal a VLAN that is partitioned on a
single link. As far as I know, that could only happen due to the link
being a bridged LAN and the bridge or bridges within it being configured
to partition the VLAN. Since, for simplicity, there is only one Rbridge
forwarding on-to/off-of the link for any particular VLAN, such a
partitioning is considered a misconfiguration and can result in orphaned
nodes.

@@@ The current proposal does heal a VLAN that is partitioned between
different links.  That is, the incremental deployment of Rbridges may
cause what were separate islands of a VLAN in a bridged network to
become connected. The original existence of such islands can also be
considered a misconfiguration or at least a violation of the spirit of
802.1Q, although I'm sure you can find those who would dispute this
view. This island interconnection just happens automatically because of
the global view Rbridges have through the link state database. It would
require more complexity and configuration to keep such islands separate.
Since Rbridges are routing on VLAN ID and MAC address, how would they be
supposed to know there are supposed to be two separate islands of VLAN
X? Seems like you would need to extend the VLAN ID with an island ID or
something. Given Rbridges are required by our charter to be able to
capable of operating with "Minimal or no configuration" the WG has thus
far decided not to go with such "VLAN island IDs" or any similar
mechanism, which in any case would only work with extra configuration
and be more complex.

@@@ If a bridged LAN link between Rbridges is misconfigured to partition
a VLAN, it isn't healed because to do so would make things more complex
and less safe. And if a VLAN is partitioned between separate links that
connect to Rbridges, it is healed because to not do so would make things
more complex and would require additional configuration.

@@@ None of these questions arise, of course, in an all Rbridge LAN or
one where any remaining bridges are configured to provide VLAN
connectivity.

Let's begin with this: rbridges don't care about the state of the links
between rbridges, they only care to solve possible loops for edge ports.

@@@ As above, Rbridges must consider the case where the links between
Rbridges are bridged LANs. Also, it is my impression that a number of
TRILL WG members consider loops to be so harmful that Rbridges need to
take reasonable precautions against them everywhere, not just on "edge"
ports, whatever you consider such ports to be. So I don't see how we can
begin where you suggest we begin.

> The RBridges have to stick some VLAN tag on packets when they
> talk to each other.  

Actually, the don't, from what I understand. They could talk native on
the media, or they could use a vlan, depend on how they're configured.

@@@ Well, they could emit untagged TRILL frames. Note that you are using
the word "native" in a different way that it is used in the TRILL WG and
protocol document. Here "native" currently means any data frame that
isn't encapsulated with the TRILL Ethertype, as opposed to a TRILL frame
which does have the TRILL Ethertype encapsulation. Whether or not the
frame is VLAN tagged is orthogonal to whether or not it is native in
this sense.

@@@ Also, assuming an 802.1Q sort of network, conformant with Annex E of
802.1Q-2005, then I think it is reasonable to think of all frames,
whether they are VLAN tagged or not, as being in/on a particular VLAN.
It is certainly the case that data frames inside an 802.1Q bridge always
have a VLAN ID associated with them. If the frame was untagged on the
wire but was admitted, then the port through which it was admitted
associated a VLAN ID with that frame. And, if the network is Annex E
conformant, all ports attached to that wire which will admit untagged
frames are required to be configured so as to associate the same VLAN ID
with the frame. So it might be reasonable to consider the frame to be in
that VLAN even when it is transiting untagged on the wire.

...

> Personally, I think we should leave the spec the way it is. It was a
careful balancing act between overhead and
> safety, plus supporting features such as load splitting based on
VLANs.

The problems with the current mechanism are:

1. It doesn't solve what it was intended to solve.

@@@ I think it does a reasonable job of solving the problem it was
intended to solve: "... a solution for shortest-path frame routing in
multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary topology
..." I think that, when combined with the incremental deployment
requirement, necessitates consideration of intervening bridges.

2. When it does work, it has unintended side effects.

@@@ How is anyone supposed to know what side effects you are talking
about?

...

@@@ Thanks,
@@@ Donald

Russ

- --
riw at cisco.com CCIE <>< Grace Alone