Subject: [rbridge] VLAN Scoping / MAC Uniqueness

From: Radia.Perlman at sun.com ([email-masked])
Date: Sat, 10 Mar 2007 23:25:14 -0800

I don't agree that we have to explicitly advertise which VLAN a MAC address belongs to, because
each VLAN runs its own instance of IS-IS in which endnodes are announced. This could be looked
at as implicitly advertising the VLAN. In other words, the endnode information is announced in
an instance of IS-IS distinguished by having an inner VLAN tag (I think that's how we differentiate it).
Core RBridges forward it like a multicast packet for that VLAN. Only border RBridges of that VLAN actually
store the information.

Radia

----- Original Message -----
From: Erik Nordmark <erik.nordmark at sun.com>
Date: Friday, March 9, 2007 4:11 pm
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness

> Caitlin Bestler wrote:
> 
> > This suggests three options:
> > 
> > 	1) Require all RBridges to scope on a per-VLAN basis.
> >            The only real flaw in this is that it is a RBridge
> >            requirement that does not apply to conventional bridges.
> > 
> > 	2) Allow all RBridges to have whatever scoping rules they
> >            want, but require that all updates go to all RBridgges.
> >            Each RBridge can judge for itself it the information is
> >            relevant to it, and organize that data however it wants.
> > 
> > 	3) Punt: require the network adminstrator to ensure that naming
> >            scopes enforced by RBRidges are "consistent" and provide
> >            only text-based suggestions on how to achieve this.
> 
> I didn't see a conclusion on this discussion.
> 
> I think 802.1D mandates that bridges be capable of doing learning 
> independently for each VLAN (what is called IVL). Thus mandating 
> the 
> same for RBridges (option 1 above) seems natural.
> 
> I think this means that the link state routing protocol needs to be 
> able 
> to carry <VLAN tag, L2 address> in the LSAs instead of just <L2 
> address>. If that is correct then we should clarify this in the 
> routing 
> requirements. They currently say
>    o  layer 2 addresses of nodes within the domain which have
>       transmitted frames but have not transmitted ARP or ND replies
> and that would need to be the tuple of VLAN tag and L2 address.
> 
>    Erik
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Sun, 11 Mar 2007 18:25:32 -0700

Radia.Perlman at sun.com wrote:
> I don't agree that we have to explicitly advertise which VLAN
> a MAC address belongs to, because each VLAN runs its own
> instance of IS-IS in which endnodes are announced. This could
> be looked at as implicitly advertising the VLAN. In other
> words, the endnode information is announced in an instance of
> IS-IS distinguished by having an inner VLAN tag (I think
> that's how we differentiate it).
> Core RBridges forward it like a multicast packet for that
> VLAN. Only border RBridges of that VLAN actually store the
> information. 
> 
> Radia
> 

VLAN tagging the endnode announcement assumes that the 
announcement is only relevant within the VLAN. That still
leaves the following scenario:

	RBridge I participates in VLANs R and S.
	It uses a single (VLAN independent) MAC learning database.
	It believes the MAC X is on a local port for VLAN R.

	RBridge J participates in VLANs S and T.
	It uses a single (VLAN independent) MAC learning database.
	
	RBridge K participates in VLAN T
	It detects MAC X on a local port for VLAN T.

It would share that information with RBridge J, but not RBridge I.
RBRidge J can now receive contradictory information from I and K.

This is avoided if RBridge K does not presume which RBridges 
need this informaton, or if RBridge I advertises itself as
wanting information for all VLANs (that is, it is a member
of VLAN T, but only for purposes of getting endnode announcements).

As for the more general problem, obviously any CRED which
has varying concepts on the scope over which a MAC address
is unique is going to have potential problems. But most of
that problem is well outside of TRILL's scope. 

The issue that is within TRILL's scope is ensuring that 
endnode announcements are distributed everywhere that
the information is needed.

The prior drafts explicitly assumed that information about
MAC Address X was not relevant to any RBridge that was not
in the same VLAN. This is only a valid assumption if port
learning is being done on a per VLAN basis.

The current drafts do not have this problem, because they
merely state that distribution might be limited based upon
VLAN (which would be appropriate if the RBridges are known
to have compatible scoping concepts).

The language could be more explicit, but to be realistic,
network administrators would generally avoid allowing
this problem to exist in the first place.

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Mon, 12 Mar 2007 14:44:19 -0700

> Core RBridges forward it like a multicast packet for that VLAN. Only border RBridges of that VLAN actually

That is true if you are required to have N IS-IS VLAN instances when 
there are N VLANs in use.

I don't know if that is overkill when all the RBridges are all part of 
all N VLANs - basically when it is just different subsets of 
stations/hosts that make up the different VLANs.

    Erik

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 12 Mar 2007 15:49:36 -0700

Yes. There are three ways of sending per-VLAN endnode information:

a) a single instance of IS-IS for both "core" information and "endnode" 
information. Endnode
information would be marked as (VLAN ID, {set of endnodes}).
RBridges that are
not in VLAN A would need to store the VLAN A endnode information, and 
all endnode information would
go to all parts of the campus

