[rbridge] IS-IS per VLAN ?

[touch at ISI.EDU (Joe Touch)]

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



Michael Smith (michsmit) wrote:
>  
> 
> 
>>-----Original Message-----
>>From: rbridge-bounces at postel.org 
>>[mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch> 
> 
> 
> 
>>michsmit at cisco.com wrote:
> 
>>>>-----Original Message-----
>>>>From: rbridge-bounces at postel.org
>>>>[mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch
> 
>>...
> 
>>>I would expect that a set of rbridge nodes could work anywhere a 
>>>single bridge could work, but that the overall total number of 
>>>devices on the
>>>L2 served by the system would not change substantially.
> 
> 
>>Does that definition of a "single bridge" include 802.1ah and metro 
>>environments ?
> 
> My personal opinion is 'no', i.e., I consider an rbridge 
> campus to act as a single, conventional bridge.
> 
> 
>> If we don't consider those environments, I think we may be
>> under-estimating the size of current L2 deployments.  The line between
>> service provider and enterprise is very blurry as the enterprise becomes
>> larger.  I have run into quite a few larger enterprises that have
>> adopted a model where they provide services to the various
>> departments/divisions using a large L2 core, essentially becoming an
>> internal Metro Ethernet provider.  Quite often, those are the
>> enterprises deploying the more advanced spanning tree technology as they
>> often see the "shortcomings" first.  

We could - as an 'option'. It's just not the primary focus. Would that
suffice?

> That's with the caveat that I can't access the 802 specs on 
> the subject ;-(
> 
>> Sounds like we have something to ask for in a liason statement :-)  They
>> have given password access to the IETF before (you may just find it if
>> you look at http://www.ietf.org/proceedings/01aug/51-65.htm )

That would be useful, though having read IEEE specs a while ago, I'm not
looking forward to it much ;-)

Joe

> 
>> Michael
> 
> 
> If that bridge is part of an 802.1ah bridge device, then so 
> be it, but there may be more to an 802.1ah bridge than we're 
> thinking for an rbridge campus, at least AFAICT from what I 
> can infer the specs say on the matter.
> 
> Joe
> 
> 
> 
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://www.postel.org/mailman/listinfo/rbridge

> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> 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

iD8DBQFDOa38E5f5cImnZrsRAtEUAJ4jVN++w2/8O6Elbq057HBuncLjGwCg26/m
qL5OhyDpjjCAcFv3Ko6JHEI=
=aobJ
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8RKfLY09083; Tue, 27 Sep 2005 13:41:21 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 27 Sep 2005 13:39:24 -0700
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] IS-IS per VLAN ?
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, 27 Sep 2005 20:42:07 -0000
Status: RO
Content-Length: 2719

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



Michael Smith (michsmit) wrote:
>  
> 
> 
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Joe Touch> 
> 
> 
> 
>>[e-mail] wrote:
> 
>>>>-----Original Message-----
>>>>From: [e-mail]
>>>>[mailto:[e-mail]] On Behalf Of Joe Touch
> 
>>...
> 
>>>I would expect that a set of rbridge nodes could work anywhere a 
>>>single bridge could work, but that the overall total number of 
>>>devices on the
>>>L2 served by the system would not change substantially.
> 
> 
>>Does that definition of a "single bridge" include 802.1ah and metro 
>>environments ?
> 
> My personal opinion is 'no', i.e., I consider an rbridge 
> campus to act as a single, conventional bridge.
> 
> 
>> If we don't consider those environments, I think we may be
>> under-estimating the size of current L2 deployments.  The line between
>> service provider and enterprise is very blurry as the enterprise becomes
>> larger.  I have run into quite a few larger enterprises that have
>> adopted a model where they provide services to the various
>> departments/divisions using a large L2 core, essentially becoming an
>> internal Metro Ethernet provider.  Quite often, those are the
>> enterprises deploying the more advanced spanning tree technology as they
>> often see the "shortcomings" first.  

We could - as an 'option'. It's just not the primary focus. Would that
suffice?

> That's with the caveat that I can't access the 802 specs on 
> the subject ;-(
> 
>> Sounds like we have something to ask for in a liason statement :-)  They
>> have given password access to the IETF before (you may just find it if
>> you look at http://www.ietf.org/proceedings/01aug/51-65.htm )

That would be useful, though having read IEEE specs a while ago, I'm not
looking forward to it much ;-)

Joe

> 
>> Michael
> 
> 
> If that bridge is part of an 802.1ah bridge device, then so 
> be it, but there may be more to an 802.1ah bridge than we're 
> thinking for an rbridge campus, at least AFAICT from what I 
> can infer the specs say on the matter.
> 
> Joe
> 
> 
> 
_______________________________________________
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

iD8DBQFDOa38E5f5cImnZrsRAtEUAJ4jVN++w2/8O6Elbq057HBuncLjGwCg26/m
qL5OhyDpjjCAcFv3Ko6JHEI=
=aobJ
-----END PGP SIGNATURE-----


Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8RFElY20711 for <[e-mail]>; Tue, 27 Sep 2005 08:14:48 -0700 (PDT)
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 27 Sep 2005 08:14:42 -0700
X-IronPort-AV: i="3.97,150,1125903600";  d="scan'208"; a="345942426:sNHT31116272"
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8RFEa4w025206 for <[e-mail]>; Tue, 27 Sep 2005 08:14:38 -0700 (PDT)
Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 08:14:34 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 27 Sep 2005 08:14:33 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] IS-IS per VLAN ?
Thread-Index: AcXC2QVignNauX2YQfmlUqyTDS2tsAAm2S7Q
From: "Michael Smith \(michsmit\)" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 27 Sep 2005 15:14:34.0306 (UTC) FILETIME=[2AE3DA20:01C5C376]
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 j8RFElY20711
Subject: Re: [rbridge] IS-IS per VLAN ?
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, 27 Sep 2005 15:14:59 -0000
Status: RO
Content-Length: 2332

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Joe Touch> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> > [e-mail] wrote:
> >>>-----Original Message-----
> >>>From: [e-mail]
> >>>[mailto:[e-mail]] On Behalf Of Joe Touch
> > ...
> >> I would expect that a set of rbridge nodes could work anywhere a 
> >> single bridge could work, but that the overall total number of 
> >> devices on the
> >> L2 served by the system would not change substantially.
> >> 
> > Does that definition of a "single bridge" include 802.1ah and metro 
> > environments ?
> 
> My personal opinion is 'no', i.e., I consider an rbridge 
> campus to act as a single, conventional bridge.

If we don't consider those environments, I think we may be
under-estimating the size of current L2 deployments.  The line between
service provider and enterprise is very blurry as the enterprise becomes
larger.  I have run into quite a few larger enterprises that have
adopted a model where they provide services to the various
departments/divisions using a large L2 core, essentially becoming an
internal Metro Ethernet provider.  Quite often, those are the
enterprises deploying the more advanced spanning tree technology as they
often see the "shortcomings" first.  

> That's with the caveat that I can't access the 802 specs on 
> the subject ;-(

Sounds like we have something to ask for in a liason statement :-)  They
have given password access to the IETF before (you may just find it if
you look at http://www.ietf.org/proceedings/01aug/51-65.htm )

Michael

> 
> If that bridge is part of an 802.1ah bridge device, then so 
> be it, but there may be more to an 802.1ah bridge than we're 
> thinking for an rbridge campus, at least AFAICT from what I 
> can infer the specs say on the matter.
> 
> Joe
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFDOFdYE5f5cImnZrsRAmcMAKCvUC+y9PRxMC27cwT8FmM2MFA6LACgm+Mu
> kan+bBAtp2i4Xcwsmhsq/Fw=
> =dOmq
> -----END PGP SIGNATURE-----
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
> 


Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8REUCY07317; Tue, 27 Sep 2005 07:30:12 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 27 Sep 2005 07:29:58 -0700
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]>	<5677C1974412605B468B89BC@Mike_HP.linx.net>	<[e-mail]>	<[e-mail]>	<0c4c01c5c114$74cc2610$[e-mail]>	<[e-mail]>	<36522B7EAEDD76AE26C04AD7@B50854F0A9192E8EC6CDA126>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.92.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig32EA1A72E5885D9012B0170E"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] IS-IS per VLAN ?
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, 27 Sep 2005 14:31:33 -0000
Status: RO
Content-Length: 3493

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



Guillermo Ib=E1=F1ez wrote:
>=20
> Joe Touch wrote:
>=20
> Dino Farinacci wrote:
=2E..
> I would expect that a set of rbridge nodes could work anywhere a single=

> bridge could work, but that the overall total number of devices on the
> L2 served by the system would not change substantially.
>=20
> I.e., the primary goal of rbridge is better bandwidth between nodes by
> the use of an alternative to a spanning tree inside the rbridge campus,=

> but it doesn't solve the problem that it's still part of the L2 system
> into which it is plugged, and so I wouldn't expect scale to change much=

> - EXCEPT where it is limited by spanning tree convergence.
>=20
> Joe
>=20
>> I am not sure I understood well the argument provided by Joe on keepin=
g=20
>> the actual scale, so I apologize in advance  if I missed the point.
>> It seems a bit conservative to assume that the current L2 network size=
=20
>> will not change.

It's not as much conservative as it is focus of the architecture or an
rbridge.

>> The limitations to scale that current L2 networks have are well-known =
: =20
>> broadcast storms that can propagate along the switched domain, spannin=
g=20
>> tree convergence (argument to be reviewed with RSTP), excessive ARP=20
>> broadcast difussion, inefficient links usage by spanning tree algoritm=
=2E=20
>> These problems increase with L2 domain  size and need to be alleviated=
=2E

While I agree with these issues, the point is that it is NOT the goal of
rbridges to address all of them.

Rbridges focuses on inefficient link use by spanning trees, and also
addresses convergence time.

It does NOT address broadcast storms either due to regular broadcasts or
address resolution. I'm not sure an L2 solution CAN deal with these; the
former is asking to flood, and flooding doesn't scale. The latter can be
replaced with centralized solutions (e.g., as was done in LANE for ATM),
but at the cost of robustness and zero-configuration.

>> Besides this, the Ethernet domains tend to grow in actual campus=20
>> networks: more devices (sensors, PDA, displays) connected.  My=20
>> understanding is that Rbridges should try to improve this situation an=
d=20
>> allow bigger network sizes under a single IP subnet.=20

The goal of an rbridge is better BW first, and hopefully better
convergence. This MAY have the side-effect of encouraging larger
installations, which should be addressed -- but supporting larger
installations is not a primary goal.

Joe

>> Regards
>> Guillermo
>=20
>=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


--------------enig32EA1A72E5885D9012B0170E
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 Thunderbird - http://enigmail.mozdev.org

iD8DBQFDOVduE5f5cImnZrsRAjHiAJ0ccoDvQ8oSsy1+LYmBHTbpqGGKZACdHIci
btbHejkEttW//wtdft3v9RM=
=zWLC
-----END PGP SIGNATURE-----

--------------enig32EA1A72E5885D9012B0170E--


Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8R8UfY23541 for <[e-mail]>; Tue, 27 Sep 2005 01:30:41 -0700 (PDT)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4CACA749EE for <[e-mail]>; Tue, 27 Sep 2005 10:30:35 +0200 (CEST)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp02.uc3m.es (Postfix) with ESMTP id A7AF4749B6 for <[e-mail]>; Tue, 27 Sep 2005 10:30:34 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 27 Sep 2005 10:30:34 +0200
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]>	<5677C1974412605B468B89BC@Mike_HP.linx.net>	<[e-mail]>	<[e-mail]>	<0c4c01c5c114$74cc2610$[e-mail]>	<[e-mail]>	<36522B7EAEDD76AE26C04AD7@B50854F0A9192E8EC6CDA126>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] IS-IS per VLAN ?
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, 27 Sep 2005 08:30:57 -0000
Status: RO
Content-Length: 2220

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Dino Farinacci wrote:
>  
>
>>>>My guess. No reason, no computational logic. Just an estimate.
>>>>        
>>>>
>>    Sorry I wasn't clear. I was referring to the number of rBridge nodes, so we
>>    can understand how both the core-switch and edge-switch network needs to 
>>    scale.
>>    
>>
>
>I would expect that a set of rbridge nodes could work anywhere a single
>bridge could work, but that the overall total number of devices on the
>L2 served by the system would not change substantially.
>
>I.e., the primary goal of rbridge is better bandwidth between nodes by
>the use of an alternative to a spanning tree inside the rbridge campus,
>but it doesn't solve the problem that it's still part of the L2 system
>into which it is plugged, and so I wouldn't expect scale to change much
>- - EXCEPT where it is limited by spanning tree convergence.
>
>Joe
>  
>
I am not sure I understood well the argument provided by Joe on keeping 
the actual scale, so I apologize in advance  if I missed the point.
It seems a bit conservative to assume that the current L2 network size 
will not change.
The limitations to scale that current L2 networks have are well-known :  
broadcast storms that can propagate along the switched domain, spanning 
tree convergence (argument to be reviewed with RSTP), excessive ARP 
broadcast difussion, inefficient links usage by spanning tree algoritm. 
These problems increase with L2 domain  size and need to be alleviated.
Besides this, the Ethernet domains tend to grow in actual campus 
networks: more devices (sensors, PDA, displays) connected.  My 
understanding is that Rbridges should try to improve this situation and 
allow bigger network sizes under a single IP subnet. 
Regards
Guillermo

>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDOEBWE5f5cImnZrsRAh+jAKCaflVr5EGAatUzPxbL9JHdTSzedACeP/SE
>muZvkqSgacJ5rmJ5J8C+iN4=
>=MU0/
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>


Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8QMNFY22182 for <[e-mail]>; Mon, 26 Sep 2005 15:23:15 -0700 (PDT)
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 26 Sep 2005 15:23:09 -0700
X-IronPort-AV: i="3.97,146,1125903600";  d="scan'208"; a="662070944:sNHT26384526"
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j8QMN2Vt009445 for <[e-mail]>; Mon, 26 Sep 2005 15:23:03 -0700 (PDT)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j8QMN7iM008127 for <[e-mail]>; Mon, 26 Sep 2005 15:23:07 -0700
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j8QMN7sK008123; Mon, 26 Sep 2005 15:23:07 -0700
Date: Mon, 26 Sep 2005 15:23:07 -0700
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> (message from Joe Touch on Mon, 26 Sep 2005 11:39:18 -0700)
References: <[e-mail]>	<5677C1974412605B468B89BC@Mike_HP.linx.net>	<[e-mail]>	<[e-mail]>	<0c4c01c5c114$74cc2610$[e-mail]>	<[e-mail]>	<36522B7EAEDD76AE26C04AD7@B50854F0A9192E8EC6CDA126>	<[e-mail]>	<[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] IS-IS per VLAN ?
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, 26 Sep 2005 22:23:51 -0000
Status: RO
Content-Length: 385

>> I.e., the primary goal of rbridge is better bandwidth between nodes by
>> the use of an alternative to a spanning tree inside the rbridge campus,
>> but it doesn't solve the problem that it's still part of the L2 system
>> into which it is plugged, and so I wouldn't expect scale to change much
>> - - EXCEPT where it is limited by spanning tree convergence.

    Good point.

Dino


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 j8QKJRY10056; Mon, 26 Sep 2005 13:19:27 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 26 Sep 2005 13:17:28 -0700
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] IS-IS per VLAN ?
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, 26 Sep 2005 20:20:01 -0000
Status: RO
Content-Length: 1184

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



> [e-mail] wrote:
>>>-----Original Message-----
>>>From: [e-mail] 
>>>[mailto:[e-mail]] On Behalf Of Joe Touch
> ...
>> I would expect that a set of rbridge nodes could work 
>> anywhere a single bridge could work, but that the overall 
>> total number of devices on the
>> L2 served by the system would not change substantially.
>> 
> Does that definition of a "single bridge" include 802.1ah and metro
> environments ?  

My personal opinion is 'no', i.e., I consider an rbridge campus to act
as a single, conventional bridge.

That's with the caveat that I can't access the 802 specs on the subject ;-(

If that bridge is part of an 802.1ah bridge device, then so be it, but
there may be more to an 802.1ah bridge than we're thinking for an
rbridge campus, at least AFAICT from what I can infer the specs say on
the matter.

Joe



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

iD8DBQFDOFdYE5f5cImnZrsRAmcMAKCvUC+y9PRxMC27cwT8FmM2MFA6LACgm+Mu
kan+bBAtp2i4Xcwsmhsq/Fw=
=dOmq
-----END PGP SIGNATURE-----


Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8QJ14Y14326 for <[e-mail]>; Mon, 26 Sep 2005 12:01:04 -0700 (PDT)
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 26 Sep 2005 12:00:59 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8QJ0S5K022326 for <[e-mail]>; Mon, 26 Sep 2005 12:00:57 -0700 (PDT)
From: [e-mail]
Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Sep 2005 12:00:56 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 26 Sep 2005 12:00:55 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] IS-IS per VLAN ?
Thread-Index: AcXCyyE7a8jUnI69RsW/VZ2Bgu8TFwAAFmkA
To: "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 26 Sep 2005 19:00:56.0090 (UTC) FILETIME=[9FD9DFA0:01C5C2CC]
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 j8QJ14Y14326
Subject: Re: [rbridge] IS-IS per VLAN ?
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, 26 Sep 2005 19:01:51 -0000
Status: RO
Content-Length: 1567

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Joe Touch
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Dino Farinacci wrote:
> >>>My guess. No reason, no computational logic. Just an estimate.
> > 
> > 
> >     Sorry I wasn't clear. I was referring to the number of 
> rBridge nodes, so we
> >     can understand how both the core-switch and edge-switch 
> network needs to 
> >     scale.
> 
> I would expect that a set of rbridge nodes could work 
> anywhere a single bridge could work, but that the overall 
> total number of devices on the
> L2 served by the system would not change substantially.

Does that definition of a "single bridge" include 802.1ah and metro
environments ?  

> 
> I.e., the primary goal of rbridge is better bandwidth between 
> nodes by the use of an alternative to a spanning tree inside 
> the rbridge campus, but it doesn't solve the problem that 
> it's still part of the L2 system into which it is plugged, 
> and so I wouldn't expect scale to change much
> - - EXCEPT where it is limited by spanning tree convergence.
> 
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFDOEBWE5f5cImnZrsRAh+jAKCaflVr5EGAatUzPxbL9JHdTSzedACeP/SE
> muZvkqSgacJ5rmJ5J8C+iN4=
> =MU0/
> -----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 j8QIfHY05949; Mon, 26 Sep 2005 11:41:17 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 26 Sep 2005 11:39:18 -0700
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]>	<5677C1974412605B468B89BC@Mike_HP.linx.net>	<[e-mail]>	<[e-mail]>	<0c4c01c5c114$74cc2610$[e-mail]>	<[e-mail]>	<36522B7EAEDD76AE26C04AD7@B50854F0A9192E8EC6CDA126>	<[e-mail]>	<[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] IS-IS per VLAN ?
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, 26 Sep 2005 18:41:58 -0000
Status: RO
Content-Length: 1125

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



Dino Farinacci wrote:
>>>My guess. No reason, no computational logic. Just an estimate.
> 
> 
>     Sorry I wasn't clear. I was referring to the number of rBridge nodes, so we
>     can understand how both the core-switch and edge-switch network needs to 
>     scale.

I would expect that a set of rbridge nodes could work anywhere a single
bridge could work, but that the overall total number of devices on the
L2 served by the system would not change substantially.

I.e., the primary goal of rbridge is better bandwidth between nodes by
the use of an alternative to a spanning tree inside the rbridge campus,
but it doesn't solve the problem that it's still part of the L2 system
into which it is plugged, and so I wouldn't expect scale to change much
- - EXCEPT where it is limited by spanning tree convergence.

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

iD8DBQFDOEBWE5f5cImnZrsRAh+jAKCaflVr5EGAatUzPxbL9JHdTSzedACeP/SE
muZvkqSgacJ5rmJ5J8C+iN4=
=MU0/
-----END PGP SIGNATURE-----


Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8QIZpY04134 for <[e-mail]>; Mon, 26 Sep 2005 11:35:51 -0700 (PDT)
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 26 Sep 2005 11:35:47 -0700
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j8QIZgVt008184 for <[e-mail]>; Mon, 26 Sep 2005 11:35:42 -0700 (PDT)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j8QIZiQN023703 for <[e-mail]>; Mon, 26 Sep 2005 11:35:44 -0700
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j8QIZiCE023695; Mon, 26 Sep 2005 11:35:44 -0700
Date: Mon, 26 Sep 2005 11:35:44 -0700
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> (message from Joe Touch on Mon, 26 Sep 2005 08:07:53 -0700)
References: <[e-mail]>	<5677C1974412605B468B89BC@Mike_HP.linx.net>	<[e-mail]>	<[e-mail]>	<0c4c01c5c114$74cc2610$[e-mail]>	<[e-mail]>	<36522B7EAEDD76AE26C04AD7@B50854F0A9192E8EC6CDA126>	<[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] IS-IS per VLAN ?
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, 26 Sep 2005 18:36:50 -0000
Status: RO
Content-Length: 242

>> My guess. No reason, no computational logic. Just an estimate.

    Sorry I wasn't clear. I was referring to the number of rBridge nodes, so we
    can understand how both the core-switch and edge-switch network needs to 
    scale.

Dino


Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8QIVAY02324 for <[e-mail]>; Mon, 26 Sep 2005 11:31:10 -0700 (PDT)
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 26 Sep 2005 11:31:04 -0700
X-IronPort-AV: i="3.97,146,1125903600";  d="scan'208"; a="214950928:sNHT75051188"
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j8QIV3uk026931 for <[e-mail]>; Mon, 26 Sep 2005 11:31:03 -0700 (PDT)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j8QIV2uH019835 for <[e-mail]>; Mon, 26 Sep 2005 11:31:02 -0700
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j8QIV2ar019829; Mon, 26 Sep 2005 11:31:02 -0700
Date: Mon, 26 Sep 2005 11:31:02 -0700
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> (message from Joe Touch on Sat, 24 Sep 2005 09:52:21 -0700)
References: <[e-mail]><5677C1974412605B468B89BC@Mike_HP.linx.net>	<[e-mail]>	<[e-mail]> <0c4c01c5c114$74cc2610$[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] IS-IS per VLAN ?
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, 26 Sep 2005 18:32:16 -0000
Status: RO
Content-Length: 203

>> L2 network should mean anywhere an L2 packet can reach with the its
>> header intact; that generally includes L2-connected LAN segments, esp.

    You mean the *original* L2 header intact.  ;-)

Dino


Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8QF84Y17833; Mon, 26 Sep 2005 08:08:04 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 26 Sep 2005 08:07:53 -0700
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]>	<5677C1974412605B468B89BC@Mike_HP.linx.net>	<[e-mail]>	<[e-mail]>	<0c4c01c5c114$74cc2610$[e-mail]>	<[e-mail]>	<36522B7EAEDD76AE26C04AD7@B50854F0A9192E8EC6CDA126>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.92.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4B35140F0B41507BA324E548"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] IS-IS per VLAN ?
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, 26 Sep 2005 15:09:20 -0000
Status: RO
Content-Length: 1512

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



Harald Tveit Alvestrand wrote:
>=20
> --On s=F8ndag, september 25, 2005 12:22:00 -0700 Joe Touch <touch@ISI.E=
DU>=20
> wrote:
>=20
>>End nodes. I would expect bridges to be 1/5 of that number, roughly.
>=20
> ah - then the numbers are much more compatible!
>=20
> But that 1/5 number..... Why?

My guess. No reason, no computational logic. Just an estimate.

> When I'm in big buildings, I usually see these fat bundles of Cat5 runn=
ing=20
> from the panels in the offices to a central switching closet somewhere =
-=20
> 10, 100 or even 1000 ports off the same switch.
>=20
> In an 100:1 scenario, a 1000-end-node L2 network would have 10 bridges;=
 in=20
> a 5:1 scenario, it would have 200 bridges. That makes an obvious differ=
ence=20
> to how far we have to make sure TRILL scales.

Agreed.


Joe


--------------enig4B35140F0B41507BA324E548
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 Thunderbird - http://enigmail.mozdev.org

iD8DBQFDOA7OE5f5cImnZrsRAk8EAKC6kZlfelN26TqQ6sotULvbZx1phgCdFDPw
NrIYR0kWE8vzCDkO+vVScRQ=
=cyYC
-----END PGP SIGNATURE-----

--------------enig4B35140F0B41507BA324E548--


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 j8Q5V0Y08487 for <[e-mail]>; Sun, 25 Sep 2005 22:31:00 -0700 (PDT)
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7A44225806E for <[e-mail]>; Mon, 26 Sep 2005 07:30:27 +0200 (CEST)
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 30947-10 for <[e-mail]>; Mon, 26 Sep 2005 07:30:24 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1431725806A for <[e-mail]>; Mon, 26 Sep 2005 07:30:24 +0200 (CEST)
Date: Mon, 26 Sep 2005 07:30:54 +0200
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]> <5677C1974412605B468B89BC@Mike_HP.linx.net>	<[e-mail]> <[e-mail]> <0c4c01c5c114$74cc2610$[e-mail]>	<[e-mail]> <36522B7EAEDD76AE26C04AD7@B50854F0A9192E8EC6CDA126> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
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]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j8Q5V0Y08487
Subject: Re: [rbridge] IS-IS per VLAN ?
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, 26 Sep 2005 05:31:47 -0000
Status: RO
Content-Length: 636

