Subject: [rbridge] VLAN hopping: firewall on a stick

From: Kris Price <[email-masked]>
Date: Sat, 14 Mar 2009 12:38:51 +1300

Hi,

I asked about this last year, but at the time I was more interested in 
the use of MPLS. I'm hoping I am just misunderstanding something here, 
but my reading of TRILL is that it bypasses the configured policy, and 
enables a kind of VLAN hopping.

Is it possible to send a frame with an inner VLAN tag across a link that 
does not ordinarily permit that VLAN tag?

I'll try to explain with an overly-simplistic case.

*Diagram*

     Office floor : Server room
     ------------ : -----------
                  :
   +---Sw1---+         +---Sw2---+
   | [Vlan1]-|--Vlan1--|-[Vlan1] |
   +---------+         | [Vlan2] |--dot1Q--[Firewall]
                  :    +---------+
                  :        |
                  :      dot1Q
                  :        |
                  :    +---Sw3---+
                  :    | [Vlan1] |
                  :    | [Vlan2] |
                  :    +---------+

Traffic between VLAN 1 and VLAN 2 must go via the firewall.

Sw3 is reaching EOL so a smart thinking engineer decides to replace with 
an RBridge. At first there is no problem because the engineer configures 
the RBridge to only allow the correct VLANs on the access ports. Traffic 
between VLAN 1 and VLAN 2 must still go via the firewall.

An unscrupulous individual comes on the scene and connects an RBridge to 
Sw1 which is accessible, or simply emulates an RBridge on her PC, either 
way there are now two RBridges seeking each other out across VLAN 1. She 
can bypass the firewall to reach VLAN 2, sending packets via the RBridge 
that replaced Sw3.

Do I understand right?

Regards

Kris
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 14 Mar 2009 14:10:20 -0400

Hi,

> does not ordinarily permit that VLAN tag?

Yes. It's a feature mentioned a few places in the protocol draft.

The TRILL view, as stated in the draft, is that a VLAN represents a
layer 2 community and that all end stations in that VLAN within a
campus should be able to get to each other. Many people believe that
is the spirit of 802.1Q and is why, in 802.1Q, dynamic VLAN
registration is mandatory to implement and is the default for almost
all VLANs on almost all ports, so that all end stations in a VLAN are
connected. Anyway, if there are two or more islands of a particular
VLAN in a bridged networks, replacing enough of the bridges with
RBridges will heal the partitioning of that VLAN.

>     Office floor : Server room

I find your diagram very confusing. Does "dot1Q" in the middle of a
link means that frames on that link are VLAN tagged? Does a list of
VLANs inside a box means that the ports of that box which are shown
are configured to enable output of frames in that VLAN (except perhaps
for the horizontal link between Sw1 and Sw2 which has "Vlan 1" in the
middle of it, presumably meaning that the ports at both ends are
configured for VLAN 1 only?)?

Is this Firewall an end station? Why do frames go to the firewall? Are
they addressed to it? Couldn't any end station connected to Sw2 or Sw3
do VLAN mapping on frame it receives?

> between VLAN 1 and VLAN 2 must still go via the firewall.

If you are replacing a bridge with an RBridge, of course you have to
do the same VLAN configuration on its ports as the bridge ports had.
And, unless you are using the optional RBridge VLAN mapping feature
(see draft-ietf-trill-rbridge-vlan-mapping-00.txt), you can only map
frames from one VLAN to another via an end station or by using port
configurations so a VLAN tag gets stripped on transmission and a
different tag added on receipt.

> can bypass the firewall to reach VLAN 2, sending packets via the RBridge

I don't really understand what you mean by "reach VLAN 2". First of
all, if someone "unscrupulous" attaches a hardware or software RBridge
and you have no TRILL IS-IS security, you're pretty well screwed
anyway. See the Security Considerations section of the protocols
draft. Second, if you mean they can send a VLAN 1 frame that would be
delivered to a VLAN 2 end station which is attached to an RBridge port
where only VLAN 2 is enabled, I don't see why you think that. There
seems to be vast amounts of detail you are assuming and not
describing.

> Do I understand right?

Probably, although I'm not sure. Try looking at Section 2.3, 4.1.2,
and 6.1 of draft-ietf-trill-rbridge-protocol-12.txt.

> Kris

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: Kris Price <[email-masked]>
Date: Sun, 15 Mar 2009 19:25:45 +1300

