[rbridge] (R)bridging dissimilar media

[gibanez at it.uc3m.es ( Guillermo Ibáñez )]

As far as I understand, TRILL supports it in the same way as Ethernet 
does support dissimilar physical media. Physical layer should be the 
same of standard Ethernet bridges. But it is only my personal view.
Guillermo

Templin, Fred L wrote:

>Does the TRILL approach extend to support (R)bridging of
>dissimilar media?
>
>Fred
>fred.l.templin at boeing.com
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

-- 
Guillermo Ib??ez
Departamento de Ingenier?a Telem?tica
Universidad Carlos III de Madrid
1.1.B.11 Colmenarejo 91-6241393
4.1.F.13 Legan?s 91-6248794



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 jAUJ9AE04279 for <[e-mail]>; Wed, 30 Nov 2005 11:09:10 -0800 (PST)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2B2DB82FDE for <[e-mail]>; Wed, 30 Nov 2005 20:09:04 +0100 (CET)
Received: from [163.117.203.92] (unknown [163.117.203.92]) by smtp03.uc3m.es (Postfix) with ESMTP id 2953482F01 for <[e-mail]>; Wed, 30 Nov 2005 20:09:03 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 30 Nov 2005 20:09:02 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
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]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] (R)bridging dissimilar media
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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, 30 Nov 2005 19:12:01 -0000
Status: RO
Content-Length: 657

As far as I understand, TRILL supports it in the same way as Ethernet 
does support dissimilar physical media. Physical layer should be the 
same of standard Ethernet bridges. But it is only my personal view.
Guillermo

Templin, Fred L wrote:

>Does the TRILL approach extend to support (R)bridging of
>dissimilar media?
>
>Fred
>[e-mail]
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

-- 
Guillermo Ib??ez
Departamento de Ingenier?a Telem?tica
Universidad Carlos III de Madrid
1.1.B.11 Colmenarejo 91-6241393
4.1.F.13 Legan?s 91-6248794



Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAUGIHE29554 for <[e-mail]>; Wed, 30 Nov 2005 08:18:17 -0800 (PST)
Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA18081 for <[e-mail]>; Wed, 30 Nov 2005 08:18:12 -0800 (PST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jAUGICx28722 for <[e-mail]>; Wed, 30 Nov 2005 08:18:12 -0800 (PST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 30 Nov 2005 08:17:41 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 30 Nov 2005 08:17:41 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: (R)bridging dissimilar media
Thread-Index: AcXxztjtw6r2e4BhTiCMrGRMIwzRIgD+jGFg
From: "Templin, Fred L" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 30 Nov 2005 16:17:41.0686 (UTC) FILETIME=[96C82D60:01C5F5C9]
X-ISI-4-43-8-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 jAUGIHE29554
Subject: [rbridge] (R)bridging dissimilar media
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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, 30 Nov 2005 16:20:07 -0000
Status: RO
Content-Length: 107

Does the TRILL approach extend to support (R)bridging of
dissimilar media?

Fred
[e-mail]


Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAPEdpE28335 for <[e-mail]>; Fri, 25 Nov 2005 06:39:52 -0800 (PST)
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ECB28259716 for <[e-mail]>; Fri, 25 Nov 2005 15:39:17 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04663-05 for <[e-mail]>; Fri, 25 Nov 2005 15:39:13 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 22C2025971A for <[e-mail]>; Fri, 25 Nov 2005 15:39:11 +0100 (CET)
Date: Fri, 25 Nov 2005 15:39:30 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Message-ID: <BDD1451F2D3F7999934B11CD@B50854F0A9192E8EC6CDA126>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========3EB39BD549AA82DD307E=========="
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Notes on draft-touch-trill-prob-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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, 25 Nov 2005 14:40:36 -0000
Status: RO
Content-Length: 4011

--==========3EB39BD549AA82DD307E==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Summary:

Good start. Much to be done.

- Key issue: Are you baselining "the current Ethernet" off 802.1D-1998=20
(with the STP protocol), 802.1D-2004 (with the RSTP protocol), or are you=20
thinking about some network that incorporates devices of both types? I=20
couldn't tell.
Also, the problem statement does not mention VLAN (802.1Q - another moving=20
target - current version is -2003). Where does it fit?

- Key issue: Should we attach strict numbers to the "should scale as large=20
as current Ethernet solutions"? I'd like to have the numbers in there=20
somewhere (very round numbers), like saying the protocol MUST function=20
effectively in deployments of:

 * 1000 end-hosts in a single bridged LAN of 100 bridges
 * 100.000 end-hosts inside 1000 VLANs served by 10.000 bridges

Those numbers were pulled from a hat - but naming numbers works better at=20
pointing out whether we agree or just think we do.....

Details, dumped while I read through the document:

- Section 1: I think "host reattachment" doesn't affect the STP convergence =

at all; it is bridge reattachment that does you in. Host reattachment=20
matters because of the time required to "unlearn" MAC addresses - but=20
that's a different issue than STP.

- Section 1, term "Ethernet link subnet" - I think the 802.1D-2004 term is=20
"Bridged Local Area Network" - 802.1D uses "Network" to refer to a bridged=20
net and "LAN" to refer to a non-bridged component of that network. I think=20
we should avoid inventing terms unless we have to.

- Section 1: I think "operating at the link layer" should be "offering an=20
Ethernet service" - with a reference to IEEE 802-2001 section 7.1 for a=20
defintion of what that is. (That's a reference to ISO/IEC 15802-1; you're=20
caught in a twisty little maze of standards, all interdependent...)

- Section 2.1: The diagram becomes less untidy if you switch the bridges=20
marked A and B - then, lines don't cross....

- Section 2.4: I don't think STP is the main culprit limiting the size of=20
an Ethernet domain, and we shouldn't say that it is; I think that with=20
normal hosts, it's the broadcast traffic that matters most..... other=20
opinions?

- Section 2.4: I can't parse "grouped modularity". Rephrase?

- Section 3.1, "No change to Link capabilities", should mention the=20
ordering and duplication guarantees of Ethernet: in-order delivery and no=20
duplicated packets.

- The way section 3.2 reads now, it looks as if you want to autoconfigure=20
VLANs. While that may be possible for inter-bridge bridges (.1Q ports), I=20
don't think it's possible for bridges with end-user ports. Note that=20
letting ports autoconfigure to .1Q is a security risk! We should probably=20
move this mention to the section (3.6) on how we want to deal with VLANs -=20
too many different issues, interwined.

- Section 3.3: I wouldn't call TTL "loop avoidance", it's more like "loop=20
effect mitigation".

- Section 3.4: May want to be explicit again that we want to require=20
absolutely no modification to bridges running (R)STP.

- I don't think section 3.7 adds much... and I think the main point is=20
equivalence *as seen from the end-users*.

- section 3.9: the more important issue that makes stealing the IP TTL=20
field impossible is that there is traffic that is not IP....

No promise that this is anywhere near a final set of comments. But I=20
thought it would provide value to the participants to share these now.

                   Harald







--==========3EB39BD549AA82DD307E==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFDhyIjOMj+2+WY0F4RAlZWAKDZBr8CgfxJvYRsgwnUDFB3YmegXQCdHjNN
TlV3tjxFpnquHsLIJIn6Unk=
=oJgb
-----END PGP SIGNATURE-----

--==========3EB39BD549AA82DD307E==========--



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 jAILJZE09003; Fri, 18 Nov 2005 13:19:35 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 18 Nov 2005 13:19:36 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
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.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] TRILL rbridge architecture submitted
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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, 18 Nov 2005 21:19:49 -0000
Status: RO
Content-Length: 1281

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



Gray, Eric wrote:
> Joe,
> 
> 	I did not find it under that name
> (draft-touch-trill-rbridge-arch-00.txt).

I submitted it to the ID queue; it takes a day or two. It's up on the
rbridge website (www.postel.org/rbridge)

> do you mean that it has been submitted rather than it has been posted - or
> is
> it under a different name? 
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [e-mail] 
> --> [mailto:[e-mail]] On Behalf Of Joe Touch
> --> Sent: Friday, November 18, 2005 2:49 PM
> --> To: Joe Touch
> --> Cc: Developing a hybrid router/bridge.
> --> Subject: [rbridge] TRILL rbridge architecture submitted
> --> 
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://www.postel.org/mailman/listinfo/rbridge
> --> 
> _______________________________________________
> 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

iD8DBQFDfkVoE5f5cImnZrsRAqFWAJ9xWobgphoGHB/jt90mZokCf0MNuwCgkftI
AeT2NwreFVNf0eEwUFpxbj4=
=whQO
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAIKA1E17576 for <[e-mail]>; Fri, 18 Nov 2005 12:10:01 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jAIK9sfK025714 for <[e-mail]>; Fri, 18 Nov 2005 15:09:55 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA08411 for <[e-mail]>; Fri, 18 Nov 2005 15:09:54 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WCKH70PW>; Fri, 18 Nov 2005 18:09:54 -0200
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Fri, 18 Nov 2005 18:09:53 -0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] TRILL rbridge architecture submitted
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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, 18 Nov 2005 20:10:49 -0000
Status: RO
Content-Length: 3146

Joe,

	I did not find it under that name
(draft-touch-trill-rbridge-arch-00.txt).
do you mean that it has been submitted rather than it has been posted - or
is
it under a different name? 

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Joe Touch
--> Sent: Friday, November 18, 2005 2:49 PM
--> To: Joe Touch
--> Cc: Developing a hybrid router/bridge.
--> Subject: [rbridge] TRILL rbridge architecture submitted
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Hi, all,
--> 
--> The rbridge architecture doc has been posted to the Internet drafts.
--> The only change was the reference to the P&AS doc, and that 
--> this document is currently considered the product of a few 
--> authors rather than an editor (that decision can be revised 
--> if accepted as a WG doc).
--> 
--> Joe
--> 
--> - ---
--> 
--> TRILL WG                                                    
-->    J. Touch
--> Internet Draft                                              
-->     USC/ISI
--> Expires: May 2006                                           
-->  R. Perlman
-->                                                             
-->         Sun
-->                                                       
--> November 18, 2005
--> 
--> 
-->              The Architecture of an RBridge Solution to TRILL
-->                    draft-touch-trill-rbridge-arch-00.txt
--> 
--> ...
--> Abstract
--> 
-->    RBridges are link layer (L2) devices that use routing 
--> protocols as a
-->    control plane. They combine the link layer ability to 
--> allow hosts to
-->    reattach without renumbering with network layer routing benefits.
-->    RBridges use existing link state routing to provide 
--> higher internal
-->    cross-section bandwidth, faster convergence under 
--> reconfiguration,
-->    and more robustness to link interruption than an 
--> equivalent set of
-->    conventional bridges using existing spanning tree 
--> forwarding. They
-->    are intended to apply to similar L2 network sizes as conventional
-->    bridges and are intended to be backward compatible with 
--> those bridges
-->    as both ingress/egress and transit. They also attempt to 
--> retain as
-->    much 'plug and play' as is already available in existing bridges.
-->    This document proposes the RBridge system as a solution 
--> to the TRILL
-->    problem. It also defines the RBridge architecture, presents its
-->    terminology, and describes its basic components and 
--> desired behavior.
-->    A separate document specifies the protocols and mechanisms that
-->    satisfy the architecture presented herein.
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDfjA6E5f5cImnZrsRAmC6AKCKjuSMzCq6vBpihtt2wutf9vhlUACgxe1s
--> tPzcyx/UvFeuiFlvo8Bp/oU=
--> =XWhl
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> 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 jAIJnDE11259; Fri, 18 Nov 2005 11:49:13 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 18 Nov 2005 11:49:14 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Touch <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: [rbridge] TRILL rbridge architecture submitted
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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, 18 Nov 2005 19:50:15 -0000
Status: RO
Content-Length: 2196

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



Hi, all,

The rbridge architecture doc has been posted to the Internet drafts.
The only change was the reference to the P&AS doc, and that this document
is currently considered the product of a few authors rather than an
editor (that decision can be revised if accepted as a WG doc).

Joe

- ---

TRILL WG                                                       J. Touch
Internet Draft                                                  USC/ISI
Expires: May 2006                                            R. Perlman
                                                                    Sun
                                                      November 18, 2005


             The Architecture of an RBridge Solution to TRILL
                   draft-touch-trill-rbridge-arch-00.txt

...
Abstract

   RBridges are link layer (L2) devices that use routing protocols as a
   control plane. They combine the link layer ability to allow hosts to
   reattach without renumbering with network layer routing benefits.
   RBridges use existing link state routing to provide higher internal
   cross-section bandwidth, faster convergence under reconfiguration,
   and more robustness to link interruption than an equivalent set of
   conventional bridges using existing spanning tree forwarding. They
   are intended to apply to similar L2 network sizes as conventional
   bridges and are intended to be backward compatible with those bridges
   as both ingress/egress and transit. They also attempt to retain as
   much 'plug and play' as is already available in existing bridges.
   This document proposes the RBridge system as a solution to the TRILL
   problem. It also defines the RBridge architecture, presents its
   terminology, and describes its basic components and desired behavior.
   A separate document specifies the protocols and mechanisms that
   satisfy the architecture presented herein.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDfjA6E5f5cImnZrsRAmC6AKCKjuSMzCq6vBpihtt2wutf9vhlUACgxe1s
tPzcyx/UvFeuiFlvo8Bp/oU=
=XWhl
-----END PGP SIGNATURE-----


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 jAI9XWE11682 for <[e-mail]>; Fri, 18 Nov 2005 01:33:32 -0800 (PST)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2316083113 for <[e-mail]>; Fri, 18 Nov 2005 10:33:26 +0100 (CET)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp03.uc3m.es (Postfix) with ESMTP id 39965831C2 for <[e-mail]>; Fri, 18 Nov 2005 10:33:25 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 18 Nov 2005 10:33:26 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
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]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] TRILL Prob statement submitted
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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, 18 Nov 2005 09:34:07 -0000
Status: RO
Content-Length: 2862

Please forgive me if I discuss already agreed statements, but I would 
like to understand the reasons to exclude the scalability from the 
objectives. A minimum target should be stated for number of hosts. 
Taking into account that Ethernet networks are expanding in size, and 
the number of devices increases this is one of the main requirements for 
the near future. Besides this, it is a contradiction to look to replace 
routers inside campus networks and in practice we use them again because 
the replacement will not scale enough midterm. It seems  a bit 
shorsighted approach.  
Guillermo


Joe Touch wrote:

>Hi, all,
>
>I had a chance to update the problem statement to avoid all references
>to rbridges; the result, including corrected title and filename, was
>submitted today, and represents the 00 version from which to start
>discussion. It has been posted on the rbridge website, and should appear
>in the draft directories shortly.
>
>The similarly updated rbridge architecture doc should be posted
>tomorrow, FYI.
>
>Joe
>
>----
>
>TRILL WG                                                 J. Touch (ed.)
>Internet Draft                                                  USC/ISI
>Expires: May 2006                                     November 17, 2005
>
>
>           Transparent Interconnection of Lots of Links (TRILL):
>                    Problem and Applicability Statement
>                       draft-touch-trill-prob-00.txt
>
>...
>
>Abstract
>
>   Current Ethernet (802.1) link layers use custom routing protocols
>   that have a number of challenges. The routing protocols need to
>   strictly avoid loops, even temporary loops during route propagation,
>   because of the lack of header loop detection support. Routing tends
>   not to take full advantage of alternate paths, or even non-
>   overlapping pairwise paths (in the case of spanning trees). The
>   convergence of these routing protocols and stability under link
>   changes and failures is also of concern. This document addresses
>   these concerns and suggests that they are related to the need to be
>   able to apply network layer routing (e.g., link state or distance
>   vector) protocols at the link layer. This document assumes that
>   solutions would not address issues of scalability beyond that of
>   existing bridged (802.1D) links, but that a solution would be
>   backward compatible with 802.1D, including hubs, bridges, and their
>   existing plug-and-play capabilities.
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

-- 
Guillermo Ib??ez
Departamento de Ingenier?a Telem?tica
Universidad Carlos III de Madrid
1.1.B.11 Colmenarejo 91-6241393
4.1.F.13 Legan?s 91-6248794



Received: from [128.9.176.128] (ras28.isi.edu [128.9.176.128]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAI06BE00958; Thu, 17 Nov 2005 16:06:12 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 17 Nov 2005 16:06:09 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEA787D8E6F434FC114D2647B"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] TRILL Prob statement submitted
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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, 18 Nov 2005 00:07:14 -0000
Status: RO
Content-Length: 2522

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigEA787D8E6F434FC114D2647B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, all,

I had a chance to update the problem statement to avoid all references
to rbridges; the result, including corrected title and filename, was
submitted today, and represents the 00 version from which to start
discussion. It has been posted on the rbridge website, and should appear
in the draft directories shortly.

The similarly updated rbridge architecture doc should be posted
tomorrow, FYI.

Joe

----

TRILL WG                                                 J. Touch (ed.)
Internet Draft                                                  USC/ISI
Expires: May 2006                                     November 17, 2005


           Transparent Interconnection of Lots of Links (TRILL):
                    Problem and Applicability Statement
                       draft-touch-trill-prob-00.txt

=2E..

Abstract

   Current Ethernet (802.1) link layers use custom routing protocols
   that have a number of challenges. The routing protocols need to
   strictly avoid loops, even temporary loops during route propagation,
   because of the lack of header loop detection support. Routing tends
   not to take full advantage of alternate paths, or even non-
   overlapping pairwise paths (in the case of spanning trees). The
   convergence of these routing protocols and stability under link
   changes and failures is also of concern. This document addresses
   these concerns and suggests that they are related to the need to be
   able to apply network layer routing (e.g., link state or distance
   vector) protocols at the link layer. This document assumes that
   solutions would not address issues of scalability beyond that of
   existing bridged (802.1D) links, but that a solution would be
   backward compatible with 802.1D, including hubs, bridges, and their
   existing plug-and-play capabilities.


--------------enigEA787D8E6F434FC114D2647B
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.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFDfRrxE5f5cImnZrsRAsVqAJ9xEAmS5q/09kGEknOB1b2ifRc0iQCXbgE3
yUogOIB8NXCaSocE59eH2A==
=sogf
-----END PGP SIGNATURE-----

--------------enigEA787D8E6F434FC114D2647B--


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 jAA9S0Y28247 for <[e-mail]>; Thu, 10 Nov 2005 01:28:00 -0800 (PST)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6C5DC8304F for <[e-mail]>; Thu, 10 Nov 2005 10:27:54 +0100 (CET)
Received: from [163.117.139.70] (gibanez.it.uc3m.es [163.117.139.70]) by smtp03.uc3m.es (Postfix) with ESMTP id C355483056 for <[e-mail]>; Thu, 10 Nov 2005 10:27:53 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 10 Nov 2005 10:27:54 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
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: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] routing heirarchy discussion in	draft-touch-trill-rbridge-prob-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 09:28:48 -0000
Status: RO
Content-Length: 2499

IEEE 802.1Q  Multiple Spanning Tree Protocol. 
Tutorial available : "Understanding Multiple Spanning Tree Protocol" at 
www.cisco.com
Regards
Guillermo

Alia Atlas wrote:

>Could you send me a pointer to the ref on this work?  I'd be
>interested in taking
>a look.  Maybe we could come up with a more accurate statement - both
>of what is possible and what improvements trill might be able to
>provide.
>
>Alia
>
>On 11/9/05, Guillermo Ib??ez <[e-mail]> wrote:
>  
>
>>Alia Atlas wrote:
>>
>>    
>>
>>>Sec 2.2 says:
>>>
>>>"The spanning tree protocol is inherently global to an entire layer 2
>>>  subnet; there is no current way to contain, partition, or otherwise
>>>  factor the protocol into a number of smaller, more stable subsets
>>>  that interact as groups. Contrast this with Internet routing, which
>>>  includes both intradomain and interdomain variants, split to provide
>>>  exactly that containment and scalability within a domain while
>>>  allowing domains to interact freely independent of what happens
>>>  inside.  "
>>>
>>>
>>>
>>>      
>>>
>>This statement is not completely true, as Multiple Spanning Tree
>>Protocol allows the definition of regions
>>where independent trees are contained and partitioned.
>>
>>    
>>
>>>I think that one strength of rbridges is the potential for introducing
>>>a level of heirarchy in the routing.  However, I believe this is confined
>>>to IGP-like areas (intra-domain).  The idea of nesting inter-domain
>>>heirarchy inside seems rather implausible.
>>>
>>>If we are considering routing areas, then it may also be interesting to
>>>consider or at least discuss the topology constraints required in order
>>>to support such.
>>>
>>>
>>>
>>>      
>>>
>>Regarding introducing hierarchy, a second level of spanning trees
>>(double L2 encapsulated as well inside a confined core region with
>>multiple spanning trees,  each tree rooted at edge bridges) is also a
>>way to introduce hierarchy and hence obtain scalability
>>Guillermo
>>
>>    
>>
>>>Alia
>>>_______________________________________________
>>>rbridge mailing list
>>>[e-mail]
>>>http://www.postel.org/mailman/listinfo/rbridge
>>>
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>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 smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA9LfAM09059 for <[e-mail]>; Wed, 9 Nov 2005 13:41:10 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 295169E137 for <[e-mail]>; Wed,  9 Nov 2005 22:41:04 +0100 (CET)
Received: from [163.117.203.188] (unknown [163.117.203.188]) by smtp01.uc3m.es (Postfix) with ESMTP id 495109E130 for <[e-mail]>; Wed,  9 Nov 2005 22:41:03 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 09 Nov 2005 22:41:03 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
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: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Sec 2.3 in draft-touch-trill-rbridge-prob-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 21:45:36 -0000
Status: RO
Content-Length: 2133

Alia Atlas wrote:

>On 11/9/05, Guillermo Ib??ez <[e-mail]> wrote:
>  
>
>>Alia Atlas wrote:
>>
>>    
>>
>>>"It would be more useful for subnet configuration to be tolerant of
>>>  such transients, e.g., supporting alternate, backup paths.
>>>
>>>  [QUESTION: is there more to say here?]
>>>
>>>  Contrast this to network layer intradomain and interdomain routing,
>>>  both of which include provisions for backup paths. These backups
>>>  allow routing to be more stable in the presence of transients, as
>>>  well as to recover more "rapidly when the transient disappears. "
>>>
>>>I found the description here to be rather confusing.  Are you saying
>>>that the possibility for the use of additional links permits easier
>>>routing convergence?  Or are you suggesting that
>>>alternate next-hops can be pre-computed and used on a failure - as is
>>>described in the IP fast-reroute work in rtgwg?  I'd assume the
>>>former.  If that's the case, then I think the language needs some
>>>clarification.
>>>
>>>
>>>      
>>>
>>May be the terminology is confusing, but it is a must to obtain fast
>>reconfiguration as required by rbridges.
>>(I will be again advocate of RSTP as example, that includes alternate
>>port role, able to be root port via different path to root bridge,  for
>>faster reconfiguration.
>>    
>>
>
>What times do you define as fast reconfiguration?  If there's interest in
>using alternates such as in IP FRR, that could help; it may also add some
>complexity.
>  
>
Less than about one second seems acceptable for campus networks. 
Although tenths of milliseconds would be preferable.
Guillermo

>Alia
>
>  
>
>>>Alia
>>>_______________________________________________
>>>rbridge mailing list
>>>[e-mail]
>>>http://www.postel.org/mailman/listinfo/rbridge
>>>
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>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 wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA9LTTM04565 for <[e-mail]>; Wed, 9 Nov 2005 13:29:29 -0800 (PST)
Received: by wproxy.gmail.com with SMTP id i6so412612wra for <[e-mail]>; Wed, 09 Nov 2005 13:29:28 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=O8VqVkyD+TettBItFi0L9REZtHdAnhSA4gvkA7k5iB1AylY+G2bftP1PYQP5b1Roixp0DjY04slZaBGuIpDuC7d9UeZosp+ZP1Zn7fW2kHMP4XeomdUBcNtTRgX5r/1K7mU0VhNbnKp4BCMSFRLAqfApashUjubiR0NW6JPPhYA=
Received: by 10.54.133.11 with SMTP id g11mr877011wrd; Wed, 09 Nov 2005 13:29:28 -0800 (PST)
Received: by 10.54.151.15 with HTTP; Wed, 9 Nov 2005 13:29:28 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 9 Nov 2005 13:29:28 -0800
From: Alia Atlas <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <[e-mail]> <[e-mail]>
X-ISI-4-43-8-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 jA9LTTM04565
Subject: Re: [rbridge] routing heirarchy discussion in draft-touch-trill-rbridge-prob-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 21:30:17 -0000
Status: RO
Content-Length: 2090

Could you send me a pointer to the ref on this work?  I'd be
interested in taking
a look.  Maybe we could come up with a more accurate statement - both
of what is possible and what improvements trill might be able to
provide.

Alia

On 11/9/05, Guillermo Ib??ez <[e-mail]> wrote:
>
>
> Alia Atlas wrote:
>
> >Sec 2.2 says:
> >
> >"The spanning tree protocol is inherently global to an entire layer 2
> >   subnet; there is no current way to contain, partition, or otherwise
> >   factor the protocol into a number of smaller, more stable subsets
> >   that interact as groups. Contrast this with Internet routing, which
> >   includes both intradomain and interdomain variants, split to provide
> >   exactly that containment and scalability within a domain while
> >   allowing domains to interact freely independent of what happens
> >   inside.  "
> >
> >
> >
> This statement is not completely true, as Multiple Spanning Tree
> Protocol allows the definition of regions
> where independent trees are contained and partitioned.
>
> >I think that one strength of rbridges is the potential for introducing
> >a level of heirarchy in the routing.  However, I believe this is confined
> >to IGP-like areas (intra-domain).  The idea of nesting inter-domain
> >heirarchy inside seems rather implausible.
> >
> >If we are considering routing areas, then it may also be interesting to
> >consider or at least discuss the topology constraints required in order
> >to support such.
> >
> >
> >
> Regarding introducing hierarchy, a second level of spanning trees
> (double L2 encapsulated as well inside a confined core region with
> multiple spanning trees,  each tree rooted at edge bridges) is also a
> way to introduce hierarchy and hence obtain scalability
> Guillermo
>
> >Alia
> >_______________________________________________
> >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 wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA9LOtM02832 for <[e-mail]>; Wed, 9 Nov 2005 13:24:55 -0800 (PST)
Received: by wproxy.gmail.com with SMTP id i6so411914wra for <[e-mail]>; Wed, 09 Nov 2005 13:24:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bgMuBGaHq7o4HtbMV4OaZHeu9NC6ybNLr5dXOIVlbDVhe4i66TahnmgMIzQPvWO1kdjaJFDVPD8RItYsShMS8VF9lS5q5r9oRinL7x9sJ6hDb7O6ebhg5L8L1buLxYZa+wW+TD412Tt/8uoBlwGr2zlKUme9dgX57x1l7RkUq00=
Received: by 10.54.104.2 with SMTP id b2mr897960wrc; Wed, 09 Nov 2005 13:24:54 -0800 (PST)
Received: by 10.54.151.15 with HTTP; Wed, 9 Nov 2005 13:24:54 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 9 Nov 2005 13:24:54 -0800
From: Alia Atlas <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <[e-mail]> <[e-mail]>
X-ISI-4-43-8-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 jA9LOtM02832
Subject: Re: [rbridge] Sec 2.3 in draft-touch-trill-rbridge-prob-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 21:25:56 -0000
Status: RO
Content-Length: 1761

On 11/9/05, Guillermo Ib??ez <[e-mail]> wrote:
>
>
> Alia Atlas wrote:
>
> >"It would be more useful for subnet configuration to be tolerant of
> >   such transients, e.g., supporting alternate, backup paths.
> >
> >   [QUESTION: is there more to say here?]
> >
> >   Contrast this to network layer intradomain and interdomain routing,
> >   both of which include provisions for backup paths. These backups
> >   allow routing to be more stable in the presence of transients, as
> >   well as to recover more "rapidly when the transient disappears. "
> >
> >I found the description here to be rather confusing.  Are you saying
> >that the possibility for the use of additional links permits easier
> >routing convergence?  Or are you suggesting that
> >alternate next-hops can be pre-computed and used on a failure - as is
> >described in the IP fast-reroute work in rtgwg?  I'd assume the
> >former.  If that's the case, then I think the language needs some
> >clarification.
> >
> >
> May be the terminology is confusing, but it is a must to obtain fast
> reconfiguration as required by rbridges.
> (I will be again advocate of RSTP as example, that includes alternate
> port role, able to be root port via different path to root bridge,  for
> faster reconfiguration.

What times do you define as fast reconfiguration?  If there's interest in
using alternates such as in IP FRR, that could help; it may also add some
complexity.

Alia

> >Alia
> >_______________________________________________
> >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 eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA9LIqM00695 for <[e-mail]>; Wed, 9 Nov 2005 13:18:52 -0800 (PST)
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E9DA72596C4 for <[e-mail]>; Wed,  9 Nov 2005 22:17:59 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32647-01 for <[e-mail]>; Wed,  9 Nov 2005 22:17:56 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DA7E62596AF for <[e-mail]>; Wed,  9 Nov 2005 22:17:55 +0100 (CET)
Date: Wed, 09 Nov 2005 13:07:58 -0800
From: Harald Tveit Alvestrand <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-ID: <F1840E5F11CBBE4A55A423F3@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <[e-mail] .marconi.com> <[e-mail]>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========037821590E18096A24BA=========="
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Comments to draft Touch-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 21:19:20 -0000
Status: RO
Content-Length: 1373

--==========037821590E18096A24BA==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline



--On 9. november 2005 10:46 -0800 Joe Touch <[e-mail]> wrote:

>> 	As far as whether or not we all agree on the meaning of the
>> word "campus" it is unlikely that we all completely agree on the
>> meaning of any word in any language.  Working on getting a common
>> agreement on the meaning of the current terminology is very likely
>> to be a more productive than picking a different term to disagree
>> on.
>
> Different groups have used it in different ways - I was asking how to
> proceed, given that. If we're all comfortable with "campus" meaning
> "group of cooperating rbridge devices", that's fine...

The classical way of finessing that problem is to have an early terminology =

section, saying "in this document, foo means bar - note that it is used for =

other concepts in other contexts".....

I like terminology sections.



--==========037821590E18096A24BA==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFDcmUvOMj+2+WY0F4RAnToAKD84UshbVoNGP32ELhxQa0FyUly/gCgyguG
U+d/QuUHFufeM7SbR3eopBQ=
=CJk2
-----END PGP SIGNATURE-----

--==========037821590E18096A24BA==========--



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 jA9KigM16968 for <[e-mail]>; Wed, 9 Nov 2005 12:44:43 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 970DC9DB15 for <[e-mail]>; Wed,  9 Nov 2005 21:44:32 +0100 (CET)
Received: from [163.117.203.188] (unknown [163.117.203.188]) by smtp01.uc3m.es (Postfix) with ESMTP id C0A3C9DA8F for <[e-mail]>; Wed,  9 Nov 2005 21:00:16 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 09 Nov 2005 21:00:13 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
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]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] routing heirarchy discussion in	draft-touch-trill-rbridge-prob-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 20:47:47 -0000
Status: RO
Content-Length: 1578