--On s?ndag, september 25, 2005 12:22:00 -0700 Joe Touch <[e-mail]> 
wrote:

> End nodes. I would expect bridges to be 1/5 of that number, roughly.

ah - then the numbers are much more compatible!

But that 1/5 number..... Why?

When I'm in big buildings, I usually see these fat bundles of Cat5 running 
from the panels in the offices to a central switching closet somewhere - 
10, 100 or even 1000 ports off the same switch.

In an 100:1 scenario, a 1000-end-node L2 network would have 10 bridges; in 
a 5:1 scenario, it would have 200 bridges. That makes an obvious difference 
to how far we have to make sure TRILL scales.




Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8PJMMY18027; Sun, 25 Sep 2005 12:22:34 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sun, 25 Sep 2005 12:22:00 -0700
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]>	<5677C1974412605B468B89BC@Mike_HP.linx.net>	<[e-mail]>	<[e-mail]>	<0c4c01c5c114$74cc2610$[e-mail]>	<[e-mail]> <36522B7EAEDD76AE26C04AD7@B50854F0A9192E8EC6CDA126>
In-Reply-To: <36522B7EAEDD76AE26C04AD7@B50854F0A9192E8EC6CDA126>
X-Enigmail-Version: 0.92.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFF9A137DB1EC237B71C39E4A"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] IS-IS per VLAN ?
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: Sun, 25 Sep 2005 19:23:42 -0000
Status: RO
Content-Length: 1414

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

End nodes. I would expect bridges to be 1/5 of that number, roughly.

Joe

Harald Tveit Alvestrand wrote:
> 
> 
> --On 24. september 2005 09:52 -0700 Joe Touch <[e-mail]> wrote:
> 
>> As to the number of nodes on an L2, I've seen very modest installations
>> have over 200 in an office, and that doesn't include a university dorm
>> or cable modem system, which could be much higher.
> 
> 
> Joe,
> 
> are you counting the end-nodes, or just the bridges?
> 
>                     Harald
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge

--------------enigFF9A137DB1EC237B71C39E4A
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 Thunderbird - http://enigmail.mozdev.org

iD8DBQFDNvjYE5f5cImnZrsRAifMAJ4iKT0fbCGy552ekMhvHd2GRTREdQCg9yq6
qVBHYv3psX6eaIpX5MSU328=
=W9gz
-----END PGP SIGNATURE-----

--------------enigFF9A137DB1EC237B71C39E4A--


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 j8PGs6Y11830 for <[e-mail]>; Sun, 25 Sep 2005 09:54:06 -0700 (PDT)
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2944225808E for <[e-mail]>; Sun, 25 Sep 2005 18:53:33 +0200 (CEST)
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 05454-07 for <[e-mail]>; Sun, 25 Sep 2005 18:53:27 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 39AF3258080 for <[e-mail]>; Sun, 25 Sep 2005 18:53:27 +0200 (CEST)
Date: Sun, 25 Sep 2005 18:53:29 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-ID: <36522B7EAEDD76AE26C04AD7@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <5677C1974412605B468B89BC@Mike_HP.linx.net>	<[e-mail]> <[e-mail]> <0c4c01c5c114$74cc2610$[e-mail]> <[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="==========8F3917A3D972BC9696DD=========="
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] IS-IS per VLAN ?
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: Sun, 25 Sep 2005 16:54:40 -0000
Status: RO
Content-Length: 888

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



--On 24. september 2005 09:52 -0700 Joe Touch <[e-mail]> wrote:

> As to the number of nodes on an L2, I've seen very modest installations
> have over 200 in an office, and that doesn't include a university dorm
> or cable modem system, which could be much higher.

Joe,

are you counting the end-nodes, or just the bridges?

                     Harald



--==========8F3917A3D972BC9696DD==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

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

iD8DBQFDNtYJOMj+2+WY0F4RAq53AJ9Ag+ez/USFkS5CIKeflGL8x9t6AACg0S0K
quAFo58cS/d3Njve8/te7ck=
=Oe/x
-----END PGP SIGNATURE-----

--==========8F3917A3D972BC9696DD==========--



Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [63.240.76.49]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8OLfUY15015 for <[e-mail]>; Sat, 24 Sep 2005 14:41:31 -0700 (PDT)
Received: from s73602 (unknown[218.18.236.95]) by comcast.net (sccrmhc14) with SMTP id <2005092421412101400j2nq0e>; Sat, 24 Sep 2005 21:41:22 +0000
Message-ID: <0cfd01c5c150$af29e4f0$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]><5677C1974412605B468B89BC@Mike_HP.linx.net><[e-mail]><[e-mail]><0c4c01c5c114$74cc2610$[e-mail]> <[e-mail]>
Date: Sun, 25 Sep 2005 05:41:04 +0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] IS-IS per VLAN ?
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, 24 Sep 2005 21:41:42 -0000
Status: RO
Content-Length: 1417

>>> I agree that discussing a shared vision of the size of an rBridge 
>>> network is
>>> a good thing to do. To start that discussion - When you say "L2 
>>> network",
>>> are you talking about a LAN segment, or a collection of bridged LAN
>>> segments?
>
>    A collection of bridged LAN segments which usually is IP addressed as
>    one IP subnet or in many cases multiple secondary IP subnets. And only
>    needing a router if you are going off logical subnet.
>
> Dino

Hi, Dino,

OK, that's what I thought you meant.

Caution: I have managed networks before, but it wasn't recently... people 
with recent experience should probably be saying something :-)

The 10-50 device range is a little higher than what I was used to seeing in 
UNbridged LAN segments. Joe's "200 devices is a moderate size" seemed closer 
to what I expected for a collection of bridged LAN segments.

I look forward to the Problem Statement draft with baited breath, but I 
thought rBridges would be a way of using larger collections of L2 devices, 
since we would be tending to use more paths than just the spanning tree 
path. I think I understand that we're talking about the number of VLANs, not 
the number of L2 devices here, but would expect that there is a fair chance 
we would see larger numbers of VLANs in environments where there are larger 
numbers of L2 devices.

I'll let other people express an opinion now.

Spencer 



Received: from [128.9.176.130] (ras30.isi.edu [128.9.176.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8OGqRY08129; Sat, 24 Sep 2005 09:52:27 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sat, 24 Sep 2005 09:52:21 -0700
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]><5677C1974412605B468B89BC@Mike_HP.linx.net>	<[e-mail]>	<[e-mail]> <0c4c01c5c114$74cc2610$[e-mail]>
In-Reply-To: <0c4c01c5c114$74cc2610$[e-mail]>
X-Enigmail-Version: 0.92.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD506CC1D2F1B611D2E5D19BB"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] IS-IS per VLAN ?
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, 24 Sep 2005 16:52:35 -0000
Status: RO
Content-Length: 2056

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



Spencer Dawkins wrote:
> Hi, Dino,
> 
> 
>>   I think this list really has to decide how large we anticipate an 
>>rBridge
>>   network is going to be. Traditionally, an L2 network is usually less 
>>than
>>   50 nodes and I would say the average is more like 10. If we stay with
>>   these sort of numbers, then we can under-optimize in the spirit of more
>>   simplicity.
> 
> 
> I agree that discussing a shared vision of the size of an rBridge network is 
> a good thing to do. To start that discussion - When you say "L2 network", 
> are you talking about a LAN segment, or a collection of bridged LAN 
> segments?

L2 network should mean anywhere an L2 packet can reach with the its
header intact; that generally includes L2-connected LAN segments, esp.
since 'LAN segment' includes more than two nodes only for shared media
(wireless or somewhat antiquated variants of ethernet). Ways of
interconnecting the segments at L2 include hubs and bridges - which to
me are both kinds of switches.

As to the number of nodes on an L2, I've seen very modest installations
have over 200 in an office, and that doesn't include a university dorm
or cable modem system, which could be much higher.

While we're not defining an architecture by poll, does anyone have a
good estimate of the size of a large L2? (I'm guessing around 1,000, but
it's just a guess)...

Joe

--------------enigD506CC1D2F1B611D2E5D19BB
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 Thunderbird - http://enigmail.mozdev.org

iD8DBQFDNYRKE5f5cImnZrsRAmS3AKDKRRk5Xzj/Hy9o7ejITPHtFgixiACgqs8C
1hClIt3vNMEKXAhlUeqUrrk=
=Fets
-----END PGP SIGNATURE-----

--------------enigD506CC1D2F1B611D2E5D19BB--


Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8OGF0Y00204 for <[e-mail]>; Sat, 24 Sep 2005 09:15:00 -0700 (PDT)
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 24 Sep 2005 09:14:56 -0700
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j8OGEruk016183 for <[e-mail]>; Sat, 24 Sep 2005 09:14:54 -0700 (PDT)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j8OGEr3U030799 for <[e-mail]>; Sat, 24 Sep 2005 09:14:53 -0700
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j8OGErCr030795; Sat, 24 Sep 2005 09:14:53 -0700
Date: Sat, 24 Sep 2005 09:14:53 -0700
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <0c4c01c5c114$74cc2610$[e-mail]> ([e-mail])
References: <[e-mail]><5677C1974412605B468B89BC@Mike_HP.linx.net> <[e-mail]> <[e-mail]> <0c4c01c5c114$74cc2610$[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] IS-IS per VLAN ?
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, 24 Sep 2005 16:15:32 -0000
Status: RO
Content-Length: 458

>> I agree that discussing a shared vision of the size of an rBridge network is 
>> a good thing to do. To start that discussion - When you say "L2 network", 
>> are you talking about a LAN segment, or a collection of bridged LAN 
>> segments?

    A collection of bridged LAN segments which usually is IP addressed as
    one IP subnet or in many cases multiple secondary IP subnets. And only
    needing a router if you are going off logical subnet.

Dino


Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8OEUIY04821 for <[e-mail]>; Sat, 24 Sep 2005 07:30:18 -0700 (PDT)
Received: from s73602 (unknown[218.18.236.95]) by comcast.net (sccrmhc13) with SMTP id <20050924143009013009g4hre>; Sat, 24 Sep 2005 14:30:11 +0000
Message-ID: <0c4c01c5c114$74cc2610$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]><5677C1974412605B468B89BC@Mike_HP.linx.net> <[e-mail]> <[e-mail]>
Date: Sat, 24 Sep 2005 22:29:57 +0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] IS-IS per VLAN ?
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, 24 Sep 2005 14:31:03 -0000
Status: RO
Content-Length: 597

Hi, Dino,

>    I think this list really has to decide how large we anticipate an 
> rBridge
>    network is going to be. Traditionally, an L2 network is usually less 
> than
>    50 nodes and I would say the average is more like 10. If we stay with
>    these sort of numbers, then we can under-optimize in the spirit of more
>    simplicity.

I agree that discussing a shared vision of the size of an rBridge network is 
a good thing to do. To start that discussion - When you say "L2 network", 
are you talking about a LAN segment, or a collection of bridged LAN 
segments?

Thanks,

Spencer 



Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8O0rxn21945 for <[e-mail]>; Fri, 23 Sep 2005 17:53:59 -0700 (PDT)
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 23 Sep 2005 17:53:54 -0700
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j8O0rnVt020344 for <[e-mail]>; Fri, 23 Sep 2005 17:53:50 -0700 (PDT)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j8O0rql6004232 for <[e-mail]>; Fri, 23 Sep 2005 17:53:52 -0700
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j8O0rqZl004228; Fri, 23 Sep 2005 17:53:52 -0700
Date: Fri, 23 Sep 2005 17:53:52 -0700
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> (message from Radia Perlman on Thu, 22 Sep 2005 09:37:10 -0700)
References: <[e-mail]> <5677C1974412605B468B89BC@Mike_HP.linx.net> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] IS-IS per VLAN ?
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, 24 Sep 2005 00:55:01 -0000
Status: RO
Content-Length: 5385

    Sorry for the long email.

>> The reason for multiple instances is so that a core RBridge that is not 
>> attached to VLAN A will
>> not have to store information for endnodes in VLAN A.

    And for the core-switches to not have to process LSPs with potentially
    constantly changing VLAN registration/deregistration. In a larger switch
    network with edge-switcehs with ports in the 100s and even 1000s of ports
    there could be constant change.

    If you use the IS-IS overlay model, then the core-switches just move 
    multicast packets among them to transport such packets to the edge-nodes.

    Also, architecturally, we are doing a hierarchical forwarding model here
    and not a hierarchical addressing model. Therefore, the core-switches, if
    they don't know about edge MACs shouldn't know about edge-VLANs either.

    I view the IS-IS instance that runs among the edge-switches simply as
    a transport of TLV-encoded information. All you need to run at this 
    instance is the Neighbor Hello machinery, DR election, and the flooding
    algorithim. You don't need to run SPF and argubaly you don't even need to 
    keep a link state database (and the LSPs don't have link information only
    VLAN and MAC encoded entries).

>> With multiple instances, R *still* needs to forward the information 
>> (assuming R is on the spanning
>> tree for VLAN A), but R would only be forwarding in "datagram" mode, as 
>> if the IS-IS instance
>> running over VLAN A were just normal data traffic.

    Just to be clear when I say multiple instances, I refer to a core IS-IS
    instance running among the core switches and another IS-IS instance running
    overlaid on the core among the edge-switches.

    I have heard on this list queries about running an instance per VLAN. I
    made a comment (maybe not very well in Paris) that we will have a tradeoff
    between fault isolation and scalability. If you want one IS-IS instance to
    run independently from the others (i.e. if it crashes only one VLAN is
    effected, if you want to reload that IS-IS with a new software release,
    if you want to limit DOS attacks, etc) then you go with separate instances.
  
    But separate instances will stress memory and CPU resources on the switch.
    Also, there are metro deployments that will want to deploy more than 4K
    VLANs, so the different sets of VLANs will have to be distinguished and
    now there are even more instances.

    This same argument comes up in L3 VPNs when a router designer has to
    decide to support 10,000 VRFs with 10,000 different instances of an IGP
    or BGP. The line seems to be drawn around 50 (or less) for separate
    processes/instances. So some fate-sharing of failures is inevitable at
    the benefit of scalability.

    I propose this:

    o One core-instance
    o One edge-instance
    o n Broadcast trees, one for each VLAN computed by the core-instance.
    o k Multicast trees, that span *across* VLANs so you get best bandwidth/
      link efficiencies where k is the number of sources times number of
      groups, where sources here are source edge-switches and not source end-
      nodes.

>> With multiple instances, R *still* needs to forward the information 
>> (assuming R is on the spanning
>> tree for VLAN A), but R would only be forwarding in "datagram" mode, as 
>> if the IS-IS instance
>> running over VLAN A were just normal data traffic.

    Yes, we use the broadcast tree for VLAN A here where each VLAN can have
    a different root and the spanning tree is computed by the core IS-IS
    instance.

>> 1) if most RBridges support most of the VLANs, then it's clearly better 
>> to just flood all the information
>> in one instance

    I think this all depends on how topological wide the rBridge network will
    span. You could have geographically close VPNs on a metro deployment 
    where flooding would be rather inefficient.

    I think this list really has to decide how large we anticipate an rBridge
    network is going to be. Traditionally, an L2 network is usually less than
    50 nodes and I would say the average is more like 10. If we stay with
    these sort of numbers, then we can under-optimize in the spirit of more
    simplicity.

>> 2) if only a very few RBridges support a given VLAN, then having 
>> multiple instances saves memory
>> in other RBridges. Furthermore, it saves traffic, because VLAN A 
>> information only has to be sent on
>> a tree from the RBridge injecting the VLAN A information to the RBridges 
>> that attach to VLAN A.

    The next question would be, would people deploy rBridges to do an 
    alternative to VPLS where the rBridges use tunnels over an IP network to
    connect each other. And then the same question of size should be asked
    for this environment as well.

>> Note from the IS-IS implementers I talked to, they seemed to think that 
>> having multiple instances
>> was not a big deal, but it would be better to have the discussion in 
>> email on the list if anyone
>> has strong opinions.

    Multiple instances seem to be what people want for Virtual Router type
    capability. But they seek to have separate management *and* failure
    domains more so than scalability. But the VPN/VRF folks want it the
    other way, where they want separate management domains but larger number 
    VPNs.

Dino


Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8NK6Sn01690 for <[e-mail]>; Fri, 23 Sep 2005 13:06:29 -0700 (PDT)
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 23 Sep 2005 13:06:23 -0700
X-IronPort-AV: i="3.97,141,1125903600";  d="scan'208"; a="214490893:sNHT25267832"
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j8NK6IVt004921 for <[e-mail]>; Fri, 23 Sep 2005 13:06:19 -0700 (PDT)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j8NK6LAS025918 for <[e-mail]>; Fri, 23 Sep 2005 13:06:21 -0700
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j8NK6LOq025914; Fri, 23 Sep 2005 13:06:21 -0700
Date: Fri, 23 Sep 2005 13:06:21 -0700
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> (message from Radia Perlman on Thu, 22 Sep 2005 21:12:13 -0700)
References: <[e-mail]> <77905507F6E3FBE9466ABE6F@Mike_HP.linx.net> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] STP and ISIS
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, 23 Sep 2005 20:07:28 -0000
Status: RO
Content-Length: 561

>> I agree with what Mike said, but just to clarify...although there are 
>> spanning trees computed in order
>> to send multicast packets, and packets for unknown destinations, and IP 
>> multicasts, the spanning
>> trees (yes, multiple ones) are computed from the information already 
>> distributed in the link
>> state protocol. There's no need for an extra protocol to compute a 
>> spanning tree.

    This should be a major goal of the solution space. Bridges need to stay
    simple and self-configuring. And we can achieve this with IS-IS.

Dino

    


Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8NGven05532 for <[e-mail]>; Fri, 23 Sep 2005 09:57:40 -0700 (PDT)
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 23 Sep 2005 09:57:25 -0700
X-IronPort-AV: i="3.97,141,1125903600";  d="scan'208"; a="344894111:sNHT947469120"
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8NGuoKc021062 for <[e-mail]>; Fri, 23 Sep 2005 09:57:20 -0700 (PDT)
From: [e-mail]
Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Sep 2005 09:57:22 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Fri, 23 Sep 2005 09:57:22 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Configuration of VLANs vs selfconfiguration
Thread-Index: AcXAUkcwgSt91ClMQ2e5Yqun793u6QADOvZw
To: "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 23 Sep 2005 16:57:22.0776 (UTC) FILETIME=[DDEEAD80:01C5C05F]
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 j8NGven05532
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
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, 23 Sep 2005 16:57:59 -0000
Status: RO
Content-Length: 3723

 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Joe Touch
> 
> I'm not sure whether being in more than one VLAN breaks this 
> or is permitted (it seems like it wouldn't be, but I'm not sure).
> 
> However, the step below assumes a preconfigured management function:
> >>- Some management function replies "I do - he's in vlan G"
> 
> That's not zero-config to me; it, like DHCP, just moves the 
> configuration to a central location.

Agreed, another option would be to move the config to the host and use GVRP from the host.  However, VLANs are a topology construct and the VLAN determination is typically determined based on where the device is attached so neither approach would likely become prevalent.  As a side note, GVRP is scarcely used in the campus today, even between switches.

Michael

> 
> Joe
> 
> 
> Gray, Eric wrote:
> > Joe,
> > 
> > 	Last I heard, there was nothing preventing the same MAC address 
> > living in more than one VLAN.  In fact, for routers and 
> VLAN bridges, 
> > wouldn't this be the dominant case?
> > 
> > 	If that has not changed, then the suggested approach 
> will not even 
> > work - independent of whether or not its in scope for what we're 
> > trying to do.
> > 
> > --
> > Eric
> > 
> > ====================================================================
> > While Harald's suggestion is interesting, IMO it would be 
> part of an 
> > rbridge only after it has been developed for bridges first.
> > 
> > This is not an rbridge issue.
> > 
> > Joe
> > 
> > Harald Tveit Alvestrand wrote:
> > 
> >>--On fredag, september 23, 2005 09:38:53 +0200 Guillermo Ib??ez 
> >><[e-mail]> wrote:
> >>
> >>
> >>
> >>>  IMHO, with this restrictive interpretation of zero 
> configuration we 
> >>>solve only half of the configuration problem.
> >>>  Anyway, if this is the prevalent opinion, I suggest to add  this 
> >>>clarification  to the draft (zero configuration for single 
> LAN, equal 
> >>>configuration for VLANs as standard bridges).
> >>>Guillermo
> >>
> >>
> >>I think you could in theory get close to zeroconf for VLAN 
> membership.
> >>It would go something like:
> >>
> >>- Device attaches
> >>- Bridge broadcasts "who knows this guy" on a reserved "management" 
> >>VLAN
> >>- Some management function replies "I do - he's in vlan G"
> >>- Bridge configures the port to that VLAN
> >>  (or if no reply - to a "default" VLAN)
> >>
> >>(For extra credits, work in where to add 802.1x authentication)
> >>
> >>The only config on the bridge would be what answers to believe 
> >>(security makes complete zeroconf impossible, but we all 
> know that by 
> >>now....)
> >>
> >>But this mechanism would be completely orthogonal to what TRILL is 
> >>about, of course. So this is not the right list to discuss it.
> >>
> >>                       Harald
> >>
> >>_______________________________________________
> >>rbridge mailing list
> >>[e-mail]
> >>http://www.postel.org/mailman/listinfo/rbridge
> > 
> > 
> > --> -----Original Message-----
> > --> From: [e-mail]
> > --> [mailto:[e-mail]]On
> > --> Behalf Of Joe Touch
> > --> Sent: Friday, September 23, 2005 10:21 AM
> > --> To: Developing a hybrid router/bridge.
> > --> Subject: Re: [rbridge] Configuration of VLANs vs 
> selfconfiguration
> > --> 
> > --> 
> > --> _______________________________________________
> > --> 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 j8NFv3n16569 for <[e-mail]>; Fri, 23 Sep 2005 08:57:03 -0700 (PDT)
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 j8NFuqhE028819 for <[e-mail]>; Fri, 23 Sep 2005 11:56:52 -0400 (EDT)
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 LAA10050 for <[e-mail]>; Fri, 23 Sep 2005 11:56:52 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THF3RYDC>; Fri, 23 Sep 2005 12:56:51 -0300
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Fri, 23 Sep 2005 12:56:51 -0300
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 j8NFv3n16569
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
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, 23 Sep 2005 15:57:58 -0000
Status: RO
Content-Length: 4789

