Subject: [rbridge] IS-IS per VLAN ?

From: michsmit at cisco.com (Michael Smith (michsmit))
Date: Tue, 27 Sep 2005 08:14:33 -0700

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> > 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.  

> 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
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge
>

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 27 Sep 2005 13:39:24 -0700

>> often see the "shortcomings" first.  

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

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

Date: Tue, 27 Sep 2005 13:39:24 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2719

Michael Smith (michsmit) wrote:
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Joe Touch> 
> 
> 
> 
>>[email-masked] wrote:
> 
>>>>From: [email-masked]
>>>>[mailto:[email-masked]] On Behalf Of Joe Touch
> 
>>...
> 

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

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

[email-masked]

> [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 27 Sep 2005 08:14:33 -0700
From: "Michael Smith \(michsmit\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2332

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Joe Touch> 
> > [email-masked] wrote:
> >>>From: [email-masked]
> >>>[mailto:[email-masked]] On Behalf Of Joe Touch
> > ...

Michael

> [email-masked]

Date: Tue, 27 Sep 2005 07:29:58 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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
>=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
[email-masked]

> [email-masked]

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

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

Date: Tue, 27 Sep 2005 10:30:34 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2220

Joe Touch wrote:

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

>iD8DBQFDOEBWE5f5cImnZrsRAh+jAKCaflVr5EGAatUzPxbL9JHdTSzedACeP/SE
>muZvkqSgacJ5rmJ5J8C+iN4=
>=MU0/
>[email-masked]

Date: Mon, 26 Sep 2005 15:23:07 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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

Date: Mon, 26 Sep 2005 13:17:28 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1184

> [email-masked] wrote:
>>>From: [email-masked] 
>>>[mailto:[email-masked]] 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

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

From: [email-masked]
Content-class: urn:content-classes:message
Date: Mon, 26 Sep 2005 12:00:55 -0700
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1567

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Joe Touch
> 
> 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

> 
> 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
> iD8DBQFDOEBWE5f5cImnZrsRAh+jAKCaflVr5EGAatUzPxbL9JHdTSzedACeP/SE
> muZvkqSgacJ5rmJ5J8C+iN4=
> =MU0/
> [email-masked]

Date: Mon, 26 Sep 2005 11:39:18 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1125

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

Date: Mon, 26 Sep 2005 11:35:44 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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

Date: Mon, 26 Sep 2005 11:31:02 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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

Date: Mon, 26 Sep 2005 08:07:53 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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 <[email-masked]=
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"

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

Date: Mon, 26 Sep 2005 07:30:54 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 636

--On s?ndag, september 25, 2005 12:22:00 -0700 Joe Touch <[email-masked]> 
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.

Date: Sun, 25 Sep 2005 12:22:00 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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 <[email-masked]> 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
> 
> 
> 
> ------------------------------------------------------------------------
> 
> [email-masked]

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

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

Date: Sun, 25 Sep 2005 18:53:29 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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 <[email-masked]> 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

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

From: "Spencer Dawkins" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Date: Sun, 25 Sep 2005 05:41:04 +0800
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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 

Date: Sat, 24 Sep 2005 09:52:21 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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"

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

Date: Sat, 24 Sep 2005 09:14:53 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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

From: "Spencer Dawkins" <[email-masked]>
To: <[email-masked]>
Date: Sat, 24 Sep 2005 22:29:57 +0800
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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 

Date: Fri, 23 Sep 2005 17:53:52 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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

Date: Fri, 23 Sep 2005 13:06:21 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [rbridge] STP and ISIS
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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

From: [email-masked]
Content-class: urn:content-classes:message
Date: Fri, 23 Sep 2005 09:57:22 -0700
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3723

> From: [email-masked] 
> [mailto:[email-masked]] 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 
> >><[email-masked]> 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
> >>
> >>[email-masked]
> > --> -----Original Message-----
> > --> From: [email-masked]
> > --> [mailto:[email-masked]]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
> > --> [email-masked]
> > --> http://www.postel.org/mailman/listinfo/rbridge
> > --> 
> > [email-masked]

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 23 Sep 2005 12:56:51 -0300
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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: [email-masked] 
--> [mailto:[email-masked]]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: [email-masked] 
--> [mailto:[email-masked]]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 
--> >><[email-masked]> 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
--> >>[email-masked]
--> >>http://www.postel.org/mailman/listinfo/rbridge
--> > 
--> > 
--> > --> -----Original Message-----
--> > --> From: [email-masked] 
--> > --> [mailto:[email-masked]]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
--> > --> [email-masked]
--> > --> http://www.postel.org/mailman/listinfo/rbridge
--> > --> 
--> > _______________________________________________
--> > rbridge mailing list
--> > [email-masked]
--> > http://www.postel.org/mailman/listinfo/rbridge
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

content-class: urn:content-classes:message
Date: Fri, 23 Sep 2005 11:37:39 -0400
From: "Holland, David \(David\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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: [email-masked] [mailto:[email-masked]]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 
>><[email-masked]> 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
>>
>>[email-masked]
> --> -----Original Message-----
> --> From: [email-masked] 
> --> [mailto:[email-masked]]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
> --> [email-masked]
> --> http://www.postel.org/mailman/listinfo/rbridge
> --> 
> [email-masked]

Date: Fri, 23 Sep 2005 08:08:53 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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
>><[email-masked]> 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
>>
>>[email-masked]
>=20
>=20
> --> -----Original Message-----
> --> From: [email-masked]=20
> --> [mailto:[email-masked]]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
> --> [email-masked]
> --> http://www.postel.org/mailman/listinfo/rbridge
> -->=20
> [email-masked]

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

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

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 23 Sep 2005 11:45:28 -0300
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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 
> <[email-masked]> 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
> 
> [email-masked]

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]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
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Fri, 23 Sep 2005 07:23:37 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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
> From: [email-masked] [mailto:[email-masked]] 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
> [email-masked]

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

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