Hi Donald,

> RBridges will heal the partitioning of that VLAN.

I think I understood the TRILL view on VLANs, but it didn't seem to 
align to my understanding of 802.1Q or the real world networks I've 
worked on and seen.

802.1Q does permit VLAN topologies to be constrained or partitioned 
through the use of management controls (i.e. by allowing or denying 
VLANs on links). This comes through clear to me in the standard but 
anyone please feel free to disabuse me of this belief if it's wrong. 
Either way it certainly comes through clear in practise.

So I think you've confirmed my suspicion for me, along with section 6 of 
the draft. If I'm not wrong, is this behaviour such a good idea? I'll go 
into a bit more detail.

> I find your diagram very confusing. Does "dot1Q" in the middle of a
[snip]

So much for my attempt at simple. :) This can actually be broken down 
into an even simpler case, so I'll change tack a little bit.

I am concerned that TRILL appears to take the view that removing 
partitions is OK when they are often there for a very good reason. These 
kinds of partitions are also *very* far from infrequent.

   +----+         +----+         +----+
   | B1 |--dot1Q--| B2 |--dot1Q--| B3 |
   +----+         +----+         +----+

B1 is in an untrusted location so from a security perspective should be 
treated as potentially compromised. The administrator wants to control 
access to VLAN X so disallows VLAN X on the dot1Q trunk between B1 and 
B2. Rightly or wrongly this is very common.

In a situation where B1 and B3 are replaced with RBridges is it possible 
for B1 to bypass the restriction configured on B2 and access any VLAN on 
the network?

It looks to me like B1 can send an TRILL data frame with an inner VLAN 
tag X over the Designated VLAN to B3, and B3 will decapsulate it and 
forward the encapsulated frame quite happily.

Clearly TRILL cannot assume that every RBridge is trusted. There may be 
administrative divisions and all kinds of things, let alone determined 
attackers. Just as a provider would not place a PE router on an unsecure 
customer site, because if compromised they have the keys to the kingdom.

> draft. Second, if you mean they can send a VLAN 1 frame that would be
[snip]

This seems very dangerous to me. In an 802.1Q network you are not so 
screwed when someone attaches or compromises a device because people do 
this kind of filtering for that very reason.

I think it is important for TRILL to err towards safety and security. 
(Actually, I see it's a goal not to be less secure.)

*Solutions*

Without thinking too hard about it, here are some possible solutions 
that may have other serious problems with them of course. :)

The hard fix would be to copy the inner VLAN tag to the outer VLAN tag. 
Thus the frame could still only travel on the same links it could in a 
pre-RBridge deployment.

The drawback would be that the shortest path may traverse a bridge where 
this VLAN is filtered and so frames are dropped, whereas prior to the 
RBridge deployment the spanning tree for that VLAN allowed communication 
to continue via the long way around.

But this is much safer, and it is very much more realistically caused by 
a misconfiguration than in the other case of filtering. When it happens, 
it's most likely because the engineer allowed the VLAN on some other 
link, communications worked because that was the spanning tree route, 
and he forgot to allow it on this shortest path as well. Such a failure 
should come up during deployment within the outage window, and it isn't 
hard for the engineer to understand what is going on. Quite simply he 
can see packets on VLAN X are being dropped between his shiny new 
RBridges, he looks at the network and sees VLAN X is blocked on a trunk. 
To him the VLAN forwarding behaviour of RBridges and Bridges remains 
similar. He doesn't have to understand that some VLAN X frames now 
travel on VLAN 1.

The *soft* solution is probably to use something like the protection 
Hello's with the outer VLAN tags. An RBridge will drop frames if they 
arrive with an inner VLAN tag from another RBridge which it hasn't seen 
a protection Hello from with that as the outer VLAN tag. It knows then 
that that RBridge can't send frames with that VLAN tag to it because it 
never got a Hello on that VLAN, so why should it see frames with the 
inner tag, it shouldn't, and should be respectful and drop them.

But this is fairly soft and subject to spoofing and the like. It may be 
possible to do something cryptographically to ensure that packets aren't 
spoofed, but this adds complexity and configuration.