Also, consider any device that participates in an arbitrary number
of VLANs using a single Ethernet PHY.  It should not - for example
- have 4096 MAC addresses.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]]On
--> Behalf Of Holland, David (David)
--> Sent: Friday, September 23, 2005 11:38 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
--> 
--> 
--> Joe,
--> 
--> A MAC may certainly be on more than one VLAN. Consider a 
--> BSD or Linux implementation with a virtual interface 
--> configured, and imagine an applications like telephony 
--> using the virtual interface with tagging (for priority) and 
--> other applications using the standard interface. Both flows 
--> will have the same MAC, but (potentially) belong to different VLANS.
--> 
--> David
--> 
--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]]On
--> Behalf Of Joe Touch
--> Sent: Friday, September 23, 2005 11:09 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
--> 
--> 
--> I'm not sure whether being in more than one VLAN breaks this or is
--> permitted (it seems like it wouldn't be, but I'm not sure).
--> 
--> However, the step below assumes a preconfigured management function:
--> >>- Some management function replies "I do - he's in vlan G"
--> 
--> That's not zero-config to me; it, like DHCP, just moves the
--> configuration to a central location.
--> 
--> Joe
--> 
--> 
--> Gray, Eric wrote:
--> > Joe,
--> > 
--> > 	Last I heard, there was nothing preventing the same MAC 
--> > address living in more than one VLAN.  In fact, for routers and
--> > VLAN bridges, wouldn't this be the dominant case?
--> > 
--> > 	If that has not changed, then the suggested approach will
--> > not even work - independent of whether or not its in scope for
--> > what we're trying to do.
--> > 
--> > --
--> > Eric
--> > 
--> > 
--> ====================================================================
--> > While Harald's suggestion is interesting, IMO it would be 
--> part of an
--> > rbridge only after it has been developed for bridges first.
--> > 
--> > This is not an rbridge issue.
--> > 
--> > Joe
--> > 
--> > Harald Tveit Alvestrand wrote:
--> > 
--> >>--On fredag, september 23, 2005 09:38:53 +0200 Guillermo Ib??ez 
--> >><[e-mail]> wrote:
--> >>
--> >>
--> >>
--> >>>  IMHO, with this restrictive interpretation of zero 
--> configuration we
--> >>>solve only half of the configuration problem.
--> >>>  Anyway, if this is the prevalent opinion, I suggest to 
--> add  this
--> >>>clarification  to the draft (zero configuration for 
--> single LAN, equal
--> >>>configuration for VLANs as standard bridges).
--> >>>Guillermo
--> >>
--> >>
--> >>I think you could in theory get close to zeroconf for 
--> VLAN membership.
--> >>It would go something like:
--> >>
--> >>- Device attaches
--> >>- Bridge broadcasts "who knows this guy" on a reserved 
--> "management" VLAN
--> >>- Some management function replies "I do - he's in vlan G"
--> >>- Bridge configures the port to that VLAN
--> >>  (or if no reply - to a "default" VLAN)
--> >>
--> >>(For extra credits, work in where to add 802.1x authentication)
--> >>
--> >>The only config on the bridge would be what answers to 
--> believe (security 
--> >>makes complete zeroconf impossible, but we all know that 
--> by now....)
--> >>
--> >>But this mechanism would be completely orthogonal to what 
--> TRILL is about, 
--> >>of course. So this is not the right list to discuss it.
--> >>
--> >>                       Harald
--> >>
--> >>_______________________________________________
--> >>rbridge mailing list
--> >>[e-mail]
--> >>http://www.postel.org/mailman/listinfo/rbridge
--> > 
--> > 
--> > --> -----Original Message-----
--> > --> From: [e-mail] 
--> > --> [mailto:[e-mail]]On
--> > --> Behalf Of Joe Touch
--> > --> Sent: Friday, September 23, 2005 10:21 AM
--> > --> To: Developing a hybrid router/bridge.
--> > --> Subject: Re: [rbridge] Configuration of VLANs vs 
--> selfconfiguration
--> > --> 
--> > --> 
--> > --> _______________________________________________
--> > --> 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 tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8NFbgn10872 for <[e-mail]>; Fri, 23 Sep 2005 08:37:42 -0700 (PDT)
Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8NFYvma008144 for <[e-mail]>; Fri, 23 Sep 2005 11:34:58 -0400 (EDT)
Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8NFYuma008112 for <[e-mail]>; Fri, 23 Sep 2005 11:34:56 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Fri, 23 Sep 2005 11:37:39 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Configuration of VLANs vs selfconfiguration
Thread-Index: AcXAU9eNVF9RoWfsS0m3VoM20uAjPwAAE1Mw
From: "Holland, David \(David\)" <[e-mail]>
To: "Developing a hybrid router/bridge." <[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 j8NFbgn10872
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
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, 23 Sep 2005 15:38:24 -0000
Status: RO
Content-Length: 3631

Joe,

A MAC may certainly be on more than one VLAN. Consider a BSD or Linux implementation with a virtual interface configured, and imagine an applications like telephony using the virtual interface with tagging (for priority) and other applications using the standard interface. Both flows will have the same MAC, but (potentially) belong to different VLANS.

David

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Joe Touch
Sent: Friday, September 23, 2005 11:09 AM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration


I'm not sure whether being in more than one VLAN breaks this or is
permitted (it seems like it wouldn't be, but I'm not sure).

However, the step below assumes a preconfigured management function:
>>- Some management function replies "I do - he's in vlan G"

That's not zero-config to me; it, like DHCP, just moves the
configuration to a central location.

Joe


Gray, Eric wrote:
> Joe,
> 
> 	Last I heard, there was nothing preventing the same MAC 
> address living in more than one VLAN.  In fact, for routers and
> VLAN bridges, wouldn't this be the dominant case?
> 
> 	If that has not changed, then the suggested approach will
> not even work - independent of whether or not its in scope for
> what we're trying to do.
> 
> --
> Eric
> 
> ====================================================================
> While Harald's suggestion is interesting, IMO it would be part of an
> rbridge only after it has been developed for bridges first.
> 
> This is not an rbridge issue.
> 
> Joe
> 
> Harald Tveit Alvestrand wrote:
> 
>>--On fredag, september 23, 2005 09:38:53 +0200 Guillermo Ib??ez 
>><[e-mail]> wrote:
>>
>>
>>
>>>  IMHO, with this restrictive interpretation of zero configuration we
>>>solve only half of the configuration problem.
>>>  Anyway, if this is the prevalent opinion, I suggest to add  this
>>>clarification  to the draft (zero configuration for single LAN, equal
>>>configuration for VLANs as standard bridges).
>>>Guillermo
>>
>>
>>I think you could in theory get close to zeroconf for VLAN membership.
>>It would go something like:
>>
>>- Device attaches
>>- Bridge broadcasts "who knows this guy" on a reserved "management" VLAN
>>- Some management function replies "I do - he's in vlan G"
>>- Bridge configures the port to that VLAN
>>  (or if no reply - to a "default" VLAN)
>>
>>(For extra credits, work in where to add 802.1x authentication)
>>
>>The only config on the bridge would be what answers to believe (security 
>>makes complete zeroconf impossible, but we all know that by now....)
>>
>>But this mechanism would be completely orthogonal to what TRILL is about, 
>>of course. So this is not the right list to discuss it.
>>
>>                       Harald
>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
> 
> 
> --> -----Original Message-----
> --> From: [e-mail] 
> --> [mailto:[e-mail]]On
> --> Behalf Of Joe Touch
> --> Sent: Friday, September 23, 2005 10:21 AM
> --> To: Developing a hybrid router/bridge.
> --> Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
> --> 
> --> 
> --> _______________________________________________
> --> 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 [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8NF8xn01655; Fri, 23 Sep 2005 08:08:59 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 23 Sep 2005 08:08:53 -0700
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.92.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBC5A314B0DC703C21D769C4A"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
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, 23 Sep 2005 15:10:05 -0000
Status: RO
Content-Length: 3885

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

I'm not sure whether being in more than one VLAN breaks this or is
permitted (it seems like it wouldn't be, but I'm not sure).

However, the step below assumes a preconfigured management function:
>>- Some management function replies "I do - he's in vlan G"

That's not zero-config to me; it, like DHCP, just moves the
configuration to a central location.

Joe


Gray, Eric wrote:
> Joe,
>=20
> 	Last I heard, there was nothing preventing the same MAC=20
> address living in more than one VLAN.  In fact, for routers and
> VLAN bridges, wouldn't this be the dominant case?
>=20
> 	If that has not changed, then the suggested approach will
> not even work - independent of whether or not its in scope for
> what we're trying to do.
>=20
> --
> Eric
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> While Harald's suggestion is interesting, IMO it would be part of an
> rbridge only after it has been developed for bridges first.
>=20
> This is not an rbridge issue.
>=20
> Joe
>=20
> Harald Tveit Alvestrand wrote:
>=20
>>--On fredag, september 23, 2005 09:38:53 +0200 Guillermo Ib=E1=F1ez=20
>><[e-mail]> wrote:
>>
>>
>>
>>>  IMHO, with this restrictive interpretation of zero configuration we
>>>solve only half of the configuration problem.
>>>  Anyway, if this is the prevalent opinion, I suggest to add  this
>>>clarification  to the draft (zero configuration for single LAN, equal
>>>configuration for VLANs as standard bridges).
>>>Guillermo
>>
>>
>>I think you could in theory get close to zeroconf for VLAN membership.
>>It would go something like:
>>
>>- Device attaches
>>- Bridge broadcasts "who knows this guy" on a reserved "management" VLA=
N
>>- Some management function replies "I do - he's in vlan G"
>>- Bridge configures the port to that VLAN
>>  (or if no reply - to a "default" VLAN)
>>
>>(For extra credits, work in where to add 802.1x authentication)
>>
>>The only config on the bridge would be what answers to believe (securit=
y=20
>>makes complete zeroconf impossible, but we all know that by now....)
>>
>>But this mechanism would be completely orthogonal to what TRILL is abou=
t,=20
>>of course. So this is not the right list to discuss it.
>>
>>                       Harald
>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>=20
>=20
> --> -----Original Message-----
> --> From: [e-mail]=20
> --> [mailto:[e-mail]]On
> --> Behalf Of Joe Touch
> --> Sent: Friday, September 23, 2005 10:21 AM
> --> To: Developing a hybrid router/bridge.
> --> Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
> -->=20
> -->=20
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://www.postel.org/mailman/listinfo/rbridge
> -->=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


--------------enigBC5A314B0DC703C21D769C4A
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 Thunderbird - http://enigmail.mozdev.org

iD8DBQFDNBqFE5f5cImnZrsRAuZaAKD4fq+Giav6bIa28q90SOkatgzqRwCeL42E
fEiaZLtP9sik6QwD6Tar+Sk=
=9M2O
-----END PGP SIGNATURE-----

--------------enigBC5A314B0DC703C21D769C4A--


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 j8NEjan23997 for <[e-mail]>; Fri, 23 Sep 2005 07:45:36 -0700 (PDT)
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 j8NEjUhE027013 for <[e-mail]>; Fri, 23 Sep 2005 10:45:30 -0400 (EDT)
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 KAA01272 for <[e-mail]>; Fri, 23 Sep 2005 10:45:30 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THF3RVTC>; Fri, 23 Sep 2005 11:45:29 -0300
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Fri, 23 Sep 2005 11:45:28 -0300
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 j8NEjan23997
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
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, 23 Sep 2005 14:46:00 -0000
Status: RO
Content-Length: 2386

Joe,

	Last I heard, there was nothing preventing the same MAC 
address living in more than one VLAN.  In fact, for routers and
VLAN bridges, wouldn't this be the dominant case?

	If that has not changed, then the suggested approach will
not even work - independent of whether or not its in scope for
what we're trying to do.

--
Eric

====================================================================
While Harald's suggestion is interesting, IMO it would be part of an
rbridge only after it has been developed for bridges first.

This is not an rbridge issue.

Joe

Harald Tveit Alvestrand wrote:
> 
> --On fredag, september 23, 2005 09:38:53 +0200 Guillermo Ib??ez 
> <[e-mail]> wrote:
> 
> 
>>   IMHO, with this restrictive interpretation of zero configuration we
>>solve only half of the configuration problem.
>>   Anyway, if this is the prevalent opinion, I suggest to add  this
>>clarification  to the draft (zero configuration for single LAN, equal
>>configuration for VLANs as standard bridges).
>>Guillermo
> 
> 
> I think you could in theory get close to zeroconf for VLAN membership.
> It would go something like:
> 
> - Device attaches
> - Bridge broadcasts "who knows this guy" on a reserved "management" VLAN
> - Some management function replies "I do - he's in vlan G"
> - Bridge configures the port to that VLAN
>   (or if no reply - to a "default" VLAN)
> 
> (For extra credits, work in where to add 802.1x authentication)
> 
> The only config on the bridge would be what answers to believe (security 
> makes complete zeroconf impossible, but we all know that by now....)
> 
> But this mechanism would be completely orthogonal to what TRILL is about, 
> of course. So this is not the right list to discuss it.
> 
>                        Harald
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]]On
--> Behalf Of Joe Touch
--> Sent: Friday, September 23, 2005 10:21 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8NENhn17348; Fri, 23 Sep 2005 07:23:43 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 23 Sep 2005 07:23:37 -0700
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.92.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8BC087AEB654CA27C5FAA189"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
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, 23 Sep 2005 14:24:25 -0000
Status: RO
Content-Length: 3704

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

If there is a way the routing protocol can be leveraged for distributing
VLAN info, or to run multiple VLANs over a single protocol, or to assist
with zero-config VLANs, that should be considered after the basic
rbridge system is defined, IMO.

I.e., these are extensions, not key aspects of the basic architecture,
IMO. The point of the rbridge, IMO, is increased cross-section bandwidth
- not, as many have focused on - issues of scale (either in number of
VLANs or number of nodes) beyond that of existing bridge systems per se.

Joe

Vishwas Manral wrote:
> Hi Joe,
>=20
> May be the question could be, do we intend the use of GVRP for distribu=
ting VLAN information even in Rbridge mode?=20
>=20
> I think the GVRP should be allowed else the Rbridge protocol should be =
extended for a similar purpose.
>=20
> Thanks,
> Vishwas
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Joe Touch
> Sent: Friday, September 23, 2005 5:40 AM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
>=20
> Rbridges are supposed to work like bridges:
>=20
> 	- zero configuration for a single LAN
> 	- as easy (or hard) to configure for VLANs
>=20
> They are not intended to be zero-config VLAN systems any more than
> bridges are.
>=20
> Joe
>=20
> Guillermo Ib=E1=F1ez wrote:
>=20
>>G. Ib=E1=F1ez wrote:
>>
>>I have a doubt since some time on VLAN configuration. One of the main=20
>>aspects driving the routing bridges proposal is to be configuration=20
>>free, like the transparent bridges, opposite to using  routers where IP=
=20
>>addresses must be  asigned, administered and may change when the host=20
>>moves in the network. However, VLAN configuration of bridges is an=20
>>important aspect and effort, that prevents selfconfiguration of rbridge=
s=20
>>to be achieved. In the Rbridges draft (see extract below), this problem=
=20
>>is skipped assuming the Rbridges are already configured with the=20
>>information on which VLANs should be supported on which port.
>>Although the problem of VLAN configuration is complex to handle, by=20
>>ignoring it we risk not to fulfill  one of the main requirements of=20
>>Rbridges: zero configuration.
>>Regards
>>Guillermo
>>
>>Extracted from draft:
>>
>>"Support of VLANs does traditionally require configuration=20
>>   of the bridges (or in this case RBridges) to know which links belong=
=20
>>   to which VLANs. In theory some other mechanism might allow an RBridg=
e=20
>>   to know which VLANs should be supported on which port. The RBridge=20
>>   design does not care how RBridges discover which VLANs are supported=
=20
>>   by each of their ports, but for simplicity we assume here that=20
>>   RBridges (like bridges) are configured with this information."=20
>>
>>
>>
>=20
>=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


--------------enig8BC087AEB654CA27C5FAA189
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 Thunderbird - http://enigmail.mozdev.org

iD8DBQFDNA/pE5f5cImnZrsRAmAaAKDcVDb5zs3ie4nJG7oBCSSN+Fy2OgCfV+81
cnSiER/oAzZWkvSItRRLBcw=
=fk6e
-----END PGP SIGNATURE-----

--------------enig8BC087AEB654CA27C5FAA189--


Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8NEL5n16793; Fri, 23 Sep 2005 07:21:05 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 23 Sep 2005 07:20:59 -0700
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]	m>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.92.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig11F87DF564C3177638845769"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
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, 23 Sep 2005 14:22:30 -0000
Status: RO
Content-Length: 2262

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

While Harald's suggestion is interesting, IMO it would be part of an
rbridge only after it has been developed for bridges first.

This is not an rbridge issue.

Joe

Harald Tveit Alvestrand wrote:
>=20
> --On fredag, september 23, 2005 09:38:53 +0200 Guillermo Ib=E1=F1ez=20
> <[e-mail]> wrote:
>=20
>=20
>>   IMHO, with this restrictive interpretation of zero configuration we
>>solve only half of the configuration problem.
>>   Anyway, if this is the prevalent opinion, I suggest to add  this
>>clarification  to the draft (zero configuration for single LAN, equal
>>configuration for VLANs as standard bridges).
>>Guillermo
>=20
>=20
> I think you could in theory get close to zeroconf for VLAN membership.
> It would go something like:
>=20
> - Device attaches
> - Bridge broadcasts "who knows this guy" on a reserved "management" VLA=
N
> - Some management function replies "I do - he's in vlan G"
> - Bridge configures the port to that VLAN
>   (or if no reply - to a "default" VLAN)
>=20
> (For extra credits, work in where to add 802.1x authentication)
>=20
> The only config on the bridge would be what answers to believe (securit=
y=20
> makes complete zeroconf impossible, but we all know that by now....)
>=20
> But this mechanism would be completely orthogonal to what TRILL is abou=
t,=20
> of course. So this is not the right list to discuss it.
>=20
>                        Harald
>=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


--------------enig11F87DF564C3177638845769
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 Thunderbird - http://enigmail.mozdev.org

iD8DBQFDNA9LE5f5cImnZrsRAozkAKDhvLc013jpBvWK1be3xqiJnqEapQCeK4aS
kpDUvrQFvai1OVAQjo59234=
=xtQW
-----END PGP SIGNATURE-----

--------------enig11F87DF564C3177638845769--


Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8N9ann02181 for <[e-mail]>; Fri, 23 Sep 2005 02:36:49 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 23 Sep 2005 02:39:17 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] IS-IS per VLAN ?
Thread-Index: AcXAIUzD3Ld20LbrSHWniV9iAwnPIgAAP+8Q
From: "Vishwas Manral" <[e-mail]>
To: "Tom Sanders" <[e-mail]>, "Developing a hybrid router/bridge." <[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 j8N9ann02181
Subject: Re: [rbridge] IS-IS per VLAN ?
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, 23 Sep 2005 09:36:58 -0000
Status: RO
Content-Length: 5004

Hi Tom,

Extending what you are saying, using GVRP, for each VLAN detected we
would have to start a new instance of the Routing Protocol.

In my view we would not run multiple instances of the LS Routing
Protocol, but be running a single instances but logically divide the
topology. I am not sure, but Multi-topology extensions to Routing
Protocols could help in such a case.

Thanks,
Vishwas
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Tom Sanders
Sent: Friday, September 23, 2005 2:47 PM
To: [e-mail]
Subject: Re: [rbridge] IS-IS per VLAN ?

I would prefer to have a single instance of ISIS running, that has all
the vlan information irrespective of whether it is attached to a
subset of vlans or not. I see an issue in running multiple instances:

What if an Rbridge at some later time is configured for vlan A, a vlan
for which it wasnt configured before? If so,  then we need to have an
algorithm that syncs up its LSD for Vlan A.

If OTOH, we have a single instance running then this isnt an issue at
all.

Toms.

On 22/09/05, Radia Perlman <[e-mail]> wrote:
> The reason for multiple instances is so that a core RBridge that is
not
> attached to VLAN A will
> not have to store information for endnodes in VLAN A.
>
> An alternative is to just flood all the endnode information for all
> VLANs in a single instance of IS-IS.
> This is certainly conceptually simpler. And the VLAN A endnode
> information would not have to
> appear in the forwarding table of an RBridge, R, that was not attached
> to VLAN A. However, because
> of link state reliable flooding, R *would* have to store the endnode
> information in memory in
> order to make sure that information gets flooded reliably to R's
neighbors.
>
> With multiple instances, R *still* needs to forward the information
> (assuming R is on the spanning
> tree for VLAN A), but R would only be forwarding in "datagram" mode,
as
> if the IS-IS instance
> running over VLAN A were just normal data traffic.
>
> So it's an interesting tradeoff. I don't have strong opinions about
this.
>
> So, for clarity, I see the choices we're discussing as:
>
> a) single instance, where VLAN A information is flooded as essentially
> opaque data by non-VLAN A
> RBridges, but is reliably stored as part of the link state information
>
> b) per-VLAN instance, where the core instance gives enough information
> for RBridges to have the
> link state information and the RBridge-VLAN info necessary to flood
VLAN
> A information
> to just VLAN A RBridges. Then an instance of IS-IS for VLAN A would
use
> that ability
> to flood to just VLAN-A links in order to have the VLAN A RBridges
share
> endnode information
> with each other. Note the VLAN-A instance would see the topology as
just
> being a single link,
> where all VLAN A RBridges were direct neighbors.
>
> As for the tradeoffs I see:
> 1) if most RBridges support most of the VLANs, then it's clearly
better
> to just flood all the information
> in one instance
> 2) if only a very few RBridges support a given VLAN, then having
> multiple instances saves memory
> in other RBridges. Furthermore, it saves traffic, because VLAN A
> information only has to be sent on
> a tree from the RBridge injecting the VLAN A information to the
RBridges
> that attach to VLAN A.
>
> Note from the IS-IS implementers I talked to, they seemed to think
that
> having multiple instances
> was not a big deal, but it would be better to have the discussion in
> email on the list if anyone
> has strong opinions.
>
> Radia
>
>
>
> Mike Hughes wrote:
>
> >--On 22 September 2005 20:26 +0530 Ganesh CS <[e-mail]>
wrote:
> >
> >
> >
> >> From end node learning preso(
> >>http://www.postel.org/rbridge/trill-ietf63/trillendnodelearn.pdf ) I
see
> >>that IS-IS per VLAN has been recommended. Since there can be 4096
VLANs
> >>per 802.1Q it looks like we may have to run 4096 IS-IS instances.
Are we
> >>going for this approach ? Is this a scalable solution ?
> >>
> >>
> >
> >I'm not 100% certain what this would gain in a core-type rbridge
transport
> >network. You would assume that all VLANs would be "flooded"
throughout the
> >core transmission infrastructure (so in the STP world could be done
with a
> >single spanning tree).
> >
> >MISTP/PVST seems to primarily be offered as a solution for dealing
with
> >making better use of redundant links by allowing different blocked
links to
> >exist for each VLAN, or where the VLAN and physical topologies are
> >significantly non-concurrent.
> >
> >Unless I'm missing something, I can't work out what multiple
instances of
> >ISIS would achieve.
> >
> >Cheers,
> >Mike
> >
> >
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
>


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




Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.206]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8N9HOn28009 for <[e-mail]>; Fri, 23 Sep 2005 02:17:24 -0700 (PDT)
Received: by xproxy.gmail.com with SMTP id s15so691888wxc for <[e-mail]>; Fri, 23 Sep 2005 02:16:56 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nGmUOZ6/sOA3oQlIReFfRAG582fwaB3O+l6vdhVkkuxVF6Gd5qX8UJY1ZkeeAiJv8Y8w201UjanIOUL4/CKNS28YgX9JTCuuGMDTuRU8Ez0Es6iUG0yFuoY2ybyzCwlDgusRN9HcI9xuHQsk549JeNFt1WNunWzZ+F17MzaoH5E=
Received: by 10.70.110.20 with SMTP id i20mr866075wxc; Fri, 23 Sep 2005 02:16:56 -0700 (PDT)
Received: by 10.70.76.17 with HTTP; Fri, 23 Sep 2005 02:16:56 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 23 Sep 2005 14:46:56 +0530
From: Tom Sanders <[e-mail]>
To: [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]> <5677C1974412605B468B89BC@Mike_HP.linx.net> <[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 j8N9HOn28009
Subject: Re: [rbridge] IS-IS per VLAN ?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: Tom Sanders <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 23 Sep 2005 09:18:32 -0000
Status: RO
Content-Length: 4248

I would prefer to have a single instance of ISIS running, that has all
the vlan information irrespective of whether it is attached to a
subset of vlans or not. I see an issue in running multiple instances:

What if an Rbridge at some later time is configured for vlan A, a vlan
for which it wasnt configured before? If so,  then we need to have an
algorithm that syncs up its LSD for Vlan A.

If OTOH, we have a single instance running then this isnt an issue at all.

Toms.

On 22/09/05, Radia Perlman <[e-mail]> wrote:
> The reason for multiple instances is so that a core RBridge that is not
> attached to VLAN A will
> not have to store information for endnodes in VLAN A.
>
> An alternative is to just flood all the endnode information for all
> VLANs in a single instance of IS-IS.
> This is certainly conceptually simpler. And the VLAN A endnode
> information would not have to
> appear in the forwarding table of an RBridge, R, that was not attached
> to VLAN A. However, because
> of link state reliable flooding, R *would* have to store the endnode
> information in memory in
> order to make sure that information gets flooded reliably to R's neighbors.
>
> With multiple instances, R *still* needs to forward the information
> (assuming R is on the spanning
> tree for VLAN A), but R would only be forwarding in "datagram" mode, as
> if the IS-IS instance
> running over VLAN A were just normal data traffic.
>
> So it's an interesting tradeoff. I don't have strong opinions about this.
>
> So, for clarity, I see the choices we're discussing as:
>
> a) single instance, where VLAN A information is flooded as essentially
> opaque data by non-VLAN A
> RBridges, but is reliably stored as part of the link state information
>
> b) per-VLAN instance, where the core instance gives enough information
> for RBridges to have the
> link state information and the RBridge-VLAN info necessary to flood VLAN
> A information
> to just VLAN A RBridges. Then an instance of IS-IS for VLAN A would use
> that ability
> to flood to just VLAN-A links in order to have the VLAN A RBridges share
> endnode information
> with each other. Note the VLAN-A instance would see the topology as just
> being a single link,
> where all VLAN A RBridges were direct neighbors.
>
> As for the tradeoffs I see:
> 1) if most RBridges support most of the VLANs, then it's clearly better
> to just flood all the information
> in one instance
> 2) if only a very few RBridges support a given VLAN, then having
> multiple instances saves memory
> in other RBridges. Furthermore, it saves traffic, because VLAN A
> information only has to be sent on
> a tree from the RBridge injecting the VLAN A information to the RBridges
> that attach to VLAN A.
>
> Note from the IS-IS implementers I talked to, they seemed to think that
> having multiple instances
> was not a big deal, but it would be better to have the discussion in
> email on the list if anyone
> has strong opinions.
>
> Radia
>
>
>
> Mike Hughes wrote:
>
> >--On 22 September 2005 20:26 +0530 Ganesh CS <[e-mail]> wrote:
> >
> >
> >
> >> From end node learning preso(
> >>http://www.postel.org/rbridge/trill-ietf63/trillendnodelearn.pdf ) I see
> >>that IS-IS per VLAN has been recommended. Since there can be 4096 VLANs
> >>per 802.1Q it looks like we may have to run 4096 IS-IS instances. Are we
> >>going for this approach ? Is this a scalable solution ?
> >>
> >>
> >
> >I'm not 100% certain what this would gain in a core-type rbridge transport
> >network. You would assume that all VLANs would be "flooded" throughout the
> >core transmission infrastructure (so in the STP world could be done with a
> >single spanning tree).
> >
> >MISTP/PVST seems to primarily be offered as a solution for dealing with
> >making better use of redundant links by allowing different blocked links to
> >exist for each VLAN, or where the VLAN and physical topologies are
> >significantly non-concurrent.
> >
> >Unless I'm missing something, I can't work out what multiple instances of
> >ISIS would achieve.
> >
> >Cheers,
> >Mike
> >
> >
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
>


--
Toms.


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 j8N8XZn18067 for <[e-mail]>; Fri, 23 Sep 2005 01:33:35 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B1F498CD60 for <[e-mail]>; Fri, 23 Sep 2005 10:33:28 +0200 (CEST)
Received: from [163.117.203.200] (unknown [163.117.203.200]) by smtp01.uc3m.es (Postfix) with ESMTP id D1E138CDAD for <[e-mail]>; Fri, 23 Sep 2005 10:33:27 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 23 Sep 2005 10:33:27 +0200
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]	m>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
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, 23 Sep 2005 08:34:05 -0000
Status: RO
Content-Length: 1755