Date: Fri, 23 Sep 2005 07:20:59 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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
> <[email-masked]> 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
> [email-masked]

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

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

Content-class: urn:content-classes:message
Date: Fri, 23 Sep 2005 02:39:17 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Tom Sanders" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Sanders
Sent: Friday, September 23, 2005 2:47 PM
To: [email-masked]
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 <[email-masked]> 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 <[email-masked]>
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
> [email-masked]

--
Toms.
[email-masked]

Date: Fri, 23 Sep 2005 14:46:56 +0530
From: Tom Sanders <[email-masked]>
To: [email-masked]
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: Tom Sanders <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
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 <[email-masked]> 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 <[email-masked]> 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
> >
> >
>
> [email-masked]

--
Toms.

Date: Fri, 23 Sep 2005 10:33:27 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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 
><[email-masked]> 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
>
>[email-masked]

Date: Fri, 23 Sep 2005 10:05:30 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1126

--On fredag, september 23, 2005 09:38:53 +0200 Guillermo Ib??ez 
<[email-masked]> 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

Date: Fri, 23 Sep 2005 09:38:53 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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." 
>>
>>
>>[email-masked]
>------------------------------------------------------------------------
>
>[email-masked]

Date: Thu, 22 Sep 2005 21:12:13 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] STP and ISIS
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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 <[email-masked]>
>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
>  
>

Content-class: urn:content-classes:message
Date: Thu, 22 Sep 2005 20:59:15 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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: [email-masked] [mailto:[email-masked]] 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." 
> 
> 
> 

Date: Thu, 22 Sep 2005 17:09:35 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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
> [email-masked]

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

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

Date: Thu, 22 Sep 2005 09:37:10 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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 <[email-masked]> 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
>  
>

Date: Thu, 22 Sep 2005 16:21:06 +0100
From: Mike Hughes <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1166

--On 22 September 2005 20:26 +0530 Ganesh CS <[email-masked]> 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
[email-masked]   http://www.linx.net/
     "Only one thing in life is certain: init is Process #1"

Date: Thu, 22 Sep 2005 20:26:47 +0530
From: Ganesh CS <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] IS-IS per VLAN ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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

Date: Thu, 22 Sep 2005 15:23:57 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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
>From: [email-masked] [mailto:[email-masked]] 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." 
>
>
>[email-masked]

Content-class: urn:content-classes:message
Date: Thu, 22 Sep 2005 03:26:34 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Configuration of VLANs vs selfconfiguration
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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: [email-masked] [mailto:[email-masked]] 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." 

Date: Thu, 22 Sep 2005 11:00:09 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Configuration of VLANs vs selfconfiguration
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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." 

Date: Wed, 21 Sep 2005 16:56:21 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] STP and ISIS
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2463

[email-masked] wrote:
>>From: [email-masked] 
>>[mailto:[email-masked]] 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

From: [email-masked]
Content-class: urn:content-classes:message
Date: Wed, 21 Sep 2005 16:36:38 -0700
To: "Developing a hybrid router/bridge." <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] STP and ISIS
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1860