The third option is a configuration option if the implementation of 
RBridges permits. The engineer should, provided he understands TRILL and 
his network well enough, be able to add inner VLAN filtering on the 
appropriate Designated VLANs. Thus he could filter VLAN X on the 
designated VLAN on B3 that links through B2 to B1. The filter would look 
at the inner tag of arriving TRILL data frames, and discard VLAN X.

A fourth option might be something like MST-like regions, where TRILL 
only does TRILL on RBridge-RBridge links. Might require the TRILL region 
appearing as a bridge for the purpose of STP, or RPF checks and the like 
to get around potential looping issues. But does mean that you can have 
different admin domains too.

> and 6.1 of draft-ietf-trill-rbridge-protocol-12.txt.

I coudn't see anything prohibiting this in the sections you mentioned, 
other than to confirm my concerns, which is possibly described (but a 
little unclearly to me) in section 6.

*Digressing a bit*

Forgive me if I am well off the reservation saying this. Saying the 
following as an outsider with possibly fresh eyes:

I think TRILL must be careful not end up sold as requiring similar or 
less configuration than bridges, especially in terms of replacing 
bridges with RBridges.

I've heard zero-conf and simplicity mentioned quite a bit as a goal, but 
it seems to only apply to greenfields deployments, and even then perhaps 
not always.

TRILL's behaviour is unlike anything else. It neither behaves like 802.1 
bridges that people have become accustomed to, or routers in that it 
treats all VLANs on an interface as the same link. Its deployment 
requires a reasonable level of TRILL specific knowledge. One of the 
things I thought TRILL was about was making safe networks by default. So 
if every engineer who was deploying these was at a level of 
understanding and working with the potential caveats of TRILL, we'd have 
lots of really good engineers and have less need for TRILL in most 
environments.

So is TRILL perhaps now targeted more at scale out clusters and 
greenfields, perhaps with an eventual trickle down to the existing 
enterprise, and so on, as prices drop and engineers become more 
comfortable with the technology? If so perhaps it would benefit 
significantly from a recognition of that and study of what effect it 
could have on the protocol.

Regards

Kris

---

From: Caitlin Bestler <[email-masked]>
Date: Sun, 15 Mar 2009 12:13:39 -0700

> kinds of partitions are also *very* far from infrequent.

I am not following how B2 is supposed to be enforcing a restriction.

A frame that belongs to VLAN X can only be originated on an endstation
that belongs to VLAN X, and 802.1Q Bridges enforce that.

A frame that belongs to VLAN X can only be delivered to an endstation
that belongs to VLAN X, and again 802.1Q Bridges enforce that.

Bridges also seek to avoid forwarding frames to locations where they
cannot be delivered to any endstations -- but that's a matter of 
optimizing network utilization.

All of the above is also true for RBridges.

If B1 and B3 both are members of VLAN X then it is appropriate for
frames originated in B1 to be delivered in B3, no matter what B2 thinks.
If "VLAN X" in B1 and "VLAN X" in B3 are different networks then they
should have different VLAN IDs.

Even without RBridges, any *new* path between B1 and B3 can bypass
B2's attempt to partition VLAN X into two VLANs. If you two VLANs
are distinct, use different VLAN IDs.

-- 
Caitlin Bestler
[email-masked] - http://www.asomi.com/CaitlinBestlerResume.html
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Radia Perlman <[email-masked]>
Date: Sun, 15 Mar 2009 12:32:39 -0700

Although it's good to have people look at things with a fresh eye, part 
of the problem with looking at it
so late is that some decisions might have been made that you might 
disagree with, and you didn't have a chance
to argue about it at the time.

We did discuss this issue, and the conclusion was that RBridges didn't 
have to behave *exactly* like bridges in
various configuration-intensive situations.

However, in this case -- VLAN hopping -- if you really want the feature 
of keeping two communities, both
labelled "VLAN 5" distinct within a layer 2 cloud, can't you accomplish 
that with VLAN mapping, which RBridges
do support?

Radia

---

From: Kris Price <[email-masked]>
Date: Mon, 16 Mar 2009 19:56:20 +1300

Hi Radia,

> to argue about it at the time.

I respect that and realise it's probably too late to revisit the overall 
architecture or some of these decisions, but I like idea behind TRILL 
and really want it to be successful, so (lacking any diplomacy perhaps) 
I can't help but question things that seem counter intuitive or 
contradictory to me. Maybe I'd be better to explore those things in a 
paper or some such tho.

> various configuration-intensive situations.