Guillermo Ib??ez wrote :
  Your proposal is fine, but I think it only covers configuring per-MAC 
belonging to a VLAN, not per-port, and per-port  is the criteria to 
belong to VLAN most related with the bridges,  where the real splitting 
of the physical network into separate virtual networks is done.  Per MAC 
belonging to VLAN can be considered "external" to the bridge, as your 
proposal shows.
Guillermo

 Harald Tveit Alvestrand wrote:

>--On fredag, september 23, 2005 09:38:53 +0200 Guillermo Ib??ez 
><[e-mail]> wrote:
>
>  
>
>>   IMHO, with this restrictive interpretation of zero configuration we
>>solve only half of the configuration problem.
>>   Anyway, if this is the prevalent opinion, I suggest to add  this
>>clarification  to the draft (zero configuration for single LAN, equal
>>configuration for VLANs as standard bridges).
>>Guillermo
>>    
>>
>
>I think you could in theory get close to zeroconf for VLAN membership.
>It would go something like:
>
>- Device attaches
>- Bridge broadcasts "who knows this guy" on a reserved "management" VLAN
>- Some management function replies "I do - he's in vlan G"
>- Bridge configures the port to that VLAN
>  (or if no reply - to a "default" VLAN)
>
>(For extra credits, work in where to add 802.1x authentication)
>
>The only config on the bridge would be what answers to believe (security 
>makes complete zeroconf impossible, but we all know that by now....)
>
>But this mechanism would be completely orthogonal to what TRILL is about, 
>of course. So this is not the right list to discuss it.
>
>                       Harald
>
>_______________________________________________
>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 j8N85bn11460 for <[e-mail]>; Fri, 23 Sep 2005 01:05:37 -0700 (PDT)
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 160562581B0 for <[e-mail]>; Fri, 23 Sep 2005 10:05:06 +0200 (CEST)
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 07596-08 for <[e-mail]>; Fri, 23 Sep 2005 10:05:01 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2488525817F for <[e-mail]>; Fri, 23 Sep 2005 10:05:01 +0200 (CEST)
Date: Fri, 23 Sep 2005 10:05:30 +0200
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] m>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
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]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j8N85bn11460
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
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, 23 Sep 2005 08:05:56 -0000
Status: RO
Content-Length: 1126

--On fredag, september 23, 2005 09:38:53 +0200 Guillermo Ib??ez 
<[e-mail]> wrote:

>    IMHO, with this restrictive interpretation of zero configuration we
> solve only half of the configuration problem.
>    Anyway, if this is the prevalent opinion, I suggest to add  this
> clarification  to the draft (zero configuration for single LAN, equal
> configuration for VLANs as standard bridges).
> Guillermo

I think you could in theory get close to zeroconf for VLAN membership.
It would go something like:

- Device attaches
- Bridge broadcasts "who knows this guy" on a reserved "management" VLAN
- Some management function replies "I do - he's in vlan G"
- Bridge configures the port to that VLAN
  (or if no reply - to a "default" VLAN)

(For extra credits, work in where to add 802.1x authentication)

The only config on the bridge would be what answers to believe (security 
makes complete zeroconf impossible, but we all know that by now....)

But this mechanism would be completely orthogonal to what TRILL is about, 
of course. So this is not the right list to discuss it.

                       Harald



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 j8N7d1n04410 for <[e-mail]>; Fri, 23 Sep 2005 00:39:01 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C851A8CD3D for <[e-mail]>; Fri, 23 Sep 2005 09:38:54 +0200 (CEST)
Received: from [163.117.203.200] (unknown [163.117.203.200]) by smtp01.uc3m.es (Postfix) with ESMTP id E34A28CCD5 for <[e-mail]>; Fri, 23 Sep 2005 09:38:53 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 23 Sep 2005 09:38:53 +0200
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]> <[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] Configuration of VLANs vs selfconfiguration
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, 23 Sep 2005 07:39:59 -0000
Status: RO
Content-Length: 2373

   IMHO, with this restrictive interpretation of zero configuration we 
solve only half of the configuration problem.    
   Anyway, if this is the prevalent opinion, I suggest to add  this 
clarification  to the draft (zero configuration for single LAN, equal 
configuration for VLANs as standard bridges).
Guillermo

Joe Touch wrote:

>Rbridges are supposed to work like bridges:
>
>	- zero configuration for a single LAN
>	- as easy (or hard) to configure for VLANs
>
>They are not intended to be zero-config VLAN systems any more than
>bridges are.
>
>Joe
>
>Guillermo Ib??ez wrote:
>  
>
>>G. Ib??ez wrote:
>>
>>I have a doubt since some time on VLAN configuration. One of the main 
>>aspects driving the routing bridges proposal is to be configuration 
>>free, like the transparent bridges, opposite to using  routers where IP 
>>addresses must be  asigned, administered and may change when the host 
>>moves in the network. However, VLAN configuration of bridges is an 
>>important aspect and effort, that prevents selfconfiguration of rbridges 
>>to be achieved. In the Rbridges draft (see extract below), this problem 
>>is skipped assuming the Rbridges are already configured with the 
>>information on which VLANs should be supported on which port.
>>Although the problem of VLAN configuration is complex to handle, by 
>>ignoring it we risk not to fulfill  one of the main requirements of 
>>Rbridges: zero configuration.
>>Regards
>>Guillermo
>>
>>Extracted from draft:
>>
>>"Support of VLANs does traditionally require configuration 
>>   of the bridges (or in this case RBridges) to know which links belong 
>>   to which VLANs. In theory some other mechanism might allow an RBridge 
>>   to know which VLANs should be supported on which port. The RBridge 
>>   design does not care how RBridges discover which VLANs are supported 
>>   by each of their ports, but for simplicity we assume here that 
>>   RBridges (like bridges) are configured with this information." 
>>
>>
>>_______________________________________________
>>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 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 j8N4CKn16291 for <[e-mail]>; Thu, 22 Sep 2005 21:12:20 -0700 (PDT)
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]; Thu, 22 Sep 2005 21:12:14 -0700 (PDT)
Received: from sun.com ([129.150.26.150]) 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]; Thu, 22 Sep 2005 21:12:14 -0700 (PDT)
Date: Thu, 22 Sep 2005 21:12:13 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <77905507F6E3FBE9466ABE6F@Mike_HP.linx.net>
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]> <77905507F6E3FBE9466ABE6F@Mike_HP.linx.net>
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] STP and ISIS
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, 23 Sep 2005 04:12:56 -0000
Status: RO
Content-Length: 1960

I agree with what Mike said, but just to clarify...although there are 
spanning trees computed in order
to send multicast packets, and packets for unknown destinations, and IP 
multicasts, the spanning
trees (yes, multiple ones) are computed from the information already 
distributed in the link
state protocol. There's no need for an extra protocol to compute a 
spanning tree.

Radia



Mike Hughes wrote:

>--On 21 September 2005 12:04 +0530 Tom Sanders <[e-mail]>
>wrote:
>
>  
>
>>So, is the proposal to totally do away with STP et. al and run only
>>ISIS instead? The spanning tree is then computed with the topology
>>information provided by ISIS. Is this correct?
>>    
>>
>
>The proposal is to give a more optimal alternative for spanning tree in a
>"campus" L2 network.
>
>The problem with spanning tree, as you correctly assert, is that you end up
>with blocked links. In more complex L2 topologies, you can end up with
>significant numbers of blocked links. Blocked links = wasted bandwidth,
>which is especially expensive/wasteful at something like 10Gig/nx10Gig.
>
>Blocked links also mean sub-optimal, rather than shortest path, forwarding
>within the network.
>
>The proposal (almost) completely replaces STP within a "campus" L2 network
>of switches/bridges. (I say almost, as it looks like a spanning tree will
>still need to be used for things like network layer broadcast frames.)
>
>It has the potential to be more efficient, and more elegant, as for known
>unicasted frames, delivery will be done via the shortest/most optimal path.
>The proposed encapsulation of payload will also add a TTL to manage
>temporary forwarding loops during convergence.
>
>While rbridge was originally concieved for managing redundancy and mobility
>within a campus, I can think of other applications, such as within L2 metro
>networks (like the one I operate) where moving to an L3 routed solution is
>not an option.
>
>Regards,
>Mike
>  
>



Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8N3ukn12314 for <[e-mail]>; Thu, 22 Sep 2005 20:56:46 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Thu, 22 Sep 2005 20:59:15 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Configuration of VLANs vs selfconfiguration
Thread-Index: AcW/1NnSIHwEnfhFS4qiv1fDzSjJnAAGkNXw
From: "Vishwas Manral" <[e-mail]>
To: "Developing a hybrid router/bridge." <[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 j8N3ukn12314
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
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, 23 Sep 2005 03:56:56 -0000
Status: RO
Content-Length: 2157

Hi Joe,

May be the question could be, do we intend the use of GVRP for distributing VLAN information even in Rbridge mode? 

I think the GVRP should be allowed else the Rbridge protocol should be extended for a similar purpose.

Thanks,
Vishwas
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Joe Touch
Sent: Friday, September 23, 2005 5:40 AM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration

Rbridges are supposed to work like bridges:

	- zero configuration for a single LAN
	- as easy (or hard) to configure for VLANs

They are not intended to be zero-config VLAN systems any more than
bridges are.

Joe

Guillermo Ib??ez wrote:
> 
> G. Ib??ez wrote:
> 
> I have a doubt since some time on VLAN configuration. One of the main 
> aspects driving the routing bridges proposal is to be configuration 
> free, like the transparent bridges, opposite to using  routers where IP 
> addresses must be  asigned, administered and may change when the host 
> moves in the network. However, VLAN configuration of bridges is an 
> important aspect and effort, that prevents selfconfiguration of rbridges 
> to be achieved. In the Rbridges draft (see extract below), this problem 
> is skipped assuming the Rbridges are already configured with the 
> information on which VLANs should be supported on which port.
> Although the problem of VLAN configuration is complex to handle, by 
> ignoring it we risk not to fulfill  one of the main requirements of 
> Rbridges: zero configuration.
> Regards
> Guillermo
> 
> Extracted from draft:
> 
> "Support of VLANs does traditionally require configuration 
>    of the bridges (or in this case RBridges) to know which links belong 
>    to which VLANs. In theory some other mechanism might allow an RBridge 
>    to know which VLANs should be supported on which port. The RBridge 
>    design does not care how RBridges discover which VLANs are supported 
>    by each of their ports, but for simplicity we assume here that 
>    RBridges (like bridges) are configured with this information." 
> 
> 
> 



Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8N09en18169; Thu, 22 Sep 2005 17:09:40 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 22 Sep 2005 17:09:35 -0700
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.92.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB452A4DD957628C3CB564093"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
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, 23 Sep 2005 00:09:58 -0000
Status: RO
Content-Length: 2554

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

Rbridges are supposed to work like bridges:

	- zero configuration for a single LAN
	- as easy (or hard) to configure for VLANs

They are not intended to be zero-config VLAN systems any more than
bridges are.

Joe

Guillermo Ib=E1=F1ez wrote:
>=20
> G. Ib=E1=F1ez wrote:
>=20
> I have a doubt since some time on VLAN configuration. One of the main=20
> aspects driving the routing bridges proposal is to be configuration=20
> free, like the transparent bridges, opposite to using  routers where IP=
=20
> addresses must be  asigned, administered and may change when the host=20
> moves in the network. However, VLAN configuration of bridges is an=20
> important aspect and effort, that prevents selfconfiguration of rbridge=
s=20
> to be achieved. In the Rbridges draft (see extract below), this problem=
=20
> is skipped assuming the Rbridges are already configured with the=20
> information on which VLANs should be supported on which port.
> Although the problem of VLAN configuration is complex to handle, by=20
> ignoring it we risk not to fulfill  one of the main requirements of=20
> Rbridges: zero configuration.
> Regards
> Guillermo
>=20
> Extracted from draft:
>=20
> "Support of VLANs does traditionally require configuration=20
>    of the bridges (or in this case RBridges) to know which links belong=
=20
>    to which VLANs. In theory some other mechanism might allow an RBridg=
e=20
>    to know which VLANs should be supported on which port. The RBridge=20
>    design does not care how RBridges discover which VLANs are supported=
=20
>    by each of their ports, but for simplicity we assume here that=20
>    RBridges (like bridges) are configured with this information."=20
>=20
>=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


--------------enigB452A4DD957628C3CB564093
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 Thunderbird - http://enigmail.mozdev.org

iD8DBQFDM0e/E5f5cImnZrsRArL8AKD7iQkHx+fLFEBrWl5UuUWU1VEQkACeJjY0
r9fYCsryVeliWnk85al94Ik=
=kJre
-----END PGP SIGNATURE-----

--------------enigB452A4DD957628C3CB564093--


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 j8MGbIn27722 for <[e-mail]>; Thu, 22 Sep 2005 09:37:18 -0700 (PDT)
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]; Thu, 22 Sep 2005 09:37:10 -0700 (PDT)
Received: from sun.com ([129.150.26.150]) 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]; Thu, 22 Sep 2005 09:37:10 -0700 (PDT)
Date: Thu, 22 Sep 2005 09:37:10 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <5677C1974412605B468B89BC@Mike_HP.linx.net>
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]> <5677C1974412605B468B89BC@Mike_HP.linx.net>
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] IS-IS per VLAN ?
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, 22 Sep 2005 16:38:24 -0000
Status: RO
Content-Length: 3417

The reason for multiple instances is so that a core RBridge that is not 
attached to VLAN A will
not have to store information for endnodes in VLAN A.

An alternative is to just flood all the endnode information for all 
VLANs in a single instance of IS-IS.
This is certainly conceptually simpler. And the VLAN A endnode 
information would not have to
appear in the forwarding table of an RBridge, R, that was not attached 
to VLAN A. However, because
of link state reliable flooding, R *would* have to store the endnode 
information in memory in
order to make sure that information gets flooded reliably to R's neighbors.

With multiple instances, R *still* needs to forward the information 
(assuming R is on the spanning
tree for VLAN A), but R would only be forwarding in "datagram" mode, as 
if the IS-IS instance
running over VLAN A were just normal data traffic.

So it's an interesting tradeoff. I don't have strong opinions about this.

So, for clarity, I see the choices we're discussing as:

a) single instance, where VLAN A information is flooded as essentially 
opaque data by non-VLAN A
RBridges, but is reliably stored as part of the link state information

b) per-VLAN instance, where the core instance gives enough information 
for RBridges to have the
link state information and the RBridge-VLAN info necessary to flood VLAN 
A information
to just VLAN A RBridges. Then an instance of IS-IS for VLAN A would use 
that ability
to flood to just VLAN-A links in order to have the VLAN A RBridges share 
endnode information
with each other. Note the VLAN-A instance would see the topology as just 
being a single link,
where all VLAN A RBridges were direct neighbors.

As for the tradeoffs I see:
1) if most RBridges support most of the VLANs, then it's clearly better 
to just flood all the information
in one instance
2) if only a very few RBridges support a given VLAN, then having 
multiple instances saves memory
in other RBridges. Furthermore, it saves traffic, because VLAN A 
information only has to be sent on
a tree from the RBridge injecting the VLAN A information to the RBridges 
that attach to VLAN A.

Note from the IS-IS implementers I talked to, they seemed to think that 
having multiple instances
was not a big deal, but it would be better to have the discussion in 
email on the list if anyone
has strong opinions.

Radia



Mike Hughes wrote:

>--On 22 September 2005 20:26 +0530 Ganesh CS <[e-mail]> wrote:
>
>  
>
>> From end node learning preso( 
>>http://www.postel.org/rbridge/trill-ietf63/trillendnodelearn.pdf ) I see 
>>that IS-IS per VLAN has been recommended. Since there can be 4096 VLANs 
>>per 802.1Q it looks like we may have to run 4096 IS-IS instances. Are we 
>>going for this approach ? Is this a scalable solution ?
>>    
>>
>
>I'm not 100% certain what this would gain in a core-type rbridge transport
>network. You would assume that all VLANs would be "flooded" throughout the
>core transmission infrastructure (so in the STP world could be done with a
>single spanning tree).
>
>MISTP/PVST seems to primarily be offered as a solution for dealing with
>making better use of redundant links by allowing different blocked links to
>exist for each VLAN, or where the VLAN and physical topologies are
>significantly non-concurrent.
>
>Unless I'm missing something, I can't work out what multiple instances of
>ISIS would achieve.
>
>Cheers,
>Mike
>  
>



Received: from weathered.linx.net (weathered.linx.net [195.66.232.37]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8MFL2n26397 for <[e-mail]>; Thu, 22 Sep 2005 08:21:02 -0700 (PDT)
Received: from [195.66.233.98] (helo=Mike_HP.linx.net) by weathered.linx.net with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 1EISsY-0000dS-00 for [e-mail]; Thu, 22 Sep 2005 16:20:54 +0100
Date: Thu, 22 Sep 2005 16:21:06 +0100
From: Mike Hughes <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-ID: <5677C1974412605B468B89BC@Mike_HP.linx.net>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Win32)
X-NCC-RegID: uk.linx
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] IS-IS per VLAN ?
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, 22 Sep 2005 15:21:55 -0000
Status: RO
Content-Length: 1166

--On 22 September 2005 20:26 +0530 Ganesh CS <[e-mail]> wrote:

>  From end node learning preso( 
> http://www.postel.org/rbridge/trill-ietf63/trillendnodelearn.pdf ) I see 
> that IS-IS per VLAN has been recommended. Since there can be 4096 VLANs 
> per 802.1Q it looks like we may have to run 4096 IS-IS instances. Are we 
> going for this approach ? Is this a scalable solution ?

I'm not 100% certain what this would gain in a core-type rbridge transport
network. You would assume that all VLANs would be "flooded" throughout the
core transmission infrastructure (so in the STP world could be done with a
single spanning tree).

MISTP/PVST seems to primarily be offered as a solution for dealing with
making better use of redundant links by allowing different blocked links to
exist for each VLAN, or where the VLAN and physical topologies are
significantly non-concurrent.

Unless I'm missing something, I can't work out what multiple instances of
ISIS would achieve.

Cheers,
Mike
-- 
Mike Hughes     Chief Technical Officer  London Internet Exchange
[e-mail]   http://www.linx.net/
     "Only one thing in life is certain: init is Process #1"



Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8MEw0n19364 for <[e-mail]>; Thu, 22 Sep 2005 07:58:00 -0700 (PDT)
Received: from india-core-1.cisco.com ([64.104.129.221]) by ind-iport-1.cisco.com with ESMTP; 22 Sep 2005 20:35:11 -0700
Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8MEv7bS023109 for <[e-mail]>; Thu, 22 Sep 2005 14:57:32 GMT
Received: from xfe-blr-411.apac.cisco.com ([64.104.140.151]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0);  Thu, 22 Sep 2005 20:26:48 +0530
Received: from [10.77.203.69] ([10.77.203.69]) by xfe-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Sep 2005 20:26:47 +0530
Message-ID: <[e-mail]>
Date: Thu, 22 Sep 2005 20:26:47 +0530
From: Ganesh CS <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Sep 2005 14:56:47.0997 (UTC) FILETIME=[DB4142D0:01C5BF85]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] IS-IS per VLAN ?
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, 22 Sep 2005 14:58:52 -0000
Status: RO
Content-Length: 321

Hi,
 From end node learning preso( 
http://www.postel.org/rbridge/trill-ietf63/trillendnodelearn.pdf ) I see 
that IS-IS per VLAN has been recommended. Since there can be 4096 VLANs 
per 802.1Q it looks like we may have to run 4096 IS-IS instances. Are we 
going for this approach ? Is this a scalable solution ?

Ganesh


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 j8MDOCn17457 for <[e-mail]>; Thu, 22 Sep 2005 06:24:12 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8473A8CCAB for <[e-mail]>; Thu, 22 Sep 2005 15:23:58 +0200 (CEST)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp01.uc3m.es (Postfix) with ESMTP id C58A98CCA6 for <[e-mail]>; Thu, 22 Sep 2005 15:23:57 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 22 Sep 2005 15:23:57 +0200
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] Configuration of VLANs vs selfconfiguration
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, 22 Sep 2005 13:24:50 -0000
Status: RO
Content-Length: 3156

Hi Vishwas,
         Yes, regarding the trunking ports, and no, as far as I know, 
regarding the terminal ports, that require specific configuration.  
(Unless the NIC at the hosts are GVRP-aware and preconfigured with the 
VLAN they belong to, and VLAN belonging is distributed in the network 
via GVRP). But this translates the configuration work to the each host., 
IMHO.
In the case of per-port VLANs,  somehow it must be stated which port of 
each bridge belongs to which VLAN.  Actually, this seems to be somewhat 
contradictory with real selfconfiguration (i.e. we split the physical 
network manually in different virtual networks, overriding 
selfconfiguration).
 In the case of per-MAC (dynamic) VLAN belonging, this is something to 
be configured somewhere  at central level (in  the vlan policy server)  
and the result (VLAN belonging), loaded into the rbridge.
      So perhaps we should forget about zero configuration, as long as 
VLANs  shall  still be specified and configured in the campus networks 
to provide separated broadcast domains. Or, alternatively, specify "zero 
IP configuration" in the design objectives.
Regards
GI

Vishwas Manral wrote:

