[rbridge] Updating Expired Draft

[margaret at thingmagic.com (Margaret Wasserman)]

Radia, are you planning to update the rbridge proposal before the 
draft cut-off (21-Feb at 9am EST)?  The current I-D has expired.

Erik, will there be other I-Ds on the agenda?

Margaret
From touch at ISI.EDU  Sat Feb 12 09:29:35 2005
From: touch at ISI.EDU (Joe Touch)
Date: Sat Feb 12 09:31:12 2005
Subject: [rbridge] Updating Expired Draft
In-Reply-To: <p0620072fbe33a904be61@[192.168.2.2]>
References: <[e-mail]>
	<[e-mail]>	<[e-mail]>
	<[e-mail]> <p0620072fbe33a904be61@[192.168.2.2]>
Message-ID: <[e-mail]>

I am ;-)

If anyone has other mods, please send them to me.

Margaret Wasserman wrote:
> 
> Radia, are you planning to update the rbridge proposal before the draft 
> cut-off (21-Feb at 9am EST)?  The current I-D has expired.
> 
> Erik, will there be other I-Ds on the agenda?
> 
> Margaret
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
-------------- 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/20050212/2e42bb17/signature.bin

Received: from [192.168.1.47] (lsanca1-ar42-4-61-185-150.lsanca1.dsl-verizon.net [4.61.185.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j1CHTdQ14726; Sat, 12 Feb 2005 09:29:39 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sat, 12 Feb 2005 09:29:35 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Updating Expired Draft
References: <[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]> <p0620072fbe33a904be61@[192.168.2.2]>
In-Reply-To: <p0620072fbe33a904be61@[192.168.2.2]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2855B2E2AAB80C86E2E4519C"
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: Radia Perlman <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 12 Feb 2005 17:31:11 -0000
Status: RO
Content-Length: 1141

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2855B2E2AAB80C86E2E4519C
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I am ;-)

If anyone has other mods, please send them to me.

Margaret Wasserman wrote:
> 
> Radia, are you planning to update the rbridge proposal before the draft 
> cut-off (21-Feb at 9am EST)?  The current I-D has expired.
> 
> Erik, will there be other I-Ds on the agenda?
> 
> Margaret
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge

--------------enig2855B2E2AAB80C86E2E4519C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCDjz/E5f5cImnZrsRAptKAJ4gu+p9SAcIz+ee8WXQmaXhqhW8SQCfdyPZ
/otMM2+5waM1wWnGknUyTxA=
=j0sb
-----END PGP SIGNATURE-----

--------------enig2855B2E2AAB80C86E2E4519C--


Received: from thingmagic.com ([204.9.221.21]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j1CChsQ23726 for <[e-mail]>; Sat, 12 Feb 2005 04:43:54 -0800 (PST)
Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 285577; Sat, 12 Feb 2005 07:42:19 -0500
Mime-Version: 1.0
Message-Id: <p0620072fbe33a904be61@[192.168.2.2]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 12 Feb 2005 07:40:23 -0500
To: [e-mail]
From: Margaret Wasserman <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: Radia Perlman <[e-mail]>
Subject: [rbridge] Updating Expired Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 12 Feb 2005 12:45:02 -0000
Status: RO
Content-Length: 190

Radia, are you planning to update the rbridge proposal before the 
draft cut-off (21-Feb at 9am EST)?  The current I-D has expired.

Erik, will there be other I-Ds on the agenda?

Margaret


Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j1A5mwQ05234 for <[e-mail]>; Wed, 9 Feb 2005 21:48:58 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j1A5mvnK024541 for <[e-mail]>; Wed, 9 Feb 2005 22:48:57 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 10 Feb 2005 00:48:57 -0500 (EST)
Received: from [192.168.2.58] (vpn-129-147-152-33.Central.Sun.COM [129.147.152.33]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Thu, 10 Feb 2005 00:48:57 -0500 (EST)
Date: Wed, 09 Feb 2005 21:48:56 -0800
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Multicast options
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Feb 2005 05:50:55 -0000
Status: RO
Content-Length: 1143

Aidan Williams wrote:

>
> If it is worth doing optimal forwarding for unicast why
> is it not worth it for multicast?


If there's no way to do pruning (as is the case with multicasts that 
aren't derived from
IP multicast, and therefore not advertised by the endnodes in IGMP), 
then there's no
particular "optimization" of delivery with one spanning tree vs another. 
I think the
real "cost" of delivery should be the number of packet hops, and to 
deliver to all the
links will be the same number of packet hops no matter which node is 
chosen to be
the root of the tree. With unicast bridge-like spanning tree forwarding, 
then optimality
of the paths can be quite different depending on which spanning tree is 
chosen.

For IGMP-pruned multicast it's a different story. The Dijstra 
calculation is "greedy", and
will calculate shortest paths to each link from the source, so if there 
are only listeners on
a couple of links, then delivery will be optimized.

Another reason one might argue for per-source spanning trees is to 
spread the traffic
around. With one spanning tree, all multicast traffic will go on the 
same tree.

Radia




Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j19LpSQ16362 for <[e-mail]>; Wed, 9 Feb 2005 13:51:28 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.87.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j19LpSPD012997 for <[e-mail]>; Wed, 9 Feb 2005 13:51:28 -0800 (PST)
Received: from [129.146.89.82] (par.SFBay.Sun.COM [129.146.89.82]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j19Lp0fM864624; Wed, 9 Feb 2005 13:51:27 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 09 Feb 2005 13:50:59 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Choice of routing protocols
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Feb 2005 21:52:53 -0000
Status: RO
Content-Length: 1028

Pekka Savola wrote:

> 
> I'd also like to consider using OSPF as a basis for the simple reason 
> that it has been widely implemented by the same vendors we'd like to 
> ship Rbridges.  Those low-end router manufacturers don't implement 
> IS-IS, so this would incur a steeper curve for implementation.
> 
> However, as for IPv6 one would have to use OSPFv3 as a basis (and then 
> one could use draft-ietf-ospf-af-alt-01.txt), not OSPFv2, this does not 
> seem to be all that relevant consideration anymore because those low-end 
> vendors don't implement OSPFv3 in any case.
> 
> That said, the arguments below seem to indicate that using OSPF has some 
> serious issues (mainly relating to IP address assignment) and IS-IS may 
> be a better fit, with an automated NSAP address "generation".
> 
> To avoid rehashing this discussion over and over again, these 
> considerations should be nailed down in the charter or an internet-draft.

Excellent suggestion. Any volunteers for starting to capture this as an I-D?

    Erik


Received: from miews.nicta.com.au ([129.94.138.156]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j19503Q03337 for <[e-mail]>; Tue, 8 Feb 2005 21:00:03 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by miews.nicta.com.au (Postfix) with ESMTP id 835AC12A595 for <[e-mail]>; Wed,  9 Feb 2005 15:59:56 +1100 (EST)
Message-ID: <[e-mail]>
Date: Wed, 09 Feb 2005 15:59:56 +1100
From: Aidan Williams <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041217
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Multicast options
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Feb 2005 05:00:54 -0000
Status: RO
Content-Length: 2283

Radia Perlman wrote:
> Some choices for RBridges are: a) send all multicasts on the single
> computed spanning tree, and endnodes can filter by telling their
> local NIC card b) like a), but have some link-local method of the
> endnodes informing the RBridge what layer 2 multicast destinations
> they want to receive, so the RBridge won't send on the last hop if
> there are no listeners c) still send all multicasts on the single
> computed spanning tree, but have RBridges stick locations of
> receivers of G into their LSPs, and then prune that one spanning tree
> if there are no downstream listeners for G d) compute per-source
> spanning trees and filter them based on where the listeners are (like
> MOSPF).
> 

How about using a per-source spanning tree for distribution
without passing listener location info around in the LSPs?

IGMP snooping could then be used to prune the optimal tree
for multicast IP traffic.  This would be analogous to how
current switches use IGMP messages to prune multicast
distribution today.

I agree that non-IP multicast probably boils down to option a).



> Personally, I think d) (having RBridges compute separate per-source 
> spanning trees) is not worth the complexity, but it's not impossibly
> complex/expensive. It doesn't require any extra messages on the wire
> (since RBridges can compute any spanning tree they want from the link
> state database). The difference between b) and c) is whether RBridges
> pass around the location of receivers in their LSPs. So c), although
> it allows more optimal data delivery, does involve more bandwidth for
> the routing protocol (especially since LSP information will be more
> volatile if location of receivers from groups is included).
> 

If it is worth doing optimal forwarding for unicast why
is it not worth it for multicast?  Perhaps there is a
hidden assumption that there won't be much multicast
traffic.  On the networks I'm using there can be a lot
of multicast traffic and I would like it to take the
best path from the sender to any receivers.

I would like to see efficient multicast forwarding with some
mechanism for pruning available.  The pruning mechanism could
be built into the rbridge protocol/design or could be achieved
via a technique like IGMP snooping.

- aidan



Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j190K3Q06352 for <[e-mail]>; Tue, 8 Feb 2005 16:20:03 -0800 (PST)
Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.92.1.67]) by palrel12.hp.com (Postfix) with ESMTP id 7367D4005C7 for <[e-mail]>; Tue,  8 Feb 2005 16:20:03 -0800 (PST)
Received: from cacexc06.americas.cpqcorp.net ([16.92.1.28]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);  Tue, 8 Feb 2005 16:19:56 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [rbridge] Multicast options
Date: Tue, 8 Feb 2005 16:19:56 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Multicast options
Thread-Index: AcUOORPnx6s2VnUyQ6K2RAy7txdtmAAAzZVw
From: "Ghanwani, Anoop" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 09 Feb 2005 00:19:56.0740 (UTC) FILETIME=[158EC840:01C50E3D]
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j190K3Q06352
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Feb 2005 00:20:49 -0000
Status: RO
Content-Length: 550

> My suspicion is that for layer 2 multicasts other than 
> IP-derived ones, 
> we have no choice
> but to do a), even though I think 802 is working on some IGMP-like 
> thing, since we
> can't assume all endnodes will have implemented it.

IEEE 802.1D has had for a while now a protocol called 
GMRP which limits the propagation of multicasts to segments 
of the spanning tree where there are registered participants.
The protocol hasn't seen much deployment, since IGMP-snooping
seems to work well for most applications that are out there.

Anoop


Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j18Ng6Q26155 for <[e-mail]>; Tue, 8 Feb 2005 15:42:06 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j18Ng5PD007122 for <[e-mail]>; Tue, 8 Feb 2005 15:42:05 -0800 (PST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Tue, 08 Feb 2005 18:42:05 -0500 (EST)
Received: from [192.168.2.58] (vpn-129-150-16-79.SFBay.Sun.COM [129.150.16.79]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Tue, 08 Feb 2005 18:42:05 -0500 (EST)
Date: Tue, 08 Feb 2005 15:42:08 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
References: <[e-mail]>
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Multicast options
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 08 Feb 2005 23:42:50 -0000
Status: RO
Content-Length: 2792

It might help, for each of the items on the agenda, to start off with an 
email
summarizing the problem, with alternatives, and some pros and cons.
It's hard when all the discussion is jumbled up with a single subject line
of "agenda items", so I'm starting a different thread, at least for this 
one, since
I recently did a summary of the alternatives for a different discussion.

The problem is: what should RBridges do with layer 2 multicast packets?
The various alternatives are all tradeoffs between protocol complexity, 
protocol
overhead, optimization of bandwidth for data packet delivery, 
compatibility with
existing endnodes.

Some choices for RBridges are:
a) send all multicasts on the single computed spanning tree, and 
endnodes can
filter by telling their local NIC card
b) like a), but have some link-local method of the endnodes informing 
the RBridge what layer 2
multicast destinations they want to receive, so the RBridge won't send 
on the last
hop if there are no listeners
c) still send all multicasts on the single computed spanning tree, but 
have RBridges stick
locations of receivers of G into their LSPs, and then prune that one 
spanning tree if there
are no downstream listeners for G
d) compute per-source spanning trees and filter them based on where the 
listeners are
(like MOSPF).

Doing anything other than a) assumes some sort of universally 
implemented IGMP-like
thing at layer 2. Now we could do something fancy for IP-derived layer 2 
multicasts, because
we can assume that the IP multicast nodes will be doing IGMP (can we 
assume a particular
version of IGMP or would RBridges need to understand all versions of 
IGMP), allowing
more optimal delivery of multicasts derived from IP multicast addresses, 
and then send
any other layer 2 multicasts everywhere (like bridges or a hard-wired 
Ethernet would do).

My suspicion is that for layer 2 multicasts other than IP-derived ones, 
we have no choice
but to do a), even though I think 802 is working on some IGMP-like 
thing, since we
can't assume all endnodes will have implemented it.

Personally, I think d) (having RBridges compute separate per-source 
spanning trees) is
not worth the complexity, but it's not impossibly complex/expensive. It 
doesn't require
any extra messages on the wire (since RBridges can compute any spanning 
tree they
want from the link state database). The difference between b) and c) is 
whether
RBridges pass around the location of receivers in their LSPs. So c), 
although it allows
more optimal data delivery, does involve more bandwidth for the routing 
protocol (especially
since LSP information will be more volatile if location of receivers 
from groups is included).

If I have missed alternatives, or arguments, people should feel free to 
chime in.

Radia