b) two instances of  IS-IS: one for core information (which RBridges are 
connected to which other
RBridges, and which VLANs are attached to which RBridges), and one for 
endnode information. Not
sure what advantage/disadvantage this has over a), since all link state 
information would go to all RBridges.

c) n+1 instance of IS-IS, where n is the number of VLANs that are in 
use. Each RBridge R1 would run
k+1 instances of IS-IS; the core instance, and one for each of the k 
VLANs that R1 is attached to.
The advantage of this is that flooding of endnode information for VLAN A 
need not be stored by
any RBridges except those that attach to VLAN A. Also, because the core 
instance enables flooding
of VLAN multicast just to links that are interested (RBridges that are 
attached to VLAN A), there is
further optimization because this information does not need to traverse 
all the links in the campus; just
those needed to get the packet from the RBridge that originates the LSP 
for VLAN A endnode
information to the RBridges that attach to VLAN A.

I prefer c). I don't think there is that much overhead to running n 
instances. It's really like separating
the endnode information into distinct LSPs. Except for...the Hello 
Protocol. If all RBridges are connected
to 4000 VLANs, then they'd all be sending 4000 Hellos, one for each 
instance. The core instance Hellos
are a bit different -- they only go to direct neighbors. But the VLAN 
instances get flooded by the core
to all links throughout the campus attached to that VLAN.

We could eliminate the hello protocol for the per-VLAN instance of 
IS-IS, since there's enough information
in the core instance for all VLAN A RBridges to know about each other 
and decide which should be
Designated (for sending out CSNPs).

Radia

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Mon, 12 Mar 2007 16:00:25 -0700

One suggestion that I think is adequate:

RBridge Hello messages would be from the core instance
and sent to core instance. It would list the VLAN IDs
and whether it maintained a single destination database
or a per VLAN database.

In the latter case, other RBridges would only forward
relevant advertisements to RBridges that advertised the
relevant VLAN. An RBridge using an unscoped database
would be send all address advertisements.

Alternately, we could explicitly require per VLAN scoping.

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 12 Mar 2007 18:35:32 -0700

I'm not sure I understand what you're saying. But I think the issue is 
how link state information is distributed.

The core instance link state information is flooded to all RBridges, but 
transmitted hop by hop. That means
every RBridge, including core RBridges that do not attach to any VLANs, 
have to store this information,
in addition to forwarding it, in case it needs to be retransmitted to a 
neighbor, or transmitted to a new
neighbor that might come up later.

As the spec currently is, the endnode information is multicast. So R1, 
attached to VLAN A, just multicasts
a single copy of its VLAN A information, and it gets distributed by the 
core like any VLAN A multicast
data packet. It magically gets received just by RBridges attached to 
VLAN A. Only RBridges actually
attached to VLAN A need to store this information. It is not sent 
reliably neighbor-to-neighbor. Only
R1 has to ensure that all the relevant RBridges have received the link 
state information about VLAN A.
THe intervening RBridges just forward it and forget it.

So as I said, you could get rid of running the per-instance IS-IS 
hellos, by just listing, in the core
instance LSP, which VLANs you attach to. There really isn't anything 
that the per-VLAN instance
of the hello protocol
needs to know that isn't already in the core instance link state 
information, so we could eliminate running
4000 Hello and Designated RBridge elections.

However, the per-VLAN link state information (listing the endnodes) is 
potentially large enough that
I believe it is useful to avoid having non-VLAN-A RBridges keep track of 
the VLAN A endnodes (and
VLAN A IP groups and multicast routers).

And if we are using multicast to distribute, I don't see how R1 can 
choose which RBridges to send the
information to, or to format it differently depending on the recipient.

