Subject: [rbridge] area addr question

From: "Jeff Pickering" <[email-masked]>
Date: Thu, 3 Dec 2009 10:01:31 -0800

All Rbridges must participate in the TRILL IS-IS instance, which

   constitutes a single Level 1 IS-IS area using the fixed area-ID zero.

Does this mean zero length or zero value? If zero len, is that legal? If zero
value what's the len?
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 3 Dec 2009 13:28:26 -0500

I think the length should be 1, but this should be specified in a future
revision of draft-ietf-isis-layer2.

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

---

From: James Carlson <[email-masked]>
Date: Thu, 03 Dec 2009 14:13:07 -0500

> revision of draft-ietf-isis-layer2.

That's what we used; length 1, with a single octet of 00.

-- 
James Carlson         42.703N 71.076W         <[email-masked]>
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: radia <[email-masked]>
Date: Thu, 03 Dec 2009 21:40:17 -0800

Is "0" the default, and it could be configured to be something else (for 
instance, one way to
ensure two TRILL campuses don't accidentally merge), or is it always 0?

Radia

---

From: James Carlson <[email-masked]>
Date: Fri, 04 Dec 2009 08:22:09 -0500

> ensure two TRILL campuses don't accidentally merge), or is it always 0?

The existing Quagga configuration commands are still there, so you could
set it if you wanted.  I think it'd probably be a mistake to do so, as I
don't think we've figured out what loop avoidance would look like with
connected but independent TRILL areas.

---

From: radia <[email-masked]>
Date: Sat, 05 Dec 2009 12:21:18 -0800

Good point.  The problem you are talking about, I think, is when R1 in 
area A1, is on the same link
as R2 in area A2. R1 and R2 might both decide to encapsulate/decapsulate 
from that link even
if they refuse to talk to each other. So if we were to think about this 
case,
one of R1 or R2 should turn off the port completely (don't transmit, but 
continue to receive the other RBridge's Hellos
in order to stay suppressed), rather than just refusing to talk to the 
other RBridge neighbor.

Radia

---

From: jeff pickering <[email-masked]>
Date: Mon, 07 Dec 2009 11:50:06 -0800

I also think it would be a mistake to make the area address 
configurable. It serves no purpose and
could be dangerous.

Jeff

---

From: James Carlson <[email-masked]>
Date: Thu, 10 Dec 2009 09:57:06 -0500

> in order to stay suppressed), rather than just refusing to talk to the

Yes, I think that at a minimum, we need to compare received area
numbers, and disable the port based on some rule (say, smallest area
number 'wins' -- so that the default of zero always wins, and any other
areas are auxiliary).

What we're missing is the equivalent of a root bridge ID.  When a TRILL
cloud is attached to the same 802-bridged network through multiple
links, we can detect that by seeing our own hellos and (when VLANs
interfere) by seeing the same root bridge ID.  However, when connected
to another TRILL cloud, we don't get those same clues, because TRILL
nodes don't forward TRILL hellos, and don't communicate a single 802
root bridge ID through the whole network.

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 10 Dec 2009 10:22:53 -0500

Wait a second... Before worrying about additional complexities to handle
adjacent TRILL clouds with different area numbers, why is this happening?
The spec requires them all to use area zero. The address space is flat so
there doesn't seem to be any advantage to breaking it up.... And you will
get more efficient routing paths if they all peer.

Donald

PS: If you do want the equivalent of the "root bridge ID" for RBridges, it
is easy enough. They all have to determine the RBridge with the highest
priority to be a distribution root for multidestination frames. The SystemID
of that RBridge could serve as a "root RBridge ID" and could be included in
TRILL Hellos. But, as I say, I just don't see the need or motivation for
this.
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
[email-masked]

---

From: James Carlson <[email-masked]>
Date: Thu, 10 Dec 2009 10:55:18 -0500

Donald Eastlake wrote:
> adjacent TRILL clouds with different area numbers, why is this
> happening? The spec requires them all to use area zero. The address
> space is flat so there doesn't seem to be any advantage to breaking it
> up.... And you will get more efficient routing paths if they all peer.

To be clear: I don't want to use different area numbers.  The current
spec says area zero only, and that's all I ever want to use.

Radia asked whether it was possibly configurable, and it is, and we were
discussing the implications of doing that.

> PS: If you do want the equivalent of the "root bridge ID" for RBridges,
> it is easy enough. They all have to determine the RBridge with
> the highest priority to be a distribution root for multidestination
> frames. The SystemID of that RBridge could serve as a "root RBridge ID"
> and could be included in TRILL Hellos. But, as I say, I just don't see
> the need or motivation for this.

You would also need to carry this information around through other areas
-- just as we currently do for root bridge IDs.

---

From: Radia Perlman <[email-masked]>
Date: Fri, 11 Dec 2009 12:46:28 -0800

Just to clarify the reason for allowing area address to be configurable: 
it is in case someone wants to
build two TRILL campuses that someone could inadvertently interconnect, 
and they want to
prevent them from merging. This might be because of wanting to limit the 
size of each of the
campuses, or because the VLANs are used in overlapping ways in the two 
campuses. I'm not sure
whether there's any other way besides area addresses of preventing two 
TRILL clouds from merging
if someone interconnects them.

The way it would work is that if there were two campuses, and someone 
wanted to ensure they
don't get inadvertently interconnected, *every* RBridge in one of the 
campuses would be configured
with an area address, of, say X.

What would need to be in the spec to ensure these campuses are not 
interconnected would be
words something like:

"If R1 receives a TRILL-Hello on port p, with area address X, not equal 
to R1's area address Y,
then if X > Y, R1 does not transmit anything on port p (including 
Hellos), until all Hellos with
area address X have expired."

I don't understand the comment about "equivalent of "root bridge ID" in 
connection to the issue
of allowing configuration of area address.

Radia

---

From: James Carlson <[email-masked]>
Date: Fri, 11 Dec 2009 16:14:27 -0500

> area address X have expired."

That works.

> of allowing configuration of area address.

I didn't know what your intent was.  That comment was in regard to a
situation in which someone wanted to have separate area IDs *and* wanted
to allow them to connect at the forwarding level.  In that case, we have
to be very careful about where we enable ports, or we could end up with
loops -- for essentially the same reason we would end up with loops in
the case where two of our cloud's ports are connected together by 802
bridges that are (mis)configured to block the VLANs being used for TRILL
hellos.

If the intention is to avoid any interconnection, then I agree that the
answer is easy, and that comparing areas does it.