Alia Atlas wrote:

>Sec 2.2 says:
>
>"The spanning tree protocol is inherently global to an entire layer 2
>   subnet; there is no current way to contain, partition, or otherwise
>   factor the protocol into a number of smaller, more stable subsets
>   that interact as groups. Contrast this with Internet routing, which
>   includes both intradomain and interdomain variants, split to provide
>   exactly that containment and scalability within a domain while
>   allowing domains to interact freely independent of what happens
>   inside.  "
>
>  
>
This statement is not completely true, as Multiple Spanning Tree 
Protocol allows the definition of regions
where independent trees are contained and partitioned.

>I think that one strength of rbridges is the potential for introducing
>a level of heirarchy in the routing.  However, I believe this is confined
>to IGP-like areas (intra-domain).  The idea of nesting inter-domain
>heirarchy inside seems rather implausible.
>
>If we are considering routing areas, then it may also be interesting to
>consider or at least discuss the topology constraints required in order
>to support such.
>
>  
>
Regarding introducing hierarchy, a second level of spanning trees 
(double L2 encapsulated as well inside a confined core region with 
multiple spanning trees,  each tree rooted at edge bridges) is also a 
way to introduce hierarchy and hence obtain scalability
Guillermo

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


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA9KYIM13780 for <[e-mail]>; Wed, 9 Nov 2005 12:34:18 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jA9KYC6l005498 for <[e-mail]>; Wed, 9 Nov 2005 15:34:13 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA09995 for <[e-mail]>; Wed, 9 Nov 2005 15:34:12 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WCKHTDJ9>; Wed, 9 Nov 2005 18:34:11 -0200
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Wed, 9 Nov 2005 18:34:11 -0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-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 jA9KYIM13780
Subject: Re: [rbridge] Comments to draft Touch-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 20:35:19 -0000
Status: RO
Content-Length: 8627

Guillermo,

	Please see responses in line below...

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Wednesday, November 09, 2005 2:13 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Comments to draft Touch-00
--> 
--> 
--> Eric,
-->       I insert just a couple of comments to your comments.
--> Guillermo
--> 
--> Gray, Eric wrote:
--> 
--> >Guillermo/Joe,
--> >
--> >	I agree with Guillermo that the abstract - along with several other
--> >sections - describes RBridge solutions instead of the problems
addressed.
--> >I strongly suspect that many (if not most) of Guillermo's comments
would
--> >be addressed if the draft were targetted more toward describing
problems
--> >rather than the RBridge solution(s).
--> >
--> >	Questions about whether RSTP, self-rooted multiple spanning trees 
--> >and/or Shortest Path Bridging are also solutions (with or without
implied 
--> >preferences) should be a separate issue, document and discussion.
--> >
--> >	We have been using the term campus for some time now and I think it
--> >is clear that introducing a new term at this point is probably not a
good
--> >idea.  For one thing, we're defining terms like internal and external
as
--> >relative to a campus (and therefore, defining the term campus in the
same
--> >process).  If we assume that we were to define the terms internal and 
--> >external relative to some other term "X", then we come up with the same
--> >areas of potential confusion with a different term.  Do we need to go
--> >through that exercise just to demonstrate this?
--> >
--> >	However, it would help if we did not use clearly confusing wording
--> >(such as the phrase "this communication may traverse external devices, 
--> >but is still considered internal").  I think - for instance - that
we've
--> >beat the definitions of internal and external to the point that it
should
--> >be very clear what is internal and what is external (and, therefore,
what
--> >is internal is internal not external).  We have elastically defined the
--> >term "internal" to me between mutually participating RBridges and - as
a
--> >consequence - it does have an agreed topological meaning.
--> >
--> >  
--> >
--> May be I did not follow the terms discussion in detail, but it is very 
--> confusing to consider *internally* connected to RBridges that are
connected 
--> [physically] via standard bridges. As long as we are not considering a 
--> *RBridge core* scenario (RBridges interconnected directly between them),
I 
--> see the term internal [inadequate].
--> 

Some things are only confusing if we fail to accept them as given.  :-)

In previous discussions we discussed at great length how it is that the 
fact that two or more RBridges are 1) part of the same broadcast domain,
2) connected to each other by a link of some kind and 3) cooperating (as
in they are not configured to ignore each other) means that the "link"
connecting them is a "campus-internal" link.

We need to work with this as a definition, rather than try to invent new
terms and definitions - unless there is some reason why it absolutely does
not work - or we will be going in circles forever.

This is critical to any further discussion of the proposal.  Forwarding 
between RBrdiges over 'internal' links is based on shortest path - however
the frames might be forwarded on those links themselves - and that is a
basic element of the RBridge proposal.

Those links may be constructed using any arbitrary technology, as long as
they looks to RBridges at each end as a link.  That includes 802 spanning
trees, and Ethernet/802 pseudo wires for example.

-->
--> >	I agree with Joe that small changes can have big effects but I also
--> >agree with Guillermo that we need to at least briefly illustrate how
this
--> >can occur.  It would probably be sufficient to show how (possibly
faulty)
--> >bridge networks could result in many interface forwarding-state changes
--> >as a result of loss of a key bridge or link.  Alternatively, we could
just 
--> >add a reference to some place(s) where this is documented elsewhere. 
--> >
--> >	In the same sense that we hope to avoid configuration, we probably
--> >should not assume RBrdiges will be deployed in an idealistic
configuration 
--> >either.  In other words, we should describe what causes the problem
with 
--> >STP (or RSTP) with a view to how it might be fixed in design rather
than
--> >in deployment.
--> >
--> >	I agree with Guillermo that more information is required with repect
--> >to convergence time considerations or camparisons between STP/RSTP and
SPF
--> >routing.  I suspect that this might be related to the blurring of
intenal 
--> >and external described above.  The presence of bridges and other
devices 
--> >on links between RBridges (at least RBridges not deliberately
configured 
--> >to ignore each other) does not change the fact that these links are
campus-
--> >internal and - in fact - these components are also internal to the
campus.
--> >However, it might be fair to say that SPF convergence between directly 
--> >connected RBridges should be faster than STP convergence between
directly 
--> >connected bridges.
--> >  
--> >
--> The fair comparison would be with RSTP convergence, not with STP 
--> convergence. Remember that the current IEEE standard is RSTP. STP is
legacy.
--> 
--> >	Since an RBridge is - among other things - a VLAN aware bridge, I 
--> >do not agree that support for VLANs necessarily requires configuration.
--> >The fact that - from RBridge's perspective - a VLAN is simply an ID,
makes
--> >it possible, for example, for an RBridge to simply use the ID as part
of
--> >context it uses for learning, shortest path determination, spanning
tree
--> >setup, etc.  In this sense, it would be necessary to configure
information
--> >relative to specific VLAN IDs only if something other than simple
context
--> >is required (like authentication, ID-to-ID translation/mapping, etc.).
--> >  
--> >
--> If , as most common  example, per-port VLANs are used, it must be 
--> configured which ports belong to which VLANs. If VLAN ID learning is 
--> assumed, somebody (Bridge or host) must label the frames with the VLAN 
--> tag. This "somebody" must be instructed (configured) to label with such 
--> value for VLAN.

This is combining functions.  As I believe I indicated in response to Joe,
there are indeed devices that provide the ability to insert non-VLAN traffic
on a VLAN.  There are also devices with the ability to stack VLAN tags in a
similar fashion.  Interesting, but not particularly relevant.  Typical
bridges
are completely VLAN unaware and require no configuration to support VLANs.

It is certainly possible to make a bridge that is capable of consistently 
handling VLAN as context information for learning and filtering, but without
the ability to change (or insert) the VLAN ID in frames being forwarded.

In such a bridge, no configuration is required in order to make it work - 
any more than configuration is required to make bridge learning and
filtering
without VLAN context information work.

It is certainly possible to combine functionality that requires
configuration
with essential RBridge functionality.  However, since a goal is to allow for
RBridge deployment with configuration, it should be a non-goal to include
any
such functional combination as part of the basic RBridge design.

--> 
--> >	For IANA considerations change the first sentence to read:
--> >
--> >    "This document currently has no IANA considerations."
--> >
--> >and it will be correct until the situation changes (at 
--> which time, it
--> >should be changed as well).
--> >
--> >--
--> >Eric
--> >
--> >--> -----Original Message-----
--> >--> From: [e-mail] 
--> >--> [mailto:[e-mail]]On
--> >--> Behalf Of Guillermo Ib??ez
--> >--> Sent: Monday, November 07, 2005 7:23 AM
--> >--> To: Developing a hybrid router/bridge.
--> >--> Subject: [rbridge] Comments to draft Touch-00
--> >--> 
--> >--> 
--> >--> Joe,
--> >--> 
--> >-->       Please find attached commented draft. Comments are 
--> >--> indicated with GI>
--> >--> 
--> >--> Guillermo Ib??ez
--> >--> 
--> >_______________________________________________
--> >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 smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA9KVnM12770 for <[e-mail]>; Wed, 9 Nov 2005 12:31:49 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 16DEF9D935 for <[e-mail]>; Wed,  9 Nov 2005 21:31:43 +0100 (CET)
Received: from [163.117.203.188] (unknown [163.117.203.188]) by smtp01.uc3m.es (Postfix) with ESMTP id DC6319DB47 for <[e-mail]>; Wed,  9 Nov 2005 21:31:41 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 09 Nov 2005 21:31:41 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
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]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Comments to draft Touch-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 20:32:16 -0000
Status: RO
Content-Length: 11282

Although obvioully desirable, I see extremely difficult to make the 
problem statement in this case whithout pointing to the proposed solution.
This is reinforced by the fact that some potential challenges to the 
existing solution, like loioking for bigger network sizes, are excluded 
as requirements or design objectives. So we end specifying what we can 
already get with the proposed solution.
Guillermo

Gray, Eric wrote:

>Joe,
>
>	As the second document was not posted until this week, I have
>not had so much as a second to look at it. So naturally my comments
>in response to Guillermo's earlier comments are in reference to the
>first document.  I think it is innapproriate for you to expect, or 
>even imply that you expect, comments on your second document at this
>point.
>
>	It is generally an error in IETF people-to-people protocol to
>describe a problem in terms of any solution - least of all your own
>solution - as it looks too much like you're making up a problem that
>requires your solution.  Consequently, the document is very unlikely
>to make progress until it is no longer couched in terms of specific
>solution(s).
>
>	It might be easier to write it down that way, but it will not
>be easier to convince people to accept what is written.  :-)
>
>	As far as whether or not we all agree on the meaning of the 
>word "campus" it is unlikely that we all completely agree on the 
>meaning of any word in any language.  Working on getting a common
>agreement on the meaning of the current terminology is very likely
>to be a more productive than picking a different term to disagree
>on.
>
>	Please see additional comments below (prefixed with EG>)
>
>--> -----Original Message-----
>--> From: [e-mail] 
>--> [mailto:[e-mail]]On
>--> Behalf Of Joe Touch
>--> Sent: Tuesday, November 08, 2005 6:52 PM
>--> To: Developing a hybrid router/bridge.
>--> Subject: Re: [rbridge] Comments to draft Touch-00
>--> 
>--> 
>--> _______________________________________________
>--> rbridge mailing list
>--> [e-mail]
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> 
>
>Earlier, you wrote:
>
>
>Gray, Eric wrote:
>  
>
>>Guillermo/Joe,
>>
>>	I agree with Guillermo that the abstract - along with several other
>>sections - describes RBridge solutions instead of the problems addressed.
>>I strongly suspect that many (if not most) of Guillermo's comments would
>>be addressed if the draft were targetted more toward describing problems
>>rather than the RBridge solution(s).
>>    
>>
>
>I'm presuming this addresses the first doc; see below...
>
>  
>
>>	Questions about whether RSTP, self-rooted multiple spanning trees 
>>and/or Shortest Path Bridging are also solutions (with or without implied 
>>preferences) should be a separate issue, document and discussion.
>>    
>>
>
>Problem statements often cite or refer to current work that might solve
>the problem, as well as allude to the solution as in "something that
>solves this will work under the following conditions". That requires
>saying something about the possible solutions in that doc, but it
>doesn't define the solutions. It's just 'enough to identify them', as
>well as to indicate that existing solutions may not suffice.
>
>  
>
>>	We have been using the term campus for some time now and I think it
>>is clear that introducing a new term at this point is probably not a good
>>idea.
>>    
>>
>
>The issue is whether it means the same thing to all of us. Does it?
>
>  
>
>>For one thing, we're defining terms like internal and external as
>>relative to a campus (and therefore, defining the term campus in the same
>>process).  If we assume that we were to define the terms internal and 
>>external relative to some other term "X", then we come up with the same
>>areas of potential confusion with a different term.  Do we need to go
>>through that exercise just to demonstrate this?
>>
>>	However, it would help if we did not use clearly confusing wording
>>(such as the phrase "this communication may traverse external devices, 
>>but is still considered internal").
>>    
>>
>
>I came up with an explanation of that that's visual in the second doc. I
>can include that in the first, but that strays into 'describing the
>solution' more.
>
>  
>
>>I think - for instance - that we've
>>beat the definitions of internal and external to the point that it should
>>be very clear what is internal and what is external (and, therefore, what
>>is internal is internal not external).
>>    
>>
>
>To us; these docs are not for us ;-) We need to explain this so a newbie
>to TRILL can understand.
>
>EG>
>EG> Yes, and using confusing phraseology does not help either for us,
>EG> or for them.
>EG>
>
>  
>
>>We have elastically defined the
>>term "internal" to me between mutually participating RBridges and - as a
>>consequence - it does have an agreed topological meaning.
>>
>>	I agree with Joe that small changes can have big effects but I also
>>agree with Guillermo that we need to at least briefly illustrate how this
>>can occur.  It would probably be sufficient to show how (possibly faulty)
>>bridge networks could result in many interface forwarding-state changes
>>as a result of loss of a key bridge or link.  Alternatively, we could just
>>    
>>
>
>  
>
>>add a reference to some place(s) where this is documented elsewhere. 
>>    
>>
>
>Yes - if someone has a picture, please send it; if not, a ref would be
>fantastic.
>
>EG>
>EG>
>EG> Yes, no doubt it would. However, you're the one making the statement
>EG> - therefore it is reasonable for everyone to assume you had a basis 
>EG> for making it.  My point in saying that a reference or example would
>EG> help is to prod you to do so.
>EG> 
>EG> Please do not make statements and expect me to prove them.  I already
>EG> have a job...
>EG>
>EG>
>
>  
>
>>	In the same sense that we hope to avoid configuration, we probably
>>should not assume RBrdiges will be deployed in an idealistic configuration
>>    
>>
>
>  
>
>>either.  In other words, we should describe what causes the problem with 
>>STP (or RSTP) with a view to how it might be fixed in design rather than
>>in deployment.
>>
>>	I agree with Guillermo that more information is required with repect
>>to convergence time considerations or camparisons between STP/RSTP and SPF
>>routing.  I suspect that this might be related to the blurring of intenal 
>>and external described above.  The presence of bridges and other devices 
>>on links between RBridges (at least RBridges not deliberately configured 
>>to ignore each other) does not change the fact that these links are
>>    
>>
>campus-
>  
>
>>internal and - in fact - these components are also internal to the campus.
>>However, it might be fair to say that SPF convergence between directly 
>>connected RBridges should be faster than STP convergence between directly 
>>connected bridges.
>>    
>>
>
>This is addressed in the second doc; I had hoped to avoid that level of
>discussion in the first.
>
>EG>
>EG>
>EG> It is not clear that we agree on the purpose for a problem statement
>EG> at all.  This is not a detail; you made the statement that convergence
>EG> would be faster, but you've not made it clear under what circumstances
>EG> this would be true.  In complete fairness, Guillermo has certainly made
>EG> the point that it is not true in all circumstances and it is equally 
>EG> fair to expect the document to address these limitations.
>EG>
>EG> This is a requirement of a problem statement unless the purpose of the
>EG> problem statement is just to be an excuse for moving on to a specific 
>EG> solution.  If a problem statement is intended to be a description of a
>EG> specific problem we want to solve, it must be put in a specific context.
>EG> 
>EG>
>
>  
>
>>	Since an RBridge is - among other things - a VLAN aware bridge, I 
>>do not agree that support for VLANs necessarily requires configuration.
>>    
>>
>
>How do you know which traffic is on which VLAN, i.e., if it arrives at
>the rbridge and isn't VLAN-tagged yet? (maybe I need to brush up on how
>VLANs work, but I thought you needed to tag ports somewhere).
>
>EG>
>EG>
>EG> Strictly speaking of RBridges as an extension of bridge functionality,
>EG> bridges are not (properly, at least) used to transfer traffic from one
>EG> VLAN to another.  This should be true of insertion of traffic onto a
>EG> specific VLAN (effectively transferring from the default VLAN to one
>EG> that has a specific - non-zero - VLAN ID).  It could also be stretched 
>EG> to include changing the VLAN ID for local scope reasons - but this is
>EG> something that is commonly done (and requires configuration).
>EG>
>EG> Transferring traffic from one VLAN to another is (properly) a function
>EG> of routing and it is not much of a stretch to say that this applies to
>EG> initial insertion onto a non-default VLAN.
>EG>
>EG> In any case, for bridges which are currently VLAN unaware, there is
>EG> no need to configure VLAN information.  It is certainly possible to
>EG> make RBridges VLAN aware and _only_ require configuration when VLAN
>EG> context (IDs) changes in transfer across an RBridge.
>EG>
>EG> As far as I know, the goal is to allow configuration free RBridges.
>EG> 
>EG>
>
>  
>
>>The fact that - from RBridge's perspective - a VLAN is simply an ID, makes
>>it possible, for example, for an RBridge to simply use the ID as part of
>>context it uses for learning, shortest path determination, spanning tree
>>setup, etc.  In this sense, it would be necessary to configure information
>>relative to specific VLAN IDs only if something other than simple context
>>is required (like authentication, ID-to-ID translation/mapping, etc.).
>>
>>	For IANA considerations change the first sentence to read:
>>
>>    "This document currently has no IANA considerations."
>>
>>and it will be correct until the situation changes (at which time, it
>>should be changed as well).
>>    
>>
>
>P&AS should not have IANA considerations unless the problem is itself
>with IANA-based information. That's not the case here - there's no
>IANA-centric issue. Architectures that address the problem (such as
>rbridges) may have IANA considerations, but that's not relevant to the
>P&AS doc.
>
>Arch docs should have an IANA consideration if any variants of instances
>of the architecture would have new protocol/port/etc numbers. So far,
>the arch doc indicates that this might be the case for rbridges.
>
>EG>
>EG> Agreed.
>EG>
>
>Joe
>
>  
>
>>--> -----Original Message-----
>>--> From: [e-mail] 
>>--> [mailto:[e-mail]]On
>>--> Behalf Of Guillermo Ib??ez
>>--> Sent: Monday, November 07, 2005 7:23 AM
>>--> To: Developing a hybrid router/bridge.
>>--> Subject: [rbridge] Comments to draft Touch-00
>>--> 
>>--> 
>>--> Joe,
>>--> 
>>-->       Please find attached commented draft. Comments are 
>>--> indicated with GI>
>>--> 
>>--> Guillermo Ib??ez
>>--> 
>>_______________________________________________
>>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 smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA9KOiM04951 for <[e-mail]>; Wed, 9 Nov 2005 12:24:44 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 094C79E109 for <[e-mail]>; Wed,  9 Nov 2005 21:24:38 +0100 (CET)
Received: from [163.117.203.188] (unknown [163.117.203.188]) by smtp01.uc3m.es (Postfix) with ESMTP id 9BD8B9D88D for <[e-mail]>; Wed,  9 Nov 2005 21:24:36 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 09 Nov 2005 21:24:36 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Comments to draft Touch-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 20:25:12 -0000
Status: RO
Content-Length: 13869

Just a few comments


Joe Touch wrote:

>Gray, Eric wrote:
>  
>
>>Joe,
>>
>>	As the second document was not posted until this week, I have
>>not had so much as a second to look at it. So naturally my comments
>>in response to Guillermo's earlier comments are in reference to the
>>first document.  I think it is innapproriate for you to expect, or 
>>even imply that you expect, comments on your second document at this
>>point.
>>    
>>
>
>I don't expect it; I asked for clarification (the mails refer to
>touch-00, not touch-prob-00), and tried to point out where issues were
>covered in the other doc for that reason.
>
>  
>
>>	It is generally an error in IETF people-to-people protocol to
>>describe a problem in terms of any solution - least of all your own
>>solution - as it looks too much like you're making up a problem that
>>requires your solution.  Consequently, the document is very unlikely
>>to make progress until it is no longer couched in terms of specific
>>solution(s).
>>    
>>
>
>The problem is already defined without reference to a solution (section
>2), with the sole exception of using the name (rbridges) in the final
>section on issues not solved. That can easily be remedied by replacing
>'rbridge' with 'the desired solution'.
>
>The 'desired properties' and 'applicability' are discussed in terms of a
>solution - I thought that was more typical than not. Is there a way to
>avoid that in this section of the doc, except by saying "anything that
>solves the problem is fine", and if so is that what is preferred?
>
>  
>
>>	It might be easier to write it down that way, but it will not
>>be easier to convince people to accept what is written.  :-)
>>    
>>
>?
>  
>
>>	As far as whether or not we all agree on the meaning of the 
>>word "campus" it is unlikely that we all completely agree on the 
>>meaning of any word in any language.  Working on getting a common
>>agreement on the meaning of the current terminology is very likely
>>to be a more productive than picking a different term to disagree
>>on.
>>    
>>
>
>Different groups have used it in different ways - I was asking how to
>proceed, given that. If we're all comfortable with "campus" meaning
>"group of cooperating rbridge devices", that's fine...
>
>  
>
>>	Please see additional comments below (prefixed with EG>)
>>
>>--> -----Original Message-----
>>--> From: [e-mail] 
>>--> [mailto:[e-mail]]On
>>--> Behalf Of Joe Touch
>>--> Sent: Tuesday, November 08, 2005 6:52 PM
>>--> To: Developing a hybrid router/bridge.
>>--> Subject: Re: [rbridge] Comments to draft Touch-00
>>--> 
>>--> 
>>--> _______________________________________________
>>--> rbridge mailing list
>>--> [e-mail]
>>--> http://www.postel.org/mailman/listinfo/rbridge
>>--> 
>>
>>Earlier, you wrote:
>>
>>
>>Gray, Eric wrote:
>>    
>>
>>>Guillermo/Joe,
>>>
>>>	I agree with Guillermo that the abstract - along with several other
>>>sections - describes RBridge solutions instead of the problems addressed.
>>>I strongly suspect that many (if not most) of Guillermo's comments would
>>>be addressed if the draft were targetted more toward describing problems
>>>rather than the RBridge solution(s).
>>>      
>>>
>>I'm presuming this addresses the first doc; see below...
>>
>>    
>>
>>>	Questions about whether RSTP, self-rooted multiple spanning trees 
>>>and/or Shortest Path Bridging are also solutions (with or without implied 
>>>preferences) should be a separate issue, document and discussion.
>>>      
>>>
>>Problem statements often cite or refer to current work that might solve
>>the problem, as well as allude to the solution as in "something that
>>solves this will work under the following conditions". That requires
>>saying something about the possible solutions in that doc, but it
>>doesn't define the solutions. It's just 'enough to identify them', as
>>well as to indicate that existing solutions may not suffice.
>>
>>    
>>
>>>	We have been using the term campus for some time now and I think it
>>>is clear that introducing a new term at this point is probably not a good
>>>idea.
>>>      
>>>
>>The issue is whether it means the same thing to all of us. Does it?
>>
>>    
>>
>>>For one thing, we're defining terms like internal and external as
>>>relative to a campus (and therefore, defining the term campus in the same
>>>process).  If we assume that we were to define the terms internal and 
>>>external relative to some other term "X", then we come up with the same
>>>areas of potential confusion with a different term.  Do we need to go
>>>through that exercise just to demonstrate this?
>>>
>>>	However, it would help if we did not use clearly confusing wording
>>>(such as the phrase "this communication may traverse external devices, 
>>>but is still considered internal").
>>>      
>>>
>>I came up with an explanation of that that's visual in the second doc. I
>>can include that in the first, but that strays into 'describing the
>>solution' more.
>>
>>    
>>
>>>I think - for instance - that we've
>>>beat the definitions of internal and external to the point that it should
>>>be very clear what is internal and what is external (and, therefore, what
>>>is internal is internal not external).
>>>      
>>>
>>To us; these docs are not for us ;-) We need to explain this so a newbie
>>to TRILL can understand.
>>
>>EG>
>>EG> Yes, and using confusing phraseology does not help either for us,
>>EG> or for them.
>>EG>
>>    
>>
>
>We all agree on that. If it's so clear, then let's agree on a definition
>and put it down in the doc.
>
>  
>
>>>We have elastically defined the
>>>term "internal" to me between mutually participating RBridges and - as a
>>>consequence - it does have an agreed topological meaning.
>>>
>>>	I agree with Joe that small changes can have big effects but I also
>>>agree with Guillermo that we need to at least briefly illustrate how this
>>>can occur.  It would probably be sufficient to show how (possibly faulty)
>>>bridge networks could result in many interface forwarding-state changes
>>>as a result of loss of a key bridge or link.  Alternatively, we could just
>>>      
>>>
>>>add a reference to some place(s) where this is documented elsewhere. 
>>>      
>>>
>>Yes - if someone has a picture, please send it; if not, a ref would be
>>fantastic.
>>
>>EG>
>>EG>
>>EG> Yes, no doubt it would. However, you're the one making the statement
>>EG> - therefore it is reasonable for everyone to assume you had a basis 
>>EG> for making it.  My point in saying that a reference or example would
>>EG> help is to prod you to do so.
>>EG> 
>>EG> Please do not make statements and expect me to prove them.  I already
>>EG> have a job...
>>EG>
>>EG>
>>    
>>
>
>I'm editor of the doc, not sole author. I've asked for assistance where
>needed. For the document, I included statements made on the list - not
>my own ideas per se - and asked for backup or clarification. I'd be just
>as happy to delete the statement, since it wasn't my idea I was asserting.
>
>  
>
>>>	In the same sense that we hope to avoid configuration, we probably
>>>should not assume RBrdiges will be deployed in an idealistic configuration
>>>      
>>>
>>>either.  In other words, we should describe what causes the problem with 
>>>STP (or RSTP) with a view to how it might be fixed in design rather than
>>>in deployment.
>>>
>>>	I agree with Guillermo that more information is required with repect
>>>to convergence time considerations or camparisons between STP/RSTP and SPF
>>>routing.  I suspect that this might be related to the blurring of intenal 
>>>and external described above.  The presence of bridges and other devices 
>>>on links between RBridges (at least RBridges not deliberately configured 
>>>to ignore each other) does not change the fact that these links are
>>>      
>>>
>>campus-
>>    
>>
>>>internal and - in fact - these components are also internal to the campus.
>>>However, it might be fair to say that SPF convergence between directly 
>>>connected RBridges should be faster than STP convergence between directly 
>>>connected bridges.
>>>      
>>>
>>This is addressed in the second doc; I had hoped to avoid that level of
>>discussion in the first.
>>
>>EG>
>>EG>
>>EG> It is not clear that we agree on the purpose for a problem statement
>>EG> at all.  This is not a detail; you made the statement that convergence
>>EG> would be faster, but you've not made it clear under what circumstances
>>EG> this would be true.  In complete fairness, Guillermo has certainly made
>>EG> the point that it is not true in all circumstances and it is equally 
>>EG> fair to expect the document to address these limitations.
>>    
>>
>
>Agreed. The doc needs to discuss both possibilities and where each might
>arise - with citations for each case.
>
>However, don't expect me to provide citations for a summary of what many
>have raised on the list, sometimes as questions or propositions. T
>
>  
>
>>EG> This is a requirement of a problem statement unless the purpose of the
>>EG> problem statement is just to be an excuse for moving on to a specific 
>>EG> solution.  If a problem statement is intended to be a description of a
>>EG> specific problem we want to solve, it must be put in a specific context.
>>EG> 
>>EG>
>>
>>    
>>
>>>	Since an RBridge is - among other things - a VLAN aware bridge, I 
>>>do not agree that support for VLANs necessarily requires configuration.
>>>      
>>>
>>How do you know which traffic is on which VLAN, i.e., if it arrives at
>>the rbridge and isn't VLAN-tagged yet? (maybe I need to brush up on how
>>VLANs work, but I thought you needed to tag ports somewhere).
>>
>>EG>
>>EG>
>>EG> Strictly speaking of RBridges as an extension of bridge functionality,
>>EG> bridges are not (properly, at least) used to transfer traffic from one
>>EG> VLAN to another.  This should be true of insertion of traffic onto a
>>EG> specific VLAN (effectively transferring from the default VLAN to one
>>EG> that has a specific - non-zero - VLAN ID).  It could also be stretched 
>>EG> to include changing the VLAN ID for local scope reasons - but this is
>>EG> something that is commonly done (and requires configuration).
>>EG>
>>EG> Transferring traffic from one VLAN to another is (properly) a function
>>EG> of routing and it is not much of a stretch to say that this applies to
>>EG> initial insertion onto a non-default VLAN.
>>EG>
>>EG> In any case, for bridges which are currently VLAN unaware, there is
>>EG> no need to configure VLAN information. 
>>    
>>
>
>Agreed - that needs to be added.
>
>  
>
>>EG> It is certainly possible to
>>EG> make RBridges VLAN aware and _only_ require configuration when VLAN
>>EG> context (IDs) changes in transfer across an RBridge.
>>    
>>
>
>Yes, but we also were talking about per-VLAN tables. I wasn't sure that
>didn't require some configuration of the ports.
>  
>
I think VLANs will normally reire configuration of the ports. It seems 
that assuming they will not require configuration means they will be 
configured at the bridges and that nodes are always connected to a 
bridge that tags the frames (or the nodes themselves tag the frames).

>  
>
>>EG> As far as I know, the goal is to allow configuration free RBridges.
>>EG> 
>>EG>
>>    
>>
>
>Yes. If everyone is convinced that VLANs don't affect this, then the doc
>will be changed to reflect that.
>  
>
I think pure configuration free RBridges are not possible with VLANs. 
Somebody has to tell the networks what port belongs to what VLAN.
Guillermo

>  
>
>>>The fact that - from RBridge's perspective - a VLAN is simply an ID, makes
>>>it possible, for example, for an RBridge to simply use the ID as part of
>>>context it uses for learning, shortest path determination, spanning tree
>>>setup, etc.  In this sense, it would be necessary to configure information
>>>relative to specific VLAN IDs only if something other than simple context
>>>is required (like authentication, ID-to-ID translation/mapping, etc.).
>>>
>>>	For IANA considerations change the first sentence to read:
>>>
>>>    "This document currently has no IANA considerations."
>>>
>>>and it will be correct until the situation changes (at which time, it
>>>should be changed as well).
>>>      
>>>
>>P&AS should not have IANA considerations unless the problem is itself
>>with IANA-based information. That's not the case here - there's no
>>IANA-centric issue. Architectures that address the problem (such as
>>rbridges) may have IANA considerations, but that's not relevant to the
>>P&AS doc.
>>
>>Arch docs should have an IANA consideration if any variants of instances
>>of the architecture would have new protocol/port/etc numbers. So far,
>>the arch doc indicates that this might be the case for rbridges.
>>
>>EG>
>>EG> Agreed.
>>EG>
>>
>>Joe
>>
>>    
>>
>>>--> -----Original Message-----
>>>--> From: [e-mail] 
>>>--> [mailto:[e-mail]]On
>>>--> Behalf Of Guillermo Ib??ez
>>>--> Sent: Monday, November 07, 2005 7:23 AM
>>>--> To: Developing a hybrid router/bridge.
>>>--> Subject: [rbridge] Comments to draft Touch-00
>>>--> 
>>>--> 
>>>--> Joe,
>>>--> 
>>>-->       Please find attached commented draft. Comments are 
>>>--> indicated with GI>
>>>--> 
>>>--> Guillermo Ib??ez
>>>--> 
>>>_______________________________________________
>>>rbridge mailing list
>>>[e-mail]
>>>http://www.postel.org/mailman/listinfo/rbridge
>>>      
>>>
>>_______________________________________________
>>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 smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA9KEWM00913 for <[e-mail]>; Wed, 9 Nov 2005 12:14:32 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A20519E109 for <[e-mail]>; Wed,  9 Nov 2005 21:14:26 +0100 (CET)
Received: from [163.117.203.188] (unknown [163.117.203.188]) by smtp01.uc3m.es (Postfix) with ESMTP id D190F9E0B5 for <[e-mail]>; Wed,  9 Nov 2005 21:14:25 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 09 Nov 2005 21:14:25 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
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]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Sec 2.3 in draft-touch-trill-rbridge-prob-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 20:15:39 -0000
Status: RO
Content-Length: 1330

Alia Atlas wrote:

>"It would be more useful for subnet configuration to be tolerant of
>   such transients, e.g., supporting alternate, backup paths.
>
>   [QUESTION: is there more to say here?]
>
>   Contrast this to network layer intradomain and interdomain routing,
>   both of which include provisions for backup paths. These backups
>   allow routing to be more stable in the presence of transients, as
>   well as to recover more "rapidly when the transient disappears. "
>
>I found the description here to be rather confusing.  Are you saying
>that the possibility for the use of additional links permits easier
>routing convergence?  Or are you suggesting that
>alternate next-hops can be pre-computed and used on a failure - as is
>described in the IP fast-reroute work in rtgwg?  I'd assume the
>former.  If that's the case, then I think the language needs some
>clarification.
>  
>
May be the terminology is confusing, but it is a must to obtain fast 
reconfiguration as required by rbridges.
(I will be again advocate of RSTP as example, that includes alternate 
port role, able to be root port via different path to root bridge,  for 
faster reconfiguration.

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


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA9Ju2M23748 for <[e-mail]>; Wed, 9 Nov 2005 11:56:02 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jA9Jtu6l004585 for <[e-mail]>; Wed, 9 Nov 2005 14:55:56 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA03896 for <[e-mail]>; Wed, 9 Nov 2005 14:55:56 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WCKHTB5P>; Wed, 9 Nov 2005 17:55:55 -0200
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Wed, 9 Nov 2005 17:55:55 -0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Comments to draft Touch-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 19:57:24 -0000
Status: RO
Content-Length: 1755

Joe,

	When I made the coment that you're the one making the statement, I 
was referring to the fact that you're the one who put it in the document 
- therefore you're the one most likely to know where it came from.  While 
I believe you are correct, I am pretty sure you didn't get it from me.

	In terms of the definition of a campus as a collection of
cooperating
RBridges, this is not sufficiently inclusive.  A fuller definition includes
the infrastructure (links and intervening devices) over which the RBridges
are connected together so that they can cooperate.  When you include this
piece, I think we will all find that internal and external are much clearer
terms for further discussion.  If you do not include this in the definition,
then - at least - the intervening devices are trivialized (from the RBridge
perspective) to the point that the terms internal and external become fuzzy.

	As for word-smithing the "questionable" text relating to specific 
solution-oriented problem descriptions, I will be happy to propose specific
text changes when I have a bit more time.

	Certainly among the changes I would suggest would be a complete
over-
haul of the abstract - which is nothing if not a statement of the form "we
need to solve the problem outlined in this document using RBridge."

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]]On
--> Behalf Of Joe Touch
--> Sent: Wednesday, November 09, 2005 1:47 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Comments to draft Touch-00
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from [209.52.104.180] (pp104-180.bctel.ca [209.52.104.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA9IkiM02332; Wed, 9 Nov 2005 10:46:44 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 09 Nov 2005 10:46:42 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig72D0B40062D8552FE27855D2"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Comments to draft Touch-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 18:47:16 -0000
Status: RO
Content-Length: 13667

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig72D0B40062D8552FE27855D2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Gray, Eric wrote:
> Joe,
>=20
> 	As the second document was not posted until this week, I have
> not had so much as a second to look at it. So naturally my comments
> in response to Guillermo's earlier comments are in reference to the
> first document.  I think it is innapproriate for you to expect, or=20
> even imply that you expect, comments on your second document at this
> point.

I don't expect it; I asked for clarification (the mails refer to
touch-00, not touch-prob-00), and tried to point out where issues were
covered in the other doc for that reason.

> 	It is generally an error in IETF people-to-people protocol to
> describe a problem in terms of any solution - least of all your own
> solution - as it looks too much like you're making up a problem that
> requires your solution.  Consequently, the document is very unlikely
> to make progress until it is no longer couched in terms of specific
> solution(s).

The problem is already defined without reference to a solution (section
2), with the sole exception of using the name (rbridges) in the final
section on issues not solved. That can easily be remedied by replacing
'rbridge' with 'the desired solution'.

The 'desired properties' and 'applicability' are discussed in terms of a
solution - I thought that was more typical than not. Is there a way to
avoid that in this section of the doc, except by saying "anything that
solves the problem is fine", and if so is that what is preferred?

> 	It might be easier to write it down that way, but it will not
> be easier to convince people to accept what is written.  :-)
?
> 	As far as whether or not we all agree on the meaning of the=20
> word "campus" it is unlikely that we all completely agree on the=20
> meaning of any word in any language.  Working on getting a common
> agreement on the meaning of the current terminology is very likely
> to be a more productive than picking a different term to disagree
> on.

Different groups have used it in different ways - I was asking how to
proceed, given that. If we're all comfortable with "campus" meaning
"group of cooperating rbridge devices", that's fine...

> 	Please see additional comments below (prefixed with EG>)
>=20
> --> -----Original Message-----
> --> From: [e-mail]=20
> --> [mailto:[e-mail]]On
> --> Behalf Of Joe Touch
> --> Sent: Tuesday, November 08, 2005 6:52 PM
> --> To: Developing a hybrid router/bridge.
> --> Subject: Re: [rbridge] Comments to draft Touch-00
> -->=20
> -->=20
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://www.postel.org/mailman/listinfo/rbridge
> -->=20
>=20
> Earlier, you wrote:
>=20
>=20
> Gray, Eric wrote:
>> Guillermo/Joe,
>>
>> 	I agree with Guillermo that the abstract - along with several other
>> sections - describes RBridge solutions instead of the problems address=
ed.
>> I strongly suspect that many (if not most) of Guillermo's comments wou=
ld
>> be addressed if the draft were targetted more toward describing proble=
ms
>> rather than the RBridge solution(s).
>=20
> I'm presuming this addresses the first doc; see below...
>=20
>> 	Questions about whether RSTP, self-rooted multiple spanning trees=20
>> and/or Shortest Path Bridging are also solutions (with or without impl=
ied=20
>> preferences) should be a separate issue, document and discussion.
>=20
> Problem statements often cite or refer to current work that might solve=

> the problem, as well as allude to the solution as in "something that
> solves this will work under the following conditions". That requires
> saying something about the possible solutions in that doc, but it
> doesn't define the solutions. It's just 'enough to identify them', as
> well as to indicate that existing solutions may not suffice.
>=20
>> 	We have been using the term campus for some time now and I think it
>> is clear that introducing a new term at this point is probably not a g=
ood
>> idea.
>=20
> The issue is whether it means the same thing to all of us. Does it?
>=20
>> For one thing, we're defining terms like internal and external as
>> relative to a campus (and therefore, defining the term campus in the s=
ame
>> process).  If we assume that we were to define the terms internal and =

>> external relative to some other term "X", then we come up with the sam=
e
>> areas of potential confusion with a different term.  Do we need to go
>> through that exercise just to demonstrate this?
>>
>> 	However, it would help if we did not use clearly confusing wording
>> (such as the phrase "this communication may traverse external devices,=
=20
>> but is still considered internal").
>=20
> I came up with an explanation of that that's visual in the second doc. =
I
> can include that in the first, but that strays into 'describing the
> solution' more.
>=20
>> I think - for instance - that we've
>> beat the definitions of internal and external to the point that it sho=
uld
>> be very clear what is internal and what is external (and, therefore, w=
hat
>> is internal is internal not external).
>=20
> To us; these docs are not for us ;-) We need to explain this so a newbi=
e
> to TRILL can understand.
>=20
> EG>
> EG> Yes, and using confusing phraseology does not help either for us,
> EG> or for them.
> EG>

We all agree on that. If it's so clear, then let's agree on a definition
and put it down in the doc.

>> We have elastically defined the
>> term "internal" to me between mutually participating RBridges and - as=
 a
>> consequence - it does have an agreed topological meaning.
>>
>> 	I agree with Joe that small changes can have big effects but I also
>> agree with Guillermo that we need to at least briefly illustrate how t=
his
>> can occur.  It would probably be sufficient to show how (possibly faul=
ty)
>> bridge networks could result in many interface forwarding-state change=
s
>> as a result of loss of a key bridge or link.  Alternatively, we could =
just
>=20
>> add a reference to some place(s) where this is documented elsewhere.=20
>=20
> Yes - if someone has a picture, please send it; if not, a ref would be
> fantastic.
>=20
> EG>
> EG>
> EG> Yes, no doubt it would. However, you're the one making the statemen=
t
> EG> - therefore it is reasonable for everyone to assume you had a basis=
=20
> EG> for making it.  My point in saying that a reference or example woul=
d
> EG> help is to prod you to do so.
> EG>=20
> EG> Please do not make statements and expect me to prove them.  I alrea=
dy
> EG> have a job...
> EG>
> EG>

I'm editor of the doc, not sole author. I've asked for assistance where
needed. For the document, I included statements made on the list - not
my own ideas per se - and asked for backup or clarification. I'd be just
as happy to delete the statement, since it wasn't my idea I was asserting=
=2E

>> 	In the same sense that we hope to avoid configuration, we probably
>> should not assume RBrdiges will be deployed in an idealistic configura=
tion
>=20
>> either.  In other words, we should describe what causes the problem wi=
th=20
>> STP (or RSTP) with a view to how it might be fixed in design rather th=
an
>> in deployment.
>>
>> 	I agree with Guillermo that more information is required with repect
>> to convergence time considerations or camparisons between STP/RSTP and=
 SPF
>> routing.  I suspect that this might be related to the blurring of inte=
nal=20
>> and external described above.  The presence of bridges and other devic=
es=20
>> on links between RBridges (at least RBridges not deliberately configur=
ed=20
>> to ignore each other) does not change the fact that these links are
> campus-
>> internal and - in fact - these components are also internal to the cam=
pus.
>> However, it might be fair to say that SPF convergence between directly=
=20
>> connected RBridges should be faster than STP convergence between direc=
tly=20
>> connected bridges.
>=20
> This is addressed in the second doc; I had hoped to avoid that level of=

> discussion in the first.
>=20
> EG>
> EG>
> EG> It is not clear that we agree on the purpose for a problem statemen=
t
> EG> at all.  This is not a detail; you made the statement that converge=
nce
> EG> would be faster, but you've not made it clear under what circumstan=
ces
> EG> this would be true.  In complete fairness, Guillermo has certainly =
made
> EG> the point that it is not true in all circumstances and it is equall=
y=20
> EG> fair to expect the document to address these limitations.

Agreed. The doc needs to discuss both possibilities and where each might
arise - with citations for each case.

However, don't expect me to provide citations for a summary of what many
have raised on the list, sometimes as questions or propositions. T

> EG> This is a requirement of a problem statement unless the purpose of =
the
> EG> problem statement is just to be an excuse for moving on to a specif=
ic=20
> EG> solution.  If a problem statement is intended to be a description o=
f a
> EG> specific problem we want to solve, it must be put in a specific con=
text.
> EG>=20
> EG>
>=20
>> 	Since an RBridge is - among other things - a VLAN aware bridge, I=20
>> do not agree that support for VLANs necessarily requires configuration=
=2E
>=20
> How do you know which traffic is on which VLAN, i.e., if it arrives at
> the rbridge and isn't VLAN-tagged yet? (maybe I need to brush up on how=

> VLANs work, but I thought you needed to tag ports somewhere).
>=20
> EG>
> EG>
> EG> Strictly speaking of RBridges as an extension of bridge functionali=
ty,
> EG> bridges are not (properly, at least) used to transfer traffic from =
one
> EG> VLAN to another.  This should be true of insertion of traffic onto =
a
> EG> specific VLAN (effectively transferring from the default VLAN to on=
e
> EG> that has a specific - non-zero - VLAN ID).  It could also be stretc=
hed=20
> EG> to include changing the VLAN ID for local scope reasons - but this =
is
> EG> something that is commonly done (and requires configuration).
> EG>
> EG> Transferring traffic from one VLAN to another is (properly) a funct=
ion
> EG> of routing and it is not much of a stretch to say that this applies=
 to
> EG> initial insertion onto a non-default VLAN.
> EG>
> EG> In any case, for bridges which are currently VLAN unaware, there is=

> EG> no need to configure VLAN information.=20

Agreed - that needs to be added.

> EG> It is certainly possible to
> EG> make RBridges VLAN aware and _only_ require configuration when VLAN=

> EG> context (IDs) changes in transfer across an RBridge.

Yes, but we also were talking about per-VLAN tables. I wasn't sure that
didn't require some configuration of the ports.

> EG> As far as I know, the goal is to allow configuration free RBridges.=

> EG>=20
> EG>

Yes. If everyone is convinced that VLANs don't affect this, then the doc
will be changed to reflect that.

>> The fact that - from RBridge's perspective - a VLAN is simply an ID, m=
akes
>> it possible, for example, for an RBridge to simply use the ID as part =
of
>> context it uses for learning, shortest path determination, spanning tr=
ee
>> setup, etc.  In this sense, it would be necessary to configure informa=
tion
>> relative to specific VLAN IDs only if something other than simple cont=
ext
>> is required (like authentication, ID-to-ID translation/mapping, etc.).=

>>
>> 	For IANA considerations change the first sentence to read:
>>
>>     "This document currently has no IANA considerations."
>>
>> and it will be correct until the situation changes (at which time, it
>> should be changed as well).
>=20
> P&AS should not have IANA considerations unless the problem is itself
> with IANA-based information. That's not the case here - there's no
> IANA-centric issue. Architectures that address the problem (such as
> rbridges) may have IANA considerations, but that's not relevant to the
> P&AS doc.
>=20
> Arch docs should have an IANA consideration if any variants of instance=
s
> of the architecture would have new protocol/port/etc numbers. So far,
> the arch doc indicates that this might be the case for rbridges.
>=20
> EG>
> EG> Agreed.
> EG>
>=20
> Joe
>=20
>> --> -----Original Message-----
>> --> From: [e-mail]=20
>> --> [mailto:[e-mail]]On
>> --> Behalf Of Guillermo Ib=E1=F1ez
>> --> Sent: Monday, November 07, 2005 7:23 AM
>> --> To: Developing a hybrid router/bridge.
>> --> Subject: [rbridge] Comments to draft Touch-00
>> -->=20
>> -->=20
>> --> Joe,
>> -->=20
>> -->       Please find attached commented draft. Comments are=20
>> --> indicated with GI>
>> -->=20
>> --> Guillermo Ib=E1=F1ez
>> -->=20
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://www.postel.org/mailman/listinfo/rbridge
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


--------------enig72D0B40062D8552FE27855D2
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.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDckQSE5f5cImnZrsRAmWWAKCIYVLQvc9ap7C7NNwX8B1p8E9D6gCgk6Qq
UJWhhrT6IUJDFd9pJpvsAIw=
=l622
-----END PGP SIGNATURE-----

--------------enig72D0B40062D8552FE27855D2--


Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA9ITUM26909 for <[e-mail]>; Wed, 9 Nov 2005 10:29:30 -0800 (PST)
Received: by wproxy.gmail.com with SMTP id i6so382706wra for <[e-mail]>; Wed, 09 Nov 2005 10:29:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=AYwK+W++FCHS5jrf0DtX0Bs9PushQNa9G+b/YekamRP6tM8Opgm3dAb1Ywt7qhNA+V8nqHnFq62e5R71lkj8ef/IBx1ix+DUi4FTgTLMtx6WGZRAsxBh3eaFzXT8eCQ+rQShcZB0hNU0/3goT81B9UYojwJiKIOEdy04nXdF0ps=
Received: by 10.54.146.11 with SMTP id t11mr488120wrd; Wed, 09 Nov 2005 10:29:29 -0800 (PST)
Received: by 10.54.151.15 with HTTP; Wed, 9 Nov 2005 10:29:29 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 9 Nov 2005 10:29:29 -0800
From: Alia Atlas <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
X-ISI-4-43-8-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 jA9ITUM26909
Subject: [rbridge] Sec 2.3 in draft-touch-trill-rbridge-prob-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 18:30:38 -0000
Status: RO
Content-Length: 859