Received: from netcore.fi (netcore.fi [193.94.160.1]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j187h4Q15977 for <[e-mail]>; Mon, 7 Feb 2005 23:43:04 -0800 (PST)
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j187gu727650 for <[e-mail]>; Tue, 8 Feb 2005 09:42:57 +0200
Date: Tue, 8 Feb 2005 09:42:56 +0200 (EET)
From: Pekka Savola <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Choice of routing protocols
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 08 Feb 2005 07:46:09 -0000
Status: RO
Content-Length: 5737

On Fri, 4 Feb 2005, Erik Nordmark wrote:
> Below is an excerpt from emails between myself and Bob Hinden that tries
> to capture some issues around the choice of routing protocol.
> Hopefully this can stimulate further discussion on this topic.

I'd also like to consider using OSPF as a basis for the simple reason 
that it has been widely implemented by the same vendors we'd like to 
ship Rbridges.  Those low-end router manufacturers don't implement 
IS-IS, so this would incur a steeper curve for implementation.

However, as for IPv6 one would have to use OSPFv3 as a basis (and then 
one could use draft-ietf-ospf-af-alt-01.txt), not OSPFv2, this does 
not seem to be all that relevant consideration anymore because those 
low-end vendors don't implement OSPFv3 in any case.

That said, the arguments below seem to indicate that using OSPF has 
some serious issues (mainly relating to IP address assignment) and 
IS-IS may be a better fit, with an automated NSAP address 
"generation".

To avoid rehashing this discussion over and over again, these 
considerations should be nailed down in the charter or an 
internet-draft.

> -------- Original Message --------
> Subject: Re: Late agenda item?:  ipvlx charter
> Date: Mon, 31 Jan 2005 10:24:35 -0800
> From: Erik Nordmark <[e-mail]>
> To: Bob Hinden <[e-mail]>
>
>
> Bob Hinden wrote:
>
>> I also wonder if we want to consider OSPF for this.  The IETF owns all the 
>> IPR and can produce derivative standards, where the situation with ISIS is 
>> very different (e.g., OSI owns the basic protocol). It's going to be 
>> difficult for an L2 bridge implementor to figure out and understand which 
>> collection of IETF and OSI specs to use.  Also, if I remember correctly, 
>> ISIS still requires manual configuration of 20 byte OSI NSAP addresses. 
>> This would be a pretty odd thing for a L2 bridge.
>
> AFAIK it is only the 6-byte MAC address that is the 'system ID' in
> IS-IS. One would probably need to fill in some dummy value for the AFI
> and area, but this can be done without any manual config since each box
> is assumed to have a factory assigned unique MAC address.
>
> OSPF is a bit harder in fact, since (even with the IPv6 pieces in
> OSPFv3) the OSPF router ID is a 4 byte number, and there isn't any
> existing numbering space which could be used to create factory assigned
> globally unique 32 bit numbers.
>
> While in principle OSPF is interesting and should be explored, there are
> some additional items (in addition to the router ID assignment) which
> makes using OSPF harder than IS-IS:
> - the OSPF LSAs are specified to carry fixed length addresses (either
>   IPv4 or IPv6), so one would probably need to define a new (set of)
>   LSAs for TRILL Not a big deal really, but IS-IS was designed to
>   handle variable length NLRI from the start.
> - OSPF is designed to run on top of IP whereas IS-IS runs directly on
>   IEEE 802.1. While rbridges (just like bridges) will probably be
>   assigned IP addresses for management purposes (SNMP), requiring an IP
>   address for the rbridge before it can start OSPF do build the
>   topology would be a severe limitation. One would want to allow
>   rbridges that don't have IP addresses (e.g. for home), or where the
>   IP addresses are assigned after the rbridges have established
>   connectivity across the link (assigned using stateless IPv6 or DHCP
>   for instance).
>   [Bob later told me: A possible choice when using OSPF is to use
>   OSPFv3 over IPv6 and IPv6 link-local addresses, since any device with
>   an IEEE MAC address can form an IPv6 link-local address.]
>
> So trust me, I did really like to use OSPF here, because of the IS-IS
> specification issues but also because there are more open source OSPF
> code out there for implementors to reuse.
>
>
>> While on the general topic, RIPv2 might even be a reasonable choice for 
>> routing technology.  It's a lot simpler to implement and would still work a 
>> lot better than spanning tree.
>
> TRILL does add one additional constraint on a routing protocol (beyond
> carrying MAC addresses around) which is to be able to construct a
> spanning tree between the rbridges. The spanning tree is needed for
> flooding (ARP, ND, and any other broadcast/multicast). Doing this in a
> link state protocol is relatively easy; each router can independently
> calculate the spanning tree in a consistent manner. But it is far from
> clear whether this can be be done in a distance vector protocol.
>
> Also, part of the goal for TRILL is to be better than the IEEE 802.1D
> spanning tree, which has a worst-case convergence time of 45 seconds or
> so. It isn't clear that RIP is a good fit for fast convergence.
>
>> My general question is:  Is the decision on the routing technology to be 
>> used for this going to be something that the w.g. decides or is it just 
>> assumed it is ISIS?  I would favor the former approach, but in either case 
>> I think it is important that the charter clarify this.
>
> The TRILL WG would need to make the choice.
> If the actual routing protocol work is farmed out to the specific,
> long-lived routing protocol WGs, the success would depend on those WGs
> having interest in this space.
> An option is that the TRILL WG define the
> extension to the routing protocols, and just have that reviewed by the
> routing protocol WG(s).
>
>   Erik
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
>

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


Received: from smtp807.mail.sc5.yahoo.com (smtp807.mail.sc5.yahoo.com [66.163.168.186]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id j17NsBQ03023 for <[e-mail]>; Mon, 7 Feb 2005 15:54:11 -0800 (PST)
Received: from unknown (HELO grayling) (osprey67@63.197.18.101 with login) by smtp807.mail.sc5.yahoo.com with SMTP; 7 Feb 2005 23:54:10 -0000
From: "Fred L. Templin" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: RE: [rbridge] Choice of routing protocols
Date: Mon, 7 Feb 2005 15:54:07 -0800
Message-ID: <000401c50d70$4ff2fd30$6401a8c0@grayling>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
in-reply-to: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 07 Feb 2005 23:55:44 -0000
Status: RO
Content-Length: 1020

Thank you, Hilarie,

Again, no disrespect toward anyone was intended - especially
not toward Radia, Erik and Bob, the people whom I named on
the ill-concieved message and the many people on the rbridge
list who know much more about routing protocols than I do.

Sincerely,

Fred L. Templin
[e-mail]
[e-mail]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Hilarie Orman
Sent: Monday, February 07, 2005 1:44 PM
To: [e-mail]
Subject: RE: [rbridge] Choice of routing protocols


Fred L. Templin declared on Sun, 6 Feb 2005 at 14:48:00 -0800 :

>  I am sure
>  Erik would consult the appropriate routing experts as necessary

I'd be sure, too, given Radia Perlman's involvement.  Isn't her Infocomm
paper the basis for the WG concept?  I think rbridge has no lack of
expertise.

Hilarie Orman



_______________________________________________
rbridge mailing list
[e-mail] http://www.postel.org/mailman/listinfo/rbridge




Received: from mail.rfburst.com (mail.esmartstart.com [66.119.143.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j17LjJQ27582 for <[e-mail]>; Mon, 7 Feb 2005 13:45:19 -0800 (PST)
Received: from tobermory.localdomain ([66.119.143.202]) by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id j17LjE0J010756 for <[e-mail]>; Mon, 7 Feb 2005 14:45:14 -0700
Received: from tobermory.localdomain (localhost [127.0.0.1]) by tobermory.localdomain (8.12.10/8.11.6) with ESMTP id j17LiEe4013862 for <[e-mail]>; Mon, 7 Feb 2005 14:44:14 -0700
Received: (from ho@localhost) by tobermory.localdomain (8.12.10/8.12.10/Submit) id j17LiDja013858; Mon, 7 Feb 2005 14:44:13 -0700
Date: Mon, 7 Feb 2005 14:44:13 -0700
Message-Id: <[e-mail]>
From: "Hilarie Orman" <[e-mail]>
To: [e-mail]
In-reply-to: Yourmessage <000201c50c9d$e97058a0$6401a8c0@grayling>
Subject: RE: [rbridge] Choice of routing protocols
X-esmartscan-MailScanner-Information: Please contact the ISP for more information
X-esmartscan-MailScanner: Found to be clean
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 07 Feb 2005 21:46:46 -0000
Status: RO
Content-Length: 316

Fred L. Templin declared on Sun, 6 Feb 2005 at 14:48:00 -0800 :

>  I am sure
>  Erik would consult the appropriate routing experts as necessary

I'd be sure, too, given Radia Perlman's involvement.  Isn't her
Infocomm paper the basis for the WG concept?  I think rbridge has no
lack of expertise.

Hilarie Orman





Received: from smtp806.mail.sc5.yahoo.com (smtp806.mail.sc5.yahoo.com [66.163.168.185]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id j16MkqQ16842 for <[e-mail]>; Sun, 6 Feb 2005 14:46:52 -0800 (PST)
Received: from unknown (HELO grayling) (osprey67@63.197.18.101 with login) by smtp806.mail.sc5.yahoo.com with SMTP; 6 Feb 2005 22:46:52 -0000
From: "Fred L. Templin" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: RE: [rbridge] Choice of routing protocols
Date: Sun, 6 Feb 2005 14:48:00 -0800
Message-ID: <000201c50c9d$e97058a0$6401a8c0@grayling>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <00df01c50b97$8f04a260$6401a8c0@grayling>
Importance: Normal
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 06 Feb 2005 22:49:32 -0000
Status: RO
Content-Length: 5758

I would like to apologize to Erik and to the list for my inappropriate
message. I was just trying to be helpful, but in hindsight I am sure
Erik would consult the appropriate routing experts as necessary and
that my more helpful alternative would have been to remain silent.

Sincerely,

Fred L. Templin
[e-mail]
 
  

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Fred L. Templin
Sent: Saturday, February 05, 2005 7:30 AM
To: 'Developing a hybrid router/bridge.'
Subject: RE: [rbridge] Choice of routing protocols


Erik,

There are a lot of peopole who know a lot more about routing protocols
than I do and I suspect even more than you and Bob. Folks like Fred
Baker, Charles Perkins and perhaps Dave Oran just to name a few. Have
they been following these discussions?

Fred
[e-mail]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Erik Nordmark
Sent: Friday, February 04, 2005 11:58 AM
To: [e-mail]
Subject: [rbridge] Choice of routing protocols



Below is an excerpt from emails between myself and Bob Hinden that tries
to capture some issues around the choice of routing protocol. Hopefully
this can stimulate further discussion on this topic.

    Erik

-------- Original Message --------
Subject: Re: Late agenda item?:  ipvlx charter
Date: Mon, 31 Jan 2005 10:24:35 -0800
From: Erik Nordmark <[e-mail]>
To: Bob Hinden <[e-mail]>


Bob Hinden wrote:

> I also wonder if we want to consider OSPF for this.  The IETF owns all

> the IPR and can produce derivative standards, where the situation with

> ISIS is very different (e.g., OSI owns the basic protocol). It's going

> to be difficult for an L2 bridge implementor to figure out and
> understand which collection of IETF and OSI specs to use.  Also, if I 
> remember correctly, ISIS still requires manual configuration of 20
byte 
> OSI NSAP addresses.  This would be a pretty odd thing for a L2 bridge.

AFAIK it is only the 6-byte MAC address that is the 'system ID' in
IS-IS. One would probably need to fill in some dummy value for the AFI
and area, but this can be done without any manual config since each box
is assumed to have a factory assigned unique MAC address.

OSPF is a bit harder in fact, since (even with the IPv6 pieces in
OSPFv3) the OSPF router ID is a 4 byte number, and there isn't any
existing numbering space which could be used to create factory assigned
globally unique 32 bit numbers.

While in principle OSPF is interesting and should be explored, there are
some additional items (in addition to the router ID assignment) which
makes using OSPF harder than IS-IS:
  - the OSPF LSAs are specified to carry fixed length addresses (either
    IPv4 or IPv6), so one would probably need to define a new (set of)
    LSAs for TRILL Not a big deal really, but IS-IS was designed to
    handle variable length NLRI from the start.
  - OSPF is designed to run on top of IP whereas IS-IS runs directly on
    IEEE 802.1. While rbridges (just like bridges) will probably be
    assigned IP addresses for management purposes (SNMP), requiring an
IP
    address for the rbridge before it can start OSPF do build the
    topology would be a severe limitation. One would want to allow
    rbridges that don't have IP addresses (e.g. for home), or where the
    IP addresses are assigned after the rbridges have established
    connectivity across the link (assigned using stateless IPv6 or DHCP
    for instance).
    [Bob later told me: A possible choice when using OSPF is to use
    OSPFv3 over IPv6 and IPv6 link-local addresses, since any device
with
    an IEEE MAC address can form an IPv6 link-local address.]

So trust me, I did really like to use OSPF here, because of the IS-IS
specification issues but also because there are more open source OSPF
code out there for implementors to reuse.


> While on the general topic, RIPv2 might even be a reasonable choice
> for
> routing technology.  It's a lot simpler to implement and would still 
> work a lot better than spanning tree.

TRILL does add one additional constraint on a routing protocol (beyond
carrying MAC addresses around) which is to be able to construct a
spanning tree between the rbridges. The spanning tree is needed for
flooding (ARP, ND, and any other broadcast/multicast). Doing this in a
link state protocol is relatively easy; each router can independently
calculate the spanning tree in a consistent manner. But it is far from
clear whether this can be be done in a distance vector protocol.

Also, part of the goal for TRILL is to be better than the IEEE 802.1D
spanning tree, which has a worst-case convergence time of 45 seconds or
so. It isn't clear that RIP is a good fit for fast convergence.

> My general question is:  Is the decision on the routing technology to
> be
> used for this going to be something that the w.g. decides or is it
just 
> assumed it is ISIS?  I would favor the former approach, but in either
> case I think it is important that the charter clarify this.

The TRILL WG would need to make the choice.
If the actual routing protocol work is farmed out to the specific,
long-lived routing protocol WGs, the success would depend on those WGs
having interest in this space. An option is that the TRILL WG define the
extension to the routing protocols, and just have that reviewed by the
routing protocol WG(s).

    Erik
_______________________________________________
rbridge mailing list
[e-mail] http://www.postel.org/mailman/listinfo/rbridge


_______________________________________________
rbridge mailing list
[e-mail] http://www.postel.org/mailman/listinfo/rbridge




Received: from smtp802.mail.sc5.yahoo.com (smtp802.mail.sc5.yahoo.com [66.163.168.181]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id j15FSrQ16308 for <[e-mail]>; Sat, 5 Feb 2005 07:28:53 -0800 (PST)
Received: from unknown (HELO grayling) (osprey67@63.197.18.101 with login) by smtp802.mail.sc5.yahoo.com with SMTP; 5 Feb 2005 15:28:53 -0000
From: "Fred L. Templin" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: RE: [rbridge] Choice of routing protocols
Date: Sat, 5 Feb 2005 07:30:01 -0800
Message-ID: <00df01c50b97$8f04a260$6401a8c0@grayling>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 05 Feb 2005 15:31:29 -0000
Status: RO
Content-Length: 5035

Erik,

There are a lot of peopole who know a lot more about routing
protocols than I do and I suspect even more than you and Bob.
Folks like Fred Baker, Charles Perkins and perhaps Dave Oran
just to name a few. Have they been following these discussions?

Fred
[e-mail]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Erik Nordmark
Sent: Friday, February 04, 2005 11:58 AM
To: [e-mail]
Subject: [rbridge] Choice of routing protocols



Below is an excerpt from emails between myself and Bob Hinden that tries
to capture some issues around the choice of routing protocol. Hopefully
this can stimulate further discussion on this topic.

    Erik

-------- Original Message --------
Subject: Re: Late agenda item?:  ipvlx charter
Date: Mon, 31 Jan 2005 10:24:35 -0800
From: Erik Nordmark <[e-mail]>
To: Bob Hinden <[e-mail]>


Bob Hinden wrote:

> I also wonder if we want to consider OSPF for this.  The IETF owns all
> the IPR and can produce derivative standards, where the situation with

> ISIS is very different (e.g., OSI owns the basic protocol). It's going

> to be difficult for an L2 bridge implementor to figure out and 
> understand which collection of IETF and OSI specs to use.  Also, if I 
> remember correctly, ISIS still requires manual configuration of 20
byte 
> OSI NSAP addresses.  This would be a pretty odd thing for a L2 bridge.

AFAIK it is only the 6-byte MAC address that is the 'system ID' in
IS-IS. One would probably need to fill in some dummy value for the AFI
and area, but this can be done without any manual config since each box
is assumed to have a factory assigned unique MAC address.

OSPF is a bit harder in fact, since (even with the IPv6 pieces in
OSPFv3) the OSPF router ID is a 4 byte number, and there isn't any
existing numbering space which could be used to create factory assigned
globally unique 32 bit numbers.

While in principle OSPF is interesting and should be explored, there are
some additional items (in addition to the router ID assignment) which
makes using OSPF harder than IS-IS:
  - the OSPF LSAs are specified to carry fixed length addresses (either
    IPv4 or IPv6), so one would probably need to define a new (set of)
    LSAs for TRILL Not a big deal really, but IS-IS was designed to
    handle variable length NLRI from the start.
  - OSPF is designed to run on top of IP whereas IS-IS runs directly on
    IEEE 802.1. While rbridges (just like bridges) will probably be
    assigned IP addresses for management purposes (SNMP), requiring an
IP
    address for the rbridge before it can start OSPF do build the
    topology would be a severe limitation. One would want to allow
    rbridges that don't have IP addresses (e.g. for home), or where the
    IP addresses are assigned after the rbridges have established
    connectivity across the link (assigned using stateless IPv6 or DHCP
    for instance).
    [Bob later told me: A possible choice when using OSPF is to use
    OSPFv3 over IPv6 and IPv6 link-local addresses, since any device
with
    an IEEE MAC address can form an IPv6 link-local address.]

So trust me, I did really like to use OSPF here, because of the IS-IS
specification issues but also because there are more open source OSPF
code out there for implementors to reuse.


> While on the general topic, RIPv2 might even be a reasonable choice 
> for
> routing technology.  It's a lot simpler to implement and would still 
> work a lot better than spanning tree.

TRILL does add one additional constraint on a routing protocol (beyond
carrying MAC addresses around) which is to be able to construct a
spanning tree between the rbridges. The spanning tree is needed for
flooding (ARP, ND, and any other broadcast/multicast). Doing this in a
link state protocol is relatively easy; each router can independently
calculate the spanning tree in a consistent manner. But it is far from
clear whether this can be be done in a distance vector protocol.

Also, part of the goal for TRILL is to be better than the IEEE 802.1D
spanning tree, which has a worst-case convergence time of 45 seconds or
so. It isn't clear that RIP is a good fit for fast convergence.

> My general question is:  Is the decision on the routing technology to 
> be
> used for this going to be something that the w.g. decides or is it
just 
> assumed it is ISIS?  I would favor the former approach, but in either 
> case I think it is important that the charter clarify this.

The TRILL WG would need to make the choice.
If the actual routing protocol work is farmed out to the specific,
long-lived routing protocol WGs, the success would depend on those WGs
having interest in this space. An option is that the TRILL WG define the
extension to the routing protocols, and just have that reviewed by the
routing protocol WG(s).

    Erik
_______________________________________________
rbridge mailing list
[e-mail] http://www.postel.org/mailman/listinfo/rbridge




Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j15AL3Q17595 for <[e-mail]>; Sat, 5 Feb 2005 02:21:04 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3BC3845DFA for <[e-mail]>; Sat,  5 Feb 2005 11:20:57 +0100 (CET)
Received: from [163.117.252.29] (unknown [163.117.252.29]) by smtp01.uc3m.es (Postfix) with ESMTP id 5F6E545DF5 for <[e-mail]>; Sat,  5 Feb 2005 11:20:56 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: marcelo bagnulo braun <[e-mail]>
Subject: Re: [rbridge] Agenda items?
Date: Sat, 5 Feb 2005 11:20:52 +0100
To: "Developing a hybrid router/bridge." <[e-mail]>
X-Mailer: Apple Mail (2.619.2)
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 05 Feb 2005 10:22:46 -0000
Status: RO
Content-Length: 195

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


I can volunteer to try to make an initial threat analysis if you want 
me to.

Regards, marcelo



Received: from smtp801.mail.sc5.yahoo.com (smtp801.mail.sc5.yahoo.com [66.163.168.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id j157dpQ11653 for <[e-mail]>; Fri, 4 Feb 2005 23:39:51 -0800 (PST)
Received: from unknown (HELO grayling) (osprey67@63.197.18.101 with login) by smtp801.mail.sc5.yahoo.com with SMTP; 5 Feb 2005 07:39:51 -0000
From: "Fred L. Templin" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: RE: [rbridge] Conflicts to avoid for BoF/WG?
Date: Fri, 4 Feb 2005 23:40:58 -0800
Message-ID: <00d801c50b56$08f9f8a0$6401a8c0@grayling>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 05 Feb 2005 07:40:42 -0000
Status: RO
Content-Length: 1424

Erik,

Understood, but what I meant to ask is whether Firewire devices
will always sit behind a router *interface* for simplicity and
security? The device with the router interface might have many
other interfaces that act as Rbridge or even simple bridge
interfaces, so the device itself would still be a hybrid. The
zeroconf considerations would really be no different than what
we have been discussing for generic RBridges, then - i.e., the
goal is for no manual config needed.

Fred
[e-mail]
 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Erik Nordmark
Sent: Friday, February 04, 2005 4:18 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Conflicts to avoid for BoF/WG?


Fred L. Templin wrote:

> If we can say that Firewire devices will only occur along the network 
> edges (rather than somewhere in the middle) and will always sit behind

> a router (rather than a bridge) doesn't that make things more simple 
> and secure? Am I being unrealistic here?

The issue that folks bring up is that random consumers can be expected 
to know how to configure the IP subnets into a router. Hence the desire 
for something that has the property of a bridge of not needing 
configuration.

    Erik
_______________________________________________
rbridge mailing list
[e-mail] http://www.postel.org/mailman/listinfo/rbridge




Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j150HvQ08344 for <[e-mail]>; Fri, 4 Feb 2005 16:17:57 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.88.130]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j150Hrdt012168 for <[e-mail]>; Fri, 4 Feb 2005 17:17:57 -0700 (MST)
Received: from [129.146.89.82] (par.SFBay.Sun.COM [129.146.89.82]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j150HnVV710097; Fri, 4 Feb 2005 16:17:52 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 04 Feb 2005 16:17:49 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Conflicts to avoid for BoF/WG?
References: <00d701c50b15$1cd3aba0$6401a8c0@grayling>
In-Reply-To: <00d701c50b15$1cd3aba0$6401a8c0@grayling>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 05 Feb 2005 00:18:40 -0000
Status: RO
Content-Length: 518

Fred L. Templin wrote:

> If we can say that Firewire devices will only occur along the
> network edges (rather than somewhere in the middle) and will
> always sit behind a router (rather than a bridge) doesn't that
> make things more simple and secure? Am I being unrealistic here?

The issue that folks bring up is that random consumers can be expected 
to know how to configure the IP subnets into a router. Hence the desire 
for something that has the property of a bridge of not needing 
configuration.

    Erik


Received: from smtp814.mail.sc5.yahoo.com (smtp814.mail.sc5.yahoo.com [66.163.170.84]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id j14Nt8Q02250 for <[e-mail]>; Fri, 4 Feb 2005 15:55:08 -0800 (PST)
Received: from unknown (HELO grayling) (osprey67@63.197.18.101 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 4 Feb 2005 23:55:07 -0000
From: "Fred L. Templin" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: RE: [rbridge] Conflicts to avoid for BoF/WG?
Date: Fri, 4 Feb 2005 15:56:09 -0800
Message-ID: <00d701c50b15$1cd3aba0$6401a8c0@grayling>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2005 23:56:41 -0000
Status: RO
Content-Length: 411

Erik,

> In the past there has been home networking discussions worrying about 
> e.g. Ethernet and Firewire both being used for IP.

If we can say that Firewire devices will only occur along the
network edges (rather than somewhere in the middle) and will
always sit behind a router (rather than a bridge) doesn't that
make things more simple and secure? Am I being unrealistic here?

Fred
[e-mail] 




Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j14NRSQ25585; Fri, 4 Feb 2005 15:27:28 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 04 Feb 2005 15:27:28 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Conflicts to avoid for BoF/WG?
References: <[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4F0B8ED0DBB7DB32161DA13B"
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2005 23:29:24 -0000
Status: RO
Content-Length: 1351

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4F0B8ED0DBB7DB32161DA13B
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Erik Nordmark wrote:
> Joe Touch wrote:
> 
>> Also, if possible, to avoid BTNS (which may or may not be scheduled ;-),
> 
> 
> Is this a prospective BoF? I don't find a WG by that name.

The first BTNS happened last IETF; we requested a slot for this one to 
do charter bashing (not yet widely announced, since we didn't get the 
ACK for the slot yet).

> 
>  >    ipv6*
> 
> I had ipv6, v6ops, multi6, shim6.
> Any other specific WG?

Those were the ones I was thinking of.

> I didn't want to add the mobility WGs that do v6 work since we'd either 
> have to meet at 4pm or on the weekend with such a long list of conflicts 
> :-)

Agreed.

--------------enig4F0B8ED0DBB7DB32161DA13B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCBATgE5f5cImnZrsRAn8WAKCaU0L+55bw4vNqR9GRygZgnK1CvACfUsGA
isDTUWJ1dB1DKvQpKDJra6k=
=yy+D
-----END PGP SIGNATURE-----

--------------enig4F0B8ED0DBB7DB32161DA13B--


Received: from mailout3 (mailout3.samsung.com [203.254.224.33]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j14NAYQ21637 for <[e-mail]>; Fri, 4 Feb 2005 15:10:36 -0800 (PST)
Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <[e-mail]> for [e-mail]; Sat, 05 Feb 2005 08:10:27 +0900 (KST)
Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 05 Feb 2005 08:10:27 +0900 (KST)
Received: from Alperyegin ([105.144.29.41]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <[e-mail]> for [e-mail]; Sat, 05 Feb 2005 08:10:27 +0900 (KST)
Date: Fri, 04 Feb 2005 15:10:25 -0800
From: Alper Yegin <[e-mail]>
Subject: RE: [rbridge] Conflicts to avoid for BoF/WG?
In-reply-to: <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Message-id: <07a101c50b0e$b6b57480$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2005 23:10:43 -0000
Status: RO
Content-Length: 575

 
> In the past there has been home networking discussions worrying about
> e.g. Ethernet and Firewire both being used for IP.

I don't have more detailed data points, but this is what I heard earlier
too (I'll see if I can get more concrete data). Besides, how can we
ensure that LANs will stick to a uniform 48-bit address space for the
foreseeable future? I read that IEEE is already discouraging use of
48-bit identifiers in favor of EUI-64. 

I think it is worth investigating the feasibility and cost of inheriting
that aspect of "routers" for this "hybrid". 

Alper




Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j14N6vQ20518 for <[e-mail]>; Fri, 4 Feb 2005 15:06:57 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.85.105]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j14N6upv002345 for <[e-mail]>; Fri, 4 Feb 2005 15:06:56 -0800 (PST)
Received: from [129.146.89.82] (par.SFBay.Sun.COM [129.146.89.82]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j14N6tP5670107; Fri, 4 Feb 2005 15:06:55 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 04 Feb 2005 15:06:55 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Conflicts to avoid for BoF/WG?
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2005 23:08:49 -0000
Status: RO
Content-Length: 384

Joe Touch wrote:

> Also, if possible, to avoid BTNS (which may or may not be scheduled ;-),

Is this a prospective BoF? I don't find a WG by that name.

 >    ipv6*

I had ipv6, v6ops, multi6, shim6.
Any other specific WG?

I didn't want to add the mobility WGs that do v6 work since we'd either 
have to meet at 4pm or on the weekend with such a long list of conflicts :-)

   Erik


Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j14N4OQ19914 for <[e-mail]>; Fri, 4 Feb 2005 15:04:26 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.85.105]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j14N4LiI027171 for <[e-mail]>; Fri, 4 Feb 2005 15:04:21 -0800 (PST)
Received: from [129.146.89.82] (par.SFBay.Sun.COM [129.146.89.82]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j14N4KKj669355; Fri, 4 Feb 2005 15:04:21 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 04 Feb 2005 15:04:20 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Agenda items?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2005 23:04:39 -0000
Status: RO
Content-Length: 363

Joe Touch wrote:

> | 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?
> 
> I'll take #5; I can help with #6 (related, IMO) if needed).

Thanks,
    Erik


Received: from smtp819.mail.sc5.yahoo.com (smtp819.mail.sc5.yahoo.com [66.163.170.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id j14MAvQ05169 for <[e-mail]>; Fri, 4 Feb 2005 14:10:57 -0800 (PST)
Received: from unknown (HELO grayling) (osprey67@63.197.18.101 with login) by smtp819.mail.sc5.yahoo.com with SMTP; 4 Feb 2005 22:10:55 -0000
From: "Fred L. Templin" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: RE: [rbridge] Conflicts to avoid for BoF/WG?
Date: Fri, 4 Feb 2005 14:11:58 -0800
Message-ID: <00ce01c50b06$8e1a1330$6401a8c0@grayling>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2005 22:13:16 -0000
Status: RO
Content-Length: 9117

Radia,

I would be happy to volunteer to talk about mixing L2 link types,
but my attendance at IETF-62 is looking doubtful at the moment since
I am currently under a budget crunch and I have been summoned for jury
duty on March 1st. (The first issue has an obvious solution, but the
second is a wait-and-see scenario as to whether I would be picked for
a jury). So, I guess I am volunteering(*) with an asterisk, i.e.,
provided I am somehow able to attend.

Fred L. Templin
American Kestrel Consulting
[e-mail]
[e-mail]
[e-mail]  

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Friday, February 04, 2005 1:03 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Conflicts to avoid for BoF/WG?


Is it possible to request that this not be Friday? A lot of people make 
plane reservations
early assuming that they don't want to stay on Friday.

As for the agenda...looks great. I'm happy to lead any of the 
discussions below
if you don't have other volunteers. Though for the one you have me down 
for (mixing
L2 link types) I can talk about some ways of doing it, but I'm still not

really clear
on why people want this, and what types of links they'd like to mix. Is 
there
someone who would like to talk about the problem statement?

Radia



Erik Nordmark wrote:

>
> Are there other conflicts which we must avoid?
>
>    Erik
>
>
> This might be approved as a WG before the meeting, but we will 
> schedule it as a BoF for the time being.
>
>    a. Working Group or BOF full name with acronym in brackets:
>     TRansparent Interconnection of Lots of Links (TRILL)
>    b. AREA under which Working Group or BOF appears:
>     INT
>    c. CONFLICTS you wish to avoid, please be as specific as possible:
>     multi6, shim6, ipv6, v6ops, is-is, ospf
>
>    d. Expected Attendance (figures from the previous IETF are sent
when
>       WG/BOF scheduling opens)
>     100 (based on IPVLX BoF)
>
>    e. Special requests (i.e. multicast):
>    f. Number of slots:
>     1
>
>    g. Length of slot:
>           2 1/2 hours
>
> Bof Description: See proposed charter below.
> This is a follow-on to the IPVLX BoF in Aug 2004
>
> Bof Chair: Erik Nordmark <[e-mail]>
>
> Mailing list: [e-mail]
> Subscribe: http://www.postel.org/mailman/listinfo/rbridge
> Web page: http://www.postel.org/rbridge/
>     With additional information as well as mailing list archives
>
>
> Agenda:
> -------
>
>  - Welcome and Administrivia            5 minutes    Chair
>
>  - Charter review                10 minutes    Chair
>
>  - Problem statement discussion            30 minutes    Erik Nordmark
>     Including the "service" that a cloud of hybrid devices will
>     provide, whether it is equivalent to IEEE 802.1D devices, or
>     handles IP packets differently
>     When is it ok to reorder packets? MTU considerations?
>
>
>  - Threats and security considerations        10 minutes    ???
>         What should the goal be? What can we do better?
>
>  - Requirements on routing protocols        20 minutes    ???
>         For zero configuration
>         Carrying MAC addresses
>         Broadcast
>         IS-IS vs. OSPF vs. something else
>
>  - Connecting different L2 types        30 minutes    Radia Perlman?
>
>  - Choices for ARP/ND                10 minutes    ???
>        Constraints from security discussion (intentionally duplicate
L2
>     addresses), mobility, SeND support, etc.
>
>
>  - Choices for broadcast/multicast        10 minutes    ???
>     Worth doing any optimizations? Spanning tree between rbridges?
>
>
>
> Proposed charter:
> -----------------
>
> TRansparent Interconnection of Lots of Links (TRILL)
>
>
> While IEEE 802 bridges are attractive due to not needing explicit 
> configuration and allowing hosts to move within the bridged topology, 
> they are more limited than IP routers since bridges only support IEEE 
> 802 technologies, and the most common layer 2 interconnection method 
> (dynamically created spanning tree formation using bridges) is not as 
> flexible and robust as layer 3 routing.
>
> The WG will design a hybrid solution that combines the simplicity of 
> configuration while taking full advantage of complex topologies.
>
> The design should have the following properties:
>  - zero configuration of the hybrid devices
>  - ability for hosts to move without changing their IP address
>  - it should be possible to forward packets using pair-wise shortest
> paths,
>    and exploit the redundant paths through the network for increased
>    aggregate bandwidth
>  - possible optimizations for ARP and Neighbor Discovery packets 
> (potentially
>    avoid flooding all the time)
>  - support Secure Neighbor Discovery
>  - the packet header should have a hop count for robustness in the 
> presence
>    of temporary routing loops
>  - nodes should be able to have multiple attachments to the network
>  - no delay when a new node is attached to the network
>  - multicast should work (and after a re-charter it might make sense
to
>    look at optimizations for IP multicast)
>  - be no less secure than existing bridges (and explore whether the 
> protocol
>    can make "L2 address theft" harder or easier to detect)
>
> A required piece of the solution is an IP routing protocol which is
> extended
> to carry L2 address reachability, handle broadcast, and is friendly to
> zero-configuration. Likely candidate are the link-state routing
protocols
> since they can easily be extended to provide for broadcast, which is 
> believed
> to be difficult for distance vector protocols.
> This working group will define the requirements on such routing 
> protocol(s),
> and select the routing protocol(s) to be used.  The intent is that the

> actual
> extensions to the routing protocol(s) be performed in the WGs with 
> expertise
> in the routing protocol(s).
>
> The working group will look into solutions that can interconnect
> different
> layer 2 technologies, and also look at providing support for non-IP 
> protocols,
> even though one can not combine those two features together; the
> interconnection of different layer 2 technologies (with different
layer 2
> address formats) will most likely only work for the IP family of 
> protocols.
> Whether the same or different address formats are used, there might be

> a need
> to handle different MTUs.
>
> The WG will design a protocol that combines the benefits of bridges 
> and routers in a way that will co-exist with existing hosts, IP 
> routers and bridges. The design must support both IPv4 and IPv6
>
> The working group will not work any layer 3 aspects except to provide
>  - Possible optimizations for ARP and ND packets (not always
>    flooded everywhere)
>  - Being able to carry IP broadcast and multicast packets (which might
> just
>    fall out from supporting L2 multicast)
>  - Defining the L3 operations needed to interconnect different L2 
> technologies
>
>
> The work consists of several, separable pieces:
>  - Defining the requirement on the routing protocol(s), and select one
or
>    more routing protocols. The detailed specification of the
> extensions to
>    a particular routing protocol will be left as an action item for
the
>    specific routing protocol WG.
>  - Defining what information must be carried in an encapsulation 
> header for
>    data packets, and how to map that information to various link types

> (e.g.,
>    IEEE LAN, Fibrechannel, MPLS)
>  - Defining how address resolution (ARP and Neighbor Discovery) is 
> performed,
>    taking into account the desire to be compatible with Secure
Neighbor
>    Discovery.
>  - Defining how the solution extends to the case when multiple layer 2
>    technologies, that have different address format/length, are 
> interconnected.
>
> Deliverables
>  - A short draft on the problem statement and goals
>  - A document defining what information needs to be carried in routing
>    protocols to support the trill concept, and other requirements on
>    the routing protocols.
>  - Encapsulation draft specifying what needs to be carried in general
>    and the specific format to use on IEEE LANs
>  - ARP and ND draft
>  - Draft on interconnecting different types of layer 2 technologies
>  - Threat analysis document
>
> Goals and Milestones
>
> Jun 05  Problem statement and Goals submitted to IESG for 
> Informational Sep 05  Routing protocol support requirements to IESG 
> for Informational Dec 05  Encapsulation document to IESG for Proposed 
> Standard Sep 05  ARP & ND to IESG for Proposed Standard Mar 06  
> Interconnecting Layer 2 Technologies document to IESG for
>         Proposed Standard
> Dec 05  Threat analysis to IESG for Informational
>
> ---
>
>
> _______________________________________________
> rbridge mailing list
> [e-mail] http://www.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[e-mail] http://www.postel.org/mailman/listinfo/rbridge




Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j14M2YQ02418; Fri, 4 Feb 2005 14:02:34 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 04 Feb 2005 14:04:39 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Conflicts to avoid for BoF/WG?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2005 22:03:25 -0000
Status: RO
Content-Length: 741

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Radia Perlman wrote:
| Is it possible to request that this not be Friday? A lot of people make
| plane reservations
| early assuming that they don't want to stay on Friday.

I'd second that.

Also, if possible, to avoid BTNS (which may or may not be scheduled ;-),
as well as some related groups:
	l2vpn
	rtgarea
	ipv6*

It's hard to avoid the following but would be useful due to some
significant (IMO) overlap:

	tsvwg
	tcpm
	saag

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCA/F3E5f5cImnZrsRAtqYAKDxWO3Ib8MOT9ng4WoHhIOf2YT2NQCfSBfd
qDSH9WDDL3JJha5F5sqe5a4=
=s8t2
-----END PGP SIGNATURE-----


Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j14LoGQ29005 for <[e-mail]>; Fri, 4 Feb 2005 13:50:16 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.88.130]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j14LoFpv002975 for <[e-mail]>; Fri, 4 Feb 2005 13:50:15 -0800 (PST)
Received: from [129.146.89.82] (par.SFBay.Sun.COM [129.146.89.82]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j14LoE9G647748; Fri, 4 Feb 2005 13:50:15 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 04 Feb 2005 13:50:14 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Conflicts to avoid for BoF/WG?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2005 21:50:42 -0000
Status: RO
Content-Length: 2148

Radia Perlman wrote:
> Is it possible to request that this not be Friday? A lot of people make 
> plane reservations
> early assuming that they don't want to stay on Friday.

I'll try.

> As for the agenda...looks great. I'm happy to lead any of the 
> discussions below
> if you don't have other volunteers. Though for the one you have me down 
> for (mixing
> L2 link types) I can talk about some ways of doing it, but I'm still not 
> really clear
> on why people want this, and what types of links they'd like to mix. Is 
> there
> someone who would like to talk about the problem statement?

I know a problem statement has been discussed in the IPv6 WG as part of 
the ndproxy draft, which has two examples related to home networking:
1. The ISP assigns a /64 prefix to the PPP link to the home, but the
    subscriber wants to use the /64 for the home link as well.
    Thus you have PPP on one side of a device, and an IEEE 802 network on
    the other side, and want to share the same /64 subnet prefix.

2. The home subnet is assigned a /64 subnet prefix, but the user also
    has a WIFI AP, and want to hang another wired link of a WIFI client.
    Today such an IPv4 802.11 client might be a NAT box, so the question
    that's been asked in the IPv6 WG is whether something is needed to
    make this less likely for IPv6. (See figures in the ndproxy draft.)

    In this case, the 802.11 client could just be a vanilla 802.11D
    bridge, but the argument is that it is hard to build such a thing
    using a regular 802.11 client NIC (not possible to be promiscious,
    which is required to be a bridge is the main argument I think)

    In any case, a TRILL based solution wouldn't need to connect
    different L2s address formats in this case, since they are both IEEE
    802 ones.

In the past there has been home networking discussions worrying about 
e.g. Ethernet and Firewire both being used for IP.

Perhaps there is someone working on home networking that can help us 
shine some light on this. If the only argument for different L2 address 
formats is the PPP one (#1 above), it probably doesn't fit in TRILL.

    Erik


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j14LbeQ25676; Fri, 4 Feb 2005 13:37:40 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 04 Feb 2005 13:39:46 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Agenda items?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2005 21:38:52 -0000
Status: RO
Content-Length: 636

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



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

I'll take #5; I can help with #6 (related, IMO) if needed).

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCA+uiE5f5cImnZrsRAqOFAJ0ZtYvoXST964E7F8HJU3yDf5LZcwCgwW8/
zB2GsohZKRnUncjFZwr1HTk=
=xdt2
-----END PGP SIGNATURE-----


Received: from smtp817.mail.sc5.yahoo.com (smtp817.mail.sc5.yahoo.com [66.163.170.3]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id j14L6lQ17503 for <[e-mail]>; Fri, 4 Feb 2005 13:06:47 -0800 (PST)
Received: from unknown (HELO grayling) (osprey67@63.197.18.101 with login) by smtp817.mail.sc5.yahoo.com with SMTP; 4 Feb 2005 21:06:46 -0000
From: "Fred L. Templin" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: RE: [rbridge] Conflicts to avoid for BoF/WG?
Date: Fri, 4 Feb 2005 13:07:53 -0800
Message-ID: <00ca01c50afd$97f9a090$6401a8c0@grayling>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2005 21:09:23 -0000
Status: RO
Content-Length: 7649

> Are there other conflicts which we must avoid?

Only that the name 'TRILL' is already taken - by a *birdseed* company!
(See: http://www.trill.com.)

Fred L. Templin
American Kestrel Consulting
[e-mail]
[e-mail]
[e-mail]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Erik Nordmark
Sent: Friday, February 04, 2005 12:04 PM
To: Developing a hybrid router/bridge.
Subject: [rbridge] Conflicts to avoid for BoF/WG?



Are there other conflicts which we must avoid?

    Erik


This might be approved as a WG before the meeting, but we will schedule
it as a BoF for the time being.

    a. Working Group or BOF full name with acronym in brackets:
	TRansparent Interconnection of Lots of Links (TRILL)
    b. AREA under which Working Group or BOF appears:
	INT
    c. CONFLICTS you wish to avoid, please be as specific as possible:
	multi6, shim6, ipv6, v6ops, is-is, ospf

    d. Expected Attendance (figures from the previous IETF are sent when
       WG/BOF scheduling opens)
	100 (based on IPVLX BoF)

    e. Special requests (i.e. multicast):
    f. Number of slots:
	1

    g. Length of slot:
       	2 1/2 hours

Bof Description: See proposed charter below.
This is a follow-on to the IPVLX BoF in Aug 2004

Bof Chair: Erik Nordmark <[e-mail]>

Mailing list: [e-mail]
Subscribe: http://www.postel.org/mailman/listinfo/rbridge
Web page: http://www.postel.org/rbridge/
	With additional information as well as mailing list archives


Agenda:
-------

  - Welcome and Administrivia			5 minutes	Chair

  - Charter review				10 minutes	Chair

  - Problem statement discussion			30 minutes
Erik Nordmark
	Including the "service" that a cloud of hybrid devices will
	provide, whether it is equivalent to IEEE 802.1D devices, or
	handles IP packets differently
	When is it ok to reorder packets? MTU considerations?


  - Threats and security considerations		10 minutes	???
     	What should the goal be? What can we do better?

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

  - Connecting different L2 types		30 minutes	Radia
Perlman?

  - Choices for ARP/ND				10 minutes	???
    	Constraints from security discussion (intentionally duplicate L2
	addresses), mobility, SeND support, etc.


  - Choices for broadcast/multicast		10 minutes	???
	Worth doing any optimizations? Spanning tree between rbridges?



Proposed charter:
-----------------

TRansparent Interconnection of Lots of Links (TRILL)


While IEEE 802 bridges are attractive due to not needing explicit
configuration and allowing hosts to move within the bridged topology,
they are more limited than IP routers since bridges only support IEEE
802 technologies, and the most common layer 2 interconnection method
(dynamically created spanning tree formation using bridges) is not as
flexible and robust as layer 3 routing.

The WG will design a hybrid solution that combines the simplicity of
configuration while taking full advantage of complex topologies.

The design should have the following properties:
  - zero configuration of the hybrid devices
  - ability for hosts to move without changing their IP address
  - it should be possible to forward packets using pair-wise shortest
paths,
    and exploit the redundant paths through the network for increased
    aggregate bandwidth
  - possible optimizations for ARP and Neighbor Discovery packets 
(potentially
    avoid flooding all the time)
  - support Secure Neighbor Discovery
  - the packet header should have a hop count for robustness in the
presence
    of temporary routing loops
  - nodes should be able to have multiple attachments to the network
  - no delay when a new node is attached to the network
  - multicast should work (and after a re-charter it might make sense to
    look at optimizations for IP multicast)
  - be no less secure than existing bridges (and explore whether the 
protocol
    can make "L2 address theft" harder or easier to detect)

A required piece of the solution is an IP routing protocol which is
extended to carry L2 address reachability, handle broadcast, and is
friendly to zero-configuration. Likely candidate are the link-state
routing protocols since they can easily be extended to provide for
broadcast, which is 
believed
to be difficult for distance vector protocols.
This working group will define the requirements on such routing
protocol(s), and select the routing protocol(s) to be used.  The intent
is that the 
actual
extensions to the routing protocol(s) be performed in the WGs with 
expertise
in the routing protocol(s).

The working group will look into solutions that can interconnect
different layer 2 technologies, and also look at providing support for
non-IP 
protocols,
even though one can not combine those two features together; the
interconnection of different layer 2 technologies (with different layer
2 address formats) will most likely only work for the IP family of
protocols. Whether the same or different address formats are used, there
might be a 
need
to handle different MTUs.

The WG will design a protocol that combines the benefits of bridges and
routers in a way that will co-exist with existing hosts, IP routers and
bridges. The design must support both IPv4 and IPv6

The working group will not work any layer 3 aspects except to provide
  - Possible optimizations for ARP and ND packets (not always
    flooded everywhere)
  - Being able to carry IP broadcast and multicast packets (which might 
just
    fall out from supporting L2 multicast)
  - Defining the L3 operations needed to interconnect different L2 
technologies


The work consists of several, separable pieces:
  - Defining the requirement on the routing protocol(s), and select one
or
    more routing protocols. The detailed specification of the extensions
to
    a particular routing protocol will be left as an action item for the
    specific routing protocol WG.
  - Defining what information must be carried in an encapsulation header
for
    data packets, and how to map that information to various link types 
(e.g.,
    IEEE LAN, Fibrechannel, MPLS)
  - Defining how address resolution (ARP and Neighbor Discovery) is 
performed,
    taking into account the desire to be compatible with Secure Neighbor
    Discovery.
  - Defining how the solution extends to the case when multiple layer 2
    technologies, that have different address format/length, are 
interconnected.

Deliverables
  - A short draft on the problem statement and goals
  - A document defining what information needs to be carried in routing
    protocols to support the trill concept, and other requirements on
    the routing protocols.
  - Encapsulation draft specifying what needs to be carried in general
    and the specific format to use on IEEE LANs
  - ARP and ND draft
  - Draft on interconnecting different types of layer 2 technologies
  - Threat analysis document

Goals and Milestones

Jun 05  Problem statement and Goals submitted to IESG for Informational
Sep 05  Routing protocol support requirements to IESG for Informational
Dec 05  Encapsulation document to IESG for Proposed Standard Sep 05  ARP
& ND to IESG for Proposed Standard Mar 06  Interconnecting Layer 2
Technologies document to IESG for
         Proposed Standard
Dec 05  Threat analysis to IESG for Informational

---


_______________________________________________
rbridge mailing list
[e-mail] http://www.postel.org/mailman/listinfo/rbridge




Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j14L38Q16697 for <[e-mail]>; Fri, 4 Feb 2005 13:03:08 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j14L37Vu023864 for <[e-mail]>; Fri, 4 Feb 2005 14:03:07 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 04 Feb 2005 16:03:07 -0500 (EST)
Received: from [192.168.2.58] (vpn-129-150-16-79.SFBay.Sun.COM [129.150.16.79]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Fri, 04 Feb 2005 16:03:07 -0500 (EST)
Date: Fri, 04 Feb 2005 13:03:09 -0800
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Conflicts to avoid for BoF/WG?
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
References: <[e-mail]>
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2005 21:05:11 -0000
Status: RO
Content-Length: 8135

Is it possible to request that this not be Friday? A lot of people make 
plane reservations
early assuming that they don't want to stay on Friday.

As for the agenda...looks great. I'm happy to lead any of the 
discussions below
if you don't have other volunteers. Though for the one you have me down 
for (mixing
L2 link types) I can talk about some ways of doing it, but I'm still not 
really clear
on why people want this, and what types of links they'd like to mix. Is 
there
someone who would like to talk about the problem statement?

Radia



Erik Nordmark wrote:

>
> Are there other conflicts which we must avoid?
>
>    Erik
>
>
> This might be approved as a WG before the meeting, but we will schedule
> it as a BoF for the time being.
>
>    a. Working Group or BOF full name with acronym in brackets:
>     TRansparent Interconnection of Lots of Links (TRILL)
>    b. AREA under which Working Group or BOF appears:
>     INT
>    c. CONFLICTS you wish to avoid, please be as specific as possible:
>     multi6, shim6, ipv6, v6ops, is-is, ospf
>
>    d. Expected Attendance (figures from the previous IETF are sent when
>       WG/BOF scheduling opens)
>     100 (based on IPVLX BoF)
>
>    e. Special requests (i.e. multicast):
>    f. Number of slots:
>     1
>
>    g. Length of slot:
>           2 1/2 hours
>
> Bof Description: See proposed charter below.
> This is a follow-on to the IPVLX BoF in Aug 2004
>
> Bof Chair: Erik Nordmark <[e-mail]>
>
> Mailing list: [e-mail]
> Subscribe: http://www.postel.org/mailman/listinfo/rbridge
> Web page: http://www.postel.org/rbridge/
>     With additional information as well as mailing list archives
>
>
> Agenda:
> -------
>
>  - Welcome and Administrivia            5 minutes    Chair
>
>  - Charter review                10 minutes    Chair
>
>  - Problem statement discussion            30 minutes    Erik Nordmark
>     Including the "service" that a cloud of hybrid devices will
>     provide, whether it is equivalent to IEEE 802.1D devices, or
>     handles IP packets differently
>     When is it ok to reorder packets? MTU considerations?
>
>
>  - Threats and security considerations        10 minutes    ???
>         What should the goal be? What can we do better?
>
>  - Requirements on routing protocols        20 minutes    ???
>         For zero configuration
>         Carrying MAC addresses
>         Broadcast
>         IS-IS vs. OSPF vs. something else
>
>  - Connecting different L2 types        30 minutes    Radia Perlman?
>
>  - Choices for ARP/ND                10 minutes    ???
>        Constraints from security discussion (intentionally duplicate L2
>     addresses), mobility, SeND support, etc.
>
>
>  - Choices for broadcast/multicast        10 minutes    ???
>     Worth doing any optimizations? Spanning tree between rbridges?
>
>
>
> Proposed charter:
> -----------------
>
> TRansparent Interconnection of Lots of Links (TRILL)
>
>
> While IEEE 802 bridges are attractive due to not needing explicit
> configuration and allowing hosts to move within the bridged topology,
> they are more limited than IP routers since bridges
> only support IEEE 802 technologies, and the most common layer 2
> interconnection method (dynamically created spanning tree
> formation using bridges) is not as flexible and robust as layer 3 
> routing.
>
> The WG will design a hybrid solution that combines the simplicity of
> configuration while taking full advantage of complex topologies.
>
> The design should have the following properties:
>  - zero configuration of the hybrid devices
>  - ability for hosts to move without changing their IP address
>  - it should be possible to forward packets using pair-wise shortest 
> paths,
>    and exploit the redundant paths through the network for increased
>    aggregate bandwidth
>  - possible optimizations for ARP and Neighbor Discovery packets 
> (potentially
>    avoid flooding all the time)
>  - support Secure Neighbor Discovery
>  - the packet header should have a hop count for robustness in the 
> presence
>    of temporary routing loops
>  - nodes should be able to have multiple attachments to the network
>  - no delay when a new node is attached to the network
>  - multicast should work (and after a re-charter it might make sense to
>    look at optimizations for IP multicast)
>  - be no less secure than existing bridges (and explore whether the 
> protocol
>    can make "L2 address theft" harder or easier to detect)
>
> A required piece of the solution is an IP routing protocol which is 
> extended
> to carry L2 address reachability, handle broadcast, and is friendly to
> zero-configuration. Likely candidate are the link-state routing protocols
> since they can easily be extended to provide for broadcast, which is 
> believed
> to be difficult for distance vector protocols.
> This working group will define the requirements on such routing 
> protocol(s),
> and select the routing protocol(s) to be used.  The intent is that the 
> actual
> extensions to the routing protocol(s) be performed in the WGs with 
> expertise
> in the routing protocol(s).
>
> The working group will look into solutions that can interconnect 
> different
> layer 2 technologies, and also look at providing support for non-IP 
> protocols,
> even though one can not combine those two features together; the
> interconnection of different layer 2 technologies (with different layer 2
> address formats) will most likely only work for the IP family of 
> protocols.
> Whether the same or different address formats are used, there might be 
> a need
> to handle different MTUs.
>
> The WG will design a protocol that combines the benefits of bridges
> and routers in a way that will co-exist with existing hosts, IP routers
> and bridges. The design must support both IPv4 and IPv6
>
> The working group will not work any layer 3 aspects except to provide
>  - Possible optimizations for ARP and ND packets (not always
>    flooded everywhere)
>  - Being able to carry IP broadcast and multicast packets (which might 
> just
>    fall out from supporting L2 multicast)
>  - Defining the L3 operations needed to interconnect different L2 
> technologies
>
>
> The work consists of several, separable pieces:
>  - Defining the requirement on the routing protocol(s), and select one or
>    more routing protocols. The detailed specification of the 
> extensions to
>    a particular routing protocol will be left as an action item for the
>    specific routing protocol WG.
>  - Defining what information must be carried in an encapsulation 
> header for
>    data packets, and how to map that information to various link types 
> (e.g.,
>    IEEE LAN, Fibrechannel, MPLS)
>  - Defining how address resolution (ARP and Neighbor Discovery) is 
> performed,
>    taking into account the desire to be compatible with Secure Neighbor
>    Discovery.
>  - Defining how the solution extends to the case when multiple layer 2
>    technologies, that have different address format/length, are 
> interconnected.
>
> Deliverables
>  - A short draft on the problem statement and goals
>  - A document defining what information needs to be carried in routing
>    protocols to support the trill concept, and other requirements on
>    the routing protocols.
>  - Encapsulation draft specifying what needs to be carried in general
>    and the specific format to use on IEEE LANs
>  - ARP and ND draft
>  - Draft on interconnecting different types of layer 2 technologies
>  - Threat analysis document
>
> Goals and Milestones
>
> Jun 05  Problem statement and Goals submitted to IESG for Informational
> Sep 05  Routing protocol support requirements to IESG for Informational
> Dec 05  Encapsulation document to IESG for Proposed Standard
> Sep 05  ARP & ND to IESG for Proposed Standard
> Mar 06  Interconnecting Layer 2 Technologies document to IESG for
>         Proposed Standard
> Dec 05  Threat analysis to IESG for Informational
>
> ---
>
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge



Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j14K3WQ02021 for <[e-mail]>; Fri, 4 Feb 2005 12:03:32 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.81.36]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j14K3Wpv023559 for <[e-mail]>; Fri, 4 Feb 2005 12:03:32 -0800 (PST)
Received: from [129.146.89.82] (par.SFBay.Sun.COM [129.146.89.82]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j14K3U59619327; Fri, 4 Feb 2005 12:03:31 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 04 Feb 2005 12:03:30 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Conflicts to avoid for BoF/WG?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2005 20:04:51 -0000
Status: RO
Content-Length: 6981

Are there other conflicts which we must avoid?

    Erik


This might be approved as a WG before the meeting, but we will schedule
it as a BoF for the time being.

    a. Working Group or BOF full name with acronym in brackets:
	TRansparent Interconnection of Lots of Links (TRILL)
    b. AREA under which Working Group or BOF appears:
	INT
    c. CONFLICTS you wish to avoid, please be as specific as possible:
	multi6, shim6, ipv6, v6ops, is-is, ospf

    d. Expected Attendance (figures from the previous IETF are sent when
       WG/BOF scheduling opens)
	100 (based on IPVLX BoF)

    e. Special requests (i.e. multicast):
    f. Number of slots:
	1

    g. Length of slot:
       	2 1/2 hours

Bof Description: See proposed charter below.
This is a follow-on to the IPVLX BoF in Aug 2004

Bof Chair: Erik Nordmark <[e-mail]>

Mailing list: [e-mail]
Subscribe: http://www.postel.org/mailman/listinfo/rbridge
Web page: http://www.postel.org/rbridge/
	With additional information as well as mailing list archives


Agenda:
-------

  - Welcome and Administrivia			5 minutes	Chair

  - Charter review				10 minutes	Chair

  - Problem statement discussion			30 minutes	Erik Nordmark
	Including the "service" that a cloud of hybrid devices will
	provide, whether it is equivalent to IEEE 802.1D devices, or
	handles IP packets differently
	When is it ok to reorder packets? MTU considerations?


  - Threats and security considerations		10 minutes	???
     	What should the goal be? What can we do better?

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

  - Connecting different L2 types		30 minutes	Radia Perlman?

  - Choices for ARP/ND				10 minutes	???
    	Constraints from security discussion (intentionally duplicate L2
	addresses), mobility, SeND support, etc.


  - Choices for broadcast/multicast		10 minutes	???
	Worth doing any optimizations? Spanning tree between rbridges?



Proposed charter:
-----------------

TRansparent Interconnection of Lots of Links (TRILL)


While IEEE 802 bridges are attractive due to not needing explicit
configuration and allowing hosts to move within the bridged topology,
they are more limited than IP routers since bridges
only support IEEE 802 technologies, and the most common layer 2
interconnection method (dynamically created spanning tree
formation using bridges) is not as flexible and robust as layer 3 routing.

The WG will design a hybrid solution that combines the simplicity of
configuration while taking full advantage of complex topologies.

The design should have the following properties:
  - zero configuration of the hybrid devices
  - ability for hosts to move without changing their IP address
  - it should be possible to forward packets using pair-wise shortest paths,
    and exploit the redundant paths through the network for increased
    aggregate bandwidth
  - possible optimizations for ARP and Neighbor Discovery packets 
(potentially
    avoid flooding all the time)
  - support Secure Neighbor Discovery
  - the packet header should have a hop count for robustness in the presence
    of temporary routing loops
  - nodes should be able to have multiple attachments to the network
  - no delay when a new node is attached to the network
  - multicast should work (and after a re-charter it might make sense to
    look at optimizations for IP multicast)
  - be no less secure than existing bridges (and explore whether the 
protocol
    can make "L2 address theft" harder or easier to detect)

A required piece of the solution is an IP routing protocol which is extended
to carry L2 address reachability, handle broadcast, and is friendly to
zero-configuration. Likely candidate are the link-state routing protocols
since they can easily be extended to provide for broadcast, which is 
believed
to be difficult for distance vector protocols.
This working group will define the requirements on such routing protocol(s),
and select the routing protocol(s) to be used.  The intent is that the 
actual
extensions to the routing protocol(s) be performed in the WGs with 
expertise
in the routing protocol(s).

The working group will look into solutions that can interconnect different
layer 2 technologies, and also look at providing support for non-IP 
protocols,
even though one can not combine those two features together; the
interconnection of different layer 2 technologies (with different layer 2
address formats) will most likely only work for the IP family of protocols.
Whether the same or different address formats are used, there might be a 
need
to handle different MTUs.

The WG will design a protocol that combines the benefits of bridges
and routers in a way that will co-exist with existing hosts, IP routers
and bridges. The design must support both IPv4 and IPv6

The working group will not work any layer 3 aspects except to provide
  - Possible optimizations for ARP and ND packets (not always
    flooded everywhere)
  - Being able to carry IP broadcast and multicast packets (which might 
just
    fall out from supporting L2 multicast)
  - Defining the L3 operations needed to interconnect different L2 
technologies


The work consists of several, separable pieces:
  - Defining the requirement on the routing protocol(s), and select one or
    more routing protocols. The detailed specification of the extensions to
    a particular routing protocol will be left as an action item for the
    specific routing protocol WG.
  - Defining what information must be carried in an encapsulation header for
    data packets, and how to map that information to various link types 
(e.g.,
    IEEE LAN, Fibrechannel, MPLS)
  - Defining how address resolution (ARP and Neighbor Discovery) is 
performed,
    taking into account the desire to be compatible with Secure Neighbor
    Discovery.
  - Defining how the solution extends to the case when multiple layer 2
    technologies, that have different address format/length, are 
interconnected.

Deliverables
  - A short draft on the problem statement and goals
  - A document defining what information needs to be carried in routing
    protocols to support the trill concept, and other requirements on
    the routing protocols.
  - Encapsulation draft specifying what needs to be carried in general
    and the specific format to use on IEEE LANs
  - ARP and ND draft
  - Draft on interconnecting different types of layer 2 technologies
  - Threat analysis document

Goals and Milestones

Jun 05  Problem statement and Goals submitted to IESG for Informational
Sep 05  Routing protocol support requirements to IESG for Informational
Dec 05  Encapsulation document to IESG for Proposed Standard
Sep 05  ARP & ND to IESG for Proposed Standard
Mar 06  Interconnecting Layer 2 Technologies document to IESG for
         Proposed Standard
Dec 05  Threat analysis to IESG for Informational

---




Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j14Jw2Q00614 for <[e-mail]>; Fri, 4 Feb 2005 11:58:11 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.88.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j14Jvmdt005503 for <[e-mail]>; Fri, 4 Feb 2005 12:57:48 -0700 (MST)
Received: from [129.146.89.82] (par.SFBay.Sun.COM [129.146.89.82]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j14Jvk7p616169; Fri, 4 Feb 2005 11:57:47 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 04 Feb 2005 11:57:46 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Choice of routing protocols
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2005 19:58:54 -0000
Status: RO
Content-Length: 4378

Below is an excerpt from emails between myself and Bob Hinden that tries
to capture some issues around the choice of routing protocol.
Hopefully this can stimulate further discussion on this topic.

    Erik

-------- Original Message --------
Subject: Re: Late agenda item?:  ipvlx charter
Date: Mon, 31 Jan 2005 10:24:35 -0800
From: Erik Nordmark <[e-mail]>
To: Bob Hinden <[e-mail]>


Bob Hinden wrote:

> I also wonder if we want to consider OSPF for this.  The IETF owns all 
> the IPR and can produce derivative standards, where the situation with 
> ISIS is very different (e.g., OSI owns the basic protocol). It's going 
> to be difficult for an L2 bridge implementor to figure out and 
> understand which collection of IETF and OSI specs to use.  Also, if I 
> remember correctly, ISIS still requires manual configuration of 20 byte 
> OSI NSAP addresses.  This would be a pretty odd thing for a L2 bridge.

AFAIK it is only the 6-byte MAC address that is the 'system ID' in
IS-IS. One would probably need to fill in some dummy value for the AFI
and area, but this can be done without any manual config since each box
is assumed to have a factory assigned unique MAC address.

OSPF is a bit harder in fact, since (even with the IPv6 pieces in
OSPFv3) the OSPF router ID is a 4 byte number, and there isn't any
existing numbering space which could be used to create factory assigned
globally unique 32 bit numbers.

While in principle OSPF is interesting and should be explored, there are
some additional items (in addition to the router ID assignment) which
makes using OSPF harder than IS-IS:
  - the OSPF LSAs are specified to carry fixed length addresses (either
    IPv4 or IPv6), so one would probably need to define a new (set of)
    LSAs for TRILL Not a big deal really, but IS-IS was designed to
    handle variable length NLRI from the start.
  - OSPF is designed to run on top of IP whereas IS-IS runs directly on
    IEEE 802.1. While rbridges (just like bridges) will probably be
    assigned IP addresses for management purposes (SNMP), requiring an IP
    address for the rbridge before it can start OSPF do build the
    topology would be a severe limitation. One would want to allow
    rbridges that don't have IP addresses (e.g. for home), or where the
    IP addresses are assigned after the rbridges have established
    connectivity across the link (assigned using stateless IPv6 or DHCP
    for instance).
    [Bob later told me: A possible choice when using OSPF is to use
    OSPFv3 over IPv6 and IPv6 link-local addresses, since any device with
    an IEEE MAC address can form an IPv6 link-local address.]

So trust me, I did really like to use OSPF here, because of the IS-IS
specification issues but also because there are more open source OSPF
code out there for implementors to reuse.


> While on the general topic, RIPv2 might even be a reasonable choice for 
> routing technology.  It's a lot simpler to implement and would still 
> work a lot better than spanning tree.

TRILL does add one additional constraint on a routing protocol (beyond
carrying MAC addresses around) which is to be able to construct a
spanning tree between the rbridges. The spanning tree is needed for
flooding (ARP, ND, and any other broadcast/multicast). Doing this in a
link state protocol is relatively easy; each router can independently
calculate the spanning tree in a consistent manner. But it is far from
clear whether this can be be done in a distance vector protocol.

Also, part of the goal for TRILL is to be better than the IEEE 802.1D
spanning tree, which has a worst-case convergence time of 45 seconds or
so. It isn't clear that RIP is a good fit for fast convergence.

> My general question is:  Is the decision on the routing technology to be 
> used for this going to be something that the w.g. decides or is it just 
> assumed it is ISIS?  I would favor the former approach, but in either 
> case I think it is important that the charter clarify this.

The TRILL WG would need to make the choice.
If the actual routing protocol work is farmed out to the specific,
long-lived routing protocol WGs, the success would depend on those WGs
having interest in this space.
An option is that the TRILL WG define the
extension to the routing protocols, and just have that reviewed by the
routing protocol WG(s).

    Erik


Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j14FI4Q15024 for <[e-mail]>; Fri, 4 Feb 2005 07:18:05 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.86.38]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j14FI4pv008453 for <[e-mail]>; Fri, 4 Feb 2005 07:18:04 -0800 (PST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j14FI4Zc538524; Fri, 4 Feb 2005 07:18:04 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 04 Feb 2005 07:17:22 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Updated charter
References: <000901c50896$e2619610$6401a8c0@grayling>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2005 15:18:43 -0000
Status: RO
Content-Length: 2259

Joe Touch wrote:
>> 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.

And the numerous problems in that case are ....

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

It might route the packet based on the L2 address instead of IP, for
instance. Hence using a different term than "router" aids in clarity IMHO.

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

I think you need to re-read what I wrote above.


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

Who has been talking about hybrid devices which interconnect broadcast
and NMBA L2s?

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

Because, AFAIK, it forwards packets based on L2 addresses.
(Remember, we had this mailing list discussion about packets sent to
off-subnet destinations and the interaction with redirects etc, which
resulted in at a minimum packets destined off-subnet need to be routed
based on the L2 destination.)

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

I'm confused. We'd talked about ARP/ND flooding a while back, and
concluded there were security and robustness issues around that, which
need considerations.
But I thought the current topic was about interconnecting different
types of L2s (with different address formats), which is orthogonal to 
any limitations on the flooding of broadcasts.

    Erik



Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j140u2Q25785 for <[e-mail]>; Thu, 3 Feb 2005 16:56:02 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.81.144]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j140u1dt018441;  Thu, 3 Feb 2005 17:56:01 -0700 (MST)
Received: from [129.146.89.82] (par.SFBay.Sun.COM [129.146.89.82]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j140twdf285247; Thu, 3 Feb 2005 16:56:01 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 03 Feb 2005 16:55:58 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Agenda items?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2005 00:57:26 -0000
Status: RO
Content-Length: 753

Michael Smith wrote:
> I think an important issue to discuss is packet reordering.  The current
> rbridge proposal introduces a significant possibility of L2 packet
> reordering within a network with a stable topology.  IEEE bridges do not
> reorder packets except in some corner cases with the new rapid spanning tree
> protocol and even then, it is only during a network topology change.  The
> traditional spanning tree protocol (non-rapid spanning tree) provides no
> packet reordering even during topology change.  Since rbridges are targeted
> to support non-IP protocols, this issue should be addressed.

Perhaps it makes sense to add this under #1, and expand that item to 
cover the "service" provided by the cloud of hybrid devices.

    Erik


Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j140cNQ20532 for <[e-mail]>; Thu, 3 Feb 2005 16:38:23 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j140cMdv008225 for <[e-mail]>; Thu, 3 Feb 2005 17:38:23 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 03 Feb 2005 19:38:22 -0500 (EST)
Received: from [192.168.2.58] (vpn-129-150-16-79.SFBay.Sun.COM [129.150.16.79]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]>; Thu, 03 Feb 2005 19:38:22 -0500 (EST)
Date: Thu, 03 Feb 2005 16:38:25 -0800
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Agenda items?
In-reply-to: <[e-mail]>
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
References: <[e-mail]>
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2005 00:38:39 -0000
Status: RO
Content-Length: 932

Michael Smith wrote:

>
>Someone please correct me if I'm mistaken.  My understanding of the proposal
>is that packets sent to an unknown L2 destination will be treated as
>broadcast and sent along the single spanning tree.  Once the destination is
>known, packets will follow the shortest path which may or may not be the
>same as the spanning tree path.  Packets in transit via the spanning tree
>may quite easily be passed by subsequent packets following the shortest
>path, hence the reordering.
>
>  
>
Ah yes, that might cause some reordering. I'm not sure how much we 
should/need to
stand on our head to avoid reordering, especially if it's OK to 
"sometimes" do it (after
a topology change), so it's clearly assumed that
reordinering sometimes is not fatal. But it's definitely an issue we 
should discuss.

It would be nice for applications to realize they are working on a 
network and be
written appropriately.

Radia



Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j13NegQ06289 for <[e-mail]>; Thu, 3 Feb 2005 15:40:42 -0800 (PST)
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 03 Feb 2005 15:48:12 -0800
Received: from mira-sjc5-f.cisco.com (IDENT:[e-mail] [171.71.163.13]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j13NeYoQ017307; Thu, 3 Feb 2005 15:40:35 -0800 (PST)
Received: from michsmitw2k02 ([10.34.37.93]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id BBQ19184; Thu, 3 Feb 2005 15:40:02 -0800 (PST)
Message-Id: <[e-mail]>
From: "Michael Smith" <[e-mail]>
To: "'Alper Yegin'" <[e-mail]>, "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: RE: [rbridge] Agenda items?
Date: Thu, 3 Feb 2005 15:40:02 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <072501c50a44$57ba7ae0$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Thread-Index: AcUKRJTG14ZirDnRRE6997BN5xpldAAAzM5A
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2005 23:43:11 -0000
Status: RO
Content-Length: 4872

> From: Alper Yegin [mailto:[e-mail]] 
> 
> I have some clarification questions...
> 
> > I think an important issue to discuss is packet reordering.  The
> current
> > rbridge proposal introduces a significant possibility of L2 packet 
> > reordering within a network with a stable topology.
> 
> What aspect of rbridge would cause this?

Someone please correct me if I'm mistaken.  My understanding of the proposal
is that packets sent to an unknown L2 destination will be treated as
broadcast and sent along the single spanning tree.  Once the destination is
known, packets will follow the shortest path which may or may not be the
same as the spanning tree path.  Packets in transit via the spanning tree
may quite easily be passed by subsequent packets following the shortest
path, hence the reordering.

> 
> > IEEE bridges do not
> > reorder packets except in some corner cases with the new rapid
> spanning
> > tree
> > protocol and even then, it is only during a network topology change.
> The
> > traditional spanning tree protocol (non-rapid spanning 
> tree) provides
> no
> > packet reordering even during topology change.  Since rbridges are 
> > targeted to support non-IP protocols, this issue should be 
> addressed.
> 
> Is this increased reordering probability going to break 
> anything? Or, are you just identifying something that may 
> impact IP+ layer performance?

If I recall correctly, SNA has serious problems with reordering.  I did some
quick googling and apparently so do Netware, and DecNet.

For example, check the last couple of paragraphs in the following article:
http://www.telecommagazine.com/default.asp?journalid=3&func=departments&page
=0409t05&year=2004&month=9

Michael

> 
> Thank you.
> 
> Alper
> 
> 
> 
> 
> 
> > 
> > Michael
> > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Erik Nordmark
> > > Sent: Wednesday, February 02, 2005 6:19 PM
> > > To: Developing a hybrid router/bridge.
> > > Subject: [rbridge] Agenda items?
> > >
> > >
> > > 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
> > >
> > > _______________________________________________
> > > rbridge mailing list
> > > [e-mail]
> > > http://www.postel.org/mailman/listinfo/rbridge
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://www.postel.org/mailman/listinfo/rbridge


Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j13NVrQ03851 for <[e-mail]>; Thu, 3 Feb 2005 15:31:53 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j13NVqVw017040 for <[e-mail]>; Thu, 3 Feb 2005 16:31:53 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 03 Feb 2005 18:31:52 -0500 (EST)
Received: from [192.168.2.58] (vpn-129-150-16-79.SFBay.Sun.COM [129.150.16.79]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]>; Thu, 03 Feb 2005 18:31:52 -0500 (EST)
Date: Thu, 03 Feb 2005 15:31:55 -0800
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Agenda items?
In-reply-to: <[e-mail]>
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
References: <[e-mail]>
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2005 23:32:38 -0000
Status: RO
Content-Length: 4179

RBridges wouldn't reorder either, except after a topology change, unless 
people wanted
to path split across multiple paths on an ongoing basis. That would be 
problematic (because
of reordering) even for applications that can tolerate reordering 
because of issues like
a) TCP trying to discover the round-trip delay
b) TCP having to buffer out-of-order messages

However, using multiple paths is still possible if, (as is common with 
today's routers)
care is taken to send all packets for a given flow on the same choice, 
for instance
by doing a hash of addresses and ports to make a selection among 
equivalent paths to D.

Is there some way other than path splitting that you see the RBridge 
proposal reordering
packets within a network with a stable topology?

Radia



Michael Smith wrote:

>I think an important issue to discuss is packet reordering.  The current
>rbridge proposal introduces a significant possibility of L2 packet
>reordering within a network with a stable topology.  IEEE bridges do not
>reorder packets except in some corner cases with the new rapid spanning tree
>protocol and even then, it is only during a network topology change.  The
>traditional spanning tree protocol (non-rapid spanning tree) provides no
>packet reordering even during topology change.  Since rbridges are targeted
>to support non-IP protocols, this issue should be addressed.
>
>Michael
>
>  
>
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Erik Nordmark
>>Sent: Wednesday, February 02, 2005 6:19 PM
>>To: Developing a hybrid router/bridge.
>>Subject: [rbridge] Agenda items?
>>
>>
>>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
>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>>    
>>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>


Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j13N1uQ25089 for <[e-mail]>; Thu, 3 Feb 2005 15:01:57 -0800 (PST)
Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <[e-mail]> for [e-mail]; Fri, 04 Feb 2005 08:01:50 +0900 (KST)
Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 04 Feb 2005 08:01:49 +0900 (KST)
Received: from Alperyegin ([105.144.29.41]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <[e-mail]> for [e-mail]; Fri, 04 Feb 2005 08:01:49 +0900 (KST)
Date: Thu, 03 Feb 2005 15:01:47 -0800
From: Alper Yegin <[e-mail]>
Subject: RE: [rbridge] Agenda items?
In-reply-to: <[e-mail]>
To: [e-mail], "'Developing a hybrid router/bridge.'" <[e-mail]>
Message-id: <072501c50a44$57ba7ae0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2005 23:03:05 -0000
Status: RO
Content-Length: 3750

I have some clarification questions...

> I think an important issue to discuss is packet reordering.  The
current
> rbridge proposal introduces a significant possibility of L2 packet
> reordering within a network with a stable topology.  

What aspect of rbridge would cause this?

> IEEE bridges do not
> reorder packets except in some corner cases with the new rapid
spanning
> tree
> protocol and even then, it is only during a network topology change.
The
> traditional spanning tree protocol (non-rapid spanning tree) provides
no
> packet reordering even during topology change.  Since rbridges are
> targeted
> to support non-IP protocols, this issue should be addressed.

Is this increased reordering probability going to break anything? Or,
are you just identifying something that may impact IP+ layer
performance?

Thank you.

Alper





> 
> Michael
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Erik Nordmark
> > Sent: Wednesday, February 02, 2005 6:19 PM
> > To: Developing a hybrid router/bridge.
> > Subject: [rbridge] Agenda items?
> >
> >
> > 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
> >
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://www.postel.org/mailman/listinfo/rbridge
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge




Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j13MWLQ15708 for <[e-mail]>; Thu, 3 Feb 2005 14:32:21 -0800 (PST)
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 03 Feb 2005 14:39:51 -0800
Received: from mira-sjc5-f.cisco.com (IDENT:[e-mail] [171.71.163.13]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j13MWEHo013984 for <[e-mail]>; Thu, 3 Feb 2005 14:32:14 -0800 (PST)
Received: from michsmitw2k02 ([10.34.37.93]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id BBQ09239; Thu, 3 Feb 2005 14:32:13 -0800 (PST)
Message-Id: <[e-mail]>
From: "Michael Smith" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: RE: [rbridge] Agenda items?
Date: Thu, 3 Feb 2005 14:32:12 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Thread-Index: AcUJl6v7JQzDlg78RwGWk9mqxBkiwwAptcpg
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2005 22:32:51 -0000
Status: RO
Content-Length: 3207

I think an important issue to discuss is packet reordering.  The current
rbridge proposal introduces a significant possibility of L2 packet
reordering within a network with a stable topology.  IEEE bridges do not
reorder packets except in some corner cases with the new rapid spanning tree
protocol and even then, it is only during a network topology change.  The
traditional spanning tree protocol (non-rapid spanning tree) provides no
packet reordering even during topology change.  Since rbridges are targeted
to support non-IP protocols, this issue should be addressed.

Michael

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Erik Nordmark
> Sent: Wednesday, February 02, 2005 6:19 PM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] Agenda items?
> 
> 
> 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
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j13HNrQ16280; Thu, 3 Feb 2005 09:23:53 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 03 Feb 2005 09:25:58 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Updated charter
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2005 17:25:54 -0000
Status: RO
Content-Length: 5905

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Posted to www.postel.org/rbridge

Once we lock on a name, I'll add that to the website...

Joe
- --


Erik Nordmark wrote:
|
| I generated an update because Margaret asked for one. As part of doing
| that I've tried to capture something about what has been discussed on
| the list.
|
| Next step is to figure out an agenda for Minneapolis.
|
|    Erik
|
|
| [Note: name change from IPVLX to TRILL]
|
| TRansparent Interconnection of Lots of Links (TRILL)
|
|
| While IEEE 802 bridges are attractive due to not needing explicit
| configuration and allowing hosts to move within the bridged topology,
| they are more limited than IP routers since bridges
| only support IEEE 802 technologies, and the most common layer 2
| interconnection method (dynamically created spanning tree
| formation using bridges) is not as flexible and robust as layer 3 routing.
|
| The WG will design a hybrid solution that combines the simplicity of
| configuration while taking full advantage of complex topologies.
|
| The design should have the following properties:
|  - zero configuration of the hybrid devices
|  - ability for hosts to move without changing their IP address
|  - it should be possible to forward packets using pair-wise shortest
paths,
|    and exploit the redundant paths through the network for increased
|    aggregate bandwidth
|  - possible optimizations for ARP and Neighbor Discovery packets
| (potentially
|    avoid flooding all the time)
|  - support Secure Neighbor Discovery
|  - the packet header should have a hop count for robustness in the
presence
|    of temporary routing loops
|  - nodes should be able to have multiple attachments to the network
|  - no delay when a new node is attached to the network
|  - multicast should work (and after a re-charter it might make sense to
|    look at optimizations for IP multicast)
|  - be no less secure than existing bridges (and explore whether the
| protocol
|    can make "L2 address theft" harder or easier to detect)
|
| A required piece of the solution is an IP routing protocol which is
| extended
| to carry L2 address reachability, handle broadcast, and is friendly to
| zero-configuration. Likely candidate are the link-state routing protocols
| since they can easily be extended to provide for broadcast, which is
| believed
| to be difficult for distance vector protocols.
| This working group will define the requirements on such routing
| protocol(s),
| and select the routing protocol(s) to be used.  The intent is that the
| actual
| extensions to the routing protocol(s) be performed in the WGs with
| expertise
| in the routing protocol(s).
|
| The working group will look into solutions that can interconnect different
| layer 2 technologies, and also look at providing support for non-IP
| protocols,
| even though one can not combine those two features together; the
| interconnection of different layer 2 technologies (with different layer 2
| address formats) will most likely only work for the IP family of
protocols.
| Whether the same or different address formats are used, there might be a
| need
| to handle different MTUs.
|
| The WG will design a protocol that combines the benefits of bridges
| and routers in a way that will co-exist with existing hosts, IP routers
| and bridges. The design must support both IPv4 and IPv6
|
| The working group will not work any layer 3 aspects except to provide
|  - Possible optimizations for ARP and ND packets (not always
|    flooded everywhere)
|  - Being able to carry IP broadcast and multicast packets (which might
just
|    fall out from supporting L2 multicast)
|  - Defining the L3 operations needed to interconnect different L2
| technologies
|
|
| The work consists of several, separable pieces:
|  - Defining the requirement on the routing protocol(s), and select one or
|    more routing protocols. The detailed specification of the extensions to
|    a particular routing protocol will be left as an action item for the
|    specific routing protocol WG.
|  - Defining what information must be carried in an encapsulation
header for
|    data packets, and how to map that information to various link types
| (e.g.,
|    IEEE LAN, Fibrechannel, MPLS)
|  - Defining how address resolution (ARP and Neighbor Discovery) is
| performed,
|    taking into account the desire to be compatible with Secure Neighbor
|    Discovery.
|  - Defining how the solution extends to the case when multiple layer 2
|    technologies, that have different address format/length, are
| interconnected.
|
| Deliverables
|  - A short draft on the problem statement and goals
|  - A document defining what information needs to be carried in routing
|    protocols to support the rbridge concept, and other requirements on
|    the routing protocols.
|  - Encapsulation draft specifying what needs to be carried in general
|    and the specific format to use on IEEE LANs
|  - ARP and ND draft
|  - Draft on interconnecting different types of layer 2 technologies
|  - Threat analysis document
|
| Goals and Milestones
|
| Jun 05  Problem statement and Goals submitted to IESG for Informational
| Sep 05  Routing protocol support requirements to IESG for Informational
| Dec 05  Encapsulation document to IESG for Proposed Standard
| Sep 05  ARP & ND to IESG for Proposed Standard
| Mar 06  Interconnecting Layer 2 Technologies document to IESG for
|         Proposed Standard
| Dec 05  Threat analysis to IESG for Informational
|
| ---
|
| _______________________________________________
| rbridge mailing list
| [e-mail]
| http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCAl6mE5f5cImnZrsRAktPAKD988gLmW4jP0EY+Qc8SOCJBHlV/QCg9BqH
F28k49z2KZrv7B7Gg9i3pgY=
=FRcU
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j13HC0Q12548; Thu, 3 Feb 2005 09:12:00 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 03 Feb 2005 09:14:05 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] updated BOF website
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2005 17:13:12 -0000
Status: RO
Content-Length: 135

Hi, all,

The Rbridge / IPVLX BOF website has been updated with the current
proposed charter (1/27/2005).

www.postel.org/rbridge

Joe


Received: from smtp807.mail.sc5.yahoo.com (smtp807.mail.sc5.yahoo.com [66.163.168.186]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id j13FhmQ13177 for <[e-mail]>; Thu, 3 Feb 2005 07:43:49 -0800 (PST)
Received: from unknown (HELO grayling) (osprey67@63.197.18.101 with login) by smtp807.mail.sc5.yahoo.com with SMTP; 3 Feb 2005 15:43:48 -0000
From: "Fred L. Templin" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: RE: [rbridge] IPvLX acronym and URLs
Date: Thu, 3 Feb 2005 07:44:55 -0800
Message-ID: <006501c50a07$4f3995f0$6401a8c0@grayling>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <000f01c508ae$6fa20cf0$6401a8c0@grayling>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2005 15:44:35 -0000
Status: RO
Content-Length: 750

The placeholder web page at 'ipvlx.{com,org.net}' has been updated.

Fred
[e-mail]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Fred L. Templin
Sent: Tuesday, February 01, 2005 2:36 PM
To: [e-mail]
Subject: [rbridge] IPvLX acronym and URLs


I have reserved the acronym "IPvLX" and domain names
'ipvlx.{com,org,net}' with the intention of turning them over at any
time the chairs feel they are ready to begin using them for the WG's
efforts - just let me know when you'd like to take them over, Erik. 

Fred
[e-mail]


_______________________________________________
rbridge mailing list
[e-mail] http://www.postel.org/mailman/listinfo/rbridge




Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j132JxQ25598 for <[e-mail]>; Wed, 2 Feb 2005 18:19:59 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.84.45]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j132Jxpv028022 for <[e-mail]>; Wed, 2 Feb 2005 18:19:59 -0800 (PST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j132JuaU611510; Wed, 2 Feb 2005 18:19:58 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 02 Feb 2005 18:19:13 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Agenda items?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2005 02:21:44 -0000
Status: RO
Content-Length: 2081

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



Received: from [192.168.1.47] (lsanca1-ar42-4-61-185-150.lsanca1.dsl-verizon.net [4.61.185.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j131wBQ20189; Wed, 2 Feb 2005 17:58:11 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 02 Feb 2005 17:58:06 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Updated charter
References: <000901c50896$e2619610$6401a8c0@grayling>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig84DA250CF4941CFCE2D19255"
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2005 02:00:15 -0000
Status: RO
Content-Length: 5169

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig84DA250CF4941CFCE2D19255
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



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

--------------enig84DA250CF4941CFCE2D19255
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCAYUuE5f5cImnZrsRAsGoAJ9g8M2fCGr7gpA9r2zMUSRwjlmU7gCbB5wG
O+9HYX4iFiQAT2FrVdLCW7M=
=8XFu
-----END PGP SIGNATURE-----

--------------enig84DA250CF4941CFCE2D19255--


Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j130x8Q04446 for <[e-mail]>; Wed, 2 Feb 2005 16:59:08 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.85.31]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j130x7Vu007795 for <[e-mail]>; Wed, 2 Feb 2005 17:59:07 -0700 (MST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j130x6Pq569280; Wed, 2 Feb 2005 16:59:06 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 02 Feb 2005 16:58:22 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2005 01:00:43 -0000
Status: RO
Content-Length: 5170

I generated an update because Margaret asked for one. As part of doing
that I've tried to capture something about what has been discussed on 
the list.

Next step is to figure out an agenda for Minneapolis.

    Erik


[Note: name change from IPVLX to TRILL]

TRansparent Interconnection of Lots of Links (TRILL)


While IEEE 802 bridges are attractive due to not needing explicit
configuration and allowing hosts to move within the bridged topology,
they are more limited than IP routers since bridges
only support IEEE 802 technologies, and the most common layer 2
interconnection method (dynamically created spanning tree
formation using bridges) is not as flexible and robust as layer 3 routing.

The WG will design a hybrid solution that combines the simplicity of
configuration while taking full advantage of complex topologies.

The design should have the following properties:
  - zero configuration of the hybrid devices
  - ability for hosts to move without changing their IP address
  - it should be possible to forward packets using pair-wise shortest paths,
    and exploit the redundant paths through the network for increased
    aggregate bandwidth
  - possible optimizations for ARP and Neighbor Discovery packets 
(potentially
    avoid flooding all the time)
  - support Secure Neighbor Discovery
  - the packet header should have a hop count for robustness in the presence
    of temporary routing loops
  - nodes should be able to have multiple attachments to the network
  - no delay when a new node is attached to the network
  - multicast should work (and after a re-charter it might make sense to
    look at optimizations for IP multicast)
  - be no less secure than existing bridges (and explore whether the 
protocol
    can make "L2 address theft" harder or easier to detect)

A required piece of the solution is an IP routing protocol which is extended
to carry L2 address reachability, handle broadcast, and is friendly to
zero-configuration. Likely candidate are the link-state routing protocols
since they can easily be extended to provide for broadcast, which is 
believed
to be difficult for distance vector protocols.
This working group will define the requirements on such routing protocol(s),
and select the routing protocol(s) to be used.  The intent is that the 
actual
extensions to the routing protocol(s) be performed in the WGs with 
expertise
in the routing protocol(s).

The working group will look into solutions that can interconnect different
layer 2 technologies, and also look at providing support for non-IP 
protocols,
even though one can not combine those two features together; the
interconnection of different layer 2 technologies (with different layer 2
address formats) will most likely only work for the IP family of protocols.
Whether the same or different address formats are used, there might be a 
need
to handle different MTUs.

The WG will design a protocol that combines the benefits of bridges
and routers in a way that will co-exist with existing hosts, IP routers
and bridges. The design must support both IPv4 and IPv6

The working group will not work any layer 3 aspects except to provide
  - Possible optimizations for ARP and ND packets (not always
    flooded everywhere)
  - Being able to carry IP broadcast and multicast packets (which might 
just
    fall out from supporting L2 multicast)
  - Defining the L3 operations needed to interconnect different L2 
technologies


The work consists of several, separable pieces:
  - Defining the requirement on the routing protocol(s), and select one or
    more routing protocols. The detailed specification of the extensions to
    a particular routing protocol will be left as an action item for the
    specific routing protocol WG.
  - Defining what information must be carried in an encapsulation header for
    data packets, and how to map that information to various link types 
(e.g.,
    IEEE LAN, Fibrechannel, MPLS)
  - Defining how address resolution (ARP and Neighbor Discovery) is 
performed,
    taking into account the desire to be compatible with Secure Neighbor
    Discovery.
  - Defining how the solution extends to the case when multiple layer 2
    technologies, that have different address format/length, are 
interconnected.

Deliverables
  - A short draft on the problem statement and goals
  - A document defining what information needs to be carried in routing
    protocols to support the rbridge concept, and other requirements on
    the routing protocols.
  - Encapsulation draft specifying what needs to be carried in general
    and the specific format to use on IEEE LANs
  - ARP and ND draft
  - Draft on interconnecting different types of layer 2 technologies
  - Threat analysis document

Goals and Milestones

Jun 05  Problem statement and Goals submitted to IESG for Informational
Sep 05  Routing protocol support requirements to IESG for Informational
Dec 05  Encapsulation document to IESG for Proposed Standard
Sep 05  ARP & ND to IESG for Proposed Standard
Mar 06  Interconnecting Layer 2 Technologies document to IESG for
         Proposed Standard
Dec 05  Threat analysis to IESG for Informational

---



Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j130vqQ04096 for <[e-mail]>; Wed, 2 Feb 2005 16:57:52 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.83.36]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j130vmiI008646 for <[e-mail]>; Wed, 2 Feb 2005 16:57:48 -0800 (PST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j130vm6J567991; Wed, 2 Feb 2005 16:57:48 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 02 Feb 2005 16:57:05 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Updated charter
References: <000901c50896$e2619610$6401a8c0@grayling>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2005 00:59:04 -0000
Status: RO
Content-Length: 3328

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


Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j12LFFQ27041 for <[e-mail]>; Wed, 2 Feb 2005 13:15:16 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.82.37]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j12LFFiI024253;  Wed, 2 Feb 2005 13:15:15 -0800 (PST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j12LFEDQ442363; Wed, 2 Feb 2005 13:15:14 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 02 Feb 2005 13:14:31 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Updated charter
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2005 21:16:58 -0000
Status: RO
Content-Length: 1385

Michael Smith wrote:

>>The solutions that have been discussed will replace the L2 
>>headers (at least in some cases, and encapsulate in another 
>>L2 header in some cases), and not decrement the L3 TTL, which 
>>is different than a bridge (which doesn't replace the L2 
>>header) and a router (which decrements TTL).
> 
> 
> Some specific examples may help clarify, but the above statement sounds like
> the traditional bridge of yore i.e. bridges with ethernet and token ring
> interfaces that swap MAC headers to the appropriate canonical format and
> encapsulating bridging packets over ATM and Frame Relay using RFC1483 and
> RFC1490.

I guess there is a difference between the theory of bridges, captured in 
IEEE standards, and what products actually do. I don't think the IEEE 
standards talk about what bridges between e.g. Ethernet and Token Ring 
do, but I recall products doing somethings like handling bit-order 
issues with the addresses in arp packets, and the need to fragment IP 
packets due to the different MTUs.

Radia's rbridge draft (I think) talks about optimizations for IP where 
the IP packet would transit a cloud of rbridges unmodified, but where 
the L2 header might be different on exit than on entry. This isn't a 
problem for IP, since IP doesn't look at the L2 header, but can't be 
applied to non-IP (aka unknown to the rbridge) protocols.

    Erik


Received: from smtp815.mail.sc5.yahoo.com (smtp815.mail.sc5.yahoo.com [66.163.170.1]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id j12J3GQ19680 for <[e-mail]>; Wed, 2 Feb 2005 11:03:16 -0800 (PST)
Received: from unknown (HELO grayling) (osprey67@63.197.18.101 with login) by smtp815.mail.sc5.yahoo.com with SMTP; 2 Feb 2005 19:03:15 -0000
From: "Fred L. Templin" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Wed, 2 Feb 2005 11:04:22 -0800
Message-ID: <003201c5095a$01ae6480$6401a8c0@grayling>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] An IPvLX Study
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2005 19:04:36 -0000
Status: RO
Content-Length: 3062

Joe Touch and I have been discussing off-list about a study
I have been involved with over the past few years which has
resulted in the following two Internet-Drafts:

  http://www.ietf.org/internet-drafts/draft-templin-ipvlx-01.txt
  http://www.ietf.org/internet-drafts/draft-templin-ipvlx-errata-05.txt

and an updated version that will obsolete both of these at:

  http://ipvlx.com/IPVLX.txt

The study proposes mechanisms and operational practices for
establishing virtual links between IP peer end nodes. The virtual
link can provide authentication (e.g., using Secure Neighbor
Discovery - SEND) and confidentiality (e.g., using IPSec). In
some cases, the virtual link can be extended all the way to the
end nodes but in other cases it may be desireable to terminate
the link at a router in the end node's network, e.g., to protect
people and assets from would-be attackers. (Both alternatives are
supported in the model proposed by the study.)

The study proposes IPv6 as the L3 protocol for end-node addressing
and IPv4 as the L2 protocol, i.e., IPv6-in-IPv4 tunneling, but it
could easily be extended to deal generically with IP-in-IP tunneling
(where "IP" could refer to any IP version). The study proposes special
nodes called: "IPvLX Gateways" that get involved in establishing and
providing transit switching for virtual links. These nodes exhibit
some of the same hybrid routing/bridging features proposed for Rbridges,
and can be deployed incrementally without requiring flag-day upgrades
of existing routers and bridges. In fact, IPvLX gateways need only
be deployed in the same locations that an IPv4 NAT would be deployed.

While the study presents a big-picture proposal for a next-generation
Internet architecture, it is also useful to consider the component
aspects seperately. In particular:

  1) Autoconfiguration - IPvLX nodes automatically configure
     themselves for operation with zero configuration.

  2) Encapsulation - the study proposes a special encapsulation in
     the L2 (IPv4) header to encode flow identification information.

  3) Link adaptation - the study proposes a link adaptation scheme
     used by virtual link endpoints to dynamically determine the
     best-fit L2 segment size (without packet loss) while presenting
     a uniform MTU to L3.

  4) Virtual link extension - the study proposes methods for
     establishing virtual links through Secure Neighbor Discovery
     and establishing soft state for flow switching in intermediate
     IPvLX gateways.

  5) Error handling - a method for relaying ICMPv4 error messages
     back to the IPvLX gateway at the near-end of a virtual link
     is proposed.

  6) Mobilitiy - aspects of IPvLX node mobility are discussed.
       

Although this study is now concluded, it is my sincere hope
that some/all of its aspects may be found useful for adoption
as work items for this group and that others will be interested
in helping to carry the work forward.

Please send any questions/comments,

Fred L. Templin
American Kestrel Consulting
[e-mail]




Received: from [192.168.1.47] (lsanca1-ar42-4-61-185-150.lsanca1.dsl-verizon.net [4.61.185.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j12ItlQ17298; Wed, 2 Feb 2005 10:55:47 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 02 Feb 2005 10:55:41 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [rbridge] Updated charter
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEAE780B311462D93FB27EA79"
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2005 18:56:50 -0000
Status: RO
Content-Length: 1495

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigEAE780B311462D93FB27EA79
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Michael Smith wrote:
...
> Yes, I was referring to traditional translational bridges which "adapt" the
> headers.  AFAIK, a bridge either retains the MAC header (transparent
> bridging), translates the MAC header (translational bridging), strips the
> header and terminates the frame (i.e. BPDUs), or encapsulates/decapsulates
> it when transporting across specific media types.  I was assuming that
> "replace the MAC header" in this context was referring to translational
> bridging.  If not, it would be nice to see a specific example as to what is
> meant by "replace" and if it implies something beyond the capabilities just
> stated.

Sure - translating 802 token ring to 802 ethernet is easy. IMO, they're 
effectively a single L2 by design.

Translating 802 to ATM is not.

Joe

--------------enigEAE780B311462D93FB27EA79
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCASItE5f5cImnZrsRAjD9AKDGqQkjt8aXZh9lwzSTox1dIxzpxACglDC3
S9okJ2jNxNibzj47cJkS9ic=
=HffL
-----END PGP SIGNATURE-----

--------------enigEAE780B311462D93FB27EA79--


Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j12Is5Q16883 for <[e-mail]>; Wed, 2 Feb 2005 10:54:05 -0800 (PST)
Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j12Irxpv004414 for <[e-mail]>; Wed, 2 Feb 2005 10:54:05 -0800 (PST)
Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j12IrxQp019048; Wed, 2 Feb 2005 13:53:59 -0500 (EST)
Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j12Irx0e015333; Wed, 2 Feb 2005 13:53:59 -0500 (EST)
Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j12Irxne015332; Wed, 2 Feb 2005 13:53:59 -0500 (EST)
X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to [e-mail] using -f
Subject: Re: [rbridge] What should be the goal in terms of security?
From: Bill Sommerfeld <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1107370438.13538.378.camel@thunk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6.325 
Date: Wed, 02 Feb 2005 13:53:58 -0500
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2005 18:54:34 -0000
Status: RO
Content-Length: 255

On Wed, 2005-02-02 at 08:33, marcelo bagnulo braun wrote:

> 
> If the goal is to replace routers by rbridges

I would hope that this is not our goal.

Maybe we need to state this extremely clearly at the start of every paragraph of the
charter.











Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j12IiqQ13392 for <[e-mail]>; Wed, 2 Feb 2005 10:44:52 -0800 (PST)
Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 02 Feb 2005 11:55:08 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-f.cisco.com (IDENT:[e-mail] [171.71.163.13]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j12IigPA011070; Wed, 2 Feb 2005 10:44:44 -0800 (PST)
Received: from michsmitw2k02 ([10.34.37.29]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id BBO48908; Wed, 2 Feb 2005 10:44:31 -0800 (PST)
Message-Id: <[e-mail]>
From: "Michael Smith" <[e-mail]>
To: "'Joe Touch'" <[e-mail]>, "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: RE: [rbridge] Updated charter
Date: Wed, 2 Feb 2005 10:44:31 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Thread-Index: AcUJUIv0ZBym4UXuQZWe4aCeshBvHAABWIFg
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2005 18:46:57 -0000
Status: RO
Content-Length: 1770

> From: Joe Touch [mailto:[e-mail]] 
>
> Michael Smith wrote:
> >  
> >>From: Erik Nordmark
> >>
> >>Joe Touch wrote:
> ...
> >>The solutions that have been discussed will replace the L2 
> headers (at 
> >>least in some cases, and encapsulate in another
> >>L2 header in some cases), and not decrement the L3 TTL, which is 
> >>different than a bridge (which doesn't replace the L2
> >>header) and a router (which decrements TTL).
> > 
> > Some specific examples may help clarify, but the above statement 
> > sounds like the traditional bridge of yore i.e. bridges 
> with ethernet 
> > and token ring interfaces that swap MAC headers to the appropriate 
> > canonical format and encapsulating bridging packets over 
> ATM and Frame 
> > Relay using RFC1483 and RFC1490.
> 
> How they're encapsulated isn't important per se. Traditional 
> bridges between ethernet and 802 token ring don't change the 
> MAC header; they adapt between to access protocols, frame 
> structures, etc, but the addresses are consistent. Or are you 
> referring to somthing else, and if so, perhaps it'd be useful 
> to understand why it's extinct at this point...

Yes, I was referring to traditional translational bridges which "adapt" the
headers.  AFAIK, a bridge either retains the MAC header (transparent
bridging), translates the MAC header (translational bridging), strips the
header and terminates the frame (i.e. BPDUs), or encapsulates/decapsulates
it when transporting across specific media types.  I was assuming that
"replace the MAC header" in this context was referring to translational
bridging.  If not, it would be nice to see a specific example as to what is
meant by "replace" and if it implies something beyond the capabilities just
stated.

Michael

> 
> Joe
> 


Received: from [192.168.1.47] (lsanca1-ar42-4-61-185-150.lsanca1.dsl-verizon.net [4.61.185.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j12HqmQ26471; Wed, 2 Feb 2005 09:52:48 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 02 Feb 2005 09:52:41 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Updated charter
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig235A12815E7C72515D71009C"
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2005 17:56:29 -0000
Status: RO
Content-Length: 1760

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig235A12815E7C72515D71009C
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Michael Smith wrote:
>  
>>From: Erik Nordmark
>>
>>Joe Touch wrote:
...
>>The solutions that have been discussed will replace the L2 
>>headers (at least in some cases, and encapsulate in another 
>>L2 header in some cases), and not decrement the L3 TTL, which 
>>is different than a bridge (which doesn't replace the L2 
>>header) and a router (which decrements TTL).
> 
> Some specific examples may help clarify, but the above statement sounds like
> the traditional bridge of yore i.e. bridges with ethernet and token ring
> interfaces that swap MAC headers to the appropriate canonical format and
> encapsulating bridging packets over ATM and Frame Relay using RFC1483 and
> RFC1490.

How they're encapsulated isn't important per se. Traditional bridges 
between ethernet and 802 token ring don't change the MAC header; they 
adapt between to access protocols, frame structures, etc, but the 
addresses are consistent. Or are you referring to somthing else, and if 
so, perhaps it'd be useful to understand why it's extinct at this point...

Joe

--------------enig235A12815E7C72515D71009C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCARNqE5f5cImnZrsRAhZlAKCffUDXfWnGTAIVhD4KEcVA27lW/wCgxdsE
kzpguWruhtn8eMdjvN2c/NY=
=c8ks
-----END PGP SIGNATURE-----

--------------enig235A12815E7C72515D71009C--


Received: from [192.168.1.47] (lsanca1-ar42-4-61-185-150.lsanca1.dsl-verizon.net [4.61.185.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j12Hh7Q23311; Wed, 2 Feb 2005 09:43:07 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 02 Feb 2005 09:42:57 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] What should be the goal in terms of security?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig05488C457DE0055518EA91F4"
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2005 17:46:06 -0000
Status: RO
Content-Length: 1896

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig05488C457DE0055518EA91F4
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



marcelo bagnulo braun wrote:
> Hi all,
> 
> after all the discussion about ARP and flooding and so on, i guess that 
> an important point should be to clearly define what is the goal of the 
> rbridge solution in terms of security. I mean it seems to me that the 
> security provided by a router and the security provided by a bridge are 
> quite different. I mean, in arp, hijacking a link layer address seems to 
> be an important vulnerability, since it may allow sniffing and spoofing 
> any interface of the cloud. Besides, the potential DOS attakcs that may 
> result because of broacasts used for discovery may be important. All 
> this issues are not present in a routed network AFAICT.
> 
> So i guess that the first question is: an rbridge solution should 
> provide the level of security of a bridged network or the level of 
> security of a routed network?
> 
> If the goal is to replace routers by rbridges, i would say that the 
> routed network security level is required....

The goal, IMO, is to replace bridges by rbridges. rbridges ought to 
provide no worse security than bridges, with better performance 
(cross-section bandwidth, more than anything else IMO).

Joe

--------------enig05488C457DE0055518EA91F4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCAREmE5f5cImnZrsRAu1mAJ4rENiWnerHvR713HcXKiV8z5jjxACdGPe+
22HU+KHRKlrPlf4R9jGFnQM=
=8rQ6
-----END PGP SIGNATURE-----

--------------enig05488C457DE0055518EA91F4--


Received: from motgate7.mot.com (motgate7.mot.com [129.188.136.7]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j12EpgQ03075 for <[e-mail]>; Wed, 2 Feb 2005 06:51:42 -0800 (PST)
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id j12EgEKU017438 for <[e-mail]>; Wed, 2 Feb 2005 07:42:15 -0700 (MST)
Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id j12EoMfg006281 for <[e-mail]>; Wed, 2 Feb 2005 08:50:22 -0600
Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id <ZH8S4MMZ>; Wed, 2 Feb 2005 09:51:40 -0500
Message-ID: <[e-mail]>
From: Eastlake III Donald-LDE008 <[e-mail]>
To: [e-mail]
Subject: RE: [rbridge] What should be the goal in terms of security?
Date: Wed, 2 Feb 2005 09:51:39 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2005 14:52:33 -0000
Status: RO
Content-Length: 1601

I certainly never thought of Rbridges as an idea for downgrading the network by replacing routers but as a way of upgrading bridges to get such benefits of "routing" as you can get while still avoiding the configuration penalties of IP routing. More security is better if you can get it without undue penalty but bridged security is adequate, in my opinion.

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of marcelo bagnulo braun
Sent: Wednesday, February 02, 2005 8:34 AM
To: 'Developing a hybrid router/bridge.'
Subject: [rbridge] What should be the goal in terms of security?

Hi all,

after all the discussion about ARP and flooding and so on, i guess that 
an important point should be to clearly define what is the goal of the 
rbridge solution in terms of security. I mean it seems to me that the 
security provided by a router and the security provided by a bridge are 
quite different. I mean, in arp, hijacking a link layer address seems 
to be an important vulnerability, since it may allow sniffing and 
spoofing any interface of the cloud. Besides, the potential DOS attakcs 
that may result because of broacasts used for discovery may be 
important. All this issues are not present in a routed network AFAICT.

So i guess that the first question is: an rbridge solution should 
provide the level of security of a bridged network or the level of 
security of a routed network?

If the goal is to replace routers by rbridges, i would say that the 
routed network security level is required....

any thoughts...?

marcelo


Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j12DXmQ12721 for <[e-mail]>; Wed, 2 Feb 2005 05:33:48 -0800 (PST)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 010EE324BF for <[e-mail]>; Wed,  2 Feb 2005 14:33:42 +0100 (CET)
Received: from [163.117.139.55] (unknown [163.117.139.55]) by smtp03.uc3m.es (Postfix) with ESMTP id E1AE13244A for <[e-mail]>; Wed,  2 Feb 2005 14:33:41 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v619)
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
From: marcelo bagnulo braun <[e-mail]>
Date: Wed, 2 Feb 2005 14:33:58 +0100
X-Mailer: Apple Mail (2.619)
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] What should be the goal in terms of security?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2005 13:34:49 -0000
Status: RO
Content-Length: 954

Hi all,

after all the discussion about ARP and flooding and so on, i guess that 
an important point should be to clearly define what is the goal of the 
rbridge solution in terms of security. I mean it seems to me that the 
security provided by a router and the security provided by a bridge are 
quite different. I mean, in arp, hijacking a link layer address seems 
to be an important vulnerability, since it may allow sniffing and 
spoofing any interface of the cloud. Besides, the potential DOS attakcs 
that may result because of broacasts used for discovery may be 
important. All this issues are not present in a routed network AFAICT.

So i guess that the first question is: an rbridge solution should 
provide the level of security of a bridged network or the level of 
security of a routed network?

If the goal is to replace routers by rbridges, i would say that the 
routed network security level is required....

any thoughts...?

marcelo



Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j121ovQ01994 for <[e-mail]>; Tue, 1 Feb 2005 17:50:57 -0800 (PST)
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 01 Feb 2005 17:59:58 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-f.cisco.com (IDENT:[e-mail] [171.71.163.13]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j121onoQ013973 for <[e-mail]>; Tue, 1 Feb 2005 17:50:50 -0800 (PST)
Received: from michsmitw2k02 ([10.34.37.29]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id BBN74825; Tue, 1 Feb 2005 17:50:49 -0800 (PST)
Message-Id: <[e-mail]>
From: "Michael Smith" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: RE: [rbridge] Updated charter
Date: Tue, 1 Feb 2005 17:50:49 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Thread-Index: AcUIt/alyqjZHbx7QH24ttJ7w07JBgAEEV9A
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2005 01:54:19 -0000
Status: RO
Content-Length: 2766

 

> From: Erik Nordmark
> 
> Joe Touch wrote:
> 
> > While I cannot argue with the motivation, I don't think this is a 
> > place where we can "eat our cake and have it too". IMO, briding 
> > dissimilar MTUs might be possible, but bridging different 
> L2 address 
> > spaces implies a common address space, which means 
> something very much 
> > like IP (with all the warts noted above).
> > 
> > FWIW, if we end up peeking into L3 to get this done, then 
> we ought to 
> > call it a router and be done with it.
> 
> The charter calls it neither a router nor a bridge, but a hybrid.
> 
> The solutions that have been discussed will replace the L2 
> headers (at least in some cases, and encapsulate in another 
> L2 header in some cases), and not decrement the L3 TTL, which 
> is different than a bridge (which doesn't replace the L2 
> header) and a router (which decrements TTL).

Some specific examples may help clarify, but the above statement sounds like
the traditional bridge of yore i.e. bridges with ethernet and token ring
interfaces that swap MAC headers to the appropriate canonical format and
encapsulating bridging packets over ATM and Frame Relay using RFC1483 and
RFC1490.

Michael

> 
> Is there a problem with the devices being hybrids?
> They will preserve the behavior that an IP packet injected at 
> one end of
>   the link will appear unmodified at the other end.
> 
> 
> > Optimizing is one thing, but talking about specifics (involving 
> > flooding) or not is where the charter is getting a bit overspecific.
> 
> Ack. Let me see what additional comments Margaret receives 
> from the IESG 
> and IAB.
> 
> > As to the last bullet, see RFC1812, which IMO provides 
> exactly the L3 
> > operations that interconnect disparate L2s.
> > 
> >> FYI: Some more IAB/IESG comments have come in asking for more 
> >> clarifications on the relationship between this WG and the routing 
> >> protocol WG(s), so we will most likely need more detail on 
> that front 
> >> in the charter.
> > 
> > 
> > Agreed. This doesn't appear to discuss the encapsulation of routing 
> > within the rbridge - that it is necessarily opaque to other routing 
> > protocols, e.g., BGP in ways unlike other routing protocols.
> 
> Do you mean opaque to the routing protocol used to carry IP 
> reachability? (where the ipvlx routing protocol carries L2 address 
> reachability)
> Or something different?
> 
> > Concrete list of work items, agreed.
> > 
> > Concrete list of approaches to those work items is the task 
> of the WG, IMO.
> 
> I'll make another pass over the charter and hopefully fix this.
> 
>     Erik
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


Received: from [192.168.1.47] (lsanca1-ar42-4-61-185-150.lsanca1.dsl-verizon.net [4.61.185.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j120s6Q14689; Tue, 1 Feb 2005 16:54:07 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 01 Feb 2005 16:54:01 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Updated charter
References: <000901c50896$e2619610$6401a8c0@grayling>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4A0EFA413916A050477FEE0E"
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2005 00:55:33 -0000
Status: RO
Content-Length: 3427

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4A0EFA413916A050477FEE0E
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Erik Nordmark wrote:
> Joe Touch wrote:
> 
>> While I cannot argue with the motivation, I don't think this is a 
>> place where we can "eat our cake and have it too". IMO, briding 
>> dissimilar MTUs might be possible, but bridging different L2 address 
>> spaces implies a common address space, which means something very much 
>> like IP (with all the warts noted above).
>>
>> FWIW, if we end up peeking into L3 to get this done, then we ought to 
>> call it a router and be done with it.
> 
> The charter calls it neither a router nor a bridge, but a hybrid.
> 
> The solutions that have been discussed will replace the L2 headers (at 
> least in some cases, and encapsulate in another L2 header in some 
> cases), and not decrement the L3 TTL, which is different than a bridge 
> (which doesn't replace the L2 header) and a router (which decrements TTL).
> 
> Is there a problem with the devices being hybrids?
> They will preserve the behavior that an IP packet injected at one end of 
>  the link will appear unmodified at the other end.

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.

What you're proposing is a router that doesn't decrement the TTL. 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.

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.

...
>>> FYI: Some more IAB/IESG comments have come in asking for more 
>>> clarifications on the relationship between this WG and the routing 
>>> protocol WG(s), so we will most likely need more detail on that front 
>>> in the charter.
>>
>> Agreed. This doesn't appear to discuss the encapsulation of routing 
>> within the rbridge - that it is necessarily opaque to other routing 
>> protocols, e.g., BGP in ways unlike other routing protocols.
> 
> Do you mean opaque to the routing protocol used to carry IP 
> reachability? (where the ipvlx routing protocol carries L2 address 
> reachability)
> Or something different?

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

Joe

--------------enig4A0EFA413916A050477FEE0E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCACSqE5f5cImnZrsRAtuUAJ9Kmux5UbEffRpteUGVcmPo97WV9gCfW3Bk
tkyJ1ecJUZP2u9QNaqHwpj0=
=8b2H
-----END PGP SIGNATURE-----

--------------enig4A0EFA413916A050477FEE0E--


Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j11NboQ22296 for <[e-mail]>; Tue, 1 Feb 2005 15:37:50 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j11NbnVu003547 for <[e-mail]>; Tue, 1 Feb 2005 16:37:49 -0700 (MST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j11NbnsW908987; Tue, 1 Feb 2005 15:37:49 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 01 Feb 2005 15:37:05 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Updated charter
References: <000901c50896$e2619610$6401a8c0@grayling>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 01 Feb 2005 23:39:01 -0000
Status: RO
Content-Length: 2144

Joe Touch wrote:

> While I cannot argue with the motivation, I don't think this is a place 
> where we can "eat our cake and have it too". IMO, briding dissimilar 
> MTUs might be possible, but bridging different L2 address spaces implies 
> a common address space, which means something very much like IP (with 
> all the warts noted above).
> 
> FWIW, if we end up peeking into L3 to get this done, then we ought to 
> call it a router and be done with it.

The charter calls it neither a router nor a bridge, but a hybrid.

The solutions that have been discussed will replace the L2 headers (at 
least in some cases, and encapsulate in another L2 header in some 
cases), and not decrement the L3 TTL, which is different than a bridge 
(which doesn't replace the L2 header) and a router (which decrements TTL).

Is there a problem with the devices being hybrids?
They will preserve the behavior that an IP packet injected at one end of 
  the link will appear unmodified at the other end.


> Optimizing is one thing, but talking about specifics (involving 
> flooding) or not is where the charter is getting a bit overspecific.

Ack. Let me see what additional comments Margaret receives from the IESG 
and IAB.

> As to the last bullet, see RFC1812, which IMO provides exactly the L3 
> operations that interconnect disparate L2s.
> 
>> FYI: Some more IAB/IESG comments have come in asking for more 
>> clarifications on the relationship between this WG and the routing 
>> protocol WG(s), so we will most likely need more detail on that front 
>> in the charter.
> 
> 
> Agreed. This doesn't appear to discuss the encapsulation of routing 
> within the rbridge - that it is necessarily opaque to other routing 
> protocols, e.g., BGP in ways unlike other routing protocols.

Do you mean opaque to the routing protocol used to carry IP 
reachability? (where the ipvlx routing protocol carries L2 address 
reachability)
Or something different?

> Concrete list of work items, agreed.
> 
> Concrete list of approaches to those work items is the task of the WG, IMO.

I'll make another pass over the charter and hopefully fix this.

    Erik


Received: from [192.168.1.47] (lsanca1-ar42-4-61-185-150.lsanca1.dsl-verizon.net [4.61.185.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j11MvnQ11748; Tue, 1 Feb 2005 14:57:49 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 01 Feb 2005 14:57:43 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Updated charter
References: <000901c50896$e2619610$6401a8c0@grayling>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig69DD4763F6BD5673533869E8"
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 01 Feb 2005 22:58:36 -0000
Status: RO
Content-Length: 4037

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig69DD4763F6BD5673533869E8
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Erik Nordmark wrote:
> Joe Touch wrote:
> 
>> Why is interconnection of different L2 technologies either useful or
>> relevant? IMO, that's not a bridge anymore.
>>
>> I thought the goal was to build something that looked like a bridge from
>> the outside. Interconnecting different L2's (different address formats,
>> TTLs, etc.) is a router, isn't it?
> 
> There were folks that expressed interest in this at the BoF, and I 
> suspect the motivation is the same as for the rest of the work i.e. 
> avoid the subnet numbering issue one has with IP routers, have the 
> plug&play of bridges, and a robust protocol.

While I cannot argue with the motivation, I don't think this is a place 
where we can "eat our cake and have it too". IMO, briding dissimilar 
MTUs might be possible, but bridging different L2 address spaces implies 
a common address space, which means something very much like IP (with 
all the warts noted above).

FWIW, if we end up peeking into L3 to get this done, then we ought to 
call it a router and be done with it.

>> Also, some of the charter is over-specific:
>>
>> | The working group will not work any layer 3 aspects except to provide
>> |  - Optimizations so that ARP and ND packets are not always
>> |    flooded everywhere
>> |  - Being able to carry IP multicast packets using flooding (which will
>> |    presumably fall out by being able to flood L2 multicast packets, so
>> there
>> |    might not be any specific work needed here).
>> |  - Defining the L3 operations needed to interconnect different L2
>> technologies
>>
>> IMO, if we want to include, in general terms "optimizations to avoid
>> unnecessary flooding", or "ability to efficiently handle multicast",
>> that's good, but specifying HOW those should be achieved, or what
>> defined efficient, IMO is what the WG ought to decide.
> 
> Margaret has been circulating the draft charter amount the IAB and IESG 
> in advance of it being on their agenda (next week).
> The above items were added because Rob Austein thought the charter was 
> quite nebulous on what was needed in terms of L3, so I tried to clarify 
> things.
> 
> My take is that optimizing multicast delivery above just making it work, 
> is something which a WG can look into once they've delivered the basic 
> technology i.e. something that would be reasonable to add after a 
> recharter.

Optimizing is one thing, but talking about specifics (involving 
flooding) or not is where the charter is getting a bit overspecific.

As to the last bullet, see RFC1812, which IMO provides exactly the L3 
operations that interconnect disparate L2s.

> FYI: Some more IAB/IESG comments have come in asking for more 
> clarifications on the relationship between this WG and the routing 
> protocol WG(s), so we will most likely need more detail on that front in 
> the charter.

Agreed. This doesn't appear to discuss the encapsulation of routing 
within the rbridge - that it is necessarily opaque to other routing 
protocols, e.g., BGP in ways unlike other routing protocols.

>> Similar comments apply to the list of work items.
> 
> My experience is that the IESG wants to see a concrete list of work 
> items before they want to charter a WG.

Concrete list of work items, agreed.

Concrete list of approaches to those work items is the task of the WG, IMO.

Joe

--------------enig69DD4763F6BD5673533869E8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCAAlnE5f5cImnZrsRAud2AKDif0+WwpxBZJCOR4xiRdhkyRR3cgCg8Knj
eWAQPqIPMFy94iJ1TRN9F80=
=SDML
-----END PGP SIGNATURE-----

--------------enig69DD4763F6BD5673533869E8--


Received: from smtp808.mail.sc5.yahoo.com (smtp808.mail.sc5.yahoo.com [66.163.168.187]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id j11MZ9Q05582 for <[e-mail]>; Tue, 1 Feb 2005 14:35:09 -0800 (PST)
Received: from unknown (HELO grayling) (osprey67@63.197.18.101 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 1 Feb 2005 22:35:07 -0000
From: "Fred L. Templin" <[e-mail]>
To: <[e-mail]>
Date: Tue, 1 Feb 2005 14:36:12 -0800
Message-ID: <000f01c508ae$6fa20cf0$6401a8c0@grayling>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
Subject: [rbridge] IPvLX acronym and URLs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 01 Feb 2005 22:36:58 -0000
Status: RO
Content-Length: 286

I have reserved the acronym "IPvLX" and domain names
'ipvlx.{com,org,net}' with the intention of turning them over at any
time the chairs feel they are ready to begin using them for the WG's
efforts - just let me know when you'd like to take them over, Erik. 

Fred
[e-mail]




Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j11MONQ02823 for <[e-mail]>; Tue, 1 Feb 2005 14:24:23 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.88.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j11MO9pv014674;  Tue, 1 Feb 2005 14:24:09 -0800 (PST)
Received: from [129.146.89.82] (par.SFBay.Sun.COM [129.146.89.82]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j11MO6f5880548; Tue, 1 Feb 2005 14:24:07 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 01 Feb 2005 14:24:06 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Fred L. Templin" <[e-mail]>
References: <000901c50896$e2619610$6401a8c0@grayling>
In-Reply-To: <000901c50896$e2619610$6401a8c0@grayling>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: [rbridge] Re: Updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 01 Feb 2005 22:24:33 -0000
Status: RO
Content-Length: 576

Fred L. Templin wrote:
> Erik,
> 
> The updated Rbridge charter you posted on 1/27/05 doesn't say anything
> about MTU issues for bridging dissimilar layer 2 media. Can we have a
> bullet under work items and deliverables that specifically calls for
> work on MTU issues?

Perhaps it isn't a separable deliverable, but instead a goal for the 
solution to work when the MTUs are different, which might be the case 
even for L2s that use the same address format (such as one Ethernet with 
and one Ethernet without jumbo frame support)

I can add this to the charter.

    Erik


Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j11MLqQ02078 for <[e-mail]>; Tue, 1 Feb 2005 14:21:52 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.87.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j11MLqiI006105 for <[e-mail]>; Tue, 1 Feb 2005 14:21:52 -0800 (PST)
Received: from [129.146.89.82] (par.SFBay.Sun.COM [129.146.89.82]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j11MLljo880021; Tue, 1 Feb 2005 14:21:50 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 01 Feb 2005 14:21:47 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Updated charter
References: <000901c50896$e2619610$6401a8c0@grayling> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 01 Feb 2005 22:22:33 -0000
Status: RO
Content-Length: 2248

Joe Touch wrote:
> Why is interconnection of different L2 technologies either useful or
> relevant? IMO, that's not a bridge anymore.
> 
> I thought the goal was to build something that looked like a bridge from
> the outside. Interconnecting different L2's (different address formats,
> TTLs, etc.) is a router, isn't it?

There were folks that expressed interest in this at the BoF, and I 
suspect the motivation is the same as for the rest of the work i.e. 
avoid the subnet numbering issue one has with IP routers, have the 
plug&play of bridges, and a robust protocol.


> Also, some of the charter is over-specific:
> 
> | The working group will not work any layer 3 aspects except to provide
> |  - Optimizations so that ARP and ND packets are not always
> |    flooded everywhere
> |  - Being able to carry IP multicast packets using flooding (which will
> |    presumably fall out by being able to flood L2 multicast packets, so
> there
> |    might not be any specific work needed here).
> |  - Defining the L3 operations needed to interconnect different L2
> technologies
> 
> IMO, if we want to include, in general terms "optimizations to avoid
> unnecessary flooding", or "ability to efficiently handle multicast",
> that's good, but specifying HOW those should be achieved, or what
> defined efficient, IMO is what the WG ought to decide.

Margaret has been circulating the draft charter amount the IAB and IESG 
in advance of it being on their agenda (next week).
The above items were added because Rob Austein thought the charter was 
quite nebulous on what was needed in terms of L3, so I tried to clarify 
things.

My take is that optimizing multicast delivery above just making it work, 
is something which a WG can look into once they've delivered the basic 
technology i.e. something that would be reasonable to add after a recharter.

FYI: Some more IAB/IESG comments have come in asking for more 
clarifications on the relationship between this WG and the routing 
protocol WG(s), so we will most likely need more detail on that front in 
the charter.

> Similar comments apply to the list of work items.

My experience is that the IESG wants to see a concrete list of work 
items before they want to charter a WG.

    Erik


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j11K15Q17356; Tue, 1 Feb 2005 12:01:05 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 01 Feb 2005 12:02:56 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Updated charter
References: <000901c50896$e2619610$6401a8c0@grayling>
In-Reply-To: <000901c50896$e2619610$6401a8c0@grayling>
X-Enigmail-Version: 0.86.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 01 Feb 2005 20:03:08 -0000
Status: RO
Content-Length: 2134

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fred L. Templin wrote:
| Erik,
|
| The updated Rbridge charter you posted on 1/27/05 doesn't say anything
| about MTU issues for bridging dissimilar layer 2 media. Can we have a
| bullet under work items and deliverables that specifically calls for
| work on MTU issues?
|
| Fred
| [e-mail]

That part of the proposed charter, notably:

| The working group will look into solutions that can interconnect different
| layer 2 technologies, and also look at providing support for non-IP
protocols,
| even though one can not combine those two features together; the
| interconnection of different layer 2 technologies (with different layer 2
| address formats) will most likely only work for the IP family of
protocols.

Why is interconnection of different L2 technologies either useful or
relevant? IMO, that's not a bridge anymore.

I thought the goal was to build something that looked like a bridge from
the outside. Interconnecting different L2's (different address formats,
TTLs, etc.) is a router, isn't it?

- ----

Also, some of the charter is over-specific:

| The working group will not work any layer 3 aspects except to provide
|  - Optimizations so that ARP and ND packets are not always
|    flooded everywhere
|  - Being able to carry IP multicast packets using flooding (which will
|    presumably fall out by being able to flood L2 multicast packets, so
there
|    might not be any specific work needed here).
|  - Defining the L3 operations needed to interconnect different L2
technologies

IMO, if we want to include, in general terms "optimizations to avoid
unnecessary flooding", or "ability to efficiently handle multicast",
that's good, but specifying HOW those should be achieved, or what
defined efficient, IMO is what the WG ought to decide.

Similar comments apply to the list of work items.

Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB/+BwE5f5cImnZrsRAjbgAJ9703XR7CGqFqkso+2kCK2/m7g7yQCg5RLI
JaxkiK8bI97zofOyoDnZcoM=
=Pb2m
-----END PGP SIGNATURE-----


Received: from smtp808.mail.sc5.yahoo.com (smtp808.mail.sc5.yahoo.com [66.163.168.187]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id j11JkWQ13414 for <[e-mail]>; Tue, 1 Feb 2005 11:46:32 -0800 (PST)
Received: from unknown (HELO grayling) (osprey67@63.197.18.101 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 1 Feb 2005 19:46:31 -0000
From: "Fred L. Templin" <[e-mail]>
To: <[e-mail]>
Date: Tue, 1 Feb 2005 11:47:37 -0800
Message-ID: <000901c50896$e2619610$6401a8c0@grayling>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
Subject: [rbridge] Updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 01 Feb 2005 19:48:31 -0000
Status: RO
Content-Length: 263

Erik,

The updated Rbridge charter you posted on 1/27/05 doesn't say anything
about MTU issues for bridging dissimilar layer 2 media. Can we have a
bullet under work items and deliverables that specifically calls for
work on MTU issues?

Fred
[e-mail]