> From: [email-masked] 
> [mailto:[email-masked]] 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

Date: Wed, 21 Sep 2005 14:50:18 -0700
From: Joe Touch <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] STP and ISIS
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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"

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

Date: Wed, 21 Sep 2005 13:06:52 +0100
From: Mike Hughes <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [rbridge] STP and ISIS
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1666

--On 21 September 2005 12:04 +0530 Tom Sanders <[email-masked]>
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
[email-masked]   http://www.linx.net/
     "Only one thing in life is certain: init is Process #1"

Date: Wed, 21 Sep 2005 12:04:36 +0530
From: Tom Sanders <[email-masked]>
To: [email-masked]
Subject: [rbridge] STP and ISIS
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
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.

Date: Tue, 20 Sep 2005 10:38:19 +0200
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To: [email-masked], [email-masked], [email-masked], pwe3 <[email-masked]>, [email-masked], L2VPN <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>, [email-masked],  [email-masked]
Subject: [rbridge] GMPLS Ethernet in Vancouver
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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

[email-masked] (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:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 19 Sep 2005 21:48:18 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] ????:  ????:  rbridge for ipv6 ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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: [email-masked] [mailto:[email-masked]] 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
> ??-----????-----
> ???: [email-masked] [mailto:[email-masked]]
> ?? 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: [email-masked] [mailto:[email-masked]]
> 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
> ????-----????-----
> ?????: [email-masked]
> [mailto:[email-masked]]
> ???? 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
> ????>??-----????-----
> ????>???: [email-masked]
> ??[mailto:[email-masked]]
> ????>?? 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: [email-masked]
> ??[mailto:[email-masked]]
> ????>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
> ??[email-masked]
> ??http://www.postel.org/mailman/listinfo/rbridge
> 
> 
> ------------------------------------------------------------------------
> 
> [email-masked]

Date: Mon, 19 Sep 2005 21:08:03 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] ????:  ????:  rbridge for ipv6 ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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: [email-masked] [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: [email-masked] [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: [email-masked]
> [mailto:[email-masked]]
> =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: [email-masked]=

> =A1=A1=A1=A1[mailto:[email-masked]]
> =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: [email-masked]
> =A1=A1=A1=A1[mailto:[email-masked]]
> =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=[email-masked]
> =A1=A1=A1=A1http://www.postel.org/mailman/listinfo/rbridge
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> [email-masked]

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

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

Date: Tue, 20 Sep 2005 10:30:44 +0800
From: Yiou Deng <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Importance: Normal
Subject: Re: [rbridge] ????:  ????:  rbridge for ipv6 ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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
????-----??????-----
??????: [email-masked] [mailto:[email-masked]]
???? 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: [email-masked] [mailto:[email-masked]]
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
????????-----??????-----
??????????: [email-masked]
[mailto:[email-masked]]
???????? 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
????????>????-----??????-----
????????>??????: [email-masked]
????[mailto:[email-masked]]
????????>???? 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: [email-masked]
????[mailto:[email-masked]]
????????>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
????[email-masked]
????http://www.postel.org/mailman/listinfo/rbridge

Date: Mon, 19 Sep 2005 10:36:56 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] ????:  ????:  rbridge for ipv6 ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5262

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
>>????-----??????-----
>>??????: [email-masked] [mailto:[email-masked]]
>>???? 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
>>????>????-----??????-----
>>????>??????: [email-masked]
>>[mailto:[email-masked]]
>>????>???? 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: [email-masked]
>>[mailto:[email-masked]]
>>????>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
>>????>????> [email-masked]
>>????>????> http://www.postel.org/mailman/listinfo/rbridge
>>????>????
>>????>????
>>????>????_______________________________________________
>>????>????rbridge mailing list
>>????>????[email-masked]
>>????>????http://www.postel.org/mailman/listinfo/rbridge
>>????>
>>????>  
>>????>
>>????
>> 
>>
>>
>>>-----------------------------------------------------------------------
>>>   
>>>
>>
>>-
>>????>
>>????>_______________________________________________
>>????>rbridge mailing list
>>????>[email-masked]
>>????>http://www.postel.org/mailman/listinfo/rbridge
>>????>  
>>????>
>> 
>>
>>------------------------------------------------------------------------
>>
>>[email-masked]
>>------------------------------------------------------------------------
>>
>>[email-masked]

Date: Mon, 19 Sep 2005 20:27:35 +0530
From: Ganesh CS <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] ????:  ????:  rbridge for ipv6 ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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
>????-----??????-----
>??????: [email-masked] [mailto:[email-masked]]
>???? 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
>????>????-----??????-----
>????>??????: [email-masked]
>[mailto:[email-masked]]
>????>???? 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: [email-masked]
>[mailto:[email-masked]]
>????>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
>????>????> [email-masked]
>????>????> http://www.postel.org/mailman/listinfo/rbridge
>????>????
>????>????
>????>????_______________________________________________
>????>????rbridge mailing list
>????>????[email-masked]
>????>????http://www.postel.org/mailman/listinfo/rbridge
>????>
>????>  
>????>
>????
>  
>
>>-----------------------------------------------------------------------
>>    
>>
>-
>????>
>????>_______________________________________________
>????>rbridge mailing list
>????>[email-masked]
>????>http://www.postel.org/mailman/listinfo/rbridge
>????>  
>????>
>  
>
>------------------------------------------------------------------------
>
>[email-masked]