"It would be more useful for subnet configuration to be tolerant of
   such transients, e.g., supporting alternate, backup paths.

   [QUESTION: is there more to say here?]

   Contrast this to network layer intradomain and interdomain routing,
   both of which include provisions for backup paths. These backups
   allow routing to be more stable in the presence of transients, as
   well as to recover more "rapidly when the transient disappears. "

I found the description here to be rather confusing.  Are you saying
that the possibility for the use of additional links permits easier
routing convergence?  Or are you suggesting that
alternate next-hops can be pre-computed and used on a failure - as is
described in the IP fast-reroute work in rtgwg?  I'd assume the
former.  If that's the case, then I think the language needs some
clarification.

Alia


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA9IOHM25373 for <[e-mail]>; Wed, 9 Nov 2005 10:24:18 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jA9IOC6l002268 for <[e-mail]>; Wed, 9 Nov 2005 13:24:12 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA20117 for <[e-mail]>; Wed, 9 Nov 2005 13:24:12 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WCKHS9CT>; Wed, 9 Nov 2005 16:24:11 -0200
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Wed, 9 Nov 2005 16:24:10 -0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Comments to draft Touch-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 18:25:13 -0000
Status: RO
Content-Length: 10342

Joe,

	As the second document was not posted until this week, I have
not had so much as a second to look at it. So naturally my comments
in response to Guillermo's earlier comments are in reference to the
first document.  I think it is innapproriate for you to expect, or 
even imply that you expect, comments on your second document at this
point.

	It is generally an error in IETF people-to-people protocol to
describe a problem in terms of any solution - least of all your own
solution - as it looks too much like you're making up a problem that
requires your solution.  Consequently, the document is very unlikely
to make progress until it is no longer couched in terms of specific
solution(s).

	It might be easier to write it down that way, but it will not
be easier to convince people to accept what is written.  :-)

	As far as whether or not we all agree on the meaning of the 
word "campus" it is unlikely that we all completely agree on the 
meaning of any word in any language.  Working on getting a common
agreement on the meaning of the current terminology is very likely
to be a more productive than picking a different term to disagree
on.

	Please see additional comments below (prefixed with EG>)

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]]On
--> Behalf Of Joe Touch
--> Sent: Tuesday, November 08, 2005 6:52 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Comments to draft Touch-00
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Earlier, you wrote:


Gray, Eric wrote:
> Guillermo/Joe,
> 
> 	I agree with Guillermo that the abstract - along with several other
> sections - describes RBridge solutions instead of the problems addressed.
> I strongly suspect that many (if not most) of Guillermo's comments would
> be addressed if the draft were targetted more toward describing problems
> rather than the RBridge solution(s).

I'm presuming this addresses the first doc; see below...

> 	Questions about whether RSTP, self-rooted multiple spanning trees 
> and/or Shortest Path Bridging are also solutions (with or without implied 
> preferences) should be a separate issue, document and discussion.

Problem statements often cite or refer to current work that might solve
the problem, as well as allude to the solution as in "something that
solves this will work under the following conditions". That requires
saying something about the possible solutions in that doc, but it
doesn't define the solutions. It's just 'enough to identify them', as
well as to indicate that existing solutions may not suffice.

> 	We have been using the term campus for some time now and I think it
> is clear that introducing a new term at this point is probably not a good
> idea.

The issue is whether it means the same thing to all of us. Does it?

> For one thing, we're defining terms like internal and external as
> relative to a campus (and therefore, defining the term campus in the same
> process).  If we assume that we were to define the terms internal and 
> external relative to some other term "X", then we come up with the same
> areas of potential confusion with a different term.  Do we need to go
> through that exercise just to demonstrate this?
> 
> 	However, it would help if we did not use clearly confusing wording
> (such as the phrase "this communication may traverse external devices, 
> but is still considered internal").

I came up with an explanation of that that's visual in the second doc. I
can include that in the first, but that strays into 'describing the
solution' more.

> I think - for instance - that we've
> beat the definitions of internal and external to the point that it should
> be very clear what is internal and what is external (and, therefore, what
> is internal is internal not external).

To us; these docs are not for us ;-) We need to explain this so a newbie
to TRILL can understand.

EG>
EG> Yes, and using confusing phraseology does not help either for us,
EG> or for them.
EG>

> We have elastically defined the
> term "internal" to me between mutually participating RBridges and - as a
> consequence - it does have an agreed topological meaning.
> 
> 	I agree with Joe that small changes can have big effects but I also
> agree with Guillermo that we need to at least briefly illustrate how this
> can occur.  It would probably be sufficient to show how (possibly faulty)
> bridge networks could result in many interface forwarding-state changes
> as a result of loss of a key bridge or link.  Alternatively, we could just

> add a reference to some place(s) where this is documented elsewhere. 

Yes - if someone has a picture, please send it; if not, a ref would be
fantastic.

EG>
EG>
EG> Yes, no doubt it would. However, you're the one making the statement
EG> - therefore it is reasonable for everyone to assume you had a basis 
EG> for making it.  My point in saying that a reference or example would
EG> help is to prod you to do so.
EG> 
EG> Please do not make statements and expect me to prove them.  I already
EG> have a job...
EG>
EG>

> 	In the same sense that we hope to avoid configuration, we probably
> should not assume RBrdiges will be deployed in an idealistic configuration

> either.  In other words, we should describe what causes the problem with 
> STP (or RSTP) with a view to how it might be fixed in design rather than
> in deployment.
> 
> 	I agree with Guillermo that more information is required with repect
> to convergence time considerations or camparisons between STP/RSTP and SPF
> routing.  I suspect that this might be related to the blurring of intenal 
> and external described above.  The presence of bridges and other devices 
> on links between RBridges (at least RBridges not deliberately configured 
> to ignore each other) does not change the fact that these links are
campus-
> internal and - in fact - these components are also internal to the campus.
> However, it might be fair to say that SPF convergence between directly 
> connected RBridges should be faster than STP convergence between directly 
> connected bridges.

This is addressed in the second doc; I had hoped to avoid that level of
discussion in the first.

EG>
EG>
EG> It is not clear that we agree on the purpose for a problem statement
EG> at all.  This is not a detail; you made the statement that convergence
EG> would be faster, but you've not made it clear under what circumstances
EG> this would be true.  In complete fairness, Guillermo has certainly made
EG> the point that it is not true in all circumstances and it is equally 
EG> fair to expect the document to address these limitations.
EG>
EG> This is a requirement of a problem statement unless the purpose of the
EG> problem statement is just to be an excuse for moving on to a specific 
EG> solution.  If a problem statement is intended to be a description of a
EG> specific problem we want to solve, it must be put in a specific context.
EG> 
EG>

> 	Since an RBridge is - among other things - a VLAN aware bridge, I 
> do not agree that support for VLANs necessarily requires configuration.

How do you know which traffic is on which VLAN, i.e., if it arrives at
the rbridge and isn't VLAN-tagged yet? (maybe I need to brush up on how
VLANs work, but I thought you needed to tag ports somewhere).

EG>
EG>
EG> Strictly speaking of RBridges as an extension of bridge functionality,
EG> bridges are not (properly, at least) used to transfer traffic from one
EG> VLAN to another.  This should be true of insertion of traffic onto a
EG> specific VLAN (effectively transferring from the default VLAN to one
EG> that has a specific - non-zero - VLAN ID).  It could also be stretched 
EG> to include changing the VLAN ID for local scope reasons - but this is
EG> something that is commonly done (and requires configuration).
EG>
EG> Transferring traffic from one VLAN to another is (properly) a function
EG> of routing and it is not much of a stretch to say that this applies to
EG> initial insertion onto a non-default VLAN.
EG>
EG> In any case, for bridges which are currently VLAN unaware, there is
EG> no need to configure VLAN information.  It is certainly possible to
EG> make RBridges VLAN aware and _only_ require configuration when VLAN
EG> context (IDs) changes in transfer across an RBridge.
EG>
EG> As far as I know, the goal is to allow configuration free RBridges.
EG> 
EG>

> The fact that - from RBridge's perspective - a VLAN is simply an ID, makes
> it possible, for example, for an RBridge to simply use the ID as part of
> context it uses for learning, shortest path determination, spanning tree
> setup, etc.  In this sense, it would be necessary to configure information
> relative to specific VLAN IDs only if something other than simple context
> is required (like authentication, ID-to-ID translation/mapping, etc.).
> 
> 	For IANA considerations change the first sentence to read:
> 
>     "This document currently has no IANA considerations."
> 
> and it will be correct until the situation changes (at which time, it
> should be changed as well).

P&AS should not have IANA considerations unless the problem is itself
with IANA-based information. That's not the case here - there's no
IANA-centric issue. Architectures that address the problem (such as
rbridges) may have IANA considerations, but that's not relevant to the
P&AS doc.

Arch docs should have an IANA consideration if any variants of instances
of the architecture would have new protocol/port/etc numbers. So far,
the arch doc indicates that this might be the case for rbridges.

EG>
EG> Agreed.
EG>

Joe

> 
> --> -----Original Message-----
> --> From: [e-mail] 
> --> [mailto:[e-mail]]On
> --> Behalf Of Guillermo Ib??ez
> --> Sent: Monday, November 07, 2005 7:23 AM
> --> To: Developing a hybrid router/bridge.
> --> Subject: [rbridge] Comments to draft Touch-00
> --> 
> --> 
> --> Joe,
> --> 
> -->       Please find attached commented draft. Comments are 
> --> indicated with GI>
> --> 
> --> Guillermo Ib??ez
> --> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA9HYXM09114 for <[e-mail]>; Wed, 9 Nov 2005 09:34:34 -0800 (PST)
Received: by wproxy.gmail.com with SMTP id i6so373391wra for <[e-mail]>; Wed, 09 Nov 2005 09:34:33 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=DM7W2Umq+0YoXYPHSC1LMa+xWdzih5spn35+Smt38sYSLIJZdgcM+uhSx/He0MWZgHs6pcPNRzasApdee2BEC7c0wJWkODx5yCyZrFlN1PKFLbZ+hsPHzeUXs5gJ+kAK6MRe8/jEK3STBMiSMf2UJsKI2WtiRebyshMNNZhiT/I=
Received: by 10.54.104.2 with SMTP id b2mr726992wrc; Wed, 09 Nov 2005 09:34:33 -0800 (PST)
Received: by 10.54.151.15 with HTTP; Wed, 9 Nov 2005 09:34:33 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 9 Nov 2005 09:34:33 -0800
From: Alia Atlas <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
X-ISI-4-43-8-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 jA9HYXM09114
Subject: [rbridge] routing heirarchy discussion in draft-touch-trill-rbridge-prob-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 17:35:11 -0000
Status: RO
Content-Length: 940

Sec 2.2 says:

"The spanning tree protocol is inherently global to an entire layer 2
   subnet; there is no current way to contain, partition, or otherwise
   factor the protocol into a number of smaller, more stable subsets
   that interact as groups. Contrast this with Internet routing, which
   includes both intradomain and interdomain variants, split to provide
   exactly that containment and scalability within a domain while
   allowing domains to interact freely independent of what happens
   inside.  "

I think that one strength of rbridges is the potential for introducing
a level of heirarchy in the routing.  However, I believe this is confined
to IGP-like areas (intra-domain).  The idea of nesting inter-domain
heirarchy inside seems rather implausible.

If we are considering routing areas, then it may also be interesting to
consider or at least discuss the topology constraints required in order
to support such.

Alia


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 jA9CW0M06421 for <[e-mail]>; Wed, 9 Nov 2005 04:32:00 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2DC809DF3C for <[e-mail]>; Wed,  9 Nov 2005 13:31:54 +0100 (CET)
Received: from [163.117.139.70] (gibanez.it.uc3m.es [163.117.139.70]) by smtp01.uc3m.es (Postfix) with ESMTP id 39DCF9DE25 for <[e-mail]>; Wed,  9 Nov 2005 13:31:53 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 09 Nov 2005 13:31:53 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
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-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Comments to draft Touch- arch-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 12:51:20 -0000
Status: RO
Content-Length: 3217

Joe,
     These are my comments to the second draft (architecture).
Guillermo

- Structure of document.
    Looks right overall.
    "4.9 External protocols" may be has category enough to be a separate 
section. Name suggested for that section  would be  "Interaction with 
802.D protocols" just to be more precise and avoid the 
"internal/external" terminology dispute.

Abstract
     " RBridges are link layer (L2) devices...
GI> this seems a too simple but "strong" statement. If RBridges were 
(only) L2 link
GI>  layer devices, should not they be standardized by IEEE ?.

2.1 Existing Terminology

- I would recommend as general criteria to align the terminology 
whenever possible with IEEE 802.1D terminology.
   So use STP (and RSTP) for Spanning (and Rapid) Spanning Tree 
Algorithm and Protocol instead of BSTP.
Bridge: as the term can be used sometimes with a very general meaning, 
an specific term for  802.1D bridge is needed. Perhaps SBridge.
- BST: as the newcomers are the rbridges spanning trees, I recommend to 
use explicitely rbridge spanning trees
- Node :  do not use terms "outside" (or inside RBridge campus).

2.2 RBridge Terminology
- Do not use the term campus, better use RBridge set, structure, pool or 
anotherm term.
- CFT: use FT
- CTH: use TH
- CTT: the name is not illustrative, I suggest  Node (or Host) Table
- Designated RBridge:  "... rbridge associated" add "...by the rbridge 
protocol"
- Edge: do not use outside/inside, ingress/eggress traffic instead.
- Inside/ Outside (also Internal/External)
- I agree with E. Nodmark in that it is applicable to traffic entering 
but to apply it  to topological view is confusing.

3.
     RBridge campus: 
3.1
    In conventional bridges the port learning is included and named as 
"filtering" like Filtering Database. Also Filtering ID term is used when 
there are several (multiple VLANs).
3.3
    add "rbridge" to "...of the egresss"

4.9
The term "Internal Spanning Tree" should also be avoided.
I suggest not to use spanning tree term for communication between  
Rbridges and use another term. Some where proposed already (you may add 
"SPF trees" to the proposed) . Besides the  "internal" issue, the  
rbridges spanning trees have only meaning for multicast across VLANs, 
so  only in multicast context should be used. 

4.9.2.1 Transparent-STP

If you look at the figure 2 and assume that rbridges work in 
transparent-STP mode, as hubs for STP BPDUs, all b3, r4, r5, h2, r6, r7, 
b8, r9 will be connected together for the BPDUs, b3 or b8 will be the 
root bridge. This seems to introduce uncontrollability in the network, 
as long as the rbridges behave like hubs, but  they are not (do not 
create real collisions, do not forward external traffic), and they 
create longer spanning trees that  are slower to converge, etc. This has 
been already discussed. At least some comment on the risks of this mode 
should be included.

4.9.2.3 Block STP
    Include the paragraph as agreed with Radia and Eric Gray mentioning  
B-RB-B implementations of rbridges that will allow real rbridges to act 
as prioritary root bridges of the external spanning tree whithout change 
of rbridge functionality.

____________________________





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 jA97D4M14130 for <[e-mail]>; Tue, 8 Nov 2005 23:13:05 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2515F9DF9D for <[e-mail]>; Wed,  9 Nov 2005 08:12:58 +0100 (CET)
Received: from [163.117.203.188] (unknown [163.117.203.188]) by smtp01.uc3m.es (Postfix) with ESMTP id 1485B9DAB5 for <[e-mail]>; Wed,  9 Nov 2005 08:12:57 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 09 Nov 2005 08:12:56 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
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]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Comments to draft Touch-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 07:14:38 -0000
Status: RO
Content-Length: 5446

Eric,
      I insert just a couple of comments to your comments.
Guillermo

Gray, Eric wrote:

