[rbridge] Updated charter

[Erik Nordmark]

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 
exist today.

> That's 
> 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 
> semantics.

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 
broadcast/multicast.

> That the routing inside the rbridge is opaque to things outside the 
> rbridge.

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.

    Erik