Okay. My experience differs, and maybe that's due to a regional thing. 
Down under I would say this kind of configuration is the norm, perhaps 
considered intensive, but certainly the norm. I haven't personally seen 
a configuration free 802.1 network since 1999, and at that time we were 
still using thinnet there. Even very small sites here are configured 
with VLANs for remote management and such. And when I imagine replacing 
them with an RBridge it would seem to never require less configuration. 
But in quite a few RBridges would seem to require more configuration due 
to security, and in quite a few places be disqualified from use if what 
I've been talking about isn't solvable. Which is why I wondered if it 
had evolved to being really just targeted at people with big clusters.

> that with VLAN mapping, which RBridges

It might do. I'm reading draft-ietf-trill-rbridge-vlan-mapping-00.txt 
but it isn't completely clear to me. Let's see if I have it right.

In the diagram the <1, 2, n> lists the VLANs allowed on the link as 
configured on the ports at both ends. If these were all 802.1Q bridges 
then B1 would not be able to reach stations in VLANs 2 and 3 attached to 
B2 or B3, even if it changed its configuration.

Let's assume again that B1 and B3 have been swapped out to RBridges and 
B2 is still the 802.1Q bridge. Again B1 is untrusted so capable of 
changing its port configuration or crafting frames, etc.

   +----+       +----+           +----+
   | B1 |--<1>--| B2 |--<1,2,3>--x B3 |
   +----+       +----+           +----+

We want to prevent B1 from accessing VLANs 2 and 3. Remembering B1 is 
untrusted, so possibly compromised and capable of changing its port 
configuration or crafting frames, etc.

Using VLAN mapping, would we configure a map on the port "x" on B3, to 
map the VLANs we want to protect to other VLAN IDs? E.g. map VLAN 2 to 
VLAN 998 and map VLAN 3 to VLAN 999. Then make sure VLAN IDs 998 and 999 
are never used for anything else. Is that how we'd do it?

Can we map 2 and 3 to the same garbage VLAN ID or do we need to make a 1 
for 1 mapping for every VLAN we want to protect?

Can we do this inbound/outbound on the same trunk port?

What happens if B1 sends a crafted frame tagged with 998 or 999 to B3, 
does it get mapped back to 2 or 3?

Regards

Kris

---

From: Kris Price <[email-masked]>
Date: Mon, 16 Mar 2009 20:19:37 +1300

Hi Caitlin,

> I am not following how B2 is supposed to be enforcing a restriction.

Okay, I'm officially seeking a sanity check now. :)

Using a real world configuration may make what I'm saying clearer, so in
Cisco terms we configure the following on B2:

   interface <Port-connected-to-B1>
    switchport trunk encapsulation dot1q
    switchport trunk allowed vlan 1,2,3
    switchport mode trunk

In this configuration the trunk port on B2 is statically configured to
be a member of VLANs 1, 2, and 3.

If B2 receives a frame that is tagged with VLAN 100 from B1 what does it
do? It should discard it because the trunk port is not a member of VLAN
100, right?

If B2 receives a frame, say its a broadcast for an easy example, tagged
with VLAN 100 from an attached end station or B3, it floods it over the
spanning tree, but does not forward it out the trunk port to B1 because
that port is not a member of VLAN 100.

Replacing B1 and B3 with RBridges, as currently specified, bypasses this
kind of behaviour.

> that belongs to VLAN X, and 802.1Q Bridges enforce that.

Yep.

> that belongs to VLAN X, and again 802.1Q Bridges enforce that.

Yep.

802.1Q says a frame that belongs to VLAN X will only be delivered to a
LAN that is a member of VLAN X.

> should have different VLAN IDs.

I don't think this is true or reflective of 802.1Q, but granted I'm not
an 802 expert. I am going from my practical experience and a quick look
at the 802.1Q Std.

I think saying they should have different VLAN IDs is missing the point
that we don't trust what comes out of B1. People use this feature of
bridges extensively in practise as a way of securing their networks.

It certainly might be TRILL's decision to do it this way regardless, but
that decision shouldn't be due to any notion that this feature of 802.1Q
isn't important or widely used.

> are distinct, use different VLAN IDs.