>Guillermo/Joe,
>
>	I agree with Guillermo that the abstract - along with several other
>sections - describes RBridge solutions instead of the problems addressed.
>I strongly suspect that many (if not most) of Guillermo's comments would
>be addressed if the draft were targetted more toward describing problems
>rather than the RBridge solution(s).
>
>	Questions about whether RSTP, self-rooted multiple spanning trees 
>and/or Shortest Path Bridging are also solutions (with or without implied 
>preferences) should be a separate issue, document and discussion.
>
>	We have been using the term campus for some time now and I think it
>is clear that introducing a new term at this point is probably not a good
>idea.  For one thing, we're defining terms like internal and external as
>relative to a campus (and therefore, defining the term campus in the same
>process).  If we assume that we were to define the terms internal and 
>external relative to some other term "X", then we come up with the same
>areas of potential confusion with a different term.  Do we need to go
>through that exercise just to demonstrate this?
>
>	However, it would help if we did not use clearly confusing wording
>(such as the phrase "this communication may traverse external devices, 
>but is still considered internal").  I think - for instance - that we've
>beat the definitions of internal and external to the point that it should
>be very clear what is internal and what is external (and, therefore, what
>is internal is internal not external).  We have elastically defined the
>term "internal" to me between mutually participating RBridges and - as a
>consequence - it does have an agreed topological meaning.
>
>  
>
May be I did not follow the terms discussion in detail, but it is very 
confusing to consider *internally* connected to RBridges that are 
connected phisically via standard bridges. As long as we are not 
considering a *RBridge core* scenario (RBridges interconnected directly 
between them), I see the term internal inadecuate.

>	I agree with Joe that small changes can have big effects but I also
>agree with Guillermo that we need to at least briefly illustrate how this
>can occur.  It would probably be sufficient to show how (possibly faulty)
>bridge networks could result in many interface forwarding-state changes
>as a result of loss of a key bridge or link.  Alternatively, we could just 
>add a reference to some place(s) where this is documented elsewhere. 
>
>	In the same sense that we hope to avoid configuration, we probably
>should not assume RBrdiges will be deployed in an idealistic configuration 
>either.  In other words, we should describe what causes the problem with 
>STP (or RSTP) with a view to how it might be fixed in design rather than
>in deployment.
>
>	I agree with Guillermo that more information is required with repect
>to convergence time considerations or camparisons between STP/RSTP and SPF
>routing.  I suspect that this might be related to the blurring of intenal 
>and external described above.  The presence of bridges and other devices 
>on links between RBridges (at least RBridges not deliberately configured 
>to ignore each other) does not change the fact that these links are campus-
>internal and - in fact - these components are also internal to the campus.
>However, it might be fair to say that SPF convergence between directly 
>connected RBridges should be faster than STP convergence between directly 
>connected bridges.
>  
>
The fair comparison would be with RSTP convergence, not with STP 
convergence. Remember that the current IEEE standard is RSTP. STP is legacy.

>	Since an RBridge is - among other things - a VLAN aware bridge, I 
>do not agree that support for VLANs necessarily requires configuration.
>The fact that - from RBridge's perspective - a VLAN is simply an ID, makes
>it possible, for example, for an RBridge to simply use the ID as part of
>context it uses for learning, shortest path determination, spanning tree
>setup, etc.  In this sense, it would be necessary to configure information
>relative to specific VLAN IDs only if something other than simple context
>is required (like authentication, ID-to-ID translation/mapping, etc.).
>  
>
If , as most common  example, per-port VLANs are used, it must be 
configured which ports belong to which VLANs. If VLAN ID learning is 
assumed, somebody (Bridge or host) must label the frames with the VLAN 
tag. This "somebody" must be instructed (configured) to label with such 
value for VLAN.

>	For IANA considerations change the first sentence to read:
>
>    "This document currently has no IANA considerations."
>
>and it will be correct until the situation changes (at which time, it
>should be changed as well).
>
>--
>Eric
>
>--> -----Original Message-----
>--> From: [e-mail] 
>--> [mailto:[e-mail]]On
>--> Behalf Of Guillermo Ib??ez
>--> Sent: Monday, November 07, 2005 7:23 AM
>--> To: Developing a hybrid router/bridge.
>--> Subject: [rbridge] Comments to draft Touch-00
>--> 
>--> 
>--> Joe,
>--> 
>-->       Please find attached commented draft. Comments are 
>--> indicated with GI>
>--> 
>--> Guillermo Ib??ez
>--> 
>_______________________________________________
>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 jA93xYM26054 for <[e-mail]>; Tue, 8 Nov 2005 19:59:34 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.226.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jA93xXD7021250;  Tue, 8 Nov 2005 20:59:33 -0700 (MST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jA93xRhW325439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 8 Nov 2005 19:59:33 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 08 Nov 2005 19:59:27 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Touch <[e-mail]>
References: <[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-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Minor issue in draft-touch-trill-rbridge-arch-00a.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 04:00:04 -0000
Status: RO
Content-Length: 1388

Joe Touch wrote:

> You are correct that routing information might not go over tunnels, but
> I'm wondering why - the performance benefit is minimal, and by using the
> tunnels the routing protocol 'fate shares' the data paths - I thought
> that was a desirable property.
> 
> So, strictly, it's not required, but what's the benefit?

The discovery packets might be the more interesting case.
The encapsulation header includes the "next hop" as well as "final 
rbridge", and at least the last one would be useless hence potentially 
confusing for the discovery packets, since they take a single RBridge 
hop to an unknown (multicast) destination.

> We can define internal/external just as easily without discussing
> tunnels, FWIW (sorry, I lost this idea while I was writing the drafts,
> but can fix it): all internal traffic is addressed TO the rbridge's 802
> address (whether it is tunneled or not). I also didn't get to the part
> where we need to discuss how many 802 addresses an rbridge has (it may
> need one per port; I can't see how to avoid that - more in the update to
> the draft on that).

Yes, I think describing internal vs. external *traffic* (or frames) is 
useful. Basing that on the destination address is probably general enough.

But the current set of definitions try to define internal and external 
*parts of topology*, which I think adds confusion.

    Erik


Received: from [209.52.104.180] (pp104-180.bctel.ca [209.52.104.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA92f2M06282; Tue, 8 Nov 2005 18:41:02 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 08 Nov 2005 18:41:01 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: Erik Nordmark <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3BC429EDF940D9B55D214D50"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Minor issue in draft-touch-trill-rbridge-arch-00a.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 02:42:07 -0000
Status: RO
Content-Length: 2228

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3BC429EDF940D9B55D214D50
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Erik Nordmark wrote:
> Joe Touch wrote:
>=20
>> Rbridges treat all their physical ports as external ports, and all the=
ir
>> tunnels (logical ports) as internal ports.
>>
>> No physical port 'becomes' internal; a tunnel is created on that port,=

>> and it is the tunnel that is internal.
>=20
> By "tunnel" do you mean that packets are always encapsulated when
> sending on these logical, internal ports?

Yes.

> While this is necessary for the frames being forwarded, it isn't clear
> to me that it is required to encapsulate the control packets the
> rbridges exchange with each other (for discovering each other as well a=
s
> the routing protocol exchanges).
>=20
>    Erik

The diagrams discussed data traffic, not control traffic. All data
traffic is tunneled.

You are correct that routing information might not go over tunnels, but
I'm wondering why - the performance benefit is minimal, and by using the
tunnels the routing protocol 'fate shares' the data paths - I thought
that was a desirable property.

So, strictly, it's not required, but what's the benefit?

We can define internal/external just as easily without discussing
tunnels, FWIW (sorry, I lost this idea while I was writing the drafts,
but can fix it): all internal traffic is addressed TO the rbridge's 802
address (whether it is tunneled or not). I also didn't get to the part
where we need to discuss how many 802 addresses an rbridge has (it may
need one per port; I can't see how to avoid that - more in the update to
the draft on that).

Joe


--------------enig3BC429EDF940D9B55D214D50
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.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDcWG9E5f5cImnZrsRAlwEAJ4wlNkfSL6ByqWrfvNukuvS+iJgYwCg0kEV
PJ9Y75dkRPjTWmIsWtIEGHE=
=sQH/
-----END PGP SIGNATURE-----

--------------enig3BC429EDF940D9B55D214D50--


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 jA92T3M02680 for <[e-mail]>; Tue, 8 Nov 2005 18:29:03 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.108.38]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id jA92T2dK000316;  Tue, 8 Nov 2005 18:29:02 -0800 (PST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jA92SwoI286881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 8 Nov 2005 18:29:00 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 08 Nov 2005 18:28:58 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Touch <[e-mail]>
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-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Minor issue in draft-touch-trill-rbridge-arch-00a.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 02:30:05 -0000
Status: RO
Content-Length: 621

Joe Touch wrote:

> Rbridges treat all their physical ports as external ports, and all their
> tunnels (logical ports) as internal ports.
> 
> No physical port 'becomes' internal; a tunnel is created on that port,
> and it is the tunnel that is internal.

By "tunnel" do you mean that packets are always encapsulated when 
sending on these logical, internal ports?

While this is necessary for the frames being forwarded, it isn't clear 
to me that it is required to encapsulate the control packets the 
rbridges exchange with each other (for discovering each other as well as 
the routing protocol exchanges).

    Erik


Received: from [209.52.104.180] (pp104-180.bctel.ca [209.52.104.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA91jNM21057; Tue, 8 Nov 2005 17:45:23 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 08 Nov 2005 17:45:22 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: Erik Nordmark <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0FF58ED5F910F4BF2BEB4E2B"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Minor issue in draft-touch-trill-rbridge-arch-00a.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 01:46:11 -0000
Status: RO
Content-Length: 3288

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0FF58ED5F910F4BF2BEB4E2B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Erik Nordmark wrote:
>=20
>                              N       N---b3---N
>                              |           ||
>                              |           ||
>                              |           h2
>                              |          /| \
>                              |         / N  \
>                              |        /      \
>                         N---h1--r4***r5******r6
>                                 *   *        *
>                                 *  *         *
>                                 * *          *
>                             N---r7***********r9-----N
>                                  \          /|\
>                                   \        / | \
>                                    \      /  N  N
>                                     \    /
>                                      \  /
>                                       b8
>                                       |
>                                       N
>=20
>              Figure 3 Reorganized RBridge Ethernet link subnet
>=20
> Since there might be a hub or bridge between e.g. r4 and r7 that they
> can't see (in addition to the hub it could also be a bridge which
> doesn't speak BSTP). Thus I think the RBridges must assume that the pat=
h
> between any pair of them might have nodes/stations attached, just as in=

> the r7-r9 path.

They can assume that, but then the diagram wouldn't 'reorganize' to this
diagram. I showed that property on the r7-r9 link (for bridge b8) and on
the r5-r6 link (for a hub, e.g., h2).

> I think this makes the "inside" vs. "outside" definitions not very
> helpful in terms of understanding the toplogy; we have paths between
> RBridges which carry encapsulated frames, but for those we also have a
> designated forwarder which sends unencapsulated frames out, in order to=

> handle the r7,r9,b8 type topology above.

That's already shown above; I noted that the diagram is topological (who
talks to whom), not traffic/bandwidth (who transparently is carried over
whom).

> For instance, I think an RBridge must treat all its ports as external.
> In addition, a port would also be internal when the discovery protocol
> finds that there are other RBridges directly reachable over that port.
>=20
>    Erik

Rbridges treat all their physical ports as external ports, and all their
tunnels (logical ports) as internal ports.

No physical port 'becomes' internal; a tunnel is created on that port,
and it is the tunnel that is internal.

(I should have put that in the second doc; that'll make it in there later=
).

Joe


--------------enig0FF58ED5F910F4BF2BEB4E2B
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.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDcVSyE5f5cImnZrsRAjHFAKD5TxgQzkNCyU28y6Xu3My0o7AAVgCgkxT6
OsvEiwQo9s8ELOV8Xm8CKXc=
=KZPs
-----END PGP SIGNATURE-----

--------------enig0FF58ED5F910F4BF2BEB4E2B--


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 jA917iM10346 for <[e-mail]>; Tue, 8 Nov 2005 17:07:44 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.56.36]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id jA917hdK016969;  Tue, 8 Nov 2005 17:07:43 -0800 (PST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jA917g5t239565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 8 Nov 2005 17:07:43 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 08 Nov 2005 16:59:29 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Touch <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: [rbridge] Minor issue in draft-touch-trill-rbridge-arch-00a.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 01:08:52 -0000
Status: RO
Content-Length: 1854

                              N       N---b3---N
                              |           ||
                              |           ||
                              |           h2
                              |          /| \
                              |         / N  \
                              |        /      \
                         N---h1--r4***r5******r6
                                 *   *        *
                                 *  *         *
                                 * *          *
                             N---r7***********r9-----N
                                  \          /|\
                                   \        / | \
                                    \      /  N  N
                                     \    /
                                      \  /
                                       b8
                                       |
                                       N

              Figure 3 Reorganized RBridge Ethernet link subnet

Since there might be a hub or bridge between e.g. r4 and r7 that they 
can't see (in addition to the hub it could also be a bridge which 
doesn't speak BSTP). Thus I think the RBridges must assume that the path 
between any pair of them might have nodes/stations attached, just as in 
the r7-r9 path.

I think this makes the "inside" vs. "outside" definitions not very 
helpful in terms of understanding the toplogy; we have paths between 
RBridges which carry encapsulated frames, but for those we also have a 
designated forwarder which sends unencapsulated frames out, in order to 
handle the r7,r9,b8 type topology above.

For instance, I think an RBridge must treat all its ports as external. 
In addition, a port would also be internal when the discovery protocol 
finds that there are other RBridges directly reachable over that port.

    Erik



Received: from [209.52.104.180] (pp104-180.bctel.ca [209.52.104.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA8Nq8M13941; Tue, 8 Nov 2005 15:52:08 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 08 Nov 2005 15:51:55 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig022D395B56AF788D2E1F849C"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Comments to draft Touch-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 23:53:06 -0000
Status: RO
Content-Length: 7161

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig022D395B56AF788D2E1F849C
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Gray, Eric wrote:
> Guillermo/Joe,
>=20
> 	I agree with Guillermo that the abstract - along with several other
> sections - describes RBridge solutions instead of the problems addresse=
d.
> I strongly suspect that many (if not most) of Guillermo's comments woul=
d
> be addressed if the draft were targetted more toward describing problem=
s
> rather than the RBridge solution(s).

I'm presuming this addresses the first doc; see below...

> 	Questions about whether RSTP, self-rooted multiple spanning trees=20
> and/or Shortest Path Bridging are also solutions (with or without impli=
ed=20
> preferences) should be a separate issue, document and discussion.

Problem statements often cite or refer to current work that might solve
the problem, as well as allude to the solution as in "something that
solves this will work under the following conditions". That requires
saying something about the possible solutions in that doc, but it
doesn't define the solutions. It's just 'enough to identify them', as
well as to indicate that existing solutions may not suffice.

> 	We have been using the term campus for some time now and I think it
> is clear that introducing a new term at this point is probably not a go=
od
> idea.

The issue is whether it means the same thing to all of us. Does it?

> For one thing, we're defining terms like internal and external as
> relative to a campus (and therefore, defining the term campus in the sa=
me
> process).  If we assume that we were to define the terms internal and=20
> external relative to some other term "X", then we come up with the same=

> areas of potential confusion with a different term.  Do we need to go
> through that exercise just to demonstrate this?
>=20
> 	However, it would help if we did not use clearly confusing wording
> (such as the phrase "this communication may traverse external devices, =

> but is still considered internal").

I came up with an explanation of that that's visual in the second doc. I
can include that in the first, but that strays into 'describing the
solution' more.

> I think - for instance - that we've
> beat the definitions of internal and external to the point that it shou=
ld
> be very clear what is internal and what is external (and, therefore, wh=
at
> is internal is internal not external).

To us; these docs are not for us ;-) We need to explain this so a newbie
to TRILL can understand.

> We have elastically defined the
> term "internal" to me between mutually participating RBridges and - as =
a
> consequence - it does have an agreed topological meaning.
>=20
> 	I agree with Joe that small changes can have big effects but I also
> agree with Guillermo that we need to at least briefly illustrate how th=
is
> can occur.  It would probably be sufficient to show how (possibly fault=
y)
> bridge networks could result in many interface forwarding-state changes=

> as a result of loss of a key bridge or link.  Alternatively, we could j=
ust=20
> add a reference to some place(s) where this is documented elsewhere.=20

Yes - if someone has a picture, please send it; if not, a ref would be
fantastic.

> 	In the same sense that we hope to avoid configuration, we probably
> should not assume RBrdiges will be deployed in an idealistic configurat=
ion=20
> either.  In other words, we should describe what causes the problem wit=
h=20
> STP (or RSTP) with a view to how it might be fixed in design rather tha=
n
> in deployment.
>=20
> 	I agree with Guillermo that more information is required with repect
> to convergence time considerations or camparisons between STP/RSTP and =
SPF
> routing.  I suspect that this might be related to the blurring of inten=
al=20
> and external described above.  The presence of bridges and other device=
s=20
> on links between RBridges (at least RBridges not deliberately configure=
d=20
> to ignore each other) does not change the fact that these links are cam=
pus-
> internal and - in fact - these components are also internal to the camp=
us.
> However, it might be fair to say that SPF convergence between directly =

> connected RBridges should be faster than STP convergence between direct=
ly=20
> connected bridges.

This is addressed in the second doc; I had hoped to avoid that level of
discussion in the first.

> 	Since an RBridge is - among other things - a VLAN aware bridge, I=20
> do not agree that support for VLANs necessarily requires configuration.=


How do you know which traffic is on which VLAN, i.e., if it arrives at
the rbridge and isn't VLAN-tagged yet? (maybe I need to brush up on how
VLANs work, but I thought you needed to tag ports somewhere).

> The fact that - from RBridge's perspective - a VLAN is simply an ID, ma=
kes
> it possible, for example, for an RBridge to simply use the ID as part o=
f
> context it uses for learning, shortest path determination, spanning tre=
e
> setup, etc.  In this sense, it would be necessary to configure informat=
ion
> relative to specific VLAN IDs only if something other than simple conte=
xt
> is required (like authentication, ID-to-ID translation/mapping, etc.).
>=20
> 	For IANA considerations change the first sentence to read:
>=20
>     "This document currently has no IANA considerations."
>=20
> and it will be correct until the situation changes (at which time, it
> should be changed as well).

P&AS should not have IANA considerations unless the problem is itself
with IANA-based information. That's not the case here - there's no
IANA-centric issue. Architectures that address the problem (such as
rbridges) may have IANA considerations, but that's not relevant to the
P&AS doc.

Arch docs should have an IANA consideration if any variants of instances
of the architecture would have new protocol/port/etc numbers. So far,
the arch doc indicates that this might be the case for rbridges.

Joe

>=20
> --> -----Original Message-----
> --> From: [e-mail]=20
> --> [mailto:[e-mail]]On
> --> Behalf Of Guillermo Ib=E1=F1ez
> --> Sent: Monday, November 07, 2005 7:23 AM
> --> To: Developing a hybrid router/bridge.
> --> Subject: [rbridge] Comments to draft Touch-00
> -->=20
> -->=20
> --> Joe,
> -->=20
> -->       Please find attached commented draft. Comments are=20
> --> indicated with GI>
> -->=20
> --> Guillermo Ib=E1=F1ez
> -->=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


--------------enig022D395B56AF788D2E1F849C
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.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDcTooE5f5cImnZrsRArDKAKDMOW/4A7MocUPz0K/LyGzS+pHz7QCglGkt
jKwMUpdygoZmK8H2sX7bsvc=
=y58u
-----END PGP SIGNATURE-----

--------------enig022D395B56AF788D2E1F849C--


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA8N0AM28564 for <[e-mail]>; Tue, 8 Nov 2005 15:00:10 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jA8N046l016003 for <[e-mail]>; Tue, 8 Nov 2005 18:00:04 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA06981 for <[e-mail]>; Tue, 8 Nov 2005 18:00:04 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WCKHSDNM>; Tue, 8 Nov 2005 21:00:03 -0200
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Tue, 8 Nov 2005 21:00:02 -0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Comments to draft Touch-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 23:03:31 -0000
Status: RO
Content-Length: 4328

Guillermo/Joe,

	I agree with Guillermo that the abstract - along with several other
sections - describes RBridge solutions instead of the problems addressed.
I strongly suspect that many (if not most) of Guillermo's comments would
be addressed if the draft were targetted more toward describing problems
rather than the RBridge solution(s).

	Questions about whether RSTP, self-rooted multiple spanning trees 
and/or Shortest Path Bridging are also solutions (with or without implied 
preferences) should be a separate issue, document and discussion.

	We have been using the term campus for some time now and I think it
is clear that introducing a new term at this point is probably not a good
idea.  For one thing, we're defining terms like internal and external as
relative to a campus (and therefore, defining the term campus in the same
process).  If we assume that we were to define the terms internal and 
external relative to some other term "X", then we come up with the same
areas of potential confusion with a different term.  Do we need to go
through that exercise just to demonstrate this?

	However, it would help if we did not use clearly confusing wording
(such as the phrase "this communication may traverse external devices, 
but is still considered internal").  I think - for instance - that we've
beat the definitions of internal and external to the point that it should
be very clear what is internal and what is external (and, therefore, what
is internal is internal not external).  We have elastically defined the
term "internal" to me between mutually participating RBridges and - as a
consequence - it does have an agreed topological meaning.

	I agree with Joe that small changes can have big effects but I also
agree with Guillermo that we need to at least briefly illustrate how this
can occur.  It would probably be sufficient to show how (possibly faulty)
bridge networks could result in many interface forwarding-state changes
as a result of loss of a key bridge or link.  Alternatively, we could just 
add a reference to some place(s) where this is documented elsewhere. 

	In the same sense that we hope to avoid configuration, we probably
should not assume RBrdiges will be deployed in an idealistic configuration 
either.  In other words, we should describe what causes the problem with 
STP (or RSTP) with a view to how it might be fixed in design rather than
in deployment.

	I agree with Guillermo that more information is required with repect
to convergence time considerations or camparisons between STP/RSTP and SPF
routing.  I suspect that this might be related to the blurring of intenal 
and external described above.  The presence of bridges and other devices 
on links between RBridges (at least RBridges not deliberately configured 
to ignore each other) does not change the fact that these links are campus-
internal and - in fact - these components are also internal to the campus.
However, it might be fair to say that SPF convergence between directly 
connected RBridges should be faster than STP convergence between directly 
connected bridges.

	Since an RBridge is - among other things - a VLAN aware bridge, I 
do not agree that support for VLANs necessarily requires configuration.
The fact that - from RBridge's perspective - a VLAN is simply an ID, makes
it possible, for example, for an RBridge to simply use the ID as part of
context it uses for learning, shortest path determination, spanning tree
setup, etc.  In this sense, it would be necessary to configure information
relative to specific VLAN IDs only if something other than simple context
is required (like authentication, ID-to-ID translation/mapping, etc.).

	For IANA considerations change the first sentence to read:

    "This document currently has no IANA considerations."

and it will be correct until the situation changes (at which time, it
should be changed as well).

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Monday, November 07, 2005 7:23 AM
--> To: Developing a hybrid router/bridge.
--> Subject: [rbridge] Comments to draft Touch-00
--> 
--> 
--> Joe,
--> 
-->       Please find attached commented draft. Comments are 
--> indicated with GI>
--> 
--> Guillermo Ib??ez
--> 


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 jA8Lf9M03306 for <[e-mail]>; Tue, 8 Nov 2005 13:41:09 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.226.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id jA8Lf8dK021458 for <[e-mail]>; Tue, 8 Nov 2005 13:41:08 -0800 (PST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jA8LewkF140943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 8 Nov 2005 13:41:07 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 08 Nov 2005 21:40:57 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720)
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-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Updated agenda
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 21:42:32 -0000
Status: RO
Content-Length: 812

The updated agenda has been posted to the datatracker.
It is included below.

    Erik


Transparent interconnection of Lots of Links WG

WEDNESDAY, November 9, 2005
1300-1500 Afternoon Session I

Administrativia (scribe etc)		Chair		5 minutes

Agenda bashing				Chair		5 minutes

Base specifications			Joe Touch	20 minutes
Late drafts are at
http://www.postel.org/rbridge/draft-touch-trill-rbridge-prob-00.txt
http://www.postel.org/rbridge/draft-touch-trill-rbridge-arch-00a.txt

Routing Requirements in Support of R-Bridges
draft-gray-rbridge-routing-reqs-00.txt	Eric Gray	20 minutes

Multicast Link State For Rbidges
draft-hares-trill-multicast-00.txt	Sue Hares	20 minutes

TRILL using Pseudo-Wire Emulation (PWE) Encapsulation
draft-bryant-perlman-trill-pwe-encap-00.txt
					Stewart Bryant	20 minutes







Received: from [128.9.176.136] (ras36.isi.edu [128.9.176.136]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA7JYfM03974; Mon, 7 Nov 2005 11:34:41 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 07 Nov 2005 11:34:40 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: Joe Touch <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig368060BA2B06DE4D8AE39965"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Proposed agenda
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 19:35:46 -0000
Status: RO
Content-Length: 1191

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig368060BA2B06DE4D8AE39965
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Joe Touch wrote:
=2E..
> A draft of the first document is now available on the website:
> 	http://www.postel.org/rbridge

The second is now available as well; it's a bit draftier. I have text
for other sections, just haven't entered it yet. As a result, it's
labelled 00a (and will be completed by the time the ID queue reopens and
it is submitted).

The key issue on both drafts:

	- are these the right structure and general tone?

	- are these the kind of docs to become WG docs?

Joe


--------------enig368060BA2B06DE4D8AE39965
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.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDb6xQE5f5cImnZrsRAoh2AKCNjYIao5VgS96cUQ8oGCm/seeUnQCeMZYt
jC3Gqe8/CtPYOgmc6YgRYAg=
=w4aw
-----END PGP SIGNATURE-----

--------------enig368060BA2B06DE4D8AE39965--


Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA7HQQM22060 for <[e-mail]>; Mon, 7 Nov 2005 09:26:26 -0800 (PST)
Received: by wproxy.gmail.com with SMTP id i5so649862wra for <[e-mail]>; Mon, 07 Nov 2005 09:26:25 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=b5sdZ7aXUR6OMgS8vp+BrbM9raGg3iplNBhKDfGb31N1Fza/HUhvmUPaxP9VsSsnmDVPpD/qlR71GRZ7S7HF5aDl7BgXit173J4xtc/wwyXOkYonGvD6c9UnhVI1paIHPX7MMaPzZNZCA61qdHRiFAf3vEtmdmZuTDAa0ojHsB8=
Received: by 10.54.60.9 with SMTP id i9mr1616717wra; Mon, 07 Nov 2005 09:26:25 -0800 (PST)
Received: by 10.54.151.15 with HTTP; Mon, 7 Nov 2005 09:26:25 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 7 Nov 2005 09:26:25 -0800
From: Alia Atlas <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_9082_14515005.1131384385830"
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Proposed agenda
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 17:26:40 -0000
Status: RO
Content-Length: 2442

------=_Part_9082_14515005.1131384385830
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 11/4/05, Radia Perlman <[e-mail]> wrote:
>
> That document is a new idea to shrink the shim header into 4 bytes. I
> think it would be
> good to have that on the agenda. I didn't volunteer because I won't be
> at this IETF, but it
> would be great if one of the other coauthors would volunteer to present
> it.


I could present it, if there is time and interest.

Alia

Radia
>
>
>
> Harald said:
>
> >
> >
> >>draft-bryant-perlman-trill-pwe-encap-00 doesn't seem complete.... do yo=
u
> >>count it as part of the base, or not?
> >>
> >>
> >
> >
> >
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
>

------=_Part_9082_14515005.1131384385830
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 11/4/05, <b class=3D"gmail_sendername">Radia Perlman</b> &lt;<a href=3D"=
mailto:[e-mail]">[e-mail]</a>&gt; wrote:<div><spa=
n class=3D"gmail_quote"></span><blockquote class=3D"gmail_quote" style=3D"b=
order-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; paddin=
g-left: 1ex;">
That document is a new idea to shrink the shim header into 4 bytes. I<br>th=
ink it would be<br>good to have that on the agenda. I didn't volunteer beca=
use I won't be<br>at this IETF, but it<br>would be great if one of the othe=
r coauthors would volunteer to present it.
</blockquote><div><br>
I could present it, if there is time and interest.<br>
<br>
Alia<br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Radia<b=
r><br><br><br>Harald said:<br><br>&gt;<br>&gt;<br>&gt;&gt;draft-bryant-perl=
man-trill-pwe-encap-00 doesn't seem complete.... do you
<br>&gt;&gt;count it as part of the base, or not?<br>&gt;&gt;<br>&gt;&gt;<b=
r>&gt;<br>&gt;<br>&gt;<br><br>_____________________________________________=
__<br>rbridge mailing list<br><a href=3D"mailto:[e-mail]">rbridge=
@postel.org
</a><br><a href=3D"http://www.postel.org/mailman/listinfo/rbridge">http://w=
ww.postel.org/mailman/listinfo/rbridge</a><br></blockquote></div><br>

------=_Part_9082_14515005.1131384385830--


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 jA7CNXM16265 for <[e-mail]>; Mon, 7 Nov 2005 04:23:34 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A6D0E9D55D for <[e-mail]>; Mon,  7 Nov 2005 13:23:27 +0100 (CET)
Received: from [163.117.139.80] (gibanez.it.uc3m.es [163.117.139.80]) by smtp01.uc3m.es (Postfix) with ESMTP id CFF0B9DF35 for <[e-mail]>; Mon,  7 Nov 2005 13:23:26 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 07 Nov 2005 13:23:26 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: multipart/mixed; boundary="------------040105060508070308050508"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Comments to draft Touch-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 12:24:08 -0000
Status: RO
Content-Length: 39764

This is a multi-part message in MIME format.
--------------040105060508070308050508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Joe,

      Please find attached commented draft. Comments are indicated with GI>

Guillermo Ib??ez

--------------040105060508070308050508
Content-Type: text/plain;
	name="GIcommentsdraft-touch-trill-rbridge-prob-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
	filename="GIcommentsdraft-touch-trill-rbridge-prob-00.txt"

TRILL WG                                                 J. Touch (ed.) 
Internet Draft                                                  USC/ISI 
Expires: May 2006                                      November 4, 2005 
                                    
 
                                      
                    RBridge: Problem and Applicability 
                   draft-touch-trill-rbridge-prob-00.txt 


Status of this Memo 

   By submitting this Internet-Draft, each author represents that       
   any applicable patent or other IPR claims of which he or she is       
   aware have been or will be disclosed, and any of which he or she       
   becomes aware will be disclosed, in accordance with Section 6 of       
   BCP 79. 

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 

   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 

   The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt 

   The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html 

   This Internet-Draft will expire on May 4, 2006. 

Copyright Notice 

   Copyright (C) The Internet Society (2005).  All Rights Reserved. 

Abstract 

   RBridges are link layer (L2) devices that use routing protocols as a 
   control plane. They combine the link layer ability to allow hosts to 
   reattach without renumbering with network layer routing benefits. 
   RBridges use existing link state routing to provide higher internal 
   cross-section bandwidth, faster convergence under reconfiguration, 
   and more robustness to link interruption than an equivalent set of 
 
 GI> It describes the hammer more than the "nail"
 
Touch                    Expires May 4, 2006                   [Page 1] 

Internet-Draft    RBridge: Problem and Applicability      November 2005 
    

   conventional bridges using existing spanning tree forwarding. They 
   are intended to apply 
GI> AT LEAST 
to similar L2 network sizes as conventional 
   bridges and are intended to be backward compatible with those bridges 
   as both ingress/egress and transit. They also attempt to retain as 
   much 'plug and play' as is already available in existing bridges. 
   This document explains the need for RBridges, defines their desired 
   properties, and describes situations where they will be useful. 

   This document is a work in progress; we invite you to participate on 
   the mailing list at http://www.postel.org/rbridge 

Table of Contents 

    
   1. Introduction...................................................2 
   2. The Problem....................................................4 
      2.1. Inefficient Paths.........................................4 
      2.2. Convergence Under Reconfiguration.........................6 
      2.3. Robustness to Link Interruption...........................7 
      2.4. Problems Not Addressed....................................7 
   3. Desired Properties of RBridges.................................8 
      3.1. No Change to Link Capabilities............................8 
      3.2. Zero Configuration and Zero Assumption....................8 
      3.3. Forwarding Loop Mitigation................................9 
      3.4. Spanning Tree Management..................................9 
      3.5. Multiple Attachments.....................................10 
      3.6. VLAN Issues..............................................10 
      3.7. Equivalence..............................................10 
      3.8. Optimizations............................................10 
      3.9. Internet Architecture Issues.............................11 
   4. Applicability.................................................11 
   5. Security Considerations.......................................12 
   6. IANA Considerations...........................................13 
   7. Conclusions...................................................13 
   8. Acknowledgments...............................................13 
      8.1. Normative References.....................................13 
      8.2. Informative References...................................13 
   Author's Addresses...............................................14 
   Intellectual Property Statement..................................14 
   Disclaimer of Validity...........................................15 
   Copyright Statement..............................................15 
   Acknowledgment...................................................15 
    
1. Introduction 

   [CAVEAT: this document is in very rough form. Input and feedback is 
   solicited] 
 
 
Touch                    Expires May 4, 2006                   [Page 2] 

Internet-Draft    RBridge: Problem and Applicability      November 2005 
    

   Conventional Ethernet link subnets have a number of attractive 
   features, allowing hosts and routers to relocate within the subnet 
   without requiring renumbering and are automatically configuring. 
   Unfortunately, the basis of the simplicity of these subnets is the 
   spanning tree, which although simple and elegant, can have 
   substantial limitations. 
GI> In subnets with high host reattachment 
   frequency, convergence of the spanning tree protocol can be slow. 
   This is not true with RSTP, hosts are leaf nodes that do not affect the protocol.


   Because all traffic flows over a single tree,
GI> This ignores the current work at IEEE on Shortest Path Bridging and other 
   proposals with multiple spanning trees.
   
   all traffic is 
   concentrated on a subset of links, increasing susceptibility to the 
   effects of link failures and limiting the bandwidth across the 
   subnet. 

   [I use the term Ethernet link subnets; do I need to define this? It's 
   not a segment, which I think of as being shared or hubbed but not 
   bridged]

GI> May be the term Ethernet switched subnets would be more illustrative. 

   The alternative to an Ethernet link subnet is often a network 
GI>  LAYER
  subnet. 
   Network subnets can use link-state routing protocols that allow 
   traffic to traverse least-cost paths rather than being aggregated on 
   a spanning tree backbone, providing higher aggregate capacity and 
   more resistance to link failures. Unfortunately, IP - the dominant 
   network layer technology - requires that hosts be renumbered when 
   relocated in different network subnets, interrupting network (e.g., 
   tunnels, IPsec) and transport (e.g., TCP, UDP) associations that are 
   in progress during the transition.  

   It is thus useful to consider a new approach that combines the 
   features of these two existing solutions, hopefully retaining the 
   desirable properties of each. Such an approach would develop a new 
   kind of bridge system that was capable of using network-style 
   routing, while still operating at the link layer.  

   This document describes the challenge of such a combined approach in 
   detail and proposes one solution called an "RBridge". RBridges are 
   bridge-like, link layer devices that aggregate with other rbridges on 
   the same Ethernet link subnet to create a single, virtual device 
   called an "RBridge campus". An Rbridge campus uses the subnet as the 
   substrate for an encapsulation overlay network. Within that network, 
   the campus uses variants of network layer link state routing 
   protocols to enable shortest-path forwarding, robust reaction to link 
   failures, and more rapid reaction to host reattachment. 

GI> Again the above paragraph describes more the solution than the problem.

   The remainder of this document makes as few assumptions about the 
   rbridge architecture, but a review of some terms will be useful. Note 
   that these terms assume only that an rbridge campus is an aggregation 
   of devices that act as a unit: 

 
 
Touch                    Expires May 4, 2006                   [Page 3] 

Internet-Draft    RBridge: Problem and Applicability      November 2005 
    

   o  Rbridge: a single rbridge device which can aggregate with other 
      rbridge devices to create a campus 

   o  Rbridge campus: a set of rbridges acting in unison 

GI > May be the terms RBridge *pool* or *set* (or another one) are less confusing than "campus"

   o  Inside a campus (internal): describes communication between 
      rbridge devices; this communication may traverse external devices, 
      but is still considered internal 

   o  Outside a campus (external): describes communication on the non-
      rbridge components of an Ethernet link subnet, notably not between 
      rbridges or between non-rbridges and rbridges 
GI> I think the terms are confusing. Both RBridges and STD bridges belong 
	to the campus. The campus is not owned by RBridges. 
     InterRBridge and interStd bridge communication would me more clear terms.  

   o  Edge of a campus: describes rbridges that transit traffic from 
      outside the campus to inside, and vice-versa
 
GI> As long as "internal" and "external" do not have physical/topological sense
     this is confusing. (It sounds a bit metaphorically as a "Moebius surface/tape" :-))

   [NOTE - I think a campus is *just* the set of rbridges, and that the 
   Ethernet link subnet is the 'rest of the network'; some others have 
   used the term 'campus' to refer to what I (and some others in the 
   IETF, I think) think of as the Ethernet link subnet - is this 
   confusing? If so, is there a better set of terms? Is 'campus' a term 
   that is better avoided?] 
GI> Yes. Better to avoid the term "campus".

2. The Problem 

   Ethernet subnets have evolved from 'thicknet' to 'thinnet' to twisted 
   pair with hubs to twisted pair with switches, becoming increasingly 
   simple to wire and manage. Each level has corresponding topology 
   restrictions; thicknet is inherently linear, whereas thinnet and hub-
   connected twisted pair have to be wired as a tree. Switches allow 
   network managers to avoid thinking in trees, where the spanning tree 
   protocol finds a valid tree automatically; unfortunately, this 
   additional simplicity comes with a number of associated penalties. 

   The spanning tree often results in inefficient use of the link 
   topology; traffic is concentrated on the spanning tree path, and all 
   traffic follows that path even when other more direct paths may be 
   available. The spanning tree configuration is affected by even small 
   topology changes, and small changes can have large effects. 

GI> Explain how these small changes have large effects. 

   Each of these inefficiencies can cause problems for current link layer 
   deployments. 

2.1. Inefficient Paths 

   The Spanning Tree Protocol (STP) helps break cycles in a set of 
   interconnected bridges, but it also can limit the bandwidth among 
   that set and cause traffic to take circuitous paths. 
 
 
Touch                    Expires May 4, 2006                   [Page 4] 

Internet-Draft    RBridge: Problem and Applicability      November 2005 
    

   Consider the network shown in Figure 1, which shows a number of 
   bridges and their interconnecting links. End hosts and routers are 
   not shown; they would connect to the bridges that are shown, labeled 
   A-H. Note that the network shown has cycles which would cause packet 
   storms if hubs (repeaters) were used instead of STP-capable bridges. 
   One possible spanning tree is shown by double lines. 

                           B=======\\     C                                 
                         // \       \\  / \\   D                          
                        //   \       \\/   \\ //                          
                        A-----\-------H===== E                             
                               \     //     || 
                                \   //      ||                             
                                 \ //       ||                             
                                  G----------F                             
                                                                    
             Figure 1 Bridged subnet with spanning tree shown 

   The spanning tree limits the capacity of the resulting subnet. Assume 
   that the links are 100 Mbps. Figure 2 shows how traffic from hosts on 
   A to hosts on C goes via the spanning tree path A-B-H-E-C (links 
   replaced with '1' in the figure); traffic from hosts on G to F go via 
   the spanning three path G-H-E-F (links replaced by '2' in the 
   figure). The link H-E is shared by both paths (alternating '1's and 
   '2's), resulting in an aggregate capacity for both A..C and G..F 
   paths of a total of 100 Mbps.  

                           B11111111      C                                 
                          1         1      1                              
                         1           1      1                            
                        A             H121212E                             
                                     2       2 
                                    2        2                             
                                   2         2                             
                                  G          F                             
                                                                    
         Figure 2 Traffic from A..C (1) and G..F (2) share a link 

   If traffic from G to F were to go directly using full routing, e.g., 
   from G-F, both paths could have 100 Mbps each, and the total 
   aggregate capacity could be 200 Mbps (Figure 3). In this case, the H-
   F link carries only A-C traffic ('1's) and the G-F traffic ('2's) is 
   more direct. 




 
 
Touch                    Expires May 4, 2006                   [Page 5] 

Internet-Draft    RBridge: Problem and Applicability      November 2005 
    

                           B11111111      C                                
                          1         1      1   D                          
                         1           1      1                            
                        A             H111111E                             
                                               
                                                                           
                                                                           
                                  G2222222222F                             
                                                                    
       Figure 3 Traffic from A..C (1) and G..F (2) with full routing 

   There are a number of features of modern layer 3 routing protocols 
   which would be beneficial if available at layer 2, but which cannot 
   be integrated into the spanning tree system.

GI> This again ignores the works on self rooted multiple spanning trees.
  
   Multipath routing can distribute load simultaneously among two different paths; alternate 
   path routing supports rapid failover to backup paths. Layer 3 routing 
   typically optimizes paths between pairs of endpoints, conventionally 
   based on hopcount but also including bandwidth, latency, or other 
   policy metrics. 

2.2. Convergence Under Reconfiguration 

   The spanning tree is dependent on the way a set of bridges are 
   interconnected, i.e., the link layer topology. Small changes in this 
   topology can cause large changes in the spanning tree. 
GI> This needs more justification
   Changes in the 
   spanning tree can take time to propagate and converge. 

GI> This is not the case with RSTP, comparable or faster than IS-IS.
GI> The assertion may also backfire: RBRidges may depend on STP convergence
   to communicate between them.


   [QUESTION: is there a good visual example of this, one that we can 
   walk through in the description?] 

   [QUESTION: What is the timescale? O(# bridges)? O(#links?), etc?] 

   [QUESTION: is port autolearning in this category too? i.e., are 
   rbridges trying to hide port reattachment from other nodes (or is 
   that even necessary?)] 

   The spanning tree protocol is inherently global to an entire layer 2 
   subnet; there is no current way to contain, partition, or otherwise 
   factor the protocol into a number of smaller, more stable subsets 
   that interact as groups. Contrast this with Internet routing, which 
   includes both intradomain and interdomain variants, split to provide 
   exactly that containment and scalability within a domain while 
   allowing domains to interact freely independent of what happens 
   inside.  

GI> This seems to ignore or not appreciate precisely MSTP *regions*
   capabilities and perhaps does not correspond to the current situation 
  with Provider Bridges (802.1ad/.1ah), although these exceed the campus environment.
   I am not expert on that, though. Besides this we should mention means for scalability such as encapsulation (MAC in MAC, Q-in-Q, CMAN, etc)used by L2VPNs.
     I meab that the statement "there is no current way to ..." is very general and questionnable.

 
Touch                    Expires May 4, 2006                   [Page 6] 

Internet-Draft    RBridge: Problem and Applicability      November 2005 
    

   [QUESTION: anybody have a convenient reference for a proof? Are new 
   spanning tree protocols not considering AS-like boundaries? (just 
   checking)] 

2.3. Robustness to Link Interruption 

   Persistent changes to the link topology, as described in Section 2.2, 
   are not the only effects on subnet stability. Transient link 
   interruptions have similar effects, with similar scalability issues. 
   It would be more useful for subnet configuration to be tolerant of 
   such transients, e.g., supporting alternate, backup paths. 

GI> RSTP has some mechanisms for that. Multiple spanning trees may also
    implement such mechanisms.

   [QUESTION: is there more to say here?] 

   Contrast this to network layer intradomain and interdomain routing, 
   both of which include provisions for backup paths. These backups 
   allow routing to be more stable in the presence of transients, as 
   well as to recover more rapidly when the transient disappears. 

2.4. Problems Not Addressed 

GI> May be there are too many problems not addressed. The scale of the 
   Ethernet link subnet is one of the most difficult to justify as the
   size is continuosly increasing.   

   There are other challenges to deploying bridged link layer subnets 
   that are not addressed in this document. These include: 

   [NOTE: these are guesses; if any are wrong, we can move or revise] 

   o  increased Ethernet link subnet scale 

   o  increased node relocation 

   o  Ethernet link subnet management protocol security 

   o  flooding attacks on a Ethernet link subnet 

   Rbridges are not intended to support increasingly larger scales of 
   Ethernet link subnets than current spanning tree protocols can 
   support. This may be a side-effect of supporting more rapid reaction 
   to subnet reconfiguration or multiple internal paths, or of the 
   grouped modularity an rbridge campus affords, but is not the focus of 
   this work. 

   Similarly, rbridges are not intended to solve the problem of link 
   layer node migration, which can complicate the caches in learning 
   bridges. Similar challenges exist in the ARP protocol, where link 
   layer forwarding is not updated appropriately when nodes move to 
   ports on other bridges. Again, although the grouped modularity of 
   rbridges, like that of network layer ASes, can help hide the effect 
 
 
Touch                    Expires May 4, 2006                   [Page 7] 

Internet-Draft    RBridge: Problem and Applicability      November 2005 
    

   of migration. That is a side effect, however, and not a primary focus 
   of this work. 

   Current link control plane protocols, including Ethernet link subnet 
   management (STP) and link/network integration (ARP), are vulnerable 
   to a variety of attacks. Rbridges are not intended to directly 
   address these vulnerabilities. Similar attacks exist in the data 
   plane, e.g., source address spoofing, single address traffic attacks, 
   traffic snooping, and broadcast flooding. Rbridges do not address any 
   of these issues, although it is critical that they do not introduce 
   new vulnerabilities in the process (see Section 5). 

3. Desired Properties of RBridges 

   RBridges are a link layer device system intended to address the above 
   problems. The architecture of rbridges is presented in a separate 
   document; this document is intended to motivate their utility. The 
   remainder of this section describes some of the desirable or required 
   properties of any system that would solve the above problems, 
   independent of the details of such an architecture. Most of these are 
   based on retaining useful properties of bridges, or maintaining those 
   properties while solving the problems listed in Section 2. 

3.1. No Change to Link Capabilities 

   There must be no change to the service that Ethernet subnets already 
   provide as a result of deploying an rbridge campus. Ethernet supports 
   unicast, broadcast, and multicast natively. Although network 
   protocols, notably IP, can tolerate link layers that do not provide 
   all three, it would be useful to retain the support already in place 
   [6]. Zeroconf, as well as existing bridge autoconfiguration, are 
   dependent on broadcast as well. 

   There are subtle implications to such a requirement. Bridge 
   autolearning already is susceptible to moving nodes between ports, 
   because previously learned associations between port and link address 
   change. An rbridge campus could be similarly susceptible to such 
   changes, notably to the extent that edge rbridges learn such 
   associations. 

3.2. Zero Configuration and Zero Assumption 

   Both bridges and hubs are zero configuration devices; hubs having no 
   configuration at all, and bridges being automatically self-
   configured. Bridges are further zero-assumption devices, unlike hubs. 
   Bridges can be interconnected in arbitrary topologies, without regard 
   for cycles or even (inadvertent) self-attachment. STP removes the 
 
 
Touch                    Expires May 4, 2006                   [Page 8] 

Internet-Draft    RBridge: Problem and Applicability      November 2005 
    

   impact of cycles automatically, and port autolearning reduces 
   unnecessary broadcast of unicast traffic.  

   Rbridges should strive to have similar zero configuration, zero 
   assumption operation. This includes having rbridges automatically 
   discover other rbridges and organize themselves into a campus, as 
   well as to configure that campus for proper operation (plug-and-
   play). It also includes zero configuration backward compatibility 
   with existing bridges and hubs, which may include interacting with 
   some of the bridge protocols, such as STP. 

   Autoconfiguration extends to optional services, such as multicast 
   support via IGMP snooping, broadcast support via internal serial 
   copy, and supporting multiple VLANs. 
GI> This assertion may be misleading, it seems that VLANs will not require configuration
   and the current assumption is that somehow the VLANs are configured externally
    to RBridges.

3.3. Forwarding Loop Mitigation 

   Spanning tree avoids forwarding loops by design, even during update 
   (?). Rbridges are intended to use adapted network layer routing 
   protocols which may introduce transient loops during routing 
   convergence. Rbridges thus need support for mitigating the effect of 
   such routing loops. 

   In the Internet, loop avoidance is provided by a decrementing 
   hopcounts (TTL); in other networks, packets include a trace 
   (serialized or unioned) of visited nodes [1]. These mechanisms 
   (respectively) limit the impact of loops or detect them explicitly. A 
   mechanism with similar effect should be included in the rbridge. 

   [QUESTION: anyone have a good reference for serialized or union 
   traces - or better names for them?] 

3.4. Spanning Tree Management 

   In order to address convergence under reconfiguration and robustness 
   to link interruption (Sections 2.2 and 2.3), participation in the STP 
   must be carefully managed. The goal is to provide the desired 
   stability inside the campus and of the entire Ethernet link subnet 
   while not interfering with the operation of STP outside the campus. 
   This may involve rbridge campuses participating in the STP, where 
   internally a more stable protocol is run such that the interactions 
   between the campus and external STP is dampened, or it may involve 
   severing the external STP into separate STPs on 'stub' external 
   Etehrnet link subnet segments. 

   [we need pictures here; to appear in the next version] 

 
 
Touch                    Expires May 4, 2006                   [Page 9] 

Internet-Draft    RBridge: Problem and Applicability      November 2005 
    

3.5. Multiple Attachments 

   [QUESTION: I'm not sure what this refers to; is it the same NIC 
   attached at different points to the rbridge? If so, why should this 
   be possible where it seems ignored in bridges 

3.6. VLAN Issues 

   An rbridge campus should support multiple VLANs. This may involve 
   ignorance, just as many bridge devices do not participate in the VLAN 
   protocols. It may alternately support direct VLAN support, e.g., by 
   the use of separate internal routing protocol instances to separate 
   traffic for each VLAN inside the campus. 

   [QUESTION: is it possible to be ignorant of VLANs and still operate? 
   Bridges are, right?] 
GI> Right. All VLANs traffic is handled(forwarded) in the same way through the
  network, not the separate disjoint VLANs)

3.7. Equivalence 

   As with any extension to an existing architecture, it would be useful 
   - though not strictly necessary -  to be able to describe or consider 
   the rbridge campus as a model of an existing link layer component. 
   Such equivalence provides a validation model for the architecture. 

GI> Useful. The problem to find a model is that the rbridge campus is 
   an abstraction, rbridges are interconnected via std bridges. It is 
   the same confussion than "internal" and "external". 

   This provides a sanity check, i.e., "we got it right if we can 
   replace an rbridge campus with an X" (where "X" might be a single 
   bridge, a hub, or some other link layer abstraction). It does not 
   matter whether "X" can be implemented on the same scale as the 
   corresponding rbridge campus. It also does not matter if it can - 
   there may be utility to deploying the rbridge campus components 
   incrementally, in ways that a single "X" could not be installed. 

   For example, if an rbridge campus were equivalent to a single bridge, 
   it would mean that the campus would - as a whole - participate in the 
   STP. This need not require that the rbridge would propagate STP 
   internally, any more than a bridge need do so in its on-board 
   control. It would mean that the campus would interact with BPDUs at 
   the edge, where the campus would - again, as a whole - participate as 
   if a single node in the spanning tree. Note that this equivalence is 
   not required; a campus may act as if a hub, or may not have a 
   corresponding equivalent link layer component at all. 

3.8. Optimizations 

   There are a number of optimizations that may be applied to rbridge 
   systems. These must be applied in a way that does not affect 
   functionality as a tradeoff for increased performance. Such 
 
 
Touch                    Expires May 4, 2006                  [Page 10] 

Internet-Draft    RBridge: Problem and Applicability      November 2005 
    

   optimizations address broadcast and multicast frame distribution, 
   VLAN support, and snooping of ARP and IPv6 neighbor discovery. 

   [NOTE: need to say more here.] 

3.9. Internet Architecture Issues 

   Rbridges are intended to have no impact on the Internet network layer 
   architecture. In particular, the Internet and higher layer headers 
   should remain intact when traversing an rbridge, just as they do when 
   traversing any other link subnet technologies. This means that the IP 
   TTL field cannot be co-opted for forwarding loop mitigation, as it 
   would interfere with the Internet layer assuming that the link subnet 
   was reachable with no changes in TTL (Internet TTLs are changed only 
   at routers, as per RFC 1812) [1]. 

   Rbridges should also have no impact on Internet routing or signalng, 
   which also means that broadcast and multicast, both of which can 
   pervade an entire Ethernet link subnet, must be able to transparently 
   pervade an rbridge campus. Changing how either of these capabilities 
   behaves would have significant effects on a variety of protocols, 
   including RIP (broadcast), RIPv2 (multicast), ARP (broadcast), IPv6 
   neighbor discovery (multicast), etc. 

   Note that snooping of network layer packets may be useful, especially 
   for certain optimizations. These include snooping multicast control 
   plane packets (IGMP) to tune link multicast to match the network 
   multicast topology, as is already done in existing smart switches 
   [3]. This also includes snooping IPv6 neighbor discovery messages to 
   assist with governing campus edge configuration, as is the case in 
   some smart learning bridges [7]. Other layers may similarly be 
   snooped, notably ARP packets, for similar reasons for IPv4 [11]. 

4. Applicability 

   As might be expected, rbridges are intended to be used to solve the 
   problems described in Section 2. However, not all such installations 
   are appropriate environments for rbridge campuses. This section 
   outlines the issues in the appropriate use of rbridges. 

   Rbridges are intended to address problems of path efficiency and 
   stability within a single Ethernet link subnet. Like bridges, 
   individual rbridge components should find other rbridge components 
   within a single Ethernet link subnet and aggregate into a single 
   rbridge campus. Campuses are not intended to span separate Ethernet 
   link subnets where interconnected by network layer (e.g., router) 
   devices, except via link layer tunnels that are in place prior to 
 
 
Touch                    Expires May 4, 2006                  [Page 11] 

Internet-Draft    RBridge: Problem and Applicability      November 2005 
    

   their deployment, where such tunnels render the distinct subnet 
   undetectably equivalent from a single Ethernet link subnet. 

   A currently open question is whether a single Ethernet link subnet 
   should contain only one rbridge campus, either of necessity of 
   architecture or utility. Multiple rbridge campuses, like Internet 
   ASes, may allow internal routing protocols to be partitioned in ways 
   that help their stability, but this may come at the price of needing 
   the rbridge campuses to participate more fully as nodes (each 
   modeling a bridge) in the Ethernet link subnet STP. Each architecture 
   solution should decide whether multiple rbridges are supported within 
   a single Ethernet link subnet and mechanisms should be included to 
   enforce whatever decision is made. 

   Rbridges are not intended to address scalability limitations in 
   bridged subnets. Although there may be scale benefits of other 
   aspects of solving rbridge problems, e.g., of using network layer 
   routing to provide stability under link changes or intermittent 
   outages, this is not a focus of this work. 

   As also noted earlier, rbridges are not intended to address security 
   vulnerabilities in either the data plane or control plane of the link 
   layer. This means that rbridges should not limit broadcast frames, 
   ARP requests, or spanning tree protocol messages (if such are 
   interpreted by the campus or campus edge). 

5. Security Considerations 

   Rbridges should not introduce new vulnerabilities compared to 
   traditional bridged subnets.  

   Rbridges are not intended to be a solution to Ethernet link subnet 
   vulnerabilities, including spoofing, flooding, snooping, and attacks 
   on the link control plane (STP, flooding the learning cache) and 
   link-network control plane (ARP). Although rbridges are intended to 
   provide more stable routing than STP, this stability is limited to 
   performance, and the subsequent robustness is intended to address 
   non-malicious events. 

   There may be some side-effects to the use of rbridges that can 
   provide more robust operation under certain attacks, such as those 
   interrupting link service, but rbridges should not be relied upon for 
   such capabilities. 

   Finally, rbridges should not interfere with other protocols intended 
   to address these vulnerabilities, such as those under development to 
   secure IPv6 neighbor discovery.  
 
 
Touch                    Expires May 4, 2006                  [Page 12] 

Internet-Draft    RBridge: Problem and Applicability      November 2005 
    

   [need a ref for secure ipv6 nd] 

6. IANA Considerations 

   This document has no IANA considerations.

GI> This need explanation. I doubt if this can be stated now. An L2
   "all RBridges multicast address" is required or using an IS-IS multicast address
   suffices.  

   This section should be removed by the RFC Editor prior to final 
   publication. 

7. Conclusions 

   (TBA) 

8. Acknowledgments 

   Large portions of this document are based on and/or copied from a 
   preliminary description document with permission from the authors 
   [10]. 

8.1. Normative References 

   None. 

8.2. Informative References 

   [1]   Baker, F., "Requirements for IP Version 4 Routers", RFC 1812 
         (Standards Track), June 1995. 

   [2]   Braden, R., "Requirements for Internet Hosts - Communication 
         Layers", STD 3, RFC 1122, October 1989. 

   [3]   Cain, B., S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan, 
         "Internet Group Management Protocol, Version 3," RFC 3376 
         (Proposed Standard), October 2002. 

   [4]   Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual 
         environments", RFC 1195, December 1990. 

   [5]   IEEE 802.1d bridging standard, "IEEE 802.1d bridging standard". 

   [6]   P. Karn (ed.), C. Bormann, G.Fairhurst, D. Grossman, R. Ludwig, 
         J. Mahdavi, G. Montenegro, J. Touch, L. Wood, "Advice for 
         Internet Subnetwork Designers," RFC-3819 / BCP 89, July 2004. 

   [7]   Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 
         for IP Version 6 (IPv6)", RFC 2461 (Standards Track), December 
         1998. 
 
 
Touch                    Expires May 4, 2006                  [Page 13] 

Internet-Draft    RBridge: Problem and Applicability      November 2005 
    

   [8]   Perlman, R., "RBridges: Transparent Routing", Proc. Infocom 
         2005, March 2004. 

   [9]   Perlman, R., "Interconnection: Bridges, Routers, Switches, and 
         Internetworking Protocols", Addison Wesley Chapter 3, 1999. 

   [10]  Perlman, R., J. Touch, A. Yegin, "RBridges: Transparent 
         Routing," (work in progress), Apr. 2004 - May 2005. 

   [11]  Plummer, D., "Ethernet Address Resolution Protocol: Or 
         converting network protocol addresses to 48.bit Ethernet 
         address for transmission on Ethernet hardware", STD 37, RFC 826 
         (Standard), November 1982. 

   [12]  Touch, J., (ed.), "RBridge Architecture," (work in progress). 

   [13]  Touch, J., Wang, Y., Eggert, L. and G. Finn, "A Virtual 
         Internet Architecture", ISI Technical Report ISI-TR-570, 
         Presented at the Workshop on Future Directions in Network 
         Architecture (FDNA) 2003 at Sigcomm 2003, March 2003. 

   [14]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 
         November 1990. 

   [15]  Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923 
         (Informational), September 2000. 

Author's Addresses 

   Joe Touch 
   USC/ISI 
   4676 Admiralty Way 
   Marina del Rey, CA 90292-6695 
   U.S.A. 
       
   Phone: [phone] 
   Email: [e-mail] 
   URL:   http://www.isi.edu/touch 
    

Intellectual Property Statement 

   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
 
 
Touch                    Expires May 4, 2006                  [Page 14] 

Internet-Draft    RBridge: Problem and Applicability      November 2005 
    

   made any independent effort to identify any such rights.  Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 

   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 

   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at 
   [e-mail]. 

Disclaimer of Validity 

   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

Copyright Statement 

   Copyright (C) The Internet Society (2005). 

   This document is subject to the rights, licenses and restrictions 
   contained in BCP 78, and except as set forth therein, the authors 
   retain all their rights. 

Acknowledgment 

   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 

    






 
 
Touch                    Expires May 4, 2006                  [Page 15] 


--------------040105060508070308050508--


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 jA50bbM06529; Fri, 4 Nov 2005 16:37:37 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 04 Nov 2005 16:35:36 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Proposed agenda
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 00:38:46 -0000
Status: RO
Content-Length: 2090

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



Erik Nordmark wrote:
> Harald Tveit Alvestrand wrote:
> 
>>.... what are the base specifications ....?
> 
> 
> It refers to Joe Touch'es work to split draft-perlman-rbridge into 3 
> separate documents, which the WG can then work on in parallel.
> The split drafts do not exist in the I-D directory. I've asked Joe to 
> make them available in their current form on some other web server, so 
> that folks can see how the work is progressing, even though the 
> documents are not finished.
> 
> At a minimum we'll get a status update from Joe (I assume), but there 
> might be issues worth discussing.

There should be three docs:

	Problem and Applicability Statement
		just focus on defining the problem, making as few
		assumptions about architecture and protocol as
		possible; the goal is to allow alternate solutions,
		so long as the problem is satisfied. we don't want
		a 'hammer looking for a nail' -- this is just the nail.

	Architecture
		this describes the architecture of the proposed solution
		while making as few assumptions about particulars of
		the protocol as possible

	Protocol
		this focuses on the particulars of the solution's
		protocols based on the architecture

I had offered to work on the drafts of the first two, based on the
existing ID. The first one doesn't actually borrow that much text; the
second is more direct, though.

A draft of the first document is now available on the website:
	http://www.postel.org/rbridge

I've submitted it as an ID just to provide a basic draft-touch-*-00 to
have diffs off of later; any feedback from the meeting or list will end
up in the draft-touch-*-01, or if it is OK to become a WG doc, the
draft-ietf-trill-*-00.

The second document will be available shortly (hopefully Sun PM at the
absolute latest).

Joe

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

iD8DBQFDa/5YE5f5cImnZrsRAnepAKDmES5FjG3OGGJhlXOL92DvK7qlwQCfZrkk
Ho2X6fO7G8H8k8imkznnIbU=
=JRbC
-----END PGP SIGNATURE-----


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA4KafM25334 for <[e-mail]>; Fri, 4 Nov 2005 12:36:41 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 04 Nov 2005 12:36:35 -0800 (PST)
Received: from sun.com ([129.150.27.180]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 04 Nov 2005 12:36:35 -0800 (PST)
Date: Fri, 04 Nov 2005 12:36:43 -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
References: <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Proposed agenda
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 20:37:16 -0000
Status: RO
Content-Length: 423

That document is a new idea to shrink the shim header into 4 bytes. I 
think it would be
good to have that on the agenda. I didn't volunteer because I won't be 
at this IETF, but it
would be great if one of the other coauthors would volunteer to present it.

Radia



Harald said:

>  
>
>>draft-bryant-perlman-trill-pwe-encap-00 doesn't seem complete.... do you 
>>count it as part of the base, or not?
>>    
>>
>
>  
>



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 jA4EBsM27460 for <[e-mail]>; Fri, 4 Nov 2005 06:11:54 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.56.36]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jA4EBsD7029310 for <[e-mail]>; Fri, 4 Nov 2005 07:11:54 -0700 (MST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jA4EBmDB572935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 4 Nov 2005 06:11:52 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 04 Nov 2005 05:11:43 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
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-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Proposed agenda
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 14:12:11 -0000
Status: RO
Content-Length: 751

Harald Tveit Alvestrand wrote:
> .... what are the base specifications ....?

It refers to Joe Touch'es work to split draft-perlman-rbridge into 3 
separate documents, which the WG can then work on in parallel.
The split drafts do not exist in the I-D directory. I've asked Joe to 
make them available in their current form on some other web server, so 
that folks can see how the work is progressing, even though the 
documents are not finished.

At a minimum we'll get a status update from Joe (I assume), but there 
might be issues worth discussing.

> draft-bryant-perlman-trill-pwe-encap-00 doesn't seem complete.... do you 
> count it as part of the base, or not?

I've never heard of that document before. It is not part of the base.

    Erik


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 jA45suM24320 for <[e-mail]>; Thu, 3 Nov 2005 21:54:56 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 33DAC9DF09 for <[e-mail]>; Fri,  4 Nov 2005 06:54:50 +0100 (CET)
Received: from [163.117.203.247] (unknown [163.117.203.247]) by smtp01.uc3m.es (Postfix) with ESMTP id 077599DEAD for <[e-mail]>; Fri,  4 Nov 2005 06:54:49 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 04 Nov 2005 06:54:48 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
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]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] RB core Subcase for RBridges?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 05:55:56 -0000
Status: RO
Content-Length: 9309

Eric,
        I see "interior" or "core" mode as an optional, simplified 
protocol variant, not oriented to coexist with normal mode.
See below.
Gray, Eric wrote:

>Guillermo,
>
>	I've omitted the portions of the discussion below that
>we probably don't need to continue.  Hopefully, I've not taken
>out too much of the context.  :-)
>
>--
>E
>
>--- [SNIP] ---
>
>--> 
>--> Eric,
>-->        The basics of the proposal is that RBridges that hear RBridge 
>--> frames at one port assume there are RBridges connected to them, 
>--> although they might be connected  via "B" bridges with point to point 
>--> links. RBridges hearing RBridge type frames at one port assume the 
>--> "core" port mode. In the "core" port mode, the RBridge routes whithout  
>--> DA address change the encapsulated frames received at other RBridge core
>
>--> ports via corresponding core port to destination RBridge. 
>-->
>--> If the RBridge y does not hear RBridge type frames at that port or it 
>--> knows (by the attached B bridge port data or by another mechanism) that
>
>--> the port is attached to a shared link, it sets the port in
>"distribution" 
>--> mode. The ports in distribution mode or distribution ports only act as 
>--> ingress/egress to the core.
>-->
>
>Where "another mechanism" probably refers to configuration?
>
>  
>
I meant RBridge accessing  info on that port, not configuration info 
specifically, although it might include it.

>-->
>-->      I think that with this arrangement, the "inside" and "outside" of 
>--> the core are clearly defined. See below some more comments
>-->
>--> Guillermo
>-->
>
>--- [SNIP] ---  
>
>--> >-->
>--> >--> Although changing destination address at each hop is not too 
>--> >--> complicated, this  is something that even routers do not 
>--> >--> do, they keep the IP source and destination addresses of 
>--> >--> packets.
>--> >
>--> >Not sure how this is relevant, but routers always re-write the 
>--> >MAC SA/DA when forwarding IP packets. 
>--> >
>-->
>--> This occurs because the layer 2 difussion domain changes.
>--> 
>
>It is slightly more accurate to say that this happens because 
>routers are not transparent at layer 2.  A router re-writes the
>MAC SA/DA even when forwarding IP packets onto the same layer 2
>diffusion domain.  
>
>In any case, I think we agree that this is a not particularly
>relevant side discussion.
>  
>
I agree. It is a non relevant discussion.

>--- [SNIP] ---
>
>--> >--> >
>--> >--> >                                            +------------+
>--> >--> >      +------------------------+            |    +---+   |
>--> >--> >      |                        |            | +--+ B +-+ |
>--> >--> >      |  +---+  +----+  +---+  |            | |  +---+ | |
>--> >--> >   ---+--+ B +--+ RB +--+ B +--+---      ---+-+        +-+---
>--> >--> >      |  +---+  +----+  +---+  |            | | +----+ | |
>--> >--> >      |                        |            | +-+ RB +-+ |
>--> >--> >      +------------------------+            |   +----+   |
>--> >--> >              Hybrid A                      +------------+
>--> >--> >    						Hybrid B
>--> >--> >
>--> >--> Is Hybrid B  allowed?
>--> >
>--> >I don't know that it makes sense, but - if you remove the outer
>--> >box and consider the B and RB as separate boxes - it is certainly
>--> >one of the potential scenarios we've talked about.  Since it can
>--> >happen outside the box, I see no particular reason to put on the
>--> >blinkers for the possibility of it happening inside the box.
>--> >
>--> >Also, Hybrid B is one view of what you're talking about, since
>--> >what would normally be the next hop RBridge has to "bridge" the
>--> >MAC frames it receives that are not addressed to it in what you
>--> >are talking about.
>--> >
>--> >Take this example:
>--> >
>--> >    H1 ---> RB1 <---> RB2 <---> RB3 <--- H2
>--> >
>--> >As I understand it, you propose that RB1 might encapsulate a frame
>--> >coming from H1 and going to H2 with SA/DA = RB1/RB3 rather than
>--> >SA/DA = RB1/RB2.  What that means is that RB2 has to bridge those
>--> >frames from RB1 to RB3 as - otherwise -  it would simply ignore 
>--> >any frame not addressed to it.
>--> >  
>--> >
>--> No. It means RB2 *routes* those frames in the same way  (with IS- IS) 
>--> but it does not change the DA.
>-->
>
>Independent of option complexity, there are a few problems with this 
>approach:
>
>   1) Reachability information distributed via IS-IS is for H1, H2 and
>	similar MAC addresses. It will include RB1, RB2 and RB3 (and like)
>	addresses, but that is not the purpose.  RB1, on receiving a frame
>	for H2 needs to know how to route the frame across the RBridge
>	campus.  As a result of having reachability data on RB3, RB1 could
>	use RB3 as the DA, when sending it to RB2, and RB2 could forward 
>	the frame to RB3.  But this is a strictly tunneling approach as 
>	opposed to a routing approach, for two reasons -
>	a)	it is not done using (H2) destination-based hop-by routing,
>  
>
Destination, for routing purposes, is RB2, not H2.

>	b)	it scales like a tunneling (or bridging) approach more than 
>		a hop-by-hop routing approach.
>  
>
Scaling limitation for RBridges is a consequence of using MAC (flat, non 
aggregatable addresses)  addresses instead of hierarchical addressing. 
The routing is still hop-by-hop if you consider RB2 as destination. I do 
not see the difference in scalability.

>   2) Because the ingress decides which egress the frame will use, as
>	opposed to which next-hop, more frames will be dropped or routed
>	incorrectly during a network topology change - or if a destination
>	moves - than would be the case with a hop-by-hop approach.
>  
>
I do not see much difference in the real routing decisions as long as a 
host is associated to its Designated RBridge.
The ingress doest not decide the eggress. The eggress is the Designated 
RBridge of  the destination host as announced by the egress in its hosts 
list.
The routing tables for routes between RB's (shorter) may converge after 
reconfiguration much faster than updating routing tables for all 
destination hosts.

>   3) Since each RBridge from ingress to egress now needs to be concerned
>	with forwarding to each egress in addition to (or opposed to) each
>	neighbor, RBridges will need slightly larger forwarding tables.
>  
>
Very slightly larger (number of RBridges-1), if in addition.  For 
transit  RBridges  (RBridges without hosts) much shorter tables Orders: 
O(number of  RBridges) versus O(number of hosts).

>And there are a few plusses with this approach:
>
>   A) For the campus consisting of non-shared links exclusively between
>	RBridges, only the campus ingress RBridge needs to do a look-up on
>	the original MAC DA and determine the appropriate campus egress.
>	It is not necessary for intermediate RBridges to peek beyond the 
>	outer MAC encapsulation.
>
>   B) Under those same circumstances, only ingress and egress RBridges
>	need to do anything with respect to the outer MAC encapsulation.
>
>One might be tempted to think that advantage B would allow for simpler
>"interior" RBridge implementations. However - because the definition of
>"interior" in this case is an RBridge with no external interfaces - the
>illusion of simplicity is shattered the second you hang an NMS off of a
>port on an "interior" RBridge.
>
>The minute that an implementation is required to support both a proposed 
>interior mode and the default not-so-interior mode, it's more complicated
>than if it only supported the default mode.  This is made worse if we try 
>to extend it to an environment where some campus interior links are shared 
>- while others are not - because now we need to communicate beyond adjacent 
>peers to determine if each successive peer on a path toward each egress can 
>be "skipped" (by using a downstream RBridge's MAC as DA instead). 
>
>The above discussion was "independent of option complexity".  One thing we
>all hear a lot of is that "options are bad".  Any time we have two ways of
>doing something when one would have satisfied all cases, we have made a
>mistake.
>
>Because "skipping" can't be used all the time, the hop-by-hop mode has to
>be supported.  So the question becomes is the added complexity in both the
>control and forwarding planes - across all cases - justified by a possible 
>reduction in RBridge forwarding complexity in a (possibly large) subset of
>all cases?
>  
>
I agree that both modes should be exclusive. They are not intended to 
coexist in the same campus network. It is a decision of the campus 
designer/administrator to use interior (core) mode or  normal mode in 
all RBridges. Looking for compatibility means complicating things.  The 
"interior" mode (I prefer the term "core" ),  probably fits  better as 
a  simplified but separate and alternative version of the protocol for 
high performance cores made of RBridges where compatibility with bridges 
is excluded inside the core.

Speficying "interior" mode as an *optional* mode does not complicate 
standard implementations and allows simpler implementations oriented to 
high performance  cores.

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


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA408PM25006 for <[e-mail]>; Thu, 3 Nov 2005 16:08:25 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jA408Jp1001233 for <[e-mail]>; Thu, 3 Nov 2005 19:08:19 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA11906 for <[e-mail]>; Thu, 3 Nov 2005 19:07:48 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WCKHN3FC>; Thu, 3 Nov 2005 22:07:48 -0200
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 3 Nov 2005 22:07:46 -0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] RB core Subcase for RBridges?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 00:09:10 -0000
Status: RO
Content-Length: 7006