>Hi Guillermo,
>
>Doesn't using GVRP help minimize configuration exchanges in the trunking ports case at least currently? Can't we use that in the Rbridge case too?
>
>Thanks,
>Vishwas
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
>Sent: Thursday, September 22, 2005 2:30 PM
>To: Developing a hybrid router/bridge.
>Subject: [rbridge] Configuration of VLANs vs selfconfiguration
>
>
>
>G. Ib??ez wrote:
>
>I have a doubt since some time on VLAN configuration. One of the main 
>aspects driving the routing bridges proposal is to be configuration 
>free, like the transparent bridges, opposite to using  routers where IP 
>addresses must be  asigned, administered and may change when the host 
>moves in the network. However, VLAN configuration of bridges is an 
>important aspect and effort, that prevents selfconfiguration of rbridges 
>to be achieved. In the Rbridges draft (see extract below), this problem 
>is skipped assuming the Rbridges are already configured with the 
>information on which VLANs should be supported on which port.
>Although the problem of VLAN configuration is complex to handle, by 
>ignoring it we risk not to fulfill  one of the main requirements of 
>Rbridges: zero configuration.
>Regards
>Guillermo
>
>Extracted from draft:
>
>"Support of VLANs does traditionally require configuration 
>   of the bridges (or in this case RBridges) to know which links belong 
>   to which VLANs. In theory some other mechanism might allow an RBridge 
>   to know which VLANs should be supported on which port. The RBridge 
>   design does not care how RBridges discover which VLANs are supported 
>   by each of their ports, but for simplicity we assume here that 
>   RBridges (like bridges) are configured with this information." 
>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>


Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8MAO7n02216 for <[e-mail]>; Thu, 22 Sep 2005 03:24:07 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Thu, 22 Sep 2005 03:26:34 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Configuration of VLANs vs selfconfiguration
Thread-Index: AcW/WJ1xYH3dZ2nXTNaAvru+YsjjhgABsb1Q
From: "Vishwas Manral" <[e-mail]>
To: "Developing a hybrid router/bridge." <[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 j8MAO7n02216
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
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, 22 Sep 2005 10:24:53 -0000
Status: RO
Content-Length: 1795

Hi Guillermo,

Doesn't using GVRP help minimize configuration exchanges in the trunking ports case at least currently? Can't we use that in the Rbridge case too?

Thanks,
Vishwas
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
Sent: Thursday, September 22, 2005 2:30 PM
To: Developing a hybrid router/bridge.
Subject: [rbridge] Configuration of VLANs vs selfconfiguration



G. Ib??ez wrote:

I have a doubt since some time on VLAN configuration. One of the main 
aspects driving the routing bridges proposal is to be configuration 
free, like the transparent bridges, opposite to using  routers where IP 
addresses must be  asigned, administered and may change when the host 
moves in the network. However, VLAN configuration of bridges is an 
important aspect and effort, that prevents selfconfiguration of rbridges 
to be achieved. In the Rbridges draft (see extract below), this problem 
is skipped assuming the Rbridges are already configured with the 
information on which VLANs should be supported on which port.
Although the problem of VLAN configuration is complex to handle, by 
ignoring it we risk not to fulfill  one of the main requirements of 
Rbridges: zero configuration.
Regards
Guillermo

Extracted from draft:

"Support of VLANs does traditionally require configuration 
   of the bridges (or in this case RBridges) to know which links belong 
   to which VLANs. In theory some other mechanism might allow an RBridge 
   to know which VLANs should be supported on which port. The RBridge 
   design does not care how RBridges discover which VLANs are supported 
   by each of their ports, but for simplicity we assume here that 
   RBridges (like bridges) are configured with this information." 




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 j8M90Gn08731 for <[e-mail]>; Thu, 22 Sep 2005 02:00:16 -0700 (PDT)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4A04E738E0 for <[e-mail]>; Thu, 22 Sep 2005 11:00:10 +0200 (CEST)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp03.uc3m.es (Postfix) with ESMTP id B2B5F706C0 for <[e-mail]>; Thu, 22 Sep 2005 11:00:09 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 22 Sep 2005 11:00:09 +0200
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: [rbridge] Configuration of VLANs vs selfconfiguration
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, 22 Sep 2005 09:01:01 -0000
Status: RO
Content-Length: 1344

G. Ib??ez wrote:

I have a doubt since some time on VLAN configuration. One of the main 
aspects driving the routing bridges proposal is to be configuration 
free, like the transparent bridges, opposite to using  routers where IP 
addresses must be  asigned, administered and may change when the host 
moves in the network. However, VLAN configuration of bridges is an 
important aspect and effort, that prevents selfconfiguration of rbridges 
to be achieved. In the Rbridges draft (see extract below), this problem 
is skipped assuming the Rbridges are already configured with the 
information on which VLANs should be supported on which port.
Although the problem of VLAN configuration is complex to handle, by 
ignoring it we risk not to fulfill  one of the main requirements of 
Rbridges: zero configuration.
Regards
Guillermo

Extracted from draft:

"Support of VLANs does traditionally require configuration 
   of the bridges (or in this case RBridges) to know which links belong 
   to which VLANs. In theory some other mechanism might allow an RBridge 
   to know which VLANs should be supported on which port. The RBridge 
   design does not care how RBridges discover which VLANs are supported 
   by each of their ports, but for simplicity we assume here that 
   RBridges (like bridges) are configured with this information." 




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 j8LNuEn21951; Wed, 21 Sep 2005 16:56:14 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 21 Sep 2005 16:56:21 -0700
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] STP and ISIS
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, 21 Sep 2005 23:57:18 -0000
Status: RO
Content-Length: 2463

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



[e-mail] wrote:
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Joe Touch
>>
>>Tom Sanders wrote:
>>
>>>Hi,
>>>
>>>Going through draft-perlman-rbridge-03.txt raised a doubt 
>>
>>in my mind.
>>
>>>Please let me know if my understanding of the matter is indeed
>>>correct:
>>>
>>>As per the draft, spanning tree algos concentrate a lot of 
>>
>>traffic on 
>>
>>>certain links as it marks some ports as blocked and only 
>>
>>the ones that 
>>
>>>are in the forwarding state can pass traffic. But as per my limited 
>>>knowledge, wouldnt STP mark only the redundant links as 
>>
>>blocked? If we 
>>
>>>dont mark them as blocked, then wouldnt that result in transient 
>>>loops, etc.
>>>
>>>Then the draft says that there are other issues as well because of 
>>>which the group has decided to use a link state routing 
>>
>>protocol; more 
>>
>>>specifically ISIS because of the advantages it offers against OSPF 
>>>(TLV encoded, runs over L2, etc).
>>>
>>>So, is the proposal to totally do away with STP et. al and run only 
>>>ISIS instead? The spanning tree is then computed with the topology 
>>>information provided by ISIS. Is this correct?
>>
>>Yes, AFAIK.
>>
>>
>>>If this is so, then we will once again mark some ports as blocked, 
>>>etc. How different is this from calculating the spanning 
>>
>>tree via the 
>>
>>>STP protocol?
>>
>>The difference is that the spanning tree will be used only 
>>for broadcast messages. There may also be more than one 
>>spanning tree, e.g., one per origin. In either case, the 
>>spanning tree is NOT used for forwarding unicast traffic; the 
>>ISIS-configured routing tables are.
> 
> 
> The statement above should be clarified as *known* unicasts do not
> follow the spanning tree.  Unicast traffic for unknown destinations will
> still follow the spanning tree.
> 
> Michael

Agreed

The only reason unknown unicasts would follow the tree is because they
are broadcast - though the reason they are broadcast is not because they
are sent on broadcast addresses, but rather flooded because of lack of
knowledge of attached port.

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

iD8DBQFDMfMkE5f5cImnZrsRAuixAJ0dumoFAz6O6Kpa5l9PJyWy7g7g1gCfT7Sv
382WyL8nnm/NBSnXbVI6uvw=
=UCKJ
-----END PGP SIGNATURE-----


Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8LNamn16379 for <[e-mail]>; Wed, 21 Sep 2005 16:36:48 -0700 (PDT)
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 21 Sep 2005 16:36:43 -0700
X-IronPort-AV: i="3.97,133,1125903600";  d="scan'208"; a="344212279:sNHT34854576"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8LNaW54019081; Wed, 21 Sep 2005 16:36:41 -0700 (PDT)
From: [e-mail]
Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 16:36:39 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 21 Sep 2005 16:36:38 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] STP and ISIS
Thread-Index: AcW++CUU/pQUH95WSkOAwzLmt0Pz0QADDn+A
To: "Developing a hybrid router/bridge." <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 21 Sep 2005 23:36:39.0284 (UTC) FILETIME=[504C3340:01C5BF05]
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 j8LNamn16379
Subject: Re: [rbridge] STP and ISIS
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, 21 Sep 2005 23:37:46 -0000
Status: RO
Content-Length: 1860

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Joe Touch
> 
> Tom Sanders wrote:
> > Hi,
> > 
> > Going through draft-perlman-rbridge-03.txt raised a doubt 
> in my mind.
> > Please let me know if my understanding of the matter is indeed
> > correct:
> > 
> > As per the draft, spanning tree algos concentrate a lot of 
> traffic on 
> > certain links as it marks some ports as blocked and only 
> the ones that 
> > are in the forwarding state can pass traffic. But as per my limited 
> > knowledge, wouldnt STP mark only the redundant links as 
> blocked? If we 
> > dont mark them as blocked, then wouldnt that result in transient 
> > loops, etc.
> > 
> > Then the draft says that there are other issues as well because of 
> > which the group has decided to use a link state routing 
> protocol; more 
> > specifically ISIS because of the advantages it offers against OSPF 
> > (TLV encoded, runs over L2, etc).
> > 
> > So, is the proposal to totally do away with STP et. al and run only 
> > ISIS instead? The spanning tree is then computed with the topology 
> > information provided by ISIS. Is this correct?
> 
> Yes, AFAIK.
> 
> > If this is so, then we will once again mark some ports as blocked, 
> > etc. How different is this from calculating the spanning 
> tree via the 
> > STP protocol?
> 
> The difference is that the spanning tree will be used only 
> for broadcast messages. There may also be more than one 
> spanning tree, e.g., one per origin. In either case, the 
> spanning tree is NOT used for forwarding unicast traffic; the 
> ISIS-configured routing tables are.

The statement above should be clarified as *known* unicasts do not
follow the spanning tree.  Unicast traffic for unknown destinations will
still follow the spanning tree.

Michael

> 
> Joe
> 


Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8LLoQn18474; Wed, 21 Sep 2005 14:50:26 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 21 Sep 2005 14:50:18 -0700
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: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.92.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5391CD271AA6835BB961D13C"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] STP and ISIS
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, 21 Sep 2005 21:50:53 -0000
Status: RO
Content-Length: 2130

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



Tom Sanders wrote:
> Hi,
> 
> Going through draft-perlman-rbridge-03.txt raised a doubt in my mind.
> Please let me know if my understanding of the matter is indeed
> correct:
> 
> As per the draft, spanning tree algos concentrate a lot of traffic on
> certain links as it marks some ports as blocked and only the ones that
> are in the forwarding state can pass traffic. But as per my limited
> knowledge, wouldnt STP mark only the redundant links as blocked? If we
> dont mark them as blocked, then wouldnt that result in transient
> loops, etc.
> 
> Then the draft says that there are other issues as well because of
> which the group has decided to use a link state routing protocol; more
> specifically ISIS because of the advantages it offers against OSPF
> (TLV encoded, runs over L2, etc).
> 
> So, is the proposal to totally do away with STP et. al and run only
> ISIS instead? The spanning tree is then computed with the topology
> information provided by ISIS. Is this correct?

Yes, AFAIK.

> If this is so, then we will once again mark some ports as blocked,
> etc. How different is this from calculating the spanning tree via the
> STP protocol?

The difference is that the spanning tree will be used only for broadcast
messages. There may also be more than one spanning tree, e.g., one per
origin. In either case, the spanning tree is NOT used for forwarding
unicast traffic; the ISIS-configured routing tables are.

Joe

--------------enig5391CD271AA6835BB961D13C
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 Thunderbird - http://enigmail.mozdev.org

iD8DBQFDMdWhE5f5cImnZrsRAsEaAJ45Qcam1bMe2TBj0kAeNZz2IPi/YQCeMB4s
O9mJPI+6WCajRzPtEELJNOs=
=R3hR
-----END PGP SIGNATURE-----

--------------enig5391CD271AA6835BB961D13C--


Received: from weathered.linx.net (weathered.linx.net [195.66.232.37]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8LHGIn11221 for <[e-mail]>; Wed, 21 Sep 2005 10:16:18 -0700 (PDT)
Received: from [195.66.233.97] (helo=[192.168.1.65]) by weathered.linx.net with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 1EI3N3-0001PF-00; Wed, 21 Sep 2005 13:06:41 +0100
Date: Wed, 21 Sep 2005 13:06:52 +0100
From: Mike Hughes <[e-mail]>
To: [e-mail]
Message-ID: <77905507F6E3FBE9466ABE6F@Mike_HP.linx.net>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Win32)
X-NCC-RegID: uk.linx
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] STP and ISIS
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, 21 Sep 2005 17:16:44 -0000
Status: RO
Content-Length: 1666

--On 21 September 2005 12:04 +0530 Tom Sanders <[e-mail]>
wrote:

> So, is the proposal to totally do away with STP et. al and run only
> ISIS instead? The spanning tree is then computed with the topology
> information provided by ISIS. Is this correct?

The proposal is to give a more optimal alternative for spanning tree in a
"campus" L2 network.

The problem with spanning tree, as you correctly assert, is that you end up
with blocked links. In more complex L2 topologies, you can end up with
significant numbers of blocked links. Blocked links = wasted bandwidth,
which is especially expensive/wasteful at something like 10Gig/nx10Gig.

Blocked links also mean sub-optimal, rather than shortest path, forwarding
within the network.

The proposal (almost) completely replaces STP within a "campus" L2 network
of switches/bridges. (I say almost, as it looks like a spanning tree will
still need to be used for things like network layer broadcast frames.)

It has the potential to be more efficient, and more elegant, as for known
unicasted frames, delivery will be done via the shortest/most optimal path.
The proposed encapsulation of payload will also add a TTL to manage
temporary forwarding loops during convergence.

While rbridge was originally concieved for managing redundancy and mobility
within a campus, I can think of other applications, such as within L2 metro
networks (like the one I operate) where moving to an L3 routed solution is
not an option.

Regards,
Mike
-- 
Mike Hughes     Chief Technical Officer  London Internet Exchange
[e-mail]   http://www.linx.net/
     "Only one thing in life is certain: init is Process #1"



Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.198]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8L6YkO27022 for <[e-mail]>; Tue, 20 Sep 2005 23:34:46 -0700 (PDT)
Received: by xproxy.gmail.com with SMTP id s15so136812wxc for <[e-mail]>; Tue, 20 Sep 2005 23:34:36 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=iY+bHWHPAlOVrqPdfVR0KR7Fu32yyNcusqXj+kXUM5OsMv6NjAvgWaNIaO9fNdK9d9hYse2995X2YUsTSW8IMbp6yHncyV0GWG+AIV9c4SbtpdZcpXb7YEnd3lI2LHSdqHpo7pSxIt19pbZ2UHf57qj6IoE6BOPn/ZhwWLIkAF0=
Received: by 10.70.111.2 with SMTP id j2mr2329654wxc; Tue, 20 Sep 2005 23:34:36 -0700 (PDT)
Received: by 10.70.76.17 with HTTP; Tue, 20 Sep 2005 23:34:36 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 21 Sep 2005 12:04:36 +0530
From: Tom Sanders <[e-mail]>
To: [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 j8L6YkO27022
Subject: [rbridge] STP and ISIS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 21 Sep 2005 06:35:22 -0000
Status: RO
Content-Length: 1098

Hi,

Going through draft-perlman-rbridge-03.txt raised a doubt in my mind.
Please let me know if my understanding of the matter is indeed
correct:

As per the draft, spanning tree algos concentrate a lot of traffic on
certain links as it marks some ports as blocked and only the ones that
are in the forwarding state can pass traffic. But as per my limited
knowledge, wouldnt STP mark only the redundant links as blocked? If we
dont mark them as blocked, then wouldnt that result in transient
loops, etc.

Then the draft says that there are other issues as well because of
which the group has decided to use a link state routing protocol; more
specifically ISIS because of the advantages it offers against OSPF
(TLV encoded, runs over L2, etc).

So, is the proposal to totally do away with STP et. al and run only
ISIS instead? The spanning tree is then computed with the topology
information provided by ISIS. Is this correct?

If this is so, then we will once again mark some ports as blocked,
etc. How different is this from calculating the spanning tree via the
STP protocol?

Thanks
-- 
Toms.


Received: from smtp.testbed.se ([80.86.78.228]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8K8eUx29967 for <[e-mail]>; Tue, 20 Sep 2005 01:40:30 -0700 (PDT)
Received: from [81.183.251.5] (helo=[172.28.43.120]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1EHdf5-0006Da-TA; Tue, 20 Sep 2005 10:39:40 +0200
Message-ID: <[e-mail]>
Date: Tue, 20 Sep 2005 10:38:19 +0200
From: Loa Andersson <[e-mail]>
Organization: Acreo AB
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], [e-mail], [e-mail], pwe3 <[e-mail]>, [e-mail], L2VPN <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>, [e-mail],  [e-mail]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam detection software, running on the system "fw.testbed.se", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email.  If you have any questions, see the administrator of that system for details. Content preview:  All, following the discussion in the CCAMP working group on the L2SC design team report, the discussion continued off-line and the idea to hold a GMPLS Ethernet BoF in Vancouver was born. We have collected bits and pieces of the discussion so far and tried to come up with a way to proceed. We have put together a more focused proposal for GMPLS controled Ethernet Label Switching and have requested that a BoF will be held in Vancouver. This request has been approved by the Routing Area directors. [...]  Content analysis details:   (0.0 points, 5.0 required) pts rule name              description ---- ---------------------- --------------------------------------------------
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] GMPLS Ethernet in Vancouver
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, 20 Sep 2005 08:41:23 -0000
Status: RO
Content-Length: 1453

All,

following the discussion in the CCAMP working group on the L2SC design
team report, the discussion continued off-line and the idea to hold a
GMPLS Ethernet BoF in Vancouver was born. We have collected bits and
pieces of the discussion so far and tried to come up with a way to
proceed. We have put together a more focused proposal for GMPLS
controled Ethernet Label Switching and have requested that a BoF will
be held in Vancouver. This request has been approved by the Routing
Area directors.

A draft draft-andersson-gels-bof-prep-00.txt has been published to serve
as a starting point for the discussion at the BoF. The intention has
been to reflect the GMPLS Ethernet discussion so far, without any claim
to be complete or "objective", but to specify limited and focused
work that can serve starting as a point for GMPLS controlled Ethernet
Label Switching.

A mailing list has been set up to host the discussion before the BoF to
subscribe to the mailing list send mail to

[e-mail] (subsribe) in body or subject

or visit

https://rtg.ietf.org/mailman/listinfo/gels

Looking forward to comments and discussion.



/Loa and Dimitri



-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]


Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8K4kbx20991 for <[e-mail]>; Mon, 19 Sep 2005 21:46:38 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 19 Sep 2005 21:48:18 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] ????:  ????:  rbridge for ipv6 ?
Thread-Index: AcW9mwTKhhwAiX35RniJfXGJHw1M4AAAtf6w
From: "Vishwas Manral" <[e-mail]>
To: "Developing a hybrid router/bridge." <[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 base64 to 8bit by boreas.isi.edu id j8K4kbx20991
Subject: Re: [rbridge] ????:  ????:  rbridge for ipv6 ?
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, 20 Sep 2005 04:47:32 -0000
Status: RO
Content-Length: 7179

Hi Yiou,

> I think running a routing protocol like IS-IS is a big burden for
> lan switches.
Are you talking about CPU/ Memory or both?

Routing protocols (IS-IS/ OSPF) have an inbuilt hierarchy, that way we can run the networks as different areas, thus not overburdening certain Rbridges. Besides STP/ RSTP/ MSTP already run in the switching domain, which would probably be replaced by the RP.

Thanks,
Vishwas
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Joe Touch
Sent: Tuesday, September 20, 2005 9:38 AM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] ????: ????: rbridge for ipv6 ?



Yiou Deng wrote:
> ??Hi Vishwas,
> ??Thanks a lot for your information. It's helpful for me to understand
> more about rbridge. 
> ??Another doubt for me is that, will protocols other than ROUTING
> PROTOCOLS be considered to use in rbridge? I think running a routing
> protocol like IS-IS is a big burden for lan switches. Yes, we can say
> that rbridge campus is a layer-2 CORE network and switches in it are all
> middle-end or high-end switches which can afford to run IS-IS. But as
> the network expands, or the application requirement changes, more
> switches may be added into rbridge campus. For example, if end to end TE
> tunnels are to be established over L2 network, not only switches in the
> core network, but also the ones in the access layer, will be required to
> run routing protocol like IS-IS.
> ??Is there any consideration for this issue in rbridge?

Tunnels over L2 through an rbridge campus see the campus as a single L2
device (a single bridge), and thus would not need to participate in
IS-IS since they are outside the campus.

Additional devices can be added to an rbridge'd network either by adding
bridges outside the rbridge, by expanding the rbridge campus, or by
adding a separate rbridge campus. The first option does not require
IS-IS devices.

Joe

> ??Thanks & Regards,
> ??Yiou
> ??-----????-----
> ???: [e-mail] [mailto:[e-mail]]
> ?? Vishwas Manral
> ????: 2005?9?19? 12:27
> ???: Developing a hybrid router/bridge.
> ??: Re: [rbridge] ????: ????: rbridge for ipv6 ?
> ??
> ??Hi Yiou,
> ??
> ??I am not sure if IS-IS is the preferred protocol (I guess we are
> some distance from finalizing a protocol), however one advantage of
> IS-IS is that it uses TLV based reachability information and hence is
> independent of the protocol for which it carries information (It was
> initially used for the OSI stack and later extended to work for TCP/IP).
> ??
> ??Besides IS-IS already works over Layer-2.
> ??
> ??Thanks,
> ??Vishwas
> ??-----Original Message-----
> ??From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Yiou Deng
> ??Sent: Monday, September 19, 2005 9:33 AM
> ??To: 'Developing a hybrid router/bridge.'
> ??Subject: [rbridge] ????: ????: rbridge for ipv6 ?
> ??
> ????Hi Ganesh,
> ????I mean that ANY of the routing protocols can be used for rbridge
> ??reachability. I'm new for this mailing list and know little about
> why
> ??ISIS is preferred for rbridge. Will anyone be kind enough to explain
> ??this for me? Thanks in advance.
> ????
> ????Regards,
> ????Yiou
> ????-----????-----
> ?????: [e-mail]
> [mailto:[e-mail]]
> ???? Ganesh CS
> ??????: 2005?9?14? 22:45
> ?????: Developing a hybrid router/bridge.
> ????: Re: [rbridge] ????: rbridge for ipv6 ?
> ????
> ????Hi Yiou,
> ????Do you mean that still routing protocols other than IS-IS
> routing
> ??are
> ????required just for rbrige reachability ?
> ????
> ????regs
> ????Ganesh
> ????
> ????Yiou Deng wrote:
> ????
> ????>??Hello!!
> ????>??Rbridge network is just like a L2VPN network formed by IP
> or
> ??MPLS,
> ????>the only use of routing protocols in Rbridge is to ensure the
> ????>connectivity of Rbridge network internally. 
> ????>??
> ????>??Maybe we can talk face to face at Kuike building if any
> doubts
> ??still
> ????>there :-)
> ????>??
> ????>??Yiou
> ????>??-----????-----
> ????>???: [e-mail]
> ??[mailto:[e-mail]]
> ????>?? Yang Yang
> ????>????: 2005?9?14? 0:36
> ????>???: 'Developing a hybrid router/bridge.'
> ????>??: Re: [rbridge] rbridge for ipv6 ?
> ????>??
> ????>??Hi,
> ????>??   Rbridge forwards frames based on L2 address in data
> plane.
> ??But it
> ????>uses
> ????>??routing protocols which may operate at L3 in control plane.
> If
> ??L3
> ????>address is
> ????>??used, is Rbridge a L2 device? And I think IPv4 and IPv6
> should
> ??both
> ????>be
> ????>??supported.
> ????>??   Still now, I am not sure whether the routing protocol
> can
> ??use MAC
> ????>address
> ????>??via adding a new TLV in IS-IS.
> ????>??
> ????>??   Best Regards!
> ????>??    Yang Yang
> ????>??
> ????>??-----Original Message-----
> ????>??From: [e-mail]
> ??[mailto:[e-mail]]
> ????>On
> ????>??Behalf Of Joe Touch
> ????>??Sent: Wednesday, September 14, 2005 12:01 AM
> ????>??To: Developing a hybrid router/bridge.
> ????>??Subject: Re: [rbridge] rbridge for ipv6 ?
> ????>??
> ????>??Rbridge is an L2 device; at the ingress, it should be
> capable
> ??of
> ????>peeking
> ????>??into various packets for optimization like other L2
> systems, e.
> ??g.,
> ????>for
> ????>??multicast. This includes IPv4 and IPv6, but these are just
> ????>optimizations
> ????>??- if not implemented, it should not affect correct
> operation.
> ????>??
> ????>??Joe
> ????>??
> ????>??Ganesh CS wrote:
> ????>??> Hi all,
> ????>??> Is rbridge for ipv6 under consideration ?
> ????>??> 
> ????>??> Ganesh
> ????>??> _______________________________________________
> ????>??> 
> ??
> ??_______________________________________________
> ??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 [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8K488x09024; Mon, 19 Sep 2005 21:08:09 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 19 Sep 2005 21:08:03 -0700
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: <000a01c5bd8b$4dd844d0$[e-mail]>
In-Reply-To: <000a01c5bd8b$4dd844d0$[e-mail]>
X-Enigmail-Version: 0.92.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig397227DA7AE4734D5BCE4E36"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ????:  ????:  rbridge for ipv6 ?
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, 20 Sep 2005 04:08:33 -0000
Status: RO
Content-Length: 8866

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



Yiou Deng wrote:
> =A1=A1=A1=A1Hi Vishwas,
> =A1=A1=A1=A1Thanks a lot for your information. It's helpful for me to u=
nderstand
> more about rbridge.=20
> =A1=A1=A1=A1Another doubt for me is that, will protocols other than ROU=
TING
> PROTOCOLS be considered to use in rbridge? I think running a routing
> protocol like IS-IS is a big burden for lan switches. Yes, we can say
> that rbridge campus is a layer-2 CORE network and switches in it are al=
l
> middle-end or high-end switches which can afford to run IS-IS. But as
> the network expands, or the application requirement changes, more
> switches may be added into rbridge campus. For example, if end to end T=
E
> tunnels are to be established over L2 network, not only switches in the=

> core network, but also the ones in the access layer, will be required t=
o
> run routing protocol like IS-IS.
> =A1=A1=A1=A1Is there any consideration for this issue in rbridge?

Tunnels over L2 through an rbridge campus see the campus as a single L2
device (a single bridge), and thus would not need to participate in
IS-IS since they are outside the campus.

Additional devices can be added to an rbridge'd network either by adding
bridges outside the rbridge, by expanding the rbridge campus, or by
adding a separate rbridge campus. The first option does not require
IS-IS devices.

Joe

> =A1=A1=A1=A1Thanks & Regards,
> =A1=A1=A1=A1Yiou
> =A1=A1=A1=A1-----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: [e-mail] [mailto:rbridge-bounces@=
postel.org]
> =B4=FA=B1=ED Vishwas Manral
> =B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA9=D4=C219=C8=D5 12:27
> =CA=D5=BC=FE=C8=CB: Developing a hybrid router/bridge.
> =D6=F7=CC=E2: Re: [rbridge] ????: ????: rbridge for ipv6 ?
> =A1=A1=A1=A1
> =A1=A1=A1=A1Hi Yiou,
> =A1=A1=A1=A1
> =A1=A1=A1=A1I am not sure if IS-IS is the preferred protocol (I guess w=
e are
> some distance from finalizing a protocol), however one advantage of
> IS-IS is that it uses TLV based reachability information and hence is
> independent of the protocol for which it carries information (It was
> initially used for the OSI stack and later extended to work for TCP/IP)=
=2E
> =A1=A1=A1=A1
> =A1=A1=A1=A1Besides IS-IS already works over Layer-2.
> =A1=A1=A1=A1
> =A1=A1=A1=A1Thanks,
> =A1=A1=A1=A1Vishwas
> =A1=A1=A1=A1-----Original Message-----
> =A1=A1=A1=A1From: [e-mail] [mailto:rbridge-bounces@po=
stel.org]
> On Behalf Of Yiou Deng
> =A1=A1=A1=A1Sent: Monday, September 19, 2005 9:33 AM
> =A1=A1=A1=A1To: 'Developing a hybrid router/bridge.'
> =A1=A1=A1=A1Subject: [rbridge] ????: ????: rbridge for ipv6 ?
> =A1=A1=A1=A1
> =A1=A1=A1=A1=A1=A1=A1=A1Hi Ganesh,
> =A1=A1=A1=A1=A1=A1=A1=A1I mean that ANY of the routing protocols can be=
 used for rbridge
> =A1=A1=A1=A1reachability. I'm new for this mailing list and know little=
 about
> why
> =A1=A1=A1=A1ISIS is preferred for rbridge. Will anyone be kind enough t=
o explain
> =A1=A1=A1=A1this for me? Thanks in advance.
> =A1=A1=A1=A1=A1=A1=A1=A1
> =A1=A1=A1=A1=A1=A1=A1=A1Regards,
> =A1=A1=A1=A1=A1=A1=A1=A1Yiou
> =A1=A1=A1=A1=A1=A1=A1=A1-----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =A1=A1=A1=A1=B7=A2=BC=FE=C8=CB: [e-mail]
> [mailto:[e-mail]]
> =A1=A1=A1=A1=B4=FA=B1=ED Ganesh CS
> =A1=A1=A1=A1=B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA9=D4=C214=C8=D5 22:45
> =A1=A1=A1=A1=CA=D5=BC=FE=C8=CB: Developing a hybrid router/bridge.
> =A1=A1=A1=A1=D6=F7=CC=E2: Re: [rbridge] ????: rbridge for ipv6 ?
> =A1=A1=A1=A1=A1=A1=A1=A1
> =A1=A1=A1=A1=A1=A1=A1=A1Hi Yiou,
> =A1=A1=A1=A1=A1=A1=A1=A1Do you mean that still routing protocols other =
than IS-IS
> routing
> =A1=A1=A1=A1are
> =A1=A1=A1=A1=A1=A1=A1=A1required just for rbrige reachability ?
> =A1=A1=A1=A1=A1=A1=A1=A1
> =A1=A1=A1=A1=A1=A1=A1=A1regs
> =A1=A1=A1=A1=A1=A1=A1=A1Ganesh
> =A1=A1=A1=A1=A1=A1=A1=A1
> =A1=A1=A1=A1=A1=A1=A1=A1Yiou Deng wrote:
> =A1=A1=A1=A1=A1=A1=A1=A1
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1Hello!!
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1Rbridge network is just like a L2V=
PN network formed by IP
> or
> =A1=A1=A1=A1MPLS,
> =A1=A1=A1=A1=A1=A1=A1=A1>the only use of routing protocols in Rbridge i=
s to ensure the
> =A1=A1=A1=A1=A1=A1=A1=A1>connectivity of Rbridge network internally.=20
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1Maybe we can talk face to face at =
Kuike building if any
> doubts
> =A1=A1=A1=A1still
> =A1=A1=A1=A1=A1=A1=A1=A1>there :-)
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1Yiou
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1-----=D3=CA=BC=FE=D4=AD=BC=FE-----=

