Subject: a concern on bridge-like nd-proxies

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Jul 2003 15:32:15 +0300 (EEST)

Hi,

I tried to raise this issue in the monday's meeting, but let me try to 
augement it a bit.

I have a concern that we're trying to solve all the possible problems with 
bridge-like ND-proxies. (After all, we're engineers and we like to solve 
the problems..)

But, I think we need to really consider whether we NEED or WANT to solve 
those problems.

- what's the applicability of bridge-like ND-proxy?
  * replace the "(consecutive) simple NAT boxes for home" deployment 
model?
  * a model applicable in scenarios where deploying a router would not 
work
  * an ability to expand a /64 over a few links of different L2 media in 
home (or similar networks)
  * single admin domain/trusted environment (where SEND doesn't matter)?

- what's the non-applicability of bridge-like ND-proxy?
  * building large ad-hoc networks
  * a mechanism to replace all of your Ethernet switches / bridges
  * a replacement for routers

(probably missed some but..)

Based on this, I have a very strong gut feeling that we're going into a 
very, very questionable direction if we want to implement e.g.:

 - spanning tree protocol (implying at least 3 boxes which are not 
connected in serial)
 - supporting multiple routers connected in different branches of the 
bridge mesh
 - *having to* support SEND in every case (sure, supporting SEND would be 
nice but if it's too much bother..)

I don't think it's the goal to emulate bridges as closely as possible, as 
bridges (or Ethernet switches) are generic devices.  I don't think we want 
this to be.

Of course, we could write a problem statemetn for ND proxies but Im not 
sure it's required.
  
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: YOSHIFUJI Hideaki / 吉藤英明<[email-masked]>
Date: Wed, 16 Jul 2003 15:07:23 +0200 (CEST)

> bridges (or Ethernet switches) are generic devices.  I don't think we want 

agreed.

--yoshfuji

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Jul 2003 16:02:00 +0200

I'd go a bit further. I messed around with a large bridged
network for some years, and this included messing with ARP
proxies and all the troubles they cause. Basically, making
a level 2 device simulate level 3 functions is a kludge, and it
gets even worse when attempting to "bridge" different LAN
technologies. It probably has some failure modes that are very
hard to analyze.

So while I understand there may be a market for such devices,
I would have very low confidence in our ability to publish
a watertight spec. An informational document would seem
the right way to go, rather than anything that looks like
a standard.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Wed, 16 Jul 2003 10:39:12 -0400

] I'd go a bit further. I messed around with a large bridged
] network for some years, and this included messing with ARP
] proxies and all the troubles they cause. Basically, making
] a level 2 device simulate level 3 functions is a kludge, and it
] gets even worse when attempting to "bridge" different LAN
] technologies.

Lately I find myself wondering if there's not room for a uniform layer 2.5
interface that is designed to work over a set of bridged 802-style layer 2 
networks, but presents a slightly different interface to the host. So for
instance hosts would be explicitly required to announce presence on a link (no
more passive waiting for ARP requests), there would be an explicit L2.5
multicast join/leave (no more sniffing for L3 multicast requests), and there
would be a uniform way for a host to authenticate to the link (no more PPPoE),
with hubs having a way to know whether a particular host/port/address was
authenticated and the ability to switch that host's traffic differently
depending on that bit.  The same authentication interface could be used as a
gateway to control access to a larger network.

The point is to explicitly design such an interface rather than resorting to
more and more tricks.

(has this already been worked on and I just don't know about it?)

Keith

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 16 Jul 2003 21:10:00 +0200 (CEST)

> networks, but presents a slightly different interface to the host. [...]

> (has this already been worked on and I just don't know about it?)

There is a recent proposal in
draft-perlman-zerouter-rbridge-00.txt

which doesn't have authentication and tries to make the network
more scalable by doing better than a spanning tree.

Whether or where this fits in the IETF is an open issue.

  Erik

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 17 Jul 2003 01:12:38 -0400

At 10:39 AM 7/16/2003 -0400, Keith Moore wrote:
>multicast join/leave (no more sniffing for L3 multicast requests) [...]
>

IEEE 802.1 VLANs (Virtual LANs) are intended to provide this
type of function in L2 switches...  Many people even refer to
VLANs as "layer 2.5"...

I think that the idea of Dave Thaler's draft, though (and similar
work by others) is to switch at layer 3, so that there is no need
for layer 2 switching in this type of environment.

Margaret

---

From: Aidan Williams <[email-masked]>
Date: Thu, 17 Jul 2003 22:30:23 +1000

>> (has this already been worked on and I just don't know about it?) 
See also
http://www.ietf.org/internet-drafts/draft-perlman-zerouter-rbridge-00.txt
It doesn't address authenticating link access.

> for layer 2 switching in this type of environment.

Right.

And also to providing bridging of IP traffic across link layers that
don't use 48bit 802-style L2 addressing.

- aidan

---

From: Alper Yegin <[email-masked]>
Date: Tue, 22 Jul 2003 09:10:22 -0700

On 7/16/03 7:39 AM, "Keith Moore" <[email-masked]> wrote:

> multicast join/leave (no more sniffing for L3 multicast requests),

> and there

We are working on a standard L3 solution for that part:
http://www.ietf.org/html.charters/pana-charter.html

FYI..

Alper

---

From: Keith Moore <[email-masked]>
Date: Tue, 22 Jul 2003 12:13:08 -0400

> http://www.ietf.org/html.charters/pana-charter.html

thanks for the information.  but I really hate to see this all done
piecemeal.  it really needs to be a l2 solution, and it needs to
be comprehensive.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Alper Yegin <[email-masked]>
Date: Tue, 22 Jul 2003 09:26:31 -0700

Hi Keith,

> piecemeal.  it really needs to be a l2 solution, and it needs to

Do you mean a L2 solution that works on all types of link-layers?

Alper

---

From: Keith Moore <[email-masked]>
Date: Tue, 22 Jul 2003 12:36:34 -0400

> Do you mean a L2 solution that works on all types of link-layers?

[off-topic for ipng - further discussion in private mail if you wish.]

I'd be happy with one that worked on 802.*-like link layers, or to
be more precise, link layers that have addressing, > 2 points of access,
and multicast.  PPP could still be used for point-to-point links.
Some of the details might need to vary from one L2 to another, but
they should all share a common framework, multicast group space, and
credentials space, so that bridging them makes sense.