[rbridge] Updated charter
erik.nordmark at sun.com
Wed Feb 2 16:57:05 PST 2005
Joe Touch wrote:
> The basis of the Internet is a single address layer that spans different
> link layers. There are numerous problems stemming from the rbridge
> basically needing to proxy the semantics of two different L2 systems.
The Internet architecture assumes very little about the L2
infrastructure. For instance, it works with L2s that preserve the same
L2 header (Ethernet being one example) but also over L2s that only use
local identifiers (such as DLCIs in frame relay).
I don't see how running IP over a L2 where the L2 headers are different
when received than when transmitted will cause problems, as long as the
protocols involved in L2 address resolution are handled correctly.
So perhaps you can list the numerous problems.
> What you're proposing is a router that doesn't decrement the TTL.
No. And I think it is in the interest of clarity, especially during
these formative times, that we don't reuse old terms for new things.
So please call it a hybrid, a rbridge, a frobnits, but not a router or a
bridge, since that will confuse things with the routers and bridges that
> not the same as a bridge that uses routing (vs. spanning tree)
> internally; the former doesn't include L2 semantics, the latter does.
> The latter presumes a single L2 semantics, which is easy to verify. The
> former (as you suggest) allows multiple L2s, but does NOT preserve L2
What we are talking about is a hybrid, which includes L2 semantics but
might not preserve L2 semantics when carrying IP packets.
> That means a lot of IP will break where/when the L2s have different
> semantics, e.g., NBMA vs. broadcast. We don't have a uniform L2
> emulation protocol on which to base an interoperability layer (the PILC
> WG noted some of its expected properties, but didn't spec it out as
> such). This work seems like it should avoid L2 translation until that
> canonical virtual L2 can be spec'd.
I don't think anybody has argued that the protocol will support any L2.
What's being suggested is that it support some degree of non-uniformity.
And since we are assuming that ARP/ND be used for L2 address resolution
there is an unstated assumption that all such L2 support
> That the routing inside the rbridge is opaque to things outside the
OK, that I understand.
I think there is a range of semantics that are possible for the hybrids,
and the WG needs to discuss them.
At one end we have what you seem to be arguing for, which I'll call
strict IEEE 802 bridge equivalence,
This means that the cloud of interconnected hybrids behave the same way
as an IEEE compliant bridge. I think this means that not only are the L2
headers not modified, but also that the packets are delivered on the
ports where an IEEE 802 bridge would deliver them (i.e. all ports for
broadcast and multicast).
At another end of the scale we have what I'd call "IP works". In this
case the cloud of interconnected hybrids collectively exhibit behavior
so that IPv*/ARP/ND/DHCP etc work as expected.
Note that there are probably interesting points between these scales.
One is what existing switch products do for multicast, which is to do
IGMP/MLD snooping to limit the spread of multicast.
Presumably there are others as well.
More information about the rbridge