For as many as possible of these sorts of things that are OK to do
either this way or that way, I think we should choose,
rather than making it a parameter.

Radia

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Tue, 13 Mar 2007 10:37:09 -0700

Radia Perlman wrote:

> The advantage of this is that flooding of endnode information 
> for VLAN A need not be stored by any RBridges except those
> that attach to VLAN A.

That line leapt out at me on re-read.

*If* we are going to allow RBridges to have the traditional
bridge option of using scoped or global MAC address learning,
then we do indeed have to flood endnode information about 
VLAN A. This is not so that RBridges that are not part of
VLAN A can *store* the new endnode information, it is so
they can *delete* contradictory information.

Alternatively, if we explicitly require scoped learning,
then any RBridge that is not part of VLAN A cannot have
contradictory information. Then there would be no need
to flood endnode advertisements.

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 13 Mar 2007 10:54:47 -0700

With IS-IS flooding, an RBridge can't simply scan the information for 
VLAN A and then delete it.
It has to store it, since LSPs have to be flooded reliably, so each 
RBridge would have to keep all
endnode information for all VLANs.

Radia

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Tue, 13 Mar 2007 10:59:38 -0700

Radia Perlman wrote:
> With IS-IS flooding, an RBridge can't simply scan the
> information for VLAN A and then delete it.
> It has to store it, since LSPs have to be flooded reliably,
> so each RBridge would have to keep all endnode information for all
> VLANs. 
> 

I'm not following. If an RBridge is using globally scoped MAC
addresses, and it receives endnode information for a VLAN that
it does not support, the only thing I can see that it would have
to do is to delete any information it had on the same MAC address
on a different VLAN.

It would never send to VLAN A, so why would it retain any information
once the contradictory data was eliminated? A deleted record can be
considered to be reliably delected, can't it?

If it's knowledge of MAC Addresses is VLAN scoped then nothing
about VLAN A is ever relevant. That is why it is a very simple
solution, but one that creates an RBridge requirement for scoped
learning that does not apply to simple Bridges.

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 13 Mar 2007 11:26:11 -0700

The current spec (and my understanding) is that membership of VLAN A 
would be distributed
as link state information in IS-IS. If we include this in the link state 
information in the core instance,
then every RBridge has to store it all, since IS-IS flooding requires 
every RBridge to store all (the most
recently generated from each RBridge) link state information. R1 doesn't 
just look at the link state
information and decide what it's interested in and delete the rest. R1 
has to keep it in order for
the reliable flooding to work.

With the way the current spec is written, endnode information is *NOT* 
distributed in the core instance.
Instead, VLAN A information
is distributed like a VLAN A multicast data packet, which means the core 
RBridges distribute
it along a tree, filtered so as not to unnecessarily go on branches that 
don't lead to VLAN A links.

With that design, the only RBridges that would see information about 
VLAN A endnode membership are
RBridges attached to VLAN A.
The topology that the IS-IS instance for distributing VLAN A sees is as 
a single hop, with all RBridges
attached to VLAN A being neighbors.

There is a variant of this design that would have the property you are 
imagining; that all endnode information
goes everywhere, gets seen by all RBridges, and that only RBridges in 
VLAN A have to actually store the
information. That is to have a multicast distribution tree that sends 
things to *all* RBridges that attach to
endnodes. This is a subtly different distribution mechanism than the 
core instance. If there are core RBridges,
not attached to any endnodes, they would just pass the link state 
information along. And a "border" RBridge R2
(one that does attach to endnodes) would be allowed, if it chose, to 
simply scan VLAN A information and
then delete it, since R2 would never need to forward this link state 
ifnormation to a neighbor.