802.1Q covers this point and says you need to consider the full mesh
when configuring such filtering. My experience is that people do this
well, configuring allowed VLANs correctly on all paths. If you do
configure an allowed VLAN on one link, and the spanning tree changes to
a link you forgot to configure it on, that VLAN becomes partitioned. And
vice versa, if you forget to remove it from a link and the topology
changes it might be reconnected. But this is a clear case of
misconfiguration.

Is it a good security principal for TRILL to reduce the security of the
network to the lowest common denominator? Philosophically it isn't for
me. Not so sure that many would think it is. But maybe I'm out of date.

At a minimum I think RBridges need to implement administrative filtering
of the inner VLAN if not some other solution. The filtering should be
such that administrators, provided they properly understand TRILL's
behaviour, can mimic their existing security policy. This may be
considered an issue left for implementers to add as a feature, but I
think it'd be very beneficial to be included as a management control in
the spec. Just as 802.1Q seems to deem it fit to define the behaviour in
the spec. Radia suggests the VLAN mapping might enable this so I'll take
a look at that, but if not I think the group should consider putting it
in there.

Also by design TRILL shouldn't, whether via some automatic
configuration, easy to ignore default, or ambiguous behaviour, allow any
existing security like this to be bypassed. It ideally should only
happen via some informed decision. But I'll accept I may be the only one
to think that's a philosophically bad stance.

Regards

Kris

---

From: Dinesh G Dutt <[email-masked]>
Date: Mon, 16 Mar 2009 08:49:27 -0700

Kris,

You're right about the difference in behavior between an 802.1Q/D bridge 
and an Rbridge w.r.t. VLANs. I raised this specific issue about six 
months to a year back. I thought that customers and field engineers 
would agree with me. I found much to my surprise by polling the field 
and a few customers that they actually preferred the approach of TRILL.

The key advantage of this approach is that VLANs becomes an edge only 
feature and customers felt that they can get connectivity by only 
configuring VLANs at the edges and not at every switch. People tend to 
run into issues because they forgot to enable a VLAN somewhere in the 
middle. With people tending to larger L2 clouds due to various reasons, 
this ease of configuration becomes even more important.

One way to address the issue of preventing a VLAN from traveling over a 
specific trunk is to prevent IS-IS from announcing reachability to that 
VLAN on its links. A switch could also provide local config to prevent 
locally originated traffic from going over specified links.

In short, the issue was raised and discussed before and the current mode 
found to be more desirable.

Thanks for the questions,

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: Kris Price <[email-masked]>
Date: Wed, 18 Mar 2009 19:21:55 +1300

Thanks Dinesh,

I have a clearer picture now. TRILL's behaviour is intentionally more 
similar to MPLS than 802. But in that case the tight coupling to 802, 
yet not behaving like 802 makes me uncomfortable. E.g. VLANs shouldn't 
be called VLANs, being shackled to the C-TAG, etc.

As I think I mentioned in another email, I think TRILL could benefit 
from decoupling this.

I've explained some of this, and what I mean by this to Radia, so I want 
bother repeating it here. If it was an idea worthy of discussion, she 
can vet it and open it.

Regards

Kris

---

From: "Hari Balasubramanian (harih)" <[email-masked]>
Date: Thu, 19 Mar 2009 10:56:24 -0700

Kris,

IMO, the entire group benefits from such discussions and seemingly
differing viewpoints. I certainly hope that you will post, in this
group, either the full or condensed version of the discussions you plan
to have with Radia.  

Thanks, 
Hari

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kris Price
> Sent: Tuesday, March 17, 2009 11:22 PM
> To: Dinesh G Dutt (ddutt)
> Cc: [email-masked]
> Subject: Re: [rbridge] VLAN hopping: firewall on a stick
> 
> Thanks Dinesh,
> 
> I have a clearer picture now. TRILL's behaviour is 
> intentionally more similar to MPLS than 802. But in that case 
> the tight coupling to 802, yet not behaving like 802 makes me 
> uncomfortable. E.g. VLANs shouldn't be called VLANs, being 
> shackled to the C-TAG, etc.
> 
> As I think I mentioned in another email, I think TRILL could 
> benefit from decoupling this.
> 
> I've explained some of this, and what I mean by this to 
> Radia, so I want bother repeating it here. If it was an idea 
> worthy of discussion, she can vet it and open it.
> 
> 
> Regards
> 
> Kris
> 
> 
> Dinesh G Dutt wrote:
> > Kris,
> > 
> > You're right about the difference in behavior between an 802.1Q/D 
> > bridge and an Rbridge w.r.t. VLANs. I raised this specific 
> issue about 
> > six months to a year back. I thought that customers and field 
> > engineers would agree with me. I found much to my surprise 
> by polling 
> > the field and a few customers that they actually preferred 
> the approach of TRILL.
> > 
> > middle. With people tending to larger L2 clouds due to various 
> > reasons, this ease of configuration becomes even more important.
> > 
> > One way to address the issue of preventing a VLAN from 
> traveling over 
> > a specific trunk is to prevent IS-IS from announcing 
> reachability to 
> > that VLAN on its links. A switch could also provide local config to 
> > prevent locally originated traffic from going over specified links.
> > 
> > In short, the issue was raised and discussed before and the current 
> > mode found to be more desirable.
> >