Guillermo,

	I've omitted the portions of the discussion below that
we probably don't need to continue.  Hopefully, I've not taken
out too much of the context.  :-)

--
E

--- [SNIP] ---

--> 
--> Eric,
-->        The basics of the proposal is that RBridges that hear RBridge 
--> frames at one port assume there are RBridges connected to them, 
--> although they might be connected  via "B" bridges with point to point 
--> links. RBridges hearing RBridge type frames at one port assume the 
--> "core" port mode. In the "core" port mode, the RBridge routes whithout  
--> DA address change the encapsulated frames received at other RBridge core

--> ports via corresponding core port to destination RBridge. 
-->
--> If the RBridge y does not hear RBridge type frames at that port or it 
--> knows (by the attached B bridge port data or by another mechanism) that

--> the port is attached to a shared link, it sets the port in
"distribution" 
--> mode. The ports in distribution mode or distribution ports only act as 
--> ingress/egress to the core.
-->

Where "another mechanism" probably refers to configuration?

-->
-->      I think that with this arrangement, the "inside" and "outside" of 
--> the core are clearly defined. See below some more comments
-->
--> Guillermo
-->

--- [SNIP] ---  

--> >-->
--> >--> Although changing destination address at each hop is not too 
--> >--> complicated, this  is something that even routers do not 
--> >--> do, they keep the IP source and destination addresses of 
--> >--> packets.
--> >
--> >Not sure how this is relevant, but routers always re-write the 
--> >MAC SA/DA when forwarding IP packets. 
--> >
-->
--> This occurs because the layer 2 difussion domain changes.
--> 