I still prefer the way the spec is now, since I think the advantage of 
noticing endnodes moving to a
different VLAN is outweighed by the downsides (more cost to distribute 
endnode information, and
the ability for nasty behavior of an endnode in VLAN A to disrupt VLAN B 
maliciously, and confusion
when nonmaliciously an endnode resides on multiple VLANs with the same 
MAC address.

Radia

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Tue, 13 Mar 2007 11:36:47 -0700

Radia Perlman wrote:
> The current spec (and my understanding) is that membership of
> VLAN A would be distributed as link state information in
> IS-IS. If we include this in the link state information in
> the core instance, then every RBridge has to store it all,
> since IS-IS flooding requires every RBridge to store all (the
> most recently generated from each RBridge) link state
> information. R1 doesn't just look at the link state
> information and decide what it's interested in and delete the
> rest. R1 has to keep it in order for the reliable flooding to work.
> 
> With the way the current spec is written, endnode information
> is *NOT* distributed in the core instance.
> is distributed like a VLAN A multicast data packet, which
> means the core RBridges distribute it along a tree, filtered
> so as not to unnecessarily go on branches that don't lead to
> VLAN A links.
> 
> With that design, the only RBridges that would see
> information about VLAN A endnode membership are RBridges
> attached to VLAN A.
> The topology that the IS-IS instance for distributing VLAN A
> sees is as a single hop, with all RBridges attached to VLAN A being
> neighbors. 
> 
> There is a variant of this design that would have the
> property you are imagining; that all endnode information goes
> everywhere, gets seen by all RBridges, and that only RBridges
> in VLAN A have to actually store the information. That is to
> have a multicast distribution tree that sends things to *all*
> RBridges that attach to endnodes. This is a subtly different
> distribution mechanism than the core instance. If there are
> core RBridges, not attached to any endnodes, they would just
> pass the link state information along. And a "border" RBridge
> R2 (one that does attach to endnodes) would be allowed, if it
> chose, to simply scan VLAN A information and then delete it,
> since R2 would never need to forward this link state
> I still prefer the way the spec is now, since I think the
> advantage of noticing endnodes moving to a different VLAN is
> outweighed by the downsides (more cost to distribute endnode
> information, and the ability for nasty behavior of an endnode
> in VLAN A to disrupt VLAN B maliciously, and confusion when
> nonmaliciously an endnode resides on multiple VLANs with the
> same MAC address.
> 
> Radia
> 

It might be sufficient to merely note that any RBridge attempting
to maintain global scoping of MAC Addresses needs to be aware that
the distribution of endnode information is optimized for per-VLAN
scoping. Because of this it MUST NOT rely on prompt notification
of migration of a MAC Address to a new VLAN on a different RBridge.

I also agree that it makes sense to optimize the wire protocol
on the assumption that typical RBridges will do per-VLAN learning.

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Fri, 16 Mar 2007 02:16:11 -0700

I think TRILL needs to do exactly what IEEE 802.1Q does.
AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M >=N.

N is never advertised outside the bridge, and the mapping of M to N is
never advertised outside the bridge. TRILL must do the same.

Learning is done on {VID, MAC-address} pairs. TRILL must do the same.

We agreed that bridges learn from data frames and data frames are always
associated to a VID and RBridges learn from the per VLAN instance of
ISIS. 

Let's suppose that we have an RBridge with 2 VLANs (7 and 9) that are
mapped to the same FID. MAC-A is learnt on VLAN=7 and automatically
becomes available on VLAN=9.

Now the tricky question: should the RBridge announce MAC-A on both VLAN
7 and VLAN 9 or only on VLAN 7?

IMHO the correct answer is that it MUST only announce it on VLAN 7, i.e.
it must only announce what it has learnt from data frames, not the
internal associations it has made. If the information was learnt on data
packets, it would only be learnt on VLAN 7!

If we do this we are perfectly equivalent to an IEEE 802.1Q bridge.

-- Silvano

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Radia Perlman
> Sent: Tuesday, March 13, 2007 11:26 AM
> To: Caitlin Bestler
> Cc: rbridge at postel.org; Erik Nordmark

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Fri, 16 Mar 2007 23:26:44 -0700

-----Original Message-----
From: Silvano Gai [mailto:sgai at nuovasystems.com]
Sent: Fri 3/16/2007 2:16 AM
To: Radia Perlman; Caitlin Bestler
Cc: rbridge at postel.org; Erik Nordmark
Subject: RE: [rbridge] VLAN Scoping / MAC Uniqueness

-- Silvano

-----End Original Message-----

My understanding of 802.1 specifications is that the following sequence
is acceptable behavior for a bridge:

1) VLAN 7 MAC X is seen on port 1.
2) Bridge learns that MAC X is on port 1 with VLAN 7.
3) VLAN 8 MAC X is seen on port 1.
4) Bridge learns that MAC X is on port 1 with VLAN 8 (erasing the prior information about X).

This is of course undesirable, but a livable quirk. It is best avoided by either
ensuring that global MAC Addresses are truly unique, or ensuring that all bridges
deployed in one subnet agree on exactly how unique a "globally unique" address is.