Content-class: urn:content-classes:message
Date: Sun, 18 Sep 2005 21:27:15 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] ????:  ????:  rbridge for ipv6 ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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: [email-masked] [mailto:[email-masked]] 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
??-----????-----
???: [email-masked] [mailto:[email-masked]]
?? 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
??>??-----????-----
??>???: [email-masked]
[mailto:[email-masked]]
??>?? 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: [email-masked]
[mailto:[email-masked]]
??>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
??>??> _______________________________________________
??>??> 

Date: Mon, 19 Sep 2005 12:03:26 +0800
From: Yiou Deng <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Importance: Normal
Subject: [rbridge] ????:  ????:  rbridge for ipv6 ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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
????-----??????-----
??????: [email-masked] [mailto:[email-masked]]
???? 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
????>????-----??????-----
????>??????: [email-masked]
[mailto:[email-masked]]
????>???? 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: [email-masked]
[mailto:[email-masked]]
????>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
????>????> [email-masked]
????>????> http://www.postel.org/mailman/listinfo/rbridge
????>????
????>????
????>????_______________________________________________
????>????rbridge mailing list
????>????[email-masked]
????>????http://www.postel.org/mailman/listinfo/rbridge
????>
????>  
????>
????
>-----------------------------------------------------------------------
-
????>
????>_______________________________________________
????>rbridge mailing list
????>[email-masked]
????>http://www.postel.org/mailman/listinfo/rbridge
????>  
????>

Date: Wed, 14 Sep 2005 20:14:42 +0530
From: Ganesh CS <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] ????:  rbridge for ipv6 ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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
>????-----??????-----
>??????: [email-masked] [mailto:[email-masked]]
>???? 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: [email-masked] [mailto:[email-masked]]
>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
>????> [email-masked]
>????> http://www.postel.org/mailman/listinfo/rbridge
>????
>????
>????_______________________________________________
>????rbridge mailing list
>????[email-masked]
>????http://www.postel.org/mailman/listinfo/rbridge
>
>  
>
>------------------------------------------------------------------------
>
>[email-masked]

Date: Wed, 14 Sep 2005 13:22:57 +0800
From: Yiou Deng <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Importance: Normal
Subject: [rbridge] ????:  rbridge for ipv6 ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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
????-----??????-----
??????: [email-masked] [mailto:[email-masked]]
???? 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: [email-masked] [mailto:[email-masked]]
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
????> [email-masked]
????> http://www.postel.org/mailman/listinfo/rbridge
????
????
????_______________________________________________
????rbridge mailing list
????[email-masked]
????http://www.postel.org/mailman/listinfo/rbridge

Date: Tue, 13 Sep 2005 14:18:33 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] rbridge for ipv6 ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3218

[email-masked] 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 <[email-masked]>
> 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
[email-masked]

> [email-masked]

Date: Tue, 13 Sep 2005 12:56:58 -0700
From: [email-masked]
To: "Developing a hybrid router/bridge." <[email-masked]>
Priority: normal
Subject: Re: [rbridge] rbridge for ipv6 ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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 <[email-masked]>
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
> iD8DBQFDJwoDE5f5cImnZrsRAuroAKCP0zWimIp+Z8o9wfy3r0JCRo77mACfRA6f
> 8i4sPuCpOuJE7cN33SrQ/cw=
> =L7br
> [email-masked]

Date: Tue, 13 Sep 2005 10:18:59 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] rbridge for ipv6 ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1576

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

