Subject: [rbridge] Minor issue in draft-touch-trill-rbridge-arch-00a.txt

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Tue, 08 Nov 2005 16:59:29 -0800

N       N---b3---N
                              |           ||
                              |           ||
                              |           h2
                              |          /| \
                              |         / N  \
                              |        /      \
                         N---h1--r4***r5******r6
                                 *   *        *
                                 *  *         *
                                 * *          *
                             N---r7***********r9-----N
                                  \          /|\
                                   \        / | \
                                    \      /  N  N
                                     \    /
                                      \  /
                                       b8
                                       |
                                       N

              Figure 3 Reorganized RBridge Ethernet link subnet

Since there might be a hub or bridge between e.g. r4 and r7 that they 
can't see (in addition to the hub it could also be a bridge which 
doesn't speak BSTP). Thus I think the RBridges must assume that the path 
between any pair of them might have nodes/stations attached, just as in 
the r7-r9 path.

I think this makes the "inside" vs. "outside" definitions not very 
helpful in terms of understanding the toplogy; we have paths between 
RBridges which carry encapsulated frames, but for those we also have a 
designated forwarder which sends unencapsulated frames out, in order to 
handle the r7,r9,b8 type topology above.

For instance, I think an RBridge must treat all its ports as external. 
In addition, a port would also be internal when the discovery protocol 
finds that there are other RBridges directly reachable over that port.

    Erik

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 08 Nov 2005 17:45:22 -0800

> between any pair of them might have nodes/stations attached, just as in

They can assume that, but then the diagram wouldn't 'reorganize' to this
diagram. I showed that property on the r7-r9 link (for bridge b8) and on
the r5-r6 link (for a hub, e.g., h2).

> handle the r7,r9,b8 type topology above.

That's already shown above; I noted that the diagram is topological (who
talks to whom), not traffic/bandwidth (who transparently is carried over
whom).

> finds that there are other RBridges directly reachable over that port.

Rbridges treat all their physical ports as external ports, and all their
tunnels (logical ports) as internal ports.

No physical port 'becomes' internal; a tunnel is created on that port,
and it is the tunnel that is internal.

(I should have put that in the second doc; that'll make it in there later).

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051108/61361549/signature.bin

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Tue, 08 Nov 2005 18:28:58 -0800

> and it is the tunnel that is internal.

By "tunnel" do you mean that packets are always encapsulated when 
sending on these logical, internal ports?

While this is necessary for the frames being forwarded, it isn't clear 
to me that it is required to encapsulate the control packets the 
rbridges exchange with each other (for discovering each other as well as 
the routing protocol exchanges).

    Erik

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 08 Nov 2005 18:41:01 -0800

> sending on these logical, internal ports?

Yes.

> the routing protocol exchanges).

The diagrams discussed data traffic, not control traffic. All data
traffic is tunneled.

You are correct that routing information might not go over tunnels, but
I'm wondering why - the performance benefit is minimal, and by using the
tunnels the routing protocol 'fate shares' the data paths - I thought
that was a desirable property.

So, strictly, it's not required, but what's the benefit?

We can define internal/external just as easily without discussing
tunnels, FWIW (sorry, I lost this idea while I was writing the drafts,
but can fix it): all internal traffic is addressed TO the rbridge's 802
address (whether it is tunneled or not). I also didn't get to the part
where we need to discuss how many 802 addresses an rbridge has (it may
need one per port; I can't see how to avoid that - more in the update to
the draft on that).

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051108/1dd5b57c/signature-0001.bin

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Tue, 08 Nov 2005 19:59:27 -0800

> So, strictly, it's not required, but what's the benefit?

The discovery packets might be the more interesting case.
The encapsulation header includes the "next hop" as well as "final 
rbridge", and at least the last one would be useless hence potentially 
confusing for the discovery packets, since they take a single RBridge 
hop to an unknown (multicast) destination.

> need one per port; I can't see how to avoid that - more in the update to

Yes, I think describing internal vs. external *traffic* (or frames) is 
useful. Basing that on the destination address is probably general enough.

But the current set of definitions try to define internal and external 
*parts of topology*, which I think adds confusion.

    Erik