RBridges do more than merely forward ethernet frames amongst themselves, they collaborate
to implement a distributed ARP/ND proxy. That probably justifies stating that for purposes
of the shared discovery data that MAC Addresses are assumed to be unique only as scoped
within a VLAN, but I think we should acknowledge (and highlight) that we are narrowing
the scope of legal behaviors that would have been available to a bridge.

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Sat, 17 Mar 2007 07:50:25 -0700

Caitlin,

Is you problem with: 
1) "Learning" or
2) "ARP/ND discovery"?

In my email I was only addressing 1), but I agree with you that we also
need to address 2).

-- Silvano

> From: Caitlin Bestler [mailto:caitlinb at broadcom.com]
> Sent: Friday, March 16, 2007 11:27 PM
> To: Silvano Gai; Radia Perlman
> 4) Bridge learns that MAC X is on port 1 with VLAN 8 (erasing the
prior
> information about X).
> 
> This is of course undesirable, but a livable quirk. It is best avoided
by
> either
> ensuring that global MAC Addresses are truly unique, or ensuring that
all
> bridges
> RBridges do more than merely forward ethernet frames amongst
themselves,
> they collaborate
> to implement a distributed ARP/ND proxy. That probably justifies
stating
> that for purposes
> of the shared discovery data that MAC Addresses are assumed to be
unique
> only as scoped
> within a VLAN, but I think we should acknowledge (and highlight) that
we
> are narrowing

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Sat, 17 Mar 2007 12:27:23 -0700

Silvano Gai wrote:
> Caitlin,
> 
> Is you problem with:
> 1) "Learning" or
> 2) "ARP/ND discovery"?
> 
> In my email I was only addressing 1), but I agree with you
> that we also need to address 2).
> 

Maybe I'm not playing spec lawyer well enough. But thinking
of how I would implement these features in a smart NIC I
simply don't see the distinction. It's all information keyed
by the L2 Index.

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Mon, 19 Mar 2007 14:50:11 -0700

Silvano Gai wrote:
> N is never advertised outside the bridge, and the mapping of
> M to N is never advertised outside the bridge. TRILL must do the same.
> 
My reading of Appendix B is that Shared Learning is allowed, where VID
is not a key field (i.e, there is only one FID supported). Appendix B
details some of the problems this creates. I believe the problems for
RBridges are even greater than for simple Bridges. This probably
justifies
restricting RBridges to the Independent Learning model, but any such
additional restriction should be explicitly stated.

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Mon, 19 Mar 2007 15:24:56 -0700

Hi Caitlin,

> 4) Bridge learns that MAC X is on port 1 with VLAN 8 (erasing the prior information about X).
I don't think it happens this way. 802.1d bridges map the Vlan ID into a 
separate filtering database ID called FID and learn the MAC addresses 
along with the FID, not the VID. In independent VLAN learning, FID == 
VID whereas in shared VLAN learning, multiple VIDs map into a single 
FID. Therefore in your example above, Bridge learns MAC X on port 1, FID 
z where z is the same for VLANs 7 & 8 or it learns MAC x, FID z1 and MAC 
x, FID z2 where Vlan 7 = FID z1 and Vlan 8 = FID z2.

ARP/ND based learning is specific to TRILL and needs to decide its 
behavior. Silvano and I discuss this a bit in our presentation  on Wed.

Dinesh

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

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Tue, 20 Mar 2007 08:14:09 -0700

> additional restriction should be explicitly stated.

My understanding is is that shared learning is useless when VLANs are 
used for isolation/security. With shared learning a host on VLAN A can 
trivially cause a DoS attack VLAN B by just sending packets with the 
source MAC address being the MAC address of another host on another VLAN.

Thus I'd be surprised if it is used much in practice with bridges.

I don't see it being a reasonable default for RBridges.

    Erik

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Tue, 20 Mar 2007 08:29:24 -0700

Erik Nordmark wrote:
> Caitlin Bestler wrote:
> 
>> My reading of Appendix B is that Shared Learning is allowed, where
>> VID is not a key field (i.e, there is only one FID supported).
>> Appendix B details some of the problems this creates. I believe the
>> problems for RBridges are even greater than for simple Bridges. This
>> probably justifies restricting RBridges to the Independent Learning
>> model, but any such additional restriction should be explicitly
>> stated. 
> 
> My understanding is is that shared learning is useless when
> VLANs are used for isolation/security. With shared learning a
> host on VLAN A can trivially cause a DoS attack VLAN B by
> just sending packets with the source MAC address being the
> MAC address of another host on another VLAN.
> 

