Subject: [rbridge] rbridge Digest, Vol 17, Issue 5

From: ssuryaputra at gmail.com (Stephen Suryaputra)
Date: Tue, 11 Oct 2005 14:35:26 -0400

On 10/8/05, rbridge-request at postel.org <rbridge-request at postel.org> wrote:
> Joe Touch wrote:

[ deleted ]

As to the above,, here's a clarified version:
>
> There are three kinds of L2 devices in an rbridge:
>
> hosts: anything that sources/sinks L2 packets
> e.g., RFC1122-style hosts, RFC1812-style routers
> (routers act like hosts to L2)
>
> bridges: transit conventional L2 packets and source/sink/transit
> spanning tree messages
>
> rbridges: encapsulate/decapsulate L2 packets with shim/L2 hdrs
> exchange routing via IS-IS,
> exchange egress tables via some protocol (TBD)

I have been following the discussion on and off recently, and am still
catching up. This is the first time I heard about egress table. Is it the L2
address to egress Rbridge mapping? If yes, why do we need another protocol
to exchange those? I thought IS-IS was chosen because it is easy to
advertise those L2 addresses using its link state packet?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/rbridge/attachments/20051011/a1b5b4c0/attachment.html

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 11 Oct 2005 12:02:37 -0700

I was actually talking with Joe about a good name for that table.
There is the forwarding table, which maps egress RBridge to next hop.
There is the link state database, which talks about connectivity between 
RBridges.
Then there's what I'd call the endnode table (and Joe is calling the 
egress table), which
maps endnode membership to egress RBridge.

It would be nice to have an agreed-upon name for it that everyone will 
know what is
being referred to. I don't care about names.

But back to your question...why can't IS-IS advertise those addresses in 
link state packets?
Yes, it is the obvious choice in the absence of VLANs, because in that 
case, all the RBridges
would need to know about all the endnodes.

If there are lots of VLANs, then if an RBridge is not attached to VLAN A 
(none of its ports source
or sink packets for VLAN A, though they can be used as transit links for 
VLAN A packets), it does
not need to know where the VLAN A endnodes are located. Only the ingress 
RBridge (which would
be connected to a port on VLAN A) would look up the mapping from endnode 
to egress RBridge,
and stick the egress RBridge in the shim header.

So...how should VLAN A endnode membership be passed around? There are 
various choices:
a) in one instance of IS-IS, along with the RBridge topology information
b) have an instance of IS-IS per VLAN, just for passing around the 
endnode information for that VLAN.
This would be a fairly trivial subset of IS-IS, because there is no 
forwarding of link state information.
The VLAN A instance of IS-IS would use the VLAN A broadcast domain 
created by the main
IS-IS instance, to have each RBridge in VLAN A announce its directly 
attached VLAN A endnodes
c) have some other protocol, simpler than IS-IS (because link state 
information never needs to be forwarded),
that just sends out endnode information.

I believe the IS-IS people preferred multiple instances of IS-IS, one 
per VLAN.

The advantage of not putting this information into the main instance is 
that if R is not attached to VLAN A,
it will not need to store this information. In either case, R would not 
need to look at it, but if it's
one instance, R needs to store it for the reliable link state flooding. 
If it's a VLAN A instance layered
over, then R will be forwarding this endnode reachability information, 
but just as datagrams.

This was discussed a couple of months ago. I'm not sure anyone had 
strong opinions about it, but hopefully
people understand the issue. And hopefully somewhere in there I answered 
your question.

Radia

> catching up. This is the first time I heard about egress table. Is it 
> the L2 address to egress Rbridge mapping? If yes, why do we need 
> another protocol to exchange those? I thought IS-IS was chosen because 
> it is easy to advertise those L2 addresses using its link state packet?
>
> Thanks.
>
>  
>

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 11 Oct 2005 13:04:50 -0700

Stephen Suryaputra wrote:
> 
> On 10/8/05, *rbridge-request at postel.org
> <mailto:rbridge-request at postel.org>* <rbridge-request at postel.org
> <mailto:rbridge-request at postel.org>> wrote:
> 
>     Joe Touch wrote:
> 
> [ deleted ]
> 

Hi, Stephen,

> the L2 address to egress Rbridge mapping?

The L2 ingress address is mapped to rbridge egresses.

> If yes, why do we need another
> protocol to exchange those? I thought IS-IS was chosen because it is
> easy to advertise those L2 addresses using its link state packet?

Someone else can clarify; my understanding is that IS-IS will help with
distributing the hop-by-hop forwarding tables inside the rbridge nodes
(as an IGP), but doesn't have enough information to distribute egresses
(that would be more what an EGP would do).

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 11 Oct 2005 13:24:50 -0700

> I was actually talking with Joe about a good name for that table.

I was wondering if we might call it the Campus Transit Table (CTT), and
the other one the Campus Forwarding Table (CFT) - to distinguish it from
conventional IP router forwarding tables, or frame forwarding tables
inside conventional bridges using spanning trees.

Below is a cut of some proposed terminology, including the above.
Discussion encouraged; please limit discussion to the definitions here;
other topics will be raised in separate emails.

Joe

- ------------------------------------------------------------------------