---

From: Radia Perlman <[email-masked]>
Date: Fri, 20 Mar 2009 12:02:36 -0700

Of course. Off-line discussion is sometimes useful to keep down the 
volume on the main list, or if someone is
afraid that their question or suggestion might be viewed as "stupid" 
they might want to try it out on a smaller subset
of people first (for instance, I'm very nonscary and it's OK to ask me 
things or run suggestions by me if someone
is reluctant to post to the list),
but the intention is of course to make sure that anything substantive 
gets summarized to the list.

Radia

---

From: Kris Price <[email-masked]>
Date: Sat, 21 Mar 2009 20:23:28 +1300

> group, either the full or condensed version of the discussions you plan

Ok, but so much of this has probably been debated and it is impossible 
for me to really be aware of every reason for these design choices. So 
bear in mind these are uninformed perspectives, not criticisms.

And, hopefully I don't say something too stupid. :)

I'll share my perspectives on three topics. The language of TRILL and 
whether it is appropriate to use 802 terms. The structure of the TRILL 
specification and whether it would be better if broken up into generic 
and 802 specific components. And whether TRILL would be better off (long 
term) if it did not use 802 header information during forwarding.

Few parts to this, it will get long, hopefully I haven't oversimplified.
It's a bit fast and rough, go with the flow... etc. The language point I
think has merit, the rest maybe not so.

*Background*

To help you understand why I formed these perspectives I'll give some
observations, so you see where I'm coming from. When imagining how to
describe TRILL to someone or draw it on a whiteboard, it turns out TRILL
has no easy comparisons. So when describing TRILL, some of the things I
would have to say are:

  - TRILL is not a cloud that mimics a bridge as in an MST region.

  - TRILL is not a cloud that mimics a LAN as in 802.1ad and MPLS L2VPN.

  - TRILL neither appears as a link or bridge.

  - A TRILL cloud is formed of new devices called RBridges.

  - For the most part RBridges try to autoconnect to each other, in a
    purely greenfields deployment they will, but in almost any other
    deployment they probably wont without manual configuration.

    In mixed (existing) environments TRILL must be manually enabled on
    a different interface/VLAN, or the 802 links between the RBridges
    reconfigured to permit the require connectivity, etc. Similar to
    setting up any network layer protocol such as IP or MPLS.

  - This TRILL cloud mostly terminates BPDUs breaking up STP, though
    be aware it doesn't always do so, in quite a few cases you need to
    know when to configure it to tunnel them.

    In this sense TRILL is similar to a network layer protocol. It does
    not appear as a single bridge as with an MST region. It is does not
    appear as a single LAN similar to 802.1ad or L2VPN.

  - TRILL performs hop-by-hop routing of encapsulated payloads, using a
    shim like header. And the outer encapsulation header changes at
    each hop just as a when routing IP or MPLS.

  - TRILL may run over any layer-2 protocol, but by default configures
    for 802.3 links and by default sends 802.1Q tagged frames.

  - The TRILL control-plane protocol runs over the layer-2 links, in the
    same way they do for MPLS and IP. They are both equally constrained
    by the link topology. In comparison the 802 protocols (RSTP/MST) are
    not constrained this way.

  - Despite this, TRILL calls a LAN that runs 802.1Q a single link. Even
    if it has no interfaces on some of the VLANs. This is different to a
    router where the router would see each VLAN as a separate link over
    which to form adjacencies. To work around this TRILL does a lot of
    work with Hello's to try to understand the configured VLANs on a
    link.

  - Despite being called RBridges, they are more R, and less Bridges. :)

  - Despite using 802.1D and .1Q as the base, a TRILL cloud does not
    adhere to the underlying 802.1Q VLAN topology.

  - A TRILL VLAN and 802.1Q VLAN are different. TRILL maps 802.1Q VLANs
    at the edge to TRILL VLANs and the behaviour in the TRILL cloud is
    different. This is because TRILL does not adhere to the 802.1Q VLAN
    topology.

    RBridges in the TRILL cloud are all trusted, each has the same
    ability as any other to join or leave a VLAN. Very much like MPLS
    VPNs and very much unlike your 802 deployment.

    Once a frame ingresses at the edge it is free to go anywhere in the
    TRILL cloud. Think of it just like an MPLS VPN and very much unlike
    802. For this reason, understand carefuly any security implications
    of this different behaviour to your network when you deploy.

  - Despite this, TRILL re-purposes the 802.1Q C-TAG in the encapsulated
    frame for identifying which TRILL VLAN a frame is in.

  - TRILL does kindly detect 802.1Q VLAN mapping (a non standard feature
    of 802.1Q) so that the auto-mapping of 802.1Q VLANs at the edge to
    TRILL VLANs is consistent across the TRILL cloud. This is not 802
    like, it is a courtesy to make the auto-mapping work better.

  - Your end stations are going to see a TRILL connected bridged LAN as
    just a bridged LAN. Bridges wont. They will see RBridges as routers.

  - RBridges learn from the data-plane at the edge only. Not in the core
    like 802.1Q bridges do. RBridges also optionally learn from the
    control-plane.