It's a perfectly reasonable behavior, as long as the VID is at
least checked (i.e., it is an attribute, not a key field). A set
of RBridges that *all* used this approach would work perfectly fine.

The real issue is whether RBridges that will realistically tend to
use Independent Learning can easily accommodate some of their peers
doing Shared Learning, and if so, how.

For example, the rule could be that you can use Shared Learning as
long as no other RBridge can detect that you aren't using Independent
Learning. Or Shared/Independent Learning could be a flag that each
RBridge advertises. Or each RBridge could advertise it's VID->FID map.

All of these work, the question is which are justified. As much as I
dislike increasing the key size I can certainly see the advantages to
maintaining a distributed database of requiring all RBridges to use
Independent Learning. So I'd lean toward simply standardizing on
Independent Learning. But any new requirement is best explicitly
stated, not inferred from the data descriptions.

---

From: jrrivers at nuovasystems.com (J. R. Rivers)
Date: Tue, 20 Mar 2007 08:44:35 -0700

If I'm remembering my history correctly, 3Com wanted to use this "mode"
to enable a short-cut routing mechanism (whose name escapes me now).

JR

> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Erik Nordmark
> Sent: Tuesday, March 20, 2007 8:14 AM
> To: Caitlin Bestler
> Cc: rbridge at postel.org; Radia Perlman

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 20 Mar 2007 09:06:26 -0700

>>I don't see it being a reasonable default for RBridges.

Not just not reasonable as default, but *ever*. I'm sure we don't want 
to have a parameter
allowing RBridges to do shared learning.

Radia

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Tue, 20 Mar 2007 10:06:43 -0700

Caitlin,

inline

> Sent: Monday, March 19, 2007 2:50 PM
> > AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M
>=N.
> >

I am not saying I want to restrict, I am saying that in bridges what
triggers learning is always the reception of a frame that has a {VID,
MAC-address} pair. The fact that the VID, on that particular bridge,
shares the FID with other VIDs is what causes shared learning. But
shared learning NEVER propagates. TRILL MUST NOT propagate shared
learning. IT MUST always propagate {VID, MAC-address}. Recipients may
decide to do individual or shared learning.

-- Silvano

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Tue, 20 Mar 2007 10:16:51 -0700

Silvano Gai wrote:
>>> N is never advertised outside the bridge, and the mapping of M to N
>>> is never advertised outside the bridge. TRILL must do the same.
>>> 
> I am not saying I want to restrict, I am saying that in
> bridges what triggers learning is always the reception of a
> frame that has a {VID, MAC-address} pair. The fact that the
> VID, on that particular bridge, shares the FID with other
> VIDs is what causes shared learning. But shared learning
> NEVER propagates. TRILL MUST NOT propagate shared learning.
> IT MUST always propagate {VID, MAC-address}. Recipients may

>From a standards point of view I could see stating that all
TRILL-related protocols MUST be based on Independent Learning,
but that an RBridge MAY use Shared Learning for its local ports
when acting as a Bridge. And I suppose if you literally grafted
an RBridge as an add-on module to an existing Bridge with shared
learning it might even make sense.

Effectively, however, it is requiring RBridges to use Independent
Learning. I see that requirement as inevitable, and therefore best
stated explicitly.

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Tue, 20 Mar 2007 12:53:11 -0700

> of RBridges that *all* used this approach would work perfectly fine.

Are you taking into account hosts that maliciously change their MAC 
address in order to affect the bridging of packets for a host that is on 
a different VLAN?

Are you taking int account hosts that are part of multiple VLANs using a 
single NIC and single MAC address (servers often are configured in such 
ways by having the server add the 802.1Q headers and the bridge just 
enforce that the VID is in the allowed set for that port).

    Erik

---

From: jrrivers at nuovasystems.com (J. R. Rivers)
Date: Tue, 20 Mar 2007 13:29:21 -0700

That seems more like a set of issues associated with access control
management that is beyond the scope of TRILL.

JR

> Sent: Tuesday, March 20, 2007 12:53 PM
> To: Caitlin Bestler

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Wed, 21 Mar 2007 02:52:33 -0700

> management that is beyond the scope of TRILL.

The question we need to answer is whether RBridges need to support SVL, 
or whether we can say that we only do IVL. That is something that the WG 
needs to decide.

    Erik