It is slightly more accurate to say that this happens because 
routers are not transparent at layer 2.  A router re-writes the
MAC SA/DA even when forwarding IP packets onto the same layer 2
diffusion domain.  

In any case, I think we agree that this is a not particularly
relevant side discussion.

--- [SNIP] ---

--> >--> >
--> >--> >                                            +------------+
--> >--> >      +------------------------+            |    +---+   |
--> >--> >      |                        |            | +--+ B +-+ |
--> >--> >      |  +---+  +----+  +---+  |            | |  +---+ | |
--> >--> >   ---+--+ B +--+ RB +--+ B +--+---      ---+-+        +-+---
--> >--> >      |  +---+  +----+  +---+  |            | | +----+ | |
--> >--> >      |                        |            | +-+ RB +-+ |
--> >--> >      +------------------------+            |   +----+   |
--> >--> >              Hybrid A                      +------------+
--> >--> >    						Hybrid B
--> >--> >
--> >--> Is Hybrid B  allowed?
--> >
--> >I don't know that it makes sense, but - if you remove the outer
--> >box and consider the B and RB as separate boxes - it is certainly
--> >one of the potential scenarios we've talked about.  Since it can
--> >happen outside the box, I see no particular reason to put on the
--> >blinkers for the possibility of it happening inside the box.
--> >
--> >Also, Hybrid B is one view of what you're talking about, since
--> >what would normally be the next hop RBridge has to "bridge" the
--> >MAC frames it receives that are not addressed to it in what you
--> >are talking about.
--> >
--> >Take this example:
--> >
--> >    H1 ---> RB1 <---> RB2 <---> RB3 <--- H2
--> >
--> >As I understand it, you propose that RB1 might encapsulate a frame
--> >coming from H1 and going to H2 with SA/DA = RB1/RB3 rather than
--> >SA/DA = RB1/RB2.  What that means is that RB2 has to bridge those
--> >frames from RB1 to RB3 as - otherwise -  it would simply ignore 
--> >any frame not addressed to it.
--> >  
--> >
--> No. It means RB2 *routes* those frames in the same way  (with IS- IS) 
--> but it does not change the DA.
-->

Independent of option complexity, there are a few problems with this 
approach:

   1) Reachability information distributed via IS-IS is for H1, H2 and
	similar MAC addresses. It will include RB1, RB2 and RB3 (and like)
	addresses, but that is not the purpose.  RB1, on receiving a frame
	for H2 needs to know how to route the frame across the RBridge
	campus.  As a result of having reachability data on RB3, RB1 could
	use RB3 as the DA, when sending it to RB2, and RB2 could forward 
	the frame to RB3.  But this is a strictly tunneling approach as 
	opposed to a routing approach, for two reasons -
	a)	it is not done using (H2) destination-based hop-by routing,
	b)	it scales like a tunneling (or bridging) approach more than 
		a hop-by-hop routing approach.
   2) Because the ingress decides which egress the frame will use, as
	opposed to which next-hop, more frames will be dropped or routed
	incorrectly during a network topology change - or if a destination
	moves - than would be the case with a hop-by-hop approach.
   3) Since each RBridge from ingress to egress now needs to be concerned
	with forwarding to each egress in addition to (or opposed to) each
	neighbor, RBridges will need slightly larger forwarding tables.

And there are a few plusses with this approach:

   A) For the campus consisting of non-shared links exclusively between
	RBridges, only the campus ingress RBridge needs to do a look-up on
	the original MAC DA and determine the appropriate campus egress.
	It is not necessary for intermediate RBridges to peek beyond the 
	outer MAC encapsulation.

   B) Under those same circumstances, only ingress and egress RBridges
	need to do anything with respect to the outer MAC encapsulation.

One might be tempted to think that advantage B would allow for simpler
"interior" RBridge implementations. However - because the definition of
"interior" in this case is an RBridge with no external interfaces - the
illusion of simplicity is shattered the second you hang an NMS off of a
port on an "interior" RBridge.

The minute that an implementation is required to support both a proposed 
interior mode and the default not-so-interior mode, it's more complicated
than if it only supported the default mode.  This is made worse if we try 
to extend it to an environment where some campus interior links are shared 
- while others are not - because now we need to communicate beyond adjacent 
peers to determine if each successive peer on a path toward each egress can 
be "skipped" (by using a downstream RBridge's MAC as DA instead). 

The above discussion was "independent of option complexity".  One thing we
all hear a lot of is that "options are bad".  Any time we have two ways of
doing something when one would have satisfied all cases, we have made a
mistake.

Because "skipping" can't be used all the time, the hop-by-hop mode has to
be supported.  So the question becomes is the added complexity in both the
control and forwarding planes - across all cases - justified by a possible 
reduction in RBridge forwarding complexity in a (possibly large) subset of
all cases?

--- [SNIP] --- 


Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA3G3pM17959 for <[e-mail]>; Thu, 3 Nov 2005 08:03:51 -0800 (PST)
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 75C91258084 for <[e-mail]>; Thu,  3 Nov 2005 17:03:05 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14063-05 for <[e-mail]>; Thu,  3 Nov 2005 17:02:59 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9CA282596CE for <[e-mail]>; Thu,  3 Nov 2005 17:02:59 +0100 (CET)
Date: Thu, 03 Nov 2005 17:04:32 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Proposed agenda
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 16:04:04 -0000
Status: RO
Content-Length: 862

.... what are the base specifications ....?

draft-bryant-perlman-trill-pwe-encap-00 doesn't seem complete.... do you 
count it as part of the base, or not?

--On torsdag, november 03, 2005 07:32:19 -0800 Erik Nordmark 
<[e-mail]> wrote:

> Transparent interconnection of Lots of Links WG
>
> WEDNESDAY, November 9, 2005
> 1300-1500 Afternoon Session I
>
> Administrativia (scribe etc)		Chair		5 minutes
>
> Agenda bashing				Chair		5 minutes
>
> Base specifications			Joe Touch	40 minutes
>
>
> Routing Requirements in Support of R-Bridges
> draft-gray-rbridge-routing-reqs-00.txt	Eric Gray	20 minutes
>
> Multicast Link State For Rbidges
> draft-hares-trill-multicast-00.txt	Sue Hares	20 minutes
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
>






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 jA3FWOM08203 for <[e-mail]>; Thu, 3 Nov 2005 07:32:25 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.226.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id jA3FWOdK023515 for <[e-mail]>; Thu, 3 Nov 2005 07:32:24 -0800 (PST)
Received: from [129.157.211.214] (dhcp-gnb07-211-214.France.Sun.COM [129.157.211.214]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jA3FWMij904840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 3 Nov 2005 07:32:23 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 03 Nov 2005 07:32:19 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720)
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-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Proposed agenda
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 15:33:03 -0000
Status: RO
Content-Length: 433

Transparent interconnection of Lots of Links WG

WEDNESDAY, November 9, 2005
1300-1500 Afternoon Session I

Administrativia (scribe etc)		Chair		5 minutes

Agenda bashing				Chair		5 minutes

Base specifications			Joe Touch	40 minutes


Routing Requirements in Support of R-Bridges
draft-gray-rbridge-routing-reqs-00.txt	Eric Gray	20 minutes

Multicast Link State For Rbidges
draft-hares-trill-multicast-00.txt	Sue Hares	20 minutes



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 jA3BCdM28257 for <[e-mail]>; Thu, 3 Nov 2005 03:12:39 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5D49D9DC19 for <[e-mail]>; Thu,  3 Nov 2005 12:12:33 +0100 (CET)
Received: from [163.117.203.247] (unknown [163.117.203.247]) by smtp01.uc3m.es (Postfix) with ESMTP id 82DA19DB48 for <[e-mail]>; Thu,  3 Nov 2005 12:12:31 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 03 Nov 2005 12:12:30 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
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]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] RB core Subcase for RBridges?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 11:13:02 -0000
Status: RO
Content-Length: 13290

Eric,
       The basics of the proposal is that RBridges that hear RBridge 
frames at one port assume there are  RBridges connected to them, 
although they might be connected  via  "B" bridges with point to point 
links. RBridges hearing RBridge type  frames at one port assume the 
"core" port mode. In the "core" port mode, the RBridge routes whitout DA 
address change the encapsulated frames received at other RBridge core 
ports via corresponding core port to destination RBridge. If the RBridge 
y does not hear RBridge type frames at that port or it knows (by the 
attached B bridge port data or by another mechanism) that  the port is 
attached to a shared link, it sets the port in "distribution" mode. The 
ports  in distribution mode or distribution ports only act as 
ingress/egress to the core.
     I think that with this arrangement, the "inside" and "outside" of 
the core are  clearly defined.
See below some more comments
Guillermo
Gray, Eric wrote:

>Guillermo,
>
>	Please see below...
>
>--> -----Original Message-----
>--> From: [e-mail] 
>--> [mailto:[e-mail]]On
>--> Behalf Of Guillermo Ib??ez
>--> Sent: Wednesday, November 02, 2005 1:02 PM
>--> To: Developing a hybrid router/bridge.
>--> Subject: Re: [rbridge] Subcase for RBridges?
>--> 
>--> 
>--> Eric,
>-->      My proposal does not require RBridge to be aware of link type,  
>--> functions to  work  with bridges are implemented by the B bridge 
>--> "attached" to RB.It is a potential variant of the RBridge protocol
>--> only to be used in campuses where RBridges are directly connected
>--> between them forming  a core and do not allow standard bridges 
>--> interposed. Standard bridges are allowed only as Access Layer (any 
>--> port hearing standard STPs BPDUs runs STP).
>-->      
>--> Gray, Eric wrote:
>--> 
>--> >Guillermo,
>--> >
>--> >	I assume that - by point-to-point link - you mean full-duplex
>--> >Ethernet/802.  Since we are not trying to address L2 connectivity
>--> >other than Ethernet, that should be the case within the scope of 
>--> >discussion on this list.
>--> >
>--> >  
>--> >
>--> I mean not shared links. It may work half-duplex or full-duplex.
>
>True, assuming "shared" status can be properly determined.
>
>--> 
>--> >	It is difficult for any implementation to divine the nature of
>--> >the "wire" connecting it to another implementation - whether RBridge
>--> >or bridge.  In many cases, it is possible - for example, by looking
>--> >at port-type information and listening to both RBridge neighbor 
>--> >discovery and local STP - but not in every case.
>--> >
>--> >  
>--> >
>--> The  bridge is aware of the link type and the RSTP protocol state 
>--> machines use it. 
>--> /" 17.12 RSTP and point-to-point links
>--> The rapid transition of a Designated Port to Forwarding 
>--> depends on the Port being directly connected to at
>--> most one other Bridge [it is an Edge Port (17.3, 17.19.17),  
>--> or is attached to a point-to-point LAN, rather than a shared
>--> medium]. The adminPointToPointMAC and operPointToPointMAC 
>--> parameters (6.4.3) provide management and signalling of the 
>--> point-to-point status to RSTP state machines.
>--> A newly selected Root Port can transition to Forwarding 
>--> rapidly, even if attached to shared media."/
>--> 
>--> >	For example, the mysterious "lurking" L2 forwarding device that
>--> >participates in neither RBridge neighbor discovery, nor STP would be
>--> >invisible and - presumably - RBridges would likely be invisible to 
>--> >it as well.
>--> >
>--> >	In addition, there are a variety of transitional states in
>--> >which it is very likely that an inferred point-to-point link will 
>--> >no longer be point-to-point and the RBridges will not be aware of
>--> >that.
>--> >  
>--> >
>--> All these functions are in the B bridge attached to the RB, 
>--> RB does not need to control them.
>--> The "attached"  B as proposed by Radia has many advantages for RB 
>--> regarding compatibility in the interaction with standard bridges.
>
>Yes, and the reason why Radia brought this up was to illustrate that
>the functions are separable.  So, since we are trying to define the
>"RB" portion of the separable functions, why do we keep coming back
>to "B" functions?
>
>--> 
>--> >	However, even if all this were not true, what do we gain from
>--> >"special casing" this special case - even if it does turn out to be
>--> >common?
>--> >
>--> >  
>--> >
>--> This special casing could be a variant  for campuses where 
>--> RBridges are all connected together forming a network core,
>--> without bridges interposed between them.  Standard bridges 
>--> are only allowed at the outside of the core. This scenario 
>--> is better suited for high performance, better network 
>--> predictability and faster reconfiguration.
>
>One problem with doing this is the essentially fluid definition
>of the inside and the outside.  Now if we were to have a new
>connection show up between points "outside" the core, they will
>become "inside" points - not only requiring resolution of the
>potential loop (via RB-neighbor-discovery), but fundamentally
>changing the way they operate.
>
>--> 
>--> >	I assume we're not intending that a frame may use a different
>--> >path, in this special case and not using the next-hop MAC address,
>--> >so it still goes through the same devices.  That would be opening
>--> >a different can of worms. The only difference is that frames don't 
>--> >get their MAC SA/DA changed at each RBridge.  But that's a simple 
>--> >operation for typical forwarding hardware.
>--> >  
>--> >
>--> Although changing destination address at each hop is not too 
>--> complicated, this  is something that even routers do not 
>--> do, they keep the IP source and destination addresses of 
>--> packets.
>
>Not sure how this is relevant, but routers always re-write the 
>MAC SA/DA when forwarding IP packets. 
>
This occurs because the layer 2 difussion domain  changes.

> This is part of why I
>said that that operation is not hard.  Re-writing IP SA/DA is
>something routers do only if they are supporting NAT - but they
>still can do it.
>
>There are other circumstances under which an IP Router can do
>an IP SA/DA re-write as well.
>
>  
>
What I mean is that router usually do not change IP address (the address 
used to route).
 Discussing more this argument  is useless.

>--> 
>--> >	Given that the forwarding device has to be able to do that,
>--> >there isn't anything to gain from being able to avoid doing so -
>--> >sometimes.
>--> >
>--> >	As for what Radia suggested earlier, there's a difference
>--> >between potentially having logical bridges in-line with ports on
>--> >an RBridge, and having a logical bridge connecting the ports of
>--> >an RBridge.  But these are simply hybrid implementations and,
>--> >for our purposes, they can be considered separately from the
>--> >requirements for an RBridge.
>--> >
>--> >                                            +------------+
>--> >      +------------------------+            |    +---+   |
>--> >      |                        |            | +--+ B +-+ |
>--> >      |  +---+  +----+  +---+  |            | |  +---+ | |
>--> >   ---+--+ B +--+ RB +--+ B +--+---      ---+-+        +-+---
>--> >      |  +---+  +----+  +---+  |            | | +----+ | |
>--> >      |                        |            | +-+ RB +-+ |
>--> >      +------------------------+            |   +----+   |
>--> >              Hybrid A                      +------------+
>--> >    						Hybrid B
>--> >
>--> Is Hybrid B  allowed?
>
>I don't know that it makes sense, but - if you remove the outer
>box and consider the B and RB as separate boxes - it is certainly
>one of the potential scenarios we've talked about.  Since it can
>happen outside the box, I see no particular reason to put on the
>blinkers for the possibility of it happening inside the box.
>
>Also, Hybrid B is one view of what you're talking about, since
>what would normally be the next hop RBridge has to "bridge" the
>MAC frames it receives that are not addressed to it in what you
>are talking about.
>
>Take this example:
>
>    H1 ---> RB1 <---> RB2 <---> RB3 <--- H2
>
>As I understand it, you propose that RB1 might encapsulate a frame
>coming from H1 and going to H2 with SA/DA = RB1/RB3 rather than
>SA/DA = RB1/RB2.  What that means is that RB2 has to bridge those
>frames from RB1 to RB3 as - otherwise -  it would simply ignore 
>any frame not addressed to it.
>  
>
No. It means RB2 *routes* those frames in the same way  (with IS- IS) 
but it does not change the DA.

