[rbridge] Updated charter

[touch at ISI.EDU (Joe Touch)]

Erik Nordmark wrote:
> 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.

It works fine, as you noted, over pt-pt links, but not over things that 
are intended to look like shared media, e.g., subnets.

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

Why? It walks like a router, talks like a router, and quacks like a 
router. Examining the IP layer, changing L2 headers, etc. The only thing 
it doesn't do that a router does - so far - is decrement the TTL. Others 
would be, e.g., to limit all 1's broadcast.

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

Huh? You're preserving L2 semantics but only for IP, which doesn't care 
(above) about such preservation?

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

But we were talking about such support in ways that avoided broadcast...

>> 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).

Agreed.

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

Why can't we call that a router that doesn't decrement TTL?

> 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

Bridges can - and do limit the spread of multicast. They do not limit 
the spread of broadcast based on L3 semantics (unless doing explicit 
proxy-arp, but that's not what we're talking about). If there's an 
intermediate point between the above two, it'd be useful to figure out 
what it IS and why it's needed before we created a WG to design it.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050202/bd5c5938/signature.bin
From erik.nordmark at sun.com  Wed Feb  2 18:19:13 2005
From: erik.nordmark at sun.com (Erik Nordmark)
Date: Wed Feb  2 18:21:46 2005
Subject: [rbridge] Agenda items?
Message-ID: <[e-mail]>


It is time to start thinking about the agenda for the BoF/WG meeting in
Minneapolis.

Presumably we should go over the charter, but I'd like to also spend time on
technical discussions, which is the subject of this email.

I think there are several technical items that makes sense to discuss, and
I've tried to capture things from memory here. If you had additional items
let me know we can add them (but you might get volunteered :-).
If you need stimulation it might make sense to re-read 
draft-perlman-rbridge,
and see if there are issues that come to mind.

What I'd like for each of these items is to have a volunteer who will 
present
the topic with the issues and the tradeoffs (but no "solutions"), so 
that we
all can try to understand the different issues, and how they might interact.

I'd like to see each topic be presented in advance (so that folks can read
about it) either as a concise email to the list (which we can reference 
using
URLs to the archive) or in the form of a short internet draft.

Here are the topics I have so far:
1. What is the desired semantics of the cloud of hybrids? Just "strict IEEE
    802 bridge equivalence", "IP works", or something in between?

    I'll volunteer myself to lead the discussion on this topic.

2. Threats and security considerations
    What should the goal be? What can we do better?

    Does anybody who brought this up on the list want to volunteer?

3. Requirements on routing protocols
     For zero configuration
     Carrying MAC addresses
     Broadcast
     IS-IS vs. OSPF vs. something else

    Volunteer? I can dig out the discussion I had with Bob Hinden if
    that would stimulate someone to want to discuss this.

4. Connecting different L2 types (with different L2 address formats)

    I think I've convinced Radia to lead this one

5. Choices for ARP/ND

    We had some discussion on the list about this and how it relates to
    intentionally duplicate L2 addresses, mobility, etc.

    Any volunteers?

6. Choices for broadcast/multicast

    Any volunteers?

What am I missing?


    Erik