*Language*

Could the language and terms used by TRILL be ambiguous or misleading to
the people who haven't developed it but are going to work with it? Would
it be better to distinguish TRILL behaviour from 802.1Q behaviour?

Whenever TRILL is selective in its interpretation and implementation of
an 802 standard, doesn't it end up creating something new? And so
therefore shouldn't it be distinguished with a different name?

An obvious example, given my recent question, is the use of the term VLAN.

It's my opinion that an 802.1Q VLAN and a TRILL VLAN are very different
(as described above). TRILL's definition is more like an MPLS VPN in its
membership, and unlike anything else in its behaviour, and I feel it is
ambiguous to call it a VLAN. People (like myself) may wrongly expect
certain behaviours from it unless it is made distinct. Especially since
TRILL talks about 802.1Q a lot.

Would it be better if a TRILL VLAN were called something different that
reflected what it did. And in the draft describe as an automatic mapping
between an 802.1Q VLAN and a TRILL VLAN. Perhaps what TRILL creates is a
kind of virtual multi-access link, VLink, or Routed LAN, RLAN... *shrug*

This applies to all 802 standards. Say TRILL implements 802.1ad one day,
but a Provider VLAN doesn't tunnel STP in the TRILL version, then it
should be called something else. And so forth. 802.1au but handles it
differently, call it something else, because it's a different
implementation.

*Structure*

Could TRILL be defined as a generic mechanism in a base document, with
modular extensions added to provide compatibility for the various 802
standards that TRILL wants to support? And for that matter extensions
for TRILLs own standards should it simply diverge from 802 over time.
And would this be better?

So perhaps the architecture of TRILL looks something like this, which is
roughly how I decipher it based on my reading and peoples explanations.

             +--------+ +---------+ +-----+
           +--------------------------------+
  Software | | 802.1Q | | 802.1ad | | ... | |
           +--------------------------------+
  Hardware | | 802.1Q | | 802.1ad | | ... | |
           +--------------------------------+
             +--------+-+---------+-+-----+
  Routing    |           TRILL            |
             +----------------------------+
  Link       |      802.3, PPP, etc.      |
             +----------------------------+

Link: It just so happens at the moment it is tightly specified for 802.3 
in the draft. But TRILL could use other layer-2 link types. So in a 
generic base TRILL it may say something to the effect of TRILL is 
enabled by default on all 802 ports on an RBridge... The base TRILL 
wouldn't specify VLAN discovery for instance, just base adjacency 
formation by sending untagged Hellos (configurable to be in a VLAN or 
whatever, but this base case would mimic basic 802.1D bridges).