> =A1=A1=A1=A1=A1=A1=A1=A1>=B7=A2=BC=FE=C8=CB: [e-mail]=

> =A1=A1=A1=A1[mailto:[e-mail]]
> =A1=A1=A1=A1=A1=A1=A1=A1>=B4=FA=B1=ED Yang Yang
> =A1=A1=A1=A1=A1=A1=A1=A1>=B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA9=D4=C214=C8=
=D5 0:36
> =A1=A1=A1=A1=A1=A1=A1=A1>=CA=D5=BC=FE=C8=CB: 'Developing a hybrid route=
r/bridge.'
> =A1=A1=A1=A1=A1=A1=A1=A1>=D6=F7=CC=E2: Re: [rbridge] rbridge for ipv6 ?=

> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1Hi,
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1   Rbridge forwards frames based o=
n L2 address in data
> plane.
> =A1=A1=A1=A1But it
> =A1=A1=A1=A1=A1=A1=A1=A1>uses
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1routing protocols which may operat=
e at L3 in control plane.
> If
> =A1=A1=A1=A1L3
> =A1=A1=A1=A1=A1=A1=A1=A1>address is
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1used, is Rbridge a L2 device? And =
I think IPv4 and IPv6
> should
> =A1=A1=A1=A1both
> =A1=A1=A1=A1=A1=A1=A1=A1>be
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1supported.
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1   Still now, I am not sure whethe=
r the routing protocol
> can
> =A1=A1=A1=A1use MAC
> =A1=A1=A1=A1=A1=A1=A1=A1>address
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1via adding a new TLV in IS-IS.
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1   Best Regards!
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1    Yang Yang
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1-----Original Message-----
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1From: [e-mail]
> =A1=A1=A1=A1[mailto:[e-mail]]
> =A1=A1=A1=A1=A1=A1=A1=A1>On
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1Behalf Of Joe Touch
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1Sent: Wednesday, September 14, 200=
5 12:01 AM
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1To: Developing a hybrid router/bri=
dge.
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1Subject: Re: [rbridge] rbridge for=
 ipv6 ?
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1Rbridge is an L2 device; at the in=
gress, it should be
> capable
> =A1=A1=A1=A1of
> =A1=A1=A1=A1=A1=A1=A1=A1>peeking
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1into various packets for optimizat=
ion like other L2
> systems, e.
> =A1=A1=A1=A1g.,
> =A1=A1=A1=A1=A1=A1=A1=A1>for
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1multicast. This includes IPv4 and =
IPv6, but these are just
> =A1=A1=A1=A1=A1=A1=A1=A1>optimizations
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1- if not implemented, it should no=
t affect correct
> operation.
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1Joe
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1Ganesh CS wrote:
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1> Hi all,
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1> Is rbridge for ipv6 under consid=
eration ?
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1>=20
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1> Ganesh
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1> ________________________________=
_______________
> =A1=A1=A1=A1=A1=A1=A1=A1>=A1=A1=A1=A1>=20
> =A1=A1=A1=A1
> =A1=A1=A1=A1_______________________________________________
> =A1=A1=A1=A1rbridge mailing list
> =A1=A1=A1=[e-mail]
> =A1=A1=A1=A1http://www.postel.org/mailman/listinfo/rbridge
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


--------------enig397227DA7AE4734D5BCE4E36
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 Thunderbird - http://enigmail.mozdev.org

iD8DBQFDL4sjE5f5cImnZrsRAvGuAKDJNUT/m/iXAjfK++5vK51iUaEPFgCgnj4x
auq+e9LfDGjXlm6hh5weTXk=
=pZYP
-----END PGP SIGNATURE-----

--------------enig397227DA7AE4734D5BCE4E36--


Received: from huawei.com (szxga03-in.huawei.com [61.144.161.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8K2UPx14903 for <[e-mail]>; Mon, 19 Sep 2005 19:30:26 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 20 Sep 2005 10:33:59 +0800 (CST)
Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 20 Sep 2005 10:33:58 +0800 (CST)
Received: from d16300a ([10.111.12.196]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <[e-mail]> for [e-mail]; Tue, 20 Sep 2005 10:37:46 +0800 (CST)
Date: Tue, 20 Sep 2005 10:30:44 +0800
From: Yiou Deng <[e-mail]>
In-reply-to: <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Message-id: <000a01c5bd8b$4dd844d0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=gb2312
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by boreas.isi.edu id j8K2UPx14903
Subject: Re: [rbridge] ????:  ????:  rbridge for ipv6 ?
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, 20 Sep 2005 02:31:22 -0000
Status: RO
Content-Length: 5031

????Hi Vishwas,
????Thanks a lot for your information. It's helpful for me to understand
more about rbridge. 
????Another doubt for me is that, will protocols other than ROUTING
PROTOCOLS be considered to use in rbridge? I think running a routing
protocol like IS-IS is a big burden for lan switches. Yes, we can say
that rbridge campus is a layer-2 CORE network and switches in it are all
middle-end or high-end switches which can afford to run IS-IS. But as
the network expands, or the application requirement changes, more
switches may be added into rbridge campus. For example, if end to end TE
tunnels are to be established over L2 network, not only switches in the
core network, but also the ones in the access layer, will be required to
run routing protocol like IS-IS.
????Is there any consideration for this issue in rbridge?
????
????Thanks & Regards,
????Yiou
????-----??????-----
??????: [e-mail] [mailto:[e-mail]]
???? Vishwas Manral
???????: 2005??9??19?? 12:27
?????: Developing a hybrid router/bridge.
????: Re: [rbridge] ????: ????: rbridge for ipv6 ?
????
????Hi Yiou,
????
????I am not sure if IS-IS is the preferred protocol (I guess we are
some distance from finalizing a protocol), however one advantage of
IS-IS is that it uses TLV based reachability information and hence is
independent of the protocol for which it carries information (It was
initially used for the OSI stack and later extended to work for TCP/IP).
????
????Besides IS-IS already works over Layer-2.
????
????Thanks,
????Vishwas
????-----Original Message-----
????From: [e-mail] [mailto:[e-mail]]
On Behalf Of Yiou Deng
????Sent: Monday, September 19, 2005 9:33 AM
????To: 'Developing a hybrid router/bridge.'
????Subject: [rbridge] ????: ????: rbridge for ipv6 ?
????
????????Hi Ganesh,
????????I mean that ANY of the routing protocols can be used for rbridge
????reachability. I'm new for this mailing list and know little about
why
????ISIS is preferred for rbridge. Will anyone be kind enough to explain
????this for me? Thanks in advance.
????????
????????Regards,
????????Yiou
????????-----??????-----
??????????: [e-mail]
[mailto:[e-mail]]
???????? Ganesh CS
???????????: 2005??9??14?? 22:45
?????????: Developing a hybrid router/bridge.
????????: Re: [rbridge] ????: rbridge for ipv6 ?
????????
????????Hi Yiou,
????????Do you mean that still routing protocols other than IS-IS
routing
????are
????????required just for rbrige reachability ?
????????
????????regs
????????Ganesh
????????
????????Yiou Deng wrote:
????????
????????>????Hello!!
????????>????Rbridge network is just like a L2VPN network formed by IP
or
????MPLS,
????????>the only use of routing protocols in Rbridge is to ensure the
????????>connectivity of Rbridge network internally. 
????????>????
????????>????Maybe we can talk face to face at Kuike building if any
doubts
????still
????????>there :-)
????????>????
????????>????Yiou
????????>????-----??????-----
????????>??????: [e-mail]
????[mailto:[e-mail]]
????????>???? Yang Yang
????????>???????: 2005??9??14?? 0:36
????????>?????: 'Developing a hybrid router/bridge.'
????????>????: Re: [rbridge] rbridge for ipv6 ?
????????>????
????????>????Hi,
????????>????   Rbridge forwards frames based on L2 address in data
plane.
????But it
????????>uses
????????>????routing protocols which may operate at L3 in control plane.
If
????L3
????????>address is
????????>????used, is Rbridge a L2 device? And I think IPv4 and IPv6
should
????both
????????>be
????????>????supported.
????????>????   Still now, I am not sure whether the routing protocol
can
????use MAC
????????>address
????????>????via adding a new TLV in IS-IS.
????????>????
????????>????   Best Regards!
????????>????    Yang Yang
????????>????
????????>????-----Original Message-----
????????>????From: [e-mail]
????[mailto:[e-mail]]
????????>On
????????>????Behalf Of Joe Touch
????????>????Sent: Wednesday, September 14, 2005 12:01 AM
????????>????To: Developing a hybrid router/bridge.
????????>????Subject: Re: [rbridge] rbridge for ipv6 ?
????????>????
????????>????Rbridge is an L2 device; at the ingress, it should be
capable
????of
????????>peeking
????????>????into various packets for optimization like other L2
systems, e.
????g.,
????????>for
????????>????multicast. This includes IPv4 and IPv6, but these are just
????????>optimizations
????????>????- if not implemented, it should not affect correct
operation.
????????>????
????????>????Joe
????????>????
????????>????Ganesh CS wrote:
????????>????> Hi all,
????????>????> Is rbridge for ipv6 under consideration ?
????????>????> 
????????>????> Ganesh
????????>????> _______________________________________________
????????>????> 
????
????_______________________________________________
????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 j8JHaqx17744; Mon, 19 Sep 2005 10:36:52 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 19 Sep 2005 10:36:56 -0700
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: <000801c5bccf$16597220$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ????:  ????:  rbridge for ipv6 ?
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, 19 Sep 2005 17:37:21 -0000
Status: RO
Content-Length: 5262

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



Ganesh CS wrote:
> Hi Yiou,
> Per my understanding, within rbridge domain we should not be requiring a
> separate routing protocol other than rbridge's own routing protocol for
> rbridge reachability. However to advertise internal routes to outside of
> the rbridge domain we may require a routing protocol.

We would, if we ever intended to advertise internal routes outside. This
is the opposite of the goal of an rbridge, which is to completely
encapsulate this state internally.

When considering what an rbridge campus (which is what we call it) does,
consider the acid test: what would a single bridge do?

Bridges might export, e.g., some info about which interfaces reach
others in the way it participates in a spanning tree (directly or
indirectly; I'm not a spanning tree protocol guru). But which path is
taken internally is not exported there, nor would it be for an rbridge
campus.

Joe



> Anyone on the list can correct me if I am wrong.
> 
> regs
> Ganesh
> 
> Yiou Deng wrote:
> 
> 
>>????Hi Ganesh,
>>????I mean that ANY of the routing protocols can be used for rbridge
>>reachability. I'm new for this mailing list and know little about why
>>ISIS is preferred for rbridge. Will anyone be kind enough to explain
>>this for me? Thanks in advance.
>>????
>>????Regards,
>>????Yiou
>>????-----??????-----
>>??????: [e-mail] [mailto:[e-mail]]
>>???? Ganesh CS
>>???????: 2005??9??14?? 22:45
>>?????: Developing a hybrid router/bridge.
>>????: Re: [rbridge] ????: rbridge for ipv6 ?
>>????
>>????Hi Yiou,
>>????Do you mean that still routing protocols other than IS-IS routing
>>are
>>????required just for rbrige reachability ?
>>????
>>????regs
>>????Ganesh
>>????
>>????Yiou Deng wrote:
>>????
>>????>????Hello!!
>>????>????Rbridge network is just like a L2VPN network formed by IP or
>>MPLS,
>>????>the only use of routing protocols in Rbridge is to ensure the
>>????>connectivity of Rbridge network internally. 
>>????>????
>>????>????Maybe we can talk face to face at Kuike building if any doubts
>>still
>>????>there :-)
>>????>????
>>????>????Yiou
>>????>????-----??????-----
>>????>??????: [e-mail]
>>[mailto:[e-mail]]
>>????>???? Yang Yang
>>????>???????: 2005??9??14?? 0:36
>>????>?????: 'Developing a hybrid router/bridge.'
>>????>????: Re: [rbridge] rbridge for ipv6 ?
>>????>????
>>????>????Hi,
>>????>????   Rbridge forwards frames based on L2 address in data plane.
>>But it
>>????>uses
>>????>????routing protocols which may operate at L3 in control plane. If
>>L3
>>????>address is
>>????>????used, is Rbridge a L2 device? And I think IPv4 and IPv6 should
>>both
>>????>be
>>????>????supported.
>>????>????   Still now, I am not sure whether the routing protocol can
>>use MAC
>>????>address
>>????>????via adding a new TLV in IS-IS.
>>????>????
>>????>????   Best Regards!
>>????>????    Yang Yang
>>????>????
>>????>????-----Original Message-----
>>????>????From: [e-mail]
>>[mailto:[e-mail]]
>>????>On
>>????>????Behalf Of Joe Touch
>>????>????Sent: Wednesday, September 14, 2005 12:01 AM
>>????>????To: Developing a hybrid router/bridge.
>>????>????Subject: Re: [rbridge] rbridge for ipv6 ?
>>????>????
>>????>????Rbridge is an L2 device; at the ingress, it should be capable
>>of
>>????>peeking
>>????>????into various packets for optimization like other L2 systems, e.
>>g.,
>>????>for
>>????>????multicast. This includes IPv4 and IPv6, but these are just
>>????>optimizations
>>????>????- if not implemented, it should not affect correct operation.
>>????>????
>>????>????Joe
>>????>????
>>????>????Ganesh CS wrote:
>>????>????> Hi all,
>>????>????> Is rbridge for ipv6 under consideration ?
>>????>????> 
>>????>????> Ganesh
>>????>????> _______________________________________________
>>????>????> 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
>> 
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>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

iD8DBQFDLvc4E5f5cImnZrsRAmYVAKC6zZVL01fuPIZDIek9Nm4BXo4L5ACfTscA
F+sbCcHXyWvP606O4nPhMKU=
=osNE
-----END PGP SIGNATURE-----


Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8JEvox15560 for <[e-mail]>; Mon, 19 Sep 2005 07:57:51 -0700 (PDT)
Received: from india-core-1.cisco.com ([64.104.129.221]) by ind-iport-1.cisco.com with ESMTP; 19 Sep 2005 20:34:22 -0700
Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8JEvPbI013284 for <[e-mail]>; Mon, 19 Sep 2005 14:57:29 GMT
Received: from xfe-blr-412.apac.cisco.com ([64.104.140.152]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0);  Mon, 19 Sep 2005 20:27:36 +0530
Received: from [10.77.203.69] ([10.77.203.69]) by xfe-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 19 Sep 2005 20:27:36 +0530
Message-ID: <[e-mail]>
Date: Mon, 19 Sep 2005 20:27:35 +0530
From: Ganesh CS <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <000801c5bccf$16597220$[e-mail]>
In-Reply-To: <000801c5bccf$16597220$[e-mail]>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 19 Sep 2005 14:57:36.0667 (UTC) FILETIME=[790676B0:01C5BD2A]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ????:  ????:  rbridge for ipv6 ?
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, 19 Sep 2005 14:58:23 -0000
Status: RO
Content-Length: 3966

Hi Yiou,
Per my understanding, within rbridge domain we should not be requiring a
separate routing protocol other than rbridge's own routing protocol for
rbridge reachability. However to advertise internal routes to outside of
the rbridge domain we may require a routing protocol.

Anyone on the list can correct me if I am wrong.

regs
Ganesh

Yiou Deng wrote:

>????Hi Ganesh,
>????I mean that ANY of the routing protocols can be used for rbridge
>reachability. I'm new for this mailing list and know little about why
>ISIS is preferred for rbridge. Will anyone be kind enough to explain
>this for me? Thanks in advance.
>????
>????Regards,
>????Yiou
>????-----??????-----
>??????: [e-mail] [mailto:[e-mail]]
>???? Ganesh CS
>???????: 2005??9??14?? 22:45
>?????: Developing a hybrid router/bridge.
>????: Re: [rbridge] ????: rbridge for ipv6 ?
>????
>????Hi Yiou,
>????Do you mean that still routing protocols other than IS-IS routing
>are
>????required just for rbrige reachability ?
>????
>????regs
>????Ganesh
>????
>????Yiou Deng wrote:
>????
>????>????Hello!!
>????>????Rbridge network is just like a L2VPN network formed by IP or
>MPLS,
>????>the only use of routing protocols in Rbridge is to ensure the
>????>connectivity of Rbridge network internally. 
>????>????
>????>????Maybe we can talk face to face at Kuike building if any doubts
>still
>????>there :-)
>????>????
>????>????Yiou
>????>????-----??????-----
>????>??????: [e-mail]
>[mailto:[e-mail]]
>????>???? Yang Yang
>????>???????: 2005??9??14?? 0:36
>????>?????: 'Developing a hybrid router/bridge.'
>????>????: Re: [rbridge] rbridge for ipv6 ?
>????>????
>????>????Hi,
>????>????   Rbridge forwards frames based on L2 address in data plane.
>But it
>????>uses
>????>????routing protocols which may operate at L3 in control plane. If
>L3
>????>address is
>????>????used, is Rbridge a L2 device? And I think IPv4 and IPv6 should
>both
>????>be
>????>????supported.
>????>????   Still now, I am not sure whether the routing protocol can
>use MAC
>????>address
>????>????via adding a new TLV in IS-IS.
>????>????
>????>????   Best Regards!
>????>????    Yang Yang
>????>????
>????>????-----Original Message-----
>????>????From: [e-mail]
>[mailto:[e-mail]]
>????>On
>????>????Behalf Of Joe Touch
>????>????Sent: Wednesday, September 14, 2005 12:01 AM
>????>????To: Developing a hybrid router/bridge.
>????>????Subject: Re: [rbridge] rbridge for ipv6 ?
>????>????
>????>????Rbridge is an L2 device; at the ingress, it should be capable
>of
>????>peeking
>????>????into various packets for optimization like other L2 systems, e.
>g.,
>????>for
>????>????multicast. This includes IPv4 and IPv6, but these are just
>????>optimizations
>????>????- if not implemented, it should not affect correct operation.
>????>????
>????>????Joe
>????>????
>????>????Ganesh CS wrote:
>????>????> Hi all,
>????>????> Is rbridge for ipv6 under consideration ?
>????>????> 
>????>????> Ganesh
>????>????> _______________________________________________
>????>????> 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 sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8J4Orx20547 for <[e-mail]>; Sun, 18 Sep 2005 21:24:53 -0700 (PDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Date: Sun, 18 Sep 2005 21:27:15 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] ????:  ????:  rbridge for ipv6 ?
Thread-Index: AcW80PaiMRT7S+mqRL+beYlgOrFhfQAAG6Tg
From: "Vishwas Manral" <[e-mail]>
To: "Developing a hybrid router/bridge." <[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 base64 to 8bit by boreas.isi.edu id j8J4Orx20547
Subject: Re: [rbridge] ????:  ????:  rbridge for ipv6 ?
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, 19 Sep 2005 04:25:24 -0000
Status: RO
Content-Length: 3608

Hi Yiou,

I am not sure if IS-IS is the preferred protocol (I guess we are some distance from finalizing a protocol), however one advantage of IS-IS is that it uses TLV based reachability information and hence is independent of the protocol for which it carries information (It was initially used for the OSI stack and later extended to work for TCP/IP).

Besides IS-IS already works over Layer-2.

Thanks,
Vishwas
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Yiou Deng
Sent: Monday, September 19, 2005 9:33 AM
To: 'Developing a hybrid router/bridge.'
Subject: [rbridge] ????: ????: rbridge for ipv6 ?

??Hi Ganesh,
??I mean that ANY of the routing protocols can be used for rbridge
reachability. I'm new for this mailing list and know little about why
ISIS is preferred for rbridge. Will anyone be kind enough to explain
this for me? Thanks in advance.
??
??Regards,
??Yiou
??-----????-----
???: [e-mail] [mailto:[e-mail]]
?? Ganesh CS
????: 2005?9?14? 22:45
???: Developing a hybrid router/bridge.
??: Re: [rbridge] ????: rbridge for ipv6 ?
??
??Hi Yiou,
??Do you mean that still routing protocols other than IS-IS routing
are
??required just for rbrige reachability ?
??
??regs
??Ganesh
??
??Yiou Deng wrote:
??
??>??Hello!!
??>??Rbridge network is just like a L2VPN network formed by IP or
MPLS,
??>the only use of routing protocols in Rbridge is to ensure the
??>connectivity of Rbridge network internally. 
??>??
??>??Maybe we can talk face to face at Kuike building if any doubts
still
??>there :-)
??>??
??>??Yiou
??>??-----????-----
??>???: [e-mail]
[mailto:[e-mail]]
??>?? Yang Yang
??>????: 2005?9?14? 0:36
??>???: 'Developing a hybrid router/bridge.'
??>??: Re: [rbridge] rbridge for ipv6 ?
??>??
??>??Hi,
??>??   Rbridge forwards frames based on L2 address in data plane.
But it
??>uses
??>??routing protocols which may operate at L3 in control plane. If
L3
??>address is
??>??used, is Rbridge a L2 device? And I think IPv4 and IPv6 should
both
??>be
??>??supported.
??>??   Still now, I am not sure whether the routing protocol can
use MAC
??>address
??>??via adding a new TLV in IS-IS.
??>??
??>??   Best Regards!
??>??    Yang Yang
??>??
??>??-----Original Message-----
??>??From: [e-mail]
[mailto:[e-mail]]
??>On
??>??Behalf Of Joe Touch
??>??Sent: Wednesday, September 14, 2005 12:01 AM
??>??To: Developing a hybrid router/bridge.
??>??Subject: Re: [rbridge] rbridge for ipv6 ?
??>??
??>??Rbridge is an L2 device; at the ingress, it should be capable
of
??>peeking
??>??into various packets for optimization like other L2 systems, e.
g.,
??>for
??>??multicast. This includes IPv4 and IPv6, but these are just
??>optimizations
??>??- if not implemented, it should not affect correct operation.
??>??
??>??Joe
??>??
??>??Ganesh CS wrote:
??>??> Hi all,
??>??> Is rbridge for ipv6 under consideration ?
??>??> 
??>??> Ganesh
??>??> _______________________________________________
??>??> 



Received: from huawei.com (szxga03-in.huawei.com [61.144.161.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8J42ax16211 for <[e-mail]>; Sun, 18 Sep 2005 21:02:36 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 19 Sep 2005 12:06:39 +0800 (CST)
Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 19 Sep 2005 12:06:39 +0800 (CST)
Received: from d16300a ([10.111.12.196]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <[e-mail]> for [e-mail]; Mon, 19 Sep 2005 12:10:25 +0800 (CST)
Date: Mon, 19 Sep 2005 12:03:26 +0800
From: Yiou Deng <[e-mail]>
In-reply-to: <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Message-id: <000801c5bccf$16597220$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=gb2312
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by boreas.isi.edu id j8J42ax16211
Subject: [rbridge] ????:  ????:  rbridge for ipv6 ?
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, 19 Sep 2005 04:03:41 -0000
Status: RO
Content-Length: 3248

????Hi Ganesh,
????I mean that ANY of the routing protocols can be used for rbridge
reachability. I'm new for this mailing list and know little about why
ISIS is preferred for rbridge. Will anyone be kind enough to explain
this for me? Thanks in advance.
????
????Regards,
????Yiou
????-----??????-----
??????: [e-mail] [mailto:[e-mail]]
???? Ganesh CS
???????: 2005??9??14?? 22:45
?????: Developing a hybrid router/bridge.
????: Re: [rbridge] ????: rbridge for ipv6 ?
????
????Hi Yiou,
????Do you mean that still routing protocols other than IS-IS routing
are
????required just for rbrige reachability ?
????
????regs
????Ganesh
????
????Yiou Deng wrote:
????
????>????Hello!!
????>????Rbridge network is just like a L2VPN network formed by IP or
MPLS,
????>the only use of routing protocols in Rbridge is to ensure the
????>connectivity of Rbridge network internally. 
????>????
????>????Maybe we can talk face to face at Kuike building if any doubts
still
????>there :-)
????>????
????>????Yiou
????>????-----??????-----
????>??????: [e-mail]
[mailto:[e-mail]]
????>???? Yang Yang
????>???????: 2005??9??14?? 0:36
????>?????: 'Developing a hybrid router/bridge.'
????>????: Re: [rbridge] rbridge for ipv6 ?
????>????
????>????Hi,
????>????   Rbridge forwards frames based on L2 address in data plane.
But it
????>uses
????>????routing protocols which may operate at L3 in control plane. If
L3
????>address is
????>????used, is Rbridge a L2 device? And I think IPv4 and IPv6 should
both
????>be
????>????supported.
????>????   Still now, I am not sure whether the routing protocol can
use MAC
????>address
????>????via adding a new TLV in IS-IS.
????>????
????>????   Best Regards!
????>????    Yang Yang
????>????
????>????-----Original Message-----
????>????From: [e-mail]
[mailto:[e-mail]]
????>On
????>????Behalf Of Joe Touch
????>????Sent: Wednesday, September 14, 2005 12:01 AM
????>????To: Developing a hybrid router/bridge.
????>????Subject: Re: [rbridge] rbridge for ipv6 ?
????>????
????>????Rbridge is an L2 device; at the ingress, it should be capable
of
????>peeking
????>????into various packets for optimization like other L2 systems, e.
g.,
????>for
????>????multicast. This includes IPv4 and IPv6, but these are just
????>optimizations
????>????- if not implemented, it should not affect correct operation.
????>????
????>????Joe
????>????
????>????Ganesh CS wrote:
????>????> Hi all,
????>????> Is rbridge for ipv6 under consideration ?
????>????> 
????>????> Ganesh
????>????> _______________________________________________
????>????> 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 ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8EEirk01043 for <[e-mail]>; Wed, 14 Sep 2005 07:44:54 -0700 (PDT)
Received: from india-core-1.cisco.com ([64.104.129.221]) by ind-iport-1.cisco.com with ESMTP; 14 Sep 2005 20:20:19 -0700
Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8EEiUbG018150 for <[e-mail]>; Wed, 14 Sep 2005 14:44:32 GMT
Received: from xfe-blr-411.apac.cisco.com ([64.104.140.151]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0);  Wed, 14 Sep 2005 20:14:43 +0530
Received: from [10.77.203.69] ([10.77.203.69]) by xfe-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Sep 2005 20:14:42 +0530
Message-ID: <[e-mail]>
Date: Wed, 14 Sep 2005 20:14:42 +0530
From: Ganesh CS <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <000f01c5b8f2$2be3e840$[e-mail]>
In-Reply-To: <000f01c5b8f2$2be3e840$[e-mail]>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 14 Sep 2005 14:44:42.0897 (UTC) FILETIME=[D7C1C810:01C5B93A]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ????:  rbridge for ipv6 ?
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, 14 Sep 2005 14:45:52 -0000
Status: RO
Content-Length: 2395

Hi Yiou,
Do you mean that still routing protocols other than IS-IS routing are
required just for rbrige reachability ?

regs
Ganesh

Yiou Deng wrote:

>????Hello!!
>????Rbridge network is just like a L2VPN network formed by IP or MPLS,
>the only use of routing protocols in Rbridge is to ensure the
>connectivity of Rbridge network internally. 
>????
>????Maybe we can talk face to face at Kuike building if any doubts still
>there :-)
>????
>????Yiou
>????-----??????-----
>??????: [e-mail] [mailto:[e-mail]]
>???? Yang Yang
>???????: 2005??9??14?? 0:36
>?????: 'Developing a hybrid router/bridge.'
>????: Re: [rbridge] rbridge for ipv6 ?
>????
>????Hi,
>????   Rbridge forwards frames based on L2 address in data plane. But it
>uses
>????routing protocols which may operate at L3 in control plane. If L3
>address is
>????used, is Rbridge a L2 device? And I think IPv4 and IPv6 should both
>be
>????supported.
>????   Still now, I am not sure whether the routing protocol can use MAC
>address
>????via adding a new TLV in IS-IS.
>????
>????   Best Regards!
>????    Yang Yang
>????
>????-----Original Message-----
>????From: [e-mail] [mailto:[e-mail]]
>On
>????Behalf Of Joe Touch
>????Sent: Wednesday, September 14, 2005 12:01 AM
>????To: Developing a hybrid router/bridge.
>????Subject: Re: [rbridge] rbridge for ipv6 ?
>????
>????Rbridge is an L2 device; at the ingress, it should be capable of
>peeking
>????into various packets for optimization like other L2 systems, e.g.,
>for
>????multicast. This includes IPv4 and IPv6, but these are just
>optimizations
>????- if not implemented, it should not affect correct operation.
>????
>????Joe
>????
>????Ganesh CS wrote:
>????> Hi all,
>????> Is rbridge for ipv6 under consideration ?
>????> 
>????> Ganesh
>????> _______________________________________________
>????> 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 huawei.com (szxga01-in.huawei.com [61.144.161.53]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8E63ik22940 for <[e-mail]>; Tue, 13 Sep 2005 23:03:44 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 14 Sep 2005 14:09:55 +0800 (CST)
Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 14 Sep 2005 14:09:54 +0800 (CST)
Received: from d16300a ([10.111.12.196]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 14 Sep 2005 14:11:24 +0800 (CST)
Date: Wed, 14 Sep 2005 13:22:57 +0800
From: Yiou Deng <[e-mail]>
In-reply-to: <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Message-id: <000f01c5b8f2$2be3e840$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=gb2312
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
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 j8E63ik22940
Subject: [rbridge] ????:  rbridge for ipv6 ?
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, 14 Sep 2005 06:03:59 -0000
Status: RO
Content-Length: 1952

????Hello!!
????Rbridge network is just like a L2VPN network formed by IP or MPLS,
the only use of routing protocols in Rbridge is to ensure the
connectivity of Rbridge network internally. 
????
????Maybe we can talk face to face at Kuike building if any doubts still
there :-)
????
????Yiou
????-----??????-----
??????: [e-mail] [mailto:[e-mail]]
???? Yang Yang
???????: 2005??9??14?? 0:36
?????: 'Developing a hybrid router/bridge.'
????: Re: [rbridge] rbridge for ipv6 ?
????
????Hi,
????   Rbridge forwards frames based on L2 address in data plane. But it
uses
????routing protocols which may operate at L3 in control plane. If L3
address is
????used, is Rbridge a L2 device? And I think IPv4 and IPv6 should both
be
????supported.
????   Still now, I am not sure whether the routing protocol can use MAC
address
????via adding a new TLV in IS-IS.
????
????   Best Regards!
????    Yang Yang
????
????-----Original Message-----
????From: [e-mail] [mailto:[e-mail]]
On
????Behalf Of Joe Touch
????Sent: Wednesday, September 14, 2005 12:01 AM
????To: Developing a hybrid router/bridge.
????Subject: Re: [rbridge] rbridge for ipv6 ?
????
????Rbridge is an L2 device; at the ingress, it should be capable of
peeking
????into various packets for optimization like other L2 systems, e.g.,
for
????multicast. This includes IPv4 and IPv6, but these are just
optimizations
????- if not implemented, it should not affect correct operation.
????
????Joe
????
????Ganesh CS wrote:
????> Hi all,
????> Is rbridge for ipv6 under consideration ?
????> 
????> Ganesh
????> _______________________________________________
????> rbridge mailing list
????> [e-mail]
????> http://www.postel.org/mailman/listinfo/rbridge
????
????
????_______________________________________________
????rbridge mailing list
????[e-mail]
????http://www.postel.org/mailman/listinfo/rbridge



Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8DLI7k24251; Tue, 13 Sep 2005 14:18:07 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 13 Sep 2005 14:18:33 -0700
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] rbridge for ipv6 ?
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, 13 Sep 2005 21:19:19 -0000
Status: RO
Content-Length: 3218

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



[e-mail] wrote:
> I agree with Joe. I don't see any problem with supporting IPv6. The IS-IS routing that we'll use
> will be layer 3 agnostic. The first step is having all the RBridges exchanging their system IDs (MAC addresses)
> and connectivity to other RBridges' system IDs. IS-IS does not send over IP. It has its own Ethertype. So
> I don't see any problem with IPv6 for the basic RBridge-RBridge topology building piece.
> 
> Then there would be TLVs for announcing
> .  VLAN membership
> . MAC addresses of attached nodes
> . (L3,L2) information for supporting proxy ARP/proxy ND
> 
> I'd think only the last would be layer 3 aware. And yes, I agree we should support IPv6 as well as
> IPv4. I think it's just a matter of having two different TLVs, one for announcing (IPv4, MAC) and
> one for announcing (IPv6, MAC). 
> 
> Are there other issues?

Multicast, as another example of the third case where peeking is used.
Note that the 3rd case is just an optimization anyway, though - it's not
clear we can get around the need, e.g., for broadcast for IPv4 ARP.

Joe

> 
> Radia
> 
> 
> ----- Original Message -----
> From: Joe Touch <[e-mail]>
> Date: Tuesday, September 13, 2005 10:18 am
> Subject: Re: [rbridge] rbridge for ipv6 ?
> 
> 
> 
> 
> Pekka Savola wrote:
> 
>>On Tue, 13 Sep 2005, Joe Touch wrote:
> 
> 
>>>Rbridge is an L2 device; at the ingress, it should be capable of 
> 
> peeking>>into various packets for optimization like other L2 
> systems, e.g., for
> 
>>>multicast. This includes IPv4 and IPv6, but these are just 
> 
> optimizations>>- if not implemented, it should not affect correct 
> operation.> 
> 
>>(This should be obvious, but I'll state it explicitly in any 
> 
> case), it 
> 
>>should still work if some parts of the site implement v4/v6 
> 
> optimizing 
> 
>>rbridges, some can only optimize for v4, others only for v6, and 
> 
> yet 
> 
>>another set not at all.
> 
> Agreed. Also, how much the optimization helps may depend on how
> widespread support for the optimization is.
> 
> 
>>Maybe that requires each rbridge adversiting its optimizing 
>>capabilities in IS-IS or something, which may or may not be trivial.
> 
> We can have everyone participate in supporting multiple routing 
> 'trees'(they're not trees anymore, but you get the idea), where 
> only egresses
> that support v4 or v4 peek will be able to utilize. I don't think this
> requires advertizing the capabilities per se, but it will probably
> require the use of separate forwarding tables. those that support such
> will use them; others will support only a single merged table as well.
> 
> 
> Joe
_______________________________________________
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

iD8DBQFDJ0IpE5f5cImnZrsRAghIAKCeNhLA01YhOsPQn/wq1GqchoTetACeLG6N
gsS3ccM2wMKDIq9VP3yEmzY=
=Ox5f
-----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 j8DJv7k28171 for <[e-mail]>; Tue, 13 Sep 2005 12:57:07 -0700 (PDT)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by mail-mta.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]; Tue, 13 Sep 2005 12:56:59 -0700 (PDT)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.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]; Tue, 13 Sep 2005 12:56:58 -0700 (PDT)
Received: from [152.70.2.164] (Forwarded-For: [129.149.246.4]) by mail-srv.sfvic.sunlabs.com (mshttpd); Tue, 13 Sep 2005 12:56:58 -0700
Date: Tue, 13 Sep 2005 12:56:58 -0700
From: [e-mail]
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] rbridge for ipv6 ?
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, 13 Sep 2005 19:57:50 -0000
Status: RO
Content-Length: 2786

