Subject: [rbridge] VLAN Scoping / MAC Uniqueness

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Tue, 13 Mar 2007 07:23:55 -0700

The issue is not how the information is relayed, or how it is stored,
but who determines what information is relevant.

If all RBridges track MAC Addresses scoped within a VLAN scope
then everything you suggest works perfectly fine. The only correction
needed would be to emphasize that this is indeed a requirement.

But any RBridge that uses a global scope for MAC Addresses should
be told of new MAC detections on different VLANs because such
an RBridge would want to delete the old location.

Unless the RBridge that detected the MAC address knows that all
other RBridges are using VLAN scoped MAC addresses they should
distribute the new information to *all* RBRidges, not just those on
the VLAN where the address was discovered.

---

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

Ah. Now I understand the issue, I think. You are saying that if MAC 
addresses are globally unique,
an RBridge attached only to VLAN A should still monitor the endnode 
membership of the other VLANs,
in case one of its endnodes moves and appears elsewhere.

So I think we are talking about two alternatives:
a) have all RBridges see all endnode memberships on all VLANs
b) have RBridges only see endnode memberships for VLANs they are 
directly attached to.

I see the disadvantages of each as:
a) extra bandwidth and storage for having endnode membership go everywhere
b) less timely noticing an endnode has moved to another VLAN

If I understand things correctly, I much prefer b), for the following 
reasons:
1) option a offers an endnode in VLAN A the ability to annoy VLAN B by 
pretending to be MAC addresses
 belonging to VLAN B (so option b is safer and provides more separation 
between VLANs)
2) option b) greatly lowers the burden on RBridges because they only 
have to keep information for
their own VLANs
3) option b) is likely to save bandwidth on distributing endnode information
4) there might be cases where an endnode might attach to multiple VLANs, 
and the RBridges will
panic unnecessarily

Radia

Caitlin Bestler wrote:

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

---

From: riw at cisco.com (Russ White)
Date: Mon, 19 Mar 2007 15:06:24 -0400

- From an IS-IS perspective, if we do a, we only have, I think, a single
process, while if we do b, it makes more sense to do multiple processes,
right? In reality, the way the TLVs are laid out today, we can advertise
each l2 address with a vid, or not, or a group of l2 addresses with a
single vid to indicate they are all within this vid, or some other
various combinations.

:-)

Russ

>> the VLAN where the address was discovered.

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

---

From: jrrivers at nuovasystems.com (J. R. Rivers)
Date: Mon, 19 Mar 2007 12:35:51 -0700

Seems like Radia's option B is a reasonable option.

Just because an RBridge has directly connected hosts on VLAN A doesn't
qualify it to understand what should (or shouldn't) be connected on VLAN
B.

There are many examples of locally assigned Ethernet addresses being
used within a subnet.  It doesn't seem like there is any fundamental
requirement for TRILL to change this.  Clearly... there needs to be a
policy for handling the same address connected to different RBridges in
the SAME VLAN.

My $0.02,

JR

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Russ White
> Sent: Monday, March 19, 2007 12:06 PM
> To: Radia Perlman
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFF/t8wER27sUhU9OQRArzYAJ9WuW82Wcaeml5+OVEmb/OAChUO4wCg7cgY
> 6bS0r3gfLceCcCIUYXFR5HI=
> =F2tF
> -----END PGP SIGNATURE-----

---

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

Radia,

I prefer option b as well. Just as in regular 802.1d bridges, we need to 
age out MAC addresses periodically if we don't see them. One important 
point is that we should set the default age timer to be greater than the 
default ARP cache timer to avoid flooding due to aging out a MAC entry 
but with the hosts still retaining the ARP entry.

Dinesh

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