Routing: TRILL routes frames over any link types. There is a hardware 
component to the processing of the generic TRILL header and that hands 
off processing for the 802 specific fields in the encapsulated 802 
header to those specific hardware parts. This part I would've thought 
was able to be fairly generic to many 802 Stds, the hand of based on the 
ethertype immediately following the TRILL header. If it doesn't 
understand the ethertype, it just keeps forwarding the header to the 
egress which hopefully does.

Hardware: Plugged into generic TRILL is the hardware layers that recieve 
and process ingress/egress 802 frames. And that also process the 
specific 802 parts of the encapsulated headers for the TRILL routing 
decisions. At the moment TRILL is tightly coupled to 802.1Q and 
processing adding/removing/changing the C-TAG of the encapsulated header
(good idea or not). But it could just as easily (it seems) be extended 
to include hardware that processes S-TAGs in the case of 802.1ad, and so
on. This would be in the 802.1Q adaptation...

Software: And of course there is the software aspect of providing that
support. Such as forwarding reachability information. In the current
case of 802.1Q doing as much auto-conf as possible, VLAN discovery, etc.

To test my understanding let me consider how TRILL would handle an 802 
standard it didn't understand, e.g. 802.1ad, and how support would be added.

If TRILL recieves an 802.1ad frame on a port it will not recognise the
ethertype and so will treat it as an untagged frame. Hence TRILL will
instert another C-TAG before the S-TAG/C-TAG already in the frame and
route it as if it were an ordinary untagged frame from an end station. 
Just as it would any new 802 standards that come out because it is not 
possible for TRILL to know what those are.

So to make TRILL do something useful with 802.1ad before it has any 
implemented compatibility, provided the RBridges supported it, the 
engineer could configure RBridge ports like they were an L2VPN, into a 
particular C-VLAN (e.g. 100). Now the 802.1ad bridges at either edge of 
the TRILL cloud can forward frames to each other.

At least I think this will work, it seems ugly, but I think it works.

To make TRILL do something intelligent with 802.1ad, TRILL would define 
a addition to the draft. RBridges would impliment new 802.1ad layer to 
recieve and process 802.1ad tagged frames. New extensions would be made 
to IS-IS to distribute relevant 802.1ad information. And new port modes 
and such would be defined. Now an RBridge could have a port configured 
as an 802.1ad port, and recieve C-TAGged frames from customer LAN, apply 
an S-TAG, and all intermediate RBridges would have to be swapped out to 
understand this S-TAG in the inner encapsulated 802 header. Then they'd 
use that for their forwarding decisions.

When one of these reaches an RBridge though that doesn't understand it, 
because it wasn't replaced with the new version, it get's handled as 
untagged and put in the native VLAN with a C-TAG before the S-TAG again,
lost in the native TRILL VLAN where it goes nobody knows, or something 
like that. That seems a little messy but maybe there's some way around it.

*Coupling to 802.1Q*

Following from all of that. And this is where I get a bit out there and
it's probably full of many flaws that aren't obvious to me, and I'm
likely being too quick to share. :)

If TRILL is going to be selective in how it interprets and implements
802 standards, wouldn't it be safer, cleaner, and more flexible to
design equivalent adaptations that are specific to TRILL and its
customer's needs?

One day, if successful, most networks will be entirely TRILL, isn't that
the aim?

Simpler is better and my perspective is that simpler (for its target
customers) would be something more like MPLS. Define a new stand-alone 
forwarding method that isn't dependant on understanding the payload. For 
example:

Forget the C-TAG and processing of encapsulated 802 fields at each hop. 
Quite clearly layer 802 ontop of TRILL rather than the hybrid. Define a
kind of generic TRILL base protocol with a header that includes a CoS
field and some kind of VPN ID field (whether you call it VLAN, RLAN,
VLink, etc.). This VPN ID is used to form a TRILL virtual bridge or 
TRILL virtual link or something.

Then define adaptations of 802 standards for TRILL and in those
adaptations the mapping between the TRILL/802 equivalents.

Perhaps one of these "VPNs" in the base protocol would behave as a LAN
for all protocols it does not recognise, but terminate and interact with
those 802 protocols it does recognise. In this way behave transparently
to any new 802 standard that comes along.

Isn't this kind of layered encapsulation cleaner? Especially given
TRILL's behaviour is closest to a network layer protocol...

Of course this has been discussed (I imagine). But it makes more sense
and is simpler to me and you asked me to share. :)

Regards

Kris