I agree with Joe. I don't see any problem with supporting IPv6. The IS-IS routing that we'll use
will be layer 3 agnostic. The first step is having all the RBridges exchanging their system IDs (MAC addresses)
and connectivity to other RBridges' system IDs. IS-IS does not send over IP. It has its own Ethertype. So
I don't see any problem with IPv6 for the basic RBridge-RBridge topology building piece.

Then there would be TLVs for announcing
.  VLAN membership
. MAC addresses of attached nodes
. (L3,L2) information for supporting proxy ARP/proxy ND

I'd think only the last would be layer 3 aware. And yes, I agree we should support IPv6 as well as
IPv4. I think it's just a matter of having two different TLVs, one for announcing (IPv4, MAC) and
one for announcing (IPv6, MAC). 

Are there other issues?

Radia


----- Original Message -----
From: Joe Touch <[e-mail]>
Date: Tuesday, September 13, 2005 10:18 am
Subject: Re: [rbridge] rbridge for ipv6 ?

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Pekka Savola wrote:
> > On Tue, 13 Sep 2005, Joe Touch wrote:
> > 
> >>Rbridge is an L2 device; at the ingress, it should be capable of 
> peeking>>into various packets for optimization like other L2 
> systems, e.g., for
> >>multicast. This includes IPv4 and IPv6, but these are just 
> optimizations>>- if not implemented, it should not affect correct 
> operation.> 
> > (This should be obvious, but I'll state it explicitly in any 
> case), it 
> > should still work if some parts of the site implement v4/v6 
> optimizing 
> > rbridges, some can only optimize for v4, others only for v6, and 
> yet 
> > another set not at all.
> 
> Agreed. Also, how much the optimization helps may depend on how
> widespread support for the optimization is.
> 
> > Maybe that requires each rbridge adversiting its optimizing 
> > capabilities in IS-IS or something, which may or may not be trivial.
> 
> We can have everyone participate in supporting multiple routing 
> 'trees'(they're not trees anymore, but you get the idea), where 
> only egresses
> that support v4 or v4 peek will be able to utilize. I don't think this
> requires advertizing the capabilities per se, but it will probably
> require the use of separate forwarding tables. those that support such
> will use them; others will support only a single merged table as well.
> 
> 
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFDJwoDE5f5cImnZrsRAuroAKCP0zWimIp+Z8o9wfy3r0JCRo77mACfRA6f
> 8i4sPuCpOuJE7cN33SrQ/cw=
> =L7br
> -----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 j8DHIXk00300; Tue, 13 Sep 2005 10:18:33 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 13 Sep 2005 10:18:59 -0700
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] rbridge for ipv6 ?
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, 13 Sep 2005 17:18:56 -0000
Status: RO
Content-Length: 1576

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



Pekka Savola wrote:
> On Tue, 13 Sep 2005, Joe Touch wrote:
> 
>>Rbridge is an L2 device; at the ingress, it should be capable of peeking
>>into various packets for optimization like other L2 systems, e.g., for
>>multicast. This includes IPv4 and IPv6, but these are just optimizations
>>- if not implemented, it should not affect correct operation.
> 
> (This should be obvious, but I'll state it explicitly in any case), it 
> should still work if some parts of the site implement v4/v6 optimizing 
> rbridges, some can only optimize for v4, others only for v6, and yet 
> another set not at all.

Agreed. Also, how much the optimization helps may depend on how
widespread support for the optimization is.

> Maybe that requires each rbridge adversiting its optimizing 
> capabilities in IS-IS or something, which may or may not be trivial.

We can have everyone participate in supporting multiple routing 'trees'
(they're not trees anymore, but you get the idea), where only egresses
that support v4 or v4 peek will be able to utilize. I don't think this
requires advertizing the capabilities per se, but it will probably
require the use of separate forwarding tables. those that support such
will use them; others will support only a single merged table as well.


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

iD8DBQFDJwoDE5f5cImnZrsRAuroAKCP0zWimIp+Z8o9wfy3r0JCRo77mACfRA6f
8i4sPuCpOuJE7cN33SrQ/cw=
=L7br
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8DGrPk21008; Tue, 13 Sep 2005 09:53:25 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 13 Sep 2005 09:53:51 -0700
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] rbridge for ipv6 ?
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, 13 Sep 2005 16:54:30 -0000
Status: RO
Content-Length: 1958

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



Yang Yang wrote:
> Hi,
>    Rbridge forwards frames based on L2 address in data plane. But it uses
> routing protocols which may operate at L3 in control plane.

That's exclusively interior to the rbridge; they don't depend on
examining L3 coming in.

> If L3 address is
> used, is Rbridge a L2 device? 

See above - the L3 portion is only internal to the rbridge campus. I.e.,
imagine bridges that communicate a custom tree configuration using a
private protoco.

> And I think IPv4 and IPv6 should both be
> supported.
>    Still now, I am not sure whether the routing protocol can use MAC address
> via adding a new TLV in IS-IS.

I'll let others address that...

Joe

> 
>    Best Regards!
>     Yang Yang
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Joe Touch
> Sent: Wednesday, September 14, 2005 12:01 AM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] rbridge for ipv6 ?
> 
> Rbridge is an L2 device; at the ingress, it should be capable of peeking
> into various packets for optimization like other L2 systems, e.g., for
> multicast. This includes IPv4 and IPv6, but these are just optimizations
> - if not implemented, it should not affect correct operation.
> 
> Joe
> 
> Ganesh CS wrote:
> 
>>Hi all,
>>Is rbridge for ipv6 under consideration ?
>>
>>Ganesh
>>_______________________________________________
>>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

iD8DBQFDJwQeE5f5cImnZrsRAkpXAKCnKF6udZXGzIh3pDhVrOz4ju+jLwCfXaq/
CudXBe7RsI9eRMMZTTLFsSc=
=0wSh
-----END PGP SIGNATURE-----


Received: from netcore.fi (netcore.fi [193.94.160.1]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8DGoPk20079 for <[e-mail]>; Tue, 13 Sep 2005 09:50:25 -0700 (PDT)
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8DGnjO04331 for <[e-mail]>; Tue, 13 Sep 2005 19:49:45 +0300
Date: Tue, 13 Sep 2005 19:49:45 +0300 (EEST)
From: Pekka Savola <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] rbridge for ipv6 ?
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, 13 Sep 2005 16:50:49 -0000
Status: RO
Content-Length: 885

On Tue, 13 Sep 2005, Joe Touch wrote:
> Rbridge is an L2 device; at the ingress, it should be capable of peeking
> into various packets for optimization like other L2 systems, e.g., for
> multicast. This includes IPv4 and IPv6, but these are just optimizations
> - if not implemented, it should not affect correct operation.

(This should be obvious, but I'll state it explicitly in any case), it 
should still work if some parts of the site implement v4/v6 optimizing 
rbridges, some can only optimize for v4, others only for v6, and yet 
another set not at all.

Maybe that requires each rbridge adversiting its optimizing 
capabilities in IS-IS or something, which may or may not be trivial.

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


Received: from huawei.com (szxga01-in.huawei.com [61.144.161.53]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8DGZtk15719 for <[e-mail]>; Tue, 13 Sep 2005 09:35:56 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 14 Sep 2005 00:42:08 +0800 (CST)
Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 14 Sep 2005 00:42:08 +0800 (CST)
Received: from TrueDream ([219.134.144.25]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 14 Sep 2005 00:46:50 +0800 (CST)
Date: Wed, 14 Sep 2005 00:35:45 +0800
From: Yang Yang <[e-mail]>
In-reply-to: <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcW4fe3Narmg961fTFuKW/bXwgkPRQAAdpWQ
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] rbridge for ipv6 ?
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, 13 Sep 2005 16:37:40 -0000
Status: RO
Content-Length: 1137

Hi,
   Rbridge forwards frames based on L2 address in data plane. But it uses
routing protocols which may operate at L3 in control plane. If L3 address is
used, is Rbridge a L2 device? And I think IPv4 and IPv6 should both be
supported.
   Still now, I am not sure whether the routing protocol can use MAC address
via adding a new TLV in IS-IS.

   Best Regards!
    Yang Yang

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Joe Touch
Sent: Wednesday, September 14, 2005 12:01 AM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] rbridge for ipv6 ?

Rbridge is an L2 device; at the ingress, it should be capable of peeking
into various packets for optimization like other L2 systems, e.g., for
multicast. This includes IPv4 and IPv6, but these are just optimizations
- if not implemented, it should not affect correct operation.

Joe

Ganesh CS wrote:
> Hi all,
> Is rbridge for ipv6 under consideration ?
> 
> Ganesh
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge




Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8DG14k02701; Tue, 13 Sep 2005 09:01:04 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 13 Sep 2005 09:00:57 -0700
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.92.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBEB440FE929E8F2BF8DFB155"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] rbridge for ipv6 ?
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, 13 Sep 2005 16:01:56 -0000
Status: RO
Content-Length: 1203

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

Rbridge is an L2 device; at the ingress, it should be capable of peeking
into various packets for optimization like other L2 systems, e.g., for
multicast. This includes IPv4 and IPv6, but these are just optimizations
- if not implemented, it should not affect correct operation.

Joe

Ganesh CS wrote:
> Hi all,
> Is rbridge for ipv6 under consideration ?
> 
> Ganesh
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge

--------------enigBEB440FE929E8F2BF8DFB155
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 Thunderbird - http://enigmail.mozdev.org

iD8DBQFDJve5E5f5cImnZrsRArGrAKDof5ugHvrJYVNHC5iDlxXmJoXxhQCeJtIK
MncvVJM1sAC6vNViFEaXC9U=
=2Uje
-----END PGP SIGNATURE-----

--------------enigBEB440FE929E8F2BF8DFB155--


Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8DFaWk25505 for <[e-mail]>; Tue, 13 Sep 2005 08:36:32 -0700 (PDT)
Received: from india-core-1.cisco.com ([64.104.129.221]) by ind-iport-1.cisco.com with ESMTP; 13 Sep 2005 21:11:41 -0700
Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8DFZobG011749 for <[e-mail]>; Tue, 13 Sep 2005 15:35:51 GMT
Received: from xfe-blr-412.apac.cisco.com ([64.104.140.152]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0);  Tue, 13 Sep 2005 21:06:03 +0530
Received: from [10.77.203.69] ([10.77.203.69]) by xfe-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 Sep 2005 21:06:02 +0530
Message-ID: <[e-mail]>
Date: Tue, 13 Sep 2005 21:06:02 +0530
From: Ganesh CS <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Sep 2005 15:36:02.0791 (UTC) FILETIME=[D91A8F70:01C5B878]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] rbridge for ipv6 ?
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, 13 Sep 2005 15:36:46 -0000
Status: RO
Content-Length: 58

Hi all,
Is rbridge for ipv6 under consideration ?