>There is nothing about peer-to-peer connections within an RBridge
>campus that requires promiscuous MAC listening, or forwarding -
>nor is their currently any requirement for bridge learning on
>those ports.
>
>  
>
Right. It is not required. It has been answered with the sentence above

>So - following the idea of separable functions - RB2 would have
>to be a Hybrid B implementation.  Does it make sense to do this?
>  
>
Same as above.

>Maybe - however the separability of B and RB functions means we
>do not have to determine whether it makes sense or not, here and
>in this working group.
>
>  
>
A complication is that the "B" part of Hybrid B should shut off

>if either of its connected ports is determined by the "RB" part
>of the implementation to be connected to outside of the RBridge 
>campus.
>
>--> 
>--> >                               |           
>--> >                            +------+-----+
>--> >                            |    +-+-+   |
>--> >                            |    | B +-+ |
>--> >                            |    +---+ | |
>--> >                         ---+-+        +-+---
>--> >                            | | +----+ | |
>--> >                            | +-+ RB +-+ |
>--> >                            |   +----+   |
>--> >                            +------------+
>--> >                               Hybrid C
>--> >
>--> >Each of the above "hybrid" implementations is possible. But from
>--> >our perspective, we want to define the "RB" boxes and we can look
>--> >at each of these as "outside" the "RB" box.  From that perspective
>--> >all of these "hybrids" become simple variations of one or another 
>--> >of the topology examples we have already discussed.
>--> >
>--> >--
>--> >Eric
>--> >
>--> >--> -----Original Message-----
>--> >--> From: [e-mail] 
>--> >--> [mailto:[e-mail]]On
>--> >--> Behalf Of Guillermo Ib??ez
>--> >--> Sent: Friday, October 28, 2005 5:09 AM
>--> >--> To: Developing a hybrid router/bridge.
>--> >--> Subject: [rbridge] Subcase for RBridges?
>--> >--> 
>--> >--> 
>--> >--> I have a question regarding next-hop destination RBridge 
>--> >--> addressing. It 
>--> >--> could be avoided whitin campus cores.
>--> >--> One objection that can be made to RBridges and other 
>--> >--> proposals that keep 
>--> >--> compatibility with bridged islands  is that  the 
>--> >--> double-encapsulated 
>--> >--> frame is addressed to next-hop RBridge instead of to 
>--> destination 
>--> >--> RBridge. This is necessary as, if not, the frame could be 
>--> >--> duplicated by 
>--> >--> intermediate RBridges that receive  copies of  the frame.
>--> >--> As in some cases it is foreseable that RBridges will form 
>--> >--> the core of 
>--> >--> the campus network due to their advantages regarding 
>--> >--> segmentation, links 
>--> >--> usage, etc, I wonder whether it is worth to consider 
>--> the subcase of 
>--> >--> confined RBridges whithin a core area formed by RBridges 
>--> >--> linked by point 
>--> >--> to point links. Point to point links are an standard 
>--> >--> requirement for 
>--> >--> RSTP protocol (required for fast convergence) and common 
>--> >--> practice in 
>--> >--> campus networks by performance and security reasons.
>--> >--> Ports of RBridges linked to RBridges ( core ports) 
>--> execute RBridges 
>--> >--> protocol with double encapsulation and ports connected 
>--> to standard 
>--> >--> bridges islands (sbridge ports) act as the "B1" 
>--> standard bridge as 
>--> >--> proposed by Radia for RBridge/Bridge optional implementation.
>--> >--> Assuming an scenario like this, RBridges might address 
>--> directly the 
>--> >--> encapsulated frame to destination RBridge and only the TTL 
>--> >--> field would 
>--> >--> need to be changed at each RBridge.
>--> >--> It is not the general and standard scenario, but it could 
>--> >--> be in practice 
>--> >--> quite common, given their advantages.
>--> >--> Guillermo
>--> >--> _______________________________________________
>--> >--> rbridge mailing list
>--> >--> [e-mail]
>--> >--> http://www.postel.org/mailman/listinfo/rbridge
>--> >--> 
>--> >_______________________________________________
>--> >rbridge mailing list
>--> >[e-mail]
>--> >http://www.postel.org/mailman/listinfo/rbridge
>--> >
>--> >  
>--> >
>--> _______________________________________________
>--> 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 mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA2JMQM03111 for <[e-mail]>; Wed, 2 Nov 2005 11:22:27 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jA2JMKp1001154 for <[e-mail]>; Wed, 2 Nov 2005 14:22:20 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA17847 for <[e-mail]>; Wed, 2 Nov 2005 14:22:20 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WCKHL7LP>; Wed, 2 Nov 2005 17:22:19 -0200
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Wed, 2 Nov 2005 17:22:19 -0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-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 jA2JMQM03111
Subject: Re: [rbridge] Subcase for RBridges?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 19:23:16 -0000
Status: RO
Content-Length: 11480

Guillermo,

	Please see below...

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Wednesday, November 02, 2005 1:02 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Subcase for RBridges?
--> 
--> 
--> Eric,
-->      My proposal does not require RBridge to be aware of link type,  
--> functions to  work  with bridges are implemented by the B bridge 
--> "attached" to RB.It is a potential variant of the RBridge protocol
--> only to be used in campuses where RBridges are directly connected
--> between them forming  a core and do not allow standard bridges 
--> interposed. Standard bridges are allowed only as Access Layer (any 
--> port hearing standard STPs BPDUs runs STP).
-->      
--> Gray, Eric wrote:
--> 
--> >Guillermo,
--> >
--> >	I assume that - by point-to-point link - you mean full-duplex
--> >Ethernet/802.  Since we are not trying to address L2 connectivity
--> >other than Ethernet, that should be the case within the scope of 
--> >discussion on this list.
--> >
--> >  
--> >
--> I mean not shared links. It may work half-duplex or full-duplex.

True, assuming "shared" status can be properly determined.

--> 
--> >	It is difficult for any implementation to divine the nature of
--> >the "wire" connecting it to another implementation - whether RBridge
--> >or bridge.  In many cases, it is possible - for example, by looking
--> >at port-type information and listening to both RBridge neighbor 
--> >discovery and local STP - but not in every case.
--> >
--> >  
--> >
--> The  bridge is aware of the link type and the RSTP protocol state 
--> machines use it. 
--> /" 17.12 RSTP and point-to-point links
--> The rapid transition of a Designated Port to Forwarding 
--> depends on the Port being directly connected to at
--> most one other Bridge [it is an Edge Port (17.3, 17.19.17),  
--> or is attached to a point-to-point LAN, rather than a shared
--> medium]. The adminPointToPointMAC and operPointToPointMAC 
--> parameters (6.4.3) provide management and signalling of the 
--> point-to-point status to RSTP state machines.
--> A newly selected Root Port can transition to Forwarding 
--> rapidly, even if attached to shared media."/
--> 
--> >	For example, the mysterious "lurking" L2 forwarding device that
--> >participates in neither RBridge neighbor discovery, nor STP would be
--> >invisible and - presumably - RBridges would likely be invisible to 
--> >it as well.
--> >
--> >	In addition, there are a variety of transitional states in
--> >which it is very likely that an inferred point-to-point link will 
--> >no longer be point-to-point and the RBridges will not be aware of
--> >that.
--> >  
--> >
--> All these functions are in the B bridge attached to the RB, 
--> RB does not need to control them.
--> The "attached"  B as proposed by Radia has many advantages for RB 
--> regarding compatibility in the interaction with standard bridges.

Yes, and the reason why Radia brought this up was to illustrate that
the functions are separable.  So, since we are trying to define the
"RB" portion of the separable functions, why do we keep coming back
to "B" functions?

--> 
--> >	However, even if all this were not true, what do we gain from
--> >"special casing" this special case - even if it does turn out to be
--> >common?
--> >
--> >  
--> >
--> This special casing could be a variant  for campuses where 
--> RBridges are all connected together forming a network core,
--> without bridges interposed between them.  Standard bridges 
--> are only allowed at the outside of the core. This scenario 
--> is better suited for high performance, better network 
--> predictability and faster reconfiguration.

One problem with doing this is the essentially fluid definition
of the inside and the outside.  Now if we were to have a new
connection show up between points "outside" the core, they will
become "inside" points - not only requiring resolution of the
potential loop (via RB-neighbor-discovery), but fundamentally
changing the way they operate.

--> 
--> >	I assume we're not intending that a frame may use a different
--> >path, in this special case and not using the next-hop MAC address,
--> >so it still goes through the same devices.  That would be opening
--> >a different can of worms. The only difference is that frames don't 
--> >get their MAC SA/DA changed at each RBridge.  But that's a simple 
--> >operation for typical forwarding hardware.
--> >  
--> >
--> Although changing destination address at each hop is not too 
--> complicated, this  is something that even routers do not 
--> do, they keep the IP source and destination addresses of 
--> packets.

Not sure how this is relevant, but routers always re-write the 
MAC SA/DA when forwarding IP packets.  This is part of why I
said that that operation is not hard.  Re-writing IP SA/DA is
something routers do only if they are supporting NAT - but they
still can do it.

There are other circumstances under which an IP Router can do
an IP SA/DA re-write as well.

--> 
--> >	Given that the forwarding device has to be able to do that,
--> >there isn't anything to gain from being able to avoid doing so -
--> >sometimes.
--> >
--> >	As for what Radia suggested earlier, there's a difference
--> >between potentially having logical bridges in-line with ports on
--> >an RBridge, and having a logical bridge connecting the ports of
--> >an RBridge.  But these are simply hybrid implementations and,
--> >for our purposes, they can be considered separately from the
--> >requirements for an RBridge.
--> >
--> >                                            +------------+
--> >      +------------------------+            |    +---+   |
--> >      |                        |            | +--+ B +-+ |
--> >      |  +---+  +----+  +---+  |            | |  +---+ | |
--> >   ---+--+ B +--+ RB +--+ B +--+---      ---+-+        +-+---
--> >      |  +---+  +----+  +---+  |            | | +----+ | |
--> >      |                        |            | +-+ RB +-+ |
--> >      +------------------------+            |   +----+   |
--> >              Hybrid A                      +------------+
--> >    						Hybrid B
--> >
--> Is Hybrid B  allowed?

I don't know that it makes sense, but - if you remove the outer
box and consider the B and RB as separate boxes - it is certainly
one of the potential scenarios we've talked about.  Since it can
happen outside the box, I see no particular reason to put on the
blinkers for the possibility of it happening inside the box.

Also, Hybrid B is one view of what you're talking about, since
what would normally be the next hop RBridge has to "bridge" the
MAC frames it receives that are not addressed to it in what you
are talking about.

Take this example:

    H1 ---> RB1 <---> RB2 <---> RB3 <--- H2

As I understand it, you propose that RB1 might encapsulate a frame
coming from H1 and going to H2 with SA/DA = RB1/RB3 rather than
SA/DA = RB1/RB2.  What that means is that RB2 has to bridge those
frames from RB1 to RB3 as - otherwise -  it would simply ignore 
any frame not addressed to it.

There is nothing about peer-to-peer connections within an RBridge
campus that requires promiscuous MAC listening, or forwarding -
nor is their currently any requirement for bridge learning on
those ports.

So - following the idea of separable functions - RB2 would have
to be a Hybrid B implementation.  Does it make sense to do this?
Maybe - however the separability of B and RB functions means we
do not have to determine whether it makes sense or not, here and
in this working group.

A complication is that the "B" part of Hybrid B should shut off
if either of its connected ports is determined by the "RB" part
of the implementation to be connected to outside of the RBridge 
campus.

--> 
--> >                               |           
--> >                            +------+-----+
--> >                            |    +-+-+   |
--> >                            |    | B +-+ |
--> >                            |    +---+ | |
--> >                         ---+-+        +-+---
--> >                            | | +----+ | |
--> >                            | +-+ RB +-+ |
--> >                            |   +----+   |
--> >                            +------------+
--> >                               Hybrid C
--> >
--> >Each of the above "hybrid" implementations is possible. But from
--> >our perspective, we want to define the "RB" boxes and we can look
--> >at each of these as "outside" the "RB" box.  From that perspective
--> >all of these "hybrids" become simple variations of one or another 
--> >of the topology examples we have already discussed.
--> >
--> >--
--> >Eric
--> >
--> >--> -----Original Message-----
--> >--> From: [e-mail] 
--> >--> [mailto:[e-mail]]On
--> >--> Behalf Of Guillermo Ib??ez
--> >--> Sent: Friday, October 28, 2005 5:09 AM
--> >--> To: Developing a hybrid router/bridge.
--> >--> Subject: [rbridge] Subcase for RBridges?
--> >--> 
--> >--> 
--> >--> I have a question regarding next-hop destination RBridge 
--> >--> addressing. It 
--> >--> could be avoided whitin campus cores.
--> >--> One objection that can be made to RBridges and other 
--> >--> proposals that keep 
--> >--> compatibility with bridged islands  is that  the 
--> >--> double-encapsulated 
--> >--> frame is addressed to next-hop RBridge instead of to 
--> destination 
--> >--> RBridge. This is necessary as, if not, the frame could be 
--> >--> duplicated by 
--> >--> intermediate RBridges that receive  copies of  the frame.
--> >--> As in some cases it is foreseable that RBridges will form 
--> >--> the core of 
--> >--> the campus network due to their advantages regarding 
--> >--> segmentation, links 
--> >--> usage, etc, I wonder whether it is worth to consider 
--> the subcase of 
--> >--> confined RBridges whithin a core area formed by RBridges 
--> >--> linked by point 
--> >--> to point links. Point to point links are an standard 
--> >--> requirement for 
--> >--> RSTP protocol (required for fast convergence) and common 
--> >--> practice in 
--> >--> campus networks by performance and security reasons.
--> >--> Ports of RBridges linked to RBridges ( core ports) 
--> execute RBridges 
--> >--> protocol with double encapsulation and ports connected 
--> to standard 
--> >--> bridges islands (sbridge ports) act as the "B1" 
--> standard bridge as 
--> >--> proposed by Radia for RBridge/Bridge optional implementation.
--> >--> Assuming an scenario like this, RBridges might address 
--> directly the 
--> >--> encapsulated frame to destination RBridge and only the TTL 
--> >--> field would 
--> >--> need to be changed at each RBridge.
--> >--> It is not the general and standard scenario, but it could 
--> >--> be in practice 
--> >--> quite common, given their advantages.
--> >--> Guillermo
--> >--> _______________________________________________
--> >--> rbridge mailing list
--> >--> [e-mail]
--> >--> http://www.postel.org/mailman/listinfo/rbridge
--> >--> 
--> >_______________________________________________
--> >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 smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA2I1dM01388 for <[e-mail]>; Wed, 2 Nov 2005 10:01:40 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E2D639DACD for <[e-mail]>; Wed,  2 Nov 2005 19:01:32 +0100 (CET)
Received: from [163.117.139.63] (gibanez.it.uc3m.es [163.117.139.63]) by smtp01.uc3m.es (Postfix) with ESMTP id 1B7239D228 for <[e-mail]>; Wed,  2 Nov 2005 19:01:32 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 02 Nov 2005 19:01:34 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
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]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Subcase for RBridges?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 18:02:00 -0000
Status: RO
Content-Length: 7647

Eric,
     My proposal does not require RBridge to be aware of link type,  
functions to  work  with bridges are implemented by the
B bridge "attached" to RB.It is a potential variant of the RBridge 
protocol only to be used in campuses where RBridges are directly 
connected between them forming  a core and do not allow standard bridges 
interposed. Standard bridges are allowed only as  Access  Layer (any 
port hearing standard STPs BPDUs runs STP).
     
Gray, Eric wrote:

>Guillermo,
>
>	I assume that - by point-to-point link - you mean full-duplex
>Ethernet/802.  Since we are not trying to address L2 connectivity
>other than Ethernet, that should be the case within the scope of 
>discussion on this list.
>
>  
>
I mean not shared links. It may work half-duplex or full-duplex.

>	It is difficult for any implementation to divine the nature of
>the "wire" connecting it to another implementation - whether RBridge
>or bridge.  In many cases, it is possible - for example, by looking
>at port-type information and listening to both RBridge neighbor 
>discovery and local STP - but not in every case.
>
>  
>
The  bridge is aware of the link type and the RSTP protocol state 
machines use it.
/" 17.12 RSTP and point-to-point links
The rapid transition of a Designated Port to Forwarding depends on the 
Port being directly connected to at
most one other Bridge [it is an Edge Port (17.3, 17.19.17), or is 
attached to a point-to-point LAN, rather than
a shared medium]. The adminPointToPointMAC and operPointToPointMAC 
parameters (6.4.3) provide
management and signalling of the point-to-point status to RSTP state 
machines.
A newly selected Root Port can transition to Forwarding rapidly, even if 
attached to shared media."/

>	For example, the mysterious "lurking" L2 forwarding device that
>participates in neither RBridge neighbor discovery, nor STP would be
>invisible and - presumably - RBridges would likely be invisible to 
>it as well.
>
>	In addition, there are a variety of transitional states in
>which it is very likely that an inferred point-to-point link will 
>no longer be point-to-point and the RBridges will not be aware of
>that.
>  
>
All these functions are in the B bridge attached to the RB, RB does not 
need to control them.
The "attached"  B as proposed by Radia has many advantages for RB 
regarding compatibility in the interaction with standard bridges.

>	However, even if all this were not true, what do we gain from
>"special casing" this special case - even if it does turn out to be
>common?
>
>  
>
This special casing could be a variant  for campuses where RBridges are 
all connected together forming a network core,whitout bridges interposed 
between them.  Standard bridges are only allowed at the outside of the 
core. This scenario is better suited for high performance, better 
network predictability and faster reconfiguration .

>	I assume we're not intending that a frame may use a different
>path, in this special case and not using the next-hop MAC address,
>so it still goes through the same devices.  That would be opening
>a different can of worms. The only difference is that frames don't 
>get their MAC SA/DA changed at each RBridge.  But that's a simple 
>operation for typical forwarding hardware.
>  
>
Although changing destination address at each hop is not too 
complicated, this  is something that even routers do not do, they keep 
the IP source and destination addresses of packets.

>	Given that the forwarding device has to be able to do that,
>there isn't anything to gain from being able to avoid doing so -
>sometimes.
>
>	As for what Radia suggested earlier, there's a difference
>between potentially having logical bridges in-line with ports on
>an RBridge, and having a logical bridge connecting the ports of
>an RBridge.  But these are simply hybrid implementations and,
>for our purposes, they can be considered separately from the
>requirements for an RBridge.
>
>                                            +------------+
>      +------------------------+            |    +---+   |
>      |                        |            | +--+ B +-+ |
>      |  +---+  +----+  +---+  |            | |  +---+ | |
>   ---+--+ B +--+ RB +--+ B +--+---      ---+-+        +-+---
>      |  +---+  +----+  +---+  |            | | +----+ | |
>      |                        |            | +-+ RB +-+ |
>      +------------------------+            |   +----+   |
>              Hybrid A                      +------------+
>    						Hybrid B
>
Is Hybrid B  allowed?

>                               |           
>                            +------+-----+
>                            |    +-+-+   |
>                            |    | B +-+ |
>                            |    +---+ | |
>                         ---+-+        +-+---
>                            | | +----+ | |
>                            | +-+ RB +-+ |
>                            |   +----+   |
>                            +------------+
>                               Hybrid C
>
>Each of the above "hybrid" implementations is possible. But from
>our perspective, we want to define the "RB" boxes and we can look
>at each of these as "outside" the "RB" box.  From that perspective
>all of these "hybrids" become simple variations of one or another 
>of the topology examples we have already discussed.
>
>--
>Eric
>
>--> -----Original Message-----
>--> From: [e-mail] 
>--> [mailto:[e-mail]]On
>--> Behalf Of Guillermo Ib??ez
>--> Sent: Friday, October 28, 2005 5:09 AM
>--> To: Developing a hybrid router/bridge.
>--> Subject: [rbridge] Subcase for RBridges?
>--> 
>--> 
>--> I have a question regarding next-hop destination RBridge 
>--> addressing. It 
>--> could be avoided whitin campus cores.
>--> One objection that can be made to RBridges and other 
>--> proposals that keep 
>--> compatibility with bridged islands  is that  the 
>--> double-encapsulated 
>--> frame is addressed to next-hop RBridge instead of to destination 
>--> RBridge. This is necessary as, if not, the frame could be 
>--> duplicated by 
>--> intermediate RBridges that receive  copies of  the frame.
>--> As in some cases it is foreseable that RBridges will form 
>--> the core of 
>--> the campus network due to their advantages regarding 
>--> segmentation, links 
>--> usage, etc, I wonder whether it is worth to consider the subcase of 
>--> confined RBridges whithin a core area formed by RBridges 
>--> linked by point 
>--> to point links. Point to point links are an standard 
>--> requirement for 
>--> RSTP protocol (required for fast convergence) and common 
>--> practice in 
>--> campus networks by performance and security reasons.
>--> Ports of RBridges linked to RBridges ( core ports) execute RBridges 
>--> protocol with double encapsulation and ports connected to standard 
>--> bridges islands (sbridge ports) act as the "B1" standard bridge as 
>--> proposed by Radia for RBridge/Bridge optional implementation.
>--> Assuming an scenario like this, RBridges might address directly the 
>--> encapsulated frame to destination RBridge and only the TTL 
>--> field would 
>--> need to be changed at each RBridge.
>--> It is not the general and standard scenario, but it could 
>--> be in practice 
>--> quite common, given their advantages.
>--> Guillermo
>--> _______________________________________________
>--> 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 mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA2ErKM25496 for <[e-mail]>; Wed, 2 Nov 2005 06:53:20 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jA2ErDp1024868 for <[e-mail]>; Wed, 2 Nov 2005 09:53:14 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA09521 for <[e-mail]>; Wed, 2 Nov 2005 09:53:12 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WCKHLS4Z>; Wed, 2 Nov 2005 12:53:11 -0200
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Date: Wed, 2 Nov 2005 12:53:10 -0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-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 jA2ErKM25496
Subject: Re: [rbridge] Subcase for RBridges?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
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 Nov 2005 14:53:58 -0000
Status: RO
Content-Length: 5395

Guillermo,

	I assume that - by point-to-point link - you mean full-duplex
Ethernet/802.  Since we are not trying to address L2 connectivity
other than Ethernet, that should be the case within the scope of 
discussion on this list.

	It is difficult for any implementation to divine the nature of
the "wire" connecting it to another implementation - whether RBridge
or bridge.  In many cases, it is possible - for example, by looking
at port-type information and listening to both RBridge neighbor 
discovery and local STP - but not in every case.

	For example, the mysterious "lurking" L2 forwarding device that
participates in neither RBridge neighbor discovery, nor STP would be
invisible and - presumably - RBridges would likely be invisible to 
it as well.

	In addition, there are a variety of transitional states in
which it is very likely that an inferred point-to-point link will 
no longer be point-to-point and the RBridges will not be aware of
that.

	However, even if all this were not true, what do we gain from
"special casing" this special case - even if it does turn out to be
common?

	I assume we're not intending that a frame may use a different
path, in this special case and not using the next-hop MAC address,
so it still goes through the same devices.  That would be opening
a different can of worms. The only difference is that frames don't 
get their MAC SA/DA changed at each RBridge.  But that's a simple 
operation for typical forwarding hardware.

	Given that the forwarding device has to be able to do that,
there isn't anything to gain from being able to avoid doing so -
sometimes.

	As for what Radia suggested earlier, there's a difference
between potentially having logical bridges in-line with ports on
an RBridge, and having a logical bridge connecting the ports of
an RBridge.  But these are simply hybrid implementations and,
for our purposes, they can be considered separately from the
requirements for an RBridge.

                                            +------------+
      +------------------------+            |    +---+   |
      |                        |            | +--+ B +-+ |
      |  +---+  +----+  +---+  |            | |  +---+ | |
   ---+--+ B +--+ RB +--+ B +--+---      ---+-+        +-+---
      |  +---+  +----+  +---+  |            | | +----+ | |
      |                        |            | +-+ RB +-+ |
      +------------------------+            |   +----+   |
              Hybrid A                      +------------+
                                   |           Hybrid B
                            +------+-----+
                            |    +-+-+   |
                            |    | B +-+ |
                            |    +---+ | |
                         ---+-+        +-+---
                            | | +----+ | |
                            | +-+ RB +-+ |
                            |   +----+   |
                            +------------+
                               Hybrid C

Each of the above "hybrid" implementations is possible. But from
our perspective, we want to define the "RB" boxes and we can look
at each of these as "outside" the "RB" box.  From that perspective
all of these "hybrids" become simple variations of one or another 
of the topology examples we have already discussed.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Friday, October 28, 2005 5:09 AM
--> To: Developing a hybrid router/bridge.
--> Subject: [rbridge] Subcase for RBridges?
--> 
--> 
--> I have a question regarding next-hop destination RBridge 
--> addressing. It 
--> could be avoided whitin campus cores.
--> One objection that can be made to RBridges and other 
--> proposals that keep 
--> compatibility with bridged islands  is that  the 
--> double-encapsulated 
--> frame is addressed to next-hop RBridge instead of to destination 
--> RBridge. This is necessary as, if not, the frame could be 
--> duplicated by 
--> intermediate RBridges that receive  copies of  the frame.
--> As in some cases it is foreseable that RBridges will form 
--> the core of 
--> the campus network due to their advantages regarding 
--> segmentation, links 
--> usage, etc, I wonder whether it is worth to consider the subcase of 
--> confined RBridges whithin a core area formed by RBridges 
--> linked by point 
--> to point links. Point to point links are an standard 
--> requirement for 
--> RSTP protocol (required for fast convergence) and common 
--> practice in 
--> campus networks by performance and security reasons.
--> Ports of RBridges linked to RBridges ( core ports) execute RBridges 
--> protocol with double encapsulation and ports connected to standard 
--> bridges islands (sbridge ports) act as the "B1" standard bridge as 
--> proposed by Radia for RBridge/Bridge optional implementation.
--> Assuming an scenario like this, RBridges might address directly the 
--> encapsulated frame to destination RBridge and only the TTL 
--> field would 
--> need to be changed at each RBridge.
--> It is not the general and standard scenario, but it could 
--> be in practice 
--> quite common, given their advantages.
--> Guillermo
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
-->