Date: Tue, 13 Sep 2005 09:53:51 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] rbridge for ipv6 ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1958

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
> From: [email-masked] [mailto:[email-masked]] 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
>>[email-masked]
> [email-masked]

Date: Tue, 13 Sep 2005 19:49:45 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] rbridge for ipv6 ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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

Date: Wed, 14 Sep 2005 00:35:45 +0800
From: Yang Yang <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Subject: Re: [rbridge] rbridge for ipv6 ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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: [email-masked] [mailto:[email-masked]] 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
> [email-masked]

Date: Tue, 13 Sep 2005 09:00:57 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] rbridge for ipv6 ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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
> [email-masked]

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

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

Date: Tue, 13 Sep 2005 21:06:02 +0530
From: Ganesh CS <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] rbridge for ipv6 ?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 58

Hi all,
Is rbridge for ipv6 under consideration ?

Ganesh

Date: Tue, 13 Sep 2005 15:01:50 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Convergence time
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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
>
>
>
>From: [email-masked] [mailto:[email-masked]] 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
>>
>>
>> 
>>
>>    
>>
>>>From: [email-masked]
>>>[mailto:[email-masked]] 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* <[email-masked]
>>>><mailto:[email-masked]>> 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
>>>>
>>>>
>>>>
>>>>   [email-masked] <mailto:[email-masked]>
>>>>-------------------------------------------------------------
>>>>     
>>>>
>>>>        
>>>>
>>>-----------
>>>   
>>>
>>>      
>>>
>>>>[email-masked] http://www.postel.org/mailman/listinfo/rbridge
>>>>
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>[email-masked] http://www.postel.org/mailman/listinfo/rbridge
>>>
>>>   
>>>
>>>      
>>>
>>[email-masked] http://www.postel.org/mailman/listinfo/rbridge
>>
>> 
>>
>>    
>>
>[email-masked] http://www.postel.org/mailman/listinfo/rbridge
>[email-masked]

Content-class: urn:content-classes:message
Date: Tue, 13 Sep 2005 13:26:07 +0200
From: "Sofia, Rute" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Convergence time
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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: [email-masked] [mailto:[email-masked]] 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
> 
>
>  
>
>>From: [email-masked]
>>[mailto:[email-masked]] 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* <[email-masked]
>>><mailto:[email-masked]>> 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
>>>
>>>
>>>
>>>    [email-masked] <mailto:[email-masked]>
>>>-------------------------------------------------------------
>>>      
>>>
>>-----------
>>    
>>
>>>[email-masked] http://www.postel.org/mailman/listinfo/rbridge
>>> 
>>>
>>>      
>>>
>>[email-masked] http://www.postel.org/mailman/listinfo/rbridge
>>
>>    
>>
>[email-masked] http://www.postel.org/mailman/listinfo/rbridge
>
>  
>
_______________________________________________
rbridge mailing list
[email-masked] http://www.postel.org/mailman/listinfo/rbridge

Date: Tue, 13 Sep 2005 12:54:21 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Convergence time
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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
> 
>
>  
>
>>From: [email-masked] 
>>[mailto:[email-masked]] 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* <[email-masked] 
>>><mailto:[email-masked]>> 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
>>>
>>>
>>>
>>>    [email-masked] <mailto:[email-masked]>
>>>-------------------------------------------------------------
>>>      
>>>
>>-----------
>>    
>>
>>>[email-masked]
>>[email-masked]
>[email-masked]

Content-class: urn:content-classes:message
Date: Tue, 13 Sep 2005 00:21:11 +0200
From: "Sofia, Rute" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Convergence time
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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

> From: [email-masked] 
> [mailto:[email-masked]] 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* <[email-masked] 
> > <mailto:[email-masked]>> 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
> >
> >
> >
> >     [email-masked] <mailto:[email-masked]>
> >-------------------------------------------------------------
> -----------
> >
> >[email-masked]
> [email-masked]

Date: Mon, 12 Sep 2005 23:42:57 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Convergence time
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
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* <[email-masked] 
> <mailto:[email-masked]>> 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
>
>
>
>     [email-masked] <mailto:[email-masked]>
>------------------------------------------------------------------------
>
>[email-masked]

Date: Mon, 12 Sep 2005 14:17:22 -0700
From: Alia Atlas <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Convergence time
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
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 <[email-masked]> 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
> [email-masked]

------=_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:[email-masked]">=
[email-masked]</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=
[email-masked]">[email-masked]</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--