Ganesh


Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8DD1uk05590 for <[e-mail]>; Tue, 13 Sep 2005 06:01:56 -0700 (PDT)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2EEDD72E91 for <[e-mail]>; Tue, 13 Sep 2005 15:01:50 +0200 (CEST)
Received: from [163.117.139.229] (gibanez.it.uc3m.es [163.117.139.229]) by smtp02.uc3m.es (Postfix) with ESMTP id 2153B72EA4 for <[e-mail]>; Tue, 13 Sep 2005 15:01:49 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 13 Sep 2005 15:01:50 +0200
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] Convergence time
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, 13 Sep 2005 13:03:15 -0000
Status: RO
Content-Length: 7197

OK.
GOE is superoptimized and goes beyond RSTP in using the "Alternate" root 
port. But the values given for RSTP are pertinent.
I think the "clever" approach of tree instances rooted in the sink 
should be considered by Rbridges.
Lucent paper reports low reconfiguration times for  "their" RSTP 
including root bridge failure, only slightly superior to link failure. 
So it seems it can optimized only with RSTP.
Regards
Guillermo

Sofia, Rute wrote:

>Hello Guillermo,
>
>Thanks for the references.
>
>I am aware of GOE. However, GOE uses multiple-tree instances in a quite clever way, given that each bridge (edge bridge) becomes the root of a sink ST. And in fact, they do not take care of root failure - at least the paper does not really specify how root failure is treated. When the root fails, then they cleverly assume that because the root is the sink and represents an edge bridge (e.g., an access node), then there is no need to "recover". In other words, recover is not possible, unless there is a backup edge bridge (multi-homed scenarios) Moreover, GOE relies not only in multiple tree instances (simplification of MSTP) but also in "backup" trees, given that for each bridge, they establish two trees giving them different priorities.
>But it is a fact that their approach converges quickly. Again, this is due to the in-service reconfiguration they provide.
>
>As for the Lucent paper, I'll check it. However, my question was more related to the subject previously mentioned, meaning, the question Wojtek asked about IS-IS convergence time tunning in Rbridges and this compared to "pure" RSTP (one tree instance).
>
>The pre-flooding ability of Rbridges brings in flexibility but there is (possibly) a cost associated to the IS-IS tunning. The following reference concerns IS-IS tunning on IP:
>
>http://portal.acm.org/citation.cfm?id=1070873.1070877
>
>But the question is: does Rbridges consider this? In fact, the tuning of IS-IS may affect the performance of Rbridges, given that while tuning IS-IS to achieve convergence in the order of 10/100 ms seems feasible, there is a price to pay in terms of updates exchanged...
>
>Regards,
>Rute
>
>
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
>Sent: 13 September 2005 12:54
>To: Developing a hybrid router/bridge.
>Subject: Re: [rbridge] Convergence time
>
>
>
>
>Rute ,
>       10 msec is cited in the standard as a reachable minimum to detect 
>link failure (for instance of the bridge root port link).  As the 
>alternate port for root port  is preselected, no BPDU interchange across 
>the link is needed in this particular case for reconfiguration of the link. Global Open Ethernet goes beyond this, reaching 2 msec for switchover to 
>an alternate link with GOE switches. See:  Global Open Ethernet (GOE) 
>System and its Performance Evaluation/ A. Iwata, Y. Hidaka, M. 
>Umayabashi, N. Enomoto, and A. Arutaki  (IEEE Journal on Selected Areas 
>in Communications) Oct. 2004 ./In this article performance for 
>reconfiguration with RSTP switches is reported as 60 msec, but growing 
>with increasing network sizes.
>Lucent offers RSTP based improved implementations with reconvergence 
>under 200 msec. in :  
>www.lucent.ru/i/docs/TripplePlay/Spanning-Trees-Whitepaper.doc
>Although the upper limit for RSTP seems to be on the several seconds 
>range, it seems there is still room for improvement as the vendors 
>manifest (Lucent) and implementations show. So, improving RSTP to lower 
>upper convergence limit  might be one way to advance, as the capability 
>for fast transitions is proven.
>Regards
>Guillermo
>PD. Root bridge failure seems to be the worst case for reconvergence in 
>RSTP compared with link failure or new root bridge election.
>
>Sofia, Rute wrote:
>
>  
>
>>Guillermo,
>>
>>Can you please refer to *any* performance study on RSTP that shows 
>>convergence times in the order of 10/100 ms?
>>
>>Best Regards,
>>Rute Sofia
>>
>>
>> 
>>
>>    
>>
>>>-----Original Message-----
>>>From: [e-mail]
>>>[mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
>>>Sent: Monday, September 12, 2005 11:43 PM
>>>To: Developing a hybrid router/bridge.
>>>Subject: Re: [rbridge] Convergence time
>>>
>>>I recommend a reading of RSTP (IEEE 802.1D) protocol for
>>>mechanisms of 
>>>fast reconfiguration and spanning tree reconstruction. Although 
>>>convergence is alleged to extend to several seconds in case of root 
>>>bridge failure (Myers 2004), tipical times are tenths, hundreds of 
>>>milliseconds, not easy to achieve with routing protocols.
>>>I am not familiar with fast rerouting but applying it to 
>>>build spanning 
>>>trees may be require a different solution than repairing routes with 
>>>backup routes.
>>>Guillermo Ib??ez
>>>
>>>Alia Atlas wrote:
>>>
>>>   
>>>
>>>      
>>>
>>>>I imagine that one could do fast-reroute techniques,
>>>>     
>>>>
>>>>        
>>>>
>>>depending on the
>>>   
>>>
>>>      
>>>
>>>>convergence time requirements.  Given SPTs and a link-state
>>>>     
>>>>
>>>>        
>>>>
>>>protocol
>>>   
>>>
>>>      
>>>
>>>>are being used,
>>>>I believe that the work in rtgwg could apply.
>>>>
>>>>Alia
>>>>
>>>>On 8/29/05, *Wojtek Paprowicz* <[e-mail]
>>>><mailto:[e-mail]>> wrote:
>>>>
>>>>   Hi everybody,
>>>>
>>>>   I was wondering if convergence is a case in RBRIDGE idea. Taking
>>>>   into concideration, that currently RBRIDGEs run ISIS, I think it
>>>>   should be. How do you think should be the timers set in order to
>>>>   achieve results similar to SDH? The default timers will
>>>>     
>>>>
>>>>        
>>>>
>>>not do the
>>>   
>>>
>>>      
>>>
>>>>   trick. On the other hand, we cannot lower e.g. helloInterval too
>>>>   much. The timers are also crucial for node/link
>>>>     
>>>>
>>>>        
>>>>
>>>failures and failure
>>>   
>>>
>>>      
>>>
>>>>   recovery times. Be grateful for your opinions.
>>>>
>>>>   Regards,
>>>>   Wojtek Paprowicz
>>>>
>>>>
>>>>
>>>>   _______________________________________________
>>>>   rbridge mailing list
>>>>   [e-mail] <mailto:[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
>>
>> 
>>
>>    
>>
>_______________________________________________
>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 gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8DBQKk09548 for <[e-mail]>; Tue, 13 Sep 2005 04:26:21 -0700 (PDT)
Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j8DBQE7Y016813 for <[e-mail]>; Tue, 13 Sep 2005 13:26:14 +0200
Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j8DBQEPZ020126 for <[e-mail]>; Tue, 13 Sep 2005 13:26:14 +0200
Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0);  Tue, 13 Sep 2005 13:26:07 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Tue, 13 Sep 2005 13:26:07 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Convergence time
Thread-Index: AcW4U46ZK6+Njig0QyKU8RyND7IQiwAAL+Gg
From: "Sofia, Rute" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 13 Sep 2005 11:26:07.0787 (UTC) FILETIME=[EF6287B0:01C5B855]
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 j8DBQKk09548
Subject: Re: [rbridge] Convergence time
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, 13 Sep 2005 11:26:55 -0000
Status: RO
Content-Length: 6228

Hello Guillermo,

Thanks for the references.

I am aware of GOE. However, GOE uses multiple-tree instances in a quite clever way, given that each bridge (edge bridge) becomes the root of a sink ST. And in fact, they do not take care of root failure - at least the paper does not really specify how root failure is treated. When the root fails, then they cleverly assume that because the root is the sink and represents an edge bridge (e.g., an access node), then there is no need to "recover". In other words, recover is not possible, unless there is a backup edge bridge (multi-homed scenarios) Moreover, GOE relies not only in multiple tree instances (simplification of MSTP) but also in "backup" trees, given that for each bridge, they establish two trees giving them different priorities.
But it is a fact that their approach converges quickly. Again, this is due to the in-service reconfiguration they provide.

As for the Lucent paper, I'll check it. However, my question was more related to the subject previously mentioned, meaning, the question Wojtek asked about IS-IS convergence time tunning in Rbridges and this compared to "pure" RSTP (one tree instance).

The pre-flooding ability of Rbridges brings in flexibility but there is (possibly) a cost associated to the IS-IS tunning. The following reference concerns IS-IS tunning on IP:

http://portal.acm.org/citation.cfm?id=1070873.1070877

But the question is: does Rbridges consider this? In fact, the tuning of IS-IS may affect the performance of Rbridges, given that while tuning IS-IS to achieve convergence in the order of 10/100 ms seems feasible, there is a price to pay in terms of updates exchanged...

Regards,
Rute



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
Sent: 13 September 2005 12:54
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Convergence time




Rute ,
       10 msec is cited in the standard as a reachable minimum to detect 
link failure (for instance of the bridge root port link).  As the 
alternate port for root port  is preselected, no BPDU interchange across 
the link is needed in this particular case for reconfiguration of the link. Global Open Ethernet goes beyond this, reaching 2 msec for switchover to 
an alternate link with GOE switches. See:  Global Open Ethernet (GOE) 
System and its Performance Evaluation/ A. Iwata, Y. Hidaka, M. 
Umayabashi, N. Enomoto, and A. Arutaki  (IEEE Journal on Selected Areas 
in Communications) Oct. 2004 ./In this article performance for 
reconfiguration with RSTP switches is reported as 60 msec, but growing 
with increasing network sizes.
Lucent offers RSTP based improved implementations with reconvergence 
under 200 msec. in :  
www.lucent.ru/i/docs/TripplePlay/Spanning-Trees-Whitepaper.doc
Although the upper limit for RSTP seems to be on the several seconds 
range, it seems there is still room for improvement as the vendors 
manifest (Lucent) and implementations show. So, improving RSTP to lower 
upper convergence limit  might be one way to advance, as the capability 
for fast transitions is proven.
Regards
Guillermo
PD. Root bridge failure seems to be the worst case for reconvergence in 
RSTP compared with link failure or new root bridge election.

Sofia, Rute wrote:

>Guillermo,
>
>Can you please refer to *any* performance study on RSTP that shows 
>convergence times in the order of 10/100 ms?
>
>Best Regards,
>Rute Sofia
> 
>
>  
>
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
>>Sent: Monday, September 12, 2005 11:43 PM
>>To: Developing a hybrid router/bridge.
>>Subject: Re: [rbridge] Convergence time
>>
>>I recommend a reading of RSTP (IEEE 802.1D) protocol for
>>mechanisms of 
>>fast reconfiguration and spanning tree reconstruction. Although 
>>convergence is alleged to extend to several seconds in case of root 
>>bridge failure (Myers 2004), tipical times are tenths, hundreds of 
>>milliseconds, not easy to achieve with routing protocols.
>>I am not familiar with fast rerouting but applying it to 
>>build spanning 
>>trees may be require a different solution than repairing routes with 
>>backup routes.
>>Guillermo Ib??ez
>>
>>Alia Atlas wrote:
>>
>>    
>>
>>>I imagine that one could do fast-reroute techniques,
>>>      
>>>
>>depending on the
>>    
>>
>>>convergence time requirements.  Given SPTs and a link-state
>>>      
>>>
>>protocol
>>    
>>
>>>are being used,
>>>I believe that the work in rtgwg could apply.
>>>
>>>Alia
>>>
>>>On 8/29/05, *Wojtek Paprowicz* <[e-mail]
>>><mailto:[e-mail]>> wrote:
>>>
>>>    Hi everybody,
>>>
>>>    I was wondering if convergence is a case in RBRIDGE idea. Taking
>>>    into concideration, that currently RBRIDGEs run ISIS, I think it
>>>    should be. How do you think should be the timers set in order to
>>>    achieve results similar to SDH? The default timers will
>>>      
>>>
>>not do the
>>    
>>
>>>    trick. On the other hand, we cannot lower e.g. helloInterval too
>>>    much. The timers are also crucial for node/link
>>>      
>>>
>>failures and failure
>>    
>>
>>>    recovery times. Be grateful for your opinions.
>>>
>>>    Regards,
>>>    Wojtek Paprowicz
>>>
>>>
>>>
>>>    _______________________________________________
>>>    rbridge mailing list
>>>    [e-mail] <mailto:[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
>
>  
>
_______________________________________________
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 j8DAsRk00975 for <[e-mail]>; Tue, 13 Sep 2005 03:54:27 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 33B7F8CA23 for <[e-mail]>; Tue, 13 Sep 2005 12:54:21 +0200 (CEST)
Received: from [163.117.139.229] (gibanez.it.uc3m.es [163.117.139.229]) by smtp01.uc3m.es (Postfix) with ESMTP id 586208CA1E for <[e-mail]>; Tue, 13 Sep 2005 12:54:20 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 13 Sep 2005 12:54:21 +0200
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] Convergence time
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, 13 Sep 2005 10:54:48 -0000
Status: RO
Content-Length: 4175

Rute ,
       10 msec is cited in the standard as a reachable minimum to detect 
link failure (for instance of the bridge root port link).  As the 
alternate port for root port  is preselected, no BPDU interchange across 
the link is needed in this particular case for reconfiguration of the link.
Global Open Ethernet goes beyond this, reaching 2 msec for switchover to 
an alternate link with GOE switches. See:  Global Open Ethernet (GOE) 
System and its Performance Evaluation/ A. Iwata, Y. Hidaka, M. 
Umayabashi, N. Enomoto, and A. Arutaki  (IEEE Journal on Selected Areas 
in Communications) Oct. 2004 ./In this article performance for 
reconfiguration with RSTP switches is reported as 60 msec, but growing 
with increasing network sizes.
Lucent offers RSTP based improved implementations with reconvergence 
under 200 msec. in :  
www.lucent.ru/i/docs/TripplePlay/Spanning-Trees-Whitepaper.doc
Although the upper limit for RSTP seems to be on the several seconds 
range, it seems there is still room for improvement as the vendors 
manifest (Lucent) and implementations show. So, improving RSTP to lower 
upper convergence limit  might be one way to advance, as the capability 
for fast transitions is proven.
Regards
Guillermo
PD. Root bridge failure seems to be the worst case for reconvergence in 
RSTP compared with link failure or new root bridge election.

Sofia, Rute wrote:

>Guillermo,
>
>Can you please refer to *any* performance study on RSTP that shows convergence times in the order of 10/100 ms?
>
>Best Regards,
>Rute Sofia
> 
>
>  
>
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
>>Sent: Monday, September 12, 2005 11:43 PM
>>To: Developing a hybrid router/bridge.
>>Subject: Re: [rbridge] Convergence time
>>
>>I recommend a reading of RSTP (IEEE 802.1D) protocol for 
>>mechanisms of 
>>fast reconfiguration and spanning tree reconstruction. Although 
>>convergence is alleged to extend to several seconds in case of root 
>>bridge failure (Myers 2004), tipical times are tenths, hundreds of 
>>milliseconds, not easy to achieve with routing protocols.
>>I am not familiar with fast rerouting but applying it to 
>>build spanning 
>>trees may be require a different solution than repairing routes with 
>>backup routes.
>>Guillermo Ib??ez
>>
>>Alia Atlas wrote:
>>
>>    
>>
>>>I imagine that one could do fast-reroute techniques, 
>>>      
>>>
>>depending on the
>>    
>>
>>>convergence time requirements.  Given SPTs and a link-state 
>>>      
>>>
>>protocol 
>>    
>>
>>>are being used,
>>>I believe that the work in rtgwg could apply.
>>>
>>>Alia
>>>
>>>On 8/29/05, *Wojtek Paprowicz* <[e-mail] 
>>><mailto:[e-mail]>> wrote:
>>>
>>>    Hi everybody,
>>>
>>>    I was wondering if convergence is a case in RBRIDGE idea. Taking
>>>    into concideration, that currently RBRIDGEs run ISIS, I think it
>>>    should be. How do you think should be the timers set in order to
>>>    achieve results similar to SDH? The default timers will 
>>>      
>>>
>>not do the
>>    
>>
>>>    trick. On the other hand, we cannot lower e.g. helloInterval too
>>>    much. The timers are also crucial for node/link 
>>>      
>>>
>>failures and failure
>>    
>>
>>>    recovery times. Be grateful for your opinions.
>>>
>>>    Regards,
>>>    Wojtek Paprowicz
>>>
>>>
>>>
>>>    _______________________________________________
>>>    rbridge mailing list
>>>    [e-mail] <mailto:[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 gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8CMLNk06283 for <[e-mail]>; Mon, 12 Sep 2005 15:21:24 -0700 (PDT)
Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j8CMLHK7022638 for <[e-mail]>; Tue, 13 Sep 2005 00:21:17 +0200
Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j8CMLHbC018179 for <[e-mail]>; Tue, 13 Sep 2005 00:21:17 +0200
Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0);  Tue, 13 Sep 2005 00:21:15 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Tue, 13 Sep 2005 00:21:11 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Convergence time
Thread-Index: AcW35PzbRHhv5dHgRGeFFCYYgDXgKgAAxuNw
From: "Sofia, Rute" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 12 Sep 2005 22:21:15.0359 (UTC) FILETIME=[4A1C46F0:01C5B7E8]
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 j8CMLNk06283
Subject: Re: [rbridge] Convergence time
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, 12 Sep 2005 22:21:49 -0000
Status: RO
Content-Length: 2492

Guillermo,

Can you please refer to *any* performance study on RSTP that shows convergence times in the order of 10/100 ms?

Best Regards,
Rute Sofia
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
> Sent: Monday, September 12, 2005 11:43 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Convergence time
> 
> I recommend a reading of RSTP (IEEE 802.1D) protocol for 
> mechanisms of 
> fast reconfiguration and spanning tree reconstruction. Although 
> convergence is alleged to extend to several seconds in case of root 
> bridge failure (Myers 2004), tipical times are tenths, hundreds of 
> milliseconds, not easy to achieve with routing protocols.
> I am not familiar with fast rerouting but applying it to 
> build spanning 
> trees may be require a different solution than repairing routes with 
> backup routes.
> Guillermo Ib??ez
> 
> Alia Atlas wrote:
> 
> > I imagine that one could do fast-reroute techniques, 
> depending on the
> > convergence time requirements.  Given SPTs and a link-state 
> protocol 
> > are being used,
> > I believe that the work in rtgwg could apply.
> >
> > Alia
> >
> > On 8/29/05, *Wojtek Paprowicz* <[e-mail] 
> > <mailto:[e-mail]>> wrote:
> >
> >     Hi everybody,
> >
> >     I was wondering if convergence is a case in RBRIDGE idea. Taking
> >     into concideration, that currently RBRIDGEs run ISIS, I think it
> >     should be. How do you think should be the timers set in order to
> >     achieve results similar to SDH? The default timers will 
> not do the
> >     trick. On the other hand, we cannot lower e.g. helloInterval too
> >     much. The timers are also crucial for node/link 
> failures and failure
> >     recovery times. Be grateful for your opinions.
> >
> >     Regards,
> >     Wojtek Paprowicz
> >
> >
> >
> >     _______________________________________________
> >     rbridge mailing list
> >     [e-mail] <mailto:[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 j8CLh3k24277 for <[e-mail]>; Mon, 12 Sep 2005 14:43:03 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0136B8C660 for <[e-mail]>; Mon, 12 Sep 2005 23:42:57 +0200 (CEST)
Received: from [163.117.203.100] (unknown [163.117.203.100]) by smtp01.uc3m.es (Postfix) with ESMTP id 1A9EF8C5D1 for <[e-mail]>; Mon, 12 Sep 2005 23:42:56 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 12 Sep 2005 23:42:57 +0200
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: <15396086.1125305297383.JavaMail.webadm@ew10> <[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] Convergence time
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, 12 Sep 2005 21:43:44 -0000
Status: RO
Content-Length: 1807

I recommend a reading of RSTP (IEEE 802.1D) protocol for mechanisms of 
fast reconfiguration and spanning tree reconstruction. Although 
convergence is alleged to extend to several seconds in case of root 
bridge failure (Myers 2004), tipical times are tenths, hundreds of 
milliseconds, not easy to achieve with routing protocols.
I am not familiar with fast rerouting but applying it to build spanning 
trees may be require a different solution than repairing routes with 
backup routes.
Guillermo Ib??ez

Alia Atlas wrote:

> I imagine that one could do fast-reroute techniques, depending on the
> convergence time requirements.  Given SPTs and a link-state protocol 
> are being used,
> I believe that the work in rtgwg could apply.
>
> Alia
>
> On 8/29/05, *Wojtek Paprowicz* <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi everybody,
>
>     I was wondering if convergence is a case in RBRIDGE idea. Taking
>     into concideration, that currently RBRIDGEs run ISIS, I think it
>     should be. How do you think should be the timers set in order to
>     achieve results similar to SDH? The default timers will not do the
>     trick. On the other hand, we cannot lower e.g. helloInterval too
>     much. The timers are also crucial for node/link failures and failure
>     recovery times. Be grateful for your opinions.
>
>     Regards,
>     Wojtek Paprowicz
>
>
>
>     _______________________________________________
>     rbridge mailing list
>     [e-mail] <mailto:[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 j8CLHUk16972 for <[e-mail]>; Mon, 12 Sep 2005 14:17:30 -0700 (PDT)
Received: by wproxy.gmail.com with SMTP id 37so2230244wra for <[e-mail]>; Mon, 12 Sep 2005 14:17:22 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=TWYAhiO79UPo4eVFkOMTfNYHTgrFL+6zENVColPA0fYmMxyPHIoFA1GnZtUD+43InpUkQtBujPFnXljCwZyxHpyoogcwYBMk2Tyetrryf06awvVsseQYymhh32b6eZERnrpCQrNEU1AGdhuRU7hT3I3SLFeXrERcL6LC3PB8J/M=
Received: by 10.54.27.71 with SMTP id a71mr3016682wra; Mon, 12 Sep 2005 14:17:22 -0700 (PDT)
Received: by 10.54.148.1 with HTTP; Mon, 12 Sep 2005 14:17:22 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 12 Sep 2005 14:17:22 -0700
From: Alia Atlas <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <15396086.1125305297383.JavaMail.webadm@ew10>
Mime-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_13241_33092114.1126559842320"
References: <15396086.1125305297383.JavaMail.webadm@ew10>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Convergence time
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 12 Sep 2005 21:17:44 -0000
Status: RO
Content-Length: 2705

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

I imagine that one could do fast-reroute techniques, depending on the=20
convergence time requirements. Given SPTs and a link-state protocol are=20
being used,=20
I believe that the work in rtgwg could apply.

Alia

On 8/29/05, Wojtek Paprowicz <[e-mail]> wrote:
>=20
> Hi everybody,
>=20
> I was wondering if convergence is a case in RBRIDGE idea. Taking
> into concideration, that currently RBRIDGEs run ISIS, I think it
> should be. How do you think should be the timers set in order to
> achieve results similar to SDH? The default timers will not do the
> trick. On the other hand, we cannot lower e.g. helloInterval too
> much. The timers are also crucial for node/link failures and failure
> recovery times. Be grateful for your opinions.
>=20
> Regards,
> Wojtek Paprowicz
>=20
>=20
>=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
>

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

I imagine that one could do fast-reroute techniques, depending on the <br>
convergence time requirements.&nbsp; Given SPTs and a link-state protocol a=
re being used, <br>
I believe that the work in rtgwg could apply.<br>
<br>
Alia<br><br><div><span class=3D"gmail_quote">On 8/29/05, <b class=3D"gmail_=
sendername">Wojtek Paprowicz</b> &lt;<a href=3D"mailto:[e-mail]">=
[e-mail]</a>&gt; wrote:</span><blockquote class=3D"gmail_quote" s=
tyle=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8e=
x; padding-left: 1ex;">
Hi everybody,<br><br>I was wondering if convergence is a case in RBRIDGE id=
ea. Taking<br>into concideration, that currently RBRIDGEs run ISIS, I think=
 it<br>should be. How do you think should be the timers set in order to
<br>achieve results similar to SDH? The default timers will not do the<br>t=
rick. On the other hand, we cannot lower e.g. helloInterval too<br>much. Th=
e timers are also crucial for node/link failures and failure<br>recovery ti=
mes. Be grateful for your opinions.
<br><br>Regards,<br>Wojtek Paprowicz<br><br><br><br>_______________________=
________________________<br>rbridge mailing list<br><a href=3D"mailto:rbrid=
[e-mail]">[e-mail]</a><br><a href=3D"http://www.postel.org/m=
ailman/listinfo/rbridge">
http://www.postel.org/mailman/listinfo/rbridge</a><br></blockquote></div><b=
r>

------=_Part_13241_33092114.1126559842320--