Existing Terminology
[THIS IS TRYING TO ENCODE EXISTING TERMS; NOT NEW DEFINITIONS]

- - 802.1: IEEE Specification for Ethernet, i.e., including hubs (but
excluding bridges??)

- - 802.1D: IEEE Specification for switched Ethernet, i.e., including
bridges (??)

[WHAT?S THE DIFFERENCE BETWEEN 802.1, 802.1D, etc.? DOES IT MATTER?]

- - Bridge: an Ethernet (L2, 802.1D) forwarding device that participates
in the bridge spanning tree (BST).

- - Bridge spanning tree (BST): an Ethernet (L2, 802.1D) forwarding
protocol based on the topology of a spanning tree

- - Bridge spanning tree protocol (BSTP): an Ethernet (802.1D) protocol
for establishing and maintaining a single spanning tree among all the
bridges on a logical segment.

- - Frame: here refers to an Ethernet (L2) unit of transmission, including
the header, data, and trailer.

- - Frame forwarding table (FFT): forwarding table in existing bridges

- - Hub: an Ethernet (L2, 802.1)

- - Node: a device with an L2 address that sources and/or sinks L2
packets; nodes can occur outside the RBridge campus or be used as
transits within the campus.

- - Packet: here refers t- an IP (L3) unit of transmission, including
header and data.

- - Segment: an L2 link, either a single physical link or emulation
thereof (e.g., via hubs) or a logical link or emulation thereof (e.g.,
via bridges).

- - Router: an IP (L3) forwarding device; RBridges cannot span routers.

==========================================================================
RBridge Terminology

- - Campus: a set of RBridge devices inside the same L2 subnet, all of
which participate as a group to forward ingress L2 frames across the
campus via encapsulation.

- - Campus Forwarding Table (CFT): the per-hop forwarding table populated
by the rbridge IGP based on lookups of the CTH inside the outermost
received L2 header, rather than that L2 header.

- - Campus Transit Header (CTH): a ?shim? header that encapsulates the
ingress L2 frame and persists throughout the transit of a campus, which
is further encapsulated a hop-by-hop L2 header/trailer.

- - Campus Transit Table (CTT): a table that maps ingress L2 destinations
to egress RBridge addresses, used to encapsulate ingress frames for
transit of the campus.

- - RBridge: layer-2 devices that automatically aggregate into a virtual
device that emulates a single bridge on a conventional 802.1 Ethernet.

- --------

---

From: ssuryaputra at gmail.com (Stephen Suryaputra)
Date: Tue, 11 Oct 2005 17:53:03 -0400

> that just sends out endnode information.

This may have been discussed before. Since the first packet will go through
the spanning tree due to multicast/broadcast/unknown, why not the shim
header contain both ingress and egress Rbridge and let the egress Rbridge
learn the original L2 source address to ingress Rbridge mapping (the same as
bridge learning today with aging timer)? Rbridges on the path that are
connected to the same VLAN can use the same information.

Stephen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/rbridge/attachments/20051011/7f7a7f20/attachment.html

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 11 Oct 2005 15:18:33 -0700

Actually, Stephen,
you are right. The possibility you mention was also considered, and I left
it off that list below. If I remember correctly, I think people didn't 
like it
because it made the shim header larger on every packet, and it required
learning while forwarding data packets. The arguments for it, though,
are that inactive endnodes don't occupy space, and there's no explicit
protocol necessary for learning endnode information.

Perhaps there wasn't consensus on dropping that possibility.

It would be good to restart a thread (with a subject line more 
descriptive than
"rbridge Digest, Vol 17, Issue 5" probably),
specifically just on this one issue...possibilities for
learning endnode information, that has at least the three choices I put 
in below, plus the
one Stephen added, which is to have both ingress and egress RBridges in 
the shim header,
and have either all RBridges that forward the encapsulated packet, or 
just the egress
RBridge, learn the mapping of (ingress RBridge, source MAC) for that 
packet.

Radia

*******************

On 10/11/05, *Radia Perlman* <Radia.Perlman at sun.com 
<mailto:Radia.Perlman at sun.com>> wrote:

    a) in one instance of IS-IS, along with the RBridge topology
    information

This may have been discussed before. Since the first packet will go 
through the spanning tree due to multicast/broadcast/unknown, why not 
the shim header contain both ingress and egress Rbridge and let the 
egress Rbridge learn the original L2 source address to ingress Rbridge 
mapping (the same as bridge learning today with aging timer)? Rbridges 
on the path that are connected to the same VLAN can use the same 
information.

Stephen.

Stephen Suryaputra wrote:

>
>
> On 10/11/05, *Radia Perlman* <Radia.Perlman at sun.com 
> <mailto:Radia.Perlman at sun.com>> wrote:
>
>
> This may have been discussed before. Since the first packet will go 
> through the spanning tree due to multicast/broadcast/unknown, why not 
> the shim header contain both ingress and egress Rbridge and let the 
> egress Rbridge learn the original L2 source address to ingress Rbridge 
> mapping (the same as bridge learning today with aging timer)? Rbridges 
> on the path that are connected to the same VLAN can use the same 
> information.
>
> Stephen.
>
>------------------------------------------------------------------------
>
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>  
>