[rbridge] VLAN tags, inner/outer, revisted and summarized

[Radia.Perlman at sun.com (Radia Perlman)]

There's been a lot of discussion, and I believe this is what is going 
on: In this email I will attempt to just
explain, and not advocate. If I want to express opinions, I'll reply to 
this.

The first question we have to ask is what things people are  doing with 
VLANs. The next is to ask
which subset of these (possibly "all") we want to support with TRILL, 
and to answer that we have
to also answer what the cost/benefit of solving each with TRILL is.

Things VLANs can provide:
a) separate endnodes into communities, to enforce that only VLAN A nodes 
can talk to VLAN A nodes
b) scoping things like ARP, so an ARP for a VLAN A node only gets sent 
on VLAN A links
c) security -- making sure that VLAN A nodes cannot snoop on VLAN B traffic
d) provisioning -- making sure that the only traffic on a VLAN A link is 
VLAN A traffic, or
perhaps BGP-policy-like, as in, "this link is willing to carry VLANs A, 
B, and Q, but not D".

Perhaps this is not an exhaustive list, but I hope it's close enough.

What are the costs of providing these things?

The solution that I'd been assuming solves a) and b). That solution is 
summarized as follows:
If RBridges R1 and R2 are on the same link, they are neighbors, and they 
can send transit traffic to each other,
regardless of the VLAN on which it originated. This can be thought of as 
RBridges create a cloud,
which keeps VLAN traffic segregated at the endpoints, but is a single 
shared infrastructure for all
VLANs within the cloud.

That solution does not solve c) and d), though if the transit links are 
all point-to-point links
between RBridges, this is moot. The case that isn't solved is when a 
link is both a transit link
and a shared link with a bunch of endnodes in a VLAN.

Suppose we want to solve those?

What I think people would be asking for is to have the VLAN determine 
not just the destination, but what
path the packet takes. So some links would only allow certain VLAN 
traffic on them, even for transit.
Which would mean multiple forwarding tables, since paths would have to 
be VLAN-dependent.

So, I think the basic strategies are:

a) create as much connectivity as possible between RBridge neighbors. If 
R1,  R2, and R3 are on the same
shared/bridged link, and R1 can only talk to R2 if it puts "VLAN X" into 
the header, and R1 can only
talk to R3 if it puts "VLAN Y" into the header, R1 discovers this case 
by being configured that the
link needs either VLAN X or VLAN Y tags, sends IS-IS Hellos with both, 
and wdiscovers that on the
adjacency to R2, R1 has to stick "VLAN X" and to R3, R1 has to stick 
"VLAN Y". So R1 does whatever
is necessary to talk to its neighbors, but it is only relevant on the 
hop. R1 reports in its link state packet that
it has a neighbor R2, and R3. All RBridges can use the link for transit 
for all VLANs.

b) only allow R1 and R2 to be IS-IS neighbors if they can talk to each 
other with a null VLAN tag. A link
that requires a VLAN tag can only be used as an ingress or egress link 
from the cloud.

c) copy the VLAN tag to the outer header, assume any link that requires 
a particular VLAN tag wants to exclude
transit traffic for all other VLANs, or even for null tags, on the link 
Run separate core instances of IS-IS for
each VLAN tag. Perhaps announcing in the VLAN A instance, all VLAN A 
links, plus links that allow
for null tags.

d) like with c), but allow a link to be configured as "there are VLAN A 
endnodes here, but transit traffic for any VLAN
is fine".

Solutions c) and d) require separate forwarding tables per VLAN, and 
either separate instances of IS-IS, or
a link attribute that lists legal VLAN tags for the link. VLAN A 
segments might become disconnected
because although there is RBridge connectivity, it isn't through links 
that say it's OK to have VLAN A traffic.

Radia




Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kB13aWKA013996 for <[e-mail]>; Thu, 30 Nov 2006 19:36:32 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 30 Nov 2006 19:36:30 -0800 (PST)
Received: from sun.com ([129.150.25.207]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Thu, 30 Nov 2006 19:36:30 -0800 (PST)
Date: Thu, 30 Nov 2006 19:36:30 -0800
From: Radia Perlman <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] VLAN tags, inner/outer, revisted and summarized
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 01 Dec 2006 03:36:55 -0000
Status: RO
Content-Length: 3827

There's been a lot of discussion, and I believe this is what is going 
on: In this email I will attempt to just
explain, and not advocate. If I want to express opinions, I'll reply to 
this.

The first question we have to ask is what things people are  doing with 
VLANs. The next is to ask
which subset of these (possibly "all") we want to support with TRILL, 
and to answer that we have
to also answer what the cost/benefit of solving each with TRILL is.

Things VLANs can provide:
a) separate endnodes into communities, to enforce that only VLAN A nodes 
can talk to VLAN A nodes
b) scoping things like ARP, so an ARP for a VLAN A node only gets sent 
on VLAN A links
c) security -- making sure that VLAN A nodes cannot snoop on VLAN B traffic
d) provisioning -- making sure that the only traffic on a VLAN A link is 
VLAN A traffic, or
perhaps BGP-policy-like, as in, "this link is willing to carry VLANs A, 
B, and Q, but not D".

Perhaps this is not an exhaustive list, but I hope it's close enough.

What are the costs of providing these things?

The solution that I'd been assuming solves a) and b). That solution is 
summarized as follows:
If RBridges R1 and R2 are on the same link, they are neighbors, and they 
can send transit traffic to each other,
regardless of the VLAN on which it originated. This can be thought of as 
RBridges create a cloud,
which keeps VLAN traffic segregated at the endpoints, but is a single 
shared infrastructure for all
VLANs within the cloud.

That solution does not solve c) and d), though if the transit links are 
all point-to-point links
between RBridges, this is moot. The case that isn't solved is when a 
link is both a transit link
and a shared link with a bunch of endnodes in a VLAN.

Suppose we want to solve those?

What I think people would be asking for is to have the VLAN determine 
not just the destination, but what
path the packet takes. So some links would only allow certain VLAN 
traffic on them, even for transit.
Which would mean multiple forwarding tables, since paths would have to 
be VLAN-dependent.

So, I think the basic strategies are:

a) create as much connectivity as possible between RBridge neighbors. If 
R1,  R2, and R3 are on the same
shared/bridged link, and R1 can only talk to R2 if it puts "VLAN X" into 
the header, and R1 can only
talk to R3 if it puts "VLAN Y" into the header, R1 discovers this case 
by being configured that the
link needs either VLAN X or VLAN Y tags, sends IS-IS Hellos with both, 
and wdiscovers that on the
adjacency to R2, R1 has to stick "VLAN X" and to R3, R1 has to stick 
"VLAN Y". So R1 does whatever
is necessary to talk to its neighbors, but it is only relevant on the 
hop. R1 reports in its link state packet that
it has a neighbor R2, and R3. All RBridges can use the link for transit 
for all VLANs.

b) only allow R1 and R2 to be IS-IS neighbors if they can talk to each 
other with a null VLAN tag. A link
that requires a VLAN tag can only be used as an ingress or egress link 
from the cloud.

c) copy the VLAN tag to the outer header, assume any link that requires 
a particular VLAN tag wants to exclude
transit traffic for all other VLANs, or even for null tags, on the link 
Run separate core instances of IS-IS for
each VLAN tag. Perhaps announcing in the VLAN A instance, all VLAN A 
links, plus links that allow
for null tags.

d) like with c), but allow a link to be configured as "there are VLAN A 
endnodes here, but transit traffic for any VLAN
is fine".

Solutions c) and d) require separate forwarding tables per VLAN, and 
either separate instances of IS-IS, or
a link attribute that lists legal VLAN tags for the link. VLAN A 
segments might become disconnected
because although there is RBridge connectivity, it isn't through links 
that say it's OK to have VLAN A traffic.

Radia




Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAU4RBZd009527 for <[e-mail]>; Wed, 29 Nov 2006 20:27:11 -0800 (PST)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 29 Nov 2006 20:27:11 -0800 (PST)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 29 Nov 2006 20:27:11 -0800 (PST)
Received: from [152.70.2.164] (Forwarded-For: [67.160.72.180]) by mail-srv.sfvic.sunlabs.com (mshttpd); Wed, 29 Nov 2006 20:27:10 -0800
Date: Wed, 29 Nov 2006 20:27:10 -0800
From: [e-mail]
To: Eastlake III Donald-LDE008 <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Extensions
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 30 Nov 2006 04:27:23 -0000
Status: RO
Content-Length: 2521

Clearly making the ability to add fields in the future in a compatible way gives flexibility. Having TLV
encoding in IS-IS has proven to be really valuable.

On the other hand, questions  that should be asked are:

a) why not? As in, what is the cost of doing this future flexibility?
b) what kinds of features might we imagine
c) is there any other way of adding features in the future in a compatible way?

I'll make a stab at some of these
a) Why not?
Perhaps complexity of forwarding decision, or perceived complexity of the protocol that might discourage adoption.
If all the fields necessary for current functionality are in the fixed portion of the shim, and RBridges that don't
do the feature can ignore it, then that would not be a problem. But for instance, if they have to look at the inner
header to find the VLAN tag (in order to know whether to filter a multicast), or the inner destination address (for
IP derived multicast -- though maybe it's the layer 3 destination address that matters...not sure), then having
a variable length shim header could be a cost
b) features: LIDs ... any others?
c) not sure

Radia

----- Original Message -----
From: Eastlake III Donald-LDE008 <[e-mail]>
Date: Wednesday, November 29, 2006 7:58 pm
Subject: [rbridge] Extensions

> Hi,
> 
> It is not so much that I think that TRILL needs any particular 
> extensionadded right now, it is just that if there is ever a reason 
> to add an
> extension, it would be good for the extension framework to have been
> decided in advance. The presentation that I didn't have time to 
> make at
> the TRILL WG meeting in San Diego has now been converted from MS Power
> Point and is on the Working Group agendas and presentations web 
> page for
> the 67th IETF meeting in HTML and is also available at
> http://www.pothole.com/~dee3 in PDF.
> 
> Donald
> 
> -----Original Message-----
> From: [e-mail] [[e-mail]] On
> Behalf Of Radia Perlman
> Sent: Monday, November 13, 2006 8:01 PM
> Cc: [e-mail]
> Subject: Re: [rbridge] Should we optimize the common case?
> 
> ......
> 
> Another thing we haven't talked about on the list (and ran out of time
> at the meeting), is Don Eastlake's suggestion of allowing the shim
> header to be variable length, so that we can optionally put in thing
> like LIDs.
> 
> Radia
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id kAU3wWS9002377 for <[e-mail]>; Wed, 29 Nov 2006 19:58:32 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-9.tower-119.messagelabs.com!1164859111!11023574!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.9]
Received: (qmail 9504 invoked from network); 30 Nov 2006 03:58:31 -0000
Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-9.tower-119.messagelabs.com with SMTP; 30 Nov 2006 03:58:31 -0000
Received: from az33exr03.mot.com ([10.64.251.233]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id kAU3wUd0010892 for <[e-mail]>; Wed, 29 Nov 2006 21:58:31 -0600 (CST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id kAU3wTIl014369 for <[e-mail]>; Wed, 29 Nov 2006 21:58:30 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 29 Nov 2006 22:58:25 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Extensions
Thread-Index: AccHiPvwev8MSSM7SGGEAejTg6GctgEoztOA
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAU3wWS9002377
Subject: [rbridge] Extensions
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 30 Nov 2006 03:58:41 -0000
Status: RO
Content-Length: 1013

Hi,

It is not so much that I think that TRILL needs any particular extension
added right now, it is just that if there is ever a reason to add an
extension, it would be good for the extension framework to have been
decided in advance. The presentation that I didn't have time to make at
the TRILL WG meeting in San Diego has now been converted from MS Power
Point and is on the Working Group agendas and presentations web page for
the 67th IETF meeting in HTML and is also available at
http://www.pothole.com/~dee3 in PDF.

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Monday, November 13, 2006 8:01 PM
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?

......

Another thing we haven't talked about on the list (and ran out of time
at the meeting), is Don Eastlake's suggestion of allowing the shim
header to be variable length, so that we can optionally put in thing
like LIDs.

Radia



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAU3Kphe022291 for <[e-mail]>; Wed, 29 Nov 2006 19:20:51 -0800 (PST)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 29 Nov 2006 19:20:45 -0800 (PST)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 29 Nov 2006 19:20:45 -0800 (PST)
Received: from [152.70.2.164] (Forwarded-For: [67.160.72.180]) by mail-srv.sfvic.sunlabs.com (mshttpd); Wed, 29 Nov 2006 19:20:45 -0800
Date: Wed, 29 Nov 2006 19:20:45 -0800
From: [e-mail]
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Terminology issues -- advice?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 30 Nov 2006 03:21:08 -0000
Status: RO
Content-Length: 1118

(I'm editing the protocol document, which is why these things are coming up).

I notice that in the architecture document, the term "campus" is not used, although it was always
part of the protocol document. Instead there is the term "CRED". I suggest going back to "campus", because
that's a word that people can understand, whereas "CRED" is yet another acronym, which makes things
harder to understand. I thought originally that CRED was supposed to be the campus minus the endnodes,
and didn't quite understand why it was necessary to have a separate word for it. But if the architecture
document doesn't think there needs to be two terms ("campus" for CRED plus endnodes), then I think
we should just use "campus". Again, because people will intuitively understand the word since it is an English word.

A second issue is with the term "ingress RBridge tree". Now that we allow the ingress RBridge to select a distribution
tree, it's not really right to use the term "ingress RBridge tree", since it is really the "chosen tree". Not sure
what a better term would be. Perhaps "distribution tree".

Thanks,

Radia



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id kAU3KA8x022032 for <[e-mail]>; Wed, 29 Nov 2006 19:20:10 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-2.tower-119.messagelabs.com!1164856808!9877769!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [144.189.100.102]
Received: (qmail 12334 invoked from network); 30 Nov 2006 03:20:08 -0000
Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-2.tower-119.messagelabs.com with SMTP; 30 Nov 2006 03:20:08 -0000
Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id kAU3K4vR001576 for <[e-mail]>; Wed, 29 Nov 2006 20:20:08 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id kAU3K3ZZ024512 for <[e-mail]>; Wed, 29 Nov 2006 21:20:03 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 29 Nov 2006 22:20:01 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] The "wiring closet" problem
Thread-Index: AccUIfYQfpgtQqT4TPu4ljYyJGbsOQAAMDEg
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAU3KA8x022032
Subject: Re: [rbridge] The "wiring closet" problem
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 30 Nov 2006 03:20:26 -0000
Status: RO
Content-Length: 3852

Hi,

Although the second example you give could be a problem, I'm not sure
with today's typical star configurations it would occur much.

What I have heard referred to as the wiring closet problem is your first
case. Typically described as B1 and B2 being in the closet, so they are
very close and high bandwidth communication between them is fairly easy,
while the B1-R1 and B2-R2 links are longer distance, higher cost, and
lower bandwidth, so you want to be sure to use them both if they are
both up to get the maximum bandwidth from the E* to the campus. The
scenario considered is usually the failure of the longer communications
links, rather than an Rbridge, although they are operationally pretty
similar.

Donald

PS: Of course, things work if you replace B1 and B2 with Rbridges but
that does not allow incremental deployment.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]
Sent: Wednesday, November 29, 2006 8:32 PM
To: [e-mail]
Subject: [rbridge] The "wiriding closet" problem

I've had a couple of people explain what the "wiring closet" issue is,
and I have two potential pictures for it.
I think there's a reasonable solution for either picture, but it would
be good if someone could define what the problem is.

I will make an attempt, and that way you can correct me rather than
trying to explain it from scratch, if that's easier.

The problem is to have a bunch of end nodes attached to the campus via
multiple RBridges (for redundancy as well as load splitting). So let's
simplify it to two: R1 and R2 are attached to the campus, and to a bunch
of end nodes.

           campus

         |         |
         R1        R2
          |         |
          B1 ------ B2
          |          |
    --------       ---------
     E1 E2           E3 E4

Without thinking about this at all, the default would be that one of R1
or R2 would become DR, and the other would not forward traffic to or
from the campus. That means that if R1 was selected DR, traffic from E3
would have to go via R1.

So the desire is to have the spanning tree break the B1-B2 link in the
case where both R1 and R2 are up, but have that link available in case
either R1 or R2 fails.

This can be accomplished by configuring R1 and R2 to pretend they are
one hop away from a fictitious Root spanning tree bridge inside the
campus.

*********
Another potential configuration I've heard of as the "wiring closet
problem" is to do away with the bridges, and have this topology:

           campus

       |         |      |
       R1        R2     R3
        |         |      |
 ----------------------------
      |  |     |     |
      E1 E2    E3    E4

Again, the desire is to load split between R1,  R2, and R3, as long as
they are both up.

This can be accomplished by configuring the RBridge which is DR to
assign end nodes to other RBridges on the link. R1 knows, based on the
IS-IS router hellos, that R2 and R3 are also RBridges on the link, and
that R1 is DR. R1 could assign blocks of MAC addresses (I'd guess based
on a mask) to each of the other RBridges. If, for instance, it tells R2
to be in charge of odd MAC addresses, then only R2 learns the location
of odd-numbered MAC addresses on the link, announces those in R2's link
state information, and only R2 forwards packets from odd-MAC addresses
off the link, and decapsulates traffic for odd-MAC addresses onto the
link. In essence it winds up looking like n different disconnected LANs,
one that happens to have odd MAC addresses, the others whatever
partitioning R1 assigns.

Are there any other cases? Are these solutions to these cases OK with
people?

Radia


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



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAU1VqPA018822 for <[e-mail]>; Wed, 29 Nov 2006 17:31:53 -0800 (PST)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 29 Nov 2006 17:31:48 -0800 (PST)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 29 Nov 2006 17:31:48 -0800 (PST)
Received: from [152.70.2.164] (Forwarded-For: [67.160.72.180]) by mail-srv.sfvic.sunlabs.com (mshttpd); Wed, 29 Nov 2006 17:31:48 -0800
Date: Wed, 29 Nov 2006 17:31:48 -0800
From: [e-mail]
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] The "wiriding closet" problem
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 30 Nov 2006 01:34:28 -0000
Status: RO
Content-Length: 2790

I've had a couple of people explain what the "wiring closet" issue is, and I have two potential pictures for it.
I think there's a reasonable solution for either picture, but it would be good if someone could define what the
problem is.

I will make an attempt, and that way you can correct me rather than trying to explain it from scratch, if that's easier.

The problem is to have a bunch of endnodes attached to the campus via multiple RBridges (for redundancy
as well as load splitting). So let's simplify it to two: R1 and R2 are attached to the campus, and to a bunch of
endnodes.

                  campus

                  |            |
                R1        R2
                  |            |
                B1 ------ B2
                |                 |
           --------           ---------
             E1 E2           E3 E4

Without thinking about this at all, the default would be that one of R1 or R2 would become DR, and the other
would not forward traffic to or from the campus. That means that if R1 was selected DR, traffic from E3 would
have to go via R1.

So the desire is to have the spanning tree break the B1-B2 link in the case where both R1 and R2 are up,
but have that link available in case either R1 or R2 fails.

This can be accomplished by configuring R1 and R2 to pretend they are one hop away from a fictitious Root spanning
tree bridge inside the campus.

*********
Another potential configuration I've heard of as the "wiring closet problem" is to do away with the bridges, and have
this topology:

                  campus

                  |            |         |
                R1        R2     R3
                  |            |        |
           ----------------------------
                   |    |        |         |
                 E1 E2    E3    E4

Again, the desire is to load split between R1,  R2, and R3, as long as they are both up.

This can be accomplished by configuring the RBridge which is DR to assign endnodes to other RBridges
on the link. R1 knows, based on the IS-IS router hellos, that R2 and R3 are also RBridges on the link, and
that R1 is DR. R1 could assign blocks of MAC addresses (I'd guess based on a mask) to each
of the other RBridges. If, for instance, it tells R2 to be in charge of odd MAC addresses, then only R2 learns
the location of odd-numbered MAC addresses on the link, announces those in R2's link state information, and
only R2 forwards packets from odd-MAC addresses off the link, and decapsulates traffic for odd-MAC addresses
onto the link. In essence it winds up looking like n different disconnected LANs, one that happens to have
odd MAC addresses, the others whatever partitioning R1 assigns.

Are there any other cases? Are these solutions to these cases OK with people?

Radia




Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id kALJCngx006544 for <[e-mail]>; Tue, 21 Nov 2006 11:12:50 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-3.tower-128.messagelabs.com!1164135907!4083976!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 26937 invoked from network); 21 Nov 2006 19:05:07 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-128.messagelabs.com with SMTP; 21 Nov 2006 19:05:07 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id kALJ57UZ024072 for <[e-mail]>; Tue, 21 Nov 2006 12:05:07 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id kALJ57n9008054 for <[e-mail]>; Tue, 21 Nov 2006 13:05:07 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 21 Nov 2006 14:05:05 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Working Group Last Call on Problem and Applicability Statement and Routing Requirements, Expert Review of Architecture Draft
Thread-Index: AccB+xTio6hMLcfpSUag0KjDShKbhgKHcZsA
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kALJCngx006544
Subject: Re: [rbridge] Working Group Last Call on Problem and Applicability Statement and Routing Requirements, Expert Review of Architecture Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2006 19:13:09 -0000
Status: RO
Content-Length: 3292

Hi,

We are concluding the working group last calls on the Routing
Requirements draft and the Problem and Applicability Statement draft.

draft-ietf-trill-routing-reqs-00.txt has working group rough consensus.
The comments in
http://www.postel.org/pipermail/rbridge/2006-November/001659.html should
be generally incorporated. With regard to BPDUs, the document should say
that they may be processed at Rbridge interfaces but do not transit the
Rbridge. It is fine to also say that Rbridges terminate bridging
spanning trees. When a revised version of the draft is produced, we
expect to forward it to our AD with a request that it be published as an
Informational RFC.

draft-ietf-trill-prob-01.txt does not have working group consensus but
the last call has produced a number of useful comments. These and future
comments should be incorporated and at some future point we plan to have
another working group last call on a subsequent version of the draft.

Thanks,
Donald and Erik


Eastlake III Donald-LDE008 wrote:
> Hi,
> 
> TRILL now has three drafts which have been discussed within the TRILL 
> working group, improved based on mailing list comments, and about 
> which there does not seem to be a current serious controversy (in some

> cases these draft went through multiple versions as personal drafts 
> before being adopted as working group drafts):
> 
> 1	Transparent Interconnection of Lots of Links (TRILL): Problem
> and Applicability Statement 
> 	draft-ietf-trill-prob-01.txt
> 
> 2	The Architecture of an RBridge Solution to TRILL 
> 	draft-ietf-trill-rbridge-arch-01.txt
> 
> 3	TRILL Routing Requirements in Support of RBridges
> 	draft-ietf-trill-routing-reqs-00.txt
> 
> We have decided to initiate a two week working group last call on the 
> first and third of these: the Problem and Applicability Statement 
> draft and the Routing Requirements draft. This will run through 
> Wednesday, 8 November. Please post any further comments on these 
> drafts to the mailing list, preferably in a separate message for each
draft.
> 
> We also plan to allocate some time for comments on these two drafts at

> the TRILL WG meeting in San Diego which is during the last call
period.
> Based on the feedback we get, we expect to decided for each of these 
> two drafts whether to forward it to the IESG as is, forward it with 
> minor changes, or continue to work on it within the working group.
> 
> Our charter requires that the second draft above, the Architecture 
> draft, be subject to IEEE/IETF expert review. It seems reasonable to 
> do this review before working group last call. Accordingly, we are 
> arranging such review. If you would like to suggest an expert to 
> review the Architecture draft, preferably someone who has not been 
> heavily involved with TRILL thus far, please contact us directly. We 
> also plan to allocate some time at the San Diego meeting for comments 
> on the Architecture draft.
> 
> Thanks,
> Donald and Erik
> 
> [e-mail], [e-mail]
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> From - Fri

--
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment




Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kALIIoJL018590 for <[e-mail]>; Tue, 21 Nov 2006 10:18:55 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kALIIlfK009467; Tue, 21 Nov 2006 13:18:47 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA15793;  Tue, 21 Nov 2006 13:18:46 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <XFT03134>; Tue, 21 Nov 2006 13:18:46 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>, Radia Perlman <[e-mail]>
Date: Tue, 21 Nov 2006 13:18:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Summary of IVLANs vs OVLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2006 18:19:09 -0000
Status: RO
Content-Length: 12387

Silvano,

	With the qualification that "under a single management" means
that - if VLAN tagging is required for fractional LAN traversal - 
then VLAN tags will be assigned consistently, then I understand your
position.  That is not to say that I agree with it.

	A question for clarification: assuming a real world deployment
(in an enterprise environment) where VLANs are used both to protect
and segregate traffic, how does Radia's proposal prevent potential
"leakage" from one (end-station) VLAN to another?

	When I first read Radia's proposal, I thought (for one minute)
that she was arguing for this as a "logical model" - where practical
implementations might actually be more clever/efficient.  It might
have been reasonable to assume that the intervention of a router is
going to bound the RBridge domain (as it does a broadcast domain).

	However this does not prevent the discovery of an RBridge - as
an IS-IS (L2-specific) peer, even if the same physical RBridge is a
part of multiple VLANs.  Consequently, that logical model necessitates 
creation of separate IS-IS instances on a per-VLAN basis in RBridges
that span multiple VLANs, further resulting in over-lapping RBridge
"CREDs" and potentially forcing each (physical) RBridge to be able to
participate in each CRED.  Note that this effectively forces RBridge
implementations to support per-VLAN trees explicitly (as opposed to
implicitly as originally suggested in previous discussions involving
IRTs and VLAN optimization).

	As a second question for clarification: are we prepared to both
mandate RBridges MUST support IS-IS instancing per-VLAN and that they
MUST also be capable of participation in multiple CREDs including the
formation of per-VLAN p2mp trees?

	Also, even though there is a "hard limit" of 4k VLANs in both
the end-station and RBridge domains, that does not mean I want to be
REQUIRED to configure up to 4k VLANs in my core switches.

--
Eric

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Tuesday, November 21, 2006 12:51 PM
> To: Gray, Eric; Radia Perlman
> Cc: Russ White; [e-mail]
> Subject: RE: Summary of IVLANs vs OVLANs
> 
> 
> Eric,
> 
> I see only two possible uses for the OVLAN:
> 
> 1) The one that Radia proposes, that I think is appropriate for an
> Enterprise environment, where the TRILL network is under a single
> management;
> 
> 2) The one proposed in metro Ethernet in which the OVLAN (there called
> S-VLAN) identifies a particular customer and the IVLAN contains the
> customer VLAN. I know Ali Sajassi is in favor of this model.
> 
> I don't see any advantage of deriving the OVLAN from an "N:1 mapping
> from the inner VLAN tag": 
> - It does not increase scalability, since the overall number of VLANs
> will remain 4K;
> - It adds complexity and the need for a protocol to keep the 
> mapping in
> synch among different Rbridges;
> - It does not increase segregation, since segregation and pruning is
> anyhow performed on the IVLAN;
> - It requires unnecessary inner header lookup.
> 
> For these reasons my consensus is with Radia proposal.
> 
> -- Silvano
> 
> ----------------------------------------------------------------
> 
> 
> > -----Original Message-----
> > From: Gray, Eric [mailto:[e-mail]]
> > Sent: Tuesday, November 21, 2006 8:11 AM
> > To: Radia Perlman
> > Cc: Silvano Gai; Russ White; [e-mail]
> > Subject: RE: Summary of IVLANs vs OVLANs
> > 
> > Radia,
> > 
> > 	I think that this may be a summary of your perspective on the
> > use of VLANs, but I do not believe that this perspective has been
> > discussed generally.  Nor do I believe that it has been agreed to
> > by any sort of "rough consensus" subset within the working group.
> > 
> > 	However, I may be wrong, so I would like to suggest that we
> > (as a working group) discuss the "summary" you have provided.  If
> > I am wrong, then I suggest the members of that "subset" may need
> > to re-think their position.
> > 
> > 	I am reasonably sure that many people would like to use VLAN
> > tags in the RBridge domain as a means to form reasonable aggregates
> > of the VLANs among end-stations.  In this sense, the outer VLAN tag
> > is derived simply as an N:1 mapping from the inner VLAN tag - and,
> > as a result of this is, there will be a dependence on the inner tag
> > in how forwarding occurs between RBridges.
> > 
> > 	This approach helps scalability in two ways: one, it allows
> > for reduced VLAN configuration among RBridges to support a larger
> > quantity of end-station VLANs; two, it allows some subset of the
> > RBridge topology to avoid deriving and storing forwarding entries
> > for traffic they should not need to forward.
> > 
> > 	Arguably the latter scalability concern is eliminated by the
> > use of per-ingress p2mp forwarding trees.  However, it has been
> > suggested that we might not do that - hence it is important to bear
> > this in mind.  One potential use of VLANs between RBridges is to
> > allow for sub-setting of spanning trees (assuming we decide to use
> > spanning trees between RBridges) using the existing techniques we
> > already have defined in 802.1D (2004) - i.e. - MSTP.
> > 
> > 	It is even possible that some people may be thinking of using
> > VLAN tags in other ways.  If so, I would like to hear their ideas.
> > For one thing, it is clear that we MUST decide on some set of uses
> > that are compatible, and it is clear that the use outlined in your
> > summary is fundamentally incompatible with the use I (and, I assume,
> > other people) have assumed.  It is also incompatible with standard
> > usage as defined in 802.1Q, and new proposals currently in process
> > in the IEEE.
> > 
> > 	As a more-or-less philosophical clarification, it does not
> > make sense to configure VLANs in RBridges to accommodate the VLAN
> > tags used by the intervening fractional-LANs (what we have been
> > calling "LAN segments") between two RBridges.  VLAN tags SHOULD be
> > used to accommodate connectivity among RBridges across the under-
> > lying fractional LANs (just as they are to accommodate connectivity
> > among end-stations) - and not the other way around.
> > 
> > 	From the perspective of existing 802.1D bridges, RBridges are
> > end-stations.  You decide which end-stations require connectivity,
> > you assign them to the same VLAN, and then you configure the VLAN
> > information in the VLAN bridges.
> > 
> > 	Also, the idea of potentially "switching" from one VLAN tag
> > to another across and RBridge to accommodate a presumed under-lying
> > VLAN tagging arrangement seems broken.  We would need to consider a
> > lot of potential corner-cases - particularly during deployment and
> > re-configuration - to determine if this will even work.  For one
> > thing, there are interesting problems that arise as a result of not
> > consistently using the same VLAN tags within a single administrative
> > domain.
> > 
> > 	I assume we have not yet decided to tackle the "multi-domain"
> > problem in TRILL, given that it is supposed to be a LAN-oriented,
> > plug-and-play capable, enterprise solution...
> > 
> > --
> > Eric
> > 
> > > -----Original Message-----
> > > From: Radia Perlman [mailto:[e-mail]]
> > > Sent: Monday, November 20, 2006 8:36 PM
> > > To: Gray, Eric
> > > Cc: 'Silvano Gai'; Russ White; [e-mail]
> > > Subject: Summary of IVLANs vs OVLANs
> > >
> > > I don't think there is an issue here, but let me hopefully
> > > clarify the
> > > purpose of a VLAN tag on the inner frame
> > > vs a VLAN tag which might appear on the outer header.
> > >
> > > **********
> > > First: Purpose of "inner" VLAN tag
> > > ___________________________
> > >
> > >
> > > The purpose of the inner tag is to provide separation for endnode
> > > communities. In other words, VLAN A
> > > endnodes can only talk to VLAN A endnodes. The VLAN tag is either
> > > inserted by the original endnode,
> > > or the first bridge or RBridge that receives the frame. What
> > > tag to put
> > > in, whether to strip it, is configured
> > > into RBridges exactly as it would be with bridges.
> > >
> > > The inner VLAN tag is irrelevant for how the frame is
> > > forwarded between
> > > the RBridges.
> > >
> > > RBridges are willing to forward all frames, regardless of the
> > > inner VLAN
> > > tag. They forward towards the
> > > egress RBridge, totally ignoring the inner VLAN tag on
> > > unicast packets.
> > > On multicast, however, they
> > > will look at the VLAN tag on the inner frame to decide if they
> should
> > > filter on some outgoing ports
> > > for the selected multicast tree, because there are no
> > > downstream links
> > > for that VLAN tag.
> > >
> > > *******************
> > > Now for the outer VLAN tag
> > >
> > > Basically, the outer header is only a hop-by-hop header, and is of
> no
> > > significance other than
> > > to be able to communicate between RBridge neighbors. If it's
> > > necessary
> > > (because of configuration of
> > > bridges between two RBridges) to stick VLAN tags into the
> > > outer header,
> > > that's what the RBridges do.
> > >
> > > So: figuring out your RBridge neighbors:
> > >
> > > RBridges figure out who their RBridge neighbors are, through
> > > the IS-IS
> > > Hello protocol. VLANs make this
> > > a bit awkward, but still straightforward. Which VLAN tags 
> exist on a
> > > link is configured into the RBridges, just
> > > like it would be configured into a bridge.
> > >
> > > So...RBridge RB1 has been configured to know that on port a,
> > > packets are
> > > allowed to have, say,
> > > VLAN tags A, C, and none.
> > >
> > > So...RB1 has to figure out what RBridge neighbors it has. It
> > > does this
> > > by sending IS-IS Hellos three times
> > > on that port, tagged respectively with A, C, and none.
> > >
> > > It might form different adjacencies depending on which 
> VLAN tag the
> > > IS-IS Hello was sent with.
> > > Let's say that with VLAN tag A, it forms an adjacency with
> > > RB2, and with
> > > VLAN tag C and no VLAN tag,
> > > it forms an adjacency with RB3.
> > >
> > > Therefore, in the core instance of IS-IS, RB1 announces that
> > > it has two
> > > RBridge neighbors (maybe others on
> > > other ports as well); RB2 and RB3. It doesn't matter to any other
> > > RBridges what VLAN tags RB1 needs
> > > to stick into the outer header in order to communicate on the
> > > adjacency.
> > >
> > > Whenever RB1 sends anything (forwarded data packets, IS-IS Hellos)
> to
> > > adjacency RB2, it sticks VLAN A
> > > tag into the outer header.
> > >
> > > Whenever RB1 sends anything to adjacency RB3, it has a choice. It
> can
> > > put a VLAN C tag into the outer header,
> > > or no VLAN tag. It doesn't matter which it chooses.  I'd
> > > choose no VLAN
> > > tag, just to save a few bytes.
> > > But there might be a case where any of a set of VLAN tags would
> work,
> > > and no VLAN tag wouldn't work,
> > > in which case, again, it doesn't matter which one it chooses.
> > >
> > > ************************
> > > So, now let's look at the example being discussed in this thread:
> > >
> > >                  +-----+  1,2  +-----------+
> > >                  | RB1 |-------| Rtg Fnctn |
> > >                  +-----+       +-----------+
> > >                     |
> > >                     | 1,2
> > >                     |
> > >   +-----+   1    +-----+    2     +-----+
> > >   | RB2 |--------| SW1 |----------| RB3 |
> > >   +-----+        +-----+          +-----+
> > >      |                               |
> > >      | IVLAN=3                       | IVLAN=3
> > >   +-----+                         +-----+
> > >   |  H1 |                         |  H2 |
> > >   +-----+                         +-----+
> > >
> > >
> > > In this example, RB2 will wind up with an adjency to RB1, and have
> to
> > > stick VLAN 1 into the outer
> > > header in order to talk to RB1. RB2 will not form an
> > > adjacency with RB3.
> > >
> > > RB2, on the other other, will form two adjacencies on that
> > > port; one to
> > > RB2 (using VLAN 1), and
> > > one to RB3 (using VLAN 2).
> > >
> > > The IS-IS topology will looks like:
> > >
> > > H1----RB2---RB1----RB3---H2
> > >
> > > So the path from H1 to H2 will go through RB2, then RB1, then RB3.
> > >
> > > Hope this clarifies.
> > >
> > > Radia
> > >
> > >
> > >
> > >
> > >
> 


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kALHp2Ar009843 for <[e-mail]>; Tue, 21 Nov 2006 09:51:02 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Tue, 21 Nov 2006 09:50:56 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Summary of IVLANs vs OVLANs
Thread-Index: AccNh7SgUbAnVKI3S7mrj8nZIr8M8gACeK7g
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kALHp2Ar009843
Cc: [e-mail]
Subject: Re: [rbridge] Summary of IVLANs vs OVLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2006 17:51:18 -0000
Status: RO
Content-Length: 9685

Eric,

I see only two possible uses for the OVLAN:

1) The one that Radia proposes, that I think is appropriate for an
Enterprise environment, where the TRILL network is under a single
management;

2) The one proposed in metro Ethernet in which the OVLAN (there called
S-VLAN) identifies a particular customer and the IVLAN contains the
customer VLAN. I know Ali Sajassi is in favor of this model.

I don't see any advantage of deriving the OVLAN from an "N:1 mapping
from the inner VLAN tag": 
- It does not increase scalability, since the overall number of VLANs
will remain 4K;
- It adds complexity and the need for a protocol to keep the mapping in
synch among different Rbridges;
- It does not increase segregation, since segregation and pruning is
anyhow performed on the IVLAN;
- It requires unnecessary inner header lookup.

For these reasons my consensus is with Radia proposal.

-- Silvano

----------------------------------------------------------------


> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Tuesday, November 21, 2006 8:11 AM
> To: Radia Perlman
> Cc: Silvano Gai; Russ White; [e-mail]
> Subject: RE: Summary of IVLANs vs OVLANs
> 
> Radia,
> 
> 	I think that this may be a summary of your perspective on the
> use of VLANs, but I do not believe that this perspective has been
> discussed generally.  Nor do I believe that it has been agreed to
> by any sort of "rough consensus" subset within the working group.
> 
> 	However, I may be wrong, so I would like to suggest that we
> (as a working group) discuss the "summary" you have provided.  If
> I am wrong, then I suggest the members of that "subset" may need
> to re-think their position.
> 
> 	I am reasonably sure that many people would like to use VLAN
> tags in the RBridge domain as a means to form reasonable aggregates
> of the VLANs among end-stations.  In this sense, the outer VLAN tag
> is derived simply as an N:1 mapping from the inner VLAN tag - and,
> as a result of this is, there will be a dependence on the inner tag
> in how forwarding occurs between RBridges.
> 
> 	This approach helps scalability in two ways: one, it allows
> for reduced VLAN configuration among RBridges to support a larger
> quantity of end-station VLANs; two, it allows some subset of the
> RBridge topology to avoid deriving and storing forwarding entries
> for traffic they should not need to forward.
> 
> 	Arguably the latter scalability concern is eliminated by the
> use of per-ingress p2mp forwarding trees.  However, it has been
> suggested that we might not do that - hence it is important to bear
> this in mind.  One potential use of VLANs between RBridges is to
> allow for sub-setting of spanning trees (assuming we decide to use
> spanning trees between RBridges) using the existing techniques we
> already have defined in 802.1D (2004) - i.e. - MSTP.
> 
> 	It is even possible that some people may be thinking of using
> VLAN tags in other ways.  If so, I would like to hear their ideas.
> For one thing, it is clear that we MUST decide on some set of uses
> that are compatible, and it is clear that the use outlined in your
> summary is fundamentally incompatible with the use I (and, I assume,
> other people) have assumed.  It is also incompatible with standard
> usage as defined in 802.1Q, and new proposals currently in process
> in the IEEE.
> 
> 	As a more-or-less philosophical clarification, it does not
> make sense to configure VLANs in RBridges to accommodate the VLAN
> tags used by the intervening fractional-LANs (what we have been
> calling "LAN segments") between two RBridges.  VLAN tags SHOULD be
> used to accommodate connectivity among RBridges across the under-
> lying fractional LANs (just as they are to accommodate connectivity
> among end-stations) - and not the other way around.
> 
> 	From the perspective of existing 802.1D bridges, RBridges are
> end-stations.  You decide which end-stations require connectivity,
> you assign them to the same VLAN, and then you configure the VLAN
> information in the VLAN bridges.
> 
> 	Also, the idea of potentially "switching" from one VLAN tag
> to another across and RBridge to accommodate a presumed under-lying
> VLAN tagging arrangement seems broken.  We would need to consider a
> lot of potential corner-cases - particularly during deployment and
> re-configuration - to determine if this will even work.  For one
> thing, there are interesting problems that arise as a result of not
> consistently using the same VLAN tags within a single administrative
> domain.
> 
> 	I assume we have not yet decided to tackle the "multi-domain"
> problem in TRILL, given that it is supposed to be a LAN-oriented,
> plug-and-play capable, enterprise solution...
> 
> --
> Eric
> 
> > -----Original Message-----
> > From: Radia Perlman [mailto:[e-mail]]
> > Sent: Monday, November 20, 2006 8:36 PM
> > To: Gray, Eric
> > Cc: 'Silvano Gai'; Russ White; [e-mail]
> > Subject: Summary of IVLANs vs OVLANs
> >
> > I don't think there is an issue here, but let me hopefully
> > clarify the
> > purpose of a VLAN tag on the inner frame
> > vs a VLAN tag which might appear on the outer header.
> >
> > **********
> > First: Purpose of "inner" VLAN tag
> > ___________________________
> >
> >
> > The purpose of the inner tag is to provide separation for endnode
> > communities. In other words, VLAN A
> > endnodes can only talk to VLAN A endnodes. The VLAN tag is either
> > inserted by the original endnode,
> > or the first bridge or RBridge that receives the frame. What
> > tag to put
> > in, whether to strip it, is configured
> > into RBridges exactly as it would be with bridges.
> >
> > The inner VLAN tag is irrelevant for how the frame is
> > forwarded between
> > the RBridges.
> >
> > RBridges are willing to forward all frames, regardless of the
> > inner VLAN
> > tag. They forward towards the
> > egress RBridge, totally ignoring the inner VLAN tag on
> > unicast packets.
> > On multicast, however, they
> > will look at the VLAN tag on the inner frame to decide if they
should
> > filter on some outgoing ports
> > for the selected multicast tree, because there are no
> > downstream links
> > for that VLAN tag.
> >
> > *******************
> > Now for the outer VLAN tag
> >
> > Basically, the outer header is only a hop-by-hop header, and is of
no
> > significance other than
> > to be able to communicate between RBridge neighbors. If it's
> > necessary
> > (because of configuration of
> > bridges between two RBridges) to stick VLAN tags into the
> > outer header,
> > that's what the RBridges do.
> >
> > So: figuring out your RBridge neighbors:
> >
> > RBridges figure out who their RBridge neighbors are, through
> > the IS-IS
> > Hello protocol. VLANs make this
> > a bit awkward, but still straightforward. Which VLAN tags exist on a
> > link is configured into the RBridges, just
> > like it would be configured into a bridge.
> >
> > So...RBridge RB1 has been configured to know that on port a,
> > packets are
> > allowed to have, say,
> > VLAN tags A, C, and none.
> >
> > So...RB1 has to figure out what RBridge neighbors it has. It
> > does this
> > by sending IS-IS Hellos three times
> > on that port, tagged respectively with A, C, and none.
> >
> > It might form different adjacencies depending on which VLAN tag the
> > IS-IS Hello was sent with.
> > Let's say that with VLAN tag A, it forms an adjacency with
> > RB2, and with
> > VLAN tag C and no VLAN tag,
> > it forms an adjacency with RB3.
> >
> > Therefore, in the core instance of IS-IS, RB1 announces that
> > it has two
> > RBridge neighbors (maybe others on
> > other ports as well); RB2 and RB3. It doesn't matter to any other
> > RBridges what VLAN tags RB1 needs
> > to stick into the outer header in order to communicate on the
> > adjacency.
> >
> > Whenever RB1 sends anything (forwarded data packets, IS-IS Hellos)
to
> > adjacency RB2, it sticks VLAN A
> > tag into the outer header.
> >
> > Whenever RB1 sends anything to adjacency RB3, it has a choice. It
can
> > put a VLAN C tag into the outer header,
> > or no VLAN tag. It doesn't matter which it chooses.  I'd
> > choose no VLAN
> > tag, just to save a few bytes.
> > But there might be a case where any of a set of VLAN tags would
work,
> > and no VLAN tag wouldn't work,
> > in which case, again, it doesn't matter which one it chooses.
> >
> > ************************
> > So, now let's look at the example being discussed in this thread:
> >
> >                  +-----+  1,2  +-----------+
> >                  | RB1 |-------| Rtg Fnctn |
> >                  +-----+       +-----------+
> >                     |
> >                     | 1,2
> >                     |
> >   +-----+   1    +-----+    2     +-----+
> >   | RB2 |--------| SW1 |----------| RB3 |
> >   +-----+        +-----+          +-----+
> >      |                               |
> >      | IVLAN=3                       | IVLAN=3
> >   +-----+                         +-----+
> >   |  H1 |                         |  H2 |
> >   +-----+                         +-----+
> >
> >
> > In this example, RB2 will wind up with an adjency to RB1, and have
to
> > stick VLAN 1 into the outer
> > header in order to talk to RB1. RB2 will not form an
> > adjacency with RB3.
> >
> > RB2, on the other other, will form two adjacencies on that
> > port; one to
> > RB2 (using VLAN 1), and
> > one to RB3 (using VLAN 2).
> >
> > The IS-IS topology will looks like:
> >
> > H1----RB2---RB1----RB3---H2
> >
> > So the path from H1 to H2 will go through RB2, then RB1, then RB3.
> >
> > Hope this clarifies.
> >
> > Radia
> >
> >
> >
> >
> >



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kALGBUEv007378 for <[e-mail]>; Tue, 21 Nov 2006 08:11:42 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kALGBRfK007071; Tue, 21 Nov 2006 11:11:27 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA07363;  Tue, 21 Nov 2006 11:11:26 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <XFT03CCK>; Tue, 21 Nov 2006 11:11:26 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Radia Perlman <[e-mail]>
Date: Tue, 21 Nov 2006 11:11:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Summary of IVLANs vs OVLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2006 16:12:01 -0000
Status: RO
Content-Length: 8130

Radia,

	I think that this may be a summary of your perspective on the
use of VLANs, but I do not believe that this perspective has been
discussed generally.  Nor do I believe that it has been agreed to
by any sort of "rough consensus" subset within the working group.

	However, I may be wrong, so I would like to suggest that we
(as a working group) discuss the "summary" you have provided.  If
I am wrong, then I suggest the members of that "subset" may need
to re-think their position.

	I am reasonably sure that many people would like to use VLAN
tags in the RBridge domain as a means to form reasonable aggregates
of the VLANs among end-stations.  In this sense, the outer VLAN tag
is derived simply as an N:1 mapping from the inner VLAN tag - and, 
as a result of this is, there will be a dependence on the inner tag 
in how forwarding occurs between RBridges.

	This approach helps scalability in two ways: one, it allows 
for reduced VLAN configuration among RBridges to support a larger
quantity of end-station VLANs; two, it allows some subset of the
RBridge topology to avoid deriving and storing forwarding entries 
for traffic they should not need to forward.

	Arguably the latter scalability concern is eliminated by the
use of per-ingress p2mp forwarding trees.  However, it has been 
suggested that we might not do that - hence it is important to bear
this in mind.  One potential use of VLANs between RBridges is to
allow for sub-setting of spanning trees (assuming we decide to use
spanning trees between RBridges) using the existing techniques we
already have defined in 802.1D (2004) - i.e. - MSTP.

	It is even possible that some people may be thinking of using
VLAN tags in other ways.  If so, I would like to hear their ideas.
For one thing, it is clear that we MUST decide on some set of uses
that are compatible, and it is clear that the use outlined in your
summary is fundamentally incompatible with the use I (and, I assume,
other people) have assumed.  It is also incompatible with standard
usage as defined in 802.1Q, and new proposals currently in process
in the IEEE.

	As a more-or-less philosophical clarification, it does not
make sense to configure VLANs in RBridges to accommodate the VLAN
tags used by the intervening fractional-LANs (what we have been
calling "LAN segments") between two RBridges.  VLAN tags SHOULD be 
used to accommodate connectivity among RBridges across the under-
lying fractional LANs (just as they are to accommodate connectivity 
among end-stations) - and not the other way around.

	From the perspective of existing 802.1D bridges, RBridges are
end-stations.  You decide which end-stations require connectivity,
you assign them to the same VLAN, and then you configure the VLAN
information in the VLAN bridges.

	Also, the idea of potentially "switching" from one VLAN tag 
to another across and RBridge to accommodate a presumed under-lying
VLAN tagging arrangement seems broken.  We would need to consider a
lot of potential corner-cases - particularly during deployment and
re-configuration - to determine if this will even work.  For one
thing, there are interesting problems that arise as a result of not
consistently using the same VLAN tags within a single administrative
domain.

	I assume we have not yet decided to tackle the "multi-domain"
problem in TRILL, given that it is supposed to be a LAN-oriented,
plug-and-play capable, enterprise solution...

--
Eric

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]] 
> Sent: Monday, November 20, 2006 8:36 PM
> To: Gray, Eric
> Cc: 'Silvano Gai'; Russ White; [e-mail]
> Subject: Summary of IVLANs vs OVLANs
> 
> I don't think there is an issue here, but let me hopefully 
> clarify the 
> purpose of a VLAN tag on the inner frame
> vs a VLAN tag which might appear on the outer header.
> 
> **********
> First: Purpose of "inner" VLAN tag
> ___________________________
> 
> 
> The purpose of the inner tag is to provide separation for endnode 
> communities. In other words, VLAN A
> endnodes can only talk to VLAN A endnodes. The VLAN tag is either 
> inserted by the original endnode,
> or the first bridge or RBridge that receives the frame. What 
> tag to put 
> in, whether to strip it, is configured
> into RBridges exactly as it would be with bridges.
> 
> The inner VLAN tag is irrelevant for how the frame is 
> forwarded between 
> the RBridges.
> 
> RBridges are willing to forward all frames, regardless of the 
> inner VLAN 
> tag. They forward towards the
> egress RBridge, totally ignoring the inner VLAN tag on 
> unicast packets. 
> On multicast, however, they
> will look at the VLAN tag on the inner frame to decide if they should 
> filter on some outgoing ports
> for the selected multicast tree, because there are no 
> downstream links 
> for that VLAN tag.
> 
> *******************
> Now for the outer VLAN tag
> 
> Basically, the outer header is only a hop-by-hop header, and is of no 
> significance other than
> to be able to communicate between RBridge neighbors. If it's 
> necessary 
> (because of configuration of
> bridges between two RBridges) to stick VLAN tags into the 
> outer header, 
> that's what the RBridges do.
> 
> So: figuring out your RBridge neighbors:
> 
> RBridges figure out who their RBridge neighbors are, through 
> the IS-IS 
> Hello protocol. VLANs make this
> a bit awkward, but still straightforward. Which VLAN tags exist on a 
> link is configured into the RBridges, just
> like it would be configured into a bridge.
> 
> So...RBridge RB1 has been configured to know that on port a, 
> packets are 
> allowed to have, say,
> VLAN tags A, C, and none.
> 
> So...RB1 has to figure out what RBridge neighbors it has. It 
> does this 
> by sending IS-IS Hellos three times
> on that port, tagged respectively with A, C, and none.
> 
> It might form different adjacencies depending on which VLAN tag the 
> IS-IS Hello was sent with.
> Let's say that with VLAN tag A, it forms an adjacency with 
> RB2, and with 
> VLAN tag C and no VLAN tag,
> it forms an adjacency with RB3.
> 
> Therefore, in the core instance of IS-IS, RB1 announces that 
> it has two 
> RBridge neighbors (maybe others on
> other ports as well); RB2 and RB3. It doesn't matter to any other 
> RBridges what VLAN tags RB1 needs
> to stick into the outer header in order to communicate on the 
> adjacency.
> 
> Whenever RB1 sends anything (forwarded data packets, IS-IS Hellos) to 
> adjacency RB2, it sticks VLAN A
> tag into the outer header.
> 
> Whenever RB1 sends anything to adjacency RB3, it has a choice. It can 
> put a VLAN C tag into the outer header,
> or no VLAN tag. It doesn't matter which it chooses.  I'd 
> choose no VLAN 
> tag, just to save a few bytes.
> But there might be a case where any of a set of VLAN tags would work, 
> and no VLAN tag wouldn't work,
> in which case, again, it doesn't matter which one it chooses.
> 
> ************************
> So, now let's look at the example being discussed in this thread:
> 
>                  +-----+  1,2  +-----------+
>                  | RB1 |-------| Rtg Fnctn |
>                  +-----+       +-----------+
>                     |
>                     | 1,2
>                     |
>   +-----+   1    +-----+    2     +-----+
>   | RB2 |--------| SW1 |----------| RB3 |
>   +-----+        +-----+          +-----+
>      |                               |
>      | IVLAN=3                       | IVLAN=3
>   +-----+                         +-----+
>   |  H1 |                         |  H2 |
>   +-----+                         +-----+
> 
> 
> In this example, RB2 will wind up with an adjency to RB1, and have to 
> stick VLAN 1 into the outer
> header in order to talk to RB1. RB2 will not form an 
> adjacency with RB3.
> 
> RB2, on the other other, will form two adjacencies on that 
> port; one to 
> RB2 (using VLAN 1), and
> one to RB3 (using VLAN 2).
> 
> The IS-IS topology will looks like:
> 
> H1----RB2---RB1----RB3---H2
> 
> So the path from H1 to H2 will go through RB2, then RB1, then RB3.
> 
> Hope this clarifies.
> 
> Radia
> 
> 
> 
> 
> 


Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAL1aa0o023464 for <[e-mail]>; Mon, 20 Nov 2006 17:36:36 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 20 Nov 2006 17:36:26 -0800 (PST)
Received: from sun.com ([129.150.19.86]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 20 Nov 2006 17:36:26 -0800 (PST)
Date: Mon, 20 Nov 2006 17:36:26 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Gray, Eric" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: [rbridge] Summary of IVLANs vs OVLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2006 01:36:46 -0000
Status: RO
Content-Length: 4162

I don't think there is an issue here, but let me hopefully clarify the 
purpose of a VLAN tag on the inner frame
vs a VLAN tag which might appear on the outer header.

**********
First: Purpose of "inner" VLAN tag
___________________________


The purpose of the inner tag is to provide separation for endnode 
communities. In other words, VLAN A
endnodes can only talk to VLAN A endnodes. The VLAN tag is either 
inserted by the original endnode,
or the first bridge or RBridge that receives the frame. What tag to put 
in, whether to strip it, is configured
into RBridges exactly as it would be with bridges.

The inner VLAN tag is irrelevant for how the frame is forwarded between 
the RBridges.

RBridges are willing to forward all frames, regardless of the inner VLAN 
tag. They forward towards the
egress RBridge, totally ignoring the inner VLAN tag on unicast packets. 
On multicast, however, they
will look at the VLAN tag on the inner frame to decide if they should 
filter on some outgoing ports
for the selected multicast tree, because there are no downstream links 
for that VLAN tag.

*******************
Now for the outer VLAN tag

Basically, the outer header is only a hop-by-hop header, and is of no 
significance other than
to be able to communicate between RBridge neighbors. If it's necessary 
(because of configuration of
bridges between two RBridges) to stick VLAN tags into the outer header, 
that's what the RBridges do.

So: figuring out your RBridge neighbors:

RBridges figure out who their RBridge neighbors are, through the IS-IS 
Hello protocol. VLANs make this
a bit awkward, but still straightforward. Which VLAN tags exist on a 
link is configured into the RBridges, just
like it would be configured into a bridge.

So...RBridge RB1 has been configured to know that on port a, packets are 
allowed to have, say,
VLAN tags A, C, and none.

So...RB1 has to figure out what RBridge neighbors it has. It does this 
by sending IS-IS Hellos three times
on that port, tagged respectively with A, C, and none.

It might form different adjacencies depending on which VLAN tag the 
IS-IS Hello was sent with.
Let's say that with VLAN tag A, it forms an adjacency with RB2, and with 
VLAN tag C and no VLAN tag,
it forms an adjacency with RB3.

Therefore, in the core instance of IS-IS, RB1 announces that it has two 
RBridge neighbors (maybe others on
other ports as well); RB2 and RB3. It doesn't matter to any other 
RBridges what VLAN tags RB1 needs
to stick into the outer header in order to communicate on the adjacency.

Whenever RB1 sends anything (forwarded data packets, IS-IS Hellos) to 
adjacency RB2, it sticks VLAN A
tag into the outer header.

Whenever RB1 sends anything to adjacency RB3, it has a choice. It can 
put a VLAN C tag into the outer header,
or no VLAN tag. It doesn't matter which it chooses.  I'd choose no VLAN 
tag, just to save a few bytes.
But there might be a case where any of a set of VLAN tags would work, 
and no VLAN tag wouldn't work,
in which case, again, it doesn't matter which one it chooses.

************************
So, now let's look at the example being discussed in this thread:

                 +-----+  1,2  +-----------+
                 | RB1 |-------| Rtg Fnctn |
                 +-----+       +-----------+
                    |
                    | 1,2
                    |
  +-----+   1    +-----+    2     +-----+
  | RB2 |--------| SW1 |----------| RB3 |
  +-----+        +-----+          +-----+
     |                               |
     | IVLAN=3                       | IVLAN=3
  +-----+                         +-----+
  |  H1 |                         |  H2 |
  +-----+                         +-----+


In this example, RB2 will wind up with an adjency to RB1, and have to 
stick VLAN 1 into the outer
header in order to talk to RB1. RB2 will not form an adjacency with RB3.

RB2, on the other other, will form two adjacencies on that port; one to 
RB2 (using VLAN 1), and
one to RB3 (using VLAN 2).

The IS-IS topology will looks like:

H1----RB2---RB1----RB3---H2

So the path from H1 to H2 will go through RB2, then RB1, then RB3.

Hope this clarifies.

Radia







Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAHFM9UO019435 for <[e-mail]>; Fri, 17 Nov 2006 07:22:09 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Fri, 17 Nov 2006 07:22:05 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] IVLANs vs OVLANs
Thread-Index: AccJ9aUTExUIVdTKTeah10VuQX8Y3QAZEZMA
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, "Russ White" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAHFM9UO019435
Cc: [e-mail]
Subject: Re: [rbridge] IVLANs vs OVLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Nov 2006 15:22:36 -0000
Status: RO
Content-Length: 17288

Eric,

> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Thursday, November 16, 2006 7:08 PM
> To: Silvano Gai; Russ White
> Cc: [e-mail]
> Subject: RE: [rbridge] IVLANs vs OVLANs
> 
> Silvano,
> 
> 	Forget the "Null VLAN" concept for the moment, and look at
> the rest of what you're saying.
> 

... Snip ...

> 	Finally, to get onto the question you ask, I don't agree that
> any frame handled by an RBridge MUST be tagged - at all.  


I never said that. I understand that on the links there are three kinds
of frames:
1) Untagged
2) Priority Tagged
3) VLAN tagged

What I pointed out from the standard text is that the port of the switch
always normalizes the frame to be tagged in the moment it enters the
switch. You are right that IEEE 802.1Q allows for extensions, but the
final result is that a frame inside a switch as a VID (VLAN ID)
associated to it.

Now let's consider an RBridge:

1) if the frame is received on an access port, i.e. comes from a host,
i.e. does not have a TRILL shim, it has an IVLAN tag associated. In the
base protocol spec there is an explanation on how to handle that frame,
including VLAN pruning. I have no issues

2) if the frame is received on a trunk port, i.e. it comes from another
RBridge, i.e. it has a TRILL shim, it has both an IVLAN and an OVLAN tag
associated. This is the case that I don't understand how it works. 

We need to explain what to do with the OVLAN information: we can ignore
it or use it.

If we ignore the OVLAN it means that two hosts are considered to be on
the same VLAN if they are both on the same IVLAN, independently of the
OVLAN. This is my understanding of Radia proposal.

If we use it, it means that two stations are considered to be on the
same VLAN only if they are both on the same IVLAN and OVLAN. This is my
understanding of what Metro Ethernet folks want to do.

Which solution are you advocating?

-- Silvano





Assuming
> you are addressing the case where a deployment only uses 802.1Q
> devices, and all traffic is necessarily tagged, then every frame
> that is not TRILL encapsulated MUST have a VLAN tag.  That is a
> trivial observation that necessarily follows from the definition
> of the deployment scenario.
> 
> 	I also don't agree that frames forwarded within a CRED will
> necessarily have any VLAN tag in the tunnel encapsulation.  Again,
> if the assumption is that there is a deployment scenario in which
> this is required, then (naturally) it will be the case that this
> turns out to be true.
> 
> 	However, I do agree that there could be advantages to using
> a VLAN tagged frame format in the tunnel encapsulation when there
> was a VLAN tagged frame format in native frames being forwarded
> across a CRED.  For example, this might be used to eliminate the
> need for RBridges to peek beyond the tunnel encapsulation.
> 
> 	The potential for advantage is limited, if the mapping is not
> essentially a 1:1 VLAN tag mapping, because it seems likely that any
> N:1 mapping (where N is more than a few) will result in delivering
> some number of frames to egress devices that will then drop them.
> This approach fails to meet any sort of "efficient forwarding"
> criterion I would like to define.  This would be true, even if it is
> a hard requirement for RBridges to always filter based on VLANs -
> including within the CRED.
> 
> 	Note that this is potentially far more true if the RBridges
> are not supporting per-ingress IRTs.
> 
> 	The potential for advantage is limited, at the other end, if
> N is close to (or equal to) 1, because there is no scalability gain
> if every VLAN in the network is represented by VLAN tags in tunnel
> encapsulation within the CRED.
> 
> 	However, the issue is that this "mapping" is strictly that,
> and this greatly complicates your original question - without, in
> fact, making the answer different in any other way.  If there is a
> mapping of VLAN tags in native frames to VLAN tags in the tunneled
> (TRILL) frames, it is made at the ingress RBridge, used by transit
> RBridges for IRT VLAN-pruning (if practical), and simply stripped
> off at the egress.  This does not change the fact that these frames
> must then leave the CRED and be delivered to an L2 end-station (at
> least, as far as RBridges are concerned).  If anything is expected
> to make a re-forwarding decision, it would be the receiving end
> station, not the egress RBridge.
> 
> --
> Eric
> 
> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]]
> Sent: Thursday, November 16, 2006 8:23 PM
> To: Gray, Eric; Russ White
> Cc: [e-mail]
> Subject: RE: [rbridge] IVLANs vs OVLANs
> 
> 
> Eric,
> 
> The concept of "Null VLAN" does not exists in IEEE 802.1Q.
> 
> IEEE 802.1Q states:
> "An untagged frame or a priority-tagged frame does not carry any
> identification of the VLAN to which it belongs. Such frames are
> classified as belonging to a particular VLAN based on parameters
> associated with the receiving Port, or, through proprietary
> extensions to this standard,
> based on the data content of the frame (e.g., MAC Address, layer 3
> protocol ID, etc.)."
> 
> Therefore all the frames inside an IEEE 802.1Q compliant-switch are
> tagged with an VLAN independently from the fact that they came in
> VLAN-Tagged, Priority-Tagged or untagged.
> 
> On entering an Rbridge a frame:
> 1) if it does not have a TRILL shim header, it is always tagged with
an
> IVLAN.
> 2) if it does have a TRILL shim header it always has both an OVLAN and
> an IVLAN.
> 
> Do you agree?
> 
> -- Silvano
> 
> 
> > -----Original Message-----
> > From: Gray, Eric [mailto:[e-mail]]
> > Sent: Thursday, November 16, 2006 7:39 AM
> > To: Silvano Gai; Russ White
> > Cc: [e-mail]
> > Subject: RE: [rbridge] IVLANs vs OVLANs
> >
> > Silvano,			(note: Russ - please read this!!)
> >
> > 	For the first part of your question, Radia and I had almost
> > this exact same discussion during the BoF I mentioned.  The only
> > legitimate way to get from one (logical) VLAN to another is via a
> > routing function.
> >
> > 	Unless you include the "routing function" as part of the TRILL
> > specification requirements - which does not, in any way, makes sense
> > - then the model that applies is the one that has VLANs logically
> > separated.
> >
> > 	That is strictly a VLAN separation issue.  The second part of
> > your question is trickier, hence it is good that you ask it and even
> > better that you insisted on being understood.  :-)
> >
> > 	From an RBridge perspective, I believe it is sufficient that all
> > of the RBridges MUST support a common (probably the default - NULL)
> > VLAN to ensure that all of them MUST peer with each other - at least
> > for support of that (common) VLAN.  Hence, it should not be the case
> > that any (proper) subset of RBridges would not peer exclusively with
> > any other (proper) subset of RBridges in the same CRED.
> >
> > 	Also, from an IS-IS perspective (help me out here Russ), I am
> > reasonably sure that adjacent/connected IS-IS instances MUST
discover
> > each other during peer discovery - even if they do not subsequently
> > peer with each other (or having peered with each other, exchange any
> > routing information).  I believe this would be the case, even if
there
> > was potentially some strange virtual L3 overlay topology involving
> > separate L3 VPN instancing in the IS-IS routing deployment.
> >
> > 	If that is the case, then - from a peer discovery perspective -
> > all RBridges will still be in the same CRED.  This is the
perspective
> > that matters, because it is the peer discovery process that allows
the
> > members of a CRED to "discover" potential _hidden_ loops in
underlying
> > L2 topology.
> >
> > 	See also my reply to your question about VLAN interactions with
> > routing...
> >
> > --
> > Eric
> >
> > --> -----Original Message-----
> > --> From: Silvano Gai [mailto:[e-mail]]
> > --> Sent: Thursday, November 16, 2006 12:57 AM
> > --> To: Gray, Eric
> > --> Cc: [e-mail]
> > --> Subject: RE: [rbridge] IVLANs vs OVLANs
> > -->
> > -->
> > --> Eric,
> > -->
> > --> I am just trying to understand if there is consensus in a) or
b).
> > -->
> > --> The impression I got talking with Radia is that she was in
> > --> favor of a).
> > -->
> > --> Your reply is my b) model to which you have added a router.
> > --> Since b) is
> > --> two separate layer 2 networks, you can put a router between
> > --> the two, as
> > --> you did.
> > -->
> > --> Please also note that I can redraw the same network in a
> > --> different way:
> > -->
> > -->                 +-----+
> > -->                 | RB1 |
> > -->                 +-----+
> > -->                  |  |
> > -->                1 |  | 2
> > -->                  |  |
> > -->  +-----+   1    +-----+    2     +-----+
> > -->  | RB2 |--------| SW1 |----------| RB3 |
> > -->  +-----+        +-----+          +-----+
> > -->
> > --> Where I replaced the Etherchannel with two links, one in
> > --> OVLAN=1 and one
> > --> in OVLAN=2.
> > -->
> > --> Now is RB2 capable of talking to RB3 through RB1?
> > -->
> > --> -- Silvano
> > -->
> > --> > -----Original Message-----
> > --> > From: Gray, Eric [mailto:[e-mail]]
> > --> > Sent: Wednesday, November 15, 2006 12:13 PM
> > --> > To: Silvano Gai
> > --> > Cc: [e-mail]
> > --> > Subject: RE: [rbridge] IVLANs vs OVLANs
> > --> >
> > --> > Silvano,
> > --> >
> > --> > 	First of all, I will take very large exception to the
> way
> > --> > which you have over-loaded the term "CRED."  This term was
> coined
> > --> > to eliminate confusion caused by the various different was
> people
> > --> > were over-loading the term "Campus."
> > --> >
> > --> > 	At the "core" of your question, however, is the issue of
> > --> > how VLANs interact in a bridged/RBridge environment.  It is
not
> > --> > different than would be the case in a "classical bridged LAN."
> > --> >
> > --> > 	This issue is based on a misconception that existed very
> > --> > early on in the life of the TRILL working group (in the first
> > --> > BoF, in fact).  The misconception is that VLAN connectivity
may
> > --> > be provided by RBridges and/or bridges.
> > --> >
> > --> > 	This is fundamentally incorrect.
> > --> >
> > --> > 	Interconnection of VLANs is strictly a routing function.
> > --> > In deployed equipment that does this today, there may be some
> > --> > form of "smart VLAN bridging" that occurs in devices people
are
> > --> > used to referring to as "bridges" or "switches."  That does
not
> > --> > change the fact that forwarding from one VLAN to another is a
> > --> > "routing function."
> > --> >
> > --> > 	Note that, in this context, when I say "forwarding from
> > --> > one VLAN to another" - I mean "VLAN" in the sense of "virtual
> > --> > LAN" as a logical concept.  This has nothing to do with the
fact
> > --> > that a VLAN ID might change in traversing a VLAN-aware bridge.
> > --> >
> > --> > 	Consequently, in the picture you have below, the VLANs
> > --> > represented by the VLAN-tag in the tunnel encapsulation may
> > --> > not be connected together by RB1.
> > --> >
> > --> > 	To correctly restate your question, the original
> topology
> > --> > would be as follows:
> > --> >
> > --> >
> > --> >                 +-----+  1,2  +-----------+
> > --> >                 | RB1 |-------| Rtg Fnctn |
> > --> >                 +-----+       +-----------+
> > --> >                    |
> > --> >                    | 1,2
> > --> >                    |
> > --> >  +-----+   1    +-----+    2     +-----+
> > --> >  | RB2 |--------| SW1 |----------| RB3 |
> > --> >  +-----+        +-----+          +-----+
> > --> >
> > --> > The resulting logical topology MUST then be as follows:
> > --> >
> > --> >
> > --> >  +-----+        +-----+       +-----------+
> > --> >  | RB2 |--------| RB1 |-------| Rtg Fnctn |
> > --> >  +-----+        +-----+       +-----+-----+
> > --> >                                     |
> > --> >                                  +--+--+          +-----+
> > --> >                                  | RB1 |----------| RB3 |
> > --> >                                  +-----+          +-----+
> > --> >
> > --> > Since the "routing function" is orthogonal, and well
understood,
> > --> > it does not make sense for us to try to combine this concept
> with
> > --> > RBridge behaviors and protocol interactions.
> > --> >
> > --> > --
> > --> > Eric
> > --> >
> > --> >
> > --> > --> -----Original Message-----
> > --> > --> From: [e-mail]
> > --> > --> [mailto:[e-mail]] On Behalf Of Silvano
Gai
> > --> > --> Sent: Tuesday, November 14, 2006 8:11 PM
> > --> > --> To: [e-mail]
> > --> > --> Subject: [rbridge] IVLANs vs OVLANs
> > --> > -->
> > --> > -->
> > --> > --> During the last WG meeting I had an action item to send an
> > --> > --> email on the
> > --> > --> VLAN issue. Here it is.
> > --> > -->
> > --> > --> In a previous email I introduced the concept of IVLAN
> > --> and OVLAN.
> > --> > -->
> > --> > --> IVLAN refers to the VLAN present on the untagged frames,
> > --> > --> which must be
> > --> > --> propagated by ISIS, VLAN pruning must be performed and so
> > --> > --> on. All the
> > --> > --> IVLANs share the same core instance of ISIS.
> > --> > -->
> > --> > --> OVLAN refers to the fact that the traffic between two
> > --> > --> RBridges can be
> > --> > --> encapsulated into a VLAN.
> > --> > -->
> > --> > --> If we look to the format of a TRILL encapsulated frame the
> > --> > --> position of
> > --> > --> these two fields is as follow:
> > --> > -->
> > --> > --> +--------------------------------+
> > --> > --> |               DA               |
> > --> > --> +----------------+---------------+
> > --> > --> |       DA       |     SA        |
> > --> > --> +----------------+---------------+
> > --> > --> |               SA               |
> > --> > --> +--------------------------------+
> > --> > --> |    ET = 1Q     |   OVLAN ...   |
> > --> > --> +--------------------------------+
> > --> > --> |    ET = TRILL  | RES  |  TTL   |
> > --> > --> +--------------------------------+
> > --> > --> | Egress Add.    | Ingress Add.  |
> > --> > --> +--------------------------------+
> > --> > --> |               DA               |
> > --> > --> +----------------+---------------+
> > --> > --> |       DA       |     SA        |
> > --> > --> +----------------+---------------+
> > --> > --> |               SA               |
> > --> > --> +--------------------------------+
> > --> > --> |    ET = 1Q     |   IVLAN ...   |
> > --> > --> +--------------------------------+
> > --> > --> |             Payload            |
> > --> > -->
> > --> > --> Now let's consider the following topology:
> > --> > -->
> > --> > -->                +-----+
> > --> > -->                | RB1 |
> > --> > -->                +-----+
> > --> > -->                   |
> > --> > -->                   | 1,2
> > --> > -->                   |
> > --> > --> +-----+   1    +-----+    2     +-----+
> > --> > --> | RB2 |--------| SW1 |----------| RB3 |
> > --> > --> +-----+        +-----+          +-----+
> > --> > -->
> > --> > --> RB1, RB2, RB3 are Rbridges, SW1 is a classical
> > --> Ethernet switch.
> > --> > --> The link between RB2 and SW1 is in OVLAN 1, the link
> > --> > --> between SW1 and RB3
> > --> > --> is in OVLAN 2 and the links between SW1 and RB1 is a
> > --> trunk and it
> > --> > --> carries both OVLAN 1 and 2.
> > --> > -->
> > --> > --> Now my question is: "do we have one CRED or two?"
> > --> > -->
> > --> > --> a) possible answer: "we have one CRED". RB2 is adjacent to
> > --> > --> RB1 but not
> > --> > --> to RB3. The same applies to RB3 that is adjacent to RB1,
> > --> > --> but not RB2.
> > --> > --> RB1 is adjacent to both RB2 and RB3. There is a single
core
> > --> > --> instance of
> > --> > --> ISIS. RB2 may reach RB3 through RB1.
> > --> > -->
> > --> > --> The TRILL equivalent topology is:
> > --> > -->
> > --> > --> +-----+        +-----+          +-----+
> > --> > --> | RB2 |--------| RB1 |----------| RB3 |
> > --> > --> +-----+        +-----+          +-----+
> > --> > -->
> > --> > --> b) another possible answer: "we have two CREDs". One is
> > --> > --> composed by RB2
> > --> > --> and RB1, the other by RB3 and RB1. RB2 may not reach RB3,
> > --> > --> since they are
> > --> > --> in different CREDs.
> > --> > -->
> > --> > --> The TRILL equivalent topologies are:
> > --> > -->
> > --> > --> +-----+        +-----+
> > --> > --> | RB2 |--------| RB1 |
> > --> > --> +-----+        +-----+
> > --> > -->
> > --> > --> +-----+          +-----+
> > --> > --> | RB1 |----------| RB3 |
> > --> > --> +-----+          +-----+
> > --> > -->
> > --> > --> I like a) and I hope we are in agreement that the right
> > --> > --> answer is a),
> > --> > --> but I haven't seen it explained in any of the documents.
> > --> > -->
> > --> > --> -- Silvano
> > --> > -->
> > --> > --> _______________________________________________
> > --> > --> rbridge mailing list
> > --> > --> [e-mail]
> > --> > --> http://mailman.postel.org/mailman/listinfo/rbridge
> > --> > -->
> > -->



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAH38Oe6009367 for <[e-mail]>; Thu, 16 Nov 2006 19:08:25 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kAH38JfK007168; Thu, 16 Nov 2006 22:08:20 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA13995;  Thu, 16 Nov 2006 22:08:19 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB6VC5N6>; Thu, 16 Nov 2006 22:08:18 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Silvano Gai'" <[e-mail]>, Russ White <[e-mail]>
Date: Thu, 16 Nov 2006 22:08:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] IVLANs vs OVLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Nov 2006 03:08:41 -0000
Status: RO
Content-Length: 17770

Silvano,

	Forget the "Null VLAN" concept for the moment, and look at
the rest of what you're saying.

	What part of the quote you provide (below) from what 802.1Q
says, leads you to conclude what you say in the next paragraph -
i.e. - that an 802.1Q compliant "switch" only handles tagged frames?

	The way I read the quote, 802.1Q is making a complicated (but
- in my opinion - very wise) observation.  The observation - broken
into its explicit components is:

1)	a device MAY use other means to associate frames with a VLAN,
2)	these other means are considered extensions to 802.1Q and are
	(therefore) not addressed by 802.1Q.

An implicit observation that can be derived from this is:

3)	any such extensions may be implemented in a device and - as
	long as that device is otherwise compliant with 802.1Q - these
	extensions are allowed by 802.1Q.

The derivation for this third observation is as described in the
next few (un-indented) paragraphs.

First, the quote you provide - in no way - states (or clearly implies) 
that any device that supports any sort of extension to 802.1Q is not 
compliant with 802.1Q.

Second, the way that protocol specifications work is that anything 
not explicitly (or otherwise obviously) prohibited, is allowed.

This is the only reasonable way to deal with the possibility of any
sort of protocol that is intended (or allowed) to be extended.  By
merely stating that these are potential extensions to the protocol,
without explicitly stating that such extensions are not allowed, a 
protocol specification is making it clear that such extensions are
allowed by the protocol.

At best, you could argue that the 802.1Q "compliant function" is
logically separated from the "mapping function" but to argue that
this separation makes an implementation that is done that way "non
compliant" is to make a completely specious argument.

	Now, let's get back to the "NULL VLAN" case.  

	Whatever we call it, there is one case in which a frame is 
received by a bridge - without any VLAN tagging - and is mapped to
a specific logical VLAN (using any reasonable criteria).  In being
forwarded, such a frame MAY be tagged using 802.1Q.  This happens.

	For some people, it is convenient to view this as logically
equivalent to having received a frame from a "default VLAN", on a
logical interface defined by whatever criteria the implementation
may use to determine the frame belongs in a specific VLAN.

	There is also the case in which a 802.1Q tagged frame is
intended to be forwarded on a physical interface, without the tag.

	It is actually the combination of these two cases that tends 
to define what sorts of criteria it makes practical sense to use 
in defining an "802.1Q extension-based" VLAN.  Because people are
required to think about this combined case, it is important to have 
some term you use to talk about the "untagged" case.  Some people 
have referred to that case as the "NULL VLAN" case.

	If you have a term you feel is better, then maybe we can use 
your term sometimes.

	Finally, to get onto the question you ask, I don't agree that
any frame handled by an RBridge MUST be tagged - at all.  Assuming
you are addressing the case where a deployment only uses 802.1Q
devices, and all traffic is necessarily tagged, then every frame
that is not TRILL encapsulated MUST have a VLAN tag.  That is a
trivial observation that necessarily follows from the definition 
of the deployment scenario.

	I also don't agree that frames forwarded within a CRED will
necessarily have any VLAN tag in the tunnel encapsulation.  Again,
if the assumption is that there is a deployment scenario in which
this is required, then (naturally) it will be the case that this
turns out to be true.

	However, I do agree that there could be advantages to using 
a VLAN tagged frame format in the tunnel encapsulation when there 
was a VLAN tagged frame format in native frames being forwarded
across a CRED.  For example, this might be used to eliminate the
need for RBridges to peek beyond the tunnel encapsulation.

	The potential for advantage is limited, if the mapping is not 
essentially a 1:1 VLAN tag mapping, because it seems likely that any 
N:1 mapping (where N is more than a few) will result in delivering 
some number of frames to egress devices that will then drop them.
This approach fails to meet any sort of "efficient forwarding"
criterion I would like to define.  This would be true, even if it is 
a hard requirement for RBridges to always filter based on VLANs - 
including within the CRED.

	Note that this is potentially far more true if the RBridges
are not supporting per-ingress IRTs.

	The potential for advantage is limited, at the other end, if
N is close to (or equal to) 1, because there is no scalability gain
if every VLAN in the network is represented by VLAN tags in tunnel
encapsulation within the CRED.

	However, the issue is that this "mapping" is strictly that,
and this greatly complicates your original question - without, in
fact, making the answer different in any other way.  If there is a
mapping of VLAN tags in native frames to VLAN tags in the tunneled 
(TRILL) frames, it is made at the ingress RBridge, used by transit
RBridges for IRT VLAN-pruning (if practical), and simply stripped
off at the egress.  This does not change the fact that these frames
must then leave the CRED and be delivered to an L2 end-station (at
least, as far as RBridges are concerned).  If anything is expected
to make a re-forwarding decision, it would be the receiving end
station, not the egress RBridge.

--
Eric

-----Original Message-----
From: Silvano Gai [mailto:[e-mail]] 
Sent: Thursday, November 16, 2006 8:23 PM
To: Gray, Eric; Russ White
Cc: [e-mail]
Subject: RE: [rbridge] IVLANs vs OVLANs


Eric,

The concept of "Null VLAN" does not exists in IEEE 802.1Q.

IEEE 802.1Q states:
"An untagged frame or a priority-tagged frame does not carry any
identification of the VLAN to which it belongs. Such frames are
classified as belonging to a particular VLAN based on parameters
associated with the receiving Port, or, through proprietary 
extensions to this standard,
based on the data content of the frame (e.g., MAC Address, layer 3
protocol ID, etc.)."

Therefore all the frames inside an IEEE 802.1Q compliant-switch are
tagged with an VLAN independently from the fact that they came in
VLAN-Tagged, Priority-Tagged or untagged.

On entering an Rbridge a frame:
1) if it does not have a TRILL shim header, it is always tagged with an
IVLAN.
2) if it does have a TRILL shim header it always has both an OVLAN and
an IVLAN.

Do you agree?

-- Silvano


> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Thursday, November 16, 2006 7:39 AM
> To: Silvano Gai; Russ White
> Cc: [e-mail]
> Subject: RE: [rbridge] IVLANs vs OVLANs
> 
> Silvano,			(note: Russ - please read this!!)
> 
> 	For the first part of your question, Radia and I had almost
> this exact same discussion during the BoF I mentioned.  The only
> legitimate way to get from one (logical) VLAN to another is via a
> routing function.
> 
> 	Unless you include the "routing function" as part of the TRILL
> specification requirements - which does not, in any way, makes sense
> - then the model that applies is the one that has VLANs logically
> separated.
> 
> 	That is strictly a VLAN separation issue.  The second part of
> your question is trickier, hence it is good that you ask it and even
> better that you insisted on being understood.  :-)
> 
> 	From an RBridge perspective, I believe it is sufficient that all
> of the RBridges MUST support a common (probably the default - NULL)
> VLAN to ensure that all of them MUST peer with each other - at least
> for support of that (common) VLAN.  Hence, it should not be the case
> that any (proper) subset of RBridges would not peer exclusively with
> any other (proper) subset of RBridges in the same CRED.
> 
> 	Also, from an IS-IS perspective (help me out here Russ), I am
> reasonably sure that adjacent/connected IS-IS instances MUST discover
> each other during peer discovery - even if they do not subsequently
> peer with each other (or having peered with each other, exchange any
> routing information).  I believe this would be the case, even if there
> was potentially some strange virtual L3 overlay topology involving
> separate L3 VPN instancing in the IS-IS routing deployment.
> 
> 	If that is the case, then - from a peer discovery perspective -
> all RBridges will still be in the same CRED.  This is the perspective
> that matters, because it is the peer discovery process that allows the
> members of a CRED to "discover" potential _hidden_ loops in underlying
> L2 topology.
> 
> 	See also my reply to your question about VLAN interactions with
> routing...
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[e-mail]]
> --> Sent: Thursday, November 16, 2006 12:57 AM
> --> To: Gray, Eric
> --> Cc: [e-mail]
> --> Subject: RE: [rbridge] IVLANs vs OVLANs
> -->
> -->
> --> Eric,
> -->
> --> I am just trying to understand if there is consensus in a) or b).
> -->
> --> The impression I got talking with Radia is that she was in
> --> favor of a).
> -->
> --> Your reply is my b) model to which you have added a router.
> --> Since b) is
> --> two separate layer 2 networks, you can put a router between
> --> the two, as
> --> you did.
> -->
> --> Please also note that I can redraw the same network in a
> --> different way:
> -->
> -->                 +-----+
> -->                 | RB1 |
> -->                 +-----+
> -->                  |  |
> -->                1 |  | 2
> -->                  |  |
> -->  +-----+   1    +-----+    2     +-----+
> -->  | RB2 |--------| SW1 |----------| RB3 |
> -->  +-----+        +-----+          +-----+
> -->
> --> Where I replaced the Etherchannel with two links, one in
> --> OVLAN=1 and one
> --> in OVLAN=2.
> -->
> --> Now is RB2 capable of talking to RB3 through RB1?
> -->
> --> -- Silvano
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:[e-mail]]
> --> > Sent: Wednesday, November 15, 2006 12:13 PM
> --> > To: Silvano Gai
> --> > Cc: [e-mail]
> --> > Subject: RE: [rbridge] IVLANs vs OVLANs
> --> >
> --> > Silvano,
> --> >
> --> > 	First of all, I will take very large exception to the
way
> --> > which you have over-loaded the term "CRED."  This term was
coined
> --> > to eliminate confusion caused by the various different was
people
> --> > were over-loading the term "Campus."
> --> >
> --> > 	At the "core" of your question, however, is the issue of
> --> > how VLANs interact in a bridged/RBridge environment.  It is not
> --> > different than would be the case in a "classical bridged LAN."
> --> >
> --> > 	This issue is based on a misconception that existed very
> --> > early on in the life of the TRILL working group (in the first
> --> > BoF, in fact).  The misconception is that VLAN connectivity may
> --> > be provided by RBridges and/or bridges.
> --> >
> --> > 	This is fundamentally incorrect.
> --> >
> --> > 	Interconnection of VLANs is strictly a routing function.
> --> > In deployed equipment that does this today, there may be some
> --> > form of "smart VLAN bridging" that occurs in devices people are
> --> > used to referring to as "bridges" or "switches."  That does not
> --> > change the fact that forwarding from one VLAN to another is a
> --> > "routing function."
> --> >
> --> > 	Note that, in this context, when I say "forwarding from
> --> > one VLAN to another" - I mean "VLAN" in the sense of "virtual
> --> > LAN" as a logical concept.  This has nothing to do with the fact
> --> > that a VLAN ID might change in traversing a VLAN-aware bridge.
> --> >
> --> > 	Consequently, in the picture you have below, the VLANs
> --> > represented by the VLAN-tag in the tunnel encapsulation may
> --> > not be connected together by RB1.
> --> >
> --> > 	To correctly restate your question, the original
topology
> --> > would be as follows:
> --> >
> --> >
> --> >                 +-----+  1,2  +-----------+
> --> >                 | RB1 |-------| Rtg Fnctn |
> --> >                 +-----+       +-----------+
> --> >                    |
> --> >                    | 1,2
> --> >                    |
> --> >  +-----+   1    +-----+    2     +-----+
> --> >  | RB2 |--------| SW1 |----------| RB3 |
> --> >  +-----+        +-----+          +-----+
> --> >
> --> > The resulting logical topology MUST then be as follows:
> --> >
> --> >
> --> >  +-----+        +-----+       +-----------+
> --> >  | RB2 |--------| RB1 |-------| Rtg Fnctn |
> --> >  +-----+        +-----+       +-----+-----+
> --> >                                     |
> --> >                                  +--+--+          +-----+
> --> >                                  | RB1 |----------| RB3 |
> --> >                                  +-----+          +-----+
> --> >
> --> > Since the "routing function" is orthogonal, and well understood,
> --> > it does not make sense for us to try to combine this concept
with
> --> > RBridge behaviors and protocol interactions.
> --> >
> --> > --
> --> > Eric
> --> >
> --> >
> --> > --> -----Original Message-----
> --> > --> From: [e-mail]
> --> > --> [mailto:[e-mail]] On Behalf Of Silvano Gai
> --> > --> Sent: Tuesday, November 14, 2006 8:11 PM
> --> > --> To: [e-mail]
> --> > --> Subject: [rbridge] IVLANs vs OVLANs
> --> > -->
> --> > -->
> --> > --> During the last WG meeting I had an action item to send an
> --> > --> email on the
> --> > --> VLAN issue. Here it is.
> --> > -->
> --> > --> In a previous email I introduced the concept of IVLAN
> --> and OVLAN.
> --> > -->
> --> > --> IVLAN refers to the VLAN present on the untagged frames,
> --> > --> which must be
> --> > --> propagated by ISIS, VLAN pruning must be performed and so
> --> > --> on. All the
> --> > --> IVLANs share the same core instance of ISIS.
> --> > -->
> --> > --> OVLAN refers to the fact that the traffic between two
> --> > --> RBridges can be
> --> > --> encapsulated into a VLAN.
> --> > -->
> --> > --> If we look to the format of a TRILL encapsulated frame the
> --> > --> position of
> --> > --> these two fields is as follow:
> --> > -->
> --> > --> +--------------------------------+
> --> > --> |               DA               |
> --> > --> +----------------+---------------+
> --> > --> |       DA       |     SA        |
> --> > --> +----------------+---------------+
> --> > --> |               SA               |
> --> > --> +--------------------------------+
> --> > --> |    ET = 1Q     |   OVLAN ...   |
> --> > --> +--------------------------------+
> --> > --> |    ET = TRILL  | RES  |  TTL   |
> --> > --> +--------------------------------+
> --> > --> | Egress Add.    | Ingress Add.  |
> --> > --> +--------------------------------+
> --> > --> |               DA               |
> --> > --> +----------------+---------------+
> --> > --> |       DA       |     SA        |
> --> > --> +----------------+---------------+
> --> > --> |               SA               |
> --> > --> +--------------------------------+
> --> > --> |    ET = 1Q     |   IVLAN ...   |
> --> > --> +--------------------------------+
> --> > --> |             Payload            |
> --> > -->
> --> > --> Now let's consider the following topology:
> --> > -->
> --> > -->                +-----+
> --> > -->                | RB1 |
> --> > -->                +-----+
> --> > -->                   |
> --> > -->                   | 1,2
> --> > -->                   |
> --> > --> +-----+   1    +-----+    2     +-----+
> --> > --> | RB2 |--------| SW1 |----------| RB3 |
> --> > --> +-----+        +-----+          +-----+
> --> > -->
> --> > --> RB1, RB2, RB3 are Rbridges, SW1 is a classical
> --> Ethernet switch.
> --> > --> The link between RB2 and SW1 is in OVLAN 1, the link
> --> > --> between SW1 and RB3
> --> > --> is in OVLAN 2 and the links between SW1 and RB1 is a
> --> trunk and it
> --> > --> carries both OVLAN 1 and 2.
> --> > -->
> --> > --> Now my question is: "do we have one CRED or two?"
> --> > -->
> --> > --> a) possible answer: "we have one CRED". RB2 is adjacent to
> --> > --> RB1 but not
> --> > --> to RB3. The same applies to RB3 that is adjacent to RB1,
> --> > --> but not RB2.
> --> > --> RB1 is adjacent to both RB2 and RB3. There is a single core
> --> > --> instance of
> --> > --> ISIS. RB2 may reach RB3 through RB1.
> --> > -->
> --> > --> The TRILL equivalent topology is:
> --> > -->
> --> > --> +-----+        +-----+          +-----+
> --> > --> | RB2 |--------| RB1 |----------| RB3 |
> --> > --> +-----+        +-----+          +-----+
> --> > -->
> --> > --> b) another possible answer: "we have two CREDs". One is
> --> > --> composed by RB2
> --> > --> and RB1, the other by RB3 and RB1. RB2 may not reach RB3,
> --> > --> since they are
> --> > --> in different CREDs.
> --> > -->
> --> > --> The TRILL equivalent topologies are:
> --> > -->
> --> > --> +-----+        +-----+
> --> > --> | RB2 |--------| RB1 |
> --> > --> +-----+        +-----+
> --> > -->
> --> > --> +-----+          +-----+
> --> > --> | RB1 |----------| RB3 |
> --> > --> +-----+          +-----+
> --> > -->
> --> > --> I like a) and I hope we are in agreement that the right
> --> > --> answer is a),
> --> > --> but I haven't seen it explained in any of the documents.
> --> > -->
> --> > --> -- Silvano
> --> > -->
> --> > --> _______________________________________________
> --> > --> rbridge mailing list
> --> > --> [e-mail]
> --> > --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> > -->
> -->


Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAH2GMqC024408 for <[e-mail]>; Thu, 16 Nov 2006 18:16:22 -0800 (PST)
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 16 Nov 2006 18:16:22 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kAH2GM7P020046;  Thu, 16 Nov 2006 18:16:22 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kAH2GLW4011702; Thu, 16 Nov 2006 18:16:21 -0800 (PST)
Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 16 Nov 2006 18:16:21 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 16 Nov 2006 18:16:20 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] IVLANs vs OVLANs
Thread-Index: AccJlf/VG6ML+i7nTWWLJvSfLcATxgAVg1dw
From: "Larry Kreeger \(kreeger\)" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, "Silvano Gai" <[e-mail]>, "Russ White" <[e-mail]>
X-OriginalArrivalTime: 17 Nov 2006 02:16:21.0254 (UTC) FILETIME=[5F818A60:01C709EE]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4034; t=1163729782; x=1164593782; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22Larry=20Kreeger=20\(kreeger\)=22=20<[e-mail]> |Subject:=20RE=3A=20[rbridge]=20IVLANs=20vs=20OVLANs |Sender:=20; bh=nIzese/A3K3L84EKnH5V1/g4i4bNT1ZhAJFpJyIQKGY=; b=c9HcQn9/11jifHH3QIi0rIOIdPBqnheOLxB0eKCBudwRXFZl+CQzrOIv/b3E2uW4f5dWwOX0 eGxZsQbAr/l5Gemo2kJ4TmV1Kayr8Rldr85RJ0qaju3REln9N8ApQBcm;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAH2GMqC024408
Cc: [e-mail]
Subject: Re: [rbridge] IVLANs vs OVLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Nov 2006 02:16:41 -0000
Status: RO
Content-Length: 3904

I just read through this thread so far and I understand where Silvano is
coming from, but I don't quite get what Eric is saying.

Maybe it would help if someone could answer the following.

When an RBridge sends a frame to another RBridge (other one containing
IS-IS or a data frame), can it be encapsulated with an outer VLAN tag,
or should we say that it cannot?

If the answer is that the frames cannot be encapsulated with an OVLAN,
then things become clearer.  In the topology Silvano originally showed
(repeated below), 

                +-----+
                | RB1 |
                +-----+
                   |
                   | 1,2
                   |
 +-----+   1    +-----+    2     +-----+
 | RB2 |--------| SW1 |----------| RB3 |
 +-----+        +-----+          +-----+

If we assume that SW1's port connected to RB1 has the "native"
port-based VLAN for untagged frames set to VLAN 1, then the RBridge
topologies would look like.

 +-----+        +-----+       +-----+
 | RB2 |--------| RB1 |       | RB3 |
 +-----+        +-----+       +-----+

If the answer is that RBridges can encapsulate frames with an OVLAN,
then each OVLAN on each of an RBridge's physical port should be
considered a separate logical port on the RBridge.  Separate IS-IS
hellos should be sent by an RBridge on each of the logical ports.  This
makes the topology look exactly like Silvano's second picture (repeated
below), 

                +-----+
                | RB1 |
                +-----+
                 |   |
               1 |   | 2
                 |   |
 +-----+   1    +-----+    2     +-----+
 | RB2 |--------| SW1 |----------| RB3 |
 +-----+        +-----+          +-----+

Which would make the RBridge topology look like:

 +-----+        +-----+       +-----+
 | RB2 |--------| RB1 |-------| RB3 |
 +-----+        +-----+       +-----+

 - Larry

Gray, Eric wrote on Thursday, November 16, 2006 7:39 AM:

> Silvano,			(note: Russ - please read this!!)
> 
> 	For the first part of your question, Radia and I had almost this
> exact same discussion during the BoF I mentioned.  The only
> legitimate way to get from one (logical) VLAN to another is via a
> routing function.   
> 
> 	Unless you include the "routing function" as part of the TRILL
> specification requirements - which does not, in any way, makes sense
> - then the model that applies is the one that has VLANs logically
> separated.  
> 
> 	That is strictly a VLAN separation issue.  The second part of
your
> question is trickier, hence it is good that you ask it and even
> better that you insisted on being understood.  :-)  
> 
> 	From an RBridge perspective, I believe it is sufficient that all
of
> the RBridges MUST support a common (probably the default - NULL) VLAN
> to ensure that all of them MUST peer with each other - at least for
> support of that (common) VLAN.  Hence, it should not be the case that
> any (proper) subset of RBridges would not peer exclusively with any
> other (proper) subset of RBridges in the same CRED.     
> 
> 	Also, from an IS-IS perspective (help me out here Russ), I am
> reasonably sure that adjacent/connected IS-IS instances MUST discover
> each other during peer discovery - even if they do not subsequently
> peer with each other (or having peered with each other, exchange any
> routing information).  I believe this would be the case, even if
> there was potentially some strange virtual L3 overlay topology
> involving separate L3 VPN instancing in the IS-IS routing deployment.
> 
> 	If that is the case, then - from a peer discovery perspective -
all
> RBridges will still be in the same CRED.  This is the perspective
> that matters, because it is the peer discovery process that allows
> the members of a CRED to "discover" potential _hidden_ loops in
> underlying    
> L2 topology.
> 
> 	See also my reply to your question about VLAN interactions with
> routing... 



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAH1Mend006321 for <[e-mail]>; Thu, 16 Nov 2006 17:22:40 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Thu, 16 Nov 2006 17:22:38 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] IVLANs vs OVLANs
Thread-Index: AccJlVtY/xEkIbQ3RICdoQwFIGfMFgAT+TYQ
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, "Russ White" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAH1Mend006321
Cc: [e-mail]
Subject: Re: [rbridge] IVLANs vs OVLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Nov 2006 01:22:54 -0000
Status: RO
Content-Length: 11982

Eric,

The concept of "Null VLAN" does not exists in IEEE 802.1Q.

IEEE 802.1Q states:
"An untagged frame or a priority-tagged frame does not carry any
identification of the VLAN to which it belongs. Such frames are
classified as belonging to a particular VLAN based on parameters
associated with
the receiving Port, or, through proprietary extensions to this standard,
based on the data content of the frame (e.g., MAC Address, layer 3
protocol ID, etc.)."

Therefore all the frames inside an IEEE 802.1Q compliant-switch are
tagged with an VLAN independently from the fact that they came in
VLAN-Tagged, Priority-Tagged or untagged.

On entering an Rbridge a frame:
1) if it does not have a TRILL shim header, it is always tagged with an
IVLAN.
2) if it does have a TRILL shim header it always has both an OVLAN and
an IVLAN.

Do you agree?

-- Silvano


> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Thursday, November 16, 2006 7:39 AM
> To: Silvano Gai; Russ White
> Cc: [e-mail]
> Subject: RE: [rbridge] IVLANs vs OVLANs
> 
> Silvano,			(note: Russ - please read this!!)
> 
> 	For the first part of your question, Radia and I had almost
> this exact same discussion during the BoF I mentioned.  The only
> legitimate way to get from one (logical) VLAN to another is via a
> routing function.
> 
> 	Unless you include the "routing function" as part of the TRILL
> specification requirements - which does not, in any way, makes sense
> - then the model that applies is the one that has VLANs logically
> separated.
> 
> 	That is strictly a VLAN separation issue.  The second part of
> your question is trickier, hence it is good that you ask it and even
> better that you insisted on being understood.  :-)
> 
> 	From an RBridge perspective, I believe it is sufficient that all
> of the RBridges MUST support a common (probably the default - NULL)
> VLAN to ensure that all of them MUST peer with each other - at least
> for support of that (common) VLAN.  Hence, it should not be the case
> that any (proper) subset of RBridges would not peer exclusively with
> any other (proper) subset of RBridges in the same CRED.
> 
> 	Also, from an IS-IS perspective (help me out here Russ), I am
> reasonably sure that adjacent/connected IS-IS instances MUST discover
> each other during peer discovery - even if they do not subsequently
> peer with each other (or having peered with each other, exchange any
> routing information).  I believe this would be the case, even if there
> was potentially some strange virtual L3 overlay topology involving
> separate L3 VPN instancing in the IS-IS routing deployment.
> 
> 	If that is the case, then - from a peer discovery perspective -
> all RBridges will still be in the same CRED.  This is the perspective
> that matters, because it is the peer discovery process that allows the
> members of a CRED to "discover" potential _hidden_ loops in underlying
> L2 topology.
> 
> 	See also my reply to your question about VLAN interactions with
> routing...
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[e-mail]]
> --> Sent: Thursday, November 16, 2006 12:57 AM
> --> To: Gray, Eric
> --> Cc: [e-mail]
> --> Subject: RE: [rbridge] IVLANs vs OVLANs
> -->
> -->
> --> Eric,
> -->
> --> I am just trying to understand if there is consensus in a) or b).
> -->
> --> The impression I got talking with Radia is that she was in
> --> favor of a).
> -->
> --> Your reply is my b) model to which you have added a router.
> --> Since b) is
> --> two separate layer 2 networks, you can put a router between
> --> the two, as
> --> you did.
> -->
> --> Please also note that I can redraw the same network in a
> --> different way:
> -->
> -->                 +-----+
> -->                 | RB1 |
> -->                 +-----+
> -->                  |  |
> -->                1 |  | 2
> -->                  |  |
> -->  +-----+   1    +-----+    2     +-----+
> -->  | RB2 |--------| SW1 |----------| RB3 |
> -->  +-----+        +-----+          +-----+
> -->
> --> Where I replaced the Etherchannel with two links, one in
> --> OVLAN=1 and one
> --> in OVLAN=2.
> -->
> --> Now is RB2 capable of talking to RB3 through RB1?
> -->
> --> -- Silvano
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:[e-mail]]
> --> > Sent: Wednesday, November 15, 2006 12:13 PM
> --> > To: Silvano Gai
> --> > Cc: [e-mail]
> --> > Subject: RE: [rbridge] IVLANs vs OVLANs
> --> >
> --> > Silvano,
> --> >
> --> > 	First of all, I will take very large exception to the
way
> --> > which you have over-loaded the term "CRED."  This term was
coined
> --> > to eliminate confusion caused by the various different was
people
> --> > were over-loading the term "Campus."
> --> >
> --> > 	At the "core" of your question, however, is the issue of
> --> > how VLANs interact in a bridged/RBridge environment.  It is not
> --> > different than would be the case in a "classical bridged LAN."
> --> >
> --> > 	This issue is based on a misconception that existed very
> --> > early on in the life of the TRILL working group (in the first
> --> > BoF, in fact).  The misconception is that VLAN connectivity may
> --> > be provided by RBridges and/or bridges.
> --> >
> --> > 	This is fundamentally incorrect.
> --> >
> --> > 	Interconnection of VLANs is strictly a routing function.
> --> > In deployed equipment that does this today, there may be some
> --> > form of "smart VLAN bridging" that occurs in devices people are
> --> > used to referring to as "bridges" or "switches."  That does not
> --> > change the fact that forwarding from one VLAN to another is a
> --> > "routing function."
> --> >
> --> > 	Note that, in this context, when I say "forwarding from
> --> > one VLAN to another" - I mean "VLAN" in the sense of "virtual
> --> > LAN" as a logical concept.  This has nothing to do with the fact
> --> > that a VLAN ID might change in traversing a VLAN-aware bridge.
> --> >
> --> > 	Consequently, in the picture you have below, the VLANs
> --> > represented by the VLAN-tag in the tunnel encapsulation may
> --> > not be connected together by RB1.
> --> >
> --> > 	To correctly restate your question, the original
topology
> --> > would be as follows:
> --> >
> --> >
> --> >                 +-----+  1,2  +-----------+
> --> >                 | RB1 |-------| Rtg Fnctn |
> --> >                 +-----+       +-----------+
> --> >                    |
> --> >                    | 1,2
> --> >                    |
> --> >  +-----+   1    +-----+    2     +-----+
> --> >  | RB2 |--------| SW1 |----------| RB3 |
> --> >  +-----+        +-----+          +-----+
> --> >
> --> > The resulting logical topology MUST then be as follows:
> --> >
> --> >
> --> >  +-----+        +-----+       +-----------+
> --> >  | RB2 |--------| RB1 |-------| Rtg Fnctn |
> --> >  +-----+        +-----+       +-----+-----+
> --> >                                     |
> --> >                                  +--+--+          +-----+
> --> >                                  | RB1 |----------| RB3 |
> --> >                                  +-----+          +-----+
> --> >
> --> > Since the "routing function" is orthogonal, and well understood,
> --> > it does not make sense for us to try to combine this concept
with
> --> > RBridge behaviors and protocol interactions.
> --> >
> --> > --
> --> > Eric
> --> >
> --> >
> --> > --> -----Original Message-----
> --> > --> From: [e-mail]
> --> > --> [mailto:[e-mail]] On Behalf Of Silvano Gai
> --> > --> Sent: Tuesday, November 14, 2006 8:11 PM
> --> > --> To: [e-mail]
> --> > --> Subject: [rbridge] IVLANs vs OVLANs
> --> > -->
> --> > -->
> --> > --> During the last WG meeting I had an action item to send an
> --> > --> email on the
> --> > --> VLAN issue. Here it is.
> --> > -->
> --> > --> In a previous email I introduced the concept of IVLAN
> --> and OVLAN.
> --> > -->
> --> > --> IVLAN refers to the VLAN present on the untagged frames,
> --> > --> which must be
> --> > --> propagated by ISIS, VLAN pruning must be performed and so
> --> > --> on. All the
> --> > --> IVLANs share the same core instance of ISIS.
> --> > -->
> --> > --> OVLAN refers to the fact that the traffic between two
> --> > --> RBridges can be
> --> > --> encapsulated into a VLAN.
> --> > -->
> --> > --> If we look to the format of a TRILL encapsulated frame the
> --> > --> position of
> --> > --> these two fields is as follow:
> --> > -->
> --> > --> +--------------------------------+
> --> > --> |               DA               |
> --> > --> +----------------+---------------+
> --> > --> |       DA       |     SA        |
> --> > --> +----------------+---------------+
> --> > --> |               SA               |
> --> > --> +--------------------------------+
> --> > --> |    ET = 1Q     |   OVLAN ...   |
> --> > --> +--------------------------------+
> --> > --> |    ET = TRILL  | RES  |  TTL   |
> --> > --> +--------------------------------+
> --> > --> | Egress Add.    | Ingress Add.  |
> --> > --> +--------------------------------+
> --> > --> |               DA               |
> --> > --> +----------------+---------------+
> --> > --> |       DA       |     SA        |
> --> > --> +----------------+---------------+
> --> > --> |               SA               |
> --> > --> +--------------------------------+
> --> > --> |    ET = 1Q     |   IVLAN ...   |
> --> > --> +--------------------------------+
> --> > --> |             Payload            |
> --> > -->
> --> > --> Now let's consider the following topology:
> --> > -->
> --> > -->                +-----+
> --> > -->                | RB1 |
> --> > -->                +-----+
> --> > -->                   |
> --> > -->                   | 1,2
> --> > -->                   |
> --> > --> +-----+   1    +-----+    2     +-----+
> --> > --> | RB2 |--------| SW1 |----------| RB3 |
> --> > --> +-----+        +-----+          +-----+
> --> > -->
> --> > --> RB1, RB2, RB3 are Rbridges, SW1 is a classical
> --> Ethernet switch.
> --> > --> The link between RB2 and SW1 is in OVLAN 1, the link
> --> > --> between SW1 and RB3
> --> > --> is in OVLAN 2 and the links between SW1 and RB1 is a
> --> trunk and it
> --> > --> carries both OVLAN 1 and 2.
> --> > -->
> --> > --> Now my question is: "do we have one CRED or two?"
> --> > -->
> --> > --> a) possible answer: "we have one CRED". RB2 is adjacent to
> --> > --> RB1 but not
> --> > --> to RB3. The same applies to RB3 that is adjacent to RB1,
> --> > --> but not RB2.
> --> > --> RB1 is adjacent to both RB2 and RB3. There is a single core
> --> > --> instance of
> --> > --> ISIS. RB2 may reach RB3 through RB1.
> --> > -->
> --> > --> The TRILL equivalent topology is:
> --> > -->
> --> > --> +-----+        +-----+          +-----+
> --> > --> | RB2 |--------| RB1 |----------| RB3 |
> --> > --> +-----+        +-----+          +-----+
> --> > -->
> --> > --> b) another possible answer: "we have two CREDs". One is
> --> > --> composed by RB2
> --> > --> and RB1, the other by RB3 and RB1. RB2 may not reach RB3,
> --> > --> since they are
> --> > --> in different CREDs.
> --> > -->
> --> > --> The TRILL equivalent topologies are:
> --> > -->
> --> > --> +-----+        +-----+
> --> > --> | RB2 |--------| RB1 |
> --> > --> +-----+        +-----+
> --> > -->
> --> > --> +-----+          +-----+
> --> > --> | RB1 |----------| RB3 |
> --> > --> +-----+          +-----+
> --> > -->
> --> > --> I like a) and I hope we are in agreement that the right
> --> > --> answer is a),
> --> > --> but I haven't seen it explained in any of the documents.
> --> > -->
> --> > --> -- Silvano
> --> > -->
> --> > --> _______________________________________________
> --> > --> rbridge mailing list
> --> > --> [e-mail]
> --> > --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> > -->
> -->



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAH1AOPs001669 for <[e-mail]>; Thu, 16 Nov 2006 17:10:24 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Thu, 16 Nov 2006 17:10:21 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] IVLANs vs OVLANs
Thread-Index: AccJlEFwINs0f3GOQS+REv0qmzkp+AAT0JCQ
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAH1AOPs001669
Cc: [e-mail]
Subject: Re: [rbridge] IVLANs vs OVLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Nov 2006 01:10:45 -0000
Status: RO
Content-Length: 11250

Eric,

Inline the reply to your email, can you now reply to my email with the
two hosts added and explain me why I am incorrect?

Thank You

-- Silvano


> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Thursday, November 16, 2006 7:31 AM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: RE: [rbridge] IVLANs vs OVLANs
> 
> Silvano,
> 
> 	Sorry, but you are incorrect.
> 
> 	Routers are "end-stations" to a layer 2 network - hence it is
> necessarily the case that TRILL frames MUST egress the RBridge CRED
> prior to being delivered to a "routing function."  In the same way,
> any frame delivered frome a "routing function" MUST ingress the CRED
> for subsequent delivery in the form of TRILL frames.
> 
> 	This is a logical distinction and does not - in any way - limit
> your implementation choices.  Logically, what happens is:
> 
> 1) the TRILL encapsulation is stripped, along with the SHIM header.

This happens only if the Dest. RBridge address in the shim matches the
RBridge address.

In the moment you strip the outer header, what do you do with the OVLAN
information? Do you simply discard it? This is key and I need a clear
reply to this question.

> 2) the frame is forwarded (possibly locally, possibly only logically)
>    to the component that implements the "routing function",

One step at the time: the frame is passed to the bridging function of
the IVLAN.

The bridging function of the IVLAN delivers the frame according to its
inner destination MAC address.

If and only if the inner destination MAC address is that of a router the
frame is delivered to the sub-interface of the router associated with
the IVLAN.

> 3) the remaining Ethernet header is stripped, delivering the data (an
>    IP packet) - along with relevant packet information (such as
length)
>    - to the "routing function",
> 4) the "routing function" is used (including, for example ACLs, policy
>    based forwarding, etc.) to determine how to forward the _packet_ -
>    including forwarding to a logical "interface" on a distinct VLAN,

This VLAN is an IVLAN, not an OVLAN.

> 5) after the forwarding decision is made, appropriate encapsulation is
>    added to the IP packet, again converting it (in this case) to an
>    Ethernet frame,
> 6) the resulting Ethernet frame is forwarded (possibly locally,
possibly
>    only logically) from the component implementing the "routing
function"
>    to the appropriate RBridge component,

The frame is delivered to the bridging function associated to the new
IVLAN.
If a designated RBridge is connected to that bridging function, the
frame will be reencapsulated and transmitted.


-- Silvano

> 7) the RBridge component then provides ingress for the frame by adding
>    a SHIM and re-encapsulating the frame with the appropriate TRILL
>    encapsulation.
> 
> 	To RE-EMPHASIZE, this is what happens logically.  What you do in
> your implementation may differ substantially from this.  It may - for
> example - be quite a bit simpler.  How you do this is why you get paid
> the big bucks.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[e-mail]]
> --> Sent: Thursday, November 16, 2006 1:45 AM
> --> To: Gray, Eric
> --> Cc: [e-mail]
> --> Subject: RE: [rbridge] IVLANs vs OVLANs
> -->
> -->
> --> Eric,
> -->
> --> On a second thought, you cannot put a router between OVLAN=1 and
> --> OVLAN=2, the frame is not routable, since its Ethertype is
> --> TRILL, not
> --> IPv4 or IPv6.
> -->
> --> -- Silvano
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:[e-mail]]
> --> > Sent: Wednesday, November 15, 2006 12:13 PM
> --> > To: Silvano Gai
> --> > Cc: [e-mail]
> --> > Subject: RE: [rbridge] IVLANs vs OVLANs
> --> >
> --> > Silvano,
> --> >
> --> > 	First of all, I will take very large exception to the
way
> --> > which you have over-loaded the term "CRED."  This term was
coined
> --> > to eliminate confusion caused by the various different was
people
> --> > were over-loading the term "Campus."
> --> >
> --> > 	At the "core" of your question, however, is the issue of
> --> > how VLANs interact in a bridged/RBridge environment.  It is not
> --> > different than would be the case in a "classical bridged LAN."
> --> >
> --> > 	This issue is based on a misconception that existed very
> --> > early on in the life of the TRILL working group (in the first
> --> > BoF, in fact).  The misconception is that VLAN connectivity may
> --> > be provided by RBridges and/or bridges.
> --> >
> --> > 	This is fundamentally incorrect.
> --> >
> --> > 	Interconnection of VLANs is strictly a routing function.
> --> > In deployed equipment that does this today, there may be some
> --> > form of "smart VLAN bridging" that occurs in devices people are
> --> > used to referring to as "bridges" or "switches."  That does not
> --> > change the fact that forwarding from one VLAN to another is a
> --> > "routing function."
> --> >
> --> > 	Note that, in this context, when I say "forwarding from
> --> > one VLAN to another" - I mean "VLAN" in the sense of "virtual
> --> > LAN" as a logical concept.  This has nothing to do with the fact
> --> > that a VLAN ID might change in traversing a VLAN-aware bridge.
> --> >
> --> > 	Consequently, in the picture you have below, the VLANs
> --> > represented by the VLAN-tag in the tunnel encapsulation may
> --> > not be connected together by RB1.
> --> >
> --> > 	To correctly restate your question, the original
topology
> --> > would be as follows:
> --> >
> --> >
> --> >                 +-----+  1,2  +-----------+
> --> >                 | RB1 |-------| Rtg Fnctn |
> --> >                 +-----+       +-----------+
> --> >                    |
> --> >                    | 1,2
> --> >                    |
> --> >  +-----+   1    +-----+    2     +-----+
> --> >  | RB2 |--------| SW1 |----------| RB3 |
> --> >  +-----+        +-----+          +-----+
> --> >
> --> > The resulting logical topology MUST then be as follows:
> --> >
> --> >
> --> >  +-----+        +-----+       +-----------+
> --> >  | RB2 |--------| RB1 |-------| Rtg Fnctn |
> --> >  +-----+        +-----+       +-----+-----+
> --> >                                     |
> --> >                                  +--+--+          +-----+
> --> >                                  | RB1 |----------| RB3 |
> --> >                                  +-----+          +-----+
> --> >
> --> > Since the "routing function" is orthogonal, and well understood,
> --> > it does not make sense for us to try to combine this concept
with
> --> > RBridge behaviors and protocol interactions.
> --> >
> --> > --
> --> > Eric
> --> >
> --> >
> --> > --> -----Original Message-----
> --> > --> From: [e-mail]
> --> > --> [mailto:[e-mail]] On Behalf Of Silvano Gai
> --> > --> Sent: Tuesday, November 14, 2006 8:11 PM
> --> > --> To: [e-mail]
> --> > --> Subject: [rbridge] IVLANs vs OVLANs
> --> > -->
> --> > -->
> --> > --> During the last WG meeting I had an action item to send an
> --> > --> email on the
> --> > --> VLAN issue. Here it is.
> --> > -->
> --> > --> In a previous email I introduced the concept of IVLAN
> --> and OVLAN.
> --> > -->
> --> > --> IVLAN refers to the VLAN present on the untagged frames,
> --> > --> which must be
> --> > --> propagated by ISIS, VLAN pruning must be performed and so
> --> > --> on. All the
> --> > --> IVLANs share the same core instance of ISIS.
> --> > -->
> --> > --> OVLAN refers to the fact that the traffic between two
> --> > --> RBridges can be
> --> > --> encapsulated into a VLAN.
> --> > -->
> --> > --> If we look to the format of a TRILL encapsulated frame the
> --> > --> position of
> --> > --> these two fields is as follow:
> --> > -->
> --> > --> +--------------------------------+
> --> > --> |               DA               |
> --> > --> +----------------+---------------+
> --> > --> |       DA       |     SA        |
> --> > --> +----------------+---------------+
> --> > --> |               SA               |
> --> > --> +--------------------------------+
> --> > --> |    ET = 1Q     |   OVLAN ...   |
> --> > --> +--------------------------------+
> --> > --> |    ET = TRILL  | RES  |  TTL   |
> --> > --> +--------------------------------+
> --> > --> | Egress Add.    | Ingress Add.  |
> --> > --> +--------------------------------+
> --> > --> |               DA               |
> --> > --> +----------------+---------------+
> --> > --> |       DA       |     SA        |
> --> > --> +----------------+---------------+
> --> > --> |               SA               |
> --> > --> +--------------------------------+
> --> > --> |    ET = 1Q     |   IVLAN ...   |
> --> > --> +--------------------------------+
> --> > --> |             Payload            |
> --> > -->
> --> > --> Now let's consider the following topology:
> --> > -->
> --> > -->                +-----+
> --> > -->                | RB1 |
> --> > -->                +-----+
> --> > -->                   |
> --> > -->                   | 1,2
> --> > -->                   |
> --> > --> +-----+   1    +-----+    2     +-----+
> --> > --> | RB2 |--------| SW1 |----------| RB3 |
> --> > --> +-----+        +-----+          +-----+
> --> > -->
> --> > --> RB1, RB2, RB3 are Rbridges, SW1 is a classical
> --> Ethernet switch.
> --> > --> The link between RB2 and SW1 is in OVLAN 1, the link
> --> > --> between SW1 and RB3
> --> > --> is in OVLAN 2 and the links between SW1 and RB1 is a
> --> trunk and it
> --> > --> carries both OVLAN 1 and 2.
> --> > -->
> --> > --> Now my question is: "do we have one CRED or two?"
> --> > -->
> --> > --> a) possible answer: "we have one CRED". RB2 is adjacent to
> --> > --> RB1 but not
> --> > --> to RB3. The same applies to RB3 that is adjacent to RB1,
> --> > --> but not RB2.
> --> > --> RB1 is adjacent to both RB2 and RB3. There is a single core
> --> > --> instance of
> --> > --> ISIS. RB2 may reach RB3 through RB1.
> --> > -->
> --> > --> The TRILL equivalent topology is:
> --> > -->
> --> > --> +-----+        +-----+          +-----+
> --> > --> | RB2 |--------| RB1 |----------| RB3 |
> --> > --> +-----+        +-----+          +-----+
> --> > -->
> --> > --> b) another possible answer: "we have two CREDs". One is
> --> > --> composed by RB2
> --> > --> and RB1, the other by RB3 and RB1. RB2 may not reach RB3,
> --> > --> since they are
> --> > --> in different CREDs.
> --> > -->
> --> > --> The TRILL equivalent topologies are:
> --> > -->
> --> > --> +-----+        +-----+
> --> > --> | RB2 |--------| RB1 |
> --> > --> +-----+        +-----+
> --> > -->
> --> > --> +-----+          +-----+
> --> > --> | RB1 |----------| RB3 |
> --> > --> +-----+          +-----+
> --> > -->
> --> > --> I like a) and I hope we are in agreement that the right
> --> > --> answer is a),
> --> > --> but I haven't seen it explained in any of the documents.
> --> > -->
> --> > --> -- Silvano
> --> > -->
> --> > --> _______________________________________________
> --> > --> rbridge mailing list
> --> > --> [e-mail]
> --> > --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> > -->
> -->



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAGLtsFY020494 for <[e-mail]>; Thu, 16 Nov 2006 13:55:55 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kAGLtpfK004597; Thu, 16 Nov 2006 16:55:51 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA02487;  Thu, 16 Nov 2006 16:55:47 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB6VCX07>; Thu, 16 Nov 2006 16:55:46 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Silvano Gai'" <[e-mail]>, "Gray, Eric" <[e-mail]>, Russ White <[e-mail]>
Date: Thu, 16 Nov 2006 16:55:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] IVLANs vs OVLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2006 21:56:11 -0000
Status: RO
Content-Length: 12594

Silvano,

	You need to read my other mail.

	Once you realize that there are logical models that apply, and
start using them, it should become clear to you why there is not a
really useful reason to make the distinction you're making between
the VLANs that may exist for RBridges and the VANs that may exist 
around the RBridges.  They are logically distinct, not philosophically
distinct...

--
Eric

-----Original Message-----
From: Silvano Gai [mailto:[e-mail]] 
Sent: Thursday, November 16, 2006 11:01 AM
To: Gray, Eric; Russ White
Cc: [e-mail]
Subject: RE: [rbridge] IVLANs vs OVLANs

Eric,

> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Thursday, November 16, 2006 7:39 AM
> To: Silvano Gai; Russ White
> Cc: [e-mail]
> Subject: RE: [rbridge] IVLANs vs OVLANs
> 
> Silvano,			(note: Russ - please read this!!)
> 
> 	For the first part of your question, Radia and I had almost
> this exact same discussion during the BoF I mentioned.  The only
> legitimate way to get from one (logical) VLAN to another is via a
> routing function.

Eric you really need to start to think in term of OVLAN and IVLAN and in
term of access ports and trunk port. The fact that products may use the
same port to be a trunk and an access at the same time is OK, so as it
is OK that the IVLANs and OVLANs are both implemented used using the 1Q
tagging scheme.

Without a clear terminology we will not be able to agree on anything.

What you are saying is not true for OVLANs. A frame, when it has an
OVLAN, i.e. it is on a trunk port, i.e. it has a TRILL shim, i.e. it has
an outer header, CANNOT have the outer MAC address of a router.
Therefore saying that "The only legitimate way to get from one (logical)
VLAN to another is via a
routing function" is incorrect in the case of OVLANs.

It may be the common case for IVLANs, but there are exceptions in today
networks, starting from NAT.

-- Silvano



> 
> 	Unless you include the "routing function" as part of the TRILL
> specification requirements - which does not, in any way, makes sense
> - then the model that applies is the one that has VLANs logically
> separated.
> 
> 	That is strictly a VLAN separation issue.  The second part of
> your question is trickier, hence it is good that you ask it and even
> better that you insisted on being understood.  :-)
> 
> 	From an RBridge perspective, I believe it is sufficient that all
> of the RBridges MUST support a common (probably the default - NULL)
> VLAN to ensure that all of them MUST peer with each other - at least
> for support of that (common) VLAN.  Hence, it should not be the case
> that any (proper) subset of RBridges would not peer exclusively with
> any other (proper) subset of RBridges in the same CRED.
> 
> 	Also, from an IS-IS perspective (help me out here Russ), I am
> reasonably sure that adjacent/connected IS-IS instances MUST discover
> each other during peer discovery - even if they do not subsequently
> peer with each other (or having peered with each other, exchange any
> routing information).  I believe this would be the case, even if there
> was potentially some strange virtual L3 overlay topology involving
> separate L3 VPN instancing in the IS-IS routing deployment.
> 
> 	If that is the case, then - from a peer discovery perspective -
> all RBridges will still be in the same CRED.  This is the perspective
> that matters, because it is the peer discovery process that allows the
> members of a CRED to "discover" potential _hidden_ loops in underlying
> L2 topology.
> 
> 	See also my reply to your question about VLAN interactions with
> routing...
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[e-mail]]
> --> Sent: Thursday, November 16, 2006 12:57 AM
> --> To: Gray, Eric
> --> Cc: [e-mail]
> --> Subject: RE: [rbridge] IVLANs vs OVLANs
> -->
> -->
> --> Eric,
> -->
> --> I am just trying to understand if there is consensus in a) or b).
> -->
> --> The impression I got talking with Radia is that she was in
> --> favor of a).
> -->
> --> Your reply is my b) model to which you have added a router.
> --> Since b) is
> --> two separate layer 2 networks, you can put a router between
> --> the two, as
> --> you did.
> -->
> --> Please also note that I can redraw the same network in a
> --> different way:
> -->
> -->                 +-----+
> -->                 | RB1 |
> -->                 +-----+
> -->                  |  |
> -->                1 |  | 2
> -->                  |  |
> -->  +-----+   1    +-----+    2     +-----+
> -->  | RB2 |--------| SW1 |----------| RB3 |
> -->  +-----+        +-----+          +-----+
> -->
> --> Where I replaced the Etherchannel with two links, one in
> --> OVLAN=1 and one
> --> in OVLAN=2.
> -->
> --> Now is RB2 capable of talking to RB3 through RB1?
> -->
> --> -- Silvano
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:[e-mail]]
> --> > Sent: Wednesday, November 15, 2006 12:13 PM
> --> > To: Silvano Gai
> --> > Cc: [e-mail]
> --> > Subject: RE: [rbridge] IVLANs vs OVLANs
> --> >
> --> > Silvano,
> --> >
> --> > 	First of all, I will take very large exception to the
way
> --> > which you have over-loaded the term "CRED."  This term was
coined
> --> > to eliminate confusion caused by the various different was
people
> --> > were over-loading the term "Campus."
> --> >
> --> > 	At the "core" of your question, however, is the issue of
> --> > how VLANs interact in a bridged/RBridge environment.  It is not
> --> > different than would be the case in a "classical bridged LAN."
> --> >
> --> > 	This issue is based on a misconception that existed very
> --> > early on in the life of the TRILL working group (in the first
> --> > BoF, in fact).  The misconception is that VLAN connectivity may
> --> > be provided by RBridges and/or bridges.
> --> >
> --> > 	This is fundamentally incorrect.
> --> >
> --> > 	Interconnection of VLANs is strictly a routing function.
> --> > In deployed equipment that does this today, there may be some
> --> > form of "smart VLAN bridging" that occurs in devices people are
> --> > used to referring to as "bridges" or "switches."  That does not
> --> > change the fact that forwarding from one VLAN to another is a
> --> > "routing function."
> --> >
> --> > 	Note that, in this context, when I say "forwarding from
> --> > one VLAN to another" - I mean "VLAN" in the sense of "virtual
> --> > LAN" as a logical concept.  This has nothing to do with the fact
> --> > that a VLAN ID might change in traversing a VLAN-aware bridge.
> --> >
> --> > 	Consequently, in the picture you have below, the VLANs
> --> > represented by the VLAN-tag in the tunnel encapsulation may
> --> > not be connected together by RB1.
> --> >
> --> > 	To correctly restate your question, the original
topology
> --> > would be as follows:
> --> >
> --> >
> --> >                 +-----+  1,2  +-----------+
> --> >                 | RB1 |-------| Rtg Fnctn |
> --> >                 +-----+       +-----------+
> --> >                    |
> --> >                    | 1,2
> --> >                    |
> --> >  +-----+   1    +-----+    2     +-----+
> --> >  | RB2 |--------| SW1 |----------| RB3 |
> --> >  +-----+        +-----+          +-----+
> --> >
> --> > The resulting logical topology MUST then be as follows:
> --> >
> --> >
> --> >  +-----+        +-----+       +-----------+
> --> >  | RB2 |--------| RB1 |-------| Rtg Fnctn |
> --> >  +-----+        +-----+       +-----+-----+
> --> >                                     |
> --> >                                  +--+--+          +-----+
> --> >                                  | RB1 |----------| RB3 |
> --> >                                  +-----+          +-----+
> --> >
> --> > Since the "routing function" is orthogonal, and well understood,
> --> > it does not make sense for us to try to combine this concept
with
> --> > RBridge behaviors and protocol interactions.
> --> >
> --> > --
> --> > Eric
> --> >
> --> >
> --> > --> -----Original Message-----
> --> > --> From: [e-mail]
> --> > --> [mailto:[e-mail]] On Behalf Of Silvano Gai
> --> > --> Sent: Tuesday, November 14, 2006 8:11 PM
> --> > --> To: [e-mail]
> --> > --> Subject: [rbridge] IVLANs vs OVLANs
> --> > -->
> --> > -->
> --> > --> During the last WG meeting I had an action item to send an
> --> > --> email on the
> --> > --> VLAN issue. Here it is.
> --> > -->
> --> > --> In a previous email I introduced the concept of IVLAN
> --> and OVLAN.
> --> > -->
> --> > --> IVLAN refers to the VLAN present on the untagged frames,
> --> > --> which must be
> --> > --> propagated by ISIS, VLAN pruning must be performed and so
> --> > --> on. All the
> --> > --> IVLANs share the same core instance of ISIS.
> --> > -->
> --> > --> OVLAN refers to the fact that the traffic between two
> --> > --> RBridges can be
> --> > --> encapsulated into a VLAN.
> --> > -->
> --> > --> If we look to the format of a TRILL encapsulated frame the
> --> > --> position of
> --> > --> these two fields is as follow:
> --> > -->
> --> > --> +--------------------------------+
> --> > --> |               DA               |
> --> > --> +----------------+---------------+
> --> > --> |       DA       |     SA        |
> --> > --> +----------------+---------------+
> --> > --> |               SA               |
> --> > --> +--------------------------------+
> --> > --> |    ET = 1Q     |   OVLAN ...   |
> --> > --> +--------------------------------+
> --> > --> |    ET = TRILL  | RES  |  TTL   |
> --> > --> +--------------------------------+
> --> > --> | Egress Add.    | Ingress Add.  |
> --> > --> +--------------------------------+
> --> > --> |               DA               |
> --> > --> +----------------+---------------+
> --> > --> |       DA       |     SA        |
> --> > --> +----------------+---------------+
> --> > --> |               SA               |
> --> > --> +--------------------------------+
> --> > --> |    ET = 1Q     |   IVLAN ...   |
> --> > --> +--------------------------------+
> --> > --> |             Payload            |
> --> > -->
> --> > --> Now let's consider the following topology:
> --> > -->
> --> > -->                +-----+
> --> > -->                | RB1 |
> --> > -->                +-----+
> --> > -->                   |
> --> > -->                   | 1,2
> --> > -->                   |
> --> > --> +-----+   1    +-----+    2     +-----+
> --> > --> | RB2 |--------| SW1 |----------| RB3 |
> --> > --> +-----+        +-----+          +-----+
> --> > -->
> --> > --> RB1, RB2, RB3 are Rbridges, SW1 is a classical
> --> Ethernet switch.
> --> > --> The link between RB2 and SW1 is in OVLAN 1, the link
> --> > --> between SW1 and RB3
> --> > --> is in OVLAN 2 and the links between SW1 and RB1 is a
> --> trunk and it
> --> > --> carries both OVLAN 1 and 2.
> --> > -->
> --> > --> Now my question is: "do we have one CRED or two?"
> --> > -->
> --> > --> a) possible answer: "we have one CRED". RB2 is adjacent to
> --> > --> RB1 but not
> --> > --> to RB3. The same applies to RB3 that is adjacent to RB1,
> --> > --> but not RB2.
> --> > --> RB1 is adjacent to both RB2 and RB3. There is a single core
> --> > --> instance of
> --> > --> ISIS. RB2 may reach RB3 through RB1.
> --> > -->
> --> > --> The TRILL equivalent topology is:
> --> > -->
> --> > --> +-----+        +-----+          +-----+
> --> > --> | RB2 |--------| RB1 |----------| RB3 |
> --> > --> +-----+        +-----+          +-----+
> --> > -->
> --> > --> b) another possible answer: "we have two CREDs". One is
> --> > --> composed by RB2
> --> > --> and RB1, the other by RB3 and RB1. RB2 may not reach RB3,
> --> > --> since they are
> --> > --> in different CREDs.
> --> > -->
> --> > --> The TRILL equivalent topologies are:
> --> > -->
> --> > --> +-----+        +-----+
> --> > --> | RB2 |--------| RB1 |
> --> > --> +-----+        +-----+
> --> > -->
> --> > --> +-----+          +-----+
> --> > --> | RB1 |----------| RB3 |
> --> > --> +-----+          +-----+
> --> > -->
> --> > --> I like a) and I hope we are in agreement that the right
> --> > --> answer is a),
> --> > --> but I haven't seen it explained in any of the documents.
> --> > -->
> --> > --> -- Silvano
> --> > -->
> --> > --> _______________________________________________
> --> > --> rbridge mailing list
> --> > --> [e-mail]
> --> > --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> > -->
> -->


Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAGI0V0F025722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 16 Nov 2006 10:00:32 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 56B36A53A8; Thu, 16 Nov 2006 19:00:30 +0100 (CET)
Received: from [163.117.139.71] (gibanez.it.uc3m.es [163.117.139.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id E8646A5038; Thu, 16 Nov 2006 19:00:29 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 16 Nov 2006 19:00:29 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Silvano Gai <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2006 18:00:42 -0000
Status: RO
Content-Length: 9213

Silvano,
      I am glad you appreciate the value of hierarchy in L2 addresses.
       Can you elaborate on 2) ? Sorry, but I do not catch the idea.
Guillermo

Silvano Gai escribi?:
> Eric,
>
>
>   
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Gray, Eric
>> Sent: Wednesday, November 15, 2006 1:32 PM
>> To: Guillermo Ib??ez; J. R. Rivers
>> Cc: [e-mail]; Radia Perlman
>> Subject: Re: [rbridge] Should we optimize the common case?
>>
>> Guillermo,
>>
>> 	In an ideal world, this would be true.  However, these ideas
>> are recurring and - as a strictly practical issue - they have to
>> cooperate in a world that has moved on from past iterations of the
>> same ideas.
>>
>> 	For the most part, the answer you're going to find here is:
>> if you need hierarchical addressing, you've come to the right place
>> - just use IP...
>>     
>
> Can we stop making this argument? It is not constructive.
> I think Guillermo understand the difference between Layer 2 and IP, as well as we do.
>
> I am not sure I agree the TRILL should use Hierarchical MAC addresses, but I definitely agree that this has been proposed in several different forums/occasions and it has some value.
>
> We also need to clearly say that there are two different possible uses of Hierarchical MAC Addresses:
>
> 1) The switch assigns to the end node of a hierarchical MAC address. This goes in the inner header.
>
> 2) The switch uses in the outer header hierarchical MAC addresses to encode different kind of information.
>
> IMHO 1) is interesting but it does not support legacy and therefore is pragmatically difficult. I also don't believe in NATting the MAC addresses.
>
> 2) can be explored and used if needed.
>
> -- Silvano
>
>
>   
>> --
>> Eric
>>
>> --> -----Original Message-----
>> --> From: [e-mail]
>> --> [mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
>> --> Sent: Wednesday, November 15, 2006 10:32 AM
>> --> To: J. R. Rivers
>> --> Cc: [e-mail]; Radia Perlman
>> --> Subject: Re: [rbridge] Should we optimize the common case?
>> -->
>> --> While agreeing with some of the arguments, I see far from ideal for
>> --> scalability that RBridges advertise host lists with a
>> --> number of host L2
>> --> addresses impossible to consolidate.
>> --> Looking for some hierarchy and structure in L2 addresses,
>> --> although not
>> --> easy at first glance, may provide long term benefits in scalability.
>> --> Guillermo
>> -->
>> --> J. R. Rivers escribi?:
>> --> > I've worked on such systems, and while the address
>> --> summarization creates a degree of scale, you generally find
>> --> that the fixed association between endnode and switch is
>> --> very restricting and limiting.
>> --> >
>> --> > This is one of the reasons that I find TRILL very
>> --> clean... the relationship between an endnode and an rbridge
>> --> is that of convenience, not requirement.
>> --> >
>> --> > I can build multi-homed networks... assuming that an edge
>> --> rbridge can maintain multiple endhost->rbridge associations
>> --> without changing the forwarding constructs of the rbridge
>> --> "core".  This occurs because each edge rbridge advertises
>> --> reachability to the host.
>> --> >
>> --> > I can redirect frames through an rbridge network without
>> --> changing the underlying L2 constructs (as required by many
>> --> IDS/crypto protocols).  Then I can forward them to their
>> --> intended destinations.
>> --> >
>> --> > All of these require support from coordinating edge
>> --> rbridges... the endhosts, other edge rbridges, and core
>> --> rbridges are blissfully unaware of these goings on.
>> --> >
>> --> > All this comes from partitioning the system into a
>> --> simple, fast, cheap HW forwarding plane and a fully SW
>> --> managed control plane.
>> --> >
>> --> > JR
>> --> >
>> --> >
>> --> >
>> --> >> -----Original Message-----
>> --> >> From: Guillermo Ib??ez [mailto:[e-mail]]
>> --> >> Sent: Tuesday, November 14, 2006 2:37 AM
>> --> >> To: Caitlin Bestler; Radia Perlman; J. R. Rivers; Silvano Gai
>> --> >> Cc: [e-mail]
>> --> >> Subject: Re: [rbridge] Should we optimize the common case?
>> --> >>
>> --> >> I think there is a misunderstanding.  This is IMHO a
>> --> >> practical alternative:
>> --> >> -An RBridge port is connected to a  "link" and receives
>> --> frames from
>> --> >> multiple hosts:  The RBridge builds an internal
>> --> translation table of
>> --> >> global MACs to hierarchical MACs (HMACs) assigned by him
>> --> and replaces
>> --> >> global MAC by hierarchical MAC in the original frame.
>> --> >> -These hierarchical MAC addresses for hosts contain the RBridge
>> --> >> Nickname, so it becomes *part* of the complete host address
>> --> >> transmitted
>> --> >> as "original" frame.  So these addresses should contain
>> --> >> RBridge Nickname
>> --> >> with host nickname appended (internal grouping of host
>> --> nicknames per
>> --> >> RBridge port ID would also help). To be defined.
>> --> >> - Hierarchical MAC MAY also be used in the ARP response
>> --> packets (when
>> --> >> RBridge acts as proxy ARP or by interception of the host
>> --> response
>> --> >> packet), so the requester obtains the hierarchical MAC
>> --> >> address instead
>> --> >> of the global one and uses it for all transactions.
>> --> >> - The hosts with hierarchical MAC addresses do not need being
>> --> >> announced
>> --> >> by the RBridges in their host lists, because their DR RBridge
>> --> >> nickname
>> --> >> is included in the hierarchical MAC address of host in
>> --> the "original"
>> --> >> (now altered with HMAC) frame.
>> --> >> - Frames with inner hierarchical destination address need
>> --> >> only to read
>> --> >> the destination RBridge Nickname to obtain the egrees RBridge
>> --> >> (no need
>> --> >> to look host-RBridge table). The host list mechanism is
>> --> not used by
>> --> >> hosts whose RBridge handles them with hierarchical addressing.
>> --> >> Both types, global and local hierarchical addresses may
>> --> >> coexist. Local
>> --> >> hierarchical save processing and enhance scalability.
>> --> >> Hope this clarifies.
>> --> >> Guillermo
>> --> >>
>> --> >> PD.
>> --> >> Other issues
>> --> >> -DHCP-like mechanism
>> --> >> Hierarchical MACs can be assigned with DHCP like mechanism to
>> --> >> hosts, but
>> --> >> IMHO this has impact on end nodes, so it can not be the standard
>> --> >> mechanism, only an option.
>> --> >> - Generic hierarchical MAC addresses and masks (ref. Dr.
>> --> >> Morales slide)
>> --> >> I proposed the generic addressing format  that includes
>> --> hierarchical
>> --> >> masks looking for a generic addressing space, that could
>> --> be useful to
>> --> >> scale further RBridges in the future. I understand that at
>> --> >> this stage of
>> --> >> definition of RBridges to look for a fully generic
>> --> format could be
>> --> >> disruptive. However, the need for a generic hierarchical
>> --> addressing
>> --> >> space in Ethernet is growing.
>> --> >>
>> --> >>
>> --> >>
>> --> >>
>> --> >> Caitlin Bestler escribi?:
>> --> >>> Radia Perlman wrote:
>> --> >>>
>> --> >>>> Not sure I've been following this, but let me conjecture what
>> --> >>>> people are suggesting, and if I'm right about the suggestion,
>> --> >>>> I think it's a good idea. Correct me if it's not what
>> --> people are
>> --> >>>> saying.
>> --> >>>>
>> --> >>>> So I think what they are saying is the following:
>> --> >>>> a) there are cases where an RBridge has a block of addresses
>> --> >>>> (like DHCP) that it hands out to endnodes
>> --> >>>> b) in that case, it would be nice if the RBridge can
>> --> >>>> announce, in its LSP, the whole range of addresses, rather
>> --> >>>> than reporting each individually
>> --> >>>> c) the change would be an ability to express a range in the
>> --> >>>> endnode announcement. This seems easy, but I think it would
>> --> >>>> be best done with a 2nd TLV in IS-IS. The 1st TLV would be
>> --> >> individual
>> --> >>>> addresses. The 2nd TLV would be pairs of addresses
>> --> (low, high). Or
>> --> >>>> (low, increment), as in "starting with address X,
>> --> >>>> 32 addresses" (which would take up a bit less space
>> --> than two MAC
>> --> >>>> addresses.
>> --> >>>>
>> --> >>>> I don't think of this as a hierarchical address---I just
>> --> >>>> think of it as a range of addresses reachable from one RBridge.
>> --> >>>>
>> --> >>>>
>> --> >>> Reduction in the total number of reports required to support N
>> --> >>> addresses is probably the only benefit of "hierarchical
>> --> addresses"
>> --> >>> that we can achieve if we are going to support global-scope MAC
>> --> >>> addresses as well. Which I'm certain everyone agrees is a given.
>> --> >>>
>> --> >>>
>> --> >
>> --> _______________________________________________
>> --> rbridge mailing list
>> --> [e-mail]
>> --> http://mailman.postel.org/mailman/listinfo/rbridge
>> -->
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>     


Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAGHIW4e011563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 16 Nov 2006 09:18:34 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A5D8BA77C5; Thu, 16 Nov 2006 18:18:31 +0100 (CET)
Received: from [163.117.139.71] (gibanez.it.uc3m.es [163.117.139.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id B75C8A9F92; Thu, 16 Nov 2006 18:18:30 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 16 Nov 2006 18:18:30 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2006 17:18:38 -0000
Status: RO
Content-Length: 9677

Of course there are a lot of them that do.
But there are others that do not: Provider Backbone Bridges performs 
Ethernet based
tunnelling. 
Guillermo

Gray, Eric escribi?:
> Guillermo,
>
> 	Are you sure we are not?  Are there not a plethora of L2
> overlay services based on one or more IP-based tunneling schemes?
>
> --
> Eric 
>
> --> -----Original Message-----
> --> From: Guillermo Ib??ez [mailto:[e-mail]] 
> --> Sent: Thursday, November 16, 2006 1:42 AM
> --> To: Gray, Eric
> --> Cc: J. R. Rivers; [e-mail]; Radia Perlman
> --> Subject: Re: [rbridge] Should we optimize the common case?
> --> 
> --> 
> --> 
> --> Gray, Eric escribi?:
> --> > Guillermo,
> --> >
> --> > 	In an ideal world, this would be true.  However, these ideas
> --> > are recurring and - as a strictly practical issue - they have to 
> --> > cooperate in a world that has moved on from past 
> --> iterations of the 
> --> > same ideas
> --> >   
> --> > 	For the most part, the answer you're going to find here is:
> --> > if you need hierarchical addressing, you've come to the 
> --> right place
> --> >   
> --> > - just use IP...
> --> >   
> --> If this is so, why are not using IP to scale up  Metro 
> --> Ethernet Networks 
> --> and Provider Backbone Bridges? 
> --> > --
> --> > Eric
> --> >
> --> > --> -----Original Message-----
> --> > --> From: [e-mail] 
> --> > --> [mailto:[e-mail]] On Behalf Of 
> --> Guillermo Ib??ez
> --> > --> Sent: Wednesday, November 15, 2006 10:32 AM
> --> > --> To: J. R. Rivers
> --> > --> Cc: [e-mail]; Radia Perlman
> --> > --> Subject: Re: [rbridge] Should we optimize the common case?
> --> > --> 
> --> > --> While agreeing with some of the arguments, I see far 
> --> from ideal for 
> --> > --> scalability that RBridges advertise host lists with a 
> --> > --> number of host L2 
> --> > --> addresses impossible to consolidate.
> --> > --> Looking for some hierarchy and structure in L2 addresses, 
> --> > --> although not 
> --> > --> easy at first glance, may provide long term benefits 
> --> in scalability.
> --> > --> Guillermo
> --> > --> 
> --> > --> J. R. Rivers escribi?:
> --> > --> > I've worked on such systems, and while the address 
> --> > --> summarization creates a degree of scale, you generally find 
> --> > --> that the fixed association between endnode and switch is 
> --> > --> very restricting and limiting.  
> --> > --> > 
> --> > --> > This is one of the reasons that I find TRILL very 
> --> > --> clean... the relationship between an endnode and an rbridge 
> --> > --> is that of convenience, not requirement.
> --> > --> > 
> --> > --> > I can build multi-homed networks... assuming that an edge 
> --> > --> rbridge can maintain multiple endhost->rbridge associations 
> --> > --> without changing the forwarding constructs of the rbridge 
> --> > --> "core".  This occurs because each edge rbridge advertises 
> --> > --> reachability to the host.
> --> > --> > 
> --> > --> > I can redirect frames through an rbridge network without 
> --> > --> changing the underlying L2 constructs (as required by many 
> --> > --> IDS/crypto protocols).  Then I can forward them to their 
> --> > --> intended destinations.
> --> > --> > 
> --> > --> > All of these require support from coordinating edge 
> --> > --> rbridges... the endhosts, other edge rbridges, and core 
> --> > --> rbridges are blissfully unaware of these goings on.
> --> > --> > 
> --> > --> > All this comes from partitioning the system into a 
> --> > --> simple, fast, cheap HW forwarding plane and a fully SW 
> --> > --> managed control plane.
> --> > --> > 
> --> > --> > JR
> --> > --> > 
> --> > --> > 
> --> > --> > 
> --> > --> >> -----Original Message-----
> --> > --> >> From: Guillermo Ib??ez [mailto:[e-mail]] 
> --> > --> >> Sent: Tuesday, November 14, 2006 2:37 AM
> --> > --> >> To: Caitlin Bestler; Radia Perlman; J. R. Rivers; 
> --> Silvano Gai
> --> > --> >> Cc: [e-mail]
> --> > --> >> Subject: Re: [rbridge] Should we optimize the common case?
> --> > --> >>
> --> > --> >> I think there is a misunderstanding.  This is IMHO a 
> --> > --> >> practical alternative:
> --> > --> >> -An RBridge port is connected to a  "link" and receives 
> --> > --> frames from 
> --> > --> >> multiple hosts:  The RBridge builds an internal 
> --> > --> translation table of  
> --> > --> >> global MACs to hierarchical MACs (HMACs) assigned by him 
> --> > --> and replaces 
> --> > --> >> global MAC by hierarchical MAC in the original frame.
> --> > --> >> -These hierarchical MAC addresses for hosts 
> --> contain the RBridge 
> --> > --> >> Nickname, so it becomes *part* of the complete 
> --> host address 
> --> > --> >> transmitted 
> --> > --> >> as "original" frame.  So these addresses should contain 
> --> > --> >> RBridge Nickname 
> --> > --> >> with host nickname appended (internal grouping of host 
> --> > --> nicknames per 
> --> > --> >> RBridge port ID would also help). To be defined.
> --> > --> >> - Hierarchical MAC MAY also be used in the ARP response 
> --> > --> packets (when 
> --> > --> >> RBridge acts as proxy ARP or by interception of the host 
> --> > --> response 
> --> > --> >> packet), so the requester obtains the hierarchical MAC 
> --> > --> >> address instead 
> --> > --> >> of the global one and uses it for all transactions.
> --> > --> >> - The hosts with hierarchical MAC addresses do not 
> --> need being 
> --> > --> >> announced 
> --> > --> >> by the RBridges in their host lists, because their 
> --> DR RBridge 
> --> > --> >> nickname  
> --> > --> >> is included in the hierarchical MAC address of host in 
> --> > --> the "original" 
> --> > --> >> (now altered with HMAC) frame.
> --> > --> >> - Frames with inner hierarchical destination address need 
> --> > --> >> only to read 
> --> > --> >> the destination RBridge Nickname to obtain the 
> --> egrees RBridge 
> --> > --> >> (no need 
> --> > --> >> to look host-RBridge table). The host list mechanism is 
> --> > --> not used by  
> --> > --> >> hosts whose RBridge handles them with hierarchical 
> --> addressing. 
> --> > --> >> Both types, global and local hierarchical addresses may 
> --> > --> >> coexist. Local 
> --> > --> >> hierarchical save processing and enhance scalability.
> --> > --> >> Hope this clarifies.
> --> > --> >> Guillermo
> --> > --> >>
> --> > --> >> PD.
> --> > --> >> Other issues
> --> > --> >> -DHCP-like mechanism
> --> > --> >> Hierarchical MACs can be assigned with DHCP like 
> --> mechanism to 
> --> > --> >> hosts, but 
> --> > --> >> IMHO this has impact on end nodes, so it can not 
> --> be the standard 
> --> > --> >> mechanism, only an option.
> --> > --> >> - Generic hierarchical MAC addresses and masks (ref. Dr. 
> --> > --> >> Morales slide)
> --> > --> >> I proposed the generic addressing format  that includes 
> --> > --> hierarchical 
> --> > --> >> masks looking for a generic addressing space, that could 
> --> > --> be useful to 
> --> > --> >> scale further RBridges in the future. I understand that at 
> --> > --> >> this stage of 
> --> > --> >> definition of RBridges to look for a fully generic 
> --> > --> format could be 
> --> > --> >> disruptive. However, the need for a generic hierarchical 
> --> > --> addressing 
> --> > --> >> space in Ethernet is growing.
> --> > --> >>  
> --> > --> >>
> --> > --> >>
> --> > --> >>
> --> > --> >> Caitlin Bestler escribi?:
> --> > --> >>> Radia Perlman wrote:
> --> > --> >>>   
> --> > --> >>>> Not sure I've been following this, but let me 
> --> conjecture what
> --> > --> >>>> people are suggesting, and if I'm right about 
> --> the suggestion,
> --> > --> >>>> I think it's a good idea. Correct me if it's not what 
> --> > --> people are
> --> > --> >>>> saying. 
> --> > --> >>>>
> --> > --> >>>> So I think what they are saying is the following:
> --> > --> >>>> a) there are cases where an RBridge has a block 
> --> of addresses
> --> > --> >>>> (like DHCP) that it hands out to endnodes
> --> > --> >>>> b) in that case, it would be nice if the RBridge can
> --> > --> >>>> announce, in its LSP, the whole range of 
> --> addresses, rather
> --> > --> >>>> than reporting each individually
> --> > --> >>>> c) the change would be an ability to express a 
> --> range in the
> --> > --> >>>> endnode announcement. This seems easy, but I 
> --> think it would
> --> > --> >>>> be best done with a 2nd TLV in IS-IS. The 1st 
> --> TLV would be 
> --> > --> >> individual
> --> > --> >>>> addresses. The 2nd TLV would be pairs of addresses 
> --> > --> (low, high). Or
> --> > --> >>>> (low, increment), as in "starting with address X,
> --> > --> >>>> 32 addresses" (which would take up a bit less space 
> --> > --> than two MAC
> --> > --> >>>> addresses. 
> --> > --> >>>>
> --> > --> >>>> I don't think of this as a hierarchical address---I just
> --> > --> >>>> think of it as a range of addresses reachable 
> --> from one RBridge.
> --> > --> >>>>
> --> > --> >>>>     
> --> > --> >>> Reduction in the total number of reports required 
> --> to support N
> --> > --> >>> addresses is probably the only benefit of "hierarchical 
> --> > --> addresses"
> --> > --> >>> that we can achieve if we are going to support 
> --> global-scope MAC
> --> > --> >>> addresses as well. Which I'm certain everyone 
> --> agrees is a given.
> --> > --> >>>
> --> > --> >>>   
> --> > --> > 
> --> > --> _______________________________________________
> --> > --> rbridge mailing list
> --> > --> [e-mail]
> --> > --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> > --> 
> --> >   
> --> 
>   


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAGG1HND014074 for <[e-mail]>; Thu, 16 Nov 2006 08:01:17 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Thu, 16 Nov 2006 08:01:16 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] IVLANs vs OVLANs
Thread-Index: AccJlVtY/xEkIbQ3RICdoQwFIGfMFgAAejWA
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, "Russ White" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAGG1HND014074
Cc: [e-mail]
Subject: Re: [rbridge] IVLANs vs OVLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2006 16:01:38 -0000
Status: RO
Content-Length: 11982

Eric,

> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Thursday, November 16, 2006 7:39 AM
> To: Silvano Gai; Russ White
> Cc: [e-mail]
> Subject: RE: [rbridge] IVLANs vs OVLANs
> 
> Silvano,			(note: Russ - please read this!!)
> 
> 	For the first part of your question, Radia and I had almost
> this exact same discussion during the BoF I mentioned.  The only
> legitimate way to get from one (logical) VLAN to another is via a
> routing function.

Eric you really need to start to think in term of OVLAN and IVLAN and in
term of access ports and trunk port. The fact that products may use the
same port to be a trunk and an access at the same time is OK, so as it
is OK that the IVLANs and OVLANs are both implemented used using the 1Q
tagging scheme.

Without a clear terminology we will not be able to agree on anything.

What you are saying is not true for OVLANs. A frame, when it has an
OVLAN, i.e. it is on a trunk port, i.e. it has a TRILL shim, i.e. it has
an outer header, CANNOT have the outer MAC address of a router.
Therefore saying that "The only legitimate way to get from one (logical)
VLAN to another is via a
routing function" is incorrect in the case of OVLANs.

It may be the common case for IVLANs, but there are exceptions in today
networks, starting from NAT.

-- Silvano



> 
> 	Unless you include the "routing function" as part of the TRILL
> specification requirements - which does not, in any way, makes sense
> - then the model that applies is the one that has VLANs logically
> separated.
> 
> 	That is strictly a VLAN separation issue.  The second part of
> your question is trickier, hence it is good that you ask it and even
> better that you insisted on being understood.  :-)
> 
> 	From an RBridge perspective, I believe it is sufficient that all
> of the RBridges MUST support a common (probably the default - NULL)
> VLAN to ensure that all of them MUST peer with each other - at least
> for support of that (common) VLAN.  Hence, it should not be the case
> that any (proper) subset of RBridges would not peer exclusively with
> any other (proper) subset of RBridges in the same CRED.
> 
> 	Also, from an IS-IS perspective (help me out here Russ), I am
> reasonably sure that adjacent/connected IS-IS instances MUST discover
> each other during peer discovery - even if they do not subsequently
> peer with each other (or having peered with each other, exchange any
> routing information).  I believe this would be the case, even if there
> was potentially some strange virtual L3 overlay topology involving
> separate L3 VPN instancing in the IS-IS routing deployment.
> 
> 	If that is the case, then - from a peer discovery perspective -
> all RBridges will still be in the same CRED.  This is the perspective
> that matters, because it is the peer discovery process that allows the
> members of a CRED to "discover" potential _hidden_ loops in underlying
> L2 topology.
> 
> 	See also my reply to your question about VLAN interactions with
> routing...
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[e-mail]]
> --> Sent: Thursday, November 16, 2006 12:57 AM
> --> To: Gray, Eric
> --> Cc: [e-mail]
> --> Subject: RE: [rbridge] IVLANs vs OVLANs
> -->
> -->
> --> Eric,
> -->
> --> I am just trying to understand if there is consensus in a) or b).
> -->
> --> The impression I got talking with Radia is that she was in
> --> favor of a).
> -->
> --> Your reply is my b) model to which you have added a router.
> --> Since b) is
> --> two separate layer 2 networks, you can put a router between
> --> the two, as
> --> you did.
> -->
> --> Please also note that I can redraw the same network in a
> --> different way:
> -->
> -->                 +-----+
> -->                 | RB1 |
> -->                 +-----+
> -->                  |  |
> -->                1 |  | 2
> -->                  |  |
> -->  +-----+   1    +-----+    2     +-----+
> -->  | RB2 |--------| SW1 |----------| RB3 |
> -->  +-----+        +-----+          +-----+
> -->
> --> Where I replaced the Etherchannel with two links, one in
> --> OVLAN=1 and one
> --> in OVLAN=2.
> -->
> --> Now is RB2 capable of talking to RB3 through RB1?
> -->
> --> -- Silvano
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:[e-mail]]
> --> > Sent: Wednesday, November 15, 2006 12:13 PM
> --> > To: Silvano Gai
> --> > Cc: [e-mail]
> --> > Subject: RE: [rbridge] IVLANs vs OVLANs
> --> >
> --> > Silvano,
> --> >
> --> > 	First of all, I will take very large exception to the
way
> --> > which you have over-loaded the term "CRED."  This term was
coined
> --> > to eliminate confusion caused by the various different was
people
> --> > were over-loading the term "Campus."
> --> >
> --> > 	At the "core" of your question, however, is the issue of
> --> > how VLANs interact in a bridged/RBridge environment.  It is not
> --> > different than would be the case in a "classical bridged LAN."
> --> >
> --> > 	This issue is based on a misconception that existed very
> --> > early on in the life of the TRILL working group (in the first
> --> > BoF, in fact).  The misconception is that VLAN connectivity may
> --> > be provided by RBridges and/or bridges.
> --> >
> --> > 	This is fundamentally incorrect.
> --> >
> --> > 	Interconnection of VLANs is strictly a routing function.
> --> > In deployed equipment that does this today, there may be some
> --> > form of "smart VLAN bridging" that occurs in devices people are
> --> > used to referring to as "bridges" or "switches."  That does not
> --> > change the fact that forwarding from one VLAN to another is a
> --> > "routing function."
> --> >
> --> > 	Note that, in this context, when I say "forwarding from
> --> > one VLAN to another" - I mean "VLAN" in the sense of "virtual
> --> > LAN" as a logical concept.  This has nothing to do with the fact
> --> > that a VLAN ID might change in traversing a VLAN-aware bridge.
> --> >
> --> > 	Consequently, in the picture you have below, the VLANs
> --> > represented by the VLAN-tag in the tunnel encapsulation may
> --> > not be connected together by RB1.
> --> >
> --> > 	To correctly restate your question, the original
topology
> --> > would be as follows:
> --> >
> --> >
> --> >                 +-----+  1,2  +-----------+
> --> >                 | RB1 |-------| Rtg Fnctn |
> --> >                 +-----+       +-----------+
> --> >                    |
> --> >                    | 1,2
> --> >                    |
> --> >  +-----+   1    +-----+    2     +-----+
> --> >  | RB2 |--------| SW1 |----------| RB3 |
> --> >  +-----+        +-----+          +-----+
> --> >
> --> > The resulting logical topology MUST then be as follows:
> --> >
> --> >
> --> >  +-----+        +-----+       +-----------+
> --> >  | RB2 |--------| RB1 |-------| Rtg Fnctn |
> --> >  +-----+        +-----+       +-----+-----+
> --> >                                     |
> --> >                                  +--+--+          +-----+
> --> >                                  | RB1 |----------| RB3 |
> --> >                                  +-----+          +-----+
> --> >
> --> > Since the "routing function" is orthogonal, and well understood,
> --> > it does not make sense for us to try to combine this concept
with
> --> > RBridge behaviors and protocol interactions.
> --> >
> --> > --
> --> > Eric
> --> >
> --> >
> --> > --> -----Original Message-----
> --> > --> From: [e-mail]
> --> > --> [mailto:[e-mail]] On Behalf Of Silvano Gai
> --> > --> Sent: Tuesday, November 14, 2006 8:11 PM
> --> > --> To: [e-mail]
> --> > --> Subject: [rbridge] IVLANs vs OVLANs
> --> > -->
> --> > -->
> --> > --> During the last WG meeting I had an action item to send an
> --> > --> email on the
> --> > --> VLAN issue. Here it is.
> --> > -->
> --> > --> In a previous email I introduced the concept of IVLAN
> --> and OVLAN.
> --> > -->
> --> > --> IVLAN refers to the VLAN present on the untagged frames,
> --> > --> which must be
> --> > --> propagated by ISIS, VLAN pruning must be performed and so
> --> > --> on. All the
> --> > --> IVLANs share the same core instance of ISIS.
> --> > -->
> --> > --> OVLAN refers to the fact that the traffic between two
> --> > --> RBridges can be
> --> > --> encapsulated into a VLAN.
> --> > -->
> --> > --> If we look to the format of a TRILL encapsulated frame the
> --> > --> position of
> --> > --> these two fields is as follow:
> --> > -->
> --> > --> +--------------------------------+
> --> > --> |               DA               |
> --> > --> +----------------+---------------+
> --> > --> |       DA       |     SA        |
> --> > --> +----------------+---------------+
> --> > --> |               SA               |
> --> > --> +--------------------------------+
> --> > --> |    ET = 1Q     |   OVLAN ...   |
> --> > --> +--------------------------------+
> --> > --> |    ET = TRILL  | RES  |  TTL   |
> --> > --> +--------------------------------+
> --> > --> | Egress Add.    | Ingress Add.  |
> --> > --> +--------------------------------+
> --> > --> |               DA               |
> --> > --> +----------------+---------------+
> --> > --> |       DA       |     SA        |
> --> > --> +----------------+---------------+
> --> > --> |               SA               |
> --> > --> +--------------------------------+
> --> > --> |    ET = 1Q     |   IVLAN ...   |
> --> > --> +--------------------------------+
> --> > --> |             Payload            |
> --> > -->
> --> > --> Now let's consider the following topology:
> --> > -->
> --> > -->                +-----+
> --> > -->                | RB1 |
> --> > -->                +-----+
> --> > -->                   |
> --> > -->                   | 1,2
> --> > -->                   |
> --> > --> +-----+   1    +-----+    2     +-----+
> --> > --> | RB2 |--------| SW1 |----------| RB3 |
> --> > --> +-----+        +-----+          +-----+
> --> > -->
> --> > --> RB1, RB2, RB3 are Rbridges, SW1 is a classical
> --> Ethernet switch.
> --> > --> The link between RB2 and SW1 is in OVLAN 1, the link
> --> > --> between SW1 and RB3
> --> > --> is in OVLAN 2 and the links between SW1 and RB1 is a
> --> trunk and it
> --> > --> carries both OVLAN 1 and 2.
> --> > -->
> --> > --> Now my question is: "do we have one CRED or two?"
> --> > -->
> --> > --> a) possible answer: "we have one CRED". RB2 is adjacent to
> --> > --> RB1 but not
> --> > --> to RB3. The same applies to RB3 that is adjacent to RB1,
> --> > --> but not RB2.
> --> > --> RB1 is adjacent to both RB2 and RB3. There is a single core
> --> > --> instance of
> --> > --> ISIS. RB2 may reach RB3 through RB1.
> --> > -->
> --> > --> The TRILL equivalent topology is:
> --> > -->
> --> > --> +-----+        +-----+          +-----+
> --> > --> | RB2 |--------| RB1 |----------| RB3 |
> --> > --> +-----+        +-----+          +-----+
> --> > -->
> --> > --> b) another possible answer: "we have two CREDs". One is
> --> > --> composed by RB2
> --> > --> and RB1, the other by RB3 and RB1. RB2 may not reach RB3,
> --> > --> since they are
> --> > --> in different CREDs.
> --> > -->
> --> > --> The TRILL equivalent topologies are:
> --> > -->
> --> > --> +-----+        +-----+
> --> > --> | RB2 |--------| RB1 |
> --> > --> +-----+        +-----+
> --> > -->
> --> > --> +-----+          +-----+
> --> > --> | RB1 |----------| RB3 |
> --> > --> +-----+          +-----+
> --> > -->
> --> > --> I like a) and I hope we are in agreement that the right
> --> > --> answer is a),
> --> > --> but I haven't seen it explained in any of the documents.
> --> > -->
> --> > --> -- Silvano
> --> > -->
> --> > --> _______________________________________________
> --> > --> rbridge mailing list
> --> > --> [e-mail]
> --> > --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> > -->
> -->



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAGFmBjf009387 for <[e-mail]>; Thu, 16 Nov 2006 07:48:11 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Thu, 16 Nov 2006 07:48:09 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] IVLANs vs OVLANs
Thread-Index: AccJlEFwINs0f3GOQS+REv0qmzkp+AAAEDVg
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAGFmBjf009387
Cc: [e-mail]
Subject: Re: [rbridge] IVLANs vs OVLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2006 15:48:37 -0000
Status: RO
Content-Length: 11567

Eric,

Let me take your example, add two hosts and then you can explain me why
I am "incorrect"

                 +-----+  1,2  +-----------+
                 | RB1 |-------| Rtg Fnctn |
                 +-----+       +-----------+
                    |
                    | 1,2
                    |
  +-----+   1    +-----+    2     +-----+
  | RB2 |--------| SW1 |----------| RB3 |
  +-----+        +-----+          +-----+
     |                               |
     | IVLAN=3                       | IVLAN=3
  +-----+                         +-----+
  |  H1 |                         |  H2 |
  +-----+                         +-----+

Frame originated by H1 (fields are in order separated by commas):

Original Frame
H2, H1, VLAN=3, Payload

>From RB2 to RB1:

Outer header     | TRILL Shim    |  Original Frame 
RB1, RB2, VLAN=1 | TTL, RB3, RB2 |  H2, H1, VLAN=3, Payload

>From RB1 to RB3:

Outer header     | TRILL Shim    |  Original Frame 
RB3, RB1, VLAN=2 | TTL, RB3, RB2 |  H2, H1, VLAN=3, Payload

Where is a routing function required?

RB1 CANNOT decapsulate the frame, since it is not the destination in the
TRILL shim.

Even if it violates the previous rule, it CANNOT pass the frame to the
router, since it is not addressed to the router at the MAC layer.

Where am I incorrect?

-- Silvano




> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Thursday, November 16, 2006 7:31 AM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: RE: [rbridge] IVLANs vs OVLANs
> 
> Silvano,
> 
> 	Sorry, but you are incorrect.
> 
> 	Routers are "end-stations" to a layer 2 network - hence it is
> necessarily the case that TRILL frames MUST egress the RBridge CRED
> prior to being delivered to a "routing function."  In the same way,
> any frame delivered frome a "routing function" MUST ingress the CRED
> for subsequent delivery in the form of TRILL frames.
> 
> 	This is a logical distinction and does not - in any way - limit
> your implementation choices.  Logically, what happens is:
> 
> 1) the TRILL encapsulation is stripped, along with the SHIM header,
> 2) the frame is forwarded (possibly locally, possibly only logically)
>    to the component that implements the "routing function",
> 3) the remaining Ethernet header is stripped, delivering the data (an
>    IP packet) - along with relevant packet information (such as
length)
>    - to the "routing function",
> 4) the "routing function" is used (including, for example ACLs, policy
>    based forwarding, etc.) to determine how to forward the _packet_ -
>    including forwarding to a logical "interface" on a distinct VLAN,
> 5) after the forwarding decision is made, appropriate encapsulation is
>    added to the IP packet, again converting it (in this case) to an
>    Ethernet frame,
> 6) the resulting Ethernet frame is forwarded (possibly locally,
possibly
>    only logically) from the component implementing the "routing
function"
>    to the appropriate RBridge component,
> 7) the RBridge component then provides ingress for the frame by adding
>    a SHIM and re-encapsulating the frame with the appropriate TRILL
>    encapsulation.
> 
> 	To RE-EMPHASIZE, this is what happens logically.  What you do in
> your implementation may differ substantially from this.  It may - for
> example - be quite a bit simpler.  How you do this is why you get paid
> the big bucks.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[e-mail]]
> --> Sent: Thursday, November 16, 2006 1:45 AM
> --> To: Gray, Eric
> --> Cc: [e-mail]
> --> Subject: RE: [rbridge] IVLANs vs OVLANs
> -->
> -->
> --> Eric,
> -->
> --> On a second thought, you cannot put a router between OVLAN=1 and
> --> OVLAN=2, the frame is not routable, since its Ethertype is
> --> TRILL, not
> --> IPv4 or IPv6.
> -->
> --> -- Silvano
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:[e-mail]]
> --> > Sent: Wednesday, November 15, 2006 12:13 PM
> --> > To: Silvano Gai
> --> > Cc: [e-mail]
> --> > Subject: RE: [rbridge] IVLANs vs OVLANs
> --> >
> --> > Silvano,
> --> >
> --> > 	First of all, I will take very large exception to the
way
> --> > which you have over-loaded the term "CRED."  This term was
coined
> --> > to eliminate confusion caused by the various different was
people
> --> > were over-loading the term "Campus."
> --> >
> --> > 	At the "core" of your question, however, is the issue of
> --> > how VLANs interact in a bridged/RBridge environment.  It is not
> --> > different than would be the case in a "classical bridged LAN."
> --> >
> --> > 	This issue is based on a misconception that existed very
> --> > early on in the life of the TRILL working group (in the first
> --> > BoF, in fact).  The misconception is that VLAN connectivity may
> --> > be provided by RBridges and/or bridges.
> --> >
> --> > 	This is fundamentally incorrect.
> --> >
> --> > 	Interconnection of VLANs is strictly a routing function.
> --> > In deployed equipment that does this today, there may be some
> --> > form of "smart VLAN bridging" that occurs in devices people are
> --> > used to referring to as "bridges" or "switches."  That does not
> --> > change the fact that forwarding from one VLAN to another is a
> --> > "routing function."
> --> >
> --> > 	Note that, in this context, when I say "forwarding from
> --> > one VLAN to another" - I mean "VLAN" in the sense of "virtual
> --> > LAN" as a logical concept.  This has nothing to do with the fact
> --> > that a VLAN ID might change in traversing a VLAN-aware bridge.
> --> >
> --> > 	Consequently, in the picture you have below, the VLANs
> --> > represented by the VLAN-tag in the tunnel encapsulation may
> --> > not be connected together by RB1.
> --> >
> --> > 	To correctly restate your question, the original
topology
> --> > would be as follows:
> --> >
> --> >
> --> >                 +-----+  1,2  +-----------+
> --> >                 | RB1 |-------| Rtg Fnctn |
> --> >                 +-----+       +-----------+
> --> >                    |
> --> >                    | 1,2
> --> >                    |
> --> >  +-----+   1    +-----+    2     +-----+
> --> >  | RB2 |--------| SW1 |----------| RB3 |
> --> >  +-----+        +-----+          +-----+
> --> >
> --> > The resulting logical topology MUST then be as follows:
> --> >
> --> >
> --> >  +-----+        +-----+       +-----------+
> --> >  | RB2 |--------| RB1 |-------| Rtg Fnctn |
> --> >  +-----+        +-----+       +-----+-----+
> --> >                                     |
> --> >                                  +--+--+          +-----+
> --> >                                  | RB1 |----------| RB3 |
> --> >                                  +-----+          +-----+
> --> >
> --> > Since the "routing function" is orthogonal, and well understood,
> --> > it does not make sense for us to try to combine this concept
with
> --> > RBridge behaviors and protocol interactions.
> --> >
> --> > --
> --> > Eric
> --> >
> --> >
> --> > --> -----Original Message-----
> --> > --> From: [e-mail]
> --> > --> [mailto:[e-mail]] On Behalf Of Silvano Gai
> --> > --> Sent: Tuesday, November 14, 2006 8:11 PM
> --> > --> To: [e-mail]
> --> > --> Subject: [rbridge] IVLANs vs OVLANs
> --> > -->
> --> > -->
> --> > --> During the last WG meeting I had an action item to send an
> --> > --> email on the
> --> > --> VLAN issue. Here it is.
> --> > -->
> --> > --> In a previous email I introduced the concept of IVLAN
> --> and OVLAN.
> --> > -->
> --> > --> IVLAN refers to the VLAN present on the untagged frames,
> --> > --> which must be
> --> > --> propagated by ISIS, VLAN pruning must be performed and so
> --> > --> on. All the
> --> > --> IVLANs share the same core instance of ISIS.
> --> > -->
> --> > --> OVLAN refers to the fact that the traffic between two
> --> > --> RBridges can be
> --> > --> encapsulated into a VLAN.
> --> > -->
> --> > --> If we look to the format of a TRILL encapsulated frame the
> --> > --> position of
> --> > --> these two fields is as follow:
> --> > -->
> --> > --> +--------------------------------+
> --> > --> |               DA               |
> --> > --> +----------------+---------------+
> --> > --> |       DA       |     SA        |
> --> > --> +----------------+---------------+
> --> > --> |               SA               |
> --> > --> +--------------------------------+
> --> > --> |    ET = 1Q     |   OVLAN ...   |
> --> > --> +--------------------------------+
> --> > --> |    ET = TRILL  | RES  |  TTL   |
> --> > --> +--------------------------------+
> --> > --> | Egress Add.    | Ingress Add.  |
> --> > --> +--------------------------------+
> --> > --> |               DA               |
> --> > --> +----------------+---------------+
> --> > --> |       DA       |     SA        |
> --> > --> +----------------+---------------+
> --> > --> |               SA               |
> --> > --> +--------------------------------+
> --> > --> |    ET = 1Q     |   IVLAN ...   |
> --> > --> +--------------------------------+
> --> > --> |             Payload            |
> --> > -->
> --> > --> Now let's consider the following topology:
> --> > -->
> --> > -->                +-----+
> --> > -->                | RB1 |
> --> > -->                +-----+
> --> > -->                   |
> --> > -->                   | 1,2
> --> > -->                   |
> --> > --> +-----+   1    +-----+    2     +-----+
> --> > --> | RB2 |--------| SW1 |----------| RB3 |
> --> > --> +-----+        +-----+          +-----+
> --> > -->
> --> > --> RB1, RB2, RB3 are Rbridges, SW1 is a classical
> --> Ethernet switch.
> --> > --> The link between RB2 and SW1 is in OVLAN 1, the link
> --> > --> between SW1 and RB3
> --> > --> is in OVLAN 2 and the links between SW1 and RB1 is a
> --> trunk and it
> --> > --> carries both OVLAN 1 and 2.
> --> > -->
> --> > --> Now my question is: "do we have one CRED or two?"
> --> > -->
> --> > --> a) possible answer: "we have one CRED". RB2 is adjacent to
> --> > --> RB1 but not
> --> > --> to RB3. The same applies to RB3 that is adjacent to RB1,
> --> > --> but not RB2.
> --> > --> RB1 is adjacent to both RB2 and RB3. There is a single core
> --> > --> instance of
> --> > --> ISIS. RB2 may reach RB3 through RB1.
> --> > -->
> --> > --> The TRILL equivalent topology is:
> --> > -->
> --> > --> +-----+        +-----+          +-----+
> --> > --> | RB2 |--------| RB1 |----------| RB3 |
> --> > --> +-----+        +-----+          +-----+
> --> > -->
> --> > --> b) another possible answer: "we have two CREDs". One is
> --> > --> composed by RB2
> --> > --> and RB1, the other by RB3 and RB1. RB2 may not reach RB3,
> --> > --> since they are
> --> > --> in different CREDs.
> --> > -->
> --> > --> The TRILL equivalent topologies are:
> --> > -->
> --> > --> +-----+        +-----+
> --> > --> | RB2 |--------| RB1 |
> --> > --> +-----+        +-----+
> --> > -->
> --> > --> +-----+          +-----+
> --> > --> | RB1 |----------| RB3 |
> --> > --> +-----+          +-----+
> --> > -->
> --> > --> I like a) and I hope we are in agreement that the right
> --> > --> answer is a),
> --> > --> but I haven't seen it explained in any of the documents.
> --> > -->
> --> > --> -- Silvano
> --> > -->
> --> > --> _______________________________________________
> --> > --> rbridge mailing list
> --> > --> [e-mail]
> --> > --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> > -->
> -->



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAGFda6O005505 for <[e-mail]>; Thu, 16 Nov 2006 07:39:36 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kAGFdZfK027836 for <[e-mail]>; Thu, 16 Nov 2006 10:39:36 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07928 for <[e-mail]>; Thu, 16 Nov 2006 10:39:34 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB6VCQ8F>; Thu, 16 Nov 2006 10:39:34 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "Gray, Eric" <[e-mail]>
Date: Thu, 16 Nov 2006 10:39:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case? - not sent (OBE	)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2006 15:39:49 -0000
Status: RO
Content-Length: 20553

There are two complexity issues to consider here: specification complexity
and implementation complexity.

If we propose "cute" and "intriguing" protocols and encapsulations, but we
don't require support for them in all cases, then we have specification
complexity.  If we make the same proposals and require support for them in
all compliant implementations, then we have implementation complexity.

The potential for implementation complexity in this case is exactly a result
of the "cute" and "intriguing" nature of the proposal.  We're suggesting we
should expect RBridge hardware to be able to deal with multiple
encapsulation
types - and additional options associated at least one encapsulation type.

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Eastlake 
--> III Donald-LDE008
--> Sent: Wednesday, November 08, 2006 4:28 AM
--> To: [e-mail]
--> Subject: Re: [rbridge] Should we optimize the common case?
--> 
--> This seems like an intriguing possibility. We would need to get an OUI
--> to go into the top 24 bits of these addresses. With an OUI we can then
--> easily allocate our own multicast addresses (all rbridges, etc.) so we
--> would end up needing one OUI and one Ethertype allocated but nothing
--> else. (You might think that with these magic addresses, you could
--> dispense with the TRILL Ethertype but, besides the fact that that would
--> be non-standard, you can't anyway because, for example, you may need to
--> insert a VLAN tag and/or other tags between the addresses and the shim.)
--> 
--> Thanks,
--> Donald
--> 
--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On
--> Behalf Of [e-mail]
--> Sent: Wednesday, November 08, 2006 3:02 AM
--> To: Sanjay Sane (sanjays)
--> Cc: [e-mail]
--> Subject: Re: [rbridge] Should we optimize the common case?
--> 
--> This is an extremely cute proposal, and it works. Let me explain
--> Sanjay's proposal in different words, in case it doesn't sink in the
--> first time one sees it.
--> 
--> He is proposing using the shim header that looks like an Ethernet
--> header, with SA=ingress RBridge MAC R1 and DA=egress RBridge MAC R2,
--> but solving the two problems brought up at the meeting which were:
--> 
--> a) bridges on an [intermediate] link might have previously incorrectly
--> learned the location of R2, because packets from R2 might have arrived
--> at the link from different directions.
--> 
--> b) if we avoid problem a) by using different MAC addresses for "to" and
--> "from" for each RBridge, so that we avoid bridges ever learning the
--> direction of the egress RBridge, the problem is that we don't benefit
--> from good bridge learning on the link.
--> 
--> And also, he is proposing making it possible to use that header on a
--> link with more than 2 RBridges.
--> 
--> The way he's proposing doing it is using the 48 bit Destination and
--> Source addresses in the Ethernet header in an unconventional way.
--> 
--> Instead of putting the MAC address of the ingress and egress RBridges
--> in those fields, he is suggesting the following:
--> 
--> a) assign 16-bit nicknames to all the RBridges (as we were going to do
--> with the short shim header)
--> b) assign, say, 8 bit link-local nicknames to all the RBridges on a link
--> (this can be done through the IS-IS Hello protocol quite easily--I'd
--> suggest doing it by having the Designated RBridge assign the values, but
--> it could also be done by having each RBridge choose a nickname and back
--> off if someone with a better ID has chosen that nickname)
--> c) in the Destination address field in the Ethernet header, put in both
--> the 16-bit egress RBridge nickname, and the nextop 8-bit nickname
--> d) in the Source address field in the Ethernet header, put in both the
--> 16-bit ingress RBridge nickname, and the transmitting RBridge on that
--> link's 8-bit nickname
--> 
--> So---bridges will never incorrectly learn the location of any RBridges,
--> because no matter where a packet from
--> R12 arrives into the link, the bottom bits will be specific to the
--> RBridge on the link that injected the packet.
--> 
--> And positive learning can happen as well. Suppose there are n total
--> RBridge nicknames in use in the whole campus. Suppose there are 5
--> RBridges on the link. The bridges inside the link will see 
--> 5*n RBridge
--> addresses as a result of this proposal. In other words, if 
--> the RBridge
--> nicknames are 1, 2, ... 517. and there are 5 RBridges on 
--> the link, the
--> MAC addresses the bridges will see are:
--> {1 - 517} | {1 - 5}
--> 
--> In Sanjay's picture, if R4 wants to direct a packet towards 
--> R2 rather
--> than R3 for egress R1, it encodes R2's nickname into the "neighbor's
--> nickname" portion of the egress RBridge field.
--> 
--> Anyway---something for people to think about.
--> 
--> Radia
--> 
--> ----- Original Message -----
--> From: "Sanjay Sane (sanjays)" <[e-mail]>
--> Date: Tuesday, November 7, 2006 12:24 pm
--> Subject: RE: [rbridge] Should we optimize the common case?
--> 
--> > Oops. Typed send before finishing. 
--> > 
--> > attached the diagram.
--> > Completed the description. See inline
--> > 
--> > -Sanjay
--> > 
--> > 
--> > 
--> > -----Original Message-----
--> > From: Sanjay Sane (sanjays)
--> > Sent: Tuesday, November 07, 2006 12:19 PM
--> > To: 'Radia Perlman'; Silvano Gai
--> > Cc: [e-mail]
--> > Subject: RE: [rbridge] Should we optimize the common case?
--> > 
--> > Radia,
--> > 
--> > In today's presentation, the last suggested format was 
--> the following
--> > 
--> > 48 bits - egress rbridge id
--> > 48 bits - ingress rbridge id
--> > 16 bits - pt = TRILL
--> > 16 bits - reserved + flag + TTL - the link local nicknames (who's 
--> > supposed to be the next-hop is in here) ....
--> > 
--> > 
--> > when this goes over a shared media, there were learning issues as 
--> > pointed out during the meeting. Pls refer to this diagram to 
--> > understandthe problem
--> > 
--> > 1. if packets from r1 to r5 are sent once via r2, and 
--> other times, via
--> 
--> > r3, the classical bridge b will learn r1 as behind link 1 or 2.
--> > So, this
--> > is the learning problem. 
--> > 2. thus, for return traffic frm r5 to r1, even though r4 
--> wants r2 to 
--> > be the next-hop for this packet, if we keep the 
--> destination rbridge id
--> 
--> > as r1, the classical bridge would forward the packet to link 1, 
--> > thereby blackholing this traffic.
--> > 
--> > So, there are multiple issues - learning issues and blakholing. 
--> > 
--> > Potential solution:
--> > 
--> > r2, r3 and r4 exchange the link-local nicknames, say link local 
--> > nicknamefor r2 = 1, r3 = 2, r4 = 3.
--> > 
--> > Now, instead of using the complete 48 bit rbridge ID as 
--> the rbridge 
--> > MAC address, we can fill the 48 bits as follows:
--> > 
--> > 16 bit - rbridge nickname
--> > 4 bits - link local nickname
--> > 
--> > 2 bits - I/G and U/L
--> > 26 bits - reserved. 
--> > 
--> > Thus, on this classical ethernet/bridging cloud, rbridge 
--> emits the 
--> > packet with the appropriate link-local nicknames.
--> > 
--> > For e.g. 
--> > - packets from r1 to r5, sent via r2, are sent with SA = r1.<link 
--> > source's link-local-nickname> = r1.1, , notice 
--> link-local-nickname of 
--> > r2 is chosen.
--> > If r2 intends r4 to be the next-hop, he'll put DA = r5.<link 
--> > destination's link-local-nickname> = r5.3, notice 
--> link-local-nickname 
--> > of r4 is chosen.
--> > Thus, classical bridge will learn r1.1 on the link 1. 
--> > 
--> > - packets from r1 to r5, sent via r3, are sent with SA = r1.<link 
--> > source's link-local-nickname> = r1.2, , notice 
--> link-local-nickname of 
--> > r3 is chosen.
--> > If r3 intends r4 to be the next-hop, he'll put DA = r5.<link 
--> > destination's link-local-nickname> = r5.3, notice 
--> link-local-nickname 
--> > of r4 is chosen.
--> > Thus, classical bridge will learn r1.2 on the link 1. 
--> > 
--> > -- thus no learning issues. 
--> > 
--> > - return traffic from r5 to r1, sent via r4. If r4 
--> intends r2 to be 
--> > the next hop, it'll put SA = r5.<link source's 
--> link-local-nickname> = 
--> > r5.3, , notice link-local-nickname of r4 is chosen.
--> > If r5 intends r2 to be the next-hop, he'll put DA = r1.<link 
--> > destination's link-local-nickname> = r1.1, notice 
--> link-local-nickname 
--> > of r1 is chosen.
--> > 
--> > -- thus no blackholing.
--> > 
--> > -Sanjay
--> > 
--> > 
--> > 
--> > -----Original Message-----
--> > From: [e-mail] [[e-mail]] On 
--> > Behalf Of Radia Perlman
--> > Sent: Tuesday, November 07, 2006 10:23 AM
--> > To: Silvano Gai
--> > Cc: [e-mail]
--> > Subject: Re: [rbridge] Should we optimize the common case?
--> > 
--> > Looking at Silvano's proposed shim header---the only 
--> reason we need 
--> > the outer header is to distinguish between RBridge 
--> neighbors, in the 
--> > case of unicast, specifying next hop, and in the case of 
--> multicast, 
--> > specifying transmitter.
--> > 
--> > His format has two bytes after the Ethernet header 
--> portion of the shim
--> 
--> > for TTL, and a bunch of reserved bits.
--> > 
--> > That leaves 10 bits. We can dynamically (through the 
--> IS-IS Hello) give
--> 
--> > out, say, 4 bit link-local nicknames, and stick them there.
--> > 
--> > Then the only time we'd need an outer header is if there are more 
--> > than,say, 16 RBridges on the same link.
--> > 
--> > Radia
--> > 
--> > Silvano Gai wrote:
--> > 
--> > >I am not looking at TRILL for increased scalability, but for
--> > spanning
--> > >tree replacement to get high bisectional bandwidth.
--> > >
--> > >-- Silvano
--> > >
--> > >  
--> > >
--> > >>-----Original Message-----
--> > >>From: Gray, Eric [[e-mail]]
--> > >>Sent: Monday, November 06, 2006 10:38 AM
--> > >>To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
--> > >>Subject: RE: [rbridge] Should we optimize the common case?
--> > >>
--> > >>Silvano,
--> > >>
--> > >>	The assertion that only fortune 500 companies 
--> are interested in
--> > TRILL
--> > >>is baseless and untrue.  One reason why you may believe this is
--> > the
--> > >>case, is that you are making certain assumptions about
--> > complexity and
--> > >>scale of the desired solution that are equally 
--> unfounded or false.
--> > >>
--> > >>	There is nothing that particularly prohibits 
--> definition of some
--> > form
--> > >>of RBridge functionality that might be simple enough to deploy
--> > in
--> > >>relatively small networks - where higher speed link are becoming
--> > more
--> > >>common and wasting high speed links is also a problem.
--> > >>
--> > >>	The types of networks you're talking about 
--> cannot realistically 
--> > >>operate with plug & play devices, and greater scalability is
--> > >>    
--> > >>
--> > >paramount.
--> > >  
--> > >
--> > >>The work we're doing in this WG is aimed at simplistic, plug &
--> > play
--> > >>deployment where increased scalability is a secondary 
--> consideration.
--> > >>
--> > >>--
--> > >>Eric
--> > >>
--> > >>--> -----Original Message-----
--> > >>--> From: [e-mail] 
--> [[e-mail]] On
--> 
--> > >>--> Behalf Of Silvano Gai
--> > >>--> Sent: Monday, November 06, 2006 1:51 AM
--> > >>--> To: Eastlake III Donald-LDE008; [e-mail]
--> > >>--> Subject: Re: [rbridge] Should we optimize the common case?
--> > >>-->
--> > >>-->
--> > >>--> Donald,
--> > >>-->
--> > >>--> The high end and the low end are extremely different.
--> > >>-->
--> > >>--> The customers interested in TRILL are the Fortune 500
--> > companies. 
--> > >>--> Large Enterprise networks and large data centers 
--> used to run 
--> > >>--> Financial, Insurance, Health, Chemical, Oil, 
--> Information and 
--> > >>--> manufacturing companies.
--> > >>-->
--> > >>--> They have huge demand for high bandwidth and low latency.
--> > >>-->
--> > >>--> Each of these companies spends millions each year 
--> in network 
--> > >>--> operation
--> > >>--> (OPEX) and millions in new equipment (CAPEX). In all of them
--> > OPEX>>    
--> > >>
--> > >is
--> > >  
--> > >
--> > >>--> much larger than CAPEX. They only buy major vendor
--> > equipments and
--> > >>--> they install them according to the recommended 
--> vendor design 
--> > >>--> guideline.
--> > >>--> Typically they have an internal certification lab in which
--> > they
--> > >>--> test the network configuration and the software releases
--> > before
--> > >>--> putting them in production networks.
--> > >>-->
--> > >>--> They have a very well defined concept of backbone ports and
--> > access
--> > >>--> ports. All the backbone ports are in fiber at the highest
--> > possible
--> > >>--> speed (today 10 GE). For the access port they use a mix of
--> > fiber
--> > >>--> and copper.
--> > >>--> The backbone has a regular structure that matches the vendor
--> > >>    
--> > >>
--> > >design
--> > >  
--> > >
--> > >>--> guideline and the result of the certification 
--> experiment they 
--> > >>--> have done independently.
--> > >>-->
--> > >>--> A network outage can cost millions/hour.
--> > >>-->
--> > >>--> There is no way you will see in one of these 
--> backbones a hub or
--> > >>    
--> > >>
--> > >any
--> > >  
--> > >
--> > >>--> other uncontrolled device. NEVER.
--> > >>-->
--> > >>--> That is the reason why I think this is the most important
--> > case for
--> > >>--> TRILL.
--> > >>-->
--> > >>--> More inline.
--> > >>-->
--> > >>--> > -----Original Message-----
--> > >>--> > From: [e-mail]
--> > >>--> [[e-mail]]
--> > >>--> On
--> > >>--> > Behalf Of Eastlake III Donald-LDE008
--> > >>--> > Sent: Sunday, November 05, 2006 10:20 PM
--> > >>--> > To: [e-mail]
--> > >>--> > Subject: Re: [rbridge] Should we optimize the common case?
--> > >>--> >
--> > >>--> > Silvano,
--> > >>--> >
--> > >>--> > Why do you think that 90% of Rbridge deployment will be
--> > for this
--> > >>--> unusual
--> > >>--> > case? I mean, I have no problem with the belief that
--> > >>--> Rbridges would be
--> > >>--> > better than bridges in this case but why shouldn't that be
--> > true>>    
--> > >>
--> > >of
--> > >  
--> > >
--> > >>--> less
--> > >>--> > high end uses?
--> > >>--> >
--> > >>--> > A while ago on this list I posted a rhetorical 
--> question as to
--> > >>    
--> > >>
--> > >why
--> > >  
--> > >
--> > >>--> > Rbriges shouldn't eventually replace all bridges. No one
--> > posted>>    
--> > >>
--> > >an
--> > >  
--> > >
--> > >>--> > answer.
--> > >>-->
--> > >>--> This technology will start in the high end and move 
--> down to the 
--> > >>--> lower end. How low will it goes is a good question.
--> > >>-->
--> > >>--> The low end is extremely cost sensitive. When we buys a
--> > switch or
--> > >>    
--> > >>
--> > >a
--> > >  
--> > >
--> > >>--> router on the Internet for 50-100$, the COGS cannot 
--> be more that
--> 
--> > >>--> 15-30$, even with low margins. This implies that 
--> few dollar more
--> 
--> > >>--> to increase the memory size or the processor speed 
--> are a big 
--> > >>--> deal. Add software development cost. Couple this 
--> with the fact 
--> > >>--> that today we have low cost 1GE switches used by 
--> low-end users 
--> > >>--> that have problems pushing or pulling more than few 
--> Mb/s. There 
--> > >>--> is no bandwidth demand in the low end.
--> > >>--> Spanning tree is just fine. Cost is the big issue. Moreover 
--> > >>--> there is the huge issue of training home/small 
--> office installers
--> 
--> > >>--> in this new technology.
--> > >>-->
--> > >>--> My 0.2 cents
--> > >>-->
--> > >>--> -- Silvano
--> > >>-->
--> > >>--> >
--> > >>--> > Why not specify Rbridges more or less as we have been for
--> > >>--> the common
--> > >>--> > bridge case and, in the backbone case you are talking
--> > >>--> about, just drop
--> > >>--> > the MAC addresses on the point-to-point links within the
--> > >>    
--> > >>
--> > >backbone?
--> > >  
--> > >
--> > >>--> > Doesn't that produce less overhead than your proposal
--> > >>--> below in both
--> > >>--> the
--> > >>--> > point-to-point and shared media cases?
--> > >>--> >
--> > >>--> > Donald
--> > >>--> >
--> > >>--> > -----Original Message-----
--> > >>--> > From: [e-mail]
--> > >>--> [[e-mail]]
--> > >>--> On
--> > >>--> > Behalf Of Silvano Gai
--> > >>--> > Sent: Wednesday, November 01, 2006 9:07 PM
--> > >>--> > To: [e-mail]
--> > >>--> > Subject: [rbridge] Should we optimize the common case?
--> > >>--> >
--> > >>--> >
--> > >>--> > With 16 bit addresses the current TRILL overhead over
--> > >>--> Ethernet is 20
--> > >>--> > bytes. If we want to expand the RBridge addresses, it we
--> > >>--> will go to
--> > >>--> > 22-24 bytes.
--> > >>--> >
--> > >>--> > What customers are telling us is that they will deploy
--> > RBridges>>    
--> > >>
--> > >by
--> > >  
--> > >
--> > >>--> > creating an RBridge backbone in which all the 
--> links will be
--> > >>    
--> > >>
--> > >10GE.
--> > >  
--> > >
--> > >>--> >
--> > >>--> > They will connect regular bridges and host to the
--> > >>--> periphery of this
--> > >>--> > backbone.
--> > >>--> >
--> > >>--> > They will not mix backbone ports with access ports,
--> > because this
--> > >>--> screws
--> > >>--> > up management, traffic engineering, debugging, and
--> > >>--> troubleshooting.
--> > >>--> > Regular network design, easy to understand, is very
--> > >>--> important. Ports
--> > >>--> are
--> > >>--> > cheap, labor is expensive.
--> > >>--> >
--> > >>--> > I am totally convinced that this will account for 90+ % of
--> > TRILL>>--> > deployment.
--> > >>--> >
--> > >>--> > I am wondering if it makes sense to have a solution
--> > >>--> highly optimized
--> > >>--> for
--> > >>--> > such an environment.
--> > >>--> >
--> > >>--> > For example we can put the egress/ingress RBridge
--> > addresses in
--> > >>    
--> > >>
--> > >the
--> > >  
--> > >
--> > >>--> outer
--> > >>--> > MAC addresses and define a TRILL shim header that
--> > >>--> contains 1 byte of
--> > >>--> hop
--> > >>--> > limit and 1 byte reserved. For this common case 
--> we will get:
--> > >>--> > 1) overhead of 16 bytes (4 to 8 bytes lower)
--> > >>--> > 2) nickname = MAC address, i.e no hash collision
--> > >>--> > 3) zero-conf achieved
--> > >>--> >
--> > >>--> > In the case we need to go over a shared media we 
--> will need to
--> > >>    
--> > >>
--> > >add
--> > >  
--> > >
--> > >>--> > another Ethernet encapsulation to carry the next hop
--> > >>--> address, i.e. 14
--> > >>--> > bytes
--> > >>--> > - total overhead will be 30 bytes
--> > >>--> >
--> > >>--> > Summarizing:
--> > >>--> > - current proposal 20-24 bytes overhead
--> > >>--> > - new proposal on point to point: 16 bytes
--> > >>--> > - new proposal on shared media: 30 bytes
--> > >>--> >
--> > >>--> > Comments?
--> > >>--> >
--> > >>--> > -- Silvano
--> > >>--> >
--> > >>--> >
--> > >>--> > _______________________________________________
--> > >>--> > rbridge mailing list
--> > >>--> > [e-mail]
--> > >>--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> > >>--> >
--> > >>--> > _______________________________________________
--> > >>--> > rbridge mailing list
--> > >>--> > [e-mail]
--> > >>--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> > >>-->
--> > >>--> _______________________________________________
--> > >>--> rbridge mailing list
--> > >>--> [e-mail]
--> > >>--> http://mailman.postel.org/mailman/listinfo/rbridge
--> > >>-->
--> > >>    
--> > >>
--> > >
--> > >_______________________________________________
--> > >rbridge mailing list
--> > >[e-mail]
--> > >http://mailman.postel.org/mailman/listinfo/rbridge
--> > >  
--> > >
--> > 
--> > _______________________________________________
--> > rbridge mailing list
--> > [e-mail]
--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> > 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAGFd9Up005283 for <[e-mail]>; Thu, 16 Nov 2006 07:39:09 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kAGFd6fK027822; Thu, 16 Nov 2006 10:39:06 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07885;  Thu, 16 Nov 2006 10:39:05 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB6VCQ7Y>; Thu, 16 Nov 2006 10:39:05 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>, Russ White <[e-mail]>
Date: Thu, 16 Nov 2006 10:39:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] IVLANs vs OVLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2006 15:39:36 -0000
Status: RO
Content-Length: 10392

Silvano,			(note: Russ - please read this!!)

	For the first part of your question, Radia and I had almost 
this exact same discussion during the BoF I mentioned.  The only
legitimate way to get from one (logical) VLAN to another is via a
routing function.

	Unless you include the "routing function" as part of the TRILL
specification requirements - which does not, in any way, makes sense
- then the model that applies is the one that has VLANs logically
separated.

	That is strictly a VLAN separation issue.  The second part of
your question is trickier, hence it is good that you ask it and even
better that you insisted on being understood.  :-)

	From an RBridge perspective, I believe it is sufficient that all
of the RBridges MUST support a common (probably the default - NULL)
VLAN to ensure that all of them MUST peer with each other - at least
for support of that (common) VLAN.  Hence, it should not be the case
that any (proper) subset of RBridges would not peer exclusively with 
any other (proper) subset of RBridges in the same CRED.

	Also, from an IS-IS perspective (help me out here Russ), I am
reasonably sure that adjacent/connected IS-IS instances MUST discover
each other during peer discovery - even if they do not subsequently
peer with each other (or having peered with each other, exchange any
routing information).  I believe this would be the case, even if there
was potentially some strange virtual L3 overlay topology involving
separate L3 VPN instancing in the IS-IS routing deployment.

	If that is the case, then - from a peer discovery perspective -
all RBridges will still be in the same CRED.  This is the perspective
that matters, because it is the peer discovery process that allows the
members of a CRED to "discover" potential _hidden_ loops in underlying
L2 topology.

	See also my reply to your question about VLAN interactions with
routing...

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Thursday, November 16, 2006 12:57 AM
--> To: Gray, Eric
--> Cc: [e-mail]
--> Subject: RE: [rbridge] IVLANs vs OVLANs
--> 
--> 
--> Eric,
--> 
--> I am just trying to understand if there is consensus in a) or b).
--> 
--> The impression I got talking with Radia is that she was in 
--> favor of a).
--> 
--> Your reply is my b) model to which you have added a router. 
--> Since b) is
--> two separate layer 2 networks, you can put a router between 
--> the two, as
--> you did.
--> 
--> Please also note that I can redraw the same network in a 
--> different way:
--> 
-->                 +-----+
-->                 | RB1 |
-->                 +-----+
-->                  |  |
-->                1 |  | 2
-->                  |  |
-->  +-----+   1    +-----+    2     +-----+
-->  | RB2 |--------| SW1 |----------| RB3 |
-->  +-----+        +-----+          +-----+
--> 
--> Where I replaced the Etherchannel with two links, one in 
--> OVLAN=1 and one
--> in OVLAN=2. 
--> 
--> Now is RB2 capable of talking to RB3 through RB1?
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[e-mail]]
--> > Sent: Wednesday, November 15, 2006 12:13 PM
--> > To: Silvano Gai
--> > Cc: [e-mail]
--> > Subject: RE: [rbridge] IVLANs vs OVLANs
--> > 
--> > Silvano,
--> > 
--> > 	First of all, I will take very large exception to the way
--> > which you have over-loaded the term "CRED."  This term was coined
--> > to eliminate confusion caused by the various different was people
--> > were over-loading the term "Campus."
--> > 
--> > 	At the "core" of your question, however, is the issue of
--> > how VLANs interact in a bridged/RBridge environment.  It is not
--> > different than would be the case in a "classical bridged LAN."
--> > 
--> > 	This issue is based on a misconception that existed very
--> > early on in the life of the TRILL working group (in the first
--> > BoF, in fact).  The misconception is that VLAN connectivity may
--> > be provided by RBridges and/or bridges.
--> > 
--> > 	This is fundamentally incorrect.
--> > 
--> > 	Interconnection of VLANs is strictly a routing function.
--> > In deployed equipment that does this today, there may be some
--> > form of "smart VLAN bridging" that occurs in devices people are
--> > used to referring to as "bridges" or "switches."  That does not
--> > change the fact that forwarding from one VLAN to another is a
--> > "routing function."
--> > 
--> > 	Note that, in this context, when I say "forwarding from
--> > one VLAN to another" - I mean "VLAN" in the sense of "virtual
--> > LAN" as a logical concept.  This has nothing to do with the fact
--> > that a VLAN ID might change in traversing a VLAN-aware bridge.
--> > 
--> > 	Consequently, in the picture you have below, the VLANs
--> > represented by the VLAN-tag in the tunnel encapsulation may
--> > not be connected together by RB1.
--> > 
--> > 	To correctly restate your question, the original topology
--> > would be as follows:
--> > 
--> > 
--> >                 +-----+  1,2  +-----------+
--> >                 | RB1 |-------| Rtg Fnctn |
--> >                 +-----+       +-----------+
--> >                    |
--> >                    | 1,2
--> >                    |
--> >  +-----+   1    +-----+    2     +-----+
--> >  | RB2 |--------| SW1 |----------| RB3 |
--> >  +-----+        +-----+          +-----+
--> > 
--> > The resulting logical topology MUST then be as follows:
--> > 
--> > 
--> >  +-----+        +-----+       +-----------+
--> >  | RB2 |--------| RB1 |-------| Rtg Fnctn |
--> >  +-----+        +-----+       +-----+-----+
--> >                                     |
--> >                                  +--+--+          +-----+
--> >                                  | RB1 |----------| RB3 |
--> >                                  +-----+          +-----+
--> > 
--> > Since the "routing function" is orthogonal, and well understood,
--> > it does not make sense for us to try to combine this concept with
--> > RBridge behaviors and protocol interactions.
--> > 
--> > --
--> > Eric
--> > 
--> > 
--> > --> -----Original Message-----
--> > --> From: [e-mail]
--> > --> [mailto:[e-mail]] On Behalf Of Silvano Gai
--> > --> Sent: Tuesday, November 14, 2006 8:11 PM
--> > --> To: [e-mail]
--> > --> Subject: [rbridge] IVLANs vs OVLANs
--> > -->
--> > -->
--> > --> During the last WG meeting I had an action item to send an
--> > --> email on the
--> > --> VLAN issue. Here it is.
--> > -->
--> > --> In a previous email I introduced the concept of IVLAN 
--> and OVLAN.
--> > -->
--> > --> IVLAN refers to the VLAN present on the untagged frames,
--> > --> which must be
--> > --> propagated by ISIS, VLAN pruning must be performed and so
--> > --> on. All the
--> > --> IVLANs share the same core instance of ISIS.
--> > -->
--> > --> OVLAN refers to the fact that the traffic between two
--> > --> RBridges can be
--> > --> encapsulated into a VLAN.
--> > -->
--> > --> If we look to the format of a TRILL encapsulated frame the
--> > --> position of
--> > --> these two fields is as follow:
--> > -->
--> > --> +--------------------------------+
--> > --> |               DA               |
--> > --> +----------------+---------------+
--> > --> |       DA       |     SA        |
--> > --> +----------------+---------------+
--> > --> |               SA               |
--> > --> +--------------------------------+
--> > --> |    ET = 1Q     |   OVLAN ...   |
--> > --> +--------------------------------+
--> > --> |    ET = TRILL  | RES  |  TTL   |
--> > --> +--------------------------------+
--> > --> | Egress Add.    | Ingress Add.  |
--> > --> +--------------------------------+
--> > --> |               DA               |
--> > --> +----------------+---------------+
--> > --> |       DA       |     SA        |
--> > --> +----------------+---------------+
--> > --> |               SA               |
--> > --> +--------------------------------+
--> > --> |    ET = 1Q     |   IVLAN ...   |
--> > --> +--------------------------------+
--> > --> |             Payload            |
--> > -->
--> > --> Now let's consider the following topology:
--> > -->
--> > -->                +-----+
--> > -->                | RB1 |
--> > -->                +-----+
--> > -->                   |
--> > -->                   | 1,2
--> > -->                   |
--> > --> +-----+   1    +-----+    2     +-----+
--> > --> | RB2 |--------| SW1 |----------| RB3 |
--> > --> +-----+        +-----+          +-----+
--> > -->
--> > --> RB1, RB2, RB3 are Rbridges, SW1 is a classical 
--> Ethernet switch.
--> > --> The link between RB2 and SW1 is in OVLAN 1, the link
--> > --> between SW1 and RB3
--> > --> is in OVLAN 2 and the links between SW1 and RB1 is a 
--> trunk and it
--> > --> carries both OVLAN 1 and 2.
--> > -->
--> > --> Now my question is: "do we have one CRED or two?"
--> > -->
--> > --> a) possible answer: "we have one CRED". RB2 is adjacent to
--> > --> RB1 but not
--> > --> to RB3. The same applies to RB3 that is adjacent to RB1,
--> > --> but not RB2.
--> > --> RB1 is adjacent to both RB2 and RB3. There is a single core
--> > --> instance of
--> > --> ISIS. RB2 may reach RB3 through RB1.
--> > -->
--> > --> The TRILL equivalent topology is:
--> > -->
--> > --> +-----+        +-----+          +-----+
--> > --> | RB2 |--------| RB1 |----------| RB3 |
--> > --> +-----+        +-----+          +-----+
--> > -->
--> > --> b) another possible answer: "we have two CREDs". One is
--> > --> composed by RB2
--> > --> and RB1, the other by RB3 and RB1. RB2 may not reach RB3,
--> > --> since they are
--> > --> in different CREDs.
--> > -->
--> > --> The TRILL equivalent topologies are:
--> > -->
--> > --> +-----+        +-----+
--> > --> | RB2 |--------| RB1 |
--> > --> +-----+        +-----+
--> > -->
--> > --> +-----+          +-----+
--> > --> | RB1 |----------| RB3 |
--> > --> +-----+          +-----+
--> > -->
--> > --> I like a) and I hope we are in agreement that the right
--> > --> answer is a),
--> > --> but I haven't seen it explained in any of the documents.
--> > -->
--> > --> -- Silvano
--> > -->
--> > --> _______________________________________________
--> > --> rbridge mailing list
--> > --> [e-mail]
--> > --> http://mailman.postel.org/mailman/listinfo/rbridge
--> > -->
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAGFYm4a003248 for <[e-mail]>; Thu, 16 Nov 2006 07:34:48 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kAGFYifK027693; Thu, 16 Nov 2006 10:34:44 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07576;  Thu, 16 Nov 2006 10:34:43 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB6VCQZN>; Thu, 16 Nov 2006 10:34:43 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>, =?iso-8859-1?Q?Guillermo_Ib=E1?= =?iso-8859-1?Q?=F1ez?= <[e-mail]>, "J. R. Rivers" <[e-mail]>
Date: Thu, 16 Nov 2006 10:34:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAGFYm4a003248
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2006 15:35:02 -0000
Status: RO
Content-Length: 10326

Silvano,

	Actually, no.  We cannot stop making this argument, especially
in this venue.  Arguing that it might be appropriate to use IP is 
ALWAYS a legitimate argument in the IETF.  Period.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Thursday, November 16, 2006 10:11 AM
--> To: Gray, Eric; Guillermo Ib??ez; J. R. Rivers
--> Cc: [e-mail]; Radia Perlman
--> Subject: RE: [rbridge] Should we optimize the common case?
--> 
--> 
--> Eric,
--> 
--> 
--> > -----Original Message-----
--> > From: [e-mail] 
--> [mailto:[e-mail]] On
--> > Behalf Of Gray, Eric
--> > Sent: Wednesday, November 15, 2006 1:32 PM
--> > To: Guillermo Ib??ez; J. R. Rivers
--> > Cc: [e-mail]; Radia Perlman
--> > Subject: Re: [rbridge] Should we optimize the common case?
--> > 
--> > Guillermo,
--> > 
--> > 	In an ideal world, this would be true.  However, these ideas
--> > are recurring and - as a strictly practical issue - they have to
--> > cooperate in a world that has moved on from past iterations of the
--> > same ideas.
--> > 
--> > 	For the most part, the answer you're going to find here is:
--> > if you need hierarchical addressing, you've come to the 
--> right place
--> > - just use IP...
--> 
--> Can we stop making this argument? It is not constructive.
--> I think Guillermo understand the difference between Layer 2 
--> and IP, as well as we do.
--> 
--> I am not sure I agree the TRILL should use Hierarchical MAC 
--> addresses, but I definitely agree that this has been 
--> proposed in several different forums/occasions and it has 
--> some value.
--> 
--> We also need to clearly say that there are two different 
--> possible uses of Hierarchical MAC Addresses:
--> 
--> 1) The switch assigns to the end node of a hierarchical MAC 
--> address. This goes in the inner header.
--> 
--> 2) The switch uses in the outer header hierarchical MAC 
--> addresses to encode different kind of information.
--> 
--> IMHO 1) is interesting but it does not support legacy and 
--> therefore is pragmatically difficult. I also don't believe 
--> in NATting the MAC addresses.
--> 
--> 2) can be explored and used if needed.
--> 
--> -- Silvano
--> 
--> 
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: [e-mail]
--> > --> [mailto:[e-mail]] On Behalf Of 
--> Guillermo Ib??ez
--> > --> Sent: Wednesday, November 15, 2006 10:32 AM
--> > --> To: J. R. Rivers
--> > --> Cc: [e-mail]; Radia Perlman
--> > --> Subject: Re: [rbridge] Should we optimize the common case?
--> > -->
--> > --> While agreeing with some of the arguments, I see far 
--> from ideal for
--> > --> scalability that RBridges advertise host lists with a
--> > --> number of host L2
--> > --> addresses impossible to consolidate.
--> > --> Looking for some hierarchy and structure in L2 addresses,
--> > --> although not
--> > --> easy at first glance, may provide long term benefits 
--> in scalability.
--> > --> Guillermo
--> > -->
--> > --> J. R. Rivers escribi?:
--> > --> > I've worked on such systems, and while the address
--> > --> summarization creates a degree of scale, you generally find
--> > --> that the fixed association between endnode and switch is
--> > --> very restricting and limiting.
--> > --> >
--> > --> > This is one of the reasons that I find TRILL very
--> > --> clean... the relationship between an endnode and an rbridge
--> > --> is that of convenience, not requirement.
--> > --> >
--> > --> > I can build multi-homed networks... assuming that an edge
--> > --> rbridge can maintain multiple endhost->rbridge associations
--> > --> without changing the forwarding constructs of the rbridge
--> > --> "core".  This occurs because each edge rbridge advertises
--> > --> reachability to the host.
--> > --> >
--> > --> > I can redirect frames through an rbridge network without
--> > --> changing the underlying L2 constructs (as required by many
--> > --> IDS/crypto protocols).  Then I can forward them to their
--> > --> intended destinations.
--> > --> >
--> > --> > All of these require support from coordinating edge
--> > --> rbridges... the endhosts, other edge rbridges, and core
--> > --> rbridges are blissfully unaware of these goings on.
--> > --> >
--> > --> > All this comes from partitioning the system into a
--> > --> simple, fast, cheap HW forwarding plane and a fully SW
--> > --> managed control plane.
--> > --> >
--> > --> > JR
--> > --> >
--> > --> >
--> > --> >
--> > --> >> -----Original Message-----
--> > --> >> From: Guillermo Ib??ez [mailto:[e-mail]]
--> > --> >> Sent: Tuesday, November 14, 2006 2:37 AM
--> > --> >> To: Caitlin Bestler; Radia Perlman; J. R. Rivers; 
--> Silvano Gai
--> > --> >> Cc: [e-mail]
--> > --> >> Subject: Re: [rbridge] Should we optimize the common case?
--> > --> >>
--> > --> >> I think there is a misunderstanding.  This is IMHO a
--> > --> >> practical alternative:
--> > --> >> -An RBridge port is connected to a  "link" and receives
--> > --> frames from
--> > --> >> multiple hosts:  The RBridge builds an internal
--> > --> translation table of
--> > --> >> global MACs to hierarchical MACs (HMACs) assigned by him
--> > --> and replaces
--> > --> >> global MAC by hierarchical MAC in the original frame.
--> > --> >> -These hierarchical MAC addresses for hosts 
--> contain the RBridge
--> > --> >> Nickname, so it becomes *part* of the complete host address
--> > --> >> transmitted
--> > --> >> as "original" frame.  So these addresses should contain
--> > --> >> RBridge Nickname
--> > --> >> with host nickname appended (internal grouping of host
--> > --> nicknames per
--> > --> >> RBridge port ID would also help). To be defined.
--> > --> >> - Hierarchical MAC MAY also be used in the ARP response
--> > --> packets (when
--> > --> >> RBridge acts as proxy ARP or by interception of the host
--> > --> response
--> > --> >> packet), so the requester obtains the hierarchical MAC
--> > --> >> address instead
--> > --> >> of the global one and uses it for all transactions.
--> > --> >> - The hosts with hierarchical MAC addresses do not 
--> need being
--> > --> >> announced
--> > --> >> by the RBridges in their host lists, because their 
--> DR RBridge
--> > --> >> nickname
--> > --> >> is included in the hierarchical MAC address of host in
--> > --> the "original"
--> > --> >> (now altered with HMAC) frame.
--> > --> >> - Frames with inner hierarchical destination address need
--> > --> >> only to read
--> > --> >> the destination RBridge Nickname to obtain the 
--> egrees RBridge
--> > --> >> (no need
--> > --> >> to look host-RBridge table). The host list mechanism is
--> > --> not used by
--> > --> >> hosts whose RBridge handles them with hierarchical 
--> addressing.
--> > --> >> Both types, global and local hierarchical addresses may
--> > --> >> coexist. Local
--> > --> >> hierarchical save processing and enhance scalability.
--> > --> >> Hope this clarifies.
--> > --> >> Guillermo
--> > --> >>
--> > --> >> PD.
--> > --> >> Other issues
--> > --> >> -DHCP-like mechanism
--> > --> >> Hierarchical MACs can be assigned with DHCP like 
--> mechanism to
--> > --> >> hosts, but
--> > --> >> IMHO this has impact on end nodes, so it can not 
--> be the standard
--> > --> >> mechanism, only an option.
--> > --> >> - Generic hierarchical MAC addresses and masks (ref. Dr.
--> > --> >> Morales slide)
--> > --> >> I proposed the generic addressing format  that includes
--> > --> hierarchical
--> > --> >> masks looking for a generic addressing space, that could
--> > --> be useful to
--> > --> >> scale further RBridges in the future. I understand that at
--> > --> >> this stage of
--> > --> >> definition of RBridges to look for a fully generic
--> > --> format could be
--> > --> >> disruptive. However, the need for a generic hierarchical
--> > --> addressing
--> > --> >> space in Ethernet is growing.
--> > --> >>
--> > --> >>
--> > --> >>
--> > --> >>
--> > --> >> Caitlin Bestler escribi?:
--> > --> >>> Radia Perlman wrote:
--> > --> >>>
--> > --> >>>> Not sure I've been following this, but let me 
--> conjecture what
--> > --> >>>> people are suggesting, and if I'm right about 
--> the suggestion,
--> > --> >>>> I think it's a good idea. Correct me if it's not what
--> > --> people are
--> > --> >>>> saying.
--> > --> >>>>
--> > --> >>>> So I think what they are saying is the following:
--> > --> >>>> a) there are cases where an RBridge has a block 
--> of addresses
--> > --> >>>> (like DHCP) that it hands out to endnodes
--> > --> >>>> b) in that case, it would be nice if the RBridge can
--> > --> >>>> announce, in its LSP, the whole range of 
--> addresses, rather
--> > --> >>>> than reporting each individually
--> > --> >>>> c) the change would be an ability to express a 
--> range in the
--> > --> >>>> endnode announcement. This seems easy, but I 
--> think it would
--> > --> >>>> be best done with a 2nd TLV in IS-IS. The 1st 
--> TLV would be
--> > --> >> individual
--> > --> >>>> addresses. The 2nd TLV would be pairs of addresses
--> > --> (low, high). Or
--> > --> >>>> (low, increment), as in "starting with address X,
--> > --> >>>> 32 addresses" (which would take up a bit less space
--> > --> than two MAC
--> > --> >>>> addresses.
--> > --> >>>>
--> > --> >>>> I don't think of this as a hierarchical address---I just
--> > --> >>>> think of it as a range of addresses reachable 
--> from one RBridge.
--> > --> >>>>
--> > --> >>>>
--> > --> >>> Reduction in the total number of reports required 
--> to support N
--> > --> >>> addresses is probably the only benefit of "hierarchical
--> > --> addresses"
--> > --> >>> that we can achieve if we are going to support 
--> global-scope MAC
--> > --> >>> addresses as well. Which I'm certain everyone 
--> agrees is a given.
--> > --> >>>
--> > --> >>>
--> > --> >
--> > --> _______________________________________________
--> > --> rbridge mailing list
--> > --> [e-mail]
--> > --> http://mailman.postel.org/mailman/listinfo/rbridge
--> > -->
--> > 
--> > _______________________________________________
--> > rbridge mailing list
--> > [e-mail]
--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> 



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAGFVJLB001712 for <[e-mail]>; Thu, 16 Nov 2006 07:31:20 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kAGFVDfK027620; Thu, 16 Nov 2006 10:31:14 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07353;  Thu, 16 Nov 2006 10:31:12 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB6VCQXL>; Thu, 16 Nov 2006 10:31:12 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>
Date: Thu, 16 Nov 2006 10:31:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] IVLANs vs OVLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2006 15:31:27 -0000
Status: RO
Content-Length: 9580

Silvano,

	Sorry, but you are incorrect.

	Routers are "end-stations" to a layer 2 network - hence it is 
necessarily the case that TRILL frames MUST egress the RBridge CRED
prior to being delivered to a "routing function."  In the same way,
any frame delivered frome a "routing function" MUST ingress the CRED
for subsequent delivery in the form of TRILL frames.

	This is a logical distinction and does not - in any way - limit
your implementation choices.  Logically, what happens is:

1) the TRILL encapsulation is stripped, along with the SHIM header,
2) the frame is forwarded (possibly locally, possibly only logically) 
   to the component that implements the "routing function",
3) the remaining Ethernet header is stripped, delivering the data (an
   IP packet) - along with relevant packet information (such as length) 
   - to the "routing function",
4) the "routing function" is used (including, for example ACLs, policy
   based forwarding, etc.) to determine how to forward the _packet_ -
   including forwarding to a logical "interface" on a distinct VLAN,
5) after the forwarding decision is made, appropriate encapsulation is
   added to the IP packet, again converting it (in this case) to an
   Ethernet frame,
6) the resulting Ethernet frame is forwarded (possibly locally, possibly 
   only logically) from the component implementing the "routing function"
   to the appropriate RBridge component,
7) the RBridge component then provides ingress for the frame by adding
   a SHIM and re-encapsulating the frame with the appropriate TRILL
   encapsulation.

	To RE-EMPHASIZE, this is what happens logically.  What you do in
your implementation may differ substantially from this.  It may - for
example - be quite a bit simpler.  How you do this is why you get paid
the big bucks.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Thursday, November 16, 2006 1:45 AM
--> To: Gray, Eric
--> Cc: [e-mail]
--> Subject: RE: [rbridge] IVLANs vs OVLANs
--> 
--> 
--> Eric,
--> 
--> On a second thought, you cannot put a router between OVLAN=1 and
--> OVLAN=2, the frame is not routable, since its Ethertype is 
--> TRILL, not
--> IPv4 or IPv6.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[e-mail]]
--> > Sent: Wednesday, November 15, 2006 12:13 PM
--> > To: Silvano Gai
--> > Cc: [e-mail]
--> > Subject: RE: [rbridge] IVLANs vs OVLANs
--> > 
--> > Silvano,
--> > 
--> > 	First of all, I will take very large exception to the way
--> > which you have over-loaded the term "CRED."  This term was coined
--> > to eliminate confusion caused by the various different was people
--> > were over-loading the term "Campus."
--> > 
--> > 	At the "core" of your question, however, is the issue of
--> > how VLANs interact in a bridged/RBridge environment.  It is not
--> > different than would be the case in a "classical bridged LAN."
--> > 
--> > 	This issue is based on a misconception that existed very
--> > early on in the life of the TRILL working group (in the first
--> > BoF, in fact).  The misconception is that VLAN connectivity may
--> > be provided by RBridges and/or bridges.
--> > 
--> > 	This is fundamentally incorrect.
--> > 
--> > 	Interconnection of VLANs is strictly a routing function.
--> > In deployed equipment that does this today, there may be some
--> > form of "smart VLAN bridging" that occurs in devices people are
--> > used to referring to as "bridges" or "switches."  That does not
--> > change the fact that forwarding from one VLAN to another is a
--> > "routing function."
--> > 
--> > 	Note that, in this context, when I say "forwarding from
--> > one VLAN to another" - I mean "VLAN" in the sense of "virtual
--> > LAN" as a logical concept.  This has nothing to do with the fact
--> > that a VLAN ID might change in traversing a VLAN-aware bridge.
--> > 
--> > 	Consequently, in the picture you have below, the VLANs
--> > represented by the VLAN-tag in the tunnel encapsulation may
--> > not be connected together by RB1.
--> > 
--> > 	To correctly restate your question, the original topology
--> > would be as follows:
--> > 
--> > 
--> >                 +-----+  1,2  +-----------+
--> >                 | RB1 |-------| Rtg Fnctn |
--> >                 +-----+       +-----------+
--> >                    |
--> >                    | 1,2
--> >                    |
--> >  +-----+   1    +-----+    2     +-----+
--> >  | RB2 |--------| SW1 |----------| RB3 |
--> >  +-----+        +-----+          +-----+
--> > 
--> > The resulting logical topology MUST then be as follows:
--> > 
--> > 
--> >  +-----+        +-----+       +-----------+
--> >  | RB2 |--------| RB1 |-------| Rtg Fnctn |
--> >  +-----+        +-----+       +-----+-----+
--> >                                     |
--> >                                  +--+--+          +-----+
--> >                                  | RB1 |----------| RB3 |
--> >                                  +-----+          +-----+
--> > 
--> > Since the "routing function" is orthogonal, and well understood,
--> > it does not make sense for us to try to combine this concept with
--> > RBridge behaviors and protocol interactions.
--> > 
--> > --
--> > Eric
--> > 
--> > 
--> > --> -----Original Message-----
--> > --> From: [e-mail]
--> > --> [mailto:[e-mail]] On Behalf Of Silvano Gai
--> > --> Sent: Tuesday, November 14, 2006 8:11 PM
--> > --> To: [e-mail]
--> > --> Subject: [rbridge] IVLANs vs OVLANs
--> > -->
--> > -->
--> > --> During the last WG meeting I had an action item to send an
--> > --> email on the
--> > --> VLAN issue. Here it is.
--> > -->
--> > --> In a previous email I introduced the concept of IVLAN 
--> and OVLAN.
--> > -->
--> > --> IVLAN refers to the VLAN present on the untagged frames,
--> > --> which must be
--> > --> propagated by ISIS, VLAN pruning must be performed and so
--> > --> on. All the
--> > --> IVLANs share the same core instance of ISIS.
--> > -->
--> > --> OVLAN refers to the fact that the traffic between two
--> > --> RBridges can be
--> > --> encapsulated into a VLAN.
--> > -->
--> > --> If we look to the format of a TRILL encapsulated frame the
--> > --> position of
--> > --> these two fields is as follow:
--> > -->
--> > --> +--------------------------------+
--> > --> |               DA               |
--> > --> +----------------+---------------+
--> > --> |       DA       |     SA        |
--> > --> +----------------+---------------+
--> > --> |               SA               |
--> > --> +--------------------------------+
--> > --> |    ET = 1Q     |   OVLAN ...   |
--> > --> +--------------------------------+
--> > --> |    ET = TRILL  | RES  |  TTL   |
--> > --> +--------------------------------+
--> > --> | Egress Add.    | Ingress Add.  |
--> > --> +--------------------------------+
--> > --> |               DA               |
--> > --> +----------------+---------------+
--> > --> |       DA       |     SA        |
--> > --> +----------------+---------------+
--> > --> |               SA               |
--> > --> +--------------------------------+
--> > --> |    ET = 1Q     |   IVLAN ...   |
--> > --> +--------------------------------+
--> > --> |             Payload            |
--> > -->
--> > --> Now let's consider the following topology:
--> > -->
--> > -->                +-----+
--> > -->                | RB1 |
--> > -->                +-----+
--> > -->                   |
--> > -->                   | 1,2
--> > -->                   |
--> > --> +-----+   1    +-----+    2     +-----+
--> > --> | RB2 |--------| SW1 |----------| RB3 |
--> > --> +-----+        +-----+          +-----+
--> > -->
--> > --> RB1, RB2, RB3 are Rbridges, SW1 is a classical 
--> Ethernet switch.
--> > --> The link between RB2 and SW1 is in OVLAN 1, the link
--> > --> between SW1 and RB3
--> > --> is in OVLAN 2 and the links between SW1 and RB1 is a 
--> trunk and it
--> > --> carries both OVLAN 1 and 2.
--> > -->
--> > --> Now my question is: "do we have one CRED or two?"
--> > -->
--> > --> a) possible answer: "we have one CRED". RB2 is adjacent to
--> > --> RB1 but not
--> > --> to RB3. The same applies to RB3 that is adjacent to RB1,
--> > --> but not RB2.
--> > --> RB1 is adjacent to both RB2 and RB3. There is a single core
--> > --> instance of
--> > --> ISIS. RB2 may reach RB3 through RB1.
--> > -->
--> > --> The TRILL equivalent topology is:
--> > -->
--> > --> +-----+        +-----+          +-----+
--> > --> | RB2 |--------| RB1 |----------| RB3 |
--> > --> +-----+        +-----+          +-----+
--> > -->
--> > --> b) another possible answer: "we have two CREDs". One is
--> > --> composed by RB2
--> > --> and RB1, the other by RB3 and RB1. RB2 may not reach RB3,
--> > --> since they are
--> > --> in different CREDs.
--> > -->
--> > --> The TRILL equivalent topologies are:
--> > -->
--> > --> +-----+        +-----+
--> > --> | RB2 |--------| RB1 |
--> > --> +-----+        +-----+
--> > -->
--> > --> +-----+          +-----+
--> > --> | RB1 |----------| RB3 |
--> > --> +-----+          +-----+
--> > -->
--> > --> I like a) and I hope we are in agreement that the right
--> > --> answer is a),
--> > --> but I haven't seen it explained in any of the documents.
--> > -->
--> > --> -- Silvano
--> > -->
--> > --> _______________________________________________
--> > --> rbridge mailing list
--> > --> [e-mail]
--> > --> http://mailman.postel.org/mailman/listinfo/rbridge
--> > -->
--> 


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAGFDwok025474 for <[e-mail]>; Thu, 16 Nov 2006 07:13:58 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Thu, 16 Nov 2006 07:13:57 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IEEE meeting
Thread-Index: AccJkYuf5izyShwYSbu60yrtscx7BwAADlCA
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAGFDwok025474
Cc: [e-mail]
Subject: Re: [rbridge] IEEE meeting
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2006 15:14:05 -0000
Status: RO
Content-Length: 1249

No problem, 

Take your time

Thanks

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Thursday, November 16, 2006 7:12 AM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: RE: IEEE meeting
> 
> Silvano, et al,
> 
> I will be submitting a report to the WG as soon as possible.
> 
> To make sure there are no misunderstandings and the proper "protocol"
> is observed, I must first pass my intended report by way of the IEEE
> 802 chairs and the IETF/IEEE liaisons.
> 
> I have not yet done that, though I have started compiling notes from
> the meeting.
> 
> Please understand that the notion of even attending this meeting came
> up rather recently, so time for it (as well as time for reporting it)
> was not included in my plans for this month.  That does not mean it
> will not get done, only that it may not get done this week...
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[e-mail]]
> --> Sent: Thursday, November 16, 2006 1:46 AM
> --> To: Gray, Eric
> --> Cc: [e-mail]
> --> Subject: IEEE meeting
> -->
> -->
> --> Eric,
> -->
> --> How did the TRILL presentation to IEEE go?
> -->
> --> Thanks
> -->
> --> -- Silvano
> -->



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAGFBq71024311 for <[e-mail]>; Thu, 16 Nov 2006 07:11:52 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kAGFBofK027230; Thu, 16 Nov 2006 10:11:50 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA06134;  Thu, 16 Nov 2006 10:11:49 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB6VCQKW>; Thu, 16 Nov 2006 10:11:49 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>
Date: Thu, 16 Nov 2006 10:11:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] IEEE meeting
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2006 15:12:35 -0000
Status: RO
Content-Length: 939

Silvano, et al,

I will be submitting a report to the WG as soon as possible.

To make sure there are no misunderstandings and the proper "protocol"
is observed, I must first pass my intended report by way of the IEEE
802 chairs and the IETF/IEEE liaisons. 

I have not yet done that, though I have started compiling notes from
the meeting.

Please understand that the notion of even attending this meeting came
up rather recently, so time for it (as well as time for reporting it)
was not included in my plans for this month.  That does not mean it 
will not get done, only that it may not get done this week...

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Thursday, November 16, 2006 1:46 AM
--> To: Gray, Eric
--> Cc: [e-mail]
--> Subject: IEEE meeting
--> 
--> 
--> Eric,
--> 
--> How did the TRILL presentation to IEEE go?
--> 
--> Thanks
--> 
--> -- Silvano
--> 


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAGFBN9Z024131 for <[e-mail]>; Thu, 16 Nov 2006 07:11:23 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Thu, 16 Nov 2006 07:11:22 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: AccI/dsDOY+5ivXKQgq2VaXbvxrtEgAkn95A
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>, "J. R. Rivers" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAGFBN9Z024131
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2006 15:11:35 -0000
Status: RO
Content-Length: 8789

Eric,


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Gray, Eric
> Sent: Wednesday, November 15, 2006 1:32 PM
> To: Guillermo Ib??ez; J. R. Rivers
> Cc: [e-mail]; Radia Perlman
> Subject: Re: [rbridge] Should we optimize the common case?
> 
> Guillermo,
> 
> 	In an ideal world, this would be true.  However, these ideas
> are recurring and - as a strictly practical issue - they have to
> cooperate in a world that has moved on from past iterations of the
> same ideas.
> 
> 	For the most part, the answer you're going to find here is:
> if you need hierarchical addressing, you've come to the right place
> - just use IP...

Can we stop making this argument? It is not constructive.
I think Guillermo understand the difference between Layer 2 and IP, as well as we do.

I am not sure I agree the TRILL should use Hierarchical MAC addresses, but I definitely agree that this has been proposed in several different forums/occasions and it has some value.

We also need to clearly say that there are two different possible uses of Hierarchical MAC Addresses:

1) The switch assigns to the end node of a hierarchical MAC address. This goes in the inner header.

2) The switch uses in the outer header hierarchical MAC addresses to encode different kind of information.

IMHO 1) is interesting but it does not support legacy and therefore is pragmatically difficult. I also don't believe in NATting the MAC addresses.

2) can be explored and used if needed.

-- Silvano


> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [e-mail]
> --> [mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
> --> Sent: Wednesday, November 15, 2006 10:32 AM
> --> To: J. R. Rivers
> --> Cc: [e-mail]; Radia Perlman
> --> Subject: Re: [rbridge] Should we optimize the common case?
> -->
> --> While agreeing with some of the arguments, I see far from ideal for
> --> scalability that RBridges advertise host lists with a
> --> number of host L2
> --> addresses impossible to consolidate.
> --> Looking for some hierarchy and structure in L2 addresses,
> --> although not
> --> easy at first glance, may provide long term benefits in scalability.
> --> Guillermo
> -->
> --> J. R. Rivers escribi?:
> --> > I've worked on such systems, and while the address
> --> summarization creates a degree of scale, you generally find
> --> that the fixed association between endnode and switch is
> --> very restricting and limiting.
> --> >
> --> > This is one of the reasons that I find TRILL very
> --> clean... the relationship between an endnode and an rbridge
> --> is that of convenience, not requirement.
> --> >
> --> > I can build multi-homed networks... assuming that an edge
> --> rbridge can maintain multiple endhost->rbridge associations
> --> without changing the forwarding constructs of the rbridge
> --> "core".  This occurs because each edge rbridge advertises
> --> reachability to the host.
> --> >
> --> > I can redirect frames through an rbridge network without
> --> changing the underlying L2 constructs (as required by many
> --> IDS/crypto protocols).  Then I can forward them to their
> --> intended destinations.
> --> >
> --> > All of these require support from coordinating edge
> --> rbridges... the endhosts, other edge rbridges, and core
> --> rbridges are blissfully unaware of these goings on.
> --> >
> --> > All this comes from partitioning the system into a
> --> simple, fast, cheap HW forwarding plane and a fully SW
> --> managed control plane.
> --> >
> --> > JR
> --> >
> --> >
> --> >
> --> >> -----Original Message-----
> --> >> From: Guillermo Ib??ez [mailto:[e-mail]]
> --> >> Sent: Tuesday, November 14, 2006 2:37 AM
> --> >> To: Caitlin Bestler; Radia Perlman; J. R. Rivers; Silvano Gai
> --> >> Cc: [e-mail]
> --> >> Subject: Re: [rbridge] Should we optimize the common case?
> --> >>
> --> >> I think there is a misunderstanding.  This is IMHO a
> --> >> practical alternative:
> --> >> -An RBridge port is connected to a  "link" and receives
> --> frames from
> --> >> multiple hosts:  The RBridge builds an internal
> --> translation table of
> --> >> global MACs to hierarchical MACs (HMACs) assigned by him
> --> and replaces
> --> >> global MAC by hierarchical MAC in the original frame.
> --> >> -These hierarchical MAC addresses for hosts contain the RBridge
> --> >> Nickname, so it becomes *part* of the complete host address
> --> >> transmitted
> --> >> as "original" frame.  So these addresses should contain
> --> >> RBridge Nickname
> --> >> with host nickname appended (internal grouping of host
> --> nicknames per
> --> >> RBridge port ID would also help). To be defined.
> --> >> - Hierarchical MAC MAY also be used in the ARP response
> --> packets (when
> --> >> RBridge acts as proxy ARP or by interception of the host
> --> response
> --> >> packet), so the requester obtains the hierarchical MAC
> --> >> address instead
> --> >> of the global one and uses it for all transactions.
> --> >> - The hosts with hierarchical MAC addresses do not need being
> --> >> announced
> --> >> by the RBridges in their host lists, because their DR RBridge
> --> >> nickname
> --> >> is included in the hierarchical MAC address of host in
> --> the "original"
> --> >> (now altered with HMAC) frame.
> --> >> - Frames with inner hierarchical destination address need
> --> >> only to read
> --> >> the destination RBridge Nickname to obtain the egrees RBridge
> --> >> (no need
> --> >> to look host-RBridge table). The host list mechanism is
> --> not used by
> --> >> hosts whose RBridge handles them with hierarchical addressing.
> --> >> Both types, global and local hierarchical addresses may
> --> >> coexist. Local
> --> >> hierarchical save processing and enhance scalability.
> --> >> Hope this clarifies.
> --> >> Guillermo
> --> >>
> --> >> PD.
> --> >> Other issues
> --> >> -DHCP-like mechanism
> --> >> Hierarchical MACs can be assigned with DHCP like mechanism to
> --> >> hosts, but
> --> >> IMHO this has impact on end nodes, so it can not be the standard
> --> >> mechanism, only an option.
> --> >> - Generic hierarchical MAC addresses and masks (ref. Dr.
> --> >> Morales slide)
> --> >> I proposed the generic addressing format  that includes
> --> hierarchical
> --> >> masks looking for a generic addressing space, that could
> --> be useful to
> --> >> scale further RBridges in the future. I understand that at
> --> >> this stage of
> --> >> definition of RBridges to look for a fully generic
> --> format could be
> --> >> disruptive. However, the need for a generic hierarchical
> --> addressing
> --> >> space in Ethernet is growing.
> --> >>
> --> >>
> --> >>
> --> >>
> --> >> Caitlin Bestler escribi?:
> --> >>> Radia Perlman wrote:
> --> >>>
> --> >>>> Not sure I've been following this, but let me conjecture what
> --> >>>> people are suggesting, and if I'm right about the suggestion,
> --> >>>> I think it's a good idea. Correct me if it's not what
> --> people are
> --> >>>> saying.
> --> >>>>
> --> >>>> So I think what they are saying is the following:
> --> >>>> a) there are cases where an RBridge has a block of addresses
> --> >>>> (like DHCP) that it hands out to endnodes
> --> >>>> b) in that case, it would be nice if the RBridge can
> --> >>>> announce, in its LSP, the whole range of addresses, rather
> --> >>>> than reporting each individually
> --> >>>> c) the change would be an ability to express a range in the
> --> >>>> endnode announcement. This seems easy, but I think it would
> --> >>>> be best done with a 2nd TLV in IS-IS. The 1st TLV would be
> --> >> individual
> --> >>>> addresses. The 2nd TLV would be pairs of addresses
> --> (low, high). Or
> --> >>>> (low, increment), as in "starting with address X,
> --> >>>> 32 addresses" (which would take up a bit less space
> --> than two MAC
> --> >>>> addresses.
> --> >>>>
> --> >>>> I don't think of this as a hierarchical address---I just
> --> >>>> think of it as a range of addresses reachable from one RBridge.
> --> >>>>
> --> >>>>
> --> >>> Reduction in the total number of reports required to support N
> --> >>> addresses is probably the only benefit of "hierarchical
> --> addresses"
> --> >>> that we can achieve if we are going to support global-scope MAC
> --> >>> addresses as well. Which I'm certain everyone agrees is a given.
> --> >>>
> --> >>>
> --> >
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAGF6jTZ022089 for <[e-mail]>; Thu, 16 Nov 2006 07:06:46 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kAGF6dfK027127; Thu, 16 Nov 2006 10:06:40 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05707;  Thu, 16 Nov 2006 10:06:38 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB6VCQFZ>; Thu, 16 Nov 2006 10:06:38 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>, "Gray, Eric" <[e-mail]>
Date: Thu, 16 Nov 2006 10:06:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAGF6jTZ022089
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2006 15:07:07 -0000
Status: RO
Content-Length: 9041

Guillermo,

	Are you sure we are not?  Are there not a plethora of L2
overlay services based on one or more IP-based tunneling schemes?

--
Eric 

--> -----Original Message-----
--> From: Guillermo Ib??ez [mailto:[e-mail]] 
--> Sent: Thursday, November 16, 2006 1:42 AM
--> To: Gray, Eric
--> Cc: J. R. Rivers; [e-mail]; Radia Perlman
--> Subject: Re: [rbridge] Should we optimize the common case?
--> 
--> 
--> 
--> Gray, Eric escribi?:
--> > Guillermo,
--> >
--> > 	In an ideal world, this would be true.  However, these ideas
--> > are recurring and - as a strictly practical issue - they have to 
--> > cooperate in a world that has moved on from past 
--> iterations of the 
--> > same ideas
--> >   
--> > 	For the most part, the answer you're going to find here is:
--> > if you need hierarchical addressing, you've come to the 
--> right place
--> >   
--> > - just use IP...
--> >   
--> If this is so, why are not using IP to scale up  Metro 
--> Ethernet Networks 
--> and Provider Backbone Bridges? 
--> > --
--> > Eric
--> >
--> > --> -----Original Message-----
--> > --> From: [e-mail] 
--> > --> [mailto:[e-mail]] On Behalf Of 
--> Guillermo Ib??ez
--> > --> Sent: Wednesday, November 15, 2006 10:32 AM
--> > --> To: J. R. Rivers
--> > --> Cc: [e-mail]; Radia Perlman
--> > --> Subject: Re: [rbridge] Should we optimize the common case?
--> > --> 
--> > --> While agreeing with some of the arguments, I see far 
--> from ideal for 
--> > --> scalability that RBridges advertise host lists with a 
--> > --> number of host L2 
--> > --> addresses impossible to consolidate.
--> > --> Looking for some hierarchy and structure in L2 addresses, 
--> > --> although not 
--> > --> easy at first glance, may provide long term benefits 
--> in scalability.
--> > --> Guillermo
--> > --> 
--> > --> J. R. Rivers escribi?:
--> > --> > I've worked on such systems, and while the address 
--> > --> summarization creates a degree of scale, you generally find 
--> > --> that the fixed association between endnode and switch is 
--> > --> very restricting and limiting.  
--> > --> > 
--> > --> > This is one of the reasons that I find TRILL very 
--> > --> clean... the relationship between an endnode and an rbridge 
--> > --> is that of convenience, not requirement.
--> > --> > 
--> > --> > I can build multi-homed networks... assuming that an edge 
--> > --> rbridge can maintain multiple endhost->rbridge associations 
--> > --> without changing the forwarding constructs of the rbridge 
--> > --> "core".  This occurs because each edge rbridge advertises 
--> > --> reachability to the host.
--> > --> > 
--> > --> > I can redirect frames through an rbridge network without 
--> > --> changing the underlying L2 constructs (as required by many 
--> > --> IDS/crypto protocols).  Then I can forward them to their 
--> > --> intended destinations.
--> > --> > 
--> > --> > All of these require support from coordinating edge 
--> > --> rbridges... the endhosts, other edge rbridges, and core 
--> > --> rbridges are blissfully unaware of these goings on.
--> > --> > 
--> > --> > All this comes from partitioning the system into a 
--> > --> simple, fast, cheap HW forwarding plane and a fully SW 
--> > --> managed control plane.
--> > --> > 
--> > --> > JR
--> > --> > 
--> > --> > 
--> > --> > 
--> > --> >> -----Original Message-----
--> > --> >> From: Guillermo Ib??ez [mailto:[e-mail]] 
--> > --> >> Sent: Tuesday, November 14, 2006 2:37 AM
--> > --> >> To: Caitlin Bestler; Radia Perlman; J. R. Rivers; 
--> Silvano Gai
--> > --> >> Cc: [e-mail]
--> > --> >> Subject: Re: [rbridge] Should we optimize the common case?
--> > --> >>
--> > --> >> I think there is a misunderstanding.  This is IMHO a 
--> > --> >> practical alternative:
--> > --> >> -An RBridge port is connected to a  "link" and receives 
--> > --> frames from 
--> > --> >> multiple hosts:  The RBridge builds an internal 
--> > --> translation table of  
--> > --> >> global MACs to hierarchical MACs (HMACs) assigned by him 
--> > --> and replaces 
--> > --> >> global MAC by hierarchical MAC in the original frame.
--> > --> >> -These hierarchical MAC addresses for hosts 
--> contain the RBridge 
--> > --> >> Nickname, so it becomes *part* of the complete 
--> host address 
--> > --> >> transmitted 
--> > --> >> as "original" frame.  So these addresses should contain 
--> > --> >> RBridge Nickname 
--> > --> >> with host nickname appended (internal grouping of host 
--> > --> nicknames per 
--> > --> >> RBridge port ID would also help). To be defined.
--> > --> >> - Hierarchical MAC MAY also be used in the ARP response 
--> > --> packets (when 
--> > --> >> RBridge acts as proxy ARP or by interception of the host 
--> > --> response 
--> > --> >> packet), so the requester obtains the hierarchical MAC 
--> > --> >> address instead 
--> > --> >> of the global one and uses it for all transactions.
--> > --> >> - The hosts with hierarchical MAC addresses do not 
--> need being 
--> > --> >> announced 
--> > --> >> by the RBridges in their host lists, because their 
--> DR RBridge 
--> > --> >> nickname  
--> > --> >> is included in the hierarchical MAC address of host in 
--> > --> the "original" 
--> > --> >> (now altered with HMAC) frame.
--> > --> >> - Frames with inner hierarchical destination address need 
--> > --> >> only to read 
--> > --> >> the destination RBridge Nickname to obtain the 
--> egrees RBridge 
--> > --> >> (no need 
--> > --> >> to look host-RBridge table). The host list mechanism is 
--> > --> not used by  
--> > --> >> hosts whose RBridge handles them with hierarchical 
--> addressing. 
--> > --> >> Both types, global and local hierarchical addresses may 
--> > --> >> coexist. Local 
--> > --> >> hierarchical save processing and enhance scalability.
--> > --> >> Hope this clarifies.
--> > --> >> Guillermo
--> > --> >>
--> > --> >> PD.
--> > --> >> Other issues
--> > --> >> -DHCP-like mechanism
--> > --> >> Hierarchical MACs can be assigned with DHCP like 
--> mechanism to 
--> > --> >> hosts, but 
--> > --> >> IMHO this has impact on end nodes, so it can not 
--> be the standard 
--> > --> >> mechanism, only an option.
--> > --> >> - Generic hierarchical MAC addresses and masks (ref. Dr. 
--> > --> >> Morales slide)
--> > --> >> I proposed the generic addressing format  that includes 
--> > --> hierarchical 
--> > --> >> masks looking for a generic addressing space, that could 
--> > --> be useful to 
--> > --> >> scale further RBridges in the future. I understand that at 
--> > --> >> this stage of 
--> > --> >> definition of RBridges to look for a fully generic 
--> > --> format could be 
--> > --> >> disruptive. However, the need for a generic hierarchical 
--> > --> addressing 
--> > --> >> space in Ethernet is growing.
--> > --> >>  
--> > --> >>
--> > --> >>
--> > --> >>
--> > --> >> Caitlin Bestler escribi?:
--> > --> >>> Radia Perlman wrote:
--> > --> >>>   
--> > --> >>>> Not sure I've been following this, but let me 
--> conjecture what
--> > --> >>>> people are suggesting, and if I'm right about 
--> the suggestion,
--> > --> >>>> I think it's a good idea. Correct me if it's not what 
--> > --> people are
--> > --> >>>> saying. 
--> > --> >>>>
--> > --> >>>> So I think what they are saying is the following:
--> > --> >>>> a) there are cases where an RBridge has a block 
--> of addresses
--> > --> >>>> (like DHCP) that it hands out to endnodes
--> > --> >>>> b) in that case, it would be nice if the RBridge can
--> > --> >>>> announce, in its LSP, the whole range of 
--> addresses, rather
--> > --> >>>> than reporting each individually
--> > --> >>>> c) the change would be an ability to express a 
--> range in the
--> > --> >>>> endnode announcement. This seems easy, but I 
--> think it would
--> > --> >>>> be best done with a 2nd TLV in IS-IS. The 1st 
--> TLV would be 
--> > --> >> individual
--> > --> >>>> addresses. The 2nd TLV would be pairs of addresses 
--> > --> (low, high). Or
--> > --> >>>> (low, increment), as in "starting with address X,
--> > --> >>>> 32 addresses" (which would take up a bit less space 
--> > --> than two MAC
--> > --> >>>> addresses. 
--> > --> >>>>
--> > --> >>>> I don't think of this as a hierarchical address---I just
--> > --> >>>> think of it as a range of addresses reachable 
--> from one RBridge.
--> > --> >>>>
--> > --> >>>>     
--> > --> >>> Reduction in the total number of reports required 
--> to support N
--> > --> >>> addresses is probably the only benefit of "hierarchical 
--> > --> addresses"
--> > --> >>> that we can achieve if we are going to support 
--> global-scope MAC
--> > --> >>> addresses as well. Which I'm certain everyone 
--> agrees is a given.
--> > --> >>>
--> > --> >>>   
--> > --> > 
--> > --> _______________________________________________
--> > --> rbridge mailing list
--> > --> [e-mail]
--> > --> http://mailman.postel.org/mailman/listinfo/rbridge
--> > --> 
--> >   
--> 



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAG6vqCr016545 for <[e-mail]>; Wed, 15 Nov 2006 22:57:52 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Wed, 15 Nov 2006 22:44:49 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] IVLANs vs OVLANs
Thread-Index: AccI8m2jZzGMkQRLTWe1FSQHEKwxhQAV+fvg
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAG6vqCr016545
Cc: [e-mail]
Subject: Re: [rbridge] IVLANs vs OVLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2006 06:58:01 -0000
Status: RO
Content-Length: 6740

Eric,

On a second thought, you cannot put a router between OVLAN=1 and
OVLAN=2, the frame is not routable, since its Ethertype is TRILL, not
IPv4 or IPv6.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Wednesday, November 15, 2006 12:13 PM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: RE: [rbridge] IVLANs vs OVLANs
> 
> Silvano,
> 
> 	First of all, I will take very large exception to the way
> which you have over-loaded the term "CRED."  This term was coined
> to eliminate confusion caused by the various different was people
> were over-loading the term "Campus."
> 
> 	At the "core" of your question, however, is the issue of
> how VLANs interact in a bridged/RBridge environment.  It is not
> different than would be the case in a "classical bridged LAN."
> 
> 	This issue is based on a misconception that existed very
> early on in the life of the TRILL working group (in the first
> BoF, in fact).  The misconception is that VLAN connectivity may
> be provided by RBridges and/or bridges.
> 
> 	This is fundamentally incorrect.
> 
> 	Interconnection of VLANs is strictly a routing function.
> In deployed equipment that does this today, there may be some
> form of "smart VLAN bridging" that occurs in devices people are
> used to referring to as "bridges" or "switches."  That does not
> change the fact that forwarding from one VLAN to another is a
> "routing function."
> 
> 	Note that, in this context, when I say "forwarding from
> one VLAN to another" - I mean "VLAN" in the sense of "virtual
> LAN" as a logical concept.  This has nothing to do with the fact
> that a VLAN ID might change in traversing a VLAN-aware bridge.
> 
> 	Consequently, in the picture you have below, the VLANs
> represented by the VLAN-tag in the tunnel encapsulation may
> not be connected together by RB1.
> 
> 	To correctly restate your question, the original topology
> would be as follows:
> 
> 
>                 +-----+  1,2  +-----------+
>                 | RB1 |-------| Rtg Fnctn |
>                 +-----+       +-----------+
>                    |
>                    | 1,2
>                    |
>  +-----+   1    +-----+    2     +-----+
>  | RB2 |--------| SW1 |----------| RB3 |
>  +-----+        +-----+          +-----+
> 
> The resulting logical topology MUST then be as follows:
> 
> 
>  +-----+        +-----+       +-----------+
>  | RB2 |--------| RB1 |-------| Rtg Fnctn |
>  +-----+        +-----+       +-----+-----+
>                                     |
>                                  +--+--+          +-----+
>                                  | RB1 |----------| RB3 |
>                                  +-----+          +-----+
> 
> Since the "routing function" is orthogonal, and well understood,
> it does not make sense for us to try to combine this concept with
> RBridge behaviors and protocol interactions.
> 
> --
> Eric
> 
> 
> --> -----Original Message-----
> --> From: [e-mail]
> --> [mailto:[e-mail]] On Behalf Of Silvano Gai
> --> Sent: Tuesday, November 14, 2006 8:11 PM
> --> To: [e-mail]
> --> Subject: [rbridge] IVLANs vs OVLANs
> -->
> -->
> --> During the last WG meeting I had an action item to send an
> --> email on the
> --> VLAN issue. Here it is.
> -->
> --> In a previous email I introduced the concept of IVLAN and OVLAN.
> -->
> --> IVLAN refers to the VLAN present on the untagged frames,
> --> which must be
> --> propagated by ISIS, VLAN pruning must be performed and so
> --> on. All the
> --> IVLANs share the same core instance of ISIS.
> -->
> --> OVLAN refers to the fact that the traffic between two
> --> RBridges can be
> --> encapsulated into a VLAN.
> -->
> --> If we look to the format of a TRILL encapsulated frame the
> --> position of
> --> these two fields is as follow:
> -->
> --> +--------------------------------+
> --> |               DA               |
> --> +----------------+---------------+
> --> |       DA       |     SA        |
> --> +----------------+---------------+
> --> |               SA               |
> --> +--------------------------------+
> --> |    ET = 1Q     |   OVLAN ...   |
> --> +--------------------------------+
> --> |    ET = TRILL  | RES  |  TTL   |
> --> +--------------------------------+
> --> | Egress Add.    | Ingress Add.  |
> --> +--------------------------------+
> --> |               DA               |
> --> +----------------+---------------+
> --> |       DA       |     SA        |
> --> +----------------+---------------+
> --> |               SA               |
> --> +--------------------------------+
> --> |    ET = 1Q     |   IVLAN ...   |
> --> +--------------------------------+
> --> |             Payload            |
> -->
> --> Now let's consider the following topology:
> -->
> -->                +-----+
> -->                | RB1 |
> -->                +-----+
> -->                   |
> -->                   | 1,2
> -->                   |
> --> +-----+   1    +-----+    2     +-----+
> --> | RB2 |--------| SW1 |----------| RB3 |
> --> +-----+        +-----+          +-----+
> -->
> --> RB1, RB2, RB3 are Rbridges, SW1 is a classical Ethernet switch.
> --> The link between RB2 and SW1 is in OVLAN 1, the link
> --> between SW1 and RB3
> --> is in OVLAN 2 and the links between SW1 and RB1 is a trunk and it
> --> carries both OVLAN 1 and 2.
> -->
> --> Now my question is: "do we have one CRED or two?"
> -->
> --> a) possible answer: "we have one CRED". RB2 is adjacent to
> --> RB1 but not
> --> to RB3. The same applies to RB3 that is adjacent to RB1,
> --> but not RB2.
> --> RB1 is adjacent to both RB2 and RB3. There is a single core
> --> instance of
> --> ISIS. RB2 may reach RB3 through RB1.
> -->
> --> The TRILL equivalent topology is:
> -->
> --> +-----+        +-----+          +-----+
> --> | RB2 |--------| RB1 |----------| RB3 |
> --> +-----+        +-----+          +-----+
> -->
> --> b) another possible answer: "we have two CREDs". One is
> --> composed by RB2
> --> and RB1, the other by RB3 and RB1. RB2 may not reach RB3,
> --> since they are
> --> in different CREDs.
> -->
> --> The TRILL equivalent topologies are:
> -->
> --> +-----+        +-----+
> --> | RB2 |--------| RB1 |
> --> +-----+        +-----+
> -->
> --> +-----+          +-----+
> --> | RB1 |----------| RB3 |
> --> +-----+          +-----+
> -->
> --> I like a) and I hope we are in agreement that the right
> --> answer is a),
> --> but I haven't seen it explained in any of the documents.
> -->
> --> -- Silvano
> -->
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAG6vqCt016545 for <[e-mail]>; Wed, 15 Nov 2006 22:57:52 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Wed, 15 Nov 2006 22:45:53 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IEEE meeting
Thread-Index: AccJStyYveCz9wv6R/isFtrPj+5nAQ==
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAG6vqCt016545
Cc: [e-mail]
Subject: [rbridge] IEEE meeting
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2006 06:58:01 -0000
Status: RO
Content-Length: 73

Eric,

How did the TRILL presentation to IEEE go?

Thanks

-- Silvano




Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAG6n9et013833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 15 Nov 2006 22:49:11 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C0916EE418; Thu, 16 Nov 2006 07:49:08 +0100 (CET)
Received: from [10.0.0.7] (39.Red-80-37-137.staticIP.rima-tde.net [80.37.137.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 44FA4EE40C; Thu, 16 Nov 2006 07:49:07 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 16 Nov 2006 07:49:08 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Joe Touch <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2006 06:49:25 -0000
Status: RO
Content-Length: 941

Joe Touch escribi?:
> Gray, Eric wrote:
> ...
>   
>> 	With the exception of the fact that I am still not sold on the
>> notion that 12, 14 or 16 bits gives us a big-enough nickname space,
>> I agree that Radia's option 2.A makes sense.
>>     
>
> Me too.
>
> ...
>   
I think option 2.A makes most sense compared with the others.
>> 	IMO, we should stick to a single SHIM format.  Also, I am very
>> much opposed to inventing any new MAC formats here in the IETF - and 
>> I think we are out of line in talking about doing so.
>>     
>
> I agree with this too.
>
> Joe
>
>   
The "invented" "new" MAC format is the standard MAC format for locally 
assigned L2 addresses. It is the handling which is different. So perhaps 
is more invention in the encapsulation and shim formats discussed.
I said before that TRILL is at an advanced stage of definition, for sure 
too late to discuss this questions.
I agree to stop discussion on this.



Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAG6gJ0v011164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 15 Nov 2006 22:42:21 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B92AAEE3B2; Thu, 16 Nov 2006 07:42:18 +0100 (CET)
Received: from [10.0.0.7] (39.Red-80-37-137.staticIP.rima-tde.net [80.37.137.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 8B5B1EE3D5; Thu, 16 Nov 2006 07:42:17 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 16 Nov 2006 07:42:17 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2006 06:42:29 -0000
Status: RO
Content-Length: 7726

Gray, Eric escribi?:
> Guillermo,
>
> 	In an ideal world, this would be true.  However, these ideas
> are recurring and - as a strictly practical issue - they have to 
> cooperate in a world that has moved on from past iterations of the 
> same ideas
>   
> 	For the most part, the answer you're going to find here is:
> if you need hierarchical addressing, you've come to the right place
>   
> - just use IP...
>   
If this is so, why are not using IP to scale up  Metro Ethernet Networks 
and Provider Backbone Bridges? 
> --
> Eric
>
> --> -----Original Message-----
> --> From: [e-mail] 
> --> [mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
> --> Sent: Wednesday, November 15, 2006 10:32 AM
> --> To: J. R. Rivers
> --> Cc: [e-mail]; Radia Perlman
> --> Subject: Re: [rbridge] Should we optimize the common case?
> --> 
> --> While agreeing with some of the arguments, I see far from ideal for 
> --> scalability that RBridges advertise host lists with a 
> --> number of host L2 
> --> addresses impossible to consolidate.
> --> Looking for some hierarchy and structure in L2 addresses, 
> --> although not 
> --> easy at first glance, may provide long term benefits in scalability.
> --> Guillermo
> --> 
> --> J. R. Rivers escribi?:
> --> > I've worked on such systems, and while the address 
> --> summarization creates a degree of scale, you generally find 
> --> that the fixed association between endnode and switch is 
> --> very restricting and limiting.  
> --> > 
> --> > This is one of the reasons that I find TRILL very 
> --> clean... the relationship between an endnode and an rbridge 
> --> is that of convenience, not requirement.
> --> > 
> --> > I can build multi-homed networks... assuming that an edge 
> --> rbridge can maintain multiple endhost->rbridge associations 
> --> without changing the forwarding constructs of the rbridge 
> --> "core".  This occurs because each edge rbridge advertises 
> --> reachability to the host.
> --> > 
> --> > I can redirect frames through an rbridge network without 
> --> changing the underlying L2 constructs (as required by many 
> --> IDS/crypto protocols).  Then I can forward them to their 
> --> intended destinations.
> --> > 
> --> > All of these require support from coordinating edge 
> --> rbridges... the endhosts, other edge rbridges, and core 
> --> rbridges are blissfully unaware of these goings on.
> --> > 
> --> > All this comes from partitioning the system into a 
> --> simple, fast, cheap HW forwarding plane and a fully SW 
> --> managed control plane.
> --> > 
> --> > JR
> --> > 
> --> > 
> --> > 
> --> >> -----Original Message-----
> --> >> From: Guillermo Ib??ez [mailto:[e-mail]] 
> --> >> Sent: Tuesday, November 14, 2006 2:37 AM
> --> >> To: Caitlin Bestler; Radia Perlman; J. R. Rivers; Silvano Gai
> --> >> Cc: [e-mail]
> --> >> Subject: Re: [rbridge] Should we optimize the common case?
> --> >>
> --> >> I think there is a misunderstanding.  This is IMHO a 
> --> >> practical alternative:
> --> >> -An RBridge port is connected to a  "link" and receives 
> --> frames from 
> --> >> multiple hosts:  The RBridge builds an internal 
> --> translation table of  
> --> >> global MACs to hierarchical MACs (HMACs) assigned by him 
> --> and replaces 
> --> >> global MAC by hierarchical MAC in the original frame.
> --> >> -These hierarchical MAC addresses for hosts contain the RBridge 
> --> >> Nickname, so it becomes *part* of the complete host address 
> --> >> transmitted 
> --> >> as "original" frame.  So these addresses should contain 
> --> >> RBridge Nickname 
> --> >> with host nickname appended (internal grouping of host 
> --> nicknames per 
> --> >> RBridge port ID would also help). To be defined.
> --> >> - Hierarchical MAC MAY also be used in the ARP response 
> --> packets (when 
> --> >> RBridge acts as proxy ARP or by interception of the host 
> --> response 
> --> >> packet), so the requester obtains the hierarchical MAC 
> --> >> address instead 
> --> >> of the global one and uses it for all transactions.
> --> >> - The hosts with hierarchical MAC addresses do not need being 
> --> >> announced 
> --> >> by the RBridges in their host lists, because their DR RBridge 
> --> >> nickname  
> --> >> is included in the hierarchical MAC address of host in 
> --> the "original" 
> --> >> (now altered with HMAC) frame.
> --> >> - Frames with inner hierarchical destination address need 
> --> >> only to read 
> --> >> the destination RBridge Nickname to obtain the egrees RBridge 
> --> >> (no need 
> --> >> to look host-RBridge table). The host list mechanism is 
> --> not used by  
> --> >> hosts whose RBridge handles them with hierarchical addressing. 
> --> >> Both types, global and local hierarchical addresses may 
> --> >> coexist. Local 
> --> >> hierarchical save processing and enhance scalability.
> --> >> Hope this clarifies.
> --> >> Guillermo
> --> >>
> --> >> PD.
> --> >> Other issues
> --> >> -DHCP-like mechanism
> --> >> Hierarchical MACs can be assigned with DHCP like mechanism to 
> --> >> hosts, but 
> --> >> IMHO this has impact on end nodes, so it can not be the standard 
> --> >> mechanism, only an option.
> --> >> - Generic hierarchical MAC addresses and masks (ref. Dr. 
> --> >> Morales slide)
> --> >> I proposed the generic addressing format  that includes 
> --> hierarchical 
> --> >> masks looking for a generic addressing space, that could 
> --> be useful to 
> --> >> scale further RBridges in the future. I understand that at 
> --> >> this stage of 
> --> >> definition of RBridges to look for a fully generic 
> --> format could be 
> --> >> disruptive. However, the need for a generic hierarchical 
> --> addressing 
> --> >> space in Ethernet is growing.
> --> >>  
> --> >>
> --> >>
> --> >>
> --> >> Caitlin Bestler escribi?:
> --> >>> Radia Perlman wrote:
> --> >>>   
> --> >>>> Not sure I've been following this, but let me conjecture what
> --> >>>> people are suggesting, and if I'm right about the suggestion,
> --> >>>> I think it's a good idea. Correct me if it's not what 
> --> people are
> --> >>>> saying. 
> --> >>>>
> --> >>>> So I think what they are saying is the following:
> --> >>>> a) there are cases where an RBridge has a block of addresses
> --> >>>> (like DHCP) that it hands out to endnodes
> --> >>>> b) in that case, it would be nice if the RBridge can
> --> >>>> announce, in its LSP, the whole range of addresses, rather
> --> >>>> than reporting each individually
> --> >>>> c) the change would be an ability to express a range in the
> --> >>>> endnode announcement. This seems easy, but I think it would
> --> >>>> be best done with a 2nd TLV in IS-IS. The 1st TLV would be 
> --> >> individual
> --> >>>> addresses. The 2nd TLV would be pairs of addresses 
> --> (low, high). Or
> --> >>>> (low, increment), as in "starting with address X,
> --> >>>> 32 addresses" (which would take up a bit less space 
> --> than two MAC
> --> >>>> addresses. 
> --> >>>>
> --> >>>> I don't think of this as a hierarchical address---I just
> --> >>>> think of it as a range of addresses reachable from one RBridge.
> --> >>>>
> --> >>>>     
> --> >>> Reduction in the total number of reports required to support N
> --> >>> addresses is probably the only benefit of "hierarchical 
> --> addresses"
> --> >>> that we can achieve if we are going to support global-scope MAC
> --> >>> addresses as well. Which I'm certain everyone agrees is a given.
> --> >>>
> --> >>>   
> --> > 
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> 
>   


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAG5xE94029038 for <[e-mail]>; Wed, 15 Nov 2006 21:59:14 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Wed, 15 Nov 2006 21:56:31 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] IVLANs vs OVLANs
Thread-Index: AccI8m2jZzGMkQRLTWe1FSQHEKwxhQAUCqtg
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAG5xE94029038
Cc: [e-mail]
Subject: Re: [rbridge] IVLANs vs OVLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2006 05:59:25 -0000
Status: RO
Content-Length: 7359

Eric,

I am just trying to understand if there is consensus in a) or b).

The impression I got talking with Radia is that she was in favor of a).

Your reply is my b) model to which you have added a router. Since b) is
two separate layer 2 networks, you can put a router between the two, as
you did.

Please also note that I can redraw the same network in a different way:

                +-----+
                | RB1 |
                +-----+
                 |  |
               1 |  | 2
                 |  |
 +-----+   1    +-----+    2     +-----+
 | RB2 |--------| SW1 |----------| RB3 |
 +-----+        +-----+          +-----+

Where I replaced the Etherchannel with two links, one in OVLAN=1 and one
in OVLAN=2. 

Now is RB2 capable of talking to RB3 through RB1?

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Wednesday, November 15, 2006 12:13 PM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: RE: [rbridge] IVLANs vs OVLANs
> 
> Silvano,
> 
> 	First of all, I will take very large exception to the way
> which you have over-loaded the term "CRED."  This term was coined
> to eliminate confusion caused by the various different was people
> were over-loading the term "Campus."
> 
> 	At the "core" of your question, however, is the issue of
> how VLANs interact in a bridged/RBridge environment.  It is not
> different than would be the case in a "classical bridged LAN."
> 
> 	This issue is based on a misconception that existed very
> early on in the life of the TRILL working group (in the first
> BoF, in fact).  The misconception is that VLAN connectivity may
> be provided by RBridges and/or bridges.
> 
> 	This is fundamentally incorrect.
> 
> 	Interconnection of VLANs is strictly a routing function.
> In deployed equipment that does this today, there may be some
> form of "smart VLAN bridging" that occurs in devices people are
> used to referring to as "bridges" or "switches."  That does not
> change the fact that forwarding from one VLAN to another is a
> "routing function."
> 
> 	Note that, in this context, when I say "forwarding from
> one VLAN to another" - I mean "VLAN" in the sense of "virtual
> LAN" as a logical concept.  This has nothing to do with the fact
> that a VLAN ID might change in traversing a VLAN-aware bridge.
> 
> 	Consequently, in the picture you have below, the VLANs
> represented by the VLAN-tag in the tunnel encapsulation may
> not be connected together by RB1.
> 
> 	To correctly restate your question, the original topology
> would be as follows:
> 
> 
>                 +-----+  1,2  +-----------+
>                 | RB1 |-------| Rtg Fnctn |
>                 +-----+       +-----------+
>                    |
>                    | 1,2
>                    |
>  +-----+   1    +-----+    2     +-----+
>  | RB2 |--------| SW1 |----------| RB3 |
>  +-----+        +-----+          +-----+
> 
> The resulting logical topology MUST then be as follows:
> 
> 
>  +-----+        +-----+       +-----------+
>  | RB2 |--------| RB1 |-------| Rtg Fnctn |
>  +-----+        +-----+       +-----+-----+
>                                     |
>                                  +--+--+          +-----+
>                                  | RB1 |----------| RB3 |
>                                  +-----+          +-----+
> 
> Since the "routing function" is orthogonal, and well understood,
> it does not make sense for us to try to combine this concept with
> RBridge behaviors and protocol interactions.
> 
> --
> Eric
> 
> 
> --> -----Original Message-----
> --> From: [e-mail]
> --> [mailto:[e-mail]] On Behalf Of Silvano Gai
> --> Sent: Tuesday, November 14, 2006 8:11 PM
> --> To: [e-mail]
> --> Subject: [rbridge] IVLANs vs OVLANs
> -->
> -->
> --> During the last WG meeting I had an action item to send an
> --> email on the
> --> VLAN issue. Here it is.
> -->
> --> In a previous email I introduced the concept of IVLAN and OVLAN.
> -->
> --> IVLAN refers to the VLAN present on the untagged frames,
> --> which must be
> --> propagated by ISIS, VLAN pruning must be performed and so
> --> on. All the
> --> IVLANs share the same core instance of ISIS.
> -->
> --> OVLAN refers to the fact that the traffic between two
> --> RBridges can be
> --> encapsulated into a VLAN.
> -->
> --> If we look to the format of a TRILL encapsulated frame the
> --> position of
> --> these two fields is as follow:
> -->
> --> +--------------------------------+
> --> |               DA               |
> --> +----------------+---------------+
> --> |       DA       |     SA        |
> --> +----------------+---------------+
> --> |               SA               |
> --> +--------------------------------+
> --> |    ET = 1Q     |   OVLAN ...   |
> --> +--------------------------------+
> --> |    ET = TRILL  | RES  |  TTL   |
> --> +--------------------------------+
> --> | Egress Add.    | Ingress Add.  |
> --> +--------------------------------+
> --> |               DA               |
> --> +----------------+---------------+
> --> |       DA       |     SA        |
> --> +----------------+---------------+
> --> |               SA               |
> --> +--------------------------------+
> --> |    ET = 1Q     |   IVLAN ...   |
> --> +--------------------------------+
> --> |             Payload            |
> -->
> --> Now let's consider the following topology:
> -->
> -->                +-----+
> -->                | RB1 |
> -->                +-----+
> -->                   |
> -->                   | 1,2
> -->                   |
> --> +-----+   1    +-----+    2     +-----+
> --> | RB2 |--------| SW1 |----------| RB3 |
> --> +-----+        +-----+          +-----+
> -->
> --> RB1, RB2, RB3 are Rbridges, SW1 is a classical Ethernet switch.
> --> The link between RB2 and SW1 is in OVLAN 1, the link
> --> between SW1 and RB3
> --> is in OVLAN 2 and the links between SW1 and RB1 is a trunk and it
> --> carries both OVLAN 1 and 2.
> -->
> --> Now my question is: "do we have one CRED or two?"
> -->
> --> a) possible answer: "we have one CRED". RB2 is adjacent to
> --> RB1 but not
> --> to RB3. The same applies to RB3 that is adjacent to RB1,
> --> but not RB2.
> --> RB1 is adjacent to both RB2 and RB3. There is a single core
> --> instance of
> --> ISIS. RB2 may reach RB3 through RB1.
> -->
> --> The TRILL equivalent topology is:
> -->
> --> +-----+        +-----+          +-----+
> --> | RB2 |--------| RB1 |----------| RB3 |
> --> +-----+        +-----+          +-----+
> -->
> --> b) another possible answer: "we have two CREDs". One is
> --> composed by RB2
> --> and RB1, the other by RB3 and RB1. RB2 may not reach RB3,
> --> since they are
> --> in different CREDs.
> -->
> --> The TRILL equivalent topologies are:
> -->
> --> +-----+        +-----+
> --> | RB2 |--------| RB1 |
> --> +-----+        +-----+
> -->
> --> +-----+          +-----+
> --> | RB1 |----------| RB3 |
> --> +-----+          +-----+
> -->
> --> I like a) and I hope we are in agreement that the right
> --> answer is a),
> --> but I haven't seen it explained in any of the documents.
> -->
> --> -- Silvano
> -->
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAFMinox015400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 15 Nov 2006 14:44:49 -0800 (PST)
Received: from [127.0.0.1] (67.sub-75-209-245.myvzw.com [75.209.245.67]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kAFMi2t8019715; Wed, 15 Nov 2006 14:44:06 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 15 Nov 2006 14:43:59 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig66A821AC1BCE1F99D74BD535"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2006 22:44:55 -0000
Status: RO
Content-Length: 1152

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



Gray, Eric wrote:
=2E..
> 	With the exception of the fact that I am still not sold on the
> notion that 12, 14 or 16 bits gives us a big-enough nickname space,
> I agree that Radia's option 2.A makes sense.

Me too.

=2E..
> 	IMO, we should stick to a single SHIM format.  Also, I am very
> much opposed to inventing any new MAC formats here in the IETF - and=20
> I think we are out of line in talking about doing so.

I agree with this too.

Joe


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

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

iD8DBQFFW5gvE5f5cImnZrsRAt6tAKDjNYHhgLF5wZVqU0UJNNofLZBYCQCfZr2e
8X92LymA28vWrZ3hl3qYiMU=
=sMOs
-----END PGP SIGNATURE-----

--------------enig66A821AC1BCE1F99D74BD535--



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAFLVk9g014193 for <[e-mail]>; Wed, 15 Nov 2006 13:31:46 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kAFLVgfK018251; Wed, 15 Nov 2006 16:31:43 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA02272;  Wed, 15 Nov 2006 16:31:42 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB6VC2MA>; Wed, 15 Nov 2006 16:31:41 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>, "J. R. Rivers" <[e-mail]>
Date: Wed, 15 Nov 2006 16:31:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAFLVk9g014193
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2006 21:31:57 -0000
Status: RO
Content-Length: 7224

Guillermo,

	In an ideal world, this would be true.  However, these ideas
are recurring and - as a strictly practical issue - they have to 
cooperate in a world that has moved on from past iterations of the 
same ideas.

	For the most part, the answer you're going to find here is:
if you need hierarchical addressing, you've come to the right place 
- just use IP...

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
--> Sent: Wednesday, November 15, 2006 10:32 AM
--> To: J. R. Rivers
--> Cc: [e-mail]; Radia Perlman
--> Subject: Re: [rbridge] Should we optimize the common case?
--> 
--> While agreeing with some of the arguments, I see far from ideal for 
--> scalability that RBridges advertise host lists with a 
--> number of host L2 
--> addresses impossible to consolidate.
--> Looking for some hierarchy and structure in L2 addresses, 
--> although not 
--> easy at first glance, may provide long term benefits in scalability.
--> Guillermo
--> 
--> J. R. Rivers escribi?:
--> > I've worked on such systems, and while the address 
--> summarization creates a degree of scale, you generally find 
--> that the fixed association between endnode and switch is 
--> very restricting and limiting.  
--> > 
--> > This is one of the reasons that I find TRILL very 
--> clean... the relationship between an endnode and an rbridge 
--> is that of convenience, not requirement.
--> > 
--> > I can build multi-homed networks... assuming that an edge 
--> rbridge can maintain multiple endhost->rbridge associations 
--> without changing the forwarding constructs of the rbridge 
--> "core".  This occurs because each edge rbridge advertises 
--> reachability to the host.
--> > 
--> > I can redirect frames through an rbridge network without 
--> changing the underlying L2 constructs (as required by many 
--> IDS/crypto protocols).  Then I can forward them to their 
--> intended destinations.
--> > 
--> > All of these require support from coordinating edge 
--> rbridges... the endhosts, other edge rbridges, and core 
--> rbridges are blissfully unaware of these goings on.
--> > 
--> > All this comes from partitioning the system into a 
--> simple, fast, cheap HW forwarding plane and a fully SW 
--> managed control plane.
--> > 
--> > JR
--> > 
--> > 
--> > 
--> >> -----Original Message-----
--> >> From: Guillermo Ib??ez [mailto:[e-mail]] 
--> >> Sent: Tuesday, November 14, 2006 2:37 AM
--> >> To: Caitlin Bestler; Radia Perlman; J. R. Rivers; Silvano Gai
--> >> Cc: [e-mail]
--> >> Subject: Re: [rbridge] Should we optimize the common case?
--> >>
--> >> I think there is a misunderstanding.  This is IMHO a 
--> >> practical alternative:
--> >> -An RBridge port is connected to a  "link" and receives 
--> frames from 
--> >> multiple hosts:  The RBridge builds an internal 
--> translation table of  
--> >> global MACs to hierarchical MACs (HMACs) assigned by him 
--> and replaces 
--> >> global MAC by hierarchical MAC in the original frame.
--> >> -These hierarchical MAC addresses for hosts contain the RBridge 
--> >> Nickname, so it becomes *part* of the complete host address 
--> >> transmitted 
--> >> as "original" frame.  So these addresses should contain 
--> >> RBridge Nickname 
--> >> with host nickname appended (internal grouping of host 
--> nicknames per 
--> >> RBridge port ID would also help). To be defined.
--> >> - Hierarchical MAC MAY also be used in the ARP response 
--> packets (when 
--> >> RBridge acts as proxy ARP or by interception of the host 
--> response 
--> >> packet), so the requester obtains the hierarchical MAC 
--> >> address instead 
--> >> of the global one and uses it for all transactions.
--> >> - The hosts with hierarchical MAC addresses do not need being 
--> >> announced 
--> >> by the RBridges in their host lists, because their DR RBridge 
--> >> nickname  
--> >> is included in the hierarchical MAC address of host in 
--> the "original" 
--> >> (now altered with HMAC) frame.
--> >> - Frames with inner hierarchical destination address need 
--> >> only to read 
--> >> the destination RBridge Nickname to obtain the egrees RBridge 
--> >> (no need 
--> >> to look host-RBridge table). The host list mechanism is 
--> not used by  
--> >> hosts whose RBridge handles them with hierarchical addressing. 
--> >> Both types, global and local hierarchical addresses may 
--> >> coexist. Local 
--> >> hierarchical save processing and enhance scalability.
--> >> Hope this clarifies.
--> >> Guillermo
--> >>
--> >> PD.
--> >> Other issues
--> >> -DHCP-like mechanism
--> >> Hierarchical MACs can be assigned with DHCP like mechanism to 
--> >> hosts, but 
--> >> IMHO this has impact on end nodes, so it can not be the standard 
--> >> mechanism, only an option.
--> >> - Generic hierarchical MAC addresses and masks (ref. Dr. 
--> >> Morales slide)
--> >> I proposed the generic addressing format  that includes 
--> hierarchical 
--> >> masks looking for a generic addressing space, that could 
--> be useful to 
--> >> scale further RBridges in the future. I understand that at 
--> >> this stage of 
--> >> definition of RBridges to look for a fully generic 
--> format could be 
--> >> disruptive. However, the need for a generic hierarchical 
--> addressing 
--> >> space in Ethernet is growing.
--> >>  
--> >>
--> >>
--> >>
--> >> Caitlin Bestler escribi?:
--> >>> Radia Perlman wrote:
--> >>>   
--> >>>> Not sure I've been following this, but let me conjecture what
--> >>>> people are suggesting, and if I'm right about the suggestion,
--> >>>> I think it's a good idea. Correct me if it's not what 
--> people are
--> >>>> saying. 
--> >>>>
--> >>>> So I think what they are saying is the following:
--> >>>> a) there are cases where an RBridge has a block of addresses
--> >>>> (like DHCP) that it hands out to endnodes
--> >>>> b) in that case, it would be nice if the RBridge can
--> >>>> announce, in its LSP, the whole range of addresses, rather
--> >>>> than reporting each individually
--> >>>> c) the change would be an ability to express a range in the
--> >>>> endnode announcement. This seems easy, but I think it would
--> >>>> be best done with a 2nd TLV in IS-IS. The 1st TLV would be 
--> >> individual
--> >>>> addresses. The 2nd TLV would be pairs of addresses 
--> (low, high). Or
--> >>>> (low, increment), as in "starting with address X,
--> >>>> 32 addresses" (which would take up a bit less space 
--> than two MAC
--> >>>> addresses. 
--> >>>>
--> >>>> I don't think of this as a hierarchical address---I just
--> >>>> think of it as a range of addresses reachable from one RBridge.
--> >>>>
--> >>>>     
--> >>> Reduction in the total number of reports required to support N
--> >>> addresses is probably the only benefit of "hierarchical 
--> addresses"
--> >>> that we can achieve if we are going to support global-scope MAC
--> >>> addresses as well. Which I'm certain everyone agrees is a given.
--> >>>
--> >>>   
--> > 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAFL2Du6004764 for <[e-mail]>; Wed, 15 Nov 2006 13:02:14 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kAFL26fK017831; Wed, 15 Nov 2006 16:02:06 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA00681;  Wed, 15 Nov 2006 16:02:06 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB6VCH0G>; Wed, 15 Nov 2006 16:02:05 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>, Radia Perlman <[e-mail]>, =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
Date: Wed, 15 Nov 2006 16:02:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAFL2Du6004764
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2006 21:02:40 -0000
Status: RO
Content-Length: 5950

Radia/Silvano,

	As I understand it, a summary of the current proposals (with 
apologies for omitting discussion prior to and including Guillermo's 
suggestion) would be as follows:

Radia suggests:

1 - create a MAC header with SA derived from combining ingress and
    sending RBridge nicknames, and DA derived from combining egress
    and receiving RBridge nicknames.  Variations -
    A) TTL is a separate field in the mutated MAC header
    B) TTL is embedded in one or the other derived "MAC address",
       or in some concatenation of both derived "MAC addresses" -
       still in the mutated header.

2 - including both ingress and egress RBridge nicknames in a SHIM,
    that also includes TTL.  Variations - 
    A) fixed (6 octet) length SHIM
    B) variable (6+ octet).

Radia stated a preference for 2.A.

Silvano's modification?

2.A (?) but including the option of using a standard MAC header with
the appropriate DA/SA for a point-to-point link.

=======================================================================

	IMO, Radia's proposals 1.A and 1.B are evidence of how far from
the beaten path we can wander when we try designing things in committee.

	With the exception of the fact that I am still not sold on the
notion that 12, 14 or 16 bits gives us a big-enough nickname space,
I agree that Radia's option 2.A makes sense.

	Alternative proposal 2.B suffers from the fact that it adds more
complexity to hardware implementation in every case in the misleading 
intention of reducing hardware implementation complexity in some cases.

	Given the fact that I think we're starting to gain some degree of 
convergence on the 2.A proposal, I am willing to go along with it.

	However, the additional option proposed by Silvano also suffers
from adding complexity in all cases by trying to simplify hardware in
some cases.  You might simplify your implementation by assuming it will
only ever be deployed in point-to-point networks, but that makes it more
difficult for an implementer who is targeting a super-set of deployment
scenarios your implementation targets.  Also, it will end up making your
implementation more complex by the time you discover that users don't
necessarily deploy things according to a vendor's plans in all cases.

	IMO, we should stick to a single SHIM format.  Also, I am very
much opposed to inventing any new MAC formats here in the IETF - and 
I think we are out of line in talking about doing so.

--
Eric
    

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Silvano Gai
--> Sent: Tuesday, November 14, 2006 7:35 PM
--> To: Radia Perlman; Guillermo Ib??ez
--> Cc: [e-mail]
--> Subject: Re: [rbridge] Should we optimize the common case?
--> 
--> 
--> Radia,
--> 
--> May I propose:
--> 
--> c) Your b) proposal plus the option that on point-to-point 
--> link we can use a well know destination MAC address, i.e. 
--> RBridge-Next-Hop. 
--> 
--> This allows building a simplified HW that works only on 
--> point-to-point links and that does not keep a next hop 
--> adjacency table.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: Radia Perlman [mailto:[e-mail]]
--> > Sent: Tuesday, November 14, 2006 6:59 AM
--> > To: Guillermo Ib??ez
--> > Cc: Caitlin Bestler; J. R. Rivers; Silvano Gai; [e-mail]
--> > Subject: Re: [rbridge] Should we optimize the common case?
--> > 
--> > The first RBridge has to recognize a true MAC address, so we can't
--> > reassign endnodes hierarchicaladdresses. I think trying to see 
--> > nickname | nexthop as a hierarchical address is just confusing, 
--> > especially since the "hierarchical address" will change at every 
--> > hop. With the LIDs, it's sort of like a hierarchical address, but 
--> > not really, since lots of endnodes (all the ones on the same link) 
--> > will share the same "hierarchical address". But with Sanjay's 
--> > proposal of folding "egress nickname" and "next hop nickname" into 
--> > the destination address of the hop-by-hop header, this is *not* a
--> > hierarchical address of the destination endnode.
--> >
--> > And besides, this doesn't change the technical proposal, so trying
--> > to think of it that way is, I think, a digression.
--> > 
--> > The real question I think is between two proposals, with variants:
--> > 
--> > a) have 2 byte + Ethernet header: by folding next hop and egress
--> > nickname into "destination MAC" and transmitting RBridge and ingress 
--> > RBridge nickname into "source MAC", with TTL as the only thing left 
--> > over, with possible variant being folding TTL into the source and
--> > destination MACs as well.
--> > 
--> > b) have 6 byte + Ethernet header; putting ingress and egress RBridge
--> > nicknames and TTL into the 6 bytes; with possible variant being a 
--> > variable length shim to add things like LIDs.
--> > 
--> > I'd prefer b) with fixed length at 6 bytes. My second choice is a) 
--> > with the 2 byte addition for TTL, since I think also folding TTL 
--> > into the MACs will be even more confusing.
--> > 
--> > Radia
--> > 
--> > 
--> > 
--> > I do think we should allow advertisement of MAC address 
--> ranges in IS-IS
--> > endnode reports, because
--> > in some cases this will make smaller tables.
--> > 
--> > I'd prefer the "true" hop by hop header, where next hop 
--> and this hop is
--> > used as the MAC addresses,
--> > and a shim header with 6 bytes, partially because it is simpler to
--> > understand, and will be perceived as
--> > pretty straightforward compared with what routers do; 
--> i.e., take a piece
--> > of information, put an end-to
--> > end header (e.g., IP header, but in our case the shim with
--> > ingress/egress RBridge and
--> > TTL) on the information, and then hop by hop put a 
--> link-specific header
--> > on (e.g.,
--> > an Ethernet header).
--> > 
--> > Radia
--> > 
-- [SNIP] --



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAFKCqIm015331 for <[e-mail]>; Wed, 15 Nov 2006 12:12:52 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kAFKCofK017244; Wed, 15 Nov 2006 15:12:50 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA28029;  Wed, 15 Nov 2006 15:12:49 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB6VCHHY>; Wed, 15 Nov 2006 15:12:48 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>
Date: Wed, 15 Nov 2006 15:12:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] IVLANs vs OVLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2006 20:13:11 -0000
Status: RO
Content-Length: 6041

Silvano,

	First of all, I will take very large exception to the way
which you have over-loaded the term "CRED."  This term was coined
to eliminate confusion caused by the various different was people
were over-loading the term "Campus."

	At the "core" of your question, however, is the issue of
how VLANs interact in a bridged/RBridge environment.  It is not
different than would be the case in a "classical bridged LAN." 

	This issue is based on a misconception that existed very 
early on in the life of the TRILL working group (in the first
BoF, in fact).  The misconception is that VLAN connectivity may
be provided by RBridges and/or bridges.  

	This is fundamentally incorrect.

	Interconnection of VLANs is strictly a routing function.
In deployed equipment that does this today, there may be some
form of "smart VLAN bridging" that occurs in devices people are
used to referring to as "bridges" or "switches."  That does not
change the fact that forwarding from one VLAN to another is a
"routing function."

	Note that, in this context, when I say "forwarding from
one VLAN to another" - I mean "VLAN" in the sense of "virtual
LAN" as a logical concept.  This has nothing to do with the fact
that a VLAN ID might change in traversing a VLAN-aware bridge.

	Consequently, in the picture you have below, the VLANs
represented by the VLAN-tag in the tunnel encapsulation may 
not be connected together by RB1.

	To correctly restate your question, the original topology
would be as follows:

 
                +-----+  1,2  +-----------+
                | RB1 |-------| Rtg Fnctn |
                +-----+       +-----------+
                   |
                   | 1,2
                   |
 +-----+   1    +-----+    2     +-----+ 
 | RB2 |--------| SW1 |----------| RB3 |
 +-----+        +-----+          +-----+

The resulting logical topology MUST then be as follows:

 
 +-----+        +-----+       +-----------+
 | RB2 |--------| RB1 |-------| Rtg Fnctn |
 +-----+        +-----+       +-----+-----+
                                    |
                                 +--+--+          +-----+
                                 | RB1 |----------| RB3 |
                                 +-----+          +-----+

Since the "routing function" is orthogonal, and well understood,
it does not make sense for us to try to combine this concept with
RBridge behaviors and protocol interactions.

--
Eric


--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Silvano Gai
--> Sent: Tuesday, November 14, 2006 8:11 PM
--> To: [e-mail]
--> Subject: [rbridge] IVLANs vs OVLANs
--> 
--> 
--> During the last WG meeting I had an action item to send an 
--> email on the
--> VLAN issue. Here it is.
--> 
--> In a previous email I introduced the concept of IVLAN and OVLAN.
--> 
--> IVLAN refers to the VLAN present on the untagged frames, 
--> which must be
--> propagated by ISIS, VLAN pruning must be performed and so 
--> on. All the
--> IVLANs share the same core instance of ISIS.
--> 
--> OVLAN refers to the fact that the traffic between two 
--> RBridges can be
--> encapsulated into a VLAN.
--> 
--> If we look to the format of a TRILL encapsulated frame the 
--> position of
--> these two fields is as follow:
--> 
--> +--------------------------------+
--> |               DA               |
--> +----------------+---------------+
--> |       DA       |     SA        |
--> +----------------+---------------+
--> |               SA               |
--> +--------------------------------+
--> |    ET = 1Q     |   OVLAN ...   |
--> +--------------------------------+
--> |    ET = TRILL  | RES  |  TTL   |
--> +--------------------------------+
--> | Egress Add.    | Ingress Add.  |
--> +--------------------------------+
--> |               DA               |
--> +----------------+---------------+
--> |       DA       |     SA        |
--> +----------------+---------------+
--> |               SA               |
--> +--------------------------------+
--> |    ET = 1Q     |   IVLAN ...   |
--> +--------------------------------+
--> |             Payload            |
--> 
--> Now let's consider the following topology:
--> 
-->                +-----+
-->                | RB1 |
-->                +-----+
-->                   |
-->                   | 1,2
-->                   |
--> +-----+   1    +-----+    2     +-----+
--> | RB2 |--------| SW1 |----------| RB3 |
--> +-----+        +-----+          +-----+
--> 
--> RB1, RB2, RB3 are Rbridges, SW1 is a classical Ethernet switch.
--> The link between RB2 and SW1 is in OVLAN 1, the link 
--> between SW1 and RB3
--> is in OVLAN 2 and the links between SW1 and RB1 is a trunk and it
--> carries both OVLAN 1 and 2.
--> 
--> Now my question is: "do we have one CRED or two?"
--> 
--> a) possible answer: "we have one CRED". RB2 is adjacent to 
--> RB1 but not
--> to RB3. The same applies to RB3 that is adjacent to RB1, 
--> but not RB2.
--> RB1 is adjacent to both RB2 and RB3. There is a single core 
--> instance of
--> ISIS. RB2 may reach RB3 through RB1.
--> 
--> The TRILL equivalent topology is:
--> 
--> +-----+        +-----+          +-----+
--> | RB2 |--------| RB1 |----------| RB3 |
--> +-----+        +-----+          +-----+
--> 
--> b) another possible answer: "we have two CREDs". One is 
--> composed by RB2
--> and RB1, the other by RB3 and RB1. RB2 may not reach RB3, 
--> since they are
--> in different CREDs.
--> 
--> The TRILL equivalent topologies are:
--> 
--> +-----+        +-----+
--> | RB2 |--------| RB1 |
--> +-----+        +-----+
--> 
--> +-----+          +-----+
--> | RB1 |----------| RB3 |
--> +-----+          +-----+
--> 
--> I like a) and I hope we are in agreement that the right 
--> answer is a),
--> but I haven't seen it explained in any of the documents.
--> 
--> -- Silvano
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 


Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAFFWHau028550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 15 Nov 2006 07:32:19 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5158BEE185; Wed, 15 Nov 2006 16:32:16 +0100 (CET)
Received: from [10.0.0.7] (39.Red-80-37-137.staticIP.rima-tde.net [80.37.137.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id BAF7FEE363; Wed, 15 Nov 2006 16:32:14 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 15 Nov 2006 16:32:14 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: "J. R. Rivers" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2006 15:32:37 -0000
Status: RO
Content-Length: 5713

While agreeing with some of the arguments, I see far from ideal for 
scalability that RBridges advertise host lists with a number of host L2 
addresses impossible to consolidate.
Looking for some hierarchy and structure in L2 addresses, although not 
easy at first glance, may provide long term benefits in scalability.
Guillermo

J. R. Rivers escribi?:
> I've worked on such systems, and while the address summarization creates a degree of scale, you generally find that the fixed association between endnode and switch is very restricting and limiting.  
> 
> This is one of the reasons that I find TRILL very clean... the relationship between an endnode and an rbridge is that of convenience, not requirement.
> 
> I can build multi-homed networks... assuming that an edge rbridge can maintain multiple endhost->rbridge associations without changing the forwarding constructs of the rbridge "core".  This occurs because each edge rbridge advertises reachability to the host.
> 
> I can redirect frames through an rbridge network without changing the underlying L2 constructs (as required by many IDS/crypto protocols).  Then I can forward them to their intended destinations.
> 
> All of these require support from coordinating edge rbridges... the endhosts, other edge rbridges, and core rbridges are blissfully unaware of these goings on.
> 
> All this comes from partitioning the system into a simple, fast, cheap HW forwarding plane and a fully SW managed control plane.
> 
> JR
> 
> 
> 
>> -----Original Message-----
>> From: Guillermo Ib??ez [mailto:[e-mail]] 
>> Sent: Tuesday, November 14, 2006 2:37 AM
>> To: Caitlin Bestler; Radia Perlman; J. R. Rivers; Silvano Gai
>> Cc: [e-mail]
>> Subject: Re: [rbridge] Should we optimize the common case?
>>
>> I think there is a misunderstanding.  This is IMHO a 
>> practical alternative:
>> -An RBridge port is connected to a  "link" and receives frames from 
>> multiple hosts:  The RBridge builds an internal translation table of  
>> global MACs to hierarchical MACs (HMACs) assigned by him and replaces 
>> global MAC by hierarchical MAC in the original frame.
>> -These hierarchical MAC addresses for hosts contain the RBridge 
>> Nickname, so it becomes *part* of the complete host address 
>> transmitted 
>> as "original" frame.  So these addresses should contain 
>> RBridge Nickname 
>> with host nickname appended (internal grouping of host nicknames per 
>> RBridge port ID would also help). To be defined.
>> - Hierarchical MAC MAY also be used in the ARP response packets (when 
>> RBridge acts as proxy ARP or by interception of the host response 
>> packet), so the requester obtains the hierarchical MAC 
>> address instead 
>> of the global one and uses it for all transactions.
>> - The hosts with hierarchical MAC addresses do not need being 
>> announced 
>> by the RBridges in their host lists, because their DR RBridge 
>> nickname  
>> is included in the hierarchical MAC address of host in the "original" 
>> (now altered with HMAC) frame.
>> - Frames with inner hierarchical destination address need 
>> only to read 
>> the destination RBridge Nickname to obtain the egrees RBridge 
>> (no need 
>> to look host-RBridge table). The host list mechanism is not used by  
>> hosts whose RBridge handles them with hierarchical addressing. 
>> Both types, global and local hierarchical addresses may 
>> coexist. Local 
>> hierarchical save processing and enhance scalability.
>> Hope this clarifies.
>> Guillermo
>>
>> PD.
>> Other issues
>> -DHCP-like mechanism
>> Hierarchical MACs can be assigned with DHCP like mechanism to 
>> hosts, but 
>> IMHO this has impact on end nodes, so it can not be the standard 
>> mechanism, only an option.
>> - Generic hierarchical MAC addresses and masks (ref. Dr. 
>> Morales slide)
>> I proposed the generic addressing format  that includes hierarchical 
>> masks looking for a generic addressing space, that could be useful to 
>> scale further RBridges in the future. I understand that at 
>> this stage of 
>> definition of RBridges to look for a fully generic format could be 
>> disruptive. However, the need for a generic hierarchical addressing 
>> space in Ethernet is growing.
>>  
>>
>>
>>
>> Caitlin Bestler escribi?:
>>> Radia Perlman wrote:
>>>   
>>>> Not sure I've been following this, but let me conjecture what
>>>> people are suggesting, and if I'm right about the suggestion,
>>>> I think it's a good idea. Correct me if it's not what people are
>>>> saying. 
>>>>
>>>> So I think what they are saying is the following:
>>>> a) there are cases where an RBridge has a block of addresses
>>>> (like DHCP) that it hands out to endnodes
>>>> b) in that case, it would be nice if the RBridge can
>>>> announce, in its LSP, the whole range of addresses, rather
>>>> than reporting each individually
>>>> c) the change would be an ability to express a range in the
>>>> endnode announcement. This seems easy, but I think it would
>>>> be best done with a 2nd TLV in IS-IS. The 1st TLV would be 
>> individual
>>>> addresses. The 2nd TLV would be pairs of addresses (low, high). Or
>>>> (low, increment), as in "starting with address X,
>>>> 32 addresses" (which would take up a bit less space than two MAC
>>>> addresses. 
>>>>
>>>> I don't think of this as a hierarchical address---I just
>>>> think of it as a range of addresses reachable from one RBridge.
>>>>
>>>>     
>>> Reduction in the total number of reports required to support N
>>> addresses is probably the only benefit of "hierarchical addresses"
>>> that we can achieve if we are going to support global-scope MAC
>>> addresses as well. Which I'm certain everyone agrees is a given.
>>>
>>>   
> 


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAF1YFaj026839 for <[e-mail]>; Tue, 14 Nov 2006 17:34:16 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Tue, 14 Nov 2006 17:10:48 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IVLANs vs OVLANs
Thread-Index: AccIUuJLjZ3uCtPvSy2j5DoZGzUfqw==
From: "Silvano Gai" <[e-mail]>
To: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAF1YFaj026839
Subject: [rbridge] IVLANs vs OVLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2006 01:34:22 -0000
Status: RO
Content-Length: 2800

During the last WG meeting I had an action item to send an email on the
VLAN issue. Here it is.

In a previous email I introduced the concept of IVLAN and OVLAN.

IVLAN refers to the VLAN present on the untagged frames, which must be
propagated by ISIS, VLAN pruning must be performed and so on. All the
IVLANs share the same core instance of ISIS.

OVLAN refers to the fact that the traffic between two RBridges can be
encapsulated into a VLAN.

If we look to the format of a TRILL encapsulated frame the position of
these two fields is as follow:

+--------------------------------+
|               DA               |
+----------------+---------------+
|       DA       |     SA        |
+----------------+---------------+
|               SA               |
+--------------------------------+
|    ET = 1Q     |   OVLAN ...   |
+--------------------------------+
|    ET = TRILL  | RES  |  TTL   |
+--------------------------------+
| Egress Add.    | Ingress Add.  |
+--------------------------------+
|               DA               |
+----------------+---------------+
|       DA       |     SA        |
+----------------+---------------+
|               SA               |
+--------------------------------+
|    ET = 1Q     |   IVLAN ...   |
+--------------------------------+
|             Payload            |

Now let's consider the following topology:

               +-----+
               | RB1 |
               +-----+
                  |
                  | 1,2
                  |
+-----+   1    +-----+    2     +-----+
| RB2 |--------| SW1 |----------| RB3 |
+-----+        +-----+          +-----+

RB1, RB2, RB3 are Rbridges, SW1 is a classical Ethernet switch.
The link between RB2 and SW1 is in OVLAN 1, the link between SW1 and RB3
is in OVLAN 2 and the links between SW1 and RB1 is a trunk and it
carries both OVLAN 1 and 2.

Now my question is: "do we have one CRED or two?"

a) possible answer: "we have one CRED". RB2 is adjacent to RB1 but not
to RB3. The same applies to RB3 that is adjacent to RB1, but not RB2.
RB1 is adjacent to both RB2 and RB3. There is a single core instance of
ISIS. RB2 may reach RB3 through RB1.

The TRILL equivalent topology is:

+-----+        +-----+          +-----+
| RB2 |--------| RB1 |----------| RB3 |
+-----+        +-----+          +-----+

b) another possible answer: "we have two CREDs". One is composed by RB2
and RB1, the other by RB3 and RB1. RB2 may not reach RB3, since they are
in different CREDs.

The TRILL equivalent topologies are:

+-----+        +-----+
| RB2 |--------| RB1 |
+-----+        +-----+

+-----+          +-----+
| RB1 |----------| RB3 |
+-----+          +-----+

I like a) and I hope we are in agreement that the right answer is a),
but I haven't seen it explained in any of the documents.

-- Silvano



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAF0ZP1o020120 for <[e-mail]>; Tue, 14 Nov 2006 16:35:26 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Tue, 14 Nov 2006 16:35:24 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: AccH/XN+m4DB/QmZRKGYnLYfH/ygvgAT2M0A
From: "Silvano Gai" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAF0ZP1o020120
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2006 00:51:47 -0000
Status: RO
Content-Length: 6790

Radia,

May I propose:

c) Your b) proposal plus the option that on point-to-point link we can use a well know destination MAC address, i.e. RBridge-Next-Hop. 

This allows building a simplified HW that works only on point-to-point links and that does not keep a next hop adjacency table.

-- Silvano

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]]
> Sent: Tuesday, November 14, 2006 6:59 AM
> To: Guillermo Ib??ez
> Cc: Caitlin Bestler; J. R. Rivers; Silvano Gai; [e-mail]
> Subject: Re: [rbridge] Should we optimize the common case?
> 
> The first RBridge has to recognize a true MAC address, so we can't
> reassign endnodes hierarchical
> addresses. I think trying to see nickname | nexthop as a hierarchical
> address is just confusing, especially
> since the "hierarchical address" will change at every hop. With the
> LIDs, it's sort of like a hierarchical
> address, but not really, since lots of endnodes (all the ones on the
> same link) will share the same "hierarchical
> address". But with Sanjay's proposal of folding "egress nickname" and
> "next hop nickname" into the
> destination address of the hop-by-hop header, this is *not* a
> hierarchical address of the destination endnode.
> And besides, this doesn't change the technical proposal, so trying to
> think of it that way is, I think, a digression.
> 
> The real question I think is between two proposals, with variants:
> 
> a) have 2 byte + Ethernet header: by folding next hop and egress
> nickname into "destination MAC" and
> transmitting RBridge and ingress RBridge nickname into "source MAC",
> with TTL as the only thing left over,
> with possible variant being folding TTL into the source and destination
> MACs as well.
> 
> b) have 6 byte + Ethernet header; putting ingress and egress RBridge
> nicknames and TTL into the 6 bytes;
> with possible variant being a variable length shim to add things like
> LIDs.
> 
> I'd prefer b) with fixed length at 6 bytes. My second choice is a) with
> the 2 byte addition for TTL, since
> I think also folding TTL into the MACs will be even more confusing.
> 
> Radia
> 
> 
> 
> I do think we should allow advertisement of MAC address ranges in IS-IS
> endnode reports, because
> in some cases this will make smaller tables.
> 
> I'd prefer the "true" hop by hop header, where next hop and this hop is
> used as the MAC addresses,
> and a shim header with 6 bytes, partially because it is simpler to
> understand, and will be perceived as
> pretty straightforward compared with what routers do; i.e., take a piece
> of information, put an end-to
> end header (e.g., IP header, but in our case the shim with
> ingress/egress RBridge and
> TTL) on the information, and then hop by hop put a link-specific header
> on (e.g.,
> an Ethernet header).
> 
> Radia
> 
> 
> 
> Guillermo Ib??ez wrote:
> 
> > I think there is a misunderstanding.  This is IMHO a practical
> > alternative:
> > -An RBridge port is connected to a  "link" and receives frames from
> > multiple hosts:  The RBridge builds an internal translation table of
> > global MACs to hierarchical MACs (HMACs) assigned by him and replaces
> > global MAC by hierarchical MAC in the original frame.
> > -These hierarchical MAC addresses for hosts contain the RBridge
> > Nickname, so it becomes *part* of the complete host address
> > transmitted as "original" frame.  So these addresses should contain
> > RBridge Nickname with host nickname appended (internal grouping of
> > host nicknames per RBridge port ID would also help). To be defined.
> > - Hierarchical MAC MAY also be used in the ARP response packets (when
> > RBridge acts as proxy ARP or by interception of the host response
> > packet), so the requester obtains the hierarchical MAC address instead
> > of the global one and uses it for all transactions.
> > - The hosts with hierarchical MAC addresses do not need being
> > announced by the RBridges in their host lists, because their DR
> > RBridge nickname  is included in the hierarchical MAC address of host
> > in the "original" (now altered with HMAC) frame.
> > - Frames with inner hierarchical destination address need only to read
> > the destination RBridge Nickname to obtain the egrees RBridge (no need
> > to look host-RBridge table). The host list mechanism is not used by
> > hosts whose RBridge handles them with hierarchical addressing. Both
> > types, global and local hierarchical addresses may coexist. Local
> > hierarchical save processing and enhance scalability.
> > Hope this clarifies.
> > Guillermo
> >
> > PD.
> > Other issues
> > -DHCP-like mechanism
> > Hierarchical MACs can be assigned with DHCP like mechanism to hosts,
> > but IMHO this has impact on end nodes, so it can not be the standard
> > mechanism, only an option.
> > - Generic hierarchical MAC addresses and masks (ref. Dr. Morales slide)
> > I proposed the generic addressing format  that includes hierarchical
> > masks looking for a generic addressing space, that could be useful to
> > scale further RBridges in the future. I understand that at this stage
> > of definition of RBridges to look for a fully generic format could be
> > disruptive. However, the need for a generic hierarchical addressing
> > space in Ethernet is growing.
> >
> >
> >
> >
> > Caitlin Bestler escribi?:
> >
> >> Radia Perlman wrote:
> >>
> >>
> >>> Not sure I've been following this, but let me conjecture what
> >>> people are suggesting, and if I'm right about the suggestion,
> >>> I think it's a good idea. Correct me if it's not what people are
> >>> saying.
> >>> So I think what they are saying is the following:
> >>> a) there are cases where an RBridge has a block of addresses
> >>> (like DHCP) that it hands out to endnodes
> >>> b) in that case, it would be nice if the RBridge can
> >>> announce, in its LSP, the whole range of addresses, rather
> >>> than reporting each individually
> >>> c) the change would be an ability to express a range in the
> >>> endnode announcement. This seems easy, but I think it would
> >>> be best done with a 2nd TLV in IS-IS. The 1st TLV would be individual
> >>> addresses. The 2nd TLV would be pairs of addresses (low, high). Or
> >>> (low, increment), as in "starting with address X,
> >>> 32 addresses" (which would take up a bit less space than two MAC
> >>> addresses.
> >>> I don't think of this as a hierarchical address---I just
> >>> think of it as a range of addresses reachable from one RBridge.
> >>>
> >>>
> >>
> >>
> >> Reduction in the total number of reports required to support N
> >> addresses is probably the only benefit of "hierarchical addresses"
> >> that we can achieve if we are going to support global-scope MAC
> >> addresses as well. Which I'm certain everyone agrees is a given.
> >>
> >>
> >




Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAEHM9S2012787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 14 Nov 2006 09:22:09 -0800 (PST)
Received: from [127.0.0.1] (60.sub-75-210-252.myvzw.com [75.210.252.60]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kAEHLmhq018322; Tue, 14 Nov 2006 09:21:51 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 14 Nov 2006 09:21:45 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Caitlin Bestler <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE8E50D294611FF31D5B07DE8"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2006 17:22:12 -0000
Status: RO
Content-Length: 1680

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



Caitlin Bestler wrote:
> Guillermo Ib=E1=F1ez wrote:
>> Two comments.
>> Guillermo
>>
>> Radia Perlman escribi=F3:
>>> The first RBridge has to recognize a true MAC address,
>> The first RBridge recognizes a true MAC adress and replaces
>> in the encapsulated frame with the hierarchical address (MAC
>> swapping).
>=20
> I think you are suggesting that the RBRidge act as proxy ARP
> so that all remote traffic thinks that the local MAC address
> is *the* MAC address, complete with translation of MAC addresses
> on the fly.

That's now a router. IMO, it should act more like a bridge - it might
use MAC address wrappers to direct ingressed packets to the egress
rbridge, but should NOT affect the ARP table of hosts outside the rbridge=
=2E

Removal of the rbridge should ONLY cause reconfiguration of the spanning
tree in the remaining ethernet segments, NOT cause communication failure
due to incorrect ARP entries (i.e., that would destroy "unplug-and-play")=
=2E

Joe



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

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

iD8DBQFFWfspE5f5cImnZrsRAsRWAJ9njKg9KEfa/E/m3Jd8HcplEDgiowCeNwgW
hCydNDFWh406yUZNv8OyNYc=
=lcjb
-----END PGP SIGNATURE-----

--------------enigE8E50D294611FF31D5B07DE8--



Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAEGqwFS000608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 14 Nov 2006 08:53:00 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 89369A9E75; Tue, 14 Nov 2006 17:52:57 +0100 (CET)
Received: from [10.0.0.4] (39.Red-80-37-137.staticIP.rima-tde.net [80.37.137.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id B2B6DA9E63; Tue, 14 Nov 2006 17:52:56 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 14 Nov 2006 17:52:55 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Caitlin Bestler <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2006 16:53:09 -0000
Status: RO
Content-Length: 1185

You are likely right (DHCP and IPv6 defaul). But it is probably
worth to think a moment how to circunvent it before rejecting the 
approach, given the advantages involved.
Hierarchical addresses are an option to global standard host list 
mechanism, they could be enabled and disabled per RBridge.
Guillermo

Caitlin Bestler escribi?:
> Guillermo Ib??ez wrote:
>   
>> Two comments.
>> Guillermo
>>
>> Radia Perlman escribi?:
>>     
>>> The first RBridge has to recognize a true MAC address,
>>>       
>> The first RBridge recognizes a true MAC adress and replaces
>> in the encapsulated frame with the hierarchical address (MAC
>> swapping).
>>     
>
> I think you are suggesting that the RBRidge act as proxy ARP
> so that all remote traffic thinks that the local MAC address
> is *the* MAC address, complete with translation of MAC addresses
> on the fly.
>
> There are some cool possibilities there, but unfortunately I
> do not think such a solution is universally viable. For a local
> connection applications may attach actual meaning to the MAC
> address. Some immediate examples that come to mind include
> DHCP servers and the generation of default IPv6 addresses.
>
>   


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAEGpGNJ029578 for <[e-mail]>; Tue, 14 Nov 2006 08:51:16 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Tue, 14 Nov 2006 08:51:13 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: AccH2MGHME5IihgBTWWcULFsHzZIMgAMqY2Q
From: "J. R. Rivers" <[e-mail]>
To: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>, "Caitlin Bestler" <[e-mail]>, "Radia Perlman" <[e-mail]>, "Silvano Gai" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAEGpGNJ029578
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2006 16:51:18 -0000
Status: RO
Content-Length: 5273

I've worked on such systems, and while the address summarization creates a degree of scale, you generally find that the fixed association between endnode and switch is very restricting and limiting.  

This is one of the reasons that I find TRILL very clean... the relationship between an endnode and an rbridge is that of convenience, not requirement.

I can build multi-homed networks... assuming that an edge rbridge can maintain multiple endhost->rbridge associations without changing the forwarding constructs of the rbridge "core".  This occurs because each edge rbridge advertises reachability to the host.

I can redirect frames through an rbridge network without changing the underlying L2 constructs (as required by many IDS/crypto protocols).  Then I can forward them to their intended destinations.

All of these require support from coordinating edge rbridges... the endhosts, other edge rbridges, and core rbridges are blissfully unaware of these goings on.

All this comes from partitioning the system into a simple, fast, cheap HW forwarding plane and a fully SW managed control plane.

JR



> -----Original Message-----
> From: Guillermo Ib??ez [mailto:[e-mail]] 
> Sent: Tuesday, November 14, 2006 2:37 AM
> To: Caitlin Bestler; Radia Perlman; J. R. Rivers; Silvano Gai
> Cc: [e-mail]
> Subject: Re: [rbridge] Should we optimize the common case?
> 
> I think there is a misunderstanding.  This is IMHO a 
> practical alternative:
> -An RBridge port is connected to a  "link" and receives frames from 
> multiple hosts:  The RBridge builds an internal translation table of  
> global MACs to hierarchical MACs (HMACs) assigned by him and replaces 
> global MAC by hierarchical MAC in the original frame.
> -These hierarchical MAC addresses for hosts contain the RBridge 
> Nickname, so it becomes *part* of the complete host address 
> transmitted 
> as "original" frame.  So these addresses should contain 
> RBridge Nickname 
> with host nickname appended (internal grouping of host nicknames per 
> RBridge port ID would also help). To be defined.
> - Hierarchical MAC MAY also be used in the ARP response packets (when 
> RBridge acts as proxy ARP or by interception of the host response 
> packet), so the requester obtains the hierarchical MAC 
> address instead 
> of the global one and uses it for all transactions.
> - The hosts with hierarchical MAC addresses do not need being 
> announced 
> by the RBridges in their host lists, because their DR RBridge 
> nickname  
> is included in the hierarchical MAC address of host in the "original" 
> (now altered with HMAC) frame.
> - Frames with inner hierarchical destination address need 
> only to read 
> the destination RBridge Nickname to obtain the egrees RBridge 
> (no need 
> to look host-RBridge table). The host list mechanism is not used by  
> hosts whose RBridge handles them with hierarchical addressing. 
> Both types, global and local hierarchical addresses may 
> coexist. Local 
> hierarchical save processing and enhance scalability.
> Hope this clarifies.
> Guillermo
> 
> PD.
> Other issues
> -DHCP-like mechanism
> Hierarchical MACs can be assigned with DHCP like mechanism to 
> hosts, but 
> IMHO this has impact on end nodes, so it can not be the standard 
> mechanism, only an option.
> - Generic hierarchical MAC addresses and masks (ref. Dr. 
> Morales slide)
> I proposed the generic addressing format  that includes hierarchical 
> masks looking for a generic addressing space, that could be useful to 
> scale further RBridges in the future. I understand that at 
> this stage of 
> definition of RBridges to look for a fully generic format could be 
> disruptive. However, the need for a generic hierarchical addressing 
> space in Ethernet is growing.
>  
> 
> 
> 
> Caitlin Bestler escribi?:
> > Radia Perlman wrote:
> >   
> >> Not sure I've been following this, but let me conjecture what
> >> people are suggesting, and if I'm right about the suggestion,
> >> I think it's a good idea. Correct me if it's not what people are
> >> saying. 
> >>
> >> So I think what they are saying is the following:
> >> a) there are cases where an RBridge has a block of addresses
> >> (like DHCP) that it hands out to endnodes
> >> b) in that case, it would be nice if the RBridge can
> >> announce, in its LSP, the whole range of addresses, rather
> >> than reporting each individually
> >> c) the change would be an ability to express a range in the
> >> endnode announcement. This seems easy, but I think it would
> >> be best done with a 2nd TLV in IS-IS. The 1st TLV would be 
> individual
> >> addresses. The 2nd TLV would be pairs of addresses (low, high). Or
> >> (low, increment), as in "starting with address X,
> >> 32 addresses" (which would take up a bit less space than two MAC
> >> addresses. 
> >>
> >> I don't think of this as a hierarchical address---I just
> >> think of it as a range of addresses reachable from one RBridge.
> >>
> >>     
> >
> > Reduction in the total number of reports required to support N
> > addresses is probably the only benefit of "hierarchical addresses"
> > that we can achieve if we are going to support global-scope MAC
> > addresses as well. Which I'm certain everyone agrees is a given.
> >
> >   
> 



Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAEGYRsN023410 for <[e-mail]>; Tue, 14 Nov 2006 08:34:27 -0800 (PST)
Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Tue, 14 Nov 2006 08:34:09 -0800
X-Server-Uuid: 9206F490-5C8F-4575-BE70-2AAA8A3D4853
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id B93122AF; Tue, 14 Nov 2006 08:34:09 -0800 (PST)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 861962AE; Tue, 14 Nov 2006 08:34:09 -0800 (PST)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id ELH58537; Tue, 14 Nov 2006 08:34:04 -0800 (PST)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 3DDC320501; Tue, 14 Nov 2006 08:34:04 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 14 Nov 2006 08:34:03 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: AccH//VfxHLgOojrTCe9cNTIVyP6TQACj6qQ
From: "Caitlin Bestler" <[e-mail]>
To: "=?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?=" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-WSS-ID: 69472F8B3ES5635691-01-01
Content-Type: text/plain; charset=iso-8859-1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAEGYRsN023410
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2006 16:34:36 -0000
Status: RO
Content-Length: 784

Guillermo Ib??ez wrote:
> Two comments.
> Guillermo
> 
> Radia Perlman escribi?:
>> The first RBridge has to recognize a true MAC address,
> The first RBridge recognizes a true MAC adress and replaces
> in the encapsulated frame with the hierarchical address (MAC
> swapping).

I think you are suggesting that the RBRidge act as proxy ARP
so that all remote traffic thinks that the local MAC address
is *the* MAC address, complete with translation of MAC addresses
on the fly.

There are some cool possibilities there, but unfortunately I
do not think such a solution is universally viable. For a local
connection applications may attach actual meaning to the MAC
address. Some immediate examples that come to mind include
DHCP servers and the generation of default IPv6 addresses.




Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAEGSWxP020578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 14 Nov 2006 08:28:34 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 84F1CA84D3; Tue, 14 Nov 2006 17:28:31 +0100 (CET)
Received: from [10.0.0.4] (39.Red-80-37-137.staticIP.rima-tde.net [80.37.137.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id EF2B6A9B4E; Tue, 14 Nov 2006 17:28:28 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 14 Nov 2006 17:28:27 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Hierarchical addresses
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2006 16:28:48 -0000
Status: RO
Content-Length: 1540

Further clarifications
Guillermo

Radia Perlman escribi?:
> Ah. I think I misunderstood a bit the intent of the hierarchical 
> addresses in my previous
> message. I think the suggestion was for
> "endnodes" that don't have a fixed MAC address, so nobody would ever 
> learn
> their true MAC address. This was not an attempt to assign hierarchical 
> MAC addresses to
> all the endnodes, which I assumed.
> But even so, you want the perceived MAC address never
> to change once assigned, and the RBridge nickname might change, 
> creating confusion.
>
The RBridge nickname will change when the DR changes due to the previous 
DR being unavailable or not being root bridge anymore.
> We will achieve some scalability by announcing ranges of MAC addresses 
> (perhaps even from the local space)
> that an RBridge with virtual attached endnodes can assign. If the 
> block of MAC addresses is configured, then
> it's the "customer's fault" if the addresses are not unique within the 
> campus. Perhaps to avoid misconfiguration,
> RBridges can announce the block of MAC addresses they are going to 
> assign to virtual attached endnodes.
The hierarchical MAC shall contain the DR RBridge nickname plus host 
identifier. If the RBridge nickname is unique within the campus, so will 
be the hierarchical MAC addresses.
I am not in favour of "ranges", but of hierarchy.
> This can either be for just noticing misconfiguration, or can be a 
> negotiation -- choosing a different block if
> it conflicts with someone else.
>
> Radia
>
>
>>>  
>>
>


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAEGN1ZU018267 for <[e-mail]>; Tue, 14 Nov 2006 08:23:01 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Tue, 14 Nov 2006 08:22:58 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: AccH2MGHME5IihgBTWWcULFsHzZIMgAMBjmQ
From: "J. R. Rivers" <[e-mail]>
To: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>, "Caitlin Bestler" <[e-mail]>, "Radia Perlman" <[e-mail]>, "Silvano Gai" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAEGN1ZU018267
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2006 16:23:15 -0000
Status: RO
Content-Length: 4245

Are you suggesting address translation in the context of a layer 2 network?

JR

> -----Original Message-----
> From: Guillermo Ib??ez [mailto:[e-mail]] 
> Sent: Tuesday, November 14, 2006 2:37 AM
> To: Caitlin Bestler; Radia Perlman; J. R. Rivers; Silvano Gai
> Cc: [e-mail]
> Subject: Re: [rbridge] Should we optimize the common case?
> 
> I think there is a misunderstanding.  This is IMHO a 
> practical alternative:
> -An RBridge port is connected to a  "link" and receives frames from 
> multiple hosts:  The RBridge builds an internal translation table of  
> global MACs to hierarchical MACs (HMACs) assigned by him and replaces 
> global MAC by hierarchical MAC in the original frame.
> -These hierarchical MAC addresses for hosts contain the RBridge 
> Nickname, so it becomes *part* of the complete host address 
> transmitted 
> as "original" frame.  So these addresses should contain 
> RBridge Nickname 
> with host nickname appended (internal grouping of host nicknames per 
> RBridge port ID would also help). To be defined.
> - Hierarchical MAC MAY also be used in the ARP response packets (when 
> RBridge acts as proxy ARP or by interception of the host response 
> packet), so the requester obtains the hierarchical MAC 
> address instead 
> of the global one and uses it for all transactions.
> - The hosts with hierarchical MAC addresses do not need being 
> announced 
> by the RBridges in their host lists, because their DR RBridge 
> nickname  
> is included in the hierarchical MAC address of host in the "original" 
> (now altered with HMAC) frame.
> - Frames with inner hierarchical destination address need 
> only to read 
> the destination RBridge Nickname to obtain the egrees RBridge 
> (no need 
> to look host-RBridge table). The host list mechanism is not used by  
> hosts whose RBridge handles them with hierarchical addressing. 
> Both types, global and local hierarchical addresses may 
> coexist. Local 
> hierarchical save processing and enhance scalability.
> Hope this clarifies.
> Guillermo
> 
> PD.
> Other issues
> -DHCP-like mechanism
> Hierarchical MACs can be assigned with DHCP like mechanism to 
> hosts, but 
> IMHO this has impact on end nodes, so it can not be the standard 
> mechanism, only an option.
> - Generic hierarchical MAC addresses and masks (ref. Dr. 
> Morales slide)
> I proposed the generic addressing format  that includes hierarchical 
> masks looking for a generic addressing space, that could be useful to 
> scale further RBridges in the future. I understand that at 
> this stage of 
> definition of RBridges to look for a fully generic format could be 
> disruptive. However, the need for a generic hierarchical addressing 
> space in Ethernet is growing.
>  
> 
> 
> 
> Caitlin Bestler escribi?:
> > Radia Perlman wrote:
> >   
> >> Not sure I've been following this, but let me conjecture what
> >> people are suggesting, and if I'm right about the suggestion,
> >> I think it's a good idea. Correct me if it's not what people are
> >> saying. 
> >>
> >> So I think what they are saying is the following:
> >> a) there are cases where an RBridge has a block of addresses
> >> (like DHCP) that it hands out to endnodes
> >> b) in that case, it would be nice if the RBridge can
> >> announce, in its LSP, the whole range of addresses, rather
> >> than reporting each individually
> >> c) the change would be an ability to express a range in the
> >> endnode announcement. This seems easy, but I think it would
> >> be best done with a 2nd TLV in IS-IS. The 1st TLV would be 
> individual
> >> addresses. The 2nd TLV would be pairs of addresses (low, high). Or
> >> (low, increment), as in "starting with address X,
> >> 32 addresses" (which would take up a bit less space than two MAC
> >> addresses. 
> >>
> >> I don't think of this as a hierarchical address---I just
> >> think of it as a range of addresses reachable from one RBridge.
> >>
> >>     
> >
> > Reduction in the total number of reports required to support N
> > addresses is probably the only benefit of "hierarchical addresses"
> > that we can achieve if we are going to support global-scope MAC
> > addresses as well. Which I'm certain everyone agrees is a given.
> >
> >   
> 



Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAEFStu5027404 for <[e-mail]>; Tue, 14 Nov 2006 07:28:55 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 14 Nov 2006 07:28:54 -0800 (PST)
Received: from sun.com ([129.150.32.222]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 14 Nov 2006 07:28:51 -0800 (PST)
Date: Tue, 14 Nov 2006 07:28:56 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]> <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Hierarchical addresses
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2006 15:29:04 -0000
Status: RO
Content-Length: 1070

Ah. I think I misunderstood a bit the intent of the hierarchical 
addresses in my previous
message. I think the suggestion was for
"endnodes" that don't have a fixed MAC address, so nobody would ever learn
their true MAC address. This was not an attempt to assign hierarchical 
MAC addresses to
all the endnodes, which I assumed.
But even so, you want the perceived MAC address never
to change once assigned, and the RBridge nickname might change, creating 
confusion.

We will achieve some scalability by announcing ranges of MAC addresses 
(perhaps even from the local space)
that an RBridge with virtual attached endnodes can assign. If the block 
of MAC addresses is configured, then
it's the "customer's fault" if the addresses are not unique within the 
campus. Perhaps to avoid misconfiguration,
RBridges can announce the block of MAC addresses they are going to 
assign to virtual attached endnodes.
This can either be for just noticing misconfiguration, or can be a 
negotiation -- choosing a different block if
it conflicts with someone else.

Radia


>>  
>



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAEFP6dU025781 for <[e-mail]>; Tue, 14 Nov 2006 07:25:06 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Tue, 14 Nov 2006 07:25:03 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: AccHic4h4Z5T7pmfQx6tCnLsg3e1AQACIEmwABuq0oA=
From: "J. R. Rivers" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAEFP6dU025781
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2006 15:25:09 -0000
Status: RO
Content-Length: 1693

I agree here. 

> -----Original Message-----
> From: Caitlin Bestler [mailto:[e-mail]] 
> Sent: Monday, November 13, 2006 6:14 PM
> To: Radia Perlman; J. R. Rivers
> Cc: Silvano Gai; Guillermo Ib??ez; [e-mail]
> Subject: RE: [rbridge] Should we optimize the common case?
> 
> Radia Perlman wrote:
> > Not sure I've been following this, but let me conjecture what
> > people are suggesting, and if I'm right about the suggestion,
> > I think it's a good idea. Correct me if it's not what people are
> > saying. 
> > 
> > So I think what they are saying is the following:
> > a) there are cases where an RBridge has a block of addresses
> > (like DHCP) that it hands out to endnodes
> > b) in that case, it would be nice if the RBridge can
> > announce, in its LSP, the whole range of addresses, rather
> > than reporting each individually
> > c) the change would be an ability to express a range in the
> > endnode announcement. This seems easy, but I think it would
> > be best done with a 2nd TLV in IS-IS. The 1st TLV would be 
> individual
> > addresses. The 2nd TLV would be pairs of addresses (low, high). Or
> > (low, increment), as in "starting with address X,
> > 32 addresses" (which would take up a bit less space than two MAC
> > addresses. 
> > 
> > I don't think of this as a hierarchical address---I just
> > think of it as a range of addresses reachable from one RBridge.
> > 
> 
> Reduction in the total number of reports required to support N
> addresses is probably the only benefit of "hierarchical addresses"
> that we can achieve if we are going to support global-scope MAC
> addresses as well. Which I'm certain everyone agrees is a given.
> 
> 



Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAEFGvIN022461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 14 Nov 2006 07:16:59 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 833B7A9DD1; Tue, 14 Nov 2006 16:16:56 +0100 (CET)
Received: from [10.0.0.4] (39.Red-80-37-137.staticIP.rima-tde.net [80.37.137.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 2E904A9D7A; Tue, 14 Nov 2006 16:16:45 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 14 Nov 2006 16:16:43 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2006 15:17:09 -0000
Status: RO
Content-Length: 6481

Two comments.
Guillermo

Radia Perlman escribi?:
> The first RBridge has to recognize a true MAC address, 
The first RBridge recognizes a true MAC adress and replaces in the 
encapsulated frame with the hierarchical address (MAC swapping).
> so we can't reassign endnodes hierarchical
> addresses. I think trying to see nickname | nexthop as a hierarchical 
> address is just confusing, especially
> since the "hierarchical address" will change at every hop.
The hierarchical address consists of DR RBridge nickname plus host 
nickname (assigned by DR), so it does not change at every hop.
> With the LIDs, it's sort of like a hierarchical
> address, but not really, since lots of endnodes (all the ones on the 
> same link) will share the same "hierarchical
> address". But with Sanjay's proposal of folding "egress nickname" and 
> "next hop nickname" into the
> destination address of the hop-by-hop header, this is *not* a 
> hierarchical address of the destination endnode.
> And besides, this doesn't change the technical proposal, so trying to 
> think of it that way is, I think, a digression.
>
> The real question I think is between two proposals, with variants:
>
> a) have 2 byte + Ethernet header: by folding next hop and egress 
> nickname into "destination MAC" and
> transmitting RBridge and ingress RBridge nickname into "source MAC", 
> with TTL as the only thing left over,
> with possible variant being folding TTL into the source and 
> destination MACs as well.
>
> b) have 6 byte + Ethernet header; putting ingress and egress RBridge 
> nicknames and TTL into the 6 bytes;
> with possible variant being a variable length shim to add things like 
> LIDs.
>
> I'd prefer b) with fixed length at 6 bytes. My second choice is a) 
> with the 2 byte addition for TTL, since
> I think also folding TTL into the MACs will be even more confusing.
>
> Radia
>
>
>
> I do think we should allow advertisement of MAC address ranges in 
> IS-IS endnode reports, because
> in some cases this will make smaller tables.
>
> I'd prefer the "true" hop by hop header, where next hop and this hop 
> is used as the MAC addresses,
> and a shim header with 6 bytes, partially because it is simpler to 
> understand, and will be perceived as
> pretty straightforward compared with what routers do; i.e., take a 
> piece of information, put an end-to
> end header (e.g., IP header, but in our case the shim with 
> ingress/egress RBridge and
> TTL) on the information, and then hop by hop put a link-specific 
> header on (e.g.,
> an Ethernet header).
>
> Radia
>
>
>
> Guillermo Ib??ez wrote:
>
>> I think there is a misunderstanding.  This is IMHO a practical 
>> alternative:
>> -An RBridge port is connected to a  "link" and receives frames from 
>> multiple hosts:  The RBridge builds an internal translation table of  
>> global MACs to hierarchical MACs (HMACs) assigned by him and replaces 
>> global MAC by hierarchical MAC in the original frame.
>> -These hierarchical MAC addresses for hosts contain the RBridge 
>> Nickname, so it becomes *part* of the complete host address 
>> transmitted as "original" frame.  So these addresses should contain 
>> RBridge Nickname with host nickname appended (internal grouping of 
>> host nicknames per RBridge port ID would also help). To be defined.
>> - Hierarchical MAC MAY also be used in the ARP response packets (when 
>> RBridge acts as proxy ARP or by interception of the host response 
>> packet), so the requester obtains the hierarchical MAC address 
>> instead of the global one and uses it for all transactions.
>> - The hosts with hierarchical MAC addresses do not need being 
>> announced by the RBridges in their host lists, because their DR 
>> RBridge nickname  is included in the hierarchical MAC address of host 
>> in the "original" (now altered with HMAC) frame.
>> - Frames with inner hierarchical destination address need only to 
>> read the destination RBridge Nickname to obtain the egrees RBridge 
>> (no need to look host-RBridge table). The host list mechanism is not 
>> used by  hosts whose RBridge handles them with hierarchical 
>> addressing. Both types, global and local hierarchical addresses may 
>> coexist. Local hierarchical save processing and enhance scalability.
>> Hope this clarifies.
>> Guillermo
>>
>> PD.
>> Other issues
>> -DHCP-like mechanism
>> Hierarchical MACs can be assigned with DHCP like mechanism to hosts, 
>> but IMHO this has impact on end nodes, so it can not be the standard 
>> mechanism, only an option.
>> - Generic hierarchical MAC addresses and masks (ref. Dr. Morales slide)
>> I proposed the generic addressing format  that includes hierarchical 
>> masks looking for a generic addressing space, that could be useful to 
>> scale further RBridges in the future. I understand that at this stage 
>> of definition of RBridges to look for a fully generic format could be 
>> disruptive. However, the need for a generic hierarchical addressing 
>> space in Ethernet is growing.
>>
>>
>>
>>
>> Caitlin Bestler escribi?:
>>
>>> Radia Perlman wrote:
>>>  
>>>
>>>> Not sure I've been following this, but let me conjecture what
>>>> people are suggesting, and if I'm right about the suggestion,
>>>> I think it's a good idea. Correct me if it's not what people are
>>>> saying.
>>>> So I think what they are saying is the following:
>>>> a) there are cases where an RBridge has a block of addresses
>>>> (like DHCP) that it hands out to endnodes
>>>> b) in that case, it would be nice if the RBridge can
>>>> announce, in its LSP, the whole range of addresses, rather
>>>> than reporting each individually
>>>> c) the change would be an ability to express a range in the
>>>> endnode announcement. This seems easy, but I think it would
>>>> be best done with a 2nd TLV in IS-IS. The 1st TLV would be individual
>>>> addresses. The 2nd TLV would be pairs of addresses (low, high). Or
>>>> (low, increment), as in "starting with address X,
>>>> 32 addresses" (which would take up a bit less space than two MAC
>>>> addresses.
>>>> I don't think of this as a hierarchical address---I just
>>>> think of it as a range of addresses reachable from one RBridge.
>>>>
>>>>     
>>>
>>>
>>> Reduction in the total number of reports required to support N
>>> addresses is probably the only benefit of "hierarchical addresses"
>>> that we can achieve if we are going to support global-scope MAC
>>> addresses as well. Which I'm certain everyone agrees is a given.
>>>
>>>   
>>
>


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAEExIhv016026 for <[e-mail]>; Tue, 14 Nov 2006 06:59:18 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 14 Nov 2006 06:59:14 -0800 (PST)
Received: from sun.com ([129.150.32.222]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 14 Nov 2006 06:59:14 -0800 (PST)
Date: Tue, 14 Nov 2006 06:59:17 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 8BIT
X-Accept-Language: en-us, en
References: <[e-mail]> <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2006 14:59:34 -0000
Status: RO
Content-Length: 5983

The first RBridge has to recognize a true MAC address, so we can't 
reassign endnodes hierarchical
addresses. I think trying to see nickname | nexthop as a hierarchical 
address is just confusing, especially
since the "hierarchical address" will change at every hop. With the 
LIDs, it's sort of like a hierarchical
address, but not really, since lots of endnodes (all the ones on the 
same link) will share the same "hierarchical
address". But with Sanjay's proposal of folding "egress nickname" and 
"next hop nickname" into the
destination address of the hop-by-hop header, this is *not* a 
hierarchical address of the destination endnode.
And besides, this doesn't change the technical proposal, so trying to 
think of it that way is, I think, a digression.

The real question I think is between two proposals, with variants:

a) have 2 byte + Ethernet header: by folding next hop and egress 
nickname into "destination MAC" and
transmitting RBridge and ingress RBridge nickname into "source MAC", 
with TTL as the only thing left over,
with possible variant being folding TTL into the source and destination 
MACs as well.

b) have 6 byte + Ethernet header; putting ingress and egress RBridge 
nicknames and TTL into the 6 bytes;
with possible variant being a variable length shim to add things like LIDs.

I'd prefer b) with fixed length at 6 bytes. My second choice is a) with 
the 2 byte addition for TTL, since
I think also folding TTL into the MACs will be even more confusing.

Radia



I do think we should allow advertisement of MAC address ranges in IS-IS 
endnode reports, because
in some cases this will make smaller tables.

I'd prefer the "true" hop by hop header, where next hop and this hop is 
used as the MAC addresses,
and a shim header with 6 bytes, partially because it is simpler to 
understand, and will be perceived as
pretty straightforward compared with what routers do; i.e., take a piece 
of information, put an end-to
end header (e.g., IP header, but in our case the shim with 
ingress/egress RBridge and
TTL) on the information, and then hop by hop put a link-specific header 
on (e.g.,
an Ethernet header).

Radia



Guillermo Ib??ez wrote:

> I think there is a misunderstanding.  This is IMHO a practical 
> alternative:
> -An RBridge port is connected to a  "link" and receives frames from 
> multiple hosts:  The RBridge builds an internal translation table of  
> global MACs to hierarchical MACs (HMACs) assigned by him and replaces 
> global MAC by hierarchical MAC in the original frame.
> -These hierarchical MAC addresses for hosts contain the RBridge 
> Nickname, so it becomes *part* of the complete host address 
> transmitted as "original" frame.  So these addresses should contain 
> RBridge Nickname with host nickname appended (internal grouping of 
> host nicknames per RBridge port ID would also help). To be defined.
> - Hierarchical MAC MAY also be used in the ARP response packets (when 
> RBridge acts as proxy ARP or by interception of the host response 
> packet), so the requester obtains the hierarchical MAC address instead 
> of the global one and uses it for all transactions.
> - The hosts with hierarchical MAC addresses do not need being 
> announced by the RBridges in their host lists, because their DR 
> RBridge nickname  is included in the hierarchical MAC address of host 
> in the "original" (now altered with HMAC) frame.
> - Frames with inner hierarchical destination address need only to read 
> the destination RBridge Nickname to obtain the egrees RBridge (no need 
> to look host-RBridge table). The host list mechanism is not used by  
> hosts whose RBridge handles them with hierarchical addressing. Both 
> types, global and local hierarchical addresses may coexist. Local 
> hierarchical save processing and enhance scalability.
> Hope this clarifies.
> Guillermo
>
> PD.
> Other issues
> -DHCP-like mechanism
> Hierarchical MACs can be assigned with DHCP like mechanism to hosts, 
> but IMHO this has impact on end nodes, so it can not be the standard 
> mechanism, only an option.
> - Generic hierarchical MAC addresses and masks (ref. Dr. Morales slide)
> I proposed the generic addressing format  that includes hierarchical 
> masks looking for a generic addressing space, that could be useful to 
> scale further RBridges in the future. I understand that at this stage 
> of definition of RBridges to look for a fully generic format could be 
> disruptive. However, the need for a generic hierarchical addressing 
> space in Ethernet is growing.
>
>
>
>
> Caitlin Bestler escribi?:
>
>> Radia Perlman wrote:
>>  
>>
>>> Not sure I've been following this, but let me conjecture what
>>> people are suggesting, and if I'm right about the suggestion,
>>> I think it's a good idea. Correct me if it's not what people are
>>> saying.
>>> So I think what they are saying is the following:
>>> a) there are cases where an RBridge has a block of addresses
>>> (like DHCP) that it hands out to endnodes
>>> b) in that case, it would be nice if the RBridge can
>>> announce, in its LSP, the whole range of addresses, rather
>>> than reporting each individually
>>> c) the change would be an ability to express a range in the
>>> endnode announcement. This seems easy, but I think it would
>>> be best done with a 2nd TLV in IS-IS. The 1st TLV would be individual
>>> addresses. The 2nd TLV would be pairs of addresses (low, high). Or
>>> (low, increment), as in "starting with address X,
>>> 32 addresses" (which would take up a bit less space than two MAC
>>> addresses.
>>> I don't think of this as a hierarchical address---I just
>>> think of it as a range of addresses reachable from one RBridge.
>>>
>>>     
>>
>>
>> Reduction in the total number of reports required to support N
>> addresses is probably the only benefit of "hierarchical addresses"
>> that we can achieve if we are going to support global-scope MAC
>> addresses as well. Which I'm certain everyone agrees is a given.
>>
>>   
>



Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAEAaXbq020851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 14 Nov 2006 02:36:35 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7E17BEDD54; Tue, 14 Nov 2006 11:36:32 +0100 (CET)
Received: from [10.0.0.4] (39.Red-80-37-137.staticIP.rima-tde.net [80.37.137.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 38551EDD48; Tue, 14 Nov 2006 11:36:30 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 14 Nov 2006 11:36:30 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Caitlin Bestler <[e-mail]>, Radia Perlman <[e-mail]>, "J. R. Rivers" <[e-mail]>, Silvano Gai <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2006 10:36:44 -0000
Status: RO
Content-Length: 3687

I think there is a misunderstanding.  This is IMHO a practical alternative:
-An RBridge port is connected to a  "link" and receives frames from 
multiple hosts:  The RBridge builds an internal translation table of  
global MACs to hierarchical MACs (HMACs) assigned by him and replaces 
global MAC by hierarchical MAC in the original frame.
-These hierarchical MAC addresses for hosts contain the RBridge 
Nickname, so it becomes *part* of the complete host address transmitted 
as "original" frame.  So these addresses should contain RBridge Nickname 
with host nickname appended (internal grouping of host nicknames per 
RBridge port ID would also help). To be defined.
- Hierarchical MAC MAY also be used in the ARP response packets (when 
RBridge acts as proxy ARP or by interception of the host response 
packet), so the requester obtains the hierarchical MAC address instead 
of the global one and uses it for all transactions.
- The hosts with hierarchical MAC addresses do not need being announced 
by the RBridges in their host lists, because their DR RBridge nickname  
is included in the hierarchical MAC address of host in the "original" 
(now altered with HMAC) frame.
- Frames with inner hierarchical destination address need only to read 
the destination RBridge Nickname to obtain the egrees RBridge (no need 
to look host-RBridge table). The host list mechanism is not used by  
hosts whose RBridge handles them with hierarchical addressing. 
Both types, global and local hierarchical addresses may coexist. Local 
hierarchical save processing and enhance scalability.
Hope this clarifies.
Guillermo

PD.
Other issues
-DHCP-like mechanism
Hierarchical MACs can be assigned with DHCP like mechanism to hosts, but 
IMHO this has impact on end nodes, so it can not be the standard 
mechanism, only an option.
- Generic hierarchical MAC addresses and masks (ref. Dr. Morales slide)
I proposed the generic addressing format  that includes hierarchical 
masks looking for a generic addressing space, that could be useful to 
scale further RBridges in the future. I understand that at this stage of 
definition of RBridges to look for a fully generic format could be 
disruptive. However, the need for a generic hierarchical addressing 
space in Ethernet is growing.
 



Caitlin Bestler escribi?:
> Radia Perlman wrote:
>   
>> Not sure I've been following this, but let me conjecture what
>> people are suggesting, and if I'm right about the suggestion,
>> I think it's a good idea. Correct me if it's not what people are
>> saying. 
>>
>> So I think what they are saying is the following:
>> a) there are cases where an RBridge has a block of addresses
>> (like DHCP) that it hands out to endnodes
>> b) in that case, it would be nice if the RBridge can
>> announce, in its LSP, the whole range of addresses, rather
>> than reporting each individually
>> c) the change would be an ability to express a range in the
>> endnode announcement. This seems easy, but I think it would
>> be best done with a 2nd TLV in IS-IS. The 1st TLV would be individual
>> addresses. The 2nd TLV would be pairs of addresses (low, high). Or
>> (low, increment), as in "starting with address X,
>> 32 addresses" (which would take up a bit less space than two MAC
>> addresses. 
>>
>> I don't think of this as a hierarchical address---I just
>> think of it as a range of addresses reachable from one RBridge.
>>
>>     
>
> Reduction in the total number of reports required to support N
> addresses is probably the only benefit of "hierarchical addresses"
> that we can achieve if we are going to support global-scope MAC
> addresses as well. Which I'm certain everyone agrees is a given.
>
>   


Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAE2EU3T010231 for <[e-mail]>; Mon, 13 Nov 2006 18:14:30 -0800 (PST)
Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Mon, 13 Nov 2006 18:14:18 -0800
X-Server-Uuid: 05DA3F36-9AA8-4766-A7E5-53B43A7C42E6
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id E78AF2AF; Mon, 13 Nov 2006 18:14:17 -0800 (PST)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id C47DA2AE; Mon, 13 Nov 2006 18:14:17 -0800 (PST)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id ELF58797; Mon, 13 Nov 2006 18:14:08 -0800 (PST)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 6834C20501; Mon, 13 Nov 2006 18:14:08 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 13 Nov 2006 18:14:05 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: AccHic4h4Z5T7pmfQx6tCnLsg3e1AQACIEmw
From: "Caitlin Bestler" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "J. R. Rivers" <[e-mail]>
X-WSS-ID: 6947F9F039O5352246-01-01
Content-Type: text/plain; charset=iso-8859-1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAE2EU3T010231
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2006 02:14:41 -0000
Status: RO
Content-Length: 1331

Radia Perlman wrote:
> Not sure I've been following this, but let me conjecture what
> people are suggesting, and if I'm right about the suggestion,
> I think it's a good idea. Correct me if it's not what people are
> saying. 
> 
> So I think what they are saying is the following:
> a) there are cases where an RBridge has a block of addresses
> (like DHCP) that it hands out to endnodes
> b) in that case, it would be nice if the RBridge can
> announce, in its LSP, the whole range of addresses, rather
> than reporting each individually
> c) the change would be an ability to express a range in the
> endnode announcement. This seems easy, but I think it would
> be best done with a 2nd TLV in IS-IS. The 1st TLV would be individual
> addresses. The 2nd TLV would be pairs of addresses (low, high). Or
> (low, increment), as in "starting with address X,
> 32 addresses" (which would take up a bit less space than two MAC
> addresses. 
> 
> I don't think of this as a hierarchical address---I just
> think of it as a range of addresses reachable from one RBridge.
> 

Reduction in the total number of reports required to support N
addresses is probably the only benefit of "hierarchical addresses"
that we can achieve if we are going to support global-scope MAC
addresses as well. Which I'm certain everyone agrees is a given.




Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAE1BFlZ020287 for <[e-mail]>; Mon, 13 Nov 2006 17:11:15 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 13 Nov 2006 17:11:14 -0800 (PST)
Received: from sun.com ([129.150.32.222]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 13 Nov 2006 17:11:14 -0800 (PST)
Date: Mon, 13 Nov 2006 17:11:19 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "J. R. Rivers" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 8BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2006 01:11:21 -0000
Status: RO
Content-Length: 2584

Not sure I've been following this, but let me conjecture what people are 
suggesting, and if I'm right
about the suggestion, I think it's a good idea. Correct me if it's not 
what people are saying.

So I think what they are saying is the following:
a) there are cases where an RBridge has a block of addresses (like DHCP) 
that it hands out to endnodes
b) in that case, it would be nice if the RBridge can announce, in its 
LSP, the whole range of addresses,
rather than reporting each individually
c) the change would be an ability to express a range in the endnode 
announcement. This seems easy, but
I think it would be best done with a 2nd TLV in IS-IS. The 1st TLV would 
be individual addresses.
The 2nd TLV would be pairs of addresses (low, high). Or (low, 
increment), as in "starting with address X,
32 addresses" (which would take up a bit less space than two MAC addresses.

I don't think of this as a hierarchical address---I just think of it as 
a range of addresses reachable from
one RBridge.

Radia



J. R. Rivers wrote:

>Sounds like we are in agreement.
>
>JR
> 
>
>  
>
>>-----Original Message-----
>>From: Caitlin Bestler [mailto:[e-mail]] 
>>Sent: Saturday, November 11, 2006 7:20 PM
>>To: J. R. Rivers; Silvano Gai; Guillermo Ib??ez
>>Cc: [e-mail]; Radia Perlman
>>Subject: RE: [rbridge] Should we optimize the common case?
>>
>>J. R. Rivers wrote:
>>    
>>
>>>Hierarchical addresses assume that a single rbridge "owns" a
>>>station.  With the current concept of universal mac addresses
>>>with rbridge advertisement, a single station can be reached
>>>through multiple rbriges... allowing effective dual homing.
>>>
>>>I think that hierarchical station addresses require very careful
>>>thinking. 
>>>
>>>JR
>>>
>>>
>>>      
>>>
>>There are possible deployments of rbridges where the rbridge does
>>indeed "own" the end nodes, or perhaps it "owns" them in collaboration
>>with a partner rbridge. Prime examples would include an "rbridge"
>>implemented by a hypervisor and/or NIC to support multiple virtual
>>NICs, and a bridge connecting blades on a backplane with external
>>ethernet links.
>>
>>But even in these environments, the individual OSs may want to
>>configure their MAC addresses individually. So hierarchical addresses
>>would seem to be a possible enhancement, but there is no obvious
>>path to using them generally.
>>
>>As an option it would probably take the form of allowing
>>announcements of ranges of MAC addresses, rather than
>>requiring the  rbridge to announce each individually.
>>
>>
>>
>>    
>>
>
>  
>



Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAE11Ktm016954 for <[e-mail]>; Mon, 13 Nov 2006 17:01:20 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 13 Nov 2006 17:01:08 -0800 (PST)
Received: from sun.com ([129.150.32.222]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 13 Nov 2006 17:01:08 -0800 (PST)
Date: Mon, 13 Nov 2006 17:01:12 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Russ White <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2006 01:01:26 -0000
Status: RO
Content-Length: 2667

It's certainly simpler to only have a single nickname space, and use the 
same nickname for the
egress RBridge and the nexthop RBridge, and your own RBridge address. 
But I think 12 bits is
too small.

On the other hand, I don't think we need to stick with 24 bits---I think 
setting the local bit on the addresses
in the header should allow us to use 46 bits, which would enable 23 bits 
each for (egress, nexthop) and (ingress, me).

Or---if we had 46 bits to play with in both source and destination 
address, we could use, say, 16 bit
nicknames for RBridges, and have room left over for a TTL.

If we did a TTL, we'd want to take advantage of bridge learning. So, for 
instance, let's look at a packet from
ingress RBridge A, via link RBridge x. The bridges on the link will be 
learning A|x. If we throw in a TTL,
they would learn A|x|TTL. So therefore, we could put a TTL in both the 
source address and destination address.
The source address would be the real TTL. So x is forwarding a packet 
from ingress A to egress B via link
neighbor y, let's say. If the TTL from B via y is usually a certainly 
value, say n, then x should put "n" into
the TTL portion of the destination address (and decrement the TTL 
portion of the source address).

But other than mentioning this just in case people find it useful, I 
still think we should just stick with the 6 byte
shim header and have the traditional hop by hop header (with MAC address 
of transmitter and next hop).

Another thing we haven't talked about on the list (and ran out of time 
at the meeting), is Don Eastlake's
suggestion of allowing the shim header to be variable length, so that we 
can optionally put in thing like LIDs.

Radia



Russ White wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>  
>
>>d) in the Source address field in the Ethernet header, put in both 
>>the 16-bit ingress RBridge nickname, and the transmitting RBridge on 
>>that link's 8-bit nickname
>>    
>>
>
>I actually have a possible alteration that would make this much easier
>to deploy.... What about setting the nickname to 12 bits. Then, on a
>broadcast network, you would just set the originator's nickname into the
>upper bite of the l2 address, and your local nickname to the lower 12
>bits of the l2 address.
>
>Would this make sense? Would 2^12 be enough nickname space?
>
>:-)
>
>Russ
>
>- --
>[e-mail] CCIE <>< Grace Alone
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.2.2 (MingW32)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFFWPrkER27sUhU9OQRAnhGAKCOrYegMweS0lMzL4oQkuJ014/CSQCgigHQ
>NCIaRhMvL3u328TelicAToc=
>=TfCt
>-----END PGP SIGNATURE-----
>  
>



Received: from xmail10.myhosting.com (xmail10.myhosting.com [168.144.250.47]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kADN8ejY008293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 13 Nov 2006 15:08:41 -0800 (PST)
Received: (qmail 4272 invoked from network); 13 Nov 2006 23:08:25 -0000
Received: from unknown (HELO [127.0.0.1]) (Authenticated-user:[e-mail]@[65.190.218.139]) (envelope-sender <[e-mail]>) by xmail10.myhosting.com (qmail-ldap-1.03) with SMTP for <[e-mail]>; 13 Nov 2006 23:08:24 -0000
Message-ID: <[e-mail]>
Date: Mon, 13 Nov 2006 18:08:20 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Nov 2006 23:08:55 -0000
Status: RO
Content-Length: 893

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


> d) in the Source address field in the Ethernet header, put in both 
> the 16-bit ingress RBridge nickname, and the transmitting RBridge on 
> that link's 8-bit nickname

I actually have a possible alteration that would make this much easier
to deploy.... What about setting the nickname to 12 bits. Then, on a
broadcast network, you would just set the originator's nickname into the
upper bite of the l2 address, and your local nickname to the lower 12
bits of the l2 address.

Would this make sense? Would 2^12 be enough nickname space?

:-)

Russ

- --
[e-mail] CCIE <>< Grace Alone

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

iD8DBQFFWPrkER27sUhU9OQRAnhGAKCOrYegMweS0lMzL4oQkuJ014/CSQCgigHQ
NCIaRhMvL3u328TelicAToc=
=TfCt
-----END PGP SIGNATURE-----


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kADKj4eU018190 for <[e-mail]>; Mon, 13 Nov 2006 12:45:04 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Mon, 13 Nov 2006 12:44:55 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: AccFGZLErfqNdpozTHmbiw3uscaRQgAknCfgAADlJkAAFkSgMABW+FHQ
From: "J. R. Rivers" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>, "Silvano Gai" <[e-mail]>, =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kADKj4eU018190
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Nov 2006 20:45:11 -0000
Status: RO
Content-Length: 1509

Sounds like we are in agreement.

JR
 

> -----Original Message-----
> From: Caitlin Bestler [mailto:[e-mail]] 
> Sent: Saturday, November 11, 2006 7:20 PM
> To: J. R. Rivers; Silvano Gai; Guillermo Ib??ez
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] Should we optimize the common case?
> 
> J. R. Rivers wrote:
> > Hierarchical addresses assume that a single rbridge "owns" a
> > station.  With the current concept of universal mac addresses
> > with rbridge advertisement, a single station can be reached
> > through multiple rbriges... allowing effective dual homing.
> > 
> > I think that hierarchical station addresses require very careful
> > thinking. 
> > 
> > JR
> > 
> > 
> 
> There are possible deployments of rbridges where the rbridge does
> indeed "own" the end nodes, or perhaps it "owns" them in collaboration
> with a partner rbridge. Prime examples would include an "rbridge"
> implemented by a hypervisor and/or NIC to support multiple virtual
> NICs, and a bridge connecting blades on a backplane with external
> ethernet links.
> 
> But even in these environments, the individual OSs may want to
> configure their MAC addresses individually. So hierarchical addresses
> would seem to be a possible enhancement, but there is no obvious
> path to using them generally.
> 
> As an option it would probably take the form of allowing
> announcements of ranges of MAC addresses, rather than
> requiring the  rbridge to announce each individually.
> 
> 
> 
> 



Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kADAt28M022734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 13 Nov 2006 02:55:04 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 89C13ED76B; Mon, 13 Nov 2006 11:55:01 +0100 (CET)
Received: from [163.117.55.85] (unknown [163.117.55.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 859F9ED698; Mon, 13 Nov 2006 11:55:00 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 13 Nov 2006 11:55:01 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: "Sanjay Sane (sanjays)" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Nov 2006 10:55:12 -0000
Status: RO
Content-Length: 7439

Sanjay,
Thanks for your feedback. Just a few comments interleaved, because I did 
not fully understand your reasoning.

Sanjay Sane (sanjays) escribi?:
> Guillermo:
>
> We could have the end stations participate in a dhcp-like protocol to get their hierarchical mac addresses assigned to them by the edge switch. (or anyone who knows where they are attached to). The obvious benefit of the hiearchically assigned mac addresses is to obviate the need to do any mac learning for these addresses, thereby improving the scalability of mac learning/distribution in TRILL. 
>
>   
I do agree
> In spite of having such end-stations that have hierarchically assigned mac addresses, we would still need to support end-stations with globally-assigned mac addresses. Thus, we would still need the shim "encapsulation" header of the outer MAC addresses that have the ingress & egress rbridge Ids (& other rbridge-related fields in the MAC header). 
>
>   
I think that, if the ingress and egress RBridges had also "hierarchical" 
RBridge IDs (some kind of hierarchical "prefix" as RBridge ID, shorter 
than the end ports MAC addresses),  the outer MAC addresses would also 
be hierarchical, extending the benefits of hierarchy to inter RBridges 
routing.

> Thus, im, we should have 2 pairs of MAC addresses as part of addressing. Outer for rbridge-id & rbridge related fields, inner for end-stations addresses. Having the end-station addresses hierarchical in nature would mostly help in the protocol learning / MAC distribution aspect of TRILL. 
>
>   
I do not have a fixed position on whether the hierarchical MAC addresses 
belong to the end station or to the "leaf" ports, but I think that 
hierarchical MAC addresses somehow express a layer two "point of 
attachment" to network, rather than an station or interface identity. 
Other aspects regarding interoperability look simpler with hierarchical 
address assigned to switch port rather than to end node.
Regards
Guillermo
> -Sanjay
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
> Sent: Sunday, November 12, 2006 12:31 PM
> To: J. R. Rivers
> Cc: [e-mail]; Radia Perlman
> Subject: Re: [rbridge] Should we optimize the common case?
>
> Hierarchical address corresponds to the port of bridge where the station is attached, not to the station.
> Guillermo
>
> J. R. Rivers escribi?:
>   
>> Hierarchical addresses assume that a single rbridge "owns" a station.  With the current concept of universal mac addresses with rbridge advertisement, a single station can be reached through multiple rbriges... allowing effective dual homing.
>>
>> I think that hierarchical station addresses require very careful thinking.
>>
>> JR
>>  
>>
>>   
>>     
>>> -----Original Message-----
>>> From: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of Silvano Gai
>>> Sent: Saturday, November 11, 2006 8:13 AM
>>> To: Guillermo Ib??ez; Caitlin Bestler
>>> Cc: [e-mail]; Radia Perlman
>>> Subject: Re: [rbridge] Should we optimize the common case?
>>>
>>>
>>> This is something we should consider: it also gives the possibility 
>>> to introduce the LID in the hierarchy.
>>>
>>> -- Silvano
>>>
>>>     
>>>       
>>>> -----Original Message-----
>>>> From: [e-mail]
>>>>       
>>>>         
>>> [mailto:[e-mail]] On
>>>     
>>>       
>>>> Behalf Of Guillermo Ib??ez
>>>> Sent: Friday, November 10, 2006 2:37 PM
>>>> To: Caitlin Bestler
>>>> Cc: [e-mail]; Radia Perlman
>>>> Subject: Re: [rbridge] Should we optimize the common case?
>>>>
>>>>
>>>>
>>>> Caitlin Bestler escribi?:
>>>>       
>>>>         
>>>>> [e-mail] wrote:
>>>>>
>>>>>         
>>>>>           
>>>>>> Looking at this proposal, I get the impression that we are somehow 
>>>>>> building a hierarchy, which is essential to get scalability. 
>>>>>> However a more generic solution would have more widespread 
>>>>>> applicability. See the attached slide with a proposal from J. 
>>>>>> Morales for  a hierarchical structure usage of MAC addresses 
>>>>>> (using the Local half of MAC addresses (U/L bit set to Local) with  
>>>>>> hierarchical structure).
>>>>>> Lack of hierarchical Ethernet (not replacing current universal 
>>>>>> MACs) addresses is one of the main current obstacles for Ethernet 
>>>>>> scalability at Metro level.
>>>>>> Guillermo
>>>>>>
>>>>>>
>>>>>>           
>>>>>>             
>>>>> How would a local hierarchical MAC address be assigned?
>>>>> Particularly, how would one be associated with a permanent global 
>>>>> MAC address that an existing end node continued to use?
>>>>> Wouldn't this just replace one set of tables with another?
>>>>>
>>>>>
>>>>>
>>>>>         
>>>>>           
>>>> Perhaps the less disruptive implementation is to assign a local 
>>>> hierarchical port MAC address to each port of a
>>>>       
>>>>         
>>> "hierarchically capable"
>>>     
>>>       
>>>> RBridge.
>>>> The advantage of replacing many universal flat MAC addresses with 
>>>> hierarchical MACs is that aggregation of the routes to
>>>>       
>>>>         
>>> hosts is possible
>>>     
>>>       
>>>> (prefix announcement instead of host lists announcement between 
>>>> RBRidges). And it is quite close to what has just been
>>>>       
>>>>         
>>> proposed  if the
>>>     
>>>       
>>>> hierarchical MAC addresses include the RBridge nick-names
>>>>       
>>>>         
>>> and/or other
>>>     
>>>       
>>>> shared "regional" identifier.
>>>> Address assignment may (and should) be of varied types: based on 
>>>> topology discovery protocols, on spanning tree, management (OS) 
>>>> controlled, etc. It is a matter of the network owner.
>>>> Regarding handling of the two types of MAC addresses,  I see two 
>>>> mechanisms possible  in a mixed network, at ingress and
>>>>       
>>>>         
>>> egress points:
>>>     
>>>       
>>>> - MAC swapping. The hierarchical bridge port replaces the
>>>>       
>>>>         
>>> incoming MAC
>>>     
>>>       
>>>> by the hierarchically assigned local MAC. This seems mainly
>>>>       
>>>>         
>>> convenient
>>>     
>>>       
>>>> for "leaf" ports where only one host is connected. Host is not aware 
>>>> that the MAC is replaced by a hierarchical address.
>>>>  - MAC encapsulation.The "ingress" "hierarchical" bridge
>>>>       
>>>>         
>>> encapsulates
>>>     
>>>       
>>>> the frame with the hierarchical MAC addresses in the outer
>>>>       
>>>>         
>>> header. When
>>>     
>>>       
>>>> the link is shared by several hosts this looks the  most
>>>>       
>>>>         
>>> straightforward
>>>     
>>>       
>>>> approach. This is more in line with the current
>>>>       
>>>>         
>>> encapsulation scheme of
>>>     
>>>       
>>>> RBridges.
>>>> Regards
>>>> Guillermo
>>>>
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> [e-mail]
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>       
>>>>         
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>>     
>>>       
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   


Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAD5t5fR025742 for <[e-mail]>; Sun, 12 Nov 2006 21:55:06 -0800 (PST)
Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 12 Nov 2006 21:55:05 -0800
X-IronPort-AV: i="4.09,416,1157353200";  d="scan'208"; a="343853880:sNHT206584006"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id kAD5t5WC032747;  Sun, 12 Nov 2006 21:55:05 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kAD5t2OV011464; Sun, 12 Nov 2006 21:55:05 -0800 (PST)
Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Sun, 12 Nov 2006 21:55:02 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Sun, 12 Nov 2006 21:54:59 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: AccGmfUVvENAhlssQNi861QsuOZdeAATApuQ
From: "Sanjay Sane \(sanjays\)" <[e-mail]>
To: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>, "J. R. Rivers" <[e-mail]>
X-OriginalArrivalTime: 13 Nov 2006 05:55:02.0367 (UTC) FILETIME=[42A57EF0:01C706E8]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6277; t=1163397305; x=1164261305; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22Sanjay=20Sane=20\(sanjays\)=22=20<[e-mail]> |Subject:=20RE=3A=20[rbridge]=20Should=20we=20optimize=20the=20common=20c ase? |Sender:=20; bh=+Te3iAxQJWGBd+nu8AYTX0r1fk8ox2DIxpNVv8DeO38=; b=e+nFaaFPFIX5l83Fqw6JHHlJitPSHQgcDzvypyweCFygHVIVqUonunnFChQD67+iSTgkHtzb ztAxfDMFZ3+zNtuaU7Gc8Km3aMu82HqbzBFN/AkCS3f6kQ5eMD28Dry3;
Authentication-Results: sj-dkim-6; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAD5t5fR025742
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Nov 2006 05:55:20 -0000
Status: RO
Content-Length: 5937

Guillermo:

We could have the end stations participate in a dhcp-like protocol to get their hierarchical mac addresses assigned to them by the edge switch. (or anyone who knows where they are attached to). The obvious benefit of the hiearchically assigned mac addresses is to obviate the need to do any mac learning for these addresses, thereby improving the scalability of mac learning/distribution in TRILL. 

In spite of having such end-stations that have hierarchically assigned mac addresses, we would still need to support end-stations with globally-assigned mac addresses. Thus, we would still need the shim "encapsulation" header of the outer MAC addresses that have the ingress & egress rbridge Ids (& other rbridge-related fields in the MAC header). 

Thus, im, we should have 2 pairs of MAC addresses as part of addressing. Outer for rbridge-id & rbridge related fields, inner for end-stations addresses. Having the end-station addresses hierarchical in nature would mostly help in the protocol learning / MAC distribution aspect of TRILL. 

-Sanjay

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
Sent: Sunday, November 12, 2006 12:31 PM
To: J. R. Rivers
Cc: [e-mail]; Radia Perlman
Subject: Re: [rbridge] Should we optimize the common case?

Hierarchical address corresponds to the port of bridge where the station is attached, not to the station.
Guillermo

J. R. Rivers escribi?:
> Hierarchical addresses assume that a single rbridge "owns" a station.  With the current concept of universal mac addresses with rbridge advertisement, a single station can be reached through multiple rbriges... allowing effective dual homing.
>
> I think that hierarchical station addresses require very careful thinking.
>
> JR
>  
>
>   
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Silvano Gai
>> Sent: Saturday, November 11, 2006 8:13 AM
>> To: Guillermo Ib??ez; Caitlin Bestler
>> Cc: [e-mail]; Radia Perlman
>> Subject: Re: [rbridge] Should we optimize the common case?
>>
>>
>> This is something we should consider: it also gives the possibility 
>> to introduce the LID in the hierarchy.
>>
>> -- Silvano
>>
>>     
>>> -----Original Message-----
>>> From: [e-mail]
>>>       
>> [mailto:[e-mail]] On
>>     
>>> Behalf Of Guillermo Ib??ez
>>> Sent: Friday, November 10, 2006 2:37 PM
>>> To: Caitlin Bestler
>>> Cc: [e-mail]; Radia Perlman
>>> Subject: Re: [rbridge] Should we optimize the common case?
>>>
>>>
>>>
>>> Caitlin Bestler escribi?:
>>>       
>>>> [e-mail] wrote:
>>>>
>>>>         
>>>>> Looking at this proposal, I get the impression that we are somehow 
>>>>> building a hierarchy, which is essential to get scalability. 
>>>>> However a more generic solution would have more widespread 
>>>>> applicability. See the attached slide with a proposal from J. 
>>>>> Morales for  a hierarchical structure usage of MAC addresses 
>>>>> (using the Local half of MAC addresses (U/L bit set to Local) with  
>>>>> hierarchical structure).
>>>>> Lack of hierarchical Ethernet (not replacing current universal 
>>>>> MACs) addresses is one of the main current obstacles for Ethernet 
>>>>> scalability at Metro level.
>>>>> Guillermo
>>>>>
>>>>>
>>>>>           
>>>> How would a local hierarchical MAC address be assigned?
>>>> Particularly, how would one be associated with a permanent global 
>>>> MAC address that an existing end node continued to use?
>>>> Wouldn't this just replace one set of tables with another?
>>>>
>>>>
>>>>
>>>>         
>>> Perhaps the less disruptive implementation is to assign a local 
>>> hierarchical port MAC address to each port of a
>>>       
>> "hierarchically capable"
>>     
>>> RBridge.
>>> The advantage of replacing many universal flat MAC addresses with 
>>> hierarchical MACs is that aggregation of the routes to
>>>       
>> hosts is possible
>>     
>>> (prefix announcement instead of host lists announcement between 
>>> RBRidges). And it is quite close to what has just been
>>>       
>> proposed  if the
>>     
>>> hierarchical MAC addresses include the RBridge nick-names
>>>       
>> and/or other
>>     
>>> shared "regional" identifier.
>>> Address assignment may (and should) be of varied types: based on 
>>> topology discovery protocols, on spanning tree, management (OS) 
>>> controlled, etc. It is a matter of the network owner.
>>> Regarding handling of the two types of MAC addresses,  I see two 
>>> mechanisms possible  in a mixed network, at ingress and
>>>       
>> egress points:
>>     
>>> - MAC swapping. The hierarchical bridge port replaces the
>>>       
>> incoming MAC
>>     
>>> by the hierarchically assigned local MAC. This seems mainly
>>>       
>> convenient
>>     
>>> for "leaf" ports where only one host is connected. Host is not aware 
>>> that the MAC is replaced by a hierarchical address.
>>>  - MAC encapsulation.The "ingress" "hierarchical" bridge
>>>       
>> encapsulates
>>     
>>> the frame with the hierarchical MAC addresses in the outer
>>>       
>> header. When
>>     
>>> the link is shared by several hosts this looks the  most
>>>       
>> straightforward
>>     
>>> approach. This is more in line with the current
>>>       
>> encapsulation scheme of
>>     
>>> RBridges.
>>> Regards
>>> Guillermo
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>       
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>     
_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kACKV64C025721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Sun, 12 Nov 2006 12:31:08 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B4E95A6FAD; Sun, 12 Nov 2006 21:31:05 +0100 (CET)
Received: from [10.0.0.4] (39.Red-80-37-137.staticIP.rima-tde.net [80.37.137.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 979D1A6FAB; Sun, 12 Nov 2006 21:31:04 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sun, 12 Nov 2006 21:31:03 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: "J. R. Rivers" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 12 Nov 2006 20:31:18 -0000
Status: RO
Content-Length: 4451

Hierarchical address corresponds to the port of bridge where the station 
is attached, not to the station.
Guillermo

J. R. Rivers escribi?:
> Hierarchical addresses assume that a single rbridge "owns" a station.  With the current concept of universal mac addresses with rbridge advertisement, a single station can be reached through multiple rbriges... allowing effective dual homing.
>
> I think that hierarchical station addresses require very careful thinking.
>
> JR
>  
>
>   
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Silvano Gai
>> Sent: Saturday, November 11, 2006 8:13 AM
>> To: Guillermo Ib??ez; Caitlin Bestler
>> Cc: [e-mail]; Radia Perlman
>> Subject: Re: [rbridge] Should we optimize the common case?
>>
>>
>> This is something we should consider: it also gives the 
>> possibility to introduce the LID in the hierarchy.
>>
>> -- Silvano
>>
>>     
>>> -----Original Message-----
>>> From: [e-mail] 
>>>       
>> [mailto:[e-mail]] On
>>     
>>> Behalf Of Guillermo Ib??ez
>>> Sent: Friday, November 10, 2006 2:37 PM
>>> To: Caitlin Bestler
>>> Cc: [e-mail]; Radia Perlman
>>> Subject: Re: [rbridge] Should we optimize the common case?
>>>
>>>
>>>
>>> Caitlin Bestler escribi?:
>>>       
>>>> [e-mail] wrote:
>>>>
>>>>         
>>>>> Looking at this proposal, I get the impression that we are
>>>>> somehow building a hierarchy, which is essential to get
>>>>> scalability. However a more generic solution would have more
>>>>> widespread applicability. See the attached slide with a
>>>>> proposal from J. Morales for  a hierarchical structure usage
>>>>> of MAC addresses (using the Local half of MAC addresses (U/L
>>>>> bit set to Local) with  hierarchical structure).
>>>>> Lack of hierarchical Ethernet (not replacing current
>>>>> universal MACs) addresses is one of the main current
>>>>> obstacles for Ethernet scalability at Metro level.
>>>>> Guillermo
>>>>>
>>>>>
>>>>>           
>>>> How would a local hierarchical MAC address be assigned?
>>>> Particularly, how would one be associated with a permanent
>>>> global MAC address that an existing end node continued to use?
>>>> Wouldn't this just replace one set of tables with another?
>>>>
>>>>
>>>>
>>>>         
>>> Perhaps the less disruptive implementation is to assign a local
>>> hierarchical port MAC address to each port of a 
>>>       
>> "hierarchically capable"
>>     
>>> RBridge.
>>> The advantage of replacing many universal flat MAC addresses with
>>> hierarchical MACs is that aggregation of the routes to 
>>>       
>> hosts is possible
>>     
>>> (prefix announcement instead of host lists announcement between
>>> RBRidges). And it is quite close to what has just been 
>>>       
>> proposed  if the
>>     
>>> hierarchical MAC addresses include the RBridge nick-names 
>>>       
>> and/or other
>>     
>>> shared "regional" identifier.
>>> Address assignment may (and should) be of varied types: based on
>>> topology discovery protocols, on spanning tree, management (OS)
>>> controlled, etc. It is a matter of the network owner.
>>> Regarding handling of the two types of MAC addresses,  I see two
>>> mechanisms possible  in a mixed network, at ingress and 
>>>       
>> egress points:
>>     
>>> - MAC swapping. The hierarchical bridge port replaces the 
>>>       
>> incoming MAC
>>     
>>> by the hierarchically assigned local MAC. This seems mainly 
>>>       
>> convenient
>>     
>>> for "leaf" ports where only one host is connected. Host is not aware
>>> that the MAC is replaced by a hierarchical address.
>>>  - MAC encapsulation.The "ingress" "hierarchical" bridge 
>>>       
>> encapsulates
>>     
>>> the frame with the hierarchical MAC addresses in the outer 
>>>       
>> header. When
>>     
>>> the link is shared by several hosts this looks the  most 
>>>       
>> straightforward
>>     
>>> approach. This is more in line with the current 
>>>       
>> encapsulation scheme of
>>     
>>> RBridges.
>>> Regards
>>> Guillermo
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>       
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>     


Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAC3KkEN007535 for <[e-mail]>; Sat, 11 Nov 2006 19:20:46 -0800 (PST)
Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Sat, 11 Nov 2006 19:20:38 -0800
X-Server-Uuid: 05DA3F36-9AA8-4766-A7E5-53B43A7C42E6
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id E9C632AF; Sat, 11 Nov 2006 19:20:37 -0800 (PST)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id C258B2AE; Sat, 11 Nov 2006 19:20:37 -0800 (PST)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EKZ02666; Sat, 11 Nov 2006 19:20:28 -0800 (PST)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id AFE9E20501; Sat, 11 Nov 2006 19:20:28 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sat, 11 Nov 2006 19:20:25 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: AccFGZLErfqNdpozTHmbiw3uscaRQgAknCfgAADlJkAAFkSgMA==
From: "Caitlin Bestler" <[e-mail]>
To: "J. R. Rivers" <[e-mail]>, "Silvano Gai" <[e-mail]>, "=?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?=" <[e-mail]>
X-WSS-ID: 69484C8C39O4416327-01-01
Content-Type: text/plain; charset=iso-8859-1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAC3KkEN007535
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 12 Nov 2006 03:21:03 -0000
Status: RO
Content-Length: 1120

J. R. Rivers wrote:
> Hierarchical addresses assume that a single rbridge "owns" a
> station.  With the current concept of universal mac addresses
> with rbridge advertisement, a single station can be reached
> through multiple rbriges... allowing effective dual homing.
> 
> I think that hierarchical station addresses require very careful
> thinking. 
> 
> JR
> 
> 

There are possible deployments of rbridges where the rbridge does
indeed "own" the end nodes, or perhaps it "owns" them in collaboration
with a partner rbridge. Prime examples would include an "rbridge"
implemented by a hypervisor and/or NIC to support multiple virtual
NICs, and a bridge connecting blades on a backplane with external
ethernet links.

But even in these environments, the individual OSs may want to
configure their MAC addresses individually. So hierarchical addresses
would seem to be a possible enhancement, but there is no obvious
path to using them generally.

As an option it would probably take the form of allowing
announcements of ranges of MAC addresses, rather than
requiring the  rbridge to announce each individually.






Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id kABMHgZw023374 for <[e-mail]>; Sat, 11 Nov 2006 14:17:42 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-11.tower-128.messagelabs.com!1163283461!4911802!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [144.189.100.105]
Received: (qmail 25565 invoked from network); 11 Nov 2006 22:17:41 -0000
Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-11.tower-128.messagelabs.com with SMTP; 11 Nov 2006 22:17:41 -0000
Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id kABMHbhb013920 for <[e-mail]>; Sat, 11 Nov 2006 15:17:41 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id kABMHaE0017614 for <[e-mail]>; Sat, 11 Nov 2006 16:17:37 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 11 Nov 2006 17:17:35 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Presentations at IETF San Diego TRILL Meeting
Thread-Index: AccF3zBuQTZI+jamTvy22RfVX9Nttg==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kABMHgZw023374
Subject: [rbridge] Presentations at IETF San Diego TRILL Meeting
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 11 Nov 2006 22:17:53 -0000
Status: RO
Content-Length: 879

Hi,

The presentations at the TRILL WG Meeting in San Diego are linked off
the 67th IETF Meeting Materials page at 
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
.
For your convenience, I will include these links here but they probably
won't be good forever as these files will be converted to html.

Agenda and Milestones:
http://www3.ietf.org/proceedings/06nov/slides/trill-0.ppt

Draft-ietf-trill-prob-01:
http://www3.ietf.org/proceedings/06nov/slides/trill-4.ppt

An Encapsulation for TRILL:
http://www3.ietf.org/proceedings/06nov/slides/trill-2.ppt

TRILL Remaining Issues:
http://www3.ietf.org/proceedings/06nov/slides/trill-1.ppt

Rbridge Protocol Extensions:
http://www3.ietf.org/proceedings/06nov/slides/trill-3.ppt

Note that, due to limited time, the last item listed above was not
actually presented during the WG meeting.

Thanks,
Donald



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kABKBdDo021582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Sat, 11 Nov 2006 12:11:39 -0800 (PST)
Received: from [127.0.0.1] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kABKBSjA028685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 11 Nov 2006 12:11:28 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sat, 11 Nov 2006 12:11:27 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBBBA5BCAF7ADC7F85A028F8E"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 11 Nov 2006 20:11:45 -0000
Status: RO
Content-Length: 1652

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



[e-mail] wrote:
> This is an extremely cute proposal, and it works. Let me explain Sanjay=
's proposal in different words, in case
> it doesn't sink in the first time one sees it.
>=20
> He is proposing using the shim header that looks like an Ethernet heade=
r, with SA=3Dingress RBridge MAC R1
> and DA=3Degress RBridge MAC R2, but solving the two problems
> brought up at the meeting which were:

I'm very confused by all these proposals.

This is a LOT of complexity (either in figuring pt-pt links in the
original proposal, or assigning subnetted MAC addresses here) all to
save - at most - 4 bytes (the rbridge tags in the shim).

When it comes to optimization, we can consider:

	- performance on the link (extra bytes)
	- fragmentation (none of these help that, since
	all make the packet at least one byte larger)
	- complexity of management / configuration

IMO, the complexity of these alternatives isn't worth 4 bytes.

Joe


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

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

iD8DBQFFVi5vE5f5cImnZrsRAgXGAJ4jllT2CoA8jaDub0Mx8wRsBQ0hqgCbB4nV
MljDGqzNDpuU4GKG3izWTPM=
=olGt
-----END PGP SIGNATURE-----

--------------enigBBBA5BCAF7ADC7F85A028F8E--


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kABGqHhT001324 for <[e-mail]>; Sat, 11 Nov 2006 08:52:17 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Sat, 11 Nov 2006 08:39:09 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: AccFGZLErfqNdpozTHmbiw3uscaRQgAknCfgAADlJkA=
From: "J. R. Rivers" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>, "Caitlin Bestler" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kABGqHhT001324
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 11 Nov 2006 16:52:47 -0000
Status: RO
Content-Length: 3994

Hierarchical addresses assume that a single rbridge "owns" a station.  With the current concept of universal mac addresses with rbridge advertisement, a single station can be reached through multiple rbriges... allowing effective dual homing.

I think that hierarchical station addresses require very careful thinking.

JR
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Silvano Gai
> Sent: Saturday, November 11, 2006 8:13 AM
> To: Guillermo Ib??ez; Caitlin Bestler
> Cc: [e-mail]; Radia Perlman
> Subject: Re: [rbridge] Should we optimize the common case?
> 
> 
> This is something we should consider: it also gives the 
> possibility to introduce the LID in the hierarchy.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: [e-mail] 
> [mailto:[e-mail]] On
> > Behalf Of Guillermo Ib??ez
> > Sent: Friday, November 10, 2006 2:37 PM
> > To: Caitlin Bestler
> > Cc: [e-mail]; Radia Perlman
> > Subject: Re: [rbridge] Should we optimize the common case?
> > 
> > 
> > 
> > Caitlin Bestler escribi?:
> > > [e-mail] wrote:
> > >
> > >> Looking at this proposal, I get the impression that we are
> > >> somehow building a hierarchy, which is essential to get
> > >> scalability. However a more generic solution would have more
> > >> widespread applicability. See the attached slide with a
> > >> proposal from J. Morales for  a hierarchical structure usage
> > >> of MAC addresses (using the Local half of MAC addresses (U/L
> > >> bit set to Local) with  hierarchical structure).
> > >> Lack of hierarchical Ethernet (not replacing current
> > >> universal MACs) addresses is one of the main current
> > >> obstacles for Ethernet scalability at Metro level.
> > >> Guillermo
> > >>
> > >>
> > >
> > > How would a local hierarchical MAC address be assigned?
> > > Particularly, how would one be associated with a permanent
> > > global MAC address that an existing end node continued to use?
> > > Wouldn't this just replace one set of tables with another?
> > >
> > >
> > >
> > Perhaps the less disruptive implementation is to assign a local
> > hierarchical port MAC address to each port of a 
> "hierarchically capable"
> > RBridge.
> > The advantage of replacing many universal flat MAC addresses with
> > hierarchical MACs is that aggregation of the routes to 
> hosts is possible
> > (prefix announcement instead of host lists announcement between
> > RBRidges). And it is quite close to what has just been 
> proposed  if the
> > hierarchical MAC addresses include the RBridge nick-names 
> and/or other
> > shared "regional" identifier.
> > Address assignment may (and should) be of varied types: based on
> > topology discovery protocols, on spanning tree, management (OS)
> > controlled, etc. It is a matter of the network owner.
> > Regarding handling of the two types of MAC addresses,  I see two
> > mechanisms possible  in a mixed network, at ingress and 
> egress points:
> > - MAC swapping. The hierarchical bridge port replaces the 
> incoming MAC
> > by the hierarchically assigned local MAC. This seems mainly 
> convenient
> > for "leaf" ports where only one host is connected. Host is not aware
> > that the MAC is replaced by a hierarchical address.
> >  - MAC encapsulation.The "ingress" "hierarchical" bridge 
> encapsulates
> > the frame with the hierarchical MAC addresses in the outer 
> header. When
> > the link is shared by several hosts this looks the  most 
> straightforward
> > approach. This is more in line with the current 
> encapsulation scheme of
> > RBridges.
> > Regards
> > Guillermo
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kABGDLV0022140 for <[e-mail]>; Sat, 11 Nov 2006 08:13:21 -0800 (PST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Sat, 11 Nov 2006 08:13:08 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: AccFGZLErfqNdpozTHmbiw3uscaRQgAknCfg
From: "Silvano Gai" <[e-mail]>
To: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>, "Caitlin Bestler" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kABGDLV0022140
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 11 Nov 2006 16:13:47 -0000
Status: RO
Content-Length: 3021

This is something we should consider: it also gives the possibility to introduce the LID in the hierarchy.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Guillermo Ib??ez
> Sent: Friday, November 10, 2006 2:37 PM
> To: Caitlin Bestler
> Cc: [e-mail]; Radia Perlman
> Subject: Re: [rbridge] Should we optimize the common case?
> 
> 
> 
> Caitlin Bestler escribi?:
> > [e-mail] wrote:
> >
> >> Looking at this proposal, I get the impression that we are
> >> somehow building a hierarchy, which is essential to get
> >> scalability. However a more generic solution would have more
> >> widespread applicability. See the attached slide with a
> >> proposal from J. Morales for  a hierarchical structure usage
> >> of MAC addresses (using the Local half of MAC addresses (U/L
> >> bit set to Local) with  hierarchical structure).
> >> Lack of hierarchical Ethernet (not replacing current
> >> universal MACs) addresses is one of the main current
> >> obstacles for Ethernet scalability at Metro level.
> >> Guillermo
> >>
> >>
> >
> > How would a local hierarchical MAC address be assigned?
> > Particularly, how would one be associated with a permanent
> > global MAC address that an existing end node continued to use?
> > Wouldn't this just replace one set of tables with another?
> >
> >
> >
> Perhaps the less disruptive implementation is to assign a local
> hierarchical port MAC address to each port of a "hierarchically capable"
> RBridge.
> The advantage of replacing many universal flat MAC addresses with
> hierarchical MACs is that aggregation of the routes to hosts is possible
> (prefix announcement instead of host lists announcement between
> RBRidges). And it is quite close to what has just been proposed  if the
> hierarchical MAC addresses include the RBridge nick-names and/or other
> shared "regional" identifier.
> Address assignment may (and should) be of varied types: based on
> topology discovery protocols, on spanning tree, management (OS)
> controlled, etc. It is a matter of the network owner.
> Regarding handling of the two types of MAC addresses,  I see two
> mechanisms possible  in a mixed network, at ingress and egress points:
> - MAC swapping. The hierarchical bridge port replaces the incoming MAC
> by the hierarchically assigned local MAC. This seems mainly convenient
> for "leaf" ports where only one host is connected. Host is not aware
> that the MAC is replaced by a hierarchical address.
>  - MAC encapsulation.The "ingress" "hierarchical" bridge encapsulates
> the frame with the hierarchical MAC addresses in the outer header. When
> the link is shared by several hosts this looks the  most straightforward
> approach. This is more in line with the current encapsulation scheme of
> RBridges.
> Regards
> Guillermo
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAAMbGrD009794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 10 Nov 2006 14:37:18 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0A1C2A51FF; Fri, 10 Nov 2006 23:37:16 +0100 (CET)
Received: from [10.0.0.4] (39.Red-80-37-137.staticIP.rima-tde.net [80.37.137.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 74D24A4DD4; Fri, 10 Nov 2006 23:37:15 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 10 Nov 2006 23:37:13 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Caitlin Bestler <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 10 Nov 2006 22:37:36 -0000
Status: RO
Content-Length: 2376

Caitlin Bestler escribi?:
> [e-mail] wrote:
>   
>> Looking at this proposal, I get the impression that we are
>> somehow building a hierarchy, which is essential to get
>> scalability. However a more generic solution would have more
>> widespread applicability. See the attached slide with a
>> proposal from J. Morales for  a hierarchical structure usage
>> of MAC addresses (using the Local half of MAC addresses (U/L
>> bit set to Local) with  hierarchical structure).
>> Lack of hierarchical Ethernet (not replacing current
>> universal MACs) addresses is one of the main current
>> obstacles for Ethernet scalability at Metro level.
>> Guillermo
>>
>>     
>
> How would a local hierarchical MAC address be assigned?
> Particularly, how would one be associated with a permanent
> global MAC address that an existing end node continued to use?
> Wouldn't this just replace one set of tables with another?
>
>
>   
Perhaps the less disruptive implementation is to assign a local 
hierarchical port MAC address to each port of a "hierarchically capable" 
RBridge.
The advantage of replacing many universal flat MAC addresses with 
hierarchical MACs is that aggregation of the routes to hosts is possible 
(prefix announcement instead of host lists announcement between 
RBRidges). And it is quite close to what has just been proposed  if the 
hierarchical MAC addresses include the RBridge nick-names and/or other 
shared "regional" identifier.
Address assignment may (and should) be of varied types: based on 
topology discovery protocols, on spanning tree, management (OS) 
controlled, etc. It is a matter of the network owner.
Regarding handling of the two types of MAC addresses,  I see two 
mechanisms possible  in a mixed network, at ingress and egress points:
- MAC swapping. The hierarchical bridge port replaces the incoming MAC 
by the hierarchically assigned local MAC. This seems mainly convenient 
for "leaf" ports where only one host is connected. Host is not aware 
that the MAC is replaced by a hierarchical address.
 - MAC encapsulation.The "ingress" "hierarchical" bridge encapsulates 
the frame with the hierarchical MAC addresses in the outer header. When 
the link is shared by several hosts this looks the  most straightforward 
approach. This is more in line with the current encapsulation scheme of 
RBridges.
Regards
Guillermo



Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAALitfC019967 for <[e-mail]>; Fri, 10 Nov 2006 13:44:55 -0800 (PST)
Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Fri, 10 Nov 2006 13:44:45 -0800
X-Server-Uuid: 9206F490-5C8F-4575-BE70-2AAA8A3D4853
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 6C8792AF; Fri, 10 Nov 2006 13:44:45 -0800 (PST)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 480212AE; Fri, 10 Nov 2006 13:44:45 -0800 (PST)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EKU51625; Fri, 10 Nov 2006 13:44:36 -0800 (PST)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 166CF20501; Fri, 10 Nov 2006 13:44:36 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 10 Nov 2006 13:44:35 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: AccE0dHoDiPgiPBWSSWHiviE0HoaDgAPwZqw
From: "Caitlin Bestler" <[e-mail]>
To: "=?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?=" <[e-mail]>, "Russ White" <[e-mail]>, [e-mail], "Radia Perlman" <[e-mail]>
X-WSS-ID: 694A2D473ES3875971-01-01
Content-Type: text/plain; charset=iso-8859-1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kAALitfC019967
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 10 Nov 2006 21:45:10 -0000
Status: RO
Content-Length: 870

[e-mail] wrote:
> Looking at this proposal, I get the impression that we are
> somehow building a hierarchy, which is essential to get
> scalability. However a more generic solution would have more
> widespread applicability. See the attached slide with a
> proposal from J. Morales for  a hierarchical structure usage
> of MAC addresses (using the Local half of MAC addresses (U/L
> bit set to Local) with  hierarchical structure).
> Lack of hierarchical Ethernet (not replacing current
> universal MACs) addresses is one of the main current
> obstacles for Ethernet scalability at Metro level.
> Guillermo
> 

How would a local hierarchical MAC address be assigned?
Particularly, how would one be associated with a permanent
global MAC address that an existing end node continued to use?
Wouldn't this just replace one set of tables with another?





Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAAE6Y2B006455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 10 Nov 2006 06:06:35 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E2D1EA5010; Fri, 10 Nov 2006 15:06:32 +0100 (CET)
Received: from [163.117.55.85] (unknown [163.117.55.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id A3B84A4E93; Fri, 10 Nov 2006 15:06:32 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 10 Nov 2006 15:06:31 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Russ White <[e-mail]>, [e-mail], Radia Perlman <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------010603090201000407000004"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 10 Nov 2006 14:07:02 -0000
Status: RO
Content-Length: 31515

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

Looking at this proposal, I get the impression that we are somehow 
building a hierarchy, which is essential to get scalability. However a 
more generic solution would have more widespread applicability. See the 
attached slide with a proposal from J. Morales for  a hierarchical 
structure usage of MAC addresses (using the Local half of MAC addresses 
(U/L bit set to Local) with  hierarchical structure).
Lack of hierarchical Ethernet (not replacing current universal MACs) 
addresses is one of the main current obstacles for Ethernet scalability 
at Metro level.
Guillermo

Russ White escribi?:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>   
>> a) assign 16-bit nicknames to all the RBridges (as we were going to
>> do with the short shim header)
>>     
>
>   
>> b) assign, say, 8 bit link-local nicknames to all the RBridges on a
>> link (this can be done through the IS-IS Hello protocol quite
>> easily--I'd suggest doing it by having the Designated RBridge assign
>> the values, but it could also be done by having each RBridge choose a
>> nickname and back off if someone with a better ID has chosen that 
>> nickname)
>>     
>
>   
>> c) in the Destination address field in the Ethernet header, put in
>> both the 16-bit egress RBridge nickname, and the nextop 8-bit
>> nickname
>>     
>
>   
>> d) in the Source address field in the Ethernet header, put in both
>> the 16-bit ingress RBridge nickname, and the transmitting RBridge on
>> that link's 8-bit nickname
>>
>> So---bridges will never incorrectly learn the location of any
>> RBridges, because no matter where a packet from R12 arrives into the
>> link, the bottom bits will be specific to the RBridge on the link
>> that injected the packet.
>>
>> And positive learning can happen as well. Suppose there are n total
>> RBridge nicknames in use in the whole campus. Suppose there are 5
>> RBridges on the link. The bridges inside the link will see 5*n
>> RBridge addresses as a result of this proposal. In other words, if
>> the RBridge nicknames are 1, 2, ... 517. and there are 5 RBridges on
>> the link, the MAC addresses the bridges will see are: {1 - 517} | {1
>> - 5}
>>
>> In Sanjay's picture, if R4 wants to direct a packet towards R2 rather
>> than R3 for egress R1, it encodes R2's nickname into the "neighbor's
>> nickname" portion of the egress RBridge field.
>>
>> Anyway---something for people to think about.
>>     
>
> I like this proposal.... It solves many of the problems we've been
> looking at, with a single "shim/ethernet" header. We could make the
> total header the size of an ethernet header plus the trailing TTL and
> reserved space, making the size come out right for easy processing, etc.
>
> Should we replace the current shim header text with this?
>
> :-)
>
> Russ
>
> - --
> [e-mail] CCIE <>< Grace Alone
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFVH4kER27sUhU9OQRAlEXAKDlFkl7a93xVCs/aKRKdIc8/IihlwCg0eII
> TvOzBPbanKhybn8xTutKNtE=
> =mbtr
> -----END PGP SIGNATURE-----
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

--------------010603090201000407000004
Content-Type: application/pdf;
 name="hierarchicallocalmacaddresses.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="hierarchicallocalmacaddresses.pdf"

JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURl
Y29kZT4+CnN0cmVhbQp4nO1dSZMlt42+1694x1czUU8kwdU3WVJ77LG8dLdjFtkHW17aHmkm
bHlCMf9+8DEzsbBeVW/VCh/kDoce+BEkk0SCAIhk/fUULjGdAv4dP778+uaj5+30p29uZvHp
+Y/2H3/7081fb/qF8L9ZYH9/+fXphy+ZcZzGZdTTyz8yU7yEEEo73UWuUChd+okKXSqdXn59
88X5s9t8aSmnfP77LVfNo5xf3aZLGDW08x/k199u7/IlltHP/30FFdbT8ePZ7R1dYgx0/q3U
+t2V1v58Wy6pVMrnL2/vyqVRz01beX57Fy65p5jK+X+E+3/v96vN6PD+JL+kvV+fpWN9bh2q
7e7Xt7fEkzXG+M3Ln9xQDZfUKs/gy9/fnMfty7/cfPby5pc3sV9aOX17E09/4f//+SZcSoij
8Grc+8ErWAsarKfR8mXEfPpaSniUKDp9dfOC24nbglcqW/XSjup7SQ2zaFZ/vEt+QNvfJK92
llMapqdJum4OMXy99MV4SnGRv7rJX4yQvxgrz+Ymfz/D2oxQB4vTHf+slX/+HQsRcyOq529v
7/ol59qJRYCLaw+1swTFS6Ie0vm/lO0EvPBwMp2/0eIv9edv9edXprIp/t3WR6RcWaq0iq1u
y/8Osa1h5Hz+PxYpGrmV8w+00I7plW8ba5lbtw++P5Yf6VbYeC7Mk7x6YJyvf9iTf/B6KanH
dP69aXD/nWSi0bkZ5jdXf7oKpVS8ONtb0i4t9MbvCdWWT7GEKX9fgyynwm/cIWUsPPn05Tf8
n3T65sv/vkkx9lManVCBUj3l1E9/+8PNH/+JJffbm376nP/7E5ayv6Bqu1bVNlq0UX76ojXL
3uhs5ApkG2mmka7d9UauEQelrZFH3lXW6xEvUmQNCL6UEndOTZ4W/2alULnS9mLulepRiS4l
J6ijwBMTeGKmXio88shTvc05k4XJVkQFbPioFs+BPM6aw+EUFrxEh5e+4G04vFePl+DGV+LS
fyHXf8lxwWtyeB0LPoLDR/N4ja7/mpb5qdnNTy3L+Gpz42Mt5fEW3Pzw+7Dgyc1Po6X/Vlz/
rS79t+76b2OZH37FLd7j0n8n1z9vwwvu5aev8tO9/IyQPD4SOXyVn+HlZ6zyM7z8jO77TyHY
/lNY5CcFlZ/QQCo/y6LFWVIXvHSHl7TgFB2e8oIHsjiNpX9qrn+qS/+UXf+Uw4Kn4PBICz77
l/mngPHF6vA4ZP2A8/z2BZf13/AaFlzkZ8OJFlzkb8ODH1/sIr8T760teHHj62XpvyfXf09p
weX9m3gb2eOtuf5bXeanZdc/G6oLHt38tBg9XkX/TLz2ZX5qdfNTyzI/ldz4alr6r8H1X8My
P6W5+SltmZ9S3PyUvMxPSa7/sspP9vKTV/nJXn5yXeYnZzc/eZWf7OUnr/JDXn6o2f479j95
vm07NM9PxeGZFrySw1tY8BEcPrrHcxwWz6kueG4OL0v/uWWH9+jxEpLF9+1e5tcaSfzwUF55
Tm5iM4FKoc02iYfdsNsMrHN60jUrIK1Ohgm1bSI7zuRweA4xGpzJ5PCSQjY4k2ZNeSg5RdHp
rFOZXLyRN/KF2RupizNCuzPC7wA7JqmMS9694V/AKg8lsQn7HNZsY+sss68opR/fxgIX8fw5
w/HCZtQ4/1Br/vS2XXhrrJMnhsRKt50/VfxjdmZGDBe2+l/YRhurqxAiLObEL1o+MV+Cr/nF
+aU0+R+3PIFsCNAxTGb9TH59dJtY5kOg2Qj7V731E7tO/DbMdtzQdp6f6cgulp21wYV33BP7
M/soPtGaZmI+sQO/Y9m6BLaC+4Utb/jJL+Anhwuxvx3mWPbyZyiHE8KbziyPdZZ/Kn71F9Pc
/Q0v0u83O3bKY+3VymPtIg9PIAaFd5SwO6VuxfYF13X42D81s7MDtYVu5lz9+BYlmZ0/M78b
OxWZ/tx1Jtv57rZcCosGz81R7/mVQRip++y21iYu1hf7ZIkL4F2j3vG2Tw3LWw9PXQnbW595
7muzrz7Wi0UBrsn6g71/bopObPzvL27ijRykvLiJDTGLs6Gx4HHBx4In136itX0aDs8rnj1e
VrxGh9e1/+b5+SXyeO8O7ws/Bdc+9h6PR8dPceVPHk9twf3zU17x0hzOku1wrB/1Fs36MZnc
+hkc6+fxuOBjwZNrH+vncRoOzyuePV5WvEaH17X/5vlbX/DeHd4Xfgqufayfx6Pjx/p5PHk8
tQX3z4/183hpDuf1czjWL42WzPoxSW79DI7183hc8LHgybWP9fM4DYfnFc8eLyteo8Pr2n/z
/K0veO8O7ws/Bdc+1s/j0fFj/TyePJ7agvvnx/p5vDSHw8Cw+Fy/QsGuX6Ho10/xuX4Ojws+
Fjy59uf6OZyGw/OKZ4+XFa/R4XXtv3l+rJ/De3d4X/gpuPbn+jk8Ov65fg5PHsf6Odw//1w/
h5fm8GkgKi5xOLYam3gdsfRTG0f8711ObNg82Uw1NU/SZp7wE16wZZOe2fx0hmd56dkM+Pk0
NgoVmGhsjtc0iO0FNmZaaDBIa0RzadoqOV4qBPBuXNJuFn58S+XSRqxs9PAuwfZNm1ZGu/BK
ENsybKywM9YLGzMHbgpf4EAljZAqWzgRP2uF5YKRxBhN8zvcs2XfRs++M7fecGiwHbdsUWO2
SlKDOMau6rSCVHWYIwpK9/i+XBu6exlf+cpfzUjte7C/eiOzM4WHjuJwnJTY6d4OQs7/CduX
6yepP496KqyvzTqOe42w1rg7qnxx/vfbO7ZMK8/9u/48vXcLb9PF8w/003Tx+Qf6abp4+YF+
frgu5CUT+5+da0QZhxgWMyipUTIuCPAhBK/TpTB4BR7FsETQNEaDI2wak/BjY4nJ4DlzAQl/
RoCCDE7s8sUsOKG5bDbW+e4WwRGFjcXg2DhilY0XUeJYDY6dNKphjChxtBs3NqbYD/4wpmJS
PAzgQ3BsbHGopgrY+FNQHMc3weAto2AceEP1aPBaUCB4BZ4Mjo0rJcELqpPBoUkTCZ6h2/QU
JQVsjLz7HzihuWJxDFhUZUioXg0Ow4N9csFRvRkcUfjUBEcgKnWDw6VPXXAErdPQKOZA2Jz3
jw1nkquTiXKO3lBwRKwGgvoUDQ7DhCRKOxqqm4jVaDxgkojXgGFD5pSCd1YUCF4mbvgLD5iy
4mguGzxjwBLFHhnVi8EJA66CUwapEbcBw4aa4BB3aoYflhBJhGRgsyIThR0wHPWUb8CwomFw
yPceVp14AKl4Z/uG5eXAOwzXrBE5BPC5IAneE0jDD4Wyn6wCh3xnMvwVeD4igr2iOXMK1aFQ
chF+GGa5WBwDqsKPQ5NsovgdCiVLlL9D3LM5ZehQKLkrjubMKWWHQsnjOEXpCdWHwaFQ5GSb
SdjhweBh7vfCj1OYEjXi2QYMVzmlaQPVk/K3zVIWvE871fBDoZR8RMnbNLxNFL81HnApwg91
XswpQ4NC0VPUNu38avihUEoTHOJezClgg0IpXXCo89INPxRKGUdEuEGdF3MK06BQahB+GO41
WJwHXCWi3GZA0JzyNaSd1CQ41HlNhh8KpZLiqG5OGSoUSpVTiAp1XrPBO3A5JalQ5/YUuEKh
1Cr8DdVNlL5CodR6nMJUiHtthh8KpXbhhzqv3fBDodQu/FDndRgcCqUF4Ydj18wpLD8rCoQf
6tyeUtVUUHDo1wp13swpWoVC0VPqCnXejGNUoVD2YzHgUOfNntJjw2xZTnGhzluxOAZ87C9s
PqA5c8pYoFCankJ3VG+GHwqlNeGHOm/2FB4KpXXhhzpvZn8pUChN9pdSuHo3+0uBp9g1SwHq
vAdz4kE4MdETC6jzbk9EoFD0RKWkecBicCiUTnqKPUDuOM7bmDTbNb9AJ9Zmx3bJrwfIqjjb
Z7kd2xWTFaSJA1bwJ+Gv4E+Gv4A/Co6wYouGv4A/KA7+YPgRh63jMCciq2MmLZ65QLZ7tuRA
GhxxztqEn8Cv6hqmIRdUxcFfLX/ggiJ4QnPF8LO4c4GYgzhgqtni4BdzKSJOW8ngEfwax4no
X7c7LgB/UnMS/NHw83bABcIf0H8w/Igj16D83FzR7ZoNxYoCNUd5OKVbPKLg4Ic5mouaC1wA
folThQ7+avj5deMC5Uf/xfCzuuMC4W9oLlsc/GKuh4bhkMEhkIWEv6J/Nbe4APzHdsgk+KPh
h0CWKPyIc5do+CGfJQg/5LMEg0Mgs7g7AXH0PCzO/LkLP8Q1W3MVAinmxDSXmbQ4+Kvws3WR
szOXeUF4gg4ccf5szW0IZM7Cj2ORbM11yGcm4cexQrbmfgT/YY4hHwakwSGQOQo/zimydTdw
Yivm4DTHmbQ4DlbGYe6MgWMJsx0hTTVTF3NyZJBkcPCrOTvPUcx2OCCQVIW/g79aHPxqTs9j
G7MdDwgkZcXRXLY4zmlIcTSn7mZEYIXnU3DIJyWLgz8qDv5o8O3gRd2BIscyO47UvWHdBSYN
DoFMsl2NPBMai8F5QVJTHOflxhwbEMgk2yW8CyYtDn7Zbgehf2MOwt3IKQsO+Uy6vyCfC6mH
is9MRMMPhZmS4BH9G3N2QCBTVDzJef/ujoBfzJUR0H+wOAtEHIoTSGPOQyCjmEudrWsmjTkO
gYxNcfBbdwACGcVc6zj2i9W7O1nCCUyC37ojkM9YBId8xmzdoYICxdGcdYcgkJEExzlltO4U
BDKKuQt3KcdocfCLudwL+K07B/mMQXHmD2MYPKJAcW4uGHeyQyBDFzwjwcO4o3C3uCAJDn6T
lNkhkEHcjU7gLxZPKFAc/Cbpq0Mgg7g7Hbm6wbjjHfIZSHEMx7jzfSaoiLvVIZ8hRYOjf3XX
IvhNOKFDIENQdw78wfCzQNJQdzEkkMoPd49GV3evgYwGz1wg7ipOF2iYpK2Gc8wh7i7cQSYN
P855R1Ec/RfDj3PSIe423EUmDX9D/6Q4miPLH7hA3P1WwZ+MO1bBHxUHv0kAagX9S7iBDX+Q
hp8VJmlSaWP5ZNLy42BY9pc2j43N/gJ3lLrsL3BHmTTu4Dx4lv2lzWNZs780Ar/sL43AX6w7
i3NiCfe0ec5t9he2pblA9peW8Dhk3VnwizsA75ZJ405H8Mv+wqY3SMMfwS/7S5vH8iaBqrF8
krozbJqDtO4wC4S6Q3CHmVT+CoFUd4pNd5AW5wVVdwzuMpMGh0CqO8emPchqcPCLO1ghn8Z/
YVXLAmHcyYbmyOLgV3e0gd/sL3C3ybizkM8WLQ5+dYcr+IPqX7jjZNxpHMvXYXEWCOOOs7lJ
JiFp+udk3Hk2N8n4L1zAC2rCAZDPavaXCoE04QQCv0mKrhBIE44g9J8tHlAg/AnNmaRVuPuk
4ZCa0FyyeESB4mjO7C8VAqnhGIQDqBp3uEIgNZxTkSdSzP5SIZAaDkK4gEq3eESB8iNX0ewv
iB+QhqMK5NMl/UMgzUcByHMpLpxQZ/LjgXf0X3y4gTScxp4USINDIDUcVxqas0ntkE8N5yEc
waQJV0AgNRxYKvijxdG/hBML0l6K2V8KFKaGIwvkM9ukfwikhjPZUwNpcMinhkMR3WDSJGhC
IDWcWjKas0mnkE8NxxYCf7E4+GV/KZDPnA0OgdRwMMIhZPyXmfFJGk4uSCvKZn8pEEgNRyNc
wqTick5ft41wPjlS4ysld07/nkmkxK8QWwo882wwzdP5F5Je+W/4srBV3oX3nEDeb0weocmp
/Bf9qTVN9uCPbht0x5gJf+HS4H4UzZz84jrXp9da/eRqbuPduPDrUWieyLNsZCTAmjTHcIls
bPOeaPr89XkmLdYxzENpcqnJXzRpi1cH+rHNoDUJC9xXQdzOdGq4dKif3svV5f7lC85uUgqc
VFAWqSi8ek8vFcjG9FKRrokFUkXfTCyWpFKIRdclekgsFq57YgH8TcSiUF3E4o4t4umbXhcL
l64qz6+P+nxZzNnBL27v0hzVMIU/1aHYOZNCGbN5zhNSmmc6c79kGDiPiNHs5L4YpYfk6FsW
IWjQclhQOHoCqRE0BJSpHBr0wPcdfkPr4VC4yltqynuwIzWFff0Cj/sIYGbEO5IJsGGDOTxq
wY949I4e+txV3of37uwYnuQdvEG6Mcm3h1u6alYzeUtXVXymqzo8LvhY8OTan+mqDp/bnOJ5
xbPHy4rX6PC69t88P6xeh/fu8L7wU3Dtz3RVh0fHP9NVHZ48jnRVh/vnn+mqDp92h+KQQ4Mb
hYvjx7EZAPgIhZ2h90uXe0jzsgxOW6zIRx3frerdvnH4DlRvuOD8nqf1uu69/v3Kj6SxHzPO
y5ZbMz1gqKzBejIaddmRyzz6+gCqNCanSk2wa1NvMWSPO10Yi9OFkpkkqvTd2KGrcC1HZaae
+UcfudAUaSozZrr5XIT4IR0i3efn13+BbPI/Fu2jbtvqpqPu1nhDIB5fkIyKsCDazgh/ifsN
z0JOw77aSUnO2SrT4fw53jkB8m3HEzZ7TAy/8qyu8R17Gol9MpmYesQGd8bjKNuhX4kCuHQ2
zPs2sR2xZx3lmGdzR2zn4E8yLBxEyjNY3tn6E7Y2n5ntnRLYebv/AyrsYfRN9RpiZE6xlU2x
ZXZuAz6ay6ysNsX2yS233pDqcP6V/sSHQXXJpN3FUNTxe46k8ftwgnNL8S1HIjdBhPlt0q75
4Uji+DgcElPm4eohefiiMcsXnTupsZytoB6++kaWLmKMxsT13EgyiQHyjmaEvOsRctxJEkGZ
Hy4dEcSd1IDmViAHxhtZjoDP1liWJ5rkfvr11Y25XYXadm56NDNJSUMiRBXMKzlJcyq0VU9H
EthGLtWXxsyZrc5Eq9UNAmQ+bE9C6CJTdqQbRK1uEPMkTQeB6ktjZhD6QZoTkDrPj4/jVII1
kU32jZgOCLnJQTgM4EUjX8VfGA05O6pHXgMhDSabuBa1qTIVxzG5jXu926v2QI74lNp0QpoW
lZkm/s/7p5PY+uEYl/37zvOdfDtpJg05HkUWouLIo6oLYCYNhx31CMYwOZMVDjmp85EP295V
/uq4ieV9mnjll/0QQkRwNQOBFyZIwoYzLQmhYn7M8uCSX8HdkqOjGmToaS6pqpeGTcDgPTj8
fReYX4CCg4XhFpjKQArgtQXmAc/cDrlEZ6aiqLkEvxDTmwSfqSaHIqszFeaw0V1lu5zv3MS2
S4aaYNbw/oe0JHa7dpuJ57KQmAYIGxY6sshgSuCKMlFQlEHqVk0gg5D8ZkgGLyGgyKSomYSm
RACRXcWkKvMKUvaE4ck+bGU2AGy/uaKyyHLGt8OSCEys2phUGyqDt8o2kLM8/iQxqlGEZAHN
QSoTNyUf1e+k9oupMzvKJLPy4mKlQpasIdrKkm20kzJXs6Oa3DAqVTvIqlYhHqHWYB9Q0hq3
x5djkW1yWiA7dU37ZQVQ5Axnm/Z2HJlti9JysEvWZFcvgUDazdqiEU1lETMIgzbFrgk6kh0J
giSpctModmSyo5oy2dRIgMQ2UlMXLctMTmlvRp49iVej1mFJMmayhkxEwX//Nn3/Nn3/Nr39
27Q7csiPQbyxhinC2w6F61VKORKreBpxONBlgeD4lK6TTFh6WYIO0kg+5CQrisXVeetz+eRx
erNky8WTmIrDziRkR5Q6SEi8NUf2x1ZZkt22pihn25EluyXnmLMKM54o6/uIxzfvBR4/V+XF
G9eKJcUFgiv+/dx+mLl95ax55NKU/b4onpW42sPX8J3/0spxGyFO4zH42WOc2Q6HZX1AWSEy
jeggqG1Xjugg9vLtveTye8b4vBiIjnPdTROZz5S2vaaprw/cOoLHE9z/MZ8pqOYGN1v+pWbZ
1mCKL2SOothQ2ZBh7gnJkrInzEn6jvp6NacFRUUCKCzOuFfTTNvES7R4qSZ6ASUux/VIXDAv
24tdu2bxB8q2qUXFC6Q1CV6yiNi2LNioprJdf8yo2YPom8eqrgWqILzphO11c59xm1LkBniX
PD+/TRdkzOXzr+TXvFPnCLC/X+jsgeFgNE0+5H/b0TwWiWbbbbu11EWij1tS70ejuX7e6r9Z
NJrdYHkpZ26RMSznLQU2TswGXbFkSyZc4KLRT9Ps66LRR2rT18KoMe9oEp8eikabUY6ZKUXB
86sdSSYPzfFqNPppWvtHiEZDM6fXRqPbB45Ez69ay1uM4pEoNNUs5kmZOWliqyLFjZIjk2aM
bgWlawAYpNr9aIz6cOSBrlFoqseHHxtZuggIzrMpRUsmTZveCjTkt5FJXYSIQRRHalKVj0KT
XOm4k2qXI7dNX8WN1NytrXo6cuN20ldfGrMf0rootB3EJNVXQAKdfDGxk3YQqG4GMUkdRO33
GjODeCQKTeX4aGtGocnctOmj0LR/nftQFHrF1yg0lSO7bkahmTQhSQoOn8mK5f4cPmUUen7M
Pd4tCk1yffOMQlPRTFgfhWbZlRg/chUkp2WGkJlPIsqmso9Cv2MTj0Sh2XqSeD/S3u3l0S4K
TfsHbQ9FoVd8jUJrQuqMQlPRhPMZhbb4lCDFnyAKjQXeLBNZ4NwG+n0wCk2FJD6PhGDzQfiM
CpNcOztDyJqBO0PIJLfQuso+Cv2OTbzu4D7tH9ts5lJ59OBe687jtNeaSqkeefHTiElFwxAg
o4ZdUDmRNXGSJIHfM5WeptnXmUr6jf/O2DT+oujDppIZJYwbZVj4p3HDlY9RWl41lZ6mtX8E
Uwl3oZS3MVI+iKmUGjJ5n8ZUSmrsbKSG5uZdL9WT5kRtFhT1JkHmJuKLxkjCfpNMJrXfmUpJ
jZ2NTDZqyXzZkcG4tPMmvaT22rw/xB7YIzvOkub7SW8qpXx8qLKR8tcVpnXDr2KzZDRKclaP
zRpa5s2d1ak57kxXZqLNy1N0ELU6PtzVZAYxr26yg0B1MwiQZhDz9jnfWNYvSR4xlVLW7Wre
PpIXU/MwlXjxHz2wN3i8ZiqlPGSDxr0VWT80maaSxee9NOP+HD6lqUQsZoHezVQ6LqXZTaVk
PhrxptJxO8xu56QiAc06dwc56rCVvan0jk08Yiol+Tsg01RKZZXWw1RKeyzzWNLVVFrx1VRK
6hjU7SqepksO5W/wKUGKP4GpRCFeanvTBZ6mkt49NE0lnlwdcN1UkZqtVa4S2u2cVDSXwlT2
ptI7NuHzsQ9hTAOpx0GNgWD1oxVG2t5tCbDgZqMsVhrhIqty3DzgKm/b/Huwz9BnmFbh8SUo
wag5Psyak5vwJWsRM4IdNrHDucE0v8OSTcNW3ob3Huz78JD52eXx5kUPJluK5kUTTVLf8CG0
RG4JQfesx5S28j57787+yiVox17ZeNg2iVjGCRcsvcsXMY9cd4nP5eseLfr89g5r1EY9f3zL
88dudEUmtPwBNlx+SKxFczMVkFac2GKlgp9S1/7hts9u79qF2Jih8wv5G28vnFHz+J9hIlyd
wDMwl3gg0n7vjzDRiKiyXffRZ4LW+ieYRJnh5gOpSkfVF/7vLRCus9O/0UG4/SAWTVLc8P0k
+MCrfs684U1tZeBNr3N5y9R6u355V3xsHrBCiANp3XpLfsO6zA+4cJcbNUw1loh9Atouyn+b
WWeLPb9m1tOe5zln/d4fvnKzLlXpqHpt1vVOrzlrqepHjBve5FRk4uYj5Q2Xv5y04T3fjwe9
76wjXSI1P+upz1kvPOu1yKznPmc9uhz7N5h52s/k58z3qzNPbfv8/A1mXqo+Ku/UkpVnJr08
6+fvG97NjjnxEe3K2esFnmzm87bVfMCZz/tH/I/MPFu/9Q01jVR9dOZzG1ammfQyzRtIt3jX
D7M3XC6u2PCh9/w92cwjRFicpkFGpM78MfFp6B9QoftfeuJTDtzAvukV1tqh5+Msmr1BQIcQ
gcxBTvrnDVyePCrPiYgbdxJucje9v8VEpPDg10y8BeD9x58fJd04LxFuL+bi+MmTkZA02s//
qoU/0J8nwX+uhR9dK9SawdU8fgbBT9cKfc37jT671v2zp+xe2HlnuiYP2MX2iwdXeegNf+jr
EH2QrN0PWwoG0kIelTd52AqG4cYtJU8rD7hBBs46XXL7B5aHZ9fk4Q1W+X7hdyIPOW0Bfp7a
VR6y/JGqSRY9QsJ6L2ROesPXUVAMt73B6inlAecTx6c4mzwQrOWP9ecuD+wq7wIxS3+gP09a
4eda+tHVUlM3uLrHz6AVTldLfd3Xtnul1NR9dnUMz66O4Zkbg7YwryYZ9Yp84KKLuGdZ4hZG
kj8W+yR+Ec4g519nKuZPIqs3Y3//+Pie/coI0/4HQT/cCNlz5R34DUZ4JX/mGCX1LZj14UaJ
YPvx3e+7jjL38YFHOQ8Qd9vmV4+Msjlj8pc3/w8598t2ZW5kc3RyZWFtCmVuZG9iago2IDAg
b2JqCjc2ODcKZW5kb2JqCjQgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1
IDg0Ml0KL1JvdGF0ZSA5MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BE
RiAvVGV4dF0KL0NvbG9yU3BhY2UgMjMgMCBSCi9FeHRHU3RhdGUgMjQgMCBSCi9QYXR0ZXJu
IDI1IDAgUgovWE9iamVjdCAyNiAwIFIKL0ZvbnQgMjcgMCBSCj4+Ci9Db250ZW50cyA1IDAg
Ugo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL0tpZHMgWwo0IDAgUgpdIC9D
b3VudCAxCi9Sb3RhdGUgOTA+PgplbmRvYmoKMSAwIG9iago8PC9UeXBlIC9DYXRhbG9nIC9Q
YWdlcyAzIDAgUgo+PgplbmRvYmoKNyAwIG9iago8PC9UeXBlL0V4dEdTdGF0ZQovT1BNIDE+
PmVuZG9iagoxNCAwIG9iagpbL1BhdHRlcm5dCmVuZG9iagoyMyAwIG9iago8PC9SMTQKMTQg
MCBSPj4KZW5kb2JqCjI0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjI1IDAgb2JqCjw8
L1IxNQoxNSAwIFIvUjEyCjEyIDAgUi9SMTcKMTcgMCBSPj4KZW5kb2JqCjE1IDAgb2JqCjw8
L0ZpbHRlci9GbGF0ZURlY29kZQovVHlwZS9QYXR0ZXJuCi9QYXR0ZXJuVHlwZSAxCi9QYWlu
dFR5cGUgMQovVGlsaW5nVHlwZSAxCi9CQm94IFswIDAgNjQgNjRdCi9NYXRyaXhbMAowLjcy
CjAuNzIKMAowCjAuMTEwNTVdCi9YU3RlcCA2NAovWVN0ZXAgNjQKL1Jlc291cmNlczw8L1hP
YmplY3Q8PC9SMTYgMTYgMCBSCj4+Ci9Qcm9jU2V0IFsvUERGL0ltYWdlQ10+Pi9MZW5ndGgg
NTc+PnN0cmVhbQp4nCvkMlAwUMgFkmYmCjlcQAJGGwCpDK5whTyuQgUw10BBF0wDieRcLv0g
QzMFl3yuQCAEAN1TDb8KZW5kc3RyZWFtCmVuZG9iagoxMiAwIG9iago8PC9GaWx0ZXIvRmxh
dGVEZWNvZGUKL1R5cGUvUGF0dGVybgovUGF0dGVyblR5cGUgMQovUGFpbnRUeXBlIDEKL1Rp
bGluZ1R5cGUgMQovQkJveCBbMCAwIDY0IDY0XQovTWF0cml4WzAKMC43MgowLjcyCjAKMAow
LjExMDU1XQovWFN0ZXAgNjQKL1lTdGVwIDY0Ci9SZXNvdXJjZXM8PC9YT2JqZWN0PDwvUjEz
IDEzIDAgUgo+PgovUHJvY1NldCBbL1BERi9JbWFnZUNdPj4vTGVuZ3RoIDU3Pj5zdHJlYW0K
eJwr5DJQMFDIBZJmJgo5XEACRhsAqQyucIU8rkIFMNdAQRdMA4nkXC79IENjBZd8rkAgBADd
OA28CmVuZHN0cmVhbQplbmRvYmoKMTcgMCBvYmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2RlCi9U
eXBlL1BhdHRlcm4KL1BhdHRlcm5UeXBlIDEKL1BhaW50VHlwZSAxCi9UaWxpbmdUeXBlIDEK
L0JCb3ggWzAgMCA2NCA2NF0KL01hdHJpeFswCjAuNzIKMC43MgowCjAKMC4xMTA1NV0KL1hT
dGVwIDY0Ci9ZU3RlcCA2NAovUmVzb3VyY2VzPDwvWE9iamVjdDw8L1IxOCAxOCAwIFIKPj4K
L1Byb2NTZXQgWy9QREYvSW1hZ2VDXT4+L0xlbmd0aCA1Nz4+c3RyZWFtCnicK+QyUDBQyAWS
ZiYKOVxAAkYbAKkMrnCFPK5CBTDXQEEXTAOJ5Fwu/SBDCwWXfK5AIAQA3WUNwQplbmRzdHJl
YW0KZW5kb2JqCjI2IDAgb2JqCjw8L1IxOAoxOCAwIFIvUjE2CjE2IDAgUi9SMTMKMTMgMCBS
Pj4KZW5kb2JqCjE4IDAgb2JqCjw8L1N1YnR5cGUvSW1hZ2UKL0NvbG9yU3BhY2UvRGV2aWNl
UkdCCi9XaWR0aCA2NAovSGVpZ2h0IDY0Ci9CaXRzUGVyQ29tcG9uZW50IDgKL0ZpbHRlci9G
bGF0ZURlY29kZQovRGVjb2RlUGFybXM8PC9QcmVkaWN0b3IgMTUKL0NvbHVtbnMgNjQKL0Nv
bG9ycyAzPj4vTGVuZ3RoIDI3Mz4+c3RyZWFtCnic3ZQxbsNQDEPl8/m69vncFMkQlIsADmSf
BoOgoUGfDzyu6zrPc77mvu+X8/72+8fzPN///p3+PSD+io7/OeDPfbpT6yMSiHPs6IPQQiNT
wvfGRyQQ59jRiBbS+3Sn1kckEOfY0YgWGpkSvjc+IoE4x45GtJDepzu1PiKBOMeORrTQyJTw
vfERCcQ5djSihfQ+3an1EQnEOXY0ooVGpoTvjY9IIM6xoxEtpPfpTq2PSCDOsaMRLTQyJXxv
fEQCcY4djWghvU93an1EAnGOHY1ooZEp4XvjIxKIc+xoRAvpfbpT6yMSiHPsaEQLjUwJ3xsf
kUCcY0cjWkjv051aH5FAnGNHI1poZEr43vg/F0QJHgplbmRzdHJlYW0KZW5kb2JqCjE2IDAg
b2JqCjw8L1N1YnR5cGUvSW1hZ2UKL0NvbG9yU3BhY2UvRGV2aWNlUkdCCi9XaWR0aCA2NAov
SGVpZ2h0IDY0Ci9CaXRzUGVyQ29tcG9uZW50IDgKL0ZpbHRlci9GbGF0ZURlY29kZQovRGVj
b2RlUGFybXM8PC9QcmVkaWN0b3IgMTUKL0NvbHVtbnMgNjQKL0NvbG9ycyAzPj4vTGVuZ3Ro
IDEzOT4+c3RyZWFtCnic7dOxDcMwEARBsz62S9Ynw4YroIOVgPlow/tgxlprzvn63t77cT2u
67rDjuP+PHCHHcf9eyDfcdyDAQYYYICBf5qBuhmom4G6GaibgboZqJuBuhmom4G6GaibgboZ
qJuBuhmom4G6GaibgboZqJuBuhmom4G6GaibgboZqJuBuhmo+/EG3vSzgiUKZW5kc3RyZWFt
CmVuZG9iagoxMyAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9Db2xvclNwYWNlL0RldmljZVJH
QgovV2lkdGggNjQKL0hlaWdodCA2NAovQml0c1BlckNvbXBvbmVudCA4Ci9GaWx0ZXIvRmxh
dGVEZWNvZGUKL0RlY29kZVBhcm1zPDwvUHJlZGljdG9yIDE1Ci9Db2x1bW5zIDY0Ci9Db2xv
cnMgMz4+L0xlbmd0aCAxNDA+PnN0cmVhbQp4nO3TsQ3AMAgF0TCf1zXzESXZgBSHpaN65ae4
qKrrvcxcax3n+B4Ysqbh54E5axqOvfecNQ2HDdjAP9sAbRugbQO0bYC2DdC2Ado2QNsGaNsA
bRugbQO0bYC2DdC2Ado2QNsGaNsAbRugbQO0bYC2DdC2Ado2QNsGaNsAbRugbQO0bYD28Q3c
uwaCJQplbmRzdHJlYW0KZW5kb2JqCjI3IDAgb2JqCjw8L1IyMAoyMCAwIFIvUjExCjExIDAg
Ui9SMjIKMjIgMCBSL1I5CjkgMCBSPj4KZW5kb2JqCjI4IDAgb2JqCjw8L1N1YnR5cGUvVHlw
ZTFDL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjkgMCBSPj5zdHJlYW0KeJyNVG1MU1cY
vpf2ntu5ikrXgUF6KyECKlo+TCw4hekkARlMZXN+MGEUqBbKgGpbaF0LKPGKQD+kRVpmZBGm
RB0XkZkRFnUx83NKNG4umTMLxvjDbTHvNadLdi9s1v1Ysj/33Lznfc/znOd93kMS0giCJEnZ
WqOpTq+rE/+X8bEkvyCCj5OwmfyvL5ZTcUR2Rs3sQ3KSlUtYufSzBei7KPh8HrTNAfNcQkKS
5vaetcZaS52+sqpBnVS88YPkJUuWhiOpWq1WXWb5Z0e9Tlevr6xRLxJ+9ugMxtpqXU1Dlnqt
kG0w6D9WVxostVX16tLycl25WPZ+qUG3W71eb9DX1hr3qJPWJqvTNJrUFOGT9q6+usxUry4w
1hjVG9QbdZUmQ2ndv4IEQUTmbCnYWrh+46bN+erlmkyCiCe0xDIii9AQiUQ6kUGsIJYSJDGX
mEfEEnMEPQgpYScXkcfIZxHrIkYkqZJH0gzphPSi9DdqG9XNP43kn7IcJHIwxpFuKIMsqJDw
2VCkvIgTqTXI4myx2zwtAQY0KOh2+X3NLjNTgfCHfJDCO5GlucVmd4vbcoRzQybKgCwOocIr
hpaggEeocLoszCo0AYkUdHJKvA8BAWNUD5pG5k1c1DAU4LdhJaQL63rQRisew33glJALdiFN
Mdnrdfl6HF1WBktEPja7yOc8wil4O9bAdmpUxPH5RRwcgcwzlIJMD4JcbMdFmKWsSPE4fJPo
MK88BJmwC7R4F5WPrDMZvQzMR4GZu1oY60ue5B2OnzMsgR/gLSWkwnPKEzJlvyJQcvhYPW/q
D5NKQng5foZT4RmVJMpjs4vy9IdMepGs3SaSFau909VmJoc3uRGk4+fUNHQZ6OA6FwURI3Bp
JFph5ve/CXl0oNljs7U6LSrFebwQ3+ig4QG/k7qMQzidNrud/m63J6iCWXCyjcYPQjsphbmI
Fo5r5HgXR45zfAYngQl+UokFzXA01mItCCswEAdSiIYMyMYEKPFCpkwKsimMcAKOW4ppTGGU
AjSoQT0lLDJmxj+NHOg4EuZykDACbwgiaaFfCQklyOJ2+nxuT0AF0SJlu71ZoFyCE4Q73Uim
rV0Ov7/L26sCJlRMv5Tmm5Cp+BUf2VDQ87c0WDXTDqjgwDoDODaN1qGEGHSvanTzI7xCdinc
iWqkhYXG0xtGp05+dYG9Jvt55e3FKnwI/RfW6nBpNoIOKVghhb5zs7gwL3NLMjMtYJ1gmVbQ
GLmoKc4yCpdHoxXx/Hu8X6k4wpWWBIpi41flZpQGyocamEHT6X3f77tt72vtbzph7d3NVsly
3ileplLkadic8bbrB4+2uu2sTBBFMDcl9K252+9yB1UDtOLINu7b+luxIH946+l4w6juOGMI
Gt2rfQXeeldtb31v0yA7KLt25euf7l8pKexQKeIb27tafLG+LneA+Z3ubfXam1odVtUr5oWs
EdAKXb/LKXkTaN+mGz2fdvu7BDhAoe0Y0RaX0+d3Cb2ahKyQKZ4OW7sjrMrLA0XtyyFHFP8T
5YPJJ4bRwkn80fxfwqmbUDZsrhhfPAx1sDXmqGhwn98hTums8JQKc3wKt1PQfpcOT/Hq/9ef
yOnni9/zYrbysLv9MNsp8zrcDmdLm61VhX/8c8OBloP72QPzHV6n19vZ6XOJajQNk0BNu4Zv
hD+UkL4GCCzBkjWYwOmqRBqn3ROMLwHJPeGZSlPhh0+U7NXAzYGx40OnAiPsCDtkOaYf3BHM
ZfNlaTSbb86t3mHS6/eWsqXsrr76oZoxy032qkxEghhYBTEkXIDXlOXVRl3lYPWXjBed/eLE
2bOGEzrGARNCvKaiYrBmJj5w5oxhQMdE7u3jV/RBVF9fHzo3i3v9nFzOyWcTxF8yvDVbCmVu
ZHN0cmVhbQplbmRvYmoKMjkgMCBvYmoKMTQxMAplbmRvYmoKMzAgMCBvYmoKPDwvU3VidHlw
ZS9UeXBlMUMvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzMSAwIFI+PnN0cmVhbQp4nF1W
CVQT1xqeQGYyhkUhjBs1CSJhEXBBVLC+igIKRavijhs70QCKCATRB9i6XVotongEJSK4QKVY
RKyg4kafVBFrtVilPmtfn/UdFa36T/rHnneH1Pa8d3KSzNy5//bd7//+kTFyG0Ymk/WdlmjI
SszUx8f6TU43JEhLvqKrTHzHRhxiSzD9t/FmIzuEiSp/5EDsbYm9/NA79ned4XcnONwXcvsx
tjJZzrbSKemrjBn65JRMrdfc2fO9hw/3/WtlVFBQkDbO+PaJNjRxjT45TaujF1mJhvRVqYlp
mRO0U+hug0Efr002GFelrNHGJiQkJkhm82INiSu14XqDftWq9Cyt1xRv7eiRI0f50Z/RM/Sp
cWvXaKNj09Zoo7RS/v+zwjDM8KgQY/z0yekJC2dMSfwgdGZYRvialNlTM/XR0+ZErJybbYiN
m+/lPVzr5z8imGH8mKHMIiaU8WfcmZlMGBPMjGCGMeHMSMaDGcXomGjGk5nDRDABjBczl4lk
xjDeTCDjw0QxY5kFzHRmMjOFGc/0YZSMPSNjHJm+TD/GlfGlQDNy6jqGqWReykbKqmRPbKJs
1tscseVsV9p+K3eXJ8l3yb+RW9gt7G1uOXdL4agYoziq+F7xhu/PR/HF/BX+xz45fb5Tuigj
lfnKWmWd8oLylvKZnQA1jiIQcBLvVcjugo8t5JpTBfR5kypuBid8zjmak4gJnOmGiAqZuBU8
hWb0ZMGfwx3mVBaDOSx9k8qCH9cCdDkPnASczT2G46yj2IrpL8z9qJVarBdQbhmCduIQFv05
WGJpY7cptigWJCYsyt9YtMOoHqowbSndVk7qSGPxwV1flJVXVn4NGWbVQOomE1h4CqzsGGht
xf3ws1AAAwO+R1fCY6CfG0Zh+CN3GAMDfr4Hwh4NDuaMYemr5hI+dPnXL8/uai6v1ZQdrSlr
IJfIoVVlobyj+RYxmUMrZNfAR/SXSjaIVwUYYLnKgg8HgniVtVwFH3MqZinQxdKFA8UuFjPf
pNKnEhrgBLPoNwicnLvBBw6AOzrCsAGql9394R53n1wsa6pvqj98hVwmNxMuBTXf/PJwI7lC
zmS0xn2+vH5B2USa9x0OfNBJgHGcSuysT5s7LyktXIPjOHSSw1RO9fLb4yumz0hcMVmDUzl6
Pm8RqAMtFFMU4Lz4pYBBOpRhGIb3IAPBMP4FyCAE3vd6jRM1RcgKXWfC3XTzwya9t+DGixdn
b3yn6XXUx88kjoA+MKbC+Qj1lg/aAao80bs/aGnBWizlUs4vrppGUxS8sR+Om3wg5PP5GlXL
/Ppr+muuHeR0VV0rj0rRQfjmdPgw75ipYWExnU+fNd+4oXE0j7DiSiHxsRXHQaUA68RlLL7L
oQZvozfcZnECB5ssdK0SfBS91JIMrlMYv5Rsdvbvxd3H8iGHjeKHlCsS6mKRhHsmOIvF4CJr
ohvNfxOzhE3tGxoMJ6JvjTqBMppvHLqgJ+bjBlChJyyDCHB4CRNKNKjjCv1nzvOnW/ipv0AA
BH7zH1CeO2lMOawpy96ZU5LASxx7DUMfQd/XMtEEWUJRKdlBisn5jWc2HE9+MqatN8AIX5Rj
BIb84gZ+4PCk81WNBtVc7vKEjAUknqwszz66oWLTwa1n+Y8fCSXddSeuUDLX5lak78n+NOuT
JEq7/ZngIu6gJTTQmnRSvYPNRsGDjNNPnxYZluRBaBiU1Q+7Gt4+tXvFr+RX0v1Z+/X2ji9e
kRcEuKTnkTfe7wyuHUr4InQRoO8dTxyN3sE6tEeHCT00Kb+7PeCgsXJUXANOsi4K7CUaqKs/
HOfAltyobmm7fL3mKQGWgNzwdFbnorbwKpTT6uhzH0uPQM1cFcBefBcDcUz0u8hajxU2Usan
U4/fUY+7pJ7Jgj0CfMDB4AePwQt04++iLz3k3iYRBTndq1XcrU+ZFJKUMqHXxV9dI/tesjdC
hwDPJYmBINEBnCwHqeQ00n8NJfwgYhIHgSatwrld4md9OxUQSz2la4NC1dl94kT33l3btuxX
w1DFxqJNZDN5n0THpk7mVfWvFJKamSibrKFuSaEypVA3aaibdO13GqLE2suSstjAS7Bxbqau
I8EVnaRoPeLHoo2wFbiATvSgyAwZG462ybsN+7M0+3PKC8/lwoT5A1WP6vJL89cOXpGQHZmc
VlxqVOft/mj3R0fodm47Kn+cDuPJbXKprKG2ofbgGdJKbqScCjVh2NmBCaUFO8kB/mhtRYta
1dNBPltTtIjvzVr0Azval7IOms082uUdVIlpplroUlw51dR+9GD+2jJ1qXH7epLC4w90/XcF
6TA2J9UYqpfuXUrCycL0hJk8VFgbC0wUg9lUpKiqQxn4ogt4D1CJkAuNAkzirh5ePeMjUrBt
g2ZbDjGSfDJ1+9r9KTwEHuIy9xTuJbWbYeXmXf4N3bUn2shP5HJ2a8rnK44tKZtOeIur9ZhH
y6n/CMVJsm/zvjxe9XJfXkmGfjBJKUjPzVu3PnvTcvIH6bUmKKLJrAYX50bwGaDKMceI7wh4
iuIdzG2OK8hYu5pXnVqWPGf1LFd0GPOKJjyq6zGozjXlpX2mMRl35+5J5MGNM1LRdHyMofRQ
ktAdR2A2roZhGAgLn1yr676oUeXsG87+i3OEB+K0R7IfrEJZLUwED6psHuH+nfhPbuyp2H/X
VH2ys0r9RLF+68ZtBYRPKtzdrIHTdxSOUENPYXPF15Q5HZJ1vDS4tBLzOHOqnDqhBKFaNCIT
7KlO2MtOgTucB3db8Vdxu0A68pqSGxadDz5COxSn6IJwKLKX5oBXuuZ59rOc+nQyc9CM6KSR
HrNP3tmkprJUgiNfj4UZhIeZYPuQdpFi1lfoWq1B7oDWZDCR1kEXWuq6HrfGh+xQW4+0naL4
qVUvGyX92A73Bbzfq5nDsRpPQLU0uenT+9Y+EO/SSuDv0lZB7BFAT8l/jxax2tIjNYBUrqS/
7VKX6P+Y+9bO6MUBJlbI2iQcYuAHQXRHbS8bwxQX/wECFrIwnsOF8BNEwXIWA6wa7SL2VPSK
RI0UtIj6tBQqApbG+vktbXyoFgupthcqSNCBWS3LWmO6Vj8kD0lXdWtzS9OBy6SbFwspd/f3
xpaJ5v7gJ9az6MEFWRyDRUcWtdJVoHTlwYGvpZ6FYdwD0emexYn9sxbruUm19GZr7XJ2lEkM
ANb5ME3/AxhCGSiayoWMyg/3ksM8tCrAZtJF1KHuvenoVKgGV674YuW+TsKfP2RMNhauy9uo
ySkgJDw/umCg1jh/DvEhS/YkVq2ipF1Zczqn2fUrcqG65SyvyiHpnxTsWceDL4cTIVVQnQqO
XxK6OK2qofFAxeVSdXNJffGnH5ftHPT/o7jtz1Hc9kfTX1CoWuYdO51x3RWEJ9AXxn279lby
OU1Sa8SxCDKNxGTo5/JQqgAlnhE6W8I8vReFhYcuvv7iSXMnHcW/hVrRMKf1h6XSe1oAhzJL
Ex3cTSx6cchaTiIrnpTWIU56f3PlwE68Bo6WaxTKB+aFdIovk0BUYEgMqgn6EfRvRjXQe/4Z
5wZxepAT8CSgOwbcK1jOv7VyxMUCKCCkGdQE/Aj4x4Aa6T3vyb3CuGN01qAnQZ0eOTekVuK9
AhMEgp2Mvjra2YpHoUnASIhEO4ykHzt6FUlFka5IbKUxIB5cZXAWHgtYha5Q1Uti0MlgBego
fVFn5fV6k3kKTSbBvFTAuDcGtoOWaTZIpdHNkCMZsBLpy/6yEsvlb+0zK8V6ifwxlRwoleBm
B8oSe3tw22XvwDD/BfSsZ64KZW5kc3RyZWFtCmVuZG9iagozMSAwIG9iagoyODI5CmVuZG9i
agozMiAwIG9iago8PC9TdWJ0eXBlL1R5cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro
IDMzIDAgUj4+c3RyZWFtCnicY2RgYWJgZGTkdc4vLcpMLdJ1ys9JAQlo/ZBm/CHD9EOWubv7
x8wft1llGezqdvF28zB387As/P5U6Hu14PcK/u+lAgzMjIzlndOc8wsqizLTM0oUNEKDwjW1
tXUQIoaWlpYKSZUwGQWX1OLM9DwFNSCjLDUnvyA3Na/EWsEZqDonJzNZIT2nsiCjWCExJTUF
pCssMSc1W8EtMyezoCC/TEHDWVPByMDAUBdIGPll5iaVFiv45uflK/gogByPIsLAwMBoyMAg
xMDEyMiS+uMN34833e8Zv/e9Z/7+6aeQ6O+MkOTGuvruPMm8+SVLp/b1TJgn92gR6x9dNfbC
7pauptaapqaq7qrumsnVM5omt8zsWNTN8f0Q2/zuWX2T+mdNnTK7e0737OZZdVMbJzX3FnRz
qLHxlc//4Tn/u9D8+fPZPnB94H4xmYfnAw8vAwMApGyHBAplbmRzdHJlYW0KZW5kb2JqCjMz
IDAgb2JqCjM0MgplbmRvYmoKMzQgMCBvYmoKPDwvU3VidHlwZS9UeXBlMUMvRmlsdGVyL0Zs
YXRlRGVjb2RlL0xlbmd0aCAzNSAwIFI+PnN0cmVhbQp4nFWUfVQU1RvHZ9h1Z1KCYJy2onZH
LF7U4t13wBYE3BZSUBIzdYEVNncXfrAgJHh8S4MraRZFHm33ICqSHVGgtNbkpSxJXraIdtNd
BFwPv47nZCd+v2c4F0/d1Tqd/pkzc+c+3/k+n/t9hqakPhRN0zPTdIZynVmfp/U+LRCDaPFp
H/EZCcKmqWVTxhnPUJpjdx5FvhLkK218WnYhENoDoM4fKh6jJDRdUXc0qai4skRfUGgWwtZl
vhI+f/6Cf1ailixZIuRW/v1GSNaV6gtMQgi5KdcZioqNOpN5mZBEdhsM+jyhwFBZXFgqaPPz
dfnesmytQbdNSNEb9MXFReVCWFK4EB0ZGfU8uURn6I25ZaVCltZUKmiETF1BmUFb8q9FiqI4
U16RbmVJQUphpllfps0NCxeWUNTLVDK1mkqhQqgsKo0KpVZRMdQ6Sk1lUyoqiXqEmknR1FPU
bIKHkpKth6kf6Vh6I33cJ8Iny+ddiY9kmeRVyfvSCOl+6WXppBRmbIUWP7ETWcU1Q4WWQLsj
YQTedsu5drto5bmz09YR6GC4of/32Ef7OvI0CvyHWxSYMXVPSHyOUfWagmsfZ/zEt8wOcYGD
bhmTiNvgHn/gy11ntzcX2DTNKsTiORFYilU43iNAMAT8PAyz65WLZNWLtmiTERuxdhgeA3mX
8479s1xVvZJ4eah1bgw6xyTQJJ7jcWh0ME7GyePBEA6hnklYAatif8fzlQcT+P/2JODHsf+a
+IgXMh3AQeBXzomHIpA2ALEOun1UItbDTh7dePOLqgv60WVXwomnkOeJpxV4xZ05EAq+7gGQ
WYknc8rGgjSUjTadKPps+5l9Z2qvsHUD/JG7V3tHEOvqTY2rQTW1NUq/qQjkgrddUO2iPRMS
eAlu8eIc1/QcqBYjXdN1942ixTWtkvnBKOGqGidcBwlXOdc66IXa7IXaxKDhj2xtzSw3ePKj
pne+PsjeYqrr9h3chdah3G2vxrNc6y8EbCc22SHAC4SINI9BO1G5KUYSmUSGu3tNu745LQg/
GYVZnBDXuPLTHOWFzT3/6UZ96NLpz/vYYgYl79lSbiozbKlcj3RIX28+XnF074f7W9iFsvfC
HKvBHzlRf9MnHW1fHO1D4M8ScTURxhXpvKczEctxwLrEmMi1D8j2OG8TsoCs8N2/Wod7LnyP
tC64pqvvGydkf8XpB0i00HY3SZPEPmXk7xvdJEneHJ06tafKojjxRn0J2so+zNO4pvu5FzeZ
X9qggDOM39RW8o1LLjjkCpyYAOxZelfOTUIG9POwT+ZuzYtScmKtGm16d3OD8UmY0SgrPLHv
ZM3dWvCtOLf8E5abdLWd/dL9FAQuH8RzFfi215QoSOEQlDFX0Jm9jdubyhteR5vZuM35YQo/
aDEPifMG6FtuCRwhZOPg2cX42eTU76cFWfY543WLpe7waYWd2fXWztodiC3YXd+qBDzK+EEJ
6XO7BdItdD+pnUdqF09b3bIpo3RR8IiXg3kox7sj8LobDpGhqhDLHxeti/FlhrsoZK2MXaVt
61WIzOLpMCb2etZvDtupQZuCq1B5D95sXzkkRjoCO8ag4UHpxzaeu1iz5wDaH2TacfSkEr5l
JlIvYz5RU5ZfqCgt3m2seYUdkR357nyzE7HDHUU5yjIGFZZXrdqLZ1ZVHti2M6PEsBGlslzF
gr6X/9fX2dh1VfFO9snSLnQMNdSdOkKmAlJ5VLT3jRKz3pC7YwNi1bqWzu7W07cblOMfHD90
uoH1GnOutYoaJyRYArvccGVMzlV1PTjf4X6Gs2W0dZqGgkDhgRmggoS4SaxIWl+8Ol8JzQyE
YCs/8c1SHIBnpS+NjFlzA/zB/+sb40oyKVM5FnropgR2Ea1QLNdgNcJRCEf3YvWvWM52y2Jg
7gZYjiAWQYwN4schmP2rDJJuSiZwIf8ryHtBjSAKQbQG1KEgZ9fKxvFcG16OcCzCMRtwfAz2
lrU86AMynXDNQZ/3wKceSScs5I9h9qcUoMhMfH++vffioGUMAY9gVuVP2t78r9Jb4smfI2he
KFbiJzwvwOx+24nuS8pa/GLW/BCUjrZcqB5gYbb4Ou+6lhoRm5EetzD76i+eb67fVPqZG0Wr
NyiaRplzpnuW87Cv7633fB+lqD8BvatLvQplbmRzdHJlYW0KZW5kb2JqCjM1IDAgb2JqCjE2
MTMKZW5kb2JqCjIwIDAgb2JqCjw8L0Jhc2VGb250L1VGRlRWTCtDb3VyaWVyL0ZvbnREZXNj
cmlwdG9yIDE5IDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciA5MC9XaWR0
aHNbCjYwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjAwCjYwMCAwIDAgMCAwIDAg
MCAwIDAgMCA2MDAgMCAwIDAgMCAwCjAgNjAwIDAgMCAwIDAgNjAwIDAgMCAwIDAgNjAwIDAg
NjAwIDAgNjAwCjAgMCA2MDAgNjAwIDYwMCAwIDAgMCA2MDAgMCA2MDBdCi9FbmNvZGluZy9X
aW5BbnNpRW5jb2RpbmcvU3VidHlwZS9UeXBlMT4+CmVuZG9iagoxMSAwIG9iago8PC9CYXNl
Rm9udC9KTERNR1MrSGVsdmV0aWNhLUJvbGQvRm9udERlc2NyaXB0b3IgMTAgMCBSL1R5cGUv
Rm9udAovRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEyMS9XaWR0aHNbCjI3OCAwIDAgMCAwIDAg
MCAwIDMzMyAzMzMgMCA1ODQgMCAzMzMgMjc4IDI3OAowIDAgMCAwIDAgMCAwIDAgMCAwIDMz
MyAwIDAgMCAwIDAKMCA3MjIgNzIyIDcyMiA3MjIgNjY3IDYxMSA3NzggNzIyIDI3OCAwIDAg
NjExIDgzMyA3MjIgNzc4CjY2NyAwIDcyMiA2NjcgNjExIDcyMiAwIDk0NCAwIDY2NyAwIDAg
MCAwIDAgMAowIDU1NiA2MTEgNTU2IDYxMSA1NTYgMCAwIDYxMSAyNzggMCA1NTYgMjc4IDAg
MCA2MTEKMCAwIDM4OSA1NTYgMzMzIDAgMCA3NzggMCA1NTZdCi9FbmNvZGluZy9XaW5BbnNp
RW5jb2RpbmcvU3VidHlwZS9UeXBlMT4+CmVuZG9iagoyMiAwIG9iago8PC9CYXNlRm9udC9T
SlpHTForQ291cmllci1Cb2xkL0ZvbnREZXNjcmlwdG9yIDIxIDAgUi9UeXBlL0ZvbnQKL0Zp
cnN0Q2hhciA0OS9MYXN0Q2hhciA0OS9XaWR0aHNbIDYwMF0KL0VuY29kaW5nL1dpbkFuc2lF
bmNvZGluZy9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjkgMCBvYmoKPDwvQmFzZUZvbnQvWE9G
R0RZK0hlbHZldGljYS9Gb250RGVzY3JpcHRvciA4IDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hh
ciAzMi9MYXN0Q2hhciAxMTcvV2lkdGhzWwoyNzggMCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAg
MCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDU1NiAwIDAgMCAwIDAgMAowIDAgMCAwIDAg
NjY3IDYxMSAwIDAgMCAwIDAgMCAwIDAgMAowIDAgNzIyIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAKMCA1NTYgNTU2IDUwMCAwIDU1NiAwIDU1NiA1NTYgMjIyIDAgMCAwIDAgNTU2IDU1
NgowIDAgMzMzIDAgMjc4IDU1Nl0KL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9TdWJ0eXBl
L1R5cGUxPj4KZW5kb2JqCjE5IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5h
bWUvVUZGVFZMK0NvdXJpZXIvRm9udEJCb3hbMCAtODEgNTkzIDY2N10vRmxhZ3MgNQovQXNj
ZW50IDY2NwovQ2FwSGVpZ2h0IDY2NwovRGVzY2VudCAtODEKL0l0YWxpY0FuZ2xlIDAKL1N0
ZW1WIDg4Ci9BdmdXaWR0aCA2MDAKL01heFdpZHRoIDYwMAovTWlzc2luZ1dpZHRoIDYwMAov
Q2hhclNldCgvQS9YL00vWi9PL0YvUi9TL2NvbG9uL1QvSy9zcGFjZS9zbGFzaC96ZXJvKS9G
b250RmlsZTMgMjggMCBSPj4KZW5kb2JqCjEwIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0
b3IvRm9udE5hbWUvSkxETUdTK0hlbHZldGljYS1Cb2xkL0ZvbnRCQm94WzAgLTIxOSA5MzIg
NzQxXS9GbGFncyA0Ci9Bc2NlbnQgNzQxCi9DYXBIZWlnaHQgNzQxCi9EZXNjZW50IC0yMTkK
L0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDEzOQovTWlzc2luZ1dpZHRoIDI3OAovQ2hhclNldCgv
TC9BL3kvYy9NL0Ivby9kL1kvTi9DL2UvTy9EL1AvRS9yL0Yvcy9oL1IvRy90L2kvUy9IL2Nv
bG9uL1QvSS9rL1Uvdy9sL2EvYi9XL3BhcmVubGVmdC9wYXJlbnJpZ2h0L3BsdXMvc3BhY2Uv
aHlwaGVuL3BlcmlvZC9zbGFzaCkvRm9udEZpbGUzIDMwIDAgUj4+CmVuZG9iagoyMSAwIG9i
ago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1NKWkdMWitDb3VyaWVyLUJvbGQv
Rm9udEJCb3hbMCAwIDUxNyA1ODNdL0ZsYWdzIDUKL0FzY2VudCA1ODMKL0NhcEhlaWdodCA1
ODMKL0Rlc2NlbnQgMAovSXRhbGljQW5nbGUgMAovU3RlbVYgNzcKL0F2Z1dpZHRoIDYwMAov
TWF4V2lkdGggNjAwCi9NaXNzaW5nV2lkdGggNjAwCi9DaGFyU2V0KC9vbmUpL0ZvbnRGaWxl
MyAzMiAwIFI+PgplbmRvYmoKOCAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnRO
YW1lL1hPRkdEWStIZWx2ZXRpY2EvRm9udEJCb3hbMCAtMjE4IDY3OSA3MjldL0ZsYWdzIDQK
L0FzY2VudCA3MjkKL0NhcEhlaWdodCA3MjkKL0Rlc2NlbnQgLTIxOAovSXRhbGljQW5nbGUg
MAovU3RlbVYgMTAxCi9NaXNzaW5nV2lkdGggMjc4Ci9DaGFyU2V0KC9uL2Mvby9lL0Uvci9n
L0YvaC9SL3QvaS9uaW5lL3UvYS9iL3BhcmVubGVmdC9wYXJlbnJpZ2h0L3NwYWNlKS9Gb250
RmlsZTMgMzQgMCBSPj4KZW5kb2JqCjIgMCBvYmoKPDwvUHJvZHVjZXIoR1BMIEdob3N0c2Ny
aXB0IDguMTUpCi9DcmVhdGlvbkRhdGUoRDoyMDA2MTExMDE0NTgyNSkKL01vZERhdGUoRDoy
MDA2MTExMDE0NTgyNSkKL1RpdGxlKE1pY3Jvc29mdCBQb3dlclBvaW50IC0gZmluYWxFRlJf
SU5GT0NPTV8yMDA2LnBwdCkKL0NyZWF0b3IoUFNjcmlwdDUuZGxsIFZlcnNpb24gNS4yLjIp
Ci9BdXRob3IoR3VpbGxlcm1vKT4+ZW5kb2JqCnhyZWYKMCAzNgowMDAwMDAwMDAwIDY1NTM1
IGYgCjAwMDAwMDgwNzMgMDAwMDAgbiAKMDAwMDAxOTUxNiAwMDAwMCBuIAowMDAwMDA4MDA0
IDAwMDAwIG4gCjAwMDAwMDc3OTIgMDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBuIAowMDAw
MDA3NzcyIDAwMDAwIG4gCjAwMDAwMDgxMjEgMDAwMDAgbiAKMDAwMDAxOTI0MiAwMDAwMCBu
IAowMDAwMDE4MDEzIDAwMDAwIG4gCjAwMDAwMTg2NTUgMDAwMDAgbiAKMDAwMDAxNzQyNiAw
MDAwMCBuIAowMDAwMDA4NjE4IDAwMDAwIG4gCjAwMDAwMTAxMDYgMDAwMDAgbiAKMDAwMDAw
ODE2MiAwMDAwMCBuIAowMDAwMDA4MzA1IDAwMDAwIG4gCjAwMDAwMDk3NjkgMDAwMDAgbiAK
MDAwMDAwODkzMSAwMDAwMCBuIAowMDAwMDA5Mjk4IDAwMDAwIG4gCjAwMDAwMTgzNzYgMDAw
MDAgbiAKMDAwMDAxNzEyOCAwMDAwMCBuIAowMDAwMDE5MDAxIDAwMDAwIG4gCjAwMDAwMTc4
NTIgMDAwMDAgbiAKMDAwMDAwODE4OSAwMDAwMCBuIAowMDAwMDA4MjIxIDAwMDAwIG4gCjAw
MDAwMDgyNTEgMDAwMDAgbiAKMDAwMDAwOTI0NCAwMDAwMCBuIAowMDAwMDEwNDQ0IDAwMDAw
IG4gCjAwMDAwMTA1MDcgMDAwMDAgbiAKMDAwMDAxMjAwMyAwMDAwMCBuIAowMDAwMDEyMDI0
IDAwMDAwIG4gCjAwMDAwMTQ5MzkgMDAwMDAgbiAKMDAwMDAxNDk2MCAwMDAwMCBuIAowMDAw
MDE1Mzg4IDAwMDAwIG4gCjAwMDAwMTU0MDggMDAwMDAgbiAKMDAwMDAxNzEwNyAwMDAwMCBu
IAp0cmFpbGVyCjw8IC9TaXplIDM2IC9Sb290IDEgMCBSIC9JbmZvIDIgMCBSCi9JRCBbKLTA
SjeWDxaRjm98PrKcwQEpKLTASjeWDxaRjm98PrKcwQEpXQo+PgpzdGFydHhyZWYKMTk3MzgK
JSVFT0YK
--------------010603090201000407000004--


Received: from xmail08.myhosting.com (xmail08.myhosting.com [168.144.250.251]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kAADRKpR024775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 10 Nov 2006 05:27:21 -0800 (PST)
Received: (qmail 25432 invoked from network); 10 Nov 2006 13:27:05 -0000
Received: from unknown (HELO [127.0.0.1]) (Authenticated-user:[e-mail]@[65.190.218.139]) (envelope-sender <[e-mail]>) by xmail08.myhosting.com (qmail-ldap-1.03) with SMTP for <[e-mail]>; 10 Nov 2006 13:27:04 -0000
Message-ID: <[e-mail]>
Date: Fri, 10 Nov 2006 08:27:00 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 10 Nov 2006 13:27:46 -0000
Status: RO
Content-Length: 2372

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


> a) assign 16-bit nicknames to all the RBridges (as we were going to
> do with the short shim header)

> b) assign, say, 8 bit link-local nicknames to all the RBridges on a
> link (this can be done through the IS-IS Hello protocol quite
> easily--I'd suggest doing it by having the Designated RBridge assign
> the values, but it could also be done by having each RBridge choose a
> nickname and back off if someone with a better ID has chosen that 
> nickname)

> c) in the Destination address field in the Ethernet header, put in
> both the 16-bit egress RBridge nickname, and the nextop 8-bit
> nickname

> d) in the Source address field in the Ethernet header, put in both
> the 16-bit ingress RBridge nickname, and the transmitting RBridge on
> that link's 8-bit nickname
> 
> So---bridges will never incorrectly learn the location of any
> RBridges, because no matter where a packet from R12 arrives into the
> link, the bottom bits will be specific to the RBridge on the link
> that injected the packet.
> 
> And positive learning can happen as well. Suppose there are n total
> RBridge nicknames in use in the whole campus. Suppose there are 5
> RBridges on the link. The bridges inside the link will see 5*n
> RBridge addresses as a result of this proposal. In other words, if
> the RBridge nicknames are 1, 2, ... 517. and there are 5 RBridges on
> the link, the MAC addresses the bridges will see are: {1 - 517} | {1
> - 5}
> 
> In Sanjay's picture, if R4 wants to direct a packet towards R2 rather
> than R3 for egress R1, it encodes R2's nickname into the "neighbor's
> nickname" portion of the egress RBridge field.
> 
> Anyway---something for people to think about.

I like this proposal.... It solves many of the problems we've been
looking at, with a single "shim/ethernet" header. We could make the
total header the size of an ethernet header plus the trailing TTL and
reserved space, making the size come out right for easy processing, etc.

Should we replace the current shim header text with this?

:-)

Russ

- --
[e-mail] CCIE <>< Grace Alone

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

iD8DBQFFVH4kER27sUhU9OQRAlEXAKDlFkl7a93xVCs/aKRKdIc8/IihlwCg0eII
TvOzBPbanKhybn8xTutKNtE=
=mbtr
-----END PGP SIGNATURE-----


Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA94qJBc016684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 8 Nov 2006 20:52:19 -0800 (PST)
Received: from [127.0.0.1] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kA94oruZ009342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Nov 2006 20:50:54 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 08 Nov 2006 20:50:52 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Anoop Ghanwani <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig63B628428F0DD564F8A8C2A7"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Which 802.1 headers are relevant?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 09 Nov 2006 04:52:53 -0000
Status: RO
Content-Length: 2058

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



Anoop Ghanwani wrote:
>> -----Original Message-----
>> From: [e-mail]=20
>> [mailto:[e-mail]] On Behalf Of Joe Touch
>> Sent: Wednesday, November 08, 2006 4:41 PM
>> To: Caitlin Bestler
>> Cc: [e-mail]
>> Subject: Re: [rbridge] Which 802.1 headers are relevant?
>=20
>>> That is, rbridges ignorant of 802.1??? will result in the=20
>> cloud being=20
>>> partitioned for purposes of 802.1??? -- and generally that is the=20
>>> correct behavior.
>> The same could be said for bridges ignorant of 802.1?? - that=20
>> they partition, or more specifically 'are treated as air=20
>> gaps' to that protocol.
>=20
> I think it depends.  If, for example, rbridges were ignorant
> of xSTP but they treated xSTP frames as regular multicast
> frames (which is what they would do if they were truly
> ignorant), then an rbridge is effectively a hub from the
> standpoint of xSTP.  That would probably be true for
> GARP/GVRP/GMRP as well.  It's only if rbridges recognize
> those frames and drop them, do they become "air gaps"
> for that protocol.

Right. Routers *never* participate in L2 protocols this way; bridges
can, but don't always. When considering the rbridge campus, we should
decide whether it behaves as a single bridge would - whether that
equivalent bridge would participate or not is the decision.

Joe


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

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

iD8DBQFFUrOsE5f5cImnZrsRAgXQAKDS34joMbw03f8AZbxP2hhb+5B0jACffMhZ
YGmT8LQyub5W6uY9xi3nhnU=
=lGQ8
-----END PGP SIGNATURE-----

--------------enig63B628428F0DD564F8A8C2A7--


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA936ulU014580 for <[e-mail]>; Wed, 8 Nov 2006 19:06:56 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 8 Nov 2006 19:06:50 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Etherchannel
Thread-Index: AccDrBoGctPGBfcOQRecSwTWmpOCFQ==
From: "Silvano Gai" <[e-mail]>
To: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA936ulU014580
Subject: [rbridge] Etherchannel
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 09 Nov 2006 03:07:11 -0000
Status: RO
Content-Length: 124

During the meeting I was asked to provide a reference to Etherchannel.
It is:

IEEE P802.3ad Link Aggregation 

-- Silvano



Received: from mail53.messagelabs.com (mail53.messagelabs.com [216.82.249.211]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id kA91oKii020271 for <[e-mail]>; Wed, 8 Nov 2006 17:50:20 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-3.tower-53.messagelabs.com!1163037019!94068969!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [66.243.153.112]
Received: (qmail 31746 invoked from network); 9 Nov 2006 01:50:19 -0000
Received: from f112.brocade.com (HELO scooby.brocade.com) (66.243.153.112) by server-3.tower-53.messagelabs.com with SMTP; 9 Nov 2006 01:50:19 -0000
Received: from hq-exch-1.corp.brocade.com (hq-exch-1.brocade.com [10.3.8.21]) by scooby.brocade.com (Postfix) with ESMTP id 3B29825801A; Wed,  8 Nov 2006 17:50:16 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 8 Nov 2006 17:47:41 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Which 802.1 headers are relevant?
Thread-Index: AccDmEac6WOj2wvJSHu+CRdyQ8lfSgAB/pZA
From: "Anoop Ghanwani" <[e-mail]>
To: "Joe Touch" <[e-mail]>, "Caitlin Bestler" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA91oKii020271
Cc: [e-mail]
Subject: Re: [rbridge] Which 802.1 headers are relevant?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 09 Nov 2006 01:50:38 -0000
Status: RO
Content-Length: 1030

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Joe Touch
> Sent: Wednesday, November 08, 2006 4:41 PM
> To: Caitlin Bestler
> Cc: [e-mail]
> Subject: Re: [rbridge] Which 802.1 headers are relevant?

> 
> > That is, rbridges ignorant of 802.1??? will result in the 
> cloud being 
> > partitioned for purposes of 802.1??? -- and generally that is the 
> > correct behavior.
> 
> The same could be said for bridges ignorant of 802.1?? - that 
> they partition, or more specifically 'are treated as air 
> gaps' to that protocol.

I think it depends.  If, for example, rbridges were ignorant
of xSTP but they treated xSTP frames as regular multicast
frames (which is what they would do if they were truly
ignorant), then an rbridge is effectively a hub from the
standpoint of xSTP.  That would probably be true for
GARP/GVRP/GMRP as well.  It's only if rbridges recognize
those frames and drop them, do they become "air gaps"
for that protocol.

Anoop



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA90fter028652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 8 Nov 2006 16:41:55 -0800 (PST)
Received: from [127.0.0.1] (priras02.isi.edu [128.9.176.220]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kA90fNJS012847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Nov 2006 16:41:25 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 08 Nov 2006 16:41:22 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Caitlin Bestler <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAFF7FC058E36E4983757725C"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Which 802.1 headers are relevant?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 09 Nov 2006 00:42:10 -0000
Status: RO
Content-Length: 1652

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



Caitlin Bestler wrote:
> I have a criteria to propose on the question of which L2 standards are
> relevant to rbridges, versus being totally opaque.
>=20
> The default for any L2 option that is not fully understood or yet
> defined is covered by the general principle that to a bridge an
> rbridge looks like a router.

IMO, rbridges as a group look somewhat like a single bridge.

If they looked like a router, then traffic that transited them would be
addressed _to_ them at L2; this is never the case, so they're clearly
not routers.

> That is, rbridges ignorant of 802.1??? will result in the cloud
> being partitioned for purposes of 802.1??? -- and generally that
> is the correct behavior.

The same could be said for bridges ignorant of 802.1?? - that they
partition, or more specifically 'are treated as air gaps' to that protoco=
l.

The rest of the logic, I agree, follows... (if partitioning is OK, then
its OK; if not, then not).

Joe


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

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

iD8DBQFFUnkyE5f5cImnZrsRAkv6AJ9Bj/3bRyTrGbbIawvaIl/sX1AjWACeNA/V
b1nEuWLotur2EkVXE4qU7W0=
=ogc2
-----END PGP SIGNATURE-----

--------------enigAFF7FC058E36E4983757725C--


Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA8Mpdan023555 for <[e-mail]>; Wed, 8 Nov 2006 14:51:39 -0800 (PST)
Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Wed, 08 Nov 2006 14:51:20 -0800
X-Server-Uuid: 9206F490-5C8F-4575-BE70-2AAA8A3D4853
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 85DD72AF; Wed, 8 Nov 2006 14:51:20 -0800 (PST)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 5E7062AE for <[e-mail]>; Wed, 8 Nov 2006 14:51:20 -0800 (PST)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EKN37927; Wed, 8 Nov 2006 14:51:20 -0800 (PST)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id D77B820501 for <[e-mail]>; Wed, 8 Nov 2006 14:51:19 -0800 ( PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 8 Nov 2006 14:51:14 -0800
Message-ID: <[e-mail]>
Thread-Topic: Which 802.1 headers are relevant?
Thread-Index: AccDiGR/XEhqDVMqRpa6fTME2+e+vA==
From: "Caitlin Bestler" <[e-mail]>
To: [e-mail]
X-WSS-ID: 694C80E23ES2980183-01-01
Content-Type: text/plain; charset=us-ascii
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA8Mpdan023555
Subject: [rbridge] Which 802.1 headers are relevant?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 08 Nov 2006 22:52:03 -0000
Status: RO
Content-Length: 1579

I have a criteria to propose on the question of which L2 standards are
relevant to rbridges, versus being totally opaque.

The default for any L2 option that is not fully understood or yet
defined is covered by the general principle that to a bridge an
rbridge looks like a router.

That is, rbridges ignorant of 802.1??? will result in the cloud
being partitioned for purposes of 802.1??? -- and generally that
is the correct behavior.

For example, the value of 802.1x (Port-Based Network Access Control)
would not seem to be impaired by partitioning the cloud.

By contrast 802.1au (Congestion Avoidance) is clearly impaired
if BCNs cannot be delivered as close to the true source as possible.

I suggest that this be the criteria for determining which IEEE 
efforts are worth considering. More specifically, anyone who wishes
to discusss IEEE protocols (particularly those that are in progress)
needs to explain why rbridges being ignorant of said protocol would
produce a detrimental effect.

Once that case has been made, the WG can discuss mitigations including
possible new requirements for rbridges to properly support the 
specific IEEE protocol. Such requirements would probably need to
packaged in separate drafts, to prevent the main document being
dependent on different IEEE project's delivery schedules, which
probably also means that each feature set would be optional.
But I still think it would be of value for the trill WG to define
how an 802.1au-aware rbridge should handle each type of 802.1au
defined frames even if being 802.1au-aware is not required.




Received: from smtp-1.dynsipr.ucl.ac.be (smtp.dynsipr.ucl.ac.be [130.104.4.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA8MW0qb016277 for <[e-mail]>; Wed, 8 Nov 2006 14:32:01 -0800 (PST)
Received: from smtp-1.dynsipr.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp-1.dynsipr.ucl.ac.be (Postfix) with ESMTP id F39C32C257; Wed,  8 Nov 2006 23:31:56 +0100 (CET)
Received: from [130.129.68.111] (dhcp68-111.ietf67.org [130.129.68.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: [e-mail]) by smtp-1.dynsipr.ucl.ac.be (Postfix) with ESMTP; Wed,  8 Nov 2006 23:31:56 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 08 Nov 2006 14:31:47 -0800
From: Pierre Francois <[e-mail]>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-AV-Checked: ClamAV using ClamSMTP
X-SGSI-MailScanner: Found to be clean
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Gideon Kaempfer <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail]
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 08 Nov 2006 22:32:31 -0000
Status: RO
Content-Length: 29003

Eric,

The ECMP problem makes the drop behavior much more difficult to achieve, 
as simply looking
if a packet would get out by the same oif as it entered is not 
sufficient to drop all loopy packets.
So if there is no support for "clever-ness", we'll have to admit that 
packets will loop.

Pierre.

Gray, Eric wrote:
> Mike,
>
> 	To add one point to what Alia said, we need to make up our
> minds what we want the failure mode to be (or - shudder - what the
> options should be for different deployment scenarios).
>
> 	At yesterday's meeting, there was substantial support for a
> failure mode that "prefers" drop behavior to "clever-ness."  I can
> think of no good reason why this should be the model in some cases
> and not in others.
>
> --
> Eric
>
> --> -----Original Message-----
> --> From: [e-mail] 
> --> [mailto:[e-mail]] On Behalf Of Alia Atlas
> --> Sent: Wednesday, November 08, 2006 4:43 PM
> --> To: mike shand
> --> Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
> --> Subject: Re: [rbridge] Traffic storms
> --> 
> --> On 11/8/06, mike shand <[e-mail]> wrote:
> --> > At 23:31 06/11/2006, Alia Atlas wrote:
> --> > >The multi-hop micro-forwarding loops only come up with 
> --> asymmetric link
> --> > >costs.
> --> >
> --> > We used to think that was true, but it is also
> --> > possible to introduce multihop forwarding loops via ECMP.
> --> >
> --> > e.g
> --> >                 D
> --> >               /  \
> --> >          A------B----C
> --> >          |           |
> --> >       E-----------F
> --> >
> --> > All costs 1, except BC = 2 and EF = 10 (both symmetric)
> --> > When AB fails C was previously forwarding to A via both B and D
> --> > After, B forwards via both D and C
> --> > So if a packet gets sent (say) C->B AND B->D we end up 
> --> with a cyclic loop.
> --> 
> --> Interesting case.  When we'd discussed it before, I think 
> --> we'd missed
> --> this ECMP case.
> --> What are the implications for PLSN  with this?  Does your simulator
> --> catch these cases?
> --> 
> --> > >  In TRILL, I believe the assumption is that there aren't
> --> > >asymmetric link costs so that traffic flows are bidirectional.
> --> > >
> --> > >For this case, dropping frames that would transmit 
> --> through the same
> --> > >interface that received it would handle the 
> --> micro-forwarding loops, I
> --> > >believe.
> --> >
> --> > Handle, in the sense of avoiding looping, but of
> --> > course the traffic would be dropped!
> --> 
> --> Sure - but in the absence of a fast-reroute technology, that's what
> --> you need to do on failures.
> --> 
> --> Alia
> --> 
> --> >          Mike
> --> >
> --> >
> --> >
> --> > >Alia
> --> > >
> --> > >On 11/6/06, Pierre Francois <[e-mail]> wrote:
> --> > > > Gray, Eric wrote:
> --> > > > > Pierre,
> --> > > > >
> --> > > > >       The "?loop problem" is apparently an issue 
> --> with some devices where
> --> > > > > reasonable forwarding behavior limitations have 
> --> been "optimized out."  A
> --> > > > > better way to handle the ?loop problem with 
> --> RBridges is not to optimize
> --> > > > > out the behavior that prevents it - i.e. - a 
> --> prohibition against emitting
> --> > > > > a frame on the same interface on which it was received.
> --> > > > >       To be clear, at either the last IETF
> --> > > meeting, or the one just before
> --> > > > > that one, it was made fairly clear that the ?loop 
> --> problem occurs when a
> --> > > > > device sends a PDU out of the same interface on 
> --> which it was received. In
> --> > > > > comparison with simply dropping such a PDU, this 
> --> behavior is pathological
> --> > > > > - particularly in the case of L2 forwarding generally.
> --> > > > >
> --> > > >
> --> > > > That would mean that under a **planned** removal of 
> --> an rbridge-rbridge
> --> > > > link, where the rbridge network could suffer of forwarding
> --> > > > loops, you could drop traffic. Indeed,  "IS-IS like 
> --> FIBs" are updated in
> --> > > > an asynchronous fashion upon topological changes, so 
> --> that transient
> --> > > > inconsistency in the forwarding of
> --> > > > unicast traffic, leading to ?loops,  is something 
> --> that regularly occur.
> --> > > >
> --> > > > Moreover, if you use TE tools to set up the metrics 
> --> of your links, you
> --> > > > might end up with metric(X-->Y) != metric(Y-->X).
> --> > > > In such cases, "longer ?loops", i.e. loops involving 
> --> 3 or 4 rBridges can
> --> > > > occur upon convergence,
> --> > > > in which case the simple "incoming interface 
> --> <>outgoing interface" loop
> --> > > > mitigation check won't work.
> --> > > >
> --> > > > Pierre.
> --> > > > >       I am not saying that we do not need ordered 
> --> FIB for loop prevention
> --> > > > > generally, but we should not need it for the ?loop problem.
> --> > > > >
> --> > > >
> --> > > >
> --> > > > > --
> --> > > > > Eric
> --> > > > >
> --> > > > > --> -----Original Message-----
> --> > > > > --> From: [e-mail]
> --> > > > > --> [mailto:[e-mail]] On Behalf 
> --> Of Pierre Francois
> --> > > > > --> Sent: Monday, November 06, 2006 5:20 PM
> --> > > > > --> To: Sanjay Sane (sanjays)
> --> > > > > --> Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
> --> > > > > --> Subject: Re: [rbridge] Traffic storms
> --> > > > > -->
> --> > > > > -->
> --> > > > > --> Sanjay,
> --> > > > > -->
> --> > > > > --> Sanjay Sane (sanjays) wrote:
> --> > > > > --> > Pierre,
> --> > > > > --> >
> --> > > > > --> > After reading through this paper, it seems the oFIB
> --> > > > > --> mechanism is suited
> --> > > > > --> > towards unicast traffic, or a 
> --> single-destination traffic.
> --> > > > > --> >
> --> > > > > --> > In TRILL, if the plan is to protect the 
> --> traffic storms, we *must*
> --> > > > > --> > protect the transient loops in the "trees" 
> --> that are built to carry
> --> > > > > --> > unknowns/floods, multicast as well as unicast. Such
> --> > > > > --> traffic is targetted
> --> > > > > --> > towards multiple destination, in fact, a tree 
> --> extends to all the
> --> > > > > --> > rbridges.
> --> > > > > --> >
> --> > > > > --> > After thinking a bit, if we think of extending the
> --> > > > > --> mechanisms in the
> --> > > > > --> > paper to cover "trees", we may have to delay the FIB
> --> > > > > --> ordering on all the
> --> > > > > --> > links that are part of the tree on any given rbridge.
> --> > > > > --> This could be very
> --> > > > > --> > inefficient. Do you think the oFIB mechanism would be
> --> > > > > --> suitable for such
> --> > > > > --> > trees?
> --> > > > > --> >
> --> > > > > -->
> --> > > > > --> Applying an "oFIB-like" solution for multicast 
> --> traffic is
> --> > > > > --> something we
> --> > > > > --> are working on.
> --> > > > > --> So, you can make ofib suitable for multicast 
> --> trees, but we
> --> > > > > --> intend to
> --> > > > > --> modify it for efficiency purposes.
> --> > > > > --> btw, you already face the ?loop problem for unicast
> --> > > > > --> traffic, and there
> --> > > > > --> oFIB can be applied as-is by rbridges..
> --> > > > > -->
> --> > > > > --> Pierre.
> --> > > > > --> > -Sanjay
> --> > > > > --> >
> --> > > > > --> >
> --> > > > > --> >
> --> > > > > --> > -----Original Message-----
> --> > > > > --> > From: [e-mail]
> --> > > > > --> [mailto:[e-mail]] On
> --> > > > > --> > Behalf Of Pierre Francois
> --> > > > > --> > Sent: Friday, November 03, 2006 5:10 PM
> --> > > > > --> > To: Silvano Gai
> --> > > > > --> > Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
> --> > > > > --> > Subject: Re: [rbridge] Traffic storms
> --> > > > > --> >
> --> > > > > --> >
> --> > > > > --> > Silvano,
> --> > > > > --> >
> --> > > > > --> > See
> --> > > > > --> >
> --> > > > > --> 
> --> http://www.ietf.org/internet-drafts/draft-francois-ordered-f
> --> > > > > --> ib-02.txt,
> --> > > > > --> > for a loop avoidance mechanism for IS-IS/OSPF.
> --> > > > > --> >
> --> > > > > --> > See you in SD,
> --> > > > > --> >
> --> > > > > --> > Pierre.
> --> > > > > --> >
> --> > > > > --> >
> --> > > > > --> >
> --> > > > > --> > On Fri, 3 Nov 2006, Silvano Gai wrote:
> --> > > > > --> >
> --> > > > > --> >
> --> > > > > --> >> Eric,
> --> > > > > --> >>
> --> > > > > --> >> Also I suggest that people that have solved 
> --> the problem
> --> > > > > --> of having a
> --> > > > > --> >> loop free topology using ISIS, submit 
> --> proposasl so that
> --> > > > > --> we can compare
> --> > > > > --> >>
> --> > > > > --> > them.
> --> > > > > --> >
> --> > > > > --> >> Unfortunately I don't have one.
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >> -- Silvano
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >> ________________________________
> --> > > > > --> >>
> --> > > > > --> >> From: [e-mail]
> --> > > > > --> [mailto:[e-mail]]
> --> > > > > --> >> On Behalf Of Gray, Eric
> --> > > > > --> >> Sent: Friday, November 03, 2006 11:54 AM
> --> > > > > --> >> To: Gideon Kaempfer; Radia Perlman
> --> > > > > --> >> Cc: [e-mail]
> --> > > > > --> >> Subject: Re: [rbridge] Traffic storms
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >> Gideon,
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>     "Drop BPDUs" is not (exactly) the same as ignore
> --> > > > > --> them.  We use the
> --> > > > > --> >>
> --> > > > > --> >
> --> > > > > --> >
> --> > > > > --> >> term
> --> > > > > --> >>
> --> > > > > --> >> as short-hand for the one of three options 
> --> we considered
> --> > > > > --> for handling
> --> > > > > --> >> BPDUs:
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>     Drop (do not participate actively in 
> --> STP, and do not
> --> > > > > --> pass BPDUs
> --> > > > > --> >> through),
> --> > > > > --> >>
> --> > > > > --> >>     Transparent (pass BPDUs through - potentially
> --> > > > > --> altering them in
> --> > > > > --> >> some way),
> --> > > > > --> >>
> --> > > > > --> >>     Participate (have each RBridge 
> --> participate in STP as
> --> > > > > --> if it were a
> --> > > > > --> >> bridge).
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >> Hence, when we say "Drop BPDUs" we are not 
> --> saying that
> --> > > > > --> we cannot look
> --> > > > > --> >>
> --> > > > > --> >> at them, we are just saying that we're not 
> --> doing one of
> --> > > > > --> the other two
> --> > > > > --> >> choices.
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >> --
> --> > > > > --> >>
> --> > > > > --> >> Eric
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >> ________________________________
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>        From: [e-mail]
> --> > > > > --> >> [mailto:[e-mail]] On 
> --> Behalf Of Gideon Kaempfer
> --> > > > > --> >>        Sent: Friday, November 03, 2006 1:40 AM
> --> > > > > --> >>        To: Radia Perlman
> --> > > > > --> >>        Cc: [e-mail]
> --> > > > > --> >>        Subject: Re: [rbridge] Traffic storms
> --> > > > > --> >>
> --> > > > > --> >>        Radia,
> --> > > > > --> >>
> --> > > > > --> >>        Wouldn't this create a link
> --> > > between TRILL and STP we are trying
> --> > > > > --> >>
> --> > > > > --> > to
> --> > > > > --> >
> --> > > > > --> >> avoid?
> --> > > > > --> >>
> --> > > > > --> >>        Relying on the fact that a
> --> > > LAN segment has some kind of unique
> --> > > > > --> >> identifier (such as the root bridge ID) seems like a
> --> > > > > --> very practical
> --> > > > > --> >> solution to me, but strongly reliant on the fact that
> --> > > > > --> the Rbridges
> --> > > > > --> >> actually process BPDUs. I thought they were 
> --> just meant to discard
> --> > > > > --> >>
> --> > > > > --> > them.
> --> > > > > --> >
> --> > > > > --> >> Is this acceptable?
> --> > > > > --> >>
> --> > > > > --> >>        Regrads,
> --> > > > > --> >>
> --> > > > > --> >>         Gidi
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>        On 11/3/06, Radia Perlman 
> --> <[e-mail]> wrote:
> --> > > > > --> >>
> --> > > > > --> >>        The simplest way to put it, I think, 
> --> is that in certain
> --> > > > > --> >>
> --> > > > > --> > transitory
> --> > > > > --> >
> --> > > > > --> >>        situations there might be two
> --> > > > > --> >>        RBridges that both think they
> --> > > are Designated RBridge, and that
> --> > > > > --> >>
> --> > > > > --> > is
> --> > > > > --> >
> --> > > > > --> >> bad,
> --> > > > > --> >>        but should stop
> --> > > > > --> >>        as soon as a single Hello is
> --> > > received by the RBridge who should
> --> > > > > --> >>
> --> > > > > --> > not
> --> > > > > --> >
> --> > > > > --> >> be
> --> > > > > --> >>        Designated.
> --> > > > > --> >>
> --> > > > > --> >>        I think PIM has similar
> --> > > transitory situations that can occur,
> --> > > > > --> >>
> --> > > > > --> > and
> --> > > > > --> >
> --> > > > > --> >>        bridges can also have (hopefully
> --> > > > > --> >>        temporary) problems if a
> --> > > repeater came up and merged two LANs. I
> --> > > > > --> >>
> --> > > > > --> >
> --> > > > > --> >
> --> > > > > --> >> think
> --> > > > > --> >>        such things are
> --> > > > > --> >>        annoying but not fatal. But I
> --> > > think it's possible we can with
> --> > > > > --> >>
> --> > > > > --> > little
> --> > > > > --> >
> --> > > > > --> >>        effort avoid this problem.
> --> > > > > --> >>
> --> > > > > --> >>        However, with RBridges, because the 
> --> bridge spanning tree
> --> > > > > --> >>
> --> > > > > --> > algorithm
> --> > > > > --> >
> --> > > > > --> >>        elects a Root, there's
> --> > > > > --> >>        really a way of uniquely
> --> > > identifying a LAN (where "LAN" is a
> --> > > > > --> >>
> --> > > > > --> > bunch of
> --> > > > > --> >
> --> > > > > --> >>        links connected with
> --> > > > > --> >>        bridges). The unique identifier is 
> --> the root bridge.
> --> > > > > --> >>
> --> > > > > --> >>        When the B1-B2 link is down,
> --> > > RB1 and RB2 will see the topology
> --> > > > > --> >>
> --> > > > > --> > as two
> --> > > > > --> >
> --> > > > > --> >>        separate links, and each
> --> > > > > --> >>        one will have a distinct
> --> > > spanning tree Root bridge (RB1 will see
> --> > > > > --> >>
> --> > > > > --> > B1,
> --> > > > > --> >
> --> > > > > --> >> and
> --> > > > > --> >>        RB2 will see B2 as the root).
> --> > > > > --> >>
> --> > > > > --> >>        When the B1-B2 link comes up,
> --> > > the bridges will first merge the
> --> > > > > --> >>
> --> > > > > --> > two
> --> > > > > --> >
> --> > > > > --> >>        links, and either RB1 or RB2 will
> --> > > > > --> >>        see that the bridge spanning
> --> > > tree root has changed. This will be
> --> > > > > --> >>        discovered before B1 and B2 forward
> --> > > > > --> >>        traffic across the link
> --> > > because of the bridge forwarding delay.
> --> > > > > --> >>        If B1 has better priority as
> --> > > bridge spanning tree root than B2,
> --> > > > > --> >>
> --> > > > > --> > then
> --> > > > > --> >
> --> > > > > --> >> RB1
> --> > > > > --> >>        will not notice anything
> --> > > > > --> >>        different when the B1-B2 link comes 
> --> up. But RB2 will notice
> --> > > > > --> >>        something different; the spanning 
> --> tree root has changed
> --> > > > > --> >>
> --> > > > > --> > identities
> --> > > > > --> >
> --> > > > > --> >> from
> --> > > > > --> >>        "B2" to "B1".
> --> > > > > --> >>
> --> > > > > --> >>        Given this, RB2 could
> --> > > temporarily stop forwarding to or from the
> --> > > > > --> >>
> --> > > > > --> > link
> --> > > > > --> >
> --> > > > > --> >>        when the Root bridge
> --> > > > > --> >>        changes identities, though it
> --> > > should definitely immediately send
> --> > > > > --> >>
> --> > > > > --> >
> --> > > > > --> >
> --> > > > > --> >> IS-IS
> --> > > > > --> >>        Hellos (either RB1 or RB2 will
> --> > > > > --> >>        be elected Designated Router in the 
> --> IS-IS election for that
> --> > > > > --> >>
> --> > > > > --> > link). If
> --> > > > > --> >
> --> > > > > --> >>        RB2 has better prioirty for
> --> > > > > --> >>        root, the RB1 will
> --> > > immediately stop forwarding to or from the
> --> > > > > --> >>
> --> > > > > --> > link
> --> > > > > --> >
> --> > > > > --> >> when
> --> > > > > --> >>        it sees the Hello from RB2.
> --> > > > > --> >>        If RB2 has better priority in the 
> --> IS-IS election, then RB1
> --> > > > > --> >>
> --> > > > > --> > should
> --> > > > > --> >
> --> > > > > --> >>        immediately send an IS-IS Hello
> --> > > > > --> >>        when it sees a Hello from a new 
> --> RBridge on the link.
> --> > > > > --> >>
> --> > > > > --> >>        So I think this is not a big
> --> > > deal, and that if we are worried,
> --> > > > > --> >>
> --> > > > > --> > we can
> --> > > > > --> >
> --> > > > > --> >>        specify that an RBridge should
> --> > > > > --> >>        stop acting like the
> --> > > Designated RBridge for a few seconds after
> --> > > > > --> >>
> --> > > > > --> > the
> --> > > > > --> >
> --> > > > > --> >>        identity of the Root in the spanning
> --> > > > > --> >>        tree algorithm changes.
> --> > > > > --> >>
> --> > > > > --> >>        Or we could be even fancier
> --> > > and have each RBridge announce in
> --> > > > > --> >>
> --> > > > > --> > its
> --> > > > > --> >
> --> > > > > --> >> IS-IS
> --> > > > > --> >>        Hellos which LAN IDs it
> --> > > > > --> >>        is Designated for, where a
> --> > > LAN ID is the MAC address of the Root
> --> > > > > --> >>
> --> > > > > --> >
> --> > > > > --> >
> --> > > > > --> >> bridge.
> --> > > > > --> >>        So RB1 continue
> --> > > > > --> >>        forwarding if the identity
> --> > > changes from B1 to B2 provided no
> --> > > > > --> >>
> --> > > > > --> > other
> --> > > > > --> >
> --> > > > > --> >>        RBridge has claimed to be connected
> --> > > > > --> >>        to B2. But if RB2's LSP
> --> > > claims it is attached to B2, then RB1
> --> > > > > --> >>
> --> > > > > --> > must
> --> > > > > --> >
> --> > > > > --> >> stop
> --> > > > > --> >>        forwarding for enough time
> --> > > > > --> >>        for the IS-IS election to sort itself 
> --> out and choose a
> --> > > > > --> >>
> --> > > > > --> > Designated
> --> > > > > --> >
> --> > > > > --> >> RBridge.
> --> > > > > --> >>
> --> > > > > --> >>        Radia
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>        Gideon Kaempfer wrote:
> --> > > > > --> >>
> --> > > > > --> >>        >Following mention by Silvano
> --> > > of broadcast and multicast storms
> --> > > > > --> >>
> --> > > > > --> > (and
> --> > > > > --> >
> --> > > > > --> >> the need
> --> > > > > --> >>        >to protect against them), I played 
> --> around with different
> --> > > > > --> >>
> --> > > > > --> > scenarios
> --> > > > > --> >
> --> > > > > --> >> and came
> --> > > > > --> >>        >upon one I would appreciate
> --> > > your comments on (in the hope I am
> --> > > > > --> >> pointing out
> --> > > > > --> >>        >a non-existent issue with
> --> > > TRILL). I believe a broadcast and
> --> > > > > --> >>
> --> > > > > --> > even a
> --> > > > > --> >
> --> > > > > --> >> unicast
> --> > > > > --> >>        >storm could be created as the result 
> --> of a loop that isn't
> --> > > > > --> >>
> --> > > > > --> > protected
> --> > > > > --> >
> --> > > > > --> >> by TTL
> --> > > > > --> >>        >nor by STP in the case of a
> --> > > link connecting two separate LAN
> --> > > > > --> >> segments coming
> --> > > > > --> >>        >to life.
> --> > > > > --> >>        >
> --> > > > > --> >>        >- RB1 ---- RB2 -
> --> > > > > --> >>        >   |        |
> --> > > > > --> >>        >-  B1 --x-- B2 -
> --> > > > > --> >>        >   |        |
> --> > > > > --> >>        >   H1       H2
> --> > > > > --> >>        >
> --> > > > > --> >>        >1. The network (segment) involved 
> --> consists of two Rbridges
> --> > > > > --> >>
> --> > > > > --> > (RB1,
> --> > > > > --> >
> --> > > > > --> >> RB2), two
> --> > > > > --> >>        >bridges (B1, B2) and two
> --> > > hosts (H1, H2). They are physically
> --> > > > > --> >> connected as
> --> > > > > --> >>        >depicted.
> --> > > > > --> >>        >2. State A: the direct link
> --> > > between B1 and B2 is down. B1 and
> --> > > > > --> >> B2 find
> --> > > > > --> >>        >themselves on different LAN segments 
> --> and hence different
> --> > > > > --> >>
> --> > > > > --> > spanning
> --> > > > > --> >
> --> > > > > --> >> trees. RB1
> --> > > > > --> >>        >and RB2 are both designated
> --> > > Rbridges (each for the segment of
> --> > > > > --> >>
> --> > > > > --> > the
> --> > > > > --> >
> --> > > > > --> >>        >corresponding bridge).
> --> > > > > --> >>        >3. State B: the direct link
> --> > > between B1 and B2 goes up (someone
> --> > > > > --> >> connects a
> --> > > > > --> >>        >cable). B1 and B2 discover
> --> > > each other and establish a common
> --> > > > > --> >> spanning tree.
> --> > > > > --> >>        >RB1 and RB2 both find themselves 
> --> attached to the same LAN
> --> > > > > --> >>
> --> > > > > --> > segment
> --> > > > > --> >
> --> > > > > --> >> and hence
> --> > > > > --> >>        >RB1 (without loss of
> --> > > generality) will eventually become the
> --> > > > > --> >> designated
> --> > > > > --> >>        >Rbridge for it.
> --> > > > > --> >>        >4. Just before RB1 and RB2
> --> > > identify that they are both on the
> --> > > > > --> >>
> --> > > > > --> > same
> --> > > > > --> >
> --> > > > > --> >> segment
> --> > > > > --> >>        >and RB2 stops functioning as
> --> > > a designated Rbridge the following
> --> > > > > --> >>
> --> > > > > --> >
> --> > > > > --> >
> --> > > > > --> >> scenario
> --> > > > > --> >>        >seems possible:
> --> > > > > --> >>        >  a. H1 sends a broadcast frame.
> --> > > > > --> >>        >  b. B1 receives it and forwards to 
> --> RB1 and B2.
> --> > > > > --> >>        >  c. RB1 (encapsulates and) forwards to RB2.
> --> > > > > --> >>        >  d. B2 forwards to RB2 and H2.
> --> > > > > --> >>        >  e. RB2 forwards the copy
> --> > > from RB1 to B2 (and the copy from B2
> --> > > > > --> >>
> --> > > > > --> > to
> --> > > > > --> >
> --> > > > > --> >> RB1).
> --> > > > > --> >>        >  f. (RB1 forwards to B1.)
> --> > > > > --> >>        >  g. B2 forwards (again) to H2 and to B1.
> --> > > > > --> >>        >  h. B1 forwards to H1 (see
> --> > > remark below regarding filtering
> --> > > > > --> >>
> --> > > > > --> > table
> --> > > > > --> >
> --> > > > > --> >>        >contamination) and to RB1.
> --> > > > > --> >>        >  i. Etcetera etcetera.
> --> > > > > --> >>        >5. A broadcast storm is
> --> > > born, created by a loop that is not
> --> > > > > --> >> protected by TTL
> --> > > > > --> >>        >(due to the fact that
> --> > > forwarding between the Rbridges is only
> --> > > > > --> >>
> --> > > > > --> > across
> --> > > > > --> >
> --> > > > > --> >> a
> --> > > > > --> >>        >single hop) nor by STP (due
> --> > > to the fact that Rbridges do not
> --> > > > > --> >> participate in
> --> > > > > --> >>        >STP).
> --> > > > > --> >>        >6. If forwarding commences at the 
> --> hardware level and no
> --> > > > > --> >>
> --> > > > > --> > broadcast
> --> > > > > --> >
> --> > > > > --> >> rate
> --> > > > > --> >>        >limiting is in place, the
> --> > > storm may cause severe damage in a
> --> > > > > --> >>
> --> > > > > --> > very
> --> > > > > --> >
> --> > > > > --> >> short time
> --> > > > > --> >>        >(note that replicated frames are 
> --> sent to H1 and H2 (or any
> --> > > > > --> >>
> --> > > > > --> > network
> --> > > > > --> >
> --> > > > > --> >> they
> --> > > > > --> >>        >could represent).
> --> > > > > --> >>        >7. Another unfortunate
> --> > > effect of this storm is that B1 and B2
> --> > > > > --> >>
> --> > > > > --> > no
> --> > > > > --> >
> --> > > > > --> >> longer know
> --> > > > > --> >>        >where H1 is located (due to the 
> --> contamination of their
> --> > > > > --> >>
> --> > > > > --> > filtering
> --> > > > > --> >
> --> > > > > --> >> tables by a
> --> > > > > --> >>        >frame from H1 that arrives
> --> > > from the wrong direction (and in
> --> > > > > --> >>
> --> > > > > --> > fact
> --> > > > > --> >
> --> > > > > --> >> from
> --> > > > > --> >>        >multiple directions). As a
> --> > > result, a possible unicast frame
> --> > > > > --> >>
> --> > > > > --> > from H2
> --> > > > > --> >
> --> > > > > --> >> to H1
> --> > > > > --> >>        >will just join the storm over the 
> --> loop at least in one
> --> > > > > --> >>
> --> > > > > --> > direction
> --> > > > > --> >
> --> > > > > --> >> (RB2 will
> --> > > > > --> >>        >forward it to RB1) but will not 
> --> arrive at H1...
> --> > > > > --> >>        >
> --> > > > > --> >>        >One possible solution could
> --> > > be for RB2 to identify the fact
> --> > > > > --> >>
> --> > > > > --> > that it
> --> > > > > --> >
> --> > > > > --> >> is
> --> > > > > --> >>        >receiving a frame from a host with a 
> --> MAC address that is
> --> > > > > --> >>
> --> > > > > --> > associated
> --> > > > > --> >
> --> > > > > --> >> with a
> --> > > > > --> >>        >segment it thought it isn't
> --> > > connected to. Hence, it may trigger
> --> > > > > --> >>
> --> > > > > --> > an
> --> > > > > --> >
> --> > > > > --> >> immediate
> --> > > > > --> >>        >neighbor discovery / designated 
> --> Rbridge election. However,
> --> > > > > --> >>
> --> > > > > --> > because
> --> > > > > --> >
> --> > > > > --> >> Rbridges
> --> > > > > --> >>        >should allow host mobility,
> --> > > this frame may need to be forwarded
> --> > > > > --> >>
> --> > > > > --> > (and
> --> > > > > --> >
> --> > > > > --> >> hence
> --> > > > > --> >>        >the storm commences).
> --> > > > > --> >>        >
> --> > > > > --> >>        >As mentioned above, any comments are welcome.
> --> > > > > --> >>        >  Gideon Kaempfer
> --> > > > > --> >>        >
> --> > > > > --> >>        
> --> >_______________________________________________
> --> > > > > --> >>        >rbridge mailing list
> --> > > > > --> >>        >[e-mail]
> --> > > > > --> >>        > 
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> > > > > --> >> <http://mailman.postel.org/mailman/listinfo/rbridge>
> --> > > > > --> >>        >
> --> > > > > --> >>        >
> --> > > > > --> >>
> --> > > > > --> >>        
> --> _______________________________________________
> --> > > > > --> >>        rbridge mailing list
> --> > > > > --> >>        [e-mail]
> --> > > > > --> >>        
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> >>
> --> > > > > --> > _______________________________________________
> --> > > > > --> > rbridge mailing list
> --> > > > > --> > [e-mail]
> --> > > > > --> > http://mailman.postel.org/mailman/listinfo/rbridge
> --> > > > > --> >
> --> > > > > --> >
> --> > > > > -->
> --> > > > > --> _______________________________________________
> --> > > > > --> rbridge mailing list
> --> > > > > --> [e-mail]
> --> > > > > --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> > > > > -->
> --> > > > >
> --> > > > >
> --> > > >
> --> > > > _______________________________________________
> --> > > > rbridge mailing list
> --> > > > [e-mail]
> --> > > > http://mailman.postel.org/mailman/listinfo/rbridge
> --> > > >
> --> > >
> --> > >_______________________________________________
> --> > >rbridge mailing list
> --> > >[e-mail]
> --> > >http://mailman.postel.org/mailman/listinfo/rbridge
> --> >
> --> 
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> 
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA8Ls1xf001208 for <[e-mail]>; Wed, 8 Nov 2006 13:54:02 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA8LrqfK029270; Wed, 8 Nov 2006 16:53:52 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA01169;  Wed, 8 Nov 2006 16:53:52 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB640Q26>; Wed, 8 Nov 2006 16:53:51 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Alia Atlas <[e-mail]>, mike shand <[e-mail]>
Date: Wed, 8 Nov 2006 16:53:45 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA8Ls1xf001208
Cc: [e-mail], Gideon Kaempfer <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 08 Nov 2006 21:55:03 -0000
Status: RO
Content-Length: 26943

Mike,

	To add one point to what Alia said, we need to make up our
minds what we want the failure mode to be (or - shudder - what the
options should be for different deployment scenarios).

	At yesterday's meeting, there was substantial support for a
failure mode that "prefers" drop behavior to "clever-ness."  I can
think of no good reason why this should be the model in some cases
and not in others.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Alia Atlas
--> Sent: Wednesday, November 08, 2006 4:43 PM
--> To: mike shand
--> Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
--> Subject: Re: [rbridge] Traffic storms
--> 
--> On 11/8/06, mike shand <[e-mail]> wrote:
--> > At 23:31 06/11/2006, Alia Atlas wrote:
--> > >The multi-hop micro-forwarding loops only come up with 
--> asymmetric link
--> > >costs.
--> >
--> > We used to think that was true, but it is also
--> > possible to introduce multihop forwarding loops via ECMP.
--> >
--> > e.g
--> >                 D
--> >               /  \
--> >          A------B----C
--> >          |           |
--> >       E-----------F
--> >
--> > All costs 1, except BC = 2 and EF = 10 (both symmetric)
--> > When AB fails C was previously forwarding to A via both B and D
--> > After, B forwards via both D and C
--> > So if a packet gets sent (say) C->B AND B->D we end up 
--> with a cyclic loop.
--> 
--> Interesting case.  When we'd discussed it before, I think 
--> we'd missed
--> this ECMP case.
--> What are the implications for PLSN  with this?  Does your simulator
--> catch these cases?
--> 
--> > >  In TRILL, I believe the assumption is that there aren't
--> > >asymmetric link costs so that traffic flows are bidirectional.
--> > >
--> > >For this case, dropping frames that would transmit 
--> through the same
--> > >interface that received it would handle the 
--> micro-forwarding loops, I
--> > >believe.
--> >
--> > Handle, in the sense of avoiding looping, but of
--> > course the traffic would be dropped!
--> 
--> Sure - but in the absence of a fast-reroute technology, that's what
--> you need to do on failures.
--> 
--> Alia
--> 
--> >          Mike
--> >
--> >
--> >
--> > >Alia
--> > >
--> > >On 11/6/06, Pierre Francois <[e-mail]> wrote:
--> > > > Gray, Eric wrote:
--> > > > > Pierre,
--> > > > >
--> > > > >       The "?loop problem" is apparently an issue 
--> with some devices where
--> > > > > reasonable forwarding behavior limitations have 
--> been "optimized out."  A
--> > > > > better way to handle the ?loop problem with 
--> RBridges is not to optimize
--> > > > > out the behavior that prevents it - i.e. - a 
--> prohibition against emitting
--> > > > > a frame on the same interface on which it was received.
--> > > > >       To be clear, at either the last IETF
--> > > meeting, or the one just before
--> > > > > that one, it was made fairly clear that the ?loop 
--> problem occurs when a
--> > > > > device sends a PDU out of the same interface on 
--> which it was received. In
--> > > > > comparison with simply dropping such a PDU, this 
--> behavior is pathological
--> > > > > - particularly in the case of L2 forwarding generally.
--> > > > >
--> > > >
--> > > > That would mean that under a **planned** removal of 
--> an rbridge-rbridge
--> > > > link, where the rbridge network could suffer of forwarding
--> > > > loops, you could drop traffic. Indeed,  "IS-IS like 
--> FIBs" are updated in
--> > > > an asynchronous fashion upon topological changes, so 
--> that transient
--> > > > inconsistency in the forwarding of
--> > > > unicast traffic, leading to ?loops,  is something 
--> that regularly occur.
--> > > >
--> > > > Moreover, if you use TE tools to set up the metrics 
--> of your links, you
--> > > > might end up with metric(X-->Y) != metric(Y-->X).
--> > > > In such cases, "longer ?loops", i.e. loops involving 
--> 3 or 4 rBridges can
--> > > > occur upon convergence,
--> > > > in which case the simple "incoming interface 
--> <>outgoing interface" loop
--> > > > mitigation check won't work.
--> > > >
--> > > > Pierre.
--> > > > >       I am not saying that we do not need ordered 
--> FIB for loop prevention
--> > > > > generally, but we should not need it for the ?loop problem.
--> > > > >
--> > > >
--> > > >
--> > > > > --
--> > > > > Eric
--> > > > >
--> > > > > --> -----Original Message-----
--> > > > > --> From: [e-mail]
--> > > > > --> [mailto:[e-mail]] On Behalf 
--> Of Pierre Francois
--> > > > > --> Sent: Monday, November 06, 2006 5:20 PM
--> > > > > --> To: Sanjay Sane (sanjays)
--> > > > > --> Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
--> > > > > --> Subject: Re: [rbridge] Traffic storms
--> > > > > -->
--> > > > > -->
--> > > > > --> Sanjay,
--> > > > > -->
--> > > > > --> Sanjay Sane (sanjays) wrote:
--> > > > > --> > Pierre,
--> > > > > --> >
--> > > > > --> > After reading through this paper, it seems the oFIB
--> > > > > --> mechanism is suited
--> > > > > --> > towards unicast traffic, or a 
--> single-destination traffic.
--> > > > > --> >
--> > > > > --> > In TRILL, if the plan is to protect the 
--> traffic storms, we *must*
--> > > > > --> > protect the transient loops in the "trees" 
--> that are built to carry
--> > > > > --> > unknowns/floods, multicast as well as unicast. Such
--> > > > > --> traffic is targetted
--> > > > > --> > towards multiple destination, in fact, a tree 
--> extends to all the
--> > > > > --> > rbridges.
--> > > > > --> >
--> > > > > --> > After thinking a bit, if we think of extending the
--> > > > > --> mechanisms in the
--> > > > > --> > paper to cover "trees", we may have to delay the FIB
--> > > > > --> ordering on all the
--> > > > > --> > links that are part of the tree on any given rbridge.
--> > > > > --> This could be very
--> > > > > --> > inefficient. Do you think the oFIB mechanism would be
--> > > > > --> suitable for such
--> > > > > --> > trees?
--> > > > > --> >
--> > > > > -->
--> > > > > --> Applying an "oFIB-like" solution for multicast 
--> traffic is
--> > > > > --> something we
--> > > > > --> are working on.
--> > > > > --> So, you can make ofib suitable for multicast 
--> trees, but we
--> > > > > --> intend to
--> > > > > --> modify it for efficiency purposes.
--> > > > > --> btw, you already face the ?loop problem for unicast
--> > > > > --> traffic, and there
--> > > > > --> oFIB can be applied as-is by rbridges..
--> > > > > -->
--> > > > > --> Pierre.
--> > > > > --> > -Sanjay
--> > > > > --> >
--> > > > > --> >
--> > > > > --> >
--> > > > > --> > -----Original Message-----
--> > > > > --> > From: [e-mail]
--> > > > > --> [mailto:[e-mail]] On
--> > > > > --> > Behalf Of Pierre Francois
--> > > > > --> > Sent: Friday, November 03, 2006 5:10 PM
--> > > > > --> > To: Silvano Gai
--> > > > > --> > Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
--> > > > > --> > Subject: Re: [rbridge] Traffic storms
--> > > > > --> >
--> > > > > --> >
--> > > > > --> > Silvano,
--> > > > > --> >
--> > > > > --> > See
--> > > > > --> >
--> > > > > --> 
--> http://www.ietf.org/internet-drafts/draft-francois-ordered-f
--> > > > > --> ib-02.txt,
--> > > > > --> > for a loop avoidance mechanism for IS-IS/OSPF.
--> > > > > --> >
--> > > > > --> > See you in SD,
--> > > > > --> >
--> > > > > --> > Pierre.
--> > > > > --> >
--> > > > > --> >
--> > > > > --> >
--> > > > > --> > On Fri, 3 Nov 2006, Silvano Gai wrote:
--> > > > > --> >
--> > > > > --> >
--> > > > > --> >> Eric,
--> > > > > --> >>
--> > > > > --> >> Also I suggest that people that have solved 
--> the problem
--> > > > > --> of having a
--> > > > > --> >> loop free topology using ISIS, submit 
--> proposasl so that
--> > > > > --> we can compare
--> > > > > --> >>
--> > > > > --> > them.
--> > > > > --> >
--> > > > > --> >> Unfortunately I don't have one.
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >> -- Silvano
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >> ________________________________
--> > > > > --> >>
--> > > > > --> >> From: [e-mail]
--> > > > > --> [mailto:[e-mail]]
--> > > > > --> >> On Behalf Of Gray, Eric
--> > > > > --> >> Sent: Friday, November 03, 2006 11:54 AM
--> > > > > --> >> To: Gideon Kaempfer; Radia Perlman
--> > > > > --> >> Cc: [e-mail]
--> > > > > --> >> Subject: Re: [rbridge] Traffic storms
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >> Gideon,
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>     "Drop BPDUs" is not (exactly) the same as ignore
--> > > > > --> them.  We use the
--> > > > > --> >>
--> > > > > --> >
--> > > > > --> >
--> > > > > --> >> term
--> > > > > --> >>
--> > > > > --> >> as short-hand for the one of three options 
--> we considered
--> > > > > --> for handling
--> > > > > --> >> BPDUs:
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>     Drop (do not participate actively in 
--> STP, and do not
--> > > > > --> pass BPDUs
--> > > > > --> >> through),
--> > > > > --> >>
--> > > > > --> >>     Transparent (pass BPDUs through - potentially
--> > > > > --> altering them in
--> > > > > --> >> some way),
--> > > > > --> >>
--> > > > > --> >>     Participate (have each RBridge 
--> participate in STP as
--> > > > > --> if it were a
--> > > > > --> >> bridge).
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >> Hence, when we say "Drop BPDUs" we are not 
--> saying that
--> > > > > --> we cannot look
--> > > > > --> >>
--> > > > > --> >> at them, we are just saying that we're not 
--> doing one of
--> > > > > --> the other two
--> > > > > --> >> choices.
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >> --
--> > > > > --> >>
--> > > > > --> >> Eric
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >> ________________________________
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>        From: [e-mail]
--> > > > > --> >> [mailto:[e-mail]] On 
--> Behalf Of Gideon Kaempfer
--> > > > > --> >>        Sent: Friday, November 03, 2006 1:40 AM
--> > > > > --> >>        To: Radia Perlman
--> > > > > --> >>        Cc: [e-mail]
--> > > > > --> >>        Subject: Re: [rbridge] Traffic storms
--> > > > > --> >>
--> > > > > --> >>        Radia,
--> > > > > --> >>
--> > > > > --> >>        Wouldn't this create a link
--> > > between TRILL and STP we are trying
--> > > > > --> >>
--> > > > > --> > to
--> > > > > --> >
--> > > > > --> >> avoid?
--> > > > > --> >>
--> > > > > --> >>        Relying on the fact that a
--> > > LAN segment has some kind of unique
--> > > > > --> >> identifier (such as the root bridge ID) seems like a
--> > > > > --> very practical
--> > > > > --> >> solution to me, but strongly reliant on the fact that
--> > > > > --> the Rbridges
--> > > > > --> >> actually process BPDUs. I thought they were 
--> just meant to discard
--> > > > > --> >>
--> > > > > --> > them.
--> > > > > --> >
--> > > > > --> >> Is this acceptable?
--> > > > > --> >>
--> > > > > --> >>        Regrads,
--> > > > > --> >>
--> > > > > --> >>         Gidi
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>        On 11/3/06, Radia Perlman 
--> <[e-mail]> wrote:
--> > > > > --> >>
--> > > > > --> >>        The simplest way to put it, I think, 
--> is that in certain
--> > > > > --> >>
--> > > > > --> > transitory
--> > > > > --> >
--> > > > > --> >>        situations there might be two
--> > > > > --> >>        RBridges that both think they
--> > > are Designated RBridge, and that
--> > > > > --> >>
--> > > > > --> > is
--> > > > > --> >
--> > > > > --> >> bad,
--> > > > > --> >>        but should stop
--> > > > > --> >>        as soon as a single Hello is
--> > > received by the RBridge who should
--> > > > > --> >>
--> > > > > --> > not
--> > > > > --> >
--> > > > > --> >> be
--> > > > > --> >>        Designated.
--> > > > > --> >>
--> > > > > --> >>        I think PIM has similar
--> > > transitory situations that can occur,
--> > > > > --> >>
--> > > > > --> > and
--> > > > > --> >
--> > > > > --> >>        bridges can also have (hopefully
--> > > > > --> >>        temporary) problems if a
--> > > repeater came up and merged two LANs. I
--> > > > > --> >>
--> > > > > --> >
--> > > > > --> >
--> > > > > --> >> think
--> > > > > --> >>        such things are
--> > > > > --> >>        annoying but not fatal. But I
--> > > think it's possible we can with
--> > > > > --> >>
--> > > > > --> > little
--> > > > > --> >
--> > > > > --> >>        effort avoid this problem.
--> > > > > --> >>
--> > > > > --> >>        However, with RBridges, because the 
--> bridge spanning tree
--> > > > > --> >>
--> > > > > --> > algorithm
--> > > > > --> >
--> > > > > --> >>        elects a Root, there's
--> > > > > --> >>        really a way of uniquely
--> > > identifying a LAN (where "LAN" is a
--> > > > > --> >>
--> > > > > --> > bunch of
--> > > > > --> >
--> > > > > --> >>        links connected with
--> > > > > --> >>        bridges). The unique identifier is 
--> the root bridge.
--> > > > > --> >>
--> > > > > --> >>        When the B1-B2 link is down,
--> > > RB1 and RB2 will see the topology
--> > > > > --> >>
--> > > > > --> > as two
--> > > > > --> >
--> > > > > --> >>        separate links, and each
--> > > > > --> >>        one will have a distinct
--> > > spanning tree Root bridge (RB1 will see
--> > > > > --> >>
--> > > > > --> > B1,
--> > > > > --> >
--> > > > > --> >> and
--> > > > > --> >>        RB2 will see B2 as the root).
--> > > > > --> >>
--> > > > > --> >>        When the B1-B2 link comes up,
--> > > the bridges will first merge the
--> > > > > --> >>
--> > > > > --> > two
--> > > > > --> >
--> > > > > --> >>        links, and either RB1 or RB2 will
--> > > > > --> >>        see that the bridge spanning
--> > > tree root has changed. This will be
--> > > > > --> >>        discovered before B1 and B2 forward
--> > > > > --> >>        traffic across the link
--> > > because of the bridge forwarding delay.
--> > > > > --> >>        If B1 has better priority as
--> > > bridge spanning tree root than B2,
--> > > > > --> >>
--> > > > > --> > then
--> > > > > --> >
--> > > > > --> >> RB1
--> > > > > --> >>        will not notice anything
--> > > > > --> >>        different when the B1-B2 link comes 
--> up. But RB2 will notice
--> > > > > --> >>        something different; the spanning 
--> tree root has changed
--> > > > > --> >>
--> > > > > --> > identities
--> > > > > --> >
--> > > > > --> >> from
--> > > > > --> >>        "B2" to "B1".
--> > > > > --> >>
--> > > > > --> >>        Given this, RB2 could
--> > > temporarily stop forwarding to or from the
--> > > > > --> >>
--> > > > > --> > link
--> > > > > --> >
--> > > > > --> >>        when the Root bridge
--> > > > > --> >>        changes identities, though it
--> > > should definitely immediately send
--> > > > > --> >>
--> > > > > --> >
--> > > > > --> >
--> > > > > --> >> IS-IS
--> > > > > --> >>        Hellos (either RB1 or RB2 will
--> > > > > --> >>        be elected Designated Router in the 
--> IS-IS election for that
--> > > > > --> >>
--> > > > > --> > link). If
--> > > > > --> >
--> > > > > --> >>        RB2 has better prioirty for
--> > > > > --> >>        root, the RB1 will
--> > > immediately stop forwarding to or from the
--> > > > > --> >>
--> > > > > --> > link
--> > > > > --> >
--> > > > > --> >> when
--> > > > > --> >>        it sees the Hello from RB2.
--> > > > > --> >>        If RB2 has better priority in the 
--> IS-IS election, then RB1
--> > > > > --> >>
--> > > > > --> > should
--> > > > > --> >
--> > > > > --> >>        immediately send an IS-IS Hello
--> > > > > --> >>        when it sees a Hello from a new 
--> RBridge on the link.
--> > > > > --> >>
--> > > > > --> >>        So I think this is not a big
--> > > deal, and that if we are worried,
--> > > > > --> >>
--> > > > > --> > we can
--> > > > > --> >
--> > > > > --> >>        specify that an RBridge should
--> > > > > --> >>        stop acting like the
--> > > Designated RBridge for a few seconds after
--> > > > > --> >>
--> > > > > --> > the
--> > > > > --> >
--> > > > > --> >>        identity of the Root in the spanning
--> > > > > --> >>        tree algorithm changes.
--> > > > > --> >>
--> > > > > --> >>        Or we could be even fancier
--> > > and have each RBridge announce in
--> > > > > --> >>
--> > > > > --> > its
--> > > > > --> >
--> > > > > --> >> IS-IS
--> > > > > --> >>        Hellos which LAN IDs it
--> > > > > --> >>        is Designated for, where a
--> > > LAN ID is the MAC address of the Root
--> > > > > --> >>
--> > > > > --> >
--> > > > > --> >
--> > > > > --> >> bridge.
--> > > > > --> >>        So RB1 continue
--> > > > > --> >>        forwarding if the identity
--> > > changes from B1 to B2 provided no
--> > > > > --> >>
--> > > > > --> > other
--> > > > > --> >
--> > > > > --> >>        RBridge has claimed to be connected
--> > > > > --> >>        to B2. But if RB2's LSP
--> > > claims it is attached to B2, then RB1
--> > > > > --> >>
--> > > > > --> > must
--> > > > > --> >
--> > > > > --> >> stop
--> > > > > --> >>        forwarding for enough time
--> > > > > --> >>        for the IS-IS election to sort itself 
--> out and choose a
--> > > > > --> >>
--> > > > > --> > Designated
--> > > > > --> >
--> > > > > --> >> RBridge.
--> > > > > --> >>
--> > > > > --> >>        Radia
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>        Gideon Kaempfer wrote:
--> > > > > --> >>
--> > > > > --> >>        >Following mention by Silvano
--> > > of broadcast and multicast storms
--> > > > > --> >>
--> > > > > --> > (and
--> > > > > --> >
--> > > > > --> >> the need
--> > > > > --> >>        >to protect against them), I played 
--> around with different
--> > > > > --> >>
--> > > > > --> > scenarios
--> > > > > --> >
--> > > > > --> >> and came
--> > > > > --> >>        >upon one I would appreciate
--> > > your comments on (in the hope I am
--> > > > > --> >> pointing out
--> > > > > --> >>        >a non-existent issue with
--> > > TRILL). I believe a broadcast and
--> > > > > --> >>
--> > > > > --> > even a
--> > > > > --> >
--> > > > > --> >> unicast
--> > > > > --> >>        >storm could be created as the result 
--> of a loop that isn't
--> > > > > --> >>
--> > > > > --> > protected
--> > > > > --> >
--> > > > > --> >> by TTL
--> > > > > --> >>        >nor by STP in the case of a
--> > > link connecting two separate LAN
--> > > > > --> >> segments coming
--> > > > > --> >>        >to life.
--> > > > > --> >>        >
--> > > > > --> >>        >- RB1 ---- RB2 -
--> > > > > --> >>        >   |        |
--> > > > > --> >>        >-  B1 --x-- B2 -
--> > > > > --> >>        >   |        |
--> > > > > --> >>        >   H1       H2
--> > > > > --> >>        >
--> > > > > --> >>        >1. The network (segment) involved 
--> consists of two Rbridges
--> > > > > --> >>
--> > > > > --> > (RB1,
--> > > > > --> >
--> > > > > --> >> RB2), two
--> > > > > --> >>        >bridges (B1, B2) and two
--> > > hosts (H1, H2). They are physically
--> > > > > --> >> connected as
--> > > > > --> >>        >depicted.
--> > > > > --> >>        >2. State A: the direct link
--> > > between B1 and B2 is down. B1 and
--> > > > > --> >> B2 find
--> > > > > --> >>        >themselves on different LAN segments 
--> and hence different
--> > > > > --> >>
--> > > > > --> > spanning
--> > > > > --> >
--> > > > > --> >> trees. RB1
--> > > > > --> >>        >and RB2 are both designated
--> > > Rbridges (each for the segment of
--> > > > > --> >>
--> > > > > --> > the
--> > > > > --> >
--> > > > > --> >>        >corresponding bridge).
--> > > > > --> >>        >3. State B: the direct link
--> > > between B1 and B2 goes up (someone
--> > > > > --> >> connects a
--> > > > > --> >>        >cable). B1 and B2 discover
--> > > each other and establish a common
--> > > > > --> >> spanning tree.
--> > > > > --> >>        >RB1 and RB2 both find themselves 
--> attached to the same LAN
--> > > > > --> >>
--> > > > > --> > segment
--> > > > > --> >
--> > > > > --> >> and hence
--> > > > > --> >>        >RB1 (without loss of
--> > > generality) will eventually become the
--> > > > > --> >> designated
--> > > > > --> >>        >Rbridge for it.
--> > > > > --> >>        >4. Just before RB1 and RB2
--> > > identify that they are both on the
--> > > > > --> >>
--> > > > > --> > same
--> > > > > --> >
--> > > > > --> >> segment
--> > > > > --> >>        >and RB2 stops functioning as
--> > > a designated Rbridge the following
--> > > > > --> >>
--> > > > > --> >
--> > > > > --> >
--> > > > > --> >> scenario
--> > > > > --> >>        >seems possible:
--> > > > > --> >>        >  a. H1 sends a broadcast frame.
--> > > > > --> >>        >  b. B1 receives it and forwards to 
--> RB1 and B2.
--> > > > > --> >>        >  c. RB1 (encapsulates and) forwards to RB2.
--> > > > > --> >>        >  d. B2 forwards to RB2 and H2.
--> > > > > --> >>        >  e. RB2 forwards the copy
--> > > from RB1 to B2 (and the copy from B2
--> > > > > --> >>
--> > > > > --> > to
--> > > > > --> >
--> > > > > --> >> RB1).
--> > > > > --> >>        >  f. (RB1 forwards to B1.)
--> > > > > --> >>        >  g. B2 forwards (again) to H2 and to B1.
--> > > > > --> >>        >  h. B1 forwards to H1 (see
--> > > remark below regarding filtering
--> > > > > --> >>
--> > > > > --> > table
--> > > > > --> >
--> > > > > --> >>        >contamination) and to RB1.
--> > > > > --> >>        >  i. Etcetera etcetera.
--> > > > > --> >>        >5. A broadcast storm is
--> > > born, created by a loop that is not
--> > > > > --> >> protected by TTL
--> > > > > --> >>        >(due to the fact that
--> > > forwarding between the Rbridges is only
--> > > > > --> >>
--> > > > > --> > across
--> > > > > --> >
--> > > > > --> >> a
--> > > > > --> >>        >single hop) nor by STP (due
--> > > to the fact that Rbridges do not
--> > > > > --> >> participate in
--> > > > > --> >>        >STP).
--> > > > > --> >>        >6. If forwarding commences at the 
--> hardware level and no
--> > > > > --> >>
--> > > > > --> > broadcast
--> > > > > --> >
--> > > > > --> >> rate
--> > > > > --> >>        >limiting is in place, the
--> > > storm may cause severe damage in a
--> > > > > --> >>
--> > > > > --> > very
--> > > > > --> >
--> > > > > --> >> short time
--> > > > > --> >>        >(note that replicated frames are 
--> sent to H1 and H2 (or any
--> > > > > --> >>
--> > > > > --> > network
--> > > > > --> >
--> > > > > --> >> they
--> > > > > --> >>        >could represent).
--> > > > > --> >>        >7. Another unfortunate
--> > > effect of this storm is that B1 and B2
--> > > > > --> >>
--> > > > > --> > no
--> > > > > --> >
--> > > > > --> >> longer know
--> > > > > --> >>        >where H1 is located (due to the 
--> contamination of their
--> > > > > --> >>
--> > > > > --> > filtering
--> > > > > --> >
--> > > > > --> >> tables by a
--> > > > > --> >>        >frame from H1 that arrives
--> > > from the wrong direction (and in
--> > > > > --> >>
--> > > > > --> > fact
--> > > > > --> >
--> > > > > --> >> from
--> > > > > --> >>        >multiple directions). As a
--> > > result, a possible unicast frame
--> > > > > --> >>
--> > > > > --> > from H2
--> > > > > --> >
--> > > > > --> >> to H1
--> > > > > --> >>        >will just join the storm over the 
--> loop at least in one
--> > > > > --> >>
--> > > > > --> > direction
--> > > > > --> >
--> > > > > --> >> (RB2 will
--> > > > > --> >>        >forward it to RB1) but will not 
--> arrive at H1...
--> > > > > --> >>        >
--> > > > > --> >>        >One possible solution could
--> > > be for RB2 to identify the fact
--> > > > > --> >>
--> > > > > --> > that it
--> > > > > --> >
--> > > > > --> >> is
--> > > > > --> >>        >receiving a frame from a host with a 
--> MAC address that is
--> > > > > --> >>
--> > > > > --> > associated
--> > > > > --> >
--> > > > > --> >> with a
--> > > > > --> >>        >segment it thought it isn't
--> > > connected to. Hence, it may trigger
--> > > > > --> >>
--> > > > > --> > an
--> > > > > --> >
--> > > > > --> >> immediate
--> > > > > --> >>        >neighbor discovery / designated 
--> Rbridge election. However,
--> > > > > --> >>
--> > > > > --> > because
--> > > > > --> >
--> > > > > --> >> Rbridges
--> > > > > --> >>        >should allow host mobility,
--> > > this frame may need to be forwarded
--> > > > > --> >>
--> > > > > --> > (and
--> > > > > --> >
--> > > > > --> >> hence
--> > > > > --> >>        >the storm commences).
--> > > > > --> >>        >
--> > > > > --> >>        >As mentioned above, any comments are welcome.
--> > > > > --> >>        >  Gideon Kaempfer
--> > > > > --> >>        >
--> > > > > --> >>        
--> >_______________________________________________
--> > > > > --> >>        >rbridge mailing list
--> > > > > --> >>        >[e-mail]
--> > > > > --> >>        > 
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> > > > > --> >> <http://mailman.postel.org/mailman/listinfo/rbridge>
--> > > > > --> >>        >
--> > > > > --> >>        >
--> > > > > --> >>
--> > > > > --> >>        
--> _______________________________________________
--> > > > > --> >>        rbridge mailing list
--> > > > > --> >>        [e-mail]
--> > > > > --> >>        
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> >>
--> > > > > --> > _______________________________________________
--> > > > > --> > rbridge mailing list
--> > > > > --> > [e-mail]
--> > > > > --> > http://mailman.postel.org/mailman/listinfo/rbridge
--> > > > > --> >
--> > > > > --> >
--> > > > > -->
--> > > > > --> _______________________________________________
--> > > > > --> rbridge mailing list
--> > > > > --> [e-mail]
--> > > > > --> http://mailman.postel.org/mailman/listinfo/rbridge
--> > > > > -->
--> > > > >
--> > > > >
--> > > >
--> > > > _______________________________________________
--> > > > rbridge mailing list
--> > > > [e-mail]
--> > > > http://mailman.postel.org/mailman/listinfo/rbridge
--> > > >
--> > >
--> > >_______________________________________________
--> > >rbridge mailing list
--> > >[e-mail]
--> > >http://mailman.postel.org/mailman/listinfo/rbridge
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 



Received: from smtp-1.dynsipr.ucl.ac.be (smtp.dynsipr.ucl.ac.be [130.104.4.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA8Lmw48028932 for <[e-mail]>; Wed, 8 Nov 2006 13:48:59 -0800 (PST)
Received: from smtp-1.dynsipr.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp-1.dynsipr.ucl.ac.be (Postfix) with ESMTP id 2B77A2C349; Wed,  8 Nov 2006 22:48:52 +0100 (CET)
Received: from [130.129.68.111] (dhcp68-111.ietf67.org [130.129.68.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: [e-mail]) by smtp-1.dynsipr.ucl.ac.be (Postfix) with ESMTP; Wed,  8 Nov 2006 22:48:51 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 08 Nov 2006 13:48:43 -0800
From: Pierre Francois <[e-mail]>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Alia Atlas <[e-mail]>
References: <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-AV-Checked: ClamAV using ClamSMTP
X-SGSI-MailScanner: Found to be clean
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Gideon Kaempfer <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail]
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 08 Nov 2006 21:50:48 -0000
Status: RO
Content-Length: 24120

Alia,

This problem has been raised a while ago, but as far as I remember, we 
found out that it didn't make PLSN rule for "symmetrical
links only" networks incorrect. i.e. you really need asym. link metrics 
to have plsn loop free rules go wrong, ECMP
could not make plsn do bad things.

Pierre.

Alia Atlas wrote:
> On 11/8/06, mike shand <[e-mail]> wrote:
>> At 23:31 06/11/2006, Alia Atlas wrote:
>> >The multi-hop micro-forwarding loops only come up with asymmetric link
>> >costs.
>>
>> We used to think that was true, but it is also
>> possible to introduce multihop forwarding loops via ECMP.
>>
>> e.g
>>                 D
>>               /  \
>>          A------B----C
>>          |           |
>>       E-----------F
>>
>> All costs 1, except BC = 2 and EF = 10 (both symmetric)
>> When AB fails C was previously forwarding to A via both B and D
>> After, B forwards via both D and C
>> So if a packet gets sent (say) C->B AND B->D we end up with a cyclic 
>> loop.
>
> Interesting case.  When we'd discussed it before, I think we'd missed
> this ECMP case.
> What are the implications for PLSN  with this?  Does your simulator
> catch these cases?
>
>> >  In TRILL, I believe the assumption is that there aren't
>> >asymmetric link costs so that traffic flows are bidirectional.
>> >
>> >For this case, dropping frames that would transmit through the same
>> >interface that received it would handle the micro-forwarding loops, I
>> >believe.
>>
>> Handle, in the sense of avoiding looping, but of
>> course the traffic would be dropped!
>
> Sure - but in the absence of a fast-reroute technology, that's what
> you need to do on failures.
>
> Alia
>
>>          Mike
>>
>>
>>
>> >Alia
>> >
>> >On 11/6/06, Pierre Francois <[e-mail]> wrote:
>> > > Gray, Eric wrote:
>> > > > Pierre,
>> > > >
>> > > >       The "?loop problem" is apparently an issue with some 
>> devices where
>> > > > reasonable forwarding behavior limitations have been "optimized 
>> out."  A
>> > > > better way to handle the ?loop problem with RBridges is not to 
>> optimize
>> > > > out the behavior that prevents it - i.e. - a prohibition 
>> against emitting
>> > > > a frame on the same interface on which it was received.
>> > > >       To be clear, at either the last IETF
>> > meeting, or the one just before
>> > > > that one, it was made fairly clear that the ?loop problem 
>> occurs when a
>> > > > device sends a PDU out of the same interface on which it was 
>> received. In
>> > > > comparison with simply dropping such a PDU, this behavior is 
>> pathological
>> > > > - particularly in the case of L2 forwarding generally.
>> > > >
>> > >
>> > > That would mean that under a **planned** removal of an 
>> rbridge-rbridge
>> > > link, where the rbridge network could suffer of forwarding
>> > > loops, you could drop traffic. Indeed,  "IS-IS like FIBs" are 
>> updated in
>> > > an asynchronous fashion upon topological changes, so that transient
>> > > inconsistency in the forwarding of
>> > > unicast traffic, leading to ?loops,  is something that regularly 
>> occur.
>> > >
>> > > Moreover, if you use TE tools to set up the metrics of your 
>> links, you
>> > > might end up with metric(X-->Y) != metric(Y-->X).
>> > > In such cases, "longer ?loops", i.e. loops involving 3 or 4 
>> rBridges can
>> > > occur upon convergence,
>> > > in which case the simple "incoming interface <>outgoing 
>> interface" loop
>> > > mitigation check won't work.
>> > >
>> > > Pierre.
>> > > >       I am not saying that we do not need ordered FIB for loop 
>> prevention
>> > > > generally, but we should not need it for the ?loop problem.
>> > > >
>> > >
>> > >
>> > > > --
>> > > > Eric
>> > > >
>> > > > --> -----Original Message-----
>> > > > --> From: [e-mail]
>> > > > --> [mailto:[e-mail]] On Behalf Of Pierre 
>> Francois
>> > > > --> Sent: Monday, November 06, 2006 5:20 PM
>> > > > --> To: Sanjay Sane (sanjays)
>> > > > --> Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
>> > > > --> Subject: Re: [rbridge] Traffic storms
>> > > > -->
>> > > > -->
>> > > > --> Sanjay,
>> > > > -->
>> > > > --> Sanjay Sane (sanjays) wrote:
>> > > > --> > Pierre,
>> > > > --> >
>> > > > --> > After reading through this paper, it seems the oFIB
>> > > > --> mechanism is suited
>> > > > --> > towards unicast traffic, or a single-destination traffic.
>> > > > --> >
>> > > > --> > In TRILL, if the plan is to protect the traffic storms, 
>> we *must*
>> > > > --> > protect the transient loops in the "trees" that are built 
>> to carry
>> > > > --> > unknowns/floods, multicast as well as unicast. Such
>> > > > --> traffic is targetted
>> > > > --> > towards multiple destination, in fact, a tree extends to 
>> all the
>> > > > --> > rbridges.
>> > > > --> >
>> > > > --> > After thinking a bit, if we think of extending the
>> > > > --> mechanisms in the
>> > > > --> > paper to cover "trees", we may have to delay the FIB
>> > > > --> ordering on all the
>> > > > --> > links that are part of the tree on any given rbridge.
>> > > > --> This could be very
>> > > > --> > inefficient. Do you think the oFIB mechanism would be
>> > > > --> suitable for such
>> > > > --> > trees?
>> > > > --> >
>> > > > -->
>> > > > --> Applying an "oFIB-like" solution for multicast traffic is
>> > > > --> something we
>> > > > --> are working on.
>> > > > --> So, you can make ofib suitable for multicast trees, but we
>> > > > --> intend to
>> > > > --> modify it for efficiency purposes.
>> > > > --> btw, you already face the ?loop problem for unicast
>> > > > --> traffic, and there
>> > > > --> oFIB can be applied as-is by rbridges..
>> > > > -->
>> > > > --> Pierre.
>> > > > --> > -Sanjay
>> > > > --> >
>> > > > --> >
>> > > > --> >
>> > > > --> > -----Original Message-----
>> > > > --> > From: [e-mail]
>> > > > --> [mailto:[e-mail]] On
>> > > > --> > Behalf Of Pierre Francois
>> > > > --> > Sent: Friday, November 03, 2006 5:10 PM
>> > > > --> > To: Silvano Gai
>> > > > --> > Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
>> > > > --> > Subject: Re: [rbridge] Traffic storms
>> > > > --> >
>> > > > --> >
>> > > > --> > Silvano,
>> > > > --> >
>> > > > --> > See
>> > > > --> >
>> > > > --> http://www.ietf.org/internet-drafts/draft-francois-ordered-f
>> > > > --> ib-02.txt,
>> > > > --> > for a loop avoidance mechanism for IS-IS/OSPF.
>> > > > --> >
>> > > > --> > See you in SD,
>> > > > --> >
>> > > > --> > Pierre.
>> > > > --> >
>> > > > --> >
>> > > > --> >
>> > > > --> > On Fri, 3 Nov 2006, Silvano Gai wrote:
>> > > > --> >
>> > > > --> >
>> > > > --> >> Eric,
>> > > > --> >>
>> > > > --> >> Also I suggest that people that have solved the problem
>> > > > --> of having a
>> > > > --> >> loop free topology using ISIS, submit proposasl so that
>> > > > --> we can compare
>> > > > --> >>
>> > > > --> > them.
>> > > > --> >
>> > > > --> >> Unfortunately I don't have one.
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>
>> > > > --> >> -- Silvano
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>
>> > > > --> >> ________________________________
>> > > > --> >>
>> > > > --> >> From: [e-mail]
>> > > > --> [mailto:[e-mail]]
>> > > > --> >> On Behalf Of Gray, Eric
>> > > > --> >> Sent: Friday, November 03, 2006 11:54 AM
>> > > > --> >> To: Gideon Kaempfer; Radia Perlman
>> > > > --> >> Cc: [e-mail]
>> > > > --> >> Subject: Re: [rbridge] Traffic storms
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>
>> > > > --> >> Gideon,
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>     "Drop BPDUs" is not (exactly) the same as ignore
>> > > > --> them.  We use the
>> > > > --> >>
>> > > > --> >
>> > > > --> >
>> > > > --> >> term
>> > > > --> >>
>> > > > --> >> as short-hand for the one of three options we considered
>> > > > --> for handling
>> > > > --> >> BPDUs:
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>     Drop (do not participate actively in STP, and do not
>> > > > --> pass BPDUs
>> > > > --> >> through),
>> > > > --> >>
>> > > > --> >>     Transparent (pass BPDUs through - potentially
>> > > > --> altering them in
>> > > > --> >> some way),
>> > > > --> >>
>> > > > --> >>     Participate (have each RBridge participate in STP as
>> > > > --> if it were a
>> > > > --> >> bridge).
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>
>> > > > --> >> Hence, when we say "Drop BPDUs" we are not saying that
>> > > > --> we cannot look
>> > > > --> >>
>> > > > --> >> at them, we are just saying that we're not doing one of
>> > > > --> the other two
>> > > > --> >> choices.
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>
>> > > > --> >> --
>> > > > --> >>
>> > > > --> >> Eric
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>
>> > > > --> >> ________________________________
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>        From: [e-mail]
>> > > > --> >> [mailto:[e-mail]] On Behalf Of Gideon 
>> Kaempfer
>> > > > --> >>        Sent: Friday, November 03, 2006 1:40 AM
>> > > > --> >>        To: Radia Perlman
>> > > > --> >>        Cc: [e-mail]
>> > > > --> >>        Subject: Re: [rbridge] Traffic storms
>> > > > --> >>
>> > > > --> >>        Radia,
>> > > > --> >>
>> > > > --> >>        Wouldn't this create a link
>> > between TRILL and STP we are trying
>> > > > --> >>
>> > > > --> > to
>> > > > --> >
>> > > > --> >> avoid?
>> > > > --> >>
>> > > > --> >>        Relying on the fact that a
>> > LAN segment has some kind of unique
>> > > > --> >> identifier (such as the root bridge ID) seems like a
>> > > > --> very practical
>> > > > --> >> solution to me, but strongly reliant on the fact that
>> > > > --> the Rbridges
>> > > > --> >> actually process BPDUs. I thought they were just meant 
>> to discard
>> > > > --> >>
>> > > > --> > them.
>> > > > --> >
>> > > > --> >> Is this acceptable?
>> > > > --> >>
>> > > > --> >>        Regrads,
>> > > > --> >>
>> > > > --> >>         Gidi
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>        On 11/3/06, Radia Perlman <[e-mail]> 
>> wrote:
>> > > > --> >>
>> > > > --> >>        The simplest way to put it, I think, is that in 
>> certain
>> > > > --> >>
>> > > > --> > transitory
>> > > > --> >
>> > > > --> >>        situations there might be two
>> > > > --> >>        RBridges that both think they
>> > are Designated RBridge, and that
>> > > > --> >>
>> > > > --> > is
>> > > > --> >
>> > > > --> >> bad,
>> > > > --> >>        but should stop
>> > > > --> >>        as soon as a single Hello is
>> > received by the RBridge who should
>> > > > --> >>
>> > > > --> > not
>> > > > --> >
>> > > > --> >> be
>> > > > --> >>        Designated.
>> > > > --> >>
>> > > > --> >>        I think PIM has similar
>> > transitory situations that can occur,
>> > > > --> >>
>> > > > --> > and
>> > > > --> >
>> > > > --> >>        bridges can also have (hopefully
>> > > > --> >>        temporary) problems if a
>> > repeater came up and merged two LANs. I
>> > > > --> >>
>> > > > --> >
>> > > > --> >
>> > > > --> >> think
>> > > > --> >>        such things are
>> > > > --> >>        annoying but not fatal. But I
>> > think it's possible we can with
>> > > > --> >>
>> > > > --> > little
>> > > > --> >
>> > > > --> >>        effort avoid this problem.
>> > > > --> >>
>> > > > --> >>        However, with RBridges, because the bridge 
>> spanning tree
>> > > > --> >>
>> > > > --> > algorithm
>> > > > --> >
>> > > > --> >>        elects a Root, there's
>> > > > --> >>        really a way of uniquely
>> > identifying a LAN (where "LAN" is a
>> > > > --> >>
>> > > > --> > bunch of
>> > > > --> >
>> > > > --> >>        links connected with
>> > > > --> >>        bridges). The unique identifier is the root bridge.
>> > > > --> >>
>> > > > --> >>        When the B1-B2 link is down,
>> > RB1 and RB2 will see the topology
>> > > > --> >>
>> > > > --> > as two
>> > > > --> >
>> > > > --> >>        separate links, and each
>> > > > --> >>        one will have a distinct
>> > spanning tree Root bridge (RB1 will see
>> > > > --> >>
>> > > > --> > B1,
>> > > > --> >
>> > > > --> >> and
>> > > > --> >>        RB2 will see B2 as the root).
>> > > > --> >>
>> > > > --> >>        When the B1-B2 link comes up,
>> > the bridges will first merge the
>> > > > --> >>
>> > > > --> > two
>> > > > --> >
>> > > > --> >>        links, and either RB1 or RB2 will
>> > > > --> >>        see that the bridge spanning
>> > tree root has changed. This will be
>> > > > --> >>        discovered before B1 and B2 forward
>> > > > --> >>        traffic across the link
>> > because of the bridge forwarding delay.
>> > > > --> >>        If B1 has better priority as
>> > bridge spanning tree root than B2,
>> > > > --> >>
>> > > > --> > then
>> > > > --> >
>> > > > --> >> RB1
>> > > > --> >>        will not notice anything
>> > > > --> >>        different when the B1-B2 link comes up. But RB2 
>> will notice
>> > > > --> >>        something different; the spanning tree root has 
>> changed
>> > > > --> >>
>> > > > --> > identities
>> > > > --> >
>> > > > --> >> from
>> > > > --> >>        "B2" to "B1".
>> > > > --> >>
>> > > > --> >>        Given this, RB2 could
>> > temporarily stop forwarding to or from the
>> > > > --> >>
>> > > > --> > link
>> > > > --> >
>> > > > --> >>        when the Root bridge
>> > > > --> >>        changes identities, though it
>> > should definitely immediately send
>> > > > --> >>
>> > > > --> >
>> > > > --> >
>> > > > --> >> IS-IS
>> > > > --> >>        Hellos (either RB1 or RB2 will
>> > > > --> >>        be elected Designated Router in the IS-IS 
>> election for that
>> > > > --> >>
>> > > > --> > link). If
>> > > > --> >
>> > > > --> >>        RB2 has better prioirty for
>> > > > --> >>        root, the RB1 will
>> > immediately stop forwarding to or from the
>> > > > --> >>
>> > > > --> > link
>> > > > --> >
>> > > > --> >> when
>> > > > --> >>        it sees the Hello from RB2.
>> > > > --> >>        If RB2 has better priority in the IS-IS election, 
>> then RB1
>> > > > --> >>
>> > > > --> > should
>> > > > --> >
>> > > > --> >>        immediately send an IS-IS Hello
>> > > > --> >>        when it sees a Hello from a new RBridge on the link.
>> > > > --> >>
>> > > > --> >>        So I think this is not a big
>> > deal, and that if we are worried,
>> > > > --> >>
>> > > > --> > we can
>> > > > --> >
>> > > > --> >>        specify that an RBridge should
>> > > > --> >>        stop acting like the
>> > Designated RBridge for a few seconds after
>> > > > --> >>
>> > > > --> > the
>> > > > --> >
>> > > > --> >>        identity of the Root in the spanning
>> > > > --> >>        tree algorithm changes.
>> > > > --> >>
>> > > > --> >>        Or we could be even fancier
>> > and have each RBridge announce in
>> > > > --> >>
>> > > > --> > its
>> > > > --> >
>> > > > --> >> IS-IS
>> > > > --> >>        Hellos which LAN IDs it
>> > > > --> >>        is Designated for, where a
>> > LAN ID is the MAC address of the Root
>> > > > --> >>
>> > > > --> >
>> > > > --> >
>> > > > --> >> bridge.
>> > > > --> >>        So RB1 continue
>> > > > --> >>        forwarding if the identity
>> > changes from B1 to B2 provided no
>> > > > --> >>
>> > > > --> > other
>> > > > --> >
>> > > > --> >>        RBridge has claimed to be connected
>> > > > --> >>        to B2. But if RB2's LSP
>> > claims it is attached to B2, then RB1
>> > > > --> >>
>> > > > --> > must
>> > > > --> >
>> > > > --> >> stop
>> > > > --> >>        forwarding for enough time
>> > > > --> >>        for the IS-IS election to sort itself out and 
>> choose a
>> > > > --> >>
>> > > > --> > Designated
>> > > > --> >
>> > > > --> >> RBridge.
>> > > > --> >>
>> > > > --> >>        Radia
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>        Gideon Kaempfer wrote:
>> > > > --> >>
>> > > > --> >>        >Following mention by Silvano
>> > of broadcast and multicast storms
>> > > > --> >>
>> > > > --> > (and
>> > > > --> >
>> > > > --> >> the need
>> > > > --> >>        >to protect against them), I played around with 
>> different
>> > > > --> >>
>> > > > --> > scenarios
>> > > > --> >
>> > > > --> >> and came
>> > > > --> >>        >upon one I would appreciate
>> > your comments on (in the hope I am
>> > > > --> >> pointing out
>> > > > --> >>        >a non-existent issue with
>> > TRILL). I believe a broadcast and
>> > > > --> >>
>> > > > --> > even a
>> > > > --> >
>> > > > --> >> unicast
>> > > > --> >>        >storm could be created as the result of a loop 
>> that isn't
>> > > > --> >>
>> > > > --> > protected
>> > > > --> >
>> > > > --> >> by TTL
>> > > > --> >>        >nor by STP in the case of a
>> > link connecting two separate LAN
>> > > > --> >> segments coming
>> > > > --> >>        >to life.
>> > > > --> >>        >
>> > > > --> >>        >- RB1 ---- RB2 -
>> > > > --> >>        >   |        |
>> > > > --> >>        >-  B1 --x-- B2 -
>> > > > --> >>        >   |        |
>> > > > --> >>        >   H1       H2
>> > > > --> >>        >
>> > > > --> >>        >1. The network (segment) involved consists of 
>> two Rbridges
>> > > > --> >>
>> > > > --> > (RB1,
>> > > > --> >
>> > > > --> >> RB2), two
>> > > > --> >>        >bridges (B1, B2) and two
>> > hosts (H1, H2). They are physically
>> > > > --> >> connected as
>> > > > --> >>        >depicted.
>> > > > --> >>        >2. State A: the direct link
>> > between B1 and B2 is down. B1 and
>> > > > --> >> B2 find
>> > > > --> >>        >themselves on different LAN segments and hence 
>> different
>> > > > --> >>
>> > > > --> > spanning
>> > > > --> >
>> > > > --> >> trees. RB1
>> > > > --> >>        >and RB2 are both designated
>> > Rbridges (each for the segment of
>> > > > --> >>
>> > > > --> > the
>> > > > --> >
>> > > > --> >>        >corresponding bridge).
>> > > > --> >>        >3. State B: the direct link
>> > between B1 and B2 goes up (someone
>> > > > --> >> connects a
>> > > > --> >>        >cable). B1 and B2 discover
>> > each other and establish a common
>> > > > --> >> spanning tree.
>> > > > --> >>        >RB1 and RB2 both find themselves attached to the 
>> same LAN
>> > > > --> >>
>> > > > --> > segment
>> > > > --> >
>> > > > --> >> and hence
>> > > > --> >>        >RB1 (without loss of
>> > generality) will eventually become the
>> > > > --> >> designated
>> > > > --> >>        >Rbridge for it.
>> > > > --> >>        >4. Just before RB1 and RB2
>> > identify that they are both on the
>> > > > --> >>
>> > > > --> > same
>> > > > --> >
>> > > > --> >> segment
>> > > > --> >>        >and RB2 stops functioning as
>> > a designated Rbridge the following
>> > > > --> >>
>> > > > --> >
>> > > > --> >
>> > > > --> >> scenario
>> > > > --> >>        >seems possible:
>> > > > --> >>        >  a. H1 sends a broadcast frame.
>> > > > --> >>        >  b. B1 receives it and forwards to RB1 and B2.
>> > > > --> >>        >  c. RB1 (encapsulates and) forwards to RB2.
>> > > > --> >>        >  d. B2 forwards to RB2 and H2.
>> > > > --> >>        >  e. RB2 forwards the copy
>> > from RB1 to B2 (and the copy from B2
>> > > > --> >>
>> > > > --> > to
>> > > > --> >
>> > > > --> >> RB1).
>> > > > --> >>        >  f. (RB1 forwards to B1.)
>> > > > --> >>        >  g. B2 forwards (again) to H2 and to B1.
>> > > > --> >>        >  h. B1 forwards to H1 (see
>> > remark below regarding filtering
>> > > > --> >>
>> > > > --> > table
>> > > > --> >
>> > > > --> >>        >contamination) and to RB1.
>> > > > --> >>        >  i. Etcetera etcetera.
>> > > > --> >>        >5. A broadcast storm is
>> > born, created by a loop that is not
>> > > > --> >> protected by TTL
>> > > > --> >>        >(due to the fact that
>> > forwarding between the Rbridges is only
>> > > > --> >>
>> > > > --> > across
>> > > > --> >
>> > > > --> >> a
>> > > > --> >>        >single hop) nor by STP (due
>> > to the fact that Rbridges do not
>> > > > --> >> participate in
>> > > > --> >>        >STP).
>> > > > --> >>        >6. If forwarding commences at the hardware level 
>> and no
>> > > > --> >>
>> > > > --> > broadcast
>> > > > --> >
>> > > > --> >> rate
>> > > > --> >>        >limiting is in place, the
>> > storm may cause severe damage in a
>> > > > --> >>
>> > > > --> > very
>> > > > --> >
>> > > > --> >> short time
>> > > > --> >>        >(note that replicated frames are sent to H1 and 
>> H2 (or any
>> > > > --> >>
>> > > > --> > network
>> > > > --> >
>> > > > --> >> they
>> > > > --> >>        >could represent).
>> > > > --> >>        >7. Another unfortunate
>> > effect of this storm is that B1 and B2
>> > > > --> >>
>> > > > --> > no
>> > > > --> >
>> > > > --> >> longer know
>> > > > --> >>        >where H1 is located (due to the contamination of 
>> their
>> > > > --> >>
>> > > > --> > filtering
>> > > > --> >
>> > > > --> >> tables by a
>> > > > --> >>        >frame from H1 that arrives
>> > from the wrong direction (and in
>> > > > --> >>
>> > > > --> > fact
>> > > > --> >
>> > > > --> >> from
>> > > > --> >>        >multiple directions). As a
>> > result, a possible unicast frame
>> > > > --> >>
>> > > > --> > from H2
>> > > > --> >
>> > > > --> >> to H1
>> > > > --> >>        >will just join the storm over the loop at least 
>> in one
>> > > > --> >>
>> > > > --> > direction
>> > > > --> >
>> > > > --> >> (RB2 will
>> > > > --> >>        >forward it to RB1) but will not arrive at H1...
>> > > > --> >>        >
>> > > > --> >>        >One possible solution could
>> > be for RB2 to identify the fact
>> > > > --> >>
>> > > > --> > that it
>> > > > --> >
>> > > > --> >> is
>> > > > --> >>        >receiving a frame from a host with a MAC address 
>> that is
>> > > > --> >>
>> > > > --> > associated
>> > > > --> >
>> > > > --> >> with a
>> > > > --> >>        >segment it thought it isn't
>> > connected to. Hence, it may trigger
>> > > > --> >>
>> > > > --> > an
>> > > > --> >
>> > > > --> >> immediate
>> > > > --> >>        >neighbor discovery / designated Rbridge 
>> election. However,
>> > > > --> >>
>> > > > --> > because
>> > > > --> >
>> > > > --> >> Rbridges
>> > > > --> >>        >should allow host mobility,
>> > this frame may need to be forwarded
>> > > > --> >>
>> > > > --> > (and
>> > > > --> >
>> > > > --> >> hence
>> > > > --> >>        >the storm commences).
>> > > > --> >>        >
>> > > > --> >>        >As mentioned above, any comments are welcome.
>> > > > --> >>        >  Gideon Kaempfer
>> > > > --> >>        >
>> > > > --> >>        >_______________________________________________
>> > > > --> >>        >rbridge mailing list
>> > > > --> >>        >[e-mail]
>> > > > --> >>        > http://mailman.postel.org/mailman/listinfo/rbridge
>> > > > --> >> <http://mailman.postel.org/mailman/listinfo/rbridge>
>> > > > --> >>        >
>> > > > --> >>        >
>> > > > --> >>
>> > > > --> >>        _______________________________________________
>> > > > --> >>        rbridge mailing list
>> > > > --> >>        [e-mail]
>> > > > --> >>        http://mailman.postel.org/mailman/listinfo/rbridge
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>
>> > > > --> >>
>> > > > --> > _______________________________________________
>> > > > --> > rbridge mailing list
>> > > > --> > [e-mail]
>> > > > --> > http://mailman.postel.org/mailman/listinfo/rbridge
>> > > > --> >
>> > > > --> >
>> > > > -->
>> > > > --> _______________________________________________
>> > > > --> rbridge mailing list
>> > > > --> [e-mail]
>> > > > --> http://mailman.postel.org/mailman/listinfo/rbridge
>> > > > -->
>> > > >
>> > > >
>> > >
>> > > _______________________________________________
>> > > rbridge mailing list
>> > > [e-mail]
>> > > http://mailman.postel.org/mailman/listinfo/rbridge
>> > >
>> >
>> >_______________________________________________
>> >rbridge mailing list
>> >[e-mail]
>> >http://mailman.postel.org/mailman/listinfo/rbridge
>>
>



Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA8LgWvF026261 for <[e-mail]>; Wed, 8 Nov 2006 13:42:32 -0800 (PST)
Received: by wr-out-0506.google.com with SMTP id i3so20861wra for <[e-mail]>; Wed, 08 Nov 2006 13:42:31 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=E8O1hwKMhqq/XlTynZxDeL3Dm1C0+oowAw9fq2ig4dEvwWOUAxyC9xh3EzKR066daECtgj6VDbDHL3U+MT7Pi00hQNDNMdpu3thmM5CZoDRcsB6sufWXDTahXpaIpt4tfHLa53ORVb8r9LssDENhTgWOwf1f5zhbp/1GI9EHum4=
Received: by 10.78.185.16 with SMTP id i16mr152227huf.1163022150629; Wed, 08 Nov 2006 13:42:30 -0800 (PST)
Received: by 10.78.90.3 with HTTP; Wed, 8 Nov 2006 13:42:30 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 8 Nov 2006 13:42:30 -0800
From: "Alia Atlas" <[e-mail]>
To: "mike shand" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA8LgWvF026261
Cc: [e-mail], Gideon Kaempfer <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 08 Nov 2006 21:43:12 -0000
Status: RO
Content-Length: 22931

On 11/8/06, mike shand <[e-mail]> wrote:
> At 23:31 06/11/2006, Alia Atlas wrote:
> >The multi-hop micro-forwarding loops only come up with asymmetric link
> >costs.
>
> We used to think that was true, but it is also
> possible to introduce multihop forwarding loops via ECMP.
>
> e.g
>                 D
>               /  \
>          A------B----C
>          |           |
>       E-----------F
>
> All costs 1, except BC = 2 and EF = 10 (both symmetric)
> When AB fails C was previously forwarding to A via both B and D
> After, B forwards via both D and C
> So if a packet gets sent (say) C->B AND B->D we end up with a cyclic loop.

Interesting case.  When we'd discussed it before, I think we'd missed
this ECMP case.
What are the implications for PLSN  with this?  Does your simulator
catch these cases?

> >  In TRILL, I believe the assumption is that there aren't
> >asymmetric link costs so that traffic flows are bidirectional.
> >
> >For this case, dropping frames that would transmit through the same
> >interface that received it would handle the micro-forwarding loops, I
> >believe.
>
> Handle, in the sense of avoiding looping, but of
> course the traffic would be dropped!

Sure - but in the absence of a fast-reroute technology, that's what
you need to do on failures.

Alia

>          Mike
>
>
>
> >Alia
> >
> >On 11/6/06, Pierre Francois <[e-mail]> wrote:
> > > Gray, Eric wrote:
> > > > Pierre,
> > > >
> > > >       The "?loop problem" is apparently an issue with some devices where
> > > > reasonable forwarding behavior limitations have been "optimized out."  A
> > > > better way to handle the ?loop problem with RBridges is not to optimize
> > > > out the behavior that prevents it - i.e. - a prohibition against emitting
> > > > a frame on the same interface on which it was received.
> > > >       To be clear, at either the last IETF
> > meeting, or the one just before
> > > > that one, it was made fairly clear that the ?loop problem occurs when a
> > > > device sends a PDU out of the same interface on which it was received. In
> > > > comparison with simply dropping such a PDU, this behavior is pathological
> > > > - particularly in the case of L2 forwarding generally.
> > > >
> > >
> > > That would mean that under a **planned** removal of an rbridge-rbridge
> > > link, where the rbridge network could suffer of forwarding
> > > loops, you could drop traffic. Indeed,  "IS-IS like FIBs" are updated in
> > > an asynchronous fashion upon topological changes, so that transient
> > > inconsistency in the forwarding of
> > > unicast traffic, leading to ?loops,  is something that regularly occur.
> > >
> > > Moreover, if you use TE tools to set up the metrics of your links, you
> > > might end up with metric(X-->Y) != metric(Y-->X).
> > > In such cases, "longer ?loops", i.e. loops involving 3 or 4 rBridges can
> > > occur upon convergence,
> > > in which case the simple "incoming interface <>outgoing interface" loop
> > > mitigation check won't work.
> > >
> > > Pierre.
> > > >       I am not saying that we do not need ordered FIB for loop prevention
> > > > generally, but we should not need it for the ?loop problem.
> > > >
> > >
> > >
> > > > --
> > > > Eric
> > > >
> > > > --> -----Original Message-----
> > > > --> From: [e-mail]
> > > > --> [mailto:[e-mail]] On Behalf Of Pierre Francois
> > > > --> Sent: Monday, November 06, 2006 5:20 PM
> > > > --> To: Sanjay Sane (sanjays)
> > > > --> Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
> > > > --> Subject: Re: [rbridge] Traffic storms
> > > > -->
> > > > -->
> > > > --> Sanjay,
> > > > -->
> > > > --> Sanjay Sane (sanjays) wrote:
> > > > --> > Pierre,
> > > > --> >
> > > > --> > After reading through this paper, it seems the oFIB
> > > > --> mechanism is suited
> > > > --> > towards unicast traffic, or a single-destination traffic.
> > > > --> >
> > > > --> > In TRILL, if the plan is to protect the traffic storms, we *must*
> > > > --> > protect the transient loops in the "trees" that are built to carry
> > > > --> > unknowns/floods, multicast as well as unicast. Such
> > > > --> traffic is targetted
> > > > --> > towards multiple destination, in fact, a tree extends to all the
> > > > --> > rbridges.
> > > > --> >
> > > > --> > After thinking a bit, if we think of extending the
> > > > --> mechanisms in the
> > > > --> > paper to cover "trees", we may have to delay the FIB
> > > > --> ordering on all the
> > > > --> > links that are part of the tree on any given rbridge.
> > > > --> This could be very
> > > > --> > inefficient. Do you think the oFIB mechanism would be
> > > > --> suitable for such
> > > > --> > trees?
> > > > --> >
> > > > -->
> > > > --> Applying an "oFIB-like" solution for multicast traffic is
> > > > --> something we
> > > > --> are working on.
> > > > --> So, you can make ofib suitable for multicast trees, but we
> > > > --> intend to
> > > > --> modify it for efficiency purposes.
> > > > --> btw, you already face the ?loop problem for unicast
> > > > --> traffic, and there
> > > > --> oFIB can be applied as-is by rbridges..
> > > > -->
> > > > --> Pierre.
> > > > --> > -Sanjay
> > > > --> >
> > > > --> >
> > > > --> >
> > > > --> > -----Original Message-----
> > > > --> > From: [e-mail]
> > > > --> [mailto:[e-mail]] On
> > > > --> > Behalf Of Pierre Francois
> > > > --> > Sent: Friday, November 03, 2006 5:10 PM
> > > > --> > To: Silvano Gai
> > > > --> > Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
> > > > --> > Subject: Re: [rbridge] Traffic storms
> > > > --> >
> > > > --> >
> > > > --> > Silvano,
> > > > --> >
> > > > --> > See
> > > > --> >
> > > > --> http://www.ietf.org/internet-drafts/draft-francois-ordered-f
> > > > --> ib-02.txt,
> > > > --> > for a loop avoidance mechanism for IS-IS/OSPF.
> > > > --> >
> > > > --> > See you in SD,
> > > > --> >
> > > > --> > Pierre.
> > > > --> >
> > > > --> >
> > > > --> >
> > > > --> > On Fri, 3 Nov 2006, Silvano Gai wrote:
> > > > --> >
> > > > --> >
> > > > --> >> Eric,
> > > > --> >>
> > > > --> >> Also I suggest that people that have solved the problem
> > > > --> of having a
> > > > --> >> loop free topology using ISIS, submit proposasl so that
> > > > --> we can compare
> > > > --> >>
> > > > --> > them.
> > > > --> >
> > > > --> >> Unfortunately I don't have one.
> > > > --> >>
> > > > --> >>
> > > > --> >>
> > > > --> >> -- Silvano
> > > > --> >>
> > > > --> >>
> > > > --> >>
> > > > --> >> ________________________________
> > > > --> >>
> > > > --> >> From: [e-mail]
> > > > --> [mailto:[e-mail]]
> > > > --> >> On Behalf Of Gray, Eric
> > > > --> >> Sent: Friday, November 03, 2006 11:54 AM
> > > > --> >> To: Gideon Kaempfer; Radia Perlman
> > > > --> >> Cc: [e-mail]
> > > > --> >> Subject: Re: [rbridge] Traffic storms
> > > > --> >>
> > > > --> >>
> > > > --> >>
> > > > --> >> Gideon,
> > > > --> >>
> > > > --> >>
> > > > --> >>
> > > > --> >>     "Drop BPDUs" is not (exactly) the same as ignore
> > > > --> them.  We use the
> > > > --> >>
> > > > --> >
> > > > --> >
> > > > --> >> term
> > > > --> >>
> > > > --> >> as short-hand for the one of three options we considered
> > > > --> for handling
> > > > --> >> BPDUs:
> > > > --> >>
> > > > --> >>
> > > > --> >>
> > > > --> >>     Drop (do not participate actively in STP, and do not
> > > > --> pass BPDUs
> > > > --> >> through),
> > > > --> >>
> > > > --> >>     Transparent (pass BPDUs through - potentially
> > > > --> altering them in
> > > > --> >> some way),
> > > > --> >>
> > > > --> >>     Participate (have each RBridge participate in STP as
> > > > --> if it were a
> > > > --> >> bridge).
> > > > --> >>
> > > > --> >>
> > > > --> >>
> > > > --> >> Hence, when we say "Drop BPDUs" we are not saying that
> > > > --> we cannot look
> > > > --> >>
> > > > --> >> at them, we are just saying that we're not doing one of
> > > > --> the other two
> > > > --> >> choices.
> > > > --> >>
> > > > --> >>
> > > > --> >>
> > > > --> >> --
> > > > --> >>
> > > > --> >> Eric
> > > > --> >>
> > > > --> >>
> > > > --> >>
> > > > --> >>
> > > > --> >> ________________________________
> > > > --> >>
> > > > --> >>
> > > > --> >>        From: [e-mail]
> > > > --> >> [mailto:[e-mail]] On Behalf Of Gideon Kaempfer
> > > > --> >>        Sent: Friday, November 03, 2006 1:40 AM
> > > > --> >>        To: Radia Perlman
> > > > --> >>        Cc: [e-mail]
> > > > --> >>        Subject: Re: [rbridge] Traffic storms
> > > > --> >>
> > > > --> >>        Radia,
> > > > --> >>
> > > > --> >>        Wouldn't this create a link
> > between TRILL and STP we are trying
> > > > --> >>
> > > > --> > to
> > > > --> >
> > > > --> >> avoid?
> > > > --> >>
> > > > --> >>        Relying on the fact that a
> > LAN segment has some kind of unique
> > > > --> >> identifier (such as the root bridge ID) seems like a
> > > > --> very practical
> > > > --> >> solution to me, but strongly reliant on the fact that
> > > > --> the Rbridges
> > > > --> >> actually process BPDUs. I thought they were just meant to discard
> > > > --> >>
> > > > --> > them.
> > > > --> >
> > > > --> >> Is this acceptable?
> > > > --> >>
> > > > --> >>        Regrads,
> > > > --> >>
> > > > --> >>         Gidi
> > > > --> >>
> > > > --> >>
> > > > --> >>
> > > > --> >>        On 11/3/06, Radia Perlman <[e-mail]> wrote:
> > > > --> >>
> > > > --> >>        The simplest way to put it, I think, is that in certain
> > > > --> >>
> > > > --> > transitory
> > > > --> >
> > > > --> >>        situations there might be two
> > > > --> >>        RBridges that both think they
> > are Designated RBridge, and that
> > > > --> >>
> > > > --> > is
> > > > --> >
> > > > --> >> bad,
> > > > --> >>        but should stop
> > > > --> >>        as soon as a single Hello is
> > received by the RBridge who should
> > > > --> >>
> > > > --> > not
> > > > --> >
> > > > --> >> be
> > > > --> >>        Designated.
> > > > --> >>
> > > > --> >>        I think PIM has similar
> > transitory situations that can occur,
> > > > --> >>
> > > > --> > and
> > > > --> >
> > > > --> >>        bridges can also have (hopefully
> > > > --> >>        temporary) problems if a
> > repeater came up and merged two LANs. I
> > > > --> >>
> > > > --> >
> > > > --> >
> > > > --> >> think
> > > > --> >>        such things are
> > > > --> >>        annoying but not fatal. But I
> > think it's possible we can with
> > > > --> >>
> > > > --> > little
> > > > --> >
> > > > --> >>        effort avoid this problem.
> > > > --> >>
> > > > --> >>        However, with RBridges, because the bridge spanning tree
> > > > --> >>
> > > > --> > algorithm
> > > > --> >
> > > > --> >>        elects a Root, there's
> > > > --> >>        really a way of uniquely
> > identifying a LAN (where "LAN" is a
> > > > --> >>
> > > > --> > bunch of
> > > > --> >
> > > > --> >>        links connected with
> > > > --> >>        bridges). The unique identifier is the root bridge.
> > > > --> >>
> > > > --> >>        When the B1-B2 link is down,
> > RB1 and RB2 will see the topology
> > > > --> >>
> > > > --> > as two
> > > > --> >
> > > > --> >>        separate links, and each
> > > > --> >>        one will have a distinct
> > spanning tree Root bridge (RB1 will see
> > > > --> >>
> > > > --> > B1,
> > > > --> >
> > > > --> >> and
> > > > --> >>        RB2 will see B2 as the root).
> > > > --> >>
> > > > --> >>        When the B1-B2 link comes up,
> > the bridges will first merge the
> > > > --> >>
> > > > --> > two
> > > > --> >
> > > > --> >>        links, and either RB1 or RB2 will
> > > > --> >>        see that the bridge spanning
> > tree root has changed. This will be
> > > > --> >>        discovered before B1 and B2 forward
> > > > --> >>        traffic across the link
> > because of the bridge forwarding delay.
> > > > --> >>        If B1 has better priority as
> > bridge spanning tree root than B2,
> > > > --> >>
> > > > --> > then
> > > > --> >
> > > > --> >> RB1
> > > > --> >>        will not notice anything
> > > > --> >>        different when the B1-B2 link comes up. But RB2 will notice
> > > > --> >>        something different; the spanning tree root has changed
> > > > --> >>
> > > > --> > identities
> > > > --> >
> > > > --> >> from
> > > > --> >>        "B2" to "B1".
> > > > --> >>
> > > > --> >>        Given this, RB2 could
> > temporarily stop forwarding to or from the
> > > > --> >>
> > > > --> > link
> > > > --> >
> > > > --> >>        when the Root bridge
> > > > --> >>        changes identities, though it
> > should definitely immediately send
> > > > --> >>
> > > > --> >
> > > > --> >
> > > > --> >> IS-IS
> > > > --> >>        Hellos (either RB1 or RB2 will
> > > > --> >>        be elected Designated Router in the IS-IS election for that
> > > > --> >>
> > > > --> > link). If
> > > > --> >
> > > > --> >>        RB2 has better prioirty for
> > > > --> >>        root, the RB1 will
> > immediately stop forwarding to or from the
> > > > --> >>
> > > > --> > link
> > > > --> >
> > > > --> >> when
> > > > --> >>        it sees the Hello from RB2.
> > > > --> >>        If RB2 has better priority in the IS-IS election, then RB1
> > > > --> >>
> > > > --> > should
> > > > --> >
> > > > --> >>        immediately send an IS-IS Hello
> > > > --> >>        when it sees a Hello from a new RBridge on the link.
> > > > --> >>
> > > > --> >>        So I think this is not a big
> > deal, and that if we are worried,
> > > > --> >>
> > > > --> > we can
> > > > --> >
> > > > --> >>        specify that an RBridge should
> > > > --> >>        stop acting like the
> > Designated RBridge for a few seconds after
> > > > --> >>
> > > > --> > the
> > > > --> >
> > > > --> >>        identity of the Root in the spanning
> > > > --> >>        tree algorithm changes.
> > > > --> >>
> > > > --> >>        Or we could be even fancier
> > and have each RBridge announce in
> > > > --> >>
> > > > --> > its
> > > > --> >
> > > > --> >> IS-IS
> > > > --> >>        Hellos which LAN IDs it
> > > > --> >>        is Designated for, where a
> > LAN ID is the MAC address of the Root
> > > > --> >>
> > > > --> >
> > > > --> >
> > > > --> >> bridge.
> > > > --> >>        So RB1 continue
> > > > --> >>        forwarding if the identity
> > changes from B1 to B2 provided no
> > > > --> >>
> > > > --> > other
> > > > --> >
> > > > --> >>        RBridge has claimed to be connected
> > > > --> >>        to B2. But if RB2's LSP
> > claims it is attached to B2, then RB1
> > > > --> >>
> > > > --> > must
> > > > --> >
> > > > --> >> stop
> > > > --> >>        forwarding for enough time
> > > > --> >>        for the IS-IS election to sort itself out and choose a
> > > > --> >>
> > > > --> > Designated
> > > > --> >
> > > > --> >> RBridge.
> > > > --> >>
> > > > --> >>        Radia
> > > > --> >>
> > > > --> >>
> > > > --> >>
> > > > --> >>
> > > > --> >>
> > > > --> >>
> > > > --> >>        Gideon Kaempfer wrote:
> > > > --> >>
> > > > --> >>        >Following mention by Silvano
> > of broadcast and multicast storms
> > > > --> >>
> > > > --> > (and
> > > > --> >
> > > > --> >> the need
> > > > --> >>        >to protect against them), I played around with different
> > > > --> >>
> > > > --> > scenarios
> > > > --> >
> > > > --> >> and came
> > > > --> >>        >upon one I would appreciate
> > your comments on (in the hope I am
> > > > --> >> pointing out
> > > > --> >>        >a non-existent issue with
> > TRILL). I believe a broadcast and
> > > > --> >>
> > > > --> > even a
> > > > --> >
> > > > --> >> unicast
> > > > --> >>        >storm could be created as the result of a loop that isn't
> > > > --> >>
> > > > --> > protected
> > > > --> >
> > > > --> >> by TTL
> > > > --> >>        >nor by STP in the case of a
> > link connecting two separate LAN
> > > > --> >> segments coming
> > > > --> >>        >to life.
> > > > --> >>        >
> > > > --> >>        >- RB1 ---- RB2 -
> > > > --> >>        >   |        |
> > > > --> >>        >-  B1 --x-- B2 -
> > > > --> >>        >   |        |
> > > > --> >>        >   H1       H2
> > > > --> >>        >
> > > > --> >>        >1. The network (segment) involved consists of two Rbridges
> > > > --> >>
> > > > --> > (RB1,
> > > > --> >
> > > > --> >> RB2), two
> > > > --> >>        >bridges (B1, B2) and two
> > hosts (H1, H2). They are physically
> > > > --> >> connected as
> > > > --> >>        >depicted.
> > > > --> >>        >2. State A: the direct link
> > between B1 and B2 is down. B1 and
> > > > --> >> B2 find
> > > > --> >>        >themselves on different LAN segments and hence different
> > > > --> >>
> > > > --> > spanning
> > > > --> >
> > > > --> >> trees. RB1
> > > > --> >>        >and RB2 are both designated
> > Rbridges (each for the segment of
> > > > --> >>
> > > > --> > the
> > > > --> >
> > > > --> >>        >corresponding bridge).
> > > > --> >>        >3. State B: the direct link
> > between B1 and B2 goes up (someone
> > > > --> >> connects a
> > > > --> >>        >cable). B1 and B2 discover
> > each other and establish a common
> > > > --> >> spanning tree.
> > > > --> >>        >RB1 and RB2 both find themselves attached to the same LAN
> > > > --> >>
> > > > --> > segment
> > > > --> >
> > > > --> >> and hence
> > > > --> >>        >RB1 (without loss of
> > generality) will eventually become the
> > > > --> >> designated
> > > > --> >>        >Rbridge for it.
> > > > --> >>        >4. Just before RB1 and RB2
> > identify that they are both on the
> > > > --> >>
> > > > --> > same
> > > > --> >
> > > > --> >> segment
> > > > --> >>        >and RB2 stops functioning as
> > a designated Rbridge the following
> > > > --> >>
> > > > --> >
> > > > --> >
> > > > --> >> scenario
> > > > --> >>        >seems possible:
> > > > --> >>        >  a. H1 sends a broadcast frame.
> > > > --> >>        >  b. B1 receives it and forwards to RB1 and B2.
> > > > --> >>        >  c. RB1 (encapsulates and) forwards to RB2.
> > > > --> >>        >  d. B2 forwards to RB2 and H2.
> > > > --> >>        >  e. RB2 forwards the copy
> > from RB1 to B2 (and the copy from B2
> > > > --> >>
> > > > --> > to
> > > > --> >
> > > > --> >> RB1).
> > > > --> >>        >  f. (RB1 forwards to B1.)
> > > > --> >>        >  g. B2 forwards (again) to H2 and to B1.
> > > > --> >>        >  h. B1 forwards to H1 (see
> > remark below regarding filtering
> > > > --> >>
> > > > --> > table
> > > > --> >
> > > > --> >>        >contamination) and to RB1.
> > > > --> >>        >  i. Etcetera etcetera.
> > > > --> >>        >5. A broadcast storm is
> > born, created by a loop that is not
> > > > --> >> protected by TTL
> > > > --> >>        >(due to the fact that
> > forwarding between the Rbridges is only
> > > > --> >>
> > > > --> > across
> > > > --> >
> > > > --> >> a
> > > > --> >>        >single hop) nor by STP (due
> > to the fact that Rbridges do not
> > > > --> >> participate in
> > > > --> >>        >STP).
> > > > --> >>        >6. If forwarding commences at the hardware level and no
> > > > --> >>
> > > > --> > broadcast
> > > > --> >
> > > > --> >> rate
> > > > --> >>        >limiting is in place, the
> > storm may cause severe damage in a
> > > > --> >>
> > > > --> > very
> > > > --> >
> > > > --> >> short time
> > > > --> >>        >(note that replicated frames are sent to H1 and H2 (or any
> > > > --> >>
> > > > --> > network
> > > > --> >
> > > > --> >> they
> > > > --> >>        >could represent).
> > > > --> >>        >7. Another unfortunate
> > effect of this storm is that B1 and B2
> > > > --> >>
> > > > --> > no
> > > > --> >
> > > > --> >> longer know
> > > > --> >>        >where H1 is located (due to the contamination of their
> > > > --> >>
> > > > --> > filtering
> > > > --> >
> > > > --> >> tables by a
> > > > --> >>        >frame from H1 that arrives
> > from the wrong direction (and in
> > > > --> >>
> > > > --> > fact
> > > > --> >
> > > > --> >> from
> > > > --> >>        >multiple directions). As a
> > result, a possible unicast frame
> > > > --> >>
> > > > --> > from H2
> > > > --> >
> > > > --> >> to H1
> > > > --> >>        >will just join the storm over the loop at least in one
> > > > --> >>
> > > > --> > direction
> > > > --> >
> > > > --> >> (RB2 will
> > > > --> >>        >forward it to RB1) but will not arrive at H1...
> > > > --> >>        >
> > > > --> >>        >One possible solution could
> > be for RB2 to identify the fact
> > > > --> >>
> > > > --> > that it
> > > > --> >
> > > > --> >> is
> > > > --> >>        >receiving a frame from a host with a MAC address that is
> > > > --> >>
> > > > --> > associated
> > > > --> >
> > > > --> >> with a
> > > > --> >>        >segment it thought it isn't
> > connected to. Hence, it may trigger
> > > > --> >>
> > > > --> > an
> > > > --> >
> > > > --> >> immediate
> > > > --> >>        >neighbor discovery / designated Rbridge election. However,
> > > > --> >>
> > > > --> > because
> > > > --> >
> > > > --> >> Rbridges
> > > > --> >>        >should allow host mobility,
> > this frame may need to be forwarded
> > > > --> >>
> > > > --> > (and
> > > > --> >
> > > > --> >> hence
> > > > --> >>        >the storm commences).
> > > > --> >>        >
> > > > --> >>        >As mentioned above, any comments are welcome.
> > > > --> >>        >  Gideon Kaempfer
> > > > --> >>        >
> > > > --> >>        >_______________________________________________
> > > > --> >>        >rbridge mailing list
> > > > --> >>        >[e-mail]
> > > > --> >>        > http://mailman.postel.org/mailman/listinfo/rbridge
> > > > --> >> <http://mailman.postel.org/mailman/listinfo/rbridge>
> > > > --> >>        >
> > > > --> >>        >
> > > > --> >>
> > > > --> >>        _______________________________________________
> > > > --> >>        rbridge mailing list
> > > > --> >>        [e-mail]
> > > > --> >>        http://mailman.postel.org/mailman/listinfo/rbridge
> > > > --> >>
> > > > --> >>
> > > > --> >>
> > > > --> >>
> > > > --> >>
> > > > --> > _______________________________________________
> > > > --> > rbridge mailing list
> > > > --> > [e-mail]
> > > > --> > http://mailman.postel.org/mailman/listinfo/rbridge
> > > > --> >
> > > > --> >
> > > > -->
> > > > --> _______________________________________________
> > > > --> rbridge mailing list
> > > > --> [e-mail]
> > > > --> http://mailman.postel.org/mailman/listinfo/rbridge
> > > > -->
> > > >
> > > >
> > >
> > > _______________________________________________
> > > rbridge mailing list
> > > [e-mail]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > >
> >
> >_______________________________________________
> >rbridge mailing list
> >[e-mail]
> >http://mailman.postel.org/mailman/listinfo/rbridge
>



Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA8I2VlM007481 for <[e-mail]>; Wed, 8 Nov 2006 10:02:32 -0800 (PST)
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2006 19:02:31 +0100
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAAAO6pUUWQ/uCKemdsb2JhbACMSwEBCA8q
X-IronPort-AV: i="4.09,401,1157320800";  d="scan'208"; a="118177774:sNHT23501576"
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kA8I2UiL004041;  Wed, 8 Nov 2006 19:02:30 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA8I2S4Z006061;  Wed, 8 Nov 2006 19:02:28 +0100 (MET)
Received: from mshand-wxp.cisco.com (sjc-vpn7-665.cisco.com [10.21.146.153]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA07094; Wed, 8 Nov 2006 18:02:25 GMT
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Wed, 08 Nov 2006 18:01:56 +0000
To: "Alia Atlas" <[e-mail]>
From: mike shand <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
DKIM-Signature: a=rsa-sha1; q=dns; l=564; t=1163008950; x=1163872950; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:mike=20shand=20<[e-mail]> |Subject:Re=3A=20[rbridge]=20Traffic=20storms |Sender:; X=v=3Dcisco.com=3B=20h=3DHib7OKVGQw+kud5n/nfY6HqtzOA=3D; b=Ej6sOWayaMKFkvxF3iV4RFhy2l/XUnyt/e7RUMzqAUn3oxwhUlKpDSwmEsiEfSZFxtfXOEpD ArDFHDABj3+9jcU/cAmzLq5V96EsOBYqP2VAqkQrJFpzb5bOe/3oK0xn;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Gideon Kaempfer <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 08 Nov 2006 18:03:03 -0000
Status: RO
Content-Length: 548

At 17:31 08/11/2006, mike shand wrote:
> >For this case, dropping frames that would transmit through the same
> >interface that received it would handle the micro-forwarding loops, I
> >believe.
>
>Handle, in the sense of avoiding looping, but of
>course the traffic would be dropped!

Sorry, forgot to say...

So this means that where you have ECMP you would have to check for a 
packet received from ANY of the interfaces on which you could 
possibly transmit it, not just the one which you would actually 
choose for this packet.

         Mike


Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA8HWesS026715 for <[e-mail]>; Wed, 8 Nov 2006 09:32:40 -0800 (PST)
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2006 18:32:36 +0100
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAHqhUUWQ/uCLcmdsb2JhbACMTAEJDyo
X-IronPort-AV: i="4.09,401,1157320800";  d="scan'208"; a="118170232:sNHT5532222724"
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kA8HWZAW009020;  Wed, 8 Nov 2006 18:32:35 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA8HWW4Z015046;  Wed, 8 Nov 2006 18:32:32 +0100 (MET)
Received: from mshand-wxp.cisco.com (sjc-vpn7-665.cisco.com [10.21.146.153]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA03968; Wed, 8 Nov 2006 17:32:30 GMT
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Wed, 08 Nov 2006 17:31:40 +0000
To: "Alia Atlas" <[e-mail]>
From: mike shand <[e-mail]>
In-Reply-To: <[e-mail] m>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
DKIM-Signature: a=rsa-sha1; q=dns; l=22172; t=1163007155; x=1163871155; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:mike=20shand=20<[e-mail]> |Subject:Re=3A=20[rbridge]=20Traffic=20storms |Sender:; X=v=3Dcisco.com=3B=20h=3D5nC5YwRKa5uuix5daCshE8rPPPc=3D; b=Pv/Z1mpWmZSGg2ImApXFEftaGbrhSLTU8Xtaxg6UoTHB4p0uQQCuDrzD8kYArvXnP+O0AsQi GNc7R7wv4RHm72G7f2U9gMdK3rElvfZhnrG+pusgFdg2nJjCzkBKD5vl;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA8HWesS026715
Cc: [e-mail], Gideon Kaempfer <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 08 Nov 2006 17:34:40 -0000
Status: RO
Content-Length: 21286

At 23:31 06/11/2006, Alia Atlas wrote:
>The multi-hop micro-forwarding loops only come up with asymmetric link
>costs.

We used to think that was true, but it is also 
possible to introduce multihop forwarding loops via ECMP.

e.g
                D
              /  \
         A------B----C
         |           |
      E-----------F

All costs 1, except BC = 2 and EF = 10 (both symmetric)
When AB fails C was previously forwarding to A via both B and D
After, B forwards via both D and C
So if a packet gets sent (say) C->B AND B->D we end up with a cyclic loop.



>  In TRILL, I believe the assumption is that there aren't
>asymmetric link costs so that traffic flows are bidirectional.
>
>For this case, dropping frames that would transmit through the same
>interface that received it would handle the micro-forwarding loops, I
>believe.

Handle, in the sense of avoiding looping, but of 
course the traffic would be dropped!

         Mike



>Alia
>
>On 11/6/06, Pierre Francois <[e-mail]> wrote:
> > Gray, Eric wrote:
> > > Pierre,
> > >
> > >       The "?loop problem" is apparently an issue with some devices where
> > > reasonable forwarding behavior limitations have been "optimized out."  A
> > > better way to handle the ?loop problem with RBridges is not to optimize
> > > out the behavior that prevents it - i.e. - a prohibition against emitting
> > > a frame on the same interface on which it was received.
> > >       To be clear, at either the last IETF 
> meeting, or the one just before
> > > that one, it was made fairly clear that the ?loop problem occurs when a
> > > device sends a PDU out of the same interface on which it was received. In
> > > comparison with simply dropping such a PDU, this behavior is pathological
> > > - particularly in the case of L2 forwarding generally.
> > >
> >
> > That would mean that under a **planned** removal of an rbridge-rbridge
> > link, where the rbridge network could suffer of forwarding
> > loops, you could drop traffic. Indeed,  "IS-IS like FIBs" are updated in
> > an asynchronous fashion upon topological changes, so that transient
> > inconsistency in the forwarding of
> > unicast traffic, leading to ?loops,  is something that regularly occur.
> >
> > Moreover, if you use TE tools to set up the metrics of your links, you
> > might end up with metric(X-->Y) != metric(Y-->X).
> > In such cases, "longer ?loops", i.e. loops involving 3 or 4 rBridges can
> > occur upon convergence,
> > in which case the simple "incoming interface <>outgoing interface" loop
> > mitigation check won't work.
> >
> > Pierre.
> > >       I am not saying that we do not need ordered FIB for loop prevention
> > > generally, but we should not need it for the ?loop problem.
> > >
> >
> >
> > > --
> > > Eric
> > >
> > > --> -----Original Message-----
> > > --> From: [e-mail]
> > > --> [mailto:[e-mail]] On Behalf Of Pierre Francois
> > > --> Sent: Monday, November 06, 2006 5:20 PM
> > > --> To: Sanjay Sane (sanjays)
> > > --> Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
> > > --> Subject: Re: [rbridge] Traffic storms
> > > -->
> > > -->
> > > --> Sanjay,
> > > -->
> > > --> Sanjay Sane (sanjays) wrote:
> > > --> > Pierre,
> > > --> >
> > > --> > After reading through this paper, it seems the oFIB
> > > --> mechanism is suited
> > > --> > towards unicast traffic, or a single-destination traffic.
> > > --> >
> > > --> > In TRILL, if the plan is to protect the traffic storms, we *must*
> > > --> > protect the transient loops in the "trees" that are built to carry
> > > --> > unknowns/floods, multicast as well as unicast. Such
> > > --> traffic is targetted
> > > --> > towards multiple destination, in fact, a tree extends to all the
> > > --> > rbridges.
> > > --> >
> > > --> > After thinking a bit, if we think of extending the
> > > --> mechanisms in the
> > > --> > paper to cover "trees", we may have to delay the FIB
> > > --> ordering on all the
> > > --> > links that are part of the tree on any given rbridge.
> > > --> This could be very
> > > --> > inefficient. Do you think the oFIB mechanism would be
> > > --> suitable for such
> > > --> > trees?
> > > --> >
> > > -->
> > > --> Applying an "oFIB-like" solution for multicast traffic is
> > > --> something we
> > > --> are working on.
> > > --> So, you can make ofib suitable for multicast trees, but we
> > > --> intend to
> > > --> modify it for efficiency purposes.
> > > --> btw, you already face the ?loop problem for unicast
> > > --> traffic, and there
> > > --> oFIB can be applied as-is by rbridges..
> > > -->
> > > --> Pierre.
> > > --> > -Sanjay
> > > --> >
> > > --> >
> > > --> >
> > > --> > -----Original Message-----
> > > --> > From: [e-mail]
> > > --> [mailto:[e-mail]] On
> > > --> > Behalf Of Pierre Francois
> > > --> > Sent: Friday, November 03, 2006 5:10 PM
> > > --> > To: Silvano Gai
> > > --> > Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
> > > --> > Subject: Re: [rbridge] Traffic storms
> > > --> >
> > > --> >
> > > --> > Silvano,
> > > --> >
> > > --> > See
> > > --> >
> > > --> http://www.ietf.org/internet-drafts/draft-francois-ordered-f
> > > --> ib-02.txt,
> > > --> > for a loop avoidance mechanism for IS-IS/OSPF.
> > > --> >
> > > --> > See you in SD,
> > > --> >
> > > --> > Pierre.
> > > --> >
> > > --> >
> > > --> >
> > > --> > On Fri, 3 Nov 2006, Silvano Gai wrote:
> > > --> >
> > > --> >
> > > --> >> Eric,
> > > --> >>
> > > --> >> Also I suggest that people that have solved the problem
> > > --> of having a
> > > --> >> loop free topology using ISIS, submit proposasl so that
> > > --> we can compare
> > > --> >>
> > > --> > them.
> > > --> >
> > > --> >> Unfortunately I don't have one.
> > > --> >>
> > > --> >>
> > > --> >>
> > > --> >> -- Silvano
> > > --> >>
> > > --> >>
> > > --> >>
> > > --> >> ________________________________
> > > --> >>
> > > --> >> From: [e-mail]
> > > --> [mailto:[e-mail]]
> > > --> >> On Behalf Of Gray, Eric
> > > --> >> Sent: Friday, November 03, 2006 11:54 AM
> > > --> >> To: Gideon Kaempfer; Radia Perlman
> > > --> >> Cc: [e-mail]
> > > --> >> Subject: Re: [rbridge] Traffic storms
> > > --> >>
> > > --> >>
> > > --> >>
> > > --> >> Gideon,
> > > --> >>
> > > --> >>
> > > --> >>
> > > --> >>     "Drop BPDUs" is not (exactly) the same as ignore
> > > --> them.  We use the
> > > --> >>
> > > --> >
> > > --> >
> > > --> >> term
> > > --> >>
> > > --> >> as short-hand for the one of three options we considered
> > > --> for handling
> > > --> >> BPDUs:
> > > --> >>
> > > --> >>
> > > --> >>
> > > --> >>     Drop (do not participate actively in STP, and do not
> > > --> pass BPDUs
> > > --> >> through),
> > > --> >>
> > > --> >>     Transparent (pass BPDUs through - potentially
> > > --> altering them in
> > > --> >> some way),
> > > --> >>
> > > --> >>     Participate (have each RBridge participate in STP as
> > > --> if it were a
> > > --> >> bridge).
> > > --> >>
> > > --> >>
> > > --> >>
> > > --> >> Hence, when we say "Drop BPDUs" we are not saying that
> > > --> we cannot look
> > > --> >>
> > > --> >> at them, we are just saying that we're not doing one of
> > > --> the other two
> > > --> >> choices.
> > > --> >>
> > > --> >>
> > > --> >>
> > > --> >> --
> > > --> >>
> > > --> >> Eric
> > > --> >>
> > > --> >>
> > > --> >>
> > > --> >>
> > > --> >> ________________________________
> > > --> >>
> > > --> >>
> > > --> >>        From: [e-mail]
> > > --> >> [mailto:[e-mail]] On Behalf Of Gideon Kaempfer
> > > --> >>        Sent: Friday, November 03, 2006 1:40 AM
> > > --> >>        To: Radia Perlman
> > > --> >>        Cc: [e-mail]
> > > --> >>        Subject: Re: [rbridge] Traffic storms
> > > --> >>
> > > --> >>        Radia,
> > > --> >>
> > > --> >>        Wouldn't this create a link 
> between TRILL and STP we are trying
> > > --> >>
> > > --> > to
> > > --> >
> > > --> >> avoid?
> > > --> >>
> > > --> >>        Relying on the fact that a 
> LAN segment has some kind of unique
> > > --> >> identifier (such as the root bridge ID) seems like a
> > > --> very practical
> > > --> >> solution to me, but strongly reliant on the fact that
> > > --> the Rbridges
> > > --> >> actually process BPDUs. I thought they were just meant to discard
> > > --> >>
> > > --> > them.
> > > --> >
> > > --> >> Is this acceptable?
> > > --> >>
> > > --> >>        Regrads,
> > > --> >>
> > > --> >>         Gidi
> > > --> >>
> > > --> >>
> > > --> >>
> > > --> >>        On 11/3/06, Radia Perlman <[e-mail]> wrote:
> > > --> >>
> > > --> >>        The simplest way to put it, I think, is that in certain
> > > --> >>
> > > --> > transitory
> > > --> >
> > > --> >>        situations there might be two
> > > --> >>        RBridges that both think they 
> are Designated RBridge, and that
> > > --> >>
> > > --> > is
> > > --> >
> > > --> >> bad,
> > > --> >>        but should stop
> > > --> >>        as soon as a single Hello is 
> received by the RBridge who should
> > > --> >>
> > > --> > not
> > > --> >
> > > --> >> be
> > > --> >>        Designated.
> > > --> >>
> > > --> >>        I think PIM has similar 
> transitory situations that can occur,
> > > --> >>
> > > --> > and
> > > --> >
> > > --> >>        bridges can also have (hopefully
> > > --> >>        temporary) problems if a 
> repeater came up and merged two LANs. I
> > > --> >>
> > > --> >
> > > --> >
> > > --> >> think
> > > --> >>        such things are
> > > --> >>        annoying but not fatal. But I 
> think it's possible we can with
> > > --> >>
> > > --> > little
> > > --> >
> > > --> >>        effort avoid this problem.
> > > --> >>
> > > --> >>        However, with RBridges, because the bridge spanning tree
> > > --> >>
> > > --> > algorithm
> > > --> >
> > > --> >>        elects a Root, there's
> > > --> >>        really a way of uniquely 
> identifying a LAN (where "LAN" is a
> > > --> >>
> > > --> > bunch of
> > > --> >
> > > --> >>        links connected with
> > > --> >>        bridges). The unique identifier is the root bridge.
> > > --> >>
> > > --> >>        When the B1-B2 link is down, 
> RB1 and RB2 will see the topology
> > > --> >>
> > > --> > as two
> > > --> >
> > > --> >>        separate links, and each
> > > --> >>        one will have a distinct 
> spanning tree Root bridge (RB1 will see
> > > --> >>
> > > --> > B1,
> > > --> >
> > > --> >> and
> > > --> >>        RB2 will see B2 as the root).
> > > --> >>
> > > --> >>        When the B1-B2 link comes up, 
> the bridges will first merge the
> > > --> >>
> > > --> > two
> > > --> >
> > > --> >>        links, and either RB1 or RB2 will
> > > --> >>        see that the bridge spanning 
> tree root has changed. This will be
> > > --> >>        discovered before B1 and B2 forward
> > > --> >>        traffic across the link 
> because of the bridge forwarding delay.
> > > --> >>        If B1 has better priority as 
> bridge spanning tree root than B2,
> > > --> >>
> > > --> > then
> > > --> >
> > > --> >> RB1
> > > --> >>        will not notice anything
> > > --> >>        different when the B1-B2 link comes up. But RB2 will notice
> > > --> >>        something different; the spanning tree root has changed
> > > --> >>
> > > --> > identities
> > > --> >
> > > --> >> from
> > > --> >>        "B2" to "B1".
> > > --> >>
> > > --> >>        Given this, RB2 could 
> temporarily stop forwarding to or from the
> > > --> >>
> > > --> > link
> > > --> >
> > > --> >>        when the Root bridge
> > > --> >>        changes identities, though it 
> should definitely immediately send
> > > --> >>
> > > --> >
> > > --> >
> > > --> >> IS-IS
> > > --> >>        Hellos (either RB1 or RB2 will
> > > --> >>        be elected Designated Router in the IS-IS election for that
> > > --> >>
> > > --> > link). If
> > > --> >
> > > --> >>        RB2 has better prioirty for
> > > --> >>        root, the RB1 will 
> immediately stop forwarding to or from the
> > > --> >>
> > > --> > link
> > > --> >
> > > --> >> when
> > > --> >>        it sees the Hello from RB2.
> > > --> >>        If RB2 has better priority in the IS-IS election, then RB1
> > > --> >>
> > > --> > should
> > > --> >
> > > --> >>        immediately send an IS-IS Hello
> > > --> >>        when it sees a Hello from a new RBridge on the link.
> > > --> >>
> > > --> >>        So I think this is not a big 
> deal, and that if we are worried,
> > > --> >>
> > > --> > we can
> > > --> >
> > > --> >>        specify that an RBridge should
> > > --> >>        stop acting like the 
> Designated RBridge for a few seconds after
> > > --> >>
> > > --> > the
> > > --> >
> > > --> >>        identity of the Root in the spanning
> > > --> >>        tree algorithm changes.
> > > --> >>
> > > --> >>        Or we could be even fancier 
> and have each RBridge announce in
> > > --> >>
> > > --> > its
> > > --> >
> > > --> >> IS-IS
> > > --> >>        Hellos which LAN IDs it
> > > --> >>        is Designated for, where a 
> LAN ID is the MAC address of the Root
> > > --> >>
> > > --> >
> > > --> >
> > > --> >> bridge.
> > > --> >>        So RB1 continue
> > > --> >>        forwarding if the identity 
> changes from B1 to B2 provided no
> > > --> >>
> > > --> > other
> > > --> >
> > > --> >>        RBridge has claimed to be connected
> > > --> >>        to B2. But if RB2's LSP 
> claims it is attached to B2, then RB1
> > > --> >>
> > > --> > must
> > > --> >
> > > --> >> stop
> > > --> >>        forwarding for enough time
> > > --> >>        for the IS-IS election to sort itself out and choose a
> > > --> >>
> > > --> > Designated
> > > --> >
> > > --> >> RBridge.
> > > --> >>
> > > --> >>        Radia
> > > --> >>
> > > --> >>
> > > --> >>
> > > --> >>
> > > --> >>
> > > --> >>
> > > --> >>        Gideon Kaempfer wrote:
> > > --> >>
> > > --> >>        >Following mention by Silvano 
> of broadcast and multicast storms
> > > --> >>
> > > --> > (and
> > > --> >
> > > --> >> the need
> > > --> >>        >to protect against them), I played around with different
> > > --> >>
> > > --> > scenarios
> > > --> >
> > > --> >> and came
> > > --> >>        >upon one I would appreciate 
> your comments on (in the hope I am
> > > --> >> pointing out
> > > --> >>        >a non-existent issue with 
> TRILL). I believe a broadcast and
> > > --> >>
> > > --> > even a
> > > --> >
> > > --> >> unicast
> > > --> >>        >storm could be created as the result of a loop that isn't
> > > --> >>
> > > --> > protected
> > > --> >
> > > --> >> by TTL
> > > --> >>        >nor by STP in the case of a 
> link connecting two separate LAN
> > > --> >> segments coming
> > > --> >>        >to life.
> > > --> >>        >
> > > --> >>        >- RB1 ---- RB2 -
> > > --> >>        >   |        |
> > > --> >>        >-  B1 --x-- B2 -
> > > --> >>        >   |        |
> > > --> >>        >   H1       H2
> > > --> >>        >
> > > --> >>        >1. The network (segment) involved consists of two Rbridges
> > > --> >>
> > > --> > (RB1,
> > > --> >
> > > --> >> RB2), two
> > > --> >>        >bridges (B1, B2) and two 
> hosts (H1, H2). They are physically
> > > --> >> connected as
> > > --> >>        >depicted.
> > > --> >>        >2. State A: the direct link 
> between B1 and B2 is down. B1 and
> > > --> >> B2 find
> > > --> >>        >themselves on different LAN segments and hence different
> > > --> >>
> > > --> > spanning
> > > --> >
> > > --> >> trees. RB1
> > > --> >>        >and RB2 are both designated 
> Rbridges (each for the segment of
> > > --> >>
> > > --> > the
> > > --> >
> > > --> >>        >corresponding bridge).
> > > --> >>        >3. State B: the direct link 
> between B1 and B2 goes up (someone
> > > --> >> connects a
> > > --> >>        >cable). B1 and B2 discover 
> each other and establish a common
> > > --> >> spanning tree.
> > > --> >>        >RB1 and RB2 both find themselves attached to the same LAN
> > > --> >>
> > > --> > segment
> > > --> >
> > > --> >> and hence
> > > --> >>        >RB1 (without loss of 
> generality) will eventually become the
> > > --> >> designated
> > > --> >>        >Rbridge for it.
> > > --> >>        >4. Just before RB1 and RB2 
> identify that they are both on the
> > > --> >>
> > > --> > same
> > > --> >
> > > --> >> segment
> > > --> >>        >and RB2 stops functioning as 
> a designated Rbridge the following
> > > --> >>
> > > --> >
> > > --> >
> > > --> >> scenario
> > > --> >>        >seems possible:
> > > --> >>        >  a. H1 sends a broadcast frame.
> > > --> >>        >  b. B1 receives it and forwards to RB1 and B2.
> > > --> >>        >  c. RB1 (encapsulates and) forwards to RB2.
> > > --> >>        >  d. B2 forwards to RB2 and H2.
> > > --> >>        >  e. RB2 forwards the copy 
> from RB1 to B2 (and the copy from B2
> > > --> >>
> > > --> > to
> > > --> >
> > > --> >> RB1).
> > > --> >>        >  f. (RB1 forwards to B1.)
> > > --> >>        >  g. B2 forwards (again) to H2 and to B1.
> > > --> >>        >  h. B1 forwards to H1 (see 
> remark below regarding filtering
> > > --> >>
> > > --> > table
> > > --> >
> > > --> >>        >contamination) and to RB1.
> > > --> >>        >  i. Etcetera etcetera.
> > > --> >>        >5. A broadcast storm is 
> born, created by a loop that is not
> > > --> >> protected by TTL
> > > --> >>        >(due to the fact that 
> forwarding between the Rbridges is only
> > > --> >>
> > > --> > across
> > > --> >
> > > --> >> a
> > > --> >>        >single hop) nor by STP (due 
> to the fact that Rbridges do not
> > > --> >> participate in
> > > --> >>        >STP).
> > > --> >>        >6. If forwarding commences at the hardware level and no
> > > --> >>
> > > --> > broadcast
> > > --> >
> > > --> >> rate
> > > --> >>        >limiting is in place, the 
> storm may cause severe damage in a
> > > --> >>
> > > --> > very
> > > --> >
> > > --> >> short time
> > > --> >>        >(note that replicated frames are sent to H1 and H2 (or any
> > > --> >>
> > > --> > network
> > > --> >
> > > --> >> they
> > > --> >>        >could represent).
> > > --> >>        >7. Another unfortunate 
> effect of this storm is that B1 and B2
> > > --> >>
> > > --> > no
> > > --> >
> > > --> >> longer know
> > > --> >>        >where H1 is located (due to the contamination of their
> > > --> >>
> > > --> > filtering
> > > --> >
> > > --> >> tables by a
> > > --> >>        >frame from H1 that arrives 
> from the wrong direction (and in
> > > --> >>
> > > --> > fact
> > > --> >
> > > --> >> from
> > > --> >>        >multiple directions). As a 
> result, a possible unicast frame
> > > --> >>
> > > --> > from H2
> > > --> >
> > > --> >> to H1
> > > --> >>        >will just join the storm over the loop at least in one
> > > --> >>
> > > --> > direction
> > > --> >
> > > --> >> (RB2 will
> > > --> >>        >forward it to RB1) but will not arrive at H1...
> > > --> >>        >
> > > --> >>        >One possible solution could 
> be for RB2 to identify the fact
> > > --> >>
> > > --> > that it
> > > --> >
> > > --> >> is
> > > --> >>        >receiving a frame from a host with a MAC address that is
> > > --> >>
> > > --> > associated
> > > --> >
> > > --> >> with a
> > > --> >>        >segment it thought it isn't 
> connected to. Hence, it may trigger
> > > --> >>
> > > --> > an
> > > --> >
> > > --> >> immediate
> > > --> >>        >neighbor discovery / designated Rbridge election. However,
> > > --> >>
> > > --> > because
> > > --> >
> > > --> >> Rbridges
> > > --> >>        >should allow host mobility, 
> this frame may need to be forwarded
> > > --> >>
> > > --> > (and
> > > --> >
> > > --> >> hence
> > > --> >>        >the storm commences).
> > > --> >>        >
> > > --> >>        >As mentioned above, any comments are welcome.
> > > --> >>        >  Gideon Kaempfer
> > > --> >>        >
> > > --> >>        >_______________________________________________
> > > --> >>        >rbridge mailing list
> > > --> >>        >[e-mail]
> > > --> >>        > http://mailman.postel.org/mailman/listinfo/rbridge
> > > --> >> <http://mailman.postel.org/mailman/listinfo/rbridge>
> > > --> >>        >
> > > --> >>        >
> > > --> >>
> > > --> >>        _______________________________________________
> > > --> >>        rbridge mailing list
> > > --> >>        [e-mail]
> > > --> >>        http://mailman.postel.org/mailman/listinfo/rbridge
> > > --> >>
> > > --> >>
> > > --> >>
> > > --> >>
> > > --> >>
> > > --> > _______________________________________________
> > > --> > rbridge mailing list
> > > --> > [e-mail]
> > > --> > http://mailman.postel.org/mailman/listinfo/rbridge
> > > --> >
> > > --> >
> > > -->
> > > --> _______________________________________________
> > > --> rbridge mailing list
> > > --> [e-mail]
> > > --> http://mailman.postel.org/mailman/listinfo/rbridge
> > > -->
> > >
> > >
> >
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id kA89S85f018635 for <[e-mail]>; Wed, 8 Nov 2006 01:28:08 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-14.tower-128.messagelabs.com!1162978083!6646036!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [144.189.100.103]
Received: (qmail 21661 invoked from network); 8 Nov 2006 09:28:04 -0000
Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-14.tower-128.messagelabs.com with SMTP; 8 Nov 2006 09:28:04 -0000
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id kA89RxEQ005488 for <[e-mail]>; Wed, 8 Nov 2006 02:28:03 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id kA89RwHB019644 for <[e-mail]>; Wed, 8 Nov 2006 03:27:59 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 8 Nov 2006 04:27:54 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: AccDDTI3KiSXHpAuR22JET0/u/dPTwAB+z+g
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA89S85f018635
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 08 Nov 2006 09:28:52 -0000
Status: RO
Content-Length: 17028

This seems like an intriguing possibility. We would need to get an OUI
to go into the top 24 bits of these addresses. With an OUI we can then
easily allocate our own multicast addresses (all rbridges, etc.) so we
would end up needing one OUI and one Ethertype allocated but nothing
else. (You might think that with these magic addresses, you could
dispense with the TRILL Ethertype but, besides the fact that that would
be non-standard, you can't anyway because, for example, you may need to
insert a VLAN tag and/or other tags between the addresses and the shim.)

Thanks,
Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]
Sent: Wednesday, November 08, 2006 3:02 AM
To: Sanjay Sane (sanjays)
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?

This is an extremely cute proposal, and it works. Let me explain
Sanjay's proposal in different words, in case it doesn't sink in the
first time one sees it.

He is proposing using the shim header that looks like an Ethernet
header, with SA=ingress RBridge MAC R1 and DA=egress RBridge MAC R2, but
solving the two problems brought up at the meeting which were:

a) bridges on an intermedaite link might have previously incorrectly
learned the location of R2, because packets from R2 might have arrived
at the link from different directions.

b) if we avoid problem a) by using different MAC addresses for "to" and
"from" for each RBridge, so that we avoid bridges ever learning the
direction of the egress RBridge, the problem is that we don't benefit
from good bridge learning on the link.

And also, he is proposing making it possible to use that header on a
link with more than 2 RBridges.

The way he's proposing doing it is using the 48 bit Destination and
Source addresses in the Ethernet header in an unconventional way.

Instead of putting the MAC address of the ingress and egress RBridges in
those fields, he is suggesting the following:

a) assign 16-bit nicknames to all the RBridges (as we were going to do
with the short shim header)
b) assign, say, 8 bit link-local nicknames to all the RBridges on a link
(this can be done through the IS-IS Hello protocol quite easily--I'd
suggest doing it by having the Designated RBridge assign the values, but
it could also be done by having each RBridge choose a nickname and back
off if someone with a better ID has chosen that
nickname)
c) in the Destination address field in the Ethernet header, put in both
the 16-bit egress RBridge nickname, and the nextop 8-bit nickname
d) in the Source address field in the Ethernet header, put in both the
16-bit ingress RBridge nickname, and the transmitting RBridge on that
link's 8-bit nickname

So---bridges will never incorrectly learn the location of any RBridges,
because no matter where a packet from
R12 arrives into the link, the bottom bits will be specific to the
RBridge on the link that injected the packet.

And positive learning can happen as well. Suppose there are n total
RBridge nicknames in use in the whole campus. Suppose there are 5
RBridges on the link. The bridges inside the link will see 5*n RBridge
addresses as a result of this proposal. In other words, if the RBridge
nicknames are 1, 2, ... 517. and there are 5 RBridges on the link, the
MAC addresses the bridges will see are:
{1 - 517} | {1 - 5}

In Sanjay's picture, if R4 wants to direct a packet towards R2 rather
than R3 for egress R1, it encodes R2's nickname into the "neighbor's
nickname" portion of the egress RBridge field.

Anyway---something for people to think about.

Radia

----- Original Message -----
From: "Sanjay Sane (sanjays)" <[e-mail]>
Date: Tuesday, November 7, 2006 12:24 pm
Subject: RE: [rbridge] Should we optimize the common case?

> Oops. Typed send before finishing. 
> 
> attached the diagram.
> Completed the description. See inline
> 
> -Sanjay
> 
> 
> 
> -----Original Message-----
> From: Sanjay Sane (sanjays)
> Sent: Tuesday, November 07, 2006 12:19 PM
> To: 'Radia Perlman'; Silvano Gai
> Cc: [e-mail]
> Subject: RE: [rbridge] Should we optimize the common case?
> 
> Radia,
> 
> In today's presentation, the last suggested format was the following
> 
> 48 bits - egress rbridge id
> 48 bits - ingress rbridge id
> 16 bits - pt = TRILL
> 16 bits - reserved + flag + TTL - the link local nicknames (who's 
> supposed to be the next-hop is in here) ....
> 
> 
> when this goes over a shared media, there were learning issues as 
> pointed out during the meeting. Pls refer to this diagram to 
> understandthe problem
> 
> 1. if packets from r1 to r5 are sent once via r2, and other times, via

> r3, the classical bridge b will learn r1 as behind link 1 or 2.
> So, this
> is the learning problem. 
> 2. thus, for return traffic frm r5 to r1, even though r4 wants r2 to 
> be the next-hop for this packet, if we keep the destination rbridge id

> as r1, the classical bridge would forward the packet to link 1, 
> thereby blackholing this traffic.
> 
> So, there are multiple issues - learning issues and blakholing. 
> 
> Potential solution:
> 
> r2, r3 and r4 exchange the link-local nicknames, say link local 
> nicknamefor r2 = 1, r3 = 2, r4 = 3.
> 
> Now, instead of using the complete 48 bit rbridge ID as the rbridge 
> MAC address, we can fill the 48 bits as follows:
> 
> 16 bit - rbridge nickname
> 4 bits - link local nickname
> 
> 2 bits - I/G and U/L
> 26 bits - reserved. 
> 
> Thus, on this classical ethernet/bridging cloud, rbridge emits the 
> packet with the appropriate link-local nicknames.
> 
> For e.g. 
> - packets from r1 to r5, sent via r2, are sent with SA = r1.<link 
> source's link-local-nickname> = r1.1, , notice link-local-nickname of 
> r2 is chosen.
> If r2 intends r4 to be the next-hop, he'll put DA = r5.<link 
> destination's link-local-nickname> = r5.3, notice link-local-nickname 
> of r4 is chosen.
> Thus, classical bridge will learn r1.1 on the link 1. 
> 
> - packets from r1 to r5, sent via r3, are sent with SA = r1.<link 
> source's link-local-nickname> = r1.2, , notice link-local-nickname of 
> r3 is chosen.
> If r3 intends r4 to be the next-hop, he'll put DA = r5.<link 
> destination's link-local-nickname> = r5.3, notice link-local-nickname 
> of r4 is chosen.
> Thus, classical bridge will learn r1.2 on the link 1. 
> 
> -- thus no learning issues. 
> 
> - return traffic from r5 to r1, sent via r4. If r4 intends r2 to be 
> the next hop, it'll put SA = r5.<link source's link-local-nickname> = 
> r5.3, , notice link-local-nickname of r4 is chosen.
> If r5 intends r2 to be the next-hop, he'll put DA = r1.<link 
> destination's link-local-nickname> = r1.1, notice link-local-nickname 
> of r1 is chosen.
> 
> -- thus no blackholing.
> 
> -Sanjay
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [[e-mail]] On 
> Behalf Of Radia Perlman
> Sent: Tuesday, November 07, 2006 10:23 AM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: Re: [rbridge] Should we optimize the common case?
> 
> Looking at Silvano's proposed shim header---the only reason we need 
> the outer header is to distinguish between RBridge neighbors, in the 
> case of unicast, specifying next hop, and in the case of multicast, 
> specifying transmitter.
> 
> His format has two bytes after the Ethernet header portion of the shim

> for TTL, and a bunch of reserved bits.
> 
> That leaves 10 bits. We can dynamically (through the IS-IS Hello) give

> out, say, 4 bit link-local nicknames, and stick them there.
> 
> Then the only time we'd need an outer header is if there are more 
> than,say, 16 RBridges on the same link.
> 
> Radia
> 
> Silvano Gai wrote:
> 
> >I am not looking at TRILL for increased scalability, but for
> spanning
> >tree replacement to get high bisectional bandwidth.
> >
> >-- Silvano
> >
> >  
> >
> >>-----Original Message-----
> >>From: Gray, Eric [[e-mail]]
> >>Sent: Monday, November 06, 2006 10:38 AM
> >>To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> >>Subject: RE: [rbridge] Should we optimize the common case?
> >>
> >>Silvano,
> >>
> >>	The assertion that only fortune 500 companies are interested in
> TRILL
> >>is baseless and untrue.  One reason why you may believe this is
> the
> >>case, is that you are making certain assumptions about
> complexity and
> >>scale of the desired solution that are equally unfounded or false.
> >>
> >>	There is nothing that particularly prohibits definition of some
> form
> >>of RBridge functionality that might be simple enough to deploy
> in
> >>relatively small networks - where higher speed link are becoming
> more
> >>common and wasting high speed links is also a problem.
> >>
> >>	The types of networks you're talking about cannot realistically 
> >>operate with plug & play devices, and greater scalability is
> >>    
> >>
> >paramount.
> >  
> >
> >>The work we're doing in this WG is aimed at simplistic, plug &
> play
> >>deployment where increased scalability is a secondary consideration.
> >>
> >>--
> >>Eric
> >>
> >>--> -----Original Message-----
> >>--> From: [e-mail] [[e-mail]] On

> >>--> Behalf Of Silvano Gai
> >>--> Sent: Monday, November 06, 2006 1:51 AM
> >>--> To: Eastlake III Donald-LDE008; [e-mail]
> >>--> Subject: Re: [rbridge] Should we optimize the common case?
> >>-->
> >>-->
> >>--> Donald,
> >>-->
> >>--> The high end and the low end are extremely different.
> >>-->
> >>--> The customers interested in TRILL are the Fortune 500
> companies. 
> >>--> Large Enterprise networks and large data centers used to run 
> >>--> Financial, Insurance, Health, Chemical, Oil, Information and 
> >>--> manufacturing companies.
> >>-->
> >>--> They have huge demand for high bandwidth and low latency.
> >>-->
> >>--> Each of these companies spends millions each year in network 
> >>--> operation
> >>--> (OPEX) and millions in new equipment (CAPEX). In all of them
> OPEX>>    
> >>
> >is
> >  
> >
> >>--> much larger than CAPEX. They only buy major vendor
> equipments and
> >>--> they install them according to the recommended vendor design 
> >>--> guideline.
> >>--> Typically they have an internal certification lab in which
> they
> >>--> test the network configuration and the software releases
> before
> >>--> putting them in production networks.
> >>-->
> >>--> They have a very well defined concept of backbone ports and
> access
> >>--> ports. All the backbone ports are in fiber at the highest
> possible
> >>--> speed (today 10 GE). For the access port they use a mix of
> fiber
> >>--> and copper.
> >>--> The backbone has a regular structure that matches the vendor
> >>    
> >>
> >design
> >  
> >
> >>--> guideline and the result of the certification experiment they 
> >>--> have done independently.
> >>-->
> >>--> A network outage can cost millions/hour.
> >>-->
> >>--> There is no way you will see in one of these backbones a hub or
> >>    
> >>
> >any
> >  
> >
> >>--> other uncontrolled device. NEVER.
> >>-->
> >>--> That is the reason why I think this is the most important
> case for
> >>--> TRILL.
> >>-->
> >>--> More inline.
> >>-->
> >>--> > -----Original Message-----
> >>--> > From: [e-mail]
> >>--> [[e-mail]]
> >>--> On
> >>--> > Behalf Of Eastlake III Donald-LDE008
> >>--> > Sent: Sunday, November 05, 2006 10:20 PM
> >>--> > To: [e-mail]
> >>--> > Subject: Re: [rbridge] Should we optimize the common case?
> >>--> >
> >>--> > Silvano,
> >>--> >
> >>--> > Why do you think that 90% of Rbridge deployment will be
> for this
> >>--> unusual
> >>--> > case? I mean, I have no problem with the belief that
> >>--> Rbridges would be
> >>--> > better than bridges in this case but why shouldn't that be
> true>>    
> >>
> >of
> >  
> >
> >>--> less
> >>--> > high end uses?
> >>--> >
> >>--> > A while ago on this list I posted a rhetorical question as to
> >>    
> >>
> >why
> >  
> >
> >>--> > Rbriges shouldn't eventually replace all bridges. No one
> posted>>    
> >>
> >an
> >  
> >
> >>--> > answer.
> >>-->
> >>--> This technology will start in the high end and move down to the 
> >>--> lower end. How low will it goes is a good question.
> >>-->
> >>--> The low end is extremely cost sensitive. When we buys a
> switch or
> >>    
> >>
> >a
> >  
> >
> >>--> router on the Internet for 50-100$, the COGS cannot be more that

> >>--> 15-30$, even with low margins. This implies that few dollar more

> >>--> to increase the memory size or the processor speed are a big 
> >>--> deal. Add software development cost. Couple this with the fact 
> >>--> that today we have low cost 1GE switches used by low-end users 
> >>--> that have problems pushing or pulling more than few Mb/s. There 
> >>--> is no bandwidth demand in the low end.
> >>--> Spanning tree is just fine. Cost is the big issue. Moreover 
> >>--> there is the huge issue of training home/small office installers

> >>--> in this new technology.
> >>-->
> >>--> My 0.2 cents
> >>-->
> >>--> -- Silvano
> >>-->
> >>--> >
> >>--> > Why not specify Rbridges more or less as we have been for
> >>--> the common
> >>--> > bridge case and, in the backbone case you are talking
> >>--> about, just drop
> >>--> > the MAC addresses on the point-to-point links within the
> >>    
> >>
> >backbone?
> >  
> >
> >>--> > Doesn't that produce less overhead than your proposal
> >>--> below in both
> >>--> the
> >>--> > point-to-point and shared media cases?
> >>--> >
> >>--> > Donald
> >>--> >
> >>--> > -----Original Message-----
> >>--> > From: [e-mail]
> >>--> [[e-mail]]
> >>--> On
> >>--> > Behalf Of Silvano Gai
> >>--> > Sent: Wednesday, November 01, 2006 9:07 PM
> >>--> > To: [e-mail]
> >>--> > Subject: [rbridge] Should we optimize the common case?
> >>--> >
> >>--> >
> >>--> > With 16 bit addresses the current TRILL overhead over
> >>--> Ethernet is 20
> >>--> > bytes. If we want to expand the RBridge addresses, it we
> >>--> will go to
> >>--> > 22-24 bytes.
> >>--> >
> >>--> > What customers are telling us is that they will deploy
> RBridges>>    
> >>
> >by
> >  
> >
> >>--> > creating an RBridge backbone in which all the links will be
> >>    
> >>
> >10GE.
> >  
> >
> >>--> >
> >>--> > They will connect regular bridges and host to the
> >>--> periphery of this
> >>--> > backbone.
> >>--> >
> >>--> > They will not mix backbone ports with access ports,
> because this
> >>--> screws
> >>--> > up management, traffic engineering, debugging, and
> >>--> troubleshooting.
> >>--> > Regular network design, easy to understand, is very
> >>--> important. Ports
> >>--> are
> >>--> > cheap, labor is expensive.
> >>--> >
> >>--> > I am totally convinced that this will account for 90+ % of
> TRILL>>--> > deployment.
> >>--> >
> >>--> > I am wondering if it makes sense to have a solution
> >>--> highly optimized
> >>--> for
> >>--> > such an environment.
> >>--> >
> >>--> > For example we can put the egress/ingress RBridge
> addresses in
> >>    
> >>
> >the
> >  
> >
> >>--> outer
> >>--> > MAC addresses and define a TRILL shim header that
> >>--> contains 1 byte of
> >>--> hop
> >>--> > limit and 1 byte reserved. For this common case we will get:
> >>--> > 1) overhead of 16 bytes (4 to 8 bytes lower)
> >>--> > 2) nickname = MAC address, i.e no hash collision
> >>--> > 3) zero-conf achieved
> >>--> >
> >>--> > In the case we need to go over a shared media we will need to
> >>    
> >>
> >add
> >  
> >
> >>--> > another Ethernet encapsulation to carry the next hop
> >>--> address, i.e. 14
> >>--> > bytes
> >>--> > - total overhead will be 30 bytes
> >>--> >
> >>--> > Summarizing:
> >>--> > - current proposal 20-24 bytes overhead
> >>--> > - new proposal on point to point: 16 bytes
> >>--> > - new proposal on shared media: 30 bytes
> >>--> >
> >>--> > Comments?
> >>--> >
> >>--> > -- Silvano
> >>--> >
> >>--> >
> >>--> > _______________________________________________
> >>--> > rbridge mailing list
> >>--> > [e-mail]
> >>--> > http://mailman.postel.org/mailman/listinfo/rbridge
> >>--> >
> >>--> > _______________________________________________
> >>--> > rbridge mailing list
> >>--> > [e-mail]
> >>--> > http://mailman.postel.org/mailman/listinfo/rbridge
> >>-->
> >>--> _______________________________________________
> >>--> rbridge mailing list
> >>--> [e-mail]
> >>--> http://mailman.postel.org/mailman/listinfo/rbridge
> >>-->
> >>    
> >>
> >
> >_______________________________________________
> >rbridge mailing list
> >[e-mail]
> >http://mailman.postel.org/mailman/listinfo/rbridge
> >  
> >
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA882OtV023750 for <[e-mail]>; Wed, 8 Nov 2006 00:02:24 -0800 (PST)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 08 Nov 2006 00:02:20 -0800 (PST)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 08 Nov 2006 00:02:19 -0800 (PST)
Received: from [152.70.2.164] (Forwarded-For: [12.105.242.60]) by mail-srv.sfvic.sunlabs.com (mshttpd); Wed, 08 Nov 2006 00:02:19 -0800
Date: Wed, 08 Nov 2006 00:02:19 -0800
From: [e-mail]
To: "Sanjay Sane (sanjays)" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 08 Nov 2006 08:02:56 -0000
Status: RO
Content-Length: 16101

This is an extremely cute proposal, and it works. Let me explain Sanjay's proposal in different words, in case
it doesn't sink in the first time one sees it.

He is proposing using the shim header that looks like an Ethernet header, with SA=ingress RBridge MAC R1
and DA=egress RBridge MAC R2, but solving the two problems
brought up at the meeting which were:

a) bridges on an intermedaite link might have previously incorrectly learned the location of R2, because packets
from R2 might have arrived at the link from different directions.

b) if we avoid problem a) by using different MAC addresses for "to" and "from" for each RBridge, so that
we avoid bridges ever learning the direction of the egress RBridge, the problem is that we don't benefit from
good bridge learning on the link.

And also, he is proposing making it possible to use that header on a link with more than 2 RBridges.

The way he's proposing doing it is using the 48 bit Destination and Source addresses in the Ethernet header
in an unconventional way.

Instead of putting the MAC address of the ingress and egress RBridges in those fields, he is suggesting the following:

a) assign 16-bit nicknames to all the RBridges (as we were going to do with the short shim header)
b) assign, say, 8 bit link-local nicknames to all the RBridges on a link (this can be done through the IS-IS Hello
protocol quite easily--I'd suggest doing it by having the Designated RBridge assign the values, but it could also
be done by having each RBridge choose a nickname and back off if someone with a better ID has chosen that
nickname)
c) in the Destination address field in the Ethernet header, put in both the 16-bit egress RBridge nickname, and
the nextop 8-bit nickname
d) in the Source address field in the Ethernet header, put in both the 16-bit ingress RBridge nickname, and
the transmitting RBridge on that link's 8-bit nickname

So---bridges will never incorrectly learn the location of any RBridges, because no matter where a packet from
R12 arrives into the link, the bottom bits will be specific to the RBridge on the link that injected the packet.

And positive learning can happen as well. Suppose there are n total RBridge nicknames in use in the whole
campus. Suppose there are 5 RBridges on the link. The bridges inside the link will see 5*n RBridge addresses
as a result of this proposal. In other words, if the RBridge nicknames are 1, 2, ... 517. and there are 5 RBridges
on the link, the MAC addresses the bridges will see are:
{1 - 517} | {1 - 5}

In Sanjay's picture, if R4 wants to direct a packet towards R2 rather than R3 for egress R1, it encodes R2's nickname
into the "neighbor's nickname" portion of the egress RBridge field.

Anyway---something for people to think about.

Radia

----- Original Message -----
From: "Sanjay Sane (sanjays)" <[e-mail]>
Date: Tuesday, November 7, 2006 12:24 pm
Subject: RE: [rbridge] Should we optimize the common case?

> Oops. Typed send before finishing. 
> 
> attached the diagram.
> Completed the description. See inline
> 
> -Sanjay
> 
> 
> 
> -----Original Message-----
> From: Sanjay Sane (sanjays) 
> Sent: Tuesday, November 07, 2006 12:19 PM
> To: 'Radia Perlman'; Silvano Gai
> Cc: [e-mail]
> Subject: RE: [rbridge] Should we optimize the common case?
> 
> Radia,
> 
> In today's presentation, the last suggested format was the following
> 
> 48 bits - egress rbridge id
> 48 bits - ingress rbridge id
> 16 bits - pt = TRILL
> 16 bits - reserved + flag + TTL - the link local nicknames (who's
> supposed to be the next-hop is in here) ....
> 
> 
> when this goes over a shared media, there were learning issues as
> pointed out during the meeting. Pls refer to this diagram to 
> understandthe problem
> 
> 1. if packets from r1 to r5 are sent once via r2, and other times, via
> r3, the classical bridge b will learn r1 as behind link 1 or 2. 
> So, this
> is the learning problem. 
> 2. thus, for return traffic frm r5 to r1, even though r4 wants r2 
> to be
> the next-hop for this packet, if we keep the destination rbridge 
> id as
> r1, the classical bridge would forward the packet to link 1, thereby
> blackholing this traffic. 
> 
> So, there are multiple issues - learning issues and blakholing. 
> 
> Potential solution:
> 
> r2, r3 and r4 exchange the link-local nicknames, say link local 
> nicknamefor r2 = 1, r3 = 2, r4 = 3.
> 
> Now, instead of using the complete 48 bit rbridge ID as the 
> rbridge MAC
> address, we can fill the 48 bits as follows:
> 
> 16 bit - rbridge nickname
> 4 bits - link local nickname
> 
> 2 bits - I/G and U/L
> 26 bits - reserved. 
> 
> Thus, on this classical ethernet/bridging cloud, rbridge emits the
> packet with the appropriate link-local nicknames.
> 
> For e.g. 
> - packets from r1 to r5, sent via r2, are sent with
> SA = r1.<link source's link-local-nickname> = r1.1, , notice
> link-local-nickname of r2 is chosen. 
> If r2 intends r4 to be the next-hop, he'll put 
> DA = r5.<link destination's link-local-nickname> = r5.3, notice
> link-local-nickname of r4 is chosen. 
> Thus, classical bridge will learn r1.1 on the link 1. 
> 
> - packets from r1 to r5, sent via r3, are sent with
> SA = r1.<link source's link-local-nickname> = r1.2, , notice
> link-local-nickname of r3 is chosen. 
> If r3 intends r4 to be the next-hop, he'll put 
> DA = r5.<link destination's link-local-nickname> = r5.3, notice
> link-local-nickname of r4 is chosen. 
> Thus, classical bridge will learn r1.2 on the link 1. 
> 
> -- thus no learning issues. 
> 
> - return traffic from r5 to r1, sent via r4. If r4 intends r2 to 
> be the
> next hop, it'll put
> SA = r5.<link source's link-local-nickname> = r5.3, , notice
> link-local-nickname of r4 is chosen. 
> If r5 intends r2 to be the next-hop, he'll put 
> DA = r1.<link destination's link-local-nickname> = r1.1, notice
> link-local-nickname of r1 is chosen. 
> 
> -- thus no blackholing.
> 
> -Sanjay
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [[e-mail]] On
> Behalf Of Radia Perlman
> Sent: Tuesday, November 07, 2006 10:23 AM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: Re: [rbridge] Should we optimize the common case?
> 
> Looking at Silvano's proposed shim header---the only reason we 
> need the
> outer header is to distinguish between RBridge neighbors, in the 
> case of
> unicast, specifying next hop, and in the case of multicast, specifying
> transmitter.
> 
> His format has two bytes after the Ethernet header portion of the shim
> for TTL, and a bunch of reserved bits.
> 
> That leaves 10 bits. We can dynamically (through the IS-IS Hello) give
> out, say, 4 bit link-local nicknames, and stick them there.
> 
> Then the only time we'd need an outer header is if there are more 
> than,say, 16 RBridges on the same link.
> 
> Radia
> 
> Silvano Gai wrote:
> 
> >I am not looking at TRILL for increased scalability, but for 
> spanning 
> >tree replacement to get high bisectional bandwidth.
> >
> >-- Silvano
> >
> >  
> >
> >>-----Original Message-----
> >>From: Gray, Eric [[e-mail]]
> >>Sent: Monday, November 06, 2006 10:38 AM
> >>To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> >>Subject: RE: [rbridge] Should we optimize the common case?
> >>
> >>Silvano,
> >>
> >>	The assertion that only fortune 500 companies are interested in
> TRILL 
> >>is baseless and untrue.  One reason why you may believe this is 
> the 
> >>case, is that you are making certain assumptions about 
> complexity and 
> >>scale of the desired solution that are equally unfounded or false.
> >>
> >>	There is nothing that particularly prohibits definition of some
> form 
> >>of RBridge functionality that might be simple enough to deploy 
> in 
> >>relatively small networks - where higher speed link are becoming 
> more 
> >>common and wasting high speed links is also a problem.
> >>
> >>	The types of networks you're talking about cannot realistically 
> >>operate with plug & play devices, and greater scalability is
> >>    
> >>
> >paramount.
> >  
> >
> >>The work we're doing in this WG is aimed at simplistic, plug & 
> play 
> >>deployment where increased scalability is a secondary consideration.
> >>
> >>--
> >>Eric
> >>
> >>--> -----Original Message-----
> >>--> From: [e-mail]
> >>--> [[e-mail]] On Behalf Of Silvano Gai
> >>--> Sent: Monday, November 06, 2006 1:51 AM
> >>--> To: Eastlake III Donald-LDE008; [e-mail]
> >>--> Subject: Re: [rbridge] Should we optimize the common case?
> >>-->
> >>-->
> >>--> Donald,
> >>-->
> >>--> The high end and the low end are extremely different.
> >>-->
> >>--> The customers interested in TRILL are the Fortune 500 
> companies. 
> >>--> Large Enterprise networks and large data centers used to run 
> >>--> Financial, Insurance, Health, Chemical, Oil, Information and 
> >>--> manufacturing companies.
> >>-->
> >>--> They have huge demand for high bandwidth and low latency.
> >>-->
> >>--> Each of these companies spends millions each year in network 
> >>--> operation
> >>--> (OPEX) and millions in new equipment (CAPEX). In all of them 
> OPEX>>    
> >>
> >is
> >  
> >
> >>--> much larger than CAPEX. They only buy major vendor 
> equipments and 
> >>--> they install them according to the recommended vendor design 
> >>--> guideline.
> >>--> Typically they have an internal certification lab in which 
> they 
> >>--> test the network configuration and the software releases 
> before 
> >>--> putting them in production networks.
> >>-->
> >>--> They have a very well defined concept of backbone ports and 
> access
> >>--> ports. All the backbone ports are in fiber at the highest 
> possible
> >>--> speed (today 10 GE). For the access port they use a mix of 
> fiber 
> >>--> and copper.
> >>--> The backbone has a regular structure that matches the vendor
> >>    
> >>
> >design
> >  
> >
> >>--> guideline and the result of the certification experiment
> >>--> they have done
> >>--> independently.
> >>-->
> >>--> A network outage can cost millions/hour.
> >>-->
> >>--> There is no way you will see in one of these backbones a hub or
> >>    
> >>
> >any
> >  
> >
> >>--> other uncontrolled device. NEVER.
> >>-->
> >>--> That is the reason why I think this is the most important 
> case for
> >>--> TRILL.
> >>-->
> >>--> More inline.
> >>-->
> >>--> > -----Original Message-----
> >>--> > From: [e-mail]
> >>--> [[e-mail]]
> >>--> On
> >>--> > Behalf Of Eastlake III Donald-LDE008
> >>--> > Sent: Sunday, November 05, 2006 10:20 PM
> >>--> > To: [e-mail]
> >>--> > Subject: Re: [rbridge] Should we optimize the common case?
> >>--> >
> >>--> > Silvano,
> >>--> >
> >>--> > Why do you think that 90% of Rbridge deployment will be 
> for this
> >>--> unusual
> >>--> > case? I mean, I have no problem with the belief that
> >>--> Rbridges would be
> >>--> > better than bridges in this case but why shouldn't that be 
> true>>    
> >>
> >of
> >  
> >
> >>--> less
> >>--> > high end uses?
> >>--> >
> >>--> > A while ago on this list I posted a rhetorical question as to
> >>    
> >>
> >why
> >  
> >
> >>--> > Rbriges shouldn't eventually replace all bridges. No one 
> posted>>    
> >>
> >an
> >  
> >
> >>--> > answer.
> >>-->
> >>--> This technology will start in the high end and move down to
> >>--> the lower
> >>--> end. How low will it goes is a good question.
> >>-->
> >>--> The low end is extremely cost sensitive. When we buys a 
> switch or
> >>    
> >>
> >a
> >  
> >
> >>--> router on the Internet for 50-100$, the COGS cannot be more
> >>--> that 15-30$,
> >>--> even with low margins. This implies that few dollar more to
> >>--> increase the
> >>--> memory size or the processor speed are a big deal. Add software
> >>--> development cost. Couple this with the fact that today we
> >>--> have low cost
> >>--> 1GE switches used by low-end users that have problems
> >>--> pushing or pulling
> >>--> more than few Mb/s. There is no bandwidth demand in the low end.
> >>--> Spanning tree is just fine. Cost is the big issue. Moreover
> >>--> there is the
> >>--> huge issue of training home/small office installers in this new
> >>--> technology.
> >>-->
> >>--> My 0.2 cents
> >>-->
> >>--> -- Silvano
> >>-->
> >>--> >
> >>--> > Why not specify Rbridges more or less as we have been for
> >>--> the common
> >>--> > bridge case and, in the backbone case you are talking
> >>--> about, just drop
> >>--> > the MAC addresses on the point-to-point links within the
> >>    
> >>
> >backbone?
> >  
> >
> >>--> > Doesn't that produce less overhead than your proposal
> >>--> below in both
> >>--> the
> >>--> > point-to-point and shared media cases?
> >>--> >
> >>--> > Donald
> >>--> >
> >>--> > -----Original Message-----
> >>--> > From: [e-mail]
> >>--> [[e-mail]]
> >>--> On
> >>--> > Behalf Of Silvano Gai
> >>--> > Sent: Wednesday, November 01, 2006 9:07 PM
> >>--> > To: [e-mail]
> >>--> > Subject: [rbridge] Should we optimize the common case?
> >>--> >
> >>--> >
> >>--> > With 16 bit addresses the current TRILL overhead over
> >>--> Ethernet is 20
> >>--> > bytes. If we want to expand the RBridge addresses, it we
> >>--> will go to
> >>--> > 22-24 bytes.
> >>--> >
> >>--> > What customers are telling us is that they will deploy 
> RBridges>>    
> >>
> >by
> >  
> >
> >>--> > creating an RBridge backbone in which all the links will be
> >>    
> >>
> >10GE.
> >  
> >
> >>--> >
> >>--> > They will connect regular bridges and host to the
> >>--> periphery of this
> >>--> > backbone.
> >>--> >
> >>--> > They will not mix backbone ports with access ports, 
> because this
> >>--> screws
> >>--> > up management, traffic engineering, debugging, and
> >>--> troubleshooting.
> >>--> > Regular network design, easy to understand, is very
> >>--> important. Ports
> >>--> are
> >>--> > cheap, labor is expensive.
> >>--> >
> >>--> > I am totally convinced that this will account for 90+ % of 
> TRILL>>--> > deployment.
> >>--> >
> >>--> > I am wondering if it makes sense to have a solution
> >>--> highly optimized
> >>--> for
> >>--> > such an environment.
> >>--> >
> >>--> > For example we can put the egress/ingress RBridge 
> addresses in
> >>    
> >>
> >the
> >  
> >
> >>--> outer
> >>--> > MAC addresses and define a TRILL shim header that
> >>--> contains 1 byte of
> >>--> hop
> >>--> > limit and 1 byte reserved. For this common case we will get:
> >>--> > 1) overhead of 16 bytes (4 to 8 bytes lower)
> >>--> > 2) nickname = MAC address, i.e no hash collision
> >>--> > 3) zero-conf achieved
> >>--> >
> >>--> > In the case we need to go over a shared media we will need to
> >>    
> >>
> >add
> >  
> >
> >>--> > another Ethernet encapsulation to carry the next hop
> >>--> address, i.e. 14
> >>--> > bytes
> >>--> > - total overhead will be 30 bytes
> >>--> >
> >>--> > Summarizing:
> >>--> > - current proposal 20-24 bytes overhead
> >>--> > - new proposal on point to point: 16 bytes
> >>--> > - new proposal on shared media: 30 bytes
> >>--> >
> >>--> > Comments?
> >>--> >
> >>--> > -- Silvano
> >>--> >
> >>--> >
> >>--> > _______________________________________________
> >>--> > rbridge mailing list
> >>--> > [e-mail]
> >>--> > http://mailman.postel.org/mailman/listinfo/rbridge
> >>--> >
> >>--> > _______________________________________________
> >>--> > rbridge mailing list
> >>--> > [e-mail]
> >>--> > http://mailman.postel.org/mailman/listinfo/rbridge
> >>-->
> >>--> _______________________________________________
> >>--> rbridge mailing list
> >>--> [e-mail]
> >>--> http://mailman.postel.org/mailman/listinfo/rbridge
> >>-->
> >>    
> >>
> >
> >_______________________________________________
> >rbridge mailing list
> >[e-mail]
> >http://mailman.postel.org/mailman/listinfo/rbridge
> >  
> >
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA7KXNDU000161 for <[e-mail]>; Tue, 7 Nov 2006 12:33:24 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA7KXJfK009333; Tue, 7 Nov 2006 15:33:20 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA22357;  Tue, 7 Nov 2006 15:33:19 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB6498K8>; Tue, 7 Nov 2006 15:33:18 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "Sanjay Sane (sanjays)" <[e-mail]>, Radia Perlman <[e-mail]>, Silvano Gai <[e-mail]>
Date: Tue, 7 Nov 2006 15:33:13 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2006 20:33:44 -0000
Status: RO
Content-Length: 14290

At what point does the proposal become complex enough to be recognized 
as sub-optimal, even in the supposed "common case" envisioned by those 
arguing that the only solution that is important is one that applies to 
large - high-end - networks? 

What is fundamentally wrong with using a single SHIM format?

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Sanjay 
--> Sane (sanjays)
--> Sent: Tuesday, November 07, 2006 3:19 PM
--> To: Radia Perlman; Silvano Gai
--> Cc: [e-mail]
--> Subject: Re: [rbridge] Should we optimize the common case?
--> 
--> Radia,
--> 
--> In today's presentation, the last suggested format was the following
--> 
--> 48 bits - egress rbridge id
--> 48 bits - ingress rbridge id
--> 16 bits - pt = TRILL
--> 16 bits - reserved + flag + TTL - the link local nicknames (who's
--> supposed to be the next-hop is in here) 
--> ....
--> 
--> 
--> when this goes over a shared media, there were learning issues as
--> pointed out during the meeting. Pls refer to this diagram 
--> to understand
--> the problem
--> 
--> 1. if packets from r1 to r5 are sent once via r2, and other 
--> times, via
--> r3, the classical bridge b will learn r1 as behind link 1 
--> or 2. So, this
--> is the learning problem. 
--> 2. thus, for return traffic frm r5 to r1, even though r4 
--> wants r2 to be
--> the next-hop for this packet, if we keep the destination 
--> rbridge id as
--> r1, the classical bridge would forward the packet to link 1, thereby
--> blackholing this traffic. 
--> 
--> So, there are multiple issues - learning issues and blakholing. 
--> 
--> Potential solution:
--> 
--> r2, r3 and r4 exchange the link-local nicknames, say link 
--> local nickname
--> for r2 = 1, r3 = 2, r4 = 3.
--> 
--> Now, instead of using the complete 48 bit rbridge ID as the 
--> rbridge MAC
--> address, we can fill the 48 bits as follows:
--> 
--> 16 bit - rbridge nickname
--> 4 bits - link local nickname
--> 
--> 2 bits - I/G and U/L
--> 26 bits - reserved. 
--> 
--> Thus, on this classical ethernet/bridging cloud, rbridge emits the
--> packet with the appropriate link-local nicknames.
--> 
--> For e.g. 
--> - packets from r1 to r5, sent via r2, are sent with
--> SA = r1.<link source's link-local-nickname> = r1.1, , notice
--> link-local-nickname of r2 is chosen. 
--> If r2 intends r4 to be the next-hop, he'll put 
--> DA = r5.<link destination's link-local-nickname> = r5.3, notice
--> link-local-nickname of r4 is chosen. 
--> Thus, classical bridge will learn r1.1 on the link 1. 
--> 
--> - packets from r1 to r5, sent via r3, are sent with
--> SA = r1.<link source's link-local-nickname> = r1.2, , notice
--> link-local-nickname of r3 is chosen. 
--> If r3 intends r4 to be the next-hop, he'll put 
--> DA = r5.<link destination's link-local-nickname> = r5.3, notice
--> link-local-nickname of r4 is chosen. 
--> Thus, classical bridge will learn r1.2 on the link 1. 
--> 
--> -- thus no learning issues. 
--> 
--> - return traffic from r5 to r1, sent via r4. If r4 intends 
--> r2 to be the
--> next hop, it'll put
--> 
-->  
--> 
--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On
--> Behalf Of Radia Perlman
--> Sent: Tuesday, November 07, 2006 10:23 AM
--> To: Silvano Gai
--> Cc: [e-mail]
--> Subject: Re: [rbridge] Should we optimize the common case?
--> 
--> Looking at Silvano's proposed shim header---the only reason 
--> we need the
--> outer header is to distinguish between RBridge neighbors, 
--> in the case of
--> unicast, specifying next hop, and in the case of multicast, 
--> specifying
--> transmitter.
--> 
--> His format has two bytes after the Ethernet header portion 
--> of the shim
--> for TTL, and a bunch of reserved bits.
--> 
--> That leaves 10 bits. We can dynamically (through the IS-IS 
--> Hello) give
--> out, say, 4 bit link-local nicknames, and stick them there.
--> 
--> Then the only time we'd need an outer header is if there 
--> are more than,
--> say, 16 RBridges on the same link.
--> 
--> Radia
--> 
--> Silvano Gai wrote:
--> 
--> >I am not looking at TRILL for increased scalability, but 
--> for spanning 
--> >tree replacement to get high bisectional bandwidth.
--> >
--> >-- Silvano
--> >
--> >  
--> >
--> >>-----Original Message-----
--> >>From: Gray, Eric [mailto:[e-mail]]
--> >>Sent: Monday, November 06, 2006 10:38 AM
--> >>To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
--> >>Subject: RE: [rbridge] Should we optimize the common case?
--> >>
--> >>Silvano,
--> >>
--> >>	The assertion that only fortune 500 companies are interested in
--> TRILL 
--> >>is baseless and untrue.  One reason why you may believe 
--> this is the 
--> >>case, is that you are making certain assumptions about 
--> complexity and 
--> >>scale of the desired solution that are equally unfounded or false.
--> >>
--> >>	There is nothing that particularly prohibits definition of some
--> form 
--> >>of RBridge functionality that might be simple enough to deploy in 
--> >>relatively small networks - where higher speed link are 
--> becoming more 
--> >>common and wasting high speed links is also a problem.
--> >>
--> >>	The types of networks you're talking about cannot realistically 
--> >>operate with plug & play devices, and greater scalability is
--> >>    
--> >>
--> >paramount.
--> >  
--> >
--> >>The work we're doing in this WG is aimed at simplistic, 
--> plug & play 
--> >>deployment where increased scalability is a secondary 
--> consideration.
--> >>
--> >>--
--> >>Eric
--> >>
--> >>--> -----Original Message-----
--> >>--> From: [e-mail]
--> >>--> [mailto:[e-mail]] On Behalf Of Silvano Gai
--> >>--> Sent: Monday, November 06, 2006 1:51 AM
--> >>--> To: Eastlake III Donald-LDE008; [e-mail]
--> >>--> Subject: Re: [rbridge] Should we optimize the common case?
--> >>-->
--> >>-->
--> >>--> Donald,
--> >>-->
--> >>--> The high end and the low end are extremely different.
--> >>-->
--> >>--> The customers interested in TRILL are the Fortune 500 
--> companies. 
--> >>--> Large Enterprise networks and large data centers used to run 
--> >>--> Financial, Insurance, Health, Chemical, Oil, Information and 
--> >>--> manufacturing companies.
--> >>-->
--> >>--> They have huge demand for high bandwidth and low latency.
--> >>-->
--> >>--> Each of these companies spends millions each year in network 
--> >>--> operation
--> >>--> (OPEX) and millions in new equipment (CAPEX). In all 
--> of them OPEX
--> >>    
--> >>
--> >is
--> >  
--> >
--> >>--> much larger than CAPEX. They only buy major vendor 
--> equipments and 
--> >>--> they install them according to the recommended vendor design 
--> >>--> guideline.
--> >>--> Typically they have an internal certification lab in 
--> which they 
--> >>--> test the network configuration and the software 
--> releases before 
--> >>--> putting them in production networks.
--> >>-->
--> >>--> They have a very well defined concept of backbone 
--> ports and access
--> 
--> >>--> ports. All the backbone ports are in fiber at the 
--> highest possible
--> 
--> >>--> speed (today 10 GE). For the access port they use a 
--> mix of fiber 
--> >>--> and copper.
--> >>--> The backbone has a regular structure that matches the vendor
--> >>    
--> >>
--> >design
--> >  
--> >
--> >>--> guideline and the result of the certification experiment
--> >>--> they have done
--> >>--> independently.
--> >>-->
--> >>--> A network outage can cost millions/hour.
--> >>-->
--> >>--> There is no way you will see in one of these 
--> backbones a hub or
--> >>    
--> >>
--> >any
--> >  
--> >
--> >>--> other uncontrolled device. NEVER.
--> >>-->
--> >>--> That is the reason why I think this is the most 
--> important case for
--> >>--> TRILL.
--> >>-->
--> >>--> More inline.
--> >>-->
--> >>--> > -----Original Message-----
--> >>--> > From: [e-mail]
--> >>--> [mailto:[e-mail]]
--> >>--> On
--> >>--> > Behalf Of Eastlake III Donald-LDE008
--> >>--> > Sent: Sunday, November 05, 2006 10:20 PM
--> >>--> > To: [e-mail]
--> >>--> > Subject: Re: [rbridge] Should we optimize the common case?
--> >>--> >
--> >>--> > Silvano,
--> >>--> >
--> >>--> > Why do you think that 90% of Rbridge deployment 
--> will be for this
--> >>--> unusual
--> >>--> > case? I mean, I have no problem with the belief that
--> >>--> Rbridges would be
--> >>--> > better than bridges in this case but why shouldn't 
--> that be true
--> >>    
--> >>
--> >of
--> >  
--> >
--> >>--> less
--> >>--> > high end uses?
--> >>--> >
--> >>--> > A while ago on this list I posted a rhetorical 
--> question as to
--> >>    
--> >>
--> >why
--> >  
--> >
--> >>--> > Rbriges shouldn't eventually replace all bridges. 
--> No one posted
--> >>    
--> >>
--> >an
--> >  
--> >
--> >>--> > answer.
--> >>-->
--> >>--> This technology will start in the high end and move down to
--> >>--> the lower
--> >>--> end. How low will it goes is a good question.
--> >>-->
--> >>--> The low end is extremely cost sensitive. When we buys 
--> a switch or
--> >>    
--> >>
--> >a
--> >  
--> >
--> >>--> router on the Internet for 50-100$, the COGS cannot be more
--> >>--> that 15-30$,
--> >>--> even with low margins. This implies that few dollar more to
--> >>--> increase the
--> >>--> memory size or the processor speed are a big deal. 
--> Add software
--> >>--> development cost. Couple this with the fact that today we
--> >>--> have low cost
--> >>--> 1GE switches used by low-end users that have problems
--> >>--> pushing or pulling
--> >>--> more than few Mb/s. There is no bandwidth demand in 
--> the low end.
--> >>--> Spanning tree is just fine. Cost is the big issue. Moreover
--> >>--> there is the
--> >>--> huge issue of training home/small office installers 
--> in this new
--> >>--> technology.
--> >>-->
--> >>--> My 0.2 cents
--> >>-->
--> >>--> -- Silvano
--> >>-->
--> >>--> >
--> >>--> > Why not specify Rbridges more or less as we have been for
--> >>--> the common
--> >>--> > bridge case and, in the backbone case you are talking
--> >>--> about, just drop
--> >>--> > the MAC addresses on the point-to-point links within the
--> >>    
--> >>
--> >backbone?
--> >  
--> >
--> >>--> > Doesn't that produce less overhead than your proposal
--> >>--> below in both
--> >>--> the
--> >>--> > point-to-point and shared media cases?
--> >>--> >
--> >>--> > Donald
--> >>--> >
--> >>--> > -----Original Message-----
--> >>--> > From: [e-mail]
--> >>--> [mailto:[e-mail]]
--> >>--> On
--> >>--> > Behalf Of Silvano Gai
--> >>--> > Sent: Wednesday, November 01, 2006 9:07 PM
--> >>--> > To: [e-mail]
--> >>--> > Subject: [rbridge] Should we optimize the common case?
--> >>--> >
--> >>--> >
--> >>--> > With 16 bit addresses the current TRILL overhead over
--> >>--> Ethernet is 20
--> >>--> > bytes. If we want to expand the RBridge addresses, it we
--> >>--> will go to
--> >>--> > 22-24 bytes.
--> >>--> >
--> >>--> > What customers are telling us is that they will 
--> deploy RBridges
--> >>    
--> >>
--> >by
--> >  
--> >
--> >>--> > creating an RBridge backbone in which all the links will be
--> >>    
--> >>
--> >10GE.
--> >  
--> >
--> >>--> >
--> >>--> > They will connect regular bridges and host to the
--> >>--> periphery of this
--> >>--> > backbone.
--> >>--> >
--> >>--> > They will not mix backbone ports with access ports, 
--> because this
--> >>--> screws
--> >>--> > up management, traffic engineering, debugging, and
--> >>--> troubleshooting.
--> >>--> > Regular network design, easy to understand, is very
--> >>--> important. Ports
--> >>--> are
--> >>--> > cheap, labor is expensive.
--> >>--> >
--> >>--> > I am totally convinced that this will account for 
--> 90+ % of TRILL
--> >>--> > deployment.
--> >>--> >
--> >>--> > I am wondering if it makes sense to have a solution
--> >>--> highly optimized
--> >>--> for
--> >>--> > such an environment.
--> >>--> >
--> >>--> > For example we can put the egress/ingress RBridge 
--> addresses in
--> >>    
--> >>
--> >the
--> >  
--> >
--> >>--> outer
--> >>--> > MAC addresses and define a TRILL shim header that
--> >>--> contains 1 byte of
--> >>--> hop
--> >>--> > limit and 1 byte reserved. For this common case we will get:
--> >>--> > 1) overhead of 16 bytes (4 to 8 bytes lower)
--> >>--> > 2) nickname = MAC address, i.e no hash collision
--> >>--> > 3) zero-conf achieved
--> >>--> >
--> >>--> > In the case we need to go over a shared media we 
--> will need to
--> >>    
--> >>
--> >add
--> >  
--> >
--> >>--> > another Ethernet encapsulation to carry the next hop
--> >>--> address, i.e. 14
--> >>--> > bytes
--> >>--> > - total overhead will be 30 bytes
--> >>--> >
--> >>--> > Summarizing:
--> >>--> > - current proposal 20-24 bytes overhead
--> >>--> > - new proposal on point to point: 16 bytes
--> >>--> > - new proposal on shared media: 30 bytes
--> >>--> >
--> >>--> > Comments?
--> >>--> >
--> >>--> > -- Silvano
--> >>--> >
--> >>--> >
--> >>--> > _______________________________________________
--> >>--> > rbridge mailing list
--> >>--> > [e-mail]
--> >>--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> >>--> >
--> >>--> > _______________________________________________
--> >>--> > rbridge mailing list
--> >>--> > [e-mail]
--> >>--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> >>-->
--> >>--> _______________________________________________
--> >>--> rbridge mailing list
--> >>--> [e-mail]
--> >>--> http://mailman.postel.org/mailman/listinfo/rbridge
--> >>-->
--> >>    
--> >>
--> >
--> >_______________________________________________
--> >rbridge mailing list
--> >[e-mail]
--> >http://mailman.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 


Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA7KOXQT027174 for <[e-mail]>; Tue, 7 Nov 2006 12:24:33 -0800 (PST)
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 07 Nov 2006 12:24:33 -0800
X-IronPort-AV: i="4.09,397,1157353200";  d="jpg'145?scan'145,208,145"; a="86858325:sNHT114355764"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA7KOXhB006354; Tue, 7 Nov 2006 12:24:33 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA7KOXAo009198; Tue, 7 Nov 2006 12:24:33 -0800 (PST)
Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 7 Nov 2006 12:24:33 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C702AA.BC29B977"
Date: Tue, 7 Nov 2006 12:24:31 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: AccCmhUxw+MxPZZEQ5WCodMfSRFwfAADEf6gAADkzjA=
From: "Sanjay Sane \(sanjays\)" <[e-mail]>
To: "Sanjay Sane \(sanjays\)" <[e-mail]>, "Radia Perlman" <[e-mail]>, "Silvano Gai" <[e-mail]>
X-OriginalArrivalTime: 07 Nov 2006 20:24:33.0106 (UTC) FILETIME=[BC5A0320:01C702AA]
DKIM-Signature: a=rsa-sha1; q=dns; l=25196; t=1162931073; x=1163795073; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=22Sanjay=20Sane=20\(sanjays\)=22=20<[e-mail]> |Subject:RE=3A=20[rbridge]=20Should=20we=20optimize=20the=20common=20case?; X=v=3Dcisco.com=3B=20h=3DEClTlmfkc5bEqr475IlNqbpLbPE=3D; b=ofG03IsjH5kXLhKhligL4EseKBgbvKEJDTyTUDIJR0FiuogOuTjDHMYFR5dMjyoPn+hgvNF3 MLY4zAG91GB7WefJyh684dL3GZn3fXtLfUudmrfG8KyPx4hLLR5iI9js;
Authentication-Results: sj-dkim-1.cisco.com; header.From=[e-mail]; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2006 20:25:30 -0000
Status: RO
Content-Length: 24648

This is a multi-part message in MIME format.

------_=_NextPart_001_01C702AA.BC29B977
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Oops. Typed send before finishing.=20

attached the diagram.
Completed the description. See inline

-Sanjay



-----Original Message-----
From: Sanjay Sane (sanjays)=20
Sent: Tuesday, November 07, 2006 12:19 PM
To: 'Radia Perlman'; Silvano Gai
Cc: [e-mail]
Subject: RE: [rbridge] Should we optimize the common case?

Radia,

In today's presentation, the last suggested format was the following

48 bits - egress rbridge id
48 bits - ingress rbridge id
16 bits - pt =3D TRILL
16 bits - reserved + flag + TTL - the link local nicknames (who's
supposed to be the next-hop is in here) ....


when this goes over a shared media, there were learning issues as
pointed out during the meeting. Pls refer to this diagram to understand
the problem

1. if packets from r1 to r5 are sent once via r2, and other times, via
r3, the classical bridge b will learn r1 as behind link 1 or 2. So, this
is the learning problem.=20
2. thus, for return traffic frm r5 to r1, even though r4 wants r2 to be
the next-hop for this packet, if we keep the destination rbridge id as
r1, the classical bridge would forward the packet to link 1, thereby
blackholing this traffic.=20

So, there are multiple issues - learning issues and blakholing.=20

Potential solution:

r2, r3 and r4 exchange the link-local nicknames, say link local nickname
for r2 =3D 1, r3 =3D 2, r4 =3D 3.

Now, instead of using the complete 48 bit rbridge ID as the rbridge MAC
address, we can fill the 48 bits as follows:

16 bit - rbridge nickname
4 bits - link local nickname

2 bits - I/G and U/L
26 bits - reserved.=20

Thus, on this classical ethernet/bridging cloud, rbridge emits the
packet with the appropriate link-local nicknames.

For e.g.=20
- packets from r1 to r5, sent via r2, are sent with
SA =3D r1.<link source's link-local-nickname> =3D r1.1, , notice
link-local-nickname of r2 is chosen.=20
If r2 intends r4 to be the next-hop, he'll put=20
DA =3D r5.<link destination's link-local-nickname> =3D r5.3, notice
link-local-nickname of r4 is chosen.=20
Thus, classical bridge will learn r1.1 on the link 1.=20

- packets from r1 to r5, sent via r3, are sent with
SA =3D r1.<link source's link-local-nickname> =3D r1.2, , notice
link-local-nickname of r3 is chosen.=20
If r3 intends r4 to be the next-hop, he'll put=20
DA =3D r5.<link destination's link-local-nickname> =3D r5.3, notice
link-local-nickname of r4 is chosen.=20
Thus, classical bridge will learn r1.2 on the link 1.=20

-- thus no learning issues.=20

- return traffic from r5 to r1, sent via r4. If r4 intends r2 to be the
next hop, it'll put
SA =3D r5.<link source's link-local-nickname> =3D r5.3, , notice
link-local-nickname of r4 is chosen.=20
If r5 intends r2 to be the next-hop, he'll put=20
DA =3D r1.<link destination's link-local-nickname> =3D r1.1, notice
link-local-nickname of r1 is chosen.=20

-- thus no blackholing.

-Sanjay

=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Tuesday, November 07, 2006 10:23 AM
To: Silvano Gai
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?

Looking at Silvano's proposed shim header---the only reason we need the
outer header is to distinguish between RBridge neighbors, in the case of
unicast, specifying next hop, and in the case of multicast, specifying
transmitter.

His format has two bytes after the Ethernet header portion of the shim
for TTL, and a bunch of reserved bits.

That leaves 10 bits. We can dynamically (through the IS-IS Hello) give
out, say, 4 bit link-local nicknames, and stick them there.

Then the only time we'd need an outer header is if there are more than,
say, 16 RBridges on the same link.

Radia

Silvano Gai wrote:

>I am not looking at TRILL for increased scalability, but for spanning=20
>tree replacement to get high bisectional bandwidth.
>
>-- Silvano
>
> =20
>
>>-----Original Message-----
>>From: Gray, Eric [mailto:[e-mail]]
>>Sent: Monday, November 06, 2006 10:38 AM
>>To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
>>Subject: RE: [rbridge] Should we optimize the common case?
>>
>>Silvano,
>>
>>	The assertion that only fortune 500 companies are interested in
TRILL=20
>>is baseless and untrue.  One reason why you may believe this is the=20
>>case, is that you are making certain assumptions about complexity and=20
>>scale of the desired solution that are equally unfounded or false.
>>
>>	There is nothing that particularly prohibits definition of some
form=20
>>of RBridge functionality that might be simple enough to deploy in=20
>>relatively small networks - where higher speed link are becoming more=20
>>common and wasting high speed links is also a problem.
>>
>>	The types of networks you're talking about cannot realistically=20
>>operate with plug & play devices, and greater scalability is
>>   =20
>>
>paramount.
> =20
>
>>The work we're doing in this WG is aimed at simplistic, plug & play=20
>>deployment where increased scalability is a secondary consideration.
>>
>>--
>>Eric
>>
>>--> -----Original Message-----
>>--> From: [e-mail]
>>--> [mailto:[e-mail]] On Behalf Of Silvano Gai
>>--> Sent: Monday, November 06, 2006 1:51 AM
>>--> To: Eastlake III Donald-LDE008; [e-mail]
>>--> Subject: Re: [rbridge] Should we optimize the common case?
>>-->
>>-->
>>--> Donald,
>>-->
>>--> The high end and the low end are extremely different.
>>-->
>>--> The customers interested in TRILL are the Fortune 500 companies.=20
>>--> Large Enterprise networks and large data centers used to run=20
>>--> Financial, Insurance, Health, Chemical, Oil, Information and=20
>>--> manufacturing companies.
>>-->
>>--> They have huge demand for high bandwidth and low latency.
>>-->
>>--> Each of these companies spends millions each year in network=20
>>--> operation
>>--> (OPEX) and millions in new equipment (CAPEX). In all of them OPEX
>>   =20
>>
>is
> =20
>
>>--> much larger than CAPEX. They only buy major vendor equipments and=20
>>--> they install them according to the recommended vendor design=20
>>--> guideline.
>>--> Typically they have an internal certification lab in which they=20
>>--> test the network configuration and the software releases before=20
>>--> putting them in production networks.
>>-->
>>--> They have a very well defined concept of backbone ports and access

>>--> ports. All the backbone ports are in fiber at the highest possible

>>--> speed (today 10 GE). For the access port they use a mix of fiber=20
>>--> and copper.
>>--> The backbone has a regular structure that matches the vendor
>>   =20
>>
>design
> =20
>
>>--> guideline and the result of the certification experiment
>>--> they have done
>>--> independently.
>>-->
>>--> A network outage can cost millions/hour.
>>-->
>>--> There is no way you will see in one of these backbones a hub or
>>   =20
>>
>any
> =20
>
>>--> other uncontrolled device. NEVER.
>>-->
>>--> That is the reason why I think this is the most important case for
>>--> TRILL.
>>-->
>>--> More inline.
>>-->
>>--> > -----Original Message-----
>>--> > From: [e-mail]
>>--> [mailto:[e-mail]]
>>--> On
>>--> > Behalf Of Eastlake III Donald-LDE008
>>--> > Sent: Sunday, November 05, 2006 10:20 PM
>>--> > To: [e-mail]
>>--> > Subject: Re: [rbridge] Should we optimize the common case?
>>--> >
>>--> > Silvano,
>>--> >
>>--> > Why do you think that 90% of Rbridge deployment will be for this
>>--> unusual
>>--> > case? I mean, I have no problem with the belief that
>>--> Rbridges would be
>>--> > better than bridges in this case but why shouldn't that be true
>>   =20
>>
>of
> =20
>
>>--> less
>>--> > high end uses?
>>--> >
>>--> > A while ago on this list I posted a rhetorical question as to
>>   =20
>>
>why
> =20
>
>>--> > Rbriges shouldn't eventually replace all bridges. No one posted
>>   =20
>>
>an
> =20
>
>>--> > answer.
>>-->
>>--> This technology will start in the high end and move down to
>>--> the lower
>>--> end. How low will it goes is a good question.
>>-->
>>--> The low end is extremely cost sensitive. When we buys a switch or
>>   =20
>>
>a
> =20
>
>>--> router on the Internet for 50-100$, the COGS cannot be more
>>--> that 15-30$,
>>--> even with low margins. This implies that few dollar more to
>>--> increase the
>>--> memory size or the processor speed are a big deal. Add software
>>--> development cost. Couple this with the fact that today we
>>--> have low cost
>>--> 1GE switches used by low-end users that have problems
>>--> pushing or pulling
>>--> more than few Mb/s. There is no bandwidth demand in the low end.
>>--> Spanning tree is just fine. Cost is the big issue. Moreover
>>--> there is the
>>--> huge issue of training home/small office installers in this new
>>--> technology.
>>-->
>>--> My 0.2 cents
>>-->
>>--> -- Silvano
>>-->
>>--> >
>>--> > Why not specify Rbridges more or less as we have been for
>>--> the common
>>--> > bridge case and, in the backbone case you are talking
>>--> about, just drop
>>--> > the MAC addresses on the point-to-point links within the
>>   =20
>>
>backbone?
> =20
>
>>--> > Doesn't that produce less overhead than your proposal
>>--> below in both
>>--> the
>>--> > point-to-point and shared media cases?
>>--> >
>>--> > Donald
>>--> >
>>--> > -----Original Message-----
>>--> > From: [e-mail]
>>--> [mailto:[e-mail]]
>>--> On
>>--> > Behalf Of Silvano Gai
>>--> > Sent: Wednesday, November 01, 2006 9:07 PM
>>--> > To: [e-mail]
>>--> > Subject: [rbridge] Should we optimize the common case?
>>--> >
>>--> >
>>--> > With 16 bit addresses the current TRILL overhead over
>>--> Ethernet is 20
>>--> > bytes. If we want to expand the RBridge addresses, it we
>>--> will go to
>>--> > 22-24 bytes.
>>--> >
>>--> > What customers are telling us is that they will deploy RBridges
>>   =20
>>
>by
> =20
>
>>--> > creating an RBridge backbone in which all the links will be
>>   =20
>>
>10GE.
> =20
>
>>--> >
>>--> > They will connect regular bridges and host to the
>>--> periphery of this
>>--> > backbone.
>>--> >
>>--> > They will not mix backbone ports with access ports, because this
>>--> screws
>>--> > up management, traffic engineering, debugging, and
>>--> troubleshooting.
>>--> > Regular network design, easy to understand, is very
>>--> important. Ports
>>--> are
>>--> > cheap, labor is expensive.
>>--> >
>>--> > I am totally convinced that this will account for 90+ % of TRILL
>>--> > deployment.
>>--> >
>>--> > I am wondering if it makes sense to have a solution
>>--> highly optimized
>>--> for
>>--> > such an environment.
>>--> >
>>--> > For example we can put the egress/ingress RBridge addresses in
>>   =20
>>
>the
> =20
>
>>--> outer
>>--> > MAC addresses and define a TRILL shim header that
>>--> contains 1 byte of
>>--> hop
>>--> > limit and 1 byte reserved. For this common case we will get:
>>--> > 1) overhead of 16 bytes (4 to 8 bytes lower)
>>--> > 2) nickname =3D MAC address, i.e no hash collision
>>--> > 3) zero-conf achieved
>>--> >
>>--> > In the case we need to go over a shared media we will need to
>>   =20
>>
>add
> =20
>
>>--> > another Ethernet encapsulation to carry the next hop
>>--> address, i.e. 14
>>--> > bytes
>>--> > - total overhead will be 30 bytes
>>--> >
>>--> > Summarizing:
>>--> > - current proposal 20-24 bytes overhead
>>--> > - new proposal on point to point: 16 bytes
>>--> > - new proposal on shared media: 30 bytes
>>--> >
>>--> > Comments?
>>--> >
>>--> > -- Silvano
>>--> >
>>--> >
>>--> > _______________________________________________
>>--> > rbridge mailing list
>>--> > [e-mail]
>>--> > http://mailman.postel.org/mailman/listinfo/rbridge
>>--> >
>>--> > _______________________________________________
>>--> > rbridge mailing list
>>--> > [e-mail]
>>--> > http://mailman.postel.org/mailman/listinfo/rbridge
>>-->
>>--> _______________________________________________
>>--> rbridge mailing list
>>--> [e-mail]
>>--> http://mailman.postel.org/mailman/listinfo/rbridge
>>-->
>>   =20
>>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
> =20
>

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

------_=_NextPart_001_01C702AA.BC29B977
Content-Type: image/jpeg;
	name="trill.jpg"
Content-Transfer-Encoding: base64
Content-Description: trill.jpg
Content-Disposition: attachment;
	filename="trill.jpg"

/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAACgAA/+4AIUFkb2JlAGTAAAAAAQMA
EAMCAwYAAAbkAAAMGgAAIg3/2wCEABQQEBkSGScXFycyJh8mMi4mJiYmLj41NTU1NT5EQUFBQUFB
REREREREREREREREREREREREREREREREREREREQBFRkZIBwgJhgYJjYmICY2RDYrKzZERERCNUJE
RERERERERERERERERERERERERERERERERERERERERERERERERP/CABEIAVUBfwMBIgACEQEDEQH/
xADXAAEAAwEBAQAAAAAAAAAAAAAAAwQFAgEGAQEAAwEBAQAAAAAAAAAAAAAAAQIDBAUGEAACAgIA
BAQFBAIDAAAAAAACAwEEAAUQERITIDBAFFAhMRUGYHBBNCIkgDI1EQACAQIDBAUGCggEBQUAAAAB
AgMRIQAxEkFRYQRxgSIyE5GhsVJiIxAgMPDBQnKSMxRAUNGCorLSBfFT0zRw4WNzJIDC4rOEEgAB
AwIDBQcBCQAAAAAAAAABABECITFAURIQIGGRIjBgQYGhMgPRUHDwcbHxUmIT/9oADAMBAAIRAxEA
AAD7MAAAAAAjJFCwTgAIq0LzP9ib6vYtAAAAAAAAAAAAAAAAAEGfPkzS1Hz1NNSfF74+mxWleT0x
SnNoEI+Zl46vZ8ffjuMvU9XnC8AAAAAAAAAAACoW2b6i/U9uJqUNoj5uHdpcWkPU0fi9lDTxNu8B
jYAAANq7DM0/oeILwAAAAAAAAABTo2sead2+VqX7udo01ECcqSOT5nuDO3MFlMFCHTPVZksReGex
DWvF8UmHbyofW5t5jc+ry7apbi4ABRqTXZfPahdEWAAAA8ztIjI82PJh7TuRZQv04U3nvy3oCGUy
GYzqdmPr4INKjZU9ns+8/o5+b9EvWqtMrUr3lb1eXL91I/V5bV2LSi9JdRakujEzNitbLK2qOmnV
FdAAAAAAI4rMBOqwlGavY+f7FWajjaG9zcsQTsrVbPpARIAEepn7Ht8tGS078QAAFO4KdwAAAAAA
AHPUJkdyYdsdHmpq5XjlefPej6MbAAAAOGt6OPsh7PKAAAAAAAAAAAAABRp7SYw9SwgoX1bYfu3V
4NaKaPl05e+0nnyabaudb03dl56dWYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABRzuXTfYOlK4OnMqcl1x2Dg7cdhBOCkXQACAnVZzt
wO0E4QTgBBOAEE4AAABgTwT/ADXchmhlvD6ThxO7PBiea/hnxawzprvJ839nm658fBudReHL+jqE
Fbb4MWLZ8K0G9WmmZ3swmNZt5ZFNtRlG9kfSGDNa7My1b9Pn/ssTbAAAAKOdvuXTB0riQdOYAAAA
AAAAAAAAAAAAAAAABSqTXYY9xNwRIAAAAAAAAAAAAAAAAAAAAGJS0atss7ZztROsK6MLd+dJes22
m1XrVzc5zKp9oEAAAAAAAAAAAAAAAAeUrwo3gAQzEwJ0TBXvjPtTAJqAAAAAAAAAAAAAAAAUcvCP
onzutK4NpAAAAAAAAAAAAAAAAAAAAA+Voa1Dxq9Wa2gfQD2bAYXVXo0evlbB9FFjxH0XuCNjv57V
L9bJmNOX5ywb3PzFg+uAAAAAAAAAAABxn6arM0ekgkAAAAAAAoXxn6AAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf/2gAIAQIAAQUA8qZiM6hn0ccH2QVjLbTyZmeA
sMMVeKMBgsj0FqzKo6urDGIX4FNJRAcGPlx4Gn3DyJyF88kOEBMjlA5nOXg5Zy8fPhPzjIiZmYmJ
D5EfKZkomRbED1RmvKOeT51pUrYEfNhxJRMxklM+CkroDz2rhguUay8NapJT5/PgQwUMohOTRbGe
ydg0DnFVVr/SjbIKlNkGz6ZvPuI593xc855zzn5rqoNlNYFT6blnL4nyjOUZyj0THguVvBnp5iQc
sep3ppGCyBgf0N//2gAIAQMAAQUA8vlPoy+uAElELGOMxE4SoyYmJ83nHCY54tUFnLlkT8/AQwUT
HKfLL6/xH0wY5RwJkDguGZzn88dERnVHgkojInn4pjnnTHiZEwURMzEZIzM8ssRPLnGDHKOE/LPr
PkrLqGciPly55ERHgaXOfO+uAUiQlBR4TZy9BMRORERkTMZDZjIaOd0cl0YTCL9KCuSwgkfTj9D/
AOvi6JzonOic6J80WSOEcl6eSiMiYn08/LPrPDlOcpzlPpYmYzrLOss6i9Fzzn6f+f5/Tv8A/9oA
CAEBAAEFAPjrnLQP3atiLabPhdZSiJ29SM+8Vsjb1MTdrvn4HasRWWKeZXr6qQ1rCNkNKyTMc9aB
Zsmswlsbi6qVeBiFtwa/awL9hWV7irPwHaxyD8i/8/sVdYuhVMD9wYWhV/l5LEiyUXyT64igI94b
8ClBTcoF27i6l3KalV5mr0wp/XO22Z0g8n65Xsez9U/YLUX3F2fcpZg0YKeOwsykVhCxxqRbG7aQ
0vKmOea50rL0995LFr0UAtbcBr1y93WoPIvB3PcO4mAsHrKt5diCgVMFoem2Y9ObwYONl/U1v9TX
D1nwuO7CEL7S/C9hUsP/ACH2oRi3mmeFk2gFG21rONJ7pTNMCwAgCq2pbPhs2z6pqweJZWIq1spL
ypjnh0Wpz/aw0tiBGBjht/6niiep+7/prbZRYIYOKdtso90zLOwYgNU8e77pme6ZjrbRXVCFpqbK
yupoiWu1ZOVM967Peuz3rs967PeuyhMkmu2/Zmok9ZN2elfmkMFCSmsfDZhLKoFBjws2lVQrWlWg
ywckdhQ366NfIN5+5wAgB8VN/ZVT1qk1Va+vRdVSTmeFy/ZFUogCw1cqlC5uF5zki8KzimcmOeVx
7UcLa68ZSntt9uTsiIiG1EumNdXyIgY8T2doKleEILU1ZlOvroLxnq6xyvWVll6CyiWwN1fbnajO
Xbq4ZjXgnLNE9hNHXjSjy6yvcv8AWGcAK1TYYV5MBU2Bua4JrEquCvN5G4kpFAestpl6azO4vS9m
lrkksdg5UWGuQypglBx5SoO1NeuFcfXWKZdS4ZXGvVYOVqsV4x+tEpPvIxbQbHhIoCAcT8VrJPIi
Bj4M+hXfJanlk66zGeyuZ9vtTkaopxerrLn/AI0XLhLIq0NwEdrKdyXTwvbKtrxRtathKWi4ODmi
kEtFwZatKpq4FtKwK8Ni0qtl2+igCWi4HNFIJaLgr2lWeFW0q4rjatKpq42LSq3lVC7ocHF2i4Vg
Fm22qKog55Eit9xtUKnesU6rSWtZP2DNibKaHMsxSvPKvX1lu33jr9nWQl1DYWrtuw9vf2F/svsq
ubCw8rAvt1dx/t2K4WKC1C9q1k/YMr2na/XDWfQv1G2bamXLGsAaz6F/fPctO5ospa16n7O7S2L7
Zxcamw2s4V+TUHtBwcPdLhe1SbpJ0yVKdoUswfx2qCA0FeEp0KV4/RIcB6CvKY/G60KaHcCrpIrl
9n6luqte+xpIewaZC9NAlgzT92GaWGpHVqgKv47VrMDVqBT9EhwM1adfR1VAiu1tIitl6gCg1VAi
u36Cb6Y/Hkdm/okXWWNJXcFHTIpSv8ZqrPyblMjIrIqwLHdynTlM/sZZtlBSg2ZCWLyrbk5+GUJ6
kVLlu40ErpX7c9A8bG/Ax1v5Cl8N36mYW7VWTR3we2qb1FltPf17jvgRh7EqdE1BFG0yUh7w+KUG
FRLH3QSgwqJh1I4rWprkTNle19EyZ8CmImJ1NfB1VeJ8BVlnM1E5NROTUTlvUotDS1CagRWUM/sF
d2EV5KxaZIWbS5pX4s/Da5y0NlLIs0rTGkRyovAN/YXjZuHiu5vKVJlvdUqeO3VJCWbdbV2d1Squ
vbepryPawdjbbAqA19vUtKZvENnZbytSwdopVOttatuKO3qbAvUPrzSO7Vc5tKqxRVK822eDX7BW
kVsbJ2lX7fVNh6aynWa5VAslaqqt1tczY2+i/p8/KJGFNcu+54CFFz00wfIoUwfuA6YvdW/UMWLR
PSpnA0qYwAEI9DsKTrM63W+y/dj/2gAIAQICBj8A7KquMLp90slfSMgq7OiRCb5RqGfitUC4wOmH
vPouuvFRLVc1z9u7qj5jNCcbHASnmdjGyd6Gy6S+wyHhfZL4/MYFhUpjQqEzYM/BkDHwFSKBE6R6
/VGOip4luS9o9fqpxZjTAH+MqhPI6Y5p4c/x+/FOFUvuazeX6YAxl5HJN8nPPe1/KGjlngtMg4T/
ABnTwuqMVYc11yA/Kqdnlme6mk1lkFpjSWRw89V3Khpu4w+o0lmFqjWWZ7vtI1yTRNcsPL/T+1+I
KH+fgzt64fqDpohu43//2gAIAQMCBj8AxzbH8FntqF0pjga2VEd1imOAA2sbprbG2CWDdMFdO6ug
UcBSpVdlNxsu3qgQqbzRvgqKtdtB3VfEBkd+45q45q45q45jtW+0KoYqlFcq5Vz9xP8A/9oACAEB
AQY/AP17rlYKu9jTFixG8RSEeULTB8JwxGYGY6RmPi1ldUHtMB6cWkDfYBb+UHGb9UMn9OLvT7Ss
vpGKRSI53KwP6kMhFTYKN7GwHlx4sval9bdwXcPTtqcAyVLMdKIgqzHgPn5SMF1BWSM0IPZkQ/R6
Dkdow0Un4iUqfWBybruDxB2Y1ysFXecU5dKD15beRc/KVx76V29kHQvkWnnJxVEVTvAv8Skiq32g
Dj3DvHwVqr91qr5se9USr6ydlvumx+8OjB8NqkZqbMOkG4/UKP8AVSRC3Qez5iQcS/ufzrgSEEsG
JBPbkZ2FDTbqal6UHViTmZqCWYqWQXChRRRXaad45Vy4uIVq2hVLHuqak32k02ccxjxJCXk9Zvo2
AdHX8kCbMO6y2YdBxo5m67Jf6xs+0Lb9P6cWYgAZk4pyq6h/mPZOra3Vb2sap2MrEEXsorY0XLy1
PHBhdDNAaWB7Ype9xqpvBrvBzKjmY5CVrpBjlBv0C+X7MOnIRGOtA7yaqW9ljqrfLs8TisZIcVOo
3qTnq3182ymNDjTIM1+kbx8zTB8FdTgBmJ7qqTQV3kmwA4nZ8npb8D/6/wD4/wAv2cv0nwwGkcZp
GK06TZR1kY/ANPtrX59eBGi6JWNAJrDqK1DH2Q1ejAfmGMrC41d0dC5dZq3H4gjj/EksvAbW6vSQ
MBVyHwUNiLhhmDw+fTiSOXvHTpYZN2h5Dw8m2nyVDj8q+QGqI+ztX93Z7PQf0hUjNHkbQDutUnqA
txphfEIRWbSCfWO8+knrOBNyoMpZXZLECid5mrSgHlJoBnXCPKAdaKzDZUiuHhkNWjI7W9TkfSOq
vxHn2VMafZU0Plap6KfEKsKg7MUkOqPY+1ftcPa+9v8AkxInfjOterZ1io68LIl1YBh0H9Hjn+rG
3b4KwIr1GleFccurAFTzEQIORF8Tf9uT+U4h/wC3H/KMSz/VbSi8Qlb+ViOr4ZJRmqsw6QMLH6oA
+MBENQatI/VptHs8Pu7seJPKdP2tCivRTzk47JZTwdv24pKdSG2vIj7VLU42ptG34fcLqc2FTQDi
eA4XOJIJ1USRadTITpOqptW4oPieBF2VRnXxDewY0CjKwtU22UOysjO59qRvQDTyDBXl5mV1pqXX
rArlVWJpXhTpwY5AFlArQZEbx9I2eQn4phgpqHfc5L1bW4bMzsBrK7ueLkD7q0XzYC8tzFHOQSbX
/CSw82BDPTWe6wyanoPDrG2nyVDlj/xiCv8AlyVFPssK0HAg8CBingX3+ItP2+bAbmiEiJoyx3+8
xpRd+kfvUrgKooBYAfDJx0j+IfHlJzBVB0aQfSxxJ+7/ADDCRTsrrKGppFNBW5A3jpv0bSrXBFDh
CYZG7I7VY78bvj8CTyx/148Q8u+kd81Sy7TZmrTq6Rhm5KKT8tpoy1H4lc+0/q50O6oyx+BJ5Y/6
8fgSeWP+vDMIZAQCakx/14RVyCjA5zmJFbWGjij0gVepozNYDI1yGkVrqxzCGRXd/DaoYdttJZ9N
KVAJOQsMQyIpZg+nStKkMpqLkDjc7Mf7aX70X+pj/bS/ei/1Mf7aX70X+pj/AG0v3ov9TH+2l+9F
/qYDnvOWduljU/sxzDJINMTzRxppWrGnZFTYBTSm++q2IPGhiCuViDJeUOwzLG1K1qAbA2qBcOO8
roy9OoenLr+WIIqDYjA5dzVT+Ex/lPEbN68QfhlVc9DEdIuMBhkRX4fEmbSuVceJC2pcq/AZeVXX
bS5+rbdvIvZa1ysQMNEHF6VYDaCDlXzbMCaWRpCg0x6raRx3mm3/AJUMcRtkzjIdHtejbxCqKACg
Hx6SWiDMkcmyisVoTsyoK2O+uE5aTTKq1ILKKXJOV9+JOaOhQ2nQNIXRQUND7XCnXgTuCqrXw1ax
qbaiNlrAZ3NfjMx/BYlq+oTc19km9dl60FMTKWEiTu8hpaz7LHz4Q8xPrghIaNGVV06bLVhnQdFT
nuwr0IhU6hX67DKnsjOu00pb5co2R2jMHYRxGzBil/FXP2hsYdO0bDbcT8DQHOJin7ua/wANOv4V
5nmAPc1ZWbZXhtOVNtcr4mmCEPMVYQjvKBtfYpbMg+c4rzBqP8te71+t129nFBljU6gt62R8ovi6
6uDEsPIScUAoB8cuBUjIbzsHWbYSE3otG4nb5TioTT9glB5FIxrRBqH1j2m8pqfkC2gAnMoSlenT
SuAwQFhkXqxHRqrT9BDIaSJdG+g+ydvlzAwZJCI9J0uGPdbd+zeKEZ493FK43hQv85XCzlXjr2JN
a2psOoVWx45E7vgGo3OQFyegYRpS0SodSqjdquwnYCNlK554YI7sGv22rTosM9vylT+HEa9L7Pu5
9NN36aWY0AFScLzj2dh3aZKch9obT0jKlCyMJCF1BYu2xFaWA42rlvODy3MRGKXT4lNSuCtaZjbX
ZTCxxsEjkOlbV0tnQdIrTcdhrTBIuxzZrsev6MvlfBi731m2IN/TuG3orgRoKKPn5Tt/TZIhYurL
5RTCtkaXG4jMdRtgc54ZLUYuUFXI1U8gABOy1cI3LyeN4ok8XtB/DUdpaEXVdRpTI9NMRQkahUu4
PqgEeckDy4rd4d+bL07xxz37WwGUgg5EfJ0g7n1pdn7vrH+Ebd2NCDiTtJ3nj+nmXlyAx7yt3W+k
HjfiDgRjlmUDIR6NPVcegYI5fl1hBzZtI/hSpPWV6cE11O3ec5n9gGwfTU/AXhPhuc6CqnpX6RQ8
ce/jNPXj7S/1DyU441RsGG9TX41WIA3nH/joZPayT7xz/d1YrzTa/wDprZOva3Xb2cUFgP1PqkQa
vWHZb7wofPj3csi8DRx/EK+fHZlQ/ajP0P8ARjvRnqbF5Yx0Rk/+/HvJnPBAqj0E+fGrRqYfWkJc
9WqtOr/00+DDQyUqSclHHeTsHzNZmaQ+0xp90UUeTFYHZDwYletTUfTxwY5ABKorbJhvH0jZ5Cfg
Dcy4QMaLYknqFT8+OG5iKQNGgLPTNQK5r3hkaWvswssZqrgMp4G4+FpZDRUBZjwFzhZYzVXAZTwN
x8BnnOmNaVNCczTZfP4ZJ2f3cLmOQ6WswIFMqm5GVvjJ4pp4jrGlias2Qt/hgS8y2hSdINCb57Ad
2FljNVcBlPA3GGlkNFQFmPAXOFljNVcBlPA3GH8I18N2jexFGXMX/wAPgE8B1RtWhoRkabb5/EM8
50xrSpoTmabL5/ETxTTxHWNLE1Zshb/D5LxznKTJ5cvItB1fDHMM0dfusdLeY16QPh5hpgC8aRCD
VnoIOorv7Vi2yumuzHMygKOZbl5A1+0UpmV6QBqpwrjlOVjaYseXjcR8sNLVoAC8hyTZlbvN9XEk
cbOZY+YKMPEHiaFpVRJTOp727h2ccynI8xI0tQFj5i0sRHeBb2gOzkFO0NqI5sCeYSxwvrg5htTq
4WutHH1dgoBWzHNcctyZmeNPyqcw7Rmjux7N28/G9dhEHKSzzO7FgTy8fvpAt7GvZ021Zs33sc/y
/Ml/dnlyFlkEjLqYV7QArWgPDpriWZKFkR3FcqqK4gm/8qTxDSbxE9zpf6yZ6QueVx6otj+4dt2p
zGjttXuuva+01e0dtBjlkPMSS+OJvFEh7NVXV2V+rfdkLZVrzDxnmdcUjRwjl0rENB+ve5O21uIo
oji8STl0blVleNGoQdeV8iDSppWg07cc9zDczMogk5jw0R6DsitzmRkAttN6d7HLQs02luXSeT8o
vvGZrcKL1U4ZFeUHMmZHTmlhDN2GZWyemxgLA1a+q5riYDu8py0pJH+ZKhFDXMaLim3M7McjzKzu
4mMMLxP3ArrbSNhUDPNjfeDz3MtPJSF+aWOMNQDsnPba2kW0kVGeOW5MzPGn5VOYdozR3Y9m7efj
euwjnpVYNMnMSLrK5klFLUy21pl0jHKQnmJJUkEupZG+sqejKimummd8f2+Px5EMv5kSOGJYhTx2
0spPdzGWOfjjleTwPA8NpjrYeJnf0DLhnXlITzEkqSCXUsjfWVPRlRTXTTO+I4oG0NPKkBel1D1u
OPzFDccyGmeZGMRQS3Ze0te1tr0CnlOOYgE7wpy6oEERpVpFrVt9N1uBF6/26SRjWQcz4gWwbQKA
kZbK9OVMf3FwxYQpG8asSVB8MnLic6Y5HmpZ3kM08Duj90FqsNPq0FQQLHhQD5LwTnETGerLyrQ9
fwxwjN3X7qnU3mFOkj4RI2pJVFElibS6jp8udczTPEsWp2aZdEsrvqdhQgXNrA0FumuIykksbRRi
EPE+ligyBt6Keih5ZC6r4njqVbtI2XZPAb6njW+JoXaSTx9PiPI9X7Pdv7Oy3TUWxIXklkaWMwl5
X1MEOYFvTX01iAZ0eFQiSxtpfSBShNPo30pU1hhRpI/A1eG8b0ftd6/tbbdFBbE0WqSk+jxCWBaq
GtakZsbtWvCmGQgEMCKMKi+8bRwwpVSVVmaOOSQukbetpsCB2tH1r1Y1asc0TKdPMSeI4L1o2oNs
p2TTZRyKVYV93FzLKFaLWEGqoGoUJa3aHqgaTlXvHQ0iqYvEPvVjkIV95cDvKb2XSxr2iC50LzCR
qjCPwAA3ZVag1pawodIFDlq73u5otIK8w7s4Zq0L2bLT2fVA7WVSNR0Q9ko0IWNJFej6VFO0RSqm
9l0txXW2hOXIZFWQS60k954gzdmINa1NLA2XIEhJ0JYnmS3iMSNVGFKA0yUd0GtMJIC7iIe7SRtS
KbVYDeTfdW4AoKTwgtp5hpHe4qDIKGlvJWuIgGdHhUIksbaX0gUoTT6N9KVNZooIjOjEuYS2daWU
0r2QKrm1RY1xDLFHOscCsGfm7MQVKqiDKi3Nt5r9WvL6Gc/lvE0VIv4meq3kpTHM8wsR5hpgmuEm
ldFuzataX2mo7N8QyxRzrHArBn5uzEFSqogyotzbea/VqYJxVTkdoO8cf8DbEsLvI5nKeJI71fsd
0VpS3R9FDMWeN2Uo7RNp1ruaxr865CkUcZeHwa+G0LaWGrO989pzO+5rKV1P4wXxPEOrVQGpNvrV
JavVQWwjhpKROJIlL1VL10gUyJpXbYXzr8j40NBJShBycfQRsPUeFJlaM+2pp94dk9RxSBWkPBSF
+8ez5+jBlkIMrClslG4fSdvkA/4GGKAAuO8zd1f2nhbeSLVrLLIx9l9A/g04rFK4O521jr1VPkIx
4UwCyUrbJhvH0jZxz/VqyHvP7xulrn9mJUARYY5JIi479stIuKjMk2NbCxxGkXiIpLCWSQtpmcr2
b5FqknZetL0GFkHeR0I62APlBI6/icxFy6yeLEJgX0VVGRSQSbijEHTvIuBiGKXWJJEFJXXSjuAN
QU79VsgK2GYrPDEJA8QlV3EYYIUUnUb0vQ6QcyKGmINeuaaVFYJGg1sNNSxUGg8u+lQDTmOc5iSs
SzOkVqErQFVAtU9N99hhoNLxuiGV/FXRpAO2p3ENuoc9mFhRZBr1+E7pRH0Z6T+0Dje36jKtaEkl
G2LX6p3X7pypbMXnR2p40kjqyG4D+hhiNebdDDCyyKy6tbFMtWq182z+nCsPwUIbV67DKnAG9d9K
bfic+hHakl5nwwL69SW00z22F6gg3BxyXKeC0ZgeN3keye6GSnaxGa5qQQcmI59CO1JLzPhgX16k
tppntsL1BBuDjluc8NpI/wAsnLOsf4iutz2TQm4oQLijE0pd5jHSVOdPM+DqBLACpVSKhiL5eq1t
Q04lohiEnKNDH4hGbMe9prpNQ3Z73ZJpmBy8Mo5nXE6k+JKvgAx+oaHUbU0C47QLDST+o6G4OKoG
ThG7IPIDTzYqylz/ANRmfzMSPN8UsVu2Z+eRsLi9l9UUPZAqALWy3bshcX7K+qKHsgVAFrZbt2Qu
L9lfVFD2QKgC1st27IXF+yvqigBBRlKsjxnSVK7tmVssqeqtDHqeSv1pWqwyyNqU0jK9hewpUIK2
GW6lPQPur6op/wAAvDjGuQ3pWyjefoGZ8+KtMV4RqoHnDHz4qspb2ZFBHmCnz4KsNMgzWtbbwdo8
42jL9W+M3ek94f3v2C3VjlzEAX97TVYd0XPRnh4plCyxkatPdIbIj5/sCSrmrr5CaEdYPxXbkEiE
CHQsk2r3hGZXT9X51zCws0Jid+YXl3SS9jtUileByzzzx4M8oVwKldLNSu+gOF8aUDWNS0q1V39k
Gx2HbswnMPKBHJ3CKmvUBW221jY3xDNysiFJJliJcNtzAAFQ27VQbTmMDl5pQshpa9q5VNKDrItf
LATmZArMKgUJNOoH/n1Y5ROXKvDzAlJa9ewtRTdexqOFjiFxpCvMkbl8grVqcxSlMzbDzwyBkjBL
mhqABXIivmvsxGOVlRqyRI+pXykBIAoO9bbYXDUOHi8RfzCozqhrSukkAnK+6oJtTMYj5zmmCB0R
jn3mFaAXPpth2hkDCMKznIKGFbk2yz3baHBTlpAzKKkUINOsD/l1/pPhn8NifDbZe+npGzeOvEUs
LKpj197iMuvI7tmHlmYNLIRq090BcgPn+0qR+EjBmO9luFHXc9FOj4n5HntUfhs4jkKErKpJao0g
77jZa9agcpLJGYq83FpR+9pBYAsKChO69tuObhlleIh5dHLQRaddu+7UupWrPU3HayoMcrL4j8vz
P5VBHNp1RMKDsMKNXflaoJqdIxynMTq/KP2zFJCnYjbivqyd4LQ1Fb0qTysjqob87GC6LpEpv7yl
Bnt4jZkOa5fnYi0ksxkRPDD+KjN2KbDQ1NDkcu1UYmhlleBSI9K8vF72e1qPStQ3ZGw921zj+1//
AK/pxy5dS6jmIqoBqLCjWptrlTbjm+c5VSYRykkTSadIZ89tz2bZWpu01/toUADxuVNt5Uk+U3xz
/KcxGfHmeWSMaNWtGqVau5Lsa929O0CMf23nJlLQRIPEamrSWRQpI4G9dlN9Af7keUQnX+XdV06S
1O0WA9q7Da1d5xDNHzDS+GhVlXl1iCKRZHII291RrFQSKC/6SUcBlOYNxj3byR8Fao/jDY94zycH
a3kUKD14CqAFFgBl+hI/LztA6E5DUrAjapseFcr9TySOZZpTqkka1aZADIAD50oB/wAV/wD/2Q==

------_=_NextPart_001_01C702AA.BC29B977--


Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA7KIhFH025249 for <[e-mail]>; Tue, 7 Nov 2006 12:18:43 -0800 (PST)
Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 07 Nov 2006 12:18:43 -0800
X-IronPort-AV: i="4.09,397,1157353200";  d="scan'208"; a="1862613978:sNHT233297704"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA7KIhKv020137; Tue, 7 Nov 2006 12:18:43 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA7KIWbL018187; Tue, 7 Nov 2006 12:18:41 -0800 (PST)
Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 7 Nov 2006 12:18:33 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 7 Nov 2006 12:18:31 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: AccCmhUxw+MxPZZEQ5WCodMfSRFwfAADEf6g
From: "Sanjay Sane \(sanjays\)" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Silvano Gai" <[e-mail]>
X-OriginalArrivalTime: 07 Nov 2006 20:18:33.0237 (UTC) FILETIME=[E5DA5C50:01C702A9]
DKIM-Signature: a=rsa-sha1; q=dns; l=12218; t=1162930723; x=1163794723; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=22Sanjay=20Sane=20\(sanjays\)=22=20<[e-mail]> |Subject:RE=3A=20[rbridge]=20Should=20we=20optimize=20the=20common=20case?; X=v=3Dcisco.com=3B=20h=3DJNDIWYHV1ktwATfyMWW0wscQadE=3D; b=AZjxm69XiTknvThsCyWrnzUJQBcPiAzK0VOPZDg9bOFzNt4VRwdBDfKcYUYv4i7xwgHbvqoS q0MMjiovaR1tIfYSm4uTVf2KA4ryW5XbKu3ftsCeoxk/BAuJYbVqn1pR;
Authentication-Results: sj-dkim-5.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA7KIhFH025249
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2006 20:19:12 -0000
Status: RO
Content-Length: 11669

Radia,

In today's presentation, the last suggested format was the following

48 bits - egress rbridge id
48 bits - ingress rbridge id
16 bits - pt = TRILL
16 bits - reserved + flag + TTL - the link local nicknames (who's
supposed to be the next-hop is in here) 
....


when this goes over a shared media, there were learning issues as
pointed out during the meeting. Pls refer to this diagram to understand
the problem

1. if packets from r1 to r5 are sent once via r2, and other times, via
r3, the classical bridge b will learn r1 as behind link 1 or 2. So, this
is the learning problem. 
2. thus, for return traffic frm r5 to r1, even though r4 wants r2 to be
the next-hop for this packet, if we keep the destination rbridge id as
r1, the classical bridge would forward the packet to link 1, thereby
blackholing this traffic. 

So, there are multiple issues - learning issues and blakholing. 

Potential solution:

r2, r3 and r4 exchange the link-local nicknames, say link local nickname
for r2 = 1, r3 = 2, r4 = 3.

Now, instead of using the complete 48 bit rbridge ID as the rbridge MAC
address, we can fill the 48 bits as follows:

16 bit - rbridge nickname
4 bits - link local nickname

2 bits - I/G and U/L
26 bits - reserved. 

Thus, on this classical ethernet/bridging cloud, rbridge emits the
packet with the appropriate link-local nicknames.

For e.g. 
- packets from r1 to r5, sent via r2, are sent with
SA = r1.<link source's link-local-nickname> = r1.1, , notice
link-local-nickname of r2 is chosen. 
If r2 intends r4 to be the next-hop, he'll put 
DA = r5.<link destination's link-local-nickname> = r5.3, notice
link-local-nickname of r4 is chosen. 
Thus, classical bridge will learn r1.1 on the link 1. 

- packets from r1 to r5, sent via r3, are sent with
SA = r1.<link source's link-local-nickname> = r1.2, , notice
link-local-nickname of r3 is chosen. 
If r3 intends r4 to be the next-hop, he'll put 
DA = r5.<link destination's link-local-nickname> = r5.3, notice
link-local-nickname of r4 is chosen. 
Thus, classical bridge will learn r1.2 on the link 1. 

-- thus no learning issues. 

- return traffic from r5 to r1, sent via r4. If r4 intends r2 to be the
next hop, it'll put

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Tuesday, November 07, 2006 10:23 AM
To: Silvano Gai
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?

Looking at Silvano's proposed shim header---the only reason we need the
outer header is to distinguish between RBridge neighbors, in the case of
unicast, specifying next hop, and in the case of multicast, specifying
transmitter.

His format has two bytes after the Ethernet header portion of the shim
for TTL, and a bunch of reserved bits.

That leaves 10 bits. We can dynamically (through the IS-IS Hello) give
out, say, 4 bit link-local nicknames, and stick them there.

Then the only time we'd need an outer header is if there are more than,
say, 16 RBridges on the same link.

Radia

Silvano Gai wrote:

>I am not looking at TRILL for increased scalability, but for spanning 
>tree replacement to get high bisectional bandwidth.
>
>-- Silvano
>
>  
>
>>-----Original Message-----
>>From: Gray, Eric [mailto:[e-mail]]
>>Sent: Monday, November 06, 2006 10:38 AM
>>To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
>>Subject: RE: [rbridge] Should we optimize the common case?
>>
>>Silvano,
>>
>>	The assertion that only fortune 500 companies are interested in
TRILL 
>>is baseless and untrue.  One reason why you may believe this is the 
>>case, is that you are making certain assumptions about complexity and 
>>scale of the desired solution that are equally unfounded or false.
>>
>>	There is nothing that particularly prohibits definition of some
form 
>>of RBridge functionality that might be simple enough to deploy in 
>>relatively small networks - where higher speed link are becoming more 
>>common and wasting high speed links is also a problem.
>>
>>	The types of networks you're talking about cannot realistically 
>>operate with plug & play devices, and greater scalability is
>>    
>>
>paramount.
>  
>
>>The work we're doing in this WG is aimed at simplistic, plug & play 
>>deployment where increased scalability is a secondary consideration.
>>
>>--
>>Eric
>>
>>--> -----Original Message-----
>>--> From: [e-mail]
>>--> [mailto:[e-mail]] On Behalf Of Silvano Gai
>>--> Sent: Monday, November 06, 2006 1:51 AM
>>--> To: Eastlake III Donald-LDE008; [e-mail]
>>--> Subject: Re: [rbridge] Should we optimize the common case?
>>-->
>>-->
>>--> Donald,
>>-->
>>--> The high end and the low end are extremely different.
>>-->
>>--> The customers interested in TRILL are the Fortune 500 companies. 
>>--> Large Enterprise networks and large data centers used to run 
>>--> Financial, Insurance, Health, Chemical, Oil, Information and 
>>--> manufacturing companies.
>>-->
>>--> They have huge demand for high bandwidth and low latency.
>>-->
>>--> Each of these companies spends millions each year in network 
>>--> operation
>>--> (OPEX) and millions in new equipment (CAPEX). In all of them OPEX
>>    
>>
>is
>  
>
>>--> much larger than CAPEX. They only buy major vendor equipments and 
>>--> they install them according to the recommended vendor design 
>>--> guideline.
>>--> Typically they have an internal certification lab in which they 
>>--> test the network configuration and the software releases before 
>>--> putting them in production networks.
>>-->
>>--> They have a very well defined concept of backbone ports and access

>>--> ports. All the backbone ports are in fiber at the highest possible

>>--> speed (today 10 GE). For the access port they use a mix of fiber 
>>--> and copper.
>>--> The backbone has a regular structure that matches the vendor
>>    
>>
>design
>  
>
>>--> guideline and the result of the certification experiment
>>--> they have done
>>--> independently.
>>-->
>>--> A network outage can cost millions/hour.
>>-->
>>--> There is no way you will see in one of these backbones a hub or
>>    
>>
>any
>  
>
>>--> other uncontrolled device. NEVER.
>>-->
>>--> That is the reason why I think this is the most important case for
>>--> TRILL.
>>-->
>>--> More inline.
>>-->
>>--> > -----Original Message-----
>>--> > From: [e-mail]
>>--> [mailto:[e-mail]]
>>--> On
>>--> > Behalf Of Eastlake III Donald-LDE008
>>--> > Sent: Sunday, November 05, 2006 10:20 PM
>>--> > To: [e-mail]
>>--> > Subject: Re: [rbridge] Should we optimize the common case?
>>--> >
>>--> > Silvano,
>>--> >
>>--> > Why do you think that 90% of Rbridge deployment will be for this
>>--> unusual
>>--> > case? I mean, I have no problem with the belief that
>>--> Rbridges would be
>>--> > better than bridges in this case but why shouldn't that be true
>>    
>>
>of
>  
>
>>--> less
>>--> > high end uses?
>>--> >
>>--> > A while ago on this list I posted a rhetorical question as to
>>    
>>
>why
>  
>
>>--> > Rbriges shouldn't eventually replace all bridges. No one posted
>>    
>>
>an
>  
>
>>--> > answer.
>>-->
>>--> This technology will start in the high end and move down to
>>--> the lower
>>--> end. How low will it goes is a good question.
>>-->
>>--> The low end is extremely cost sensitive. When we buys a switch or
>>    
>>
>a
>  
>
>>--> router on the Internet for 50-100$, the COGS cannot be more
>>--> that 15-30$,
>>--> even with low margins. This implies that few dollar more to
>>--> increase the
>>--> memory size or the processor speed are a big deal. Add software
>>--> development cost. Couple this with the fact that today we
>>--> have low cost
>>--> 1GE switches used by low-end users that have problems
>>--> pushing or pulling
>>--> more than few Mb/s. There is no bandwidth demand in the low end.
>>--> Spanning tree is just fine. Cost is the big issue. Moreover
>>--> there is the
>>--> huge issue of training home/small office installers in this new
>>--> technology.
>>-->
>>--> My 0.2 cents
>>-->
>>--> -- Silvano
>>-->
>>--> >
>>--> > Why not specify Rbridges more or less as we have been for
>>--> the common
>>--> > bridge case and, in the backbone case you are talking
>>--> about, just drop
>>--> > the MAC addresses on the point-to-point links within the
>>    
>>
>backbone?
>  
>
>>--> > Doesn't that produce less overhead than your proposal
>>--> below in both
>>--> the
>>--> > point-to-point and shared media cases?
>>--> >
>>--> > Donald
>>--> >
>>--> > -----Original Message-----
>>--> > From: [e-mail]
>>--> [mailto:[e-mail]]
>>--> On
>>--> > Behalf Of Silvano Gai
>>--> > Sent: Wednesday, November 01, 2006 9:07 PM
>>--> > To: [e-mail]
>>--> > Subject: [rbridge] Should we optimize the common case?
>>--> >
>>--> >
>>--> > With 16 bit addresses the current TRILL overhead over
>>--> Ethernet is 20
>>--> > bytes. If we want to expand the RBridge addresses, it we
>>--> will go to
>>--> > 22-24 bytes.
>>--> >
>>--> > What customers are telling us is that they will deploy RBridges
>>    
>>
>by
>  
>
>>--> > creating an RBridge backbone in which all the links will be
>>    
>>
>10GE.
>  
>
>>--> >
>>--> > They will connect regular bridges and host to the
>>--> periphery of this
>>--> > backbone.
>>--> >
>>--> > They will not mix backbone ports with access ports, because this
>>--> screws
>>--> > up management, traffic engineering, debugging, and
>>--> troubleshooting.
>>--> > Regular network design, easy to understand, is very
>>--> important. Ports
>>--> are
>>--> > cheap, labor is expensive.
>>--> >
>>--> > I am totally convinced that this will account for 90+ % of TRILL
>>--> > deployment.
>>--> >
>>--> > I am wondering if it makes sense to have a solution
>>--> highly optimized
>>--> for
>>--> > such an environment.
>>--> >
>>--> > For example we can put the egress/ingress RBridge addresses in
>>    
>>
>the
>  
>
>>--> outer
>>--> > MAC addresses and define a TRILL shim header that
>>--> contains 1 byte of
>>--> hop
>>--> > limit and 1 byte reserved. For this common case we will get:
>>--> > 1) overhead of 16 bytes (4 to 8 bytes lower)
>>--> > 2) nickname = MAC address, i.e no hash collision
>>--> > 3) zero-conf achieved
>>--> >
>>--> > In the case we need to go over a shared media we will need to
>>    
>>
>add
>  
>
>>--> > another Ethernet encapsulation to carry the next hop
>>--> address, i.e. 14
>>--> > bytes
>>--> > - total overhead will be 30 bytes
>>--> >
>>--> > Summarizing:
>>--> > - current proposal 20-24 bytes overhead
>>--> > - new proposal on point to point: 16 bytes
>>--> > - new proposal on shared media: 30 bytes
>>--> >
>>--> > Comments?
>>--> >
>>--> > -- Silvano
>>--> >
>>--> >
>>--> > _______________________________________________
>>--> > rbridge mailing list
>>--> > [e-mail]
>>--> > http://mailman.postel.org/mailman/listinfo/rbridge
>>--> >
>>--> > _______________________________________________
>>--> > rbridge mailing list
>>--> > [e-mail]
>>--> > http://mailman.postel.org/mailman/listinfo/rbridge
>>-->
>>--> _______________________________________________
>>--> rbridge mailing list
>>--> [e-mail]
>>--> http://mailman.postel.org/mailman/listinfo/rbridge
>>-->
>>    
>>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>

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



Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA7IMslI016648 for <[e-mail]>; Tue, 7 Nov 2006 10:22:54 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 07 Nov 2006 10:22:54 -0800 (PST)
Received: from sun.com ([129.150.26.83]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 07 Nov 2006 10:22:53 -0800 (PST)
Date: Tue, 07 Nov 2006 10:22:54 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Silvano Gai <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2006 18:23:05 -0000
Status: RO
Content-Length: 9064

Looking at Silvano's proposed shim header---the only reason
we need the outer header is to distinguish between RBridge neighbors,
in the case of unicast, specifying next hop, and in the case of
multicast, specifying transmitter.

His format has two bytes after the Ethernet header portion of the shim
for TTL, and a bunch of reserved bits.

That leaves 10 bits. We can dynamically (through the IS-IS Hello)
give out, say, 4 bit link-local nicknames, and stick them there.

Then the only time we'd need an outer header is if there are more than,
say, 16 RBridges on the same link.

Radia

Silvano Gai wrote:

>I am not looking at TRILL for increased scalability, but for spanning
>tree replacement to get high bisectional bandwidth.
>
>-- Silvano
>
>  
>
>>-----Original Message-----
>>From: Gray, Eric [mailto:[e-mail]]
>>Sent: Monday, November 06, 2006 10:38 AM
>>To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
>>Subject: RE: [rbridge] Should we optimize the common case?
>>
>>Silvano,
>>
>>	The assertion that only fortune 500 companies are interested in
>>TRILL is baseless and untrue.  One reason why you may believe this is
>>the case, is that you are making certain assumptions about complexity
>>and scale of the desired solution that are equally unfounded or false.
>>
>>	There is nothing that particularly prohibits definition of some
>>form of RBridge functionality that might be simple enough to deploy in
>>relatively small networks - where higher speed link are becoming more
>>common and wasting high speed links is also a problem.
>>
>>	The types of networks you're talking about cannot realistically
>>operate with plug & play devices, and greater scalability is
>>    
>>
>paramount.
>  
>
>>The work we're doing in this WG is aimed at simplistic, plug & play
>>deployment where increased scalability is a secondary consideration.
>>
>>--
>>Eric
>>
>>--> -----Original Message-----
>>--> From: [e-mail]
>>--> [mailto:[e-mail]] On Behalf Of Silvano Gai
>>--> Sent: Monday, November 06, 2006 1:51 AM
>>--> To: Eastlake III Donald-LDE008; [e-mail]
>>--> Subject: Re: [rbridge] Should we optimize the common case?
>>-->
>>-->
>>--> Donald,
>>-->
>>--> The high end and the low end are extremely different.
>>-->
>>--> The customers interested in TRILL are the Fortune 500
>>--> companies. Large
>>--> Enterprise networks and large data centers used to run Financial,
>>--> Insurance, Health, Chemical, Oil, Information and manufacturing
>>--> companies.
>>-->
>>--> They have huge demand for high bandwidth and low latency.
>>-->
>>--> Each of these companies spends millions each year in
>>--> network operation
>>--> (OPEX) and millions in new equipment (CAPEX). In all of them OPEX
>>    
>>
>is
>  
>
>>--> much larger than CAPEX. They only buy major vendor
>>--> equipments and they
>>--> install them according to the recommended vendor design guideline.
>>--> Typically they have an internal certification lab in which
>>--> they test the
>>--> network configuration and the software releases before
>>--> putting them in
>>--> production networks.
>>-->
>>--> They have a very well defined concept of backbone ports and access
>>--> ports. All the backbone ports are in fiber at the highest
>>--> possible speed
>>--> (today 10 GE). For the access port they use a mix of fiber
>>--> and copper.
>>--> The backbone has a regular structure that matches the vendor
>>    
>>
>design
>  
>
>>--> guideline and the result of the certification experiment
>>--> they have done
>>--> independently.
>>-->
>>--> A network outage can cost millions/hour.
>>-->
>>--> There is no way you will see in one of these backbones a hub or
>>    
>>
>any
>  
>
>>--> other uncontrolled device. NEVER.
>>-->
>>--> That is the reason why I think this is the most important case for
>>--> TRILL.
>>-->
>>--> More inline.
>>-->
>>--> > -----Original Message-----
>>--> > From: [e-mail]
>>--> [mailto:[e-mail]]
>>--> On
>>--> > Behalf Of Eastlake III Donald-LDE008
>>--> > Sent: Sunday, November 05, 2006 10:20 PM
>>--> > To: [e-mail]
>>--> > Subject: Re: [rbridge] Should we optimize the common case?
>>--> >
>>--> > Silvano,
>>--> >
>>--> > Why do you think that 90% of Rbridge deployment will be for this
>>--> unusual
>>--> > case? I mean, I have no problem with the belief that
>>--> Rbridges would be
>>--> > better than bridges in this case but why shouldn't that be true
>>    
>>
>of
>  
>
>>--> less
>>--> > high end uses?
>>--> >
>>--> > A while ago on this list I posted a rhetorical question as to
>>    
>>
>why
>  
>
>>--> > Rbriges shouldn't eventually replace all bridges. No one posted
>>    
>>
>an
>  
>
>>--> > answer.
>>-->
>>--> This technology will start in the high end and move down to
>>--> the lower
>>--> end. How low will it goes is a good question.
>>-->
>>--> The low end is extremely cost sensitive. When we buys a switch or
>>    
>>
>a
>  
>
>>--> router on the Internet for 50-100$, the COGS cannot be more
>>--> that 15-30$,
>>--> even with low margins. This implies that few dollar more to
>>--> increase the
>>--> memory size or the processor speed are a big deal. Add software
>>--> development cost. Couple this with the fact that today we
>>--> have low cost
>>--> 1GE switches used by low-end users that have problems
>>--> pushing or pulling
>>--> more than few Mb/s. There is no bandwidth demand in the low end.
>>--> Spanning tree is just fine. Cost is the big issue. Moreover
>>--> there is the
>>--> huge issue of training home/small office installers in this new
>>--> technology.
>>-->
>>--> My 0.2 cents
>>-->
>>--> -- Silvano
>>-->
>>--> >
>>--> > Why not specify Rbridges more or less as we have been for
>>--> the common
>>--> > bridge case and, in the backbone case you are talking
>>--> about, just drop
>>--> > the MAC addresses on the point-to-point links within the
>>    
>>
>backbone?
>  
>
>>--> > Doesn't that produce less overhead than your proposal
>>--> below in both
>>--> the
>>--> > point-to-point and shared media cases?
>>--> >
>>--> > Donald
>>--> >
>>--> > -----Original Message-----
>>--> > From: [e-mail]
>>--> [mailto:[e-mail]]
>>--> On
>>--> > Behalf Of Silvano Gai
>>--> > Sent: Wednesday, November 01, 2006 9:07 PM
>>--> > To: [e-mail]
>>--> > Subject: [rbridge] Should we optimize the common case?
>>--> >
>>--> >
>>--> > With 16 bit addresses the current TRILL overhead over
>>--> Ethernet is 20
>>--> > bytes. If we want to expand the RBridge addresses, it we
>>--> will go to
>>--> > 22-24 bytes.
>>--> >
>>--> > What customers are telling us is that they will deploy RBridges
>>    
>>
>by
>  
>
>>--> > creating an RBridge backbone in which all the links will be
>>    
>>
>10GE.
>  
>
>>--> >
>>--> > They will connect regular bridges and host to the
>>--> periphery of this
>>--> > backbone.
>>--> >
>>--> > They will not mix backbone ports with access ports, because this
>>--> screws
>>--> > up management, traffic engineering, debugging, and
>>--> troubleshooting.
>>--> > Regular network design, easy to understand, is very
>>--> important. Ports
>>--> are
>>--> > cheap, labor is expensive.
>>--> >
>>--> > I am totally convinced that this will account for 90+ % of TRILL
>>--> > deployment.
>>--> >
>>--> > I am wondering if it makes sense to have a solution
>>--> highly optimized
>>--> for
>>--> > such an environment.
>>--> >
>>--> > For example we can put the egress/ingress RBridge addresses in
>>    
>>
>the
>  
>
>>--> outer
>>--> > MAC addresses and define a TRILL shim header that
>>--> contains 1 byte of
>>--> hop
>>--> > limit and 1 byte reserved. For this common case we will get:
>>--> > 1) overhead of 16 bytes (4 to 8 bytes lower)
>>--> > 2) nickname = MAC address, i.e no hash collision
>>--> > 3) zero-conf achieved
>>--> >
>>--> > In the case we need to go over a shared media we will need to
>>    
>>
>add
>  
>
>>--> > another Ethernet encapsulation to carry the next hop
>>--> address, i.e. 14
>>--> > bytes
>>--> > - total overhead will be 30 bytes
>>--> >
>>--> > Summarizing:
>>--> > - current proposal 20-24 bytes overhead
>>--> > - new proposal on point to point: 16 bytes
>>--> > - new proposal on shared media: 30 bytes
>>--> >
>>--> > Comments?
>>--> >
>>--> > -- Silvano
>>--> >
>>--> >
>>--> > _______________________________________________
>>--> > rbridge mailing list
>>--> > [e-mail]
>>--> > http://mailman.postel.org/mailman/listinfo/rbridge
>>--> >
>>--> > _______________________________________________
>>--> > rbridge mailing list
>>--> > [e-mail]
>>--> > http://mailman.postel.org/mailman/listinfo/rbridge
>>-->
>>--> _______________________________________________
>>--> rbridge mailing list
>>--> [e-mail]
>>--> http://mailman.postel.org/mailman/listinfo/rbridge
>>-->
>>    
>>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>



Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA7HXNBL001992 for <[e-mail]>; Tue, 7 Nov 2006 09:33:23 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 07 Nov 2006 09:33:19 -0800 (PST)
Received: from sun.com ([129.150.31.13]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 07 Nov 2006 09:33:19 -0800 (PST)
Date: Tue, 07 Nov 2006 09:33:19 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Radia Perlman <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 8BIT
X-Accept-Language: en-us, en
References: <[e-mail]> <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2006 17:34:02 -0000
Status: RO
Content-Length: 5328

Actually---not sure what I said is correct. If there was actually 
connectivity (not through bridges)
it would act like I said (where the other ports would turn off).

However, beyond one hop, each port would still be reporting "R" as the 
root, so this would
actually partition the bridged cloud. Which is I think what we'd want. 
And what Sanjay said
would happen.

And this might also be the thing that does the right thing in the 
"wiring closet" case.

Radia

Radia Perlman wrote:

>Interesting question.
>
>If the RBridge is on the cut set of the link, then, indeed, the cloud 
>would get
>partitioned into multiple spanning tree domains all connected via the 
>RBridge. But
>that's a good thing.
>
>If there *is* connectivity between two of the RBridge's ports through
>the link, the RBridge will recognize this because the Root isn't simply 
>"R", but "R" concatenated with
>a port number. So RBridge R will state it is root "R.1" on one port and 
>"R.2" on the other.
>So R.1 will be the Root. So R's other port will decide "Oh...I'm not the 
>Root, so I'm not Designated
>RBridge on this link and therefore I won't forward traffic to/from this 
>link.
>
>
>Radia
>
>
>
>Sanjay Sane (sanjays) wrote:
>
>  
>
>>Radia,
>>
>>as per this proposal, 
>>if a rbridge is connected to the same bridging cloud by n ports, 
>>AND if the rbridge treats each of the ports as separate STP instances,
>>THEN it would break that single bridging cloud into n disjoint trees. 
>>Is that accurate? 
>>
>>btw, it could be that multiple ports of the same rbridge may, in fact, connect distinct bridging clouds. In such a scenario, it would not be a good idea for the rbrdige to merge the STP instances. 
>>
>>-Sanjay
>>
>>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
>>Sent: Monday, November 06, 2006 2:52 PM
>>To: Radia Perlman
>>Cc: [e-mail]
>>Subject: Re: [rbridge] Traffic storms
>>
>>Radia,
>>      As you know, I support this approach. I have a doubt, however. 
>>The ID used is the RBridge ID or a different ID per port?
>>I assume it is by RBridge ID. Then, as far I understand, several ports of an RBridge could be connected to the same bridged link. In other words, an RBridge port may have to compete against other port of same RBridge for "root bridge" election. In this case, if the ID is the same (the RBridge ID), the link will split into two separate trees near the equal cost point if that is possible (at least a bridge exists between RBridge ports) to balance the cost of link connected to each of the root bridge ports, or by any of the standard tie breaking mechanisms like port ID if no there is no bridge interposed.
>>Regards
>>Guillermo
>>Radia Perlman escribi?:
>> 
>>
>>    
>>
>>>I hesitate to bring this up because I don't want to reintroduce 
>>>confusion about "participating" in bridge spanning tree algorithm. So, 
>>>please---what I'm about to propose does NOT merge links. Bridged links 
>>>still terminate at an RBridge.
>>>
>>>The issue is that it can be unpleasant for two RBridges to 
>>>simultaneously think they are both Designated on the same link, which 
>>>can happen if a bridge came up and connected two links. Or for that 
>>>matter, a repeater.
>>>
>>>One way of making sure that a situation like that resolves very 
>>>quickly, and absolutely, is to have RBridges act like bridges on each 
>>>of their ports, with numerically lowest (i.e., highest) priority for become Root.
>>>
>>>Now---I DO NOT MEAN that an RBridge merges the spanning trees on each 
>>>of its ports.
>>>The spanning tree is terminated at an RBridge. If an RBridge has 4 
>>>ports, it will participate in 4 independent bridge spanning tree 
>>>instances.
>>>
>>>The advantage of doing this is that we could make the Root bridge be 
>>>the Designated RBridge. Then if two RBridge links merged, the RBridges 
>>>would notice immediately.
>>>If you get usurped as bridge Root, you are also usurped as RBridge 
>>>Designated RBridge.
>>>
>>>Since the bridge spanning tree messages are never delayed by 
>>>pre-forwarding delays, this seems like it might be a nice thing to do.
>>>
>>>It would be nice if the same RBridge that would get elected Desiganted 
>>>RBridge in the IS-IS link election would be elected bridge Root on 
>>>that link. The easiest thing would be not to bother with IS-IS 
>>>priority, and have them all have the same priority, with election 
>>>being solely on ID. Then they can all use the lowest bridge root 
>>>priority, and the same RBridge would get elected bridge root on the 
>>>link as would get elected Designated RBridge on the link.
>>>
>>>Radia
>>>
>>>_______________________________________________
>>>rbridge mailing list
>>>[e-mail]
>>>http://mailman.postel.org/mailman/listinfo/rbridge
>>> 
>>>   
>>>
>>>      
>>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://mailman.postel.org/mailman/listinfo/rbridge
>> 
>>
>>    
>>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>



Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA735cfN008381 for <[e-mail]>; Mon, 6 Nov 2006 19:05:38 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 06 Nov 2006 19:05:34 -0800 (PST)
Received: from sun.com ([129.150.26.163]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 06 Nov 2006 19:05:31 -0800 (PST)
Date: Mon, 06 Nov 2006 19:05:32 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Sanjay Sane (sanjays)" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 8BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2006 03:06:05 -0000
Status: RO
Content-Length: 4546

Interesting question.

If the RBridge is on the cut set of the link, then, indeed, the cloud 
would get
partitioned into multiple spanning tree domains all connected via the 
RBridge. But
that's a good thing.

If there *is* connectivity between two of the RBridge's ports through
the link, the RBridge will recognize this because the Root isn't simply 
"R", but "R" concatenated with
a port number. So RBridge R will state it is root "R.1" on one port and 
"R.2" on the other.
So R.1 will be the Root. So R's other port will decide "Oh...I'm not the 
Root, so I'm not Designated
RBridge on this link and therefore I won't forward traffic to/from this 
link.


Radia



Sanjay Sane (sanjays) wrote:

>Radia,
>
>as per this proposal, 
>if a rbridge is connected to the same bridging cloud by n ports, 
>AND if the rbridge treats each of the ports as separate STP instances,
>THEN it would break that single bridging cloud into n disjoint trees. 
>Is that accurate? 
>
>btw, it could be that multiple ports of the same rbridge may, in fact, connect distinct bridging clouds. In such a scenario, it would not be a good idea for the rbrdige to merge the STP instances. 
>
>-Sanjay
> 
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
>Sent: Monday, November 06, 2006 2:52 PM
>To: Radia Perlman
>Cc: [e-mail]
>Subject: Re: [rbridge] Traffic storms
>
>Radia,
>       As you know, I support this approach. I have a doubt, however. 
>The ID used is the RBridge ID or a different ID per port?
> I assume it is by RBridge ID. Then, as far I understand, several ports of an RBridge could be connected to the same bridged link. In other words, an RBridge port may have to compete against other port of same RBridge for "root bridge" election. In this case, if the ID is the same (the RBridge ID), the link will split into two separate trees near the equal cost point if that is possible (at least a bridge exists between RBridge ports) to balance the cost of link connected to each of the root bridge ports, or by any of the standard tie breaking mechanisms like port ID if no there is no bridge interposed.
>Regards
>Guillermo
>Radia Perlman escribi?:
>  
>
>>I hesitate to bring this up because I don't want to reintroduce 
>>confusion about "participating" in bridge spanning tree algorithm. So, 
>>please---what I'm about to propose does NOT merge links. Bridged links 
>>still terminate at an RBridge.
>>
>>The issue is that it can be unpleasant for two RBridges to 
>>simultaneously think they are both Designated on the same link, which 
>>can happen if a bridge came up and connected two links. Or for that 
>>matter, a repeater.
>>
>>One way of making sure that a situation like that resolves very 
>>quickly, and absolutely, is to have RBridges act like bridges on each 
>>of their ports, with numerically lowest (i.e., highest) priority for become Root.
>>
>>Now---I DO NOT MEAN that an RBridge merges the spanning trees on each 
>>of its ports.
>>The spanning tree is terminated at an RBridge. If an RBridge has 4 
>>ports, it will participate in 4 independent bridge spanning tree 
>>instances.
>>
>>The advantage of doing this is that we could make the Root bridge be 
>>the Designated RBridge. Then if two RBridge links merged, the RBridges 
>>would notice immediately.
>>If you get usurped as bridge Root, you are also usurped as RBridge 
>>Designated RBridge.
>>
>>Since the bridge spanning tree messages are never delayed by 
>>pre-forwarding delays, this seems like it might be a nice thing to do.
>>
>>It would be nice if the same RBridge that would get elected Desiganted 
>>RBridge in the IS-IS link election would be elected bridge Root on 
>>that link. The easiest thing would be not to bother with IS-IS 
>>priority, and have them all have the same priority, with election 
>>being solely on ID. Then they can all use the lowest bridge root 
>>priority, and the same RBridge would get elected bridge root on the 
>>link as would get elected Designated RBridge on the link.
>>
>>Radia
>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://mailman.postel.org/mailman/listinfo/rbridge
>>  
>>    
>>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id kA72TMjL028333 for <[e-mail]>; Mon, 6 Nov 2006 18:29:23 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-3.tower-128.messagelabs.com!1162866560!2460497!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [144.189.100.102]
Received: (qmail 13203 invoked from network); 7 Nov 2006 02:29:20 -0000
Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-3.tower-128.messagelabs.com with SMTP; 7 Nov 2006 02:29:20 -0000
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id kA72TKkE000330 for <[e-mail]>; Mon, 6 Nov 2006 19:29:20 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id kA72TJKr029382 for <[e-mail]>; Mon, 6 Nov 2006 20:29:20 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 6 Nov 2006 21:29:16 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] WG last call commentsto:http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt
Thread-Index: AccB1Mz1htJEVFzAQPi/kiy0cw2VYAAN4g/gAAEIpnA=
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA72TMjL028333
Subject: Re: [rbridge] WG last call commentsto:http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2006 02:30:13 -0000
Status: RO
Content-Length: 27161

Silvano,

I believe that the spec will say 1 or 2 depending on whether the working
group decides you need to look at BPDUs for loop avoidance or the like.

I believe that Rbridges will not generate BPDUs or run STP; however,
there are cases, like wanting an interface of a designated rbridge to be
the root of the spanning tree of a bridged network connected to that
interface, where people have talked about there being a "co-located"
bridge with the Rbridge. Of course, such a bridge would generate BPDUs
although it would be better to think of it as co-located just outside an
Rbridge interface, rather than co-located with the core rbridge. This
bridge is logically outboard to the rbridge, so it could be a separate
physical box:

      +--------+   +---------+
------+ Bridge +---+ Rbridge +---
      +--------+   +----+----+
                        |

Of course, someone could implement this by combining the bridge
implementation with their rbridge implementation in various clever ways.
But there is really no reason to clutter up the rbridge specification
talking about this a lot. An Rbridge implementer could implement such a
virtual bridge, assuming the bridge follows the bridging standards and
the rbridge follows the rbridge specification, even if the rbridge
specification never even hinted at this possibility.

Donald

-----Original Message-----
From: Silvano Gai [mailto:[e-mail]] 
Sent: Monday, November 06, 2006 8:41 PM
To: Gray, Eric; Eastlake III Donald-LDE008; [e-mail]
Subject: RE: [rbridge] WG last call
commentsto:http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-
reqs-00.txt

Any wording that clarify which among these possible cases TRILL
implements:

1) drop BPDUs
2) receive BPDU, examine them to acquire information, but not pass them
to STP
3) in addition of 2) also generate some BPDU's behaving as STP
4) run STP

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Monday, November 06, 2006 10:49 AM
> To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> Subject: RE: [rbridge] WG last call
>
commentsto:http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-
> reqs-00.txt
> 
> Silvano,
> 
> 	Let's not be stubborn about wording.  You don't like the phrase
"drop 
> BPDUs."  I think it's fair to observe that "process BPDUs" is not 
> quite accurate either.
> 
> 	The intention is that implementations MAY examine BPDUs in an
effort 
> to maintain awareness of network conditions, but they are not to 
> "process" them in the usual sense of STP (or RSTP, or MSTP).
> 
> 	What wording would you like to see?
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [e-mail]
> --> [mailto:[e-mail]] On Behalf Of Silvano Gai
> --> Sent: Monday, November 06, 2006 1:16 AM
> --> To: Eastlake III Donald-LDE008; [e-mail]
> --> Subject: Re: [rbridge] WG last call 
> --> commentsto:http://www.ietf.org/internet-drafts/draft-ietf-tr
> --> ill-routing-reqs-00.txt
> -->
> --> Donald,
> -->
> --> I think I agree with most of your comments, with one big
exception.
> -->
> --> I am not able to see the difference between "dropping a BPDU" or 
> --> "ignoring a BPDU".
> -->
> --> IMO there are two possibilities:
> --> 1) we drop BPDUs
> --> 2) we process BPDUs
> -->
> --> If we do 2), we can:
> --> 2.1) process BPDU using STP/RSTP
> --> 2.2) do other processing on the BPDU, not STP/RSTP related
> -->
> --> If we don't want to do 2.1), let's just say it.
> --> If we need to do 2.2), it is better we spell it out clearly, and
not
> --> hide it behind the word "ignore BPDUs".
> -->
> --> This is such a crucial point to achieve:
> --> a) Interoperability
> --> b) A robust implementation
> -->
> --> that we don't want to be vaguely defined.
> -->
> --> -- Silvano
> -->
> --> > -----Original Message-----
> --> > From: [e-mail]
> --> [mailto:[e-mail]]
> --> On
> --> > Behalf Of Eastlake III Donald-LDE008
> --> > Sent: Sunday, November 05, 2006 3:22 PM
> --> > To: [e-mail]
> --> > Subject: Re: [rbridge] WG last call
> --> >
> --> commentsto:http://www.ietf.org/internet-drafts/draft-ietf-tr
> --> ill-routing-
> --> > reqs-00.txt
> --> >
> --> > Hi Silvano,
> --> >
> --> > I think I agree with most of your comments but see a few
> --> notes at @@@
> --> >
> --> > -----Original Message-----
> --> > From: [e-mail]
> --> [mailto:[e-mail]]
> --> On
> --> > Behalf Of Silvano Gai
> --> > Sent: Sunday, October 29, 2006 12:23 PM
> --> > To: [e-mail]
> --> > Subject: [rbridge] WG last call comments
> --> >
> --> to:http://www.ietf.org/internet-drafts/draft-ietf-trill-rout
> --> ing-reqs-00.
> --> > txt
> --> >
> --> > Comments inline marked "sgai n>"
> --> >
> --> > -- Silvano
> --> >
> --> > --------------------------------------------------------
> --> >
> --> > ... snip ...
> --> >
> --> > 1. Introduction
> --> >
> --> >    The current dominant approach to segregating network
> --> traffic relies
> --> >    on a hierarchical arrangement of bridges and routers.
> --> Hierarchy is
> --> >    further extended - both within routing protocols (such
> --> as IS-IS and
> --> >    OSPF) and between routing protocols (for example,
> --> between IGPs and
> --> >    BGP).  At least part of the current network structure
> --> is based on a
> --> >    determined trade-off between limitations of IP routing
> --> and similar
> --> >    disadvantages of 802 bridging.
> --> >
> --> >    Bridging Limitations
> --> >
> --> >    For example, bridged networks consist of single
> --> broadcast/flooding
> --> >    domains.  Ethernet/802 encapsulation (on which
> --> bridging is based)
> --> >    does not provide mechanisms for reducing the impact of
> --> looping data
> --> >    traffic that may result from a transient change in
> --> network topology
> --> >    and the existence of multiple paths.
> --> >
> --> >    The impact of looping traffic is far worse with flooded or
> --> broadcast
> --> >    traffic as this results in exponentially increasing
> --> traffic load.
> --> >    Consideration of the impacts of looping data lead to the use
of
> --> >    STP/RSTP to establish a connected - loop free - tree
> --> by disabling
> --> >    forwarding on a subset of links that might create a
> --> loop.  This has
> --> >    also the effect of eliminating redundant paths.
> --> >
> --> > @@@ Also generally lowers aggregate throughput and
> --> increases latency
> --> > through the net due to frames following suboptimal paths.
> --> >
> --> >    Because of the potential for severe impact from
> --> looping traffic,
> --> >    many (if not most) current bridge implementations stop
> --> forwarding
> --> of
> --> >    traffic frames following a topology change event and
> --> restart only
> --> >    after STP/RSTP is complete.
> --> >
> --> > Sgai 1> In STP there is no way of knowing when the convergence
has
> --> been
> --> > achieved; a bridge does not know or care about the timers of
other
> --> > bridges. The state machines on the ports are run
> --> independently. If you
> --> > refer to the Topology Change Notification Flag, its purpose is
to
> --> reduce
> --> > the filtering database ageing time, not to signal if STP/RSTP is

> --> > complete.
> --> >
> --> >    As a result, the process of eliminating potential
> --> loops in existing
> --> >    bridging deployments:
> --> >
> --> >      1) Results in inefficient use of inter-bridge connections
> --> >         and
> --> >      2) Causes delays in forwarding traffic as a result of
> --> >         changes in the network topology.
> --> >
> --> > Sgai 2> 2) is not true in the RSTP case; as a matter of
> --> fact RSTP is
> --> the
> --> > fastest converging protocol available today.
> --> >
> --> > @@@ I'm not sure why this and other documents put the
> --> emphasis they do
> --> > on STP/RSTP convergence. Of course it depends some on just how
> --> STP/RSTP
> --> > is implemented and how other algorithms are implemented.
> --> Perhaps it
> --> > stems from, as was pointed out early in the Rbridge
> --> effort, that the
> --> > replacement of bridges with Rbrides typically divides
> --> what would have
> --> > been one large spanning tree domain into a number of smaller
ones
> --> > interconnected by Rbridges. The STP/RSTP protocol within
> --> these small
> --> > spanning tree domains will typically converge for them
> --> all in parallel
> --> > more rapidly than the pre-existing larger single spanning tree
> --> STP/RSTP
> --> > convergence.
> --> >
> --> >    The combined effect of broadcast/flooding traffic, and
> --> the use of
> --> >    spanning trees for loop avoidance, sets practical
> --> limits on bridged
> --> >    network size in the network hierarchy and results in
> --> inefficient
> --> >    bandwidth use of inter-bridge connections. Inefficient
> --> inter-bridge
> --> >    connection usage similarly limits the usefulness of
> --> bridging with
> --> >    high-speed (and consequently high cost) interfaces.
> --> >
> --> >
> --> >
> --> >
> --> >
> --> >
> --> >
> --> > Gray                      Expires March, 2007
> -->     [Page 3]
> --> >
> --> > Internet-Draft        TRILL Routing Requirements
> --> September, 2006
> --> >
> --> >
> --> >    IP Routing Issues
> --> >
> --> >    For IP routed networks, any link (or subnet) must have
> --> at least one
> --> >    unique prefix. This means that a node that moves from
> --> one IP subnet
> --> >
> --> > sgai 3> in the case of IP instead of "node" is better to speak
of
> --> > "interface". It is the interface that has an address, not
> --> the node.
> --> >
> --> >    to another must change its IP address. Also, nodes
> --> with multiple IP
> --> >    subnet attachments must have multiple IP addresses.
> --> In IP routed
> --> >    networks, there are frequent trade-off considerations
> --> between using
> --> >    smaller subnets (longer prefix length) to minimize wasted IP
> --> address
> --> >    space (as a result of unused addresses in the fixed
> --> address range
> --> >    defined by the prefix and length) and using larger
> --> subnets (shorter
> --> >    prefix length) to minimize the need for (changes in)
> --> configuration.
> --> >
> --> >    In any case - with current IP routing technology -
> --> subnets must be
> --> >    configured for each routed interface.
> --> >
> --> >    Proposed Solution
> --> >
> --> >    Using a hybrid of routing and bridging - an RBridge -
> --> we hope to
> --> >    gain the benefits of both technologies, in particular,
> --> gaining the
> --> >    bandwidth advantages of shortest path routing while
> --> retaning the
> --> >    simplified configuration associated with bridging.
> --> >
> --> > 1.1. Terminology
> --> >
> --> >    The following terms are used in this document in the way that
> --> >    they are defined in "TRILL RBridge Architecture" [TARCH]:
> --> >
> --> >      ARP (Address Resolution Protocol)
> --> >      Bridge Learning
> --> >      Broadcast Domain
> --> >      Broadcast Traffic
> --> >      Cooperating RBridges
> --> >      Egress RBridge
> --> >      Ethernet
> --> >      Flooded Traffic
> --> >      Flooding
> --> >      Frame
> --> >      IGP (Interior Gateway Protocol)
> --> >      Ingress RBridge
> --> >      Ingress RBridge Tree
> --> >      IS-IS (Intermediate System to Intermediate System)
> --> >      ND (Neighbor Discovery)
> --> >      OSPF (Open Shortest Path First)
> --> >      Packet
> --> >
> --> > Sgai 4> in the case of layer 2 networks is more
> --> appropriate to use the
> --> > term frame, instead of packet.
> --> >
> --> > @@@ Frame appears earlier in this list and I believe that both
are
> --> > properly defined in the architecture document.
> --> >
> --> >      RBridge
> --> >      SPF (Shortest Path First)
> --> >      STP/RSTP (Spanning Tree Protocol/Rapid Spanning Tree
> --> Protocol)
> --> >      TRILL (TRansport Interconnect over Lots of Links)
> --> >      Unknown Destination
> --> >      VLAN (Virtual Local Area Network)
> --> >
> --> >
> --> > Gray                      Expires March, 2007
> -->     [Page 4]
> --> >
> --> > Internet-Draft        TRILL Routing Requirements
> --> September, 2006
> --> >
> --> >
> --> >
> --> > 1.2. Specific TRILL Goals
> --> >
> --> >    (Near) Zero Configuration
> --> >
> --> >    It is a TRILL requirement that it must be possible to deploy
> --> RBridges
> --> >    in at least a nominal set of potential deployment
> --> scenarios without
> --> a
> --> >    need to perform any configuration at each RBridge.  It
> --> is possible
> --> to
> --> >    meet this goal for a sub-set of all possible
> --> deployment scenarios
> --> by
> --> >    making realistic restrictions on deployment - such as
> --> restricting
> --> the
> --> >    deployment scenarios to exclude those involving a "trust
model"
> --> that
> --> >    imposes a need for configuration of some form of
> --> "shared secret" or
> --> >    other configuration required to restrict access to "trusted"
> --> devices.
> --> >
> --> >    It is also conceivable that a minimal configuration
> --> may be required
> --> >    for deployment of an initial (set of) device(s) - with
> --> subsequently
> --> >    deployed devices deriving that configuration
> --> information during the
> --> >    process of - for example - peer discovery.  This would
> --> constitute a
> --> >    mechanism for "near zero configuration".
> --> >
> --> >    Efficient Unicast Bandwidth Usage
> --> >
> --> >    For unicast, non-flooded traffic, RBridges are
> --> intended to merge
> --> the
> --> >    efficient bandwidth use of IP routing with the simplicity of
> --> Ethernet
> --> >    (or 802.1) bridging for networks possibly larger - and
> --> with greater
> --> >    forwarding capacity - than is the case with these networks
> --> presently.
> --> >
> --> >    The approach that we will use in accomplishing this is
> --> based on the
> --> >    idea of extending (one or more) link state routing
> --> protocol(s) to
> --> >    include distribution of Ethernet/802 reachability information
> --> between
> --> >    RBridge instances.
> --> >
> --> > Sgai 5> "RBridge instances" is not defined.
> --> >
> --> > @@@ For a document at this level, perhaps it could just say
> --> "RBridges".
> --> >
> --> >    In addition, there may be specific requirements
> --> >    imposed on the interactions between these extensions and the
> --> Spanning
> --> >    Tree Protocol (STP) and between RBridge instances and
> --> (potentially
> --> >    co-located) IP routing instances.
> --> >
> --> >    Potentially More Efficient Multicast and Broadcast Usage
> --> >
> --> >    There are clear advantages to incorporating mechanisms
> --> for improved
> --> >    efficiency in forwarding (layer 2) multicast frames
> --> and - possibly
> --> >    in reducing the amount of broadcast traffic as well.
> --> To the extent
> --> >    that these efficiency improvements may be considered
> --> "optimizations"
> --> >    and may be defined orthogonally to the process of
> --> specifying basic
> --> >    RBridge functionality, the potential to include these
> --> optimizations
> --> >    is (highly) desirable, but not mandatory.
> --> >
> --> >    Examples of this type of optimization include use of
> --> any intrinsic
> --> >    multicast routing capabilities and optimizations of ARP/ND.
> --> >
> --> >
> --> >
> --> >
> --> >
> --> > Gray                      Expires March, 2007
> -->     [Page 5]
> --> >
> --> > Internet-Draft        TRILL Routing Requirements
> --> September, 2006
> --> >
> --> >
> --> >
> --> >    Backward Compatibility
> --> >
> --> >    RBridges must be fully compatible with current
> --> bridges, IPv4 and
> --> >    IPv6 routers and endnodes.  They should be invisible
> --> to current IP
> --> >    routers (just as bridges are), and like routers, they
> --> terminate a
> --> >    bridged spanning tree.
> --> >
> --> > Sgai 6> the concept of terminating a bridged spanning tree is to
> --> vague,
> --> > see also sgai 10.
> --> >
> --> > @@@ I think that concept is generally understood to mean
> --> that they do
> --> > not pass BPDUs. Perhaps "by not passing BPDUs" could be appended
> --> above.
> --> >
> --> >    Unlike Routers, RBridges do not terminate
> --> >    a broadcast domain.
> --> >
> --> >
> --> > 2. General Requirements Potentially Affecting Routing
> --> >
> --> >    Candidate IGP Routing protocols - IS-IS or OSPF - must
> --> be evaluated
> --> >    for compatibility with the above goals.
> --> >
> --> >    For example, since IS-IS requires a unique System ID
> --> for each IS-IS
> --> >    instance (at least within a "scoped" deployment), a
> --> requirement for
> --> >    "(near) zero configuration" implies a need for mechanisms
that
> --> allow
> --> >    auto-configuration and/or negotiation of these
> --> (scoped) unique IDs.
> --> >
> --> >    Similar requirement must apply for OSPF as well, if selected.
> --> >
> --> >    In addition, forwarding of protocol messages must be
compatible
> --> with
> --> >    (or reasonably adaptable to) use of forwarding at
> --> layer 2, or there
> --> >    must be a means for deriving suitable higher layer
> --> addresses for
> --> the
> --> >    purpose of protocol exchanges - without imposing the need to
> --> manually
> --> >    configure higher-layer addresses.
> --> >
> --> >
> --> > 3. Link State Protocol Specific Requirements
> --> >
> --> >    Assuming that link state routing protocols meet above
> --> requirements,
> --> >    running a link state protocol among RBridges is
> --> straightforward.
> --> It
> --> >    is the same as running a level 1 routing protocol in
> --> an area.  This
> --> >    would be theoretically true for either IS-IS or OSPF,
> --> assuming that
> --> >    both of these meet the general requiremenst above.
> --> >
> --> >    From the perspective of simply extending existing routing
> --> protocols,
> --> >    IS-IS is a more appropriate choice than OSPF because
> --> it is easy in
> --> >    IS-IS to define new TLVs for use in carrying a new
information
> --> type.
> --> >
> --> >    This document, however, does not mandate a specific
link-state,
> --> IGP,
> --> >    routing protocol.  Instead, it sets forth the requirements
that
> --> will
> --> >    apply to any link-state routing protocol that may be used.
> --> >
> --> >    For implementations providing co-located
> --> Router/RBridge function,
> --> >    it is necessary to have mechanisms for distinguishing
> --> any protocol
> --> >    interactions in Routing instances from protocol
> --> interactions in the
> --> >    co-located RBridge instance.  Specific mechanisms we
> --> will use are
> --> >    very likely to be determined by the Link State Routing
Protocol
> --> that
> --> >
> --> >
> --> >
> --> > Gray                      Expires March, 2007
> -->     [Page 6]
> --> >
> --> > Internet-Draft        TRILL Routing Requirements
> --> September, 2006
> --> >
> --> >
> --> >
> --> >    we select.  Potential distinguishing mechanisms
> --> include use of a
> --> new
> --> >    well-known Ethernet/802 multicast address,
> --> higher-layer protocol ID
> --> >    or other - routing protocol specific - approaches.
> --> >
> --> >    The mechanism chosen should be consistent with the TRILL
goals.
> --> If,
> --> >    for example, a routing protocol specific approach
> --> required use of a
> --> >    unique "area" identifier, the RBridge area identifier
> --> should be a
> --> >    constant, well-known, value for all RBridges, and
> --> would not be one
> --> >    that would ever appear as a real routing area
> --> identifer - in order
> --> >    to allow for a potential for configuration-free operation.
> --> >
> --> >    Information that RBridge link state information will carry
> --> includes:
> --> >
> --> >    o  layer 2 addresses of nodes within the domain which have
> --> >       transmitted frames but have not transmitted ARP or
> --> ND replies
> --> >
> --> >    o  layer 3, layer 2 addresses of IP nodes within the
> --> domain.  For
> --> >       data compression, perhaps only the portion of the address
> --> >       following the domain-wide prefix need be carried.
> --> This will be
> --> >       more of an issue for IPv6 than for IPv4.
> --> >
> --> >    o  VLANs directly connected to this RBridge
> --> >
> --> >
> --> > Sgai 7> The discussion about VLAN needs to be much more
> --> extensive. It
> --> is
> --> > clear from the mailing list discussion that VLANs can be
> --> used inside
> --> the
> --> > packet or in the Ethernet encapsulation of TRILL. These are two 
> --> > different kinds of VLANs and their requirement need to be stated

> --> > separately. Q in Q needs also to be discussed. I propose to
define
> --> inner
> --> > and outer VLANs (with reference to the position of the tag in
the
> --> frame.
> --> >
> --> > @@@ Based on the discussions that have been going on, I feel a
bit
> --> > clearer about VLANs than I used to. It seems hard to make
> --> a simple,
> --> > brief, definiteive statement about Rbridges and VLANs,
> --> except that all
> --> > the VLAN stuff needs to be configured, because there are so many

> --> > different scenarios. I agree that a fairly extensive discussion
of
> --> VLANs
> --> > should appear somewhere but I don't think this is the
> --> right document
> --> for
> --> > that. The requirement on the Rbridge routing expressed
> --> here is that it
> --> > needs, one way or the other, to be able to handle station
> --> identification
> --> > not just as a MAC address but as a VLAN tag and MAC address.
> --> >
> --> >    Endnode information need only be delivered to RBridges
> --> supporting
> --> >    the VLAN in which the endnode resides.
> --> >
> --> > Sgai 8> endnode -> station
> --> >
> --> >    So, for instance, if endnode
> --> >    E is discovered through a VLAN A frame, then E's
> --> location need only
> --> >    be delivered to other RBridges that are attached to
> --> VLAN A links.
> --> >
> --> >    Given that RBridges must support delivery only to
> --> links within a
> --> VLAN
> --> >
> --> >    (for multicast or unknown frames marked with the
> --> VLAN's tag), this
> --> >    mechanism can be used to advertise endnode information
> --> solely to
> --> the
> --> >    RBridges "within" a VLAN (i.e. - having connectivity or
> --> configuration
> --> >    that assoicates them with a VLAN).
> --> >
> --> >    Although a separate instance of
> --> >    the link state protocol could be run for this purpose,
> --> the topology
> --> >    is so restricted (just a single broadcast domain),
> --> that it may be
> --> >    preferable to define special case mechanisms whereby each DR
> --> >
> --> > sgai 9> DR? Designated RBridge???
> --> >
> --> > @@@ Yes, I think it should be spelled out.
> --> >
> --> >    advertises attached endnodes, and receives explicit
> --> acknolegments
> --> >    from other RBridges.
> --> >
> --> >
> --> > 4. Potential Issues
> --> >
> --> > 4.1. Interactions with Spanning Tree Forwarding and
> --> Bridge Learning
> --> >
> --> >    Spanning tree forwarding applies within parts of the RBridge
> --> domain,
> --> >    where two or more RBridges are connected by a link
> --> that includes
> --> >    multiple 802.1 bridges.
> --> >
> --> >
> --> >
> --> >
> --> > Gray                      Expires March, 2007
> -->     [Page 7]
> --> >
> --> > Internet-Draft        TRILL Routing Requirements
> --> September, 2006
> --> >
> --> >
> --> >
> --> >    In order to simplify the interactions between RBridges
> --> and bridges
> --> -
> --> >    in particular, relative to spanning tree forwarding -
> --> RBridges do
> --> not
> --> >    actively participate in spanning tree protocol with
> --> 802.1 bridges.
> --> >
> --> > Sgai 10> "do not participate actively" can mean two
> --> different things:
> --> > 1) they drop the BPDU
> --> > 2) they propagate the BPDUs as regular multicast frames
> --> >
> --> > can you clarify?
> --> >
> --> > @@@ They block BPDUs but might do something based on
> --> their receipt.
> --> > Another way to look at it is that an Rbridge with N
> --> interfaces, each
> --> > connected to bridged links, looks like N different leaf
> --> nodes to the
> --> > STP/RSTP running on those bridged links. (Could be N different
> --> spanning
> --> > trees or less than that if some of these links are connected or
> --> bridged
> --> > to each other.)
> --> >
> --> >    Hence, from the Link State Routing protocol perspective, the
> --> protocol
> --> >    will be able to treat spanning tree links as
> --> indistinguishable from
> --> >    any other Ethernet/802.1 link, in the same way that routing
> --> protocols
> --> >    do today.
> --> >
> --> >    However, support for multi-pathing is potentially
> --> problematic and
> --> is
> --> >    assumed - in this document - to be a non-goal.  Multi-path
> --> forwarding
> --> >    has the potential to confound the bridge learning process.
> --> >
> --> > Sgai 11> multi-pathing a non-goal? This seems to be in
> --> contradiction
> --> > with what said before. Is it because of the designated RBridge?
> --> >
> --> > Sgai 12> the requirement for a designated RBridge is not really 
> --> > discussed here. In particular there is no discussion of
> --> the property
> --> of
> --> > the election algorithm, which must avoid broadcast storms.
> --> >
> --> > @@@ Seems like the ideal thing would be to state the
> --> requirements that
> --> > having a Designated Rbridge meets rather then the
> --> mechanism of having
> --> a
> --> > Designated Rbridge.
> --> >
> --> > @@@ Some general statement about convergence and an acceptably
low
> --> level
> --> > of overhead traffic for all of the mechanisms associated with
the
> --> > routing protocol might be reasonable.
> --> >
> --> >
> --> > 4.2. Computing Routes
> --> >
> --> >    RBridges must calculate an L2 "route table" consisting
> --> of Next Hop
> --> >    information for each known L2 unicast destination
> --> address within a
> --> >    (possibly VLAN scoped) broadcast domain. This is
> --> computed using a
> --> >    routing protocol's SPF algorithm and based on
> --> destination layer 2
> --> >    address reachability advertisements.
> --> >
> --> > Sgai 13> from the previous sentence it seems that we are
> --> computing the
> --> > topology among all the MAC addresses. What we really do
> --> is compute the
> --> > topology among RBridges and then tag it with reachable
> --> MAC addresses.
> --> > >From the SPF perspective, it is a much easier problem.
> --> >
> --> > ... snip ...
> --> >
> --> >
> --> > @@@ Thanks,
> --> > @@@ Donald
> --> >
> --> > _______________________________________________
> --> > rbridge mailing list
> --> > [e-mail]
> --> > http://mailman.postel.org/mailman/listinfo/rbridge
> -->
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->



Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA72Dd7R023327 for <[e-mail]>; Mon, 6 Nov 2006 18:13:39 -0800 (PST)
Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 06 Nov 2006 18:13:38 -0800
X-IronPort-AV: i="4.09,393,1157353200";  d="scan'208"; a="340147446:sNHT71674096"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA72DcD6015900; Mon, 6 Nov 2006 18:13:38 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA72DbbF016338; Mon, 6 Nov 2006 18:13:38 -0800 (PST)
Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 6 Nov 2006 18:13:37 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Mon, 6 Nov 2006 18:13:36 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Traffic storms
Thread-Index: AccB92nsVBbC2lyeTbCKsBoLoCmqagAGNyng
From: "Sanjay Sane \(sanjays\)" <[e-mail]>
To: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 07 Nov 2006 02:13:37.0705 (UTC) FILETIME=[55E47190:01C70212]
DKIM-Signature: a=rsa-sha1; q=dns; l=3819; t=1162865618; x=1163729618; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=22Sanjay=20Sane=20\(sanjays\)=22=20<[e-mail]> |Subject:RE=3A=20[rbridge]=20Traffic=20storms; X=v=3Dcisco.com=3B=20h=3Dx2bIPRCTuWw1R5FkJHpUXtTU95Q=3D; b=UAztTbCkoMyPvwk/jvMIVMQDj0KXG+S+e4QcFhNlNA1NyhOMnJ5HVnlSerPlwizA0uUPkQiu 9NoghQP0iTSe/BeJzQc5vUCX2Rpcv9qMJS98QBVHeA9JdmZbJu4tQVi/;
Authentication-Results: sj-dkim-7.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA72Dd7R023327
Cc: [e-mail]
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2006 02:14:11 -0000
Status: RO
Content-Length: 3641

Radia,

as per this proposal, 
if a rbridge is connected to the same bridging cloud by n ports, 
AND if the rbridge treats each of the ports as separate STP instances,
THEN it would break that single bridging cloud into n disjoint trees. 
Is that accurate? 

btw, it could be that multiple ports of the same rbridge may, in fact, connect distinct bridging clouds. In such a scenario, it would not be a good idea for the rbrdige to merge the STP instances. 

-Sanjay
 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
Sent: Monday, November 06, 2006 2:52 PM
To: Radia Perlman
Cc: [e-mail]
Subject: Re: [rbridge] Traffic storms

Radia,
       As you know, I support this approach. I have a doubt, however. 
The ID used is the RBridge ID or a different ID per port?
 I assume it is by RBridge ID. Then, as far I understand, several ports of an RBridge could be connected to the same bridged link. In other words, an RBridge port may have to compete against other port of same RBridge for "root bridge" election. In this case, if the ID is the same (the RBridge ID), the link will split into two separate trees near the equal cost point if that is possible (at least a bridge exists between RBridge ports) to balance the cost of link connected to each of the root bridge ports, or by any of the standard tie breaking mechanisms like port ID if no there is no bridge interposed.
Regards
Guillermo
Radia Perlman escribi?:
> I hesitate to bring this up because I don't want to reintroduce 
> confusion about "participating" in bridge spanning tree algorithm. So, 
> please---what I'm about to propose does NOT merge links. Bridged links 
> still terminate at an RBridge.
>
> The issue is that it can be unpleasant for two RBridges to 
> simultaneously think they are both Designated on the same link, which 
> can happen if a bridge came up and connected two links. Or for that 
> matter, a repeater.
>
> One way of making sure that a situation like that resolves very 
> quickly, and absolutely, is to have RBridges act like bridges on each 
> of their ports, with numerically lowest (i.e., highest) priority for become Root.
>
> Now---I DO NOT MEAN that an RBridge merges the spanning trees on each 
> of its ports.
> The spanning tree is terminated at an RBridge. If an RBridge has 4 
> ports, it will participate in 4 independent bridge spanning tree 
> instances.
>
> The advantage of doing this is that we could make the Root bridge be 
> the Designated RBridge. Then if two RBridge links merged, the RBridges 
> would notice immediately.
> If you get usurped as bridge Root, you are also usurped as RBridge 
> Designated RBridge.
>
> Since the bridge spanning tree messages are never delayed by 
> pre-forwarding delays, this seems like it might be a nice thing to do.
>
> It would be nice if the same RBridge that would get elected Desiganted 
> RBridge in the IS-IS link election would be elected bridge Root on 
> that link. The easiest thing would be not to bother with IS-IS 
> priority, and have them all have the same priority, with election 
> being solely on ID. Then they can all use the lowest bridge root 
> priority, and the same RBridge would get elected bridge root on the 
> link as would get elected Designated RBridge on the link.
>
> Radia
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   
_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA71eviD012474 for <[e-mail]>; Mon, 6 Nov 2006 17:40:57 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 6 Nov 2006 17:40:50 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] WG last call commentsto:http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt
Thread-Index: AccB1Mz1htJEVFzAQPi/kiy0cw2VYAAN4g/g
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA71eviD012474
Subject: Re: [rbridge] WG last call commentsto:http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2006 01:41:29 -0000
Status: RO
Content-Length: 25510

Any wording that clarify which among these possible cases TRILL
implements:

1) drop BPDUs
2) receive BPDU, examine them to acquire information, but not pass them
to STP
3) in addition of 2) also generate some BPDU's behaving as STP
4) run STP

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Monday, November 06, 2006 10:49 AM
> To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> Subject: RE: [rbridge] WG last call
>
commentsto:http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-
> reqs-00.txt
> 
> Silvano,
> 
> 	Let's not be stubborn about wording.  You don't like the phrase
> "drop BPDUs."  I think it's fair to observe that "process BPDUs" is
> not quite accurate either.
> 
> 	The intention is that implementations MAY examine BPDUs in an
> effort to maintain awareness of network conditions, but they are not
> to "process" them in the usual sense of STP (or RSTP, or MSTP).
> 
> 	What wording would you like to see?
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [e-mail]
> --> [mailto:[e-mail]] On Behalf Of Silvano Gai
> --> Sent: Monday, November 06, 2006 1:16 AM
> --> To: Eastlake III Donald-LDE008; [e-mail]
> --> Subject: Re: [rbridge] WG last call
> --> commentsto:http://www.ietf.org/internet-drafts/draft-ietf-tr
> --> ill-routing-reqs-00.txt
> -->
> --> Donald,
> -->
> --> I think I agree with most of your comments, with one big
exception.
> -->
> --> I am not able to see the difference between "dropping a BPDU" or
> --> "ignoring a BPDU".
> -->
> --> IMO there are two possibilities:
> --> 1) we drop BPDUs
> --> 2) we process BPDUs
> -->
> --> If we do 2), we can:
> --> 2.1) process BPDU using STP/RSTP
> --> 2.2) do other processing on the BPDU, not STP/RSTP related
> -->
> --> If we don't want to do 2.1), let's just say it.
> --> If we need to do 2.2), it is better we spell it out clearly, and
not
> --> hide it behind the word "ignore BPDUs".
> -->
> --> This is such a crucial point to achieve:
> --> a) Interoperability
> --> b) A robust implementation
> -->
> --> that we don't want to be vaguely defined.
> -->
> --> -- Silvano
> -->
> --> > -----Original Message-----
> --> > From: [e-mail]
> --> [mailto:[e-mail]]
> --> On
> --> > Behalf Of Eastlake III Donald-LDE008
> --> > Sent: Sunday, November 05, 2006 3:22 PM
> --> > To: [e-mail]
> --> > Subject: Re: [rbridge] WG last call
> --> >
> --> commentsto:http://www.ietf.org/internet-drafts/draft-ietf-tr
> --> ill-routing-
> --> > reqs-00.txt
> --> >
> --> > Hi Silvano,
> --> >
> --> > I think I agree with most of your comments but see a few
> --> notes at @@@
> --> >
> --> > -----Original Message-----
> --> > From: [e-mail]
> --> [mailto:[e-mail]]
> --> On
> --> > Behalf Of Silvano Gai
> --> > Sent: Sunday, October 29, 2006 12:23 PM
> --> > To: [e-mail]
> --> > Subject: [rbridge] WG last call comments
> --> >
> --> to:http://www.ietf.org/internet-drafts/draft-ietf-trill-rout
> --> ing-reqs-00.
> --> > txt
> --> >
> --> > Comments inline marked "sgai n>"
> --> >
> --> > -- Silvano
> --> >
> --> > --------------------------------------------------------
> --> >
> --> > ... snip ...
> --> >
> --> > 1. Introduction
> --> >
> --> >    The current dominant approach to segregating network
> --> traffic relies
> --> >    on a hierarchical arrangement of bridges and routers.
> --> Hierarchy is
> --> >    further extended - both within routing protocols (such
> --> as IS-IS and
> --> >    OSPF) and between routing protocols (for example,
> --> between IGPs and
> --> >    BGP).  At least part of the current network structure
> --> is based on a
> --> >    determined trade-off between limitations of IP routing
> --> and similar
> --> >    disadvantages of 802 bridging.
> --> >
> --> >    Bridging Limitations
> --> >
> --> >    For example, bridged networks consist of single
> --> broadcast/flooding
> --> >    domains.  Ethernet/802 encapsulation (on which
> --> bridging is based)
> --> >    does not provide mechanisms for reducing the impact of
> --> looping data
> --> >    traffic that may result from a transient change in
> --> network topology
> --> >    and the existence of multiple paths.
> --> >
> --> >    The impact of looping traffic is far worse with flooded or
> --> broadcast
> --> >    traffic as this results in exponentially increasing
> --> traffic load.
> --> >    Consideration of the impacts of looping data lead to the use
of
> --> >    STP/RSTP to establish a connected - loop free - tree
> --> by disabling
> --> >    forwarding on a subset of links that might create a
> --> loop.  This has
> --> >    also the effect of eliminating redundant paths.
> --> >
> --> > @@@ Also generally lowers aggregate throughput and
> --> increases latency
> --> > through the net due to frames following suboptimal paths.
> --> >
> --> >    Because of the potential for severe impact from
> --> looping traffic,
> --> >    many (if not most) current bridge implementations stop
> --> forwarding
> --> of
> --> >    traffic frames following a topology change event and
> --> restart only
> --> >    after STP/RSTP is complete.
> --> >
> --> > Sgai 1> In STP there is no way of knowing when the convergence
has
> --> been
> --> > achieved; a bridge does not know or care about the timers of
other
> --> > bridges. The state machines on the ports are run
> --> independently. If you
> --> > refer to the Topology Change Notification Flag, its purpose is
to
> --> reduce
> --> > the filtering database ageing time, not to signal if STP/RSTP is
> --> > complete.
> --> >
> --> >    As a result, the process of eliminating potential
> --> loops in existing
> --> >    bridging deployments:
> --> >
> --> >      1) Results in inefficient use of inter-bridge connections
> --> >         and
> --> >      2) Causes delays in forwarding traffic as a result of
> --> >         changes in the network topology.
> --> >
> --> > Sgai 2> 2) is not true in the RSTP case; as a matter of
> --> fact RSTP is
> --> the
> --> > fastest converging protocol available today.
> --> >
> --> > @@@ I'm not sure why this and other documents put the
> --> emphasis they do
> --> > on STP/RSTP convergence. Of course it depends some on just how
> --> STP/RSTP
> --> > is implemented and how other algorithms are implemented.
> --> Perhaps it
> --> > stems from, as was pointed out early in the Rbridge
> --> effort, that the
> --> > replacement of bridges with Rbrides typically divides
> --> what would have
> --> > been one large spanning tree domain into a number of smaller
ones
> --> > interconnected by Rbridges. The STP/RSTP protocol within
> --> these small
> --> > spanning tree domains will typically converge for them
> --> all in parallel
> --> > more rapidly than the pre-existing larger single spanning tree
> --> STP/RSTP
> --> > convergence.
> --> >
> --> >    The combined effect of broadcast/flooding traffic, and
> --> the use of
> --> >    spanning trees for loop avoidance, sets practical
> --> limits on bridged
> --> >    network size in the network hierarchy and results in
> --> inefficient
> --> >    bandwidth use of inter-bridge connections. Inefficient
> --> inter-bridge
> --> >    connection usage similarly limits the usefulness of
> --> bridging with
> --> >    high-speed (and consequently high cost) interfaces.
> --> >
> --> >
> --> >
> --> >
> --> >
> --> >
> --> >
> --> > Gray                      Expires March, 2007
> -->     [Page 3]
> --> >
> --> > Internet-Draft        TRILL Routing Requirements
> --> September, 2006
> --> >
> --> >
> --> >    IP Routing Issues
> --> >
> --> >    For IP routed networks, any link (or subnet) must have
> --> at least one
> --> >    unique prefix. This means that a node that moves from
> --> one IP subnet
> --> >
> --> > sgai 3> in the case of IP instead of "node" is better to speak
of
> --> > "interface". It is the interface that has an address, not
> --> the node.
> --> >
> --> >    to another must change its IP address. Also, nodes
> --> with multiple IP
> --> >    subnet attachments must have multiple IP addresses.
> --> In IP routed
> --> >    networks, there are frequent trade-off considerations
> --> between using
> --> >    smaller subnets (longer prefix length) to minimize wasted IP
> --> address
> --> >    space (as a result of unused addresses in the fixed
> --> address range
> --> >    defined by the prefix and length) and using larger
> --> subnets (shorter
> --> >    prefix length) to minimize the need for (changes in)
> --> configuration.
> --> >
> --> >    In any case - with current IP routing technology -
> --> subnets must be
> --> >    configured for each routed interface.
> --> >
> --> >    Proposed Solution
> --> >
> --> >    Using a hybrid of routing and bridging - an RBridge -
> --> we hope to
> --> >    gain the benefits of both technologies, in particular,
> --> gaining the
> --> >    bandwidth advantages of shortest path routing while
> --> retaning the
> --> >    simplified configuration associated with bridging.
> --> >
> --> > 1.1. Terminology
> --> >
> --> >    The following terms are used in this document in the way that
> --> >    they are defined in "TRILL RBridge Architecture" [TARCH]:
> --> >
> --> >      ARP (Address Resolution Protocol)
> --> >      Bridge Learning
> --> >      Broadcast Domain
> --> >      Broadcast Traffic
> --> >      Cooperating RBridges
> --> >      Egress RBridge
> --> >      Ethernet
> --> >      Flooded Traffic
> --> >      Flooding
> --> >      Frame
> --> >      IGP (Interior Gateway Protocol)
> --> >      Ingress RBridge
> --> >      Ingress RBridge Tree
> --> >      IS-IS (Intermediate System to Intermediate System)
> --> >      ND (Neighbor Discovery)
> --> >      OSPF (Open Shortest Path First)
> --> >      Packet
> --> >
> --> > Sgai 4> in the case of layer 2 networks is more
> --> appropriate to use the
> --> > term frame, instead of packet.
> --> >
> --> > @@@ Frame appears earlier in this list and I believe that both
are
> --> > properly defined in the architecture document.
> --> >
> --> >      RBridge
> --> >      SPF (Shortest Path First)
> --> >      STP/RSTP (Spanning Tree Protocol/Rapid Spanning Tree
> --> Protocol)
> --> >      TRILL (TRansport Interconnect over Lots of Links)
> --> >      Unknown Destination
> --> >      VLAN (Virtual Local Area Network)
> --> >
> --> >
> --> > Gray                      Expires March, 2007
> -->     [Page 4]
> --> >
> --> > Internet-Draft        TRILL Routing Requirements
> --> September, 2006
> --> >
> --> >
> --> >
> --> > 1.2. Specific TRILL Goals
> --> >
> --> >    (Near) Zero Configuration
> --> >
> --> >    It is a TRILL requirement that it must be possible to deploy
> --> RBridges
> --> >    in at least a nominal set of potential deployment
> --> scenarios without
> --> a
> --> >    need to perform any configuration at each RBridge.  It
> --> is possible
> --> to
> --> >    meet this goal for a sub-set of all possible
> --> deployment scenarios
> --> by
> --> >    making realistic restrictions on deployment - such as
> --> restricting
> --> the
> --> >    deployment scenarios to exclude those involving a "trust
model"
> --> that
> --> >    imposes a need for configuration of some form of
> --> "shared secret" or
> --> >    other configuration required to restrict access to "trusted"
> --> devices.
> --> >
> --> >    It is also conceivable that a minimal configuration
> --> may be required
> --> >    for deployment of an initial (set of) device(s) - with
> --> subsequently
> --> >    deployed devices deriving that configuration
> --> information during the
> --> >    process of - for example - peer discovery.  This would
> --> constitute a
> --> >    mechanism for "near zero configuration".
> --> >
> --> >    Efficient Unicast Bandwidth Usage
> --> >
> --> >    For unicast, non-flooded traffic, RBridges are
> --> intended to merge
> --> the
> --> >    efficient bandwidth use of IP routing with the simplicity of
> --> Ethernet
> --> >    (or 802.1) bridging for networks possibly larger - and
> --> with greater
> --> >    forwarding capacity - than is the case with these networks
> --> presently.
> --> >
> --> >    The approach that we will use in accomplishing this is
> --> based on the
> --> >    idea of extending (one or more) link state routing
> --> protocol(s) to
> --> >    include distribution of Ethernet/802 reachability information
> --> between
> --> >    RBridge instances.
> --> >
> --> > Sgai 5> "RBridge instances" is not defined.
> --> >
> --> > @@@ For a document at this level, perhaps it could just say
> --> "RBridges".
> --> >
> --> >    In addition, there may be specific requirements
> --> >    imposed on the interactions between these extensions and the
> --> Spanning
> --> >    Tree Protocol (STP) and between RBridge instances and
> --> (potentially
> --> >    co-located) IP routing instances.
> --> >
> --> >    Potentially More Efficient Multicast and Broadcast Usage
> --> >
> --> >    There are clear advantages to incorporating mechanisms
> --> for improved
> --> >    efficiency in forwarding (layer 2) multicast frames
> --> and - possibly
> --> >    in reducing the amount of broadcast traffic as well.
> --> To the extent
> --> >    that these efficiency improvements may be considered
> --> "optimizations"
> --> >    and may be defined orthogonally to the process of
> --> specifying basic
> --> >    RBridge functionality, the potential to include these
> --> optimizations
> --> >    is (highly) desirable, but not mandatory.
> --> >
> --> >    Examples of this type of optimization include use of
> --> any intrinsic
> --> >    multicast routing capabilities and optimizations of ARP/ND.
> --> >
> --> >
> --> >
> --> >
> --> >
> --> > Gray                      Expires March, 2007
> -->     [Page 5]
> --> >
> --> > Internet-Draft        TRILL Routing Requirements
> --> September, 2006
> --> >
> --> >
> --> >
> --> >    Backward Compatibility
> --> >
> --> >    RBridges must be fully compatible with current
> --> bridges, IPv4 and
> --> >    IPv6 routers and endnodes.  They should be invisible
> --> to current IP
> --> >    routers (just as bridges are), and like routers, they
> --> terminate a
> --> >    bridged spanning tree.
> --> >
> --> > Sgai 6> the concept of terminating a bridged spanning tree is to
> --> vague,
> --> > see also sgai 10.
> --> >
> --> > @@@ I think that concept is generally understood to mean
> --> that they do
> --> > not pass BPDUs. Perhaps "by not passing BPDUs" could be appended
> --> above.
> --> >
> --> >    Unlike Routers, RBridges do not terminate
> --> >    a broadcast domain.
> --> >
> --> >
> --> > 2. General Requirements Potentially Affecting Routing
> --> >
> --> >    Candidate IGP Routing protocols - IS-IS or OSPF - must
> --> be evaluated
> --> >    for compatibility with the above goals.
> --> >
> --> >    For example, since IS-IS requires a unique System ID
> --> for each IS-IS
> --> >    instance (at least within a "scoped" deployment), a
> --> requirement for
> --> >    "(near) zero configuration" implies a need for mechanisms
that
> --> allow
> --> >    auto-configuration and/or negotiation of these
> --> (scoped) unique IDs.
> --> >
> --> >    Similar requirement must apply for OSPF as well, if selected.
> --> >
> --> >    In addition, forwarding of protocol messages must be
compatible
> --> with
> --> >    (or reasonably adaptable to) use of forwarding at
> --> layer 2, or there
> --> >    must be a means for deriving suitable higher layer
> --> addresses for
> --> the
> --> >    purpose of protocol exchanges - without imposing the need to
> --> manually
> --> >    configure higher-layer addresses.
> --> >
> --> >
> --> > 3. Link State Protocol Specific Requirements
> --> >
> --> >    Assuming that link state routing protocols meet above
> --> requirements,
> --> >    running a link state protocol among RBridges is
> --> straightforward.
> --> It
> --> >    is the same as running a level 1 routing protocol in
> --> an area.  This
> --> >    would be theoretically true for either IS-IS or OSPF,
> --> assuming that
> --> >    both of these meet the general requiremenst above.
> --> >
> --> >    From the perspective of simply extending existing routing
> --> protocols,
> --> >    IS-IS is a more appropriate choice than OSPF because
> --> it is easy in
> --> >    IS-IS to define new TLVs for use in carrying a new
information
> --> type.
> --> >
> --> >    This document, however, does not mandate a specific
link-state,
> --> IGP,
> --> >    routing protocol.  Instead, it sets forth the requirements
that
> --> will
> --> >    apply to any link-state routing protocol that may be used.
> --> >
> --> >    For implementations providing co-located
> --> Router/RBridge function,
> --> >    it is necessary to have mechanisms for distinguishing
> --> any protocol
> --> >    interactions in Routing instances from protocol
> --> interactions in the
> --> >    co-located RBridge instance.  Specific mechanisms we
> --> will use are
> --> >    very likely to be determined by the Link State Routing
Protocol
> --> that
> --> >
> --> >
> --> >
> --> > Gray                      Expires March, 2007
> -->     [Page 6]
> --> >
> --> > Internet-Draft        TRILL Routing Requirements
> --> September, 2006
> --> >
> --> >
> --> >
> --> >    we select.  Potential distinguishing mechanisms
> --> include use of a
> --> new
> --> >    well-known Ethernet/802 multicast address,
> --> higher-layer protocol ID
> --> >    or other - routing protocol specific - approaches.
> --> >
> --> >    The mechanism chosen should be consistent with the TRILL
goals.
> --> If,
> --> >    for example, a routing protocol specific approach
> --> required use of a
> --> >    unique "area" identifier, the RBridge area identifier
> --> should be a
> --> >    constant, well-known, value for all RBridges, and
> --> would not be one
> --> >    that would ever appear as a real routing area
> --> identifer - in order
> --> >    to allow for a potential for configuration-free operation.
> --> >
> --> >    Information that RBridge link state information will carry
> --> includes:
> --> >
> --> >    o  layer 2 addresses of nodes within the domain which have
> --> >       transmitted frames but have not transmitted ARP or
> --> ND replies
> --> >
> --> >    o  layer 3, layer 2 addresses of IP nodes within the
> --> domain.  For
> --> >       data compression, perhaps only the portion of the address
> --> >       following the domain-wide prefix need be carried.
> --> This will be
> --> >       more of an issue for IPv6 than for IPv4.
> --> >
> --> >    o  VLANs directly connected to this RBridge
> --> >
> --> >
> --> > Sgai 7> The discussion about VLAN needs to be much more
> --> extensive. It
> --> is
> --> > clear from the mailing list discussion that VLANs can be
> --> used inside
> --> the
> --> > packet or in the Ethernet encapsulation of TRILL. These are two
> --> > different kinds of VLANs and their requirement need to be stated
> --> > separately. Q in Q needs also to be discussed. I propose to
define
> --> inner
> --> > and outer VLANs (with reference to the position of the tag in
the
> --> frame.
> --> >
> --> > @@@ Based on the discussions that have been going on, I feel a
bit
> --> > clearer about VLANs than I used to. It seems hard to make
> --> a simple,
> --> > brief, definiteive statement about Rbridges and VLANs,
> --> except that all
> --> > the VLAN stuff needs to be configured, because there are so many
> --> > different scenarios. I agree that a fairly extensive discussion
of
> --> VLANs
> --> > should appear somewhere but I don't think this is the
> --> right document
> --> for
> --> > that. The requirement on the Rbridge routing expressed
> --> here is that it
> --> > needs, one way or the other, to be able to handle station
> --> identification
> --> > not just as a MAC address but as a VLAN tag and MAC address.
> --> >
> --> >    Endnode information need only be delivered to RBridges
> --> supporting
> --> >    the VLAN in which the endnode resides.
> --> >
> --> > Sgai 8> endnode -> station
> --> >
> --> >    So, for instance, if endnode
> --> >    E is discovered through a VLAN A frame, then E's
> --> location need only
> --> >    be delivered to other RBridges that are attached to
> --> VLAN A links.
> --> >
> --> >    Given that RBridges must support delivery only to
> --> links within a
> --> VLAN
> --> >
> --> >    (for multicast or unknown frames marked with the
> --> VLAN's tag), this
> --> >    mechanism can be used to advertise endnode information
> --> solely to
> --> the
> --> >    RBridges "within" a VLAN (i.e. - having connectivity or
> --> configuration
> --> >    that assoicates them with a VLAN).
> --> >
> --> >    Although a separate instance of
> --> >    the link state protocol could be run for this purpose,
> --> the topology
> --> >    is so restricted (just a single broadcast domain),
> --> that it may be
> --> >    preferable to define special case mechanisms whereby each DR
> --> >
> --> > sgai 9> DR? Designated RBridge???
> --> >
> --> > @@@ Yes, I think it should be spelled out.
> --> >
> --> >    advertises attached endnodes, and receives explicit
> --> acknolegments
> --> >    from other RBridges.
> --> >
> --> >
> --> > 4. Potential Issues
> --> >
> --> > 4.1. Interactions with Spanning Tree Forwarding and
> --> Bridge Learning
> --> >
> --> >    Spanning tree forwarding applies within parts of the RBridge
> --> domain,
> --> >    where two or more RBridges are connected by a link
> --> that includes
> --> >    multiple 802.1 bridges.
> --> >
> --> >
> --> >
> --> >
> --> > Gray                      Expires March, 2007
> -->     [Page 7]
> --> >
> --> > Internet-Draft        TRILL Routing Requirements
> --> September, 2006
> --> >
> --> >
> --> >
> --> >    In order to simplify the interactions between RBridges
> --> and bridges
> --> -
> --> >    in particular, relative to spanning tree forwarding -
> --> RBridges do
> --> not
> --> >    actively participate in spanning tree protocol with
> --> 802.1 bridges.
> --> >
> --> > Sgai 10> "do not participate actively" can mean two
> --> different things:
> --> > 1) they drop the BPDU
> --> > 2) they propagate the BPDUs as regular multicast frames
> --> >
> --> > can you clarify?
> --> >
> --> > @@@ They block BPDUs but might do something based on
> --> their receipt.
> --> > Another way to look at it is that an Rbridge with N
> --> interfaces, each
> --> > connected to bridged links, looks like N different leaf
> --> nodes to the
> --> > STP/RSTP running on those bridged links. (Could be N different
> --> spanning
> --> > trees or less than that if some of these links are connected or
> --> bridged
> --> > to each other.)
> --> >
> --> >    Hence, from the Link State Routing protocol perspective, the
> --> protocol
> --> >    will be able to treat spanning tree links as
> --> indistinguishable from
> --> >    any other Ethernet/802.1 link, in the same way that routing
> --> protocols
> --> >    do today.
> --> >
> --> >    However, support for multi-pathing is potentially
> --> problematic and
> --> is
> --> >    assumed - in this document - to be a non-goal.  Multi-path
> --> forwarding
> --> >    has the potential to confound the bridge learning process.
> --> >
> --> > Sgai 11> multi-pathing a non-goal? This seems to be in
> --> contradiction
> --> > with what said before. Is it because of the designated RBridge?
> --> >
> --> > Sgai 12> the requirement for a designated RBridge is not really
> --> > discussed here. In particular there is no discussion of
> --> the property
> --> of
> --> > the election algorithm, which must avoid broadcast storms.
> --> >
> --> > @@@ Seems like the ideal thing would be to state the
> --> requirements that
> --> > having a Designated Rbridge meets rather then the
> --> mechanism of having
> --> a
> --> > Designated Rbridge.
> --> >
> --> > @@@ Some general statement about convergence and an acceptably
low
> --> level
> --> > of overhead traffic for all of the mechanisms associated with
the
> --> > routing protocol might be reasonable.
> --> >
> --> >
> --> > 4.2. Computing Routes
> --> >
> --> >    RBridges must calculate an L2 "route table" consisting
> --> of Next Hop
> --> >    information for each known L2 unicast destination
> --> address within a
> --> >    (possibly VLAN scoped) broadcast domain. This is
> --> computed using a
> --> >    routing protocol's SPF algorithm and based on
> --> destination layer 2
> --> >    address reachability advertisements.
> --> >
> --> > Sgai 13> from the previous sentence it seems that we are
> --> computing the
> --> > topology among all the MAC addresses. What we really do
> --> is compute the
> --> > topology among RBridges and then tag it with reachable
> --> MAC addresses.
> --> > >From the SPF perspective, it is a much easier problem.
> --> >
> --> > ... snip ...
> --> >
> --> >
> --> > @@@ Thanks,
> --> > @@@ Donald
> --> >
> --> > _______________________________________________
> --> > rbridge mailing list
> --> > [e-mail]
> --> > http://mailman.postel.org/mailman/listinfo/rbridge
> -->
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA71eolY012453 for <[e-mail]>; Mon, 6 Nov 2006 17:40:51 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 6 Nov 2006 17:40:50 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: AccB0sMsux/f4nZgRqq9IwzRfxA2SQAOUC3g
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA71eolY012453
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2006 01:41:07 -0000
Status: RO
Content-Length: 8064

I am not looking at TRILL for increased scalability, but for spanning
tree replacement to get high bisectional bandwidth.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Monday, November 06, 2006 10:38 AM
> To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> Subject: RE: [rbridge] Should we optimize the common case?
> 
> Silvano,
> 
> 	The assertion that only fortune 500 companies are interested in
> TRILL is baseless and untrue.  One reason why you may believe this is
> the case, is that you are making certain assumptions about complexity
> and scale of the desired solution that are equally unfounded or false.
> 
> 	There is nothing that particularly prohibits definition of some
> form of RBridge functionality that might be simple enough to deploy in
> relatively small networks - where higher speed link are becoming more
> common and wasting high speed links is also a problem.
> 
> 	The types of networks you're talking about cannot realistically
> operate with plug & play devices, and greater scalability is
paramount.
> The work we're doing in this WG is aimed at simplistic, plug & play
> deployment where increased scalability is a secondary consideration.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [e-mail]
> --> [mailto:[e-mail]] On Behalf Of Silvano Gai
> --> Sent: Monday, November 06, 2006 1:51 AM
> --> To: Eastlake III Donald-LDE008; [e-mail]
> --> Subject: Re: [rbridge] Should we optimize the common case?
> -->
> -->
> --> Donald,
> -->
> --> The high end and the low end are extremely different.
> -->
> --> The customers interested in TRILL are the Fortune 500
> --> companies. Large
> --> Enterprise networks and large data centers used to run Financial,
> --> Insurance, Health, Chemical, Oil, Information and manufacturing
> --> companies.
> -->
> --> They have huge demand for high bandwidth and low latency.
> -->
> --> Each of these companies spends millions each year in
> --> network operation
> --> (OPEX) and millions in new equipment (CAPEX). In all of them OPEX
is
> --> much larger than CAPEX. They only buy major vendor
> --> equipments and they
> --> install them according to the recommended vendor design guideline.
> --> Typically they have an internal certification lab in which
> --> they test the
> --> network configuration and the software releases before
> --> putting them in
> --> production networks.
> -->
> --> They have a very well defined concept of backbone ports and access
> --> ports. All the backbone ports are in fiber at the highest
> --> possible speed
> --> (today 10 GE). For the access port they use a mix of fiber
> --> and copper.
> --> The backbone has a regular structure that matches the vendor
design
> --> guideline and the result of the certification experiment
> --> they have done
> --> independently.
> -->
> --> A network outage can cost millions/hour.
> -->
> --> There is no way you will see in one of these backbones a hub or
any
> --> other uncontrolled device. NEVER.
> -->
> --> That is the reason why I think this is the most important case for
> --> TRILL.
> -->
> --> More inline.
> -->
> --> > -----Original Message-----
> --> > From: [e-mail]
> --> [mailto:[e-mail]]
> --> On
> --> > Behalf Of Eastlake III Donald-LDE008
> --> > Sent: Sunday, November 05, 2006 10:20 PM
> --> > To: [e-mail]
> --> > Subject: Re: [rbridge] Should we optimize the common case?
> --> >
> --> > Silvano,
> --> >
> --> > Why do you think that 90% of Rbridge deployment will be for this
> --> unusual
> --> > case? I mean, I have no problem with the belief that
> --> Rbridges would be
> --> > better than bridges in this case but why shouldn't that be true
of
> --> less
> --> > high end uses?
> --> >
> --> > A while ago on this list I posted a rhetorical question as to
why
> --> > Rbriges shouldn't eventually replace all bridges. No one posted
an
> --> > answer.
> -->
> --> This technology will start in the high end and move down to
> --> the lower
> --> end. How low will it goes is a good question.
> -->
> --> The low end is extremely cost sensitive. When we buys a switch or
a
> --> router on the Internet for 50-100$, the COGS cannot be more
> --> that 15-30$,
> --> even with low margins. This implies that few dollar more to
> --> increase the
> --> memory size or the processor speed are a big deal. Add software
> --> development cost. Couple this with the fact that today we
> --> have low cost
> --> 1GE switches used by low-end users that have problems
> --> pushing or pulling
> --> more than few Mb/s. There is no bandwidth demand in the low end.
> --> Spanning tree is just fine. Cost is the big issue. Moreover
> --> there is the
> --> huge issue of training home/small office installers in this new
> --> technology.
> -->
> --> My 0.2 cents
> -->
> --> -- Silvano
> -->
> --> >
> --> > Why not specify Rbridges more or less as we have been for
> --> the common
> --> > bridge case and, in the backbone case you are talking
> --> about, just drop
> --> > the MAC addresses on the point-to-point links within the
backbone?
> --> > Doesn't that produce less overhead than your proposal
> --> below in both
> --> the
> --> > point-to-point and shared media cases?
> --> >
> --> > Donald
> --> >
> --> > -----Original Message-----
> --> > From: [e-mail]
> --> [mailto:[e-mail]]
> --> On
> --> > Behalf Of Silvano Gai
> --> > Sent: Wednesday, November 01, 2006 9:07 PM
> --> > To: [e-mail]
> --> > Subject: [rbridge] Should we optimize the common case?
> --> >
> --> >
> --> > With 16 bit addresses the current TRILL overhead over
> --> Ethernet is 20
> --> > bytes. If we want to expand the RBridge addresses, it we
> --> will go to
> --> > 22-24 bytes.
> --> >
> --> > What customers are telling us is that they will deploy RBridges
by
> --> > creating an RBridge backbone in which all the links will be
10GE.
> --> >
> --> > They will connect regular bridges and host to the
> --> periphery of this
> --> > backbone.
> --> >
> --> > They will not mix backbone ports with access ports, because this
> --> screws
> --> > up management, traffic engineering, debugging, and
> --> troubleshooting.
> --> > Regular network design, easy to understand, is very
> --> important. Ports
> --> are
> --> > cheap, labor is expensive.
> --> >
> --> > I am totally convinced that this will account for 90+ % of TRILL
> --> > deployment.
> --> >
> --> > I am wondering if it makes sense to have a solution
> --> highly optimized
> --> for
> --> > such an environment.
> --> >
> --> > For example we can put the egress/ingress RBridge addresses in
the
> --> outer
> --> > MAC addresses and define a TRILL shim header that
> --> contains 1 byte of
> --> hop
> --> > limit and 1 byte reserved. For this common case we will get:
> --> > 1) overhead of 16 bytes (4 to 8 bytes lower)
> --> > 2) nickname = MAC address, i.e no hash collision
> --> > 3) zero-conf achieved
> --> >
> --> > In the case we need to go over a shared media we will need to
add
> --> > another Ethernet encapsulation to carry the next hop
> --> address, i.e. 14
> --> > bytes
> --> > - total overhead will be 30 bytes
> --> >
> --> > Summarizing:
> --> > - current proposal 20-24 bytes overhead
> --> > - new proposal on point to point: 16 bytes
> --> > - new proposal on shared media: 30 bytes
> --> >
> --> > Comments?
> --> >
> --> > -- Silvano
> --> >
> --> >
> --> > _______________________________________________
> --> > rbridge mailing list
> --> > [e-mail]
> --> > http://mailman.postel.org/mailman/listinfo/rbridge
> --> >
> --> > _______________________________________________
> --> > rbridge mailing list
> --> > [e-mail]
> --> > http://mailman.postel.org/mailman/listinfo/rbridge
> -->
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA701Cmf011855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 6 Nov 2006 16:01:13 -0800 (PST)
Received: from [75.214.91.246] (246.sub-75-214-91.myvzw.com [75.214.91.246]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kA7000Hb000072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Nov 2006 16:00:02 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 06 Nov 2006 15:59:57 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Dinesh G Dutt <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF7CA38ECC77FEB9BA08564CF"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Comments on draft-ietf-trill-prob-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2006 00:01:45 -0000
Status: RO
Content-Length: 4237

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

Dinesh,

Thanks for your post.

Most should be easy to incorporate, so I trimmed them from the list.
Some notes/questions on others below:

Dinesh G Dutt wrote:
> Hi,
>=20
> Here are some comments based on the last call for=20
> draft-ietf-trill-prob-01.txt. Some general comments first.
=2E..
> - Section 2.4: There is no mention of other Ethernet protocols such as =

> 802.1au (Congestion Notification), 802.3ad (Link Aggregation), 802.3x=20
> (PAUSE). What is the relation of TRILL to these protocols ?

We haven't talked about them per-se. The 802.1 extensions are link
technology independent; the 802.3 ones do not appear to be (e.g.,
802.3ad seems GigE specific). I didn't think we were doing anything link
technology dependent.

I'm assuming control frames would be passed transparently, but I didn't
know whether we were requiring any of these on the paths inside the
rbridge, or whether they need to be interfaced to the routing protocols.

Any others have a position on this? IMO, 802.1* protocols are on the
table, but 802.3* ones shouldn't be if possible.

The goal is to support any frame that exists on an conventional ethernet
(D, D-2004, w, Q, Q-REV, v, s, etc. - though as far as I'm able to tell,
s is a supplement to Q, not subsumed in Q, and w is subsumed in D-2004).
This goes to your earlier question about support for other ethernet
control protocols, and your question below as well about VLAN pruning.

IMO, 802.1 D-2004 ought to be a minimum, but I'd add Q-REV, v, s

> - Section 2.5:I don't know were these number come from, but with 256/51=
2=20
> ports Ethernet switches available, it does not take 10,000 bridges to=20
> reach 100,000 nodes. I also don't understand if the mention of 1,000=20
> VLANs is intended as a limit. Many customers don't have enough of 4,000=
=20
> VLANs and deploy private VLANs.

The numbers are intended to reflect current scales; the goal is to imply
that this is NOT about scaling better than existing solutions. I can
update the numbers, adjust the text to refer to them as approximate, or
both.

Again, any others have a position on this?

> - Section 3.2: Use of VLANs in TRILL needs to be clarified. For example=
,=20
> there can be a VLAN tag in the outer MAC header as well as the inner=20
> MAC. Again, this has been the subject of extensive discussion on the=20
> mailing list.

Yes; how the two are handled should be addressed.

> - Section 3.2: What about VLAN pruning ? Should that be supported as=20
> well by TRILL ?

Can you define "support"? Does this mean transparently-forward, or
participate in? I didn't expect such protocols to go beyond the ingress
unless they were transparently forwarded; I didn't expect us to tie
these protocols into the interior IP routing.

Comments from others?

> - Section 3.3: Use of TTL alone isn't sufficient to fix problems caused=
=20
> by transient loops during topology changes. Again, this has been the=20
> subject of intense discussion on the mailing list. A form of interlock =

> protocol must ensure that there are no transient broadcast or multicast=
=20
> loops during topology changes.

TTL *must* be decremented before a packet is emitted; this can happen
before or after it is copied in multicast/broadcast. In that case (which
we might point out more explicitly), can you explain how TTL is not
sufficient?

> - Section 3.4: Interaction with spanning tree protocol as discussed=20
> under the subject "Traffic Storms" should be included here.

A short summary would be useful, if you can provide one ;-)

Joe


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

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

iD8DBQFFT8x9E5f5cImnZrsRAmbmAJ9fWaljJsxmwcdeJpgfm0lWaZC8VwCeNO8w
6lI5khhqlLvStngY/g2aOw4=
=A4gc
-----END PGP SIGNATURE-----

--------------enigF7CA38ECC77FEB9BA08564CF--


Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6Namq0002941 for <[e-mail]>; Mon, 6 Nov 2006 15:36:49 -0800 (PST)
Received: by ug-out-1314.google.com with SMTP id l31so898286ugc for <[e-mail]>; Mon, 06 Nov 2006 15:36:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Y0GCBCHdcLwClZsIHH9rdLXfX6wJivb7aV/UCsbyeDoDfM2APXS64NPw38Nkv7mRWHprKt/auf8jYBlF6M0ip2ekUkPT4q5QRDxsC2dY3yMBifNag2hqYu57KnBvv2XEee279NxOwEAh/6Nmerx8HP5NQPU6Eehgh5xNNS8TJd8=
Received: by 10.78.83.13 with SMTP id g13mr7471955hub.1162856207100; Mon, 06 Nov 2006 15:36:47 -0800 (PST)
Received: by 10.78.90.3 with HTTP; Mon, 6 Nov 2006 15:36:46 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 6 Nov 2006 15:36:47 -0800
From: "Alia Atlas" <[e-mail]>
To: "Joe Touch" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] LIDs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 23:36:58 -0000
Status: RO
Content-Length: 2469

I agree that LIDs are not a good idea.  For instance, if the ingress
has a separate next-hop table, then the size of the next-hop table
must grow to be O(rbridge interfaces) instead of O(rbridges) to store
the different encapsulation information.

This is avoiding a lookup on the egress rbridge to distribute more
change through the network and increase substantially the table
requirements on all ingress rbridges.

Alia

On 11/6/06, Joe Touch <[e-mail]> wrote:
> Caitlin Bestler wrote:
> ...
> >>
> >> With LIDs, an entry is need only per port, not per local MAC.
> >>  So given a 16 bit LID, only 16 cards * 48 ports * 16 bits =
> >> ~12kbits, a savings of ~47kbits.
> >>
> >> The more locally attached MACs, the bigger the savings.
> >
> > Instead of keeping the MAC to Port mapping in the egress RBridge
> > you instead keep it in each ingress rbridge that has learned
> > of this rbridge. I'm not seeing a net savings in memory costs
> > anywhere. There is certainly a potential latency benefit, but
> > is there really one that is valid over the desired lifespan
> > of the protocol?
>
> Catching up, and based on discussions today:
>
> LIDs don't seem to reduce memory; they increase it. The egress needs the
> MAC/LID table to tell the ingress anyway.
>
> Pro:    LIDs allow one existing ingress lookup to determine egress name
>         and egress port, saving the port lookup step at the egress.
>
> Con:    Larger shim header.
>
>         Need to coordinate LIDs to the ingress whenever egress port
>         changes (even if egress name doesn't), i.e., when a node moves
>         ports on an egress, the rbridge is impacted.
>
>         Packets lost/misdirected between when LID changes and when
>         ingress is updated.
>
>         Larger table -- O(R*P), vs O(R), where R=# routers, P=# ports.
>
> Given the fact that the lookup required is basically what bridges
> already do, I'm not sure why this is a useful reduction of effort at the
> egress. Further, a large egress should already have the resources to
> handle a large number of ports; shifting the work to the ingress could
> potentially redistribute the load in ways that make small ingresses
> responsible for very large egress tables.
>
> This seems like complexity and scalability risk that should be avoided.
>
> Joe
>
>
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>
>
>


Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6NVpMI001309 for <[e-mail]>; Mon, 6 Nov 2006 15:31:51 -0800 (PST)
Received: by ug-out-1314.google.com with SMTP id l31so897150ugc for <[e-mail]>; Mon, 06 Nov 2006 15:31:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hgnRj2mbd4OkylNAk0ypD5GLwXv6+sc3NYqVG+pk1KfM5dATpEiHkVPLZPdwS4/VRxGVRgMocQwBpnGdg/HFP5Ko4blu5v65BjViBjmbrn/rCb8tg0OY0YxfPzLi5pBlPN+Q/qLai0zYXHCOvRdlc6sP98eo42EtxPqSsbaJ9AU=
Received: by 10.78.157.8 with SMTP id f8mr4096244hue.1162855909419; Mon, 06 Nov 2006 15:31:49 -0800 (PST)
Received: by 10.78.90.3 with HTTP; Mon, 6 Nov 2006 15:31:49 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 6 Nov 2006 15:31:49 -0800
From: "Alia Atlas" <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Disposition: inline
References: <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA6NVpMI001309
Cc: [e-mail], Gideon Kaempfer <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 23:33:33 -0000
Status: RO
Content-Length: 19190

The multi-hop micro-forwarding loops only come up with asymmetric link
costs.  In TRILL, I believe the assumption is that there aren't
asymmetric link costs so that traffic flows are bidirectional.

For this case, dropping frames that would transmit through the same
interface that received it would handle the micro-forwarding loops, I
believe.

Alia

On 11/6/06, Pierre Francois <[e-mail]> wrote:
> Gray, Eric wrote:
> > Pierre,
> >
> >       The "?loop problem" is apparently an issue with some devices where
> > reasonable forwarding behavior limitations have been "optimized out."  A
> > better way to handle the ?loop problem with RBridges is not to optimize
> > out the behavior that prevents it - i.e. - a prohibition against emitting
> > a frame on the same interface on which it was received.
> >       To be clear, at either the last IETF meeting, or the one just before
> > that one, it was made fairly clear that the ?loop problem occurs when a
> > device sends a PDU out of the same interface on which it was received. In
> > comparison with simply dropping such a PDU, this behavior is pathological
> > - particularly in the case of L2 forwarding generally.
> >
>
> That would mean that under a **planned** removal of an rbridge-rbridge
> link, where the rbridge network could suffer of forwarding
> loops, you could drop traffic. Indeed,  "IS-IS like FIBs" are updated in
> an asynchronous fashion upon topological changes, so that transient
> inconsistency in the forwarding of
> unicast traffic, leading to ?loops,  is something that regularly occur.
>
> Moreover, if you use TE tools to set up the metrics of your links, you
> might end up with metric(X-->Y) != metric(Y-->X).
> In such cases, "longer ?loops", i.e. loops involving 3 or 4 rBridges can
> occur upon convergence,
> in which case the simple "incoming interface <>outgoing interface" loop
> mitigation check won't work.
>
> Pierre.
> >       I am not saying that we do not need ordered FIB for loop prevention
> > generally, but we should not need it for the ?loop problem.
> >
>
>
> > --
> > Eric
> >
> > --> -----Original Message-----
> > --> From: [e-mail]
> > --> [mailto:[e-mail]] On Behalf Of Pierre Francois
> > --> Sent: Monday, November 06, 2006 5:20 PM
> > --> To: Sanjay Sane (sanjays)
> > --> Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
> > --> Subject: Re: [rbridge] Traffic storms
> > -->
> > -->
> > --> Sanjay,
> > -->
> > --> Sanjay Sane (sanjays) wrote:
> > --> > Pierre,
> > --> >
> > --> > After reading through this paper, it seems the oFIB
> > --> mechanism is suited
> > --> > towards unicast traffic, or a single-destination traffic.
> > --> >
> > --> > In TRILL, if the plan is to protect the traffic storms, we *must*
> > --> > protect the transient loops in the "trees" that are built to carry
> > --> > unknowns/floods, multicast as well as unicast. Such
> > --> traffic is targetted
> > --> > towards multiple destination, in fact, a tree extends to all the
> > --> > rbridges.
> > --> >
> > --> > After thinking a bit, if we think of extending the
> > --> mechanisms in the
> > --> > paper to cover "trees", we may have to delay the FIB
> > --> ordering on all the
> > --> > links that are part of the tree on any given rbridge.
> > --> This could be very
> > --> > inefficient. Do you think the oFIB mechanism would be
> > --> suitable for such
> > --> > trees?
> > --> >
> > -->
> > --> Applying an "oFIB-like" solution for multicast traffic is
> > --> something we
> > --> are working on.
> > --> So, you can make ofib suitable for multicast trees, but we
> > --> intend to
> > --> modify it for efficiency purposes.
> > --> btw, you already face the ?loop problem for unicast
> > --> traffic, and there
> > --> oFIB can be applied as-is by rbridges..
> > -->
> > --> Pierre.
> > --> > -Sanjay
> > --> >
> > --> >
> > --> >
> > --> > -----Original Message-----
> > --> > From: [e-mail]
> > --> [mailto:[e-mail]] On
> > --> > Behalf Of Pierre Francois
> > --> > Sent: Friday, November 03, 2006 5:10 PM
> > --> > To: Silvano Gai
> > --> > Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
> > --> > Subject: Re: [rbridge] Traffic storms
> > --> >
> > --> >
> > --> > Silvano,
> > --> >
> > --> > See
> > --> >
> > --> http://www.ietf.org/internet-drafts/draft-francois-ordered-f
> > --> ib-02.txt,
> > --> > for a loop avoidance mechanism for IS-IS/OSPF.
> > --> >
> > --> > See you in SD,
> > --> >
> > --> > Pierre.
> > --> >
> > --> >
> > --> >
> > --> > On Fri, 3 Nov 2006, Silvano Gai wrote:
> > --> >
> > --> >
> > --> >> Eric,
> > --> >>
> > --> >> Also I suggest that people that have solved the problem
> > --> of having a
> > --> >> loop free topology using ISIS, submit proposasl so that
> > --> we can compare
> > --> >>
> > --> > them.
> > --> >
> > --> >> Unfortunately I don't have one.
> > --> >>
> > --> >>
> > --> >>
> > --> >> -- Silvano
> > --> >>
> > --> >>
> > --> >>
> > --> >> ________________________________
> > --> >>
> > --> >> From: [e-mail]
> > --> [mailto:[e-mail]]
> > --> >> On Behalf Of Gray, Eric
> > --> >> Sent: Friday, November 03, 2006 11:54 AM
> > --> >> To: Gideon Kaempfer; Radia Perlman
> > --> >> Cc: [e-mail]
> > --> >> Subject: Re: [rbridge] Traffic storms
> > --> >>
> > --> >>
> > --> >>
> > --> >> Gideon,
> > --> >>
> > --> >>
> > --> >>
> > --> >>     "Drop BPDUs" is not (exactly) the same as ignore
> > --> them.  We use the
> > --> >>
> > --> >
> > --> >
> > --> >> term
> > --> >>
> > --> >> as short-hand for the one of three options we considered
> > --> for handling
> > --> >> BPDUs:
> > --> >>
> > --> >>
> > --> >>
> > --> >>     Drop (do not participate actively in STP, and do not
> > --> pass BPDUs
> > --> >> through),
> > --> >>
> > --> >>     Transparent (pass BPDUs through - potentially
> > --> altering them in
> > --> >> some way),
> > --> >>
> > --> >>     Participate (have each RBridge participate in STP as
> > --> if it were a
> > --> >> bridge).
> > --> >>
> > --> >>
> > --> >>
> > --> >> Hence, when we say "Drop BPDUs" we are not saying that
> > --> we cannot look
> > --> >>
> > --> >> at them, we are just saying that we're not doing one of
> > --> the other two
> > --> >> choices.
> > --> >>
> > --> >>
> > --> >>
> > --> >> --
> > --> >>
> > --> >> Eric
> > --> >>
> > --> >>
> > --> >>
> > --> >>
> > --> >> ________________________________
> > --> >>
> > --> >>
> > --> >>        From: [e-mail]
> > --> >> [mailto:[e-mail]] On Behalf Of Gideon Kaempfer
> > --> >>        Sent: Friday, November 03, 2006 1:40 AM
> > --> >>        To: Radia Perlman
> > --> >>        Cc: [e-mail]
> > --> >>        Subject: Re: [rbridge] Traffic storms
> > --> >>
> > --> >>        Radia,
> > --> >>
> > --> >>        Wouldn't this create a link between TRILL and STP we are trying
> > --> >>
> > --> > to
> > --> >
> > --> >> avoid?
> > --> >>
> > --> >>        Relying on the fact that a LAN segment has some kind of unique
> > --> >> identifier (such as the root bridge ID) seems like a
> > --> very practical
> > --> >> solution to me, but strongly reliant on the fact that
> > --> the Rbridges
> > --> >> actually process BPDUs. I thought they were just meant to discard
> > --> >>
> > --> > them.
> > --> >
> > --> >> Is this acceptable?
> > --> >>
> > --> >>        Regrads,
> > --> >>
> > --> >>         Gidi
> > --> >>
> > --> >>
> > --> >>
> > --> >>        On 11/3/06, Radia Perlman <[e-mail]> wrote:
> > --> >>
> > --> >>        The simplest way to put it, I think, is that in certain
> > --> >>
> > --> > transitory
> > --> >
> > --> >>        situations there might be two
> > --> >>        RBridges that both think they are Designated RBridge, and that
> > --> >>
> > --> > is
> > --> >
> > --> >> bad,
> > --> >>        but should stop
> > --> >>        as soon as a single Hello is received by the RBridge who should
> > --> >>
> > --> > not
> > --> >
> > --> >> be
> > --> >>        Designated.
> > --> >>
> > --> >>        I think PIM has similar transitory situations that can occur,
> > --> >>
> > --> > and
> > --> >
> > --> >>        bridges can also have (hopefully
> > --> >>        temporary) problems if a repeater came up and merged two LANs. I
> > --> >>
> > --> >
> > --> >
> > --> >> think
> > --> >>        such things are
> > --> >>        annoying but not fatal. But I think it's possible we can with
> > --> >>
> > --> > little
> > --> >
> > --> >>        effort avoid this problem.
> > --> >>
> > --> >>        However, with RBridges, because the bridge spanning tree
> > --> >>
> > --> > algorithm
> > --> >
> > --> >>        elects a Root, there's
> > --> >>        really a way of uniquely identifying a LAN (where "LAN" is a
> > --> >>
> > --> > bunch of
> > --> >
> > --> >>        links connected with
> > --> >>        bridges). The unique identifier is the root bridge.
> > --> >>
> > --> >>        When the B1-B2 link is down, RB1 and RB2 will see the topology
> > --> >>
> > --> > as two
> > --> >
> > --> >>        separate links, and each
> > --> >>        one will have a distinct spanning tree Root bridge (RB1 will see
> > --> >>
> > --> > B1,
> > --> >
> > --> >> and
> > --> >>        RB2 will see B2 as the root).
> > --> >>
> > --> >>        When the B1-B2 link comes up, the bridges will first merge the
> > --> >>
> > --> > two
> > --> >
> > --> >>        links, and either RB1 or RB2 will
> > --> >>        see that the bridge spanning tree root has changed. This will be
> > --> >>        discovered before B1 and B2 forward
> > --> >>        traffic across the link because of the bridge forwarding delay.
> > --> >>        If B1 has better priority as bridge spanning tree root than B2,
> > --> >>
> > --> > then
> > --> >
> > --> >> RB1
> > --> >>        will not notice anything
> > --> >>        different when the B1-B2 link comes up. But RB2 will notice
> > --> >>        something different; the spanning tree root has changed
> > --> >>
> > --> > identities
> > --> >
> > --> >> from
> > --> >>        "B2" to "B1".
> > --> >>
> > --> >>        Given this, RB2 could temporarily stop forwarding to or from the
> > --> >>
> > --> > link
> > --> >
> > --> >>        when the Root bridge
> > --> >>        changes identities, though it should definitely immediately send
> > --> >>
> > --> >
> > --> >
> > --> >> IS-IS
> > --> >>        Hellos (either RB1 or RB2 will
> > --> >>        be elected Designated Router in the IS-IS election for that
> > --> >>
> > --> > link). If
> > --> >
> > --> >>        RB2 has better prioirty for
> > --> >>        root, the RB1 will immediately stop forwarding to or from the
> > --> >>
> > --> > link
> > --> >
> > --> >> when
> > --> >>        it sees the Hello from RB2.
> > --> >>        If RB2 has better priority in the IS-IS election, then RB1
> > --> >>
> > --> > should
> > --> >
> > --> >>        immediately send an IS-IS Hello
> > --> >>        when it sees a Hello from a new RBridge on the link.
> > --> >>
> > --> >>        So I think this is not a big deal, and that if we are worried,
> > --> >>
> > --> > we can
> > --> >
> > --> >>        specify that an RBridge should
> > --> >>        stop acting like the Designated RBridge for a few seconds after
> > --> >>
> > --> > the
> > --> >
> > --> >>        identity of the Root in the spanning
> > --> >>        tree algorithm changes.
> > --> >>
> > --> >>        Or we could be even fancier and have each RBridge announce in
> > --> >>
> > --> > its
> > --> >
> > --> >> IS-IS
> > --> >>        Hellos which LAN IDs it
> > --> >>        is Designated for, where a LAN ID is the MAC address of the Root
> > --> >>
> > --> >
> > --> >
> > --> >> bridge.
> > --> >>        So RB1 continue
> > --> >>        forwarding if the identity changes from B1 to B2 provided no
> > --> >>
> > --> > other
> > --> >
> > --> >>        RBridge has claimed to be connected
> > --> >>        to B2. But if RB2's LSP claims it is attached to B2, then RB1
> > --> >>
> > --> > must
> > --> >
> > --> >> stop
> > --> >>        forwarding for enough time
> > --> >>        for the IS-IS election to sort itself out and choose a
> > --> >>
> > --> > Designated
> > --> >
> > --> >> RBridge.
> > --> >>
> > --> >>        Radia
> > --> >>
> > --> >>
> > --> >>
> > --> >>
> > --> >>
> > --> >>
> > --> >>        Gideon Kaempfer wrote:
> > --> >>
> > --> >>        >Following mention by Silvano of broadcast and multicast storms
> > --> >>
> > --> > (and
> > --> >
> > --> >> the need
> > --> >>        >to protect against them), I played around with different
> > --> >>
> > --> > scenarios
> > --> >
> > --> >> and came
> > --> >>        >upon one I would appreciate your comments on (in the hope I am
> > --> >> pointing out
> > --> >>        >a non-existent issue with TRILL). I believe a broadcast and
> > --> >>
> > --> > even a
> > --> >
> > --> >> unicast
> > --> >>        >storm could be created as the result of a loop that isn't
> > --> >>
> > --> > protected
> > --> >
> > --> >> by TTL
> > --> >>        >nor by STP in the case of a link connecting two separate LAN
> > --> >> segments coming
> > --> >>        >to life.
> > --> >>        >
> > --> >>        >- RB1 ---- RB2 -
> > --> >>        >   |        |
> > --> >>        >-  B1 --x-- B2 -
> > --> >>        >   |        |
> > --> >>        >   H1       H2
> > --> >>        >
> > --> >>        >1. The network (segment) involved consists of two Rbridges
> > --> >>
> > --> > (RB1,
> > --> >
> > --> >> RB2), two
> > --> >>        >bridges (B1, B2) and two hosts (H1, H2). They are physically
> > --> >> connected as
> > --> >>        >depicted.
> > --> >>        >2. State A: the direct link between B1 and B2 is down. B1 and
> > --> >> B2 find
> > --> >>        >themselves on different LAN segments and hence different
> > --> >>
> > --> > spanning
> > --> >
> > --> >> trees. RB1
> > --> >>        >and RB2 are both designated Rbridges (each for the segment of
> > --> >>
> > --> > the
> > --> >
> > --> >>        >corresponding bridge).
> > --> >>        >3. State B: the direct link between B1 and B2 goes up (someone
> > --> >> connects a
> > --> >>        >cable). B1 and B2 discover each other and establish a common
> > --> >> spanning tree.
> > --> >>        >RB1 and RB2 both find themselves attached to the same LAN
> > --> >>
> > --> > segment
> > --> >
> > --> >> and hence
> > --> >>        >RB1 (without loss of generality) will eventually become the
> > --> >> designated
> > --> >>        >Rbridge for it.
> > --> >>        >4. Just before RB1 and RB2 identify that they are both on the
> > --> >>
> > --> > same
> > --> >
> > --> >> segment
> > --> >>        >and RB2 stops functioning as a designated Rbridge the following
> > --> >>
> > --> >
> > --> >
> > --> >> scenario
> > --> >>        >seems possible:
> > --> >>        >  a. H1 sends a broadcast frame.
> > --> >>        >  b. B1 receives it and forwards to RB1 and B2.
> > --> >>        >  c. RB1 (encapsulates and) forwards to RB2.
> > --> >>        >  d. B2 forwards to RB2 and H2.
> > --> >>        >  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2
> > --> >>
> > --> > to
> > --> >
> > --> >> RB1).
> > --> >>        >  f. (RB1 forwards to B1.)
> > --> >>        >  g. B2 forwards (again) to H2 and to B1.
> > --> >>        >  h. B1 forwards to H1 (see remark below regarding filtering
> > --> >>
> > --> > table
> > --> >
> > --> >>        >contamination) and to RB1.
> > --> >>        >  i. Etcetera etcetera.
> > --> >>        >5. A broadcast storm is born, created by a loop that is not
> > --> >> protected by TTL
> > --> >>        >(due to the fact that forwarding between the Rbridges is only
> > --> >>
> > --> > across
> > --> >
> > --> >> a
> > --> >>        >single hop) nor by STP (due to the fact that Rbridges do not
> > --> >> participate in
> > --> >>        >STP).
> > --> >>        >6. If forwarding commences at the hardware level and no
> > --> >>
> > --> > broadcast
> > --> >
> > --> >> rate
> > --> >>        >limiting is in place, the storm may cause severe damage in a
> > --> >>
> > --> > very
> > --> >
> > --> >> short time
> > --> >>        >(note that replicated frames are sent to H1 and H2 (or any
> > --> >>
> > --> > network
> > --> >
> > --> >> they
> > --> >>        >could represent).
> > --> >>        >7. Another unfortunate effect of this storm is that B1 and B2
> > --> >>
> > --> > no
> > --> >
> > --> >> longer know
> > --> >>        >where H1 is located (due to the contamination of their
> > --> >>
> > --> > filtering
> > --> >
> > --> >> tables by a
> > --> >>        >frame from H1 that arrives from the wrong direction (and in
> > --> >>
> > --> > fact
> > --> >
> > --> >> from
> > --> >>        >multiple directions). As a result, a possible unicast frame
> > --> >>
> > --> > from H2
> > --> >
> > --> >> to H1
> > --> >>        >will just join the storm over the loop at least in one
> > --> >>
> > --> > direction
> > --> >
> > --> >> (RB2 will
> > --> >>        >forward it to RB1) but will not arrive at H1...
> > --> >>        >
> > --> >>        >One possible solution could be for RB2 to identify the fact
> > --> >>
> > --> > that it
> > --> >
> > --> >> is
> > --> >>        >receiving a frame from a host with a MAC address that is
> > --> >>
> > --> > associated
> > --> >
> > --> >> with a
> > --> >>        >segment it thought it isn't connected to. Hence, it may trigger
> > --> >>
> > --> > an
> > --> >
> > --> >> immediate
> > --> >>        >neighbor discovery / designated Rbridge election. However,
> > --> >>
> > --> > because
> > --> >
> > --> >> Rbridges
> > --> >>        >should allow host mobility, this frame may need to be forwarded
> > --> >>
> > --> > (and
> > --> >
> > --> >> hence
> > --> >>        >the storm commences).
> > --> >>        >
> > --> >>        >As mentioned above, any comments are welcome.
> > --> >>        >  Gideon Kaempfer
> > --> >>        >
> > --> >>        >_______________________________________________
> > --> >>        >rbridge mailing list
> > --> >>        >[e-mail]
> > --> >>        > http://mailman.postel.org/mailman/listinfo/rbridge
> > --> >> <http://mailman.postel.org/mailman/listinfo/rbridge>
> > --> >>        >
> > --> >>        >
> > --> >>
> > --> >>        _______________________________________________
> > --> >>        rbridge mailing list
> > --> >>        [e-mail]
> > --> >>        http://mailman.postel.org/mailman/listinfo/rbridge
> > --> >>
> > --> >>
> > --> >>
> > --> >>
> > --> >>
> > --> > _______________________________________________
> > --> > rbridge mailing list
> > --> > [e-mail]
> > --> > http://mailman.postel.org/mailman/listinfo/rbridge
> > --> >
> > --> >
> > -->
> > --> _______________________________________________
> > --> rbridge mailing list
> > --> [e-mail]
> > --> http://mailman.postel.org/mailman/listinfo/rbridge
> > -->
> >
> >
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6NNYMc028958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 6 Nov 2006 15:23:34 -0800 (PST)
Received: from [75.214.91.246] (246.sub-75-214-91.myvzw.com [75.214.91.246]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kA6NMrg5020237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Nov 2006 15:22:58 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 06 Nov 2006 15:22:51 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Caitlin Bestler <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig710D60A126E918DA987DDE3B"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] LIDs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 23:23:53 -0000
Status: RO
Content-Length: 2416

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

Caitlin Bestler wrote:
=2E..
>>
>> With LIDs, an entry is need only per port, not per local MAC.
>>  So given a 16 bit LID, only 16 cards * 48 ports * 16 bits =3D
>> ~12kbits, a savings of ~47kbits.
>>
>> The more locally attached MACs, the bigger the savings.
>=20
> Instead of keeping the MAC to Port mapping in the egress RBridge
> you instead keep it in each ingress rbridge that has learned
> of this rbridge. I'm not seeing a net savings in memory costs
> anywhere. There is certainly a potential latency benefit, but
> is there really one that is valid over the desired lifespan
> of the protocol?

Catching up, and based on discussions today:

LIDs don't seem to reduce memory; they increase it. The egress needs the
MAC/LID table to tell the ingress anyway.

Pro:	LIDs allow one existing ingress lookup to determine egress name
	and egress port, saving the port lookup step at the egress.

Con:	Larger shim header.

	Need to coordinate LIDs to the ingress whenever egress port
	changes (even if egress name doesn't), i.e., when a node moves
	ports on an egress, the rbridge is impacted.

	Packets lost/misdirected between when LID changes and when
	ingress is updated.

	Larger table -- O(R*P), vs O(R), where R=3D# routers, P=3D# ports.

Given the fact that the lookup required is basically what bridges
already do, I'm not sure why this is a useful reduction of effort at the
egress. Further, a large egress should already have the resources to
handle a large number of ports; shifting the work to the ingress could
potentially redistribute the load in ways that make small ingresses
responsible for very large egress tables.

This seems like complexity and scalability risk that should be avoided.

Joe


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

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

iD8DBQFFT8PLE5f5cImnZrsRAk+HAJ4nz+ZdiWElEk6QnKyxUi/dOtygYwCeNApu
PzX6CdyLhP4vHcQC+k4CZoI=
=yiMu
-----END PGP SIGNATURE-----

--------------enig710D60A126E918DA987DDE3B--


Received: from smtp-1.dynsipr.ucl.ac.be (smtp-1.dynsipr.ucl.ac.be [130.104.4.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6N1IaA021215 for <[e-mail]>; Mon, 6 Nov 2006 15:01:19 -0800 (PST)
Received: from smtp-1.dynsipr.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp-1.dynsipr.ucl.ac.be (Postfix) with ESMTP id 22A912C2DE; Tue,  7 Nov 2006 00:01:17 +0100 (CET)
Received: from [130.129.68.111] (dhcp68-111.ietf67.org [130.129.68.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: [e-mail]) by smtp-1.dynsipr.ucl.ac.be (Postfix) with ESMTP; Tue,  7 Nov 2006 00:01:16 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 06 Nov 2006 15:01:00 -0800
From: Pierre Francois <[e-mail]>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-AV-Checked: ClamAV using ClamSMTP
X-SGSI-MailScanner: Found to be clean
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Gideon Kaempfer <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail]
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 23:01:56 -0000
Status: RO
Content-Length: 17131

Gray, Eric wrote:
> Pierre,
>
> 	The "?loop problem" is apparently an issue with some devices where
> reasonable forwarding behavior limitations have been "optimized out."  A
> better way to handle the ?loop problem with RBridges is not to optimize
> out the behavior that prevents it - i.e. - a prohibition against emitting
> a frame on the same interface on which it was received.
> 	To be clear, at either the last IETF meeting, or the one just before
> that one, it was made fairly clear that the ?loop problem occurs when a
> device sends a PDU out of the same interface on which it was received. In 
> comparison with simply dropping such a PDU, this behavior is pathological
> - particularly in the case of L2 forwarding generally.
>   

That would mean that under a **planned** removal of an rbridge-rbridge 
link, where the rbridge network could suffer of forwarding
loops, you could drop traffic. Indeed,  "IS-IS like FIBs" are updated in 
an asynchronous fashion upon topological changes, so that transient 
inconsistency in the forwarding of
unicast traffic, leading to ?loops,  is something that regularly occur.

Moreover, if you use TE tools to set up the metrics of your links, you 
might end up with metric(X-->Y) != metric(Y-->X).
In such cases, "longer ?loops", i.e. loops involving 3 or 4 rBridges can 
occur upon convergence,
in which case the simple "incoming interface <>outgoing interface" loop 
mitigation check won't work.

Pierre.
> 	I am not saying that we do not need ordered FIB for loop prevention
> generally, but we should not need it for the ?loop problem.
>   


> --
> Eric
>
> --> -----Original Message-----
> --> From: [e-mail] 
> --> [mailto:[e-mail]] On Behalf Of Pierre Francois
> --> Sent: Monday, November 06, 2006 5:20 PM
> --> To: Sanjay Sane (sanjays)
> --> Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
> --> Subject: Re: [rbridge] Traffic storms
> --> 
> --> 
> --> Sanjay,
> --> 
> --> Sanjay Sane (sanjays) wrote:
> --> > Pierre,
> --> >
> --> > After reading through this paper, it seems the oFIB 
> --> mechanism is suited
> --> > towards unicast traffic, or a single-destination traffic. 
> --> >
> --> > In TRILL, if the plan is to protect the traffic storms, we *must*
> --> > protect the transient loops in the "trees" that are built to carry
> --> > unknowns/floods, multicast as well as unicast. Such 
> --> traffic is targetted
> --> > towards multiple destination, in fact, a tree extends to all the
> --> > rbridges. 
> --> >
> --> > After thinking a bit, if we think of extending the 
> --> mechanisms in the
> --> > paper to cover "trees", we may have to delay the FIB 
> --> ordering on all the
> --> > links that are part of the tree on any given rbridge. 
> --> This could be very
> --> > inefficient. Do you think the oFIB mechanism would be 
> --> suitable for such
> --> > trees?
> --> >   
> --> 
> --> Applying an "oFIB-like" solution for multicast traffic is 
> --> something we 
> --> are working on.
> --> So, you can make ofib suitable for multicast trees, but we 
> --> intend to 
> --> modify it for efficiency purposes.
> --> btw, you already face the ?loop problem for unicast 
> --> traffic, and there 
> --> oFIB can be applied as-is by rbridges..
> --> 
> --> Pierre.
> --> > -Sanjay 
> --> >
> --> >  
> --> >
> --> > -----Original Message-----
> --> > From: [e-mail] 
> --> [mailto:[e-mail]] On
> --> > Behalf Of Pierre Francois
> --> > Sent: Friday, November 03, 2006 5:10 PM
> --> > To: Silvano Gai
> --> > Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
> --> > Subject: Re: [rbridge] Traffic storms
> --> >
> --> >
> --> > Silvano,
> --> >
> --> > See
> --> > 
> --> http://www.ietf.org/internet-drafts/draft-francois-ordered-f
> --> ib-02.txt,
> --> > for a loop avoidance mechanism for IS-IS/OSPF.
> --> >
> --> > See you in SD,
> --> >
> --> > Pierre.
> --> >
> --> >
> --> >
> --> > On Fri, 3 Nov 2006, Silvano Gai wrote:
> --> >
> --> >   
> --> >> Eric,
> --> >>
> --> >> Also I suggest that people that have solved the problem 
> --> of having a 
> --> >> loop free topology using ISIS, submit proposasl so that 
> --> we can compare
> --> >>     
> --> > them.
> --> >   
> --> >> Unfortunately I don't have one.
> --> >>
> --> >>
> --> >>
> --> >> -- Silvano
> --> >>
> --> >>
> --> >>
> --> >> ________________________________
> --> >>
> --> >> From: [e-mail] 
> --> [mailto:[e-mail]] 
> --> >> On Behalf Of Gray, Eric
> --> >> Sent: Friday, November 03, 2006 11:54 AM
> --> >> To: Gideon Kaempfer; Radia Perlman
> --> >> Cc: [e-mail]
> --> >> Subject: Re: [rbridge] Traffic storms
> --> >>
> --> >>
> --> >>
> --> >> Gideon,
> --> >>
> --> >>
> --> >>
> --> >>     "Drop BPDUs" is not (exactly) the same as ignore 
> --> them.  We use the
> --> >>     
> --> >
> --> >   
> --> >> term
> --> >>
> --> >> as short-hand for the one of three options we considered 
> --> for handling
> --> >> BPDUs:
> --> >>
> --> >>
> --> >>
> --> >>     Drop (do not participate actively in STP, and do not 
> --> pass BPDUs 
> --> >> through),
> --> >>
> --> >>     Transparent (pass BPDUs through - potentially 
> --> altering them in 
> --> >> some way),
> --> >>
> --> >>     Participate (have each RBridge participate in STP as 
> --> if it were a 
> --> >> bridge).
> --> >>
> --> >>
> --> >>
> --> >> Hence, when we say "Drop BPDUs" we are not saying that 
> --> we cannot look
> --> >>
> --> >> at them, we are just saying that we're not doing one of 
> --> the other two 
> --> >> choices.
> --> >>
> --> >>
> --> >>
> --> >> --
> --> >>
> --> >> Eric
> --> >>
> --> >>
> --> >>
> --> >>
> --> >> ________________________________
> --> >>
> --> >>
> --> >> 	From: [e-mail]
> --> >> [mailto:[e-mail]] On Behalf Of Gideon Kaempfer
> --> >> 	Sent: Friday, November 03, 2006 1:40 AM
> --> >> 	To: Radia Perlman
> --> >> 	Cc: [e-mail]
> --> >> 	Subject: Re: [rbridge] Traffic storms
> --> >>
> --> >> 	Radia,
> --> >>
> --> >> 	Wouldn't this create a link between TRILL and STP we are trying
> --> >>     
> --> > to 
> --> >   
> --> >> avoid?
> --> >>
> --> >> 	Relying on the fact that a LAN segment has some kind of unique 
> --> >> identifier (such as the root bridge ID) seems like a 
> --> very practical 
> --> >> solution to me, but strongly reliant on the fact that 
> --> the Rbridges 
> --> >> actually process BPDUs. I thought they were just meant to discard
> --> >>     
> --> > them.
> --> >   
> --> >> Is this acceptable?
> --> >>
> --> >> 	Regrads,
> --> >>
> --> >> 	 Gidi
> --> >>
> --> >>
> --> >>
> --> >> 	On 11/3/06, Radia Perlman <[e-mail]> wrote:
> --> >>
> --> >> 	The simplest way to put it, I think, is that in certain
> --> >>     
> --> > transitory
> --> >   
> --> >> 	situations there might be two
> --> >> 	RBridges that both think they are Designated RBridge, and that
> --> >>     
> --> > is 
> --> >   
> --> >> bad,
> --> >> 	but should stop
> --> >> 	as soon as a single Hello is received by the RBridge who should
> --> >>     
> --> > not 
> --> >   
> --> >> be
> --> >> 	Designated.
> --> >>
> --> >> 	I think PIM has similar transitory situations that can occur,
> --> >>     
> --> > and
> --> >   
> --> >> 	bridges can also have (hopefully
> --> >> 	temporary) problems if a repeater came up and merged two LANs. I
> --> >>     
> --> >
> --> >   
> --> >> think
> --> >> 	such things are
> --> >> 	annoying but not fatal. But I think it's possible we can with
> --> >>     
> --> > little
> --> >   
> --> >> 	effort avoid this problem.
> --> >>
> --> >> 	However, with RBridges, because the bridge spanning tree
> --> >>     
> --> > algorithm
> --> >   
> --> >> 	elects a Root, there's
> --> >> 	really a way of uniquely identifying a LAN (where "LAN" is a
> --> >>     
> --> > bunch of
> --> >   
> --> >> 	links connected with
> --> >> 	bridges). The unique identifier is the root bridge.
> --> >>
> --> >> 	When the B1-B2 link is down, RB1 and RB2 will see the topology
> --> >>     
> --> > as two
> --> >   
> --> >> 	separate links, and each
> --> >> 	one will have a distinct spanning tree Root bridge (RB1 will see
> --> >>     
> --> > B1, 
> --> >   
> --> >> and
> --> >> 	RB2 will see B2 as the root).
> --> >>
> --> >> 	When the B1-B2 link comes up, the bridges will first merge the
> --> >>     
> --> > two
> --> >   
> --> >> 	links, and either RB1 or RB2 will
> --> >> 	see that the bridge spanning tree root has changed. This will be
> --> >> 	discovered before B1 and B2 forward
> --> >> 	traffic across the link because of the bridge forwarding delay.
> --> >> 	If B1 has better priority as bridge spanning tree root than B2,
> --> >>     
> --> > then 
> --> >   
> --> >> RB1
> --> >> 	will not notice anything
> --> >> 	different when the B1-B2 link comes up. But RB2 will notice
> --> >> 	something different; the spanning tree root has changed
> --> >>     
> --> > identities 
> --> >   
> --> >> from
> --> >> 	"B2" to "B1".
> --> >>
> --> >> 	Given this, RB2 could temporarily stop forwarding to or from the
> --> >>     
> --> > link
> --> >   
> --> >> 	when the Root bridge
> --> >> 	changes identities, though it should definitely immediately send
> --> >>     
> --> >
> --> >   
> --> >> IS-IS
> --> >> 	Hellos (either RB1 or RB2 will
> --> >> 	be elected Designated Router in the IS-IS election for that
> --> >>     
> --> > link). If
> --> >   
> --> >> 	RB2 has better prioirty for
> --> >> 	root, the RB1 will immediately stop forwarding to or from the
> --> >>     
> --> > link 
> --> >   
> --> >> when
> --> >> 	it sees the Hello from RB2.
> --> >> 	If RB2 has better priority in the IS-IS election, then RB1
> --> >>     
> --> > should
> --> >   
> --> >> 	immediately send an IS-IS Hello
> --> >> 	when it sees a Hello from a new RBridge on the link.
> --> >>
> --> >> 	So I think this is not a big deal, and that if we are worried,
> --> >>     
> --> > we can
> --> >   
> --> >> 	specify that an RBridge should
> --> >> 	stop acting like the Designated RBridge for a few seconds after
> --> >>     
> --> > the
> --> >   
> --> >> 	identity of the Root in the spanning
> --> >> 	tree algorithm changes.
> --> >>
> --> >> 	Or we could be even fancier and have each RBridge announce in
> --> >>     
> --> > its 
> --> >   
> --> >> IS-IS
> --> >> 	Hellos which LAN IDs it
> --> >> 	is Designated for, where a LAN ID is the MAC address of the Root
> --> >>     
> --> >
> --> >   
> --> >> bridge.
> --> >> 	So RB1 continue
> --> >> 	forwarding if the identity changes from B1 to B2 provided no
> --> >>     
> --> > other
> --> >   
> --> >> 	RBridge has claimed to be connected
> --> >> 	to B2. But if RB2's LSP claims it is attached to B2, then RB1
> --> >>     
> --> > must 
> --> >   
> --> >> stop
> --> >> 	forwarding for enough time
> --> >> 	for the IS-IS election to sort itself out and choose a
> --> >>     
> --> > Designated 
> --> >   
> --> >> RBridge.
> --> >>
> --> >> 	Radia
> --> >>
> --> >>
> --> >>
> --> >>
> --> >>
> --> >>
> --> >> 	Gideon Kaempfer wrote:
> --> >>
> --> >> 	>Following mention by Silvano of broadcast and multicast storms
> --> >>     
> --> > (and 
> --> >   
> --> >> the need
> --> >> 	>to protect against them), I played around with different
> --> >>     
> --> > scenarios 
> --> >   
> --> >> and came
> --> >> 	>upon one I would appreciate your comments on (in the hope I am 
> --> >> pointing out
> --> >> 	>a non-existent issue with TRILL). I believe a broadcast and
> --> >>     
> --> > even a 
> --> >   
> --> >> unicast
> --> >> 	>storm could be created as the result of a loop that isn't
> --> >>     
> --> > protected 
> --> >   
> --> >> by TTL
> --> >> 	>nor by STP in the case of a link connecting two separate LAN 
> --> >> segments coming
> --> >> 	>to life.
> --> >> 	>
> --> >> 	>- RB1 ---- RB2 -
> --> >> 	>   |        |
> --> >> 	>-  B1 --x-- B2 -
> --> >> 	>   |        |
> --> >> 	>   H1       H2
> --> >> 	>
> --> >> 	>1. The network (segment) involved consists of two Rbridges
> --> >>     
> --> > (RB1, 
> --> >   
> --> >> RB2), two
> --> >> 	>bridges (B1, B2) and two hosts (H1, H2). They are physically 
> --> >> connected as
> --> >> 	>depicted.
> --> >> 	>2. State A: the direct link between B1 and B2 is down. B1 and
> --> >> B2 find
> --> >> 	>themselves on different LAN segments and hence different
> --> >>     
> --> > spanning 
> --> >   
> --> >> trees. RB1
> --> >> 	>and RB2 are both designated Rbridges (each for the segment of
> --> >>     
> --> > the
> --> >   
> --> >> 	>corresponding bridge).
> --> >> 	>3. State B: the direct link between B1 and B2 goes up (someone 
> --> >> connects a
> --> >> 	>cable). B1 and B2 discover each other and establish a common 
> --> >> spanning tree.
> --> >> 	>RB1 and RB2 both find themselves attached to the same LAN
> --> >>     
> --> > segment 
> --> >   
> --> >> and hence
> --> >> 	>RB1 (without loss of generality) will eventually become the 
> --> >> designated
> --> >> 	>Rbridge for it.
> --> >> 	>4. Just before RB1 and RB2 identify that they are both on the
> --> >>     
> --> > same 
> --> >   
> --> >> segment
> --> >> 	>and RB2 stops functioning as a designated Rbridge the following
> --> >>     
> --> >
> --> >   
> --> >> scenario
> --> >> 	>seems possible:
> --> >> 	>  a. H1 sends a broadcast frame.
> --> >> 	>  b. B1 receives it and forwards to RB1 and B2.
> --> >> 	>  c. RB1 (encapsulates and) forwards to RB2.
> --> >> 	>  d. B2 forwards to RB2 and H2.
> --> >> 	>  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2
> --> >>     
> --> > to 
> --> >   
> --> >> RB1).
> --> >> 	>  f. (RB1 forwards to B1.)
> --> >> 	>  g. B2 forwards (again) to H2 and to B1.
> --> >> 	>  h. B1 forwards to H1 (see remark below regarding filtering
> --> >>     
> --> > table
> --> >   
> --> >> 	>contamination) and to RB1.
> --> >> 	>  i. Etcetera etcetera.
> --> >> 	>5. A broadcast storm is born, created by a loop that is not 
> --> >> protected by TTL
> --> >> 	>(due to the fact that forwarding between the Rbridges is only
> --> >>     
> --> > across 
> --> >   
> --> >> a
> --> >> 	>single hop) nor by STP (due to the fact that Rbridges do not 
> --> >> participate in
> --> >> 	>STP).
> --> >> 	>6. If forwarding commences at the hardware level and no
> --> >>     
> --> > broadcast 
> --> >   
> --> >> rate
> --> >> 	>limiting is in place, the storm may cause severe damage in a
> --> >>     
> --> > very 
> --> >   
> --> >> short time
> --> >> 	>(note that replicated frames are sent to H1 and H2 (or any
> --> >>     
> --> > network 
> --> >   
> --> >> they
> --> >> 	>could represent).
> --> >> 	>7. Another unfortunate effect of this storm is that B1 and B2
> --> >>     
> --> > no 
> --> >   
> --> >> longer know
> --> >> 	>where H1 is located (due to the contamination of their
> --> >>     
> --> > filtering 
> --> >   
> --> >> tables by a
> --> >> 	>frame from H1 that arrives from the wrong direction (and in
> --> >>     
> --> > fact 
> --> >   
> --> >> from
> --> >> 	>multiple directions). As a result, a possible unicast frame
> --> >>     
> --> > from H2 
> --> >   
> --> >> to H1
> --> >> 	>will just join the storm over the loop at least in one
> --> >>     
> --> > direction 
> --> >   
> --> >> (RB2 will
> --> >> 	>forward it to RB1) but will not arrive at H1...
> --> >> 	>
> --> >> 	>One possible solution could be for RB2 to identify the fact
> --> >>     
> --> > that it 
> --> >   
> --> >> is
> --> >> 	>receiving a frame from a host with a MAC address that is
> --> >>     
> --> > associated 
> --> >   
> --> >> with a
> --> >> 	>segment it thought it isn't connected to. Hence, it may trigger
> --> >>     
> --> > an 
> --> >   
> --> >> immediate
> --> >> 	>neighbor discovery / designated Rbridge election. However,
> --> >>     
> --> > because 
> --> >   
> --> >> Rbridges
> --> >> 	>should allow host mobility, this frame may need to be forwarded
> --> >>     
> --> > (and 
> --> >   
> --> >> hence
> --> >> 	>the storm commences).
> --> >> 	>
> --> >> 	>As mentioned above, any comments are welcome.
> --> >> 	>  Gideon Kaempfer
> --> >> 	>
> --> >> 	>_______________________________________________
> --> >> 	>rbridge mailing list
> --> >> 	>[e-mail]
> --> >> 	> http://mailman.postel.org/mailman/listinfo/rbridge
> --> >> <http://mailman.postel.org/mailman/listinfo/rbridge>
> --> >> 	>
> --> >> 	>
> --> >>
> --> >> 	_______________________________________________
> --> >> 	rbridge mailing list
> --> >> 	[e-mail]
> --> >> 	http://mailman.postel.org/mailman/listinfo/rbridge
> --> >>
> --> >>
> --> >>
> --> >>
> --> >>     
> --> > _______________________________________________
> --> > rbridge mailing list
> --> > [e-mail]
> --> > http://mailman.postel.org/mailman/listinfo/rbridge
> --> >
> --> >   
> --> 
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> 
>
>   



Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6MqLw4012977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 6 Nov 2006 14:52:23 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A3046E7D4A; Mon,  6 Nov 2006 23:52:20 +0100 (CET)
Received: from [10.0.0.4] (39.Red-80-37-137.staticIP.rima-tde.net [80.37.137.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 499A7E80CD; Mon,  6 Nov 2006 23:52:19 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 06 Nov 2006 23:52:18 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 22:53:14 -0000
Status: RO
Content-Length: 2798

Radia,
       As you know, I support this approach. I have a doubt, however. 
The ID used is the RBridge ID or a different ID per port?
 I assume it is by RBridge ID. Then, as far I understand, several ports 
of an RBridge could be connected to the same bridged link. In other 
words, an RBridge port may have to compete against other port of same 
RBridge for "root bridge" election. In this case, if the ID is the same 
(the RBridge ID), the link will split into two separate trees near the 
equal cost point if that is possible (at least a bridge exists between 
RBridge ports) to balance the cost of link connected to each of the root 
bridge ports, or by any of the standard tie breaking mechanisms like 
port ID if no there is no bridge interposed.
Regards
Guillermo
Radia Perlman escribi?:
> I hesitate to bring this up because I don't want to reintroduce 
> confusion about
> "participating" in bridge spanning tree algorithm. So, please---what I'm
> about to propose does NOT merge links. Bridged links still terminate at 
> an RBridge.
>
> The issue is that it can be unpleasant for two RBridges to 
> simultaneously think they
> are both Designated on the same link, which can happen if a bridge came up
> and connected two links. Or for that matter, a repeater.
>
> One way of making sure that a situation like that resolves very quickly,
> and absolutely, is to have RBridges act like bridges on each of their ports,
> with numerically lowest (i.e., highest) priority for become Root.
>
> Now---I DO NOT MEAN that an RBridge merges the spanning trees on each of 
> its ports.
> The spanning tree is terminated at an RBridge. If an RBridge has 4 
> ports, it will
> participate in 4 independent bridge spanning tree instances.
>
> The advantage of doing this is that we could make the Root bridge be the 
> Designated
> RBridge. Then if two RBridge links merged, the RBridges would notice 
> immediately.
> If you get usurped as bridge Root, you are also usurped as RBridge 
> Designated RBridge.
>
> Since the bridge spanning tree messages are never delayed by 
> pre-forwarding delays,
> this seems like it might be a nice thing to do.
>
> It would be nice if the same RBridge that would get elected Desiganted 
> RBridge in
> the IS-IS link election would be elected bridge Root on that link. The 
> easiest thing
> would be not to bother with IS-IS priority, and have them all have the 
> same priority,
> with election being solely on ID. Then they can all use the lowest 
> bridge root priority,
> and the same RBridge would get elected bridge root on the link as would get
> elected Designated RBridge on the link.
>
> Radia
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   


Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6MqIQd012971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 6 Nov 2006 14:52:18 -0800 (PST)
Received: from [75.214.91.246] (246.sub-75-214-91.myvzw.com [75.214.91.246]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kA6MoqYQ013004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Nov 2006 14:50:58 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 06 Nov 2006 14:50:50 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB5E0093D85301953B4916C33"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] A thought about TTLs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 22:53:14 -0000
Status: RO
Content-Length: 3238

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



Gray, Eric wrote:
> Joe,
>=20
> 	For the unicast case, it need not be.=20

Agreed.

> Reasons why it should
> be different in the flooded, broadcast and multicast case are - I
> believe - fairly obvious, since these behaviors are ditinctly not
> the same in these cases.

Yes; they're used for scoping. I'm not clear on why scoping comes into
play here, though - there's never a time we want to do
multicast/broadcast that doesn't reach the edge, and no penalty
(excepting w.r.t. looping) for overreaching. I.e., it has no equivalent
case here.
> 	Also, even in the IP case, there has been discussion in the
> past about the advantages of TTL reduction for tunneled traffic.

Much of what I've heard of there has been used for "security" (heavy
emphasis on the quotes) for tunneled BGP traffic. Is there another case,
 or are you referring to that?

Joe

>=20
> --
> Eric=20
>=20
> --> -----Original Message-----
> --> From: Joe Touch [mailto:[e-mail]]=20
> --> Sent: Monday, November 06, 2006 5:36 PM
> --> To: Gray, Eric
> --> Cc: Eastlake III Donald-LDE008; [e-mail]
> --> Subject: Re: [rbridge] A thought about TTLs
> -->=20
> -->=20
> -->=20
> --> Gray, Eric wrote:
> --> > Joe,
> --> >=20
> --> > 	The protocol specification cannot be silent on the setting of
> --> > a value for TTL.  For one thing, any value less than the=20
> --> max, should
> --> > be compared with the expected number of hops as a sanity=20
> --> check - one
> --> > way or another (meaning if the boxes don't do it, the=20
> --> user will have
> --> > to do it themselves).
> --> >=20
> --> > 	For example, if an implementer decided that 16 hops was the=20
> --> > most they could realistically expect to see in an RBridge=20
> --> CRED, they
> --> > might set it to 16.  If it subsequently turns out that a=20
> --> network is=20
> --> > larger than they expected, I sincerely hope that they made this a=

> --> > configurable value.  If there is going to be a need to configure =
a
> --> > value for this in most implementations, then we might as=20
> --> well say so
> --> > up front so that there is likely to be a standard MIB object that=

> --> > corresponds to this value.
> --> >=20
> --> > 	Clearly the simplest thing to do, therefore, is to set TTL to
> --> > the maximum possible value.  Simple, but probably not sane.
> -->=20
> --> Why is/should it be different than in an IP network?
> -->=20
> --> Joe
> -->=20
> -->=20

--=20
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment


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

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

iD8DBQFFT7xKE5f5cImnZrsRAlc6AJ9F3kQNq7YvdDMogA1/TtFXxsBbKACfQLL8
m9TJFg64OAidBW2u0dAiDc0=
=zZEd
-----END PGP SIGNATURE-----

--------------enigB5E0093D85301953B4916C33--


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6Mk2r5010852 for <[e-mail]>; Mon, 6 Nov 2006 14:46:02 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA6Mj5fK022178; Mon, 6 Nov 2006 17:45:06 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA27111;  Mon, 6 Nov 2006 17:45:05 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB649PF6>; Mon, 6 Nov 2006 17:45:04 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: [e-mail], "Sanjay Sane (sanjays)" <[e-mail]>
Date: Mon, 6 Nov 2006 17:45:04 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA6Mk2r5010852
Cc: [e-mail], Gideon Kaempfer <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 22:46:24 -0000
Status: RO
Content-Length: 15241

Pierre,

	The "?loop problem" is apparently an issue with some devices where
reasonable forwarding behavior limitations have been "optimized out."  A
better way to handle the ?loop problem with RBridges is not to optimize
out the behavior that prevents it - i.e. - a prohibition against emitting
a frame on the same interface on which it was received.

	To be clear, at either the last IETF meeting, or the one just before
that one, it was made fairly clear that the ?loop problem occurs when a
device sends a PDU out of the same interface on which it was received. In 
comparison with simply dropping such a PDU, this behavior is pathological
- particularly in the case of L2 forwarding generally.

	I am not saying that we do not need ordered FIB for loop prevention
generally, but we should not need it for the ?loop problem.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Pierre Francois
--> Sent: Monday, November 06, 2006 5:20 PM
--> To: Sanjay Sane (sanjays)
--> Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
--> Subject: Re: [rbridge] Traffic storms
--> 
--> 
--> Sanjay,
--> 
--> Sanjay Sane (sanjays) wrote:
--> > Pierre,
--> >
--> > After reading through this paper, it seems the oFIB 
--> mechanism is suited
--> > towards unicast traffic, or a single-destination traffic. 
--> >
--> > In TRILL, if the plan is to protect the traffic storms, we *must*
--> > protect the transient loops in the "trees" that are built to carry
--> > unknowns/floods, multicast as well as unicast. Such 
--> traffic is targetted
--> > towards multiple destination, in fact, a tree extends to all the
--> > rbridges. 
--> >
--> > After thinking a bit, if we think of extending the 
--> mechanisms in the
--> > paper to cover "trees", we may have to delay the FIB 
--> ordering on all the
--> > links that are part of the tree on any given rbridge. 
--> This could be very
--> > inefficient. Do you think the oFIB mechanism would be 
--> suitable for such
--> > trees?
--> >   
--> 
--> Applying an "oFIB-like" solution for multicast traffic is 
--> something we 
--> are working on.
--> So, you can make ofib suitable for multicast trees, but we 
--> intend to 
--> modify it for efficiency purposes.
--> btw, you already face the ?loop problem for unicast 
--> traffic, and there 
--> oFIB can be applied as-is by rbridges..
--> 
--> Pierre.
--> > -Sanjay 
--> >
--> >  
--> >
--> > -----Original Message-----
--> > From: [e-mail] 
--> [mailto:[e-mail]] On
--> > Behalf Of Pierre Francois
--> > Sent: Friday, November 03, 2006 5:10 PM
--> > To: Silvano Gai
--> > Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
--> > Subject: Re: [rbridge] Traffic storms
--> >
--> >
--> > Silvano,
--> >
--> > See
--> > 
--> http://www.ietf.org/internet-drafts/draft-francois-ordered-f
--> ib-02.txt,
--> > for a loop avoidance mechanism for IS-IS/OSPF.
--> >
--> > See you in SD,
--> >
--> > Pierre.
--> >
--> >
--> >
--> > On Fri, 3 Nov 2006, Silvano Gai wrote:
--> >
--> >   
--> >> Eric,
--> >>
--> >> Also I suggest that people that have solved the problem 
--> of having a 
--> >> loop free topology using ISIS, submit proposasl so that 
--> we can compare
--> >>     
--> > them.
--> >   
--> >> Unfortunately I don't have one.
--> >>
--> >>
--> >>
--> >> -- Silvano
--> >>
--> >>
--> >>
--> >> ________________________________
--> >>
--> >> From: [e-mail] 
--> [mailto:[e-mail]] 
--> >> On Behalf Of Gray, Eric
--> >> Sent: Friday, November 03, 2006 11:54 AM
--> >> To: Gideon Kaempfer; Radia Perlman
--> >> Cc: [e-mail]
--> >> Subject: Re: [rbridge] Traffic storms
--> >>
--> >>
--> >>
--> >> Gideon,
--> >>
--> >>
--> >>
--> >>     "Drop BPDUs" is not (exactly) the same as ignore 
--> them.  We use the
--> >>     
--> >
--> >   
--> >> term
--> >>
--> >> as short-hand for the one of three options we considered 
--> for handling
--> >> BPDUs:
--> >>
--> >>
--> >>
--> >>     Drop (do not participate actively in STP, and do not 
--> pass BPDUs 
--> >> through),
--> >>
--> >>     Transparent (pass BPDUs through - potentially 
--> altering them in 
--> >> some way),
--> >>
--> >>     Participate (have each RBridge participate in STP as 
--> if it were a 
--> >> bridge).
--> >>
--> >>
--> >>
--> >> Hence, when we say "Drop BPDUs" we are not saying that 
--> we cannot look
--> >>
--> >> at them, we are just saying that we're not doing one of 
--> the other two 
--> >> choices.
--> >>
--> >>
--> >>
--> >> --
--> >>
--> >> Eric
--> >>
--> >>
--> >>
--> >>
--> >> ________________________________
--> >>
--> >>
--> >> 	From: [e-mail]
--> >> [mailto:[e-mail]] On Behalf Of Gideon Kaempfer
--> >> 	Sent: Friday, November 03, 2006 1:40 AM
--> >> 	To: Radia Perlman
--> >> 	Cc: [e-mail]
--> >> 	Subject: Re: [rbridge] Traffic storms
--> >>
--> >> 	Radia,
--> >>
--> >> 	Wouldn't this create a link between TRILL and STP we are trying
--> >>     
--> > to 
--> >   
--> >> avoid?
--> >>
--> >> 	Relying on the fact that a LAN segment has some kind of unique 
--> >> identifier (such as the root bridge ID) seems like a 
--> very practical 
--> >> solution to me, but strongly reliant on the fact that 
--> the Rbridges 
--> >> actually process BPDUs. I thought they were just meant to discard
--> >>     
--> > them.
--> >   
--> >> Is this acceptable?
--> >>
--> >> 	Regrads,
--> >>
--> >> 	 Gidi
--> >>
--> >>
--> >>
--> >> 	On 11/3/06, Radia Perlman <[e-mail]> wrote:
--> >>
--> >> 	The simplest way to put it, I think, is that in certain
--> >>     
--> > transitory
--> >   
--> >> 	situations there might be two
--> >> 	RBridges that both think they are Designated RBridge, and that
--> >>     
--> > is 
--> >   
--> >> bad,
--> >> 	but should stop
--> >> 	as soon as a single Hello is received by the RBridge who should
--> >>     
--> > not 
--> >   
--> >> be
--> >> 	Designated.
--> >>
--> >> 	I think PIM has similar transitory situations that can occur,
--> >>     
--> > and
--> >   
--> >> 	bridges can also have (hopefully
--> >> 	temporary) problems if a repeater came up and merged two LANs. I
--> >>     
--> >
--> >   
--> >> think
--> >> 	such things are
--> >> 	annoying but not fatal. But I think it's possible we can with
--> >>     
--> > little
--> >   
--> >> 	effort avoid this problem.
--> >>
--> >> 	However, with RBridges, because the bridge spanning tree
--> >>     
--> > algorithm
--> >   
--> >> 	elects a Root, there's
--> >> 	really a way of uniquely identifying a LAN (where "LAN" is a
--> >>     
--> > bunch of
--> >   
--> >> 	links connected with
--> >> 	bridges). The unique identifier is the root bridge.
--> >>
--> >> 	When the B1-B2 link is down, RB1 and RB2 will see the topology
--> >>     
--> > as two
--> >   
--> >> 	separate links, and each
--> >> 	one will have a distinct spanning tree Root bridge (RB1 will see
--> >>     
--> > B1, 
--> >   
--> >> and
--> >> 	RB2 will see B2 as the root).
--> >>
--> >> 	When the B1-B2 link comes up, the bridges will first merge the
--> >>     
--> > two
--> >   
--> >> 	links, and either RB1 or RB2 will
--> >> 	see that the bridge spanning tree root has changed. This will be
--> >> 	discovered before B1 and B2 forward
--> >> 	traffic across the link because of the bridge forwarding delay.
--> >> 	If B1 has better priority as bridge spanning tree root than B2,
--> >>     
--> > then 
--> >   
--> >> RB1
--> >> 	will not notice anything
--> >> 	different when the B1-B2 link comes up. But RB2 will notice
--> >> 	something different; the spanning tree root has changed
--> >>     
--> > identities 
--> >   
--> >> from
--> >> 	"B2" to "B1".
--> >>
--> >> 	Given this, RB2 could temporarily stop forwarding to or from the
--> >>     
--> > link
--> >   
--> >> 	when the Root bridge
--> >> 	changes identities, though it should definitely immediately send
--> >>     
--> >
--> >   
--> >> IS-IS
--> >> 	Hellos (either RB1 or RB2 will
--> >> 	be elected Designated Router in the IS-IS election for that
--> >>     
--> > link). If
--> >   
--> >> 	RB2 has better prioirty for
--> >> 	root, the RB1 will immediately stop forwarding to or from the
--> >>     
--> > link 
--> >   
--> >> when
--> >> 	it sees the Hello from RB2.
--> >> 	If RB2 has better priority in the IS-IS election, then RB1
--> >>     
--> > should
--> >   
--> >> 	immediately send an IS-IS Hello
--> >> 	when it sees a Hello from a new RBridge on the link.
--> >>
--> >> 	So I think this is not a big deal, and that if we are worried,
--> >>     
--> > we can
--> >   
--> >> 	specify that an RBridge should
--> >> 	stop acting like the Designated RBridge for a few seconds after
--> >>     
--> > the
--> >   
--> >> 	identity of the Root in the spanning
--> >> 	tree algorithm changes.
--> >>
--> >> 	Or we could be even fancier and have each RBridge announce in
--> >>     
--> > its 
--> >   
--> >> IS-IS
--> >> 	Hellos which LAN IDs it
--> >> 	is Designated for, where a LAN ID is the MAC address of the Root
--> >>     
--> >
--> >   
--> >> bridge.
--> >> 	So RB1 continue
--> >> 	forwarding if the identity changes from B1 to B2 provided no
--> >>     
--> > other
--> >   
--> >> 	RBridge has claimed to be connected
--> >> 	to B2. But if RB2's LSP claims it is attached to B2, then RB1
--> >>     
--> > must 
--> >   
--> >> stop
--> >> 	forwarding for enough time
--> >> 	for the IS-IS election to sort itself out and choose a
--> >>     
--> > Designated 
--> >   
--> >> RBridge.
--> >>
--> >> 	Radia
--> >>
--> >>
--> >>
--> >>
--> >>
--> >>
--> >> 	Gideon Kaempfer wrote:
--> >>
--> >> 	>Following mention by Silvano of broadcast and multicast storms
--> >>     
--> > (and 
--> >   
--> >> the need
--> >> 	>to protect against them), I played around with different
--> >>     
--> > scenarios 
--> >   
--> >> and came
--> >> 	>upon one I would appreciate your comments on (in the hope I am 
--> >> pointing out
--> >> 	>a non-existent issue with TRILL). I believe a broadcast and
--> >>     
--> > even a 
--> >   
--> >> unicast
--> >> 	>storm could be created as the result of a loop that isn't
--> >>     
--> > protected 
--> >   
--> >> by TTL
--> >> 	>nor by STP in the case of a link connecting two separate LAN 
--> >> segments coming
--> >> 	>to life.
--> >> 	>
--> >> 	>- RB1 ---- RB2 -
--> >> 	>   |        |
--> >> 	>-  B1 --x-- B2 -
--> >> 	>   |        |
--> >> 	>   H1       H2
--> >> 	>
--> >> 	>1. The network (segment) involved consists of two Rbridges
--> >>     
--> > (RB1, 
--> >   
--> >> RB2), two
--> >> 	>bridges (B1, B2) and two hosts (H1, H2). They are physically 
--> >> connected as
--> >> 	>depicted.
--> >> 	>2. State A: the direct link between B1 and B2 is down. B1 and
--> >> B2 find
--> >> 	>themselves on different LAN segments and hence different
--> >>     
--> > spanning 
--> >   
--> >> trees. RB1
--> >> 	>and RB2 are both designated Rbridges (each for the segment of
--> >>     
--> > the
--> >   
--> >> 	>corresponding bridge).
--> >> 	>3. State B: the direct link between B1 and B2 goes up (someone 
--> >> connects a
--> >> 	>cable). B1 and B2 discover each other and establish a common 
--> >> spanning tree.
--> >> 	>RB1 and RB2 both find themselves attached to the same LAN
--> >>     
--> > segment 
--> >   
--> >> and hence
--> >> 	>RB1 (without loss of generality) will eventually become the 
--> >> designated
--> >> 	>Rbridge for it.
--> >> 	>4. Just before RB1 and RB2 identify that they are both on the
--> >>     
--> > same 
--> >   
--> >> segment
--> >> 	>and RB2 stops functioning as a designated Rbridge the following
--> >>     
--> >
--> >   
--> >> scenario
--> >> 	>seems possible:
--> >> 	>  a. H1 sends a broadcast frame.
--> >> 	>  b. B1 receives it and forwards to RB1 and B2.
--> >> 	>  c. RB1 (encapsulates and) forwards to RB2.
--> >> 	>  d. B2 forwards to RB2 and H2.
--> >> 	>  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2
--> >>     
--> > to 
--> >   
--> >> RB1).
--> >> 	>  f. (RB1 forwards to B1.)
--> >> 	>  g. B2 forwards (again) to H2 and to B1.
--> >> 	>  h. B1 forwards to H1 (see remark below regarding filtering
--> >>     
--> > table
--> >   
--> >> 	>contamination) and to RB1.
--> >> 	>  i. Etcetera etcetera.
--> >> 	>5. A broadcast storm is born, created by a loop that is not 
--> >> protected by TTL
--> >> 	>(due to the fact that forwarding between the Rbridges is only
--> >>     
--> > across 
--> >   
--> >> a
--> >> 	>single hop) nor by STP (due to the fact that Rbridges do not 
--> >> participate in
--> >> 	>STP).
--> >> 	>6. If forwarding commences at the hardware level and no
--> >>     
--> > broadcast 
--> >   
--> >> rate
--> >> 	>limiting is in place, the storm may cause severe damage in a
--> >>     
--> > very 
--> >   
--> >> short time
--> >> 	>(note that replicated frames are sent to H1 and H2 (or any
--> >>     
--> > network 
--> >   
--> >> they
--> >> 	>could represent).
--> >> 	>7. Another unfortunate effect of this storm is that B1 and B2
--> >>     
--> > no 
--> >   
--> >> longer know
--> >> 	>where H1 is located (due to the contamination of their
--> >>     
--> > filtering 
--> >   
--> >> tables by a
--> >> 	>frame from H1 that arrives from the wrong direction (and in
--> >>     
--> > fact 
--> >   
--> >> from
--> >> 	>multiple directions). As a result, a possible unicast frame
--> >>     
--> > from H2 
--> >   
--> >> to H1
--> >> 	>will just join the storm over the loop at least in one
--> >>     
--> > direction 
--> >   
--> >> (RB2 will
--> >> 	>forward it to RB1) but will not arrive at H1...
--> >> 	>
--> >> 	>One possible solution could be for RB2 to identify the fact
--> >>     
--> > that it 
--> >   
--> >> is
--> >> 	>receiving a frame from a host with a MAC address that is
--> >>     
--> > associated 
--> >   
--> >> with a
--> >> 	>segment it thought it isn't connected to. Hence, it may trigger
--> >>     
--> > an 
--> >   
--> >> immediate
--> >> 	>neighbor discovery / designated Rbridge election. However,
--> >>     
--> > because 
--> >   
--> >> Rbridges
--> >> 	>should allow host mobility, this frame may need to be forwarded
--> >>     
--> > (and 
--> >   
--> >> hence
--> >> 	>the storm commences).
--> >> 	>
--> >> 	>As mentioned above, any comments are welcome.
--> >> 	>  Gideon Kaempfer
--> >> 	>
--> >> 	>_______________________________________________
--> >> 	>rbridge mailing list
--> >> 	>[e-mail]
--> >> 	> http://mailman.postel.org/mailman/listinfo/rbridge
--> >> <http://mailman.postel.org/mailman/listinfo/rbridge>
--> >> 	>
--> >> 	>
--> >>
--> >> 	_______________________________________________
--> >> 	rbridge mailing list
--> >> 	[e-mail]
--> >> 	http://mailman.postel.org/mailman/listinfo/rbridge
--> >>
--> >>
--> >>
--> >>
--> >>     
--> > _______________________________________________
--> > rbridge mailing list
--> > [e-mail]
--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> >
--> >   
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6MfdxD009030 for <[e-mail]>; Mon, 6 Nov 2006 14:41:40 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA6MfZfK022144; Mon, 6 Nov 2006 17:41:35 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA26965;  Mon, 6 Nov 2006 17:41:35 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB649P15>; Mon, 6 Nov 2006 17:41:34 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Joe Touch <[e-mail]>, "Gray, Eric" <[e-mail]>
Date: Mon, 6 Nov 2006 17:41:34 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] A thought about TTLs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 22:42:02 -0000
Status: RO
Content-Length: 1788

Joe,

	For the unicast case, it need not be.  Reasons why it should
be different in the flooded, broadcast and multicast case are - I
believe - fairly obvious, since these behaviors are ditinctly not
the same in these cases.

	Also, even in the IP case, there has been discussion in the
past about the advantages of TTL reduction for tunneled traffic.

--
Eric 

--> -----Original Message-----
--> From: Joe Touch [mailto:[e-mail]] 
--> Sent: Monday, November 06, 2006 5:36 PM
--> To: Gray, Eric
--> Cc: Eastlake III Donald-LDE008; [e-mail]
--> Subject: Re: [rbridge] A thought about TTLs
--> 
--> 
--> 
--> Gray, Eric wrote:
--> > Joe,
--> > 
--> > 	The protocol specification cannot be silent on the setting of
--> > a value for TTL.  For one thing, any value less than the 
--> max, should
--> > be compared with the expected number of hops as a sanity 
--> check - one
--> > way or another (meaning if the boxes don't do it, the 
--> user will have
--> > to do it themselves).
--> > 
--> > 	For example, if an implementer decided that 16 hops was the 
--> > most they could realistically expect to see in an RBridge 
--> CRED, they
--> > might set it to 16.  If it subsequently turns out that a 
--> network is 
--> > larger than they expected, I sincerely hope that they made this a
--> > configurable value.  If there is going to be a need to configure a
--> > value for this in most implementations, then we might as 
--> well say so
--> > up front so that there is likely to be a standard MIB object that
--> > corresponds to this value.
--> > 
--> > 	Clearly the simplest thing to do, therefore, is to set TTL to
--> > the maximum possible value.  Simple, but probably not sane.
--> 
--> Why is/should it be different than in an IP network?
--> 
--> Joe
--> 
--> 


Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6MarK4007295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 6 Nov 2006 14:36:54 -0800 (PST)
Received: from [75.214.91.246] (246.sub-75-214-91.myvzw.com [75.214.91.246]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kA6MaFfp009656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Nov 2006 14:36:18 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 06 Nov 2006 14:36:14 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig567DB5B99A5C5175F1F3FF50"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] A thought about TTLs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 22:37:32 -0000
Status: RO
Content-Length: 1746

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



Gray, Eric wrote:
> Joe,
>=20
> 	The protocol specification cannot be silent on the setting of
> a value for TTL.  For one thing, any value less than the max, should
> be compared with the expected number of hops as a sanity check - one
> way or another (meaning if the boxes don't do it, the user will have
> to do it themselves).
>=20
> 	For example, if an implementer decided that 16 hops was the=20
> most they could realistically expect to see in an RBridge CRED, they
> might set it to 16.  If it subsequently turns out that a network is=20
> larger than they expected, I sincerely hope that they made this a
> configurable value.  If there is going to be a need to configure a
> value for this in most implementations, then we might as well say so
> up front so that there is likely to be a standard MIB object that
> corresponds to this value.
>=20
> 	Clearly the simplest thing to do, therefore, is to set TTL to
> the maximum possible value.  Simple, but probably not sane.

Why is/should it be different than in an IP network?

Joe


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

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

iD8DBQFFT7jeE5f5cImnZrsRAq32AJwLf/yGSa4O5Pkyj+PueRrhenPOfwCfXtY6
HIOTjVGqK0WxuZaTZlQoOdE=
=8JYH
-----END PGP SIGNATURE-----

--------------enig567DB5B99A5C5175F1F3FF50--


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6MU68C004767 for <[e-mail]>; Mon, 6 Nov 2006 14:30:06 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA6MU3fK021979; Mon, 6 Nov 2006 17:30:03 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA26288;  Mon, 6 Nov 2006 17:30:03 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB64930Z>; Mon, 6 Nov 2006 17:30:01 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Joe Touch <[e-mail]>
Date: Mon, 6 Nov 2006 17:30:01 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] A thought about TTLs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 22:30:27 -0000
Status: RO
Content-Length: 3777

Joe,

	The protocol specification cannot be silent on the setting of
a value for TTL.  For one thing, any value less than the max, should
be compared with the expected number of hops as a sanity check - one
way or another (meaning if the boxes don't do it, the user will have
to do it themselves).

	For example, if an implementer decided that 16 hops was the 
most they could realistically expect to see in an RBridge CRED, they
might set it to 16.  If it subsequently turns out that a network is 
larger than they expected, I sincerely hope that they made this a
configurable value.  If there is going to be a need to configure a
value for this in most implementations, then we might as well say so
up front so that there is likely to be a standard MIB object that
corresponds to this value.

	Clearly the simplest thing to do, therefore, is to set TTL to
the maximum possible value.  Simple, but probably not sane.

--
Eric

--> -----Original Message-----
--> From: Joe Touch [mailto:[e-mail]] 
--> Sent: Monday, November 06, 2006 5:12 PM
--> To: Gray, Eric
--> Cc: Eastlake III Donald-LDE008; [e-mail]
--> Subject: Re: [rbridge] A thought about TTLs
--> 
--> That argument holds as well for packets in the Internet. 
--> There are two
--> cases:
--> 
--> 	1- loops are common, and we want to reduce the looped traffic
--> 
--> 	2- loops are not common, and we want to reduce effort in
--> 	predicting the expected TTL
--> 
--> I sincerely hope that 2 is what we're designing for.
--> 
--> As to 1, if a vendor wants that as value added, that's 
--> fine. But I would
--> not encourage the WG to endorse that approach as an 
--> optimization, since
--> if (when) it fails it has more substantial consequences than longer
--> loops, since legitimate traffic will be silently dropped even when
--> routing is correct. If a vendor wants to take that risk, 
--> that's fine,
--> but the WG shouldn't engineer a spec for it, IMO.
--> 
--> Joe
--> 
--> Gray, Eric wrote:
--> > Joe,
--> > 
--> > 	I tend to agree with Donald's comments (which are not 
--> included here,
--> > because of the difficulty I have in responding to your 
--> mail generally).
--> > 
--> > 	To your point, it might be possible for RBridges to use 
--> some factor
--> > (such as +2 hops, or *2 hops) over the actual expected 
--> tunnel length, but
--> > it is unreasonable to use any number much larger than 
--> that for the purpose
--> > preserving frames that are taking some tortuous, but not 
--> looping, path in
--> > a changing network.
--> > 
--> > --
--> > Eric
--> > 
--> > Earlier, you said:
--> > --> The whole point of a TTL is that things could change 
--> en-route, which
--> > --> means that a rbridge might want to scope the TTL 
--> down, but this could
--> > --> end up dropping a packet that would have had a 
--> legitimate, nonlooping
--> > --> path that's unexpectedly longer later.
--> > --> 
--> > --> IMO, let the TTL be what it is - loop prevention for 
--> unicast, and
--> > --> diameter scope for broad/multicast. Don't try to 
--> overthink it beyond
--> > that.
--> > --> 
--> > --> Joe
--> > 
--> > --> -----Original Message-----
--> > --> From: [e-mail] 
--> > --> [mailto:[e-mail]] On Behalf Of Joe Touch
--> > --> Sent: Monday, November 06, 2006 1:32 AM
--> > --> To: Eastlake III Donald-LDE008
--> > --> Cc: [e-mail]
--> > --> Subject: Re: [rbridge] A thought about TTLs
--> > --> 
--> > --> _______________________________________________
--> > --> rbridge mailing list
--> > --> [e-mail]
--> > --> http://mailman.postel.org/mailman/listinfo/rbridge
--> > --> 
--> 
--> -- 
--> ----------------------------------------
--> Joe Touch
--> Sr. Network Engineer, USAF TSAT Space Segment
--> 
--> 


Received: from smtp-1.dynsipr.ucl.ac.be (smtp-1.dynsipr.ucl.ac.be [130.104.4.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6MJv73001329 for <[e-mail]>; Mon, 6 Nov 2006 14:19:57 -0800 (PST)
Received: from smtp-1.dynsipr.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp-1.dynsipr.ucl.ac.be (Postfix) with ESMTP id 80E892C3CF; Mon,  6 Nov 2006 23:19:53 +0100 (CET)
Received: from [130.129.68.111] (dhcp68-111.ietf67.org [130.129.68.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: [e-mail]) by smtp-1.dynsipr.ucl.ac.be (Postfix) with ESMTP; Mon,  6 Nov 2006 23:19:53 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 06 Nov 2006 14:19:35 -0800
From: Pierre Francois <[e-mail]>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: "Sanjay Sane (sanjays)" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-AV-Checked: ClamAV using ClamSMTP
X-SGSI-MailScanner: Found to be clean
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Gideon Kaempfer <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail]
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 22:20:23 -0000
Status: RO
Content-Length: 11731

Sanjay,

Sanjay Sane (sanjays) wrote:
> Pierre,
>
> After reading through this paper, it seems the oFIB mechanism is suited
> towards unicast traffic, or a single-destination traffic. 
>
> In TRILL, if the plan is to protect the traffic storms, we *must*
> protect the transient loops in the "trees" that are built to carry
> unknowns/floods, multicast as well as unicast. Such traffic is targetted
> towards multiple destination, in fact, a tree extends to all the
> rbridges. 
>
> After thinking a bit, if we think of extending the mechanisms in the
> paper to cover "trees", we may have to delay the FIB ordering on all the
> links that are part of the tree on any given rbridge. This could be very
> inefficient. Do you think the oFIB mechanism would be suitable for such
> trees?
>   

Applying an "oFIB-like" solution for multicast traffic is something we 
are working on.
So, you can make ofib suitable for multicast trees, but we intend to 
modify it for efficiency purposes.
btw, you already face the ?loop problem for unicast traffic, and there 
oFIB can be applied as-is by rbridges..

Pierre.
> -Sanjay 
>
>  
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Pierre Francois
> Sent: Friday, November 03, 2006 5:10 PM
> To: Silvano Gai
> Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
> Subject: Re: [rbridge] Traffic storms
>
>
> Silvano,
>
> See
> http://www.ietf.org/internet-drafts/draft-francois-ordered-fib-02.txt,
> for a loop avoidance mechanism for IS-IS/OSPF.
>
> See you in SD,
>
> Pierre.
>
>
>
> On Fri, 3 Nov 2006, Silvano Gai wrote:
>
>   
>> Eric,
>>
>> Also I suggest that people that have solved the problem of having a 
>> loop free topology using ISIS, submit proposasl so that we can compare
>>     
> them.
>   
>> Unfortunately I don't have one.
>>
>>
>>
>> -- Silvano
>>
>>
>>
>> ________________________________
>>
>> From: [e-mail] [mailto:[e-mail]] 
>> On Behalf Of Gray, Eric
>> Sent: Friday, November 03, 2006 11:54 AM
>> To: Gideon Kaempfer; Radia Perlman
>> Cc: [e-mail]
>> Subject: Re: [rbridge] Traffic storms
>>
>>
>>
>> Gideon,
>>
>>
>>
>>     "Drop BPDUs" is not (exactly) the same as ignore them.  We use the
>>     
>
>   
>> term
>>
>> as short-hand for the one of three options we considered for handling
>> BPDUs:
>>
>>
>>
>>     Drop (do not participate actively in STP, and do not pass BPDUs 
>> through),
>>
>>     Transparent (pass BPDUs through - potentially altering them in 
>> some way),
>>
>>     Participate (have each RBridge participate in STP as if it were a 
>> bridge).
>>
>>
>>
>> Hence, when we say "Drop BPDUs" we are not saying that we cannot look
>>
>> at them, we are just saying that we're not doing one of the other two 
>> choices.
>>
>>
>>
>> --
>>
>> Eric
>>
>>
>>
>>
>> ________________________________
>>
>>
>> 	From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Gideon Kaempfer
>> 	Sent: Friday, November 03, 2006 1:40 AM
>> 	To: Radia Perlman
>> 	Cc: [e-mail]
>> 	Subject: Re: [rbridge] Traffic storms
>>
>> 	Radia,
>>
>> 	Wouldn't this create a link between TRILL and STP we are trying
>>     
> to 
>   
>> avoid?
>>
>> 	Relying on the fact that a LAN segment has some kind of unique 
>> identifier (such as the root bridge ID) seems like a very practical 
>> solution to me, but strongly reliant on the fact that the Rbridges 
>> actually process BPDUs. I thought they were just meant to discard
>>     
> them.
>   
>> Is this acceptable?
>>
>> 	Regrads,
>>
>> 	 Gidi
>>
>>
>>
>> 	On 11/3/06, Radia Perlman <[e-mail]> wrote:
>>
>> 	The simplest way to put it, I think, is that in certain
>>     
> transitory
>   
>> 	situations there might be two
>> 	RBridges that both think they are Designated RBridge, and that
>>     
> is 
>   
>> bad,
>> 	but should stop
>> 	as soon as a single Hello is received by the RBridge who should
>>     
> not 
>   
>> be
>> 	Designated.
>>
>> 	I think PIM has similar transitory situations that can occur,
>>     
> and
>   
>> 	bridges can also have (hopefully
>> 	temporary) problems if a repeater came up and merged two LANs. I
>>     
>
>   
>> think
>> 	such things are
>> 	annoying but not fatal. But I think it's possible we can with
>>     
> little
>   
>> 	effort avoid this problem.
>>
>> 	However, with RBridges, because the bridge spanning tree
>>     
> algorithm
>   
>> 	elects a Root, there's
>> 	really a way of uniquely identifying a LAN (where "LAN" is a
>>     
> bunch of
>   
>> 	links connected with
>> 	bridges). The unique identifier is the root bridge.
>>
>> 	When the B1-B2 link is down, RB1 and RB2 will see the topology
>>     
> as two
>   
>> 	separate links, and each
>> 	one will have a distinct spanning tree Root bridge (RB1 will see
>>     
> B1, 
>   
>> and
>> 	RB2 will see B2 as the root).
>>
>> 	When the B1-B2 link comes up, the bridges will first merge the
>>     
> two
>   
>> 	links, and either RB1 or RB2 will
>> 	see that the bridge spanning tree root has changed. This will be
>> 	discovered before B1 and B2 forward
>> 	traffic across the link because of the bridge forwarding delay.
>> 	If B1 has better priority as bridge spanning tree root than B2,
>>     
> then 
>   
>> RB1
>> 	will not notice anything
>> 	different when the B1-B2 link comes up. But RB2 will notice
>> 	something different; the spanning tree root has changed
>>     
> identities 
>   
>> from
>> 	"B2" to "B1".
>>
>> 	Given this, RB2 could temporarily stop forwarding to or from the
>>     
> link
>   
>> 	when the Root bridge
>> 	changes identities, though it should definitely immediately send
>>     
>
>   
>> IS-IS
>> 	Hellos (either RB1 or RB2 will
>> 	be elected Designated Router in the IS-IS election for that
>>     
> link). If
>   
>> 	RB2 has better prioirty for
>> 	root, the RB1 will immediately stop forwarding to or from the
>>     
> link 
>   
>> when
>> 	it sees the Hello from RB2.
>> 	If RB2 has better priority in the IS-IS election, then RB1
>>     
> should
>   
>> 	immediately send an IS-IS Hello
>> 	when it sees a Hello from a new RBridge on the link.
>>
>> 	So I think this is not a big deal, and that if we are worried,
>>     
> we can
>   
>> 	specify that an RBridge should
>> 	stop acting like the Designated RBridge for a few seconds after
>>     
> the
>   
>> 	identity of the Root in the spanning
>> 	tree algorithm changes.
>>
>> 	Or we could be even fancier and have each RBridge announce in
>>     
> its 
>   
>> IS-IS
>> 	Hellos which LAN IDs it
>> 	is Designated for, where a LAN ID is the MAC address of the Root
>>     
>
>   
>> bridge.
>> 	So RB1 continue
>> 	forwarding if the identity changes from B1 to B2 provided no
>>     
> other
>   
>> 	RBridge has claimed to be connected
>> 	to B2. But if RB2's LSP claims it is attached to B2, then RB1
>>     
> must 
>   
>> stop
>> 	forwarding for enough time
>> 	for the IS-IS election to sort itself out and choose a
>>     
> Designated 
>   
>> RBridge.
>>
>> 	Radia
>>
>>
>>
>>
>>
>>
>> 	Gideon Kaempfer wrote:
>>
>> 	>Following mention by Silvano of broadcast and multicast storms
>>     
> (and 
>   
>> the need
>> 	>to protect against them), I played around with different
>>     
> scenarios 
>   
>> and came
>> 	>upon one I would appreciate your comments on (in the hope I am 
>> pointing out
>> 	>a non-existent issue with TRILL). I believe a broadcast and
>>     
> even a 
>   
>> unicast
>> 	>storm could be created as the result of a loop that isn't
>>     
> protected 
>   
>> by TTL
>> 	>nor by STP in the case of a link connecting two separate LAN 
>> segments coming
>> 	>to life.
>> 	>
>> 	>- RB1 ---- RB2 -
>> 	>   |        |
>> 	>-  B1 --x-- B2 -
>> 	>   |        |
>> 	>   H1       H2
>> 	>
>> 	>1. The network (segment) involved consists of two Rbridges
>>     
> (RB1, 
>   
>> RB2), two
>> 	>bridges (B1, B2) and two hosts (H1, H2). They are physically 
>> connected as
>> 	>depicted.
>> 	>2. State A: the direct link between B1 and B2 is down. B1 and
>> B2 find
>> 	>themselves on different LAN segments and hence different
>>     
> spanning 
>   
>> trees. RB1
>> 	>and RB2 are both designated Rbridges (each for the segment of
>>     
> the
>   
>> 	>corresponding bridge).
>> 	>3. State B: the direct link between B1 and B2 goes up (someone 
>> connects a
>> 	>cable). B1 and B2 discover each other and establish a common 
>> spanning tree.
>> 	>RB1 and RB2 both find themselves attached to the same LAN
>>     
> segment 
>   
>> and hence
>> 	>RB1 (without loss of generality) will eventually become the 
>> designated
>> 	>Rbridge for it.
>> 	>4. Just before RB1 and RB2 identify that they are both on the
>>     
> same 
>   
>> segment
>> 	>and RB2 stops functioning as a designated Rbridge the following
>>     
>
>   
>> scenario
>> 	>seems possible:
>> 	>  a. H1 sends a broadcast frame.
>> 	>  b. B1 receives it and forwards to RB1 and B2.
>> 	>  c. RB1 (encapsulates and) forwards to RB2.
>> 	>  d. B2 forwards to RB2 and H2.
>> 	>  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2
>>     
> to 
>   
>> RB1).
>> 	>  f. (RB1 forwards to B1.)
>> 	>  g. B2 forwards (again) to H2 and to B1.
>> 	>  h. B1 forwards to H1 (see remark below regarding filtering
>>     
> table
>   
>> 	>contamination) and to RB1.
>> 	>  i. Etcetera etcetera.
>> 	>5. A broadcast storm is born, created by a loop that is not 
>> protected by TTL
>> 	>(due to the fact that forwarding between the Rbridges is only
>>     
> across 
>   
>> a
>> 	>single hop) nor by STP (due to the fact that Rbridges do not 
>> participate in
>> 	>STP).
>> 	>6. If forwarding commences at the hardware level and no
>>     
> broadcast 
>   
>> rate
>> 	>limiting is in place, the storm may cause severe damage in a
>>     
> very 
>   
>> short time
>> 	>(note that replicated frames are sent to H1 and H2 (or any
>>     
> network 
>   
>> they
>> 	>could represent).
>> 	>7. Another unfortunate effect of this storm is that B1 and B2
>>     
> no 
>   
>> longer know
>> 	>where H1 is located (due to the contamination of their
>>     
> filtering 
>   
>> tables by a
>> 	>frame from H1 that arrives from the wrong direction (and in
>>     
> fact 
>   
>> from
>> 	>multiple directions). As a result, a possible unicast frame
>>     
> from H2 
>   
>> to H1
>> 	>will just join the storm over the loop at least in one
>>     
> direction 
>   
>> (RB2 will
>> 	>forward it to RB1) but will not arrive at H1...
>> 	>
>> 	>One possible solution could be for RB2 to identify the fact
>>     
> that it 
>   
>> is
>> 	>receiving a frame from a host with a MAC address that is
>>     
> associated 
>   
>> with a
>> 	>segment it thought it isn't connected to. Hence, it may trigger
>>     
> an 
>   
>> immediate
>> 	>neighbor discovery / designated Rbridge election. However,
>>     
> because 
>   
>> Rbridges
>> 	>should allow host mobility, this frame may need to be forwarded
>>     
> (and 
>   
>> hence
>> 	>the storm commences).
>> 	>
>> 	>As mentioned above, any comments are welcome.
>> 	>  Gideon Kaempfer
>> 	>
>> 	>_______________________________________________
>> 	>rbridge mailing list
>> 	>[e-mail]
>> 	> http://mailman.postel.org/mailman/listinfo/rbridge
>> <http://mailman.postel.org/mailman/listinfo/rbridge>
>> 	>
>> 	>
>>
>> 	_______________________________________________
>> 	rbridge mailing list
>> 	[e-mail]
>> 	http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>
>>
>>
>>     
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6MDOad028673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 6 Nov 2006 14:13:24 -0800 (PST)
Received: from [75.214.91.246] (246.sub-75-214-91.myvzw.com [75.214.91.246]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kA6MCDNY003045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Nov 2006 14:12:15 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 06 Nov 2006 14:12:11 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig56C06190C21DA7EC625BD003"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] A thought about TTLs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 22:14:07 -0000
Status: RO
Content-Length: 3001

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

That argument holds as well for packets in the Internet. There are two
cases:

	1- loops are common, and we want to reduce the looped traffic

	2- loops are not common, and we want to reduce effort in
	predicting the expected TTL

I sincerely hope that 2 is what we're designing for.

As to 1, if a vendor wants that as value added, that's fine. But I would
not encourage the WG to endorse that approach as an optimization, since
if (when) it fails it has more substantial consequences than longer
loops, since legitimate traffic will be silently dropped even when
routing is correct. If a vendor wants to take that risk, that's fine,
but the WG shouldn't engineer a spec for it, IMO.

Joe

Gray, Eric wrote:
> Joe,
>=20
> 	I tend to agree with Donald's comments (which are not included here,
> because of the difficulty I have in responding to your mail generally).=

>=20
> 	To your point, it might be possible for RBridges to use some factor
> (such as +2 hops, or *2 hops) over the actual expected tunnel length, b=
ut
> it is unreasonable to use any number much larger than that for the purp=
ose
> preserving frames that are taking some tortuous, but not looping, path =
in
> a changing network.
>=20
> --
> Eric
>=20
> Earlier, you said:
> --> The whole point of a TTL is that things could change en-route, whic=
h
> --> means that a rbridge might want to scope the TTL down, but this cou=
ld
> --> end up dropping a packet that would have had a legitimate, nonloopi=
ng
> --> path that's unexpectedly longer later.
> -->=20
> --> IMO, let the TTL be what it is - loop prevention for unicast, and
> --> diameter scope for broad/multicast. Don't try to overthink it beyon=
d
> that.
> -->=20
> --> Joe
>=20
> --> -----Original Message-----
> --> From: [e-mail]=20
> --> [mailto:[e-mail]] On Behalf Of Joe Touch
> --> Sent: Monday, November 06, 2006 1:32 AM
> --> To: Eastlake III Donald-LDE008
> --> Cc: [e-mail]
> --> Subject: Re: [rbridge] A thought about TTLs
> -->=20
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->=20

--=20
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment


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

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

iD8DBQFFT7M7E5f5cImnZrsRAvUMAJwOSUg63bSf/yoQ9znk970hq3r7bQCguhf0
8kS+5tWg1nItWlfOsW3xCU4=
=TbbG
-----END PGP SIGNATURE-----

--------------enig56C06190C21DA7EC625BD003--


Received: from stag.seas.upenn.edu (stag.seas.upenn.edu [158.130.70.79]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6JiHnX011307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 6 Nov 2006 11:44:18 -0800 (PST)
Received: from Abacas (MOR306-14.seas.upenn.edu [158.130.70.168]) (authenticated bits=0) by stag.seas.upenn.edu (8.13.6/8.13.6) with ESMTP id kA6JiHHK003613 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Mon, 6 Nov 2006 14:44:17 -0500
From: "Saikat Ray" <[e-mail]>
To: <[e-mail]>
Date: Mon, 6 Nov 2006 14:44:15 -0500
Organization: University of Pennsylvania
Message-ID: <004a01c701db$f40d81e0$a846829e@Abacas>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-Index: AccB2nYlVai75tTuQ4+Oo7212Rm0JQAAK/fw
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail]
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 19:44:47 -0000
Status: RO
Content-Length: 1047

> Radia,
> 
> 	I think I agree with this and would go further to make two
> additional comments/observations:
> 
> 	1) Unless it is possible to determine absolutely what cases
>          exist where RBridges can know that the link between them
>          actually is p2p (as opposed to looks like it is p2p), it
>          is risky to leave this sort of behavior as an unspecified
>          option.

Isn't it simple to test whether an RBridge A can send a packet to RBridge B
using the Shim header alone? Each of the RBridges can try sending a few test
packets without outer header; a received packet would trigger an ACK, again
without an outer header. If an RBridge gets an ACK (or ACKs to a few such
packets), then it can mark that neighbor as "directly connected". If there
are non-RBridge devise in between, then they will simply drop those
"unrecognizable" packets. The only issue would be making sure that such
"unrecognizable" packets do not trigger any undesirable behavior (e.g., they
do not resemble any non-RBridge control packets).



Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6JXM6p007221 for <[e-mail]>; Mon, 6 Nov 2006 11:33:22 -0800 (PST)
Received: from azsmga001.ch.intel.com ([10.2.17.19]) by mga03.intel.com with ESMTP; 06 Nov 2006 11:33:22 -0800
Received: from scsmsx332.sc.intel.com (HELO scsmsx332.amr.corp.intel.com) ([10.3.90.6]) by azsmga001.ch.intel.com with ESMTP; 06 Nov 2006 11:33:10 -0800
X-ExtLoop1: 1
X-IronPort-AV: i="4.09,392,1157353200";  d="scan'208"; a="142024877:sNHT38354722"
Received: from scsmsx411.amr.corp.intel.com ([10.3.90.30]) by scsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211);  Mon, 6 Nov 2006 11:33:08 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 6 Nov 2006 11:33:07 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Ingress Rbridge address and BCN - 1st Issue
Thread-Index: AccBB7Q86uzfJaKyTIis5WtY0hVwdAAAELywADPiWaA=
From: "Wadekar, Manoj K" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Gray, Eric" <[e-mail]>, "Larry Kreeger \(kreeger\)" <[e-mail]>, "Davide Bergamasco \(davide\)" <[e-mail]>
X-OriginalArrivalTime: 06 Nov 2006 19:33:08.0452 (UTC) FILETIME=[63576A40:01C701DA]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA6JXM6p007221
Cc: [e-mail]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 19:33:59 -0000
Status: RO
Content-Length: 11268

Hi Eric,

	BCN has been defined to work on the data center networks with
short range networks (in meters, not kilometers). Network latency is
definitely significant factor in the analysis for BCN. 

	Current analysis showed stability of solution for networks with
control loop delay of < 1mS. (This includes delay at the end nodes,
links as well as switch forwarding delays). 

	We can discuss details of BCN protocol and any concerns you may
have tomorrow in SD. I will be happy to share due diligence done on BCN.


Thanks,
-Manoj
-----Original Message-----
From: Silvano Gai [mailto:[e-mail]] 
Sent: Sunday, November 05, 2006 10:33 AM
To: Gray, Eric; Larry Kreeger (kreeger); Wadekar, Manoj K; Davide
Bergamasco (davide)
Cc: [e-mail]
Subject: RE: [rbridge] Ingress Rbridge address and BCN - 1st Issue


Eric,

I am OK to have this discussion, I understand BCN at the system level,
but I am not a control theory guy or a congestion management geek.

Two engineers that know BCN very well and that can contribute to the
discussion are:
Manoj K Wadekar <[e-mail]> and
Davide Bergamasco <[e-mail]>
I'll recommend we include them in the discussion.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Sunday, November 05, 2006 10:25 AM
> To: Silvano Gai; Larry Kreeger (kreeger)
> Cc: [e-mail]
> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 1st Issue
> 
> Silvano,
> 
> 	We should probably have some discussion - perhaps off line -
> about how BCN actually works.
> 
> 	For one thing, from what I've heard so far, I have some doubts
> about it working in real networks at all.  That might be addressed by
> taking the time to read the actual BCN specifications in detail and -
> if I were in  a position of having a lot of free time, or under some
> direct pressure from customers to support BCN - I would do that.  So
> far, I have heard that some people have some customers that want BCN
> support (whatever that actually means) and it is hard for me to drop
> something else on so thin a basis.
> 
> 	And it seems likely - based on what people are saying - that our
> taking the time to figure out how BCN "works" might be a waste of
time.
> 
> 	For one thing, your observation about the need for fast feedback
> mechanisms (that appear to be supported by protocol analysis that has
> been performed by someone at least) tends to argue that this technique
> was not designed with real networks in mind.
> 
> 	Delay is a big part of the nature of networks.  Hence realistic
> feedback mechanisms need not only to take into account the fact that
> delay is absolutely unavoidable, but they need to have "knobs" that
> can be adjusted to allow for the mechanism to adapt to different
delays
> in different networks.
> 
> 	The way I am hearing BCN described, it seems as if it has "hard"
> delay bounds and that is a problem - IMO - with the design of BCN.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[e-mail]]
> --> Sent: Saturday, October 28, 2006 11:16 AM
> --> To: Gray, Eric; Larry Kreeger (kreeger)
> --> Cc: [e-mail]
> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 1st Issue
> -->
> --> Eric,
> -->
> --> > -----Original Message-----
> --> > From: [e-mail]
> --> [mailto:[e-mail]]
> --> On
> --> > Behalf Of Gray, Eric
> --> > Sent: Friday, October 27, 2006 3:20 PM
> --> > To: Larry Kreeger (kreeger)
> --> > Cc: [e-mail]
> --> > Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st
Issue
> --> >
> --> > Larry,
> --> >
> --> > 	A slower look up may be okay for exception processing.
> -->
> -->
> --> The BCN closed loop control algorithm requires timely
> --> replies done in
> --> HW. We can ask BCN experts which is the amount of delay that can
be
> --> tolerate, but if I remember correctly the stability
> --> analysis, it was not
> --> much.
> -->
> --> -- Silvano
> -->
> -->
> --> >
> --> > 	BCNs should be required far less often than frames are
being
> --> > forwarded.
> --> >
> --> > 	Having a transit RBridge "look inside [at?] the inner
MAC"
> --> > is not what is effectively happening - as I understand it - when
> --> > a "core RBridge" is generating a BCN.  BCN-capable core RBridges
> --> > would presumably copy the header information from some subset of
> --> > the frames on a minimally-congested link, strip the tunneling
> --> > encapsulation and originate a new frame containing a
Notification
> --> > (BCN) message.
> --> >
> --> > 	This must be a new frame, as opposed to a reflection of
the
> --> > original frame, so it is interesting that people assume this is
a
> --> > trivial operation in hardware in the first place.
> --> >
> --> > 	Since the BCN-capable RBridge has to "flip" the MAC SA
into
> --> > a MAC DA in a BCN anyway, it MUST look at that part of the frame
> --> > in every case before it can generate a BCN.
> --> >
> --> > 	In effect, the frame is (partially) copied, the copied
> --> > information is locally terminated and used to originate a new
> --> > message.  This message would then be sent - presumably using
> --> > the usual means for message origination - by encapsulating it
> --> > in RBridge tunnel encapsulation and forwarding it to (at least)
> --> > the ingress RBridge from which it was introduced.
> --> >
> --> > 	That is not nearly as much of a confusion of layers as
it
> --> > is to 1) assume that the frame is munged in hardware and turned
> --> > around and 2) normal processing of originated local messages is
> --> > bypassed in an attempt to optimize BCN sending at the cost of
> --> > including additional information in _every_ frame.
> --> >
> --> > 	Oh, and, apparently I can blame you for trying... :-)
> --> >
> --> > --
> --> > Eric
> --> >
> --> > --> -----Original Message-----
> --> > --> From: Larry Kreeger (kreeger) [mailto:[e-mail]]
> --> > --> Sent: Friday, October 27, 2006 5:26 PM
> --> > --> To: Gray, Eric
> --> > --> Cc: [e-mail]
> --> > --> Subject: RE: [rbridge] Ingress Rbridge address and
> --> BCN - 1st Issue
> --> > -->
> --> > --> Gray, Eric wrote on Friday, October 27, 2006 11:33 AM:
> --> > -->
> --> > --> > Larry,
> --> > --> >
> --> > --> > 	Separating these issues...
> --> > --> >
> --> > --> > -- [SNIP] --
> --> > --> > -->
> --> > --> > --> Please correct me if I incorrectly summarize the
above.
> --> > --> > -->
> --> > --> > --> 1) Scaling the number of fowarding entries in the
> --> > --> core is not a
> --> > --> > --> problem that TRILL needs to solve.
> --> > --> >
> --> > --> > While this is a possible intrepretation, it is not
> --> an accurate
> --> > --> > characterization of what I said.
> --> > --> >
> --> > --> > I'll try again, starting with what you have said.
> --> > --> >
> --> > --> > Scaling of the number of forwarding entries in the
> --> core is not a
> --> > --> > problem that the TRILL working group has decided to solve.
> --> > --> >
> --> > --> > Hence, you might conclude that the TRILL working group
> --> > --> has passively
> --> > --> > decided that this is not a problem that TRILL needs
> --> to solve.
> --> > --> >
> --> > --> > One reason why this might be the case is that people
> --> > --> could not decide
> --> > --> > the "by how much" question.
> --> > --> >
> --> > --> > Never-the-less, an implicit requirement that the solution
> --> > --> should not
> --> > --> > prevent more scalable implementations, enables people who
> --> > --> might not
> --> > --> > be able to agree in public (as to what factor of increased
> --> > --> > scalability should apply) to produce and deploy solutions
> --> > --> that are in
> --> > --> > fact more scalable, by at least some amount.
> --> > --> >
> --> > --> > --> 2) Link utilization is a problem and TRILL needs to
> --> > --> be concerned
> --> > --> > --> with it.
> --> > --> >
> --> > --> > Certainly.
> --> > --> >
> --> > --> > -->
> --> > --> > --> If this is correct, it leads me to believe that you
> --> > --> would advocate
> --> > --> > --> for
> --> > --> > --> 1) Remove the destination RBridge from the shim, and
> --> > --> just lookup
> --> > --> > the
> --> > --> > --> destination MAC directly
> --> > --> >
> --> > --> > How do you arrive at this conclusion?  There are
> --> > --> scenarios where this
> --> > --> > might be done, but clearly the use of a smaller field for
> --> > --> a look-up
> --> > --> > is traditionally viewed as likely to be quicker.
> --> > -->
> --> > --> I appologize for trying to put words in you mouth, but I am
> --> > --> trying to
> --> > --> understand what you are arguing for...and after
> --> reading the above,
> --> I
> --> > --> still don't know.  Maybe it is because I am confusing
> --> what you are
> --> > --> personally saying versus what you are echoing from others
> --> > --> in the group.
> --> > --> Do you believe we need the RBridge Id in the shim or not?
> --> > --> If you do,
> --> > --> then why?  For a quicker lookup?  If so, then why would a
> --> > --> slower lookup
> --> > --> to generate the source RBridge for BCN be acceptable?
> --> > -->
> --> > --> >
> --> > --> > --> 2) Eliminate the need for the outer MAC header
> --> between two
> --> > --> > RBridges
> --> > --> > --> if the link is point to point (quite likely in
> --> my opinion).
> --> > --> >
> --> > --> > Ultimately, point-to-point is very likely, but we have to
> --> > --> deal with
> --> > --> > the step-by-step deployment scenarios.
> --> > --> >
> --> > --> > In any case, I do not advocate special-casing
> --> > --> encapsulation based on
> --> > --> > link types in general - beyond that already required by
> --> > --> the specific
> --> > --> > link.  As I thought would be obvious by now, I advocate
> --> functional
> --> > --> > separation - which works better if you don't build in a
> --> > --> lot of layer
> --> > --> > dependencies.
> --> > -->
> --> > --> I agree with you about building in a lot of layer
> --> > --> dependencies.  Having
> --> > --> transit RBridges look inside the inner MAC seems like a
> --> > --> layer dependency
> --> > --> to me.  Not encapsulating with an extra 14 to 18 bytes on
> --> > --> point to point
> --> > --> link seems like it would be well worth it if you are
> --> > --> concerned with link
> --> > --> overhead.  I would gladly trade 14/18 bytes of overhead for
> --> > --> another 2
> --> > --> bytes of source RBridge which will help with BCN as well as
> --> > --> help with
> --> > --> network troubleshooting.
> --> > -->
> --> > --> >
> --> > --> > -->
> --> > --> > --> Again, I apologize for not keeping up with the latest
> --> > --> discussions,
> --> > --> > --> but have these ideas been discussed already?
> --> If so, could
> --> you
> --> > --> > --> summarize the outcome?
> --> > --> >
> --> > --> > This is not a reasonable request.
> --> > -->
> --> > --> Oh well, cant' blame me for trying can you? ;-)
> --> > -->
> --> > --> >
> --> > --> > -- [SNIP] --
> --> > -->
> --> > _______________________________________________
> --> > rbridge mailing list
> --> > [e-mail]
> --> > http://mailman.postel.org/mailman/listinfo/rbridge
> -->



Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6JJqUl001144 for <[e-mail]>; Mon, 6 Nov 2006 11:19:52 -0800 (PST)
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 06 Nov 2006 11:19:53 -0800
X-IronPort-AV: i="4.09,392,1157353200";  d="scan'208"; a="755002742:sNHT86227554"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6JJqAF005393; Mon, 6 Nov 2006 11:19:52 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA6JIvip010602; Mon, 6 Nov 2006 11:19:51 -0800 (PST)
Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 6 Nov 2006 11:18:56 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 6 Nov 2006 11:18:56 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Traffic storms
Thread-Index: Acb/rnynEdnhHyRYR6SST6vxpbGWSgCJSjsQ
From: "Sanjay Sane \(sanjays\)" <[e-mail]>
To: "Pierre Francois" <[e-mail]>, "Silvano Gai" <[e-mail]>
X-OriginalArrivalTime: 06 Nov 2006 19:18:56.0626 (UTC) FILETIME=[679D1520:01C701D8]
DKIM-Signature: a=rsa-sha1; q=dns; l=10666; t=1162840792; x=1163704792; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=22Sanjay=20Sane=20\(sanjays\)=22=20<[e-mail]> |Subject:RE=3A=20[rbridge]=20Traffic=20storms; X=v=3Dcisco.com=3B=20h=3DAS5Npchr6zOsJOzSvi/98TrLDaM=3D; b=COS33MrQ6pgAG3NARTPnhAdCBgaWHPjFLRaOnnU7h9iGtgMv3ShKOzIXgdkwlTQbc8vMyaTn 65jynXb1P/58ArWkvwuJv3eN1wUiAplCnVBOq5f3wE3OYuZz/yra/EFm;
Authentication-Results: sj-dkim-3.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA6JJqUl001144
Cc: [e-mail], Gideon Kaempfer <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 19:20:59 -0000
Status: RO
Content-Length: 10167

Pierre,

After reading through this paper, it seems the oFIB mechanism is suited
towards unicast traffic, or a single-destination traffic. 

In TRILL, if the plan is to protect the traffic storms, we *must*
protect the transient loops in the "trees" that are built to carry
unknowns/floods, multicast as well as unicast. Such traffic is targetted
towards multiple destination, in fact, a tree extends to all the
rbridges. 

After thinking a bit, if we think of extending the mechanisms in the
paper to cover "trees", we may have to delay the FIB ordering on all the
links that are part of the tree on any given rbridge. This could be very
inefficient. Do you think the oFIB mechanism would be suitable for such
trees? 

-Sanjay 

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Pierre Francois
Sent: Friday, November 03, 2006 5:10 PM
To: Silvano Gai
Cc: [e-mail]; Gideon Kaempfer; Radia Perlman
Subject: Re: [rbridge] Traffic storms


Silvano,

See
http://www.ietf.org/internet-drafts/draft-francois-ordered-fib-02.txt,
for a loop avoidance mechanism for IS-IS/OSPF.

See you in SD,

Pierre.



On Fri, 3 Nov 2006, Silvano Gai wrote:

> Eric,
>
> Also I suggest that people that have solved the problem of having a 
> loop free topology using ISIS, submit proposasl so that we can compare
them.
> Unfortunately I don't have one.
>
>
>
> -- Silvano
>
>
>
> ________________________________
>
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Gray, Eric
> Sent: Friday, November 03, 2006 11:54 AM
> To: Gideon Kaempfer; Radia Perlman
> Cc: [e-mail]
> Subject: Re: [rbridge] Traffic storms
>
>
>
> Gideon,
>
>
>
>     "Drop BPDUs" is not (exactly) the same as ignore them.  We use the

> term
>
> as short-hand for the one of three options we considered for handling
> BPDUs:
>
>
>
>     Drop (do not participate actively in STP, and do not pass BPDUs 
> through),
>
>     Transparent (pass BPDUs through - potentially altering them in 
> some way),
>
>     Participate (have each RBridge participate in STP as if it were a 
> bridge).
>
>
>
> Hence, when we say "Drop BPDUs" we are not saying that we cannot look
>
> at them, we are just saying that we're not doing one of the other two 
> choices.
>
>
>
> --
>
> Eric
>
>
>
>
> ________________________________
>
>
> 	From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Gideon Kaempfer
> 	Sent: Friday, November 03, 2006 1:40 AM
> 	To: Radia Perlman
> 	Cc: [e-mail]
> 	Subject: Re: [rbridge] Traffic storms
>
> 	Radia,
>
> 	Wouldn't this create a link between TRILL and STP we are trying
to 
> avoid?
>
> 	Relying on the fact that a LAN segment has some kind of unique 
> identifier (such as the root bridge ID) seems like a very practical 
> solution to me, but strongly reliant on the fact that the Rbridges 
> actually process BPDUs. I thought they were just meant to discard
them.
> Is this acceptable?
>
> 	Regrads,
>
> 	 Gidi
>
>
>
> 	On 11/3/06, Radia Perlman <[e-mail]> wrote:
>
> 	The simplest way to put it, I think, is that in certain
transitory
> 	situations there might be two
> 	RBridges that both think they are Designated RBridge, and that
is 
> bad,
> 	but should stop
> 	as soon as a single Hello is received by the RBridge who should
not 
> be
> 	Designated.
>
> 	I think PIM has similar transitory situations that can occur,
and
> 	bridges can also have (hopefully
> 	temporary) problems if a repeater came up and merged two LANs. I

> think
> 	such things are
> 	annoying but not fatal. But I think it's possible we can with
little
> 	effort avoid this problem.
>
> 	However, with RBridges, because the bridge spanning tree
algorithm
> 	elects a Root, there's
> 	really a way of uniquely identifying a LAN (where "LAN" is a
bunch of
> 	links connected with
> 	bridges). The unique identifier is the root bridge.
>
> 	When the B1-B2 link is down, RB1 and RB2 will see the topology
as two
> 	separate links, and each
> 	one will have a distinct spanning tree Root bridge (RB1 will see
B1, 
> and
> 	RB2 will see B2 as the root).
>
> 	When the B1-B2 link comes up, the bridges will first merge the
two
> 	links, and either RB1 or RB2 will
> 	see that the bridge spanning tree root has changed. This will be
> 	discovered before B1 and B2 forward
> 	traffic across the link because of the bridge forwarding delay.
> 	If B1 has better priority as bridge spanning tree root than B2,
then 
> RB1
> 	will not notice anything
> 	different when the B1-B2 link comes up. But RB2 will notice
> 	something different; the spanning tree root has changed
identities 
> from
> 	"B2" to "B1".
>
> 	Given this, RB2 could temporarily stop forwarding to or from the
link
> 	when the Root bridge
> 	changes identities, though it should definitely immediately send

> IS-IS
> 	Hellos (either RB1 or RB2 will
> 	be elected Designated Router in the IS-IS election for that
link). If
> 	RB2 has better prioirty for
> 	root, the RB1 will immediately stop forwarding to or from the
link 
> when
> 	it sees the Hello from RB2.
> 	If RB2 has better priority in the IS-IS election, then RB1
should
> 	immediately send an IS-IS Hello
> 	when it sees a Hello from a new RBridge on the link.
>
> 	So I think this is not a big deal, and that if we are worried,
we can
> 	specify that an RBridge should
> 	stop acting like the Designated RBridge for a few seconds after
the
> 	identity of the Root in the spanning
> 	tree algorithm changes.
>
> 	Or we could be even fancier and have each RBridge announce in
its 
> IS-IS
> 	Hellos which LAN IDs it
> 	is Designated for, where a LAN ID is the MAC address of the Root

> bridge.
> 	So RB1 continue
> 	forwarding if the identity changes from B1 to B2 provided no
other
> 	RBridge has claimed to be connected
> 	to B2. But if RB2's LSP claims it is attached to B2, then RB1
must 
> stop
> 	forwarding for enough time
> 	for the IS-IS election to sort itself out and choose a
Designated 
> RBridge.
>
> 	Radia
>
>
>
>
>
>
> 	Gideon Kaempfer wrote:
>
> 	>Following mention by Silvano of broadcast and multicast storms
(and 
> the need
> 	>to protect against them), I played around with different
scenarios 
> and came
> 	>upon one I would appreciate your comments on (in the hope I am 
> pointing out
> 	>a non-existent issue with TRILL). I believe a broadcast and
even a 
> unicast
> 	>storm could be created as the result of a loop that isn't
protected 
> by TTL
> 	>nor by STP in the case of a link connecting two separate LAN 
> segments coming
> 	>to life.
> 	>
> 	>- RB1 ---- RB2 -
> 	>   |        |
> 	>-  B1 --x-- B2 -
> 	>   |        |
> 	>   H1       H2
> 	>
> 	>1. The network (segment) involved consists of two Rbridges
(RB1, 
> RB2), two
> 	>bridges (B1, B2) and two hosts (H1, H2). They are physically 
> connected as
> 	>depicted.
> 	>2. State A: the direct link between B1 and B2 is down. B1 and
> B2 find
> 	>themselves on different LAN segments and hence different
spanning 
> trees. RB1
> 	>and RB2 are both designated Rbridges (each for the segment of
the
> 	>corresponding bridge).
> 	>3. State B: the direct link between B1 and B2 goes up (someone 
> connects a
> 	>cable). B1 and B2 discover each other and establish a common 
> spanning tree.
> 	>RB1 and RB2 both find themselves attached to the same LAN
segment 
> and hence
> 	>RB1 (without loss of generality) will eventually become the 
> designated
> 	>Rbridge for it.
> 	>4. Just before RB1 and RB2 identify that they are both on the
same 
> segment
> 	>and RB2 stops functioning as a designated Rbridge the following

> scenario
> 	>seems possible:
> 	>  a. H1 sends a broadcast frame.
> 	>  b. B1 receives it and forwards to RB1 and B2.
> 	>  c. RB1 (encapsulates and) forwards to RB2.
> 	>  d. B2 forwards to RB2 and H2.
> 	>  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2
to 
> RB1).
> 	>  f. (RB1 forwards to B1.)
> 	>  g. B2 forwards (again) to H2 and to B1.
> 	>  h. B1 forwards to H1 (see remark below regarding filtering
table
> 	>contamination) and to RB1.
> 	>  i. Etcetera etcetera.
> 	>5. A broadcast storm is born, created by a loop that is not 
> protected by TTL
> 	>(due to the fact that forwarding between the Rbridges is only
across 
> a
> 	>single hop) nor by STP (due to the fact that Rbridges do not 
> participate in
> 	>STP).
> 	>6. If forwarding commences at the hardware level and no
broadcast 
> rate
> 	>limiting is in place, the storm may cause severe damage in a
very 
> short time
> 	>(note that replicated frames are sent to H1 and H2 (or any
network 
> they
> 	>could represent).
> 	>7. Another unfortunate effect of this storm is that B1 and B2
no 
> longer know
> 	>where H1 is located (due to the contamination of their
filtering 
> tables by a
> 	>frame from H1 that arrives from the wrong direction (and in
fact 
> from
> 	>multiple directions). As a result, a possible unicast frame
from H2 
> to H1
> 	>will just join the storm over the loop at least in one
direction 
> (RB2 will
> 	>forward it to RB1) but will not arrive at H1...
> 	>
> 	>One possible solution could be for RB2 to identify the fact
that it 
> is
> 	>receiving a frame from a host with a MAC address that is
associated 
> with a
> 	>segment it thought it isn't connected to. Hence, it may trigger
an 
> immediate
> 	>neighbor discovery / designated Rbridge election. However,
because 
> Rbridges
> 	>should allow host mobility, this frame may need to be forwarded
(and 
> hence
> 	>the storm commences).
> 	>
> 	>As mentioned above, any comments are welcome.
> 	>  Gideon Kaempfer
> 	>
> 	>_______________________________________________
> 	>rbridge mailing list
> 	>[e-mail]
> 	> http://mailman.postel.org/mailman/listinfo/rbridge
> <http://mailman.postel.org/mailman/listinfo/rbridge>
> 	>
> 	>
>
> 	_______________________________________________
> 	rbridge mailing list
> 	[e-mail]
> 	http://mailman.postel.org/mailman/listinfo/rbridge
>
>
>
>
_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6JIsnZ000611 for <[e-mail]>; Mon, 6 Nov 2006 11:18:54 -0800 (PST)
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2006 11:18:54 -0800
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAAAFIYT0WrR7PDh2dsb2JhbACMSgEBAQgOKg
X-IronPort-AV: i="4.09,392,1157353200";  d="scan'208"; a="448341778:sNHT52108716"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6JIrov004022; Mon, 6 Nov 2006 11:18:53 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA6JIrin010489; Mon, 6 Nov 2006 11:18:53 -0800 (PST)
Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 6 Nov 2006 11:18:53 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 6 Nov 2006 11:18:53 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Compromise proposal---allowing tradeoff between	computation and optimality of delivery
Thread-Index: Acb+tLKpGN3C4/Z9RQK5XOyXFq0iawBqN7jAAF3ONoA=
From: "Sanjay Sane \(sanjays\)" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 06 Nov 2006 19:18:53.0703 (UTC) FILETIME=[65DF1170:01C701D8]
DKIM-Signature: a=rsa-sha1; q=dns; l=2781; t=1162840734; x=1163704734; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=22Sanjay=20Sane=20\(sanjays\)=22=20<[e-mail]> |Subject:RE=3A=20[rbridge]=20Compromise=20proposal---allowing=20tradeoff=20betwee n=09computation=20and=20optimality=20of=20delivery; X=v=3Dcisco.com=3B=20h=3DzgNSLnE+BDA/0mcKjHkXPf5MEB0=3D; b=AQapX4SpkFJuiFP4XhmsAGHKSxXq6zKAiSQmGw8dqir27wnwWaQCOE8lK0knHdDI9nxufm99 P2jXL6ho2A+YhVkCv6NrTJ8Guylgslr1tkRpK8ea+yNFyRp5FXCkGoc+;
Authentication-Results: sj-dkim-3.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA6JIsnZ000611
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between	computation and optimality of delivery
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 19:19:21 -0000
Status: RO
Content-Length: 2697

I would also support a minimum or a default of 2 trees. Thus, at
minimum, we can assure multicast-multipathing (even if it's 2-way) in a
TRILL network. 

Sanjay

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Saturday, November 04, 2006 2:10 PM
To: [e-mail]
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between
computation and optimality of delivery

I really can't see why the minimum should be one. In an network where
Rbridge trees make any difference you have at least two Rbridges so I
can't see why you wouldn't, at a minimum, have two trees. I think we
should just prohibit Rbridges that claim to be able to support only one
tree.

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Thursday, November 02, 2006 2:20 PM
To: Sanjay Sane (sanjays)
Cc: [e-mail]
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between
com putation and optimality of delivery

Warning---half-baked idea at the end of this message (my own---see
"***")


Sanjay Sane (sanjays) wrote:

>
>So, the TLV inside rbridge LSP could contain 2 things
>1 -- "my priority for being a tree root is x". 
>2 -- "I can support n trees"
>
>If both of these are absent, we could choose 1 tree, and the rbridge 
>with lowest MAC address is the root of that single tree.
>
>-Sanjay
>
Right. I'm a bit nervous about some random RBridge that can only support
one tree, or that just leaves the TLV out, from going up and down. We
have to make sure it's not unstable.

Suppose the nickname of the RBridge with highest priority for being root
is 24.
Suppose ingress RBridge R1 doesn't notice that wimpy RBridge R5 (that
can only support one tree) has joined the net, and R1 selects "79" as
the tree .

I guess we should say that if you see a specified tree that shouldn't be
legal, you drop the packet, right?

***An alternative is to continue forwarding it along the 79-tree and
hey, if R5 is on the path, it will drop the packet and only nodes
downstream from R5 will suffer. We could even do complicated things like
say that you can calculate trees beyond R5's capabilities by considering
links out of R5 to be infinity. That way a wimpy RBridge can be a leaf,
and going up and down won't affect existing trees.

Radia

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

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



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6JFgDc029105 for <[e-mail]>; Mon, 6 Nov 2006 11:15:43 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA6JBsfK014010; Mon, 6 Nov 2006 14:11:54 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA07248;  Mon, 6 Nov 2006 14:11:54 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB649L4Y>; Mon, 6 Nov 2006 14:11:53 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Radia Perlman <[e-mail]>, Eastlake III Donald-LDE008 <[e-mail]>
Date: Mon, 6 Nov 2006 14:11:52 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 19:16:13 -0000
Status: RO
Content-Length: 4736

Radia,

	I think I agree with this and would go further to make two
additional comments/observations:

	1) Unless it is possible to determine absolutely what cases
         exist where RBridges can know that the link between them
         actually is p2p (as opposed to looks like it is p2p), it
         is risky to leave this sort of behavior as an unspecified
         option.
	2) If we cannot explicitly list the conditions under which 
         all implementations MUST assume a NULL outer header, and
         we really believe it is important to have this, then we
         need to specify a negotiation mechanism whereby RBridges
         can signal the intention to leave out the outer header.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Radia Perlman
--> Sent: Monday, November 06, 2006 1:14 PM
--> To: Eastlake III Donald-LDE008
--> Cc: [e-mail]
--> Subject: Re: [rbridge] Should we optimize the common case?
--> 
--> Yes, if there are two RBridges that can figure out they have a point to 
--> point link between them, it seems like it would be good to drop the
outer 
--> header, since there's really no information there.
--> 
--> Is there a way to automatically know this is definitely a pt-to-pt 
--> Ethernet link and not a shared link?
--> 
--> Radia
--> 
--> Eastlake III Donald-LDE008 wrote:
--> 
--> >Silvano,
--> >
--> >Why do you think that 90% of Rbridge deployment will be 
--> for this unusual
--> >case? I mean, I have no problem with the belief that 
--> Rbridges would be
--> >better than bridges in this case but why shouldn't that be 
--> true of less
--> >high end uses?
--> >
--> >A while ago on this list I posted a rhetorical question as to why
--> >Rbriges shouldn't eventually replace all bridges. No one posted an
--> >answer.
--> >
--> >Why not specify Rbridges more or less as we have been for 
--> the common
--> >bridge case and, in the backbone case you are talking 
--> about, just drop
--> >the MAC addresses on the point-to-point links within the backbone?
--> >Doesn't that produce less overhead than your proposal 
--> below in both the
--> >point-to-point and shared media cases?
--> >
--> >Donald
--> >
--> >-----Original Message-----
--> >From: [e-mail] 
--> [mailto:[e-mail]] On
--> >Behalf Of Silvano Gai
--> >Sent: Wednesday, November 01, 2006 9:07 PM
--> >To: [e-mail]
--> >Subject: [rbridge] Should we optimize the common case?
--> >
--> >
--> >With 16 bit addresses the current TRILL overhead over 
--> Ethernet is 20
--> >bytes. If we want to expand the RBridge addresses, it we will go to
--> >22-24 bytes.
--> >
--> >What customers are telling us is that they will deploy RBridges by
--> >creating an RBridge backbone in which all the links will be 10GE.
--> >
--> >They will connect regular bridges and host to the periphery of this
--> >backbone. 
--> >
--> >They will not mix backbone ports with access ports, 
--> because this screws
--> >up management, traffic engineering, debugging, and troubleshooting.
--> >Regular network design, easy to understand, is very 
--> important. Ports are
--> >cheap, labor is expensive.
--> >
--> >I am totally convinced that this will account for 90+ % of TRILL
--> >deployment. 
--> >
--> >I am wondering if it makes sense to have a solution highly 
--> optimized for
--> >such an environment.
--> >
--> >For example we can put the egress/ingress RBridge 
--> addresses in the outer
--> >MAC addresses and define a TRILL shim header that contains 
--> 1 byte of hop
--> >limit and 1 byte reserved. For this common case we will get:
--> >1) overhead of 16 bytes (4 to 8 bytes lower)
--> >2) nickname = MAC address, i.e no hash collision
--> >3) zero-conf achieved
--> >
--> >In the case we need to go over a shared media we will need to add
--> >another Ethernet encapsulation to carry the next hop 
--> address, i.e. 14
--> >bytes
--> >- total overhead will be 30 bytes
--> >
--> >Summarizing:
--> >- current proposal 20-24 bytes overhead
--> >- new proposal on point to point: 16 bytes
--> >- new proposal on shared media: 30 bytes
--> >
--> >Comments?
--> >
--> >-- Silvano
--> >
--> >
--> >_______________________________________________
--> >rbridge mailing list
--> >[e-mail]
--> >http://mailman.postel.org/mailman/listinfo/rbridge
--> >
--> >_______________________________________________
--> >rbridge mailing list
--> >[e-mail]
--> >http://mailman.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6Ivld8022135 for <[e-mail]>; Mon, 6 Nov 2006 10:57:52 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA6Is0fK013618; Mon, 6 Nov 2006 13:54:01 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05855;  Mon, 6 Nov 2006 13:54:00 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB649LGZ>; Mon, 6 Nov 2006 13:53:59 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Eastlake III Donald-LDE008 <[e-mail]>
Date: Mon, 6 Nov 2006 13:53:58 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] A thought about TTLs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 18:58:12 -0000
Status: RO
Content-Length: 1836

Donald,

	To expand on this, it is actually necessary for the protocol 
specification to be very explicit in describing how TTL is handled
- both in establishing the initial value, and in processing by an
intermediate (or egress) RBridge.

	There can be some flexibility in how any individual RBridge
implementation determines an initial value, but it is not sufficient
to leave this entirely to implementation discretion.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Eastlake 
--> III Donald-LDE008
--> Sent: Monday, November 06, 2006 1:14 AM
--> To: [e-mail]
--> Subject: [rbridge] A thought about TTLs
--> 
--> Rbridges are in a fundamentally different position in 
--> deciding shim TTLs
--> than IP hosts are in deciding IP TTLs. In particular, a host knows
--> almost nothing about the routing situation while an Rbridge 
--> has explicit
--> link state information.
--> 
--> Thus it would be reasonable to recommend a TTL based on the expected
--> number of hops for unicast or maximum expected number of hops for
--> multicast/broadcast/flooded or on the diameter of the 
--> network (maximum
--> number of Rbridge-Rbridge hops for the two most distant 
--> Rbridges) or the
--> like ... It would even be possible to have Rbridges trim 
--> back the TTL
--> for the copy forwarding to a particularly short branch of a 
--> tree or even
--> when forwarding along a unicast path if that path has 
--> gotten shorter.
--> Such adjustment is probably too much work to mandate but it 
--> seems to me
--> that it should be allowable behavior.
--> 
--> Thanks,
--> Donald
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6Ir8vO020291 for <[e-mail]>; Mon, 6 Nov 2006 10:53:09 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA6InIfK013501; Mon, 6 Nov 2006 13:49:18 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05531;  Mon, 6 Nov 2006 13:49:17 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB649LD1>; Mon, 6 Nov 2006 13:49:16 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>, Eastlake III Donald-LDE008 <[e-mail]>, [e-mail]
Date: Mon, 6 Nov 2006 13:49:14 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] WG last call commentsto:http://www.ietf.org/interne	t-drafts/draft-ietf-trill-routing-reqs-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 18:53:16 -0000
Status: RO
Content-Length: 23872

Silvano,

	Let's not be stubborn about wording.  You don't like the phrase
"drop BPDUs."  I think it's fair to observe that "process BPDUs" is
not quite accurate either.

	The intention is that implementations MAY examine BPDUs in an
effort to maintain awareness of network conditions, but they are not
to "process" them in the usual sense of STP (or RSTP, or MSTP).

	What wording would you like to see?

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Silvano Gai
--> Sent: Monday, November 06, 2006 1:16 AM
--> To: Eastlake III Donald-LDE008; [e-mail]
--> Subject: Re: [rbridge] WG last call 
--> commentsto:http://www.ietf.org/internet-drafts/draft-ietf-tr
--> ill-routing-reqs-00.txt
--> 
--> Donald,
--> 
--> I think I agree with most of your comments, with one big exception.
--> 
--> I am not able to see the difference between "dropping a BPDU" or
--> "ignoring a BPDU".
--> 
--> IMO there are two possibilities:
--> 1) we drop BPDUs
--> 2) we process BPDUs
--> 
--> If we do 2), we can:
--> 2.1) process BPDU using STP/RSTP
--> 2.2) do other processing on the BPDU, not STP/RSTP related
--> 
--> If we don't want to do 2.1), let's just say it.
--> If we need to do 2.2), it is better we spell it out clearly, and not
--> hide it behind the word "ignore BPDUs".
--> 
--> This is such a crucial point to achieve:
--> a) Interoperability
--> b) A robust implementation
--> 
--> that we don't want to be vaguely defined.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: [e-mail] 
--> [mailto:[e-mail]]
--> On
--> > Behalf Of Eastlake III Donald-LDE008
--> > Sent: Sunday, November 05, 2006 3:22 PM
--> > To: [e-mail]
--> > Subject: Re: [rbridge] WG last call
--> >
--> commentsto:http://www.ietf.org/internet-drafts/draft-ietf-tr
--> ill-routing-
--> > reqs-00.txt
--> > 
--> > Hi Silvano,
--> > 
--> > I think I agree with most of your comments but see a few 
--> notes at @@@
--> > 
--> > -----Original Message-----
--> > From: [e-mail] 
--> [mailto:[e-mail]]
--> On
--> > Behalf Of Silvano Gai
--> > Sent: Sunday, October 29, 2006 12:23 PM
--> > To: [e-mail]
--> > Subject: [rbridge] WG last call comments
--> >
--> to:http://www.ietf.org/internet-drafts/draft-ietf-trill-rout
--> ing-reqs-00.
--> > txt
--> > 
--> > Comments inline marked "sgai n>"
--> > 
--> > -- Silvano
--> > 
--> > --------------------------------------------------------
--> > 
--> > ... snip ...
--> > 
--> > 1. Introduction
--> > 
--> >    The current dominant approach to segregating network 
--> traffic relies
--> >    on a hierarchical arrangement of bridges and routers.  
--> Hierarchy is
--> >    further extended - both within routing protocols (such 
--> as IS-IS and
--> >    OSPF) and between routing protocols (for example, 
--> between IGPs and
--> >    BGP).  At least part of the current network structure 
--> is based on a
--> >    determined trade-off between limitations of IP routing 
--> and similar
--> >    disadvantages of 802 bridging.
--> > 
--> >    Bridging Limitations
--> > 
--> >    For example, bridged networks consist of single 
--> broadcast/flooding
--> >    domains.  Ethernet/802 encapsulation (on which 
--> bridging is based)
--> >    does not provide mechanisms for reducing the impact of 
--> looping data
--> >    traffic that may result from a transient change in 
--> network topology
--> >    and the existence of multiple paths.
--> > 
--> >    The impact of looping traffic is far worse with flooded or
--> broadcast
--> >    traffic as this results in exponentially increasing 
--> traffic load.
--> >    Consideration of the impacts of looping data lead to the use of
--> >    STP/RSTP to establish a connected - loop free - tree 
--> by disabling
--> >    forwarding on a subset of links that might create a 
--> loop.  This has
--> >    also the effect of eliminating redundant paths.
--> > 
--> > @@@ Also generally lowers aggregate throughput and 
--> increases latency
--> > through the net due to frames following suboptimal paths.
--> > 
--> >    Because of the potential for severe impact from 
--> looping traffic,
--> >    many (if not most) current bridge implementations stop 
--> forwarding
--> of
--> >    traffic frames following a topology change event and 
--> restart only
--> >    after STP/RSTP is complete.
--> > 
--> > Sgai 1> In STP there is no way of knowing when the convergence has
--> been
--> > achieved; a bridge does not know or care about the timers of other
--> > bridges. The state machines on the ports are run 
--> independently. If you
--> > refer to the Topology Change Notification Flag, its purpose is to
--> reduce
--> > the filtering database ageing time, not to signal if STP/RSTP is
--> > complete.
--> > 
--> >    As a result, the process of eliminating potential 
--> loops in existing
--> >    bridging deployments:
--> > 
--> >      1) Results in inefficient use of inter-bridge connections
--> >         and
--> >      2) Causes delays in forwarding traffic as a result of
--> >         changes in the network topology.
--> > 
--> > Sgai 2> 2) is not true in the RSTP case; as a matter of 
--> fact RSTP is
--> the
--> > fastest converging protocol available today.
--> > 
--> > @@@ I'm not sure why this and other documents put the 
--> emphasis they do
--> > on STP/RSTP convergence. Of course it depends some on just how
--> STP/RSTP
--> > is implemented and how other algorithms are implemented. 
--> Perhaps it
--> > stems from, as was pointed out early in the Rbridge 
--> effort, that the
--> > replacement of bridges with Rbrides typically divides 
--> what would have
--> > been one large spanning tree domain into a number of smaller ones
--> > interconnected by Rbridges. The STP/RSTP protocol within 
--> these small
--> > spanning tree domains will typically converge for them 
--> all in parallel
--> > more rapidly than the pre-existing larger single spanning tree
--> STP/RSTP
--> > convergence.
--> > 
--> >    The combined effect of broadcast/flooding traffic, and 
--> the use of
--> >    spanning trees for loop avoidance, sets practical 
--> limits on bridged
--> >    network size in the network hierarchy and results in 
--> inefficient
--> >    bandwidth use of inter-bridge connections. Inefficient 
--> inter-bridge
--> >    connection usage similarly limits the usefulness of 
--> bridging with
--> >    high-speed (and consequently high cost) interfaces.
--> > 
--> > 
--> > 
--> > 
--> > 
--> > 
--> > 
--> > Gray                      Expires March, 2007             
-->     [Page 3]
--> > 
--> > Internet-Draft        TRILL Routing Requirements       
--> September, 2006
--> > 
--> > 
--> >    IP Routing Issues
--> > 
--> >    For IP routed networks, any link (or subnet) must have 
--> at least one
--> >    unique prefix. This means that a node that moves from 
--> one IP subnet
--> > 
--> > sgai 3> in the case of IP instead of "node" is better to speak of
--> > "interface". It is the interface that has an address, not 
--> the node.
--> > 
--> >    to another must change its IP address. Also, nodes 
--> with multiple IP
--> >    subnet attachments must have multiple IP addresses.  
--> In IP routed
--> >    networks, there are frequent trade-off considerations 
--> between using
--> >    smaller subnets (longer prefix length) to minimize wasted IP
--> address
--> >    space (as a result of unused addresses in the fixed 
--> address range
--> >    defined by the prefix and length) and using larger 
--> subnets (shorter
--> >    prefix length) to minimize the need for (changes in) 
--> configuration.
--> > 
--> >    In any case - with current IP routing technology - 
--> subnets must be
--> >    configured for each routed interface.
--> > 
--> >    Proposed Solution
--> > 
--> >    Using a hybrid of routing and bridging - an RBridge - 
--> we hope to
--> >    gain the benefits of both technologies, in particular, 
--> gaining the
--> >    bandwidth advantages of shortest path routing while 
--> retaning the
--> >    simplified configuration associated with bridging.
--> > 
--> > 1.1. Terminology
--> > 
--> >    The following terms are used in this document in the way that
--> >    they are defined in "TRILL RBridge Architecture" [TARCH]:
--> > 
--> >      ARP (Address Resolution Protocol)
--> >      Bridge Learning
--> >      Broadcast Domain
--> >      Broadcast Traffic
--> >      Cooperating RBridges
--> >      Egress RBridge
--> >      Ethernet
--> >      Flooded Traffic
--> >      Flooding
--> >      Frame
--> >      IGP (Interior Gateway Protocol)
--> >      Ingress RBridge
--> >      Ingress RBridge Tree
--> >      IS-IS (Intermediate System to Intermediate System)
--> >      ND (Neighbor Discovery)
--> >      OSPF (Open Shortest Path First)
--> >      Packet
--> > 
--> > Sgai 4> in the case of layer 2 networks is more 
--> appropriate to use the
--> > term frame, instead of packet.
--> > 
--> > @@@ Frame appears earlier in this list and I believe that both are
--> > properly defined in the architecture document.
--> > 
--> >      RBridge
--> >      SPF (Shortest Path First)
--> >      STP/RSTP (Spanning Tree Protocol/Rapid Spanning Tree 
--> Protocol)
--> >      TRILL (TRansport Interconnect over Lots of Links)
--> >      Unknown Destination
--> >      VLAN (Virtual Local Area Network)
--> > 
--> > 
--> > Gray                      Expires March, 2007             
-->     [Page 4]
--> > 
--> > Internet-Draft        TRILL Routing Requirements       
--> September, 2006
--> > 
--> > 
--> > 
--> > 1.2. Specific TRILL Goals
--> > 
--> >    (Near) Zero Configuration
--> > 
--> >    It is a TRILL requirement that it must be possible to deploy
--> RBridges
--> >    in at least a nominal set of potential deployment 
--> scenarios without
--> a
--> >    need to perform any configuration at each RBridge.  It 
--> is possible
--> to
--> >    meet this goal for a sub-set of all possible 
--> deployment scenarios
--> by
--> >    making realistic restrictions on deployment - such as 
--> restricting
--> the
--> >    deployment scenarios to exclude those involving a "trust model"
--> that
--> >    imposes a need for configuration of some form of 
--> "shared secret" or
--> >    other configuration required to restrict access to "trusted"
--> devices.
--> > 
--> >    It is also conceivable that a minimal configuration 
--> may be required
--> >    for deployment of an initial (set of) device(s) - with 
--> subsequently
--> >    deployed devices deriving that configuration 
--> information during the
--> >    process of - for example - peer discovery.  This would 
--> constitute a
--> >    mechanism for "near zero configuration".
--> > 
--> >    Efficient Unicast Bandwidth Usage
--> > 
--> >    For unicast, non-flooded traffic, RBridges are 
--> intended to merge
--> the
--> >    efficient bandwidth use of IP routing with the simplicity of
--> Ethernet
--> >    (or 802.1) bridging for networks possibly larger - and 
--> with greater
--> >    forwarding capacity - than is the case with these networks
--> presently.
--> > 
--> >    The approach that we will use in accomplishing this is 
--> based on the
--> >    idea of extending (one or more) link state routing 
--> protocol(s) to
--> >    include distribution of Ethernet/802 reachability information
--> between
--> >    RBridge instances.
--> > 
--> > Sgai 5> "RBridge instances" is not defined.
--> > 
--> > @@@ For a document at this level, perhaps it could just say
--> "RBridges".
--> > 
--> >    In addition, there may be specific requirements
--> >    imposed on the interactions between these extensions and the
--> Spanning
--> >    Tree Protocol (STP) and between RBridge instances and 
--> (potentially
--> >    co-located) IP routing instances.
--> > 
--> >    Potentially More Efficient Multicast and Broadcast Usage
--> > 
--> >    There are clear advantages to incorporating mechanisms 
--> for improved
--> >    efficiency in forwarding (layer 2) multicast frames 
--> and - possibly
--> >    in reducing the amount of broadcast traffic as well.  
--> To the extent
--> >    that these efficiency improvements may be considered
--> "optimizations"
--> >    and may be defined orthogonally to the process of 
--> specifying basic
--> >    RBridge functionality, the potential to include these 
--> optimizations
--> >    is (highly) desirable, but not mandatory.
--> > 
--> >    Examples of this type of optimization include use of 
--> any intrinsic
--> >    multicast routing capabilities and optimizations of ARP/ND.
--> > 
--> > 
--> > 
--> > 
--> > 
--> > Gray                      Expires March, 2007             
-->     [Page 5]
--> > 
--> > Internet-Draft        TRILL Routing Requirements       
--> September, 2006
--> > 
--> > 
--> > 
--> >    Backward Compatibility
--> > 
--> >    RBridges must be fully compatible with current 
--> bridges, IPv4 and
--> >    IPv6 routers and endnodes.  They should be invisible 
--> to current IP
--> >    routers (just as bridges are), and like routers, they 
--> terminate a
--> >    bridged spanning tree.
--> > 
--> > Sgai 6> the concept of terminating a bridged spanning tree is to
--> vague,
--> > see also sgai 10.
--> > 
--> > @@@ I think that concept is generally understood to mean 
--> that they do
--> > not pass BPDUs. Perhaps "by not passing BPDUs" could be appended
--> above.
--> > 
--> >    Unlike Routers, RBridges do not terminate
--> >    a broadcast domain.
--> > 
--> > 
--> > 2. General Requirements Potentially Affecting Routing
--> > 
--> >    Candidate IGP Routing protocols - IS-IS or OSPF - must 
--> be evaluated
--> >    for compatibility with the above goals.
--> > 
--> >    For example, since IS-IS requires a unique System ID 
--> for each IS-IS
--> >    instance (at least within a "scoped" deployment), a 
--> requirement for
--> >    "(near) zero configuration" implies a need for mechanisms that
--> allow
--> >    auto-configuration and/or negotiation of these 
--> (scoped) unique IDs.
--> > 
--> >    Similar requirement must apply for OSPF as well, if selected.
--> > 
--> >    In addition, forwarding of protocol messages must be compatible
--> with
--> >    (or reasonably adaptable to) use of forwarding at 
--> layer 2, or there
--> >    must be a means for deriving suitable higher layer 
--> addresses for
--> the
--> >    purpose of protocol exchanges - without imposing the need to
--> manually
--> >    configure higher-layer addresses.
--> > 
--> > 
--> > 3. Link State Protocol Specific Requirements
--> > 
--> >    Assuming that link state routing protocols meet above 
--> requirements,
--> >    running a link state protocol among RBridges is 
--> straightforward.
--> It
--> >    is the same as running a level 1 routing protocol in 
--> an area.  This
--> >    would be theoretically true for either IS-IS or OSPF, 
--> assuming that
--> >    both of these meet the general requiremenst above.
--> > 
--> >    From the perspective of simply extending existing routing
--> protocols,
--> >    IS-IS is a more appropriate choice than OSPF because 
--> it is easy in
--> >    IS-IS to define new TLVs for use in carrying a new information
--> type.
--> > 
--> >    This document, however, does not mandate a specific link-state,
--> IGP,
--> >    routing protocol.  Instead, it sets forth the requirements that
--> will
--> >    apply to any link-state routing protocol that may be used.
--> > 
--> >    For implementations providing co-located 
--> Router/RBridge function,
--> >    it is necessary to have mechanisms for distinguishing 
--> any protocol
--> >    interactions in Routing instances from protocol 
--> interactions in the
--> >    co-located RBridge instance.  Specific mechanisms we 
--> will use are
--> >    very likely to be determined by the Link State Routing Protocol
--> that
--> > 
--> > 
--> > 
--> > Gray                      Expires March, 2007             
-->     [Page 6]
--> > 
--> > Internet-Draft        TRILL Routing Requirements       
--> September, 2006
--> > 
--> > 
--> > 
--> >    we select.  Potential distinguishing mechanisms 
--> include use of a
--> new
--> >    well-known Ethernet/802 multicast address, 
--> higher-layer protocol ID
--> >    or other - routing protocol specific - approaches.
--> > 
--> >    The mechanism chosen should be consistent with the TRILL goals.
--> If,
--> >    for example, a routing protocol specific approach 
--> required use of a
--> >    unique "area" identifier, the RBridge area identifier 
--> should be a
--> >    constant, well-known, value for all RBridges, and 
--> would not be one
--> >    that would ever appear as a real routing area 
--> identifer - in order
--> >    to allow for a potential for configuration-free operation.
--> > 
--> >    Information that RBridge link state information will carry
--> includes:
--> > 
--> >    o  layer 2 addresses of nodes within the domain which have
--> >       transmitted frames but have not transmitted ARP or 
--> ND replies
--> > 
--> >    o  layer 3, layer 2 addresses of IP nodes within the 
--> domain.  For
--> >       data compression, perhaps only the portion of the address
--> >       following the domain-wide prefix need be carried.  
--> This will be
--> >       more of an issue for IPv6 than for IPv4.
--> > 
--> >    o  VLANs directly connected to this RBridge
--> > 
--> > 
--> > Sgai 7> The discussion about VLAN needs to be much more 
--> extensive. It
--> is
--> > clear from the mailing list discussion that VLANs can be 
--> used inside
--> the
--> > packet or in the Ethernet encapsulation of TRILL. These are two
--> > different kinds of VLANs and their requirement need to be stated
--> > separately. Q in Q needs also to be discussed. I propose to define
--> inner
--> > and outer VLANs (with reference to the position of the tag in the
--> frame.
--> > 
--> > @@@ Based on the discussions that have been going on, I feel a bit
--> > clearer about VLANs than I used to. It seems hard to make 
--> a simple,
--> > brief, definiteive statement about Rbridges and VLANs, 
--> except that all
--> > the VLAN stuff needs to be configured, because there are so many
--> > different scenarios. I agree that a fairly extensive discussion of
--> VLANs
--> > should appear somewhere but I don't think this is the 
--> right document
--> for
--> > that. The requirement on the Rbridge routing expressed 
--> here is that it
--> > needs, one way or the other, to be able to handle station
--> identification
--> > not just as a MAC address but as a VLAN tag and MAC address.
--> > 
--> >    Endnode information need only be delivered to RBridges 
--> supporting
--> >    the VLAN in which the endnode resides.
--> > 
--> > Sgai 8> endnode -> station
--> > 
--> >    So, for instance, if endnode
--> >    E is discovered through a VLAN A frame, then E's 
--> location need only
--> >    be delivered to other RBridges that are attached to 
--> VLAN A links.
--> > 
--> >    Given that RBridges must support delivery only to 
--> links within a
--> VLAN
--> > 
--> >    (for multicast or unknown frames marked with the 
--> VLAN's tag), this
--> >    mechanism can be used to advertise endnode information 
--> solely to
--> the
--> >    RBridges "within" a VLAN (i.e. - having connectivity or
--> configuration
--> >    that assoicates them with a VLAN).
--> > 
--> >    Although a separate instance of
--> >    the link state protocol could be run for this purpose, 
--> the topology
--> >    is so restricted (just a single broadcast domain), 
--> that it may be
--> >    preferable to define special case mechanisms whereby each DR
--> > 
--> > sgai 9> DR? Designated RBridge???
--> > 
--> > @@@ Yes, I think it should be spelled out.
--> > 
--> >    advertises attached endnodes, and receives explicit 
--> acknolegments
--> >    from other RBridges.
--> > 
--> > 
--> > 4. Potential Issues
--> > 
--> > 4.1. Interactions with Spanning Tree Forwarding and 
--> Bridge Learning
--> > 
--> >    Spanning tree forwarding applies within parts of the RBridge
--> domain,
--> >    where two or more RBridges are connected by a link 
--> that includes
--> >    multiple 802.1 bridges.
--> > 
--> > 
--> > 
--> > 
--> > Gray                      Expires March, 2007             
-->     [Page 7]
--> > 
--> > Internet-Draft        TRILL Routing Requirements       
--> September, 2006
--> > 
--> > 
--> > 
--> >    In order to simplify the interactions between RBridges 
--> and bridges
--> -
--> >    in particular, relative to spanning tree forwarding - 
--> RBridges do
--> not
--> >    actively participate in spanning tree protocol with 
--> 802.1 bridges.
--> > 
--> > Sgai 10> "do not participate actively" can mean two 
--> different things:
--> > 1) they drop the BPDU
--> > 2) they propagate the BPDUs as regular multicast frames
--> > 
--> > can you clarify?
--> > 
--> > @@@ They block BPDUs but might do something based on 
--> their receipt.
--> > Another way to look at it is that an Rbridge with N 
--> interfaces, each
--> > connected to bridged links, looks like N different leaf 
--> nodes to the
--> > STP/RSTP running on those bridged links. (Could be N different
--> spanning
--> > trees or less than that if some of these links are connected or
--> bridged
--> > to each other.)
--> > 
--> >    Hence, from the Link State Routing protocol perspective, the
--> protocol
--> >    will be able to treat spanning tree links as 
--> indistinguishable from
--> >    any other Ethernet/802.1 link, in the same way that routing
--> protocols
--> >    do today.
--> > 
--> >    However, support for multi-pathing is potentially 
--> problematic and
--> is
--> >    assumed - in this document - to be a non-goal.  Multi-path
--> forwarding
--> >    has the potential to confound the bridge learning process.
--> > 
--> > Sgai 11> multi-pathing a non-goal? This seems to be in 
--> contradiction
--> > with what said before. Is it because of the designated RBridge?
--> > 
--> > Sgai 12> the requirement for a designated RBridge is not really
--> > discussed here. In particular there is no discussion of 
--> the property
--> of
--> > the election algorithm, which must avoid broadcast storms.
--> > 
--> > @@@ Seems like the ideal thing would be to state the 
--> requirements that
--> > having a Designated Rbridge meets rather then the 
--> mechanism of having
--> a
--> > Designated Rbridge.
--> > 
--> > @@@ Some general statement about convergence and an acceptably low
--> level
--> > of overhead traffic for all of the mechanisms associated with the
--> > routing protocol might be reasonable.
--> > 
--> > 
--> > 4.2. Computing Routes
--> > 
--> >    RBridges must calculate an L2 "route table" consisting 
--> of Next Hop
--> >    information for each known L2 unicast destination 
--> address within a
--> >    (possibly VLAN scoped) broadcast domain. This is 
--> computed using a
--> >    routing protocol's SPF algorithm and based on 
--> destination layer 2
--> >    address reachability advertisements.
--> > 
--> > Sgai 13> from the previous sentence it seems that we are 
--> computing the
--> > topology among all the MAC addresses. What we really do 
--> is compute the
--> > topology among RBridges and then tag it with reachable 
--> MAC addresses.
--> > >From the SPF perspective, it is a much easier problem.
--> > 
--> > ... snip ...
--> > 
--> > 
--> > @@@ Thanks,
--> > @@@ Donald
--> > 
--> > _______________________________________________
--> > rbridge mailing list
--> > [e-mail]
--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6IjhbR016824 for <[e-mail]>; Mon, 6 Nov 2006 10:45:44 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA6IjefK013341; Mon, 6 Nov 2006 13:45:41 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05179;  Mon, 6 Nov 2006 13:45:40 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB649K99>; Mon, 6 Nov 2006 13:45:39 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Joe Touch <[e-mail]>, Eastlake III Donald-LDE008 <[e-mail]>
Date: Mon, 6 Nov 2006 13:45:39 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] A thought about TTLs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 18:46:22 -0000
Status: RO
Content-Length: 1373

Joe,

	I tend to agree with Donald's comments (which are not included here,
because of the difficulty I have in responding to your mail generally).

	To your point, it might be possible for RBridges to use some factor
(such as +2 hops, or *2 hops) over the actual expected tunnel length, but
it is unreasonable to use any number much larger than that for the purpose
preserving frames that are taking some tortuous, but not looping, path in
a changing network.

--
Eric

Earlier, you said:
--> The whole point of a TTL is that things could change en-route, which
--> means that a rbridge might want to scope the TTL down, but this could
--> end up dropping a packet that would have had a legitimate, nonlooping
--> path that's unexpectedly longer later.
--> 
--> IMO, let the TTL be what it is - loop prevention for unicast, and
--> diameter scope for broad/multicast. Don't try to overthink it beyond
that.
--> 
--> Joe

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Joe Touch
--> Sent: Monday, November 06, 2006 1:32 AM
--> To: Eastlake III Donald-LDE008
--> Cc: [e-mail]
--> Subject: Re: [rbridge] A thought about TTLs
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6IfvRr014973 for <[e-mail]>; Mon, 6 Nov 2006 10:41:57 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 06 Nov 2006 10:41:57 -0800 (PST)
Received: from sun.com ([129.150.27.185]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 06 Nov 2006 10:41:57 -0800 (PST)
Date: Mon, 06 Nov 2006 10:41:58 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 18:42:19 -0000
Status: RO
Content-Length: 1767

I hesitate to bring this up because I don't want to reintroduce 
confusion about
"participating" in bridge spanning tree algorithm. So, please---what I'm
about to propose does NOT merge links. Bridged links still terminate at 
an RBridge.

The issue is that it can be unpleasant for two RBridges to 
simultaneously think they
are both Designated on the same link, which can happen if a bridge came up
and connected two links. Or for that matter, a repeater.

One way of making sure that a situation like that resolves very quickly,
and absolutely, is to have RBridges act like bridges on each of their ports,
with numerically lowest (i.e., highest) priority for become Root.

Now---I DO NOT MEAN that an RBridge merges the spanning trees on each of 
its ports.
The spanning tree is terminated at an RBridge. If an RBridge has 4 
ports, it will
participate in 4 independent bridge spanning tree instances.

The advantage of doing this is that we could make the Root bridge be the 
Designated
RBridge. Then if two RBridge links merged, the RBridges would notice 
immediately.
If you get usurped as bridge Root, you are also usurped as RBridge 
Designated RBridge.

Since the bridge spanning tree messages are never delayed by 
pre-forwarding delays,
this seems like it might be a nice thing to do.

It would be nice if the same RBridge that would get elected Desiganted 
RBridge in
the IS-IS link election would be elected bridge Root on that link. The 
easiest thing
would be not to bother with IS-IS priority, and have them all have the 
same priority,
with election being solely on ID. Then they can all use the lowest 
bridge root priority,
and the same RBridge would get elected bridge root on the link as would get
elected Designated RBridge on the link.

Radia



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6IcXNi013960 for <[e-mail]>; Mon, 6 Nov 2006 10:38:34 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA6IcRfK013207; Mon, 6 Nov 2006 13:38:28 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04594;  Mon, 6 Nov 2006 13:38:27 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB649KZ5>; Mon, 6 Nov 2006 13:38:26 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>, Eastlake III Donald-LDE008 <[e-mail]>, [e-mail]
Date: Mon, 6 Nov 2006 13:38:26 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 18:38:59 -0000
Status: RO
Content-Length: 7321

Silvano,

	The assertion that only fortune 500 companies are interested in
TRILL is baseless and untrue.  One reason why you may believe this is
the case, is that you are making certain assumptions about complexity
and scale of the desired solution that are equally unfounded or false.

	There is nothing that particularly prohibits definition of some
form of RBridge functionality that might be simple enough to deploy in
relatively small networks - where higher speed link are becoming more
common and wasting high speed links is also a problem.

	The types of networks you're talking about cannot realistically
operate with plug & play devices, and greater scalability is paramount.
The work we're doing in this WG is aimed at simplistic, plug & play
deployment where increased scalability is a secondary consideration.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Silvano Gai
--> Sent: Monday, November 06, 2006 1:51 AM
--> To: Eastlake III Donald-LDE008; [e-mail]
--> Subject: Re: [rbridge] Should we optimize the common case?
--> 
--> 
--> Donald,
--> 
--> The high end and the low end are extremely different.
--> 
--> The customers interested in TRILL are the Fortune 500 
--> companies. Large
--> Enterprise networks and large data centers used to run Financial,
--> Insurance, Health, Chemical, Oil, Information and manufacturing
--> companies.
--> 
--> They have huge demand for high bandwidth and low latency.
--> 
--> Each of these companies spends millions each year in 
--> network operation
--> (OPEX) and millions in new equipment (CAPEX). In all of them OPEX is
--> much larger than CAPEX. They only buy major vendor 
--> equipments and they
--> install them according to the recommended vendor design guideline.
--> Typically they have an internal certification lab in which 
--> they test the
--> network configuration and the software releases before 
--> putting them in
--> production networks.
--> 
--> They have a very well defined concept of backbone ports and access
--> ports. All the backbone ports are in fiber at the highest 
--> possible speed
--> (today 10 GE). For the access port they use a mix of fiber 
--> and copper.
--> The backbone has a regular structure that matches the vendor design
--> guideline and the result of the certification experiment 
--> they have done
--> independently.
--> 
--> A network outage can cost millions/hour. 
--> 
--> There is no way you will see in one of these backbones a hub or any
--> other uncontrolled device. NEVER. 
--> 
--> That is the reason why I think this is the most important case for
--> TRILL.
--> 
--> More inline.
--> 
--> > -----Original Message-----
--> > From: [e-mail] 
--> [mailto:[e-mail]]
--> On
--> > Behalf Of Eastlake III Donald-LDE008
--> > Sent: Sunday, November 05, 2006 10:20 PM
--> > To: [e-mail]
--> > Subject: Re: [rbridge] Should we optimize the common case?
--> > 
--> > Silvano,
--> > 
--> > Why do you think that 90% of Rbridge deployment will be for this
--> unusual
--> > case? I mean, I have no problem with the belief that 
--> Rbridges would be
--> > better than bridges in this case but why shouldn't that be true of
--> less
--> > high end uses?
--> > 
--> > A while ago on this list I posted a rhetorical question as to why
--> > Rbriges shouldn't eventually replace all bridges. No one posted an
--> > answer.
--> 
--> This technology will start in the high end and move down to 
--> the lower
--> end. How low will it goes is a good question. 
--> 
--> The low end is extremely cost sensitive. When we buys a switch or a
--> router on the Internet for 50-100$, the COGS cannot be more 
--> that 15-30$,
--> even with low margins. This implies that few dollar more to 
--> increase the
--> memory size or the processor speed are a big deal. Add software
--> development cost. Couple this with the fact that today we 
--> have low cost
--> 1GE switches used by low-end users that have problems 
--> pushing or pulling
--> more than few Mb/s. There is no bandwidth demand in the low end.
--> Spanning tree is just fine. Cost is the big issue. Moreover 
--> there is the
--> huge issue of training home/small office installers in this new
--> technology.
--> 
--> My 0.2 cents
--> 
--> -- Silvano
--> 
--> > 
--> > Why not specify Rbridges more or less as we have been for 
--> the common
--> > bridge case and, in the backbone case you are talking 
--> about, just drop
--> > the MAC addresses on the point-to-point links within the backbone?
--> > Doesn't that produce less overhead than your proposal 
--> below in both
--> the
--> > point-to-point and shared media cases?
--> > 
--> > Donald
--> > 
--> > -----Original Message-----
--> > From: [e-mail] 
--> [mailto:[e-mail]]
--> On
--> > Behalf Of Silvano Gai
--> > Sent: Wednesday, November 01, 2006 9:07 PM
--> > To: [e-mail]
--> > Subject: [rbridge] Should we optimize the common case?
--> > 
--> > 
--> > With 16 bit addresses the current TRILL overhead over 
--> Ethernet is 20
--> > bytes. If we want to expand the RBridge addresses, it we 
--> will go to
--> > 22-24 bytes.
--> > 
--> > What customers are telling us is that they will deploy RBridges by
--> > creating an RBridge backbone in which all the links will be 10GE.
--> > 
--> > They will connect regular bridges and host to the 
--> periphery of this
--> > backbone.
--> > 
--> > They will not mix backbone ports with access ports, because this
--> screws
--> > up management, traffic engineering, debugging, and 
--> troubleshooting.
--> > Regular network design, easy to understand, is very 
--> important. Ports
--> are
--> > cheap, labor is expensive.
--> > 
--> > I am totally convinced that this will account for 90+ % of TRILL
--> > deployment.
--> > 
--> > I am wondering if it makes sense to have a solution 
--> highly optimized
--> for
--> > such an environment.
--> > 
--> > For example we can put the egress/ingress RBridge addresses in the
--> outer
--> > MAC addresses and define a TRILL shim header that 
--> contains 1 byte of
--> hop
--> > limit and 1 byte reserved. For this common case we will get:
--> > 1) overhead of 16 bytes (4 to 8 bytes lower)
--> > 2) nickname = MAC address, i.e no hash collision
--> > 3) zero-conf achieved
--> > 
--> > In the case we need to go over a shared media we will need to add
--> > another Ethernet encapsulation to carry the next hop 
--> address, i.e. 14
--> > bytes
--> > - total overhead will be 30 bytes
--> > 
--> > Summarizing:
--> > - current proposal 20-24 bytes overhead
--> > - new proposal on point to point: 16 bytes
--> > - new proposal on shared media: 30 bytes
--> > 
--> > Comments?
--> > 
--> > -- Silvano
--> > 
--> > 
--> > _______________________________________________
--> > rbridge mailing list
--> > [e-mail]
--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> > 
--> > _______________________________________________
--> > rbridge mailing list
--> > [e-mail]
--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6IDnhN004533 for <[e-mail]>; Mon, 6 Nov 2006 10:13:49 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 06 Nov 2006 10:13:47 -0800 (PST)
Received: from sun.com ([129.150.27.185]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 06 Nov 2006 10:13:47 -0800 (PST)
Date: Mon, 06 Nov 2006 10:13:48 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Eastlake III Donald-LDE008 <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 18:14:24 -0000
Status: RO
Content-Length: 3111

Yes, if there are two RBridges that can figure out they have a point to 
point link between them, it seems
like it would be good to drop the outer header, since there's really no 
information there.

Is there a way to automatically know this is definitely a pt-to-pt 
Ethernet link and not a shared link?

Radia

Eastlake III Donald-LDE008 wrote:

>Silvano,
>
>Why do you think that 90% of Rbridge deployment will be for this unusual
>case? I mean, I have no problem with the belief that Rbridges would be
>better than bridges in this case but why shouldn't that be true of less
>high end uses?
>
>A while ago on this list I posted a rhetorical question as to why
>Rbriges shouldn't eventually replace all bridges. No one posted an
>answer.
>
>Why not specify Rbridges more or less as we have been for the common
>bridge case and, in the backbone case you are talking about, just drop
>the MAC addresses on the point-to-point links within the backbone?
>Doesn't that produce less overhead than your proposal below in both the
>point-to-point and shared media cases?
>
>Donald
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
>Behalf Of Silvano Gai
>Sent: Wednesday, November 01, 2006 9:07 PM
>To: [e-mail]
>Subject: [rbridge] Should we optimize the common case?
>
>
>With 16 bit addresses the current TRILL overhead over Ethernet is 20
>bytes. If we want to expand the RBridge addresses, it we will go to
>22-24 bytes.
>
>What customers are telling us is that they will deploy RBridges by
>creating an RBridge backbone in which all the links will be 10GE.
>
>They will connect regular bridges and host to the periphery of this
>backbone. 
>
>They will not mix backbone ports with access ports, because this screws
>up management, traffic engineering, debugging, and troubleshooting.
>Regular network design, easy to understand, is very important. Ports are
>cheap, labor is expensive.
>
>I am totally convinced that this will account for 90+ % of TRILL
>deployment. 
>
>I am wondering if it makes sense to have a solution highly optimized for
>such an environment.
>
>For example we can put the egress/ingress RBridge addresses in the outer
>MAC addresses and define a TRILL shim header that contains 1 byte of hop
>limit and 1 byte reserved. For this common case we will get:
>1) overhead of 16 bytes (4 to 8 bytes lower)
>2) nickname = MAC address, i.e no hash collision
>3) zero-conf achieved
>
>In the case we need to go over a shared media we will need to add
>another Ethernet encapsulation to carry the next hop address, i.e. 14
>bytes
>- total overhead will be 30 bytes
>
>Summarizing:
>- current proposal 20-24 bytes overhead
>- new proposal on point to point: 16 bytes
>- new proposal on shared media: 30 bytes
>
>Comments?
>
>-- Silvano
>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>



Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA6HcMmp021439 for <[e-mail]>; Mon, 6 Nov 2006 09:38:22 -0800 (PST)
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 06 Nov 2006 09:37:45 -0800
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAJr+TkWrR7MV/2dsb2JhbAA
X-IronPort-AV: i="4.09,392,1157353200";  d="scan'208"; a="1862317190:sNHT47363334"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6HbjuQ003676 for <[e-mail]>; Mon, 6 Nov 2006 09:37:45 -0800
Received: from [10.21.97.113] (sjc-vpn1-369.cisco.com [10.21.97.113]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA6Hbhin006724 for <[e-mail]>; Mon, 6 Nov 2006 09:37:44 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 06 Nov 2006 09:37:46 -0800
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0b1pre (X11/20060921)
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=3647; t=1162834665; x=1163698665; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:Dinesh=20G=20Dutt=20<[e-mail]> |Subject:Comments=20on=20draft-ietf-trill-prob-01.txt=20; X=v=3Dcisco.com=3B=20h=3D0MzfsX3++OXWptQ6XCjlPxYpKWE=3D; b=kY2B8ylrDqURTZnLCNTt5DM4m/ulu9ZJLI19KOg8LaTX5hYY9QhTJhz68Yjs/e5tukHpWunz SV3YieukXOp77kFlJPKq/29NYQMO0Lobmb7TqUMBsUh3QBwdtxa3d/2d;
Authentication-Results: sj-dkim-1.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Comments on draft-ietf-trill-prob-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 17:38:50 -0000
Status: RO
Content-Length: 3567

Hi,

Here are some comments based on the last call for 
draft-ietf-trill-prob-01.txt. Some general comments first.

- From my understanding of spanning tree, I think the document has 
multiple inaccuracies about the spanning tree protocol used in current 
802.1D bridges:
    - First, there is an assumption that there can be transient loops 
with spanning tree (Section 3.3). This is quite untrue. There is no 
chance of loops with spanning tree. There can be poor implementations or 
bugs that can cause loops, but spanning tree protocol itself cannot 
create loops.
    - Second, the convergence time of spanning tree is quite impressive 
these days, thanks to Rapid Spanning Tree (802.1w). It is in the order 
of sub-second.
    - Backup paths (section 2.3) have been deployed quite widely in 
Cisco switches using "uplinkfast" enhancement to STP.

- There is an incorrect use of terminology or concepts from IEEE 
standards. There has been extensive discussion on the mailing list about 
this. Some examples in this document:
    - Use of "cache", say in section 2.5. The correct terminology is 
"filtering database"
    - You talk about "autolearning" in section 3.1. I don't think the 
802.1D standard talks about "autolearning" What do you mean ?

More specific comments:

- You mention 802.1D as "Other Ethernet Extensions" (section 2.4) after 
having talked about spanning tree this far. 802.1D is the basic bridging 
standard and so is incorrect to refer to it under the section titled 
"Other Ethernet extensions".

- Section 2.4: There is no mention of other Ethernet protocols such as 
802.1au (Congestion Notification), 802.3ad (Link Aggregation), 802.3x 
(PAUSE). What is the relation of TRILL to these protocols ?

- Section 2.5:I don't know were these number come from, but with 256/512 
ports Ethernet switches available, it does not take 10,000 bridges to 
reach 100,000 nodes. I also don't understand if the mention of 1,000 
VLANs is intended as a limit. Many customers don't have enough of 4,000 
VLANs and deploy private VLANs.

- Section 2.5: You state: "Similar challenges exist in the ARP protocol, 
where link layer forwarding is not updated appropriately when nodes move 
to ports on other bridges. Again, the compartmentalization available in 
network routing, like that of network layer ASes, can help hide the 
effect of migration"

    I don't understand this para.

- Section 3.1: Please include that there must be support for non-IP 
protocols that are currently supported by Ethernet bridges.

- Section 3.2: Use of VLANs in TRILL needs to be clarified. For example, 
there can be a VLAN tag in the outer MAC header as well as the inner 
MAC. Again, this has been the subject of extensive discussion on the 
mailing list.

- Section 3.2: What about VLAN pruning ? Should that be supported as 
well by TRILL ?

- Section 3.3: Use of TTL alone isn't sufficient to fix problems caused 
by transient loops during topology changes. Again, this has been the 
subject of intense discussion on the mailing list. A form of interlock 
protocol must ensure that there are no transient broadcast or multicast 
loops during topology changes.

- Section 3.4: Interaction with spanning tree protocol as discussed 
under the subject "Traffic Storms" should be included here.

- Section 3.4: Please include RSTP in the list of protocols that cannot 
be modified. Current list is only STP & MSTP.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA66ov3v027851 for <[e-mail]>; Sun, 5 Nov 2006 22:50:57 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 5 Nov 2006 22:50:52 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: Acb+CctJWWSUxrynQDqF9Hp6UwHrYwAFvk2wAKANoQAAMxa3UA==
From: "Silvano Gai" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA66ov3v027851
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 06:51:24 -0000
Status: RO
Content-Length: 5275

Donald,

The high end and the low end are extremely different.

The customers interested in TRILL are the Fortune 500 companies. Large
Enterprise networks and large data centers used to run Financial,
Insurance, Health, Chemical, Oil, Information and manufacturing
companies.

They have huge demand for high bandwidth and low latency.

Each of these companies spends millions each year in network operation
(OPEX) and millions in new equipment (CAPEX). In all of them OPEX is
much larger than CAPEX. They only buy major vendor equipments and they
install them according to the recommended vendor design guideline.
Typically they have an internal certification lab in which they test the
network configuration and the software releases before putting them in
production networks.

They have a very well defined concept of backbone ports and access
ports. All the backbone ports are in fiber at the highest possible speed
(today 10 GE). For the access port they use a mix of fiber and copper.
The backbone has a regular structure that matches the vendor design
guideline and the result of the certification experiment they have done
independently.

A network outage can cost millions/hour. 

There is no way you will see in one of these backbones a hub or any
other uncontrolled device. NEVER. 

That is the reason why I think this is the most important case for
TRILL.

More inline.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Sunday, November 05, 2006 10:20 PM
> To: [e-mail]
> Subject: Re: [rbridge] Should we optimize the common case?
> 
> Silvano,
> 
> Why do you think that 90% of Rbridge deployment will be for this
unusual
> case? I mean, I have no problem with the belief that Rbridges would be
> better than bridges in this case but why shouldn't that be true of
less
> high end uses?
> 
> A while ago on this list I posted a rhetorical question as to why
> Rbriges shouldn't eventually replace all bridges. No one posted an
> answer.

This technology will start in the high end and move down to the lower
end. How low will it goes is a good question. 

The low end is extremely cost sensitive. When we buys a switch or a
router on the Internet for 50-100$, the COGS cannot be more that 15-30$,
even with low margins. This implies that few dollar more to increase the
memory size or the processor speed are a big deal. Add software
development cost. Couple this with the fact that today we have low cost
1GE switches used by low-end users that have problems pushing or pulling
more than few Mb/s. There is no bandwidth demand in the low end.
Spanning tree is just fine. Cost is the big issue. Moreover there is the
huge issue of training home/small office installers in this new
technology.

My 0.2 cents

-- Silvano

> 
> Why not specify Rbridges more or less as we have been for the common
> bridge case and, in the backbone case you are talking about, just drop
> the MAC addresses on the point-to-point links within the backbone?
> Doesn't that produce less overhead than your proposal below in both
the
> point-to-point and shared media cases?
> 
> Donald
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Silvano Gai
> Sent: Wednesday, November 01, 2006 9:07 PM
> To: [e-mail]
> Subject: [rbridge] Should we optimize the common case?
> 
> 
> With 16 bit addresses the current TRILL overhead over Ethernet is 20
> bytes. If we want to expand the RBridge addresses, it we will go to
> 22-24 bytes.
> 
> What customers are telling us is that they will deploy RBridges by
> creating an RBridge backbone in which all the links will be 10GE.
> 
> They will connect regular bridges and host to the periphery of this
> backbone.
> 
> They will not mix backbone ports with access ports, because this
screws
> up management, traffic engineering, debugging, and troubleshooting.
> Regular network design, easy to understand, is very important. Ports
are
> cheap, labor is expensive.
> 
> I am totally convinced that this will account for 90+ % of TRILL
> deployment.
> 
> I am wondering if it makes sense to have a solution highly optimized
for
> such an environment.
> 
> For example we can put the egress/ingress RBridge addresses in the
outer
> MAC addresses and define a TRILL shim header that contains 1 byte of
hop
> limit and 1 byte reserved. For this common case we will get:
> 1) overhead of 16 bytes (4 to 8 bytes lower)
> 2) nickname = MAC address, i.e no hash collision
> 3) zero-conf achieved
> 
> In the case we need to go over a shared media we will need to add
> another Ethernet encapsulation to carry the next hop address, i.e. 14
> bytes
> - total overhead will be 30 bytes
> 
> Summarizing:
> - current proposal 20-24 bytes overhead
> - new proposal on point to point: 16 bytes
> - new proposal on shared media: 30 bytes
> 
> Comments?
> 
> -- Silvano
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA66W218022840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Sun, 5 Nov 2006 22:32:02 -0800 (PST)
Received: from [75.214.47.91] (91.sub-75-214-47.myvzw.com [75.214.47.91]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kA66Vept006872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 5 Nov 2006 22:31:44 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sun, 05 Nov 2006 22:31:40 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Eastlake III Donald-LDE008 <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig17CDDF7AE0F80163787BDBED"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] A thought about TTLs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 06:32:20 -0000
Status: RO
Content-Length: 2295

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

The whole point of a TTL is that things could change en-route, which
means that a rbridge might want to scope the TTL down, but this could
end up dropping a packet that would have had a legitimate, nonlooping
path that's unexpectedly longer later.

IMO, let the TTL be what it is - loop prevention for unicast, and
diameter scope for broad/multicast. Don't try to overthink it beyond that=
=2E

Joe

Eastlake III Donald-LDE008 wrote:
> Rbridges are in a fundamentally different position in deciding shim TTL=
s
> than IP hosts are in deciding IP TTLs. In particular, a host knows
> almost nothing about the routing situation while an Rbridge has explici=
t
> link state information.
>=20
> Thus it would be reasonable to recommend a TTL based on the expected
> number of hops for unicast or maximum expected number of hops for
> multicast/broadcast/flooded or on the diameter of the network (maximum
> number of Rbridge-Rbridge hops for the two most distant Rbridges) or th=
e
> like ... It would even be possible to have Rbridges trim back the TTL
> for the copy forwarding to a particularly short branch of a tree or eve=
n
> when forwarding along a unicast path if that path has gotten shorter.
> Such adjustment is probably too much work to mandate but it seems to me=

> that it should be allowable behavior.
>=20
> Thanks,
> Donald
>=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge

--=20
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment


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

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

iD8DBQFFTtbQE5f5cImnZrsRApiIAJ9LFk05Df1y3tg6ZbHwyhh/Hrd6AgCgqeou
SFkQl4e/sX51+Z15kqkYkLo=
=go+A
-----END PGP SIGNATURE-----

--------------enig17CDDF7AE0F80163787BDBED--


Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id kA66JsbA019211 for <[e-mail]>; Sun, 5 Nov 2006 22:19:54 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-4.tower-119.messagelabs.com!1162793993!9278160!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.9]
Received: (qmail 23918 invoked from network); 6 Nov 2006 06:19:53 -0000
Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-4.tower-119.messagelabs.com with SMTP; 6 Nov 2006 06:19:53 -0000
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id kA66Jqpj011342 for <[e-mail]>; Mon, 6 Nov 2006 00:19:53 -0600 (CST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id kA66JpZQ002673 for <[e-mail]>; Mon, 6 Nov 2006 00:19:52 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 6 Nov 2006 01:19:46 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Should we optimize the common case?
Thread-Index: Acb+CctJWWSUxrynQDqF9Hp6UwHrYwAFvk2wAKANoQA=
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA66JsbA019211
Subject: Re: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 06:20:20 -0000
Status: RO
Content-Length: 2538

Silvano,

Why do you think that 90% of Rbridge deployment will be for this unusual
case? I mean, I have no problem with the belief that Rbridges would be
better than bridges in this case but why shouldn't that be true of less
high end uses?

A while ago on this list I posted a rhetorical question as to why
Rbriges shouldn't eventually replace all bridges. No one posted an
answer.

Why not specify Rbridges more or less as we have been for the common
bridge case and, in the backbone case you are talking about, just drop
the MAC addresses on the point-to-point links within the backbone?
Doesn't that produce less overhead than your proposal below in both the
point-to-point and shared media cases?

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Silvano Gai
Sent: Wednesday, November 01, 2006 9:07 PM
To: [e-mail]
Subject: [rbridge] Should we optimize the common case?


With 16 bit addresses the current TRILL overhead over Ethernet is 20
bytes. If we want to expand the RBridge addresses, it we will go to
22-24 bytes.

What customers are telling us is that they will deploy RBridges by
creating an RBridge backbone in which all the links will be 10GE.

They will connect regular bridges and host to the periphery of this
backbone. 

They will not mix backbone ports with access ports, because this screws
up management, traffic engineering, debugging, and troubleshooting.
Regular network design, easy to understand, is very important. Ports are
cheap, labor is expensive.

I am totally convinced that this will account for 90+ % of TRILL
deployment. 

I am wondering if it makes sense to have a solution highly optimized for
such an environment.

For example we can put the egress/ingress RBridge addresses in the outer
MAC addresses and define a TRILL shim header that contains 1 byte of hop
limit and 1 byte reserved. For this common case we will get:
1) overhead of 16 bytes (4 to 8 bytes lower)
2) nickname = MAC address, i.e no hash collision
3) zero-conf achieved

In the case we need to go over a shared media we will need to add
another Ethernet encapsulation to carry the next hop address, i.e. 14
bytes
- total overhead will be 30 bytes

Summarizing:
- current proposal 20-24 bytes overhead
- new proposal on point to point: 16 bytes
- new proposal on shared media: 30 bytes

Comments?

-- Silvano


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



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA66GHW0017583 for <[e-mail]>; Sun, 5 Nov 2006 22:16:17 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 5 Nov 2006 22:16:10 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] WG last call commentsto:http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt
Thread-Index: Acb7fuQbcgNuaYWOR0u0ehoeYYH/5AFiKyMgABiawIA=
From: "Silvano Gai" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA66GHW0017583
Subject: Re: [rbridge] WG last call commentsto:http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 06:17:25 -0000
Status: RO
Content-Length: 19991

Donald,

I think I agree with most of your comments, with one big exception.

I am not able to see the difference between "dropping a BPDU" or
"ignoring a BPDU".

IMO there are two possibilities:
1) we drop BPDUs
2) we process BPDUs

If we do 2), we can:
2.1) process BPDU using STP/RSTP
2.2) do other processing on the BPDU, not STP/RSTP related

If we don't want to do 2.1), let's just say it.
If we need to do 2.2), it is better we spell it out clearly, and not
hide it behind the word "ignore BPDUs".

This is such a crucial point to achieve:
a) Interoperability
b) A robust implementation

that we don't want to be vaguely defined.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Sunday, November 05, 2006 3:22 PM
> To: [e-mail]
> Subject: Re: [rbridge] WG last call
>
commentsto:http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-
> reqs-00.txt
> 
> Hi Silvano,
> 
> I think I agree with most of your comments but see a few notes at @@@
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Silvano Gai
> Sent: Sunday, October 29, 2006 12:23 PM
> To: [e-mail]
> Subject: [rbridge] WG last call comments
>
to:http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.
> txt
> 
> Comments inline marked "sgai n>"
> 
> -- Silvano
> 
> --------------------------------------------------------
> 
> ... snip ...
> 
> 1. Introduction
> 
>    The current dominant approach to segregating network traffic relies
>    on a hierarchical arrangement of bridges and routers.  Hierarchy is
>    further extended - both within routing protocols (such as IS-IS and
>    OSPF) and between routing protocols (for example, between IGPs and
>    BGP).  At least part of the current network structure is based on a
>    determined trade-off between limitations of IP routing and similar
>    disadvantages of 802 bridging.
> 
>    Bridging Limitations
> 
>    For example, bridged networks consist of single broadcast/flooding
>    domains.  Ethernet/802 encapsulation (on which bridging is based)
>    does not provide mechanisms for reducing the impact of looping data
>    traffic that may result from a transient change in network topology
>    and the existence of multiple paths.
> 
>    The impact of looping traffic is far worse with flooded or
broadcast
>    traffic as this results in exponentially increasing traffic load.
>    Consideration of the impacts of looping data lead to the use of
>    STP/RSTP to establish a connected - loop free - tree by disabling
>    forwarding on a subset of links that might create a loop.  This has
>    also the effect of eliminating redundant paths.
> 
> @@@ Also generally lowers aggregate throughput and increases latency
> through the net due to frames following suboptimal paths.
> 
>    Because of the potential for severe impact from looping traffic,
>    many (if not most) current bridge implementations stop forwarding
of
>    traffic frames following a topology change event and restart only
>    after STP/RSTP is complete.
> 
> Sgai 1> In STP there is no way of knowing when the convergence has
been
> achieved; a bridge does not know or care about the timers of other
> bridges. The state machines on the ports are run independently. If you
> refer to the Topology Change Notification Flag, its purpose is to
reduce
> the filtering database ageing time, not to signal if STP/RSTP is
> complete.
> 
>    As a result, the process of eliminating potential loops in existing
>    bridging deployments:
> 
>      1) Results in inefficient use of inter-bridge connections
>         and
>      2) Causes delays in forwarding traffic as a result of
>         changes in the network topology.
> 
> Sgai 2> 2) is not true in the RSTP case; as a matter of fact RSTP is
the
> fastest converging protocol available today.
> 
> @@@ I'm not sure why this and other documents put the emphasis they do
> on STP/RSTP convergence. Of course it depends some on just how
STP/RSTP
> is implemented and how other algorithms are implemented. Perhaps it
> stems from, as was pointed out early in the Rbridge effort, that the
> replacement of bridges with Rbrides typically divides what would have
> been one large spanning tree domain into a number of smaller ones
> interconnected by Rbridges. The STP/RSTP protocol within these small
> spanning tree domains will typically converge for them all in parallel
> more rapidly than the pre-existing larger single spanning tree
STP/RSTP
> convergence.
> 
>    The combined effect of broadcast/flooding traffic, and the use of
>    spanning trees for loop avoidance, sets practical limits on bridged
>    network size in the network hierarchy and results in inefficient
>    bandwidth use of inter-bridge connections. Inefficient inter-bridge
>    connection usage similarly limits the usefulness of bridging with
>    high-speed (and consequently high cost) interfaces.
> 
> 
> 
> 
> 
> 
> 
> Gray                      Expires March, 2007                 [Page 3]
> 
> Internet-Draft        TRILL Routing Requirements       September, 2006
> 
> 
>    IP Routing Issues
> 
>    For IP routed networks, any link (or subnet) must have at least one
>    unique prefix. This means that a node that moves from one IP subnet
> 
> sgai 3> in the case of IP instead of "node" is better to speak of
> "interface". It is the interface that has an address, not the node.
> 
>    to another must change its IP address. Also, nodes with multiple IP
>    subnet attachments must have multiple IP addresses.  In IP routed
>    networks, there are frequent trade-off considerations between using
>    smaller subnets (longer prefix length) to minimize wasted IP
address
>    space (as a result of unused addresses in the fixed address range
>    defined by the prefix and length) and using larger subnets (shorter
>    prefix length) to minimize the need for (changes in) configuration.
> 
>    In any case - with current IP routing technology - subnets must be
>    configured for each routed interface.
> 
>    Proposed Solution
> 
>    Using a hybrid of routing and bridging - an RBridge - we hope to
>    gain the benefits of both technologies, in particular, gaining the
>    bandwidth advantages of shortest path routing while retaning the
>    simplified configuration associated with bridging.
> 
> 1.1. Terminology
> 
>    The following terms are used in this document in the way that
>    they are defined in "TRILL RBridge Architecture" [TARCH]:
> 
>      ARP (Address Resolution Protocol)
>      Bridge Learning
>      Broadcast Domain
>      Broadcast Traffic
>      Cooperating RBridges
>      Egress RBridge
>      Ethernet
>      Flooded Traffic
>      Flooding
>      Frame
>      IGP (Interior Gateway Protocol)
>      Ingress RBridge
>      Ingress RBridge Tree
>      IS-IS (Intermediate System to Intermediate System)
>      ND (Neighbor Discovery)
>      OSPF (Open Shortest Path First)
>      Packet
> 
> Sgai 4> in the case of layer 2 networks is more appropriate to use the
> term frame, instead of packet.
> 
> @@@ Frame appears earlier in this list and I believe that both are
> properly defined in the architecture document.
> 
>      RBridge
>      SPF (Shortest Path First)
>      STP/RSTP (Spanning Tree Protocol/Rapid Spanning Tree Protocol)
>      TRILL (TRansport Interconnect over Lots of Links)
>      Unknown Destination
>      VLAN (Virtual Local Area Network)
> 
> 
> Gray                      Expires March, 2007                 [Page 4]
> 
> Internet-Draft        TRILL Routing Requirements       September, 2006
> 
> 
> 
> 1.2. Specific TRILL Goals
> 
>    (Near) Zero Configuration
> 
>    It is a TRILL requirement that it must be possible to deploy
RBridges
>    in at least a nominal set of potential deployment scenarios without
a
>    need to perform any configuration at each RBridge.  It is possible
to
>    meet this goal for a sub-set of all possible deployment scenarios
by
>    making realistic restrictions on deployment - such as restricting
the
>    deployment scenarios to exclude those involving a "trust model"
that
>    imposes a need for configuration of some form of "shared secret" or
>    other configuration required to restrict access to "trusted"
devices.
> 
>    It is also conceivable that a minimal configuration may be required
>    for deployment of an initial (set of) device(s) - with subsequently
>    deployed devices deriving that configuration information during the
>    process of - for example - peer discovery.  This would constitute a
>    mechanism for "near zero configuration".
> 
>    Efficient Unicast Bandwidth Usage
> 
>    For unicast, non-flooded traffic, RBridges are intended to merge
the
>    efficient bandwidth use of IP routing with the simplicity of
Ethernet
>    (or 802.1) bridging for networks possibly larger - and with greater
>    forwarding capacity - than is the case with these networks
presently.
> 
>    The approach that we will use in accomplishing this is based on the
>    idea of extending (one or more) link state routing protocol(s) to
>    include distribution of Ethernet/802 reachability information
between
>    RBridge instances.
> 
> Sgai 5> "RBridge instances" is not defined.
> 
> @@@ For a document at this level, perhaps it could just say
"RBridges".
> 
>    In addition, there may be specific requirements
>    imposed on the interactions between these extensions and the
Spanning
>    Tree Protocol (STP) and between RBridge instances and (potentially
>    co-located) IP routing instances.
> 
>    Potentially More Efficient Multicast and Broadcast Usage
> 
>    There are clear advantages to incorporating mechanisms for improved
>    efficiency in forwarding (layer 2) multicast frames and - possibly
>    in reducing the amount of broadcast traffic as well.  To the extent
>    that these efficiency improvements may be considered
"optimizations"
>    and may be defined orthogonally to the process of specifying basic
>    RBridge functionality, the potential to include these optimizations
>    is (highly) desirable, but not mandatory.
> 
>    Examples of this type of optimization include use of any intrinsic
>    multicast routing capabilities and optimizations of ARP/ND.
> 
> 
> 
> 
> 
> Gray                      Expires March, 2007                 [Page 5]
> 
> Internet-Draft        TRILL Routing Requirements       September, 2006
> 
> 
> 
>    Backward Compatibility
> 
>    RBridges must be fully compatible with current bridges, IPv4 and
>    IPv6 routers and endnodes.  They should be invisible to current IP
>    routers (just as bridges are), and like routers, they terminate a
>    bridged spanning tree.
> 
> Sgai 6> the concept of terminating a bridged spanning tree is to
vague,
> see also sgai 10.
> 
> @@@ I think that concept is generally understood to mean that they do
> not pass BPDUs. Perhaps "by not passing BPDUs" could be appended
above.
> 
>    Unlike Routers, RBridges do not terminate
>    a broadcast domain.
> 
> 
> 2. General Requirements Potentially Affecting Routing
> 
>    Candidate IGP Routing protocols - IS-IS or OSPF - must be evaluated
>    for compatibility with the above goals.
> 
>    For example, since IS-IS requires a unique System ID for each IS-IS
>    instance (at least within a "scoped" deployment), a requirement for
>    "(near) zero configuration" implies a need for mechanisms that
allow
>    auto-configuration and/or negotiation of these (scoped) unique IDs.
> 
>    Similar requirement must apply for OSPF as well, if selected.
> 
>    In addition, forwarding of protocol messages must be compatible
with
>    (or reasonably adaptable to) use of forwarding at layer 2, or there
>    must be a means for deriving suitable higher layer addresses for
the
>    purpose of protocol exchanges - without imposing the need to
manually
>    configure higher-layer addresses.
> 
> 
> 3. Link State Protocol Specific Requirements
> 
>    Assuming that link state routing protocols meet above requirements,
>    running a link state protocol among RBridges is straightforward.
It
>    is the same as running a level 1 routing protocol in an area.  This
>    would be theoretically true for either IS-IS or OSPF, assuming that
>    both of these meet the general requiremenst above.
> 
>    From the perspective of simply extending existing routing
protocols,
>    IS-IS is a more appropriate choice than OSPF because it is easy in
>    IS-IS to define new TLVs for use in carrying a new information
type.
> 
>    This document, however, does not mandate a specific link-state,
IGP,
>    routing protocol.  Instead, it sets forth the requirements that
will
>    apply to any link-state routing protocol that may be used.
> 
>    For implementations providing co-located Router/RBridge function,
>    it is necessary to have mechanisms for distinguishing any protocol
>    interactions in Routing instances from protocol interactions in the
>    co-located RBridge instance.  Specific mechanisms we will use are
>    very likely to be determined by the Link State Routing Protocol
that
> 
> 
> 
> Gray                      Expires March, 2007                 [Page 6]
> 
> Internet-Draft        TRILL Routing Requirements       September, 2006
> 
> 
> 
>    we select.  Potential distinguishing mechanisms include use of a
new
>    well-known Ethernet/802 multicast address, higher-layer protocol ID
>    or other - routing protocol specific - approaches.
> 
>    The mechanism chosen should be consistent with the TRILL goals.
If,
>    for example, a routing protocol specific approach required use of a
>    unique "area" identifier, the RBridge area identifier should be a
>    constant, well-known, value for all RBridges, and would not be one
>    that would ever appear as a real routing area identifer - in order
>    to allow for a potential for configuration-free operation.
> 
>    Information that RBridge link state information will carry
includes:
> 
>    o  layer 2 addresses of nodes within the domain which have
>       transmitted frames but have not transmitted ARP or ND replies
> 
>    o  layer 3, layer 2 addresses of IP nodes within the domain.  For
>       data compression, perhaps only the portion of the address
>       following the domain-wide prefix need be carried.  This will be
>       more of an issue for IPv6 than for IPv4.
> 
>    o  VLANs directly connected to this RBridge
> 
> 
> Sgai 7> The discussion about VLAN needs to be much more extensive. It
is
> clear from the mailing list discussion that VLANs can be used inside
the
> packet or in the Ethernet encapsulation of TRILL. These are two
> different kinds of VLANs and their requirement need to be stated
> separately. Q in Q needs also to be discussed. I propose to define
inner
> and outer VLANs (with reference to the position of the tag in the
frame.
> 
> @@@ Based on the discussions that have been going on, I feel a bit
> clearer about VLANs than I used to. It seems hard to make a simple,
> brief, definiteive statement about Rbridges and VLANs, except that all
> the VLAN stuff needs to be configured, because there are so many
> different scenarios. I agree that a fairly extensive discussion of
VLANs
> should appear somewhere but I don't think this is the right document
for
> that. The requirement on the Rbridge routing expressed here is that it
> needs, one way or the other, to be able to handle station
identification
> not just as a MAC address but as a VLAN tag and MAC address.
> 
>    Endnode information need only be delivered to RBridges supporting
>    the VLAN in which the endnode resides.
> 
> Sgai 8> endnode -> station
> 
>    So, for instance, if endnode
>    E is discovered through a VLAN A frame, then E's location need only
>    be delivered to other RBridges that are attached to VLAN A links.
> 
>    Given that RBridges must support delivery only to links within a
VLAN
> 
>    (for multicast or unknown frames marked with the VLAN's tag), this
>    mechanism can be used to advertise endnode information solely to
the
>    RBridges "within" a VLAN (i.e. - having connectivity or
configuration
>    that assoicates them with a VLAN).
> 
>    Although a separate instance of
>    the link state protocol could be run for this purpose, the topology
>    is so restricted (just a single broadcast domain), that it may be
>    preferable to define special case mechanisms whereby each DR
> 
> sgai 9> DR? Designated RBridge???
> 
> @@@ Yes, I think it should be spelled out.
> 
>    advertises attached endnodes, and receives explicit acknolegments
>    from other RBridges.
> 
> 
> 4. Potential Issues
> 
> 4.1. Interactions with Spanning Tree Forwarding and Bridge Learning
> 
>    Spanning tree forwarding applies within parts of the RBridge
domain,
>    where two or more RBridges are connected by a link that includes
>    multiple 802.1 bridges.
> 
> 
> 
> 
> Gray                      Expires March, 2007                 [Page 7]
> 
> Internet-Draft        TRILL Routing Requirements       September, 2006
> 
> 
> 
>    In order to simplify the interactions between RBridges and bridges
-
>    in particular, relative to spanning tree forwarding - RBridges do
not
>    actively participate in spanning tree protocol with 802.1 bridges.
> 
> Sgai 10> "do not participate actively" can mean two different things:
> 1) they drop the BPDU
> 2) they propagate the BPDUs as regular multicast frames
> 
> can you clarify?
> 
> @@@ They block BPDUs but might do something based on their receipt.
> Another way to look at it is that an Rbridge with N interfaces, each
> connected to bridged links, looks like N different leaf nodes to the
> STP/RSTP running on those bridged links. (Could be N different
spanning
> trees or less than that if some of these links are connected or
bridged
> to each other.)
> 
>    Hence, from the Link State Routing protocol perspective, the
protocol
>    will be able to treat spanning tree links as indistinguishable from
>    any other Ethernet/802.1 link, in the same way that routing
protocols
>    do today.
> 
>    However, support for multi-pathing is potentially problematic and
is
>    assumed - in this document - to be a non-goal.  Multi-path
forwarding
>    has the potential to confound the bridge learning process.
> 
> Sgai 11> multi-pathing a non-goal? This seems to be in contradiction
> with what said before. Is it because of the designated RBridge?
> 
> Sgai 12> the requirement for a designated RBridge is not really
> discussed here. In particular there is no discussion of the property
of
> the election algorithm, which must avoid broadcast storms.
> 
> @@@ Seems like the ideal thing would be to state the requirements that
> having a Designated Rbridge meets rather then the mechanism of having
a
> Designated Rbridge.
> 
> @@@ Some general statement about convergence and an acceptably low
level
> of overhead traffic for all of the mechanisms associated with the
> routing protocol might be reasonable.
> 
> 
> 4.2. Computing Routes
> 
>    RBridges must calculate an L2 "route table" consisting of Next Hop
>    information for each known L2 unicast destination address within a
>    (possibly VLAN scoped) broadcast domain. This is computed using a
>    routing protocol's SPF algorithm and based on destination layer 2
>    address reachability advertisements.
> 
> Sgai 13> from the previous sentence it seems that we are computing the
> topology among all the MAC addresses. What we really do is compute the
> topology among RBridges and then tag it with reachable MAC addresses.
> >From the SPF perspective, it is a much easier problem.
> 
> ... snip ...
> 
> 
> @@@ Thanks,
> @@@ Donald
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id kA66DsWs016932 for <[e-mail]>; Sun, 5 Nov 2006 22:13:54 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-3.tower-128.messagelabs.com!1162793633!2300371!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 11900 invoked from network); 6 Nov 2006 06:13:53 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-128.messagelabs.com with SMTP; 6 Nov 2006 06:13:53 -0000
Received: from il06exb01.corp.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id kA66Dqm5021753 for <[e-mail]>; Sun, 5 Nov 2006 23:13:53 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exb01.corp.mot.com (8.13.1/8.13.0) with ESMTP id kA66DqJA014206 for <[e-mail]>; Mon, 6 Nov 2006 00:13:52 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 6 Nov 2006 01:13:49 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: A thought about TTLs
Thread-Index: AccBarlDU1OQiBlCQfWq8P/Yz1oLFA==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA66DsWs016932
Subject: [rbridge] A thought about TTLs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2006 06:14:18 -0000
Status: RO
Content-Length: 857

Rbridges are in a fundamentally different position in deciding shim TTLs
than IP hosts are in deciding IP TTLs. In particular, a host knows
almost nothing about the routing situation while an Rbridge has explicit
link state information.

Thus it would be reasonable to recommend a TTL based on the expected
number of hops for unicast or maximum expected number of hops for
multicast/broadcast/flooded or on the diameter of the network (maximum
number of Rbridge-Rbridge hops for the two most distant Rbridges) or the
like ... It would even be possible to have Rbridges trim back the TTL
for the copy forwarding to a particularly short branch of a tree or even
when forwarding along a unicast path if that path has gotten shorter.
Such adjustment is probably too much work to mandate but it seems to me
that it should be allowable behavior.

Thanks,
Donald



Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA5NYH7e001154 for <[e-mail]>; Sun, 5 Nov 2006 15:34:17 -0800 (PST)
Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Sun, 05 Nov 2006 15:34:00 -0800
X-Server-Uuid: D7CB97D3-6392-476F-BE46-AB3D6F515C9A
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 0E4A92AF; Sun, 5 Nov 2006 15:34:00 -0800 (PST)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id DC7882AE; Sun, 5 Nov 2006 15:33:59 -0800 (PST)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EKD97128; Sun, 5 Nov 2006 15:33:58 -0800 (PST)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id B1DDE20501; Sun, 5 Nov 2006 15:33:58 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 5 Nov 2006 15:33:56 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] Ingress Rbridge address and BCN - 1st Issue
Thread-Index: AccBCBIZzsJLfe2aTkClXy6xN4TFQQAKoXcw
From: "Caitlin Bestler" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, "Silvano Gai" <[e-mail]>, "Larry Kreeger (kreeger)" <[e-mail]>
X-WSS-ID: 6950AB623801619035-01-01
Content-Type: text/plain; charset=us-ascii
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA5NYH7e001154
Cc: [e-mail]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 05 Nov 2006 23:34:36 -0000
Status: RO
Content-Length: 292

I don't agree with your characterization of BCN having 'hard real time'
limits. It would be more accurate to state that the quicker the response
the more effective it is in squelching congestion.

Pat Thaler will be explaining 802.1au for IETF folks at the tsvarea
session Monday evening.





Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id kA5NLxJO027907 for <[e-mail]>; Sun, 5 Nov 2006 15:21:59 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-11.tower-128.messagelabs.com!1162768918!4078338!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 6157 invoked from network); 5 Nov 2006 23:21:58 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-128.messagelabs.com with SMTP; 5 Nov 2006 23:21:58 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id kA5NLwSb016384 for <[e-mail]>; Sun, 5 Nov 2006 16:21:58 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id kA5NLvQQ029464 for <[e-mail]>; Sun, 5 Nov 2006 17:21:57 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 5 Nov 2006 18:21:56 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] WG last call comments to:http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt
Thread-Index: Acb7fuQbcgNuaYWOR0u0ehoeYYH/5AFiKyMg
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA5NLxJO027907
Subject: Re: [rbridge] WG last call comments to:http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 05 Nov 2006 23:22:15 -0000
Status: RO
Content-Length: 18035

Hi Silvano,

I think I agree with most of your comments but see a few notes at @@@

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Silvano Gai
Sent: Sunday, October 29, 2006 12:23 PM
To: [e-mail]
Subject: [rbridge] WG last call comments
to:http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.
txt

Comments inline marked "sgai n>"

-- Silvano

--------------------------------------------------------

... snip ...

1. Introduction 

   The current dominant approach to segregating network traffic relies
   on a hierarchical arrangement of bridges and routers.  Hierarchy is
   further extended - both within routing protocols (such as IS-IS and
   OSPF) and between routing protocols (for example, between IGPs and
   BGP).  At least part of the current network structure is based on a 
   determined trade-off between limitations of IP routing and similar 
   disadvantages of 802 bridging.

   Bridging Limitations

   For example, bridged networks consist of single broadcast/flooding
   domains.  Ethernet/802 encapsulation (on which bridging is based) 
   does not provide mechanisms for reducing the impact of looping data 
   traffic that may result from a transient change in network topology
   and the existence of multiple paths.

   The impact of looping traffic is far worse with flooded or broadcast 
   traffic as this results in exponentially increasing traffic load.  
   Consideration of the impacts of looping data lead to the use of 
   STP/RSTP to establish a connected - loop free - tree by disabling 
   forwarding on a subset of links that might create a loop.  This has
   also the effect of eliminating redundant paths.

@@@ Also generally lowers aggregate throughput and increases latency
through the net due to frames following suboptimal paths.

   Because of the potential for severe impact from looping traffic, 
   many (if not most) current bridge implementations stop forwarding of 
   traffic frames following a topology change event and restart only 
   after STP/RSTP is complete.

Sgai 1> In STP there is no way of knowing when the convergence has been
achieved; a bridge does not know or care about the timers of other
bridges. The state machines on the ports are run independently. If you
refer to the Topology Change Notification Flag, its purpose is to reduce
the filtering database ageing time, not to signal if STP/RSTP is
complete.

   As a result, the process of eliminating potential loops in existing 
   bridging deployments:

     1) Results in inefficient use of inter-bridge connections 
        and
     2) Causes delays in forwarding traffic as a result of 
        changes in the network topology.

Sgai 2> 2) is not true in the RSTP case; as a matter of fact RSTP is the
fastest converging protocol available today. 

@@@ I'm not sure why this and other documents put the emphasis they do
on STP/RSTP convergence. Of course it depends some on just how STP/RSTP
is implemented and how other algorithms are implemented. Perhaps it
stems from, as was pointed out early in the Rbridge effort, that the
replacement of bridges with Rbrides typically divides what would have
been one large spanning tree domain into a number of smaller ones
interconnected by Rbridges. The STP/RSTP protocol within these small
spanning tree domains will typically converge for them all in parallel
more rapidly than the pre-existing larger single spanning tree STP/RSTP
convergence.

   The combined effect of broadcast/flooding traffic, and the use of 
   spanning trees for loop avoidance, sets practical limits on bridged 
   network size in the network hierarchy and results in inefficient 
   bandwidth use of inter-bridge connections. Inefficient inter-bridge 
   connection usage similarly limits the usefulness of bridging with 
   high-speed (and consequently high cost) interfaces.







Gray                      Expires March, 2007                 [Page 3]

Internet-Draft        TRILL Routing Requirements       September, 2006


   IP Routing Issues

   For IP routed networks, any link (or subnet) must have at least one 
   unique prefix. This means that a node that moves from one IP subnet

sgai 3> in the case of IP instead of "node" is better to speak of
"interface". It is the interface that has an address, not the node.
 
   to another must change its IP address. Also, nodes with multiple IP
   subnet attachments must have multiple IP addresses.  In IP routed
   networks, there are frequent trade-off considerations between using 
   smaller subnets (longer prefix length) to minimize wasted IP address 
   space (as a result of unused addresses in the fixed address range 
   defined by the prefix and length) and using larger subnets (shorter
   prefix length) to minimize the need for (changes in) configuration.

   In any case - with current IP routing technology - subnets must be 
   configured for each routed interface.

   Proposed Solution

   Using a hybrid of routing and bridging - an RBridge - we hope to
   gain the benefits of both technologies, in particular, gaining the
   bandwidth advantages of shortest path routing while retaning the
   simplified configuration associated with bridging.

1.1. Terminology

   The following terms are used in this document in the way that
   they are defined in "TRILL RBridge Architecture" [TARCH]:

     ARP (Address Resolution Protocol)
     Bridge Learning
     Broadcast Domain 
     Broadcast Traffic
     Cooperating RBridges
     Egress RBridge
     Ethernet
     Flooded Traffic
     Flooding
     Frame 
     IGP (Interior Gateway Protocol)
     Ingress RBridge
     Ingress RBridge Tree
     IS-IS (Intermediate System to Intermediate System)
     ND (Neighbor Discovery)
     OSPF (Open Shortest Path First)
     Packet 

Sgai 4> in the case of layer 2 networks is more appropriate to use the
term frame, instead of packet.

@@@ Frame appears earlier in this list and I believe that both are
properly defined in the architecture document.

     RBridge
     SPF (Shortest Path First)
     STP/RSTP (Spanning Tree Protocol/Rapid Spanning Tree Protocol)
     TRILL (TRansport Interconnect over Lots of Links)
     Unknown Destination
     VLAN (Virtual Local Area Network)


Gray                      Expires March, 2007                 [Page 4]

Internet-Draft        TRILL Routing Requirements       September, 2006



1.2. Specific TRILL Goals

   (Near) Zero Configuration

   It is a TRILL requirement that it must be possible to deploy RBridges
   in at least a nominal set of potential deployment scenarios without a
   need to perform any configuration at each RBridge.  It is possible to
   meet this goal for a sub-set of all possible deployment scenarios by
   making realistic restrictions on deployment - such as restricting the
   deployment scenarios to exclude those involving a "trust model" that
   imposes a need for configuration of some form of "shared secret" or 
   other configuration required to restrict access to "trusted" devices.

   It is also conceivable that a minimal configuration may be required
   for deployment of an initial (set of) device(s) - with subsequently
   deployed devices deriving that configuration information during the
   process of - for example - peer discovery.  This would constitute a
   mechanism for "near zero configuration".

   Efficient Unicast Bandwidth Usage

   For unicast, non-flooded traffic, RBridges are intended to merge the
   efficient bandwidth use of IP routing with the simplicity of Ethernet
   (or 802.1) bridging for networks possibly larger - and with greater 
   forwarding capacity - than is the case with these networks presently.
 
   The approach that we will use in accomplishing this is based on the
   idea of extending (one or more) link state routing protocol(s) to
   include distribution of Ethernet/802 reachability information between
   RBridge instances.  

Sgai 5> "RBridge instances" is not defined.

@@@ For a document at this level, perhaps it could just say "RBridges".

   In addition, there may be specific requirements
   imposed on the interactions between these extensions and the Spanning
   Tree Protocol (STP) and between RBridge instances and (potentially
   co-located) IP routing instances.

   Potentially More Efficient Multicast and Broadcast Usage

   There are clear advantages to incorporating mechanisms for improved
   efficiency in forwarding (layer 2) multicast frames and - possibly
   in reducing the amount of broadcast traffic as well.  To the extent
   that these efficiency improvements may be considered "optimizations"
   and may be defined orthogonally to the process of specifying basic
   RBridge functionality, the potential to include these optimizations
   is (highly) desirable, but not mandatory.

   Examples of this type of optimization include use of any intrinsic 
   multicast routing capabilities and optimizations of ARP/ND.





Gray                      Expires March, 2007                 [Page 5]

Internet-Draft        TRILL Routing Requirements       September, 2006



   Backward Compatibility

   RBridges must be fully compatible with current bridges, IPv4 and
   IPv6 routers and endnodes.  They should be invisible to current IP
   routers (just as bridges are), and like routers, they terminate a
   bridged spanning tree.  

Sgai 6> the concept of terminating a bridged spanning tree is to vague,
see also sgai 10.

@@@ I think that concept is generally understood to mean that they do
not pass BPDUs. Perhaps "by not passing BPDUs" could be appended above.

   Unlike Routers, RBridges do not terminate
   a broadcast domain.


2. General Requirements Potentially Affecting Routing

   Candidate IGP Routing protocols - IS-IS or OSPF - must be evaluated
   for compatibility with the above goals.

   For example, since IS-IS requires a unique System ID for each IS-IS
   instance (at least within a "scoped" deployment), a requirement for 
   "(near) zero configuration" implies a need for mechanisms that allow
   auto-configuration and/or negotiation of these (scoped) unique IDs.

   Similar requirement must apply for OSPF as well, if selected.

   In addition, forwarding of protocol messages must be compatible with
   (or reasonably adaptable to) use of forwarding at layer 2, or there
   must be a means for deriving suitable higher layer addresses for the
   purpose of protocol exchanges - without imposing the need to manually
   configure higher-layer addresses.


3. Link State Protocol Specific Requirements

   Assuming that link state routing protocols meet above requirements,
   running a link state protocol among RBridges is straightforward.  It 
   is the same as running a level 1 routing protocol in an area.  This 
   would be theoretically true for either IS-IS or OSPF, assuming that
   both of these meet the general requiremenst above. 

   From the perspective of simply extending existing routing protocols,
   IS-IS is a more appropriate choice than OSPF because it is easy in 
   IS-IS to define new TLVs for use in carrying a new information type.

   This document, however, does not mandate a specific link-state, IGP,
   routing protocol.  Instead, it sets forth the requirements that will
   apply to any link-state routing protocol that may be used.

   For implementations providing co-located Router/RBridge function,
   it is necessary to have mechanisms for distinguishing any protocol 
   interactions in Routing instances from protocol interactions in the
   co-located RBridge instance.  Specific mechanisms we will use are
   very likely to be determined by the Link State Routing Protocol that



Gray                      Expires March, 2007                 [Page 6]

Internet-Draft        TRILL Routing Requirements       September, 2006



   we select.  Potential distinguishing mechanisms include use of a new
   well-known Ethernet/802 multicast address, higher-layer protocol ID
   or other - routing protocol specific - approaches.

   The mechanism chosen should be consistent with the TRILL goals.  If, 
   for example, a routing protocol specific approach required use of a
   unique "area" identifier, the RBridge area identifier should be a 
   constant, well-known, value for all RBridges, and would not be one 
   that would ever appear as a real routing area identifer - in order 
   to allow for a potential for configuration-free operation. 

   Information that RBridge link state information will carry includes: 

   o  layer 2 addresses of nodes within the domain which have 
      transmitted frames but have not transmitted ARP or ND replies  

   o  layer 3, layer 2 addresses of IP nodes within the domain.  For 
      data compression, perhaps only the portion of the address 
      following the domain-wide prefix need be carried.  This will be 
      more of an issue for IPv6 than for IPv4. 

   o  VLANs directly connected to this RBridge 


Sgai 7> The discussion about VLAN needs to be much more extensive. It is
clear from the mailing list discussion that VLANs can be used inside the
packet or in the Ethernet encapsulation of TRILL. These are two
different kinds of VLANs and their requirement need to be stated
separately. Q in Q needs also to be discussed. I propose to define inner
and outer VLANs (with reference to the position of the tag in the frame.

@@@ Based on the discussions that have been going on, I feel a bit
clearer about VLANs than I used to. It seems hard to make a simple,
brief, definiteive statement about Rbridges and VLANs, except that all
the VLAN stuff needs to be configured, because there are so many
different scenarios. I agree that a fairly extensive discussion of VLANs
should appear somewhere but I don't think this is the right document for
that. The requirement on the Rbridge routing expressed here is that it
needs, one way or the other, to be able to handle station identification
not just as a MAC address but as a VLAN tag and MAC address.

   Endnode information need only be delivered to RBridges supporting
   the VLAN in which the endnode resides. 

Sgai 8> endnode -> station

   So, for instance, if endnode
   E is discovered through a VLAN A frame, then E's location need only
   be delivered to other RBridges that are attached to VLAN A links. 

   Given that RBridges must support delivery only to links within a VLAN

   (for multicast or unknown frames marked with the VLAN's tag), this 
   mechanism can be used to advertise endnode information solely to the
   RBridges "within" a VLAN (i.e. - having connectivity or configuration
   that assoicates them with a VLAN). 

   Although a separate instance of 
   the link state protocol could be run for this purpose, the topology 
   is so restricted (just a single broadcast domain), that it may be 
   preferable to define special case mechanisms whereby each DR 

sgai 9> DR? Designated RBridge???

@@@ Yes, I think it should be spelled out.

   advertises attached endnodes, and receives explicit acknolegments
   from other RBridges. 


4. Potential Issues 

4.1. Interactions with Spanning Tree Forwarding and Bridge Learning 

   Spanning tree forwarding applies within parts of the RBridge domain,
   where two or more RBridges are connected by a link that includes
   multiple 802.1 bridges.




Gray                      Expires March, 2007                 [Page 7]

Internet-Draft        TRILL Routing Requirements       September, 2006



   In order to simplify the interactions between RBridges and bridges -
   in particular, relative to spanning tree forwarding - RBridges do not
   actively participate in spanning tree protocol with 802.1 bridges.

Sgai 10> "do not participate actively" can mean two different things:
1) they drop the BPDU
2) they propagate the BPDUs as regular multicast frames

can you clarify?

@@@ They block BPDUs but might do something based on their receipt.
Another way to look at it is that an Rbridge with N interfaces, each
connected to bridged links, looks like N different leaf nodes to the
STP/RSTP running on those bridged links. (Could be N different spanning
trees or less than that if some of these links are connected or bridged
to each other.)

   Hence, from the Link State Routing protocol perspective, the protocol
   will be able to treat spanning tree links as indistinguishable from
   any other Ethernet/802.1 link, in the same way that routing protocols
   do today.

   However, support for multi-pathing is potentially problematic and is 
   assumed - in this document - to be a non-goal.  Multi-path forwarding
   has the potential to confound the bridge learning process.

Sgai 11> multi-pathing a non-goal? This seems to be in contradiction
with what said before. Is it because of the designated RBridge?

Sgai 12> the requirement for a designated RBridge is not really
discussed here. In particular there is no discussion of the property of
the election algorithm, which must avoid broadcast storms.

@@@ Seems like the ideal thing would be to state the requirements that
having a Designated Rbridge meets rather then the mechanism of having a
Designated Rbridge.

@@@ Some general statement about convergence and an acceptably low level
of overhead traffic for all of the mechanisms associated with the
routing protocol might be reasonable.


4.2. Computing Routes

   RBridges must calculate an L2 "route table" consisting of Next Hop 
   information for each known L2 unicast destination address within a 
   (possibly VLAN scoped) broadcast domain. This is computed using a
   routing protocol's SPF algorithm and based on destination layer 2
   address reachability advertisements.

Sgai 13> from the previous sentence it seems that we are computing the
topology among all the MAC addresses. What we really do is compute the
topology among RBridges and then tag it with reachable MAC addresses.
>From the SPF perspective, it is a much easier problem.

... snip ...


@@@ Thanks,
@@@ Donald



Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA5KpBW3017081 for <[e-mail]>; Sun, 5 Nov 2006 12:51:11 -0800 (PST)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Sun, 05 Nov 2006 12:51:07 -0800 (PST)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Sun, 05 Nov 2006 12:51:06 -0800 (PST)
Received: from [152.70.2.164] (Forwarded-For: [12.105.242.98]) by mail-srv.sfvic.sunlabs.com (mshttpd); Sun, 05 Nov 2006 12:51:06 -0800
Date: Sun, 05 Nov 2006 12:51:06 -0800
From: [e-mail]
To: "Gray, Eric" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] How many trees, and per what
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 05 Nov 2006 20:51:37 -0000
Status: RO
Content-Length: 3546

Hopefully by "very similar" understanding of what we are talking about, you mean "identical". If there is some disconnect
over what we understand the technical proposal to be, we should clear that up before trying to argue the merits
of the technical proposal.

Radia

----- Original Message -----
From: "Gray, Eric" <[e-mail]>
Date: Sunday, November 5, 2006 12:38 pm
Subject: Re: [rbridge] How many trees, and per what

> Radia,
> 
> 	I think we have a very similar understanding of what "tree"
> means.  
> 
> 	The step from a uni-directional "tree" rooted at the local
> ingress to a bi-directional "tree" - potentially rooted elsewhere
> - is, IMO, a very big step.
> 
> 	Therefore, again IMO, this is something we need to decide -
> soon - hence it is something we should talk about this week.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [e-mail] [[e-mail]] 
> --> Sent: Sunday, November 05, 2006 2:25 PM
> --> To: Gray, Eric
> --> Cc: Sanjay Sane (sanjays); Russ White; [e-mail]
> --> Subject: Re: RE: [rbridge] How many trees, and per what
> --> 
> --> What I think an ingress RBridge tree is, is the following:
> --> 
> --> Suppose you have an RBridge R. Everyone calculates an SPF 
> --> tree with R as the root, with some deterministic
> --> tie-breaker in the case of two equal cost paths from R to 
> --> some node N, such as the ID of the parent. For instance,
> --> if you can attach N to the tree with either parent P1 or 
> --> P2, and get the same minimal cost from R to N, you
> --> choose the parent with lowest ID to attach N to.
> --> 
> --> So that's the ingress RBridge tree rooted at R. If it's 
> --> really an ingress tree it could be thought of as unidirectional,
> --> since traffic would only originate at R.
> --> 
> --> If instead you go with the proposal that allows the ingress 
> --> RBridge R to select a different tree for a multicast than
> --> the one rooted at R, so it selects, say, the tree rooted at 
> --> R2, then what we mean by a tree is a *bidirectional* tree
> --> rooted at R2.
> --> 
> --> If the trees are bidirectional, the calculation of the tree 
> --> is the same (do SPF with R2 as root). To figure out
> --> which of your own links are in the R2 tree, you look at 
> --> yourself in that tree, and use the port (neighbor) that connects
> --> you to your parent in the tree, and all the ports 
> --> (neighbors) that connect children in the tree to you. Those are
> --> your links in the bidirectional tree.
> --> 
> --> For forwarding on a bidirectional tree, if you receive a 
> --> packet marked as "use tree R2" from a neighbor that is
> --> not one of the R2-tree links, then you discard the packet. 
> --> Otherwise, you forward the packet onto all the other
> --> links in the R2-tree other than the one you got it from.
> --> 
> --> I am really mystified as to what other definition there 
> --> might be of trees. So please explain if you mean something else.
> --> 
> --> Thanks,
> --> 
> --> Radia
> --> 
> --> 
> --> 
> --> ----- Original Message -----
> --> From: "Gray, Eric" <[e-mail]>
> --> Date: Sunday, November 5, 2006 10:04 am
> --> Subject: RE: [rbridge] How many trees, and per what
> --> 
> --> > Clearly one of the things we need to talk about this week is 
> what 
> --> > exactlydo we mean by ingress rbridge tree. 
> --> > 
> --> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA5KcrUE013691 for <[e-mail]>; Sun, 5 Nov 2006 12:38:53 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA5KcpfK020363; Sun, 5 Nov 2006 15:38:51 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA05210;  Sun, 5 Nov 2006 15:38:51 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB64801N>; Sun, 5 Nov 2006 15:38:50 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: [e-mail], "Gray, Eric" <[e-mail]>
Date: Sun, 5 Nov 2006 15:38:50 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] How many trees, and per what
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 05 Nov 2006 20:39:05 -0000
Status: RO
Content-Length: 2817

Radia,

	I think we have a very similar understanding of what "tree"
means.  

	The step from a uni-directional "tree" rooted at the local
ingress to a bi-directional "tree" - potentially rooted elsewhere
- is, IMO, a very big step.

	Therefore, again IMO, this is something we need to decide -
soon - hence it is something we should talk about this week.

--
Eric

--> -----Original Message-----
--> From: [e-mail] [mailto:[e-mail]] 
--> Sent: Sunday, November 05, 2006 2:25 PM
--> To: Gray, Eric
--> Cc: Sanjay Sane (sanjays); Russ White; [e-mail]
--> Subject: Re: RE: [rbridge] How many trees, and per what
--> 
--> What I think an ingress RBridge tree is, is the following:
--> 
--> Suppose you have an RBridge R. Everyone calculates an SPF 
--> tree with R as the root, with some deterministic
--> tie-breaker in the case of two equal cost paths from R to 
--> some node N, such as the ID of the parent. For instance,
--> if you can attach N to the tree with either parent P1 or 
--> P2, and get the same minimal cost from R to N, you
--> choose the parent with lowest ID to attach N to.
--> 
--> So that's the ingress RBridge tree rooted at R. If it's 
--> really an ingress tree it could be thought of as unidirectional,
--> since traffic would only originate at R.
--> 
--> If instead you go with the proposal that allows the ingress 
--> RBridge R to select a different tree for a multicast than
--> the one rooted at R, so it selects, say, the tree rooted at 
--> R2, then what we mean by a tree is a *bidirectional* tree
--> rooted at R2.
--> 
--> If the trees are bidirectional, the calculation of the tree 
--> is the same (do SPF with R2 as root). To figure out
--> which of your own links are in the R2 tree, you look at 
--> yourself in that tree, and use the port (neighbor) that connects
--> you to your parent in the tree, and all the ports 
--> (neighbors) that connect children in the tree to you. Those are
--> your links in the bidirectional tree.
--> 
--> For forwarding on a bidirectional tree, if you receive a 
--> packet marked as "use tree R2" from a neighbor that is
--> not one of the R2-tree links, then you discard the packet. 
--> Otherwise, you forward the packet onto all the other
--> links in the R2-tree other than the one you got it from.
--> 
--> I am really mystified as to what other definition there 
--> might be of trees. So please explain if you mean something else.
--> 
--> Thanks,
--> 
--> Radia
--> 
--> 
--> 
--> ----- Original Message -----
--> From: "Gray, Eric" <[e-mail]>
--> Date: Sunday, November 5, 2006 10:04 am
--> Subject: RE: [rbridge] How many trees, and per what
--> 
--> > Clearly one of the things we need to talk about this week is what 
--> > exactlydo we mean by ingress rbridge tree. 
--> > 
--> 


Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA5KOihS007583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Sun, 5 Nov 2006 12:24:45 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2A3FBE7F6B; Sun,  5 Nov 2006 21:24:43 +0100 (CET)
Received: from [10.0.0.4] (39.Red-80-37-137.staticIP.rima-tde.net [80.37.137.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 5E072E7F53; Sun,  5 Nov 2006 21:24:42 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sun, 05 Nov 2006 21:24:40 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: "Larry Kreeger (kreeger)" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] LIDs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 05 Nov 2006 20:25:09 -0000
Status: RO
Content-Length: 2720

I agree that LIDs can help to improve large switches scalability.
Guillermo

Larry Kreeger (kreeger) escribi?:
> Caitlin Bestler wrote on Friday, November 03, 2006 9:07 AM:
>
>   
>> Larry Kreeger (kreeger) wrote:
>>     
>>> Hi,
>>>
>>> I was catching up on old RBridge threads and saw this one about LIDs.
>>>
>>> LIDs can be useful in reducing costs in large switches where the
>>> entire (potentially large) local MAC table would not need to be
>>> present in every module of the system.  In fact it could probably
>>> eliminate the need to keep locally learned MACs in hardware at all.
>>> Assuming a switch with 16 slots and
>>> 48 ports per linecard, and servers running 16 virtual machines each
>>> connected to the ports, the number of local MACs would be 16*48*16=
>>> 12,288.  With 48 bits per address, that is ~59kbits.
>>>
>>> With LIDs, an entry is need only per port, not per local MAC.
>>>  So given a 16 bit LID, only 16 cards * 48 ports * 16 bits =
>>> ~12kbits, a savings of ~47kbits. 
>>>
>>> The more locally attached MACs, the bigger the savings.
>>>
>>>       
>> Instead of keeping the MAC to Port mapping in the egress RBridge you
>> instead keep it in each ingress rbridge that has learned of this
>> rbridge. I'm not seeing a net savings in memory costs anywhere. There
>> is certainly a potential latency benefit, but is there really one
>> that is valid over the desired lifespan of the protocol?    
>>     
>
> The ingress RBridge must already have a mapping from MAC to egress
> RBridge nickname.  So, the table must only be widened to include the LID
> - which is much smaller (depending on the size of the LID) than the MAC
> to port mapping needed at the egress RBridge.
>
> Also, the size of the table at the ingress RBridge depends on how many
> end stations are being actively communicated with from that RBridge.  If
> the ingress RBridge is a distributed system, then each module (e.g.
> ASIC) only needs to populate the table with mappings for the active
> flows through that part of the system.  If we assume that every end
> station is not directly communicating with every other end station, then
> different entries would exist in each MAC -> Egress RBridge/LID table.
> This allows a large distributed system to scale up without requiring
> each ASIC to increase its table size - because the mapping to LID is
> spread out versus being concentrated at the inter-RBridge port ASICs of
> a large RBridge.
>
> It all depends on ratio of RBridge size (locally MAC addresses) versus
> the number of flow active.
>
>  - Larry
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA5KNWY2006997 for <[e-mail]>; Sun, 5 Nov 2006 12:23:32 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA5KNUfK020278; Sun, 5 Nov 2006 15:23:30 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA05011;  Sun, 5 Nov 2006 15:23:30 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB6480D1>; Sun, 5 Nov 2006 15:23:29 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Dinesh G Dutt <[e-mail]>, Radia Perlman <[e-mail]>
Date: Sun, 5 Nov 2006 15:23:29 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] New shim header proposal---without F-tag field
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 05 Nov 2006 20:24:03 -0000
Status: RO
Content-Length: 3751

I think this also needs to be something we discuss this week. 

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Dinesh G Dutt
--> Sent: Tuesday, October 31, 2006 10:25 AM
--> To: Radia Perlman
--> Cc: [e-mail]
--> Subject: Re: [rbridge] New shim header proposal---without 
--> F-tag field
--> 
--> I hit "send" too soon. We talked about an additional bit in 
--> the header 
--> to identify a multicast frame. Did you see no need for that ?
--> 
--> Dinesh
--> Radia Perlman wrote:
--> > After talking to Silvano and Dinesh to get them to 
--> explain to me why
--> > the use of F-tag didn't multiply the number of trees that RBridges
--> > needed to compute by the number of F-tag values, they were able to
--> > explain to me why they wanted the F-tag. Here is a proposal to
--> > get the functionality they want without the use of F-tag.
--> >
--> > ***********************
--> >
--> > Motivation for F-tag
--> >
--> > They want to be able to do multipathing on multicast. We 
--> can already
--> > do multipathing on unicast by having an RBridge keep 
--> multiple equal
--> > cost (or near equal cost) paths to destination D, and 
--> split traffic
--> > however it wants. But if we have a single tree for all multicast
--> > with ingress RBridge R1, then all multicast traffic has to use
--> > the same links. The original proposal was to use F-tag as 
--> a selector
--> > for a tree. But the modified proposal is to use the 
--> "egress RBridge"
--> > field, which wasn't all that useful for multicast, as a 
--> "tree selector".
--> >
--> > ******************************
--> >
--> > So the proposal is:
--> >
--> > In the shim header will only be:
--> > 1) 16-bit ingress RBridge
--> > 2) 16-bit egress RBridge
--> > 3) TTL
--> >
--> >
--> > How these fields will be used in order to do multipathing:
--> >
--> > a) RBridges calculate a single tree for each ingress RBridge
--> >
--> > b) For unicast, an RBridge can calculate multiple equal-cost
--> > paths to the destination (or near-equal cost), and split 
--> traffic. That 
--> > is how
--> > we'd get multipathing for unicast. If S7 has two ways to get to 
--> > destination D,
--> > it can send some of its traffic one way, some of it the 
--> other. This is 
--> > solely
--> > S7's choice and doesn't need to be coordinated with any 
--> other switches.
--> >
--> > c) For multicast, we can provide multipathing by letting 
--> the ingress RBridge
--> > choose the distribution tree.
--> > The tree used will be indicated by the "egress RBridge"
--> > field. So, if S3 receives a multicast packet from an 
--> endnode, it puts
--> > "S3" as "ingress RBridge", but selects a tree by whatever means it
--> > wants, and puts, say, "S1" into "egress RBridge". That 
--> way the packet
--> > will be forwarded based on the tree calculated using S1 
--> as the root.
--> >
--> > With this proposal, we get multipathing for multicast 
--> without configuration.
--> > The same space used for RBridge nicknames can be used for 
--> choosing the
--> > tree for multicast packets. The number of trees to be 
--> calculated does
--> > not change---it is still per ingress RBridge.
--> >
--> > Radia
--> >
--> > _______________________________________________
--> > rbridge mailing list
--> > [e-mail]
--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> >
--> >   
--> 
--> -- 
--> We make our world significant by the courage of our 
--> questions and by 
--> the depth of our answers.                               - Carl Sagan
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA5JOhG6019506 for <[e-mail]>; Sun, 5 Nov 2006 11:24:43 -0800 (PST)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Sun, 05 Nov 2006 11:24:42 -0800 (PST)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Sun, 05 Nov 2006 11:24:42 -0800 (PST)
Received: from [152.70.2.164] (Forwarded-For: [12.105.242.98]) by mail-srv.sfvic.sunlabs.com (mshttpd); Sun, 05 Nov 2006 11:24:42 -0800
Date: Sun, 05 Nov 2006 11:24:42 -0800
From: [e-mail]
To: "Gray, Eric" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] How many trees, and per what
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 05 Nov 2006 19:24:59 -0000
Status: RO
Content-Length: 1946

What I think an ingress RBridge tree is, is the following:

Suppose you have an RBridge R. Everyone calculates an SPF tree with R as the root, with some deterministic
tie-breaker in the case of two equal cost paths from R to some node N, such as the ID of the parent. For instance,
if you can attach N to the tree with either parent P1 or P2, and get the same minimal cost from R to N, you
choose the parent with lowest ID to attach N to.

So that's the ingress RBridge tree rooted at R. If it's really an ingress tree it could be thought of as unidirectional,
since traffic would only originate at R.

If instead you go with the proposal that allows the ingress RBridge R to select a different tree for a multicast than
the one rooted at R, so it selects, say, the tree rooted at R2, then what we mean by a tree is a *bidirectional* tree
rooted at R2.

If the trees are bidirectional, the calculation of the tree is the same (do SPF with R2 as root). To figure out
which of your own links are in the R2 tree, you look at yourself in that tree, and use the port (neighbor) that connects
you to your parent in the tree, and all the ports (neighbors) that connect children in the tree to you. Those are
your links in the bidirectional tree.

For forwarding on a bidirectional tree, if you receive a packet marked as "use tree R2" from a neighbor that is
not one of the R2-tree links, then you discard the packet. Otherwise, you forward the packet onto all the other
links in the R2-tree other than the one you got it from.

I am really mystified as to what other definition there might be of trees. So please explain if you mean something else.

Thanks,

Radia



----- Original Message -----
From: "Gray, Eric" <[e-mail]>
Date: Sunday, November 5, 2006 10:04 am
Subject: RE: [rbridge] How many trees, and per what

> Clearly one of the things we need to talk about this week is what 
> exactlydo we mean by ingress rbridge tree. 
> 



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA5IWccZ004194 for <[e-mail]>; Sun, 5 Nov 2006 10:32:38 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 5 Nov 2006 10:32:32 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Ingress Rbridge address and BCN - 1st Issue
Thread-Index: AccBB7Q86uzfJaKyTIis5WtY0hVwdAAAELyw
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, "Larry Kreeger \(kreeger\)" <[e-mail]>, <[e-mail]>, "Davide Bergamasco \(davide\)" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA5IWccZ004194
Cc: [e-mail]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 05 Nov 2006 18:32:58 -0000
Status: RO
Content-Length: 10440

Eric,

I am OK to have this discussion, I understand BCN at the system level,
but I am not a control theory guy or a congestion management geek.

Two engineers that know BCN very well and that can contribute to the
discussion are:
Manoj K Wadekar <[e-mail]> and
Davide Bergamasco <[e-mail]>
I'll recommend we include them in the discussion.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Sunday, November 05, 2006 10:25 AM
> To: Silvano Gai; Larry Kreeger (kreeger)
> Cc: [e-mail]
> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 1st Issue
> 
> Silvano,
> 
> 	We should probably have some discussion - perhaps off line -
> about how BCN actually works.
> 
> 	For one thing, from what I've heard so far, I have some doubts
> about it working in real networks at all.  That might be addressed by
> taking the time to read the actual BCN specifications in detail and -
> if I were in  a position of having a lot of free time, or under some
> direct pressure from customers to support BCN - I would do that.  So
> far, I have heard that some people have some customers that want BCN
> support (whatever that actually means) and it is hard for me to drop
> something else on so thin a basis.
> 
> 	And it seems likely - based on what people are saying - that our
> taking the time to figure out how BCN "works" might be a waste of
time.
> 
> 	For one thing, your observation about the need for fast feedback
> mechanisms (that appear to be supported by protocol analysis that has
> been performed by someone at least) tends to argue that this technique
> was not designed with real networks in mind.
> 
> 	Delay is a big part of the nature of networks.  Hence realistic
> feedback mechanisms need not only to take into account the fact that
> delay is absolutely unavoidable, but they need to have "knobs" that
> can be adjusted to allow for the mechanism to adapt to different
delays
> in different networks.
> 
> 	The way I am hearing BCN described, it seems as if it has "hard"
> delay bounds and that is a problem - IMO - with the design of BCN.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[e-mail]]
> --> Sent: Saturday, October 28, 2006 11:16 AM
> --> To: Gray, Eric; Larry Kreeger (kreeger)
> --> Cc: [e-mail]
> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 1st Issue
> -->
> --> Eric,
> -->
> --> > -----Original Message-----
> --> > From: [e-mail]
> --> [mailto:[e-mail]]
> --> On
> --> > Behalf Of Gray, Eric
> --> > Sent: Friday, October 27, 2006 3:20 PM
> --> > To: Larry Kreeger (kreeger)
> --> > Cc: [e-mail]
> --> > Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st
Issue
> --> >
> --> > Larry,
> --> >
> --> > 	A slower look up may be okay for exception processing.
> -->
> -->
> --> The BCN closed loop control algorithm requires timely
> --> replies done in
> --> HW. We can ask BCN experts which is the amount of delay that can
be
> --> tolerate, but if I remember correctly the stability
> --> analysis, it was not
> --> much.
> -->
> --> -- Silvano
> -->
> -->
> --> >
> --> > 	BCNs should be required far less often than frames are
being
> --> > forwarded.
> --> >
> --> > 	Having a transit RBridge "look inside [at?] the inner
MAC"
> --> > is not what is effectively happening - as I understand it - when
> --> > a "core RBridge" is generating a BCN.  BCN-capable core RBridges
> --> > would presumably copy the header information from some subset of
> --> > the frames on a minimally-congested link, strip the tunneling
> --> > encapsulation and originate a new frame containing a
Notification
> --> > (BCN) message.
> --> >
> --> > 	This must be a new frame, as opposed to a reflection of
the
> --> > original frame, so it is interesting that people assume this is
a
> --> > trivial operation in hardware in the first place.
> --> >
> --> > 	Since the BCN-capable RBridge has to "flip" the MAC SA
into
> --> > a MAC DA in a BCN anyway, it MUST look at that part of the frame
> --> > in every case before it can generate a BCN.
> --> >
> --> > 	In effect, the frame is (partially) copied, the copied
> --> > information is locally terminated and used to originate a new
> --> > message.  This message would then be sent - presumably using
> --> > the usual means for message origination - by encapsulating it
> --> > in RBridge tunnel encapsulation and forwarding it to (at least)
> --> > the ingress RBridge from which it was introduced.
> --> >
> --> > 	That is not nearly as much of a confusion of layers as
it
> --> > is to 1) assume that the frame is munged in hardware and turned
> --> > around and 2) normal processing of originated local messages is
> --> > bypassed in an attempt to optimize BCN sending at the cost of
> --> > including additional information in _every_ frame.
> --> >
> --> > 	Oh, and, apparently I can blame you for trying... :-)
> --> >
> --> > --
> --> > Eric
> --> >
> --> > --> -----Original Message-----
> --> > --> From: Larry Kreeger (kreeger) [mailto:[e-mail]]
> --> > --> Sent: Friday, October 27, 2006 5:26 PM
> --> > --> To: Gray, Eric
> --> > --> Cc: [e-mail]
> --> > --> Subject: RE: [rbridge] Ingress Rbridge address and
> --> BCN - 1st Issue
> --> > -->
> --> > --> Gray, Eric wrote on Friday, October 27, 2006 11:33 AM:
> --> > -->
> --> > --> > Larry,
> --> > --> >
> --> > --> > 	Separating these issues...
> --> > --> >
> --> > --> > -- [SNIP] --
> --> > --> > -->
> --> > --> > --> Please correct me if I incorrectly summarize the
above.
> --> > --> > -->
> --> > --> > --> 1) Scaling the number of fowarding entries in the
> --> > --> core is not a
> --> > --> > --> problem that TRILL needs to solve.
> --> > --> >
> --> > --> > While this is a possible intrepretation, it is not
> --> an accurate
> --> > --> > characterization of what I said.
> --> > --> >
> --> > --> > I'll try again, starting with what you have said.
> --> > --> >
> --> > --> > Scaling of the number of forwarding entries in the
> --> core is not a
> --> > --> > problem that the TRILL working group has decided to solve.
> --> > --> >
> --> > --> > Hence, you might conclude that the TRILL working group
> --> > --> has passively
> --> > --> > decided that this is not a problem that TRILL needs
> --> to solve.
> --> > --> >
> --> > --> > One reason why this might be the case is that people
> --> > --> could not decide
> --> > --> > the "by how much" question.
> --> > --> >
> --> > --> > Never-the-less, an implicit requirement that the solution
> --> > --> should not
> --> > --> > prevent more scalable implementations, enables people who
> --> > --> might not
> --> > --> > be able to agree in public (as to what factor of increased
> --> > --> > scalability should apply) to produce and deploy solutions
> --> > --> that are in
> --> > --> > fact more scalable, by at least some amount.
> --> > --> >
> --> > --> > --> 2) Link utilization is a problem and TRILL needs to
> --> > --> be concerned
> --> > --> > --> with it.
> --> > --> >
> --> > --> > Certainly.
> --> > --> >
> --> > --> > -->
> --> > --> > --> If this is correct, it leads me to believe that you
> --> > --> would advocate
> --> > --> > --> for
> --> > --> > --> 1) Remove the destination RBridge from the shim, and
> --> > --> just lookup
> --> > --> > the
> --> > --> > --> destination MAC directly
> --> > --> >
> --> > --> > How do you arrive at this conclusion?  There are
> --> > --> scenarios where this
> --> > --> > might be done, but clearly the use of a smaller field for
> --> > --> a look-up
> --> > --> > is traditionally viewed as likely to be quicker.
> --> > -->
> --> > --> I appologize for trying to put words in you mouth, but I am
> --> > --> trying to
> --> > --> understand what you are arguing for...and after
> --> reading the above,
> --> I
> --> > --> still don't know.  Maybe it is because I am confusing
> --> what you are
> --> > --> personally saying versus what you are echoing from others
> --> > --> in the group.
> --> > --> Do you believe we need the RBridge Id in the shim or not?
> --> > --> If you do,
> --> > --> then why?  For a quicker lookup?  If so, then why would a
> --> > --> slower lookup
> --> > --> to generate the source RBridge for BCN be acceptable?
> --> > -->
> --> > --> >
> --> > --> > --> 2) Eliminate the need for the outer MAC header
> --> between two
> --> > --> > RBridges
> --> > --> > --> if the link is point to point (quite likely in
> --> my opinion).
> --> > --> >
> --> > --> > Ultimately, point-to-point is very likely, but we have to
> --> > --> deal with
> --> > --> > the step-by-step deployment scenarios.
> --> > --> >
> --> > --> > In any case, I do not advocate special-casing
> --> > --> encapsulation based on
> --> > --> > link types in general - beyond that already required by
> --> > --> the specific
> --> > --> > link.  As I thought would be obvious by now, I advocate
> --> functional
> --> > --> > separation - which works better if you don't build in a
> --> > --> lot of layer
> --> > --> > dependencies.
> --> > -->
> --> > --> I agree with you about building in a lot of layer
> --> > --> dependencies.  Having
> --> > --> transit RBridges look inside the inner MAC seems like a
> --> > --> layer dependency
> --> > --> to me.  Not encapsulating with an extra 14 to 18 bytes on
> --> > --> point to point
> --> > --> link seems like it would be well worth it if you are
> --> > --> concerned with link
> --> > --> overhead.  I would gladly trade 14/18 bytes of overhead for
> --> > --> another 2
> --> > --> bytes of source RBridge which will help with BCN as well as
> --> > --> help with
> --> > --> network troubleshooting.
> --> > -->
> --> > --> >
> --> > --> > -->
> --> > --> > --> Again, I apologize for not keeping up with the latest
> --> > --> discussions,
> --> > --> > --> but have these ideas been discussed already?
> --> If so, could
> --> you
> --> > --> > --> summarize the outcome?
> --> > --> >
> --> > --> > This is not a reasonable request.
> --> > -->
> --> > --> Oh well, cant' blame me for trying can you? ;-)
> --> > -->
> --> > --> >
> --> > --> > -- [SNIP] --
> --> > -->
> --> > _______________________________________________
> --> > rbridge mailing list
> --> > [e-mail]
> --> > http://mailman.postel.org/mailman/listinfo/rbridge
> -->



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA5IP0KP001921 for <[e-mail]>; Sun, 5 Nov 2006 10:25:00 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA5IOufK019659; Sun, 5 Nov 2006 13:24:56 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA03276;  Sun, 5 Nov 2006 13:24:56 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB6489YF>; Sun, 5 Nov 2006 13:24:55 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>, "Larry Kreeger (kreeger)" <[e-mail]>
Date: Sun, 5 Nov 2006 13:24:54 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 05 Nov 2006 18:25:28 -0000
Status: RO
Content-Length: 9340

Silvano,

	We should probably have some discussion - perhaps off line -
about how BCN actually works.

	For one thing, from what I've heard so far, I have some doubts 
about it working in real networks at all.  That might be addressed by
taking the time to read the actual BCN specifications in detail and - 
if I were in  a position of having a lot of free time, or under some
direct pressure from customers to support BCN - I would do that.  So
far, I have heard that some people have some customers that want BCN
support (whatever that actually means) and it is hard for me to drop 
something else on so thin a basis.

	And it seems likely - based on what people are saying - that our
taking the time to figure out how BCN "works" might be a waste of time.

	For one thing, your observation about the need for fast feedback
mechanisms (that appear to be supported by protocol analysis that has
been performed by someone at least) tends to argue that this technique
was not designed with real networks in mind.  

	Delay is a big part of the nature of networks.  Hence realistic
feedback mechanisms need not only to take into account the fact that 
delay is absolutely unavoidable, but they need to have "knobs" that
can be adjusted to allow for the mechanism to adapt to different delays
in different networks.

	The way I am hearing BCN described, it seems as if it has "hard"
delay bounds and that is a problem - IMO - with the design of BCN.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Saturday, October 28, 2006 11:16 AM
--> To: Gray, Eric; Larry Kreeger (kreeger)
--> Cc: [e-mail]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 1st Issue
--> 
--> Eric,
--> 
--> > -----Original Message-----
--> > From: [e-mail] 
--> [mailto:[e-mail]]
--> On
--> > Behalf Of Gray, Eric
--> > Sent: Friday, October 27, 2006 3:20 PM
--> > To: Larry Kreeger (kreeger)
--> > Cc: [e-mail]
--> > Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue
--> > 
--> > Larry,
--> > 
--> > 	A slower look up may be okay for exception processing.
--> 
--> 
--> The BCN closed loop control algorithm requires timely 
--> replies done in
--> HW. We can ask BCN experts which is the amount of delay that can be
--> tolerate, but if I remember correctly the stability 
--> analysis, it was not
--> much.
--> 
--> -- Silvano
--> 
--> 
--> > 
--> > 	BCNs should be required far less often than frames are being
--> > forwarded.
--> > 
--> > 	Having a transit RBridge "look inside [at?] the inner MAC"
--> > is not what is effectively happening - as I understand it - when
--> > a "core RBridge" is generating a BCN.  BCN-capable core RBridges
--> > would presumably copy the header information from some subset of
--> > the frames on a minimally-congested link, strip the tunneling
--> > encapsulation and originate a new frame containing a Notification
--> > (BCN) message.
--> > 
--> > 	This must be a new frame, as opposed to a reflection of the
--> > original frame, so it is interesting that people assume this is a
--> > trivial operation in hardware in the first place.
--> > 
--> > 	Since the BCN-capable RBridge has to "flip" the MAC SA into
--> > a MAC DA in a BCN anyway, it MUST look at that part of the frame
--> > in every case before it can generate a BCN.
--> > 
--> > 	In effect, the frame is (partially) copied, the copied
--> > information is locally terminated and used to originate a new
--> > message.  This message would then be sent - presumably using
--> > the usual means for message origination - by encapsulating it
--> > in RBridge tunnel encapsulation and forwarding it to (at least)
--> > the ingress RBridge from which it was introduced.
--> > 
--> > 	That is not nearly as much of a confusion of layers as it
--> > is to 1) assume that the frame is munged in hardware and turned
--> > around and 2) normal processing of originated local messages is
--> > bypassed in an attempt to optimize BCN sending at the cost of
--> > including additional information in _every_ frame.
--> > 
--> > 	Oh, and, apparently I can blame you for trying... :-)
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: Larry Kreeger (kreeger) [mailto:[e-mail]]
--> > --> Sent: Friday, October 27, 2006 5:26 PM
--> > --> To: Gray, Eric
--> > --> Cc: [e-mail]
--> > --> Subject: RE: [rbridge] Ingress Rbridge address and 
--> BCN - 1st Issue
--> > -->
--> > --> Gray, Eric wrote on Friday, October 27, 2006 11:33 AM:
--> > -->
--> > --> > Larry,
--> > --> >
--> > --> > 	Separating these issues...
--> > --> >
--> > --> > -- [SNIP] --
--> > --> > -->
--> > --> > --> Please correct me if I incorrectly summarize the above.
--> > --> > -->
--> > --> > --> 1) Scaling the number of fowarding entries in the
--> > --> core is not a
--> > --> > --> problem that TRILL needs to solve.
--> > --> >
--> > --> > While this is a possible intrepretation, it is not 
--> an accurate
--> > --> > characterization of what I said.
--> > --> >
--> > --> > I'll try again, starting with what you have said.
--> > --> >
--> > --> > Scaling of the number of forwarding entries in the 
--> core is not a
--> > --> > problem that the TRILL working group has decided to solve.
--> > --> >
--> > --> > Hence, you might conclude that the TRILL working group
--> > --> has passively
--> > --> > decided that this is not a problem that TRILL needs 
--> to solve.
--> > --> >
--> > --> > One reason why this might be the case is that people
--> > --> could not decide
--> > --> > the "by how much" question.
--> > --> >
--> > --> > Never-the-less, an implicit requirement that the solution
--> > --> should not
--> > --> > prevent more scalable implementations, enables people who
--> > --> might not
--> > --> > be able to agree in public (as to what factor of increased
--> > --> > scalability should apply) to produce and deploy solutions
--> > --> that are in
--> > --> > fact more scalable, by at least some amount.
--> > --> >
--> > --> > --> 2) Link utilization is a problem and TRILL needs to
--> > --> be concerned
--> > --> > --> with it.
--> > --> >
--> > --> > Certainly.
--> > --> >
--> > --> > -->
--> > --> > --> If this is correct, it leads me to believe that you
--> > --> would advocate
--> > --> > --> for
--> > --> > --> 1) Remove the destination RBridge from the shim, and
--> > --> just lookup
--> > --> > the
--> > --> > --> destination MAC directly
--> > --> >
--> > --> > How do you arrive at this conclusion?  There are
--> > --> scenarios where this
--> > --> > might be done, but clearly the use of a smaller field for
--> > --> a look-up
--> > --> > is traditionally viewed as likely to be quicker.
--> > -->
--> > --> I appologize for trying to put words in you mouth, but I am
--> > --> trying to
--> > --> understand what you are arguing for...and after 
--> reading the above,
--> I
--> > --> still don't know.  Maybe it is because I am confusing 
--> what you are
--> > --> personally saying versus what you are echoing from others
--> > --> in the group.
--> > --> Do you believe we need the RBridge Id in the shim or not?
--> > --> If you do,
--> > --> then why?  For a quicker lookup?  If so, then why would a
--> > --> slower lookup
--> > --> to generate the source RBridge for BCN be acceptable?
--> > -->
--> > --> >
--> > --> > --> 2) Eliminate the need for the outer MAC header 
--> between two
--> > --> > RBridges
--> > --> > --> if the link is point to point (quite likely in 
--> my opinion).
--> > --> >
--> > --> > Ultimately, point-to-point is very likely, but we have to
--> > --> deal with
--> > --> > the step-by-step deployment scenarios.
--> > --> >
--> > --> > In any case, I do not advocate special-casing
--> > --> encapsulation based on
--> > --> > link types in general - beyond that already required by
--> > --> the specific
--> > --> > link.  As I thought would be obvious by now, I advocate
--> functional
--> > --> > separation - which works better if you don't build in a
--> > --> lot of layer
--> > --> > dependencies.
--> > -->
--> > --> I agree with you about building in a lot of layer
--> > --> dependencies.  Having
--> > --> transit RBridges look inside the inner MAC seems like a
--> > --> layer dependency
--> > --> to me.  Not encapsulating with an extra 14 to 18 bytes on
--> > --> point to point
--> > --> link seems like it would be well worth it if you are
--> > --> concerned with link
--> > --> overhead.  I would gladly trade 14/18 bytes of overhead for
--> > --> another 2
--> > --> bytes of source RBridge which will help with BCN as well as
--> > --> help with
--> > --> network troubleshooting.
--> > -->
--> > --> >
--> > --> > -->
--> > --> > --> Again, I apologize for not keeping up with the latest
--> > --> discussions,
--> > --> > --> but have these ideas been discussed already?  
--> If so, could
--> you
--> > --> > --> summarize the outcome?
--> > --> >
--> > --> > This is not a reasonable request.
--> > -->
--> > --> Oh well, cant' blame me for trying can you? ;-)
--> > -->
--> > --> >
--> > --> > -- [SNIP] --
--> > -->
--> > _______________________________________________
--> > rbridge mailing list
--> > [e-mail]
--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA5I4qkM024785 for <[e-mail]>; Sun, 5 Nov 2006 10:04:53 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA5I4ffK019594; Sun, 5 Nov 2006 13:04:41 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA03034;  Sun, 5 Nov 2006 13:04:41 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB6489WL>; Sun, 5 Nov 2006 13:04:40 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "Sanjay Sane (sanjays)" <[e-mail]>, Russ White <[e-mail]>, [e-mail]
Date: Sun, 5 Nov 2006 13:04:39 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] How many trees, and per what
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 05 Nov 2006 18:05:03 -0000
Status: RO
Content-Length: 3408

Clearly one of the things we need to talk about this week is what exactly
do we mean by ingress rbridge tree. 

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Sanjay 
--> Sane (sanjays)
--> Sent: Friday, October 27, 2006 8:41 PM
--> To: Russ White; [e-mail]
--> Cc: [e-mail]
--> Subject: Re: [rbridge] How many trees, and per what
--> 
--> 
--> Russ, Radia, et. al.
--> 
--> Having a per-ingress rbridge tree, and using it for 
--> multicast delivery
--> has many issues
--> -- no scope for multicast multi-pathing/load-balancing
--> -- for an IP multicast that is only going to links with registered
--> receivers, we now need to build a state with 
--> # of ingress rbridges * # of groups. This is heavy on computation &
--> memory. 
--> 
--> Using shared multicast trees for multicast delivery avoids 
--> both above,
--> and the forwarding state is # of shared trees * # of groups. 
--> 
--> Also, instead of adding F-tag "values" to the context of 
--> the Rbridge-id,
--> why not treat "F-tag" as the Forwarding topology 
--> identifier. (quote from
--> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-
--> encap-00.txt
--> --> "The Forwarding Tag (FTag) identifies the forwarding topology
--> assigned to a given frame"). 
--> 
--> In the tree usage case (unknowns/multicast/broadcast), it's the tree
--> identifier. If flood/unknown packets are best sent using 
--> ingress-rbridge
--> tree, use the F-tag of the tree rooted at that ingress rbridge. If
--> multicast packets are best sent using shared-multicast 
--> trees, use the
--> F-tag of the (load-balanced) shared tree. 
--> 
--> Again, which tree/topology the packet is to be put onto, is 
--> the decision
--> made at the source/ingress rbridge. But once the tree is 
--> chosen, and the
--> F-tag is put on the packet, other rbridges honor the F-tag 
--> and forward
--> accordingly.  
--> 
--> -Sanjay
--> 
--> 
--> -----Original Message-----
--> From: Russ White [mailto:[e-mail]] 
--> Sent: Friday, October 27, 2006 3:02 PM
--> To: [e-mail]
--> Cc: Sanjay Sane (sanjays); [e-mail]
--> Subject: Re: [rbridge] How many trees, and per what
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> > So the question is whether we should multiply the number 
--> of trees by 
--> > the number of F-tag values. And if so, how many F-tag values are
--> really needed.
--> 
--> I seem to be lost in the F-tag discussion, someplace.... Time warp,
--> anyone? :-)
--> 
--> My original impression was one tree per device per vlan 
--> throughout the
--> entire cloud, with some consideration for multicast still 
--> be taken in. I
--> don't really understand why we'd want one pre f-tag, maybe someone
--> should explain what we'd hope to gain through this?
--> 
--> :-)
--> 
--> Russ
--> 
--> - --
--> [e-mail] CCIE <>< Grace Alone
--> 
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.4.2.2 (MingW32)
--> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--> 
--> iD8DBQFFQoHbER27sUhU9OQRAipMAJ4whaXVLKMKVOfXBujtgRfd3vgK5wCgvGGQ
--> r2IwhU5kgDBVfpL9FGJ16Yc=
--> =g8Wb
--> -----END PGP SIGNATURE-----
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA4MNApO027860 for <[e-mail]>; Sat, 4 Nov 2006 14:23:10 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 04 Nov 2006 14:23:10 -0800 (PST)
Received: from sun.com ([129.150.22.255]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Sat, 04 Nov 2006 14:23:08 -0800 (PST)
Date: Sat, 04 Nov 2006 14:23:07 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Eastlake III Donald-LDE008 <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between	com putation and optimality of delivery
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 04 Nov 2006 22:23:26 -0000
Status: RO
Content-Length: 2881

Actually, I think it would work to have all RBridges calculate
just a single bidirectional multicast tree (pruned according to VLANs 
and IP multicast downstream of
each port in the tree). Even if it was a fairly large
campus, if a negligible percentage of traffic was multicast/unknown 
destinations, this
wouldn't even be that suboptimal. Unicast would still go via optimal 
paths. But multicast would just
go according to the one tree.

Not that I'm advocating a single tree---it's just that I don't think it 
would be incorrect.

Radia

Eastlake III Donald-LDE008 wrote:

>I really can't see why the minimum should be one. In an network where
>Rbridge trees make any difference you have at least two Rbridges so I
>can't see why you wouldn't, at a minimum, have two trees. I think we
>should just prohibit Rbridges that claim to be able to support only one
>tree.
>
>Donald
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
>Behalf Of Radia Perlman
>Sent: Thursday, November 02, 2006 2:20 PM
>To: Sanjay Sane (sanjays)
>Cc: [e-mail]
>Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between
>com putation and optimality of delivery
>
>Warning---half-baked idea at the end of this message (my own---see
>"***")
>
>
>Sanjay Sane (sanjays) wrote:
>
>  
>
>>So, the TLV inside rbridge LSP could contain 2 things
>>1 -- "my priority for being a tree root is x". 
>>2 -- "I can support n trees"
>>
>>If both of these are absent, we could choose 1 tree, and the rbridge 
>>with lowest MAC address is the root of that single tree.
>>
>>-Sanjay
>>
>>    
>>
>Right. I'm a bit nervous about some random RBridge that can only support
>one tree, or that just leaves the TLV out, from going up and down. We
>have to make sure it's not unstable.
>
>Suppose the nickname of the RBridge with highest priority for being root
>is 24.
>Suppose ingress RBridge R1 doesn't notice that wimpy RBridge R5 (that
>can only support one tree) has joined the net, and R1 selects "79" as
>the tree .
>
>I guess we should say that if you see a specified tree that shouldn't be
>legal, you drop the packet, right?
>
>***An alternative is to continue forwarding it along the 79-tree and
>hey, if R5 is on the path, it will drop the packet and only nodes
>downstream from R5 will suffer. We could even do complicated things like
>say that you can calculate trees beyond R5's capabilities by considering
>links out of R5 to be infinity. That way a wimpy RBridge can be a leaf,
>and going up and down won't affect existing trees.
>
>Radia
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id kA4M9rIu024196 for <[e-mail]>; Sat, 4 Nov 2006 14:09:53 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-7.tower-128.messagelabs.com!1162678190!1994599!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [144.189.100.103]
Received: (qmail 18169 invoked from network); 4 Nov 2006 22:09:50 -0000
Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-7.tower-128.messagelabs.com with SMTP; 4 Nov 2006 22:09:50 -0000
Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id kA4M9oi3006615 for <[e-mail]>; Sat, 4 Nov 2006 15:09:50 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id kA4M9nJU020400 for <[e-mail]>; Sat, 4 Nov 2006 16:09:49 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 4 Nov 2006 17:09:47 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Compromise proposal---allowing tradeoff between	com putation and optimality of delivery
thread-index: Acb+tLKpGN3C4/Z9RQK5XOyXFq0iawBqN7jA
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA4M9rIu024196
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between	com putation and optimality of delivery
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 04 Nov 2006 22:10:30 -0000
Status: RO
Content-Length: 2082

I really can't see why the minimum should be one. In an network where
Rbridge trees make any difference you have at least two Rbridges so I
can't see why you wouldn't, at a minimum, have two trees. I think we
should just prohibit Rbridges that claim to be able to support only one
tree.

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Thursday, November 02, 2006 2:20 PM
To: Sanjay Sane (sanjays)
Cc: [e-mail]
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between
com putation and optimality of delivery

Warning---half-baked idea at the end of this message (my own---see
"***")


Sanjay Sane (sanjays) wrote:

>
>So, the TLV inside rbridge LSP could contain 2 things
>1 -- "my priority for being a tree root is x". 
>2 -- "I can support n trees"
>
>If both of these are absent, we could choose 1 tree, and the rbridge 
>with lowest MAC address is the root of that single tree.
>
>-Sanjay
>
Right. I'm a bit nervous about some random RBridge that can only support
one tree, or that just leaves the TLV out, from going up and down. We
have to make sure it's not unstable.

Suppose the nickname of the RBridge with highest priority for being root
is 24.
Suppose ingress RBridge R1 doesn't notice that wimpy RBridge R5 (that
can only support one tree) has joined the net, and R1 selects "79" as
the tree .

I guess we should say that if you see a specified tree that shouldn't be
legal, you drop the packet, right?

***An alternative is to continue forwarding it along the 79-tree and
hey, if R5 is on the path, it will drop the packet and only nodes
downstream from R5 will suffer. We could even do complicated things like
say that you can calculate trees beyond R5's capabilities by considering
links out of R5 to be infinity. That way a wimpy RBridge can be a leaf,
and going up and down won't affect existing trees.

Radia

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



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA4FcaSl016925 for <[e-mail]>; Sat, 4 Nov 2006 07:38:37 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 4 Nov 2006 07:38:33 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Traffic storms
Thread-Index: Acb/r8f9Li/idHdJSDSp/ugS2Mx8VAAd2y1w
From: "Silvano Gai" <[e-mail]>
To: <[e-mail]>, "Pierre Francois" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA4FcaSl016925
Cc: [e-mail], Gideon Kaempfer <[e-mail]>
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 04 Nov 2006 15:38:45 -0000
Status: RO
Content-Length: 10932

Radia,

I think this is an excellent idea

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, November 03, 2006 5:23 PM
> To: Pierre Francois
> Cc: Silvano Gai; Gray, Eric; Gideon Kaempfer; [e-mail]
> Subject: Re: [rbridge] Traffic storms
> 
> And since we don't have to be backwards compatible with existing IS-IS
> implementations, we could make
> the IS-IS loop avoidance enhancement mandatory in RBridge IS-IS.
> 
> Radia
> 
> 
> 
> ----- Original Message -----
> From: Pierre Francois <[e-mail]>
> Date: Friday, November 3, 2006 5:10 pm
> Subject: Re: [rbridge] Traffic storms
> 
> >
> > Silvano,
> >
> > See http://www.ietf.org/internet-drafts/draft-francois-ordered-fib-
> > 02.txt,for a loop avoidance mechanism for IS-IS/OSPF.
> >
> > See you in SD,
> >
> > Pierre.
> >
> >
> >
> > On Fri, 3 Nov 2006, Silvano Gai wrote:
> >
> > > Eric,
> > >
> > > Also I suggest that people that have solved the problem of having
> > a loop
> > > free topology using ISIS, submit proposasl so that we can compare
> > them.> Unfortunately I don't have one.
> > >
> > >
> > >
> > > -- Silvano
> > >
> > >
> > >
> > > ________________________________
> > >
> > > From: [e-mail] [[e-mail]] On
> > > Behalf Of Gray, Eric
> > > Sent: Friday, November 03, 2006 11:54 AM
> > > To: Gideon Kaempfer; Radia Perlman
> > > Cc: [e-mail]
> > > Subject: Re: [rbridge] Traffic storms
> > >
> > >
> > >
> > > Gideon,
> > >
> > >
> > >
> > >     "Drop BPDUs" is not (exactly) the same as ignore them.  We
> > use the
> > > term
> > >
> > > as short-hand for the one of three options we considered for
> > handling> BPDUs:
> > >
> > >
> > >
> > >     Drop (do not participate actively in STP, and do not pass
BPDUs
> > > through),
> > >
> > >     Transparent (pass BPDUs through - potentially altering them
> > in some
> > > way),
> > >
> > >     Participate (have each RBridge participate in STP as if it
> > were a
> > > bridge).
> > >
> > >
> > >
> > > Hence, when we say "Drop BPDUs" we are not saying that we cannot
> > look>
> > > at them, we are just saying that we're not doing one of the other
> > two> choices.
> > >
> > >
> > >
> > > --
> > >
> > > Eric
> > >
> > >
> > >
> > >
> > > ________________________________
> > >
> > >
> > > 	From: [e-mail]
> > > [[e-mail]] On Behalf Of Gideon Kaempfer
> > > 	Sent: Friday, November 03, 2006 1:40 AM
> > > 	To: Radia Perlman
> > > 	Cc: [e-mail]
> > > 	Subject: Re: [rbridge] Traffic storms
> > >
> > > 	Radia,
> > >
> > > 	Wouldn't this create a link between TRILL and STP we are trying
> > > to avoid?
> > >
> > > 	Relying on the fact that a LAN segment has some kind of unique
> > > identifier (such as the root bridge ID) seems like a very
practical
> > > solution to me, but strongly reliant on the fact that the Rbridges
> > > actually process BPDUs. I thought they were just meant to discard
> > them.> Is this acceptable?
> > >
> > > 	Regrads,
> > >
> > >          Gidi
> > >
> > >
> > >
> > > 	On 11/3/06, Radia Perlman <[e-mail]> wrote:
> > >
> > > 	The simplest way to put it, I think, is that in certain
> > > transitory
> > > 	situations there might be two
> > > 	RBridges that both think they are Designated RBridge, and that
> > > is bad,
> > > 	but should stop
> > > 	as soon as a single Hello is received by the RBridge who should
> > > not be
> > > 	Designated.
> > >
> > > 	I think PIM has similar transitory situations that can occur,
> > > and
> > > 	bridges can also have (hopefully
> > > 	temporary) problems if a repeater came up and merged two LANs. I
> > > think
> > > 	such things are
> > > 	annoying but not fatal. But I think it's possible we can with
> > > little
> > > 	effort avoid this problem.
> > >
> > > 	However, with RBridges, because the bridge spanning tree
> > > algorithm
> > > 	elects a Root, there's
> > > 	really a way of uniquely identifying a LAN (where "LAN" is a
> > > bunch of
> > > 	links connected with
> > > 	bridges). The unique identifier is the root bridge.
> > >
> > > 	When the B1-B2 link is down, RB1 and RB2 will see the topology
> > > as two
> > > 	separate links, and each
> > > 	one will have a distinct spanning tree Root bridge (RB1 will see
> > > B1, and
> > > 	RB2 will see B2 as the root).
> > >
> > > 	When the B1-B2 link comes up, the bridges will first merge the
> > > two
> > > 	links, and either RB1 or RB2 will
> > > 	see that the bridge spanning tree root has changed. This will be
> > > 	discovered before B1 and B2 forward
> > > 	traffic across the link because of the bridge forwarding delay.
> > > 	If B1 has better priority as bridge spanning tree root than B2,
> > > then RB1
> > > 	will not notice anything
> > > 	different when the B1-B2 link comes up. But RB2 will notice
> > > 	something different; the spanning tree root has changed
> > > identities from
> > > 	"B2" to "B1".
> > >
> > > 	Given this, RB2 could temporarily stop forwarding to or from the
> > > link
> > > 	when the Root bridge
> > > 	changes identities, though it should definitely immediately send
> > > IS-IS
> > > 	Hellos (either RB1 or RB2 will
> > > 	be elected Designated Router in the IS-IS election for that
> > > link). If
> > > 	RB2 has better prioirty for
> > > 	root, the RB1 will immediately stop forwarding to or from the
> > > link when
> > > 	it sees the Hello from RB2.
> > > 	If RB2 has better priority in the IS-IS election, then RB1
> > > should
> > > 	immediately send an IS-IS Hello
> > > 	when it sees a Hello from a new RBridge on the link.
> > >
> > > 	So I think this is not a big deal, and that if we are worried,
> > > we can
> > > 	specify that an RBridge should
> > > 	stop acting like the Designated RBridge for a few seconds after
> > > the
> > > 	identity of the Root in the spanning
> > > 	tree algorithm changes.
> > >
> > > 	Or we could be even fancier and have each RBridge announce in
> > > its IS-IS
> > > 	Hellos which LAN IDs it
> > > 	is Designated for, where a LAN ID is the MAC address of the Root
> > > bridge.
> > > 	So RB1 continue
> > > 	forwarding if the identity changes from B1 to B2 provided no
> > > other
> > > 	RBridge has claimed to be connected
> > > 	to B2. But if RB2's LSP claims it is attached to B2, then RB1
> > > must stop
> > > 	forwarding for enough time
> > > 	for the IS-IS election to sort itself out and choose a
> > > Designated RBridge.
> > >
> > > 	Radia
> > >
> > >
> > >
> > >
> > >
> > >
> > > 	Gideon Kaempfer wrote:
> > >
> > > 	>Following mention by Silvano of broadcast and multicast storms
> > > (and the need
> > > 	>to protect against them), I played around with different
> > > scenarios and came
> > > 	>upon one I would appreciate your comments on (in the hope I am
> > > pointing out
> > > 	>a non-existent issue with TRILL). I believe a broadcast and
> > > even a unicast
> > > 	>storm could be created as the result of a loop that isn't
> > > protected by TTL
> > > 	>nor by STP in the case of a link connecting two separate LAN
> > > segments coming
> > > 	>to life.
> > > 	>
> > > 	>- RB1 ---- RB2 -
> > > 	>   |        |
> > > 	>-  B1 --x-- B2 -
> > > 	>   |        |
> > > 	>   H1       H2
> > > 	>
> > > 	>1. The network (segment) involved consists of two Rbridges
> > > (RB1, RB2), two
> > > 	>bridges (B1, B2) and two hosts (H1, H2). They are physically
> > > connected as
> > > 	>depicted.
> > > 	>2. State A: the direct link between B1 and B2 is down. B1 and
> > > B2 find
> > > 	>themselves on different LAN segments and hence different
> > > spanning trees. RB1
> > > 	>and RB2 are both designated Rbridges (each for the segment of
> > > the
> > > 	>corresponding bridge).
> > > 	>3. State B: the direct link between B1 and B2 goes up (someone
> > > connects a
> > > 	>cable). B1 and B2 discover each other and establish a common
> > > spanning tree.
> > > 	>RB1 and RB2 both find themselves attached to the same LAN
> > > segment and hence
> > > 	>RB1 (without loss of generality) will eventually become the
> > > designated
> > > 	>Rbridge for it.
> > > 	>4. Just before RB1 and RB2 identify that they are both on the
> > > same segment
> > > 	>and RB2 stops functioning as a designated Rbridge the following
> > > scenario
> > > 	>seems possible:
> > > 	>  a. H1 sends a broadcast frame.
> > > 	>  b. B1 receives it and forwards to RB1 and B2.
> > > 	>  c. RB1 (encapsulates and) forwards to RB2.
> > > 	>  d. B2 forwards to RB2 and H2.
> > > 	>  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2
> > > to RB1).
> > > 	>  f. (RB1 forwards to B1.)
> > > 	>  g. B2 forwards (again) to H2 and to B1.
> > > 	>  h. B1 forwards to H1 (see remark below regarding filtering
> > > table
> > > 	>contamination) and to RB1.
> > > 	>  i. Etcetera etcetera.
> > > 	>5. A broadcast storm is born, created by a loop that is not
> > > protected by TTL
> > > 	>(due to the fact that forwarding between the Rbridges is only
> > > across a
> > > 	>single hop) nor by STP (due to the fact that Rbridges do not
> > > participate in
> > > 	>STP).
> > > 	>6. If forwarding commences at the hardware level and no
> > > broadcast rate
> > > 	>limiting is in place, the storm may cause severe damage in a
> > > very short time
> > > 	>(note that replicated frames are sent to H1 and H2 (or any
> > > network they
> > > 	>could represent).
> > > 	>7. Another unfortunate effect of this storm is that B1 and B2
> > > no longer know
> > > 	>where H1 is located (due to the contamination of their
> > > filtering tables by a
> > > 	>frame from H1 that arrives from the wrong direction (and in
> > > fact from
> > > 	>multiple directions). As a result, a possible unicast frame
> > > from H2 to H1
> > > 	>will just join the storm over the loop at least in one
> > > direction (RB2 will
> > > 	>forward it to RB1) but will not arrive at H1...
> > > 	>
> > > 	>One possible solution could be for RB2 to identify the fact
> > > that it is
> > > 	>receiving a frame from a host with a MAC address that is
> > > associated with a
> > > 	>segment it thought it isn't connected to. Hence, it may trigger
> > > an immediate
> > > 	>neighbor discovery / designated Rbridge election. However,
> > > because Rbridges
> > > 	>should allow host mobility, this frame may need to be forwarded
> > > (and hence
> > > 	>the storm commences).
> > > 	>
> > > 	>As mentioned above, any comments are welcome.
> > > 	>  Gideon Kaempfer
> > > 	>
> > > 	>_______________________________________________
> > > 	>rbridge mailing list
> > > 	>[e-mail]
> > > 	> http://mailman.postel.org/mailman/listinfo/rbridge
> > > <http://mailman.postel.org/mailman/listinfo/rbridge>
> > > 	>
> > > 	>
> > >
> > > 	_______________________________________________
> > > 	rbridge mailing list
> > > 	[e-mail]
> > > 	http://mailman.postel.org/mailman/listinfo/rbridge
> > >
> > >
> > >
> > >
> >




Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA41NAIQ015475 for <[e-mail]>; Fri, 3 Nov 2006 17:23:10 -0800 (PST)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 03 Nov 2006 17:23:06 -0800 (PST)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 03 Nov 2006 17:23:05 -0800 (PST)
Received: from [152.70.2.164] (Forwarded-For: [67.160.72.180]) by mail-srv.sfvic.sunlabs.com (mshttpd); Fri, 03 Nov 2006 17:23:05 -0800
Date: Fri, 03 Nov 2006 17:23:05 -0800
From: [e-mail]
To: Pierre Francois <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Gideon Kaempfer <[e-mail]>
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 04 Nov 2006 01:23:28 -0000
Status: RO
Content-Length: 9962

And since we don't have to be backwards compatible with existing IS-IS implementations, we could make
the IS-IS loop avoidance enhancement mandatory in RBridge IS-IS.

Radia



----- Original Message -----
From: Pierre Francois <[e-mail]>
Date: Friday, November 3, 2006 5:10 pm
Subject: Re: [rbridge] Traffic storms

> 
> Silvano,
> 
> See http://www.ietf.org/internet-drafts/draft-francois-ordered-fib-
> 02.txt,for a loop avoidance mechanism for IS-IS/OSPF.
> 
> See you in SD,
> 
> Pierre.
> 
> 
> 
> On Fri, 3 Nov 2006, Silvano Gai wrote:
> 
> > Eric,
> >
> > Also I suggest that people that have solved the problem of having 
> a loop
> > free topology using ISIS, submit proposasl so that we can compare 
> them.> Unfortunately I don't have one.
> >
> >
> >
> > -- Silvano
> >
> >
> >
> > ________________________________
> >
> > From: [e-mail] [[e-mail]] On
> > Behalf Of Gray, Eric
> > Sent: Friday, November 03, 2006 11:54 AM
> > To: Gideon Kaempfer; Radia Perlman
> > Cc: [e-mail]
> > Subject: Re: [rbridge] Traffic storms
> >
> >
> >
> > Gideon,
> >
> >
> >
> >     "Drop BPDUs" is not (exactly) the same as ignore them.  We 
> use the
> > term
> >
> > as short-hand for the one of three options we considered for 
> handling> BPDUs:
> >
> >
> >
> >     Drop (do not participate actively in STP, and do not pass BPDUs
> > through),
> >
> >     Transparent (pass BPDUs through - potentially altering them 
> in some
> > way),
> >
> >     Participate (have each RBridge participate in STP as if it 
> were a
> > bridge).
> >
> >
> >
> > Hence, when we say "Drop BPDUs" we are not saying that we cannot 
> look>
> > at them, we are just saying that we're not doing one of the other 
> two> choices.
> >
> >
> >
> > --
> >
> > Eric
> >
> >
> >
> >
> > ________________________________
> >
> >
> > 	From: [e-mail]
> > [[e-mail]] On Behalf Of Gideon Kaempfer
> > 	Sent: Friday, November 03, 2006 1:40 AM
> > 	To: Radia Perlman
> > 	Cc: [e-mail]
> > 	Subject: Re: [rbridge] Traffic storms
> >
> > 	Radia,
> >
> > 	Wouldn't this create a link between TRILL and STP we are trying
> > to avoid?
> >
> > 	Relying on the fact that a LAN segment has some kind of unique
> > identifier (such as the root bridge ID) seems like a very practical
> > solution to me, but strongly reliant on the fact that the Rbridges
> > actually process BPDUs. I thought they were just meant to discard 
> them.> Is this acceptable?
> >
> > 	Regrads,
> >
> >          Gidi
> >
> >
> >
> > 	On 11/3/06, Radia Perlman <[e-mail]> wrote:
> >
> > 	The simplest way to put it, I think, is that in certain
> > transitory
> > 	situations there might be two
> > 	RBridges that both think they are Designated RBridge, and that
> > is bad,
> > 	but should stop
> > 	as soon as a single Hello is received by the RBridge who should
> > not be
> > 	Designated.
> >
> > 	I think PIM has similar transitory situations that can occur,
> > and
> > 	bridges can also have (hopefully
> > 	temporary) problems if a repeater came up and merged two LANs. I
> > think
> > 	such things are
> > 	annoying but not fatal. But I think it's possible we can with
> > little
> > 	effort avoid this problem.
> >
> > 	However, with RBridges, because the bridge spanning tree
> > algorithm
> > 	elects a Root, there's
> > 	really a way of uniquely identifying a LAN (where "LAN" is a
> > bunch of
> > 	links connected with
> > 	bridges). The unique identifier is the root bridge.
> >
> > 	When the B1-B2 link is down, RB1 and RB2 will see the topology
> > as two
> > 	separate links, and each
> > 	one will have a distinct spanning tree Root bridge (RB1 will see
> > B1, and
> > 	RB2 will see B2 as the root).
> >
> > 	When the B1-B2 link comes up, the bridges will first merge the
> > two
> > 	links, and either RB1 or RB2 will
> > 	see that the bridge spanning tree root has changed. This will be
> > 	discovered before B1 and B2 forward
> > 	traffic across the link because of the bridge forwarding delay.
> > 	If B1 has better priority as bridge spanning tree root than B2,
> > then RB1
> > 	will not notice anything
> > 	different when the B1-B2 link comes up. But RB2 will notice
> > 	something different; the spanning tree root has changed
> > identities from
> > 	"B2" to "B1".
> >
> > 	Given this, RB2 could temporarily stop forwarding to or from the
> > link
> > 	when the Root bridge
> > 	changes identities, though it should definitely immediately send
> > IS-IS
> > 	Hellos (either RB1 or RB2 will
> > 	be elected Designated Router in the IS-IS election for that
> > link). If
> > 	RB2 has better prioirty for
> > 	root, the RB1 will immediately stop forwarding to or from the
> > link when
> > 	it sees the Hello from RB2.
> > 	If RB2 has better priority in the IS-IS election, then RB1
> > should
> > 	immediately send an IS-IS Hello
> > 	when it sees a Hello from a new RBridge on the link.
> >
> > 	So I think this is not a big deal, and that if we are worried,
> > we can
> > 	specify that an RBridge should
> > 	stop acting like the Designated RBridge for a few seconds after
> > the
> > 	identity of the Root in the spanning
> > 	tree algorithm changes.
> >
> > 	Or we could be even fancier and have each RBridge announce in
> > its IS-IS
> > 	Hellos which LAN IDs it
> > 	is Designated for, where a LAN ID is the MAC address of the Root
> > bridge.
> > 	So RB1 continue
> > 	forwarding if the identity changes from B1 to B2 provided no
> > other
> > 	RBridge has claimed to be connected
> > 	to B2. But if RB2's LSP claims it is attached to B2, then RB1
> > must stop
> > 	forwarding for enough time
> > 	for the IS-IS election to sort itself out and choose a
> > Designated RBridge.
> >
> > 	Radia
> >
> >
> >
> >
> >
> >
> > 	Gideon Kaempfer wrote:
> >
> > 	>Following mention by Silvano of broadcast and multicast storms
> > (and the need
> > 	>to protect against them), I played around with different
> > scenarios and came
> > 	>upon one I would appreciate your comments on (in the hope I am
> > pointing out
> > 	>a non-existent issue with TRILL). I believe a broadcast and
> > even a unicast
> > 	>storm could be created as the result of a loop that isn't
> > protected by TTL
> > 	>nor by STP in the case of a link connecting two separate LAN
> > segments coming
> > 	>to life.
> > 	>
> > 	>- RB1 ---- RB2 -
> > 	>   |        |
> > 	>-  B1 --x-- B2 -
> > 	>   |        |
> > 	>   H1       H2
> > 	>
> > 	>1. The network (segment) involved consists of two Rbridges
> > (RB1, RB2), two
> > 	>bridges (B1, B2) and two hosts (H1, H2). They are physically
> > connected as
> > 	>depicted.
> > 	>2. State A: the direct link between B1 and B2 is down. B1 and
> > B2 find
> > 	>themselves on different LAN segments and hence different
> > spanning trees. RB1
> > 	>and RB2 are both designated Rbridges (each for the segment of
> > the
> > 	>corresponding bridge).
> > 	>3. State B: the direct link between B1 and B2 goes up (someone
> > connects a
> > 	>cable). B1 and B2 discover each other and establish a common
> > spanning tree.
> > 	>RB1 and RB2 both find themselves attached to the same LAN
> > segment and hence
> > 	>RB1 (without loss of generality) will eventually become the
> > designated
> > 	>Rbridge for it.
> > 	>4. Just before RB1 and RB2 identify that they are both on the
> > same segment
> > 	>and RB2 stops functioning as a designated Rbridge the following
> > scenario
> > 	>seems possible:
> > 	>  a. H1 sends a broadcast frame.
> > 	>  b. B1 receives it and forwards to RB1 and B2.
> > 	>  c. RB1 (encapsulates and) forwards to RB2.
> > 	>  d. B2 forwards to RB2 and H2.
> > 	>  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2
> > to RB1).
> > 	>  f. (RB1 forwards to B1.)
> > 	>  g. B2 forwards (again) to H2 and to B1.
> > 	>  h. B1 forwards to H1 (see remark below regarding filtering
> > table
> > 	>contamination) and to RB1.
> > 	>  i. Etcetera etcetera.
> > 	>5. A broadcast storm is born, created by a loop that is not
> > protected by TTL
> > 	>(due to the fact that forwarding between the Rbridges is only
> > across a
> > 	>single hop) nor by STP (due to the fact that Rbridges do not
> > participate in
> > 	>STP).
> > 	>6. If forwarding commences at the hardware level and no
> > broadcast rate
> > 	>limiting is in place, the storm may cause severe damage in a
> > very short time
> > 	>(note that replicated frames are sent to H1 and H2 (or any
> > network they
> > 	>could represent).
> > 	>7. Another unfortunate effect of this storm is that B1 and B2
> > no longer know
> > 	>where H1 is located (due to the contamination of their
> > filtering tables by a
> > 	>frame from H1 that arrives from the wrong direction (and in
> > fact from
> > 	>multiple directions). As a result, a possible unicast frame
> > from H2 to H1
> > 	>will just join the storm over the loop at least in one
> > direction (RB2 will
> > 	>forward it to RB1) but will not arrive at H1...
> > 	>
> > 	>One possible solution could be for RB2 to identify the fact
> > that it is
> > 	>receiving a frame from a host with a MAC address that is
> > associated with a
> > 	>segment it thought it isn't connected to. Hence, it may trigger
> > an immediate
> > 	>neighbor discovery / designated Rbridge election. However,
> > because Rbridges
> > 	>should allow host mobility, this frame may need to be forwarded
> > (and hence
> > 	>the storm commences).
> > 	>
> > 	>As mentioned above, any comments are welcome.
> > 	>  Gideon Kaempfer
> > 	>
> > 	>_______________________________________________
> > 	>rbridge mailing list
> > 	>[e-mail]
> > 	> http://mailman.postel.org/mailman/listinfo/rbridge
> > <http://mailman.postel.org/mailman/listinfo/rbridge>
> > 	>
> > 	>
> >
> > 	_______________________________________________
> > 	rbridge mailing list
> > 	[e-mail]
> > 	http://mailman.postel.org/mailman/listinfo/rbridge
> >
> >
> >
> >
> 



Received: from info.ucl.ac.be ([130.104.229.109]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA41Bi9R010985 for <[e-mail]>; Fri, 3 Nov 2006 17:11:45 -0800 (PST)
Received: from sisley.info.ucl.ac.be (sisley [130.104.230.8]) by info.ucl.ac.be (8.12.11/8.12.11) with SMTP id kA41BUEB000878; Sat, 4 Nov 2006 02:11:31 +0100 (MET)
Date: Sat, 4 Nov 2006 02:10:11 +0100 (CET)
From: Pierre Francois <[e-mail]>
To: Silvano Gai <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-INGI-MailScanner-Information: Please contact the ISP for more information
X-INGI-MailScanner: Found to be clean
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Gideon Kaempfer <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 04 Nov 2006 01:12:11 -0000
Status: RO
Content-Length: 8994

Silvano,

See http://www.ietf.org/internet-drafts/draft-francois-ordered-fib-02.txt,
for a loop avoidance mechanism for IS-IS/OSPF.

See you in SD,

Pierre.



On Fri, 3 Nov 2006, Silvano Gai wrote:

> Eric,
>
> Also I suggest that people that have solved the problem of having a loop
> free topology using ISIS, submit proposasl so that we can compare them.
> Unfortunately I don't have one.
>
>
>
> -- Silvano
>
>
>
> ________________________________
>
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Gray, Eric
> Sent: Friday, November 03, 2006 11:54 AM
> To: Gideon Kaempfer; Radia Perlman
> Cc: [e-mail]
> Subject: Re: [rbridge] Traffic storms
>
>
>
> Gideon,
>
>
>
>     "Drop BPDUs" is not (exactly) the same as ignore them.  We use the
> term
>
> as short-hand for the one of three options we considered for handling
> BPDUs:
>
>
>
>     Drop (do not participate actively in STP, and do not pass BPDUs
> through),
>
>     Transparent (pass BPDUs through - potentially altering them in some
> way),
>
>     Participate (have each RBridge participate in STP as if it were a
> bridge).
>
>
>
> Hence, when we say "Drop BPDUs" we are not saying that we cannot look
>
> at them, we are just saying that we're not doing one of the other two
> choices.
>
>
>
> --
>
> Eric
>
>
>
>
> ________________________________
>
>
> 	From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Gideon Kaempfer
> 	Sent: Friday, November 03, 2006 1:40 AM
> 	To: Radia Perlman
> 	Cc: [e-mail]
> 	Subject: Re: [rbridge] Traffic storms
>
> 	Radia,
>
> 	Wouldn't this create a link between TRILL and STP we are trying
> to avoid?
>
> 	Relying on the fact that a LAN segment has some kind of unique
> identifier (such as the root bridge ID) seems like a very practical
> solution to me, but strongly reliant on the fact that the Rbridges
> actually process BPDUs. I thought they were just meant to discard them.
> Is this acceptable?
>
> 	Regrads,
>
> 	 Gidi
>
>
>
> 	On 11/3/06, Radia Perlman <[e-mail]> wrote:
>
> 	The simplest way to put it, I think, is that in certain
> transitory
> 	situations there might be two
> 	RBridges that both think they are Designated RBridge, and that
> is bad,
> 	but should stop
> 	as soon as a single Hello is received by the RBridge who should
> not be
> 	Designated.
>
> 	I think PIM has similar transitory situations that can occur,
> and
> 	bridges can also have (hopefully
> 	temporary) problems if a repeater came up and merged two LANs. I
> think
> 	such things are
> 	annoying but not fatal. But I think it's possible we can with
> little
> 	effort avoid this problem.
>
> 	However, with RBridges, because the bridge spanning tree
> algorithm
> 	elects a Root, there's
> 	really a way of uniquely identifying a LAN (where "LAN" is a
> bunch of
> 	links connected with
> 	bridges). The unique identifier is the root bridge.
>
> 	When the B1-B2 link is down, RB1 and RB2 will see the topology
> as two
> 	separate links, and each
> 	one will have a distinct spanning tree Root bridge (RB1 will see
> B1, and
> 	RB2 will see B2 as the root).
>
> 	When the B1-B2 link comes up, the bridges will first merge the
> two
> 	links, and either RB1 or RB2 will
> 	see that the bridge spanning tree root has changed. This will be
> 	discovered before B1 and B2 forward
> 	traffic across the link because of the bridge forwarding delay.
> 	If B1 has better priority as bridge spanning tree root than B2,
> then RB1
> 	will not notice anything
> 	different when the B1-B2 link comes up. But RB2 will notice
> 	something different; the spanning tree root has changed
> identities from
> 	"B2" to "B1".
>
> 	Given this, RB2 could temporarily stop forwarding to or from the
> link
> 	when the Root bridge
> 	changes identities, though it should definitely immediately send
> IS-IS
> 	Hellos (either RB1 or RB2 will
> 	be elected Designated Router in the IS-IS election for that
> link). If
> 	RB2 has better prioirty for
> 	root, the RB1 will immediately stop forwarding to or from the
> link when
> 	it sees the Hello from RB2.
> 	If RB2 has better priority in the IS-IS election, then RB1
> should
> 	immediately send an IS-IS Hello
> 	when it sees a Hello from a new RBridge on the link.
>
> 	So I think this is not a big deal, and that if we are worried,
> we can
> 	specify that an RBridge should
> 	stop acting like the Designated RBridge for a few seconds after
> the
> 	identity of the Root in the spanning
> 	tree algorithm changes.
>
> 	Or we could be even fancier and have each RBridge announce in
> its IS-IS
> 	Hellos which LAN IDs it
> 	is Designated for, where a LAN ID is the MAC address of the Root
> bridge.
> 	So RB1 continue
> 	forwarding if the identity changes from B1 to B2 provided no
> other
> 	RBridge has claimed to be connected
> 	to B2. But if RB2's LSP claims it is attached to B2, then RB1
> must stop
> 	forwarding for enough time
> 	for the IS-IS election to sort itself out and choose a
> Designated RBridge.
>
> 	Radia
>
>
>
>
>
>
> 	Gideon Kaempfer wrote:
>
> 	>Following mention by Silvano of broadcast and multicast storms
> (and the need
> 	>to protect against them), I played around with different
> scenarios and came
> 	>upon one I would appreciate your comments on (in the hope I am
> pointing out
> 	>a non-existent issue with TRILL). I believe a broadcast and
> even a unicast
> 	>storm could be created as the result of a loop that isn't
> protected by TTL
> 	>nor by STP in the case of a link connecting two separate LAN
> segments coming
> 	>to life.
> 	>
> 	>- RB1 ---- RB2 -
> 	>   |        |
> 	>-  B1 --x-- B2 -
> 	>   |        |
> 	>   H1       H2
> 	>
> 	>1. The network (segment) involved consists of two Rbridges
> (RB1, RB2), two
> 	>bridges (B1, B2) and two hosts (H1, H2). They are physically
> connected as
> 	>depicted.
> 	>2. State A: the direct link between B1 and B2 is down. B1 and
> B2 find
> 	>themselves on different LAN segments and hence different
> spanning trees. RB1
> 	>and RB2 are both designated Rbridges (each for the segment of
> the
> 	>corresponding bridge).
> 	>3. State B: the direct link between B1 and B2 goes up (someone
> connects a
> 	>cable). B1 and B2 discover each other and establish a common
> spanning tree.
> 	>RB1 and RB2 both find themselves attached to the same LAN
> segment and hence
> 	>RB1 (without loss of generality) will eventually become the
> designated
> 	>Rbridge for it.
> 	>4. Just before RB1 and RB2 identify that they are both on the
> same segment
> 	>and RB2 stops functioning as a designated Rbridge the following
> scenario
> 	>seems possible:
> 	>  a. H1 sends a broadcast frame.
> 	>  b. B1 receives it and forwards to RB1 and B2.
> 	>  c. RB1 (encapsulates and) forwards to RB2.
> 	>  d. B2 forwards to RB2 and H2.
> 	>  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2
> to RB1).
> 	>  f. (RB1 forwards to B1.)
> 	>  g. B2 forwards (again) to H2 and to B1.
> 	>  h. B1 forwards to H1 (see remark below regarding filtering
> table
> 	>contamination) and to RB1.
> 	>  i. Etcetera etcetera.
> 	>5. A broadcast storm is born, created by a loop that is not
> protected by TTL
> 	>(due to the fact that forwarding between the Rbridges is only
> across a
> 	>single hop) nor by STP (due to the fact that Rbridges do not
> participate in
> 	>STP).
> 	>6. If forwarding commences at the hardware level and no
> broadcast rate
> 	>limiting is in place, the storm may cause severe damage in a
> very short time
> 	>(note that replicated frames are sent to H1 and H2 (or any
> network they
> 	>could represent).
> 	>7. Another unfortunate effect of this storm is that B1 and B2
> no longer know
> 	>where H1 is located (due to the contamination of their
> filtering tables by a
> 	>frame from H1 that arrives from the wrong direction (and in
> fact from
> 	>multiple directions). As a result, a possible unicast frame
> from H2 to H1
> 	>will just join the storm over the loop at least in one
> direction (RB2 will
> 	>forward it to RB1) but will not arrive at H1...
> 	>
> 	>One possible solution could be for RB2 to identify the fact
> that it is
> 	>receiving a frame from a host with a MAC address that is
> associated with a
> 	>segment it thought it isn't connected to. Hence, it may trigger
> an immediate
> 	>neighbor discovery / designated Rbridge election. However,
> because Rbridges
> 	>should allow host mobility, this frame may need to be forwarded
> (and hence
> 	>the storm commences).
> 	>
> 	>As mentioned above, any comments are welcome.
> 	>  Gideon Kaempfer
> 	>
> 	>_______________________________________________
> 	>rbridge mailing list
> 	>[e-mail]
> 	> http://mailman.postel.org/mailman/listinfo/rbridge
> <http://mailman.postel.org/mailman/listinfo/rbridge>
> 	>
> 	>
>
> 	_______________________________________________
> 	rbridge mailing list
> 	[e-mail]
> 	http://mailman.postel.org/mailman/listinfo/rbridge
>
>
>
>


Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA3NECpp010007 for <[e-mail]>; Fri, 3 Nov 2006 15:14:12 -0800 (PST)
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2006 15:14:13 -0800
X-IronPort-AV: i="4.09,386,1157353200";  d="scan'208"; a="754500603:sNHT50089348"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA3NECFc007901 for <[e-mail]>; Fri, 3 Nov 2006 15:14:12 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA3NECin019708 for <[e-mail]>; Fri, 3 Nov 2006 15:14:12 -0800 (PST)
Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Nov 2006 15:14:07 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 3 Nov 2006 15:14:06 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] LIDs
Thread-Index: Acby4lFXsEqxu94iRvehpH6TvWktDQAD3QvAAwQ1XmAAGebSgAALtn/A
From: "Larry Kreeger \(kreeger\)" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>, "Erik Nordmark" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 03 Nov 2006 23:14:07.0120 (UTC) FILETIME=[C2E25900:01C6FF9D]
DKIM-Signature: a=rsa-sha1; q=dns; l=2433; t=1162595652; x=1163459652; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=22Larry=20Kreeger=20\(kreeger\)=22=20<[e-mail]> |Subject:RE=3A=20[rbridge]=20LIDs; X=v=3Dcisco.com=3B=20h=3DVQQgirXyliGfNg3+e0DNukZB8Bo=3D; b=dCXWehJWvcFe2I9wj123SUvWJfQe/80K1AuxIFvUc9QtkXdHt+qsdeyePnlBAs/US74cOhlB wjajt78mh6fWccuP8MGMtnF+yz1InPv5/5ze6Dopr+LF6OBg7IHxx0VB;
Authentication-Results: sj-dkim-2.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA3NECpp010007
Cc: [e-mail]
Subject: Re: [rbridge] LIDs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 23:14:18 -0000
Status: RO
Content-Length: 2364

Caitlin Bestler wrote on Friday, November 03, 2006 9:07 AM:

> Larry Kreeger (kreeger) wrote:
>> Hi,
>> 
>> I was catching up on old RBridge threads and saw this one about LIDs.
>> 
>> LIDs can be useful in reducing costs in large switches where the
>> entire (potentially large) local MAC table would not need to be
>> present in every module of the system.  In fact it could probably
>> eliminate the need to keep locally learned MACs in hardware at all.
>> Assuming a switch with 16 slots and
>> 48 ports per linecard, and servers running 16 virtual machines each
>> connected to the ports, the number of local MACs would be 16*48*16=
>> 12,288.  With 48 bits per address, that is ~59kbits.
>> 
>> With LIDs, an entry is need only per port, not per local MAC.
>>  So given a 16 bit LID, only 16 cards * 48 ports * 16 bits =
>> ~12kbits, a savings of ~47kbits. 
>> 
>> The more locally attached MACs, the bigger the savings.
>> 
> 
> Instead of keeping the MAC to Port mapping in the egress RBridge you
> instead keep it in each ingress rbridge that has learned of this
> rbridge. I'm not seeing a net savings in memory costs anywhere. There
> is certainly a potential latency benefit, but is there really one
> that is valid over the desired lifespan of the protocol?    

The ingress RBridge must already have a mapping from MAC to egress
RBridge nickname.  So, the table must only be widened to include the LID
- which is much smaller (depending on the size of the LID) than the MAC
to port mapping needed at the egress RBridge.

Also, the size of the table at the ingress RBridge depends on how many
end stations are being actively communicated with from that RBridge.  If
the ingress RBridge is a distributed system, then each module (e.g.
ASIC) only needs to populate the table with mappings for the active
flows through that part of the system.  If we assume that every end
station is not directly communicating with every other end station, then
different entries would exist in each MAC -> Egress RBridge/LID table.
This allows a large distributed system to scale up without requiring
each ASIC to increase its table size - because the mapping to LID is
spread out versus being concentrated at the inter-RBridge port ASICs of
a large RBridge.

It all depends on ratio of RBridge size (locally MAC addresses) versus
the number of flow active.

 - Larry



Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA3MRUJn024071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 3 Nov 2006 14:27:32 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 988E0E7C1C; Fri,  3 Nov 2006 23:27:29 +0100 (CET)
Received: from [10.0.0.4] (39.Red-80-37-137.staticIP.rima-tde.net [80.37.137.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 2A966E7C04; Fri,  3 Nov 2006 23:27:28 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 03 Nov 2006 23:27:25 +0100
From: =?windows-1252?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Gideon Kaempfer <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 22:27:49 -0000
Status: RO
Content-Length: 13857

I had no time to read the above discussion. However I have got the 
impression that it is much simpler to depend on RSTP/STP protocol for 
root bridge election to perform DR election. I understand that 
dependency on other protocol is not desirable, however we must be aware 
that RBridges operate in the same domain that spanning tree protocols, 
so it seems perhaps too optimistic to expect full independence between 
them.
I am aware that it is an old and past discussion, but I think any 
alternatives for DR election ignoring RSTP/STP protocol will be 
difficult to synchronize in reconfiguration. It seems natural that, if 
links get organized by STP/RSTP, the root bridge resulting should be 
related with DR RBridge. Root bridge is the "natural" gateway for a 
bridged LAN to/from the RBridges network.
Regards
Guilllermo

Gray, Eric escribi?:
> Silvano,
> Does the specification currently say that you MUST /*ignore*/ BPDUs?
> I looked at the 3 drafts currently under discussion, and none of them
> say that you should (let alone MUST) ignore BPDUs. The Architecture
> draft - which is strictly informative - says that it (the draft) 
> assumes that
> RBridges "block STP." And this occurs immediately after listing the
> options considered (and listed in my reply to Gideon).
> The base protocol specification says "RBridges MUST recognize and
> drop BPDUs." This is - IMO - significantly different from ignoring them,
> but we could potentailly ask for clarification. IMO, recognizing BPDUs
> is sufficient to accomplish what has been suggested.
> The P&AS is ambivalent on the topic. So where have we said that you
> MUST ignore BPDUs.
> Even if a "standards track" specification did say that you MUST ignore
> BPDUs, what do you suppose is going to happen to you if you don't
> ignore them?
> I am pretty sure that nobody initially meant for routers to "snoop" IGMP
> messages, for bridges to "snoop" routing advertisements and ARPs, or
> for hubs to "snoop" BPDUs, or perform MAC learning. yet all of these
> things happen - and are even sometimes assumed to happen - in real
> world implementations.
> Implementations live in the real world.
> But I agree that it is probably necessary to say that RBridges MUST
> employ some means for detecting brdiging topology changes, citing
> some of the methods we've discussed as examples. That might - all
> by itself - clarify the meaning of the expression "recognize and drop."
> --
> Eric
>
>     ------------------------------------------------------------------------
>     *From:* Silvano Gai [mailto:[e-mail]]
>     *Sent:* Friday, November 03, 2006 3:19 PM
>     *To:* Gray, Eric; Gideon Kaempfer; Radia Perlman
>     *Cc:* [e-mail]
>     *Subject:* RE: [rbridge] Traffic storms
>
>     Eric,
>
>     TRILL needs to be a well defined spec that guarantees products
>     that are interoperable.
>
>     If you write in the spec that BPDUs must be ignored, I will drop them.
>
>     If I need to do something different with BPDUs, then let?s spell
>     it out in the spec.
>
>     I don?t like the attitude, ?oh, the spec is broken, but there is
>     some magic that will fix it?.
>
>     Let?s write in the spec what is this magic.
>
>     Also I suggest that people that have solved the problem of having
>     a loop free topology using ISIS, submit proposasl so that we can
>     compare them. Unfortunately I don?t have one.
>
>     -- Silvano
>
>     ------------------------------------------------------------------------
>
>     *From:* [e-mail]
>     [mailto:[e-mail]] *On Behalf Of *Gray, Eric
>     *Sent:* Friday, November 03, 2006 11:54 AM
>     *To:* Gideon Kaempfer; Radia Perlman
>     *Cc:* [e-mail]
>     *Subject:* Re: [rbridge] Traffic storms
>
>     Gideon,
>
>     "Drop BPDUs" is not (exactly) the same as ignore them. We use the
>     term
>
>     as short-hand for the one of three options we considered for
>     handling BPDUs:
>
>     Drop (do not participate actively in STP, and do not pass BPDUs
>     through),
>
>     Transparent (pass BPDUs through - potentially altering them in
>     some way),
>
>     Participate (have each RBridge participate in STP as if it were a
>     bridge).
>
>     Hence, when we say "Drop BPDUs" we are not saying that we cannot look
>
>     at them, we are just saying that we're not doing one of the other
>     two choices.
>
>     --
>
>     Eric
>
>         ------------------------------------------------------------------------
>
>         *From:* [e-mail]
>         [mailto:[e-mail]] *On Behalf Of *Gideon Kaempfer
>         *Sent:* Friday, November 03, 2006 1:40 AM
>         *To:* Radia Perlman
>         *Cc:* [e-mail]
>         *Subject:* Re: [rbridge] Traffic storms
>
>         Radia,
>
>         Wouldn't this create a link between TRILL and STP we are
>         trying to avoid?
>
>         Relying on the fact that a LAN segment has some kind of unique
>         identifier (such as the root bridge ID) seems like a very
>         practical solution to me, but strongly reliant on the fact
>         that the Rbridges actually process BPDUs. I thought they were
>         just meant to discard them. Is this acceptable?
>
>         Regrads,
>
>         Gidi
>
>         On 11/3/06, *Radia Perlman* <[e-mail]
>         <mailto:[e-mail]>> wrote:
>
>         The simplest way to put it, I think, is that in certain transitory
>         situations there might be two
>         RBridges that both think they are Designated RBridge, and that
>         is bad,
>         but should stop
>         as soon as a single Hello is received by the RBridge who
>         should not be
>         Designated.
>
>         I think PIM has similar transitory situations that can occur, and
>         bridges can also have (hopefully
>         temporary) problems if a repeater came up and merged two LANs.
>         I think
>         such things are
>         annoying but not fatal. But I think it's possible we can with
>         little
>         effort avoid this problem.
>
>         However, with RBridges, because the bridge spanning tree
>         algorithm
>         elects a Root, there's
>         really a way of uniquely identifying a LAN (where "LAN" is a
>         bunch of
>         links connected with
>         bridges). The unique identifier is the root bridge.
>
>         When the B1-B2 link is down, RB1 and RB2 will see the topology
>         as two
>         separate links, and each
>         one will have a distinct spanning tree Root bridge (RB1 will
>         see B1, and
>         RB2 will see B2 as the root).
>
>         When the B1-B2 link comes up, the bridges will first merge the two
>         links, and either RB1 or RB2 will
>         see that the bridge spanning tree root has changed. This will be
>         discovered before B1 and B2 forward
>         traffic across the link because of the bridge forwarding delay.
>         If B1 has better priority as bridge spanning tree root than
>         B2, then RB1
>         will not notice anything
>         different when the B1-B2 link comes up. But RB2 will notice
>         something different; the spanning tree root has changed
>         identities from
>         "B2" to "B1".
>
>         Given this, RB2 could temporarily stop forwarding to or from
>         the link
>         when the Root bridge
>         changes identities, though it should definitely immediately
>         send IS-IS
>         Hellos (either RB1 or RB2 will
>         be elected Designated Router in the IS-IS election for that
>         link). If
>         RB2 has better prioirty for
>         root, the RB1 will immediately stop forwarding to or from the
>         link when
>         it sees the Hello from RB2.
>         If RB2 has better priority in the IS-IS election, then RB1 should
>         immediately send an IS-IS Hello
>         when it sees a Hello from a new RBridge on the link.
>
>         So I think this is not a big deal, and that if we are worried,
>         we can
>         specify that an RBridge should
>         stop acting like the Designated RBridge for a few seconds
>         after the
>         identity of the Root in the spanning
>         tree algorithm changes.
>
>         Or we could be even fancier and have each RBridge announce in
>         its IS-IS
>         Hellos which LAN IDs it
>         is Designated for, where a LAN ID is the MAC address of the
>         Root bridge.
>         So RB1 continue
>         forwarding if the identity changes from B1 to B2 provided no other
>         RBridge has claimed to be connected
>         to B2. But if RB2's LSP claims it is attached to B2, then RB1
>         must stop
>         forwarding for enough time
>         for the IS-IS election to sort itself out and choose a
>         Designated RBridge.
>
>         Radia
>
>
>
>
>
>
>         Gideon Kaempfer wrote:
>
>         >Following mention by Silvano of broadcast and multicast storms
>         (and the need
>         >to protect against them), I played around with different
>         scenarios and came
>         >upon one I would appreciate your comments on (in the hope I am
>         pointing out
>         >a non-existent issue with TRILL). I believe a broadcast and
>         even a unicast
>         >storm could be created as the result of a loop that isn't
>         protected by TTL
>         >nor by STP in the case of a link connecting two separate LAN
>         segments coming
>         >to life.
>         >
>         >- RB1 ---- RB2 -
>         > | |
>         >- B1 --x-- B2 -
>         > | |
>         > H1 H2
>         >
>         >1. The network (segment) involved consists of two Rbridges
>         (RB1, RB2), two
>         >bridges (B1, B2) and two hosts (H1, H2). They are physically
>         connected as
>         >depicted.
>         >2. State A: the direct link between B1 and B2 is down. B1 and
>         B2 find
>         >themselves on different LAN segments and hence different
>         spanning trees. RB1
>         >and RB2 are both designated Rbridges (each for the segment of the
>         >corresponding bridge).
>         >3. State B: the direct link between B1 and B2 goes up (someone
>         connects a
>         >cable). B1 and B2 discover each other and establish a common
>         spanning tree.
>         >RB1 and RB2 both find themselves attached to the same LAN
>         segment and hence
>         >RB1 (without loss of generality) will eventually become the
>         designated
>         >Rbridge for it.
>         >4. Just before RB1 and RB2 identify that they are both on the
>         same segment
>         >and RB2 stops functioning as a designated Rbridge the
>         following scenario
>         >seems possible:
>         > a. H1 sends a broadcast frame.
>         > b. B1 receives it and forwards to RB1 and B2.
>         > c. RB1 (encapsulates and) forwards to RB2.
>         > d. B2 forwards to RB2 and H2.
>         > e. RB2 forwards the copy from RB1 to B2 (and the copy from B2
>         to RB1).
>         > f. (RB1 forwards to B1.)
>         > g. B2 forwards (again) to H2 and to B1.
>         > h. B1 forwards to H1 (see remark below regarding filtering table
>         >contamination) and to RB1.
>         > i. Etcetera etcetera.
>         >5. A broadcast storm is born, created by a loop that is not
>         protected by TTL
>         >(due to the fact that forwarding between the Rbridges is only
>         across a
>         >single hop) nor by STP (due to the fact that Rbridges do not
>         participate in
>         >STP).
>         >6. If forwarding commences at the hardware level and no
>         broadcast rate
>         >limiting is in place, the storm may cause severe damage in a
>         very short time
>         >(note that replicated frames are sent to H1 and H2 (or any
>         network they
>         >could represent).
>         >7. Another unfortunate effect of this storm is that B1 and B2
>         no longer know
>         >where H1 is located (due to the contamination of their
>         filtering tables by a
>         >frame from H1 that arrives from the wrong direction (and in
>         fact from
>         >multiple directions). As a result, a possible unicast frame
>         from H2 to H1
>         >will just join the storm over the loop at least in one
>         direction (RB2 will
>         >forward it to RB1) but will not arrive at H1...
>         >
>         >One possible solution could be for RB2 to identify the fact
>         that it is
>         >receiving a frame from a host with a MAC address that is
>         associated with a
>         >segment it thought it isn't connected to. Hence, it may
>         trigger an immediate
>         >neighbor discovery / designated Rbridge election. However,
>         because Rbridges
>         >should allow host mobility, this frame may need to be
>         forwarded (and hence
>         >the storm commences).
>         >
>         >As mentioned above, any comments are welcome.
>         > Gideon Kaempfer
>         >
>         >_______________________________________________
>         >rbridge mailing list
>         >[e-mail] <mailto:[e-mail]>
>         > http://mailman.postel.org/mailman/listinfo/rbridge
>         >
>         >
>
>         _______________________________________________
>         rbridge mailing list
>         [e-mail] <mailto:[e-mail]>
>         http://mailman.postel.org/mailman/listinfo/rbridge
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA3LSRua005741 for <[e-mail]>; Fri, 3 Nov 2006 13:28:27 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA3LSMfK004209; Fri, 3 Nov 2006 16:28:23 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA15877;  Fri, 3 Nov 2006 16:28:22 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB64845D>; Fri, 3 Nov 2006 16:28:21 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>
Date: Fri, 3 Nov 2006 16:28:18 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FF8E.FA51687C"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Gideon Kaempfer <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 21:29:26 -0000
Status: RO
Content-Length: 36436

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C6FF8E.FA51687C
Content-Type: text/plain

Silvano,
 
Does the specification currently say that you MUST ignore BPDUs?
 
I looked at the 3 drafts currently under discussion, and none of them
say that you should (let alone MUST) ignore BPDUs.  The Architecture
draft - which is strictly informative - says that it (the draft) assumes
that
RBridges "block STP."  And this occurs immediately after listing the
options considered (and listed in my reply to Gideon).
 
The base protocol specification says "RBridges MUST recognize and 
drop BPDUs." This is - IMO - significantly different from ignoring them,
but we could potentailly ask for clarification.  IMO, recognizing BPDUs
is sufficient to accomplish what has been suggested.
 
The P&AS is ambivalent on the topic.  So where have we said that you
MUST ignore BPDUs.
 
Even if a "standards track" specification did say that you MUST ignore
BPDUs, what do you suppose is going to happen to you if you don't 
ignore them?
 
I am pretty sure that nobody initially meant for routers to "snoop" IGMP
messages, for bridges to "snoop" routing advertisements and ARPs, or 
for hubs to "snoop" BPDUs, or perform MAC learning.  yet all of these 
things happen - and are even sometimes assumed to happen - in real 
world implementations.
 
Implementations live in the real world.  
 
But I agree that it is probably necessary to say that RBridges MUST
employ some means for detecting brdiging topology changes, citing
some of the methods we've discussed as examples.  That might - all
by itself - clarify the meaning of the expression "recognize and drop."
 
--
Eric


  _____  

From: Silvano Gai [mailto:[e-mail]] 
Sent: Friday, November 03, 2006 3:19 PM
To: Gray, Eric; Gideon Kaempfer; Radia Perlman
Cc: [e-mail]
Subject: RE: [rbridge] Traffic storms



Eric,

 

TRILL needs to be a well defined spec that guarantees products that are
interoperable.

If you write in the spec that BPDUs must be ignored, I will drop them.

 

If I need to do something different with BPDUs, then let's spell it out in
the spec.

 

I don't like the attitude, "oh, the spec is broken, but there is some magic
that will fix it".

Let's write in the spec what is this magic.

 

Also I suggest that people that have solved the problem of having a loop
free topology using ISIS, submit proposasl so that we can compare them.
Unfortunately I don't have one.

 

-- Silvano

 


  _____  


From: [e-mail] [mailto:[e-mail]] On
Behalf Of Gray, Eric
Sent: Friday, November 03, 2006 11:54 AM
To: Gideon Kaempfer; Radia Perlman
Cc: [e-mail]
Subject: Re: [rbridge] Traffic storms

 

Gideon,

 

    "Drop BPDUs" is not (exactly) the same as ignore them.  We use the term 

as short-hand for the one of three options we considered for handling BPDUs:


 

    Drop (do not participate actively in STP, and do not pass BPDUs
through), 

    Transparent (pass BPDUs through - potentially altering them in some
way),

    Participate (have each RBridge participate in STP as if it were a
bridge).

 

Hence, when we say "Drop BPDUs" we are not saying that we cannot look 

at them, we are just saying that we're not doing one of the other two
choices.

 

--

Eric

 


  _____  


From: [e-mail] [mailto:[e-mail]] On
Behalf Of Gideon Kaempfer
Sent: Friday, November 03, 2006 1:40 AM
To: Radia Perlman
Cc: [e-mail]
Subject: Re: [rbridge] Traffic storms

Radia,

Wouldn't this create a link between TRILL and STP we are trying to avoid?

Relying on the fact that a LAN segment has some kind of unique identifier
(such as the root bridge ID) seems like a very practical solution to me, but
strongly reliant on the fact that the Rbridges actually process BPDUs. I
thought they were just meant to discard them. Is this acceptable? 

Regrads,

 Gidi

 

On 11/3/06, Radia Perlman <[e-mail]
<mailto:[e-mail]> > wrote: 

The simplest way to put it, I think, is that in certain transitory
situations there might be two
RBridges that both think they are Designated RBridge, and that is bad, 
but should stop
as soon as a single Hello is received by the RBridge who should not be
Designated.

I think PIM has similar transitory situations that can occur, and
bridges can also have (hopefully
temporary) problems if a repeater came up and merged two LANs. I think
such things are
annoying but not fatal. But I think it's possible we can with little
effort avoid this problem.

However, with RBridges, because the bridge spanning tree algorithm 
elects a Root, there's
really a way of uniquely identifying a LAN (where "LAN" is a bunch of
links connected with
bridges). The unique identifier is the root bridge.

When the B1-B2 link is down, RB1 and RB2 will see the topology as two 
separate links, and each
one will have a distinct spanning tree Root bridge (RB1 will see B1, and
RB2 will see B2 as the root).

When the B1-B2 link comes up, the bridges will first merge the two
links, and either RB1 or RB2 will 
see that the bridge spanning tree root has changed. This will be
discovered before B1 and B2 forward
traffic across the link because of the bridge forwarding delay.
If B1 has better priority as bridge spanning tree root than B2, then RB1 
will not notice anything
different when the B1-B2 link comes up. But RB2 will notice
something different; the spanning tree root has changed identities from
"B2" to "B1".

Given this, RB2 could temporarily stop forwarding to or from the link 
when the Root bridge
changes identities, though it should definitely immediately send IS-IS
Hellos (either RB1 or RB2 will
be elected Designated Router in the IS-IS election for that link). If
RB2 has better prioirty for 
root, the RB1 will immediately stop forwarding to or from the link when
it sees the Hello from RB2.
If RB2 has better priority in the IS-IS election, then RB1 should
immediately send an IS-IS Hello
when it sees a Hello from a new RBridge on the link. 

So I think this is not a big deal, and that if we are worried, we can
specify that an RBridge should
stop acting like the Designated RBridge for a few seconds after the
identity of the Root in the spanning 
tree algorithm changes.

Or we could be even fancier and have each RBridge announce in its IS-IS
Hellos which LAN IDs it
is Designated for, where a LAN ID is the MAC address of the Root bridge.
So RB1 continue 
forwarding if the identity changes from B1 to B2 provided no other
RBridge has claimed to be connected
to B2. But if RB2's LSP claims it is attached to B2, then RB1 must stop
forwarding for enough time
for the IS-IS election to sort itself out and choose a Designated RBridge. 

Radia






Gideon Kaempfer wrote:

>Following mention by Silvano of broadcast and multicast storms (and the
need
>to protect against them), I played around with different scenarios and came

>upon one I would appreciate your comments on (in the hope I am pointing out
>a non-existent issue with TRILL). I believe a broadcast and even a unicast
>storm could be created as the result of a loop that isn't protected by TTL 
>nor by STP in the case of a link connecting two separate LAN segments
coming
>to life.
>
>- RB1 ---- RB2 -
>   |        |
>-  B1 --x-- B2 -
>   |        |
>   H1       H2
>
>1. The network (segment) involved consists of two Rbridges (RB1, RB2), two
>bridges (B1, B2) and two hosts (H1, H2). They are physically connected as
>depicted.
>2. State A: the direct link between B1 and B2 is down. B1 and B2 find 
>themselves on different LAN segments and hence different spanning trees.
RB1
>and RB2 are both designated Rbridges (each for the segment of the
>corresponding bridge).
>3. State B: the direct link between B1 and B2 goes up (someone connects a 
>cable). B1 and B2 discover each other and establish a common spanning tree.
>RB1 and RB2 both find themselves attached to the same LAN segment and hence
>RB1 (without loss of generality) will eventually become the designated 
>Rbridge for it.
>4. Just before RB1 and RB2 identify that they are both on the same segment
>and RB2 stops functioning as a designated Rbridge the following scenario
>seems possible:
>  a. H1 sends a broadcast frame. 
>  b. B1 receives it and forwards to RB1 and B2.
>  c. RB1 (encapsulates and) forwards to RB2.
>  d. B2 forwards to RB2 and H2.
>  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2 to RB1). 
>  f. (RB1 forwards to B1.)
>  g. B2 forwards (again) to H2 and to B1.
>  h. B1 forwards to H1 (see remark below regarding filtering table
>contamination) and to RB1.
>  i. Etcetera etcetera. 
>5. A broadcast storm is born, created by a loop that is not protected by
TTL
>(due to the fact that forwarding between the Rbridges is only across a
>single hop) nor by STP (due to the fact that Rbridges do not participate in

>STP).
>6. If forwarding commences at the hardware level and no broadcast rate
>limiting is in place, the storm may cause severe damage in a very short
time
>(note that replicated frames are sent to H1 and H2 (or any network they 
>could represent).
>7. Another unfortunate effect of this storm is that B1 and B2 no longer
know
>where H1 is located (due to the contamination of their filtering tables by
a
>frame from H1 that arrives from the wrong direction (and in fact from 
>multiple directions). As a result, a possible unicast frame from H2 to H1
>will just join the storm over the loop at least in one direction (RB2 will
>forward it to RB1) but will not arrive at H1...
>
>One possible solution could be for RB2 to identify the fact that it is
>receiving a frame from a host with a MAC address that is associated with a
>segment it thought it isn't connected to. Hence, it may trigger an
immediate 
>neighbor discovery / designated Rbridge election. However, because Rbridges
>should allow host mobility, this frame may need to be forwarded (and hence
>the storm commences).
>
>As mentioned above, any comments are welcome. 
>  Gideon Kaempfer
>
>_______________________________________________
>rbridge mailing list
>[e-mail] <mailto:[e-mail]> 
>  <http://mailman.postel.org/mailman/listinfo/rbridge>
http://mailman.postel.org/mailman/listinfo/rbridge
>
>

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

 


------_=_NextPart_001_01C6FF8E.FA51687C
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = 
"urn:schemas-microsoft-com:vml" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">


<META content="MSHTML 6.00.2800.1561" name=GENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 90.0pt 72.0pt 90.0pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=EN-US vLink=blue link=blue>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2>Silvano,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2>Does the specification currently say that you MUST 
<EM><STRONG>ignore</STRONG></EM> BPDUs?</DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2>I looked at the 3 drafts currently under discussion, and 
none of them</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006>say that you should (let 
alone MUST) ignore BPDUs.&nbsp; The Architecture</SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006>draft - which is strictly 
informative - says that it (the draft) assumes that</SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006>RBridges "block 
STP."&nbsp; And this occurs immediately after listing the</SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006>options considered (and 
listed in my reply to Gideon).</SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006>The base protocol 
specification says "RBridges MUST recognize and&nbsp;<BR>drop BPDUs." This is - 
IMO - significantly different from ignoring them,</SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006>but we could potentailly 
ask for clarification.&nbsp; IMO, recognizing BPDUs</SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006>is sufficient to 
accomplish what has been suggested.</SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006>The P&amp;AS is 
ambivalent on the topic.&nbsp; So where have we said that you</SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006>MUST ignore 
BPDUs.</SPAN></DIV></FONT></SPAN>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2>Even if&nbsp;a "standards track" specification&nbsp;did say 
that you MUST ignore</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2>BPDUs, what do you suppose is going to happen to you if you 
</FONT></SPAN><SPAN class=682250521-03112006><FONT face=Arial color=#0000ff 
size=2>don't </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2>ignore them?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2>I am pretty sure that nobody initially meant for routers to 
"snoop" IGMP</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2>messages, for bridges to "snoop" routing advertisements and 
ARPs, or </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2>for hubs </FONT></SPAN><SPAN class=682250521-03112006><FONT 
face=Arial color=#0000ff size=2>to "snoop" BPDUs, or perform MAC learning.&nbsp; 
yet all of these </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2>things </FONT></SPAN><SPAN class=682250521-03112006><FONT 
face=Arial color=#0000ff size=2>happen - and are even sometimes assumed to 
happen - in real </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2>world </FONT></SPAN><SPAN class=682250521-03112006><FONT 
face=Arial color=#0000ff size=2>implementations.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2>Implementations live in the real world.&nbsp; 
</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2>But I agree that it is probably necessary to say that 
RBridges MUST</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2>employ some means for detecting brdiging topology changes, 
citing</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2>some of the methods we've discussed as examples.&nbsp; That 
might - all</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2>by itself - clarify the meaning of the expression 
"recognize and drop."</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2>--</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=682250521-03112006><FONT face=Arial 
color=#0000ff size=2>Eric</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> Silvano Gai 
  [mailto:[e-mail]] <BR><B>Sent:</B> Friday, November 03, 2006 3:19 
  PM<BR><B>To:</B> Gray, Eric; Gideon Kaempfer; Radia Perlman<BR><B>Cc:</B> 
  [e-mail]<BR><B>Subject:</B> RE: [rbridge] Traffic 
  storms<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=Section1>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Eric,<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">TRILL needs to be a 
  well defined spec that guarantees products that are 
  interoperable.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">If you write in the 
  spec that BPDUs must be ignored, I will drop 
them.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">If I need to do 
  something different with BPDUs, then let&#8217;s spell it out in the 
  spec.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I don&#8217;t like the 
  attitude, &#8220;oh, the spec is broken, but there is some magic that will fix 
  it&#8221;.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Let&#8217;s write in the 
  spec what is this magic.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Also I suggest that 
  people that have solved the problem of having a loop free topology using ISIS, 
  submit proposasl so that we can compare them. Unfortunately I don&#8217;t have 
  one.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">-- 
  Silvano<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0pt; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0pt; BORDER-BOTTOM: medium none">
  <DIV>
  <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT 
  face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">
  <HR tabIndex=-1 align=center width="100%" SIZE=2>
  </SPAN></FONT></DIV>
  <P class=MsoNormal><B><FONT face=Tahoma size=2><SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT 
  face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> 
  [e-mail] [mailto:[e-mail]] <B><SPAN 
  style="FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Gray, Eric<BR><B><SPAN 
  style="FONT-WEIGHT: bold">Sent:</SPAN></B> Friday, November 03, 2006 11:54 
  AM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> Gideon Kaempfer; Radia 
  Perlman<BR><B><SPAN style="FONT-WEIGHT: bold">Cc:</SPAN></B> 
  [e-mail]<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> 
  Re: [rbridge] Traffic storms</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Gideon,</SPAN></FONT><o:p></o:p></P>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt">&nbsp;&nbsp;&nbsp; </SPAN></FONT><FONT face=Arial 
  color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">"Drop BPDUs" is not 
  (exactly) the same as ignore them.&nbsp; We use the term 
  </SPAN></FONT><o:p></o:p></P>
  <P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">as short-hand for the 
  one of three options we considered for handling BPDUs: 
  </SPAN></FONT><o:p></o:p></P>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">&nbsp;&nbsp;&nbsp; 
  Drop (do not participate actively in STP, and do not pass BPDUs through), 
  </SPAN></FONT><o:p></o:p></P>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt">&nbsp;&nbsp;&nbsp; </SPAN></FONT><FONT face=Arial 
  color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Transparent (pass 
  BPDUs through - potentially altering them in some 
  way),</SPAN></FONT><o:p></o:p></P>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt">&nbsp;&nbsp;&nbsp; </SPAN></FONT><FONT face=Arial 
  color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Participate (have 
  each RBridge participate in STP as if it were a 
  bridge).</SPAN></FONT><o:p></o:p></P>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hence, when we say 
  "Drop BPDUs" we are not saying that we cannot look 
  </SPAN></FONT><o:p></o:p></P>
  <P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">at them, we are just 
  saying that we're not doing one of the other two 
  choices.</SPAN></FONT><o:p></o:p></P>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">--</SPAN></FONT><o:p></o:p></P>
  <P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Eric</SPAN></FONT><o:p></o:p></P>
  <BLOCKQUOTE 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0pt; BORDER-TOP: medium none; PADDING-LEFT: 3pt; PADDING-BOTTOM: 0pt; MARGIN: 5pt 0pt 5pt 3pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0pt; BORDER-BOTTOM: medium none">
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT 
    face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">
    <HR tabIndex=-1 align=center width="100%" SIZE=2>
    </SPAN></FONT></DIV>
    <P class=MsoNormal style="MARGIN-BOTTOM: 12pt"><B><FONT face=Tahoma 
    size=2><SPAN 
    style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT 
    face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> 
    [e-mail] [mailto:[e-mail]] <B><SPAN 
    style="FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Gideon 
    Kaempfer<BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Friday, 
    November 03, 2006 1:40 AM<BR><B><SPAN 
    style="FONT-WEIGHT: bold">To:</SPAN></B> Radia Perlman<BR><B><SPAN 
    style="FONT-WEIGHT: bold">Cc:</SPAN></B> [e-mail]<BR><B><SPAN 
    style="FONT-WEIGHT: bold">Subject:</SPAN></B> Re: [rbridge] Traffic 
    storms</SPAN></FONT><o:p></o:p></P>
    <DIV>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt">Radia,<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt">Wouldn't this create a link between TRILL and STP we 
    are trying to avoid?<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt">Relying on the fact that a LAN segment has some kind 
    of unique identifier (such as the root bridge ID) seems like a very 
    practical solution to me, but strongly reliant on the fact that the Rbridges 
    actually process BPDUs. I thought they were just meant to discard them. Is 
    this acceptable? <o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt">Regrads,<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt">&nbsp;Gidi<BR><BR>&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=MsoNormal><SPAN class=gmailquote><FONT face="Times New Roman" 
    size=3><SPAN style="FONT-SIZE: 12pt">On 11/3/06, <B><SPAN 
    style="FONT-WEIGHT: bold">Radia Perlman</SPAN></B> &lt;<A 
    href="mailto:[e-mail]">[e-mail]</A>&gt; 
    wrote:</SPAN></FONT></SPAN> <o:p></o:p></P>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt">The simplest way to put it, I think, is that in 
    certain transitory<BR>situations there might be two<BR>RBridges that both 
    think they are Designated RBridge, and that is bad, <BR>but should 
    stop<BR>as soon as a single Hello is received by the RBridge who should not 
    be<BR>Designated.<BR><BR>I think PIM has similar transitory situations that 
    can occur, and<BR>bridges can also have (hopefully<BR>temporary) problems if 
    a repeater came up and merged two LANs. I think<BR>such things 
    are<BR>annoying but not fatal. But I think it's possible we can with 
    little<BR>effort avoid this problem.<BR><BR>However, with RBridges, because 
    the bridge spanning tree algorithm <BR>elects a Root, there's<BR>really a 
    way of uniquely identifying a LAN (where "LAN" is a bunch of<BR>links 
    connected with<BR>bridges). The unique identifier is the root 
    bridge.<BR><BR>When the B1-B2 link is down, RB1 and RB2 will see the 
    topology as two <BR>separate links, and each<BR>one will have a distinct 
    spanning tree Root bridge (RB1 will see B1, and<BR>RB2 will see B2 as the 
    root).<BR><BR>When the B1-B2 link comes up, the bridges will first merge the 
    two<BR>links, and either RB1 or RB2 will <BR>see that the bridge spanning 
    tree root has changed. This will be<BR>discovered before B1 and B2 
    forward<BR>traffic across the link because of the bridge forwarding 
    delay.<BR>If B1 has better priority as bridge spanning tree root than B2, 
    then RB1 <BR>will not notice anything<BR>different when the B1-B2 link comes 
    up. But RB2 will notice<BR>something different; the spanning tree root has 
    changed identities from<BR>"B2" to "B1".<BR><BR>Given this, RB2 could 
    temporarily stop forwarding to or from the link <BR>when the Root 
    bridge<BR>changes identities, though it should definitely immediately send 
    IS-IS<BR>Hellos (either RB1 or RB2 will<BR>be elected Designated Router in 
    the IS-IS election for that link). If<BR>RB2 has better prioirty for 
    <BR>root, the RB1 will immediately stop forwarding to or from the link 
    when<BR>it sees the Hello from RB2.<BR>If RB2 has better priority in the 
    IS-IS election, then RB1 should<BR>immediately send an IS-IS Hello<BR>when 
    it sees a Hello from a new RBridge on the link. <BR><BR>So I think this is 
    not a big deal, and that if we are worried, we can<BR>specify that an 
    RBridge should<BR>stop acting like the Designated RBridge for a few seconds 
    after the<BR>identity of the Root in the spanning <BR>tree algorithm 
    changes.<BR><BR>Or we could be even fancier and have each RBridge announce 
    in its IS-IS<BR>Hellos which LAN IDs it<BR>is Designated for, where a LAN ID 
    is the MAC address of the Root bridge.<BR>So RB1 continue <BR>forwarding if 
    the identity changes from B1 to B2 provided no other<BR>RBridge has claimed 
    to be connected<BR>to B2. But if RB2's LSP claims it is attached to B2, then 
    RB1 must stop<BR>forwarding for enough time<BR>for the IS-IS election to 
    sort itself out and choose a Designated RBridge. 
    <BR><BR>Radia<BR><BR><BR><BR><BR><BR><BR>Gideon Kaempfer 
    wrote:<BR><BR>&gt;Following mention by Silvano of broadcast and multicast 
    storms (and the need<BR>&gt;to protect against them), I played around with 
    different scenarios and came <BR>&gt;upon one I would appreciate your 
    comments on (in the hope I am pointing out<BR>&gt;a non-existent issue with 
    TRILL). I believe a broadcast and even a unicast<BR>&gt;storm could be 
    created as the result of a loop that isn't protected by TTL <BR>&gt;nor by 
    STP in the case of a link connecting two separate LAN segments 
    coming<BR>&gt;to life.<BR>&gt;<BR>&gt;- RB1 ---- RB2 -<BR>&gt;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<BR>&gt;-&nbsp;&nbsp;B1 
    --x-- B2 -<BR>&gt;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<BR>&gt;&nbsp;&nbsp; 
    H1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; H2<BR>&gt;<BR>&gt;1. The network 
    (segment) involved consists of two Rbridges (RB1, RB2), two<BR>&gt;bridges 
    (B1, B2) and two hosts (H1, H2). They are physically connected 
    as<BR>&gt;depicted.<BR>&gt;2. State A: the direct link between B1 and B2 is 
    down. B1 and B2 find <BR>&gt;themselves on different LAN segments and hence 
    different spanning trees. RB1<BR>&gt;and RB2 are both designated Rbridges 
    (each for the segment of the<BR>&gt;corresponding bridge).<BR>&gt;3. State 
    B: the direct link between B1 and B2 goes up (someone connects a 
    <BR>&gt;cable). B1 and B2 discover each other and establish a common 
    spanning tree.<BR>&gt;RB1 and RB2 both find themselves attached to the same 
    LAN segment and hence<BR>&gt;RB1 (without loss of generality) will 
    eventually become the designated <BR>&gt;Rbridge for it.<BR>&gt;4. Just 
    before RB1 and RB2 identify that they are both on the same 
    segment<BR>&gt;and RB2 stops functioning as a designated Rbridge the 
    following scenario<BR>&gt;seems possible:<BR>&gt;&nbsp;&nbsp;a. H1 sends a 
    broadcast frame. <BR>&gt;&nbsp;&nbsp;b. B1 receives it and forwards to RB1 
    and B2.<BR>&gt;&nbsp;&nbsp;c. RB1 (encapsulates and) forwards to 
    RB2.<BR>&gt;&nbsp;&nbsp;d. B2 forwards to RB2 and H2.<BR>&gt;&nbsp;&nbsp;e. 
    RB2 forwards the copy from RB1 to B2 (and the copy from B2 to RB1). 
    <BR>&gt;&nbsp;&nbsp;f. (RB1 forwards to B1.)<BR>&gt;&nbsp;&nbsp;g. B2 
    forwards (again) to H2 and to B1.<BR>&gt;&nbsp;&nbsp;h. B1 forwards to H1 
    (see remark below regarding filtering table<BR>&gt;contamination) and to 
    RB1.<BR>&gt;&nbsp;&nbsp;i. Etcetera etcetera. <BR>&gt;5. A broadcast storm 
    is born, created by a loop that is not protected by TTL<BR>&gt;(due to the 
    fact that forwarding between the Rbridges is only across a<BR>&gt;single 
    hop) nor by STP (due to the fact that Rbridges do not participate in 
    <BR>&gt;STP).<BR>&gt;6. If forwarding commences at the hardware level and no 
    broadcast rate<BR>&gt;limiting is in place, the storm may cause severe 
    damage in a very short time<BR>&gt;(note that replicated frames are sent to 
    H1 and H2 (or any network they <BR>&gt;could represent).<BR>&gt;7. Another 
    unfortunate effect of this storm is that B1 and B2 no longer 
    know<BR>&gt;where H1 is located (due to the contamination of their filtering 
    tables by a<BR>&gt;frame from H1 that arrives from the wrong direction (and 
    in fact from <BR>&gt;multiple directions). As a result, a possible unicast 
    frame from H2 to H1<BR>&gt;will just join the storm over the loop at least 
    in one direction (RB2 will<BR>&gt;forward it to RB1) but will not arrive at 
    H1...<BR>&gt;<BR>&gt;One possible solution could be for RB2 to identify the 
    fact that it is<BR>&gt;receiving a frame from a host with a MAC address that 
    is associated with a<BR>&gt;segment it thought it isn't connected to. Hence, 
    it may trigger an immediate <BR>&gt;neighbor discovery / designated Rbridge 
    election. However, because Rbridges<BR>&gt;should allow host mobility, this 
    frame may need to be forwarded (and hence<BR>&gt;the storm 
    commences).<BR>&gt;<BR>&gt;As mentioned above, any comments are welcome. 
    <BR>&gt;&nbsp;&nbsp;Gideon 
    Kaempfer<BR>&gt;<BR>&gt;_______________________________________________<BR>&gt;rbridge 
    mailing list<BR>&gt;<A 
    href="mailto:[e-mail]">[e-mail]</A><BR>&gt;<A 
    href="http://mailman.postel.org/mailman/listinfo/rbridge"> 
    http://mailman.postel.org/mailman/listinfo/rbridge</A><BR>&gt;<BR>&gt;<BR><BR>_______________________________________________<BR>rbridge 
    mailing list<BR><A 
    href="mailto:[e-mail]">[e-mail]</A><BR><A 
    href="http://mailman.postel.org/mailman/listinfo/rbridge">http://mailman.postel.org/mailman/listinfo/rbridge</A><o:p></o:p></SPAN></FONT></P></DIV>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></BLOCKQUOTE></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C6FF8E.FA51687C--


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA3KJ8EK015453 for <[e-mail]>; Fri, 3 Nov 2006 12:19:09 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FF85.518FA3D7"
Date: Fri, 3 Nov 2006 12:19:05 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Traffic storms
Thread-Index: Acb/gyG5okIgr9c3RAKluPjkBYG41gAAXBQQ
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, "Gideon Kaempfer" <[e-mail]>,  "Radia Perlman" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 20:19:23 -0000
Status: RO
Content-Length: 28335

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6FF85.518FA3D7
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Eric,

=20

TRILL needs to be a well defined spec that guarantees products that are
interoperable.

If you write in the spec that BPDUs must be ignored, I will drop them.

=20

If I need to do something different with BPDUs, then let's spell it out
in the spec.

=20

I don't like the attitude, "oh, the spec is broken, but there is some
magic that will fix it".

Let's write in the spec what is this magic.

=20

Also I suggest that people that have solved the problem of having a loop
free topology using ISIS, submit proposasl so that we can compare them.
Unfortunately I don't have one.

=20

-- Silvano

=20

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Gray, Eric
Sent: Friday, November 03, 2006 11:54 AM
To: Gideon Kaempfer; Radia Perlman
Cc: [e-mail]
Subject: Re: [rbridge] Traffic storms

=20

Gideon,

=20

    "Drop BPDUs" is not (exactly) the same as ignore them.  We use the
term=20

as short-hand for the one of three options we considered for handling
BPDUs:=20

=20

    Drop (do not participate actively in STP, and do not pass BPDUs
through),=20

    Transparent (pass BPDUs through - potentially altering them in some
way),

    Participate (have each RBridge participate in STP as if it were a
bridge).

=20

Hence, when we say "Drop BPDUs" we are not saying that we cannot look=20

at them, we are just saying that we're not doing one of the other two
choices.

=20

--

Eric

	=20

=09
________________________________


	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Gideon Kaempfer
	Sent: Friday, November 03, 2006 1:40 AM
	To: Radia Perlman
	Cc: [e-mail]
	Subject: Re: [rbridge] Traffic storms

	Radia,

	Wouldn't this create a link between TRILL and STP we are trying
to avoid?

	Relying on the fact that a LAN segment has some kind of unique
identifier (such as the root bridge ID) seems like a very practical
solution to me, but strongly reliant on the fact that the Rbridges
actually process BPDUs. I thought they were just meant to discard them.
Is this acceptable?=20

	Regrads,

	 Gidi
=09
	=20

	On 11/3/06, Radia Perlman <[e-mail]> wrote:=20

	The simplest way to put it, I think, is that in certain
transitory
	situations there might be two
	RBridges that both think they are Designated RBridge, and that
is bad,=20
	but should stop
	as soon as a single Hello is received by the RBridge who should
not be
	Designated.
=09
	I think PIM has similar transitory situations that can occur,
and
	bridges can also have (hopefully
	temporary) problems if a repeater came up and merged two LANs. I
think
	such things are
	annoying but not fatal. But I think it's possible we can with
little
	effort avoid this problem.
=09
	However, with RBridges, because the bridge spanning tree
algorithm=20
	elects a Root, there's
	really a way of uniquely identifying a LAN (where "LAN" is a
bunch of
	links connected with
	bridges). The unique identifier is the root bridge.
=09
	When the B1-B2 link is down, RB1 and RB2 will see the topology
as two=20
	separate links, and each
	one will have a distinct spanning tree Root bridge (RB1 will see
B1, and
	RB2 will see B2 as the root).
=09
	When the B1-B2 link comes up, the bridges will first merge the
two
	links, and either RB1 or RB2 will=20
	see that the bridge spanning tree root has changed. This will be
	discovered before B1 and B2 forward
	traffic across the link because of the bridge forwarding delay.
	If B1 has better priority as bridge spanning tree root than B2,
then RB1=20
	will not notice anything
	different when the B1-B2 link comes up. But RB2 will notice
	something different; the spanning tree root has changed
identities from
	"B2" to "B1".
=09
	Given this, RB2 could temporarily stop forwarding to or from the
link=20
	when the Root bridge
	changes identities, though it should definitely immediately send
IS-IS
	Hellos (either RB1 or RB2 will
	be elected Designated Router in the IS-IS election for that
link). If
	RB2 has better prioirty for=20
	root, the RB1 will immediately stop forwarding to or from the
link when
	it sees the Hello from RB2.
	If RB2 has better priority in the IS-IS election, then RB1
should
	immediately send an IS-IS Hello
	when it sees a Hello from a new RBridge on the link.=20
=09
	So I think this is not a big deal, and that if we are worried,
we can
	specify that an RBridge should
	stop acting like the Designated RBridge for a few seconds after
the
	identity of the Root in the spanning=20
	tree algorithm changes.
=09
	Or we could be even fancier and have each RBridge announce in
its IS-IS
	Hellos which LAN IDs it
	is Designated for, where a LAN ID is the MAC address of the Root
bridge.
	So RB1 continue=20
	forwarding if the identity changes from B1 to B2 provided no
other
	RBridge has claimed to be connected
	to B2. But if RB2's LSP claims it is attached to B2, then RB1
must stop
	forwarding for enough time
	for the IS-IS election to sort itself out and choose a
Designated RBridge.=20
=09
	Radia
=09
=09
=09
=09
=09
=09
	Gideon Kaempfer wrote:
=09
	>Following mention by Silvano of broadcast and multicast storms
(and the need
	>to protect against them), I played around with different
scenarios and came=20
	>upon one I would appreciate your comments on (in the hope I am
pointing out
	>a non-existent issue with TRILL). I believe a broadcast and
even a unicast
	>storm could be created as the result of a loop that isn't
protected by TTL=20
	>nor by STP in the case of a link connecting two separate LAN
segments coming
	>to life.
	>
	>- RB1 ---- RB2 -
	>   |        |
	>-  B1 --x-- B2 -
	>   |        |
	>   H1       H2
	>
	>1. The network (segment) involved consists of two Rbridges
(RB1, RB2), two
	>bridges (B1, B2) and two hosts (H1, H2). They are physically
connected as
	>depicted.
	>2. State A: the direct link between B1 and B2 is down. B1 and
B2 find=20
	>themselves on different LAN segments and hence different
spanning trees. RB1
	>and RB2 are both designated Rbridges (each for the segment of
the
	>corresponding bridge).
	>3. State B: the direct link between B1 and B2 goes up (someone
connects a=20
	>cable). B1 and B2 discover each other and establish a common
spanning tree.
	>RB1 and RB2 both find themselves attached to the same LAN
segment and hence
	>RB1 (without loss of generality) will eventually become the
designated=20
	>Rbridge for it.
	>4. Just before RB1 and RB2 identify that they are both on the
same segment
	>and RB2 stops functioning as a designated Rbridge the following
scenario
	>seems possible:
	>  a. H1 sends a broadcast frame.=20
	>  b. B1 receives it and forwards to RB1 and B2.
	>  c. RB1 (encapsulates and) forwards to RB2.
	>  d. B2 forwards to RB2 and H2.
	>  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2
to RB1).=20
	>  f. (RB1 forwards to B1.)
	>  g. B2 forwards (again) to H2 and to B1.
	>  h. B1 forwards to H1 (see remark below regarding filtering
table
	>contamination) and to RB1.
	>  i. Etcetera etcetera.=20
	>5. A broadcast storm is born, created by a loop that is not
protected by TTL
	>(due to the fact that forwarding between the Rbridges is only
across a
	>single hop) nor by STP (due to the fact that Rbridges do not
participate in=20
	>STP).
	>6. If forwarding commences at the hardware level and no
broadcast rate
	>limiting is in place, the storm may cause severe damage in a
very short time
	>(note that replicated frames are sent to H1 and H2 (or any
network they=20
	>could represent).
	>7. Another unfortunate effect of this storm is that B1 and B2
no longer know
	>where H1 is located (due to the contamination of their
filtering tables by a
	>frame from H1 that arrives from the wrong direction (and in
fact from=20
	>multiple directions). As a result, a possible unicast frame
from H2 to H1
	>will just join the storm over the loop at least in one
direction (RB2 will
	>forward it to RB1) but will not arrive at H1...
	>
	>One possible solution could be for RB2 to identify the fact
that it is
	>receiving a frame from a host with a MAC address that is
associated with a
	>segment it thought it isn't connected to. Hence, it may trigger
an immediate=20
	>neighbor discovery / designated Rbridge election. However,
because Rbridges
	>should allow host mobility, this frame may need to be forwarded
(and hence
	>the storm commences).
	>
	>As mentioned above, any comments are welcome.=20
	>  Gideon Kaempfer
	>
	>_______________________________________________
	>rbridge mailing list
	>[e-mail]
	> http://mailman.postel.org/mailman/listinfo/rbridge
<http://mailman.postel.org/mailman/listinfo/rbridge>=20
	>
	>
=09
	_______________________________________________
	rbridge mailing list
	[e-mail]
	http://mailman.postel.org/mailman/listinfo/rbridge

	=20


------_=_NextPart_001_01C6FF85.518FA3D7
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Eric,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>TRILL needs to be a well defined =
spec that
guarantees products that are interoperable.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>If you write in the spec that BPDUs =
must
be ignored, I will drop them.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>If I need to do something different =
with
BPDUs, then let&#8217;s spell it out in the =
spec.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I don&#8217;t like the attitude, =
&#8220;oh,
the spec is broken, but there is some magic that will fix =
it&#8221;.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Let&#8217;s write in the spec what =
is this
magic.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Also I suggest that people that =
have
solved the problem of having a loop free topology using ISIS, submit =
proposasl
so that we can compare them. Unfortunately I don&#8217;t have =
one.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>-- =
Silvano<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0pt 0pt =
0pt 4.0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Gray, Eric<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, November =
03, 2006
11:54 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Gideon Kaempfer; =
Radia Perlman<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [rbridge] =
Traffic
storms</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Gideon,</span></font><o:p></o:p></p>=


<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;&nbsp;&nbsp; </span></font><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>&quot;Drop =
BPDUs&quot; is
not (exactly) the same as ignore them.&nbsp; We use the term =
</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>as short-hand for the one of three =
options
we considered for handling BPDUs: </span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>&nbsp;&nbsp;&nbsp; Drop (do not
participate actively in STP, and do not pass BPDUs through), =
</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;&nbsp;&nbsp; </span></font><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Transparent =
(pass BPDUs
through - potentially altering them in some =
way),</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;&nbsp;&nbsp; </span></font><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Participate =
(have each
RBridge participate in STP as if it were a =
bridge).</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hence, when we say &quot;Drop =
BPDUs&quot;
we are not saying that we cannot look </span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>at them, we are just saying that =
we're not
doing one of the other two choices.</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>--</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Eric</span></font><o:p></o:p></p>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0pt 0pt 0pt 3.0pt;
margin-left:3.0pt;margin-top:5.0pt;margin-right:0pt;margin-bottom:5.0pt'>=


<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Gideon Kaempfer<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, November =
03, 2006
1:40 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Radia Perlman<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [rbridge] =
Traffic
storms</span></font><o:p></o:p></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Radia,<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Wouldn't this create a link between TRILL and STP we are trying =
to
avoid?<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Relying on the fact that a LAN segment has some kind of unique
identifier (such as the root bridge ID) seems like a very practical =
solution to
me, but strongly reliant on the fact that the Rbridges actually process =
BPDUs.
I thought they were just meant to discard them. Is this acceptable? =
<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Regrads,<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;Gidi<br>
<br>
&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><span class=3Dgmailquote><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>On 11/3/06, <b><span =
style=3D'font-weight:bold'>Radia
Perlman</span></b> &lt;<a =
href=3D"mailto:[e-mail]">[e-mail]</a>&gt;
wrote:</span></font></span> <o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>The simplest way to put it, I think, is that in certain =
transitory<br>
situations there might be two<br>
RBridges that both think they are Designated RBridge, and that is bad, =
<br>
but should stop<br>
as soon as a single Hello is received by the RBridge who should not =
be<br>
Designated.<br>
<br>
I think PIM has similar transitory situations that can occur, and<br>
bridges can also have (hopefully<br>
temporary) problems if a repeater came up and merged two LANs. I =
think<br>
such things are<br>
annoying but not fatal. But I think it's possible we can with little<br>
effort avoid this problem.<br>
<br>
However, with RBridges, because the bridge spanning tree algorithm <br>
elects a Root, there's<br>
really a way of uniquely identifying a LAN (where &quot;LAN&quot; is a =
bunch of<br>
links connected with<br>
bridges). The unique identifier is the root bridge.<br>
<br>
When the B1-B2 link is down, RB1 and RB2 will see the topology as two =
<br>
separate links, and each<br>
one will have a distinct spanning tree Root bridge (RB1 will see B1, =
and<br>
RB2 will see B2 as the root).<br>
<br>
When the B1-B2 link comes up, the bridges will first merge the two<br>
links, and either RB1 or RB2 will <br>
see that the bridge spanning tree root has changed. This will be<br>
discovered before B1 and B2 forward<br>
traffic across the link because of the bridge forwarding delay.<br>
If B1 has better priority as bridge spanning tree root than B2, then RB1 =
<br>
will not notice anything<br>
different when the B1-B2 link comes up. But RB2 will notice<br>
something different; the spanning tree root has changed identities =
from<br>
&quot;B2&quot; to &quot;B1&quot;.<br>
<br>
Given this, RB2 could temporarily stop forwarding to or from the link =
<br>
when the Root bridge<br>
changes identities, though it should definitely immediately send =
IS-IS<br>
Hellos (either RB1 or RB2 will<br>
be elected Designated Router in the IS-IS election for that link). =
If<br>
RB2 has better prioirty for <br>
root, the RB1 will immediately stop forwarding to or from the link =
when<br>
it sees the Hello from RB2.<br>
If RB2 has better priority in the IS-IS election, then RB1 should<br>
immediately send an IS-IS Hello<br>
when it sees a Hello from a new RBridge on the link. <br>
<br>
So I think this is not a big deal, and that if we are worried, we =
can<br>
specify that an RBridge should<br>
stop acting like the Designated RBridge for a few seconds after the<br>
identity of the Root in the spanning <br>
tree algorithm changes.<br>
<br>
Or we could be even fancier and have each RBridge announce in its =
IS-IS<br>
Hellos which LAN IDs it<br>
is Designated for, where a LAN ID is the MAC address of the Root =
bridge.<br>
So RB1 continue <br>
forwarding if the identity changes from B1 to B2 provided no other<br>
RBridge has claimed to be connected<br>
to B2. But if RB2's LSP claims it is attached to B2, then RB1 must =
stop<br>
forwarding for enough time<br>
for the IS-IS election to sort itself out and choose a Designated =
RBridge. <br>
<br>
Radia<br>
<br>
<br>
<br>
<br>
<br>
<br>
Gideon Kaempfer wrote:<br>
<br>
&gt;Following mention by Silvano of broadcast and multicast storms (and =
the
need<br>
&gt;to protect against them), I played around with different scenarios =
and came
<br>
&gt;upon one I would appreciate your comments on (in the hope I am =
pointing out<br>
&gt;a non-existent issue with TRILL). I believe a broadcast and even a =
unicast<br>
&gt;storm could be created as the result of a loop that isn't protected =
by TTL <br>
&gt;nor by STP in the case of a link connecting two separate LAN =
segments
coming<br>
&gt;to life.<br>
&gt;<br>
&gt;- RB1 ---- RB2 -<br>
&gt;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br>
&gt;-&nbsp;&nbsp;B1 --x-- B2 -<br>
&gt;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br>
&gt;&nbsp;&nbsp; H1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; H2<br>
&gt;<br>
&gt;1. The network (segment) involved consists of two Rbridges (RB1, =
RB2), two<br>
&gt;bridges (B1, B2) and two hosts (H1, H2). They are physically =
connected as<br>
&gt;depicted.<br>
&gt;2. State A: the direct link between B1 and B2 is down. B1 and B2 =
find <br>
&gt;themselves on different LAN segments and hence different spanning =
trees.
RB1<br>
&gt;and RB2 are both designated Rbridges (each for the segment of =
the<br>
&gt;corresponding bridge).<br>
&gt;3. State B: the direct link between B1 and B2 goes up (someone =
connects a <br>
&gt;cable). B1 and B2 discover each other and establish a common =
spanning tree.<br>
&gt;RB1 and RB2 both find themselves attached to the same LAN segment =
and hence<br>
&gt;RB1 (without loss of generality) will eventually become the =
designated <br>
&gt;Rbridge for it.<br>
&gt;4. Just before RB1 and RB2 identify that they are both on the same =
segment<br>
&gt;and RB2 stops functioning as a designated Rbridge the following =
scenario<br>
&gt;seems possible:<br>
&gt;&nbsp;&nbsp;a. H1 sends a broadcast frame. <br>
&gt;&nbsp;&nbsp;b. B1 receives it and forwards to RB1 and B2.<br>
&gt;&nbsp;&nbsp;c. RB1 (encapsulates and) forwards to RB2.<br>
&gt;&nbsp;&nbsp;d. B2 forwards to RB2 and H2.<br>
&gt;&nbsp;&nbsp;e. RB2 forwards the copy from RB1 to B2 (and the copy =
from B2
to RB1). <br>
&gt;&nbsp;&nbsp;f. (RB1 forwards to B1.)<br>
&gt;&nbsp;&nbsp;g. B2 forwards (again) to H2 and to B1.<br>
&gt;&nbsp;&nbsp;h. B1 forwards to H1 (see remark below regarding =
filtering
table<br>
&gt;contamination) and to RB1.<br>
&gt;&nbsp;&nbsp;i. Etcetera etcetera. <br>
&gt;5. A broadcast storm is born, created by a loop that is not =
protected by
TTL<br>
&gt;(due to the fact that forwarding between the Rbridges is only across =
a<br>
&gt;single hop) nor by STP (due to the fact that Rbridges do not =
participate in
<br>
&gt;STP).<br>
&gt;6. If forwarding commences at the hardware level and no broadcast =
rate<br>
&gt;limiting is in place, the storm may cause severe damage in a very =
short
time<br>
&gt;(note that replicated frames are sent to H1 and H2 (or any network =
they <br>
&gt;could represent).<br>
&gt;7. Another unfortunate effect of this storm is that B1 and B2 no =
longer
know<br>
&gt;where H1 is located (due to the contamination of their filtering =
tables by
a<br>
&gt;frame from H1 that arrives from the wrong direction (and in fact =
from <br>
&gt;multiple directions). As a result, a possible unicast frame from H2 =
to H1<br>
&gt;will just join the storm over the loop at least in one direction =
(RB2 will<br>
&gt;forward it to RB1) but will not arrive at H1...<br>
&gt;<br>
&gt;One possible solution could be for RB2 to identify the fact that it =
is<br>
&gt;receiving a frame from a host with a MAC address that is associated =
with a<br>
&gt;segment it thought it isn't connected to. Hence, it may trigger an
immediate <br>
&gt;neighbor discovery / designated Rbridge election. However, because =
Rbridges<br>
&gt;should allow host mobility, this frame may need to be forwarded (and =
hence<br>
&gt;the storm commences).<br>
&gt;<br>
&gt;As mentioned above, any comments are welcome. <br>
&gt;&nbsp;&nbsp;Gideon Kaempfer<br>
&gt;<br>
&gt;_______________________________________________<br>
&gt;rbridge mailing list<br>
&gt;<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
&gt;<a href=3D"http://mailman.postel.org/mailman/listinfo/rbridge">
http://mailman.postel.org/mailman/listinfo/rbridge</a><br>
&gt;<br>
&gt;<br>
<br>
_______________________________________________<br>
rbridge mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a =
href=3D"http://mailman.postel.org/mailman/listinfo/rbridge">http://mailma=
n.postel.org/mailman/listinfo/rbridge</a><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</blockquote>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C6FF85.518FA3D7--


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA3KC1p1013074 for <[e-mail]>; Fri, 3 Nov 2006 12:12:01 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA3KBufK002933; Fri, 3 Nov 2006 15:11:57 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA10378;  Fri, 3 Nov 2006 15:11:56 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB648TNZ>; Fri, 3 Nov 2006 15:11:55 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "Joel M. Halpern" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
Date: Fri, 3 Nov 2006 15:11:47 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA3KC1p1013074
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 20:12:16 -0000
Status: RO
Content-Length: 12633

Joel,

	These are techniques for preventing the formation of temporary
loops during a routing change.  Ordered FIB updates does not seen to
address the potential for dealing with a loop introduced through an
agency outside of routing.  For one thing, such loops exist before a
router can detect them, hence there is nothing a router can do to 
prevent them.

	Order FIB updates is a reasonable technique for avoiding loops
in reconstructing route entries after a purge, however, and this is 
something we should consider.  However, in the RBridge case, I think
FIB entries will be naturally ordered (once we are sure of a stable
bridge topology in attached LAN segments) by the process in which 
MAC address learning information is distributed - via IS-IS - from 
egress toward ingresses.

	Is that not true, or are there specific cases in which it might
not be true?

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Joel M. Halpern
--> Sent: Friday, November 03, 2006 11:21 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Traffic storms
--> 
--> If we need to make the link state algorithm 
--> converge without introducing loops, the 
--> techniques for loop avoidance being discussed in 
--> the routing area may be of relevance.
--> In particular, ordered fib convergence seems quite suitable.
--> Yours,
--> Joel M. Halpern
--> 
--> At 10:31 AM 11/3/2006, Silvano Gai wrote:
--> 
--> >The examples from Gideon and Guillermo deal with 
--> >the interaction between STP/RSTP and TRILL and point one 
--> weakness of TRILL.
--> >
--> >There will be another cause for Broadcast storm 
--> >that does not involve STP/RSTP interaction, i.e. 
--> >a simple topology change in the TRILL network.
--> >
--> >Djikstar will run in an asynchronous way on the 
--> >different RBridges and the trees used to 
--> >distribute broadcast/multicast/unknown will 
--> >potentially have loops during the transition.
--> >
--> >TTL will be of limited help since the traffic 
--> >will replicate. For example, if the loop is 
--> >between two RBridges with 256 ports each, 
--> >assuming a TTL of 64, each broadcast present on 
--> >the link at the time the loop will cause a storm 
--> >of 16,000 frames. If the loops involve more 
--> >switches and links millions of copy will be 
--> >create. For Enterprise/Datacenter RBridges the 
--> >forwarding delay is less than 5 microseconds, 
--> >therefore the storm will reach its peak in 300 
--> >microseconds, well before any software intervention can 
--> break the loop.
--> >
--> >-- Silvano
--> >
--> > > -----Original Message-----
--> > > From: [e-mail] 
--> [mailto:[e-mail]] On
--> > > Behalf Of Guillermo Ib??ez
--> > > Sent: Friday, November 03, 2006 12:36 AM
--> > > To: Developing a hybrid router/bridge.
--> > > Subject: Re: [rbridge] Traffic storms
--> > >
--> > > This comment is just to signal that the behaviour must 
--> be analyzed also
--> > > assuming that B1 and B2 execute the (current standard) 
--> RSTP protocol.
--> > > There is no forwarding delay in RSTP when the links are 
--> dedicated (point
--> > > to point).
--> > > If B1 and B2 execute RSTP protocol and B1 has best 
--> priority, before
--> > > link B1-B2 being enabled, B2 will block its designated 
--> ports  and stop
--> > > forwarding  to RB2.  The process will repeat later  for 
--> next stage
--> > > downstream links like B2-RB2 and so on, one level at a time.
--> > > The trend is to uses RSTP instead of STP. Root bridge 
--> election is likely
--> > > much faster  than DR election. Setting timers at 
--> RBridges to stop
--> > > forwarding may be a solution but it slows reconfiguration speed.
--> > > Guillermo
--> > >
--> > > Radia Perlman escribi?:
--> > > > The simplest way to put it, I think, is that in 
--> certain transitory
--> > > > situations there might be two
--> > > > RBridges that both think they are Designated RBridge, 
--> and that is bad,
--> > > > but should stop
--> > > > as soon as a single Hello is received by the RBridge 
--> who should not be
--> > > > Designated.
--> > > > I think PIM has similar transitory situations that 
--> can occur, and
--> > > >
--> > > > bridges can also have (hopefully
--> > > > temporary) problems if a repeater came up and merged 
--> two LANs. I think
--> > > > such things are
--> > > > annoying but not fatal. But I think it's possible we 
--> can with little
--> > > > effort avoid this problem.
--> > > >
--> > > > However, with RBridges, because the bridge spanning 
--> tree algorithm
--> > > > elects a Root, there's
--> > > > really a way of uniquely identifying a LAN (where 
--> "LAN" is a bunch of
--> > > > links connected with
--> > > > bridges). The unique identifier is the root bridge.
--> > > >
--> > >
--> > > > When the B1-B2 link is down, RB1 and RB2 will see the 
--> topology as two
--> > > > separate links, and each
--> > > > one will have a distinct spanning tree Root bridge 
--> (RB1 will see B1, and
--> > > > RB2 will see B2 as the root).
--> > > >
--> > > > When the B1-B2 link comes up, the bridges will first 
--> merge the two
--> > > > links,
--> > > > and either RB1 or RB2 will
--> > > > see that the bridge spanning tree root has changed. 
--> This will be
--> > > > discovered before B1 and B2 forward
--> > > > traffic across the link because of the bridge 
--> forwarding delay.If B1 has
--> > > better priority as bridge spanning tree root than B2, 
--> then RB1 will not
--> > > notice anything
--> > > > different when the B1-B2 link comes up. But RB2 will notice
--> > > > something different; the spanning tree root has 
--> changed identities from
--> > > > "B2" to "B1".
--> > > > Given this, RB2 could temporarily stop forwarding to 
--> or from the link
--> > > > when the Root bridge
--> > > > changes identities, though it should definitely 
--> immediately send IS-IS
--> > > > Hellos (either RB1 or RB2 will
--> > > > be elected Designated Router in the IS-IS election 
--> for that link). If
--> > > > RB2 has better prioirty for
--> > > > root, the RB1 will immediately stop forwarding to or 
--> from the link when
--> > > > it sees the Hello from RB2.
--> > > > If RB2 has better priority in the IS-IS election, 
--> then RB1 should
--> > > > immediately send an IS-IS Hello
--> > > > when it sees a Hello from a new RBridge on the link.
--> > > >
--> > > > So I think this is not a big deal, and that if we are 
--> worried, we can
--> > > > specify that an RBridge should
--> > > > stop acting like the Designated RBridge for a few 
--> seconds after the
--> > > > identity of the Root in the spanning
--> > > > tree algorithm changes.
--> > > >
--> > > > Or we could be even fancier and have each RBridge 
--> announce in its IS-IS
--> > > > Hellos which LAN IDs it
--> > > > is Designated for, where a LAN ID is the MAC address 
--> of the Root bridge.
--> > > > So RB1 continue
--> > > > forwarding if the identity changes from B1 to B2 
--> provided no other
--> > > > RBridge has claimed to be connected
--> > > > to B2. But if RB2's LSP claims it is attached to B2, 
--> then RB1 must stop
--> > > > forwarding for enough time
--> > > > for the IS-IS election to sort itself out and choose 
--> a Designated
--> > > RBridge.
--> > > >
--> > > > Radia
--> > > >
--> > > >
--> > > >
--> > > >
--> > > >
--> > > >
--> > > > Gideon Kaempfer wrote:
--> > > >
--> > > >
--> > > >> Following mention by Silvano of broadcast and 
--> multicast storms (and the
--> > > need
--> > > >> to protect against them), I played around with 
--> different scenarios and
--> > > came
--> > > >> upon one I would appreciate your comments on (in the 
--> hope I am pointing
--> > > out
--> > > >> a non-existent issue with TRILL). I believe a 
--> broadcast and even a
--> > > unicast
--> > > >> storm could be created as the result of a loop that 
--> isn't protected by
--> > > TTL
--> > > >> nor by STP in the case of a link connecting two 
--> separate LAN segments
--> > > coming
--> > > >> to life.
--> > > >>
--> > > >> - RB1 ---- RB2 -
--> > > >>   |        |
--> > > >> -  B1 --x-- B2 -
--> > > >>   |        |
--> > > >>   H1       H2
--> > > >>
--> > > >> 1. The network (segment) involved consists of two 
--> Rbridges (RB1, RB2),
--> > > two
--> > > >> bridges (B1, B2) and two hosts (H1, H2). They are 
--> physically connected
--> > > as
--> > > >> depicted.
--> > > >> 2. State A: the direct link between B1 and B2 is 
--> down. B1 and B2 find
--> > > >> themselves on different LAN segments and hence 
--> different spanning
--> > > trees. RB1
--> > > >> and RB2 are both designated Rbridges (each for the 
--> segment of the
--> > > >> corresponding bridge).
--> > > >> 3. State B: the direct link between B1 and B2 goes 
--> up (someone connects
--> > > a
--> > > >> cable). B1 and B2 discover each other and establish 
--> a common spanning
--> > > tree.
--> > > >> RB1 and RB2 both find themselves attached to the 
--> same LAN segment and
--> > > hence
--> > > >> RB1 (without loss of generality) will eventually 
--> become the designated
--> > > >> Rbridge for it.
--> > > >> 4. Just before RB1 and RB2 identify that they are 
--> both on the same
--> > > segment
--> > > >> and RB2 stops functioning as a designated Rbridge 
--> the following
--> > > scenario
--> > > >> seems possible:
--> > > >>  a. H1 sends a broadcast frame.
--> > > >>  b. B1 receives it and forwards to RB1 and B2.
--> > > >>  c. RB1 (encapsulates and) forwards to RB2.
--> > > >>  d. B2 forwards to RB2 and H2.
--> > > >>  e. RB2 forwards the copy from RB1 to B2 (and the 
--> copy from B2 to RB1).
--> > > >>  f. (RB1 forwards to B1.)
--> > > >>  g. B2 forwards (again) to H2 and to B1.
--> > > >>  h. B1 forwards to H1 (see remark below regarding 
--> filtering table
--> > > >> contamination) and to RB1.
--> > > >>  i. Etcetera etcetera.
--> > > >> 5. A broadcast storm is born, created by a loop that 
--> is not protected
--> > > by TTL
--> > > >> (due to the fact that forwarding between the 
--> Rbridges is only across a
--> > > >> single hop) nor by STP (due to the fact that Rbridges do not
--> > > participate in
--> > > >> STP).
--> > > >> 6. If forwarding commences at the hardware level and 
--> no broadcast rate
--> > > >> limiting is in place, the storm may cause severe 
--> damage in a very short
--> > > time
--> > > >> (note that replicated frames are sent to H1 and H2 
--> (or any network they
--> > > >> could represent).
--> > > >> 7. Another unfortunate effect of this storm is that 
--> B1 and B2 no longer
--> > > know
--> > > >> where H1 is located (due to the contamination of 
--> their filtering tables
--> > > by a
--> > > >> frame from H1 that arrives from the wrong direction 
--> (and in fact from
--> > > >> multiple directions). As a result, a possible 
--> unicast frame from H2 to
--> > > H1
--> > > >> will just join the storm over the loop at least in 
--> one direction (RB2
--> > > will
--> > > >> forward it to RB1) but will not arrive at H1...
--> > > >>
--> > > >> One possible solution could be for RB2 to identify 
--> the fact that it is
--> > > >> receiving a frame from a host with a MAC address 
--> that is associated
--> > > with a
--> > > >> segment it thought it isn't connected to. Hence, it 
--> may trigger an
--> > > immediate
--> > > >> neighbor discovery / designated Rbridge election. 
--> However, because
--> > > Rbridges
--> > > >> should allow host mobility, this frame may need to 
--> be forwarded (and
--> > > hence
--> > > >> the storm commences).
--> > > >>
--> > > >> As mentioned above, any comments are welcome.
--> > > >>  Gideon Kaempfer
--> > > >>
--> > > >> _______________________________________________
--> > > >> rbridge mailing list
--> > > >> [e-mail]
--> > > >> http://mailman.postel.org/mailman/listinfo/rbridge
--> > > >>
--> > > >>
--> > > >>
--> > > >
--> > > > _______________________________________________
--> > > > rbridge mailing list
--> > > > [e-mail]
--> > > > http://mailman.postel.org/mailman/listinfo/rbridge
--> > > >
--> > > _______________________________________________
--> > > rbridge mailing list
--> > > [e-mail]
--> > > http://mailman.postel.org/mailman/listinfo/rbridge
--> >
--> >_______________________________________________
--> >rbridge mailing list
--> >[e-mail]
--> >http://mailman.postel.org/mailman/listinfo/rbridge
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA3K5SSX010453 for <[e-mail]>; Fri, 3 Nov 2006 12:05:28 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA3K5PfK002818; Fri, 3 Nov 2006 15:05:25 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA09935;  Fri, 3 Nov 2006 15:05:25 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB648TKJ>; Fri, 3 Nov 2006 15:05:24 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>
Date: Fri, 3 Nov 2006 15:05:17 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA3K5SSX010453
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 20:05:47 -0000
Status: RO
Content-Length: 11427

Silvano,

	The simplest way to deal with these storms is to pay attention
to topology change indications and - when they are found - purge all
affected IRT entries.  This effectively creates necessary forwarding
delays to avoid the "storm" phenomenom we appear to be concerned about. 

	It is important to realize that there are clever ways in which
it is possible to reduce the set of "affected IRT entries" - thus it
is possible to reduce the trauma that might be introduced by the need
to re-aquire IRT entries.

	This approach deals with all of the potential scenarios we've
discussed (or heard about) so far.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Silvano Gai
--> Sent: Friday, November 03, 2006 10:32 AM
--> To: Guillermo Ib??ez; Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Traffic storms
--> 
--> 
--> The examples from Gideon and Guillermo deal with the 
--> interaction between STP/RSTP and TRILL and point one 
--> weakness of TRILL.
--> 
--> There will be another cause for Broadcast storm that does 
--> not involve STP/RSTP interaction, i.e. a simple topology 
--> change in the TRILL network.
--> 
--> Djikstar will run in an asynchronous way on the different 
--> RBridges and the trees used to distribute 
--> broadcast/multicast/unknown will potentially have loops 
--> during the transition.
--> 
--> TTL will be of limited help since the traffic will 
--> replicate. For example, if the loop is between two RBridges 
--> with 256 ports each, assuming a TTL of 64, each broadcast 
--> present on the link at the time the loop will cause a storm 
--> of 16,000 frames. If the loops involve more switches and 
--> links millions of copy will be create. For 
--> Enterprise/Datacenter RBridges the forwarding delay is less 
--> than 5 microseconds, therefore the storm will reach its 
--> peak in 300 microseconds, well before any software 
--> intervention can break the loop.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: [e-mail] 
--> [mailto:[e-mail]] On
--> > Behalf Of Guillermo Ib??ez
--> > Sent: Friday, November 03, 2006 12:36 AM
--> > To: Developing a hybrid router/bridge.
--> > Subject: Re: [rbridge] Traffic storms
--> > 
--> > This comment is just to signal that the behaviour must be 
--> analyzed also
--> > assuming that B1 and B2 execute the (current standard) 
--> RSTP protocol.
--> > There is no forwarding delay in RSTP when the links are 
--> dedicated (point
--> > to point).
--> > If B1 and B2 execute RSTP protocol and B1 has best 
--> priority, before
--> > link B1-B2 being enabled, B2 will block its designated 
--> ports  and stop
--> > forwarding  to RB2.  The process will repeat later  for next stage
--> > downstream links like B2-RB2 and so on, one level at a time.
--> > The trend is to uses RSTP instead of STP. Root bridge 
--> election is likely
--> > much faster  than DR election. Setting timers at RBridges to stop
--> > forwarding may be a solution but it slows reconfiguration speed.
--> > Guillermo
--> > 
--> > Radia Perlman escribi?:
--> > > The simplest way to put it, I think, is that in certain 
--> transitory
--> > > situations there might be two
--> > > RBridges that both think they are Designated RBridge, 
--> and that is bad,
--> > > but should stop
--> > > as soon as a single Hello is received by the RBridge 
--> who should not be
--> > > Designated.
--> > > I think PIM has similar transitory situations that can 
--> occur, and
--> > >
--> > > bridges can also have (hopefully
--> > > temporary) problems if a repeater came up and merged 
--> two LANs. I think
--> > > such things are
--> > > annoying but not fatal. But I think it's possible we 
--> can with little
--> > > effort avoid this problem.
--> > >
--> > > However, with RBridges, because the bridge spanning 
--> tree algorithm
--> > > elects a Root, there's
--> > > really a way of uniquely identifying a LAN (where "LAN" 
--> is a bunch of
--> > > links connected with
--> > > bridges). The unique identifier is the root bridge.
--> > >
--> > 
--> > > When the B1-B2 link is down, RB1 and RB2 will see the 
--> topology as two
--> > > separate links, and each
--> > > one will have a distinct spanning tree Root bridge (RB1 
--> will see B1, and
--> > > RB2 will see B2 as the root).
--> > >
--> > > When the B1-B2 link comes up, the bridges will first 
--> merge the two
--> > > links,
--> > > and either RB1 or RB2 will
--> > > see that the bridge spanning tree root has changed. This will be
--> > > discovered before B1 and B2 forward
--> > > traffic across the link because of the bridge 
--> forwarding delay.If B1 has
--> > better priority as bridge spanning tree root than B2, 
--> then RB1 will not
--> > notice anything
--> > > different when the B1-B2 link comes up. But RB2 will notice
--> > > something different; the spanning tree root has changed 
--> identities from
--> > > "B2" to "B1".
--> > > Given this, RB2 could temporarily stop forwarding to or 
--> from the link
--> > > when the Root bridge
--> > > changes identities, though it should definitely 
--> immediately send IS-IS
--> > > Hellos (either RB1 or RB2 will
--> > > be elected Designated Router in the IS-IS election for 
--> that link). If
--> > > RB2 has better prioirty for
--> > > root, the RB1 will immediately stop forwarding to or 
--> from the link when
--> > > it sees the Hello from RB2.
--> > > If RB2 has better priority in the IS-IS election, then 
--> RB1 should
--> > > immediately send an IS-IS Hello
--> > > when it sees a Hello from a new RBridge on the link.
--> > >
--> > > So I think this is not a big deal, and that if we are 
--> worried, we can
--> > > specify that an RBridge should
--> > > stop acting like the Designated RBridge for a few 
--> seconds after the
--> > > identity of the Root in the spanning
--> > > tree algorithm changes.
--> > >
--> > > Or we could be even fancier and have each RBridge 
--> announce in its IS-IS
--> > > Hellos which LAN IDs it
--> > > is Designated for, where a LAN ID is the MAC address of 
--> the Root bridge.
--> > > So RB1 continue
--> > > forwarding if the identity changes from B1 to B2 
--> provided no other
--> > > RBridge has claimed to be connected
--> > > to B2. But if RB2's LSP claims it is attached to B2, 
--> then RB1 must stop
--> > > forwarding for enough time
--> > > for the IS-IS election to sort itself out and choose a 
--> Designated
--> > RBridge.
--> > >
--> > > Radia
--> > >
--> > >
--> > >
--> > >
--> > >
--> > >
--> > > Gideon Kaempfer wrote:
--> > >
--> > >
--> > >> Following mention by Silvano of broadcast and 
--> multicast storms (and the
--> > need
--> > >> to protect against them), I played around with 
--> different scenarios and
--> > came
--> > >> upon one I would appreciate your comments on (in the 
--> hope I am pointing
--> > out
--> > >> a non-existent issue with TRILL). I believe a 
--> broadcast and even a
--> > unicast
--> > >> storm could be created as the result of a loop that 
--> isn't protected by
--> > TTL
--> > >> nor by STP in the case of a link connecting two 
--> separate LAN segments
--> > coming
--> > >> to life.
--> > >>
--> > >> - RB1 ---- RB2 -
--> > >>   |        |
--> > >> -  B1 --x-- B2 -
--> > >>   |        |
--> > >>   H1       H2
--> > >>
--> > >> 1. The network (segment) involved consists of two 
--> Rbridges (RB1, RB2),
--> > two
--> > >> bridges (B1, B2) and two hosts (H1, H2). They are 
--> physically connected
--> > as
--> > >> depicted.
--> > >> 2. State A: the direct link between B1 and B2 is down. 
--> B1 and B2 find
--> > >> themselves on different LAN segments and hence 
--> different spanning
--> > trees. RB1
--> > >> and RB2 are both designated Rbridges (each for the 
--> segment of the
--> > >> corresponding bridge).
--> > >> 3. State B: the direct link between B1 and B2 goes up 
--> (someone connects
--> > a
--> > >> cable). B1 and B2 discover each other and establish a 
--> common spanning
--> > tree.
--> > >> RB1 and RB2 both find themselves attached to the same 
--> LAN segment and
--> > hence
--> > >> RB1 (without loss of generality) will eventually 
--> become the designated
--> > >> Rbridge for it.
--> > >> 4. Just before RB1 and RB2 identify that they are both 
--> on the same
--> > segment
--> > >> and RB2 stops functioning as a designated Rbridge the following
--> > scenario
--> > >> seems possible:
--> > >>  a. H1 sends a broadcast frame.
--> > >>  b. B1 receives it and forwards to RB1 and B2.
--> > >>  c. RB1 (encapsulates and) forwards to RB2.
--> > >>  d. B2 forwards to RB2 and H2.
--> > >>  e. RB2 forwards the copy from RB1 to B2 (and the copy 
--> from B2 to RB1).
--> > >>  f. (RB1 forwards to B1.)
--> > >>  g. B2 forwards (again) to H2 and to B1.
--> > >>  h. B1 forwards to H1 (see remark below regarding 
--> filtering table
--> > >> contamination) and to RB1.
--> > >>  i. Etcetera etcetera.
--> > >> 5. A broadcast storm is born, created by a loop that 
--> is not protected
--> > by TTL
--> > >> (due to the fact that forwarding between the Rbridges 
--> is only across a
--> > >> single hop) nor by STP (due to the fact that Rbridges do not
--> > participate in
--> > >> STP).
--> > >> 6. If forwarding commences at the hardware level and 
--> no broadcast rate
--> > >> limiting is in place, the storm may cause severe 
--> damage in a very short
--> > time
--> > >> (note that replicated frames are sent to H1 and H2 (or 
--> any network they
--> > >> could represent).
--> > >> 7. Another unfortunate effect of this storm is that B1 
--> and B2 no longer
--> > know
--> > >> where H1 is located (due to the contamination of their 
--> filtering tables
--> > by a
--> > >> frame from H1 that arrives from the wrong direction 
--> (and in fact from
--> > >> multiple directions). As a result, a possible unicast 
--> frame from H2 to
--> > H1
--> > >> will just join the storm over the loop at least in one 
--> direction (RB2
--> > will
--> > >> forward it to RB1) but will not arrive at H1...
--> > >>
--> > >> One possible solution could be for RB2 to identify the 
--> fact that it is
--> > >> receiving a frame from a host with a MAC address that 
--> is associated
--> > with a
--> > >> segment it thought it isn't connected to. Hence, it 
--> may trigger an
--> > immediate
--> > >> neighbor discovery / designated Rbridge election. 
--> However, because
--> > Rbridges
--> > >> should allow host mobility, this frame may need to be 
--> forwarded (and
--> > hence
--> > >> the storm commences).
--> > >>
--> > >> As mentioned above, any comments are welcome.
--> > >>  Gideon Kaempfer
--> > >>
--> > >> _______________________________________________
--> > >> rbridge mailing list
--> > >> [e-mail]
--> > >> http://mailman.postel.org/mailman/listinfo/rbridge
--> > >>
--> > >>
--> > >>
--> > >
--> > > _______________________________________________
--> > > rbridge mailing list
--> > > [e-mail]
--> > > http://mailman.postel.org/mailman/listinfo/rbridge
--> > >
--> > _______________________________________________
--> > rbridge mailing list
--> > [e-mail]
--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA3Jw7XS007668 for <[e-mail]>; Fri, 3 Nov 2006 11:58:07 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA3Jw4fK002701; Fri, 3 Nov 2006 14:58:05 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09421;  Fri, 3 Nov 2006 14:58:04 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB648TGN>; Fri, 3 Nov 2006 14:58:03 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
Date: Fri, 3 Nov 2006 14:57:58 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA3Jw7XS007668
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 19:58:20 -0000
Status: RO
Content-Length: 9188

Guillermo,

	There may be no forwarding delay under certain cicumstances
using RSTP, but there are other ways in which this storm concern
may be eliminated.

	Under any form of STP that I am aware of, bridges either stop,
or carefully restrict forwarding while they resolve the new spanning
tree.  Because they can do this, so can we.

	(This is a "high-level" analysis, but I think you will agree
that it is correct.)

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
--> Sent: Friday, November 03, 2006 3:36 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Traffic storms
--> 
--> This comment is just to signal that the behaviour must be 
--> analyzed also 
--> assuming that B1 and B2 execute the (current standard) RSTP 
--> protocol.  
--> There is no forwarding delay in RSTP when the links are 
--> dedicated (point 
--> to point).
--> If B1 and B2 execute RSTP protocol and B1 has best 
--> priority, before  
--> link B1-B2 being enabled, B2 will block its designated 
--> ports  and stop 
--> forwarding  to RB2.  The process will repeat later  for next stage 
--> downstream links like B2-RB2 and so on, one level at a time.
--> The trend is to uses RSTP instead of STP. Root bridge 
--> election is likely 
--> much faster  than DR election. Setting timers at RBridges to stop 
--> forwarding may be a solution but it slows reconfiguration speed.
--> Guillermo
--> 
--> Radia Perlman escribi?:
--> > The simplest way to put it, I think, is that in certain 
--> transitory 
--> > situations there might be two
--> > RBridges that both think they are Designated RBridge, and 
--> that is bad, 
--> > but should stop
--> > as soon as a single Hello is received by the RBridge who 
--> should not be 
--> > Designated.
--> > I think PIM has similar transitory situations that can occur, and 
--> >   
--> > bridges can also have (hopefully
--> > temporary) problems if a repeater came up and merged two 
--> LANs. I think 
--> > such things are
--> > annoying but not fatal. But I think it's possible we can 
--> with little 
--> > effort avoid this problem.
--> >
--> > However, with RBridges, because the bridge spanning tree 
--> algorithm 
--> > elects a Root, there's
--> > really a way of uniquely identifying a LAN (where "LAN" 
--> is a bunch of 
--> > links connected with
--> > bridges). The unique identifier is the root bridge.
--> >   
--> 
--> > When the B1-B2 link is down, RB1 and RB2 will see the 
--> topology as two 
--> > separate links, and each
--> > one will have a distinct spanning tree Root bridge (RB1 
--> will see B1, and 
--> > RB2 will see B2 as the root).
--> >
--> > When the B1-B2 link comes up, the bridges will first 
--> merge the two 
--> > links, 
--> > and either RB1 or RB2 will
--> > see that the bridge spanning tree root has changed. This will be 
--> > discovered before B1 and B2 forward
--> > traffic across the link because of the bridge forwarding 
--> delay.If B1 has better priority as bridge spanning tree 
--> root than B2, then RB1 will not notice anything
--> > different when the B1-B2 link comes up. But RB2 will notice
--> > something different; the spanning tree root has changed 
--> identities from 
--> > "B2" to "B1".
--> > Given this, RB2 could temporarily stop forwarding to or 
--> from the link 
--> > when the Root bridge
--> > changes identities, though it should definitely 
--> immediately send IS-IS 
--> > Hellos (either RB1 or RB2 will
--> > be elected Designated Router in the IS-IS election for 
--> that link). If 
--> > RB2 has better prioirty for
--> > root, the RB1 will immediately stop forwarding to or from 
--> the link when 
--> > it sees the Hello from RB2.
--> > If RB2 has better priority in the IS-IS election, then RB1 should 
--> > immediately send an IS-IS Hello
--> > when it sees a Hello from a new RBridge on the link.
--> >
--> > So I think this is not a big deal, and that if we are 
--> worried, we can 
--> > specify that an RBridge should
--> > stop acting like the Designated RBridge for a few seconds 
--> after the 
--> > identity of the Root in the spanning
--> > tree algorithm changes.
--> >
--> > Or we could be even fancier and have each RBridge 
--> announce in its IS-IS 
--> > Hellos which LAN IDs it
--> > is Designated for, where a LAN ID is the MAC address of 
--> the Root bridge. 
--> > So RB1 continue
--> > forwarding if the identity changes from B1 to B2 provided 
--> no other 
--> > RBridge has claimed to be connected
--> > to B2. But if RB2's LSP claims it is attached to B2, then 
--> RB1 must stop 
--> > forwarding for enough time
--> > for the IS-IS election to sort itself out and choose a 
--> Designated RBridge.
--> >
--> > Radia
--> >
--> >
--> >
--> >
--> >
--> >
--> > Gideon Kaempfer wrote:
--> >
--> >   
--> >> Following mention by Silvano of broadcast and multicast 
--> storms (and the need
--> >> to protect against them), I played around with different 
--> scenarios and came
--> >> upon one I would appreciate your comments on (in the 
--> hope I am pointing out
--> >> a non-existent issue with TRILL). I believe a broadcast 
--> and even a unicast
--> >> storm could be created as the result of a loop that 
--> isn't protected by TTL
--> >> nor by STP in the case of a link connecting two separate 
--> LAN segments coming
--> >> to life.
--> >>
--> >> - RB1 ---- RB2 -
--> >>   |        |
--> >> -  B1 --x-- B2 -
--> >>   |        |
--> >>   H1       H2
--> >>
--> >> 1. The network (segment) involved consists of two 
--> Rbridges (RB1, RB2), two
--> >> bridges (B1, B2) and two hosts (H1, H2). They are 
--> physically connected as
--> >> depicted.
--> >> 2. State A: the direct link between B1 and B2 is down. 
--> B1 and B2 find
--> >> themselves on different LAN segments and hence different 
--> spanning trees. RB1
--> >> and RB2 are both designated Rbridges (each for the segment of the
--> >> corresponding bridge).
--> >> 3. State B: the direct link between B1 and B2 goes up 
--> (someone connects a
--> >> cable). B1 and B2 discover each other and establish a 
--> common spanning tree.
--> >> RB1 and RB2 both find themselves attached to the same 
--> LAN segment and hence
--> >> RB1 (without loss of generality) will eventually become 
--> the designated
--> >> Rbridge for it.
--> >> 4. Just before RB1 and RB2 identify that they are both 
--> on the same segment
--> >> and RB2 stops functioning as a designated Rbridge the 
--> following scenario
--> >> seems possible:
--> >>  a. H1 sends a broadcast frame.
--> >>  b. B1 receives it and forwards to RB1 and B2.
--> >>  c. RB1 (encapsulates and) forwards to RB2.
--> >>  d. B2 forwards to RB2 and H2.
--> >>  e. RB2 forwards the copy from RB1 to B2 (and the copy 
--> from B2 to RB1).
--> >>  f. (RB1 forwards to B1.)
--> >>  g. B2 forwards (again) to H2 and to B1.
--> >>  h. B1 forwards to H1 (see remark below regarding filtering table
--> >> contamination) and to RB1.
--> >>  i. Etcetera etcetera.
--> >> 5. A broadcast storm is born, created by a loop that is 
--> not protected by TTL
--> >> (due to the fact that forwarding between the Rbridges is 
--> only across a
--> >> single hop) nor by STP (due to the fact that Rbridges do 
--> not participate in
--> >> STP).
--> >> 6. If forwarding commences at the hardware level and no 
--> broadcast rate
--> >> limiting is in place, the storm may cause severe damage 
--> in a very short time
--> >> (note that replicated frames are sent to H1 and H2 (or 
--> any network they
--> >> could represent).
--> >> 7. Another unfortunate effect of this storm is that B1 
--> and B2 no longer know
--> >> where H1 is located (due to the contamination of their 
--> filtering tables by a
--> >> frame from H1 that arrives from the wrong direction (and 
--> in fact from
--> >> multiple directions). As a result, a possible unicast 
--> frame from H2 to H1
--> >> will just join the storm over the loop at least in one 
--> direction (RB2 will
--> >> forward it to RB1) but will not arrive at H1...
--> >>
--> >> One possible solution could be for RB2 to identify the 
--> fact that it is
--> >> receiving a frame from a host with a MAC address that is 
--> associated with a
--> >> segment it thought it isn't connected to. Hence, it may 
--> trigger an immediate
--> >> neighbor discovery / designated Rbridge election. 
--> However, because Rbridges
--> >> should allow host mobility, this frame may need to be 
--> forwarded (and hence
--> >> the storm commences).
--> >>
--> >> As mentioned above, any comments are welcome.
--> >>  Gideon Kaempfer
--> >>
--> >> _______________________________________________
--> >> rbridge mailing list
--> >> [e-mail]
--> >> http://mailman.postel.org/mailman/listinfo/rbridge
--> >>  
--> >>
--> >>     
--> >
--> > _______________________________________________
--> > rbridge mailing list
--> > [e-mail]
--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> >   
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA3JsHFw005903 for <[e-mail]>; Fri, 3 Nov 2006 11:54:17 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA3JsEfK002657; Fri, 3 Nov 2006 14:54:14 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09270;  Fri, 3 Nov 2006 14:54:14 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB648TFF>; Fri, 3 Nov 2006 14:54:13 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Gideon Kaempfer <[e-mail]>, Radia Perlman <[e-mail]>
Date: Fri, 3 Nov 2006 14:54:06 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FF81.D21DAD75"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 19:54:44 -0000
Status: RO
Content-Length: 19900

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C6FF81.D21DAD75
Content-Type: text/plain

Gideon,
 
    "Drop BPDUs" is not (exactly) the same as ignore them.  We use the term 
as short-hand for the one of three options we considered for handling BPDUs:

 
    Drop (do not participate actively in STP, and do not pass BPDUs
through), 
    Transparent (pass BPDUs through - potentially altering them in some
way),
    Participate (have each RBridge participate in STP as if it were a
bridge).
 
Hence, when we say "Drop BPDUs" we are not saying that we cannot look 
at them, we are just saying that we're not doing one of the other two
choices.
 
--
Eric


  _____  

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Gideon Kaempfer
Sent: Friday, November 03, 2006 1:40 AM
To: Radia Perlman
Cc: [e-mail]
Subject: Re: [rbridge] Traffic storms


Radia,
Wouldn't this create a link between TRILL and STP we are trying to avoid?
Relying on the fact that a LAN segment has some kind of unique identifier
(such as the root bridge ID) seems like a very practical solution to me, but
strongly reliant on the fact that the Rbridges actually process BPDUs. I
thought they were just meant to discard them. Is this acceptable? 
Regrads,
 Gidi

 
On 11/3/06, Radia Perlman <[e-mail]
<mailto:[e-mail]> > wrote: 

The simplest way to put it, I think, is that in certain transitory
situations there might be two
RBridges that both think they are Designated RBridge, and that is bad, 
but should stop
as soon as a single Hello is received by the RBridge who should not be
Designated.

I think PIM has similar transitory situations that can occur, and
bridges can also have (hopefully
temporary) problems if a repeater came up and merged two LANs. I think
such things are
annoying but not fatal. But I think it's possible we can with little
effort avoid this problem.

However, with RBridges, because the bridge spanning tree algorithm 
elects a Root, there's
really a way of uniquely identifying a LAN (where "LAN" is a bunch of
links connected with
bridges). The unique identifier is the root bridge.

When the B1-B2 link is down, RB1 and RB2 will see the topology as two 
separate links, and each
one will have a distinct spanning tree Root bridge (RB1 will see B1, and
RB2 will see B2 as the root).

When the B1-B2 link comes up, the bridges will first merge the two
links, and either RB1 or RB2 will 
see that the bridge spanning tree root has changed. This will be
discovered before B1 and B2 forward
traffic across the link because of the bridge forwarding delay.
If B1 has better priority as bridge spanning tree root than B2, then RB1 
will not notice anything
different when the B1-B2 link comes up. But RB2 will notice
something different; the spanning tree root has changed identities from
"B2" to "B1".

Given this, RB2 could temporarily stop forwarding to or from the link 
when the Root bridge
changes identities, though it should definitely immediately send IS-IS
Hellos (either RB1 or RB2 will
be elected Designated Router in the IS-IS election for that link). If
RB2 has better prioirty for 
root, the RB1 will immediately stop forwarding to or from the link when
it sees the Hello from RB2.
If RB2 has better priority in the IS-IS election, then RB1 should
immediately send an IS-IS Hello
when it sees a Hello from a new RBridge on the link. 

So I think this is not a big deal, and that if we are worried, we can
specify that an RBridge should
stop acting like the Designated RBridge for a few seconds after the
identity of the Root in the spanning 
tree algorithm changes.

Or we could be even fancier and have each RBridge announce in its IS-IS
Hellos which LAN IDs it
is Designated for, where a LAN ID is the MAC address of the Root bridge.
So RB1 continue 
forwarding if the identity changes from B1 to B2 provided no other
RBridge has claimed to be connected
to B2. But if RB2's LSP claims it is attached to B2, then RB1 must stop
forwarding for enough time
for the IS-IS election to sort itself out and choose a Designated RBridge. 

Radia






Gideon Kaempfer wrote:

>Following mention by Silvano of broadcast and multicast storms (and the
need
>to protect against them), I played around with different scenarios and came

>upon one I would appreciate your comments on (in the hope I am pointing out
>a non-existent issue with TRILL). I believe a broadcast and even a unicast
>storm could be created as the result of a loop that isn't protected by TTL 
>nor by STP in the case of a link connecting two separate LAN segments
coming
>to life.
>
>- RB1 ---- RB2 -
>   |        |
>-  B1 --x-- B2 -
>   |        |
>   H1       H2
>
>1. The network (segment) involved consists of two Rbridges (RB1, RB2), two
>bridges (B1, B2) and two hosts (H1, H2). They are physically connected as
>depicted.
>2. State A: the direct link between B1 and B2 is down. B1 and B2 find 
>themselves on different LAN segments and hence different spanning trees.
RB1
>and RB2 are both designated Rbridges (each for the segment of the
>corresponding bridge).
>3. State B: the direct link between B1 and B2 goes up (someone connects a 
>cable). B1 and B2 discover each other and establish a common spanning tree.
>RB1 and RB2 both find themselves attached to the same LAN segment and hence
>RB1 (without loss of generality) will eventually become the designated 
>Rbridge for it.
>4. Just before RB1 and RB2 identify that they are both on the same segment
>and RB2 stops functioning as a designated Rbridge the following scenario
>seems possible:
>  a. H1 sends a broadcast frame. 
>  b. B1 receives it and forwards to RB1 and B2.
>  c. RB1 (encapsulates and) forwards to RB2.
>  d. B2 forwards to RB2 and H2.
>  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2 to RB1). 
>  f. (RB1 forwards to B1.)
>  g. B2 forwards (again) to H2 and to B1.
>  h. B1 forwards to H1 (see remark below regarding filtering table
>contamination) and to RB1.
>  i. Etcetera etcetera. 
>5. A broadcast storm is born, created by a loop that is not protected by
TTL
>(due to the fact that forwarding between the Rbridges is only across a
>single hop) nor by STP (due to the fact that Rbridges do not participate in

>STP).
>6. If forwarding commences at the hardware level and no broadcast rate
>limiting is in place, the storm may cause severe damage in a very short
time
>(note that replicated frames are sent to H1 and H2 (or any network they 
>could represent).
>7. Another unfortunate effect of this storm is that B1 and B2 no longer
know
>where H1 is located (due to the contamination of their filtering tables by
a
>frame from H1 that arrives from the wrong direction (and in fact from 
>multiple directions). As a result, a possible unicast frame from H2 to H1
>will just join the storm over the loop at least in one direction (RB2 will
>forward it to RB1) but will not arrive at H1...
>
>One possible solution could be for RB2 to identify the fact that it is
>receiving a frame from a host with a MAC address that is associated with a
>segment it thought it isn't connected to. Hence, it may trigger an
immediate 
>neighbor discovery / designated Rbridge election. However, because Rbridges
>should allow host mobility, this frame may need to be forwarded (and hence
>the storm commences).
>
>As mentioned above, any comments are welcome. 
>  Gideon Kaempfer
>
>_______________________________________________
>rbridge mailing list
>[e-mail] <mailto:[e-mail]> 
>  <http://mailman.postel.org/mailman/listinfo/rbridge>
http://mailman.postel.org/mailman/listinfo/rbridge
>
>

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




------_=_NextPart_001_01C6FF81.D21DAD75
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">


<META content="MSHTML 6.00.2800.1561" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=798025019-03112006><FONT face=Arial 
color=#0000ff size=2>Gideon,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=798025019-03112006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=798025019-03112006>&nbsp;&nbsp;&nbsp; <FONT 
face=Arial color=#0000ff size=2>"Drop BPDUs" is not (exactly) the same as ignore 
them.&nbsp; We use the term </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=798025019-03112006><FONT face=Arial 
color=#0000ff size=2>as short-hand for the one of three options we considered 
for handling BPDUs: </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=798025019-03112006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=798025019-03112006><FONT face=Arial 
color=#0000ff size=2>&nbsp;&nbsp;&nbsp; Drop (do not participate actively in 
STP, and do not pass BPDUs through), </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=798025019-03112006>&nbsp;&nbsp;&nbsp; <FONT 
face=Arial color=#0000ff size=2>Transparent (pass BPDUs through - potentially 
altering them in some way),</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=798025019-03112006>&nbsp;&nbsp;&nbsp; <FONT 
face=Arial color=#0000ff size=2>Participate (have each RBridge participate in 
STP as if it were a bridge).</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=798025019-03112006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=798025019-03112006><FONT face=Arial 
color=#0000ff size=2>Hence, when we say "Drop BPDUs" we are not saying that we 
cannot look </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=798025019-03112006><FONT face=Arial 
color=#0000ff size=2>at them, we are just saying that we're not doing one of the 
other two choices.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=798025019-03112006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=798025019-03112006><FONT face=Arial 
color=#0000ff size=2>--</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=798025019-03112006><FONT face=Arial 
color=#0000ff size=2>Eric</FONT></SPAN></DIV><BR>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> [e-mail] 
  [mailto:[e-mail]] <B>On Behalf Of </B>Gideon 
  Kaempfer<BR><B>Sent:</B> Friday, November 03, 2006 1:40 AM<BR><B>To:</B> Radia 
  Perlman<BR><B>Cc:</B> [e-mail]<BR><B>Subject:</B> Re: [rbridge] 
  Traffic storms<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV>Radia,</DIV>
  <DIV>Wouldn't this create a link between TRILL and STP we are trying to 
  avoid?</DIV>
  <DIV>Relying on the fact that a LAN segment has some kind of unique identifier 
  (such as the root bridge ID) seems like a very practical solution to me, but 
  strongly reliant on the fact that the Rbridges actually process BPDUs. I 
  thought they were just meant to discard them. Is this acceptable? </DIV>
  <DIV>Regrads,</DIV>
  <DIV>&nbsp;Gidi<BR><BR>&nbsp;</DIV>
  <DIV><SPAN class=gmail_quote>On 11/3/06, <B class=gmail_sendername>Radia 
  Perlman</B> &lt;<A 
  href="mailto:[e-mail]">[e-mail]</A>&gt; 
  wrote:</SPAN> 
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">The 
    simplest way to put it, I think, is that in certain transitory<BR>situations 
    there might be two<BR>RBridges that both think they are Designated RBridge, 
    and that is bad, <BR>but should stop<BR>as soon as a single Hello is 
    received by the RBridge who should not be<BR>Designated.<BR><BR>I think PIM 
    has similar transitory situations that can occur, and<BR>bridges can also 
    have (hopefully<BR>temporary) problems if a repeater came up and merged two 
    LANs. I think<BR>such things are<BR>annoying but not fatal. But I think it's 
    possible we can with little<BR>effort avoid this problem.<BR><BR>However, 
    with RBridges, because the bridge spanning tree algorithm <BR>elects a Root, 
    there's<BR>really a way of uniquely identifying a LAN (where "LAN" is a 
    bunch of<BR>links connected with<BR>bridges). The unique identifier is the 
    root bridge.<BR><BR>When the B1-B2 link is down, RB1 and RB2 will see the 
    topology as two <BR>separate links, and each<BR>one will have a distinct 
    spanning tree Root bridge (RB1 will see B1, and<BR>RB2 will see B2 as the 
    root).<BR><BR>When the B1-B2 link comes up, the bridges will first merge the 
    two<BR>links, and either RB1 or RB2 will <BR>see that the bridge spanning 
    tree root has changed. This will be<BR>discovered before B1 and B2 
    forward<BR>traffic across the link because of the bridge forwarding 
    delay.<BR>If B1 has better priority as bridge spanning tree root than B2, 
    then RB1 <BR>will not notice anything<BR>different when the B1-B2 link comes 
    up. But RB2 will notice<BR>something different; the spanning tree root has 
    changed identities from<BR>"B2" to "B1".<BR><BR>Given this, RB2 could 
    temporarily stop forwarding to or from the link <BR>when the Root 
    bridge<BR>changes identities, though it should definitely immediately send 
    IS-IS<BR>Hellos (either RB1 or RB2 will<BR>be elected Designated Router in 
    the IS-IS election for that link). If<BR>RB2 has better prioirty for 
    <BR>root, the RB1 will immediately stop forwarding to or from the link 
    when<BR>it sees the Hello from RB2.<BR>If RB2 has better priority in the 
    IS-IS election, then RB1 should<BR>immediately send an IS-IS Hello<BR>when 
    it sees a Hello from a new RBridge on the link. <BR><BR>So I think this is 
    not a big deal, and that if we are worried, we can<BR>specify that an 
    RBridge should<BR>stop acting like the Designated RBridge for a few seconds 
    after the<BR>identity of the Root in the spanning <BR>tree algorithm 
    changes.<BR><BR>Or we could be even fancier and have each RBridge announce 
    in its IS-IS<BR>Hellos which LAN IDs it<BR>is Designated for, where a LAN ID 
    is the MAC address of the Root bridge.<BR>So RB1 continue <BR>forwarding if 
    the identity changes from B1 to B2 provided no other<BR>RBridge has claimed 
    to be connected<BR>to B2. But if RB2's LSP claims it is attached to B2, then 
    RB1 must stop<BR>forwarding for enough time<BR>for the IS-IS election to 
    sort itself out and choose a Designated RBridge. 
    <BR><BR>Radia<BR><BR><BR><BR><BR><BR><BR>Gideon Kaempfer 
    wrote:<BR><BR>&gt;Following mention by Silvano of broadcast and multicast 
    storms (and the need<BR>&gt;to protect against them), I played around with 
    different scenarios and came <BR>&gt;upon one I would appreciate your 
    comments on (in the hope I am pointing out<BR>&gt;a non-existent issue with 
    TRILL). I believe a broadcast and even a unicast<BR>&gt;storm could be 
    created as the result of a loop that isn't protected by TTL <BR>&gt;nor by 
    STP in the case of a link connecting two separate LAN segments 
    coming<BR>&gt;to life.<BR>&gt;<BR>&gt;- RB1 ---- RB2 -<BR>&gt;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<BR>&gt;-&nbsp;&nbsp;B1 
    --x-- B2 -<BR>&gt;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<BR>&gt;&nbsp;&nbsp; 
    H1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; H2<BR>&gt;<BR>&gt;1. The network 
    (segment) involved consists of two Rbridges (RB1, RB2), two<BR>&gt;bridges 
    (B1, B2) and two hosts (H1, H2). They are physically connected 
    as<BR>&gt;depicted.<BR>&gt;2. State A: the direct link between B1 and B2 is 
    down. B1 and B2 find <BR>&gt;themselves on different LAN segments and hence 
    different spanning trees. RB1<BR>&gt;and RB2 are both designated Rbridges 
    (each for the segment of the<BR>&gt;corresponding bridge).<BR>&gt;3. State 
    B: the direct link between B1 and B2 goes up (someone connects a 
    <BR>&gt;cable). B1 and B2 discover each other and establish a common 
    spanning tree.<BR>&gt;RB1 and RB2 both find themselves attached to the same 
    LAN segment and hence<BR>&gt;RB1 (without loss of generality) will 
    eventually become the designated <BR>&gt;Rbridge for it.<BR>&gt;4. Just 
    before RB1 and RB2 identify that they are both on the same 
    segment<BR>&gt;and RB2 stops functioning as a designated Rbridge the 
    following scenario<BR>&gt;seems possible:<BR>&gt;&nbsp;&nbsp;a. H1 sends a 
    broadcast frame. <BR>&gt;&nbsp;&nbsp;b. B1 receives it and forwards to RB1 
    and B2.<BR>&gt;&nbsp;&nbsp;c. RB1 (encapsulates and) forwards to 
    RB2.<BR>&gt;&nbsp;&nbsp;d. B2 forwards to RB2 and H2.<BR>&gt;&nbsp;&nbsp;e. 
    RB2 forwards the copy from RB1 to B2 (and the copy from B2 to RB1). 
    <BR>&gt;&nbsp;&nbsp;f. (RB1 forwards to B1.)<BR>&gt;&nbsp;&nbsp;g. B2 
    forwards (again) to H2 and to B1.<BR>&gt;&nbsp;&nbsp;h. B1 forwards to H1 
    (see remark below regarding filtering table<BR>&gt;contamination) and to 
    RB1.<BR>&gt;&nbsp;&nbsp;i. Etcetera etcetera. <BR>&gt;5. A broadcast storm 
    is born, created by a loop that is not protected by TTL<BR>&gt;(due to the 
    fact that forwarding between the Rbridges is only across a<BR>&gt;single 
    hop) nor by STP (due to the fact that Rbridges do not participate in 
    <BR>&gt;STP).<BR>&gt;6. If forwarding commences at the hardware level and no 
    broadcast rate<BR>&gt;limiting is in place, the storm may cause severe 
    damage in a very short time<BR>&gt;(note that replicated frames are sent to 
    H1 and H2 (or any network they <BR>&gt;could represent).<BR>&gt;7. Another 
    unfortunate effect of this storm is that B1 and B2 no longer 
    know<BR>&gt;where H1 is located (due to the contamination of their filtering 
    tables by a<BR>&gt;frame from H1 that arrives from the wrong direction (and 
    in fact from <BR>&gt;multiple directions). As a result, a possible unicast 
    frame from H2 to H1<BR>&gt;will just join the storm over the loop at least 
    in one direction (RB2 will<BR>&gt;forward it to RB1) but will not arrive at 
    H1...<BR>&gt;<BR>&gt;One possible solution could be for RB2 to identify the 
    fact that it is<BR>&gt;receiving a frame from a host with a MAC address that 
    is associated with a<BR>&gt;segment it thought it isn't connected to. Hence, 
    it may trigger an immediate <BR>&gt;neighbor discovery / designated Rbridge 
    election. However, because Rbridges<BR>&gt;should allow host mobility, this 
    frame may need to be forwarded (and hence<BR>&gt;the storm 
    commences).<BR>&gt;<BR>&gt;As mentioned above, any comments are welcome. 
    <BR>&gt;&nbsp;&nbsp;Gideon 
    Kaempfer<BR>&gt;<BR>&gt;_______________________________________________<BR>&gt;rbridge 
    mailing list<BR>&gt;<A 
    href="mailto:[e-mail]">[e-mail]</A><BR>&gt;<A 
    href="http://mailman.postel.org/mailman/listinfo/rbridge"> 
    http://mailman.postel.org/mailman/listinfo/rbridge</A><BR>&gt;<BR>&gt;<BR><BR>_______________________________________________<BR>rbridge 
    mailing list<BR><A 
    href="mailto:[e-mail]">[e-mail]</A><BR><A 
    href="http://mailman.postel.org/mailman/listinfo/rbridge">http://mailman.postel.org/mailman/listinfo/rbridge</A><BR></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C6FF81.D21DAD75--


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA3JnlP4004123 for <[e-mail]>; Fri, 3 Nov 2006 11:49:47 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA3JnhfK002598; Fri, 3 Nov 2006 14:49:44 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09072;  Fri, 3 Nov 2006 14:49:43 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB648TDJ>; Fri, 3 Nov 2006 14:49:42 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Radia Perlman <[e-mail]>, [e-mail]
Date: Fri, 3 Nov 2006 14:49:37 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 19:50:31 -0000
Status: RO
Content-Length: 4111

Radia,

	A few amplifying comments below...

--
Eric 

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Radia Perlman
--> Sent: Friday, November 03, 2006 1:25 AM
--> To: [e-mail]
--> Cc: [e-mail]
--> Subject: Re: [rbridge] Traffic storms
--> 
--> The simplest way to put it, I think, is that in certain transitory 
--> situations there might be two RBridges that both think they are 
--> Designated RBridge, and that is bad, but should stop as soon as a
--> single Hello is received by the RBridge who should not be Designated.

Yes, this is what would happen in the least clue-full implementation
possible.  This would be a pretty bad solution in the absence of the
potential for determining that a topology cahnge has occurred (or is
in progress) by other means.

For one thing, the RBridges in this approach would have to employ some
form of priorityzed forwarding in order to inclrease the likelihood
that Hello messages actually get through the storm.

--> 
--> I think PIM has similar transitory situations that can occur, and 
--> bridges can also have (hopefully temporary) problems if a repeater 
--> came up and merged two LANs. I think such things are annoying but 
--> not fatal. But I think it's possible we can with little effort 
--> avoid this problem.
--> 
--> However, with RBridges, because the bridge spanning tree algorithm 
--> elects a Root, there's really a way of uniquely identifying a LAN 
--> (where "LAN" is a bunch of links connected with bridges). The unique 
--> identifier is the root bridge.

I am sure that this is not required.

--> 
--> When the B1-B2 link is down, RB1 and RB2 will see the topology as two 
--> separate links, and each one will have a distinct spanning tree Root 
--> bridge (RB1 will see B1, and RB2 will see B2 as the root).
--> 
--> When the B1-B2 link comes up, the bridges will first merge the two 
--> links, and either RB1 or RB2 will see that the bridge spanning tree 
--> root has changed. This will be discovered before B1 and B2 forward
--> traffic across the link because of the bridge forwarding delay.

Agree.

--> If B1 has better priority as bridge spanning tree root than B2, then RB1

--> will not notice anything different when the B1-B2 link comes up. But RB2

--> will notice something different; the spanning tree root has changed 
--> identities from "B2" to "B1".

Yet another way to detect the change.

--> 
--> Given this, RB2 could temporarily stop forwarding to or from the link 
--> when the Root bridge changes identities, though it should definitely 
--> immediately send IS-IS Hellos (either RB1 or RB2 will be elected 
--> Designated Router in the IS-IS election for that link). If RB2 has 
--> better prioirty for root, the RB1 will immediately stop forwarding to 
--> or from the link when it sees the Hello from RB2.
-->
--> If RB2 has better priority in the IS-IS election, then RB1 should 
--> immediately send an IS-IS Hello when it sees a Hello from a new RBridge 
--> on the link.
--> 
--> So I think this is not a big deal, and that if we are worried, we can 
--> specify that an RBridge should stop acting like the Designated RBridge 
--> for a few seconds after the identity of the Root in the spanning
--> tree algorithm changes.

I believe this is essential only for non-unicast traffic.

--> 
--> Or we could be even fancier and have each RBridge announce in its IS-IS 
--> Hellos which LAN IDs it is Designated for, where a LAN ID is the MAC 
--> address of the Root bridge. So RB1 continue forwarding if the identity 
--> changes from B1 to B2 provided no other RBridge has claimed to be
connected
--> to B2. But if RB2's LSP claims it is attached to B2, then RB1 must stop 
--> forwarding for enough time for the IS-IS election to sort itself out and

--> choose a Designated RBridge.

In addition to being "too fancy" by more than enough, this is not really
necessary, given the plethora of ways to detect that a topology change 
either has already occurred, or may be in progress.

--> 
--> Radia
--> 
-- [snip] --


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA3JJXt2024200 for <[e-mail]>; Fri, 3 Nov 2006 11:19:34 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA3JJTfK002150; Fri, 3 Nov 2006 14:19:29 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA07294;  Fri, 3 Nov 2006 14:19:29 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB648STX>; Fri, 3 Nov 2006 14:19:28 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: [e-mail]
Date: Fri, 3 Nov 2006 14:19:27 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA3JJXt2024200
Cc: [e-mail]
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 19:20:14 -0000
Status: RO
Content-Length: 7575

Gideon,

	This is a good question.  Please see comments and responses 
below...

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Gideon Kaempfer
--> Sent: Thursday, November 02, 2006 6:08 PM
--> To: [e-mail]
--> Subject: [rbridge] Traffic storms
--> 
--> Following mention by Silvano of broadcast and multicast storms (and the
need
--> to protect against them), I played around with different scenarios and
came
--> upon one I would appreciate your comments on (in the hope I am pointing
out
--> a non-existent issue with TRILL). I believe a broadcast and even a
unicast
--> storm could be created as the result of a loop that isn't protected by
TTL
--> nor by STP in the case of a link connecting two separate LAN segments
coming
--> to life.
--> 
--> - RB1 ---- RB2 -
-->    |        |
--> -  B1 --x-- B2 -
-->    |        |
-->    H1       H2
--> 
--> 1. The network (segment) involved consists of two Rbridges (RB1, RB2),
two
--> bridges (B1, B2) and two hosts (H1, H2). They are physically connected
as
--> depicted.
--> 2. State A: the direct link between B1 and B2 is down. B1 and B2 find
--> themselves on different LAN segments and hence different spanning trees.
--> RB1 and RB2 are both designated Rbridges (each for the segment of the
--> corresponding bridge).
--> 3. State B: the direct link between B1 and B2 goes up (someone connects
a
--> cable). B1 and B2 discover each other and establish a common spanning
tree.
--> RB1 and RB2 both find themselves attached to the same LAN segment and
hence
--> RB1 (without loss of generality) will eventually become the designated
--> Rbridge for it.

This is exactly the reverse of the "chicken and egg" problem I mentioned
in dicussions of the "wiring closet" problem (note the similar topology)
with Guillermo (IBA?EZ), back in July.

In the "wiring closet" problem, the intention is to "break" the link between
B1 and B2 so that - in normal operation - both links [B1<->RB1 and B2<->RB2]
are used, while link [B1<->B2] is not.

In this case, you're positing that the link becomes active.  I have seen - 
and studied - this scenario in analysis.  I am reasonably sure others have 
as well.

--> 4. Just before RB1 and RB2 identify that they are both on the same
segment
--> and RB2 stops functioning as a designated Rbridge the following scenario
--> seems possible:
-->   a. H1 sends a broadcast frame.
-->   b. B1 receives it and forwards to RB1 and B2.
-->   c. RB1 (encapsulates and) forwards to RB2.
-->   d. B2 forwards to RB2 and H2.
-->   e. RB2 forwards the copy from RB1 to B2 (and the copy from B2 to RB1).
-->   f. (RB1 forwards to B1.)
-->   g. B2 forwards (again) to H2 and to B1.
-->   h. B1 forwards to H1 (see remark below regarding filtering table
-->      contamination) and to RB1.
-->   i. Etcetera etcetera.

One thing that you're not considering is that both B1 and B2 will send out
"topology change" BPDUs when the link [B1<->B2) goes active.  I believe 
several of the WG members have pointed out that the idea that RBridges 
"drop BPDUs" does not mean they ignore them - in particular, in the case 
of a "topology change" BPDU.

Ignoring this for a minute, it is worth noting that - in this scenario - 
both RBridges are in position to "get a clue" about the problem.  The MAC 
SA on the broadcast frame (forwarded onto the segment including B2, for
example), is a MAC DA that it may know is present on that segment, by the
time it is deciding whether or not to forward it on that segment.  

Typically, bridges will perform a consistency check, when learning a new
MAC from a received frame.  There is no reason to suppose that RBridges
are unable to perform this same trick.  The consistency check is - when 
a new MAC SA is seen on a port, the "bridge" makes a new filtering DB
entry for that port (showing that MAC as reachable via that port); at the
same time, the bridge should check that a matching entry does not exist
on another port. 

In the scenario you pose, the same broadcast frame will arrive at both 
RBridges from different ports, resulting in an apparent need to "learn"
the same MAC SA on both ports (order is not important) - resulting in 
the finding of "matching entries" at each RBridge.

If a matching entry is found, a clue is born - even if the RBridge hasn't
already determined (by BPDU snooping) that a topology change is happening. 

This may happen because, at the same time B1 forwards the broadcast frame 
(from H1) to RB1, it forwards it to B2 as well (as you note above).  B2 is
also going to forward that frame to RB2, which will attempt to forward it 
to RB1.  Meanwhile, RB1 will try to forward the broadcast frame, it gets
from B1, toward RB2.  No matter what order this occurs in, one or both of
the RBridges are going to detect an anomaly.

Of course, this assumes that both RBridges did not snoop a topology change
BPDU from either B1 or B2 - which would have directly clued them in on the
potential problem.

As Silvano has already indicated (and - I believe - gotten full agreement),
broadcast, multicast and flooded traffic - at least - must stop during a
topology change (just as it would in 802.1D bridging).

--> 5. A broadcast storm is born, created by a loop that is not protected by
TTL
--> (due to the fact that forwarding between the Rbridges is only across a
--> single hop) nor by STP (due to the fact that Rbridges do not participate
in
--> STP).

Assuming reasonably "clueful" RBridge implementations, no storm will occur.

--> 6. If forwarding commences at the hardware level and no broadcast rate
--> limiting is in place, the storm may cause severe damage in a very short
time
--> (note that replicated frames are sent to H1 and H2 (or any network they
--> could represent).

See above.

--> 7. Another unfortunate effect of this storm is that B1 and B2 no longer
know
--> where H1 is located (due to the contamination of their filtering tables
by a
--> frame from H1 that arrives from the wrong direction (and in fact from
--> multiple directions). As a result, a possible unicast frame from H2 to
H1
--> will just join the storm over the loop at least in one direction (RB2
will
--> forward it to RB1) but will not arrive at H1...

If RB1 and RB2 behave reasonably, this problem will either never occur, or
will be resolved as quickly as it would be in 802.1D bridging.

--> 
--> One possible solution could be for RB2 to identify the fact that it is
--> receiving a frame from a host with a MAC address that is associated with
a
--> segment it thought it isn't connected to. Hence, it may trigger an
immediate
--> neighbor discovery / designated Rbridge election. However, because
Rbridges
--> should allow host mobility, this frame may need to be forwarded (and
hence
--> the storm commences).

Yes, this is another approach.  Combine this with the fact that RB2 may also
have received a new reachability advertisement (via IS-IS) from RB1 (or have
one already from previous advertisements), saying that this MAC is reachable

via RB1 - just as RB2 should be considering make such an advertisement
itself.

This is an obvious inconsistency, and - while we do want to support mobility
- we do not have to optimize for it by assuming that all MAC "relocations"
are
automatically legitimate.

--> 
--> As mentioned above, any comments are welcome.
-->   Gideon Kaempfer
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA3IVnms004310 for <[e-mail]>; Fri, 3 Nov 2006 10:31:49 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA3IVkfK001342; Fri, 3 Nov 2006 13:31:47 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04321;  Fri, 3 Nov 2006 13:31:41 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB648R5B>; Fri, 3 Nov 2006 13:31:40 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>
Date: Fri, 3 Nov 2006 13:31:37 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] SPF verses STP, straight across the board
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 18:32:20 -0000
Status: RO
Content-Length: 2933

Silvano,

	 Not sure you have looked at my post to the WG on the subject
of using SPF for all cases.

	I have been assuming that SPF is used for all cases, as not
doing so produces problems.  Interestingly enough - from off-line
discussions - some of the problems I assume will happen if you mix
SPF (for unicast) and STP (for everything else), are exactly the
same as the problems you appear to be trying to address.

	Assume for a minute that all forwarding is based on SPF.  Do
the problems you're concerned about go away?

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Thursday, November 02, 2006 9:29 PM
--> To: Gray, Eric; [e-mail]
--> Subject: RE: [rbridge] SPF verses STP, straight across the board
--> 
--> 
--> Suppose that we have 5 RBridges, R1 to R5 and that R2 and R4 are
--> requesting a tree.
--> 
--> All the RBridges have the same LSA database propagated by ISIS.
--> They use Djikstra for the unicast core instance, putting 
--> themselves as
--> the root.
--> 
--> Then they also run two other instances of Djikstra, one 
--> using R2 as root
--> and one using R4 as root. As a result they put some port in 
--> forwarding
--> state and some in blocking state. Basically they compute 2 spanning
--> trees, one rooted in R2 (let's call it T2) and one rooted 
--> in R4 (T4),
--> without using the spanning tree protocol.
--> 
--> Each ingress RBridge can send multicast, broadcast and 
--> flooded frames
--> either on T2 or T4. It indicates its decision on the FTAG, which is
--> honored by all the other RBridges.
--> 
--> In this way the customer can get Shortest Path and also 
--> load balancing,
--> depending where he/she roots the trees. For example, in Fat Tree
--> networks, if you root the trees in the core, you get both.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: [e-mail] 
--> [mailto:[e-mail]]
--> On
--> > Behalf Of Gray, Eric
--> > Sent: Thursday, November 02, 2006 2:34 PM
--> > To: [e-mail]
--> > Subject: [rbridge] SPF verses STP, straight across the board
--> > 
--> > 
--> > There appears to be a late-blooming source of confusion 
--> relative to
--> > multicast, broadcast and flooded frame forwarding among RBridges.
--> > 
--> > The question is - do the concerns about efficient link utilization
--> > via the use of SPF routing apply to multicast, broadcast 
--> and flooded
--> > traffic (as they do to unicast traffic), or do we simply use some
--> > variation of STP to determine "spanning trees" for the non-unicast
--> > case?
--> > 
--> > I've been under the impression that the intention is to use SPF
--> > routing, straight across the board.
--> > 
--> > --
--> > Eric
--> > _______________________________________________
--> > rbridge mailing list
--> > [e-mail]
--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> 


Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA3H7khI006624 for <[e-mail]>; Fri, 3 Nov 2006 09:07:46 -0800 (PST)
Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Fri, 03 Nov 2006 09:07:25 -0800
X-Server-Uuid: 9206F490-5C8F-4575-BE70-2AAA8A3D4853
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 3B7552AE; Fri, 3 Nov 2006 09:07:25 -0800 (PST)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 0E30E2B0; Fri, 3 Nov 2006 09:07:25 -0800 (PST)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EJX90028; Fri, 3 Nov 2006 09:07:24 -0800 (PST)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 5E6D520501; Fri, 3 Nov 2006 09:07:24 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 3 Nov 2006 09:07:25 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] LIDs
Thread-Index: Acby4lFXsEqxu94iRvehpH6TvWktDQAD3QvAAwQ1XmAAGebSgA==
From: "Caitlin Bestler" <[e-mail]>
To: "Larry Kreeger (kreeger)" <[e-mail]>, "Erik Nordmark" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-WSS-ID: 6955A8C73ES700133-01-01
Content-Type: text/plain; charset=us-ascii
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA3H7khI006624
Cc: [e-mail]
Subject: Re: [rbridge] LIDs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 17:08:19 -0000
Status: RO
Content-Length: 1185

Larry Kreeger (kreeger) wrote:
> Hi,
> 
> I was catching up on old RBridge threads and saw this one about LIDs.
> 
> LIDs can be useful in reducing costs in large switches where
> the entire (potentially large) local MAC table would not need
> to be present in every module of the system.  In fact it
> could probably eliminate the need to keep locally learned
> MACs in hardware at all.  Assuming a switch with 16 slots and
> 48 ports per linecard, and servers running 16 virtual
> machines each connected to the ports, the number of local
> MACs would be 16*48*16= 12,288.  With 48 bits per address,
> that is ~59kbits.
> 
> With LIDs, an entry is need only per port, not per local MAC.
>  So given a 16 bit LID, only 16 cards * 48 ports * 16 bits =
> ~12kbits, a savings of ~47kbits.
> 
> The more locally attached MACs, the bigger the savings.
> 

Instead of keeping the MAC to Port mapping in the egress RBridge
you instead keep it in each ingress rbridge that has learned
of this rbridge. I'm not seeing a net savings in memory costs
anywhere. There is certainly a potential latency benefit, but
is there really one that is valid over the desired lifespan
of the protocol?








Received: from bender-mail.tigertech.net (bender-mail.tigertech.net [64.62.209.30]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA3GOJAt016621 for <[e-mail]>; Fri, 3 Nov 2006 08:24:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 039FB7E65 for <[e-mail]>; Fri,  3 Nov 2006 08:24:18 -0800 (PST)
Received: from JMHLap3.joelhalpern.com (pool-71-254-22-111.clppva.east.verizon.net [71.254.22.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id B85287E5B for <[e-mail]>; Fri,  3 Nov 2006 08:24:07 -0800 (PST)
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Fri, 03 Nov 2006 11:21:18 -0500
To: "Developing a hybrid router/bridge." <[e-mail]>
From: "Joel M. Halpern" <[e-mail]>
In-Reply-To: <[e-mail] mpresa.com>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net
X-Spam-Status: No, hits=-2.8 tagged_above=-999.0 required=7.0 tests=ALL_TRUSTED
X-Spam-Level: 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA3GOJAt016621
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 16:25:01 -0000
Status: RO
Content-Length: 9977

If we need to make the link state algorithm 
converge without introducing loops, the 
techniques for loop avoidance being discussed in 
the routing area may be of relevance.
In particular, ordered fib convergence seems quite suitable.
Yours,
Joel M. Halpern

At 10:31 AM 11/3/2006, Silvano Gai wrote:

>The examples from Gideon and Guillermo deal with 
>the interaction between STP/RSTP and TRILL and point one weakness of TRILL.
>
>There will be another cause for Broadcast storm 
>that does not involve STP/RSTP interaction, i.e. 
>a simple topology change in the TRILL network.
>
>Djikstar will run in an asynchronous way on the 
>different RBridges and the trees used to 
>distribute broadcast/multicast/unknown will 
>potentially have loops during the transition.
>
>TTL will be of limited help since the traffic 
>will replicate. For example, if the loop is 
>between two RBridges with 256 ports each, 
>assuming a TTL of 64, each broadcast present on 
>the link at the time the loop will cause a storm 
>of 16,000 frames. If the loops involve more 
>switches and links millions of copy will be 
>create. For Enterprise/Datacenter RBridges the 
>forwarding delay is less than 5 microseconds, 
>therefore the storm will reach its peak in 300 
>microseconds, well before any software intervention can break the loop.
>
>-- Silvano
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Guillermo Ib??ez
> > Sent: Friday, November 03, 2006 12:36 AM
> > To: Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] Traffic storms
> >
> > This comment is just to signal that the behaviour must be analyzed also
> > assuming that B1 and B2 execute the (current standard) RSTP protocol.
> > There is no forwarding delay in RSTP when the links are dedicated (point
> > to point).
> > If B1 and B2 execute RSTP protocol and B1 has best priority, before
> > link B1-B2 being enabled, B2 will block its designated ports  and stop
> > forwarding  to RB2.  The process will repeat later  for next stage
> > downstream links like B2-RB2 and so on, one level at a time.
> > The trend is to uses RSTP instead of STP. Root bridge election is likely
> > much faster  than DR election. Setting timers at RBridges to stop
> > forwarding may be a solution but it slows reconfiguration speed.
> > Guillermo
> >
> > Radia Perlman escribi?:
> > > The simplest way to put it, I think, is that in certain transitory
> > > situations there might be two
> > > RBridges that both think they are Designated RBridge, and that is bad,
> > > but should stop
> > > as soon as a single Hello is received by the RBridge who should not be
> > > Designated.
> > > I think PIM has similar transitory situations that can occur, and
> > >
> > > bridges can also have (hopefully
> > > temporary) problems if a repeater came up and merged two LANs. I think
> > > such things are
> > > annoying but not fatal. But I think it's possible we can with little
> > > effort avoid this problem.
> > >
> > > However, with RBridges, because the bridge spanning tree algorithm
> > > elects a Root, there's
> > > really a way of uniquely identifying a LAN (where "LAN" is a bunch of
> > > links connected with
> > > bridges). The unique identifier is the root bridge.
> > >
> >
> > > When the B1-B2 link is down, RB1 and RB2 will see the topology as two
> > > separate links, and each
> > > one will have a distinct spanning tree Root bridge (RB1 will see B1, and
> > > RB2 will see B2 as the root).
> > >
> > > When the B1-B2 link comes up, the bridges will first merge the two
> > > links,
> > > and either RB1 or RB2 will
> > > see that the bridge spanning tree root has changed. This will be
> > > discovered before B1 and B2 forward
> > > traffic across the link because of the bridge forwarding delay.If B1 has
> > better priority as bridge spanning tree root than B2, then RB1 will not
> > notice anything
> > > different when the B1-B2 link comes up. But RB2 will notice
> > > something different; the spanning tree root has changed identities from
> > > "B2" to "B1".
> > > Given this, RB2 could temporarily stop forwarding to or from the link
> > > when the Root bridge
> > > changes identities, though it should definitely immediately send IS-IS
> > > Hellos (either RB1 or RB2 will
> > > be elected Designated Router in the IS-IS election for that link). If
> > > RB2 has better prioirty for
> > > root, the RB1 will immediately stop forwarding to or from the link when
> > > it sees the Hello from RB2.
> > > If RB2 has better priority in the IS-IS election, then RB1 should
> > > immediately send an IS-IS Hello
> > > when it sees a Hello from a new RBridge on the link.
> > >
> > > So I think this is not a big deal, and that if we are worried, we can
> > > specify that an RBridge should
> > > stop acting like the Designated RBridge for a few seconds after the
> > > identity of the Root in the spanning
> > > tree algorithm changes.
> > >
> > > Or we could be even fancier and have each RBridge announce in its IS-IS
> > > Hellos which LAN IDs it
> > > is Designated for, where a LAN ID is the MAC address of the Root bridge.
> > > So RB1 continue
> > > forwarding if the identity changes from B1 to B2 provided no other
> > > RBridge has claimed to be connected
> > > to B2. But if RB2's LSP claims it is attached to B2, then RB1 must stop
> > > forwarding for enough time
> > > for the IS-IS election to sort itself out and choose a Designated
> > RBridge.
> > >
> > > Radia
> > >
> > >
> > >
> > >
> > >
> > >
> > > Gideon Kaempfer wrote:
> > >
> > >
> > >> Following mention by Silvano of broadcast and multicast storms (and the
> > need
> > >> to protect against them), I played around with different scenarios and
> > came
> > >> upon one I would appreciate your comments on (in the hope I am pointing
> > out
> > >> a non-existent issue with TRILL). I believe a broadcast and even a
> > unicast
> > >> storm could be created as the result of a loop that isn't protected by
> > TTL
> > >> nor by STP in the case of a link connecting two separate LAN segments
> > coming
> > >> to life.
> > >>
> > >> - RB1 ---- RB2 -
> > >>   |        |
> > >> -  B1 --x-- B2 -
> > >>   |        |
> > >>   H1       H2
> > >>
> > >> 1. The network (segment) involved consists of two Rbridges (RB1, RB2),
> > two
> > >> bridges (B1, B2) and two hosts (H1, H2). They are physically connected
> > as
> > >> depicted.
> > >> 2. State A: the direct link between B1 and B2 is down. B1 and B2 find
> > >> themselves on different LAN segments and hence different spanning
> > trees. RB1
> > >> and RB2 are both designated Rbridges (each for the segment of the
> > >> corresponding bridge).
> > >> 3. State B: the direct link between B1 and B2 goes up (someone connects
> > a
> > >> cable). B1 and B2 discover each other and establish a common spanning
> > tree.
> > >> RB1 and RB2 both find themselves attached to the same LAN segment and
> > hence
> > >> RB1 (without loss of generality) will eventually become the designated
> > >> Rbridge for it.
> > >> 4. Just before RB1 and RB2 identify that they are both on the same
> > segment
> > >> and RB2 stops functioning as a designated Rbridge the following
> > scenario
> > >> seems possible:
> > >>  a. H1 sends a broadcast frame.
> > >>  b. B1 receives it and forwards to RB1 and B2.
> > >>  c. RB1 (encapsulates and) forwards to RB2.
> > >>  d. B2 forwards to RB2 and H2.
> > >>  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2 to RB1).
> > >>  f. (RB1 forwards to B1.)
> > >>  g. B2 forwards (again) to H2 and to B1.
> > >>  h. B1 forwards to H1 (see remark below regarding filtering table
> > >> contamination) and to RB1.
> > >>  i. Etcetera etcetera.
> > >> 5. A broadcast storm is born, created by a loop that is not protected
> > by TTL
> > >> (due to the fact that forwarding between the Rbridges is only across a
> > >> single hop) nor by STP (due to the fact that Rbridges do not
> > participate in
> > >> STP).
> > >> 6. If forwarding commences at the hardware level and no broadcast rate
> > >> limiting is in place, the storm may cause severe damage in a very short
> > time
> > >> (note that replicated frames are sent to H1 and H2 (or any network they
> > >> could represent).
> > >> 7. Another unfortunate effect of this storm is that B1 and B2 no longer
> > know
> > >> where H1 is located (due to the contamination of their filtering tables
> > by a
> > >> frame from H1 that arrives from the wrong direction (and in fact from
> > >> multiple directions). As a result, a possible unicast frame from H2 to
> > H1
> > >> will just join the storm over the loop at least in one direction (RB2
> > will
> > >> forward it to RB1) but will not arrive at H1...
> > >>
> > >> One possible solution could be for RB2 to identify the fact that it is
> > >> receiving a frame from a host with a MAC address that is associated
> > with a
> > >> segment it thought it isn't connected to. Hence, it may trigger an
> > immediate
> > >> neighbor discovery / designated Rbridge election. However, because
> > Rbridges
> > >> should allow host mobility, this frame may need to be forwarded (and
> > hence
> > >> the storm commences).
> > >>
> > >> As mentioned above, any comments are welcome.
> > >>  Gideon Kaempfer
> > >>
> > >> _______________________________________________
> > >> rbridge mailing list
> > >> [e-mail]
> > >> http://mailman.postel.org/mailman/listinfo/rbridge
> > >>
> > >>
> > >>
> > >
> > > _______________________________________________
> > > rbridge mailing list
> > > [e-mail]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > >
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge




Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA3FVinm027815 for <[e-mail]>; Fri, 3 Nov 2006 07:31:44 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Fri, 3 Nov 2006 07:31:40 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Traffic storms
Thread-Index: Acb/JBETbtTwiIidQBSXef/wDuZTEAANtKbw
From: "Silvano Gai" <[e-mail]>
To: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA3FVinm027815
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 15:32:21 -0000
Status: RO
Content-Length: 9085

The examples from Gideon and Guillermo deal with the interaction between STP/RSTP and TRILL and point one weakness of TRILL.

There will be another cause for Broadcast storm that does not involve STP/RSTP interaction, i.e. a simple topology change in the TRILL network.

Djikstar will run in an asynchronous way on the different RBridges and the trees used to distribute broadcast/multicast/unknown will potentially have loops during the transition.

TTL will be of limited help since the traffic will replicate. For example, if the loop is between two RBridges with 256 ports each, assuming a TTL of 64, each broadcast present on the link at the time the loop will cause a storm of 16,000 frames. If the loops involve more switches and links millions of copy will be create. For Enterprise/Datacenter RBridges the forwarding delay is less than 5 microseconds, therefore the storm will reach its peak in 300 microseconds, well before any software intervention can break the loop.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Guillermo Ib??ez
> Sent: Friday, November 03, 2006 12:36 AM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Traffic storms
> 
> This comment is just to signal that the behaviour must be analyzed also
> assuming that B1 and B2 execute the (current standard) RSTP protocol.
> There is no forwarding delay in RSTP when the links are dedicated (point
> to point).
> If B1 and B2 execute RSTP protocol and B1 has best priority, before
> link B1-B2 being enabled, B2 will block its designated ports  and stop
> forwarding  to RB2.  The process will repeat later  for next stage
> downstream links like B2-RB2 and so on, one level at a time.
> The trend is to uses RSTP instead of STP. Root bridge election is likely
> much faster  than DR election. Setting timers at RBridges to stop
> forwarding may be a solution but it slows reconfiguration speed.
> Guillermo
> 
> Radia Perlman escribi?:
> > The simplest way to put it, I think, is that in certain transitory
> > situations there might be two
> > RBridges that both think they are Designated RBridge, and that is bad,
> > but should stop
> > as soon as a single Hello is received by the RBridge who should not be
> > Designated.
> > I think PIM has similar transitory situations that can occur, and
> >
> > bridges can also have (hopefully
> > temporary) problems if a repeater came up and merged two LANs. I think
> > such things are
> > annoying but not fatal. But I think it's possible we can with little
> > effort avoid this problem.
> >
> > However, with RBridges, because the bridge spanning tree algorithm
> > elects a Root, there's
> > really a way of uniquely identifying a LAN (where "LAN" is a bunch of
> > links connected with
> > bridges). The unique identifier is the root bridge.
> >
> 
> > When the B1-B2 link is down, RB1 and RB2 will see the topology as two
> > separate links, and each
> > one will have a distinct spanning tree Root bridge (RB1 will see B1, and
> > RB2 will see B2 as the root).
> >
> > When the B1-B2 link comes up, the bridges will first merge the two
> > links,
> > and either RB1 or RB2 will
> > see that the bridge spanning tree root has changed. This will be
> > discovered before B1 and B2 forward
> > traffic across the link because of the bridge forwarding delay.If B1 has
> better priority as bridge spanning tree root than B2, then RB1 will not
> notice anything
> > different when the B1-B2 link comes up. But RB2 will notice
> > something different; the spanning tree root has changed identities from
> > "B2" to "B1".
> > Given this, RB2 could temporarily stop forwarding to or from the link
> > when the Root bridge
> > changes identities, though it should definitely immediately send IS-IS
> > Hellos (either RB1 or RB2 will
> > be elected Designated Router in the IS-IS election for that link). If
> > RB2 has better prioirty for
> > root, the RB1 will immediately stop forwarding to or from the link when
> > it sees the Hello from RB2.
> > If RB2 has better priority in the IS-IS election, then RB1 should
> > immediately send an IS-IS Hello
> > when it sees a Hello from a new RBridge on the link.
> >
> > So I think this is not a big deal, and that if we are worried, we can
> > specify that an RBridge should
> > stop acting like the Designated RBridge for a few seconds after the
> > identity of the Root in the spanning
> > tree algorithm changes.
> >
> > Or we could be even fancier and have each RBridge announce in its IS-IS
> > Hellos which LAN IDs it
> > is Designated for, where a LAN ID is the MAC address of the Root bridge.
> > So RB1 continue
> > forwarding if the identity changes from B1 to B2 provided no other
> > RBridge has claimed to be connected
> > to B2. But if RB2's LSP claims it is attached to B2, then RB1 must stop
> > forwarding for enough time
> > for the IS-IS election to sort itself out and choose a Designated
> RBridge.
> >
> > Radia
> >
> >
> >
> >
> >
> >
> > Gideon Kaempfer wrote:
> >
> >
> >> Following mention by Silvano of broadcast and multicast storms (and the
> need
> >> to protect against them), I played around with different scenarios and
> came
> >> upon one I would appreciate your comments on (in the hope I am pointing
> out
> >> a non-existent issue with TRILL). I believe a broadcast and even a
> unicast
> >> storm could be created as the result of a loop that isn't protected by
> TTL
> >> nor by STP in the case of a link connecting two separate LAN segments
> coming
> >> to life.
> >>
> >> - RB1 ---- RB2 -
> >>   |        |
> >> -  B1 --x-- B2 -
> >>   |        |
> >>   H1       H2
> >>
> >> 1. The network (segment) involved consists of two Rbridges (RB1, RB2),
> two
> >> bridges (B1, B2) and two hosts (H1, H2). They are physically connected
> as
> >> depicted.
> >> 2. State A: the direct link between B1 and B2 is down. B1 and B2 find
> >> themselves on different LAN segments and hence different spanning
> trees. RB1
> >> and RB2 are both designated Rbridges (each for the segment of the
> >> corresponding bridge).
> >> 3. State B: the direct link between B1 and B2 goes up (someone connects
> a
> >> cable). B1 and B2 discover each other and establish a common spanning
> tree.
> >> RB1 and RB2 both find themselves attached to the same LAN segment and
> hence
> >> RB1 (without loss of generality) will eventually become the designated
> >> Rbridge for it.
> >> 4. Just before RB1 and RB2 identify that they are both on the same
> segment
> >> and RB2 stops functioning as a designated Rbridge the following
> scenario
> >> seems possible:
> >>  a. H1 sends a broadcast frame.
> >>  b. B1 receives it and forwards to RB1 and B2.
> >>  c. RB1 (encapsulates and) forwards to RB2.
> >>  d. B2 forwards to RB2 and H2.
> >>  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2 to RB1).
> >>  f. (RB1 forwards to B1.)
> >>  g. B2 forwards (again) to H2 and to B1.
> >>  h. B1 forwards to H1 (see remark below regarding filtering table
> >> contamination) and to RB1.
> >>  i. Etcetera etcetera.
> >> 5. A broadcast storm is born, created by a loop that is not protected
> by TTL
> >> (due to the fact that forwarding between the Rbridges is only across a
> >> single hop) nor by STP (due to the fact that Rbridges do not
> participate in
> >> STP).
> >> 6. If forwarding commences at the hardware level and no broadcast rate
> >> limiting is in place, the storm may cause severe damage in a very short
> time
> >> (note that replicated frames are sent to H1 and H2 (or any network they
> >> could represent).
> >> 7. Another unfortunate effect of this storm is that B1 and B2 no longer
> know
> >> where H1 is located (due to the contamination of their filtering tables
> by a
> >> frame from H1 that arrives from the wrong direction (and in fact from
> >> multiple directions). As a result, a possible unicast frame from H2 to
> H1
> >> will just join the storm over the loop at least in one direction (RB2
> will
> >> forward it to RB1) but will not arrive at H1...
> >>
> >> One possible solution could be for RB2 to identify the fact that it is
> >> receiving a frame from a host with a MAC address that is associated
> with a
> >> segment it thought it isn't connected to. Hence, it may trigger an
> immediate
> >> neighbor discovery / designated Rbridge election. However, because
> Rbridges
> >> should allow host mobility, this frame may need to be forwarded (and
> hence
> >> the storm commences).
> >>
> >> As mentioned above, any comments are welcome.
> >>  Gideon Kaempfer
> >>
> >> _______________________________________________
> >> rbridge mailing list
> >> [e-mail]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>
> >>
> >>
> >
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA38Zr02020903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 3 Nov 2006 00:35:55 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 92D6CE7B58 for <[e-mail]>; Fri,  3 Nov 2006 09:35:52 +0100 (CET)
Received: from [10.0.0.4] (39.Red-80-37-137.staticIP.rima-tde.net [80.37.137.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id E1CECE7B4E for <[e-mail]>; Fri,  3 Nov 2006 09:35:51 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 03 Nov 2006 09:35:49 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <002d01c6fed3$bf109f50$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 08:36:03 -0000
Status: RO
Content-Length: 7354

This comment is just to signal that the behaviour must be analyzed also 
assuming that B1 and B2 execute the (current standard) RSTP protocol.  
There is no forwarding delay in RSTP when the links are dedicated (point 
to point).
If B1 and B2 execute RSTP protocol and B1 has best priority, before  
link B1-B2 being enabled, B2 will block its designated ports  and stop 
forwarding  to RB2.  The process will repeat later  for next stage 
downstream links like B2-RB2 and so on, one level at a time.
The trend is to uses RSTP instead of STP. Root bridge election is likely 
much faster  than DR election. Setting timers at RBridges to stop 
forwarding may be a solution but it slows reconfiguration speed.
Guillermo

Radia Perlman escribi?:
> The simplest way to put it, I think, is that in certain transitory 
> situations there might be two
> RBridges that both think they are Designated RBridge, and that is bad, 
> but should stop
> as soon as a single Hello is received by the RBridge who should not be 
> Designated.
> I think PIM has similar transitory situations that can occur, and 
>   
> bridges can also have (hopefully
> temporary) problems if a repeater came up and merged two LANs. I think 
> such things are
> annoying but not fatal. But I think it's possible we can with little 
> effort avoid this problem.
>
> However, with RBridges, because the bridge spanning tree algorithm 
> elects a Root, there's
> really a way of uniquely identifying a LAN (where "LAN" is a bunch of 
> links connected with
> bridges). The unique identifier is the root bridge.
>   

> When the B1-B2 link is down, RB1 and RB2 will see the topology as two 
> separate links, and each
> one will have a distinct spanning tree Root bridge (RB1 will see B1, and 
> RB2 will see B2 as the root).
>
> When the B1-B2 link comes up, the bridges will first merge the two 
> links, 
> and either RB1 or RB2 will
> see that the bridge spanning tree root has changed. This will be 
> discovered before B1 and B2 forward
> traffic across the link because of the bridge forwarding delay.If B1 has better priority as bridge spanning tree root than B2, then RB1 will not notice anything
> different when the B1-B2 link comes up. But RB2 will notice
> something different; the spanning tree root has changed identities from 
> "B2" to "B1".
> Given this, RB2 could temporarily stop forwarding to or from the link 
> when the Root bridge
> changes identities, though it should definitely immediately send IS-IS 
> Hellos (either RB1 or RB2 will
> be elected Designated Router in the IS-IS election for that link). If 
> RB2 has better prioirty for
> root, the RB1 will immediately stop forwarding to or from the link when 
> it sees the Hello from RB2.
> If RB2 has better priority in the IS-IS election, then RB1 should 
> immediately send an IS-IS Hello
> when it sees a Hello from a new RBridge on the link.
>
> So I think this is not a big deal, and that if we are worried, we can 
> specify that an RBridge should
> stop acting like the Designated RBridge for a few seconds after the 
> identity of the Root in the spanning
> tree algorithm changes.
>
> Or we could be even fancier and have each RBridge announce in its IS-IS 
> Hellos which LAN IDs it
> is Designated for, where a LAN ID is the MAC address of the Root bridge. 
> So RB1 continue
> forwarding if the identity changes from B1 to B2 provided no other 
> RBridge has claimed to be connected
> to B2. But if RB2's LSP claims it is attached to B2, then RB1 must stop 
> forwarding for enough time
> for the IS-IS election to sort itself out and choose a Designated RBridge.
>
> Radia
>
>
>
>
>
>
> Gideon Kaempfer wrote:
>
>   
>> Following mention by Silvano of broadcast and multicast storms (and the need
>> to protect against them), I played around with different scenarios and came
>> upon one I would appreciate your comments on (in the hope I am pointing out
>> a non-existent issue with TRILL). I believe a broadcast and even a unicast
>> storm could be created as the result of a loop that isn't protected by TTL
>> nor by STP in the case of a link connecting two separate LAN segments coming
>> to life.
>>
>> - RB1 ---- RB2 -
>>   |        |
>> -  B1 --x-- B2 -
>>   |        |
>>   H1       H2
>>
>> 1. The network (segment) involved consists of two Rbridges (RB1, RB2), two
>> bridges (B1, B2) and two hosts (H1, H2). They are physically connected as
>> depicted.
>> 2. State A: the direct link between B1 and B2 is down. B1 and B2 find
>> themselves on different LAN segments and hence different spanning trees. RB1
>> and RB2 are both designated Rbridges (each for the segment of the
>> corresponding bridge).
>> 3. State B: the direct link between B1 and B2 goes up (someone connects a
>> cable). B1 and B2 discover each other and establish a common spanning tree.
>> RB1 and RB2 both find themselves attached to the same LAN segment and hence
>> RB1 (without loss of generality) will eventually become the designated
>> Rbridge for it.
>> 4. Just before RB1 and RB2 identify that they are both on the same segment
>> and RB2 stops functioning as a designated Rbridge the following scenario
>> seems possible:
>>  a. H1 sends a broadcast frame.
>>  b. B1 receives it and forwards to RB1 and B2.
>>  c. RB1 (encapsulates and) forwards to RB2.
>>  d. B2 forwards to RB2 and H2.
>>  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2 to RB1).
>>  f. (RB1 forwards to B1.)
>>  g. B2 forwards (again) to H2 and to B1.
>>  h. B1 forwards to H1 (see remark below regarding filtering table
>> contamination) and to RB1.
>>  i. Etcetera etcetera.
>> 5. A broadcast storm is born, created by a loop that is not protected by TTL
>> (due to the fact that forwarding between the Rbridges is only across a
>> single hop) nor by STP (due to the fact that Rbridges do not participate in
>> STP).
>> 6. If forwarding commences at the hardware level and no broadcast rate
>> limiting is in place, the storm may cause severe damage in a very short time
>> (note that replicated frames are sent to H1 and H2 (or any network they
>> could represent).
>> 7. Another unfortunate effect of this storm is that B1 and B2 no longer know
>> where H1 is located (due to the contamination of their filtering tables by a
>> frame from H1 that arrives from the wrong direction (and in fact from
>> multiple directions). As a result, a possible unicast frame from H2 to H1
>> will just join the storm over the loop at least in one direction (RB2 will
>> forward it to RB1) but will not arrive at H1...
>>
>> One possible solution could be for RB2 to identify the fact that it is
>> receiving a frame from a host with a MAC address that is associated with a
>> segment it thought it isn't connected to. Hence, it may trigger an immediate
>> neighbor discovery / designated Rbridge election. However, because Rbridges
>> should allow host mobility, this frame may need to be forwarded (and hence
>> the storm commences).
>>
>> As mentioned above, any comments are welcome.
>>  Gideon Kaempfer
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>  
>>
>>     
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   


Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA36emgn023276 for <[e-mail]>; Thu, 2 Nov 2006 22:40:48 -0800 (PST)
Received: by nf-out-0910.google.com with SMTP id x4so17715nfb for <[e-mail]>; Thu, 02 Nov 2006 22:40:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=I8pZQ/kbxzsIInBJsovVLkthd3exOG5xUBdoNm4v8+lkNrPrgDn6A3ONDvwU5IC6LVfHGUqZnnIlN7nA3e0H0LiKiMEeiNCJp4pkHOV96JpskH8uvqZQgjU/Sgrnn+vmTFYD1d+5tlRAUNKU3MnTOSiVVQm/NnZm0SRwaPV/hII=
Received: by 10.82.107.15 with SMTP id f15mr636039buc.1162536026617; Thu, 02 Nov 2006 22:40:26 -0800 (PST)
Received: by 10.82.159.8 with HTTP; Thu, 2 Nov 2006 22:40:25 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 3 Nov 2006 08:40:25 +0200
From: "Gideon Kaempfer" <[e-mail]>
Sender: [e-mail]
To: "Radia Perlman" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_19928_17478998.1162536025887"
References: <002d01c6fed3$bf109f50$[e-mail]> <[e-mail]>
X-Google-Sender-Auth: 5ca2dda230022dcc
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 06:40:55 -0000
Status: RO
Content-Length: 15685

------=_Part_19928_17478998.1162536025887
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Radia,
Wouldn't this create a link between TRILL and STP we are trying to avoid?
Relying on the fact that a LAN segment has some kind of unique identifier
(such as the root bridge ID) seems like a very practical solution to me, but
strongly reliant on the fact that the Rbridges actually process BPDUs. I
thought they were just meant to discard them. Is this acceptable?
Regrads,
 Gidi


On 11/3/06, Radia Perlman <[e-mail]> wrote:
>
> The simplest way to put it, I think, is that in certain transitory
> situations there might be two
> RBridges that both think they are Designated RBridge, and that is bad,
> but should stop
> as soon as a single Hello is received by the RBridge who should not be
> Designated.
>
> I think PIM has similar transitory situations that can occur, and
> bridges can also have (hopefully
> temporary) problems if a repeater came up and merged two LANs. I think
> such things are
> annoying but not fatal. But I think it's possible we can with little
> effort avoid this problem.
>
> However, with RBridges, because the bridge spanning tree algorithm
> elects a Root, there's
> really a way of uniquely identifying a LAN (where "LAN" is a bunch of
> links connected with
> bridges). The unique identifier is the root bridge.
>
> When the B1-B2 link is down, RB1 and RB2 will see the topology as two
> separate links, and each
> one will have a distinct spanning tree Root bridge (RB1 will see B1, and
> RB2 will see B2 as the root).
>
> When the B1-B2 link comes up, the bridges will first merge the two
> links, and either RB1 or RB2 will
> see that the bridge spanning tree root has changed. This will be
> discovered before B1 and B2 forward
> traffic across the link because of the bridge forwarding delay.
> If B1 has better priority as bridge spanning tree root than B2, then RB1
> will not notice anything
> different when the B1-B2 link comes up. But RB2 will notice
> something different; the spanning tree root has changed identities from
> "B2" to "B1".
>
> Given this, RB2 could temporarily stop forwarding to or from the link
> when the Root bridge
> changes identities, though it should definitely immediately send IS-IS
> Hellos (either RB1 or RB2 will
> be elected Designated Router in the IS-IS election for that link). If
> RB2 has better prioirty for
> root, the RB1 will immediately stop forwarding to or from the link when
> it sees the Hello from RB2.
> If RB2 has better priority in the IS-IS election, then RB1 should
> immediately send an IS-IS Hello
> when it sees a Hello from a new RBridge on the link.
>
> So I think this is not a big deal, and that if we are worried, we can
> specify that an RBridge should
> stop acting like the Designated RBridge for a few seconds after the
> identity of the Root in the spanning
> tree algorithm changes.
>
> Or we could be even fancier and have each RBridge announce in its IS-IS
> Hellos which LAN IDs it
> is Designated for, where a LAN ID is the MAC address of the Root bridge.
> So RB1 continue
> forwarding if the identity changes from B1 to B2 provided no other
> RBridge has claimed to be connected
> to B2. But if RB2's LSP claims it is attached to B2, then RB1 must stop
> forwarding for enough time
> for the IS-IS election to sort itself out and choose a Designated RBridge.
>
> Radia
>
>
>
>
>
>
> Gideon Kaempfer wrote:
>
> >Following mention by Silvano of broadcast and multicast storms (and the
> need
> >to protect against them), I played around with different scenarios and
> came
> >upon one I would appreciate your comments on (in the hope I am pointing
> out
> >a non-existent issue with TRILL). I believe a broadcast and even a
> unicast
> >storm could be created as the result of a loop that isn't protected by
> TTL
> >nor by STP in the case of a link connecting two separate LAN segments
> coming
> >to life.
> >
> >- RB1 ---- RB2 -
> >   |        |
> >-  B1 --x-- B2 -
> >   |        |
> >   H1       H2
> >
> >1. The network (segment) involved consists of two Rbridges (RB1, RB2),
> two
> >bridges (B1, B2) and two hosts (H1, H2). They are physically connected as
> >depicted.
> >2. State A: the direct link between B1 and B2 is down. B1 and B2 find
> >themselves on different LAN segments and hence different spanning trees.
> RB1
> >and RB2 are both designated Rbridges (each for the segment of the
> >corresponding bridge).
> >3. State B: the direct link between B1 and B2 goes up (someone connects a
> >cable). B1 and B2 discover each other and establish a common spanning
> tree.
> >RB1 and RB2 both find themselves attached to the same LAN segment and
> hence
> >RB1 (without loss of generality) will eventually become the designated
> >Rbridge for it.
> >4. Just before RB1 and RB2 identify that they are both on the same
> segment
> >and RB2 stops functioning as a designated Rbridge the following scenario
> >seems possible:
> >  a. H1 sends a broadcast frame.
> >  b. B1 receives it and forwards to RB1 and B2.
> >  c. RB1 (encapsulates and) forwards to RB2.
> >  d. B2 forwards to RB2 and H2.
> >  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2 to RB1).
> >  f. (RB1 forwards to B1.)
> >  g. B2 forwards (again) to H2 and to B1.
> >  h. B1 forwards to H1 (see remark below regarding filtering table
> >contamination) and to RB1.
> >  i. Etcetera etcetera.
> >5. A broadcast storm is born, created by a loop that is not protected by
> TTL
> >(due to the fact that forwarding between the Rbridges is only across a
> >single hop) nor by STP (due to the fact that Rbridges do not participate
> in
> >STP).
> >6. If forwarding commences at the hardware level and no broadcast rate
> >limiting is in place, the storm may cause severe damage in a very short
> time
> >(note that replicated frames are sent to H1 and H2 (or any network they
> >could represent).
> >7. Another unfortunate effect of this storm is that B1 and B2 no longer
> know
> >where H1 is located (due to the contamination of their filtering tables
> by a
> >frame from H1 that arrives from the wrong direction (and in fact from
> >multiple directions). As a result, a possible unicast frame from H2 to H1
> >will just join the storm over the loop at least in one direction (RB2
> will
> >forward it to RB1) but will not arrive at H1...
> >
> >One possible solution could be for RB2 to identify the fact that it is
> >receiving a frame from a host with a MAC address that is associated with
> a
> >segment it thought it isn't connected to. Hence, it may trigger an
> immediate
> >neighbor discovery / designated Rbridge election. However, because
> Rbridges
> >should allow host mobility, this frame may need to be forwarded (and
> hence
> >the storm commences).
> >
> >As mentioned above, any comments are welcome.
> >  Gideon Kaempfer
> >
> >_______________________________________________
> >rbridge mailing list
> >[e-mail]
> >http://mailman.postel.org/mailman/listinfo/rbridge
> >
> >
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>

------=_Part_19928_17478998.1162536025887
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div>Radia,</div>
<div>Wouldn't this create a link between TRILL and STP we are trying to avoid?</div>
<div>Relying on the fact that a LAN segment has some kind of unique identifier (such as the root bridge ID) seems like a very practical solution to me, but strongly reliant on the fact that the Rbridges actually process BPDUs. I thought they were just meant to discard them. Is this acceptable?
</div>
<div>Regrads,</div>
<div>&nbsp;Gidi<br><br>&nbsp;</div>
<div><span class="gmail_quote">On 11/3/06, <b class="gmail_sendername">Radia Perlman</b> &lt;<a href="mailto:[e-mail]">[e-mail]</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">The simplest way to put it, I think, is that in certain transitory<br>situations there might be two<br>RBridges that both think they are Designated RBridge, and that is bad,
<br>but should stop<br>as soon as a single Hello is received by the RBridge who should not be<br>Designated.<br><br>I think PIM has similar transitory situations that can occur, and<br>bridges can also have (hopefully<br>
temporary) problems if a repeater came up and merged two LANs. I think<br>such things are<br>annoying but not fatal. But I think it's possible we can with little<br>effort avoid this problem.<br><br>However, with RBridges, because the bridge spanning tree algorithm
<br>elects a Root, there's<br>really a way of uniquely identifying a LAN (where &quot;LAN&quot; is a bunch of<br>links connected with<br>bridges). The unique identifier is the root bridge.<br><br>When the B1-B2 link is down, RB1 and RB2 will see the topology as two
<br>separate links, and each<br>one will have a distinct spanning tree Root bridge (RB1 will see B1, and<br>RB2 will see B2 as the root).<br><br>When the B1-B2 link comes up, the bridges will first merge the two<br>links, and either RB1 or RB2 will
<br>see that the bridge spanning tree root has changed. This will be<br>discovered before B1 and B2 forward<br>traffic across the link because of the bridge forwarding delay.<br>If B1 has better priority as bridge spanning tree root than B2, then RB1
<br>will not notice anything<br>different when the B1-B2 link comes up. But RB2 will notice<br>something different; the spanning tree root has changed identities from<br>&quot;B2&quot; to &quot;B1&quot;.<br><br>Given this, RB2 could temporarily stop forwarding to or from the link
<br>when the Root bridge<br>changes identities, though it should definitely immediately send IS-IS<br>Hellos (either RB1 or RB2 will<br>be elected Designated Router in the IS-IS election for that link). If<br>RB2 has better prioirty for
<br>root, the RB1 will immediately stop forwarding to or from the link when<br>it sees the Hello from RB2.<br>If RB2 has better priority in the IS-IS election, then RB1 should<br>immediately send an IS-IS Hello<br>when it sees a Hello from a new RBridge on the link.
<br><br>So I think this is not a big deal, and that if we are worried, we can<br>specify that an RBridge should<br>stop acting like the Designated RBridge for a few seconds after the<br>identity of the Root in the spanning
<br>tree algorithm changes.<br><br>Or we could be even fancier and have each RBridge announce in its IS-IS<br>Hellos which LAN IDs it<br>is Designated for, where a LAN ID is the MAC address of the Root bridge.<br>So RB1 continue
<br>forwarding if the identity changes from B1 to B2 provided no other<br>RBridge has claimed to be connected<br>to B2. But if RB2's LSP claims it is attached to B2, then RB1 must stop<br>forwarding for enough time<br>for the IS-IS election to sort itself out and choose a Designated RBridge.
<br><br>Radia<br><br><br><br><br><br><br>Gideon Kaempfer wrote:<br><br>&gt;Following mention by Silvano of broadcast and multicast storms (and the need<br>&gt;to protect against them), I played around with different scenarios and came
<br>&gt;upon one I would appreciate your comments on (in the hope I am pointing out<br>&gt;a non-existent issue with TRILL). I believe a broadcast and even a unicast<br>&gt;storm could be created as the result of a loop that isn't protected by TTL
<br>&gt;nor by STP in the case of a link connecting two separate LAN segments coming<br>&gt;to life.<br>&gt;<br>&gt;- RB1 ---- RB2 -<br>&gt;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br>&gt;-&nbsp;&nbsp;B1 --x-- B2 -<br>&gt;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br>&gt;&nbsp;&nbsp; H1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; H2<br>
&gt;<br>&gt;1. The network (segment) involved consists of two Rbridges (RB1, RB2), two<br>&gt;bridges (B1, B2) and two hosts (H1, H2). They are physically connected as<br>&gt;depicted.<br>&gt;2. State A: the direct link between B1 and B2 is down. B1 and B2 find
<br>&gt;themselves on different LAN segments and hence different spanning trees. RB1<br>&gt;and RB2 are both designated Rbridges (each for the segment of the<br>&gt;corresponding bridge).<br>&gt;3. State B: the direct link between B1 and B2 goes up (someone connects a
<br>&gt;cable). B1 and B2 discover each other and establish a common spanning tree.<br>&gt;RB1 and RB2 both find themselves attached to the same LAN segment and hence<br>&gt;RB1 (without loss of generality) will eventually become the designated
<br>&gt;Rbridge for it.<br>&gt;4. Just before RB1 and RB2 identify that they are both on the same segment<br>&gt;and RB2 stops functioning as a designated Rbridge the following scenario<br>&gt;seems possible:<br>&gt;&nbsp;&nbsp;a. H1 sends a broadcast frame.
<br>&gt;&nbsp;&nbsp;b. B1 receives it and forwards to RB1 and B2.<br>&gt;&nbsp;&nbsp;c. RB1 (encapsulates and) forwards to RB2.<br>&gt;&nbsp;&nbsp;d. B2 forwards to RB2 and H2.<br>&gt;&nbsp;&nbsp;e. RB2 forwards the copy from RB1 to B2 (and the copy from B2 to RB1).
<br>&gt;&nbsp;&nbsp;f. (RB1 forwards to B1.)<br>&gt;&nbsp;&nbsp;g. B2 forwards (again) to H2 and to B1.<br>&gt;&nbsp;&nbsp;h. B1 forwards to H1 (see remark below regarding filtering table<br>&gt;contamination) and to RB1.<br>&gt;&nbsp;&nbsp;i. Etcetera etcetera.
<br>&gt;5. A broadcast storm is born, created by a loop that is not protected by TTL<br>&gt;(due to the fact that forwarding between the Rbridges is only across a<br>&gt;single hop) nor by STP (due to the fact that Rbridges do not participate in
<br>&gt;STP).<br>&gt;6. If forwarding commences at the hardware level and no broadcast rate<br>&gt;limiting is in place, the storm may cause severe damage in a very short time<br>&gt;(note that replicated frames are sent to H1 and H2 (or any network they
<br>&gt;could represent).<br>&gt;7. Another unfortunate effect of this storm is that B1 and B2 no longer know<br>&gt;where H1 is located (due to the contamination of their filtering tables by a<br>&gt;frame from H1 that arrives from the wrong direction (and in fact from
<br>&gt;multiple directions). As a result, a possible unicast frame from H2 to H1<br>&gt;will just join the storm over the loop at least in one direction (RB2 will<br>&gt;forward it to RB1) but will not arrive at H1...<br>
&gt;<br>&gt;One possible solution could be for RB2 to identify the fact that it is<br>&gt;receiving a frame from a host with a MAC address that is associated with a<br>&gt;segment it thought it isn't connected to. Hence, it may trigger an immediate
<br>&gt;neighbor discovery / designated Rbridge election. However, because Rbridges<br>&gt;should allow host mobility, this frame may need to be forwarded (and hence<br>&gt;the storm commences).<br>&gt;<br>&gt;As mentioned above, any comments are welcome.
<br>&gt;&nbsp;&nbsp;Gideon Kaempfer<br>&gt;<br>&gt;_______________________________________________<br>&gt;rbridge mailing list<br>&gt;<a href="mailto:[e-mail]">[e-mail]</a><br>&gt;<a href="http://mailman.postel.org/mailman/listinfo/rbridge">
http://mailman.postel.org/mailman/listinfo/rbridge</a><br>&gt;<br>&gt;<br><br>_______________________________________________<br>rbridge mailing list<br><a href="mailto:[e-mail]">[e-mail]</a><br><a href="http://mailman.postel.org/mailman/listinfo/rbridge">
http://mailman.postel.org/mailman/listinfo/rbridge</a><br></blockquote></div><br>

------=_Part_19928_17478998.1162536025887--


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA36PBiR018502 for <[e-mail]>; Thu, 2 Nov 2006 22:25:11 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 02 Nov 2006 22:25:07 -0800 (PST)
Received: from sun.com ([129.150.22.255]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Thu, 02 Nov 2006 22:25:07 -0800 (PST)
Date: Thu, 02 Nov 2006 22:25:06 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <002d01c6fed3$bf109f50$[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <002d01c6fed3$bf109f50$[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 06:25:24 -0000
Status: RO
Content-Length: 6193

The simplest way to put it, I think, is that in certain transitory 
situations there might be two
RBridges that both think they are Designated RBridge, and that is bad, 
but should stop
as soon as a single Hello is received by the RBridge who should not be 
Designated.

I think PIM has similar transitory situations that can occur, and 
bridges can also have (hopefully
temporary) problems if a repeater came up and merged two LANs. I think 
such things are
annoying but not fatal. But I think it's possible we can with little 
effort avoid this problem.

However, with RBridges, because the bridge spanning tree algorithm 
elects a Root, there's
really a way of uniquely identifying a LAN (where "LAN" is a bunch of 
links connected with
bridges). The unique identifier is the root bridge.

When the B1-B2 link is down, RB1 and RB2 will see the topology as two 
separate links, and each
one will have a distinct spanning tree Root bridge (RB1 will see B1, and 
RB2 will see B2 as the root).

When the B1-B2 link comes up, the bridges will first merge the two 
links, and either RB1 or RB2 will
see that the bridge spanning tree root has changed. This will be 
discovered before B1 and B2 forward
traffic across the link because of the bridge forwarding delay.
If B1 has better priority as bridge spanning tree root than B2, then RB1 
will not notice anything
different when the B1-B2 link comes up. But RB2 will notice
something different; the spanning tree root has changed identities from 
"B2" to "B1".

Given this, RB2 could temporarily stop forwarding to or from the link 
when the Root bridge
changes identities, though it should definitely immediately send IS-IS 
Hellos (either RB1 or RB2 will
be elected Designated Router in the IS-IS election for that link). If 
RB2 has better prioirty for
root, the RB1 will immediately stop forwarding to or from the link when 
it sees the Hello from RB2.
If RB2 has better priority in the IS-IS election, then RB1 should 
immediately send an IS-IS Hello
when it sees a Hello from a new RBridge on the link.

So I think this is not a big deal, and that if we are worried, we can 
specify that an RBridge should
stop acting like the Designated RBridge for a few seconds after the 
identity of the Root in the spanning
tree algorithm changes.

Or we could be even fancier and have each RBridge announce in its IS-IS 
Hellos which LAN IDs it
is Designated for, where a LAN ID is the MAC address of the Root bridge. 
So RB1 continue
forwarding if the identity changes from B1 to B2 provided no other 
RBridge has claimed to be connected
to B2. But if RB2's LSP claims it is attached to B2, then RB1 must stop 
forwarding for enough time
for the IS-IS election to sort itself out and choose a Designated RBridge.

Radia






Gideon Kaempfer wrote:

>Following mention by Silvano of broadcast and multicast storms (and the need
>to protect against them), I played around with different scenarios and came
>upon one I would appreciate your comments on (in the hope I am pointing out
>a non-existent issue with TRILL). I believe a broadcast and even a unicast
>storm could be created as the result of a loop that isn't protected by TTL
>nor by STP in the case of a link connecting two separate LAN segments coming
>to life.
>
>- RB1 ---- RB2 -
>   |        |
>-  B1 --x-- B2 -
>   |        |
>   H1       H2
>
>1. The network (segment) involved consists of two Rbridges (RB1, RB2), two
>bridges (B1, B2) and two hosts (H1, H2). They are physically connected as
>depicted.
>2. State A: the direct link between B1 and B2 is down. B1 and B2 find
>themselves on different LAN segments and hence different spanning trees. RB1
>and RB2 are both designated Rbridges (each for the segment of the
>corresponding bridge).
>3. State B: the direct link between B1 and B2 goes up (someone connects a
>cable). B1 and B2 discover each other and establish a common spanning tree.
>RB1 and RB2 both find themselves attached to the same LAN segment and hence
>RB1 (without loss of generality) will eventually become the designated
>Rbridge for it.
>4. Just before RB1 and RB2 identify that they are both on the same segment
>and RB2 stops functioning as a designated Rbridge the following scenario
>seems possible:
>  a. H1 sends a broadcast frame.
>  b. B1 receives it and forwards to RB1 and B2.
>  c. RB1 (encapsulates and) forwards to RB2.
>  d. B2 forwards to RB2 and H2.
>  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2 to RB1).
>  f. (RB1 forwards to B1.)
>  g. B2 forwards (again) to H2 and to B1.
>  h. B1 forwards to H1 (see remark below regarding filtering table
>contamination) and to RB1.
>  i. Etcetera etcetera.
>5. A broadcast storm is born, created by a loop that is not protected by TTL
>(due to the fact that forwarding between the Rbridges is only across a
>single hop) nor by STP (due to the fact that Rbridges do not participate in
>STP).
>6. If forwarding commences at the hardware level and no broadcast rate
>limiting is in place, the storm may cause severe damage in a very short time
>(note that replicated frames are sent to H1 and H2 (or any network they
>could represent).
>7. Another unfortunate effect of this storm is that B1 and B2 no longer know
>where H1 is located (due to the contamination of their filtering tables by a
>frame from H1 that arrives from the wrong direction (and in fact from
>multiple directions). As a result, a possible unicast frame from H2 to H1
>will just join the storm over the loop at least in one direction (RB2 will
>forward it to RB1) but will not arrive at H1...
>
>One possible solution could be for RB2 to identify the fact that it is
>receiving a frame from a host with a MAC address that is associated with a
>segment it thought it isn't connected to. Hence, it may trigger an immediate
>neighbor discovery / designated Rbridge election. However, because Rbridges
>should allow host mobility, this frame may need to be forwarded (and hence
>the storm commences).
>
>As mentioned above, any comments are welcome.
>  Gideon Kaempfer
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>



Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA36Ltc2017088 for <[e-mail]>; Thu, 2 Nov 2006 22:21:55 -0800 (PST)
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 02 Nov 2006 22:21:56 -0800
X-IronPort-AV: i="4.09,383,1157353200";  d="scan'208"; a="754238351:sNHT53788120"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA36Ltbo014778; Thu, 2 Nov 2006 22:21:55 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA36LtW4024977; Thu, 2 Nov 2006 22:21:55 -0800 (PST)
Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Nov 2006 22:21:55 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 2 Nov 2006 22:21:52 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] LIDs
Thread-Index: Acby4lFXsEqxu94iRvehpH6TvWktDQAD3QvAAwQ1XmA=
From: "Larry Kreeger \(kreeger\)" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>, "Erik Nordmark" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 03 Nov 2006 06:21:55.0103 (UTC) FILETIME=[5BC7FAF0:01C6FF10]
DKIM-Signature: a=rsa-sha1; q=dns; l=3028; t=1162534915; x=1163398915; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=22Larry=20Kreeger=20\(kreeger\)=22=20<[e-mail]> |Subject:RE=3A=20[rbridge]=20LIDs; X=v=3Dcisco.com=3B=20h=3DVQQgirXyliGfNg3+e0DNukZB8Bo=3D; b=Z2iL6KaM/UwPg+TCzAlbRzvepDutYFljjQFbaA2WCdLQjHulMKxddhT4PGpqXO3c4Xwq2pUB 4M6pbWx5WnlMnhWfEX4oOpHkdjLE1iWHumL7RGKUiofqKltLQ5OEte4k;
Authentication-Results: sj-dkim-1.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA36Ltc2017088
Cc: [e-mail]
Subject: Re: [rbridge] LIDs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 06:22:26 -0000
Status: RO
Content-Length: 2925

Hi,

I was catching up on old RBridge threads and saw this one about LIDs.

LIDs can be useful in reducing costs in large switches where the entire
(potentially large) local MAC table would not need to be present in
every module of the system.  In fact it could probably eliminate the
need to keep locally learned MACs in hardware at all.  Assuming a switch
with 16 slots and 48 ports per linecard, and servers running 16 virtual
machines each connected to the ports, the number of local MACs would be
16*48*16= 12,288.  With 48 bits per address, that is ~59kbits.

With LIDs, an entry is need only per port, not per local MAC.  So given
a 16 bit LID, only 16 cards * 48 ports * 16 bits = ~12kbits, a savings
of ~47kbits.

The more locally attached MACs, the bigger the savings.

  - Larry
 
Caitlin Bestler wrote on Wednesday, October 18, 2006 1:19 PM:

> Erik Nordmark wrote:
>> Radia Perlman wrote:
>> 
>>> We haven't discussed the LID fields. Perhaps that should be a
>>> different thread. Since that doesn't affect forwarding, and is only
>>> a convenience to the egress RBridge, that doesn't seem too
>>> compelling. The ingress RBridge has to do the lookup per endnode,
>>> so it's only at most twice as much computation for a Designated
>>> RBridge to have to do the lookup both when a packet leaves its link
>>> and when it enters. 
>> 
>> If we are trying to squeeze bits and see a need for a LID capability,
>> it might make sense to allow different egress rbridges have different
>> number of LID bits - they only need to number their ports so in some
>> cases few bits would be sufficient.
>> 
>> Assuming we have a 19 bit space for RBridge alias plus LID, then an
>> rbridge with 16 ports would ask for an alias that is 19-4=15 bits.
>> 
>> The downside of such an approach is that the alias setup would need
>> to be able to handle variable length aliases, and the transit
>> rbridges would either need variable length matching on the RBridge
>> alias, or expand out to all the matching 19 bit patterns and have
>> the hardware do full 19 bit matches. For instance, the above 15 bit
>> alias would expand to 16 different matches on 19 bits.
>> 
>>     Erik
> 
> Bitmask aliasing an RBridge ID has the same potential uses as LID
> aliasing for InfiniBand, and the same complexities. 
> 
> My generate comment on the LID is that it is only worth considering
> if it can be multiplexed with the RBridge ID. Otherwise you are
> replacing an egress RBridge table [local mac-->local port] by having
> having more data in the ingress RBridge table [remote mac-->remote
> rbridge + LID]. I'm not certain that it really reduces the amount of
> memory, and given the likely size of the [local mac-->local port]
> table I don't think it improves latency.      
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id kA32dtqt018073 for <[e-mail]>; Thu, 2 Nov 2006 18:39:55 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-15.tower-119.messagelabs.com!1162521434!12398142!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 9036 invoked from network); 3 Nov 2006 02:37:14 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-119.messagelabs.com with SMTP; 3 Nov 2006 02:37:14 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id kA32bAnj024557 for <[e-mail]>; Thu, 2 Nov 2006 19:37:14 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id kA32b9HE003510 for <[e-mail]>; Thu, 2 Nov 2006 20:37:09 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 2 Nov 2006 21:37:07 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Last Call question
thread-index: Acb+5Ez1jVJShYegSVaMLt+sjiclvAAC1TIg
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA32dtqt018073
Subject: Re: [rbridge] Last Call question
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 02:40:20 -0000
Status: RO
Content-Length: 2171

Hi Dinesh,

I am unaware of any rule which prohibits a working group last call under
these circumstances.

One major purpose of a working group last call is to solicit comments.
If comments were received which resolved all these items and any other
issues in a way which had consensus then, after the conclusion of the
last call, these comments could be incorporated into the draft and it
could be forwarded to the IESG. If there are unresolved issues, then the
draft should be improved as far as possible based on the feedback
received and be subject to further work within the working group.

Thanks,
Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Dinesh G Dutt
Sent: Thursday, November 02, 2006 8:01 PM
To: [e-mail]
Subject: [rbridge] Last Call question

Folks,

Can we do a last call on document: 
http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-01.txt
when the document contains sections such as the following:

    [QUESTION: What is the timescale? O(# bridges)? O(#links?), etc? on
    report is that "I have heard things said that imply that the worst
    case RSTP settling time is related to 3 times the network diameter,
    where diameter is the maximum of the minimum number of hops between
    all pairs of nodes." - if anyone has a more specific reference,
    please provide one]


    [JUST CHECKING - OR AM I MISREADING WHAT
    802.1V DOES?]

    [we need pictures here; to appear]

    [NOTE: this might be omitted, as it has not been shown to be a
    problem with STP].

    [NOTE: need to say more here.]

    [Need a ref for the router-router 'igmp' protocol]

    [need a ref for secure ipv6 nd]

    7. Conclusions

    (TBA)

I haven't been following up the thread with Silvano's comments and I
apologize if I'm posting something that has already been discussed.

Dinesh

--
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan
_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA32c2X2017420 for <[e-mail]>; Thu, 2 Nov 2006 18:38:02 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 2 Nov 2006 18:37:59 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Traffic storms
Thread-Index: Acb+07otf1I2/4myTNaem613g1ekZgAHGtrA
From: "Silvano Gai" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA32c2X2017420
Subject: Re: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 02:38:17 -0000
Status: RO
Content-Length: 4335

Gideon,

You hit the nail on the head; this is one of the many examples in which
the current TRILL proposal will generate Broadcast Storm that will crash
any network.

This is the reason why, if we don't solve the Broadcast Storm, TRILL is
unusable and there is no point in building products.

I think we need to start to discuss possible solutions, since this can
influence also other aspects of the design.

Unfortunately I am more pessimistic than you: I think that TTL help very
little for Broadcast, since Broadcast replicate in HW. When TTL kicks
in, the storm has already happened.

-- Silvano




> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Gideon Kaempfer
> Sent: Thursday, November 02, 2006 3:08 PM
> To: [e-mail]
> Subject: [rbridge] Traffic storms
> 
> Following mention by Silvano of broadcast and multicast storms (and
the
> need
> to protect against them), I played around with different scenarios and
> came
> upon one I would appreciate your comments on (in the hope I am
pointing
> out
> a non-existent issue with TRILL). I believe a broadcast and even a
unicast
> storm could be created as the result of a loop that isn't protected by
TTL
> nor by STP in the case of a link connecting two separate LAN segments
> coming
> to life.
> 
> - RB1 ---- RB2 -
>    |        |
> -  B1 --x-- B2 -
>    |        |
>    H1       H2
> 
> 1. The network (segment) involved consists of two Rbridges (RB1, RB2),
two
> bridges (B1, B2) and two hosts (H1, H2). They are physically connected
as
> depicted.
> 2. State A: the direct link between B1 and B2 is down. B1 and B2 find
> themselves on different LAN segments and hence different spanning
trees.
> RB1
> and RB2 are both designated Rbridges (each for the segment of the
> corresponding bridge).
> 3. State B: the direct link between B1 and B2 goes up (someone
connects a
> cable). B1 and B2 discover each other and establish a common spanning
> tree.
> RB1 and RB2 both find themselves attached to the same LAN segment and
> hence
> RB1 (without loss of generality) will eventually become the designated
> Rbridge for it.
> 4. Just before RB1 and RB2 identify that they are both on the same
segment
> and RB2 stops functioning as a designated Rbridge the following
scenario
> seems possible:
>   a. H1 sends a broadcast frame.
>   b. B1 receives it and forwards to RB1 and B2.
>   c. RB1 (encapsulates and) forwards to RB2.
>   d. B2 forwards to RB2 and H2.
>   e. RB2 forwards the copy from RB1 to B2 (and the copy from B2 to
RB1).
>   f. (RB1 forwards to B1.)
>   g. B2 forwards (again) to H2 and to B1.
>   h. B1 forwards to H1 (see remark below regarding filtering table
> contamination) and to RB1.
>   i. Etcetera etcetera.
> 5. A broadcast storm is born, created by a loop that is not protected
by
> TTL
> (due to the fact that forwarding between the Rbridges is only across a
> single hop) nor by STP (due to the fact that Rbridges do not
participate
> in
> STP).
> 6. If forwarding commences at the hardware level and no broadcast rate
> limiting is in place, the storm may cause severe damage in a very
short
> time
> (note that replicated frames are sent to H1 and H2 (or any network
they
> could represent).
> 7. Another unfortunate effect of this storm is that B1 and B2 no
longer
> know
> where H1 is located (due to the contamination of their filtering
tables by
> a
> frame from H1 that arrives from the wrong direction (and in fact from
> multiple directions). As a result, a possible unicast frame from H2 to
H1
> will just join the storm over the loop at least in one direction (RB2
will
> forward it to RB1) but will not arrive at H1...
> 
> One possible solution could be for RB2 to identify the fact that it is
> receiving a frame from a host with a MAC address that is associated
with a
> segment it thought it isn't connected to. Hence, it may trigger an
> immediate
> neighbor discovery / designated Rbridge election. However, because
> Rbridges
> should allow host mobility, this frame may need to be forwarded (and
hence
> the storm commences).
> 
> As mentioned above, any comments are welcome.
>   Gideon Kaempfer
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA32SmH2014520 for <[e-mail]>; Thu, 2 Nov 2006 18:28:48 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 2 Nov 2006 18:28:45 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] SPF verses STP, straight across the board
Thread-Index: Acb+z56NaVnQz1lwR1OzEgDU8DdF3gAHlt3w
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA32SmH2014520
Subject: Re: [rbridge] SPF verses STP, straight across the board
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 02:29:18 -0000
Status: RO
Content-Length: 1900

Suppose that we have 5 RBridges, R1 to R5 and that R2 and R4 are
requesting a tree.

All the RBridges have the same LSA database propagated by ISIS.
They use Djikstra for the unicast core instance, putting themselves as
the root.

Then they also run two other instances of Djikstra, one using R2 as root
and one using R4 as root. As a result they put some port in forwarding
state and some in blocking state. Basically they compute 2 spanning
trees, one rooted in R2 (let's call it T2) and one rooted in R4 (T4),
without using the spanning tree protocol.

Each ingress RBridge can send multicast, broadcast and flooded frames
either on T2 or T4. It indicates its decision on the FTAG, which is
honored by all the other RBridges.

In this way the customer can get Shortest Path and also load balancing,
depending where he/she roots the trees. For example, in Fat Tree
networks, if you root the trees in the core, you get both.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Gray, Eric
> Sent: Thursday, November 02, 2006 2:34 PM
> To: [e-mail]
> Subject: [rbridge] SPF verses STP, straight across the board
> 
> 
> There appears to be a late-blooming source of confusion relative to
> multicast, broadcast and flooded frame forwarding among RBridges.
> 
> The question is - do the concerns about efficient link utilization
> via the use of SPF routing apply to multicast, broadcast and flooded
> traffic (as they do to unicast traffic), or do we simply use some
> variation of STP to determine "spanning trees" for the non-unicast
> case?
> 
> I've been under the impression that the intention is to use SPF
> routing, straight across the board.
> 
> --
> Eric
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA310j5X017950 for <[e-mail]>; Thu, 2 Nov 2006 17:00:45 -0800 (PST)
Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 02 Nov 2006 17:00:43 -0800
X-IronPort-AV: i="4.09,382,1157353200";  d="scan'208"; a="338968661:sNHT46478664"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA310hRk017466 for <[e-mail]>; Thu, 2 Nov 2006 17:00:43 -0800
Received: from [171.71.49.48] (dhcp-171-71-49-48.cisco.com [171.71.49.48]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA310hbF023551 for <[e-mail]>; Thu, 2 Nov 2006 17:00:43 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 02 Nov 2006 17:00:42 -0800
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0b1pre (X11/20061028)
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=1235; t=1162515643; x=1163379643; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:Dinesh=20G=20Dutt=20<[e-mail]> |Subject:Last=20Call=20question; X=v=3Dcisco.com=3B=20h=3D5jSl0fn86KraxzUV1pZEoUhzZSY=3D; b=oGNfj08DoKJyusJqHdQ/IT0oklQ9IEy7oGAqwnXk9tbXSbhsZJQgWo3WxuJYCBqjwkhdX82F SOq4mkgbHRHCnPoLxl4sQnZHbTeIrD6KpC2rhfTnSR21cDqAbHaf+WW0;
Authentication-Results: sj-dkim-7.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Last Call question
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2006 01:01:15 -0000
Status: RO
Content-Length: 1195

Folks,

Can we do a last call on document: 
http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-01.txt
when the document contains sections such as the following:

    [QUESTION: What is the timescale? O(# bridges)? O(#links?), etc? on
    report is that "I have heard things said that imply that the worst
    case RSTP settling time is related to 3 times the network diameter,
    where diameter is the maximum of the minimum number of hops between
    all pairs of nodes." - if anyone has a more specific reference,
    please provide one]


    [JUST CHECKING - OR AM I MISREADING WHAT
    802.1V DOES?]

    [we need pictures here; to appear]

    [NOTE: this might be omitted, as it has not been shown to be a
    problem with STP].

    [NOTE: need to say more here.]

    [Need a ref for the router-router 'igmp' protocol]

    [need a ref for secure ipv6 nd]

    7. Conclusions

    (TBA)

I haven't been following up the thread with Silvano's comments and I 
apologize if I'm posting something that has already been discussed.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan


Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA2NALwO014168 for <[e-mail]>; Thu, 2 Nov 2006 15:10:21 -0800 (PST)
Received: by nf-out-0910.google.com with SMTP id x4so1048045nfb for <[e-mail]>; Thu, 02 Nov 2006 15:10:20 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:reply-to:from:to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:x-mimeole:sender; b=ntPuPPWB8PIno7XGRe5yfsp+g5CAIeSfbLyAwH+7Ss5YkgE2Jqz13eHZIptK5onqMC0/J57ZSmiEc3tfDIdYMURIh3XThEtflJfHMhRIWL22TRXJVHrloUhib2XzxlKJ0bf+eCSQ1mHPQ3ao8D4xPFjFl90oW8NvZxnlQ9hG4Q4=
Received: by 10.49.12.4 with SMTP id p4mr145934nfi.1162509020452; Thu, 02 Nov 2006 15:10:20 -0800 (PST)
Received: from wxpgidi ( [212.235.106.113]) by mx.google.com with ESMTP id b1sm732717nfe.2006.11.02.15.10.19; Thu, 02 Nov 2006 15:10:20 -0800 (PST)
From: "Gideon Kaempfer" <[e-mail]>
To: <[e-mail]>
Date: Fri, 3 Nov 2006 01:07:54 +0200
Message-ID: <002d01c6fed3$bf109f50$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acb+07otf1I2/4myTNaem613g1ekZg==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Sender: Gideon Kaempfer <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Traffic storms
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail]
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 02 Nov 2006 23:11:21 -0000
Status: RO
Content-Length: 3186

Following mention by Silvano of broadcast and multicast storms (and the need
to protect against them), I played around with different scenarios and came
upon one I would appreciate your comments on (in the hope I am pointing out
a non-existent issue with TRILL). I believe a broadcast and even a unicast
storm could be created as the result of a loop that isn't protected by TTL
nor by STP in the case of a link connecting two separate LAN segments coming
to life.

- RB1 ---- RB2 -
   |        |
-  B1 --x-- B2 -
   |        |
   H1       H2

1. The network (segment) involved consists of two Rbridges (RB1, RB2), two
bridges (B1, B2) and two hosts (H1, H2). They are physically connected as
depicted.
2. State A: the direct link between B1 and B2 is down. B1 and B2 find
themselves on different LAN segments and hence different spanning trees. RB1
and RB2 are both designated Rbridges (each for the segment of the
corresponding bridge).
3. State B: the direct link between B1 and B2 goes up (someone connects a
cable). B1 and B2 discover each other and establish a common spanning tree.
RB1 and RB2 both find themselves attached to the same LAN segment and hence
RB1 (without loss of generality) will eventually become the designated
Rbridge for it.
4. Just before RB1 and RB2 identify that they are both on the same segment
and RB2 stops functioning as a designated Rbridge the following scenario
seems possible:
  a. H1 sends a broadcast frame.
  b. B1 receives it and forwards to RB1 and B2.
  c. RB1 (encapsulates and) forwards to RB2.
  d. B2 forwards to RB2 and H2.
  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2 to RB1).
  f. (RB1 forwards to B1.)
  g. B2 forwards (again) to H2 and to B1.
  h. B1 forwards to H1 (see remark below regarding filtering table
contamination) and to RB1.
  i. Etcetera etcetera.
5. A broadcast storm is born, created by a loop that is not protected by TTL
(due to the fact that forwarding between the Rbridges is only across a
single hop) nor by STP (due to the fact that Rbridges do not participate in
STP).
6. If forwarding commences at the hardware level and no broadcast rate
limiting is in place, the storm may cause severe damage in a very short time
(note that replicated frames are sent to H1 and H2 (or any network they
could represent).
7. Another unfortunate effect of this storm is that B1 and B2 no longer know
where H1 is located (due to the contamination of their filtering tables by a
frame from H1 that arrives from the wrong direction (and in fact from
multiple directions). As a result, a possible unicast frame from H2 to H1
will just join the storm over the loop at least in one direction (RB2 will
forward it to RB1) but will not arrive at H1...

One possible solution could be for RB2 to identify the fact that it is
receiving a frame from a host with a MAC address that is associated with a
segment it thought it isn't connected to. Hence, it may trigger an immediate
neighbor discovery / designated Rbridge election. However, because Rbridges
should allow host mobility, this frame may need to be forwarded (and hence
the storm commences).

As mentioned above, any comments are welcome.
  Gideon Kaempfer



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA2MhuGC004156 for <[e-mail]>; Thu, 2 Nov 2006 14:43:56 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA2MhqfK020197; Thu, 2 Nov 2006 17:43:52 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA19357;  Thu, 2 Nov 2006 17:43:52 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB648HJJ>; Thu, 2 Nov 2006 17:43:51 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Caitlin Bestler <[e-mail]>
Date: Thu, 2 Nov 2006 17:43:42 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] On Nick-Names
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 02 Nov 2006 22:44:10 -0000
Status: RO
Content-Length: 2213

Caitlin,

	Anything more explicit than "it magically happens" would
be an improvement.  However, disadvantages in what you suggest
include the "new" requirement for persistent storage (this is
not implicit in typical plug and play hardware), and the fact
that we might have to be pretty explicit about when we require
this to happen (i.e. - at what point can other implementations
assume this has been done?).

--
Eric

--> -----Original Message-----
--> From: Caitlin Bestler [mailto:[e-mail]] 
--> Sent: Thursday, November 02, 2006 5:37 PM
--> To: Gray, Eric; Eastlake III Donald-LDE008
--> Cc: [e-mail]; Radia Perlman
--> Subject: RE: [rbridge] On Nick-Names
--> 
--> [e-mail] wrote:
--> > Donald,
--> > 
--> > 	Yes, this sounds familiar.  There are issues with this
--> > negotiation approach, however.  For example, because it is
--> > non-determinstic, some of the assumptions in this text are
--> > either incorrect, or subject to race-conditions.
--> > 
--> > 	For example, the statement "once it is stable,
--> > nicknames should remain stable even as routers go up or down"
--> > appears to either assume that a nick-name is presistent
--> > across a system's reset/reboot, or assume that this approach
--> > will (somehow) result in selecting the same nick-names again.
--> > 
--> > 	Also, the statement "To minimize the probability of a
--> > new RBridge usurping a nickname already in use, an RBridge
--> > should wait to acquire the link state database from a
--> > neighbor before it announces its own nickname" seems to have
--> > built-in difficulty in boot-strapping.  Exactly _how_ does
--> > this occur without the possibility of two devices each
--> > believing the other is the one doing the "usurping"?
--> > 
--> > 	I am also very uncomfortable with the idea of allowing
--> > any implementation choice possible, for nick-name selection,
--> > to be used, under the assumption that convergence will
--> > eventually happen, and that persistant nick-names will be a
--> > natural result of this chaotic assumption.
--> > 
--> Why not explicitly state that an RBridge SHOULD use its
--> prior nick-name as its first choice after a reset/reboot?
--> 


Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA2MbJZS001634 for <[e-mail]>; Thu, 2 Nov 2006 14:37:19 -0800 (PST)
Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Thu, 02 Nov 2006 14:36:58 -0800
X-Server-Uuid: 05DA3F36-9AA8-4766-A7E5-53B43A7C42E6
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 5D1112B0; Thu, 2 Nov 2006 14:36:58 -0800 (PST)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 35A2D2AF; Thu, 2 Nov 2006 14:36:58 -0800 (PST)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EJV74338; Thu, 2 Nov 2006 14:36:57 -0800 (PST)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 82E0120501; Thu, 2 Nov 2006 14:36:57 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 2 Nov 2006 14:36:57 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] On Nick-Names
Thread-Index: Acb+zW52G9af27VuT7eiMaKTvEJnBAAAdEBw
From: "Caitlin Bestler" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>
X-WSS-ID: 6954AC8039O384527-01-01
Content-Type: text/plain; charset=us-ascii
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA2MbJZS001634
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] On Nick-Names
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 02 Nov 2006 22:37:41 -0000
Status: RO
Content-Length: 1400

[e-mail] wrote:
> Donald,
> 
> 	Yes, this sounds familiar.  There are issues with this
> negotiation approach, however.  For example, because it is
> non-determinstic, some of the assumptions in this text are
> either incorrect, or subject to race-conditions.
> 
> 	For example, the statement "once it is stable,
> nicknames should remain stable even as routers go up or down"
> appears to either assume that a nick-name is presistent
> across a system's reset/reboot, or assume that this approach
> will (somehow) result in selecting the same nick-names again.
> 
> 	Also, the statement "To minimize the probability of a
> new RBridge usurping a nickname already in use, an RBridge
> should wait to acquire the link state database from a
> neighbor before it announces its own nickname" seems to have
> built-in difficulty in boot-strapping.  Exactly _how_ does
> this occur without the possibility of two devices each
> believing the other is the one doing the "usurping"?
> 
> 	I am also very uncomfortable with the idea of allowing
> any implementation choice possible, for nick-name selection,
> to be used, under the assumption that convergence will
> eventually happen, and that persistant nick-names will be a
> natural result of this chaotic assumption.
> 
Why not explicitly state that an RBridge SHOULD use its
prior nick-name as its first choice after a reset/reboot?




Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA2MYCoL000858 for <[e-mail]>; Thu, 2 Nov 2006 14:34:12 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA2MYBfK020132 for <[e-mail]>; Thu, 2 Nov 2006 17:34:11 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA18872 for <[e-mail]>; Thu, 2 Nov 2006 17:34:11 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB648HFR>; Thu, 2 Nov 2006 17:34:11 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: [e-mail]
Date: Thu, 2 Nov 2006 17:34:05 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] SPF verses STP, straight across the board
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 02 Nov 2006 22:34:40 -0000
Status: RO
Content-Length: 524

There appears to be a late-blooming source of confusion relative to 
multicast, broadcast and flooded frame forwarding among RBridges.

The question is - do the concerns about efficient link utilization 
via the use of SPF routing apply to multicast, broadcast and flooded
traffic (as they do to unicast traffic), or do we simply use some
variation of STP to determine "spanning trees" for the non-unicast 
case?

I've been under the impression that the intention is to use SPF
routing, straight across the board.

--
Eric


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA2MJfsE025694 for <[e-mail]>; Thu, 2 Nov 2006 14:19:42 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA2MJdfK019999; Thu, 2 Nov 2006 17:19:39 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA18308;  Thu, 2 Nov 2006 17:19:38 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB648HA5>; Thu, 2 Nov 2006 17:19:38 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Eastlake III Donald-LDE008 <[e-mail]>
Date: Thu, 2 Nov 2006 17:19:32 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] On Nick-Names
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 02 Nov 2006 22:20:14 -0000
Status: RO
Content-Length: 6329

Donald,

	Yes, this sounds familiar.  There are issues with this 
negotiation approach, however.  For example, because it is 
non-determinstic, some of the assumptions in this text are 
either incorrect, or subject to race-conditions.

	For example, the statement "once it is stable, nicknames 
should remain stable even as routers go up or down" appears to 
either assume that a nick-name is presistent across a system's
reset/reboot, or assume that this approach will (somehow) result
in selecting the same nick-names again.

	Also, the statement "To minimize the probability of a new 
RBridge usurping a nickname already in use, an RBridge should 
wait to acquire the link state database from a neighbor before 
it announces its own nickname" seems to have built-in difficulty
in boot-strapping.  Exactly _how_ does this occur without the 
possibility of two devices each believing the other is the one 
doing the "usurping"? 

	I am also very uncomfortable with the idea of allowing any
implementation choice possible, for nick-name selection, to be 
used, under the assumption that convergence will eventually 
happen, and that persistant nick-names will be a natural result
of this chaotic assumption.

--> -----Original Message-----
--> From: Eastlake III Donald-LDE008 
--> [mailto:[e-mail]] 
--> Sent: Thursday, November 02, 2006 1:03 AM
--> To: Radia Perlman; Gray, Eric
--> Cc: [e-mail]
--> Subject: RE: [rbridge] On Nick-Names
--> 
--> Details on choosing a nickname are in the expired
--> draft-bryant-perlman-trill-pwe-encap-00. I'll paste them below
--> 
--> Donald
--> 
-->    Each RBridge chooses its own nickname.  However, each 
--> RBridge is also
-->    responsible for ensuring that its nickname is unique.  
--> If R1 chooses
-->    nickname x, and R1 discovers, through receipt of R2's 
--> LSP, that R2
-->    has also chosen x, then the RBridge with the lower 
--> system ID keeps
-->    the nickname, and the other one must choose a new nickname.
--> 
-->    If two RBridge domains merge, then there might be a lot 
--> of nickname
-->    collisions for a short time, but as soon as each side 
--> receives the
-->    link state packets of the other, the RBridges that need to change
-->    nicknames will quickly become aware of this, and choose 
--> new nicknames
-->    that do not, to the best of their ability, collide with 
--> any existing
-->    nicknames.
--> 
-->    To minimize the probability of nickname collisions, each RBridge
-->    chooses its nickname randomly from the set of assigned nicknames.
-->    Alternatively, we could use some sort of hash algorithm 
--> (such as the
-->    bottom 19 bits of the MD5 of the RBridge's system ID), 
--> to choose the
-->    first nickname, and then if there is a collision, go to 
--> the next 19
-->    bits of the MD5, and so on, until all 128 bits of the 
--> MD5 hash are
-->    exhausted, in which case the RBridge hashes its own 
--> system ID again,
-->    this time together with the constant "1".
--> 
-->    There is no reason for all RBridges to use the same algorithm for
-->    choosing nicknames.  Picking them at random, or using a 
--> hash, are an
-->    attempt to avoid collisions when the network starts up, 
--> but that is
-->    only an optimization.  Even if all RBridges used the 
--> same algorithm,
-->    say as a worst case, they all start with "1" and count up
-->    sequentially until they find an uncontested nickname, the network
-->    will eventually stabilize.  And once it is stable, 
--> nicknames should
-->    remain stable even as routers go up or down.
--> 
-->    To minimize the probability of a new RBridge usurping a nickname
-->    already in use, an RBridge should wait to acquire the link state
-->    database from a neighbor before it announces its own nickname.
--> 
--> 
--> 
--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On
--> Behalf Of Radia Perlman
--> Sent: Wednesday, November 01, 2006 9:58 PM
--> To: Gray, Eric
--> Cc: [e-mail]
--> Subject: Re: [rbridge] On Nick-Names
--> 
--> I thought the spec did say how to choose nicknames.
--> 
--> I think it should be done based on choosing them at random, 
--> (rather than
--> some substring of the MAC address) and if someone with 
--> higher priority
--> asks for the same nickname you did, you have to choose a 
--> different one. 
--> Priority is
--> based on lower MAC address.
--> 
--> It will converge more quickly if the nickname space is not 
--> very densely
--> used of course. But I really think that people are not talking about
--> building campuses with more than 1000 RBridges, so with 16 bits it
--> wouldn't be densely assigned.
--> 
--> I don't care what size the nickname is. 16 bits seemed to 
--> align nicely,
--> but as I said, I don't care.
--> 
--> Radia
--> 
--> 
--> 
--> Gray, Eric wrote:
--> 
--> >Folks,
--> >
--> >Another thing to consider in potentially reducing the size of the 
--> >RBridge ID name space is that reducing the number of bits also 
--> >increases the probability of "name collisions" during the 
--> process of 
--> >nick-name negotiation - further complicating the RBridge 
--> interactions 
--> >by increasing the probability that "name collisions" will 
--> result in 
--> >multiple retries.
--> >
--> >Last I heard, the protocol specification was going to 
--> spell out how 
--> >nick-names would be negotiated.  As I understand it, the 
--> plan was to 
--> >assert a nick-name based on some substring of the 
--> MAC-derived system 
--> >ID.  Since this is at least 48 bits (with perhaps fewer 
--> bits relevantly
--> 
--> >significant), a reduction to 19 bits was felt to introduce 
--> a collision 
--> >probability that is not too bad.
--> >
--> >Do people feel that collisions are likely to remain rare 
--> if the name 
--> >space is reduced to 16 bits?  IMO, that may be an unreasonable 
--> >assumption...
--> >
--> >--
--> >Eric
--> >_______________________________________________
--> >rbridge mailing list
--> >[e-mail]
--> >http://mailman.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA2JKAJ4029540 for <[e-mail]>; Thu, 2 Nov 2006 11:20:10 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 02 Nov 2006 11:20:06 -0800 (PST)
Received: from sun.com ([129.150.22.255]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Thu, 02 Nov 2006 11:20:05 -0800 (PST)
Date: Thu, 02 Nov 2006 11:20:04 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Sanjay Sane (sanjays)" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between	com putation and optimality of delivery
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 02 Nov 2006 19:20:44 -0000
Status: RO
Content-Length: 1329

Warning---half-baked idea at the end of this message (my own---see "***")


Sanjay Sane (sanjays) wrote:

>
>So, the TLV inside rbridge LSP could contain 2 things 
>1 -- "my priority for being a tree root is x". 
>2 -- "I can support n trees"
>
>If both of these are absent, we could choose 1 tree, and the rbridge
>with lowest MAC address is the root of that single tree.
>
>-Sanjay
>
Right. I'm a bit nervous about some random RBridge that can only support 
one tree, or that just
leaves the TLV out, from going up and down. We have to make sure it's 
not unstable.

Suppose the nickname of the RBridge with highest priority for being root 
is 24.
Suppose ingress RBridge R1 doesn't notice that wimpy RBridge R5 (that 
can only support one tree)
has joined the net, and R1 selects "79" as the tree .

I guess we should say that if you see a specified tree that shouldn't be 
legal, you drop the packet, right?

***An alternative is to continue forwarding it along the 79-tree and 
hey, if R5 is on the path, it will
drop the packet and only nodes downstream from R5 will suffer. We could 
even do complicated things
like say that you can calculate trees beyond R5's capabilities by 
considering links out of R5 to be
infinity. That way a wimpy RBridge can be a leaf, and going up and down 
won't affect existing trees.

Radia



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA2J1eLn022537 for <[e-mail]>; Thu, 2 Nov 2006 11:01:41 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA2J1dfK016973; Thu, 2 Nov 2006 14:01:39 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA05446;  Thu, 2 Nov 2006 14:01:38 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB648DXV>; Thu, 2 Nov 2006 14:01:38 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Radia Perlman <[e-mail]>, "Gray, Eric" <[e-mail]>
Date: Thu, 2 Nov 2006 14:01:36 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] On Nick-Names
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 02 Nov 2006 19:02:19 -0000
Status: RO
Content-Length: 3090

Radia,

	I was under the impression that - while the "random approach"
has been discussed - there was some concerns about the fact that this
approach is inherently non-deterministic.  I don't recall exactly the
conversation I over-heard, but I thought there were concerns that this
may lead to management difficulties, etc.

	Also, this would mean that an RBridge would rarely use the same
nick-name in later negotiations, possibly leading to inconsistencies 
in forwarding entries and difficulties in defining a graceful restart
approach later on.

	However, even if this is - indeed - the approach we're going to 
use, the probability of a collisions is clearly 8 times as great with
16 bits as it is with 19 (16 times as great with 16 bits in comparison
with 20 bits).  That is true irrespective of the "sparseness" of usage
of the nick-name space.

--
Eric 

--> -----Original Message-----
--> From: Radia Perlman [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 9:58 PM
--> To: Gray, Eric
--> Cc: [e-mail]
--> Subject: Re: [rbridge] On Nick-Names
--> 
--> I thought the spec did say how to choose nicknames.
--> 
--> I think it should be done based on choosing them at random, 
--> (rather than 
--> some substring
--> of the MAC address) and if someone with higher priority
--> asks for the same nickname you did, you have to choose a 
--> different one. 
--> Priority is
--> based on lower MAC address.
--> 
--> It will converge more quickly if the nickname space is not 
--> very densely 
--> used of course. But I really
--> think that people are not talking about building campuses 
--> with more than 
--> 1000 RBridges, so
--> with 16 bits it wouldn't be densely assigned.
--> 
--> I don't care what size the nickname is. 16 bits seemed to 
--> align nicely, 
--> but as I said, I don't care.
--> 
--> Radia
--> 
--> 
--> 
--> Gray, Eric wrote:
--> 
--> >Folks,
--> >
--> >Another thing to consider in potentially reducing the size of 
--> >the RBridge ID name space is that reducing the number of bits
--> >also increases the probability of "name collisions" during the
--> >process of nick-name negotiation - further complicating the
--> >RBridge interactions by increasing the probability that "name
--> >collisions" will result in multiple retries.
--> >
--> >Last I heard, the protocol specification was going to spell
--> >out how nick-names would be negotiated.  As I understand it,
--> >the plan was to assert a nick-name based on some substring of
--> >the MAC-derived system ID.  Since this is at least 48 bits
--> >(with perhaps fewer bits relevantly significant), a reduction
--> >to 19 bits was felt to introduce a collision probability that
--> >is not too bad.
--> >
--> >Do people feel that collisions are likely to remain rare if 
--> >the name space is reduced to 16 bits?  IMO, that may be an
--> >unreasonable assumption...
--> >
--> >--
--> >Eric
--> >_______________________________________________
--> >rbridge mailing list
--> >[e-mail]
--> >http://mailman.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 


Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA2Hgs9f025667 for <[e-mail]>; Thu, 2 Nov 2006 09:42:54 -0800 (PST)
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 02 Nov 2006 09:42:55 -0800
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FAKK8SUWrR7O6WWdsb2JhbACMQAEUDis
X-IronPort-AV: i="4.09,381,1157353200";  d="scan'208"; a="349658309:sNHT44335176"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA2HgrVL030038; Thu, 2 Nov 2006 09:42:53 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA2HgpB8023275; Thu, 2 Nov 2006 09:42:53 -0800 (PST)
Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 2 Nov 2006 09:42:50 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 2 Nov 2006 09:42:49 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Compromise proposal---allowing tradeoff between	com putation and optimality of delivery
Thread-Index: Acb99g+n0Ii5UYozRmeIjzxRkP2cjQABHtOQ
From: "Sanjay Sane \(sanjays\)" <[e-mail]>
To: <[e-mail]>, "Gray, Eric" <[e-mail]>
X-OriginalArrivalTime: 02 Nov 2006 17:42:50.0534 (UTC) FILETIME=[511A4460:01C6FEA6]
DKIM-Signature: a=rsa-sha1; q=dns; l=6129; t=1162489373; x=1163353373; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=22Sanjay=20Sane=20\(sanjays\)=22=20<[e-mail]> |Subject:RE=3A=20[rbridge]=20Compromise=20proposal---allowing=20tradeoff=20betwee n=09com=20putation=20and=20optimality=20of=20delivery; X=v=3Dcisco.com=3B=20h=3DpzKVSMtD0eVBVlgZdpOW3H7tUC8=3D; b=l4T4wJbLOikMoTljKxacCkycSua39YgSRgPsJLZzDEHfgPLhU2MLTufrH8fe8YJsvLETvzE7 XfG7nxj+0ITmpQqjBdqyxpKMJRGBlnTeZtG1fg+x7dBJmCAXt9RGIuVQ;
Authentication-Results: sj-dkim-2.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA2Hgs9f025667
Cc: [e-mail]
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between	com putation and optimality of delivery
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 02 Nov 2006 17:43:14 -0000
Status: RO
Content-Length: 5884

inline with <sanjay>

3) Right. Choosing which n RBridges get to be roots based on MAC
addresses is arbitrary. I just wanted a simple tie breaker so all the
RBridges compute the same trees. For DR election there's a priority
field that is used as the most significant byte of the address. We could
do the same thing here. Rather than a flag saying "I want to be a root",
there can be, say, a 1 byte TLV in the link state packet saying "my
priority for being a tree root is x". If the TLV is not there at all
then it means "I don't want to be a root at all, unless there are no
other volunteers and I happen to be the lowest MAC address". Otherwise,
the n RBridges with the highest ( root priority | MAC ) get chosen.

<sanjay> And is this "n" derived from the lowest n seen from the "I can
support n trees" message from rbridge TLVs. ?

So, the TLV inside rbridge LSP could contain 2 things 
1 -- "my priority for being a tree root is x". 
2 -- "I can support n trees"

If both of these are absent, we could choose 1 tree, and the rbridge
with lowest MAC address is the root of that single tree.

-Sanjay

----- Original Message -----
From: "Gray, Eric" <[e-mail]>
Date: Wednesday, November 1, 2006 11:51 am
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between
com putation and optimality of delivery

> Radia,
> 
> 	There are three problems with this proposal: 1) the general
problem 
> associated with having options, 2) the fact that it is not consistent 
> with the idea of trying to utilize links more fully if the approach 
> may require traffic to traverse the same links more than one time, and

> 3) there is nothing about a low MAC address that has anything to do 
> with the suitability of a particular RBridge to act as the root for a 
> shared tree.
> 
> 	I think there are other ways to allow for an optional server for

> broadcast/multicast/flooding distribution than to complicate the TRILL

> protocol with optional implementation alternatives like this proposal 
> seems to suggest.  Part of the complication - at a minimum - is the 
> need to provide for a neogitation mechanism with one or more tunable 
> parameters for determing a primary, and one or more secondary, roots 
> for the shared tree.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [e-mail]
> --> [[e-mail]] On Behalf Of Radia Perlman
> --> Sent: Wednesday, November 01, 2006 1:43 PM
> --> To: [e-mail]
> --> Subject: [rbridge] Compromise proposal---allowing tradeoff between

> --> computation and optimality of delivery
> --> 
> --> There is understandable nervousness about the need to compute 
> --> per-ingress trees for every RBridge, and optimality of delivery.
> --> I actually was dubious about whether people *really* wanted to 
> --> have to compute per-ingress trees.
> --> 
> --> Here's a proposal that will allow tradeoff between overhead of 
> --> computation and optimality of delivery. If people really want they

> --> can have RBridges compute trees rooted at every RBridge. Or they 
> --> can have all multicast delivered on a single shared tree.
> --> Or anything in
> --> between.
> --> I'm arbitrarily picking the zero configuration option being a 
> --> single tree.
> --> 
> --> The new shim format allows the ingress RBridge to specify the 
> --> distribution tree for multicast, by putting into the "egress 
> --> RBridge"
> --> field a tree rooted at at the specified RBridge.
> --> 
> --> In this proposal, by default, the only tree that will be computed 
> --> is a single shared tree rooted at the RBridge with smallest MAC 
> --> address. Let's say
> that--> RBridge has nickname "71". By specifying 71 as egress
> RBridge in
> --> a multicast packet, the delivery path will be via the
> bidirectional--> tree rooted at 71.
> --> 
> --> An RBridge can be configured to demand that it, too, be the
> root of
> --> a tree, and it informs the other RBridges with a flag in its link 
> --> state packet.
> --> 
> --> So now we have a subset of RBridges that can be used as roots of 
> --> trees, because they have specified that in their link state 
> --> packet.
> --> Let's say that RBridges with nicknames 11, 15, 71, 222, and 259
> all--> have announced that they want to be roots of trees.
> --> 
> --> Then an ingress RBridge, say R2, with nickname 11, can send a
> --> multicast/unknown destination packet with "ingress"=11 (its own)
> --> and "egress"=11 (because it said it wanted to be a root). 
> --> Or it could
> --> choose any of the other potential ones (15, 71, 222, 259).
> --> 
> --> Likewise, an ingress RBridge, say R3, with nickname 13, who has
> --> not requested to be the root of a tree, can specify only
> --> the trees 11, 15, 71, 222, 259. Note it cannot specify 
> --> "13", since we
> --> are assuming it has not requested that all RBridges 
> --> calculate a tree 
> --> rooted at itself.
> --> 
> --> If no RBridges are configured to say they want to be the root,
> --> then only a single tree will get computed---the one rooted
> --> at 71.
> --> 
> --> So the zero configuration option is a single shared tree 
> --> (still filtered
> --> based on IP multicast announcements and VLANs) rooted at 
> --> the RBridge with
> --> smallest MAC address. But by configuration, more and more 
> optimality--> can be introduced by having RBridges compute more trees.
> --> 
> --> Radia
> --> 
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

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



Received: from xmail07.myhosting.com (xmail07.myhosting.com [168.144.250.250]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA2DHb8U029010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 2 Nov 2006 05:17:37 -0800 (PST)
Received: (qmail 22561 invoked from network); 2 Nov 2006 13:17:26 -0000
Received: from unknown (HELO [127.0.0.1]) (Authenticated-user:[e-mail]@[65.190.218.139]) (envelope-sender <[e-mail]>) by xmail07.myhosting.com (qmail-ldap-1.03) with SMTP for <[e-mail]>; 2 Nov 2006 13:17:26 -0000
Message-ID: <[e-mail]>
Date: Thu, 02 Nov 2006 08:17:24 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Silvano Gai <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between	computation and optimality of delivery
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 02 Nov 2006 13:19:38 -0000
Status: RO
Content-Length: 3728

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


I support this as well.... We need to sort the signaling out, somehow.

:-)

Russ

Silvano Gai wrote:
> Radia,
> 
> This is a great proposal,
> I fully support it
> 
> -- Silvano
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
> On
>> Behalf Of Radia Perlman
>> Sent: Wednesday, November 01, 2006 10:43 AM
>> To: [e-mail]
>> Subject: [rbridge] Compromise proposal---allowing tradeoff between
>> computation and optimality of delivery
>>
>> There is understandable nervousness about the need to compute
>> per-ingress trees for every RBridge, and optimality of delivery.
>> I actually was dubious about whether people *really* wanted
>> to have to compute per-ingress trees.
>>
>> Here's a proposal that will allow tradeoff between overhead of
>> computation and optimality of delivery. If people really want
>> they can have RBridges compute trees rooted at every RBridge. Or they
>> can have all multicast delivered on a single shared tree. Or anything
> in
>> between.
>> I'm arbitrarily picking the zero configuration option being a single
> tree.
>> The new shim format allows the ingress RBridge to specify the
>> distribution tree for multicast, by putting into the "egress RBridge"
>> field a tree rooted at at the specified RBridge.
>>
>> In this proposal, by default, the only tree that will be computed is a
>> single shared
>> tree rooted at the RBridge with smallest MAC address. Let's say that
>> RBridge has nickname "71". By specifying 71 as egress RBridge in
>> a multicast packet, the delivery path will be via the bidirectional
>> tree rooted at 71.
>>
>> An RBridge can be configured to demand that it, too, be the root of
>> a tree, and it informs the other RBridges with a flag in its link
> state
>> packet.
>>
>> So now we have a subset of RBridges that can be used as roots of
> trees,
>> because
>> they have specified that in their link state packet.
>> Let's say that RBridges with nicknames 11, 15, 71, 222, and 259 all
>> have announced that they want to be roots of trees.
>>
>> Then an ingress RBridge, say R2, with nickname 11, can send a
>> multicast/unknown destination packet with "ingress"=11 (its own)
>> and "egress"=11 (because it said it wanted to be a root). Or it could
>> choose any of the other potential ones (15, 71, 222, 259).
>>
>> Likewise, an ingress RBridge, say R3, with nickname 13, who has
>> not requested to be the root of a tree, can specify only
>> the trees 11, 15, 71, 222, 259. Note it cannot specify "13", since we
>> are assuming it has not requested that all RBridges calculate a tree
>> rooted at itself.
>>
>> If no RBridges are configured to say they want to be the root,
>> then only a single tree will get computed---the one rooted
>> at 71.
>>
>> So the zero configuration option is a single shared tree (still
> filtered
>> based on IP multicast announcements and VLANs) rooted at the RBridge
> with
>> smallest MAC address. But by configuration, more and more optimality
>> can be introduced by having RBridges compute more trees.
>>
>> Radia
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge

- --
[e-mail] CCIE <>< Grace Alone

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

iD8DBQFFSe/jER27sUhU9OQRAijWAJ4x7YMh30geODak9oMu9hFCwUR0mQCgl9O3
ah/WKrnrVzEoShD2xihrUtE=
=vBsK
-----END PGP SIGNATURE-----


Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id kA264j2d018581 for <[e-mail]>; Wed, 1 Nov 2006 22:04:45 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-12.tower-119.messagelabs.com!1162447483!11522062!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 12225 invoked from network); 2 Nov 2006 06:04:43 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-119.messagelabs.com with SMTP; 2 Nov 2006 06:04:43 -0000
Received: from il06exb01.corp.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id kA264dMK003573 for <[e-mail]>; Wed, 1 Nov 2006 23:04:43 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exb01.corp.mot.com (8.13.1/8.13.0) with ESMTP id kA264d5H014954 for <[e-mail]>; Thu, 2 Nov 2006 00:04:39 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 2 Nov 2006 01:03:04 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] On Nick-Names
thread-index: Acb+K6EoQVlsowjxSyGgXXr+M+XVHQAGEhVw
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Gray, Eric" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA264j2d018581
Cc: [e-mail]
Subject: Re: [rbridge] On Nick-Names
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 02 Nov 2006 06:05:10 -0000
Status: RO
Content-Length: 4267

Details on choosing a nickname are in the expired
draft-bryant-perlman-trill-pwe-encap-00. I'll paste them below

Donald

   Each RBridge chooses its own nickname.  However, each RBridge is also
   responsible for ensuring that its nickname is unique.  If R1 chooses
   nickname x, and R1 discovers, through receipt of R2's LSP, that R2
   has also chosen x, then the RBridge with the lower system ID keeps
   the nickname, and the other one must choose a new nickname.

   If two RBridge domains merge, then there might be a lot of nickname
   collisions for a short time, but as soon as each side receives the
   link state packets of the other, the RBridges that need to change
   nicknames will quickly become aware of this, and choose new nicknames
   that do not, to the best of their ability, collide with any existing
   nicknames.

   To minimize the probability of nickname collisions, each RBridge
   chooses its nickname randomly from the set of assigned nicknames.
   Alternatively, we could use some sort of hash algorithm (such as the
   bottom 19 bits of the MD5 of the RBridge's system ID), to choose the
   first nickname, and then if there is a collision, go to the next 19
   bits of the MD5, and so on, until all 128 bits of the MD5 hash are
   exhausted, in which case the RBridge hashes its own system ID again,
   this time together with the constant "1".

   There is no reason for all RBridges to use the same algorithm for
   choosing nicknames.  Picking them at random, or using a hash, are an
   attempt to avoid collisions when the network starts up, but that is
   only an optimization.  Even if all RBridges used the same algorithm,
   say as a worst case, they all start with "1" and count up
   sequentially until they find an uncontested nickname, the network
   will eventually stabilize.  And once it is stable, nicknames should
   remain stable even as routers go up or down.

   To minimize the probability of a new RBridge usurping a nickname
   already in use, an RBridge should wait to acquire the link state
   database from a neighbor before it announces its own nickname.



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Wednesday, November 01, 2006 9:58 PM
To: Gray, Eric
Cc: [e-mail]
Subject: Re: [rbridge] On Nick-Names

I thought the spec did say how to choose nicknames.

I think it should be done based on choosing them at random, (rather than
some substring of the MAC address) and if someone with higher priority
asks for the same nickname you did, you have to choose a different one. 
Priority is
based on lower MAC address.

It will converge more quickly if the nickname space is not very densely
used of course. But I really think that people are not talking about
building campuses with more than 1000 RBridges, so with 16 bits it
wouldn't be densely assigned.

I don't care what size the nickname is. 16 bits seemed to align nicely,
but as I said, I don't care.

Radia



Gray, Eric wrote:

>Folks,
>
>Another thing to consider in potentially reducing the size of the 
>RBridge ID name space is that reducing the number of bits also 
>increases the probability of "name collisions" during the process of 
>nick-name negotiation - further complicating the RBridge interactions 
>by increasing the probability that "name collisions" will result in 
>multiple retries.
>
>Last I heard, the protocol specification was going to spell out how 
>nick-names would be negotiated.  As I understand it, the plan was to 
>assert a nick-name based on some substring of the MAC-derived system 
>ID.  Since this is at least 48 bits (with perhaps fewer bits relevantly

>significant), a reduction to 19 bits was felt to introduce a collision 
>probability that is not too bad.
>
>Do people feel that collisions are likely to remain rare if the name 
>space is reduced to 16 bits?  IMO, that may be an unreasonable 
>assumption...
>
>--
>Eric
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>

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



Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA22wDn0027333 for <[e-mail]>; Wed, 1 Nov 2006 18:58:13 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 01 Nov 2006 18:57:59 -0800 (PST)
Received: from sun.com ([129.150.22.255]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Wed, 01 Nov 2006 18:57:59 -0800 (PST)
Date: Wed, 01 Nov 2006 18:57:58 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Gray, Eric" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] On Nick-Names
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 02 Nov 2006 02:58:32 -0000
Status: RO
Content-Length: 1760

I thought the spec did say how to choose nicknames.

I think it should be done based on choosing them at random, (rather than 
some substring
of the MAC address) and if someone with higher priority
asks for the same nickname you did, you have to choose a different one. 
Priority is
based on lower MAC address.

It will converge more quickly if the nickname space is not very densely 
used of course. But I really
think that people are not talking about building campuses with more than 
1000 RBridges, so
with 16 bits it wouldn't be densely assigned.

I don't care what size the nickname is. 16 bits seemed to align nicely, 
but as I said, I don't care.

Radia



Gray, Eric wrote:

>Folks,
>
>Another thing to consider in potentially reducing the size of 
>the RBridge ID name space is that reducing the number of bits
>also increases the probability of "name collisions" during the
>process of nick-name negotiation - further complicating the
>RBridge interactions by increasing the probability that "name
>collisions" will result in multiple retries.
>
>Last I heard, the protocol specification was going to spell
>out how nick-names would be negotiated.  As I understand it,
>the plan was to assert a nick-name based on some substring of
>the MAC-derived system ID.  Since this is at least 48 bits
>(with perhaps fewer bits relevantly significant), a reduction
>to 19 bits was felt to introduce a collision probability that
>is not too bad.
>
>Do people feel that collisions are likely to remain rare if 
>the name space is reduced to 16 bits?  IMO, that may be an
>unreasonable assumption...
>
>--
>Eric
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA22JVa8016976 for <[e-mail]>; Wed, 1 Nov 2006 18:19:31 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Nov 2006 18:19:28 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
Thread-Index: Acb93YwRVoDKGqwjScqLHJwPROk7agARwceQ
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA22JVa8016976
Cc: [e-mail]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 02 Nov 2006 02:20:07 -0000
Status: RO
Content-Length: 45506

Eric,

In the spirit of making progress the compromise I can accept is: 
"Ethernet: In this document the term "Ethernet" is used to represent
both IEEE 802.3 and its bridging component as described in IEEE 802.1D
and IEEE 802.1Q"

I am also OK if you want to say something like: "any IEEE 802 Local Area
Network that provides an Ethernet service will automatically be able to
take advantage of and be usable by TRILL"

Fell free to improve my English.

-- Silvano



> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Wednesday, November 01, 2006 9:46 AM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: RE: [rbridge] Comments on: http://www.ietf.org/internet-
> drafts/draft-ietf-trill-rbridge-arch-01.txt
> 
> Silvano,
> 
> 	I think that there may be a compromise we can arrive at here.
> 
> 	I propose changing the defintion of "Ethernet" to read:
> 
> 'Ethernet: In this document the term "Ethernet" is used to represent
>  Ethernet-like and/or Ethernet-equivalent technologies - explicitly
>  including 802.3 [802.3 ref], 802.1Q [802.Q ref] and other closely
>  related LAN technologies, and NOT explicitly excluding any other
>  Ethernet-like and/or Ethernet-equivalent technology that exists, or
>  may be developed in the future.'
> 
> 	Using this definition should clarify that I am not necessarily
> using the term in the way that some people may feel it should be used,
> while clearly stating what I am using the term to mean.  This should
> also reduce your concern that I am apprently equating Ethernet and
> 802 in general.  It also satisfies my intention to be inclusive.
> 
> 	How does this sound?
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[e-mail]]
> --> Sent: Wednesday, November 01, 2006 1:21 AM
> --> To: Gray, Eric
> --> Cc: [e-mail]
> --> Subject: RE: [rbridge] Comments on:
> --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
> --> -arch-01.txt
> -->
> -->
> --> Eric,
> -->
> --> I disagree.
> -->
> --> I don't think it is wise for TRILL to redefine the term Ethernet.
> --> Ethernet is a term that has a well known meaning in the industry.
> --> The original definition is:
> --> Digital Equipment Corporation, Intel, Xerox, The Ethernet,
> --> Version 2.0,
> --> November 1982.
> --> Which has been then standardized by IEEE 802.3.
> -->
> --> To speak about other IEEE 802 standards that are alive and
> --> used, IEEE
> --> 802.11 (Wireless LAN) and IEEE 802.17 (Resilient Packet
> --> Ring Working)
> --> have nothing to do with Ethernet.
> -->
> --> -- Silvano
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:[e-mail]]
> --> > Sent: Tuesday, October 31, 2006 2:44 PM
> --> > To: Silvano Gai
> --> > Cc: [e-mail]
> --> > Subject: RE: [rbridge] Comments on:
http://www.ietf.org/internet-
> --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
> --> >
> --> > Silvano,
> --> >
> --> > 	To be perfectly frank, I am unaware of any reason not to
> include
> --> > token ring or any other obsolete form of "Ethernet equivalent
> --> technology"
> --> > - this is one of the reason to focus on the SHIM as
> --> separate from any
> --> > specific encapsulation above or below the SHIM.
> --> >
> --> > 	If you want to check it against all 802 activities,
that's
> fine.
> --> > I would suggest, however, that even though people are
> --> realistically
> --> not
> --> > going to implement most of the hairy/scary versions in an
> --> RBridge, I
> --> do
> --> > not know of a good reason to exclude them at this point.
> --> In abstract,
> --> > it is certainly possible that people will be able to work out
> --> specifics
> --> > of implementation - if and when they decide to do so.
> --> >
> --> > 	After all, we (the industry) have been building
translation
> --> bridges
> --> > for these technologies for decades.
> --> >
> --> > 	However, I am open to scoping the architecture to apply
only
> to
> --> a
> --> > limited subset of 802 technologies, if that is what would
> --> make people
> --> > happy...
> --> >
> --> > --
> --> > Eric
> --> >
> --> > --> -----Original Message-----
> --> > --> From: Silvano Gai [mailto:[e-mail]]
> --> > --> Sent: Tuesday, October 31, 2006 5:34 PM
> --> > --> To: Gray, Eric
> --> > --> Cc: [e-mail]
> --> > --> Subject: RE: [rbridge] Comments on:
> --> > --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
> --> > --> -arch-01.txt
> --> > -->
> --> > -->
> --> > --> Eric,
> --> > -->
> --> > --> A quick reply:
> --> > --> Are you telling me that the term Ethernet includes Token
Ring,
> --> Token
> --> > --> Bus, DQDB?
> --> > -->
> --> > --> This is what you are doing when you say that Ethernet
> --> is IEEE 802
> --> > --> instead of IEEE 802.3.
> --> > -->
> --> > --> This is NOT a terminology issue. If the term Ethernet means
> --> > --> 802 I need
> --> > --> to check the operation of TRILL against all the 802
> --> technologies.
> --> > -->
> --> > --> -- Silvano
> --> > -->
> --> > --> > -----Original Message-----
> --> > --> > From: Gray, Eric [mailto:[e-mail]]
> --> > --> > Sent: Tuesday, October 31, 2006 1:46 PM
> --> > --> > To: Silvano Gai
> --> > --> > Cc: [e-mail]
> --> > --> > Subject: RE: [rbridge] Comments on:
> --> http://www.ietf.org/internet-
> --> > --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
> --> > --> >
> --> > --> >
> --> > --> >
> --> > --> > -- [snip] --
> --> > --> > -->
> --> > --> > --> Sgai 4> an RBridge must be also able to send
> --> two copies of a
> --> > --> > --> unicast/multicast/broadcast packet on the same
> --> port when it
> --> > --> > --> acts as a designated RBridge (one copy is
> --> encapsulated, the
> --> > --> > --> other not).
> --> > --> > -->
> --> > --> >
> --> > --> > This, I think, refers to the immediately preceding
> --> text in the
> --> > --> > architecture:
> --> > --> >
> --> > --> >         Forwarding information is derived from the
> --> combination
> --> of
> --> > --> >         attached MAC address learning, snooping of
> --> > --> multicast-related
> --> > --> >         protocols (e.g. - IGMP), and routing
> --> > --> advertisements and path
> --> > --> >         computations using the link-state routing
protocol.
> --> > --> >
> --> > --> > While your comment is a reasonable one - although
> --> potentially
> --> > --> > implementation specific - it does not appear to
> --> have any bearing
> --> > --> > on this text.
> --> > --> >
> --> > --> >
> --> > --> > -- [snip] --
> --> > --> > -->
> --> > --> > --> Sgai 5> here there is some confusion between
> --> 802 and 802.3
> --> > --> > -->
> --> > --> >
> --> > --> > This  refers (I believe) to the immeditately preceding
text:
> --> > --> >
> --> > --> >         The following terminology is defined in
> --> other documents.
> --> A
> --> > --> brief
> --> > --> >         definition is included in this section for
> --> > --> convenience and -
> --> > --> in
> --> > --> >         some cases - to remove any ambiguity in how the
> --> > --> term may be
> --> > --> used
> --> > --> >         in this document, as well as derivative documents
> --> > --> intended to
> --> > --> >         specify components, protocol, behavior and
> --> encapsulation
> --> > --> >         relative to the architecture specified in
> --> this document.
> --> > --> >
> --> > --> >         o  802: IEEE Specification for the Ethernet
> --> architecture,
> --> > --> i.e.,
> --> > --> >            including hubs and bridges.
> --> > --> >
> --> > --> > In this text, I explicitly state that these terms
> --> are defined
> --> > --> elsewhere.
> --> > --> > I am also trying to use the most generic definition
> --> of Ethernet
> --> > --> possible.
> --> > --> >
> --> > --> > The reason for this is that the problem statement does
> --> > --> not restrict
> --> > --> the
> --> > --> > solution to 802.3.
> --> > --> >
> --> > --> > There is some confusion in referring to 802.3 in
> --> any case: we
> --> > --> explicitly
> --> > --> > want to include 802.1Q - as well as all of its
> --> variations and
> --> > --> extensions.
> --> > --> >
> --> > --> > Consequently, we define the term Ethernet in the broadest
> --> possible
> --> > --> sense.
> --> > --> >
> --> > --> >
> --> > --> > -- [snip] --
> --> > --> > -->
> --> > --> > -->        o  Bridge Spanning Tree (BST): an Ethernet (L2,
> --> 802.1D)
> --> > --> > -->           forwarding protocol based on the topology
> --> > --> of a spanning
> --> > --> > tree.
> --> > --> > -->
> --> > --> > --> Sgai 6> I have never seen the acronym BST,
> --> everyone use STP.
> --> > --> > -->
> --> > --> >
> --> > --> > I do not know if this term is used in any of the other
> --> documents,
> --> > --> > but it is not used in this one.  Unless someone
> --> objects, I am
> --> only
> --> > --> > too happy to remove it from this document.
> --> > --> >
> --> > --> > From a historical perspective, this was defined this way
> --> > --> originally
> --> > --> > because we were re-using the term spanning tree instead
> --> > --> of IRT.  It
> --> > --> > was causing amazing communication difficulties, so
> --> we came up
> --> with
> --> > --> > the term IRT.  Now we don't need to differentiate BST.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 7> for Ethernet is better to reference 802.3
> --> > --> > -->
> --> > --> >
> --> > --> > See my response to your point (Sgai 5) above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Hub: an Ethernet (L2, 802) device with
> --> > --> multiple ports
> --> > --> which
> --> > --> > -->
> --> > --> > --> sgai 8> for Hub is better to reference 802.3
> --> > --> > -->
> --> > --> >
> --> > --> > See my response to your point (Sgai 5) above.  By the
> --> > --> definition we
> --> > --> > provide in this document, Ethernet is defined
> --> broadly to include
> --> > --> > 802 technologies.  This is reasonable, because the term
was
> --> stolen
> --> > --> > by IEEE from a technology stolen from a satellite
> --> communication
> --> > --> > protocol.  Ironic that 802.3 does not include wireless,
all
> --> things
> --> > --> > considered.  Certainly the term "Ethernet" should...
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Node: a device with an L2 (MAC) address
> --> > --> that sources
> --> > --> and/or
> --> > --> > -->            sinks L2 frames.
> --> > --> > -->
> --> > --> > --> Sgai 9> The IEEE term is "station".
> --> > --> > -->
> --> > --> >
> --> > --> > However, we in the IETF are more familiar with the
> --> term "node."
> --> > --> >
> --> > --> > This is hardly a significant issue.  if people agree that
> --> > --> we should
> --> > --> > use the term "station" as opposed to "node", then I will
> --> > --> change it.
> --> > --> >
> --> > --> > Note that we should be consistent in this usage, if we
> --> > --> decide to do
> --> > --> > yet another terminology evolution.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Segment: an Ethernet link, either a single
> --> physical
> --> > --> link or
> --> > --> > -->            emulation thereof (e.g., via hubs) or a
> --> > --> logical link or
> --> > --> > -->            emulation thereof (e.g., via bridges).
> --> > --> > -->
> --> > --> > --> Sgai 10> IEEE uses the term "LAN segment"
> --> > --> > -->
> --> > --> >
> --> > --> > I agree, however this is the definition we agreed on here.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Subnet, Ethernet: a single segment,
> --> or a set of
> --> > --> segments
> --> > --> > -->            interconnected by a CRED (see
> --> section 2.2); in
> --> the
> --> > --> latter
> --> > --> > -->
> --> > --> > --> sgai 11> There is no concept of subnet in IEEE.
> --> Subnet is
> --> > --> typically
> --> > --> > --> an IP subnet, and, even if it is common to have
> --> one subnet
> --> per
> --> > --> LAN,
> --> > --> > --> this is not the only possibility. Pragmatically
> --> IP subnets
> --> and
> --> > --> > --> Ethernet LAN are unrelated concepts.
> --> > --> > -->
> --> > --> >
> --> > --> > Again, we are defining this term for use in this
> --> > --> document.  Does its
> --> > --> > use (not its definition) cause confusion or ambiguity?
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->            case, the subnet may or may not be
> --> equivalent to
> --> a
> --> > --> single
> --> > --> > -->            segment. Also a subnet may be
> --> referred to as a
> --> > --> broadcast
> --> > --> > -->            domain or LAN. By definition, all
> --> nodes within an
> --> > --> Ethernet
> --> > --> > -->            Subnet (broadcast domain or LAN) must have
L2
> --> > --> connectivity
> --> > --> > -->            with all other nodes in the same
> --> Ethernet subnet.
> --> > --> > -->
> --> > --> > -->         o  TRILL: Transparent Interconnect over Lots
> --> > --> of Links -
> --> > --> the
> --> > --> > -->            working group and working name for the
> --> > --> problem domain
> --> > --> to be
> --> > --> > -->            addressed in this document.
> --> > --> > -->
> --> > --> > -->         o  Unicast Forwarding: forwarding methods
> --> > --> that apply to
> --> > --> frames
> --> > --> > -->            with unicast destination MAC addresses.
> --> > --> > -->
> --> > --> > -->         o  Unknown Destination - a destination
> --> for which a
> --> > --> receiving
> --> > --> > -->            device has no filtering database entry.
> --> > --> Destination
> --> > --> (layer
> --> > --> > -->
> --> > --> > --> sgai 12> the stations receive the unknown
> --> unicast and have
> --> > --> filtering
> --> > --> > --> information, only the bridges don't. I propose to
> --> > --> replace device
> --> > --> with
> --> > --> > --> bridge.
> --> > --> > -->
> --> > --> >
> --> > --> > Again, it is the intention to provide as broad a
> --> definition as
> --> > --> possible
> --> > --> > without introducing confusion or ambiguity.  An end node
> --> > --> (or station)
> --> > --> > has - in a sense - a filtering database (it's mine, or
> --> > --> it's for the
> --> > --> bit
> --> > --> > bucket).
> --> > --> >
> --> > --> > We need to explicitly include 802.1D forwarding devices
> --> > --> and RBridges.
> --> > --> >
> --> > --> > However, the definition should specify "forwarding
> --> device" - as
> --> > --> opposed
> --> > --> > to just "receiving device."
> --> > --> >
> --> > --> > I will change that.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->            2) addresses are typically "learned"
> --> by (layer 2)
> --> > --> > forwarding
> --> > --> > -->            devices via a process commonly referred to
> --> > --> as "bridge
> --> > --> > learning".
> --> > --> > -->
> --> > --> > --> Sgai 13> in IEEE, the term used is "learning" instead
> --> > --> of "bridge
> --> > --> > learning"
> --> > --> > -->
> --> > --> >
> --> > --> > However, the term defined in this document is
> --> "bridge learning."
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  VLAN: Virtual Local Area Network. VLANs in
> --> > --> general fall
> --> > --> > into
> --> > --> > -->            two categories: link (or port)
> --> specific VLANs and
> --> > --> tagged
> --> > --> > -->            VLANs. In the former case, all frames
> --> > --> forwarded and all
> --> > --> > -->            directly connected nodes are assumed to be
> --> > --> part of a
> --> > --> single
> --> > --> > -->            VLAN.  In the latter case, VLAN tagged
> --> > --> frames are used
> --> > --> to
> --> > --> > -->            distinguish which VLAN each frame is
intended
> --> for.
> --> > --> > -->
> --> > --> > --> Sgai 14> This definition is not completely correct, I
> --> prefer:
> --> > --> > -->
> --> > --> > --> VLAN technology introduces the following three
> --> basic types
> --> of
> --> > --> frame:
> --> > --> > --> a) Untagged frames;
> --> > --> > --> b) Priority-tagged frames; and
> --> > --> > --> c) VLAN-tagged frames.
> --> > --> > -->
> --> > --> > --> An untagged frame or a priority-tagged frame does not
> --> > --> carry any
> --> > --> > --> identification of the VLAN to which it belongs. Such
> --> > --> frames are
> --> > --> > --> classified as belonging to a particular VLAN based on
> --> > --> parameters
> --> > --> > --> associated with the receiving Port, or, through
> --> proprietary
> --> > --> extensions
> --> > --> > --> to IEEE 802.1Q standard, based on the data content of
> --> > --> the frame
> --> > --> (e.g.,
> --> > --> > --> MAC Address, layer 3 protocol ID, etc.).
> --> > --> > -->
> --> > --> > --> A VLAN-tagged frame carries an explicit
> --> > --> identification of the VLAN
> --> > --> to
> --> > --> > --> which it belongs; i.e., it carries a tag header
> --> that carries
> --> a
> --> > --> non-
> --> > --> > null
> --> > --> > --> VID. Such a frame is classified as belonging to a
> --> > --> particular VLAN
> --> > --> > based
> --> > --> > --> on the value of the VID that is included in the tag
> --> > --> header. The
> --> > --> > presence
> --> > --> > --> of the tag header carrying a non-null VID means that
> --> > --> some other
> --> > --> > device,
> --> > --> > --> either the originator of the frame or a
> --> VLAN-aware Bridge,
> --> has
> --> > --> mapped
> --> > --> > --> this frame into a VLAN and has inserted the
> --> appropriate VID.
> --> > --> > -->
> --> > --> >
> --> > --> > So, you're getting into the details of the
> --> technology and - in
> --> > --> particular
> --> > --> > the encapsulation.  I will expand the definition to
> --> include a
> --> > --> possibility
> --> > --> > that other criteria may be used to define a "VLAN port" -
> --> although
> --> > --> this is
> --> > --> > isomorphic to a logical model in which a device
> --> > --> implementation uses
> --> > --> some
> --> > --> > criteria to decide that a subset of the traffic received
> --> > --> on a specific
> --> > --> > physical port is to be forwarded as if received on a
> --> > --> specific logical
> --> > --> > port.
> --> > --> >
> --> > --> > The key point in this definition is that a VLAN is a
> --> > --> "Virtual LAN" -
> --> > --> > meaning
> --> > --> > it consists of a subset of the physical and L2
connectivity
> --> > --> corresponding
> --> > --> > to
> --> > --> > a "logical LAN."  The intent is to "rise above" the
> --> technological
> --> > --> > approaches
> --> > --> > and encapsulations to establish a generic definition that
> --> > --> is loosely
> --> > --> tied
> --> > --> > to
> --> > --> >
> --> > --> > ways that this generic definition is actually implemented.
> --> > --> >
> --> > --> > Again, bearing in mind the way that the term is
> --> defined, does
> --> the
> --> > --> usage of
> --> > --> > the term cause confusion or ambiguity?
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  CRED Forwarding Table (CFT): the per-hop
> --> forwarding
> --> > --> table
> --> > --> > -->            populated by the RBridge Routing Protocol;
> --> > --> forwarding
> --> > --> > within
> --> > --> > -->            the CRED is based on a lookup of the
> --> CRED Transit
> --> > --> Header
> --> > --> > -->            (CTH) encapsulated within the
> --> outermost received
> --> L2
> --> > --> header.
> --> > --> > -->            The outermost L2 encapsulation in this
> --> > --> case includes
> --> > --> the
> --> > --> > -->            source MAC address of the immediate
> --> > --> upstream RBridge
> --> > --> > -->            transmitting the frame and destination MAC
> --> > --> address of
> --> > --> the
> --> > --> > -->            receiving RBridge for use in the unicast
> --> forwarding
> --> > --> case.
> --> > --> > -->
> --> > --> > --> Sgai 15> In section 7 of
> --> > --> > -->
> --> > -->
> --> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-
> --> > --> > 00.txt
> --> > --> > --> we proposed that when two rbridges are
> --> connected by a point
> --> to
> --> > --> point
> --> > --> > --> link the outer MAC addresses may be set to a
> --> > --> predefined value in
> --> > --> > --> transmission and ignored in reception.
> --> > --> > -->
> --> > --> >
> --> > --> > I'm not sure how your proposal intends to determine that
> --> > --> a link is in
> --> > --> > fact point-to-point and does not just look that way.
> --> > --> >
> --> > --> > I prefer to use the same encapsulation in all cases where
it
> --> will
> --> > --> work.
> --> > --> >
> --> > --> > The optimization associated with using some form of
> --> > --> null-encapsulation
> --> > --> > is of dubious value, given that it may not be possible to
> --> > --> be certain a
> --> > --> > point-to-point link is - and will remain - in fact a
> --> > --> point-to-point
> --> > --> > link.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  CFT-IRT: a forwarding table used for
> --> propagation
> --> of
> --> > --> > -->            broadcast, multicast or flooded
> --> frames along the
> --> > --> Ingress
> --> > --> > -->            RBridge Tree (IRT).
> --> > --> > -->
> --> > --> > --> Sgai 16> is it a forwarding table or is it a
> --> > --> filtering database.
> --> > --> Since
> --> > --> > --> the "miss" behavior is to flood, I see it as a
> --> > --> filtering database.
> --> > --> > -->
> --> > --> >
> --> > --> > What state was "miss" behavior from - Hawaii?  :-)
> --> > --> >
> --> > --> > It is analogous to a filtering database entry, but it is
not
> --> that.
> --> > --> >
> --> > --> > Clearly there are more things in this world than can be
> --> classified
> --> > --> > in this taxonomy.  However, given these choices, it is a
> --> > --> forwarding
> --> > --> > table.
> --> > --> >
> --> > --> > This is not a misbehavior, in that the same "base" tree
> --> > --> is used for
> --> > --> > broadcast and multicast traffic as well as flooded
> --> > --> traffic.  It may
> --> > --> > be arguable that flooding is a misbehavior, but I
> --> seem to recall
> --> > --> > that people still see it as a necessary evil.
> --> > --> >
> --> > --> > It is also not "miss" behavior (as in "cache miss") in
> --> > --> the multicast
> --> > --> > and broadcast case, either.
> --> > --> >
> --> > --> > I believe the definition is quite correct and easy to
> --> understand,
> --> > --> > provided you're not reading it with preconceived
> --> misconceptions
> --> > --> > about its meaning.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  CRED Transit Header (CTH): a 'shim'
> --> header that
> --> > --> > encapsulates
> --> > --> > -->            the ingress L2 frame and persists
> --> throughout the
> --> > --> transit of
> --> > --> > a
> --> > --> >
> --> > --> > -->            CRED, which is further encapsulated within
> --> > --> a hop-by-hop
> --> > --> L2
> --> > --> > -->            header (and trailer). The hop-by-hop L2
> --> > --> encapsulation
> --> > --> in
> --> > --> > this
> --> > --> >
> --> > --> > -->            case includes the source MAC address of
> --> > --> the immediate
> --> > --> > -->            upstream RBridge transmitting the frame
> --> > --> and destination
> --> > --> MAC
> --> > --> > -->            address of the receiving RBridge -
> --> at least in
> --> the
> --> > --> unicast
> --> > --> > -->            forwarding case.
> --> > --> > -->
> --> > --> > --> Sgai 17> is this true also for unknown unicast?
> --> > --> > -->
> --> > --> >
> --> > --> > That is something that will be (may be already)
> --> decided in the
> --> > --> protocol
> --> > --> > specification.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  CRED Transit Table (CTT): a table that maps
> --> ingress
> --> > --> frame
> --> > --> > L2
> --> > --> > -->            destinations to egress RBridge
> --> addresses, used to
> --> > --> determine
> --> > --> > -->            encapsulation of ingress frames for
> --> transit of
> --> the
> --> > --> CRED.
> --> > --> > -->
> --> > --> > -->         o  Cooperating RBridges - those RBridges
> --> > --> within a single
> --> > --> > -->            Ethernet Subnet (broadcast domain or LAN)
> --> > --> not having
> --> > --> been
> --> > --> > -->            configured to ignore each other. By
> --> default, all
> --> > --> RBridges
> --> > --> > -->            within a single Ethernet subnet will
> --> cooperate
> --> with
> --> > --> each
> --> > --> > -->            other. It is possible for implementations
> --> > --> to allow for
> --> > --> > -->            configuration that will restrict
> --> > --> "cooperation" between
> --> > --> an
> --> > --> > -->            RBridge and an apparent neighboring
> --> RBridge.  One
> --> > --> reason
> --> > --> > why
> --> > --> > -->            this might occur is if the trust model
> --> > --> that applies in
> --> > --> a
> --> > --> > -->            particular deployment imposes a need for
> --> > --> configuration
> --> > --> of
> --> > --> > -->            security information.  By default no such
> --> > --> configuration
> --> > --> is
> --> > --> > -->            required however - should it be used in
> --> > --> any specific
> --> > --> > scenario
> --> > --> > -->
> --> > --> > -->            - it is possible (either deliberately or
> --> > --> inadvertently)
> --> > --> to
> --> > --> > -->            configure neighboring RBridges so
> --> that they do
> --> not
> --> > --> > cooperate.
> --> > --> > -->
> --> > --> > -->            In the remainder of this document,
> --> all RBridges
> --> are
> --> > --> assumed
> --> > --> > -->            to be in a cooperating (default)
> --> configuration.
> --> > --> > -->
> --> > --> > --> Sgai 18> can RBridges cooperate in groups, e.g. four
> --> Rbridges
> --> > --> > connected
> --> > --> > --> to a LAN cooperating two and two?
> --> > --> > -->
> --> > --> >
> --> > --> > Yes.  There may be reasons why this might be done
> --> deliberately,
> --> > --> however
> --> > --> > - even in the absence of any "proof of concept"
> --> > --> justification - it is
> --> > --> a
> --> > --> > really good idea to design the protocol to be robust in
> --> > --> cases where a
> --> > --> > set of RBridges may be (mis)configured in such a way as
> --> > --> to be unable
> --> > --> to
> --> > --> > discover each other.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Ingress RBridge Tree: a tree
> --> computed for each
> --> edge
> --> > --> RBridge
> --> > --> > -->            and potentially for each VLAN in which that
> --> RBridge
> --> > --> > -->
> --> > --> > --> sgai 19> why for each VLAN? I got the
> --> impression that there
> --> > --> > --> was a single tree that was pruned differently for
> --> > --> different VLANs.
> --> > --> > -->
> --> > --> >
> --> > --> > Pruning may also take place at the ingress, if - for
> --> > --> example - it has
> --> > --> a
> --> > --> > subset of interfaces that are not connected to any
> --> egress for
> --> > --> particular
> --> > --> > VLANs.  It is a small point but, in such cases, there is
in
> --> effect
> --> > --> more
> --> > --> > than one IRT even at the ingress.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->            participates - for delivery of broadcast,
> --> > --> multicast and
> --> > --> > -->            flooded frames from that RBridge to all
> --> > --> relevant egress
> --> > --> > -->            RBridges. This is the point-to-multipoint
> --> > --> delivery tree
> --> > --> > used
> --> > --> > -->            by an ingress RBridge to deliver
> --> > --> multicast, broadcast
> --> > --> or
> --> > --> > -->            flooded traffic.
> --> > --> > -->
> --> > --> > --> Sgai 20> the current version of the proposal
> --> speaks about a
> --> > --> multicast
> --> > --> > --> address, not point-to-point.
> --> > --> > -->
> --> > --> >
> --> > --> > I did not say "point-to-point" (look again).
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  LPT: Learned Port Table. See
> --> Filtering Database.
> --> > --> > -->
> --> > --> > --> Sgai 21> not proper terminology, I would use
> --> > --> "filtering database"
> --> > --> > --> everywhere.
> --> > --> > -->
> --> > --> >
> --> > --> > I am happy to remove this if there is no objection
> --> to my doing
> --> so.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 22> I wired port is Ehernet, i.e. IEEE 802.3, a
> --> > --> > --> wireless port is not Ethernet, it is IEEE 802.11.
> --> > --> > -->
> --> > --> >
> --> > --> > See my response to your point (sgai 8) above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 23> they learn because STP guarantees
> --> > --> symmetrical forwarding
> --> > --> > -->
> --> > --> >
> --> > --> > This (apparently) refers to the immeditately preceding
text:
> --> > --> >
> --> > --> >         Conventional bridges contain a learned port table
> --> > --> (LPT), or
> --> > --> >         filtering database, and a spanning tree table
> --> > --> (STT). The LPT
> --> > --> >         allows a bridge to avoid flooding all received
> --> > --> frames, as is
> --> > --> >         typical for a hub or repeater. The bridge learns
> --> > --> which nodes
> --> > --> are
> --> > --> >         accessible from a particular port by assuming
> --> > --> bi-directional
> --> > --> >         consistency:
> --> > --> >
> --> > --> > I'm not sure how picking at the peculiarities of
> --> STP behavior is
> --> > --> > relevant to this description.  STP results in a
> --> single spanning
> --> > --> > tree where each link is bi-directional.  This
> --> ensures that the
> --> > --> > MAC frames are forwarded in a bi-directionally consistent
> --> fashion.
> --> > --> >
> --> > --> > To replace this text with yours is to provide less
> --> information.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 24> active ports -> forwarding ports
> --> > --> > -->
> --> > --> >
> --> > --> > "Active ports" was the exact wording suggested to me.  In
> --> > --> context for
> --> > --> > this working group "active ports" is more meaningful than
> --> > --> "forwarding
> --> > --> > ports."  For people not used to STP-speak, "forwarding
> --> > --> port" might be
> --> > --> > used to discriminate from a "code port."
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 25> there is no STT, there is a state associated
> --> > --> with each
> --> > --> port
> --> > --> > --> that can be: disabled, blocking, listening,
> --> learning, and
> --> > --> forwarding
> --> > --> > -->
> --> > --> >
> --> > --> > Other than the issue with terminology, is this text
> --> wrong?  I am
> --> > --> fairly
> --> > --> > sure that different implementations handle the "port
state"
> --> > --> information
> --> > --> > in different ways, and I am also reasonably sure that a
> --> > --> "table" such
> --> > --> as
> --> > --> > the one described here is one of the ways it might be
done.
> --> > --> >
> --> > --> > However, I agree with your assertion that this is the way
> --> > --> that it is
> --> > --> > usually talked about in an IEEE context, so -
> --> unless there are
> --> > --> specific
> --> > --> > objections - I can change the wording to be consistent
> --> > --> with what you
> --> > --> > suggest.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 26> disabled -> blocking
> --> > --> > -->
> --> > --> >
> --> > --> > I can make this change as well.  However, from the
> --> > --> perspective of what
> --> > --> > we are trying to do, "disabled" is potentially a more
> --> > --> correct term.
> --> > --> It
> --> > --> > is certainly more intuitively correct, outside of a
> --> > --> strictly IEEE/STP
> --> > --> > context.
> --> > --> >
> --> > --> > Symmetry is maintained in STP by blocking ports/links
> --> > --> bi-directionally.
> --> > --> > In such cases, a port is effectively disabled for bridges
> --> > --> at either
> --> > --> end
> --> > --> > of the link for which a port is blocked, is it not?
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 27> I repeat a comment that I have made to other
> --> > --> documents: "
> --> > --> > --> The discussion about VLAN needs to be much more
> --> > --> extensive. It is
> --> > --> clear
> --> > --> > --> from the mailing list discussion that VLANs can be
> --> > --> used inside the
> --> > --> > --> packet or in the Ethernet encapsulation of TRILL.
> --> > --> These are two
> --> > --> > --> different kinds of VLANs and their requirement need
> --> > --> to be stated
> --> > --> > --> separately. Q in Q needs also to be discussed. I
> --> > --> propose to define
> --> > --> > inner
> --> > --> > --> and outer VLANs (with reference to the position of
> --> > --> the tag in the
> --> > --> > frame."
> --> > --> > --> Here I think we are talking about outer VLANs
> --> > --> > -->
> --> > --> >
> --> > --> > I responded to this in separate mail.  I wait to hear
> --> > --> other opinions
> --> > --> on
> --> > --> > this subject.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 28> IMO all RBridges must be ingress RBridges,
> --> > --> at least to
> --> > --> > support
> --> > --> > --> inband management, e.g. SNMP.
> --> > --> > -->
> --> > --> >
> --> > --> > No.
> --> > --> >
> --> > --> > In order to ensure symmetry with RBridges not
> --> > --> participating in STP,
> --> > --> there
> --> > --> > MUST be a designated RBridge that does all of the
> --> sending and
> --> > --> receiving
> --> > --> > of native encapsulated frames on a LAN segment.
> --> > --> >
> --> > --> > Any RBridge the loses the "Designated RBridge"
> --> election cannot
> --> be
> --> > --> either
> --> > --> > an ingress or an egress for that LAN segment.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 29> same as above
> --> > --> > -->
> --> > --> >
> --> > --> > Same as above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 30> I think the previous definition is not
needed.
> --> > --> > -->
> --> > --> >
> --> > --> > This appears to refer to:
> --> > --> >
> --> > --> >         o  Local RBridge - the RBridge that forms and
> --> > --> maintains the
> --> > --> CFT-
> --> > --> >            IRT entry (or entries) under discussion. The
> --> > --> local RBridge
> --> > --> >            may be an Ingress RBridge, or an egress
> --> RBridge with
> --> > --> respect
> --> > --> >            to any set of entries in the CFT-IRT.
> --> > --> >
> --> > --> > This defintion is needed.  It is subsequently used
> --> in at least 4
> --> > --> places.
> --> > --> > When discussing the behavior of a specific RBridge
> --> > --> relative to a peer,
> --> > --> > it is convenient to define the term "local RBridge."
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 31> why is it zero or more, if an RBridge
> --> exists, it
> --> must
> --> > --> have
> --> > --> > --> a an IRT, I haven't seen any discussion to support
> --> > --> multiple IRTs.
> --> > --> > -->
> --> > --> >
> --> > --> > This was answered previously on the mailing list.
> --> > --> Briefly, zero or
> --> > --> > more is correct, given that an RBridge may not have
> --> > --> forwarding entries
> --> > --> > for frames it has received.  In these cases, a frame is
> --> > --> not forwarded.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 32> I don't understand this. Since the current
> --> > --> proposal uses
> --> > --> a
> --> > --> > --> multicast MAC address, what is needed is a bit map
> --> > --> for each IRT
> --> > --> that
> --> > --> > --> says which ports are blocking and which are
> --> > --> forwarding. You are
> --> > --> > --> basically building a ST using ISIS.
> --> > --> > -->
> --> > --> >
> --> > --> > This might be the case for a specific implementation.
> --> > --> Whether it is
> --> > --> > implemented as a "bit-mask" with "non-blocking"
> --> > --> (forwarding) ports, or
> --> > --> > is implemented as a full-blown table is largely dependent
on
> --> what
> --> > --> other
> --> > --> > information the local device requires in order to
> --> > --> properly forwad the
> --> > --> > frame.  If - for example - a device has multiple
> --> > --> different port types,
> --> > --> > it may need to have more information for each port (or
that
> --> > --> information
> --> > --> > may be added later on).
> --> > --> >
> --> > --> > All of these are implementation choices that are
> --> > --> logically represented
> --> > --> > by the table described here.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 33> I don't get the pair.
> --> > --> > -->
> --> > --> >
> --> > --> > Since this immediately follows:
> --> > --> >
> --> > --> >         Each entry would contain an indication of
> --> which single
> --> > --> interface
> --> > --> >         a broadcast, multicast or flooded frame would be
> --> > --> forwarded for
> --> > --> >         each (ingress RBridge, egress RBridge) pair.
> --> > --> >
> --> > --> > I don't get what you don't get.
> --> > --> >
> --> > --> > The pair refers to the tuple "(ingress RBridge, egress
> --> RBridge)."
> --> > --> >
> --> > --> > This might be the point at which your earlier point (Sgai
4)
> --> would
> --> > --> make
> --> > --> > sense to insert.  I had logically modeled this in my own
> --> > --> mind as two
> --> > --> > distinct "interfaces" (the reason I use this term, rather
> --> > --> thhan port),
> --> > --> > but I should clarify this.
> --> > --> >
> --> > --> > In any case, the entries are keyed by both ingress and
> --> > --> egress RBridge.
> --> > --> > While there will be entries for only those egress
> --> > --> RBridges where this
> --> > --> > local RBridge is on the shortest path (between the given
> --> > --> ingress and
> --> > --> > egress pair), there will be at most one entry per
> --> any ingress
> --> and
> --> > --> > egress pair.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 34> as a matter of fact each interface is
> --> > --> basically a set of
> --> > --> two
> --> > --> > --> interfaces, a regular one and a tunnel one, and the
> --> > --> > forwarding/blocking
> --> > --> > --> state may be different for the two.
> --> > --> > -->
> --> > --> >
> --> > --> > No.
> --> > --> >
> --> > --> > As per my response to your point (Sgai 28) above, not
> --> > --> every RBridge
> --> > --> has a
> --> > --> > "regular one" as you describe here.
> --> > --> >
> --> > --> > The forwarding/blocking state is not applicable as
> --> > --> RBridges don't do
> --> > --> STP.
> --> > --> >
> --> > --> > For the native interface, fowarding/blocking state is
> --> > --> analogous to the
> --> > --> > "Designated RBridge" election process.
> --> > --> >
> --> > --> > Since this point evidently applies to -
> --> > --> >
> --> > --> >
Entries
> --> would
> --> > --> also
> --> > --> >         contain any required encapsulation information,
> --> > --> etc. required
> --> > --> >         for forwarding on a given interface, and toward a
> --> > --> corresponding
> --> > --> >         specific egress RBridge.
> --> > --> >
> --> > --> > - your point, and my response, are related to the point
> --> > --> (and response)
> --> > --> > above (Sgai 33), and I will try to clarify this
> --> part as well.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 35> this protocol must be designed to avoid
> --> > --> transient loops,
> --> > --> > since
> --> > --> > --> transient loops of multicast/broadcast cause
> --> > --> broadcast storm that
> --> > --> are
> --> > --> > --> highly undesirable.
> --> > --> > -->
> --> > --> >
> --> > --> > No.
> --> > --> >
> --> > --> > The protocol needs to include a provision to prevent
> --> > --> _use_ of links
> --> > --> that
> --> > --> > may connect to transient loops.  Using a link-state
> --> > --> routing protocol
> --> > --> has
> --> > --> > clearly been demostrated to produce transient loops, but
> --> > --> the problem
> --> > --> you
> --> > --> > want to address has to do with using those links.
> --> > --> >
> --> > --> > A state-machine driven mechanism similar to STP might be
> --> > --> the approach
> --> > --> to
> --> > --> > use.
> --> > --> >
> --> > --> > Because we're incorporating TTL in the SHIM, however this
> --> > --> would need
> --> > --> to
> --> > --> > apply only to IRT traffic.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->
> --> > --> > --> Sgai 36> see my previous comment about VLANs
> --> > --> > -->
> --> > --> >
> --> > --> > See my previous responses.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 37> disabled -> blocking.
> --> > --> > -->
> --> > --> >
> --> > --> > See my response to your point (sgai 26) above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 38> for multicast/broadcast we also need to
> --> > --> avoid transient
> --> > --> > loops.
> --> > --> > -->
> --> > --> >
> --> > --> > Yes.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 39> but RBridge discovery and STP are ongoing
> --> > --> processes, why
> --> > --> do
> --> > --> > we
> --> > --> > --> want to couple their timers?
> --> > --> > -->
> --> > --> >
> --> > --> > I am not suggesting "coupling their timers."  I am
> --> saying that
> --> the
> --> > --> value
> --> > --> > chosen for a timer (if one is used) to determine when it
> --> > --> is reasonable
> --> > --> to
> --> > --> > start RBridge peer discovery should take into
> --> account the time
> --> it
> --> > --> takes
> --> > --> > for the local spanning tree resolution.
> --> > --> >
> --> > --> > I feel the reason for this is self-evident but, just to
> --> > --> clarify, think
> --> > --> > about the process we're planning to use to determine
RBridge
> --> > --> nick-names.
> --> > --> > If we start this too early, we will be re-starting it
> --> > --> many times as we
> --> > --> > "hear from" new RBridge peers when the connecting links go
> --> active
> --> > --> after
> --> > --> > local bridges go to the forwarding state.  This would
> --> > --> apply only at
> --> > --> the
> --> > --> > system start up as - after that - you are quite correct
> --> > --> in asserting
> --> > --> it
> --> > --> > would be an ongoing process.
> --> > --> >
> --> > --> > Perhaps I should add some words to indicate that a delay
> --> > --> would not be
> --> > --> > necessary if the protocol mechanisms do not introduce
> --> > --> instability as a
> --> > --> > new peer is discovered.  So far, I have not seen any
> --> > --> indication that a
> --> > --> > "race-free" solution to accomplish this has been designed
> --> > --> - or talked
> --> > --> > about.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 40> there is also a requirement to time-out
learnt
> --> > --> information to
> --> > --> > --> maintain the filtering databases.
> --> > --> > -->
> --> > --> >
> --> > --> > There would be, if we were doing that.  Instead,
> --> we're adopting
> --> a
> --> > --> > link-state routing protocol and they tend to have
> --> that covered.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 41> periodically or on demand
> --> > --> > -->
> --> > --> >
> --> > --> > See the response to your point (Sgai 40) above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 42> potentially there is an unencapsulated
> --> > --> interface for each
> --> > --> > --> physical interface of the RBridge. It is true that
> --> > --> you can model
> --> > --> all
> --> > --> > --> of them as a single separate logical interface, but
> --> > --> then we need
> --> > --> to
> --> > --> > --> replicate the frame according to a bitmask that tells
on
> --> which
> --> > --> > physical
> --> > --> > --> interface the RBridge is designated.
> --> > --> > -->
> --> > --> >
> --> > --> > Again, your use of a "bitmask" is an implementation
> --> > --> choice as opposed
> --> > --> > to a logical model.
> --> > --> >
> --> > --> > As you observe, I do "model all of them as a single
> --> > --> separate logical
> --> > --> > interface" and if you want to "replicate the frame
> --> according to
> --> a
> --> > --> > bitmask that tells on which physical interface the
> --> RBridge is
> --> > --> > designated" - you're absolutely free to do so.
> --> > --> >
> --> > --> > Personally, I think this is far too much implementation
> --> > --> stuff for a
> --> > --> > protocol specification, let alone an architecture
document.
> --> > --> >
> --> > --> > -->
> --> > --> > --> Sgai 43> can we clarify that this means "drop BPDUs".
> --> > --> > -->
> --> > --> >
> --> > --> > Yes.
> --> > --> >
> --> > --> > -- [snip --
> --> > -->
> -->



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA226bmP012939 for <[e-mail]>; Wed, 1 Nov 2006 18:06:37 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Nov 2006 18:06:35 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Should we optimize the common case?
Thread-Index: Acb+CctJWWSUxrynQDqF9Hp6UwHrYwAFvk2w
From: "Silvano Gai" <[e-mail]>
To: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA226bmP012939
Subject: [rbridge] Should we optimize the common case?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 02 Nov 2006 02:07:02 -0000
Status: RO
Content-Length: 1444

With 16 bit addresses the current TRILL overhead over Ethernet is 20
bytes. If we want to expand the RBridge addresses, it we will go to
22-24 bytes.

What customers are telling us is that they will deploy RBridges by
creating an RBridge backbone in which all the links will be 10GE.

They will connect regular bridges and host to the periphery of this
backbone. 

They will not mix backbone ports with access ports, because this screws
up management, traffic engineering, debugging, and troubleshooting.
Regular network design, easy to understand, is very important. Ports are
cheap, labor is expensive.

I am totally convinced that this will account for 90+ % of TRILL
deployment. 

I am wondering if it makes sense to have a solution highly optimized for
such an environment.

For example we can put the egress/ingress RBridge addresses in the outer
MAC addresses and define a TRILL shim header that contains 1 byte of hop
limit and 1 byte reserved. For this common case we will get:
1) overhead of 16 bytes (4 to 8 bytes lower)
2) nickname = MAC address, i.e no hash collision
3) zero-conf achieved

In the case we need to go over a shared media we will need to add
another Ethernet encapsulation to carry the next hop address, i.e. 14
bytes
- total overhead will be 30 bytes

Summarizing:
- current proposal 20-24 bytes overhead
- new proposal on point to point: 16 bytes
- new proposal on shared media: 30 bytes

Comments?

-- Silvano




Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1MxW8q011819 for <[e-mail]>; Wed, 1 Nov 2006 14:59:33 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1MxWfK005218 for <[e-mail]>; Wed, 1 Nov 2006 17:59:32 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA19436 for <[e-mail]>; Wed, 1 Nov 2006 17:59:32 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647Y4K>; Wed, 1 Nov 2006 17:59:31 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: [e-mail]
Date: Wed, 1 Nov 2006 17:59:31 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] On Nick-Names
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 23:00:11 -0000
Status: RO
Content-Length: 903

Folks,

Another thing to consider in potentially reducing the size of 
the RBridge ID name space is that reducing the number of bits
also increases the probability of "name collisions" during the
process of nick-name negotiation - further complicating the
RBridge interactions by increasing the probability that "name
collisions" will result in multiple retries.

Last I heard, the protocol specification was going to spell
out how nick-names would be negotiated.  As I understand it,
the plan was to assert a nick-name based on some substring of
the MAC-derived system ID.  Since this is at least 48 bits
(with perhaps fewer bits relevantly significant), a reduction
to 19 bits was felt to introduce a collision probability that
is not too bad.

Do people feel that collisions are likely to remain rare if 
the name space is reduced to 16 bits?  IMO, that may be an
unreasonable assumption...

--
Eric


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1MaSPT001380 for <[e-mail]>; Wed, 1 Nov 2006 14:36:28 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1MaNfK004989; Wed, 1 Nov 2006 17:36:23 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA18590;  Wed, 1 Nov 2006 17:36:08 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647YMW>; Wed, 1 Nov 2006 17:36:07 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>
Date: Wed, 1 Nov 2006 17:36:07 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] New shim header proposal---without F-tag field
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 22:37:14 -0000
Status: RO
Content-Length: 7143

Silvano,

	Radia and I are currently having an off-line discussion 
about what your #3 below means.  I'll have to get back to you
on that.

	In the meantime, I have been assuming that we are using
a link state routing protocol - at least in part - because of
the built in shortest-path first algorithm.  This is implied 
in your #3.

	Assuming that one might be running IS-IS instances per
VLAN, IS-IS peers being used to support VLANs over RBridges 
do not need to compute Dijkstra (SPF) for all other RBridges.
Just those in the same VLANs, and part of the same LSDB.

 	Note that I am not saying everyone would do this, but -
if people did - then they would be trading RBridge IDs (as 
IS-IS instances) to achieve simplified per-VLAN LSDBs.

	By the way, "computing trees" is - IMO - not what is
being done.  It is only a way to view what is actually
being done.  Each IS-IS node has to know the shortest path
to all other IS-IS nodes in any case.  What it does in the
process of "constructing an IRT", is:

1)	compute this same information for all IS-IS instances 
	in the same LSDB,
2)	make a note of which RBridges it is on the shortest
	path between,
3)	create IRT entries for these RBridges

	This creates an analog of a point-to-multipoint tree 
because the RBridge can then retrieve all entries for any
frame based on the ingress RBridge ID in that frame (this
applies ONLY to multicast, broadcast and flooded frames).
The RBridge then forwards a copy of the received frame for
each of these entries.

	I think if you model it this way, you will find that 
the computational complexity is less than you think it is
- especially if the problem is broken up (by, for example,
using per-VLAN instancing).

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 5:02 PM
--> To: Gray, Eric; Russ White
--> Cc: Radia Perlman; [e-mail]
--> Subject: RE: [rbridge] New shim header proposal---without 
--> F-tag field
--> 
--> 
--> Eric, 
--> 
--> This has nothing to do with the connectivity.
--> I simply read:
--> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> -protocol-00
--> .txt
--> 
--> tell me where I am wrong:
--> 1) there is one IRT per RBridge
--> 2) there is one ISIS LSA per RBridge, i.e. # of RBridge
--> 3) Each RBridge needs to compute Djikstra for all the IRTs, 
--> plus one for
--> the core instance, therefore the number of Djikstra 
--> computation is (# of
--> RBridge + 1)
--> 
--> The total CPU effort to compute Djikstra is therefore (# of 
--> Rbridge + 1)
--> on a LSA database # of Rbridges.
--> 
--> This has nothing to do with the connectivity/topology among the
--> RBridges.
--> 
--> You should like a lot the last proposal of Radia, because 
--> it elegantly
--> solves this problem for you.
--> 
--> -- Silvano
--> 
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[e-mail]]
--> > Sent: Wednesday, November 01, 2006 1:11 PM
--> > To: Silvano Gai; Russ White
--> > Cc: Gray, Eric; Radia Perlman; [e-mail]
--> > Subject: RE: [rbridge] New shim header proposal---without 
--> F-tag field
--> > 
--> > Silvano,
--> > 
--> > 	I did not actually say that we need to support half a
--> > million RBridges, I simply said that we may need to support
--> > more than 32K (or even 64K), consequently I do not support a
--> > reduction in the "name space" to 16 bits.
--> > 
--> > 	It would never work out to an order N^2 connectivity
--> > in any case, so this concern - IMO - comes under the heading
--> > of FUD.  If every port needed to be connected to every other
--> > port, then there would not be a need to have VLANs, and -
--> > hence - no need to have separate per-VLAN instances.  In a
--> > real world application where VLANs are used to connect large
--> > numbers of multi-port switches, only a few ports on a few
--> > switches typically end up connected to each individual VLAN.
--> > Some exceptions would occur, but they would be exceptions.
--> > Thus per-VLAN connectivity would be a sparse partial mesh, or
--> > VLANs would not be used.
--> > 
--> > 	This is in fact part of the justification for having
--> > per-VLAN IS-IS instances.  Trauma to part of the network is
--> > only going to impact on routing convergence for the IS-IS
--> > instances participating in affected VLANs.
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: Silvano Gai [mailto:[e-mail]]
--> > --> Sent: Wednesday, November 01, 2006 11:55 AM
--> > --> To: Russ White
--> > --> Cc: Gray, Eric; Radia Perlman; [e-mail]
--> > --> Subject: RE: [rbridge] New shim header proposal---without
--> > --> F-tag field
--> > -->
--> > -->
--> > --> What is a stretch is 32K trees of 32K nodes, which is what
--> > --> you need if
--> > --> you want to deploy the current TRILL proposal with 
--> 32K RBridges.
--> > -->
--> > --> Eric says that we need to accommodate half a million RBridges.
--> > --> Half a million tree of half a million nodes is unfeasible.
--> > -->
--> > --> If we want to support such a large number of Rbridges, we
--> > --> need to modify
--> > --> the current Trill proposal, reducing the number of trees
--> > --> that need to be
--> > --> computed.
--> > -->
--> > --> Agreed?
--> > -->
--> > --> -- Silvano
--> > -->
--> > -->
--> > --> > -----Original Message-----
--> > --> > From: Russ White [mailto:[e-mail]]
--> > --> > Sent: Wednesday, November 01, 2006 8:35 AM
--> > --> > To: Silvano Gai
--> > --> > Cc: Gray, Eric; Radia Perlman; [e-mail]
--> > --> > Subject: Re: [rbridge] New shim header proposal---without
--> > --> F-tag field
--> > --> >
--> > --> > -----BEGIN PGP SIGNED MESSAGE-----
--> > --> > Hash: SHA1
--> > --> >
--> > --> >
--> > --> > >> 	I don't think there is consensus yet that we
--> > --> only need 16 bits
--> > --> > >> for RBridge IDs.
--> > --> > >
--> > --> > > With 16 bits, using 1 bit to indicate unicast, we 
--> can have 32K
--> > --> switches.
--> > --> > > According to the current definition of TRILL, there is
--> > --> the need to
--> > --> run
--> > --> > > Djikstra on a database with 32K records, one time 
--> for the core
--> > --> instance
--> > --> > > and 32K times for the IRTs. This is clearly out of
--> > --> reach even for
--> > --> the
--> > --> > > most powerful CPU.
--> > --> >
--> > --> > ?? Perhaps 32k trees is a stretch, but 32k nodes in a
--> > --> tree? I don't
--> > --> > think that's really a stretch on today's processors, from
--> > --> the scaling
--> > --> > work I've seen done in IS-IS.
--> > --> >
--> > --> > :-)
--> > --> >
--> > --> > Russ
--> > --> >
--> > --> > - --
--> > --> > [e-mail] CCIE <>< Grace Alone
--> > --> >
--> > --> > -----BEGIN PGP SIGNATURE-----
--> > --> > Version: GnuPG v1.4.2.2 (MingW32)
--> > --> > Comment: Using GnuPG with Mozilla - 
--> http://enigmail.mozdev.org
--> > --> >
--> > --> > 
--> iD8DBQFFSMypER27sUhU9OQRAqLwAJ9FLN2YNP2mrB6i0ZcV1fxLzAT0hgCfYHYj
--> > --> > 6mJCA68nQLjCD8US9nRZZag=
--> > --> > =kwzq
--> > --> > -----END PGP SIGNATURE-----
--> > -->
--> 


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1MGZ4v024318 for <[e-mail]>; Wed, 1 Nov 2006 14:16:35 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Nov 2006 14:16:32 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Compromise proposal---allowing tradeoff between computation and optimality of delivery
Thread-Index: Acb95dnEECMUhCTaRySUWDXd/VurIwAHXW0w
From: "Silvano Gai" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA1MGZ4v024318
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between computation and optimality of delivery
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 22:16:57 -0000
Status: RO
Content-Length: 3055

Radia,

This is a great proposal,
I fully support it

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Radia Perlman
> Sent: Wednesday, November 01, 2006 10:43 AM
> To: [e-mail]
> Subject: [rbridge] Compromise proposal---allowing tradeoff between
> computation and optimality of delivery
> 
> There is understandable nervousness about the need to compute
> per-ingress trees for every RBridge, and optimality of delivery.
> I actually was dubious about whether people *really* wanted
> to have to compute per-ingress trees.
> 
> Here's a proposal that will allow tradeoff between overhead of
> computation and optimality of delivery. If people really want
> they can have RBridges compute trees rooted at every RBridge. Or they
> can have all multicast delivered on a single shared tree. Or anything
in
> between.
> I'm arbitrarily picking the zero configuration option being a single
tree.
> 
> The new shim format allows the ingress RBridge to specify the
> distribution tree for multicast, by putting into the "egress RBridge"
> field a tree rooted at at the specified RBridge.
> 
> In this proposal, by default, the only tree that will be computed is a
> single shared
> tree rooted at the RBridge with smallest MAC address. Let's say that
> RBridge has nickname "71". By specifying 71 as egress RBridge in
> a multicast packet, the delivery path will be via the bidirectional
> tree rooted at 71.
> 
> An RBridge can be configured to demand that it, too, be the root of
> a tree, and it informs the other RBridges with a flag in its link
state
> packet.
> 
> So now we have a subset of RBridges that can be used as roots of
trees,
> because
> they have specified that in their link state packet.
> Let's say that RBridges with nicknames 11, 15, 71, 222, and 259 all
> have announced that they want to be roots of trees.
> 
> Then an ingress RBridge, say R2, with nickname 11, can send a
> multicast/unknown destination packet with "ingress"=11 (its own)
> and "egress"=11 (because it said it wanted to be a root). Or it could
> choose any of the other potential ones (15, 71, 222, 259).
> 
> Likewise, an ingress RBridge, say R3, with nickname 13, who has
> not requested to be the root of a tree, can specify only
> the trees 11, 15, 71, 222, 259. Note it cannot specify "13", since we
> are assuming it has not requested that all RBridges calculate a tree
> rooted at itself.
> 
> If no RBridges are configured to say they want to be the root,
> then only a single tree will get computed---the one rooted
> at 71.
> 
> So the zero configuration option is a single shared tree (still
filtered
> based on IP multicast announcements and VLANs) rooted at the RBridge
with
> smallest MAC address. But by configuration, more and more optimality
> can be introduced by having RBridges compute more trees.
> 
> Radia
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1MEg1V023693 for <[e-mail]>; Wed, 1 Nov 2006 14:14:42 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Nov 2006 14:14:40 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Last Call comment on: http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-01.txt
Thread-Index: Acb98CHmD2sQIjJyQ8ek19izx6/VWAAEq9vQ
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA1MEg1V023693
Cc: [e-mail]
Subject: Re: [rbridge] Last Call comment on: http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 22:14:56 -0000
Status: RO
Content-Length: 6903

Eric,

If you want to use node instead of station that is fine, I agree that
this is common.

I am against the term cache, because it is so overloaded, unless you
explain what it really means.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Wednesday, November 01, 2006 11:59 AM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: RE: [rbridge] Last Call comment on:
http://www.ietf.org/internet-
> drafts/draft-ietf-trill-prob-01.txt
> 
> Silvano,
> 
> 	I think that - with some minor exceptions - these are quite
> reasonable terminology change proposals over-all.  In particular,
> the idea of using frames to represent L2 PDUs is one that has been
> suggested before.
> 
> 	I suspect that we will need to expand the definition, or give
> a definition, for the term "node" to indicate that this term is
> meant to include the conceptual idea of a "station" as defined for
> the IEEE.
> 
> 	On the term "cache," this is generally a well understood term
> in this context and whether or not filtering database is more correct
> is something that may have to be considered on a case-by-case basis.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[e-mail]]
> --> Sent: Saturday, October 28, 2006 10:59 AM
> --> To: Gray, Eric
> --> Cc: [e-mail]
> --> Subject: RE: [rbridge] Last Call comment on:
> --> http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-01.txt
> -->
> -->
> --> Per Eric request, this is the terminology changes I
> --> propose, to align
> --> these documents with a layer two terminology:
> -->
> --> Packet -> frame
> --> In IEEE 802.1D the term packet means something at higher
> --> level (IP and
> --> above)
> -->
> --> Autolearning -> learning
> -->
> --> Cache -> filtering database
> --> The term filtering database is consistently used to
> --> indicate that a hit
> --> on the database limit the frame propagation, while a miss causes
> --> flooding (this is a different behavior from a forwarding
> --> database, where
> --> a miss causes a drop).
> -->
> --> I am not sure about the term "Port autolearning" used in
> --> the draft, can
> --> you clarify the meaning?
> -->
> --> IEEE speaks about stations, this may be the most
> --> controversial change,
> --> but we need to settle on a single term.
> --> Node -> station
> --> Endnode -> station
> --> Host -> station
> -->
> --> -- Silvano
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:[e-mail]]
> --> > Sent: Friday, October 27, 2006 10:59 AM
> --> > To: Silvano Gai
> --> > Cc: [e-mail]
> --> > Subject: RE: [rbridge] Last Call comment on:
> --> http://www.ietf.org/internet-
> --> > drafts/draft-ietf-trill-prob-01.txt
> --> >
> --> > Silvano, et al,
> --> >
> --> > 	 Please see below.
> --> >
> --> > -- [SNIP] --
> --> > --> I don't think it is acceptable to have temporary loop for
> --> broadcast
> --> > --> multicast, even if they are mitigated by TTL. An interlock
> --> mechanism
> --> > --> similar to ST must be used for multicast/broadcast.
> --> > -->
> --> > --> I ask for a strong requirement that says: "TRILL MUST avoid
> --> > --> multicast/broadcast storms"
> --> >
> --> > I completely agree with this and I have been assuming an
> --> "interlock"
> --> > function would be applied - especially for non-unicast or
unknown
> --> > frames.
> --> >
> --> > In retrospect, it is obvious that this should be
> --> explicitly spelled
> --> > out.
> --> >
> --> > -->
> --> > --> Sgai 2> ST provides symmetrical forwarding, i.e. the
> --> path from A
> --> to B
> --> > is
> --> > --> the reverse of the path from B to A. Is this a requirement
for
> --> TRILL?
> --> >
> --> > I believe this has certainly been assumed in discussions, but it
> --> > might not have been deemed necessary to explicitly include this
> --> > as a "requirement" in the PA&S document.  It is a behavior that
> --> > applies to existing 802.1D bridges and we are required to be
> --> > compatible with 802.1D bridges.
> --> >
> --> > -->
> --> > --> Sgai 3> the terminology used in this draft is not the
> --> one used in
> --> IEEE
> --> > --> standards. This makes it difficult to understand what
certain
> --> > sentences
> --> > --> really mean. Concepts like autolearning and caches
> --> are not IEEE
> --> > concepts.
> --> >
> --> > This observation has been made before.  Can you make specific
> --> > proposals for textual changes (replace "XYZ" with "LMNOP")?
> --> >
> --> > -->
> --> > --> Sgai 4> There is no mention of the applicability of other
> --> important
> --> > IEEE
> --> > --> standards/WG/Study Groups, e.g.
> --> > --> - 802.3ad-2000, Link Aggregation.
> --> > --> - 802.1ah - Provider Backbone Bridges
> --> > --> - 802.1aq - Shortest Path Bridging
> --> > --> - 802.1au - Congestion Notification
> --> > --> - 802.1ad - Provider Bridges
> --> > --> - 802.1AE - MAC Security
> --> > --> - 802.3ar - Congestion Management Task Force.
> --> > --> - 802.3as - Frame Expansion Task Force.
> --> > --> I think this document needs to clearly state the
> --> position of the
> --> WG
> --> > with
> --> > --> respect to these projects.
> --> > -->
> --> > --> Sgai 5> I also think there need to be a mention of the
> --> applicability
> --> > of
> --> > --> important industrial efforts:
> --> > --> - NIC Teaming
> --> > --> - uplinkfast
> --> > --> - split-MLT
> --> > --> - Q in Q
> --> > --> All these are widely deployed in all
> --> datacenters/enterprises. I
> --> think
> --> > --> this document needs to clearly state the position of
> --> the WG with
> --> > respect
> --> > --> to these de fact standards.
> --> >
> --> > Why?  Is it not sufficient to say that the solution must
> --> be compatible
> --> > with existing technologies without listing them all?
> --> >
> --> > -->
> --> > --> Sgai 6> Many customers look at TRILL as a backbone
> --> network. They
> --> would
> --> > --> like to connect their current switches to the TRILL
> --> backbone using
> --> > --> Etherchannel  and connecting the member links on different
> --> RBridges
> --> > for
> --> > --> High availability. Is this a requirement? In general
> --> which is the
> --> > --> relation between Etherchannel and TRILL?
> --> >
> --> > These are good questions, touching on at least one of the
> --> issues that
> --> > has been brought up previously (the "wiring closet problem").
> --> >
> --> > I am not sure that the WG has reached consensus on this.
> --> At present,
> --> > there appears to be a distinct "lean" toward simply
> --> listing the set
> --> > of existing deployment scenarios that may not be directly
> --> supported
> --> > using RBridges in a partial-deployment scenario.
> --> >
> --> > -->
> --> > --> Sgai 7> Does TRILL work properly if Ethernet is deployed
with
> --> Pause
> --> > --> enabled?
> --> > -- [SNIP] --
> -->



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1M1fOV017718 for <[e-mail]>; Wed, 1 Nov 2006 14:01:41 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Nov 2006 14:01:39 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] New shim header proposal---without F-tag field
Thread-Index: Acb9+wsCGTfzHvGbQAyBjoVnjiAotAABRAXg
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, "Russ White" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA1M1fOV017718
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] New shim header proposal---without F-tag field
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 22:02:12 -0000
Status: RO
Content-Length: 4521

Eric, 

This has nothing to do with the connectivity.
I simply read:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
.txt

tell me where I am wrong:
1) there is one IRT per RBridge
2) there is one ISIS LSA per RBridge, i.e. # of RBridge
3) Each RBridge needs to compute Djikstra for all the IRTs, plus one for
the core instance, therefore the number of Djikstra computation is (# of
RBridge + 1)

The total CPU effort to compute Djikstra is therefore (# of Rbridge + 1)
on a LSA database # of Rbridges.

This has nothing to do with the connectivity/topology among the
RBridges.

You should like a lot the last proposal of Radia, because it elegantly
solves this problem for you.

-- Silvano


> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Wednesday, November 01, 2006 1:11 PM
> To: Silvano Gai; Russ White
> Cc: Gray, Eric; Radia Perlman; [e-mail]
> Subject: RE: [rbridge] New shim header proposal---without F-tag field
> 
> Silvano,
> 
> 	I did not actually say that we need to support half a
> million RBridges, I simply said that we may need to support
> more than 32K (or even 64K), consequently I do not support a
> reduction in the "name space" to 16 bits.
> 
> 	It would never work out to an order N^2 connectivity
> in any case, so this concern - IMO - comes under the heading
> of FUD.  If every port needed to be connected to every other
> port, then there would not be a need to have VLANs, and -
> hence - no need to have separate per-VLAN instances.  In a
> real world application where VLANs are used to connect large
> numbers of multi-port switches, only a few ports on a few
> switches typically end up connected to each individual VLAN.
> Some exceptions would occur, but they would be exceptions.
> Thus per-VLAN connectivity would be a sparse partial mesh, or
> VLANs would not be used.
> 
> 	This is in fact part of the justification for having
> per-VLAN IS-IS instances.  Trauma to part of the network is
> only going to impact on routing convergence for the IS-IS
> instances participating in affected VLANs.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[e-mail]]
> --> Sent: Wednesday, November 01, 2006 11:55 AM
> --> To: Russ White
> --> Cc: Gray, Eric; Radia Perlman; [e-mail]
> --> Subject: RE: [rbridge] New shim header proposal---without
> --> F-tag field
> -->
> -->
> --> What is a stretch is 32K trees of 32K nodes, which is what
> --> you need if
> --> you want to deploy the current TRILL proposal with 32K RBridges.
> -->
> --> Eric says that we need to accommodate half a million RBridges.
> --> Half a million tree of half a million nodes is unfeasible.
> -->
> --> If we want to support such a large number of Rbridges, we
> --> need to modify
> --> the current Trill proposal, reducing the number of trees
> --> that need to be
> --> computed.
> -->
> --> Agreed?
> -->
> --> -- Silvano
> -->
> -->
> --> > -----Original Message-----
> --> > From: Russ White [mailto:[e-mail]]
> --> > Sent: Wednesday, November 01, 2006 8:35 AM
> --> > To: Silvano Gai
> --> > Cc: Gray, Eric; Radia Perlman; [e-mail]
> --> > Subject: Re: [rbridge] New shim header proposal---without
> --> F-tag field
> --> >
> --> > -----BEGIN PGP SIGNED MESSAGE-----
> --> > Hash: SHA1
> --> >
> --> >
> --> > >> 	I don't think there is consensus yet that we
> --> only need 16 bits
> --> > >> for RBridge IDs.
> --> > >
> --> > > With 16 bits, using 1 bit to indicate unicast, we can have 32K
> --> switches.
> --> > > According to the current definition of TRILL, there is
> --> the need to
> --> run
> --> > > Djikstra on a database with 32K records, one time for the core
> --> instance
> --> > > and 32K times for the IRTs. This is clearly out of
> --> reach even for
> --> the
> --> > > most powerful CPU.
> --> >
> --> > ?? Perhaps 32k trees is a stretch, but 32k nodes in a
> --> tree? I don't
> --> > think that's really a stretch on today's processors, from
> --> the scaling
> --> > work I've seen done in IS-IS.
> --> >
> --> > :-)
> --> >
> --> > Russ
> --> >
> --> > - --
> --> > [e-mail] CCIE <>< Grace Alone
> --> >
> --> > -----BEGIN PGP SIGNATURE-----
> --> > Version: GnuPG v1.4.2.2 (MingW32)
> --> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> --> >
> --> > iD8DBQFFSMypER27sUhU9OQRAqLwAJ9FLN2YNP2mrB6i0ZcV1fxLzAT0hgCfYHYj
> --> > 6mJCA68nQLjCD8US9nRZZag=
> --> > =kwzq
> --> > -----END PGP SIGNATURE-----
> -->



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1LGnKp004265 for <[e-mail]>; Wed, 1 Nov 2006 13:16:49 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1LBEfK003830; Wed, 1 Nov 2006 16:11:15 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA13422;  Wed, 1 Nov 2006 16:11:14 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647XBZ>; Wed, 1 Nov 2006 16:11:13 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>, Russ White <[e-mail]>
Date: Wed, 1 Nov 2006 16:11:13 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] New shim header proposal---without F-tag field
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 21:17:40 -0000
Status: RO
Content-Length: 3343

Silvano,

	I did not actually say that we need to support half a
million RBridges, I simply said that we may need to support
more than 32K (or even 64K), consequently I do not support a
reduction in the "name space" to 16 bits.

	It would never work out to an order N^2 connectivity 
in any case, so this concern - IMO - comes under the heading
of FUD.  If every port needed to be connected to every other
port, then there would not be a need to have VLANs, and -
hence - no need to have separate per-VLAN instances.  In a
real world application where VLANs are used to connect large
numbers of multi-port switches, only a few ports on a few 
switches typically end up connected to each individual VLAN.
Some exceptions would occur, but they would be exceptions.
Thus per-VLAN connectivity would be a sparse partial mesh, or
VLANs would not be used.

	This is in fact part of the justification for having
per-VLAN IS-IS instances.  Trauma to part of the network is
only going to impact on routing convergence for the IS-IS
instances participating in affected VLANs.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 11:55 AM
--> To: Russ White
--> Cc: Gray, Eric; Radia Perlman; [e-mail]
--> Subject: RE: [rbridge] New shim header proposal---without 
--> F-tag field
--> 
--> 
--> What is a stretch is 32K trees of 32K nodes, which is what 
--> you need if
--> you want to deploy the current TRILL proposal with 32K RBridges.
--> 
--> Eric says that we need to accommodate half a million RBridges.
--> Half a million tree of half a million nodes is unfeasible.
--> 
--> If we want to support such a large number of Rbridges, we 
--> need to modify
--> the current Trill proposal, reducing the number of trees 
--> that need to be
--> computed.
--> 
--> Agreed?
--> 
--> -- Silvano
--> 
--> 
--> > -----Original Message-----
--> > From: Russ White [mailto:[e-mail]]
--> > Sent: Wednesday, November 01, 2006 8:35 AM
--> > To: Silvano Gai
--> > Cc: Gray, Eric; Radia Perlman; [e-mail]
--> > Subject: Re: [rbridge] New shim header proposal---without 
--> F-tag field
--> > 
--> > -----BEGIN PGP SIGNED MESSAGE-----
--> > Hash: SHA1
--> > 
--> > 
--> > >> 	I don't think there is consensus yet that we 
--> only need 16 bits
--> > >> for RBridge IDs.
--> > >
--> > > With 16 bits, using 1 bit to indicate unicast, we can have 32K
--> switches.
--> > > According to the current definition of TRILL, there is 
--> the need to
--> run
--> > > Djikstra on a database with 32K records, one time for the core
--> instance
--> > > and 32K times for the IRTs. This is clearly out of 
--> reach even for
--> the
--> > > most powerful CPU.
--> > 
--> > ?? Perhaps 32k trees is a stretch, but 32k nodes in a 
--> tree? I don't
--> > think that's really a stretch on today's processors, from 
--> the scaling
--> > work I've seen done in IS-IS.
--> > 
--> > :-)
--> > 
--> > Russ
--> > 
--> > - --
--> > [e-mail] CCIE <>< Grace Alone
--> > 
--> > -----BEGIN PGP SIGNATURE-----
--> > Version: GnuPG v1.4.2.2 (MingW32)
--> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--> > 
--> > iD8DBQFFSMypER27sUhU9OQRAqLwAJ9FLN2YNP2mrB6i0ZcV1fxLzAT0hgCfYHYj
--> > 6mJCA68nQLjCD8US9nRZZag=
--> > =kwzq
--> > -----END PGP SIGNATURE-----
--> 


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1KZ9Fr021365 for <[e-mail]>; Wed, 1 Nov 2006 12:35:09 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 01 Nov 2006 12:35:09 -0800 (PST)
Received: from sun.com ([129.150.22.255]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Wed, 01 Nov 2006 12:35:09 -0800 (PST)
Date: Wed, 01 Nov 2006 12:35:08 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Gray, Eric" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between	com putation and optimality of delivery
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 20:35:29 -0000
Status: RO
Content-Length: 7853

No. I'm talking about a bidirectional tree. Just like with the spanning 
tree computed by legacy bridges,
packets don't traverse links twice. A particular bridge B has a root 
port and other ports for which it is DB.
On the ports for which B is DB, B sends the frame and it travels further 
from the root on those paths.
It's only on the root port that the frame travels towards the root, and 
then when the root
receives the frame, it only sends the frame onto other ports (not the 
one it got it from).

Radia



Gray, Eric wrote:

>If you're assuming a shared tree with a common root (not in the sense
>that STP defines root, but in the sense that an IRT is computed from
>this root to all egress RBridges), then all multicast, broadcast and
>flooded traffic has first to be delivered to this "root" before it
>can be delivered anywhere else.
>
>Is that not what you mean?
>
>If it has to be delivered first to the root, then it is very likely 
>that frames will traverse a link going toward the root, and will use
>one or more of the same link(s) in being delivered to egress RBridges.
>
>--
>Eric
>
>--> -----Original Message-----
>--> From: [e-mail] [mailto:[e-mail]] 
>--> Sent: Wednesday, November 01, 2006 3:19 PM
>--> To: Gray, Eric
>--> Cc: [e-mail]
>--> Subject: Re: [rbridge] Compromise proposal---allowing 
>--> tradeoff between com putation and optimality of delivery
>--> 
>--> 1) Yeah, options are better avoided if possible. But 
>--> they're not too bad as long as there
>--> are reasonable defaults, and no way to screw up by setting 
>--> things differently at different RBridges.
>--> 
>--> 2) Traffic should not traverse any link more than once no 
>--> matter which tree is being used. Or am I confused?
>--> 
>--> 3) Right. Choosing which n RBridges get to be roots based 
>--> on MAC addresses is arbitrary. I just wanted
>--> a simple tie breaker so all the RBridges compute the same 
>--> trees. For DR election there's a priority
>--> field that is used as the most significant byte of the 
>--> address. We could do the same thing here. Rather than
>--> a flag saying "I want to be a root", there can be, say, a 1 
>--> byte TLV in the link state packet saying "my priority
>--> for being a tree root is x". If the TLV is not there at all 
>--> then it means "I don't want to be a root at all, unless
>--> there are no other volunteers and I happen to be the lowest 
>--> MAC address". Otherwise, the n RBridges
>--> with the highest ( root priority | MAC ) get chosen.
>--> 
>--> Radia
>--> 
>--> ----- Original Message -----
>--> From: "Gray, Eric" <[e-mail]>
>--> Date: Wednesday, November 1, 2006 11:51 am
>--> Subject: Re: [rbridge] Compromise proposal---allowing 
>--> tradeoff between	com putation and optimality of delivery
>--> 
>--> > Radia,
>--> > 
>--> > 	There are three problems with this proposal: 1) the general
>--> > problem associated with having options, 2) the fact that 
>--> it is not 
>--> > consistent with the idea of trying to utilize links more fully if 
>--> > the approach may require traffic to traverse the same links more
>--> > than one time, and 3) there is nothing about a low MAC 
>--> address that
>--> > has anything to do with the suitability of a particular RBridge to
>--> > act as the root for a shared tree. 
>--> > 
>--> > 	I think there are other ways to allow for an optional server
>--> > for broadcast/multicast/flooding distribution than to complicate
>--> > the TRILL protocol with optional implementation alternatives like
>--> > this proposal seems to suggest.  Part of the complication - at a
>--> > minimum - is the need to provide for a neogitation mechanism with
>--> > one or more tunable parameters for determing a primary, 
>--> and one or 
>--> > more secondary, roots for the shared tree.
>--> > 
>--> > --
>--> > Eric
>--> > 
>--> > --> -----Original Message-----
>--> > --> From: [e-mail] 
>--> > --> [[e-mail]] On Behalf Of Radia Perlman
>--> > --> Sent: Wednesday, November 01, 2006 1:43 PM
>--> > --> To: [e-mail]
>--> > --> Subject: [rbridge] Compromise proposal---allowing tradeoff 
>--> > --> between computation and optimality of delivery
>--> > --> 
>--> > --> There is understandable nervousness about the need to compute
>--> > --> per-ingress trees for every RBridge, and optimality 
>--> of delivery.
>--> > --> I actually was dubious about whether people *really* wanted
>--> > --> to have to compute per-ingress trees.
>--> > --> 
>--> > --> Here's a proposal that will allow tradeoff between overhead of
>--> > --> computation and optimality of delivery. If people really want
>--> > --> they can have RBridges compute trees rooted at every 
>--> > --> RBridge. Or they
>--> > --> can have all multicast delivered on a single shared tree. 
>--> > --> Or anything in 
>--> > --> between.
>--> > --> I'm arbitrarily picking the zero configuration option being 
>--> > --> a single tree.
>--> > --> 
>--> > --> The new shim format allows the ingress RBridge to specify the
>--> > --> distribution tree for multicast, by putting into the 
>--> > --> "egress RBridge"
>--> > --> field a tree rooted at at the specified RBridge.
>--> > --> 
>--> > --> In this proposal, by default, the only tree that will be 
>--> > --> computed is a 
>--> > --> single shared
>--> > --> tree rooted at the RBridge with smallest MAC address. 
>--> Let's say 
>--> > that--> RBridge has nickname "71". By specifying 71 as egress 
>--> > RBridge in
>--> > --> a multicast packet, the delivery path will be via the 
>--> > bidirectional--> tree rooted at 71.
>--> > --> 
>--> > --> An RBridge can be configured to demand that it, too, be the 
>--> > root of
>--> > --> a tree, and it informs the other RBridges with a flag in 
>--> > --> its link state
>--> > --> packet.
>--> > --> 
>--> > --> So now we have a subset of RBridges that can be used as 
>--> > --> roots of trees, 
>--> > --> because
>--> > --> they have specified that in their link state packet.
>--> > --> Let's say that RBridges with nicknames 11, 15, 71, 
>--> 222, and 259 
>--> > all--> have announced that they want to be roots of trees.
>--> > --> 
>--> > --> Then an ingress RBridge, say R2, with nickname 11, can send a
>--> > --> multicast/unknown destination packet with 
>--> "ingress"=11 (its own)
>--> > --> and "egress"=11 (because it said it wanted to be a root). 
>--> > --> Or it could
>--> > --> choose any of the other potential ones (15, 71, 222, 259).
>--> > --> 
>--> > --> Likewise, an ingress RBridge, say R3, with nickname 
>--> 13, who has
>--> > --> not requested to be the root of a tree, can specify only
>--> > --> the trees 11, 15, 71, 222, 259. Note it cannot specify 
>--> > --> "13", since we
>--> > --> are assuming it has not requested that all RBridges 
>--> > --> calculate a tree 
>--> > --> rooted at itself.
>--> > --> 
>--> > --> If no RBridges are configured to say they want to be the root,
>--> > --> then only a single tree will get computed---the one rooted
>--> > --> at 71.
>--> > --> 
>--> > --> So the zero configuration option is a single shared tree 
>--> > --> (still filtered
>--> > --> based on IP multicast announcements and VLANs) rooted at 
>--> > --> the RBridge with
>--> > --> smallest MAC address. But by configuration, more and more 
>--> > optimality--> can be introduced by having RBridges 
>--> compute more trees.
>--> > --> 
>--> > --> Radia
>--> > --> 
>--> > --> _______________________________________________
>--> > --> rbridge mailing list
>--> > --> [e-mail]
>--> > --> http://mailman.postel.org/mailman/listinfo/rbridge
>--> > --> 
>--> > _______________________________________________
>--> > rbridge mailing list
>--> > [e-mail]
>--> > http://mailman.postel.org/mailman/listinfo/rbridge
>--> > 
>--> 
>  
>



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1KOH6L016940 for <[e-mail]>; Wed, 1 Nov 2006 12:24:17 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1KOGfK003100; Wed, 1 Nov 2006 15:24:16 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA10508;  Wed, 1 Nov 2006 15:24:16 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647W2B>; Wed, 1 Nov 2006 15:24:15 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: [e-mail]
Date: Wed, 1 Nov 2006 15:24:15 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between	com	 putation and optimality of delivery
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 20:24:50 -0000
Status: RO
Content-Length: 7141

If you're assuming a shared tree with a common root (not in the sense
that STP defines root, but in the sense that an IRT is computed from
this root to all egress RBridges), then all multicast, broadcast and
flooded traffic has first to be delivered to this "root" before it
can be delivered anywhere else.

Is that not what you mean?

If it has to be delivered first to the root, then it is very likely 
that frames will traverse a link going toward the root, and will use
one or more of the same link(s) in being delivered to egress RBridges.

--
Eric

--> -----Original Message-----
--> From: [e-mail] [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 3:19 PM
--> To: Gray, Eric
--> Cc: [e-mail]
--> Subject: Re: [rbridge] Compromise proposal---allowing 
--> tradeoff between com putation and optimality of delivery
--> 
--> 1) Yeah, options are better avoided if possible. But 
--> they're not too bad as long as there
--> are reasonable defaults, and no way to screw up by setting 
--> things differently at different RBridges.
--> 
--> 2) Traffic should not traverse any link more than once no 
--> matter which tree is being used. Or am I confused?
--> 
--> 3) Right. Choosing which n RBridges get to be roots based 
--> on MAC addresses is arbitrary. I just wanted
--> a simple tie breaker so all the RBridges compute the same 
--> trees. For DR election there's a priority
--> field that is used as the most significant byte of the 
--> address. We could do the same thing here. Rather than
--> a flag saying "I want to be a root", there can be, say, a 1 
--> byte TLV in the link state packet saying "my priority
--> for being a tree root is x". If the TLV is not there at all 
--> then it means "I don't want to be a root at all, unless
--> there are no other volunteers and I happen to be the lowest 
--> MAC address". Otherwise, the n RBridges
--> with the highest ( root priority | MAC ) get chosen.
--> 
--> Radia
--> 
--> ----- Original Message -----
--> From: "Gray, Eric" <[e-mail]>
--> Date: Wednesday, November 1, 2006 11:51 am
--> Subject: Re: [rbridge] Compromise proposal---allowing 
--> tradeoff between	com putation and optimality of delivery
--> 
--> > Radia,
--> > 
--> > 	There are three problems with this proposal: 1) the general
--> > problem associated with having options, 2) the fact that 
--> it is not 
--> > consistent with the idea of trying to utilize links more fully if 
--> > the approach may require traffic to traverse the same links more
--> > than one time, and 3) there is nothing about a low MAC 
--> address that
--> > has anything to do with the suitability of a particular RBridge to
--> > act as the root for a shared tree. 
--> > 
--> > 	I think there are other ways to allow for an optional server
--> > for broadcast/multicast/flooding distribution than to complicate
--> > the TRILL protocol with optional implementation alternatives like
--> > this proposal seems to suggest.  Part of the complication - at a
--> > minimum - is the need to provide for a neogitation mechanism with
--> > one or more tunable parameters for determing a primary, 
--> and one or 
--> > more secondary, roots for the shared tree.
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: [e-mail] 
--> > --> [[e-mail]] On Behalf Of Radia Perlman
--> > --> Sent: Wednesday, November 01, 2006 1:43 PM
--> > --> To: [e-mail]
--> > --> Subject: [rbridge] Compromise proposal---allowing tradeoff 
--> > --> between computation and optimality of delivery
--> > --> 
--> > --> There is understandable nervousness about the need to compute
--> > --> per-ingress trees for every RBridge, and optimality 
--> of delivery.
--> > --> I actually was dubious about whether people *really* wanted
--> > --> to have to compute per-ingress trees.
--> > --> 
--> > --> Here's a proposal that will allow tradeoff between overhead of
--> > --> computation and optimality of delivery. If people really want
--> > --> they can have RBridges compute trees rooted at every 
--> > --> RBridge. Or they
--> > --> can have all multicast delivered on a single shared tree. 
--> > --> Or anything in 
--> > --> between.
--> > --> I'm arbitrarily picking the zero configuration option being 
--> > --> a single tree.
--> > --> 
--> > --> The new shim format allows the ingress RBridge to specify the
--> > --> distribution tree for multicast, by putting into the 
--> > --> "egress RBridge"
--> > --> field a tree rooted at at the specified RBridge.
--> > --> 
--> > --> In this proposal, by default, the only tree that will be 
--> > --> computed is a 
--> > --> single shared
--> > --> tree rooted at the RBridge with smallest MAC address. 
--> Let's say 
--> > that--> RBridge has nickname "71". By specifying 71 as egress 
--> > RBridge in
--> > --> a multicast packet, the delivery path will be via the 
--> > bidirectional--> tree rooted at 71.
--> > --> 
--> > --> An RBridge can be configured to demand that it, too, be the 
--> > root of
--> > --> a tree, and it informs the other RBridges with a flag in 
--> > --> its link state
--> > --> packet.
--> > --> 
--> > --> So now we have a subset of RBridges that can be used as 
--> > --> roots of trees, 
--> > --> because
--> > --> they have specified that in their link state packet.
--> > --> Let's say that RBridges with nicknames 11, 15, 71, 
--> 222, and 259 
--> > all--> have announced that they want to be roots of trees.
--> > --> 
--> > --> Then an ingress RBridge, say R2, with nickname 11, can send a
--> > --> multicast/unknown destination packet with 
--> "ingress"=11 (its own)
--> > --> and "egress"=11 (because it said it wanted to be a root). 
--> > --> Or it could
--> > --> choose any of the other potential ones (15, 71, 222, 259).
--> > --> 
--> > --> Likewise, an ingress RBridge, say R3, with nickname 
--> 13, who has
--> > --> not requested to be the root of a tree, can specify only
--> > --> the trees 11, 15, 71, 222, 259. Note it cannot specify 
--> > --> "13", since we
--> > --> are assuming it has not requested that all RBridges 
--> > --> calculate a tree 
--> > --> rooted at itself.
--> > --> 
--> > --> If no RBridges are configured to say they want to be the root,
--> > --> then only a single tree will get computed---the one rooted
--> > --> at 71.
--> > --> 
--> > --> So the zero configuration option is a single shared tree 
--> > --> (still filtered
--> > --> based on IP multicast announcements and VLANs) rooted at 
--> > --> the RBridge with
--> > --> smallest MAC address. But by configuration, more and more 
--> > optimality--> can be introduced by having RBridges 
--> compute more trees.
--> > --> 
--> > --> Radia
--> > --> 
--> > --> _______________________________________________
--> > --> rbridge mailing list
--> > --> [e-mail]
--> > --> http://mailman.postel.org/mailman/listinfo/rbridge
--> > --> 
--> > _______________________________________________
--> > rbridge mailing list
--> > [e-mail]
--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> > 
--> 


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1KJCox014864 for <[e-mail]>; Wed, 1 Nov 2006 12:19:12 -0800 (PST)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 01 Nov 2006 12:19:12 -0800 (PST)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 01 Nov 2006 12:19:11 -0800 (PST)
Received: from [152.70.2.164] (Forwarded-For: [67.160.72.180]) by mail-srv.sfvic.sunlabs.com (mshttpd); Wed, 01 Nov 2006 12:19:11 -0800
Date: Wed, 01 Nov 2006 12:19:11 -0800
From: [e-mail]
To: "Gray, Eric" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between	com putation and optimality of delivery
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 20:19:36 -0000
Status: RO
Content-Length: 5662

1) Yeah, options are better avoided if possible. But they're not too bad as long as there
are reasonable defaults, and no way to screw up by setting things differently at different RBridges.

2) Traffic should not traverse any link more than once no matter which tree is being used. Or am I confused?

3) Right. Choosing which n RBridges get to be roots based on MAC addresses is arbitrary. I just wanted
a simple tie breaker so all the RBridges compute the same trees. For DR election there's a priority
field that is used as the most significant byte of the address. We could do the same thing here. Rather than
a flag saying "I want to be a root", there can be, say, a 1 byte TLV in the link state packet saying "my priority
for being a tree root is x". If the TLV is not there at all then it means "I don't want to be a root at all, unless
there are no other volunteers and I happen to be the lowest MAC address". Otherwise, the n RBridges
with the highest ( root priority | MAC ) get chosen.

Radia

----- Original Message -----
From: "Gray, Eric" <[e-mail]>
Date: Wednesday, November 1, 2006 11:51 am
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between	com putation and optimality of delivery

> Radia,
> 
> 	There are three problems with this proposal: 1) the general
> problem associated with having options, 2) the fact that it is not 
> consistent with the idea of trying to utilize links more fully if 
> the approach may require traffic to traverse the same links more
> than one time, and 3) there is nothing about a low MAC address that
> has anything to do with the suitability of a particular RBridge to
> act as the root for a shared tree. 
> 
> 	I think there are other ways to allow for an optional server
> for broadcast/multicast/flooding distribution than to complicate
> the TRILL protocol with optional implementation alternatives like
> this proposal seems to suggest.  Part of the complication - at a
> minimum - is the need to provide for a neogitation mechanism with
> one or more tunable parameters for determing a primary, and one or 
> more secondary, roots for the shared tree.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [e-mail] 
> --> [[e-mail]] On Behalf Of Radia Perlman
> --> Sent: Wednesday, November 01, 2006 1:43 PM
> --> To: [e-mail]
> --> Subject: [rbridge] Compromise proposal---allowing tradeoff 
> --> between computation and optimality of delivery
> --> 
> --> There is understandable nervousness about the need to compute
> --> per-ingress trees for every RBridge, and optimality of delivery.
> --> I actually was dubious about whether people *really* wanted
> --> to have to compute per-ingress trees.
> --> 
> --> Here's a proposal that will allow tradeoff between overhead of
> --> computation and optimality of delivery. If people really want
> --> they can have RBridges compute trees rooted at every 
> --> RBridge. Or they
> --> can have all multicast delivered on a single shared tree. 
> --> Or anything in 
> --> between.
> --> I'm arbitrarily picking the zero configuration option being 
> --> a single tree.
> --> 
> --> The new shim format allows the ingress RBridge to specify the
> --> distribution tree for multicast, by putting into the 
> --> "egress RBridge"
> --> field a tree rooted at at the specified RBridge.
> --> 
> --> In this proposal, by default, the only tree that will be 
> --> computed is a 
> --> single shared
> --> tree rooted at the RBridge with smallest MAC address. Let's say 
> that--> RBridge has nickname "71". By specifying 71 as egress 
> RBridge in
> --> a multicast packet, the delivery path will be via the 
> bidirectional--> tree rooted at 71.
> --> 
> --> An RBridge can be configured to demand that it, too, be the 
> root of
> --> a tree, and it informs the other RBridges with a flag in 
> --> its link state
> --> packet.
> --> 
> --> So now we have a subset of RBridges that can be used as 
> --> roots of trees, 
> --> because
> --> they have specified that in their link state packet.
> --> Let's say that RBridges with nicknames 11, 15, 71, 222, and 259 
> all--> have announced that they want to be roots of trees.
> --> 
> --> Then an ingress RBridge, say R2, with nickname 11, can send a
> --> multicast/unknown destination packet with "ingress"=11 (its own)
> --> and "egress"=11 (because it said it wanted to be a root). 
> --> Or it could
> --> choose any of the other potential ones (15, 71, 222, 259).
> --> 
> --> Likewise, an ingress RBridge, say R3, with nickname 13, who has
> --> not requested to be the root of a tree, can specify only
> --> the trees 11, 15, 71, 222, 259. Note it cannot specify 
> --> "13", since we
> --> are assuming it has not requested that all RBridges 
> --> calculate a tree 
> --> rooted at itself.
> --> 
> --> If no RBridges are configured to say they want to be the root,
> --> then only a single tree will get computed---the one rooted
> --> at 71.
> --> 
> --> So the zero configuration option is a single shared tree 
> --> (still filtered
> --> based on IP multicast announcements and VLANs) rooted at 
> --> the RBridge with
> --> smallest MAC address. But by configuration, more and more 
> optimality--> can be introduced by having RBridges compute more trees.
> --> 
> --> Radia
> --> 
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1K5QgY008998 for <[e-mail]>; Wed, 1 Nov 2006 12:05:26 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 01 Nov 2006 12:05:24 -0800 (PST)
Received: from sun.com ([129.150.22.255]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Wed, 01 Nov 2006 12:05:24 -0800 (PST)
Date: Wed, 01 Nov 2006 12:05:23 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Sanjay Sane (sanjays)" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between computation and optimality of delivery
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 20:05:49 -0000
Status: RO
Content-Length: 5492

If the header already has "ingress" and "egress" RBridge nicknames for 
unicast, then there
doesn't seem to be a reason to try to have a different nickname to 
identify the tree.
Using the already computed nickname seems simplest.

As for Ayan's questions:
a) can we assume that the list of trees is ordered and consistent:

Yes---that's the idea. The tree is specified by who is the root, and 
there needs to be deterministic
tie breakers so all RBridges calculate the same tree.

b) is it possible to have a TLV that indicates how many trees an RBridge 
is willing to compute

That seems like a good idea, though there needs to be some reasonable 
default so that RBridges
work reasonably well with zero configuration. Should the default be 1 
tree? Or 100?

So to make your proposal clear---each RBridge announces in its link 
state packet "I can support
n trees". The number of trees allowed would be the smallest n announced 
by any RBridge. If
more than n RBridges ask to be roots of trees, then the n RBridges with 
smallest MAC addresses
are roots.

There are other alternatives, similar to the "overloaded" flag. An 
RBridge that can't support
as many trees as requested could set a "overloaded with multicast trees" 
flag, and then
other RBridges could compute trees avoiding that guy. But this seems 
more complicated than
just doing what you suggest.

Radia




Sanjay Sane (sanjays) wrote:

>This proposal sounds good to me, with one exception. 
>
>If we don't expect the number of trees to be equal to the number of
>rbridges, why have the tree identifier from the same number-space as of
>rbridge-nickname ? 
>
>Rbridge nickname space is 16 bits = 64K combinations. Its not practical
>to scale to these many "trees". If the "tree-identifier" space is
>different (say 10 bits - max 1k combinations) than the rbridge nickname
>space, hardware resources can be optimized. 
>
>To optimize the fields in the shim header, its ok to carry this
>tree-identifier in the egress rbridge id field (as per your latest SHIM
>header proposal). 
>
>Yes, this would mean another "dynamic assignment" process to assign the
>"tree-identifier". Whichever rbridge is configured/chosen to become the
>root of a tree, first participates in the "dynamic assignment" process,
>gets itself assigned a "tree-identifier", and then informs the other
>RBridges with some information in its link state packet - indicating 2
>things
>1. flag suggesting it wants to be a root of a tree 
>2. "tree-identifier" to be used for the tree computed with itself as the
>root. 
>
>-Sanjay
>
>
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
>Behalf Of Radia Perlman
>Sent: Wednesday, November 01, 2006 10:43 AM
>To: [e-mail]
>Subject: [rbridge] Compromise proposal---allowing tradeoff between
>computation and optimality of delivery
>
>There is understandable nervousness about the need to compute
>per-ingress trees for every RBridge, and optimality of delivery.
>I actually was dubious about whether people *really* wanted to have to
>compute per-ingress trees.
>
>Here's a proposal that will allow tradeoff between overhead of
>computation and optimality of delivery. If people really want they can
>have RBridges compute trees rooted at every RBridge. Or they can have
>all multicast delivered on a single shared tree. Or anything in between.
>I'm arbitrarily picking the zero configuration option being a single
>tree.
>
>The new shim format allows the ingress RBridge to specify the
>distribution tree for multicast, by putting into the "egress RBridge"
>field a tree rooted at at the specified RBridge.
>
>In this proposal, by default, the only tree that will be computed is a
>single shared tree rooted at the RBridge with smallest MAC address.
>Let's say that RBridge has nickname "71". By specifying 71 as egress
>RBridge in a multicast packet, the delivery path will be via the
>bidirectional tree rooted at 71.
>
>An RBridge can be configured to demand that it, too, be the root of a
>tree, and it informs the other RBridges with a flag in its link state
>packet.
>
>So now we have a subset of RBridges that can be used as roots of trees,
>because they have specified that in their link state packet.
>Let's say that RBridges with nicknames 11, 15, 71, 222, and 259 all have
>announced that they want to be roots of trees.
>
>Then an ingress RBridge, say R2, with nickname 11, can send a
>multicast/unknown destination packet with "ingress"=11 (its own) and
>"egress"=11 (because it said it wanted to be a root). Or it could choose
>any of the other potential ones (15, 71, 222, 259).
>
>Likewise, an ingress RBridge, say R3, with nickname 13, who has not
>requested to be the root of a tree, can specify only the trees 11, 15,
>71, 222, 259. Note it cannot specify "13", since we are assuming it has
>not requested that all RBridges calculate a tree rooted at itself.
>
>If no RBridges are configured to say they want to be the root, then only
>a single tree will get computed---the one rooted at 71.
>
>So the zero configuration option is a single shared tree (still filtered
>based on IP multicast announcements and VLANs) rooted at the RBridge
>with smallest MAC address. But by configuration, more and more
>optimality can be introduced by having RBridges compute more trees.
>
>Radia
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1JwhVw006174 for <[e-mail]>; Wed, 1 Nov 2006 11:58:43 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1JwefK002691; Wed, 1 Nov 2006 14:58:40 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA08858;  Wed, 1 Nov 2006 14:58:40 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647VYW>; Wed, 1 Nov 2006 14:58:39 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>
Date: Wed, 1 Nov 2006 14:58:38 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Last Call comment on: http://www.ietf.org/internet-	drafts/draft-ietf-trill-prob-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 19:59:26 -0000
Status: RO
Content-Length: 6086

Silvano,

	I think that - with some minor exceptions - these are quite 
reasonable terminology change proposals over-all.  In particular, 
the idea of using frames to represent L2 PDUs is one that has been 
suggested before. 

	I suspect that we will need to expand the definition, or give
a definition, for the term "node" to indicate that this term is 
meant to include the conceptual idea of a "station" as defined for
the IEEE.

	On the term "cache," this is generally a well understood term
in this context and whether or not filtering database is more correct
is something that may have to be considered on a case-by-case basis.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Saturday, October 28, 2006 10:59 AM
--> To: Gray, Eric
--> Cc: [e-mail]
--> Subject: RE: [rbridge] Last Call comment on: 
--> http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-01.txt
--> 
--> 
--> Per Eric request, this is the terminology changes I 
--> propose, to align
--> these documents with a layer two terminology:
--> 
--> Packet -> frame
--> In IEEE 802.1D the term packet means something at higher 
--> level (IP and
--> above)
--> 
--> Autolearning -> learning
--> 
--> Cache -> filtering database
--> The term filtering database is consistently used to 
--> indicate that a hit
--> on the database limit the frame propagation, while a miss causes
--> flooding (this is a different behavior from a forwarding 
--> database, where
--> a miss causes a drop).
--> 
--> I am not sure about the term "Port autolearning" used in 
--> the draft, can
--> you clarify the meaning?
--> 
--> IEEE speaks about stations, this may be the most 
--> controversial change,
--> but we need to settle on a single term.
--> Node -> station
--> Endnode -> station
--> Host -> station
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[e-mail]]
--> > Sent: Friday, October 27, 2006 10:59 AM
--> > To: Silvano Gai
--> > Cc: [e-mail]
--> > Subject: RE: [rbridge] Last Call comment on:
--> http://www.ietf.org/internet-
--> > drafts/draft-ietf-trill-prob-01.txt
--> > 
--> > Silvano, et al,
--> > 
--> > 	 Please see below.
--> > 
--> > -- [SNIP] --
--> > --> I don't think it is acceptable to have temporary loop for
--> broadcast
--> > --> multicast, even if they are mitigated by TTL. An interlock
--> mechanism
--> > --> similar to ST must be used for multicast/broadcast.
--> > -->
--> > --> I ask for a strong requirement that says: "TRILL MUST avoid
--> > --> multicast/broadcast storms"
--> > 
--> > I completely agree with this and I have been assuming an 
--> "interlock"
--> > function would be applied - especially for non-unicast or unknown
--> > frames.
--> > 
--> > In retrospect, it is obvious that this should be 
--> explicitly spelled
--> > out.
--> > 
--> > -->
--> > --> Sgai 2> ST provides symmetrical forwarding, i.e. the 
--> path from A
--> to B
--> > is
--> > --> the reverse of the path from B to A. Is this a requirement for
--> TRILL?
--> > 
--> > I believe this has certainly been assumed in discussions, but it
--> > might not have been deemed necessary to explicitly include this
--> > as a "requirement" in the PA&S document.  It is a behavior that
--> > applies to existing 802.1D bridges and we are required to be
--> > compatible with 802.1D bridges.
--> > 
--> > -->
--> > --> Sgai 3> the terminology used in this draft is not the 
--> one used in
--> IEEE
--> > --> standards. This makes it difficult to understand what certain
--> > sentences
--> > --> really mean. Concepts like autolearning and caches 
--> are not IEEE
--> > concepts.
--> > 
--> > This observation has been made before.  Can you make specific
--> > proposals for textual changes (replace "XYZ" with "LMNOP")?
--> > 
--> > -->
--> > --> Sgai 4> There is no mention of the applicability of other
--> important
--> > IEEE
--> > --> standards/WG/Study Groups, e.g.
--> > --> - 802.3ad-2000, Link Aggregation.
--> > --> - 802.1ah - Provider Backbone Bridges
--> > --> - 802.1aq - Shortest Path Bridging
--> > --> - 802.1au - Congestion Notification
--> > --> - 802.1ad - Provider Bridges
--> > --> - 802.1AE - MAC Security
--> > --> - 802.3ar - Congestion Management Task Force.
--> > --> - 802.3as - Frame Expansion Task Force.
--> > --> I think this document needs to clearly state the 
--> position of the
--> WG
--> > with
--> > --> respect to these projects.
--> > -->
--> > --> Sgai 5> I also think there need to be a mention of the
--> applicability
--> > of
--> > --> important industrial efforts:
--> > --> - NIC Teaming
--> > --> - uplinkfast
--> > --> - split-MLT
--> > --> - Q in Q
--> > --> All these are widely deployed in all 
--> datacenters/enterprises. I
--> think
--> > --> this document needs to clearly state the position of 
--> the WG with
--> > respect
--> > --> to these de fact standards.
--> > 
--> > Why?  Is it not sufficient to say that the solution must 
--> be compatible
--> > with existing technologies without listing them all?
--> > 
--> > -->
--> > --> Sgai 6> Many customers look at TRILL as a backbone 
--> network. They
--> would
--> > --> like to connect their current switches to the TRILL 
--> backbone using
--> > --> Etherchannel  and connecting the member links on different
--> RBridges
--> > for
--> > --> High availability. Is this a requirement? In general 
--> which is the
--> > --> relation between Etherchannel and TRILL?
--> > 
--> > These are good questions, touching on at least one of the 
--> issues that
--> > has been brought up previously (the "wiring closet problem").
--> > 
--> > I am not sure that the WG has reached consensus on this.  
--> At present,
--> > there appears to be a distinct "lean" toward simply 
--> listing the set
--> > of existing deployment scenarios that may not be directly 
--> supported
--> > using RBridges in a partial-deployment scenario.
--> > 
--> > -->
--> > --> Sgai 7> Does TRILL work properly if Ethernet is deployed with
--> Pause
--> > --> enabled?
--> > -- [SNIP] --
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1Jpbhh003754 for <[e-mail]>; Wed, 1 Nov 2006 11:51:38 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1JpafK002599; Wed, 1 Nov 2006 14:51:37 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA08531;  Wed, 1 Nov 2006 14:51:36 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647VVV>; Wed, 1 Nov 2006 14:51:35 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Radia Perlman <[e-mail]>
Date: Wed, 1 Nov 2006 14:51:34 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between com	putation and optimality of delivery
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 19:51:48 -0000
Status: RO
Content-Length: 4078

Radia,

	There are three problems with this proposal: 1) the general
problem associated with having options, 2) the fact that it is not 
consistent with the idea of trying to utilize links more fully if 
the approach may require traffic to traverse the same links more
than one time, and 3) there is nothing about a low MAC address that
has anything to do with the suitability of a particular RBridge to
act as the root for a shared tree. 

	I think there are other ways to allow for an optional server
for broadcast/multicast/flooding distribution than to complicate
the TRILL protocol with optional implementation alternatives like
this proposal seems to suggest.  Part of the complication - at a
minimum - is the need to provide for a neogitation mechanism with
one or more tunable parameters for determing a primary, and one or 
more secondary, roots for the shared tree.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Radia Perlman
--> Sent: Wednesday, November 01, 2006 1:43 PM
--> To: [e-mail]
--> Subject: [rbridge] Compromise proposal---allowing tradeoff 
--> between computation and optimality of delivery
--> 
--> There is understandable nervousness about the need to compute
--> per-ingress trees for every RBridge, and optimality of delivery.
--> I actually was dubious about whether people *really* wanted
--> to have to compute per-ingress trees.
--> 
--> Here's a proposal that will allow tradeoff between overhead of
--> computation and optimality of delivery. If people really want
--> they can have RBridges compute trees rooted at every 
--> RBridge. Or they
--> can have all multicast delivered on a single shared tree. 
--> Or anything in 
--> between.
--> I'm arbitrarily picking the zero configuration option being 
--> a single tree.
--> 
--> The new shim format allows the ingress RBridge to specify the
--> distribution tree for multicast, by putting into the 
--> "egress RBridge"
--> field a tree rooted at at the specified RBridge.
--> 
--> In this proposal, by default, the only tree that will be 
--> computed is a 
--> single shared
--> tree rooted at the RBridge with smallest MAC address. Let's say that
--> RBridge has nickname "71". By specifying 71 as egress RBridge in
--> a multicast packet, the delivery path will be via the bidirectional
--> tree rooted at 71.
--> 
--> An RBridge can be configured to demand that it, too, be the root of
--> a tree, and it informs the other RBridges with a flag in 
--> its link state
--> packet.
--> 
--> So now we have a subset of RBridges that can be used as 
--> roots of trees, 
--> because
--> they have specified that in their link state packet.
--> Let's say that RBridges with nicknames 11, 15, 71, 222, and 259 all
--> have announced that they want to be roots of trees.
--> 
--> Then an ingress RBridge, say R2, with nickname 11, can send a
--> multicast/unknown destination packet with "ingress"=11 (its own)
--> and "egress"=11 (because it said it wanted to be a root). 
--> Or it could
--> choose any of the other potential ones (15, 71, 222, 259).
--> 
--> Likewise, an ingress RBridge, say R3, with nickname 13, who has
--> not requested to be the root of a tree, can specify only
--> the trees 11, 15, 71, 222, 259. Note it cannot specify 
--> "13", since we
--> are assuming it has not requested that all RBridges 
--> calculate a tree 
--> rooted at itself.
--> 
--> If no RBridges are configured to say they want to be the root,
--> then only a single tree will get computed---the one rooted
--> at 71.
--> 
--> So the zero configuration option is a single shared tree 
--> (still filtered
--> based on IP multicast announcements and VLANs) rooted at 
--> the RBridge with
--> smallest MAC address. But by configuration, more and more optimality
--> can be introduced by having RBridges compute more trees.
--> 
--> Radia
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1JUSFH025770 for <[e-mail]>; Wed, 1 Nov 2006 11:30:28 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1JUOfK002179; Wed, 1 Nov 2006 14:30:24 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA07044;  Wed, 1 Nov 2006 14:30:24 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647VHC>; Wed, 1 Nov 2006 14:30:23 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "Wadekar, Manoj K" <[e-mail]>
Date: Wed, 1 Nov 2006 14:30:22 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Comments on:http://www.ietf.org/internet-drafts/dr		aft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 19:30:57 -0000
Status: RO
Content-Length: 3497

Manoj,

	Note that the proposed revision does not refer to 802, but
offers 802.3 and 802.1Q as specific examples of intentionally 
included "Ethernet-like" technologies.

	Actually, after looking into some IETF-related references, 
I'm not convinced I am "re-defining" the term Ethernet.  What I am
doing, that might be a little unusual, is being specific about how
I am using the term.

	Look, for example, at my reference [10].  This reference is
from 1982, and remains reasonably accurate in part because it does
not attempt to narrow the scope of what it means by "Ethernet."

	An alternative approach is to not define Ethernet in this 
document at all, and replace every instance of the word "Ethernet"
with "Ethernet-like."  I am not very comfortable with that as it
leads to very cumbersome wording, so I would very likely remove
the word "Ethernet" entirely in every case where I feel this can
be done.

	Another alternative is to remove the definition entirely and
continue to use the word "Ethernet" - relying on the fact that a
reasonable person would interpret this in the most general sense.

	In that sense, trying to avoid cumbersome wording has to be
weighed against removing information content.

	As a question for clarification, do you disagree with the
current definition of 802?  I got that directly from comments in
the last round of reviews.

--
Eric

--> -----Original Message-----
--> From: Wadekar, Manoj K [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 1:00 PM
--> To: Gray, Eric; Silvano Gai
--> Cc: [e-mail]
--> Subject: RE: [rbridge] Comments 
--> on:http://www.ietf.org/internet-drafts/dr 
--> aft-ietf-trill-rbridge-arch-01.txt
--> 
--> Hi Eric,
--> 
--> 	802 is definitely not Ethernet. 802.3 defined Ethernet MAC and
--> Phy functionality. 802.1 (not only Q) defines bridging functionality -
--> not only for Ethernet, for Wireless (802.11, 802.16 etc), for RPR
--> (802.17) - many underlying technologies. 
--> 
--> 	So, trying to define "Ethernet" in a document like this is not
--> only incorrect, it can be very misleading and confusing.
--> 
--> Thanks,
--> - Manoj
--> 
--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On
--> Behalf Of Gray, Eric
--> Sent: Wednesday, November 01, 2006 9:46 AM
--> To: Silvano Gai
--> Cc: [e-mail]
--> Subject: Re: [rbridge] Comments
--> on:http://www.ietf.org/internet-drafts/dr
--> aft-ietf-trill-rbridge-arch-01.txt
--> 
--> Silvano,
--> 
--> 	I think that there may be a compromise we can arrive at here.
--> 
--> 	I propose changing the defintion of "Ethernet" to read:
--> 
--> 'Ethernet: In this document the term "Ethernet" is used to represent
-->  Ethernet-like and/or Ethernet-equivalent technologies - explicitly
-->  including 802.3 [802.3 ref], 802.1Q [802.Q ref] and other closely 
-->  related LAN technologies, and NOT explicitly excluding any other 
-->  Ethernet-like and/or Ethernet-equivalent technology that exists, or
-->  may be developed in the future.'
--> 
--> 	Using this definition should clarify that I am not necessarily
--> using the term in the way that some people may feel it 
--> should be used,
--> while clearly stating what I am using the term to mean.  This should
--> also reduce your concern that I am apprently equating Ethernet and 
--> 802 in general.  It also satisfies my intention to be inclusive.
--> 
--> 	How does this sound?
--> 
--> --
--> Eric
--> 
-- [snip] --


Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1JMoJ6023666 for <[e-mail]>; Wed, 1 Nov 2006 11:22:51 -0800 (PST)
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 01 Nov 2006 11:22:51 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1JMo45027257; Wed, 1 Nov 2006 11:22:50 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA1JMoin020537; Wed, 1 Nov 2006 11:22:50 -0800 (PST)
Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Nov 2006 11:22:50 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Nov 2006 11:22:49 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Compromise proposal---allowing tradeoff between computation and optimality of delivery
Thread-Index: Acb95oDxCkdgdslTTxO+lBF0W67gsAAAf4Fg
From: "Sanjay Sane \(sanjays\)" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 01 Nov 2006 19:22:50.0462 (UTC) FILETIME=[1EECDFE0:01C6FDEB]
DKIM-Signature: a=rsa-sha1; q=dns; l=4107; t=1162408970; x=1163272970; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=22Sanjay=20Sane=20\(sanjays\)=22=20<[e-mail]> |Subject:RE=3A=20[rbridge]=20Compromise=20proposal---allowing=20tradeoff=20betwee n=20computation=20and=20optimality=20of=20delivery; X=v=3Dcisco.com=3B=20h=3DzgNSLnE+BDA/0mcKjHkXPf5MEB0=3D; b=tSi7zb2HPZRsYoZbbNR1ysKoTC9MBIUkOZaWUKxfWiiesji5IO9C448zg3zuroguSGfHi97C PF6+W/ouF50XaDvZhOGHId3nEZ/kLJUWB8+oS+ztfbkUbDYokXX9ZMHi;
Authentication-Results: sj-dkim-4.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA1JMoJ6023666
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between computation and optimality of delivery
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 19:23:55 -0000
Status: RO
Content-Length: 3991

This proposal sounds good to me, with one exception. 

If we don't expect the number of trees to be equal to the number of
rbridges, why have the tree identifier from the same number-space as of
rbridge-nickname ? 

Rbridge nickname space is 16 bits = 64K combinations. Its not practical
to scale to these many "trees". If the "tree-identifier" space is
different (say 10 bits - max 1k combinations) than the rbridge nickname
space, hardware resources can be optimized. 

To optimize the fields in the shim header, its ok to carry this
tree-identifier in the egress rbridge id field (as per your latest SHIM
header proposal). 

Yes, this would mean another "dynamic assignment" process to assign the
"tree-identifier". Whichever rbridge is configured/chosen to become the
root of a tree, first participates in the "dynamic assignment" process,
gets itself assigned a "tree-identifier", and then informs the other
RBridges with some information in its link state packet - indicating 2
things
1. flag suggesting it wants to be a root of a tree 
2. "tree-identifier" to be used for the tree computed with itself as the
root. 

-Sanjay



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Wednesday, November 01, 2006 10:43 AM
To: [e-mail]
Subject: [rbridge] Compromise proposal---allowing tradeoff between
computation and optimality of delivery

There is understandable nervousness about the need to compute
per-ingress trees for every RBridge, and optimality of delivery.
I actually was dubious about whether people *really* wanted to have to
compute per-ingress trees.

Here's a proposal that will allow tradeoff between overhead of
computation and optimality of delivery. If people really want they can
have RBridges compute trees rooted at every RBridge. Or they can have
all multicast delivered on a single shared tree. Or anything in between.
I'm arbitrarily picking the zero configuration option being a single
tree.

The new shim format allows the ingress RBridge to specify the
distribution tree for multicast, by putting into the "egress RBridge"
field a tree rooted at at the specified RBridge.

In this proposal, by default, the only tree that will be computed is a
single shared tree rooted at the RBridge with smallest MAC address.
Let's say that RBridge has nickname "71". By specifying 71 as egress
RBridge in a multicast packet, the delivery path will be via the
bidirectional tree rooted at 71.

An RBridge can be configured to demand that it, too, be the root of a
tree, and it informs the other RBridges with a flag in its link state
packet.

So now we have a subset of RBridges that can be used as roots of trees,
because they have specified that in their link state packet.
Let's say that RBridges with nicknames 11, 15, 71, 222, and 259 all have
announced that they want to be roots of trees.

Then an ingress RBridge, say R2, with nickname 11, can send a
multicast/unknown destination packet with "ingress"=11 (its own) and
"egress"=11 (because it said it wanted to be a root). Or it could choose
any of the other potential ones (15, 71, 222, 259).

Likewise, an ingress RBridge, say R3, with nickname 13, who has not
requested to be the root of a tree, can specify only the trees 11, 15,
71, 222, 259. Note it cannot specify "13", since we are assuming it has
not requested that all RBridges calculate a tree rooted at itself.

If no RBridges are configured to say they want to be the root, then only
a single tree will get computed---the one rooted at 71.

So the zero configuration option is a single shared tree (still filtered
based on IP multicast announcements and VLANs) rooted at the RBridge
with smallest MAC address. But by configuration, more and more
optimality can be introduced by having RBridges compute more trees.

Radia

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



Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1JLdGc022956 for <[e-mail]>; Wed, 1 Nov 2006 11:21:39 -0800 (PST)
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 01 Nov 2006 11:21:40 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1JLdIE028677; Wed, 1 Nov 2006 11:21:39 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA1JLdin018901; Wed, 1 Nov 2006 11:21:39 -0800 (PST)
Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Nov 2006 11:21:39 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Nov 2006 11:21:38 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Compromise proposal---allowing tradeoff between computation and optimality of delivery
Thread-Index: Acb95jVoXa/oi0N6Sr++ZbnSkexL4wAA+Nug
From: "Ayan Banerjee \(ayabaner\)" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 01 Nov 2006 19:21:39.0322 (UTC) FILETIME=[F485C5A0:01C6FDEA]
DKIM-Signature: a=rsa-sha1; q=dns; l=3427; t=1162408899; x=1163272899; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=22Ayan=20Banerjee=20\(ayabaner\)=22=20<[e-mail]> |Subject:RE=3A=20[rbridge]=20Compromise=20proposal---allowing=20tradeoff=20betwee n=20computation=20and=20optimality=20of=20delivery; X=v=3Dcisco.com=3B=20h=3DR6GBIoKD/8jOTAiC/KqWQrRKUEU=3D; b=lgVZSV+Bsib1y7BqNM0UDqdbk1M6v4miVbEAIJx3Kb2TaDjdkDFjOpJ6paOWRpgsMi2ocyBC /i5mc2a/TUhFwptfX4W8tqh5+p9nQdP7GKF6EgkPcLPAVzp0M5kYFZr6;
Authentication-Results: sj-dkim-1.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA1JLdGc022956
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between computation and optimality of delivery
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 19:21:47 -0000
Status: RO
Content-Length: 3337

Radia,

In this case could we assume that this list of trees to be computed will
be ordered and consistent across all nodes (say on MAC address or
priority)? 

Given the above, is it possible to have another TLV that states how many
trees (or the roots of trees) a node is "willing" to compute based on
its resource constraints. This will eliminate interoperability issues
across next-generation rbridges which may be more capable and deployed
with older rbridges. 

Thanks,
Ayan 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Wednesday, November 01, 2006 10:43 AM
To: [e-mail]
Subject: [rbridge] Compromise proposal---allowing tradeoff between
computation and optimality of delivery

There is understandable nervousness about the need to compute
per-ingress trees for every RBridge, and optimality of delivery.
I actually was dubious about whether people *really* wanted to have to
compute per-ingress trees.

Here's a proposal that will allow tradeoff between overhead of
computation and optimality of delivery. If people really want they can
have RBridges compute trees rooted at every RBridge. Or they can have
all multicast delivered on a single shared tree. Or anything in between.
I'm arbitrarily picking the zero configuration option being a single
tree.

The new shim format allows the ingress RBridge to specify the
distribution tree for multicast, by putting into the "egress RBridge"
field a tree rooted at at the specified RBridge.

In this proposal, by default, the only tree that will be computed is a
single shared tree rooted at the RBridge with smallest MAC address.
Let's say that RBridge has nickname "71". By specifying 71 as egress
RBridge in a multicast packet, the delivery path will be via the
bidirectional tree rooted at 71.

An RBridge can be configured to demand that it, too, be the root of a
tree, and it informs the other RBridges with a flag in its link state
packet.

So now we have a subset of RBridges that can be used as roots of trees,
because they have specified that in their link state packet.
Let's say that RBridges with nicknames 11, 15, 71, 222, and 259 all have
announced that they want to be roots of trees.

Then an ingress RBridge, say R2, with nickname 11, can send a
multicast/unknown destination packet with "ingress"=11 (its own) and
"egress"=11 (because it said it wanted to be a root). Or it could choose
any of the other potential ones (15, 71, 222, 259).

Likewise, an ingress RBridge, say R3, with nickname 13, who has not
requested to be the root of a tree, can specify only the trees 11, 15,
71, 222, 259. Note it cannot specify "13", since we are assuming it has
not requested that all RBridges calculate a tree rooted at itself.

If no RBridges are configured to say they want to be the root, then only
a single tree will get computed---the one rooted at 71.

So the zero configuration option is a single shared tree (still filtered
based on IP multicast announcements and VLANs) rooted at the RBridge
with smallest MAC address. But by configuration, more and more
optimality can be introduced by having RBridges compute more trees.

Radia

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



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id kA1J6qoF018749 for <[e-mail]>; Wed, 1 Nov 2006 11:06:52 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-13.tower-128.messagelabs.com!1162408009!6080340!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.100]
Received: (qmail 20016 invoked from network); 1 Nov 2006 19:06:49 -0000
Received: from motgate.mot.com (HELO motgate.mot.com) (129.188.136.100) by server-13.tower-128.messagelabs.com with SMTP; 1 Nov 2006 19:06:49 -0000
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (Motorola/Motorola) with ESMTP id kA1J6cfU023125 for <[e-mail]>; Wed, 1 Nov 2006 12:06:44 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id kA1J6bOt017229 for <[e-mail]>; Wed, 1 Nov 2006 13:06:37 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Nov 2006 14:06:35 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] New shim header proposal---without F-tag field
thread-index: Acb92zaI2Fb1n1RQSp2nLS2OfhEGRAADAcuA
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Silvano Gai" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA1J6qoF018749
Cc: [e-mail]
Subject: Re: [rbridge] New shim header proposal---without F-tag field
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 19:07:23 -0000
Status: RO
Content-Length: 3207

 
Personally, I'm reluctant to go below 18 bits. We don't want to
necessarily allocate the values too densely, we don't really know what
future heuristics will come along, etc.

How would I handle the ingress trees if there were N Rbridges for some
large N (like 500,000) if I had to? The first idea that comes to mind is
to adopt a heuristic to select a subset of the Rbridges, say about
SQRT(N) (which would be 708 in this case), perhaps on the basis of the
richness of their connectivity and other heuristic factors. Then I'd
compute trees just for those Rbridges and, using the marvelous
capability you have successfully argued for, have frames that need
multicast/broadcast distribution directed to that much smaller number of
trees rather than the tree rooted at the Rbridge where they are
encapsulated.

Donald

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]]
--> Sent: Wednesday, November 01, 2006 11:55 AM
--> To: Russ White
--> Cc: Gray, Eric; Radia Perlman; [e-mail]
--> Subject: RE: [rbridge] New shim header proposal---without F-tag 
--> field
--> 
--> 
--> What is a stretch is 32K trees of 32K nodes, which is what you need 
--> if you want to deploy the current TRILL proposal with 32K RBridges.
--> 
--> Eric says that we need to accommodate half a million RBridges.
--> Half a million tree of half a million nodes is unfeasible.
--> 
--> If we want to support such a large number of Rbridges, we need to 
--> modify the current Trill proposal, reducing the number of trees that

--> need to be computed.
--> 
--> Agreed?
--> 
--> -- Silvano
--> 
--> 
--> > -----Original Message-----
--> > From: Russ White [mailto:[e-mail]]
--> > Sent: Wednesday, November 01, 2006 8:35 AM
--> > To: Silvano Gai
--> > Cc: Gray, Eric; Radia Perlman; [e-mail]
--> > Subject: Re: [rbridge] New shim header proposal---without
--> F-tag field
--> > 
--> > -----BEGIN PGP SIGNED MESSAGE-----
--> > Hash: SHA1
--> > 
--> > 
--> > >> 	I don't think there is consensus yet that we
--> only need 16 bits
--> > >> for RBridge IDs.
--> > >
--> > > With 16 bits, using 1 bit to indicate unicast, we can have 32K
--> switches.
--> > > According to the current definition of TRILL, there is
--> the need to
--> run
--> > > Djikstra on a database with 32K records, one time for the core
--> instance
--> > > and 32K times for the IRTs. This is clearly out of
--> reach even for
--> the
--> > > most powerful CPU.
--> > 
--> > ?? Perhaps 32k trees is a stretch, but 32k nodes in a
--> tree? I don't
--> > think that's really a stretch on today's processors, from
--> the scaling
--> > work I've seen done in IS-IS.
--> > 
--> > :-)
--> > 
--> > Russ
--> > 
--> > - --
--> > [e-mail] CCIE <>< Grace Alone
--> > 
--> > -----BEGIN PGP SIGNATURE-----
--> > Version: GnuPG v1.4.2.2 (MingW32)
--> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--> > 
--> > iD8DBQFFSMypER27sUhU9OQRAqLwAJ9FLN2YNP2mrB6i0ZcV1fxLzAT0hgCfYHYj
--> > 6mJCA68nQLjCD8US9nRZZag=
--> > =kwzq
--> > -----END PGP SIGNATURE-----
--> 
_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail63.messagelabs.com (mail63.messagelabs.com [216.82.240.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id kA1IlU1G011786 for <[e-mail]>; Wed, 1 Nov 2006 10:47:30 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-15.tower-63.messagelabs.com!1162406847!82944001!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [66.243.153.112]
Received: (qmail 24976 invoked from network); 1 Nov 2006 18:47:27 -0000
Received: from f112.brocade.com (HELO scooby.brocade.com) (66.243.153.112) by server-15.tower-63.messagelabs.com with SMTP; 1 Nov 2006 18:47:27 -0000
Received: from hq-exch-1.corp.brocade.com (hq-exch-1.brocade.com [10.3.8.21]) by scooby.brocade.com (Postfix) with ESMTP id 82B0A25801A; Wed,  1 Nov 2006 10:47:38 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Nov 2006 10:44:58 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Comments on:http://www.ietf.org/internet-drafts/dr aft-ietf-trill-rbridge-arch-01.txt (terminology)
Thread-Index: Acb93hY4Z+Fjr1WcQqaQNaj4usmhcwAARsDgAAF+BkA=
From: "Anoop Ghanwani" <[e-mail]>
To: "Wadekar, Manoj K" <[e-mail]>, "Gray, Eric" <[e-mail]>, "Silvano Gai" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA1IlU1G011786
Cc: [e-mail]
Subject: Re: [rbridge] Comments on:http://www.ietf.org/internet-drafts/dr aft-ietf-trill-rbridge-arch-01.txt (terminology)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 18:48:25 -0000
Status: RO
Content-Length: 46460

I tend to agree with what Manoj and Silvano are
saying.  Overloading existing terminology can only
lead to confusion.

Anoop

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Wadekar, Manoj K
> Sent: Wednesday, November 01, 2006 10:00 AM
> To: Gray, Eric; Silvano Gai
> Cc: [e-mail]
> Subject: Re: [rbridge] Comments 
> on:http://www.ietf.org/internet-drafts/dr 
> aft-ietf-trill-rbridge-arch-01.txt
> 
> Hi Eric,
> 
> 	802 is definitely not Ethernet. 802.3 defined Ethernet 
> MAC and Phy functionality. 802.1 (not only Q) defines 
> bridging functionality - not only for Ethernet, for Wireless 
> (802.11, 802.16 etc), for RPR
> (802.17) - many underlying technologies. 
> 
> 	So, trying to define "Ethernet" in a document like this 
> is not only incorrect, it can be very misleading and confusing.
> 
> Thanks,
> - Manoj
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Gray, Eric
> Sent: Wednesday, November 01, 2006 9:46 AM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: Re: [rbridge] Comments
> on:http://www.ietf.org/internet-drafts/dr
> aft-ietf-trill-rbridge-arch-01.txt
> 
> Silvano,
> 
> 	I think that there may be a compromise we can arrive at here.
> 
> 	I propose changing the defintion of "Ethernet" to read:
> 
> 'Ethernet: In this document the term "Ethernet" is used to 
> represent  Ethernet-like and/or Ethernet-equivalent 
> technologies - explicitly  including 802.3 [802.3 ref], 
> 802.1Q [802.Q ref] and other closely  related LAN 
> technologies, and NOT explicitly excluding any other  
> Ethernet-like and/or Ethernet-equivalent technology that 
> exists, or  may be developed in the future.'
> 
> 	Using this definition should clarify that I am not 
> necessarily using the term in the way that some people may 
> feel it should be used, while clearly stating what I am using 
> the term to mean.  This should also reduce your concern that 
> I am apprently equating Ethernet and
> 802 in general.  It also satisfies my intention to be inclusive.
> 
> 	How does this sound?
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[e-mail]]
> --> Sent: Wednesday, November 01, 2006 1:21 AM
> --> To: Gray, Eric
> --> Cc: [e-mail]
> --> Subject: RE: [rbridge] Comments on: 
> --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
> --> -arch-01.txt
> --> 
> --> 
> --> Eric,
> --> 
> --> I disagree.
> --> 
> --> I don't think it is wise for TRILL to redefine the term Ethernet.
> --> Ethernet is a term that has a well known meaning in the industry.
> --> The original definition is:
> --> Digital Equipment Corporation, Intel, Xerox, The 
> Ethernet, Version 
> --> 2.0, November 1982.
> --> Which has been then standardized by IEEE 802.3.
> --> 
> --> To speak about other IEEE 802 standards that are alive and used, 
> --> IEEE
> --> 802.11 (Wireless LAN) and IEEE 802.17 (Resilient Packet Ring 
> --> Working) have nothing to do with Ethernet.
> --> 
> --> -- Silvano
> --> 
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:[e-mail]]
> --> > Sent: Tuesday, October 31, 2006 2:44 PM
> --> > To: Silvano Gai
> --> > Cc: [e-mail]
> --> > Subject: RE: [rbridge] Comments on: 
> http://www.ietf.org/internet- 
> --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
> --> > 
> --> > Silvano,
> --> > 
> --> > 	To be perfectly frank, I am unaware of any 
> reason not to include 
> --> > token ring or any other obsolete form of "Ethernet equivalent
> --> technology"
> --> > - this is one of the reason to focus on the SHIM as
> --> separate from any
> --> > specific encapsulation above or below the SHIM.
> --> > 
> --> > 	If you want to check it against all 802 
> activities, that's fine.
> --> > I would suggest, however, that even though people are
> --> realistically
> --> not
> --> > going to implement most of the hairy/scary versions in an
> --> RBridge, I
> --> do
> --> > not know of a good reason to exclude them at this point.  
> --> In abstract,
> --> > it is certainly possible that people will be able to work out
> --> specifics
> --> > of implementation - if and when they decide to do so.
> --> > 
> --> > 	After all, we (the industry) have been building 
> translation
> --> bridges
> --> > for these technologies for decades.
> --> > 
> --> > 	However, I am open to scoping the architecture 
> to apply only to
> --> a
> --> > limited subset of 802 technologies, if that is what would
> --> make people
> --> > happy...
> --> > 
> --> > --
> --> > Eric
> --> > 
> --> > --> -----Original Message-----
> --> > --> From: Silvano Gai [mailto:[e-mail]]
> --> > --> Sent: Tuesday, October 31, 2006 5:34 PM
> --> > --> To: Gray, Eric
> --> > --> Cc: [e-mail]
> --> > --> Subject: RE: [rbridge] Comments on:
> --> > --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
> --> > --> -arch-01.txt
> --> > -->
> --> > -->
> --> > --> Eric,
> --> > -->
> --> > --> A quick reply:
> --> > --> Are you telling me that the term Ethernet includes 
> Token Ring,
> --> Token
> --> > --> Bus, DQDB?
> --> > -->
> --> > --> This is what you are doing when you say that Ethernet
> --> is IEEE 802
> --> > --> instead of IEEE 802.3.
> --> > -->
> --> > --> This is NOT a terminology issue. If the term Ethernet means
> --> > --> 802 I need
> --> > --> to check the operation of TRILL against all the 802
> --> technologies.
> --> > -->
> --> > --> -- Silvano
> --> > -->
> --> > --> > -----Original Message-----
> --> > --> > From: Gray, Eric [mailto:[e-mail]]
> --> > --> > Sent: Tuesday, October 31, 2006 1:46 PM
> --> > --> > To: Silvano Gai
> --> > --> > Cc: [e-mail]
> --> > --> > Subject: RE: [rbridge] Comments on:
> --> http://www.ietf.org/internet-
> --> > --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
> --> > --> >
> --> > --> >
> --> > --> >
> --> > --> > -- [snip] --
> --> > --> > -->
> --> > --> > --> Sgai 4> an RBridge must be also able to send
> --> two copies of a
> --> > --> > --> unicast/multicast/broadcast packet on the same
> --> port when it
> --> > --> > --> acts as a designated RBridge (one copy is
> --> encapsulated, the
> --> > --> > --> other not).
> --> > --> > -->
> --> > --> >
> --> > --> > This, I think, refers to the immediately preceding
> --> text in the
> --> > --> > architecture:
> --> > --> >
> --> > --> >         Forwarding information is derived from the
> --> combination
> --> of
> --> > --> >         attached MAC address learning, snooping of
> --> > --> multicast-related
> --> > --> >         protocols (e.g. - IGMP), and routing
> --> > --> advertisements and path
> --> > --> >         computations using the link-state routing 
> protocol.
> --> > --> >
> --> > --> > While your comment is a reasonable one - although
> --> potentially
> --> > --> > implementation specific - it does not appear to
> --> have any bearing
> --> > --> > on this text.
> --> > --> >
> --> > --> >
> --> > --> > -- [snip] --
> --> > --> > -->
> --> > --> > --> Sgai 5> here there is some confusion between
> --> 802 and 802.3
> --> > --> > -->
> --> > --> >
> --> > --> > This  refers (I believe) to the immeditately 
> preceding text:
> --> > --> >
> --> > --> >         The following terminology is defined in
> --> other documents.
> --> A
> --> > --> brief
> --> > --> >         definition is included in this section for
> --> > --> convenience and -
> --> > --> in
> --> > --> >         some cases - to remove any ambiguity in how the
> --> > --> term may be
> --> > --> used
> --> > --> >         in this document, as well as derivative documents
> --> > --> intended to
> --> > --> >         specify components, protocol, behavior and
> --> encapsulation
> --> > --> >         relative to the architecture specified in
> --> this document.
> --> > --> >
> --> > --> >         o  802: IEEE Specification for the Ethernet
> --> architecture,
> --> > --> i.e.,
> --> > --> >            including hubs and bridges.
> --> > --> >
> --> > --> > In this text, I explicitly state that these terms
> --> are defined
> --> > --> elsewhere.
> --> > --> > I am also trying to use the most generic definition
> --> of Ethernet
> --> > --> possible.
> --> > --> >
> --> > --> > The reason for this is that the problem statement does
> --> > --> not restrict
> --> > --> the
> --> > --> > solution to 802.3.
> --> > --> >
> --> > --> > There is some confusion in referring to 802.3 in
> --> any case: we
> --> > --> explicitly
> --> > --> > want to include 802.1Q - as well as all of its
> --> variations and
> --> > --> extensions.
> --> > --> >
> --> > --> > Consequently, we define the term Ethernet in the broadest
> --> possible
> --> > --> sense.
> --> > --> >
> --> > --> >
> --> > --> > -- [snip] --
> --> > --> > -->
> --> > --> > -->        o  Bridge Spanning Tree (BST): an Ethernet (L2,
> --> 802.1D)
> --> > --> > -->           forwarding protocol based on the topology
> --> > --> of a spanning
> --> > --> > tree.
> --> > --> > -->
> --> > --> > --> Sgai 6> I have never seen the acronym BST,
> --> everyone use STP.
> --> > --> > -->
> --> > --> >
> --> > --> > I do not know if this term is used in any of the other
> --> documents,
> --> > --> > but it is not used in this one.  Unless someone
> --> objects, I am
> --> only
> --> > --> > too happy to remove it from this document.
> --> > --> >
> --> > --> > From a historical perspective, this was defined this way
> --> > --> originally
> --> > --> > because we were re-using the term spanning tree instead
> --> > --> of IRT.  It
> --> > --> > was causing amazing communication difficulties, so
> --> we came up
> --> with
> --> > --> > the term IRT.  Now we don't need to differentiate BST.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 7> for Ethernet is better to reference 802.3
> --> > --> > -->
> --> > --> >
> --> > --> > See my response to your point (Sgai 5) above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Hub: an Ethernet (L2, 802) device with
> --> > --> multiple ports
> --> > --> which
> --> > --> > -->
> --> > --> > --> sgai 8> for Hub is better to reference 802.3
> --> > --> > -->
> --> > --> >
> --> > --> > See my response to your point (Sgai 5) above.  By the
> --> > --> definition we
> --> > --> > provide in this document, Ethernet is defined
> --> broadly to include
> --> > --> > 802 technologies.  This is reasonable, because 
> the term was
> --> stolen
> --> > --> > by IEEE from a technology stolen from a satellite
> --> communication
> --> > --> > protocol.  Ironic that 802.3 does not include 
> wireless, all
> --> things
> --> > --> > considered.  Certainly the term "Ethernet" should...
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Node: a device with an L2 (MAC) address
> --> > --> that sources
> --> > --> and/or
> --> > --> > -->            sinks L2 frames.
> --> > --> > -->
> --> > --> > --> Sgai 9> The IEEE term is "station".
> --> > --> > -->
> --> > --> >
> --> > --> > However, we in the IETF are more familiar with the
> --> term "node."
> --> > --> >
> --> > --> > This is hardly a significant issue.  if people agree that
> --> > --> we should
> --> > --> > use the term "station" as opposed to "node", then I will
> --> > --> change it.
> --> > --> >
> --> > --> > Note that we should be consistent in this usage, if we
> --> > --> decide to do
> --> > --> > yet another terminology evolution.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Segment: an Ethernet link, either a single
> --> physical
> --> > --> link or
> --> > --> > -->            emulation thereof (e.g., via hubs) or a
> --> > --> logical link or
> --> > --> > -->            emulation thereof (e.g., via bridges).
> --> > --> > -->
> --> > --> > --> Sgai 10> IEEE uses the term "LAN segment"
> --> > --> > -->
> --> > --> >
> --> > --> > I agree, however this is the definition we agreed on here.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Subnet, Ethernet: a single segment,
> --> or a set of
> --> > --> segments
> --> > --> > -->            interconnected by a CRED (see
> --> section 2.2); in
> --> the
> --> > --> latter
> --> > --> > -->
> --> > --> > --> sgai 11> There is no concept of subnet in IEEE. 
> --> Subnet is
> --> > --> typically
> --> > --> > --> an IP subnet, and, even if it is common to have
> --> one subnet
> --> per
> --> > --> LAN,
> --> > --> > --> this is not the only possibility. Pragmatically
> --> IP subnets
> --> and
> --> > --> > --> Ethernet LAN are unrelated concepts.
> --> > --> > -->
> --> > --> >
> --> > --> > Again, we are defining this term for use in this
> --> > --> document.  Does its
> --> > --> > use (not its definition) cause confusion or ambiguity?
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->            case, the subnet may or may not be
> --> equivalent to
> --> a
> --> > --> single
> --> > --> > -->            segment. Also a subnet may be
> --> referred to as a
> --> > --> broadcast
> --> > --> > -->            domain or LAN. By definition, all
> --> nodes within an
> --> > --> Ethernet
> --> > --> > -->            Subnet (broadcast domain or LAN) 
> must have L2
> --> > --> connectivity
> --> > --> > -->            with all other nodes in the same
> --> Ethernet subnet.
> --> > --> > -->
> --> > --> > -->         o  TRILL: Transparent Interconnect over Lots
> --> > --> of Links -
> --> > --> the
> --> > --> > -->            working group and working name for the
> --> > --> problem domain
> --> > --> to be
> --> > --> > -->            addressed in this document.
> --> > --> > -->
> --> > --> > -->         o  Unicast Forwarding: forwarding methods
> --> > --> that apply to
> --> > --> frames
> --> > --> > -->            with unicast destination MAC addresses.
> --> > --> > -->
> --> > --> > -->         o  Unknown Destination - a destination
> --> for which a
> --> > --> receiving
> --> > --> > -->            device has no filtering database entry.
> --> > --> Destination
> --> > --> (layer
> --> > --> > -->
> --> > --> > --> sgai 12> the stations receive the unknown
> --> unicast and have
> --> > --> filtering
> --> > --> > --> information, only the bridges don't. I propose to
> --> > --> replace device
> --> > --> with
> --> > --> > --> bridge.
> --> > --> > -->
> --> > --> >
> --> > --> > Again, it is the intention to provide as broad a
> --> definition as
> --> > --> possible
> --> > --> > without introducing confusion or ambiguity.  An end node
> --> > --> (or station)
> --> > --> > has - in a sense - a filtering database (it's mine, or
> --> > --> it's for the
> --> > --> bit
> --> > --> > bucket).
> --> > --> >
> --> > --> > We need to explicitly include 802.1D forwarding devices
> --> > --> and RBridges.
> --> > --> >
> --> > --> > However, the definition should specify "forwarding
> --> device" - as
> --> > --> opposed
> --> > --> > to just "receiving device."
> --> > --> >
> --> > --> > I will change that.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->            2) addresses are typically "learned" 
> --> by (layer 2)
> --> > --> > forwarding
> --> > --> > -->            devices via a process commonly referred to
> --> > --> as "bridge
> --> > --> > learning".
> --> > --> > -->
> --> > --> > --> Sgai 13> in IEEE, the term used is "learning" instead
> --> > --> of "bridge
> --> > --> > learning"
> --> > --> > -->
> --> > --> >
> --> > --> > However, the term defined in this document is
> --> "bridge learning."
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  VLAN: Virtual Local Area Network. VLANs in
> --> > --> general fall
> --> > --> > into
> --> > --> > -->            two categories: link (or port)
> --> specific VLANs and
> --> > --> tagged
> --> > --> > -->            VLANs. In the former case, all frames
> --> > --> forwarded and all
> --> > --> > -->            directly connected nodes are assumed to be
> --> > --> part of a
> --> > --> single
> --> > --> > -->            VLAN.  In the latter case, VLAN tagged
> --> > --> frames are used
> --> > --> to
> --> > --> > -->            distinguish which VLAN each frame 
> is intended
> --> for.
> --> > --> > -->
> --> > --> > --> Sgai 14> This definition is not completely correct, I
> --> prefer:
> --> > --> > -->
> --> > --> > --> VLAN technology introduces the following three
> --> basic types
> --> of
> --> > --> frame:
> --> > --> > --> a) Untagged frames;
> --> > --> > --> b) Priority-tagged frames; and
> --> > --> > --> c) VLAN-tagged frames.
> --> > --> > -->
> --> > --> > --> An untagged frame or a priority-tagged frame does not
> --> > --> carry any
> --> > --> > --> identification of the VLAN to which it belongs. Such
> --> > --> frames are
> --> > --> > --> classified as belonging to a particular VLAN based on
> --> > --> parameters
> --> > --> > --> associated with the receiving Port, or, through
> --> proprietary
> --> > --> extensions
> --> > --> > --> to IEEE 802.1Q standard, based on the data content of
> --> > --> the frame
> --> > --> (e.g.,
> --> > --> > --> MAC Address, layer 3 protocol ID, etc.).
> --> > --> > -->
> --> > --> > --> A VLAN-tagged frame carries an explicit
> --> > --> identification of the VLAN
> --> > --> to
> --> > --> > --> which it belongs; i.e., it carries a tag header
> --> that carries
> --> a
> --> > --> non-
> --> > --> > null
> --> > --> > --> VID. Such a frame is classified as belonging to a
> --> > --> particular VLAN
> --> > --> > based
> --> > --> > --> on the value of the VID that is included in the tag
> --> > --> header. The
> --> > --> > presence
> --> > --> > --> of the tag header carrying a non-null VID means that
> --> > --> some other
> --> > --> > device,
> --> > --> > --> either the originator of the frame or a
> --> VLAN-aware Bridge,
> --> has
> --> > --> mapped
> --> > --> > --> this frame into a VLAN and has inserted the
> --> appropriate VID.
> --> > --> > -->
> --> > --> >
> --> > --> > So, you're getting into the details of the
> --> technology and - in
> --> > --> particular
> --> > --> > the encapsulation.  I will expand the definition to
> --> include a
> --> > --> possibility
> --> > --> > that other criteria may be used to define a "VLAN port" -
> --> although
> --> > --> this is
> --> > --> > isomorphic to a logical model in which a device
> --> > --> implementation uses
> --> > --> some
> --> > --> > criteria to decide that a subset of the traffic received
> --> > --> on a specific
> --> > --> > physical port is to be forwarded as if received on a
> --> > --> specific logical
> --> > --> > port.
> --> > --> >
> --> > --> > The key point in this definition is that a VLAN is a
> --> > --> "Virtual LAN" -
> --> > --> > meaning
> --> > --> > it consists of a subset of the physical and L2 
> connectivity
> --> > --> corresponding
> --> > --> > to
> --> > --> > a "logical LAN."  The intent is to "rise above" the
> --> technological
> --> > --> > approaches
> --> > --> > and encapsulations to establish a generic definition that
> --> > --> is loosely
> --> > --> tied
> --> > --> > to
> --> > --> >
> --> > --> > ways that this generic definition is actually implemented.
> --> > --> >
> --> > --> > Again, bearing in mind the way that the term is
> --> defined, does
> --> the
> --> > --> usage of
> --> > --> > the term cause confusion or ambiguity?
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  CRED Forwarding Table (CFT): the per-hop
> --> forwarding
> --> > --> table
> --> > --> > -->            populated by the RBridge Routing Protocol;
> --> > --> forwarding
> --> > --> > within
> --> > --> > -->            the CRED is based on a lookup of the
> --> CRED Transit
> --> > --> Header
> --> > --> > -->            (CTH) encapsulated within the
> --> outermost received
> --> L2
> --> > --> header.
> --> > --> > -->            The outermost L2 encapsulation in this
> --> > --> case includes
> --> > --> the
> --> > --> > -->            source MAC address of the immediate
> --> > --> upstream RBridge
> --> > --> > -->            transmitting the frame and destination MAC
> --> > --> address of
> --> > --> the
> --> > --> > -->            receiving RBridge for use in the unicast
> --> forwarding
> --> > --> case.
> --> > --> > -->
> --> > --> > --> Sgai 15> In section 7 of
> --> > --> > -->
> --> > --> 
> --> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-
> --> > --> > 00.txt
> --> > --> > --> we proposed that when two rbridges are
> --> connected by a point
> --> to
> --> > --> point
> --> > --> > --> link the outer MAC addresses may be set to a
> --> > --> predefined value in
> --> > --> > --> transmission and ignored in reception.
> --> > --> > -->
> --> > --> >
> --> > --> > I'm not sure how your proposal intends to determine that
> --> > --> a link is in
> --> > --> > fact point-to-point and does not just look that way.
> --> > --> >
> --> > --> > I prefer to use the same encapsulation in all 
> cases where it
> --> will
> --> > --> work.
> --> > --> >
> --> > --> > The optimization associated with using some form of
> --> > --> null-encapsulation
> --> > --> > is of dubious value, given that it may not be possible to
> --> > --> be certain a
> --> > --> > point-to-point link is - and will remain - in fact a
> --> > --> point-to-point
> --> > --> > link.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  CFT-IRT: a forwarding table used for
> --> propagation
> --> of
> --> > --> > -->            broadcast, multicast or flooded
> --> frames along the
> --> > --> Ingress
> --> > --> > -->            RBridge Tree (IRT).
> --> > --> > -->
> --> > --> > --> Sgai 16> is it a forwarding table or is it a
> --> > --> filtering database.
> --> > --> Since
> --> > --> > --> the "miss" behavior is to flood, I see it as a
> --> > --> filtering database.
> --> > --> > -->
> --> > --> >
> --> > --> > What state was "miss" behavior from - Hawaii?  :-)
> --> > --> >
> --> > --> > It is analogous to a filtering database entry, 
> but it is not
> --> that.
> --> > --> >
> --> > --> > Clearly there are more things in this world than can be
> --> classified
> --> > --> > in this taxonomy.  However, given these choices, it is a
> --> > --> forwarding
> --> > --> > table.
> --> > --> >
> --> > --> > This is not a misbehavior, in that the same "base" tree
> --> > --> is used for
> --> > --> > broadcast and multicast traffic as well as flooded
> --> > --> traffic.  It may
> --> > --> > be arguable that flooding is a misbehavior, but I
> --> seem to recall
> --> > --> > that people still see it as a necessary evil.
> --> > --> >
> --> > --> > It is also not "miss" behavior (as in "cache miss") in
> --> > --> the multicast
> --> > --> > and broadcast case, either.
> --> > --> >
> --> > --> > I believe the definition is quite correct and easy to
> --> understand,
> --> > --> > provided you're not reading it with preconceived
> --> misconceptions
> --> > --> > about its meaning.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  CRED Transit Header (CTH): a 'shim' 
> --> header that
> --> > --> > encapsulates
> --> > --> > -->            the ingress L2 frame and persists
> --> throughout the
> --> > --> transit of
> --> > --> > a
> --> > --> >
> --> > --> > -->            CRED, which is further encapsulated within
> --> > --> a hop-by-hop
> --> > --> L2
> --> > --> > -->            header (and trailer). The hop-by-hop L2
> --> > --> encapsulation
> --> > --> in
> --> > --> > this
> --> > --> >
> --> > --> > -->            case includes the source MAC address of
> --> > --> the immediate
> --> > --> > -->            upstream RBridge transmitting the frame
> --> > --> and destination
> --> > --> MAC
> --> > --> > -->            address of the receiving RBridge -
> --> at least in
> --> the
> --> > --> unicast
> --> > --> > -->            forwarding case.
> --> > --> > -->
> --> > --> > --> Sgai 17> is this true also for unknown unicast?
> --> > --> > -->
> --> > --> >
> --> > --> > That is something that will be (may be already)
> --> decided in the
> --> > --> protocol
> --> > --> > specification.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  CRED Transit Table (CTT): a table that maps
> --> ingress
> --> > --> frame
> --> > --> > L2
> --> > --> > -->            destinations to egress RBridge
> --> addresses, used to
> --> > --> determine
> --> > --> > -->            encapsulation of ingress frames for
> --> transit of
> --> the
> --> > --> CRED.
> --> > --> > -->
> --> > --> > -->         o  Cooperating RBridges - those RBridges
> --> > --> within a single
> --> > --> > -->            Ethernet Subnet (broadcast domain or LAN)
> --> > --> not having
> --> > --> been
> --> > --> > -->            configured to ignore each other. By
> --> default, all
> --> > --> RBridges
> --> > --> > -->            within a single Ethernet subnet will
> --> cooperate
> --> with
> --> > --> each
> --> > --> > -->            other. It is possible for implementations
> --> > --> to allow for
> --> > --> > -->            configuration that will restrict
> --> > --> "cooperation" between
> --> > --> an
> --> > --> > -->            RBridge and an apparent neighboring
> --> RBridge.  One
> --> > --> reason
> --> > --> > why
> --> > --> > -->            this might occur is if the trust model
> --> > --> that applies in
> --> > --> a
> --> > --> > -->            particular deployment imposes a need for
> --> > --> configuration
> --> > --> of
> --> > --> > -->            security information.  By default no such
> --> > --> configuration
> --> > --> is
> --> > --> > -->            required however - should it be used in
> --> > --> any specific
> --> > --> > scenario
> --> > --> > -->
> --> > --> > -->            - it is possible (either deliberately or
> --> > --> inadvertently)
> --> > --> to
> --> > --> > -->            configure neighboring RBridges so
> --> that they do
> --> not
> --> > --> > cooperate.
> --> > --> > -->
> --> > --> > -->            In the remainder of this document,
> --> all RBridges
> --> are
> --> > --> assumed
> --> > --> > -->            to be in a cooperating (default)
> --> configuration.
> --> > --> > -->
> --> > --> > --> Sgai 18> can RBridges cooperate in groups, e.g. four
> --> Rbridges
> --> > --> > connected
> --> > --> > --> to a LAN cooperating two and two?
> --> > --> > -->
> --> > --> >
> --> > --> > Yes.  There may be reasons why this might be done
> --> deliberately,
> --> > --> however
> --> > --> > - even in the absence of any "proof of concept"
> --> > --> justification - it is
> --> > --> a
> --> > --> > really good idea to design the protocol to be robust in
> --> > --> cases where a
> --> > --> > set of RBridges may be (mis)configured in such a way as
> --> > --> to be unable
> --> > --> to
> --> > --> > discover each other.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Ingress RBridge Tree: a tree
> --> computed for each
> --> edge
> --> > --> RBridge
> --> > --> > -->            and potentially for each VLAN in which that
> --> RBridge
> --> > --> > -->
> --> > --> > --> sgai 19> why for each VLAN? I got the
> --> impression that there
> --> > --> > --> was a single tree that was pruned differently for
> --> > --> different VLANs.
> --> > --> > -->
> --> > --> >
> --> > --> > Pruning may also take place at the ingress, if - for
> --> > --> example - it has
> --> > --> a
> --> > --> > subset of interfaces that are not connected to any
> --> egress for
> --> > --> particular
> --> > --> > VLANs.  It is a small point but, in such cases, 
> there is in
> --> effect
> --> > --> more
> --> > --> > than one IRT even at the ingress.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->            participates - for delivery of broadcast,
> --> > --> multicast and
> --> > --> > -->            flooded frames from that RBridge to all
> --> > --> relevant egress
> --> > --> > -->            RBridges. This is the point-to-multipoint
> --> > --> delivery tree
> --> > --> > used
> --> > --> > -->            by an ingress RBridge to deliver
> --> > --> multicast, broadcast
> --> > --> or
> --> > --> > -->            flooded traffic.
> --> > --> > -->
> --> > --> > --> Sgai 20> the current version of the proposal
> --> speaks about a
> --> > --> multicast
> --> > --> > --> address, not point-to-point.
> --> > --> > -->
> --> > --> >
> --> > --> > I did not say "point-to-point" (look again).
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  LPT: Learned Port Table. See
> --> Filtering Database.
> --> > --> > -->
> --> > --> > --> Sgai 21> not proper terminology, I would use
> --> > --> "filtering database"
> --> > --> > --> everywhere.
> --> > --> > -->
> --> > --> >
> --> > --> > I am happy to remove this if there is no objection
> --> to my doing
> --> so.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 22> I wired port is Ehernet, i.e. IEEE 802.3, a 
> --> > --> > --> wireless port is not Ethernet, it is IEEE 802.11.
> --> > --> > -->
> --> > --> >
> --> > --> > See my response to your point (sgai 8) above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 23> they learn because STP guarantees
> --> > --> symmetrical forwarding
> --> > --> > -->
> --> > --> >
> --> > --> > This (apparently) refers to the immeditately 
> preceding text:
> --> > --> >
> --> > --> >         Conventional bridges contain a learned port table
> --> > --> (LPT), or
> --> > --> >         filtering database, and a spanning tree table
> --> > --> (STT). The LPT
> --> > --> >         allows a bridge to avoid flooding all received
> --> > --> frames, as is
> --> > --> >         typical for a hub or repeater. The bridge learns
> --> > --> which nodes
> --> > --> are
> --> > --> >         accessible from a particular port by assuming
> --> > --> bi-directional
> --> > --> >         consistency:
> --> > --> >
> --> > --> > I'm not sure how picking at the peculiarities of
> --> STP behavior is
> --> > --> > relevant to this description.  STP results in a
> --> single spanning
> --> > --> > tree where each link is bi-directional.  This
> --> ensures that the
> --> > --> > MAC frames are forwarded in a bi-directionally consistent
> --> fashion.
> --> > --> >
> --> > --> > To replace this text with yours is to provide less
> --> information.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 24> active ports -> forwarding ports
> --> > --> > -->
> --> > --> >
> --> > --> > "Active ports" was the exact wording suggested to me.  In
> --> > --> context for
> --> > --> > this working group "active ports" is more meaningful than
> --> > --> "forwarding
> --> > --> > ports."  For people not used to STP-speak, "forwarding
> --> > --> port" might be
> --> > --> > used to discriminate from a "code port."
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 25> there is no STT, there is a state associated
> --> > --> with each
> --> > --> port
> --> > --> > --> that can be: disabled, blocking, listening,
> --> learning, and
> --> > --> forwarding
> --> > --> > -->
> --> > --> >
> --> > --> > Other than the issue with terminology, is this text
> --> wrong?  I am
> --> > --> fairly
> --> > --> > sure that different implementations handle the 
> "port state"
> --> > --> information
> --> > --> > in different ways, and I am also reasonably sure that a
> --> > --> "table" such
> --> > --> as
> --> > --> > the one described here is one of the ways it 
> might be done.
> --> > --> >
> --> > --> > However, I agree with your assertion that this is the way
> --> > --> that it is
> --> > --> > usually talked about in an IEEE context, so -
> --> unless there are
> --> > --> specific
> --> > --> > objections - I can change the wording to be consistent
> --> > --> with what you
> --> > --> > suggest.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 26> disabled -> blocking
> --> > --> > -->
> --> > --> >
> --> > --> > I can make this change as well.  However, from the
> --> > --> perspective of what
> --> > --> > we are trying to do, "disabled" is potentially a more
> --> > --> correct term.
> --> > --> It
> --> > --> > is certainly more intuitively correct, outside of a
> --> > --> strictly IEEE/STP
> --> > --> > context.
> --> > --> >
> --> > --> > Symmetry is maintained in STP by blocking ports/links
> --> > --> bi-directionally.
> --> > --> > In such cases, a port is effectively disabled for bridges
> --> > --> at either
> --> > --> end
> --> > --> > of the link for which a port is blocked, is it not?
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 27> I repeat a comment that I have made to other
> --> > --> documents: "
> --> > --> > --> The discussion about VLAN needs to be much more
> --> > --> extensive. It is
> --> > --> clear
> --> > --> > --> from the mailing list discussion that VLANs can be
> --> > --> used inside the
> --> > --> > --> packet or in the Ethernet encapsulation of TRILL.
> --> > --> These are two
> --> > --> > --> different kinds of VLANs and their requirement need
> --> > --> to be stated
> --> > --> > --> separately. Q in Q needs also to be discussed. I
> --> > --> propose to define
> --> > --> > inner
> --> > --> > --> and outer VLANs (with reference to the position of
> --> > --> the tag in the
> --> > --> > frame."
> --> > --> > --> Here I think we are talking about outer VLANs
> --> > --> > -->
> --> > --> >
> --> > --> > I responded to this in separate mail.  I wait to hear
> --> > --> other opinions
> --> > --> on
> --> > --> > this subject.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 28> IMO all RBridges must be ingress RBridges,
> --> > --> at least to
> --> > --> > support
> --> > --> > --> inband management, e.g. SNMP.
> --> > --> > -->
> --> > --> >
> --> > --> > No.
> --> > --> >
> --> > --> > In order to ensure symmetry with RBridges not
> --> > --> participating in STP,
> --> > --> there
> --> > --> > MUST be a designated RBridge that does all of the
> --> sending and
> --> > --> receiving
> --> > --> > of native encapsulated frames on a LAN segment.
> --> > --> >
> --> > --> > Any RBridge the loses the "Designated RBridge" 
> --> election cannot
> --> be
> --> > --> either
> --> > --> > an ingress or an egress for that LAN segment.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 29> same as above
> --> > --> > -->
> --> > --> >
> --> > --> > Same as above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 30> I think the previous definition is 
> not needed.
> --> > --> > -->
> --> > --> >
> --> > --> > This appears to refer to:
> --> > --> >
> --> > --> >         o  Local RBridge - the RBridge that forms and
> --> > --> maintains the
> --> > --> CFT-
> --> > --> >            IRT entry (or entries) under discussion. The
> --> > --> local RBridge
> --> > --> >            may be an Ingress RBridge, or an egress
> --> RBridge with
> --> > --> respect
> --> > --> >            to any set of entries in the CFT-IRT.
> --> > --> >
> --> > --> > This defintion is needed.  It is subsequently used
> --> in at least 4
> --> > --> places.
> --> > --> > When discussing the behavior of a specific RBridge
> --> > --> relative to a peer,
> --> > --> > it is convenient to define the term "local RBridge."
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 31> why is it zero or more, if an RBridge
> --> exists, it
> --> must
> --> > --> have
> --> > --> > --> a an IRT, I haven't seen any discussion to support
> --> > --> multiple IRTs.
> --> > --> > -->
> --> > --> >
> --> > --> > This was answered previously on the mailing list.
> --> > --> Briefly, zero or
> --> > --> > more is correct, given that an RBridge may not have
> --> > --> forwarding entries
> --> > --> > for frames it has received.  In these cases, a frame is
> --> > --> not forwarded.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 32> I don't understand this. Since the current
> --> > --> proposal uses
> --> > --> a
> --> > --> > --> multicast MAC address, what is needed is a bit map
> --> > --> for each IRT
> --> > --> that
> --> > --> > --> says which ports are blocking and which are
> --> > --> forwarding. You are
> --> > --> > --> basically building a ST using ISIS.
> --> > --> > -->
> --> > --> >
> --> > --> > This might be the case for a specific implementation.
> --> > --> Whether it is
> --> > --> > implemented as a "bit-mask" with "non-blocking"
> --> > --> (forwarding) ports, or
> --> > --> > is implemented as a full-blown table is largely 
> dependent on
> --> what
> --> > --> other
> --> > --> > information the local device requires in order to
> --> > --> properly forwad the
> --> > --> > frame.  If - for example - a device has multiple
> --> > --> different port types,
> --> > --> > it may need to have more information for each 
> port (or that
> --> > --> information
> --> > --> > may be added later on).
> --> > --> >
> --> > --> > All of these are implementation choices that are
> --> > --> logically represented
> --> > --> > by the table described here.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 33> I don't get the pair.
> --> > --> > -->
> --> > --> >
> --> > --> > Since this immediately follows:
> --> > --> >
> --> > --> >         Each entry would contain an indication of
> --> which single
> --> > --> interface
> --> > --> >         a broadcast, multicast or flooded frame would be
> --> > --> forwarded for
> --> > --> >         each (ingress RBridge, egress RBridge) pair.
> --> > --> >
> --> > --> > I don't get what you don't get.
> --> > --> >
> --> > --> > The pair refers to the tuple "(ingress RBridge, egress
> --> RBridge)."
> --> > --> >
> --> > --> > This might be the point at which your earlier 
> point (Sgai 4)
> --> would
> --> > --> make
> --> > --> > sense to insert.  I had logically modeled this in my own
> --> > --> mind as two
> --> > --> > distinct "interfaces" (the reason I use this term, rather
> --> > --> thhan port),
> --> > --> > but I should clarify this.
> --> > --> >
> --> > --> > In any case, the entries are keyed by both ingress and
> --> > --> egress RBridge.
> --> > --> > While there will be entries for only those egress
> --> > --> RBridges where this
> --> > --> > local RBridge is on the shortest path (between the given
> --> > --> ingress and
> --> > --> > egress pair), there will be at most one entry per
> --> any ingress
> --> and
> --> > --> > egress pair.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 34> as a matter of fact each interface is
> --> > --> basically a set of
> --> > --> two
> --> > --> > --> interfaces, a regular one and a tunnel one, and the
> --> > --> > forwarding/blocking
> --> > --> > --> state may be different for the two.
> --> > --> > -->
> --> > --> >
> --> > --> > No.
> --> > --> >
> --> > --> > As per my response to your point (Sgai 28) above, not
> --> > --> every RBridge
> --> > --> has a
> --> > --> > "regular one" as you describe here.
> --> > --> >
> --> > --> > The forwarding/blocking state is not applicable as
> --> > --> RBridges don't do
> --> > --> STP.
> --> > --> >
> --> > --> > For the native interface, fowarding/blocking state is
> --> > --> analogous to the
> --> > --> > "Designated RBridge" election process.
> --> > --> >
> --> > --> > Since this point evidently applies to -
> --> > --> >
> --> > --> >                                                   
>    Entries
> --> would
> --> > --> also
> --> > --> >         contain any required encapsulation information,
> --> > --> etc. required
> --> > --> >         for forwarding on a given interface, and toward a
> --> > --> corresponding
> --> > --> >         specific egress RBridge.
> --> > --> >
> --> > --> > - your point, and my response, are related to the point
> --> > --> (and response)
> --> > --> > above (Sgai 33), and I will try to clarify this
> --> part as well.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 35> this protocol must be designed to avoid
> --> > --> transient loops,
> --> > --> > since
> --> > --> > --> transient loops of multicast/broadcast cause
> --> > --> broadcast storm that
> --> > --> are
> --> > --> > --> highly undesirable.
> --> > --> > -->
> --> > --> >
> --> > --> > No.
> --> > --> >
> --> > --> > The protocol needs to include a provision to prevent
> --> > --> _use_ of links
> --> > --> that
> --> > --> > may connect to transient loops.  Using a link-state
> --> > --> routing protocol
> --> > --> has
> --> > --> > clearly been demostrated to produce transient loops, but
> --> > --> the problem
> --> > --> you
> --> > --> > want to address has to do with using those links.
> --> > --> >
> --> > --> > A state-machine driven mechanism similar to STP might be
> --> > --> the approach
> --> > --> to
> --> > --> > use.
> --> > --> >
> --> > --> > Because we're incorporating TTL in the SHIM, however this
> --> > --> would need
> --> > --> to
> --> > --> > apply only to IRT traffic.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->
> --> > --> > --> Sgai 36> see my previous comment about VLANs
> --> > --> > -->
> --> > --> >
> --> > --> > See my previous responses.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 37> disabled -> blocking.
> --> > --> > -->
> --> > --> >
> --> > --> > See my response to your point (sgai 26) above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 38> for multicast/broadcast we also need to
> --> > --> avoid transient
> --> > --> > loops.
> --> > --> > -->
> --> > --> >
> --> > --> > Yes.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 39> but RBridge discovery and STP are ongoing
> --> > --> processes, why
> --> > --> do
> --> > --> > we
> --> > --> > --> want to couple their timers?
> --> > --> > -->
> --> > --> >
> --> > --> > I am not suggesting "coupling their timers."  I am
> --> saying that
> --> the
> --> > --> value
> --> > --> > chosen for a timer (if one is used) to determine when it
> --> > --> is reasonable
> --> > --> to
> --> > --> > start RBridge peer discovery should take into
> --> account the time
> --> it
> --> > --> takes
> --> > --> > for the local spanning tree resolution.
> --> > --> >
> --> > --> > I feel the reason for this is self-evident but, just to
> --> > --> clarify, think
> --> > --> > about the process we're planning to use to 
> determine RBridge
> --> > --> nick-names.
> --> > --> > If we start this too early, we will be re-starting it
> --> > --> many times as we
> --> > --> > "hear from" new RBridge peers when the connecting links go
> --> active
> --> > --> after
> --> > --> > local bridges go to the forwarding state.  This would
> --> > --> apply only at
> --> > --> the
> --> > --> > system start up as - after that - you are quite correct
> --> > --> in asserting
> --> > --> it
> --> > --> > would be an ongoing process.
> --> > --> >
> --> > --> > Perhaps I should add some words to indicate that a delay
> --> > --> would not be
> --> > --> > necessary if the protocol mechanisms do not introduce
> --> > --> instability as a
> --> > --> > new peer is discovered.  So far, I have not seen any
> --> > --> indication that a
> --> > --> > "race-free" solution to accomplish this has been designed
> --> > --> - or talked
> --> > --> > about.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 40> there is also a requirement to 
> time-out learnt
> --> > --> information to
> --> > --> > --> maintain the filtering databases.
> --> > --> > -->
> --> > --> >
> --> > --> > There would be, if we were doing that.  Instead,
> --> we're adopting
> --> a
> --> > --> > link-state routing protocol and they tend to have
> --> that covered.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 41> periodically or on demand
> --> > --> > -->
> --> > --> >
> --> > --> > See the response to your point (Sgai 40) above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 42> potentially there is an unencapsulated
> --> > --> interface for each
> --> > --> > --> physical interface of the RBridge. It is true that
> --> > --> you can model
> --> > --> all
> --> > --> > --> of them as a single separate logical interface, but
> --> > --> then we need
> --> > --> to
> --> > --> > --> replicate the frame according to a bitmask 
> that tells on
> --> which
> --> > --> > physical
> --> > --> > --> interface the RBridge is designated.
> --> > --> > -->
> --> > --> >
> --> > --> > Again, your use of a "bitmask" is an implementation
> --> > --> choice as opposed
> --> > --> > to a logical model.
> --> > --> >
> --> > --> > As you observe, I do "model all of them as a single
> --> > --> separate logical
> --> > --> > interface" and if you want to "replicate the frame
> --> according to
> --> a
> --> > --> > bitmask that tells on which physical interface the
> --> RBridge is
> --> > --> > designated" - you're absolutely free to do so.
> --> > --> >
> --> > --> > Personally, I think this is far too much implementation
> --> > --> stuff for a
> --> > --> > protocol specification, let alone an architecture 
> document.
> --> > --> >
> --> > --> > -->
> --> > --> > --> Sgai 43> can we clarify that this means "drop BPDUs".
> --> > --> > -->
> --> > --> >
> --> > --> > Yes.
> --> > --> >
> --> > --> > -- [snip --
> --> > -->
> --> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
> 



Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1IhGjJ010510 for <[e-mail]>; Wed, 1 Nov 2006 10:43:16 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 01 Nov 2006 10:43:12 -0800 (PST)
Received: from sun.com ([129.150.22.255]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Wed, 01 Nov 2006 10:43:12 -0800 (PST)
Date: Wed, 01 Nov 2006 10:43:11 -0800
From: Radia Perlman <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Compromise proposal---allowing tradeoff between computation and optimality of delivery
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 18:43:46 -0000
Status: RO
Content-Length: 2422

There is understandable nervousness about the need to compute
per-ingress trees for every RBridge, and optimality of delivery.
I actually was dubious about whether people *really* wanted
to have to compute per-ingress trees.

Here's a proposal that will allow tradeoff between overhead of
computation and optimality of delivery. If people really want
they can have RBridges compute trees rooted at every RBridge. Or they
can have all multicast delivered on a single shared tree. Or anything in 
between.
I'm arbitrarily picking the zero configuration option being a single tree.

The new shim format allows the ingress RBridge to specify the
distribution tree for multicast, by putting into the "egress RBridge"
field a tree rooted at at the specified RBridge.

In this proposal, by default, the only tree that will be computed is a 
single shared
tree rooted at the RBridge with smallest MAC address. Let's say that
RBridge has nickname "71". By specifying 71 as egress RBridge in
a multicast packet, the delivery path will be via the bidirectional
tree rooted at 71.

An RBridge can be configured to demand that it, too, be the root of
a tree, and it informs the other RBridges with a flag in its link state
packet.

So now we have a subset of RBridges that can be used as roots of trees, 
because
they have specified that in their link state packet.
Let's say that RBridges with nicknames 11, 15, 71, 222, and 259 all
have announced that they want to be roots of trees.

Then an ingress RBridge, say R2, with nickname 11, can send a
multicast/unknown destination packet with "ingress"=11 (its own)
and "egress"=11 (because it said it wanted to be a root). Or it could
choose any of the other potential ones (15, 71, 222, 259).

Likewise, an ingress RBridge, say R3, with nickname 13, who has
not requested to be the root of a tree, can specify only
the trees 11, 15, 71, 222, 259. Note it cannot specify "13", since we
are assuming it has not requested that all RBridges calculate a tree 
rooted at itself.

If no RBridges are configured to say they want to be the root,
then only a single tree will get computed---the one rooted
at 71.

So the zero configuration option is a single shared tree (still filtered
based on IP multicast announcements and VLANs) rooted at the RBridge with
smallest MAC address. But by configuration, more and more optimality
can be introduced by having RBridges compute more trees.

Radia



Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1I8LCH029331 for <[e-mail]>; Wed, 1 Nov 2006 10:08:22 -0800 (PST)
Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 01 Nov 2006 10:07:38 -0800
Received: from scsmsx332.sc.intel.com (HELO scsmsx332.amr.corp.intel.com) ([10.3.90.6]) by fmsmga001.fm.intel.com with ESMTP; 01 Nov 2006 10:03:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: i="4.09,379,1157353200";  d="scan'208"; a="155972004:sNHT63830179"
Received: from scsmsx411.amr.corp.intel.com ([10.3.90.30]) by scsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211);  Wed, 1 Nov 2006 10:03:14 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Nov 2006 10:03:14 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Comments on:http://www.ietf.org/internet-drafts/dr	aft-ietf-trill-rbridge-arch-01.txt
Thread-Index: Acb93Slx+JvpA+UER+Wd95pdzAFo5AAAnVIw
From: "Wadekar, Manoj K" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, "Silvano Gai" <[e-mail]>
X-OriginalArrivalTime: 01 Nov 2006 18:03:14.0773 (UTC) FILETIME=[00649050:01C6FDE0]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA1I8LCH029331
Cc: [e-mail]
Subject: Re: [rbridge] Comments on:http://www.ietf.org/internet-drafts/dr	aft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 18:08:45 -0000
Status: RO
Content-Length: 6451

For Data Center networks, increasing bisectional bandwidth is very
important and "load splitting between multiple paths" is important to
achieve this. L2 ECMP is logical way of doing it. This is how I read as
well.

What is the alternative? I think multiple trees rooted at each node and
using shortest path to the destination is a limited approach as compared
to L2 ECMP.


Thanks,
- Manoj

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Gray, Eric
Sent: Wednesday, November 01, 2006 9:32 AM
To: Silvano Gai
Cc: [e-mail]
Subject: Re: [rbridge] Comments
on:http://www.ietf.org/internet-drafts/dr
aft-ietf-trill-rbridge-arch-01.txt

Silvano,

	Let's leave-off restating our cases, and simply let others 
comment on what they think is meant by this phrase in the charter.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 12:22 PM
--> To: Gray, Eric
--> Cc: [e-mail]
--> Subject: RE: [rbridge] Comments on: 
--> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
-arch-01.txt
--> 
--> Eric,
--> 
--> If the sentence "load-splitting among multiple paths", does not mean
--> Layer 2 ECMP, what does it mean?
--> 
--> How can I split the load among multiple paths, without doing
--> multipathing?
--> 
--> To split the load, I need at least two paths, If they are not Equal
--> Cost, what are they?
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[e-mail]]
--> > Sent: Wednesday, November 01, 2006 9:09 AM
--> > To: Silvano Gai
--> > Cc: [e-mail]
--> > Subject: RE: [rbridge] Comments on: http://www.ietf.org/internet-
--> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > 
--> > Silvano,
--> > 
--> > 	There is a difference.  I've been participating in this working
--> > group for some time, and I have not heard anyone suggest 
--> using L2 ECMP
--> > is what the charter means by "load-splitting among 
--> multiple paths."
--> > 
--> > 	However, I agree we need to be fair.  Consequently, let's ask
--> > other people to weigh in on this issue.  You assert that 
--> the charter
--> > means to include L2 ECMP as an explicit requirement of 
--> the TRILL work.
--> > I assert that it does not.
--> > 
--> > 	What do other people say?
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: Silvano Gai [mailto:[e-mail]]
--> > --> Sent: Wednesday, November 01, 2006 11:29 AM
--> > --> To: Gray, Eric
--> > --> Cc: [e-mail]
--> > --> Subject: RE: [rbridge] Comments on:
--> > --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> > --> -arch-01.txt
--> > -->
--> > --> Eric,
--> > -->
--> > --> When I propose something that is not in the charter, it is
--> > --> out of scope
--> > --> because not in the charter; when I propose something 
--> that is in
--> the
--> > --> charter, it is out of scope because "this is not what 
--> the charter
--> is
--> > --> meant to
--> > --> describe."
--> > -->
--> > --> Let's be fair!
--> > -->
--> > --> IMHO, if TRILL does not support Layer 2 ECMP, it is not
--> > --> interesting at
--> > --> all for us. All the interest in replacing Spanning Tree is
--> > --> to get Layer
--> > --> 2 ECMP.
--> > -->
--> > --> -- Silvano
--> > -->
--> > --> > -----Original Message-----
--> > --> > From: Gray, Eric [mailto:[e-mail]]
--> > --> > Sent: Wednesday, November 01, 2006 8:20 AM
--> > --> > To: Silvano Gai
--> > --> > Cc: [e-mail]
--> > --> > Subject: RE: [rbridge] Comments on:
--> http://www.ietf.org/internet-
--> > --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > --> >
--> > --> > Silvano,
--> > --> >
--> > --> > 	As I said in my other reply, this is not what the
--> charter is
--> > --> meant
--> > --> > to
--> > --> > describe.
--> > --> >
--> > --> > --
--> > --> > Eric
--> > --> >
--> > --> > --> -----Original Message-----
--> > --> > --> From: Silvano Gai [mailto:[e-mail]]
--> > --> > --> Sent: Wednesday, November 01, 2006 1:08 AM
--> > --> > --> To: Gray, Eric
--> > --> > --> Cc: [e-mail]
--> > --> > --> Subject: RE: [rbridge] Comments on:
--> > --> > --> 
--> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> > --> > --> -arch-01.txt
--> > --> > -->
--> > --> > -->
--> > --> > --> Eric,
--> > --> > -->
--> > --> > --> The charter says:
--> > --> > --> "load-splitting among multiple paths"
--> > --> > --> The pragmatic way to achieve this is to 
--> implement Layer 2
--> ECMP
--> > --> > -->
--> > --> > --> -- Silvano
--> > --> > -->
--> > --> > -->
--> > --> > --> > -----Original Message-----
--> > --> > --> > From: Gray, Eric [mailto:[e-mail]]
--> > --> > --> > Sent: Tuesday, October 31, 2006 9:25 AM
--> > --> > --> > To: Silvano Gai
--> > --> > --> > Cc: [e-mail]
--> > --> > --> > Subject: RE: [rbridge] Comments on:
--> > --> http://www.ietf.org/internet-
--> > --> > --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > --> > --> >
--> > --> > --> > Silvano,
--> > --> > --> >
--> > --> > --> > 	See below...
--> > --> > --> >
--> > --> > --> > --
--> > --> > --> > Eric
--> > --> > --> >
--> > --> > --> > -- [snip] --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 2> I think we should explicitly 
--> mention layer 2
--> > --> > --> multipath.
--> > --> > --> > -->
--> > --> > --> > -- [snip] --
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > What do you mean by layer 2 multipath?
--> > --> > --> >
--> > --> > --> > Do you mean "link bundling" or something else?
--> > --> > --> >
--> > --> > --> > Are we trying now to apply ECMP to routing 
--> advertisements
--> > --> > --> for layer
--> > --> > --> > two reachability?  That's a big step, particularly
--> > --> when we need
--> > --> to
--> > --> > --> > retain compatibility with existing 802.1 bridges.
--> > --> > --> >
--> > --> > --> > I don't recall seeing anything about this in 
--> the problem
--> > --> statement
--> > --> > --> > document, so I don't know of any reason why we should
--> > --> > --> include it in
--> > --> > --> > the architecture.
--> > --> > --> >
--> > --> > --> > --
--> > --> > --> > Eric
--> > --> > -->
--> > -->
--> 
_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1I3arh027629 for <[e-mail]>; Wed, 1 Nov 2006 10:03:36 -0800 (PST)
Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Wed, 01 Nov 2006 10:03:23 -0800
X-Server-Uuid: 79DB55DB-3CB4-423E-BEDB-D0F268247E63
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id A5EBB2B2; Wed, 1 Nov 2006 10:03:22 -0800 (PST)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 6CFEB2AF; Wed, 1 Nov 2006 10:03:22 -0800 (PST)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EJR75459; Wed, 1 Nov 2006 10:03:13 -0800 (PST)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 4E2E120501; Wed, 1 Nov 2006 10:03:13 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 1 Nov 2006 10:03:12 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr aft-ietf-trill-rbridge-arch-01.t xt
Thread-Index: Acb93t+7S5iS6iCaQIihA/IQZt0THgAAMUXg
From: "Caitlin Bestler" <[e-mail]>
To: "Joel M. Halpern" <[e-mail]>, [e-mail]
X-WSS-ID: 69563EE138S8156061-01-01
Content-Type: text/plain; charset=us-ascii
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA1I3arh027629
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr aft-ietf-trill-rbridge-arch-01.t xt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 18:03:58 -0000
Status: RO
Content-Length: 940

[e-mail] wrote:
> With regard to the multiple path support, my understanding of
> the charter was that it was intended to permit the usage of
> multiple paths by traffic from different places.  I.e. to
> lift the restriction of STP to a single tree for the entire bridged
> network. I did not think that it meant that traffic from a given
> ingress to a given egress was supposed to be able to use
> multiple paths, although I can see how a reader would get that.
> 

My take is that RBridges should not break any existing scheme that
spreads traffic across multiple paths, and I cannot think of any
way in which it might do so.

It is concievable that RBridges *could* be specced to load balance
traffic between any two rbridges, but it would be challenging to
do so in a way that maintained in-order delivery. Therefore I 
think most people would agree that such functionality should
not be part of the base protocol.




Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1I0Om8025801 for <[e-mail]>; Wed, 1 Nov 2006 10:00:24 -0800 (PST)
Received: from orsmga001.jf.intel.com ([10.7.209.18]) by mga09.intel.com with ESMTP; 01 Nov 2006 10:00:23 -0800
Received: from scsmsx331.sc.intel.com (HELO scsmsx331.amr.corp.intel.com) ([10.3.90.4]) by orsmga001.jf.intel.com with ESMTP; 01 Nov 2006 10:00:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: i="4.09,379,1157353200";  d="scan'208"; a="154320076:sNHT1532046495"
Received: from scsmsx411.amr.corp.intel.com ([10.3.90.30]) by scsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211);  Wed, 1 Nov 2006 10:00:20 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Nov 2006 10:00:19 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Comments on:http://www.ietf.org/internet-drafts/dr	aft-ietf-trill-rbridge-arch-01.txt
Thread-Index: Acb93hY4Z+Fjr1WcQqaQNaj4usmhcwAARsDg
From: "Wadekar, Manoj K" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, "Silvano Gai" <[e-mail]>
X-OriginalArrivalTime: 01 Nov 2006 18:00:20.0595 (UTC) FILETIME=[98931C30:01C6FDDF]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA1I0Om8025801
Cc: [e-mail]
Subject: Re: [rbridge] Comments on:http://www.ietf.org/internet-drafts/dr	aft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 18:01:46 -0000
Status: RO
Content-Length: 43168

Hi Eric,

	802 is definitely not Ethernet. 802.3 defined Ethernet MAC and
Phy functionality. 802.1 (not only Q) defines bridging functionality -
not only for Ethernet, for Wireless (802.11, 802.16 etc), for RPR
(802.17) - many underlying technologies. 

	So, trying to define "Ethernet" in a document like this is not
only incorrect, it can be very misleading and confusing.

Thanks,
- Manoj

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Gray, Eric
Sent: Wednesday, November 01, 2006 9:46 AM
To: Silvano Gai
Cc: [e-mail]
Subject: Re: [rbridge] Comments
on:http://www.ietf.org/internet-drafts/dr
aft-ietf-trill-rbridge-arch-01.txt

Silvano,

	I think that there may be a compromise we can arrive at here.

	I propose changing the defintion of "Ethernet" to read:

'Ethernet: In this document the term "Ethernet" is used to represent
 Ethernet-like and/or Ethernet-equivalent technologies - explicitly
 including 802.3 [802.3 ref], 802.1Q [802.Q ref] and other closely 
 related LAN technologies, and NOT explicitly excluding any other 
 Ethernet-like and/or Ethernet-equivalent technology that exists, or
 may be developed in the future.'

	Using this definition should clarify that I am not necessarily
using the term in the way that some people may feel it should be used,
while clearly stating what I am using the term to mean.  This should
also reduce your concern that I am apprently equating Ethernet and 
802 in general.  It also satisfies my intention to be inclusive.

	How does this sound?

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 1:21 AM
--> To: Gray, Eric
--> Cc: [e-mail]
--> Subject: RE: [rbridge] Comments on: 
--> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> -arch-01.txt
--> 
--> 
--> Eric,
--> 
--> I disagree.
--> 
--> I don't think it is wise for TRILL to redefine the term Ethernet.
--> Ethernet is a term that has a well known meaning in the industry.
--> The original definition is:
--> Digital Equipment Corporation, Intel, Xerox, The Ethernet, 
--> Version 2.0,
--> November 1982.
--> Which has been then standardized by IEEE 802.3.
--> 
--> To speak about other IEEE 802 standards that are alive and 
--> used, IEEE
--> 802.11 (Wireless LAN) and IEEE 802.17 (Resilient Packet 
--> Ring Working)
--> have nothing to do with Ethernet.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[e-mail]]
--> > Sent: Tuesday, October 31, 2006 2:44 PM
--> > To: Silvano Gai
--> > Cc: [e-mail]
--> > Subject: RE: [rbridge] Comments on: http://www.ietf.org/internet-
--> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > 
--> > Silvano,
--> > 
--> > 	To be perfectly frank, I am unaware of any reason not to include
--> > token ring or any other obsolete form of "Ethernet equivalent
--> technology"
--> > - this is one of the reason to focus on the SHIM as 
--> separate from any
--> > specific encapsulation above or below the SHIM.
--> > 
--> > 	If you want to check it against all 802 activities, that's fine.
--> > I would suggest, however, that even though people are 
--> realistically
--> not
--> > going to implement most of the hairy/scary versions in an 
--> RBridge, I
--> do
--> > not know of a good reason to exclude them at this point.  
--> In abstract,
--> > it is certainly possible that people will be able to work out
--> specifics
--> > of implementation - if and when they decide to do so.
--> > 
--> > 	After all, we (the industry) have been building translation
--> bridges
--> > for these technologies for decades.
--> > 
--> > 	However, I am open to scoping the architecture to apply only to
--> a
--> > limited subset of 802 technologies, if that is what would 
--> make people
--> > happy...
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: Silvano Gai [mailto:[e-mail]]
--> > --> Sent: Tuesday, October 31, 2006 5:34 PM
--> > --> To: Gray, Eric
--> > --> Cc: [e-mail]
--> > --> Subject: RE: [rbridge] Comments on:
--> > --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> > --> -arch-01.txt
--> > -->
--> > -->
--> > --> Eric,
--> > -->
--> > --> A quick reply:
--> > --> Are you telling me that the term Ethernet includes Token Ring,
--> Token
--> > --> Bus, DQDB?
--> > -->
--> > --> This is what you are doing when you say that Ethernet 
--> is IEEE 802
--> > --> instead of IEEE 802.3.
--> > -->
--> > --> This is NOT a terminology issue. If the term Ethernet means
--> > --> 802 I need
--> > --> to check the operation of TRILL against all the 802 
--> technologies.
--> > -->
--> > --> -- Silvano
--> > -->
--> > --> > -----Original Message-----
--> > --> > From: Gray, Eric [mailto:[e-mail]]
--> > --> > Sent: Tuesday, October 31, 2006 1:46 PM
--> > --> > To: Silvano Gai
--> > --> > Cc: [e-mail]
--> > --> > Subject: RE: [rbridge] Comments on:
--> http://www.ietf.org/internet-
--> > --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > --> >
--> > --> >
--> > --> >
--> > --> > -- [snip] --
--> > --> > -->
--> > --> > --> Sgai 4> an RBridge must be also able to send 
--> two copies of a
--> > --> > --> unicast/multicast/broadcast packet on the same 
--> port when it
--> > --> > --> acts as a designated RBridge (one copy is 
--> encapsulated, the
--> > --> > --> other not).
--> > --> > -->
--> > --> >
--> > --> > This, I think, refers to the immediately preceding 
--> text in the
--> > --> > architecture:
--> > --> >
--> > --> >         Forwarding information is derived from the 
--> combination
--> of
--> > --> >         attached MAC address learning, snooping of
--> > --> multicast-related
--> > --> >         protocols (e.g. - IGMP), and routing
--> > --> advertisements and path
--> > --> >         computations using the link-state routing protocol.
--> > --> >
--> > --> > While your comment is a reasonable one - although 
--> potentially
--> > --> > implementation specific - it does not appear to 
--> have any bearing
--> > --> > on this text.
--> > --> >
--> > --> >
--> > --> > -- [snip] --
--> > --> > -->
--> > --> > --> Sgai 5> here there is some confusion between 
--> 802 and 802.3
--> > --> > -->
--> > --> >
--> > --> > This  refers (I believe) to the immeditately preceding text:
--> > --> >
--> > --> >         The following terminology is defined in 
--> other documents.
--> A
--> > --> brief
--> > --> >         definition is included in this section for
--> > --> convenience and -
--> > --> in
--> > --> >         some cases - to remove any ambiguity in how the
--> > --> term may be
--> > --> used
--> > --> >         in this document, as well as derivative documents
--> > --> intended to
--> > --> >         specify components, protocol, behavior and 
--> encapsulation
--> > --> >         relative to the architecture specified in 
--> this document.
--> > --> >
--> > --> >         o  802: IEEE Specification for the Ethernet
--> architecture,
--> > --> i.e.,
--> > --> >            including hubs and bridges.
--> > --> >
--> > --> > In this text, I explicitly state that these terms 
--> are defined
--> > --> elsewhere.
--> > --> > I am also trying to use the most generic definition 
--> of Ethernet
--> > --> possible.
--> > --> >
--> > --> > The reason for this is that the problem statement does
--> > --> not restrict
--> > --> the
--> > --> > solution to 802.3.
--> > --> >
--> > --> > There is some confusion in referring to 802.3 in 
--> any case: we
--> > --> explicitly
--> > --> > want to include 802.1Q - as well as all of its 
--> variations and
--> > --> extensions.
--> > --> >
--> > --> > Consequently, we define the term Ethernet in the broadest
--> possible
--> > --> sense.
--> > --> >
--> > --> >
--> > --> > -- [snip] --
--> > --> > -->
--> > --> > -->        o  Bridge Spanning Tree (BST): an Ethernet (L2,
--> 802.1D)
--> > --> > -->           forwarding protocol based on the topology
--> > --> of a spanning
--> > --> > tree.
--> > --> > -->
--> > --> > --> Sgai 6> I have never seen the acronym BST, 
--> everyone use STP.
--> > --> > -->
--> > --> >
--> > --> > I do not know if this term is used in any of the other
--> documents,
--> > --> > but it is not used in this one.  Unless someone 
--> objects, I am
--> only
--> > --> > too happy to remove it from this document.
--> > --> >
--> > --> > From a historical perspective, this was defined this way
--> > --> originally
--> > --> > because we were re-using the term spanning tree instead
--> > --> of IRT.  It
--> > --> > was causing amazing communication difficulties, so 
--> we came up
--> with
--> > --> > the term IRT.  Now we don't need to differentiate BST.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 7> for Ethernet is better to reference 802.3
--> > --> > -->
--> > --> >
--> > --> > See my response to your point (Sgai 5) above.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  Hub: an Ethernet (L2, 802) device with
--> > --> multiple ports
--> > --> which
--> > --> > -->
--> > --> > --> sgai 8> for Hub is better to reference 802.3
--> > --> > -->
--> > --> >
--> > --> > See my response to your point (Sgai 5) above.  By the
--> > --> definition we
--> > --> > provide in this document, Ethernet is defined 
--> broadly to include
--> > --> > 802 technologies.  This is reasonable, because the term was
--> stolen
--> > --> > by IEEE from a technology stolen from a satellite 
--> communication
--> > --> > protocol.  Ironic that 802.3 does not include wireless, all
--> things
--> > --> > considered.  Certainly the term "Ethernet" should...
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  Node: a device with an L2 (MAC) address
--> > --> that sources
--> > --> and/or
--> > --> > -->            sinks L2 frames.
--> > --> > -->
--> > --> > --> Sgai 9> The IEEE term is "station".
--> > --> > -->
--> > --> >
--> > --> > However, we in the IETF are more familiar with the 
--> term "node."
--> > --> >
--> > --> > This is hardly a significant issue.  if people agree that
--> > --> we should
--> > --> > use the term "station" as opposed to "node", then I will
--> > --> change it.
--> > --> >
--> > --> > Note that we should be consistent in this usage, if we
--> > --> decide to do
--> > --> > yet another terminology evolution.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  Segment: an Ethernet link, either a single
--> physical
--> > --> link or
--> > --> > -->            emulation thereof (e.g., via hubs) or a
--> > --> logical link or
--> > --> > -->            emulation thereof (e.g., via bridges).
--> > --> > -->
--> > --> > --> Sgai 10> IEEE uses the term "LAN segment"
--> > --> > -->
--> > --> >
--> > --> > I agree, however this is the definition we agreed on here.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  Subnet, Ethernet: a single segment, 
--> or a set of
--> > --> segments
--> > --> > -->            interconnected by a CRED (see 
--> section 2.2); in
--> the
--> > --> latter
--> > --> > -->
--> > --> > --> sgai 11> There is no concept of subnet in IEEE. 
--> Subnet is
--> > --> typically
--> > --> > --> an IP subnet, and, even if it is common to have 
--> one subnet
--> per
--> > --> LAN,
--> > --> > --> this is not the only possibility. Pragmatically 
--> IP subnets
--> and
--> > --> > --> Ethernet LAN are unrelated concepts.
--> > --> > -->
--> > --> >
--> > --> > Again, we are defining this term for use in this
--> > --> document.  Does its
--> > --> > use (not its definition) cause confusion or ambiguity?
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->            case, the subnet may or may not be 
--> equivalent to
--> a
--> > --> single
--> > --> > -->            segment. Also a subnet may be 
--> referred to as a
--> > --> broadcast
--> > --> > -->            domain or LAN. By definition, all 
--> nodes within an
--> > --> Ethernet
--> > --> > -->            Subnet (broadcast domain or LAN) must have L2
--> > --> connectivity
--> > --> > -->            with all other nodes in the same 
--> Ethernet subnet.
--> > --> > -->
--> > --> > -->         o  TRILL: Transparent Interconnect over Lots
--> > --> of Links -
--> > --> the
--> > --> > -->            working group and working name for the
--> > --> problem domain
--> > --> to be
--> > --> > -->            addressed in this document.
--> > --> > -->
--> > --> > -->         o  Unicast Forwarding: forwarding methods
--> > --> that apply to
--> > --> frames
--> > --> > -->            with unicast destination MAC addresses.
--> > --> > -->
--> > --> > -->         o  Unknown Destination - a destination 
--> for which a
--> > --> receiving
--> > --> > -->            device has no filtering database entry.
--> > --> Destination
--> > --> (layer
--> > --> > -->
--> > --> > --> sgai 12> the stations receive the unknown 
--> unicast and have
--> > --> filtering
--> > --> > --> information, only the bridges don't. I propose to
--> > --> replace device
--> > --> with
--> > --> > --> bridge.
--> > --> > -->
--> > --> >
--> > --> > Again, it is the intention to provide as broad a 
--> definition as
--> > --> possible
--> > --> > without introducing confusion or ambiguity.  An end node
--> > --> (or station)
--> > --> > has - in a sense - a filtering database (it's mine, or
--> > --> it's for the
--> > --> bit
--> > --> > bucket).
--> > --> >
--> > --> > We need to explicitly include 802.1D forwarding devices
--> > --> and RBridges.
--> > --> >
--> > --> > However, the definition should specify "forwarding 
--> device" - as
--> > --> opposed
--> > --> > to just "receiving device."
--> > --> >
--> > --> > I will change that.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->            2) addresses are typically "learned" 
--> by (layer 2)
--> > --> > forwarding
--> > --> > -->            devices via a process commonly referred to
--> > --> as "bridge
--> > --> > learning".
--> > --> > -->
--> > --> > --> Sgai 13> in IEEE, the term used is "learning" instead
--> > --> of "bridge
--> > --> > learning"
--> > --> > -->
--> > --> >
--> > --> > However, the term defined in this document is 
--> "bridge learning."
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  VLAN: Virtual Local Area Network. VLANs in
--> > --> general fall
--> > --> > into
--> > --> > -->            two categories: link (or port) 
--> specific VLANs and
--> > --> tagged
--> > --> > -->            VLANs. In the former case, all frames
--> > --> forwarded and all
--> > --> > -->            directly connected nodes are assumed to be
--> > --> part of a
--> > --> single
--> > --> > -->            VLAN.  In the latter case, VLAN tagged
--> > --> frames are used
--> > --> to
--> > --> > -->            distinguish which VLAN each frame is intended
--> for.
--> > --> > -->
--> > --> > --> Sgai 14> This definition is not completely correct, I
--> prefer:
--> > --> > -->
--> > --> > --> VLAN technology introduces the following three 
--> basic types
--> of
--> > --> frame:
--> > --> > --> a) Untagged frames;
--> > --> > --> b) Priority-tagged frames; and
--> > --> > --> c) VLAN-tagged frames.
--> > --> > -->
--> > --> > --> An untagged frame or a priority-tagged frame does not
--> > --> carry any
--> > --> > --> identification of the VLAN to which it belongs. Such
--> > --> frames are
--> > --> > --> classified as belonging to a particular VLAN based on
--> > --> parameters
--> > --> > --> associated with the receiving Port, or, through 
--> proprietary
--> > --> extensions
--> > --> > --> to IEEE 802.1Q standard, based on the data content of
--> > --> the frame
--> > --> (e.g.,
--> > --> > --> MAC Address, layer 3 protocol ID, etc.).
--> > --> > -->
--> > --> > --> A VLAN-tagged frame carries an explicit
--> > --> identification of the VLAN
--> > --> to
--> > --> > --> which it belongs; i.e., it carries a tag header 
--> that carries
--> a
--> > --> non-
--> > --> > null
--> > --> > --> VID. Such a frame is classified as belonging to a
--> > --> particular VLAN
--> > --> > based
--> > --> > --> on the value of the VID that is included in the tag
--> > --> header. The
--> > --> > presence
--> > --> > --> of the tag header carrying a non-null VID means that
--> > --> some other
--> > --> > device,
--> > --> > --> either the originator of the frame or a 
--> VLAN-aware Bridge,
--> has
--> > --> mapped
--> > --> > --> this frame into a VLAN and has inserted the 
--> appropriate VID.
--> > --> > -->
--> > --> >
--> > --> > So, you're getting into the details of the 
--> technology and - in
--> > --> particular
--> > --> > the encapsulation.  I will expand the definition to 
--> include a
--> > --> possibility
--> > --> > that other criteria may be used to define a "VLAN port" -
--> although
--> > --> this is
--> > --> > isomorphic to a logical model in which a device
--> > --> implementation uses
--> > --> some
--> > --> > criteria to decide that a subset of the traffic received
--> > --> on a specific
--> > --> > physical port is to be forwarded as if received on a
--> > --> specific logical
--> > --> > port.
--> > --> >
--> > --> > The key point in this definition is that a VLAN is a
--> > --> "Virtual LAN" -
--> > --> > meaning
--> > --> > it consists of a subset of the physical and L2 connectivity
--> > --> corresponding
--> > --> > to
--> > --> > a "logical LAN."  The intent is to "rise above" the
--> technological
--> > --> > approaches
--> > --> > and encapsulations to establish a generic definition that
--> > --> is loosely
--> > --> tied
--> > --> > to
--> > --> >
--> > --> > ways that this generic definition is actually implemented.
--> > --> >
--> > --> > Again, bearing in mind the way that the term is 
--> defined, does
--> the
--> > --> usage of
--> > --> > the term cause confusion or ambiguity?
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  CRED Forwarding Table (CFT): the per-hop
--> forwarding
--> > --> table
--> > --> > -->            populated by the RBridge Routing Protocol;
--> > --> forwarding
--> > --> > within
--> > --> > -->            the CRED is based on a lookup of the 
--> CRED Transit
--> > --> Header
--> > --> > -->            (CTH) encapsulated within the 
--> outermost received
--> L2
--> > --> header.
--> > --> > -->            The outermost L2 encapsulation in this
--> > --> case includes
--> > --> the
--> > --> > -->            source MAC address of the immediate
--> > --> upstream RBridge
--> > --> > -->            transmitting the frame and destination MAC
--> > --> address of
--> > --> the
--> > --> > -->            receiving RBridge for use in the unicast
--> forwarding
--> > --> case.
--> > --> > -->
--> > --> > --> Sgai 15> In section 7 of
--> > --> > -->
--> > --> 
--> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-
--> > --> > 00.txt
--> > --> > --> we proposed that when two rbridges are 
--> connected by a point
--> to
--> > --> point
--> > --> > --> link the outer MAC addresses may be set to a
--> > --> predefined value in
--> > --> > --> transmission and ignored in reception.
--> > --> > -->
--> > --> >
--> > --> > I'm not sure how your proposal intends to determine that
--> > --> a link is in
--> > --> > fact point-to-point and does not just look that way.
--> > --> >
--> > --> > I prefer to use the same encapsulation in all cases where it
--> will
--> > --> work.
--> > --> >
--> > --> > The optimization associated with using some form of
--> > --> null-encapsulation
--> > --> > is of dubious value, given that it may not be possible to
--> > --> be certain a
--> > --> > point-to-point link is - and will remain - in fact a
--> > --> point-to-point
--> > --> > link.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  CFT-IRT: a forwarding table used for 
--> propagation
--> of
--> > --> > -->            broadcast, multicast or flooded 
--> frames along the
--> > --> Ingress
--> > --> > -->            RBridge Tree (IRT).
--> > --> > -->
--> > --> > --> Sgai 16> is it a forwarding table or is it a
--> > --> filtering database.
--> > --> Since
--> > --> > --> the "miss" behavior is to flood, I see it as a
--> > --> filtering database.
--> > --> > -->
--> > --> >
--> > --> > What state was "miss" behavior from - Hawaii?  :-)
--> > --> >
--> > --> > It is analogous to a filtering database entry, but it is not
--> that.
--> > --> >
--> > --> > Clearly there are more things in this world than can be
--> classified
--> > --> > in this taxonomy.  However, given these choices, it is a
--> > --> forwarding
--> > --> > table.
--> > --> >
--> > --> > This is not a misbehavior, in that the same "base" tree
--> > --> is used for
--> > --> > broadcast and multicast traffic as well as flooded
--> > --> traffic.  It may
--> > --> > be arguable that flooding is a misbehavior, but I 
--> seem to recall
--> > --> > that people still see it as a necessary evil.
--> > --> >
--> > --> > It is also not "miss" behavior (as in "cache miss") in
--> > --> the multicast
--> > --> > and broadcast case, either.
--> > --> >
--> > --> > I believe the definition is quite correct and easy to
--> understand,
--> > --> > provided you're not reading it with preconceived 
--> misconceptions
--> > --> > about its meaning.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  CRED Transit Header (CTH): a 'shim' 
--> header that
--> > --> > encapsulates
--> > --> > -->            the ingress L2 frame and persists 
--> throughout the
--> > --> transit of
--> > --> > a
--> > --> >
--> > --> > -->            CRED, which is further encapsulated within
--> > --> a hop-by-hop
--> > --> L2
--> > --> > -->            header (and trailer). The hop-by-hop L2
--> > --> encapsulation
--> > --> in
--> > --> > this
--> > --> >
--> > --> > -->            case includes the source MAC address of
--> > --> the immediate
--> > --> > -->            upstream RBridge transmitting the frame
--> > --> and destination
--> > --> MAC
--> > --> > -->            address of the receiving RBridge - 
--> at least in
--> the
--> > --> unicast
--> > --> > -->            forwarding case.
--> > --> > -->
--> > --> > --> Sgai 17> is this true also for unknown unicast?
--> > --> > -->
--> > --> >
--> > --> > That is something that will be (may be already) 
--> decided in the
--> > --> protocol
--> > --> > specification.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  CRED Transit Table (CTT): a table that maps
--> ingress
--> > --> frame
--> > --> > L2
--> > --> > -->            destinations to egress RBridge 
--> addresses, used to
--> > --> determine
--> > --> > -->            encapsulation of ingress frames for 
--> transit of
--> the
--> > --> CRED.
--> > --> > -->
--> > --> > -->         o  Cooperating RBridges - those RBridges
--> > --> within a single
--> > --> > -->            Ethernet Subnet (broadcast domain or LAN)
--> > --> not having
--> > --> been
--> > --> > -->            configured to ignore each other. By 
--> default, all
--> > --> RBridges
--> > --> > -->            within a single Ethernet subnet will 
--> cooperate
--> with
--> > --> each
--> > --> > -->            other. It is possible for implementations
--> > --> to allow for
--> > --> > -->            configuration that will restrict
--> > --> "cooperation" between
--> > --> an
--> > --> > -->            RBridge and an apparent neighboring 
--> RBridge.  One
--> > --> reason
--> > --> > why
--> > --> > -->            this might occur is if the trust model
--> > --> that applies in
--> > --> a
--> > --> > -->            particular deployment imposes a need for
--> > --> configuration
--> > --> of
--> > --> > -->            security information.  By default no such
--> > --> configuration
--> > --> is
--> > --> > -->            required however - should it be used in
--> > --> any specific
--> > --> > scenario
--> > --> > -->
--> > --> > -->            - it is possible (either deliberately or
--> > --> inadvertently)
--> > --> to
--> > --> > -->            configure neighboring RBridges so 
--> that they do
--> not
--> > --> > cooperate.
--> > --> > -->
--> > --> > -->            In the remainder of this document, 
--> all RBridges
--> are
--> > --> assumed
--> > --> > -->            to be in a cooperating (default) 
--> configuration.
--> > --> > -->
--> > --> > --> Sgai 18> can RBridges cooperate in groups, e.g. four
--> Rbridges
--> > --> > connected
--> > --> > --> to a LAN cooperating two and two?
--> > --> > -->
--> > --> >
--> > --> > Yes.  There may be reasons why this might be done 
--> deliberately,
--> > --> however
--> > --> > - even in the absence of any "proof of concept"
--> > --> justification - it is
--> > --> a
--> > --> > really good idea to design the protocol to be robust in
--> > --> cases where a
--> > --> > set of RBridges may be (mis)configured in such a way as
--> > --> to be unable
--> > --> to
--> > --> > discover each other.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  Ingress RBridge Tree: a tree 
--> computed for each
--> edge
--> > --> RBridge
--> > --> > -->            and potentially for each VLAN in which that
--> RBridge
--> > --> > -->
--> > --> > --> sgai 19> why for each VLAN? I got the 
--> impression that there
--> > --> > --> was a single tree that was pruned differently for
--> > --> different VLANs.
--> > --> > -->
--> > --> >
--> > --> > Pruning may also take place at the ingress, if - for
--> > --> example - it has
--> > --> a
--> > --> > subset of interfaces that are not connected to any 
--> egress for
--> > --> particular
--> > --> > VLANs.  It is a small point but, in such cases, there is in
--> effect
--> > --> more
--> > --> > than one IRT even at the ingress.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->            participates - for delivery of broadcast,
--> > --> multicast and
--> > --> > -->            flooded frames from that RBridge to all
--> > --> relevant egress
--> > --> > -->            RBridges. This is the point-to-multipoint
--> > --> delivery tree
--> > --> > used
--> > --> > -->            by an ingress RBridge to deliver
--> > --> multicast, broadcast
--> > --> or
--> > --> > -->            flooded traffic.
--> > --> > -->
--> > --> > --> Sgai 20> the current version of the proposal 
--> speaks about a
--> > --> multicast
--> > --> > --> address, not point-to-point.
--> > --> > -->
--> > --> >
--> > --> > I did not say "point-to-point" (look again).
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  LPT: Learned Port Table. See 
--> Filtering Database.
--> > --> > -->
--> > --> > --> Sgai 21> not proper terminology, I would use
--> > --> "filtering database"
--> > --> > --> everywhere.
--> > --> > -->
--> > --> >
--> > --> > I am happy to remove this if there is no objection 
--> to my doing
--> so.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> sgai 22> I wired port is Ehernet, i.e. IEEE 802.3, a
--> > --> > --> wireless port is not Ethernet, it is IEEE 802.11.
--> > --> > -->
--> > --> >
--> > --> > See my response to your point (sgai 8) above.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> sgai 23> they learn because STP guarantees
--> > --> symmetrical forwarding
--> > --> > -->
--> > --> >
--> > --> > This (apparently) refers to the immeditately preceding text:
--> > --> >
--> > --> >         Conventional bridges contain a learned port table
--> > --> (LPT), or
--> > --> >         filtering database, and a spanning tree table
--> > --> (STT). The LPT
--> > --> >         allows a bridge to avoid flooding all received
--> > --> frames, as is
--> > --> >         typical for a hub or repeater. The bridge learns
--> > --> which nodes
--> > --> are
--> > --> >         accessible from a particular port by assuming
--> > --> bi-directional
--> > --> >         consistency:
--> > --> >
--> > --> > I'm not sure how picking at the peculiarities of 
--> STP behavior is
--> > --> > relevant to this description.  STP results in a 
--> single spanning
--> > --> > tree where each link is bi-directional.  This 
--> ensures that the
--> > --> > MAC frames are forwarded in a bi-directionally consistent
--> fashion.
--> > --> >
--> > --> > To replace this text with yours is to provide less 
--> information.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 24> active ports -> forwarding ports
--> > --> > -->
--> > --> >
--> > --> > "Active ports" was the exact wording suggested to me.  In
--> > --> context for
--> > --> > this working group "active ports" is more meaningful than
--> > --> "forwarding
--> > --> > ports."  For people not used to STP-speak, "forwarding
--> > --> port" might be
--> > --> > used to discriminate from a "code port."
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 25> there is no STT, there is a state associated
--> > --> with each
--> > --> port
--> > --> > --> that can be: disabled, blocking, listening, 
--> learning, and
--> > --> forwarding
--> > --> > -->
--> > --> >
--> > --> > Other than the issue with terminology, is this text 
--> wrong?  I am
--> > --> fairly
--> > --> > sure that different implementations handle the "port state"
--> > --> information
--> > --> > in different ways, and I am also reasonably sure that a
--> > --> "table" such
--> > --> as
--> > --> > the one described here is one of the ways it might be done.
--> > --> >
--> > --> > However, I agree with your assertion that this is the way
--> > --> that it is
--> > --> > usually talked about in an IEEE context, so - 
--> unless there are
--> > --> specific
--> > --> > objections - I can change the wording to be consistent
--> > --> with what you
--> > --> > suggest.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> sgai 26> disabled -> blocking
--> > --> > -->
--> > --> >
--> > --> > I can make this change as well.  However, from the
--> > --> perspective of what
--> > --> > we are trying to do, "disabled" is potentially a more
--> > --> correct term.
--> > --> It
--> > --> > is certainly more intuitively correct, outside of a
--> > --> strictly IEEE/STP
--> > --> > context.
--> > --> >
--> > --> > Symmetry is maintained in STP by blocking ports/links
--> > --> bi-directionally.
--> > --> > In such cases, a port is effectively disabled for bridges
--> > --> at either
--> > --> end
--> > --> > of the link for which a port is blocked, is it not?
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> sgai 27> I repeat a comment that I have made to other
--> > --> documents: "
--> > --> > --> The discussion about VLAN needs to be much more
--> > --> extensive. It is
--> > --> clear
--> > --> > --> from the mailing list discussion that VLANs can be
--> > --> used inside the
--> > --> > --> packet or in the Ethernet encapsulation of TRILL.
--> > --> These are two
--> > --> > --> different kinds of VLANs and their requirement need
--> > --> to be stated
--> > --> > --> separately. Q in Q needs also to be discussed. I
--> > --> propose to define
--> > --> > inner
--> > --> > --> and outer VLANs (with reference to the position of
--> > --> the tag in the
--> > --> > frame."
--> > --> > --> Here I think we are talking about outer VLANs
--> > --> > -->
--> > --> >
--> > --> > I responded to this in separate mail.  I wait to hear
--> > --> other opinions
--> > --> on
--> > --> > this subject.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 28> IMO all RBridges must be ingress RBridges,
--> > --> at least to
--> > --> > support
--> > --> > --> inband management, e.g. SNMP.
--> > --> > -->
--> > --> >
--> > --> > No.
--> > --> >
--> > --> > In order to ensure symmetry with RBridges not
--> > --> participating in STP,
--> > --> there
--> > --> > MUST be a designated RBridge that does all of the 
--> sending and
--> > --> receiving
--> > --> > of native encapsulated frames on a LAN segment.
--> > --> >
--> > --> > Any RBridge the loses the "Designated RBridge" 
--> election cannot
--> be
--> > --> either
--> > --> > an ingress or an egress for that LAN segment.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 29> same as above
--> > --> > -->
--> > --> >
--> > --> > Same as above.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 30> I think the previous definition is not needed.
--> > --> > -->
--> > --> >
--> > --> > This appears to refer to:
--> > --> >
--> > --> >         o  Local RBridge - the RBridge that forms and
--> > --> maintains the
--> > --> CFT-
--> > --> >            IRT entry (or entries) under discussion. The
--> > --> local RBridge
--> > --> >            may be an Ingress RBridge, or an egress 
--> RBridge with
--> > --> respect
--> > --> >            to any set of entries in the CFT-IRT.
--> > --> >
--> > --> > This defintion is needed.  It is subsequently used 
--> in at least 4
--> > --> places.
--> > --> > When discussing the behavior of a specific RBridge
--> > --> relative to a peer,
--> > --> > it is convenient to define the term "local RBridge."
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> sgai 31> why is it zero or more, if an RBridge 
--> exists, it
--> must
--> > --> have
--> > --> > --> a an IRT, I haven't seen any discussion to support
--> > --> multiple IRTs.
--> > --> > -->
--> > --> >
--> > --> > This was answered previously on the mailing list.
--> > --> Briefly, zero or
--> > --> > more is correct, given that an RBridge may not have
--> > --> forwarding entries
--> > --> > for frames it has received.  In these cases, a frame is
--> > --> not forwarded.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 32> I don't understand this. Since the current
--> > --> proposal uses
--> > --> a
--> > --> > --> multicast MAC address, what is needed is a bit map
--> > --> for each IRT
--> > --> that
--> > --> > --> says which ports are blocking and which are
--> > --> forwarding. You are
--> > --> > --> basically building a ST using ISIS.
--> > --> > -->
--> > --> >
--> > --> > This might be the case for a specific implementation.
--> > --> Whether it is
--> > --> > implemented as a "bit-mask" with "non-blocking"
--> > --> (forwarding) ports, or
--> > --> > is implemented as a full-blown table is largely dependent on
--> what
--> > --> other
--> > --> > information the local device requires in order to
--> > --> properly forwad the
--> > --> > frame.  If - for example - a device has multiple
--> > --> different port types,
--> > --> > it may need to have more information for each port (or that
--> > --> information
--> > --> > may be added later on).
--> > --> >
--> > --> > All of these are implementation choices that are
--> > --> logically represented
--> > --> > by the table described here.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 33> I don't get the pair.
--> > --> > -->
--> > --> >
--> > --> > Since this immediately follows:
--> > --> >
--> > --> >         Each entry would contain an indication of 
--> which single
--> > --> interface
--> > --> >         a broadcast, multicast or flooded frame would be
--> > --> forwarded for
--> > --> >         each (ingress RBridge, egress RBridge) pair.
--> > --> >
--> > --> > I don't get what you don't get.
--> > --> >
--> > --> > The pair refers to the tuple "(ingress RBridge, egress
--> RBridge)."
--> > --> >
--> > --> > This might be the point at which your earlier point (Sgai 4)
--> would
--> > --> make
--> > --> > sense to insert.  I had logically modeled this in my own
--> > --> mind as two
--> > --> > distinct "interfaces" (the reason I use this term, rather
--> > --> thhan port),
--> > --> > but I should clarify this.
--> > --> >
--> > --> > In any case, the entries are keyed by both ingress and
--> > --> egress RBridge.
--> > --> > While there will be entries for only those egress
--> > --> RBridges where this
--> > --> > local RBridge is on the shortest path (between the given
--> > --> ingress and
--> > --> > egress pair), there will be at most one entry per 
--> any ingress
--> and
--> > --> > egress pair.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 34> as a matter of fact each interface is
--> > --> basically a set of
--> > --> two
--> > --> > --> interfaces, a regular one and a tunnel one, and the
--> > --> > forwarding/blocking
--> > --> > --> state may be different for the two.
--> > --> > -->
--> > --> >
--> > --> > No.
--> > --> >
--> > --> > As per my response to your point (Sgai 28) above, not
--> > --> every RBridge
--> > --> has a
--> > --> > "regular one" as you describe here.
--> > --> >
--> > --> > The forwarding/blocking state is not applicable as
--> > --> RBridges don't do
--> > --> STP.
--> > --> >
--> > --> > For the native interface, fowarding/blocking state is
--> > --> analogous to the
--> > --> > "Designated RBridge" election process.
--> > --> >
--> > --> > Since this point evidently applies to -
--> > --> >
--> > --> >                                                      Entries
--> would
--> > --> also
--> > --> >         contain any required encapsulation information,
--> > --> etc. required
--> > --> >         for forwarding on a given interface, and toward a
--> > --> corresponding
--> > --> >         specific egress RBridge.
--> > --> >
--> > --> > - your point, and my response, are related to the point
--> > --> (and response)
--> > --> > above (Sgai 33), and I will try to clarify this 
--> part as well.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 35> this protocol must be designed to avoid
--> > --> transient loops,
--> > --> > since
--> > --> > --> transient loops of multicast/broadcast cause
--> > --> broadcast storm that
--> > --> are
--> > --> > --> highly undesirable.
--> > --> > -->
--> > --> >
--> > --> > No.
--> > --> >
--> > --> > The protocol needs to include a provision to prevent
--> > --> _use_ of links
--> > --> that
--> > --> > may connect to transient loops.  Using a link-state
--> > --> routing protocol
--> > --> has
--> > --> > clearly been demostrated to produce transient loops, but
--> > --> the problem
--> > --> you
--> > --> > want to address has to do with using those links.
--> > --> >
--> > --> > A state-machine driven mechanism similar to STP might be
--> > --> the approach
--> > --> to
--> > --> > use.
--> > --> >
--> > --> > Because we're incorporating TTL in the SHIM, however this
--> > --> would need
--> > --> to
--> > --> > apply only to IRT traffic.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->
--> > --> > --> Sgai 36> see my previous comment about VLANs
--> > --> > -->
--> > --> >
--> > --> > See my previous responses.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> sgai 37> disabled -> blocking.
--> > --> > -->
--> > --> >
--> > --> > See my response to your point (sgai 26) above.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 38> for multicast/broadcast we also need to
--> > --> avoid transient
--> > --> > loops.
--> > --> > -->
--> > --> >
--> > --> > Yes.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 39> but RBridge discovery and STP are ongoing
--> > --> processes, why
--> > --> do
--> > --> > we
--> > --> > --> want to couple their timers?
--> > --> > -->
--> > --> >
--> > --> > I am not suggesting "coupling their timers."  I am 
--> saying that
--> the
--> > --> value
--> > --> > chosen for a timer (if one is used) to determine when it
--> > --> is reasonable
--> > --> to
--> > --> > start RBridge peer discovery should take into 
--> account the time
--> it
--> > --> takes
--> > --> > for the local spanning tree resolution.
--> > --> >
--> > --> > I feel the reason for this is self-evident but, just to
--> > --> clarify, think
--> > --> > about the process we're planning to use to determine RBridge
--> > --> nick-names.
--> > --> > If we start this too early, we will be re-starting it
--> > --> many times as we
--> > --> > "hear from" new RBridge peers when the connecting links go
--> active
--> > --> after
--> > --> > local bridges go to the forwarding state.  This would
--> > --> apply only at
--> > --> the
--> > --> > system start up as - after that - you are quite correct
--> > --> in asserting
--> > --> it
--> > --> > would be an ongoing process.
--> > --> >
--> > --> > Perhaps I should add some words to indicate that a delay
--> > --> would not be
--> > --> > necessary if the protocol mechanisms do not introduce
--> > --> instability as a
--> > --> > new peer is discovered.  So far, I have not seen any
--> > --> indication that a
--> > --> > "race-free" solution to accomplish this has been designed
--> > --> - or talked
--> > --> > about.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 40> there is also a requirement to time-out learnt
--> > --> information to
--> > --> > --> maintain the filtering databases.
--> > --> > -->
--> > --> >
--> > --> > There would be, if we were doing that.  Instead, 
--> we're adopting
--> a
--> > --> > link-state routing protocol and they tend to have 
--> that covered.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 41> periodically or on demand
--> > --> > -->
--> > --> >
--> > --> > See the response to your point (Sgai 40) above.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 42> potentially there is an unencapsulated
--> > --> interface for each
--> > --> > --> physical interface of the RBridge. It is true that
--> > --> you can model
--> > --> all
--> > --> > --> of them as a single separate logical interface, but
--> > --> then we need
--> > --> to
--> > --> > --> replicate the frame according to a bitmask that tells on
--> which
--> > --> > physical
--> > --> > --> interface the RBridge is designated.
--> > --> > -->
--> > --> >
--> > --> > Again, your use of a "bitmask" is an implementation
--> > --> choice as opposed
--> > --> > to a logical model.
--> > --> >
--> > --> > As you observe, I do "model all of them as a single
--> > --> separate logical
--> > --> > interface" and if you want to "replicate the frame 
--> according to
--> a
--> > --> > bitmask that tells on which physical interface the 
--> RBridge is
--> > --> > designated" - you're absolutely free to do so.
--> > --> >
--> > --> > Personally, I think this is far too much implementation
--> > --> stuff for a
--> > --> > protocol specification, let alone an architecture document.
--> > --> >
--> > --> > -->
--> > --> > --> Sgai 43> can we clarify that this means "drop BPDUs".
--> > --> > -->
--> > --> >
--> > --> > Yes.
--> > --> >
--> > --> > -- [snip --
--> > -->
--> 
_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from bender-mail.tigertech.net (bender-mail.tigertech.net [64.62.209.30]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1Hka6W018441 for <[e-mail]>; Wed, 1 Nov 2006 09:46:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id DB68A7E20 for <[e-mail]>; Wed,  1 Nov 2006 09:46:31 -0800 (PST)
Received: from JMHLap3.joelhalpern.com (pool-71-254-22-111.clppva.east.verizon.net [71.254.22.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id B28A97E32 for <[e-mail]>; Wed,  1 Nov 2006 09:46:24 -0800 (PST)
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Wed, 01 Nov 2006 12:45:31 -0500
To: [e-mail]
From: "Joel M. Halpern" <[e-mail]>
In-Reply-To: <[e-mail]. comms.marconi.com>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net
X-Spam-Status: No, hits=-2.8 tagged_above=-999.0 required=7.0 tests=ALL_TRUSTED
X-Spam-Level: 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr	aft-ietf-trill-rbridge-arch-01.t xt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 17:47:50 -0000
Status: RO
Content-Length: 464

With regard to the multiple path support, my understanding of the 
charter was that it was intended to permit the usage of multiple 
paths by traffic from different places.  I.e. to lift the restriction 
of STP to a single tree for the entire bridged network.
I did not think that it meant that traffic from a given ingress to a 
given egress was supposed to be able to use multiple paths, although 
I can see how a reader would get that.

Yours,
Joel M. Halpern



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1Hjegs017966 for <[e-mail]>; Wed, 1 Nov 2006 09:45:41 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1HjZfK000043; Wed, 1 Nov 2006 12:45:38 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA29327;  Wed, 1 Nov 2006 12:45:35 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647TB3>; Wed, 1 Nov 2006 12:45:34 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>
Date: Wed, 1 Nov 2006 12:45:33 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr	aft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 17:46:21 -0000
Status: RO
Content-Length: 42323

Silvano,

	I think that there may be a compromise we can arrive at here.

	I propose changing the defintion of "Ethernet" to read:

'Ethernet: In this document the term "Ethernet" is used to represent
 Ethernet-like and/or Ethernet-equivalent technologies - explicitly
 including 802.3 [802.3 ref], 802.1Q [802.Q ref] and other closely 
 related LAN technologies, and NOT explicitly excluding any other 
 Ethernet-like and/or Ethernet-equivalent technology that exists, or
 may be developed in the future.'

	Using this definition should clarify that I am not necessarily
using the term in the way that some people may feel it should be used,
while clearly stating what I am using the term to mean.  This should
also reduce your concern that I am apprently equating Ethernet and 
802 in general.  It also satisfies my intention to be inclusive.

	How does this sound?

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 1:21 AM
--> To: Gray, Eric
--> Cc: [e-mail]
--> Subject: RE: [rbridge] Comments on: 
--> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> -arch-01.txt
--> 
--> 
--> Eric,
--> 
--> I disagree.
--> 
--> I don't think it is wise for TRILL to redefine the term Ethernet.
--> Ethernet is a term that has a well known meaning in the industry.
--> The original definition is:
--> Digital Equipment Corporation, Intel, Xerox, The Ethernet, 
--> Version 2.0,
--> November 1982.
--> Which has been then standardized by IEEE 802.3.
--> 
--> To speak about other IEEE 802 standards that are alive and 
--> used, IEEE
--> 802.11 (Wireless LAN) and IEEE 802.17 (Resilient Packet 
--> Ring Working)
--> have nothing to do with Ethernet.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[e-mail]]
--> > Sent: Tuesday, October 31, 2006 2:44 PM
--> > To: Silvano Gai
--> > Cc: [e-mail]
--> > Subject: RE: [rbridge] Comments on: http://www.ietf.org/internet-
--> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > 
--> > Silvano,
--> > 
--> > 	To be perfectly frank, I am unaware of any reason not to include
--> > token ring or any other obsolete form of "Ethernet equivalent
--> technology"
--> > - this is one of the reason to focus on the SHIM as 
--> separate from any
--> > specific encapsulation above or below the SHIM.
--> > 
--> > 	If you want to check it against all 802 activities, that's fine.
--> > I would suggest, however, that even though people are 
--> realistically
--> not
--> > going to implement most of the hairy/scary versions in an 
--> RBridge, I
--> do
--> > not know of a good reason to exclude them at this point.  
--> In abstract,
--> > it is certainly possible that people will be able to work out
--> specifics
--> > of implementation - if and when they decide to do so.
--> > 
--> > 	After all, we (the industry) have been building translation
--> bridges
--> > for these technologies for decades.
--> > 
--> > 	However, I am open to scoping the architecture to apply only to
--> a
--> > limited subset of 802 technologies, if that is what would 
--> make people
--> > happy...
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: Silvano Gai [mailto:[e-mail]]
--> > --> Sent: Tuesday, October 31, 2006 5:34 PM
--> > --> To: Gray, Eric
--> > --> Cc: [e-mail]
--> > --> Subject: RE: [rbridge] Comments on:
--> > --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> > --> -arch-01.txt
--> > -->
--> > -->
--> > --> Eric,
--> > -->
--> > --> A quick reply:
--> > --> Are you telling me that the term Ethernet includes Token Ring,
--> Token
--> > --> Bus, DQDB?
--> > -->
--> > --> This is what you are doing when you say that Ethernet 
--> is IEEE 802
--> > --> instead of IEEE 802.3.
--> > -->
--> > --> This is NOT a terminology issue. If the term Ethernet means
--> > --> 802 I need
--> > --> to check the operation of TRILL against all the 802 
--> technologies.
--> > -->
--> > --> -- Silvano
--> > -->
--> > --> > -----Original Message-----
--> > --> > From: Gray, Eric [mailto:[e-mail]]
--> > --> > Sent: Tuesday, October 31, 2006 1:46 PM
--> > --> > To: Silvano Gai
--> > --> > Cc: [e-mail]
--> > --> > Subject: RE: [rbridge] Comments on:
--> http://www.ietf.org/internet-
--> > --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > --> >
--> > --> >
--> > --> >
--> > --> > -- [snip] --
--> > --> > -->
--> > --> > --> Sgai 4> an RBridge must be also able to send 
--> two copies of a
--> > --> > --> unicast/multicast/broadcast packet on the same 
--> port when it
--> > --> > --> acts as a designated RBridge (one copy is 
--> encapsulated, the
--> > --> > --> other not).
--> > --> > -->
--> > --> >
--> > --> > This, I think, refers to the immediately preceding 
--> text in the
--> > --> > architecture:
--> > --> >
--> > --> >         Forwarding information is derived from the 
--> combination
--> of
--> > --> >         attached MAC address learning, snooping of
--> > --> multicast-related
--> > --> >         protocols (e.g. - IGMP), and routing
--> > --> advertisements and path
--> > --> >         computations using the link-state routing protocol.
--> > --> >
--> > --> > While your comment is a reasonable one - although 
--> potentially
--> > --> > implementation specific - it does not appear to 
--> have any bearing
--> > --> > on this text.
--> > --> >
--> > --> >
--> > --> > -- [snip] --
--> > --> > -->
--> > --> > --> Sgai 5> here there is some confusion between 
--> 802 and 802.3
--> > --> > -->
--> > --> >
--> > --> > This  refers (I believe) to the immeditately preceding text:
--> > --> >
--> > --> >         The following terminology is defined in 
--> other documents.
--> A
--> > --> brief
--> > --> >         definition is included in this section for
--> > --> convenience and -
--> > --> in
--> > --> >         some cases - to remove any ambiguity in how the
--> > --> term may be
--> > --> used
--> > --> >         in this document, as well as derivative documents
--> > --> intended to
--> > --> >         specify components, protocol, behavior and 
--> encapsulation
--> > --> >         relative to the architecture specified in 
--> this document.
--> > --> >
--> > --> >         o  802: IEEE Specification for the Ethernet
--> architecture,
--> > --> i.e.,
--> > --> >            including hubs and bridges.
--> > --> >
--> > --> > In this text, I explicitly state that these terms 
--> are defined
--> > --> elsewhere.
--> > --> > I am also trying to use the most generic definition 
--> of Ethernet
--> > --> possible.
--> > --> >
--> > --> > The reason for this is that the problem statement does
--> > --> not restrict
--> > --> the
--> > --> > solution to 802.3.
--> > --> >
--> > --> > There is some confusion in referring to 802.3 in 
--> any case: we
--> > --> explicitly
--> > --> > want to include 802.1Q - as well as all of its 
--> variations and
--> > --> extensions.
--> > --> >
--> > --> > Consequently, we define the term Ethernet in the broadest
--> possible
--> > --> sense.
--> > --> >
--> > --> >
--> > --> > -- [snip] --
--> > --> > -->
--> > --> > -->        o  Bridge Spanning Tree (BST): an Ethernet (L2,
--> 802.1D)
--> > --> > -->           forwarding protocol based on the topology
--> > --> of a spanning
--> > --> > tree.
--> > --> > -->
--> > --> > --> Sgai 6> I have never seen the acronym BST, 
--> everyone use STP.
--> > --> > -->
--> > --> >
--> > --> > I do not know if this term is used in any of the other
--> documents,
--> > --> > but it is not used in this one.  Unless someone 
--> objects, I am
--> only
--> > --> > too happy to remove it from this document.
--> > --> >
--> > --> > From a historical perspective, this was defined this way
--> > --> originally
--> > --> > because we were re-using the term spanning tree instead
--> > --> of IRT.  It
--> > --> > was causing amazing communication difficulties, so 
--> we came up
--> with
--> > --> > the term IRT.  Now we don't need to differentiate BST.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 7> for Ethernet is better to reference 802.3
--> > --> > -->
--> > --> >
--> > --> > See my response to your point (Sgai 5) above.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  Hub: an Ethernet (L2, 802) device with
--> > --> multiple ports
--> > --> which
--> > --> > -->
--> > --> > --> sgai 8> for Hub is better to reference 802.3
--> > --> > -->
--> > --> >
--> > --> > See my response to your point (Sgai 5) above.  By the
--> > --> definition we
--> > --> > provide in this document, Ethernet is defined 
--> broadly to include
--> > --> > 802 technologies.  This is reasonable, because the term was
--> stolen
--> > --> > by IEEE from a technology stolen from a satellite 
--> communication
--> > --> > protocol.  Ironic that 802.3 does not include wireless, all
--> things
--> > --> > considered.  Certainly the term "Ethernet" should...
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  Node: a device with an L2 (MAC) address
--> > --> that sources
--> > --> and/or
--> > --> > -->            sinks L2 frames.
--> > --> > -->
--> > --> > --> Sgai 9> The IEEE term is "station".
--> > --> > -->
--> > --> >
--> > --> > However, we in the IETF are more familiar with the 
--> term "node."
--> > --> >
--> > --> > This is hardly a significant issue.  if people agree that
--> > --> we should
--> > --> > use the term "station" as opposed to "node", then I will
--> > --> change it.
--> > --> >
--> > --> > Note that we should be consistent in this usage, if we
--> > --> decide to do
--> > --> > yet another terminology evolution.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  Segment: an Ethernet link, either a single
--> physical
--> > --> link or
--> > --> > -->            emulation thereof (e.g., via hubs) or a
--> > --> logical link or
--> > --> > -->            emulation thereof (e.g., via bridges).
--> > --> > -->
--> > --> > --> Sgai 10> IEEE uses the term "LAN segment"
--> > --> > -->
--> > --> >
--> > --> > I agree, however this is the definition we agreed on here.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  Subnet, Ethernet: a single segment, 
--> or a set of
--> > --> segments
--> > --> > -->            interconnected by a CRED (see 
--> section 2.2); in
--> the
--> > --> latter
--> > --> > -->
--> > --> > --> sgai 11> There is no concept of subnet in IEEE. 
--> Subnet is
--> > --> typically
--> > --> > --> an IP subnet, and, even if it is common to have 
--> one subnet
--> per
--> > --> LAN,
--> > --> > --> this is not the only possibility. Pragmatically 
--> IP subnets
--> and
--> > --> > --> Ethernet LAN are unrelated concepts.
--> > --> > -->
--> > --> >
--> > --> > Again, we are defining this term for use in this
--> > --> document.  Does its
--> > --> > use (not its definition) cause confusion or ambiguity?
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->            case, the subnet may or may not be 
--> equivalent to
--> a
--> > --> single
--> > --> > -->            segment. Also a subnet may be 
--> referred to as a
--> > --> broadcast
--> > --> > -->            domain or LAN. By definition, all 
--> nodes within an
--> > --> Ethernet
--> > --> > -->            Subnet (broadcast domain or LAN) must have L2
--> > --> connectivity
--> > --> > -->            with all other nodes in the same 
--> Ethernet subnet.
--> > --> > -->
--> > --> > -->         o  TRILL: Transparent Interconnect over Lots
--> > --> of Links -
--> > --> the
--> > --> > -->            working group and working name for the
--> > --> problem domain
--> > --> to be
--> > --> > -->            addressed in this document.
--> > --> > -->
--> > --> > -->         o  Unicast Forwarding: forwarding methods
--> > --> that apply to
--> > --> frames
--> > --> > -->            with unicast destination MAC addresses.
--> > --> > -->
--> > --> > -->         o  Unknown Destination - a destination 
--> for which a
--> > --> receiving
--> > --> > -->            device has no filtering database entry.
--> > --> Destination
--> > --> (layer
--> > --> > -->
--> > --> > --> sgai 12> the stations receive the unknown 
--> unicast and have
--> > --> filtering
--> > --> > --> information, only the bridges don't. I propose to
--> > --> replace device
--> > --> with
--> > --> > --> bridge.
--> > --> > -->
--> > --> >
--> > --> > Again, it is the intention to provide as broad a 
--> definition as
--> > --> possible
--> > --> > without introducing confusion or ambiguity.  An end node
--> > --> (or station)
--> > --> > has - in a sense - a filtering database (it's mine, or
--> > --> it's for the
--> > --> bit
--> > --> > bucket).
--> > --> >
--> > --> > We need to explicitly include 802.1D forwarding devices
--> > --> and RBridges.
--> > --> >
--> > --> > However, the definition should specify "forwarding 
--> device" - as
--> > --> opposed
--> > --> > to just "receiving device."
--> > --> >
--> > --> > I will change that.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->            2) addresses are typically "learned" 
--> by (layer 2)
--> > --> > forwarding
--> > --> > -->            devices via a process commonly referred to
--> > --> as "bridge
--> > --> > learning".
--> > --> > -->
--> > --> > --> Sgai 13> in IEEE, the term used is "learning" instead
--> > --> of "bridge
--> > --> > learning"
--> > --> > -->
--> > --> >
--> > --> > However, the term defined in this document is 
--> "bridge learning."
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  VLAN: Virtual Local Area Network. VLANs in
--> > --> general fall
--> > --> > into
--> > --> > -->            two categories: link (or port) 
--> specific VLANs and
--> > --> tagged
--> > --> > -->            VLANs. In the former case, all frames
--> > --> forwarded and all
--> > --> > -->            directly connected nodes are assumed to be
--> > --> part of a
--> > --> single
--> > --> > -->            VLAN.  In the latter case, VLAN tagged
--> > --> frames are used
--> > --> to
--> > --> > -->            distinguish which VLAN each frame is intended
--> for.
--> > --> > -->
--> > --> > --> Sgai 14> This definition is not completely correct, I
--> prefer:
--> > --> > -->
--> > --> > --> VLAN technology introduces the following three 
--> basic types
--> of
--> > --> frame:
--> > --> > --> a) Untagged frames;
--> > --> > --> b) Priority-tagged frames; and
--> > --> > --> c) VLAN-tagged frames.
--> > --> > -->
--> > --> > --> An untagged frame or a priority-tagged frame does not
--> > --> carry any
--> > --> > --> identification of the VLAN to which it belongs. Such
--> > --> frames are
--> > --> > --> classified as belonging to a particular VLAN based on
--> > --> parameters
--> > --> > --> associated with the receiving Port, or, through 
--> proprietary
--> > --> extensions
--> > --> > --> to IEEE 802.1Q standard, based on the data content of
--> > --> the frame
--> > --> (e.g.,
--> > --> > --> MAC Address, layer 3 protocol ID, etc.).
--> > --> > -->
--> > --> > --> A VLAN-tagged frame carries an explicit
--> > --> identification of the VLAN
--> > --> to
--> > --> > --> which it belongs; i.e., it carries a tag header 
--> that carries
--> a
--> > --> non-
--> > --> > null
--> > --> > --> VID. Such a frame is classified as belonging to a
--> > --> particular VLAN
--> > --> > based
--> > --> > --> on the value of the VID that is included in the tag
--> > --> header. The
--> > --> > presence
--> > --> > --> of the tag header carrying a non-null VID means that
--> > --> some other
--> > --> > device,
--> > --> > --> either the originator of the frame or a 
--> VLAN-aware Bridge,
--> has
--> > --> mapped
--> > --> > --> this frame into a VLAN and has inserted the 
--> appropriate VID.
--> > --> > -->
--> > --> >
--> > --> > So, you're getting into the details of the 
--> technology and - in
--> > --> particular
--> > --> > the encapsulation.  I will expand the definition to 
--> include a
--> > --> possibility
--> > --> > that other criteria may be used to define a "VLAN port" -
--> although
--> > --> this is
--> > --> > isomorphic to a logical model in which a device
--> > --> implementation uses
--> > --> some
--> > --> > criteria to decide that a subset of the traffic received
--> > --> on a specific
--> > --> > physical port is to be forwarded as if received on a
--> > --> specific logical
--> > --> > port.
--> > --> >
--> > --> > The key point in this definition is that a VLAN is a
--> > --> "Virtual LAN" -
--> > --> > meaning
--> > --> > it consists of a subset of the physical and L2 connectivity
--> > --> corresponding
--> > --> > to
--> > --> > a "logical LAN."  The intent is to "rise above" the
--> technological
--> > --> > approaches
--> > --> > and encapsulations to establish a generic definition that
--> > --> is loosely
--> > --> tied
--> > --> > to
--> > --> >
--> > --> > ways that this generic definition is actually implemented.
--> > --> >
--> > --> > Again, bearing in mind the way that the term is 
--> defined, does
--> the
--> > --> usage of
--> > --> > the term cause confusion or ambiguity?
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  CRED Forwarding Table (CFT): the per-hop
--> forwarding
--> > --> table
--> > --> > -->            populated by the RBridge Routing Protocol;
--> > --> forwarding
--> > --> > within
--> > --> > -->            the CRED is based on a lookup of the 
--> CRED Transit
--> > --> Header
--> > --> > -->            (CTH) encapsulated within the 
--> outermost received
--> L2
--> > --> header.
--> > --> > -->            The outermost L2 encapsulation in this
--> > --> case includes
--> > --> the
--> > --> > -->            source MAC address of the immediate
--> > --> upstream RBridge
--> > --> > -->            transmitting the frame and destination MAC
--> > --> address of
--> > --> the
--> > --> > -->            receiving RBridge for use in the unicast
--> forwarding
--> > --> case.
--> > --> > -->
--> > --> > --> Sgai 15> In section 7 of
--> > --> > -->
--> > --> 
--> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-
--> > --> > 00.txt
--> > --> > --> we proposed that when two rbridges are 
--> connected by a point
--> to
--> > --> point
--> > --> > --> link the outer MAC addresses may be set to a
--> > --> predefined value in
--> > --> > --> transmission and ignored in reception.
--> > --> > -->
--> > --> >
--> > --> > I'm not sure how your proposal intends to determine that
--> > --> a link is in
--> > --> > fact point-to-point and does not just look that way.
--> > --> >
--> > --> > I prefer to use the same encapsulation in all cases where it
--> will
--> > --> work.
--> > --> >
--> > --> > The optimization associated with using some form of
--> > --> null-encapsulation
--> > --> > is of dubious value, given that it may not be possible to
--> > --> be certain a
--> > --> > point-to-point link is - and will remain - in fact a
--> > --> point-to-point
--> > --> > link.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  CFT-IRT: a forwarding table used for 
--> propagation
--> of
--> > --> > -->            broadcast, multicast or flooded 
--> frames along the
--> > --> Ingress
--> > --> > -->            RBridge Tree (IRT).
--> > --> > -->
--> > --> > --> Sgai 16> is it a forwarding table or is it a
--> > --> filtering database.
--> > --> Since
--> > --> > --> the "miss" behavior is to flood, I see it as a
--> > --> filtering database.
--> > --> > -->
--> > --> >
--> > --> > What state was "miss" behavior from - Hawaii?  :-)
--> > --> >
--> > --> > It is analogous to a filtering database entry, but it is not
--> that.
--> > --> >
--> > --> > Clearly there are more things in this world than can be
--> classified
--> > --> > in this taxonomy.  However, given these choices, it is a
--> > --> forwarding
--> > --> > table.
--> > --> >
--> > --> > This is not a misbehavior, in that the same "base" tree
--> > --> is used for
--> > --> > broadcast and multicast traffic as well as flooded
--> > --> traffic.  It may
--> > --> > be arguable that flooding is a misbehavior, but I 
--> seem to recall
--> > --> > that people still see it as a necessary evil.
--> > --> >
--> > --> > It is also not "miss" behavior (as in "cache miss") in
--> > --> the multicast
--> > --> > and broadcast case, either.
--> > --> >
--> > --> > I believe the definition is quite correct and easy to
--> understand,
--> > --> > provided you're not reading it with preconceived 
--> misconceptions
--> > --> > about its meaning.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  CRED Transit Header (CTH): a 'shim' 
--> header that
--> > --> > encapsulates
--> > --> > -->            the ingress L2 frame and persists 
--> throughout the
--> > --> transit of
--> > --> > a
--> > --> >
--> > --> > -->            CRED, which is further encapsulated within
--> > --> a hop-by-hop
--> > --> L2
--> > --> > -->            header (and trailer). The hop-by-hop L2
--> > --> encapsulation
--> > --> in
--> > --> > this
--> > --> >
--> > --> > -->            case includes the source MAC address of
--> > --> the immediate
--> > --> > -->            upstream RBridge transmitting the frame
--> > --> and destination
--> > --> MAC
--> > --> > -->            address of the receiving RBridge - 
--> at least in
--> the
--> > --> unicast
--> > --> > -->            forwarding case.
--> > --> > -->
--> > --> > --> Sgai 17> is this true also for unknown unicast?
--> > --> > -->
--> > --> >
--> > --> > That is something that will be (may be already) 
--> decided in the
--> > --> protocol
--> > --> > specification.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  CRED Transit Table (CTT): a table that maps
--> ingress
--> > --> frame
--> > --> > L2
--> > --> > -->            destinations to egress RBridge 
--> addresses, used to
--> > --> determine
--> > --> > -->            encapsulation of ingress frames for 
--> transit of
--> the
--> > --> CRED.
--> > --> > -->
--> > --> > -->         o  Cooperating RBridges - those RBridges
--> > --> within a single
--> > --> > -->            Ethernet Subnet (broadcast domain or LAN)
--> > --> not having
--> > --> been
--> > --> > -->            configured to ignore each other. By 
--> default, all
--> > --> RBridges
--> > --> > -->            within a single Ethernet subnet will 
--> cooperate
--> with
--> > --> each
--> > --> > -->            other. It is possible for implementations
--> > --> to allow for
--> > --> > -->            configuration that will restrict
--> > --> "cooperation" between
--> > --> an
--> > --> > -->            RBridge and an apparent neighboring 
--> RBridge.  One
--> > --> reason
--> > --> > why
--> > --> > -->            this might occur is if the trust model
--> > --> that applies in
--> > --> a
--> > --> > -->            particular deployment imposes a need for
--> > --> configuration
--> > --> of
--> > --> > -->            security information.  By default no such
--> > --> configuration
--> > --> is
--> > --> > -->            required however - should it be used in
--> > --> any specific
--> > --> > scenario
--> > --> > -->
--> > --> > -->            - it is possible (either deliberately or
--> > --> inadvertently)
--> > --> to
--> > --> > -->            configure neighboring RBridges so 
--> that they do
--> not
--> > --> > cooperate.
--> > --> > -->
--> > --> > -->            In the remainder of this document, 
--> all RBridges
--> are
--> > --> assumed
--> > --> > -->            to be in a cooperating (default) 
--> configuration.
--> > --> > -->
--> > --> > --> Sgai 18> can RBridges cooperate in groups, e.g. four
--> Rbridges
--> > --> > connected
--> > --> > --> to a LAN cooperating two and two?
--> > --> > -->
--> > --> >
--> > --> > Yes.  There may be reasons why this might be done 
--> deliberately,
--> > --> however
--> > --> > - even in the absence of any "proof of concept"
--> > --> justification - it is
--> > --> a
--> > --> > really good idea to design the protocol to be robust in
--> > --> cases where a
--> > --> > set of RBridges may be (mis)configured in such a way as
--> > --> to be unable
--> > --> to
--> > --> > discover each other.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  Ingress RBridge Tree: a tree 
--> computed for each
--> edge
--> > --> RBridge
--> > --> > -->            and potentially for each VLAN in which that
--> RBridge
--> > --> > -->
--> > --> > --> sgai 19> why for each VLAN? I got the 
--> impression that there
--> > --> > --> was a single tree that was pruned differently for
--> > --> different VLANs.
--> > --> > -->
--> > --> >
--> > --> > Pruning may also take place at the ingress, if - for
--> > --> example - it has
--> > --> a
--> > --> > subset of interfaces that are not connected to any 
--> egress for
--> > --> particular
--> > --> > VLANs.  It is a small point but, in such cases, there is in
--> effect
--> > --> more
--> > --> > than one IRT even at the ingress.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->            participates - for delivery of broadcast,
--> > --> multicast and
--> > --> > -->            flooded frames from that RBridge to all
--> > --> relevant egress
--> > --> > -->            RBridges. This is the point-to-multipoint
--> > --> delivery tree
--> > --> > used
--> > --> > -->            by an ingress RBridge to deliver
--> > --> multicast, broadcast
--> > --> or
--> > --> > -->            flooded traffic.
--> > --> > -->
--> > --> > --> Sgai 20> the current version of the proposal 
--> speaks about a
--> > --> multicast
--> > --> > --> address, not point-to-point.
--> > --> > -->
--> > --> >
--> > --> > I did not say "point-to-point" (look again).
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  LPT: Learned Port Table. See 
--> Filtering Database.
--> > --> > -->
--> > --> > --> Sgai 21> not proper terminology, I would use
--> > --> "filtering database"
--> > --> > --> everywhere.
--> > --> > -->
--> > --> >
--> > --> > I am happy to remove this if there is no objection 
--> to my doing
--> so.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> sgai 22> I wired port is Ehernet, i.e. IEEE 802.3, a
--> > --> > --> wireless port is not Ethernet, it is IEEE 802.11.
--> > --> > -->
--> > --> >
--> > --> > See my response to your point (sgai 8) above.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> sgai 23> they learn because STP guarantees
--> > --> symmetrical forwarding
--> > --> > -->
--> > --> >
--> > --> > This (apparently) refers to the immeditately preceding text:
--> > --> >
--> > --> >         Conventional bridges contain a learned port table
--> > --> (LPT), or
--> > --> >         filtering database, and a spanning tree table
--> > --> (STT). The LPT
--> > --> >         allows a bridge to avoid flooding all received
--> > --> frames, as is
--> > --> >         typical for a hub or repeater. The bridge learns
--> > --> which nodes
--> > --> are
--> > --> >         accessible from a particular port by assuming
--> > --> bi-directional
--> > --> >         consistency:
--> > --> >
--> > --> > I'm not sure how picking at the peculiarities of 
--> STP behavior is
--> > --> > relevant to this description.  STP results in a 
--> single spanning
--> > --> > tree where each link is bi-directional.  This 
--> ensures that the
--> > --> > MAC frames are forwarded in a bi-directionally consistent
--> fashion.
--> > --> >
--> > --> > To replace this text with yours is to provide less 
--> information.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 24> active ports -> forwarding ports
--> > --> > -->
--> > --> >
--> > --> > "Active ports" was the exact wording suggested to me.  In
--> > --> context for
--> > --> > this working group "active ports" is more meaningful than
--> > --> "forwarding
--> > --> > ports."  For people not used to STP-speak, "forwarding
--> > --> port" might be
--> > --> > used to discriminate from a "code port."
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 25> there is no STT, there is a state associated
--> > --> with each
--> > --> port
--> > --> > --> that can be: disabled, blocking, listening, 
--> learning, and
--> > --> forwarding
--> > --> > -->
--> > --> >
--> > --> > Other than the issue with terminology, is this text 
--> wrong?  I am
--> > --> fairly
--> > --> > sure that different implementations handle the "port state"
--> > --> information
--> > --> > in different ways, and I am also reasonably sure that a
--> > --> "table" such
--> > --> as
--> > --> > the one described here is one of the ways it might be done.
--> > --> >
--> > --> > However, I agree with your assertion that this is the way
--> > --> that it is
--> > --> > usually talked about in an IEEE context, so - 
--> unless there are
--> > --> specific
--> > --> > objections - I can change the wording to be consistent
--> > --> with what you
--> > --> > suggest.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> sgai 26> disabled -> blocking
--> > --> > -->
--> > --> >
--> > --> > I can make this change as well.  However, from the
--> > --> perspective of what
--> > --> > we are trying to do, "disabled" is potentially a more
--> > --> correct term.
--> > --> It
--> > --> > is certainly more intuitively correct, outside of a
--> > --> strictly IEEE/STP
--> > --> > context.
--> > --> >
--> > --> > Symmetry is maintained in STP by blocking ports/links
--> > --> bi-directionally.
--> > --> > In such cases, a port is effectively disabled for bridges
--> > --> at either
--> > --> end
--> > --> > of the link for which a port is blocked, is it not?
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> sgai 27> I repeat a comment that I have made to other
--> > --> documents: "
--> > --> > --> The discussion about VLAN needs to be much more
--> > --> extensive. It is
--> > --> clear
--> > --> > --> from the mailing list discussion that VLANs can be
--> > --> used inside the
--> > --> > --> packet or in the Ethernet encapsulation of TRILL.
--> > --> These are two
--> > --> > --> different kinds of VLANs and their requirement need
--> > --> to be stated
--> > --> > --> separately. Q in Q needs also to be discussed. I
--> > --> propose to define
--> > --> > inner
--> > --> > --> and outer VLANs (with reference to the position of
--> > --> the tag in the
--> > --> > frame."
--> > --> > --> Here I think we are talking about outer VLANs
--> > --> > -->
--> > --> >
--> > --> > I responded to this in separate mail.  I wait to hear
--> > --> other opinions
--> > --> on
--> > --> > this subject.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 28> IMO all RBridges must be ingress RBridges,
--> > --> at least to
--> > --> > support
--> > --> > --> inband management, e.g. SNMP.
--> > --> > -->
--> > --> >
--> > --> > No.
--> > --> >
--> > --> > In order to ensure symmetry with RBridges not
--> > --> participating in STP,
--> > --> there
--> > --> > MUST be a designated RBridge that does all of the 
--> sending and
--> > --> receiving
--> > --> > of native encapsulated frames on a LAN segment.
--> > --> >
--> > --> > Any RBridge the loses the "Designated RBridge" 
--> election cannot
--> be
--> > --> either
--> > --> > an ingress or an egress for that LAN segment.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 29> same as above
--> > --> > -->
--> > --> >
--> > --> > Same as above.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 30> I think the previous definition is not needed.
--> > --> > -->
--> > --> >
--> > --> > This appears to refer to:
--> > --> >
--> > --> >         o  Local RBridge - the RBridge that forms and
--> > --> maintains the
--> > --> CFT-
--> > --> >            IRT entry (or entries) under discussion. The
--> > --> local RBridge
--> > --> >            may be an Ingress RBridge, or an egress 
--> RBridge with
--> > --> respect
--> > --> >            to any set of entries in the CFT-IRT.
--> > --> >
--> > --> > This defintion is needed.  It is subsequently used 
--> in at least 4
--> > --> places.
--> > --> > When discussing the behavior of a specific RBridge
--> > --> relative to a peer,
--> > --> > it is convenient to define the term "local RBridge."
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> sgai 31> why is it zero or more, if an RBridge 
--> exists, it
--> must
--> > --> have
--> > --> > --> a an IRT, I haven't seen any discussion to support
--> > --> multiple IRTs.
--> > --> > -->
--> > --> >
--> > --> > This was answered previously on the mailing list.
--> > --> Briefly, zero or
--> > --> > more is correct, given that an RBridge may not have
--> > --> forwarding entries
--> > --> > for frames it has received.  In these cases, a frame is
--> > --> not forwarded.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 32> I don't understand this. Since the current
--> > --> proposal uses
--> > --> a
--> > --> > --> multicast MAC address, what is needed is a bit map
--> > --> for each IRT
--> > --> that
--> > --> > --> says which ports are blocking and which are
--> > --> forwarding. You are
--> > --> > --> basically building a ST using ISIS.
--> > --> > -->
--> > --> >
--> > --> > This might be the case for a specific implementation.
--> > --> Whether it is
--> > --> > implemented as a "bit-mask" with "non-blocking"
--> > --> (forwarding) ports, or
--> > --> > is implemented as a full-blown table is largely dependent on
--> what
--> > --> other
--> > --> > information the local device requires in order to
--> > --> properly forwad the
--> > --> > frame.  If - for example - a device has multiple
--> > --> different port types,
--> > --> > it may need to have more information for each port (or that
--> > --> information
--> > --> > may be added later on).
--> > --> >
--> > --> > All of these are implementation choices that are
--> > --> logically represented
--> > --> > by the table described here.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 33> I don't get the pair.
--> > --> > -->
--> > --> >
--> > --> > Since this immediately follows:
--> > --> >
--> > --> >         Each entry would contain an indication of 
--> which single
--> > --> interface
--> > --> >         a broadcast, multicast or flooded frame would be
--> > --> forwarded for
--> > --> >         each (ingress RBridge, egress RBridge) pair.
--> > --> >
--> > --> > I don't get what you don't get.
--> > --> >
--> > --> > The pair refers to the tuple "(ingress RBridge, egress
--> RBridge)."
--> > --> >
--> > --> > This might be the point at which your earlier point (Sgai 4)
--> would
--> > --> make
--> > --> > sense to insert.  I had logically modeled this in my own
--> > --> mind as two
--> > --> > distinct "interfaces" (the reason I use this term, rather
--> > --> thhan port),
--> > --> > but I should clarify this.
--> > --> >
--> > --> > In any case, the entries are keyed by both ingress and
--> > --> egress RBridge.
--> > --> > While there will be entries for only those egress
--> > --> RBridges where this
--> > --> > local RBridge is on the shortest path (between the given
--> > --> ingress and
--> > --> > egress pair), there will be at most one entry per 
--> any ingress
--> and
--> > --> > egress pair.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 34> as a matter of fact each interface is
--> > --> basically a set of
--> > --> two
--> > --> > --> interfaces, a regular one and a tunnel one, and the
--> > --> > forwarding/blocking
--> > --> > --> state may be different for the two.
--> > --> > -->
--> > --> >
--> > --> > No.
--> > --> >
--> > --> > As per my response to your point (Sgai 28) above, not
--> > --> every RBridge
--> > --> has a
--> > --> > "regular one" as you describe here.
--> > --> >
--> > --> > The forwarding/blocking state is not applicable as
--> > --> RBridges don't do
--> > --> STP.
--> > --> >
--> > --> > For the native interface, fowarding/blocking state is
--> > --> analogous to the
--> > --> > "Designated RBridge" election process.
--> > --> >
--> > --> > Since this point evidently applies to -
--> > --> >
--> > --> >                                                      Entries
--> would
--> > --> also
--> > --> >         contain any required encapsulation information,
--> > --> etc. required
--> > --> >         for forwarding on a given interface, and toward a
--> > --> corresponding
--> > --> >         specific egress RBridge.
--> > --> >
--> > --> > - your point, and my response, are related to the point
--> > --> (and response)
--> > --> > above (Sgai 33), and I will try to clarify this 
--> part as well.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 35> this protocol must be designed to avoid
--> > --> transient loops,
--> > --> > since
--> > --> > --> transient loops of multicast/broadcast cause
--> > --> broadcast storm that
--> > --> are
--> > --> > --> highly undesirable.
--> > --> > -->
--> > --> >
--> > --> > No.
--> > --> >
--> > --> > The protocol needs to include a provision to prevent
--> > --> _use_ of links
--> > --> that
--> > --> > may connect to transient loops.  Using a link-state
--> > --> routing protocol
--> > --> has
--> > --> > clearly been demostrated to produce transient loops, but
--> > --> the problem
--> > --> you
--> > --> > want to address has to do with using those links.
--> > --> >
--> > --> > A state-machine driven mechanism similar to STP might be
--> > --> the approach
--> > --> to
--> > --> > use.
--> > --> >
--> > --> > Because we're incorporating TTL in the SHIM, however this
--> > --> would need
--> > --> to
--> > --> > apply only to IRT traffic.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->
--> > --> > --> Sgai 36> see my previous comment about VLANs
--> > --> > -->
--> > --> >
--> > --> > See my previous responses.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> sgai 37> disabled -> blocking.
--> > --> > -->
--> > --> >
--> > --> > See my response to your point (sgai 26) above.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 38> for multicast/broadcast we also need to
--> > --> avoid transient
--> > --> > loops.
--> > --> > -->
--> > --> >
--> > --> > Yes.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 39> but RBridge discovery and STP are ongoing
--> > --> processes, why
--> > --> do
--> > --> > we
--> > --> > --> want to couple their timers?
--> > --> > -->
--> > --> >
--> > --> > I am not suggesting "coupling their timers."  I am 
--> saying that
--> the
--> > --> value
--> > --> > chosen for a timer (if one is used) to determine when it
--> > --> is reasonable
--> > --> to
--> > --> > start RBridge peer discovery should take into 
--> account the time
--> it
--> > --> takes
--> > --> > for the local spanning tree resolution.
--> > --> >
--> > --> > I feel the reason for this is self-evident but, just to
--> > --> clarify, think
--> > --> > about the process we're planning to use to determine RBridge
--> > --> nick-names.
--> > --> > If we start this too early, we will be re-starting it
--> > --> many times as we
--> > --> > "hear from" new RBridge peers when the connecting links go
--> active
--> > --> after
--> > --> > local bridges go to the forwarding state.  This would
--> > --> apply only at
--> > --> the
--> > --> > system start up as - after that - you are quite correct
--> > --> in asserting
--> > --> it
--> > --> > would be an ongoing process.
--> > --> >
--> > --> > Perhaps I should add some words to indicate that a delay
--> > --> would not be
--> > --> > necessary if the protocol mechanisms do not introduce
--> > --> instability as a
--> > --> > new peer is discovered.  So far, I have not seen any
--> > --> indication that a
--> > --> > "race-free" solution to accomplish this has been designed
--> > --> - or talked
--> > --> > about.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 40> there is also a requirement to time-out learnt
--> > --> information to
--> > --> > --> maintain the filtering databases.
--> > --> > -->
--> > --> >
--> > --> > There would be, if we were doing that.  Instead, 
--> we're adopting
--> a
--> > --> > link-state routing protocol and they tend to have 
--> that covered.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 41> periodically or on demand
--> > --> > -->
--> > --> >
--> > --> > See the response to your point (Sgai 40) above.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 42> potentially there is an unencapsulated
--> > --> interface for each
--> > --> > --> physical interface of the RBridge. It is true that
--> > --> you can model
--> > --> all
--> > --> > --> of them as a single separate logical interface, but
--> > --> then we need
--> > --> to
--> > --> > --> replicate the frame according to a bitmask that tells on
--> which
--> > --> > physical
--> > --> > --> interface the RBridge is designated.
--> > --> > -->
--> > --> >
--> > --> > Again, your use of a "bitmask" is an implementation
--> > --> choice as opposed
--> > --> > to a logical model.
--> > --> >
--> > --> > As you observe, I do "model all of them as a single
--> > --> separate logical
--> > --> > interface" and if you want to "replicate the frame 
--> according to
--> a
--> > --> > bitmask that tells on which physical interface the 
--> RBridge is
--> > --> > designated" - you're absolutely free to do so.
--> > --> >
--> > --> > Personally, I think this is far too much implementation
--> > --> stuff for a
--> > --> > protocol specification, let alone an architecture document.
--> > --> >
--> > --> > -->
--> > --> > --> Sgai 43> can we clarify that this means "drop BPDUs".
--> > --> > -->
--> > --> >
--> > --> > Yes.
--> > --> >
--> > --> > -- [snip --
--> > -->
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1HWInY012231 for <[e-mail]>; Wed, 1 Nov 2006 09:32:18 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1HWCfK029742; Wed, 1 Nov 2006 12:32:16 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA28498;  Wed, 1 Nov 2006 12:32:12 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647S5D>; Wed, 1 Nov 2006 12:32:11 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>
Date: Wed, 1 Nov 2006 12:32:08 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr	aft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 17:32:58 -0000
Status: RO
Content-Length: 5607

Silvano,

	Let's leave-off restating our cases, and simply let others 
comment on what they think is meant by this phrase in the charter.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 12:22 PM
--> To: Gray, Eric
--> Cc: [e-mail]
--> Subject: RE: [rbridge] Comments on: 
--> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
-arch-01.txt
--> 
--> Eric,
--> 
--> If the sentence "load-splitting among multiple paths", does not mean
--> Layer 2 ECMP, what does it mean?
--> 
--> How can I split the load among multiple paths, without doing
--> multipathing?
--> 
--> To split the load, I need at least two paths, If they are not Equal
--> Cost, what are they?
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[e-mail]]
--> > Sent: Wednesday, November 01, 2006 9:09 AM
--> > To: Silvano Gai
--> > Cc: [e-mail]
--> > Subject: RE: [rbridge] Comments on: http://www.ietf.org/internet-
--> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > 
--> > Silvano,
--> > 
--> > 	There is a difference.  I've been participating in this working
--> > group for some time, and I have not heard anyone suggest 
--> using L2 ECMP
--> > is what the charter means by "load-splitting among 
--> multiple paths."
--> > 
--> > 	However, I agree we need to be fair.  Consequently, let's ask
--> > other people to weigh in on this issue.  You assert that 
--> the charter
--> > means to include L2 ECMP as an explicit requirement of 
--> the TRILL work.
--> > I assert that it does not.
--> > 
--> > 	What do other people say?
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: Silvano Gai [mailto:[e-mail]]
--> > --> Sent: Wednesday, November 01, 2006 11:29 AM
--> > --> To: Gray, Eric
--> > --> Cc: [e-mail]
--> > --> Subject: RE: [rbridge] Comments on:
--> > --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> > --> -arch-01.txt
--> > -->
--> > --> Eric,
--> > -->
--> > --> When I propose something that is not in the charter, it is
--> > --> out of scope
--> > --> because not in the charter; when I propose something 
--> that is in
--> the
--> > --> charter, it is out of scope because "this is not what 
--> the charter
--> is
--> > --> meant to
--> > --> describe."
--> > -->
--> > --> Let's be fair!
--> > -->
--> > --> IMHO, if TRILL does not support Layer 2 ECMP, it is not
--> > --> interesting at
--> > --> all for us. All the interest in replacing Spanning Tree is
--> > --> to get Layer
--> > --> 2 ECMP.
--> > -->
--> > --> -- Silvano
--> > -->
--> > --> > -----Original Message-----
--> > --> > From: Gray, Eric [mailto:[e-mail]]
--> > --> > Sent: Wednesday, November 01, 2006 8:20 AM
--> > --> > To: Silvano Gai
--> > --> > Cc: [e-mail]
--> > --> > Subject: RE: [rbridge] Comments on:
--> http://www.ietf.org/internet-
--> > --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > --> >
--> > --> > Silvano,
--> > --> >
--> > --> > 	As I said in my other reply, this is not what the
--> charter is
--> > --> meant
--> > --> > to
--> > --> > describe.
--> > --> >
--> > --> > --
--> > --> > Eric
--> > --> >
--> > --> > --> -----Original Message-----
--> > --> > --> From: Silvano Gai [mailto:[e-mail]]
--> > --> > --> Sent: Wednesday, November 01, 2006 1:08 AM
--> > --> > --> To: Gray, Eric
--> > --> > --> Cc: [e-mail]
--> > --> > --> Subject: RE: [rbridge] Comments on:
--> > --> > --> 
--> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> > --> > --> -arch-01.txt
--> > --> > -->
--> > --> > -->
--> > --> > --> Eric,
--> > --> > -->
--> > --> > --> The charter says:
--> > --> > --> "load-splitting among multiple paths"
--> > --> > --> The pragmatic way to achieve this is to 
--> implement Layer 2
--> ECMP
--> > --> > -->
--> > --> > --> -- Silvano
--> > --> > -->
--> > --> > -->
--> > --> > --> > -----Original Message-----
--> > --> > --> > From: Gray, Eric [mailto:[e-mail]]
--> > --> > --> > Sent: Tuesday, October 31, 2006 9:25 AM
--> > --> > --> > To: Silvano Gai
--> > --> > --> > Cc: [e-mail]
--> > --> > --> > Subject: RE: [rbridge] Comments on:
--> > --> http://www.ietf.org/internet-
--> > --> > --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > --> > --> >
--> > --> > --> > Silvano,
--> > --> > --> >
--> > --> > --> > 	See below...
--> > --> > --> >
--> > --> > --> > --
--> > --> > --> > Eric
--> > --> > --> >
--> > --> > --> > -- [snip] --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 2> I think we should explicitly 
--> mention layer 2
--> > --> > --> multipath.
--> > --> > --> > -->
--> > --> > --> > -- [snip] --
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > What do you mean by layer 2 multipath?
--> > --> > --> >
--> > --> > --> > Do you mean "link bundling" or something else?
--> > --> > --> >
--> > --> > --> > Are we trying now to apply ECMP to routing 
--> advertisements
--> > --> > --> for layer
--> > --> > --> > two reachability?  That's a big step, particularly
--> > --> when we need
--> > --> to
--> > --> > --> > retain compatibility with existing 802.1 bridges.
--> > --> > --> >
--> > --> > --> > I don't recall seeing anything about this in 
--> the problem
--> > --> statement
--> > --> > --> > document, so I don't know of any reason why we should
--> > --> > --> include it in
--> > --> > --> > the architecture.
--> > --> > --> >
--> > --> > --> > --
--> > --> > --> > Eric
--> > --> > -->
--> > -->
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1HVji0011932 for <[e-mail]>; Wed, 1 Nov 2006 09:31:46 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1HVefK029717; Wed, 1 Nov 2006 12:31:40 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA28447;  Wed, 1 Nov 2006 12:31:40 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647SZW>; Wed, 1 Nov 2006 12:31:39 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Russ White <[e-mail]>, Silvano Gai <[e-mail]>
Date: Wed, 1 Nov 2006 12:31:38 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Comments on:	http://www.ietf.org/internet-drafts/dr	 aft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 17:32:30 -0000
Status: RO
Content-Length: 1722

Russ,

	Just to amplify, I did not say anyone would necessarily be
breaking the interoperability model by implementing an ECMP-like
approach for L2 in their TRILL implementation.  What I said was 
that - if this is considered out of scope for TRILL work, then 
anyone who implements a proprietary (or subsequent standard) L2
ECMP-like approach would be responsible for ensuring that their
implementation works with (by that time) existing RBridges.

--
Eric

--> -----Original Message-----
--> From: Russ White [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 12:16 PM
--> To: Silvano Gai
--> Cc: Gray, Eric; [e-mail]
--> Subject: Re: [rbridge] Comments on: 
--> http://www.ietf.org/internet-drafts/dr 
--> aft-ietf-trill-rbridge-arch-01.txt
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> >>>> 	The notion of using a L2 version of ECMP is - 
--> IMO - in no way
--> >>>> implied
--> >>>> by the text in the charter.  Nor is there any explicit 
--> intention to
--> > preclude
--> >>>> this type of activity - with the caveat that anyone 
--> doing so has to
--> > assume
--> >>>> responsibility for not "breaking" the interoperability model.
--> > 
--> >> Why are you breaking the interoperability model?
--> 
--> That's a quote from Eric, not me.... I'm not convinced you 
--> are or aren't.
--> 
--> :-)
--> 
--> Russ
--> 
--> 
--> - --
--> [e-mail] CCIE <>< Grace Alone
--> 
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.4.2.2 (MingW32)
--> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--> 
--> iD8DBQFFSNYzER27sUhU9OQRAo69AJ4lk+k+94ohK3+4deY7ylKBDUA8nACfUS2P
--> VNXpx0HqsCabI5GWAT86HUY=
--> =j/oK
--> -----END PGP SIGNATURE-----
--> 


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1HMCJ5007613 for <[e-mail]>; Wed, 1 Nov 2006 09:22:12 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Nov 2006 09:22:10 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
Thread-Index: Acb92HXJ23Xi7jPGTB+0kA5NekIJ5QAAVxqQ
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA1HMCJ5007613
Cc: [e-mail]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 17:22:58 -0000
Status: RO
Content-Length: 4489

Eric,

If the sentence "load-splitting among multiple paths", does not mean
Layer 2 ECMP, what does it mean?

How can I split the load among multiple paths, without doing
multipathing?

To split the load, I need at least two paths, If they are not Equal
Cost, what are they?

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Wednesday, November 01, 2006 9:09 AM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: RE: [rbridge] Comments on: http://www.ietf.org/internet-
> drafts/draft-ietf-trill-rbridge-arch-01.txt
> 
> Silvano,
> 
> 	There is a difference.  I've been participating in this working
> group for some time, and I have not heard anyone suggest using L2 ECMP
> is what the charter means by "load-splitting among multiple paths."
> 
> 	However, I agree we need to be fair.  Consequently, let's ask
> other people to weigh in on this issue.  You assert that the charter
> means to include L2 ECMP as an explicit requirement of the TRILL work.
> I assert that it does not.
> 
> 	What do other people say?
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[e-mail]]
> --> Sent: Wednesday, November 01, 2006 11:29 AM
> --> To: Gray, Eric
> --> Cc: [e-mail]
> --> Subject: RE: [rbridge] Comments on:
> --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
> --> -arch-01.txt
> -->
> --> Eric,
> -->
> --> When I propose something that is not in the charter, it is
> --> out of scope
> --> because not in the charter; when I propose something that is in
the
> --> charter, it is out of scope because "this is not what the charter
is
> --> meant to
> --> describe."
> -->
> --> Let's be fair!
> -->
> --> IMHO, if TRILL does not support Layer 2 ECMP, it is not
> --> interesting at
> --> all for us. All the interest in replacing Spanning Tree is
> --> to get Layer
> --> 2 ECMP.
> -->
> --> -- Silvano
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:[e-mail]]
> --> > Sent: Wednesday, November 01, 2006 8:20 AM
> --> > To: Silvano Gai
> --> > Cc: [e-mail]
> --> > Subject: RE: [rbridge] Comments on:
http://www.ietf.org/internet-
> --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
> --> >
> --> > Silvano,
> --> >
> --> > 	As I said in my other reply, this is not what the
charter is
> --> meant
> --> > to
> --> > describe.
> --> >
> --> > --
> --> > Eric
> --> >
> --> > --> -----Original Message-----
> --> > --> From: Silvano Gai [mailto:[e-mail]]
> --> > --> Sent: Wednesday, November 01, 2006 1:08 AM
> --> > --> To: Gray, Eric
> --> > --> Cc: [e-mail]
> --> > --> Subject: RE: [rbridge] Comments on:
> --> > --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
> --> > --> -arch-01.txt
> --> > -->
> --> > -->
> --> > --> Eric,
> --> > -->
> --> > --> The charter says:
> --> > --> "load-splitting among multiple paths"
> --> > --> The pragmatic way to achieve this is to implement Layer 2
ECMP
> --> > -->
> --> > --> -- Silvano
> --> > -->
> --> > -->
> --> > --> > -----Original Message-----
> --> > --> > From: Gray, Eric [mailto:[e-mail]]
> --> > --> > Sent: Tuesday, October 31, 2006 9:25 AM
> --> > --> > To: Silvano Gai
> --> > --> > Cc: [e-mail]
> --> > --> > Subject: RE: [rbridge] Comments on:
> --> http://www.ietf.org/internet-
> --> > --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
> --> > --> >
> --> > --> > Silvano,
> --> > --> >
> --> > --> > 	See below...
> --> > --> >
> --> > --> > --
> --> > --> > Eric
> --> > --> >
> --> > --> > -- [snip] --
> --> > --> > -->
> --> > --> > --> Sgai 2> I think we should explicitly mention layer 2
> --> > --> multipath.
> --> > --> > -->
> --> > --> > -- [snip] --
> --> > --> > -->
> --> > --> >
> --> > --> > What do you mean by layer 2 multipath?
> --> > --> >
> --> > --> > Do you mean "link bundling" or something else?
> --> > --> >
> --> > --> > Are we trying now to apply ECMP to routing advertisements
> --> > --> for layer
> --> > --> > two reachability?  That's a big step, particularly
> --> when we need
> --> to
> --> > --> > retain compatibility with existing 802.1 bridges.
> --> > --> >
> --> > --> > I don't recall seeing anything about this in the problem
> --> statement
> --> > --> > document, so I don't know of any reason why we should
> --> > --> include it in
> --> > --> > the architecture.
> --> > --> >
> --> > --> > --
> --> > --> > Eric
> --> > -->
> -->



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1HHO6J004882 for <[e-mail]>; Wed, 1 Nov 2006 09:17:25 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1HHLfK029415; Wed, 1 Nov 2006 12:17:21 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA27501;  Wed, 1 Nov 2006 12:17:21 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647SP0>; Wed, 1 Nov 2006 12:17:20 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>, Russ White <[e-mail]>
Date: Wed, 1 Nov 2006 12:17:19 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] New shim header proposal---without F-tag field
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 17:18:19 -0000
Status: RO
Content-Length: 2854

Silvano,

	Actually these sort of "scaling questions" are exactly why we don't
currently include necessarily making the TRILL/RBridge solution "more  
scalable" than Ethernet is now.  It is unlikely that we will ever agree
on exactly what is and is not "feasible."  

	However, we do have an implied goal of not deliberately limiting 
scalability of a TRILL/RBridge solution - at least for arbitrary reasons 
- and I maintain that trying to fit the SHIM into a 48-bit alignment (as 
opposed to the 32-bit alignment usually preferred in the IETF) is a pretty 
arbitrary reason.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 11:55 AM
--> To: Russ White
--> Cc: Gray, Eric; Radia Perlman; [e-mail]
--> Subject: RE: [rbridge] New shim header proposal---without 
--> F-tag field
--> 
--> 
--> What is a stretch is 32K trees of 32K nodes, which is what 
--> you need if
--> you want to deploy the current TRILL proposal with 32K RBridges.
--> 
--> Eric says that we need to accommodate half a million RBridges.
--> Half a million tree of half a million nodes is unfeasible.
--> 
--> If we want to support such a large number of Rbridges, we 
--> need to modify
--> the current Trill proposal, reducing the number of trees 
--> that need to be
--> computed.
--> 
--> Agreed?
--> 
--> -- Silvano
--> 
--> 
--> > -----Original Message-----
--> > From: Russ White [mailto:[e-mail]]
--> > Sent: Wednesday, November 01, 2006 8:35 AM
--> > To: Silvano Gai
--> > Cc: Gray, Eric; Radia Perlman; [e-mail]
--> > Subject: Re: [rbridge] New shim header proposal---without 
--> F-tag field
--> > 
--> > -----BEGIN PGP SIGNED MESSAGE-----
--> > Hash: SHA1
--> > 
--> > 
--> > >> 	I don't think there is consensus yet that we 
--> only need 16 bits
--> > >> for RBridge IDs.
--> > >
--> > > With 16 bits, using 1 bit to indicate unicast, we can have 32K
--> switches.
--> > > According to the current definition of TRILL, there is 
--> the need to
--> run
--> > > Djikstra on a database with 32K records, one time for the core
--> instance
--> > > and 32K times for the IRTs. This is clearly out of 
--> reach even for
--> the
--> > > most powerful CPU.
--> > 
--> > ?? Perhaps 32k trees is a stretch, but 32k nodes in a 
--> tree? I don't
--> > think that's really a stretch on today's processors, from 
--> the scaling
--> > work I've seen done in IS-IS.
--> > 
--> > :-)
--> > 
--> > Russ
--> > 
--> > - --
--> > [e-mail] CCIE <>< Grace Alone
--> > 
--> > -----BEGIN PGP SIGNATURE-----
--> > Version: GnuPG v1.4.2.2 (MingW32)
--> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--> > 
--> > iD8DBQFFSMypER27sUhU9OQRAqLwAJ9FLN2YNP2mrB6i0ZcV1fxLzAT0hgCfYHYj
--> > 6mJCA68nQLjCD8US9nRZZag=
--> > =kwzq
--> > -----END PGP SIGNATURE-----
--> 


Received: from xmail03.myhosting.com (xmail03.myhosting.com [168.144.250.217]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1HFb9e004038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 1 Nov 2006 09:15:37 -0800 (PST)
Received: (qmail 13302 invoked from network); 1 Nov 2006 17:15:36 -0000
Received: from unknown (HELO [127.0.0.1]) (Authenticated-user:[e-mail]@[65.190.218.139]) (envelope-sender <[e-mail]>) by xmail03.myhosting.com (qmail-ldap-1.03) with SMTP for <[e-mail]>; 1 Nov 2006 17:15:36 -0000
Message-ID: <[e-mail]>
Date: Wed, 01 Nov 2006 12:15:31 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Silvano Gai <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Comments on:	http://www.ietf.org/internet-drafts/dr aft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 17:16:18 -0000
Status: RO
Content-Length: 798

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


>>>> 	The notion of using a L2 version of ECMP is - IMO - in no way
>>>> implied
>>>> by the text in the charter.  Nor is there any explicit intention to
> preclude
>>>> this type of activity - with the caveat that anyone doing so has to
> assume
>>>> responsibility for not "breaking" the interoperability model.
> 
>> Why are you breaking the interoperability model?

That's a quote from Eric, not me.... I'm not convinced you are or aren't.

:-)

Russ


- --
[e-mail] CCIE <>< Grace Alone

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

iD8DBQFFSNYzER27sUhU9OQRAo69AJ4lk+k+94ohK3+4deY7ylKBDUA8nACfUS2P
VNXpx0HqsCabI5GWAT86HUY=
=j/oK
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1H9FgN000211 for <[e-mail]>; Wed, 1 Nov 2006 09:09:15 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1H9DfK029285; Wed, 1 Nov 2006 12:09:13 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA27062;  Wed, 1 Nov 2006 12:09:13 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647SL2>; Wed, 1 Nov 2006 12:09:12 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>
Date: Wed, 1 Nov 2006 12:09:11 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr	aft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 17:09:48 -0000
Status: RO
Content-Length: 3686

Silvano,

	There is a difference.  I've been participating in this working
group for some time, and I have not heard anyone suggest using L2 ECMP
is what the charter means by "load-splitting among multiple paths." 

	However, I agree we need to be fair.  Consequently, let's ask 
other people to weigh in on this issue.  You assert that the charter 
means to include L2 ECMP as an explicit requirement of the TRILL work.  
I assert that it does not.

	What do other people say?

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 11:29 AM
--> To: Gray, Eric
--> Cc: [e-mail]
--> Subject: RE: [rbridge] Comments on: 
--> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> -arch-01.txt
--> 
--> Eric,
--> 
--> When I propose something that is not in the charter, it is 
--> out of scope
--> because not in the charter; when I propose something that is in the
--> charter, it is out of scope because "this is not what the charter is
--> meant to
--> describe."
--> 
--> Let's be fair!
--> 
--> IMHO, if TRILL does not support Layer 2 ECMP, it is not 
--> interesting at
--> all for us. All the interest in replacing Spanning Tree is 
--> to get Layer
--> 2 ECMP.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[e-mail]]
--> > Sent: Wednesday, November 01, 2006 8:20 AM
--> > To: Silvano Gai
--> > Cc: [e-mail]
--> > Subject: RE: [rbridge] Comments on: http://www.ietf.org/internet-
--> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > 
--> > Silvano,
--> > 
--> > 	As I said in my other reply, this is not what the charter is
--> meant
--> > to
--> > describe.
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: Silvano Gai [mailto:[e-mail]]
--> > --> Sent: Wednesday, November 01, 2006 1:08 AM
--> > --> To: Gray, Eric
--> > --> Cc: [e-mail]
--> > --> Subject: RE: [rbridge] Comments on:
--> > --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> > --> -arch-01.txt
--> > -->
--> > -->
--> > --> Eric,
--> > -->
--> > --> The charter says:
--> > --> "load-splitting among multiple paths"
--> > --> The pragmatic way to achieve this is to implement Layer 2 ECMP
--> > -->
--> > --> -- Silvano
--> > -->
--> > -->
--> > --> > -----Original Message-----
--> > --> > From: Gray, Eric [mailto:[e-mail]]
--> > --> > Sent: Tuesday, October 31, 2006 9:25 AM
--> > --> > To: Silvano Gai
--> > --> > Cc: [e-mail]
--> > --> > Subject: RE: [rbridge] Comments on:
--> http://www.ietf.org/internet-
--> > --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > --> >
--> > --> > Silvano,
--> > --> >
--> > --> > 	See below...
--> > --> >
--> > --> > --
--> > --> > Eric
--> > --> >
--> > --> > -- [snip] --
--> > --> > -->
--> > --> > --> Sgai 2> I think we should explicitly mention layer 2
--> > --> multipath.
--> > --> > -->
--> > --> > -- [snip] --
--> > --> > -->
--> > --> >
--> > --> > What do you mean by layer 2 multipath?
--> > --> >
--> > --> > Do you mean "link bundling" or something else?
--> > --> >
--> > --> > Are we trying now to apply ECMP to routing advertisements
--> > --> for layer
--> > --> > two reachability?  That's a big step, particularly 
--> when we need
--> to
--> > --> > retain compatibility with existing 802.1 bridges.
--> > --> >
--> > --> > I don't recall seeing anything about this in the problem
--> statement
--> > --> > document, so I don't know of any reason why we should
--> > --> include it in
--> > --> > the architecture.
--> > --> >
--> > --> > --
--> > --> > Eric
--> > -->
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1H1a51026130 for <[e-mail]>; Wed, 1 Nov 2006 09:01:37 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1H1YfK029161; Wed, 1 Nov 2006 12:01:34 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA26583;  Wed, 1 Nov 2006 12:01:34 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647SGX>; Wed, 1 Nov 2006 12:01:33 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>
Date: Wed, 1 Nov 2006 12:01:33 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr	aft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 17:03:08 -0000
Status: RO
Content-Length: 53594

Silvano,

	 I am under no obligation to offer a definition of Ethernet that is
acceptable to everyone.  If there is a "rough consensus" that this term is
"good enough" for our purposes, then it should be allowed to stand.  If,
on the other hand, you would like to propose alternate text that does not
make it more difficult to communicate the architectural ideas of this ID,
then I am all ears.

	IMO, the fact that you point out that 802.11, 802.17 and "Ethernet"
are all different standards, indicates to me that you're not getting the
point.  The point is that the TRILL/RBridge architecture is to be defined 
independent of the specific L2 that may be used by implementations.

	This is deliberately done in order to accomplish two things:

   1) To simplify architectural - and subsequent protocol - descriptions,
	and
   2) To permit flexibility in (protocol and) implementations of TRILL.

	Also, I will try to clarify another point.  Some people equate 802.3
with Ethernet.  Others do not.  In fact, many people equate "Ethernet" with
the superset of 802.3 that includes VLANs (802.1Q) and other technologies
that are similar.  In this case I explicitly adopt the most general of all
possible definitions - purposefully to be as inclusive as possible.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 11:48 AM
--> To: Gray, Eric
--> Cc: [e-mail]
--> Subject: RE: [rbridge] Comments on: 
--> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> -arch-01.txt
--> 
--> Eric,
--> 
--> Ethernet, 802.11, and 802.17 are three different standards.
--> 
--> You are confusing the fact that there are wireless 
--> router/gateway that
--> offer an Ethernet port and therefore an RBridge can 
--> potentially connect
--> to that port to access stations or other Rbridges, with the 
--> fact that it
--> is possible to natively design an encapsulation of TRILL over IEEE
--> 802.11 or IEEE 802.17.
--> 
--> I cannot accept a definition of Ethernet that include IEEE 
--> 802.11 and
--> IEEE 802.17.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[e-mail]]
--> > Sent: Wednesday, November 01, 2006 8:39 AM
--> > To: Silvano Gai
--> > Cc: [e-mail]
--> > Subject: RE: [rbridge] Comments on: http://www.ietf.org/internet-
--> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > 
--> > Silvano,
--> > 
--> > 	History is not particularly relevant, but the term "Ethernet"
--> > was originally coined by its inventor, Bob Metcalfe (who - by the
--> > way - did not work for DEC, but worked instead for Xerox at PARC).
--> > 
--> > 	The Ethernet standard was subsequently developed as a joint
--> > effort involving DEC, Intel and Xerox.
--> > 
--> > 	By stating that - when I use the term "Ethernet" - I mean to
--> > include all LAN technologies under IEEE 802, I'm merely 
--> introducing
--> > a short-hand terminology.  In that sense, I am not re-defining the
--> > term, I am merely saying what I mean when I say 
--> "Ethernet."  If you
--> > read the text, you should see that I clearly state the 
--> intention to
--> > define the terminology the way that it will be used in 
--> the document.
--> > 
--> > 	I believe that is an appropriate technique, in this case.  I
--> > also regard this part of the "feedback" as "stylistic" 
--> since you are
--> > objecting to my using a term in the way that I defined it.  In the
--> > literature, there are plenty of examples of redefining terminology
--> > to facilitate understanding and communication.  In this 
--> case, using
--> > "Ethernet" in this fashion reduces the "communication overhead" we
--> > will encounter if I replace that term with either a single term I
--> > make up from scratch, or a compound phrase such as "802.3, 802.11,
--> > 802.1Q, etc."
--> > 
--> > 	For many of us, the term Ethernet already encompasses these
--> > additional technologies.
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: Silvano Gai [mailto:[e-mail]]
--> > --> Sent: Wednesday, November 01, 2006 1:21 AM
--> > --> To: Gray, Eric
--> > --> Cc: [e-mail]
--> > --> Subject: RE: [rbridge] Comments on:
--> > --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> > --> -arch-01.txt
--> > -->
--> > -->
--> > --> Eric,
--> > -->
--> > --> I disagree.
--> > -->
--> > --> I don't think it is wise for TRILL to redefine the 
--> term Ethernet.
--> > --> Ethernet is a term that has a well known meaning in 
--> the industry.
--> > --> The original definition is:
--> > --> Digital Equipment Corporation, Intel, Xerox, The Ethernet,
--> > --> Version 2.0,
--> > --> November 1982.
--> > --> Which has been then standardized by IEEE 802.3.
--> > -->
--> > --> To speak about other IEEE 802 standards that are alive and
--> > --> used, IEEE
--> > --> 802.11 (Wireless LAN) and IEEE 802.17 (Resilient Packet
--> > --> Ring Working)
--> > --> have nothing to do with Ethernet.
--> > -->
--> > --> -- Silvano
--> > -->
--> > --> > -----Original Message-----
--> > --> > From: Gray, Eric [mailto:[e-mail]]
--> > --> > Sent: Tuesday, October 31, 2006 2:44 PM
--> > --> > To: Silvano Gai
--> > --> > Cc: [e-mail]
--> > --> > Subject: RE: [rbridge] Comments on:
--> http://www.ietf.org/internet-
--> > --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > --> >
--> > --> > Silvano,
--> > --> >
--> > --> > 	To be perfectly frank, I am unaware of any reason not to
--> > include
--> > --> > token ring or any other obsolete form of "Ethernet 
--> equivalent
--> > --> technology"
--> > --> > - this is one of the reason to focus on the SHIM as
--> > --> separate from any
--> > --> > specific encapsulation above or below the SHIM.
--> > --> >
--> > --> > 	If you want to check it against all 802 activities,
--> that's
--> > fine.
--> > --> > I would suggest, however, that even though people are
--> > --> realistically
--> > --> not
--> > --> > going to implement most of the hairy/scary versions in an
--> > --> RBridge, I
--> > --> do
--> > --> > not know of a good reason to exclude them at this point.
--> > --> In abstract,
--> > --> > it is certainly possible that people will be able 
--> to work out
--> > --> specifics
--> > --> > of implementation - if and when they decide to do so.
--> > --> >
--> > --> > 	After all, we (the industry) have been building
--> translation
--> > --> bridges
--> > --> > for these technologies for decades.
--> > --> >
--> > --> > 	However, I am open to scoping the architecture to apply
--> only
--> > to
--> > --> a
--> > --> > limited subset of 802 technologies, if that is what would
--> > --> make people
--> > --> > happy...
--> > --> >
--> > --> > --
--> > --> > Eric
--> > --> >
--> > --> > --> -----Original Message-----
--> > --> > --> From: Silvano Gai [mailto:[e-mail]]
--> > --> > --> Sent: Tuesday, October 31, 2006 5:34 PM
--> > --> > --> To: Gray, Eric
--> > --> > --> Cc: [e-mail]
--> > --> > --> Subject: RE: [rbridge] Comments on:
--> > --> > --> 
--> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> > --> > --> -arch-01.txt
--> > --> > -->
--> > --> > -->
--> > --> > --> Eric,
--> > --> > -->
--> > --> > --> A quick reply:
--> > --> > --> Are you telling me that the term Ethernet includes Token
--> Ring,
--> > --> Token
--> > --> > --> Bus, DQDB?
--> > --> > -->
--> > --> > --> This is what you are doing when you say that Ethernet
--> > --> is IEEE 802
--> > --> > --> instead of IEEE 802.3.
--> > --> > -->
--> > --> > --> This is NOT a terminology issue. If the term 
--> Ethernet means
--> > --> > --> 802 I need
--> > --> > --> to check the operation of TRILL against all the 802
--> > --> technologies.
--> > --> > -->
--> > --> > --> -- Silvano
--> > --> > -->
--> > --> > --> > -----Original Message-----
--> > --> > --> > From: Gray, Eric [mailto:[e-mail]]
--> > --> > --> > Sent: Tuesday, October 31, 2006 1:46 PM
--> > --> > --> > To: Silvano Gai
--> > --> > --> > Cc: [e-mail]
--> > --> > --> > Subject: RE: [rbridge] Comments on:
--> > --> http://www.ietf.org/internet-
--> > --> > --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > --> > --> >
--> > --> > --> >
--> > --> > --> >
--> > --> > --> > -- [snip] --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 4> an RBridge must be also able to send
--> > --> two copies of a
--> > --> > --> > --> unicast/multicast/broadcast packet on the same
--> > --> port when it
--> > --> > --> > --> acts as a designated RBridge (one copy is
--> > --> encapsulated, the
--> > --> > --> > --> other not).
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > This, I think, refers to the immediately preceding
--> > --> text in the
--> > --> > --> > architecture:
--> > --> > --> >
--> > --> > --> >         Forwarding information is derived from the
--> > --> combination
--> > --> of
--> > --> > --> >         attached MAC address learning, snooping of
--> > --> > --> multicast-related
--> > --> > --> >         protocols (e.g. - IGMP), and routing
--> > --> > --> advertisements and path
--> > --> > --> >         computations using the link-state routing
--> protocol.
--> > --> > --> >
--> > --> > --> > While your comment is a reasonable one - although
--> > --> potentially
--> > --> > --> > implementation specific - it does not appear to
--> > --> have any bearing
--> > --> > --> > on this text.
--> > --> > --> >
--> > --> > --> >
--> > --> > --> > -- [snip] --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 5> here there is some confusion between
--> > --> 802 and 802.3
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > This  refers (I believe) to the immeditately preceding
--> text:
--> > --> > --> >
--> > --> > --> >         The following terminology is defined in
--> > --> other documents.
--> > --> A
--> > --> > --> brief
--> > --> > --> >         definition is included in this section for
--> > --> > --> convenience and -
--> > --> > --> in
--> > --> > --> >         some cases - to remove any ambiguity 
--> in how the
--> > --> > --> term may be
--> > --> > --> used
--> > --> > --> >         in this document, as well as 
--> derivative documents
--> > --> > --> intended to
--> > --> > --> >         specify components, protocol, behavior and
--> > --> encapsulation
--> > --> > --> >         relative to the architecture specified in
--> > --> this document.
--> > --> > --> >
--> > --> > --> >         o  802: IEEE Specification for the Ethernet
--> > --> architecture,
--> > --> > --> i.e.,
--> > --> > --> >            including hubs and bridges.
--> > --> > --> >
--> > --> > --> > In this text, I explicitly state that these terms
--> > --> are defined
--> > --> > --> elsewhere.
--> > --> > --> > I am also trying to use the most generic definition
--> > --> of Ethernet
--> > --> > --> possible.
--> > --> > --> >
--> > --> > --> > The reason for this is that the problem statement does
--> > --> > --> not restrict
--> > --> > --> the
--> > --> > --> > solution to 802.3.
--> > --> > --> >
--> > --> > --> > There is some confusion in referring to 802.3 in
--> > --> any case: we
--> > --> > --> explicitly
--> > --> > --> > want to include 802.1Q - as well as all of its
--> > --> variations and
--> > --> > --> extensions.
--> > --> > --> >
--> > --> > --> > Consequently, we define the term Ethernet in 
--> the broadest
--> > --> possible
--> > --> > --> sense.
--> > --> > --> >
--> > --> > --> >
--> > --> > --> > -- [snip] --
--> > --> > --> > -->
--> > --> > --> > -->        o  Bridge Spanning Tree (BST): an 
--> Ethernet (L2,
--> > --> 802.1D)
--> > --> > --> > -->           forwarding protocol based on 
--> the topology
--> > --> > --> of a spanning
--> > --> > --> > tree.
--> > --> > --> > -->
--> > --> > --> > --> Sgai 6> I have never seen the acronym BST,
--> > --> everyone use STP.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > I do not know if this term is used in any of the other
--> > --> documents,
--> > --> > --> > but it is not used in this one.  Unless someone
--> > --> objects, I am
--> > --> only
--> > --> > --> > too happy to remove it from this document.
--> > --> > --> >
--> > --> > --> > From a historical perspective, this was 
--> defined this way
--> > --> > --> originally
--> > --> > --> > because we were re-using the term spanning 
--> tree instead
--> > --> > --> of IRT.  It
--> > --> > --> > was causing amazing communication difficulties, so
--> > --> we came up
--> > --> with
--> > --> > --> > the term IRT.  Now we don't need to differentiate BST.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 7> for Ethernet is better to reference 802.3
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > See my response to your point (Sgai 5) above.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > -->         o  Hub: an Ethernet (L2, 802) device with
--> > --> > --> multiple ports
--> > --> > --> which
--> > --> > --> > -->
--> > --> > --> > --> sgai 8> for Hub is better to reference 802.3
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > See my response to your point (Sgai 5) above.  By the
--> > --> > --> definition we
--> > --> > --> > provide in this document, Ethernet is defined
--> > --> broadly to include
--> > --> > --> > 802 technologies.  This is reasonable, 
--> because the term
--> was
--> > --> stolen
--> > --> > --> > by IEEE from a technology stolen from a satellite
--> > --> communication
--> > --> > --> > protocol.  Ironic that 802.3 does not include 
--> wireless,
--> all
--> > --> things
--> > --> > --> > considered.  Certainly the term "Ethernet" should...
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > -->         o  Node: a device with an L2 (MAC) address
--> > --> > --> that sources
--> > --> > --> and/or
--> > --> > --> > -->            sinks L2 frames.
--> > --> > --> > -->
--> > --> > --> > --> Sgai 9> The IEEE term is "station".
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > However, we in the IETF are more familiar with the
--> > --> term "node."
--> > --> > --> >
--> > --> > --> > This is hardly a significant issue.  if 
--> people agree that
--> > --> > --> we should
--> > --> > --> > use the term "station" as opposed to "node", 
--> then I will
--> > --> > --> change it.
--> > --> > --> >
--> > --> > --> > Note that we should be consistent in this usage, if we
--> > --> > --> decide to do
--> > --> > --> > yet another terminology evolution.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > -->         o  Segment: an Ethernet link, 
--> either a single
--> > --> physical
--> > --> > --> link or
--> > --> > --> > -->            emulation thereof (e.g., via hubs) or a
--> > --> > --> logical link or
--> > --> > --> > -->            emulation thereof (e.g., via bridges).
--> > --> > --> > -->
--> > --> > --> > --> Sgai 10> IEEE uses the term "LAN segment"
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > I agree, however this is the definition we 
--> agreed on here.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > -->         o  Subnet, Ethernet: a single segment,
--> > --> or a set of
--> > --> > --> segments
--> > --> > --> > -->            interconnected by a CRED (see
--> > --> section 2.2); in
--> > --> the
--> > --> > --> latter
--> > --> > --> > -->
--> > --> > --> > --> sgai 11> There is no concept of subnet in IEEE.
--> > --> Subnet is
--> > --> > --> typically
--> > --> > --> > --> an IP subnet, and, even if it is common to have
--> > --> one subnet
--> > --> per
--> > --> > --> LAN,
--> > --> > --> > --> this is not the only possibility. Pragmatically
--> > --> IP subnets
--> > --> and
--> > --> > --> > --> Ethernet LAN are unrelated concepts.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > Again, we are defining this term for use in this
--> > --> > --> document.  Does its
--> > --> > --> > use (not its definition) cause confusion or ambiguity?
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > -->            case, the subnet may or may not be
--> > --> equivalent to
--> > --> a
--> > --> > --> single
--> > --> > --> > -->            segment. Also a subnet may be
--> > --> referred to as a
--> > --> > --> broadcast
--> > --> > --> > -->            domain or LAN. By definition, all
--> > --> nodes within an
--> > --> > --> Ethernet
--> > --> > --> > -->            Subnet (broadcast domain or 
--> LAN) must have
--> L2
--> > --> > --> connectivity
--> > --> > --> > -->            with all other nodes in the same
--> > --> Ethernet subnet.
--> > --> > --> > -->
--> > --> > --> > -->         o  TRILL: Transparent 
--> Interconnect over Lots
--> > --> > --> of Links -
--> > --> > --> the
--> > --> > --> > -->            working group and working name for the
--> > --> > --> problem domain
--> > --> > --> to be
--> > --> > --> > -->            addressed in this document.
--> > --> > --> > -->
--> > --> > --> > -->         o  Unicast Forwarding: forwarding methods
--> > --> > --> that apply to
--> > --> > --> frames
--> > --> > --> > -->            with unicast destination MAC addresses.
--> > --> > --> > -->
--> > --> > --> > -->         o  Unknown Destination - a destination
--> > --> for which a
--> > --> > --> receiving
--> > --> > --> > -->            device has no filtering database entry.
--> > --> > --> Destination
--> > --> > --> (layer
--> > --> > --> > -->
--> > --> > --> > --> sgai 12> the stations receive the unknown
--> > --> unicast and have
--> > --> > --> filtering
--> > --> > --> > --> information, only the bridges don't. I propose to
--> > --> > --> replace device
--> > --> > --> with
--> > --> > --> > --> bridge.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > Again, it is the intention to provide as broad a
--> > --> definition as
--> > --> > --> possible
--> > --> > --> > without introducing confusion or ambiguity.  
--> An end node
--> > --> > --> (or station)
--> > --> > --> > has - in a sense - a filtering database (it's mine, or
--> > --> > --> it's for the
--> > --> > --> bit
--> > --> > --> > bucket).
--> > --> > --> >
--> > --> > --> > We need to explicitly include 802.1D 
--> forwarding devices
--> > --> > --> and RBridges.
--> > --> > --> >
--> > --> > --> > However, the definition should specify "forwarding
--> > --> device" - as
--> > --> > --> opposed
--> > --> > --> > to just "receiving device."
--> > --> > --> >
--> > --> > --> > I will change that.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > -->            2) addresses are typically "learned"
--> > --> by (layer 2)
--> > --> > --> > forwarding
--> > --> > --> > -->            devices via a process commonly 
--> referred to
--> > --> > --> as "bridge
--> > --> > --> > learning".
--> > --> > --> > -->
--> > --> > --> > --> Sgai 13> in IEEE, the term used is 
--> "learning" instead
--> > --> > --> of "bridge
--> > --> > --> > learning"
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > However, the term defined in this document is
--> > --> "bridge learning."
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > -->         o  VLAN: Virtual Local Area 
--> Network. VLANs in
--> > --> > --> general fall
--> > --> > --> > into
--> > --> > --> > -->            two categories: link (or port)
--> > --> specific VLANs and
--> > --> > --> tagged
--> > --> > --> > -->            VLANs. In the former case, all frames
--> > --> > --> forwarded and all
--> > --> > --> > -->            directly connected nodes are 
--> assumed to be
--> > --> > --> part of a
--> > --> > --> single
--> > --> > --> > -->            VLAN.  In the latter case, VLAN tagged
--> > --> > --> frames are used
--> > --> > --> to
--> > --> > --> > -->            distinguish which VLAN each frame is
--> intended
--> > --> for.
--> > --> > --> > -->
--> > --> > --> > --> Sgai 14> This definition is not 
--> completely correct, I
--> > --> prefer:
--> > --> > --> > -->
--> > --> > --> > --> VLAN technology introduces the following three
--> > --> basic types
--> > --> of
--> > --> > --> frame:
--> > --> > --> > --> a) Untagged frames;
--> > --> > --> > --> b) Priority-tagged frames; and
--> > --> > --> > --> c) VLAN-tagged frames.
--> > --> > --> > -->
--> > --> > --> > --> An untagged frame or a priority-tagged 
--> frame does not
--> > --> > --> carry any
--> > --> > --> > --> identification of the VLAN to which it 
--> belongs. Such
--> > --> > --> frames are
--> > --> > --> > --> classified as belonging to a particular 
--> VLAN based on
--> > --> > --> parameters
--> > --> > --> > --> associated with the receiving Port, or, through
--> > --> proprietary
--> > --> > --> extensions
--> > --> > --> > --> to IEEE 802.1Q standard, based on the 
--> data content of
--> > --> > --> the frame
--> > --> > --> (e.g.,
--> > --> > --> > --> MAC Address, layer 3 protocol ID, etc.).
--> > --> > --> > -->
--> > --> > --> > --> A VLAN-tagged frame carries an explicit
--> > --> > --> identification of the VLAN
--> > --> > --> to
--> > --> > --> > --> which it belongs; i.e., it carries a tag header
--> > --> that carries
--> > --> a
--> > --> > --> non-
--> > --> > --> > null
--> > --> > --> > --> VID. Such a frame is classified as belonging to a
--> > --> > --> particular VLAN
--> > --> > --> > based
--> > --> > --> > --> on the value of the VID that is included 
--> in the tag
--> > --> > --> header. The
--> > --> > --> > presence
--> > --> > --> > --> of the tag header carrying a non-null VID 
--> means that
--> > --> > --> some other
--> > --> > --> > device,
--> > --> > --> > --> either the originator of the frame or a
--> > --> VLAN-aware Bridge,
--> > --> has
--> > --> > --> mapped
--> > --> > --> > --> this frame into a VLAN and has inserted the
--> > --> appropriate VID.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > So, you're getting into the details of the
--> > --> technology and - in
--> > --> > --> particular
--> > --> > --> > the encapsulation.  I will expand the definition to
--> > --> include a
--> > --> > --> possibility
--> > --> > --> > that other criteria may be used to define a 
--> "VLAN port" -
--> > --> although
--> > --> > --> this is
--> > --> > --> > isomorphic to a logical model in which a device
--> > --> > --> implementation uses
--> > --> > --> some
--> > --> > --> > criteria to decide that a subset of the 
--> traffic received
--> > --> > --> on a specific
--> > --> > --> > physical port is to be forwarded as if received on a
--> > --> > --> specific logical
--> > --> > --> > port.
--> > --> > --> >
--> > --> > --> > The key point in this definition is that a VLAN is a
--> > --> > --> "Virtual LAN" -
--> > --> > --> > meaning
--> > --> > --> > it consists of a subset of the physical and L2
--> connectivity
--> > --> > --> corresponding
--> > --> > --> > to
--> > --> > --> > a "logical LAN."  The intent is to "rise above" the
--> > --> technological
--> > --> > --> > approaches
--> > --> > --> > and encapsulations to establish a generic 
--> definition that
--> > --> > --> is loosely
--> > --> > --> tied
--> > --> > --> > to
--> > --> > --> >
--> > --> > --> > ways that this generic definition is actually 
--> implemented.
--> > --> > --> >
--> > --> > --> > Again, bearing in mind the way that the term is
--> > --> defined, does
--> > --> the
--> > --> > --> usage of
--> > --> > --> > the term cause confusion or ambiguity?
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > -->         o  CRED Forwarding Table (CFT): 
--> the per-hop
--> > --> forwarding
--> > --> > --> table
--> > --> > --> > -->            populated by the RBridge 
--> Routing Protocol;
--> > --> > --> forwarding
--> > --> > --> > within
--> > --> > --> > -->            the CRED is based on a lookup of the
--> > --> CRED Transit
--> > --> > --> Header
--> > --> > --> > -->            (CTH) encapsulated within the
--> > --> outermost received
--> > --> L2
--> > --> > --> header.
--> > --> > --> > -->            The outermost L2 encapsulation in this
--> > --> > --> case includes
--> > --> > --> the
--> > --> > --> > -->            source MAC address of the immediate
--> > --> > --> upstream RBridge
--> > --> > --> > -->            transmitting the frame and 
--> destination MAC
--> > --> > --> address of
--> > --> > --> the
--> > --> > --> > -->            receiving RBridge for use in 
--> the unicast
--> > --> forwarding
--> > --> > --> case.
--> > --> > --> > -->
--> > --> > --> > --> Sgai 15> In section 7 of
--> > --> > --> > -->
--> > --> > -->
--> > --> 
--> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-
--> > --> > --> > 00.txt
--> > --> > --> > --> we proposed that when two rbridges are
--> > --> connected by a point
--> > --> to
--> > --> > --> point
--> > --> > --> > --> link the outer MAC addresses may be set to a
--> > --> > --> predefined value in
--> > --> > --> > --> transmission and ignored in reception.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > I'm not sure how your proposal intends to 
--> determine that
--> > --> > --> a link is in
--> > --> > --> > fact point-to-point and does not just look that way.
--> > --> > --> >
--> > --> > --> > I prefer to use the same encapsulation in all 
--> cases where
--> it
--> > --> will
--> > --> > --> work.
--> > --> > --> >
--> > --> > --> > The optimization associated with using some form of
--> > --> > --> null-encapsulation
--> > --> > --> > is of dubious value, given that it may not be 
--> possible to
--> > --> > --> be certain a
--> > --> > --> > point-to-point link is - and will remain - in fact a
--> > --> > --> point-to-point
--> > --> > --> > link.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > -->         o  CFT-IRT: a forwarding table used for
--> > --> propagation
--> > --> of
--> > --> > --> > -->            broadcast, multicast or flooded
--> > --> frames along the
--> > --> > --> Ingress
--> > --> > --> > -->            RBridge Tree (IRT).
--> > --> > --> > -->
--> > --> > --> > --> Sgai 16> is it a forwarding table or is it a
--> > --> > --> filtering database.
--> > --> > --> Since
--> > --> > --> > --> the "miss" behavior is to flood, I see it as a
--> > --> > --> filtering database.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > What state was "miss" behavior from - Hawaii?  :-)
--> > --> > --> >
--> > --> > --> > It is analogous to a filtering database 
--> entry, but it is
--> not
--> > --> that.
--> > --> > --> >
--> > --> > --> > Clearly there are more things in this world 
--> than can be
--> > --> classified
--> > --> > --> > in this taxonomy.  However, given these 
--> choices, it is a
--> > --> > --> forwarding
--> > --> > --> > table.
--> > --> > --> >
--> > --> > --> > This is not a misbehavior, in that the same 
--> "base" tree
--> > --> > --> is used for
--> > --> > --> > broadcast and multicast traffic as well as flooded
--> > --> > --> traffic.  It may
--> > --> > --> > be arguable that flooding is a misbehavior, but I
--> > --> seem to recall
--> > --> > --> > that people still see it as a necessary evil.
--> > --> > --> >
--> > --> > --> > It is also not "miss" behavior (as in "cache miss") in
--> > --> > --> the multicast
--> > --> > --> > and broadcast case, either.
--> > --> > --> >
--> > --> > --> > I believe the definition is quite correct and easy to
--> > --> understand,
--> > --> > --> > provided you're not reading it with preconceived
--> > --> misconceptions
--> > --> > --> > about its meaning.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > -->         o  CRED Transit Header (CTH): a 'shim'
--> > --> header that
--> > --> > --> > encapsulates
--> > --> > --> > -->            the ingress L2 frame and persists
--> > --> throughout the
--> > --> > --> transit of
--> > --> > --> > a
--> > --> > --> >
--> > --> > --> > -->            CRED, which is further 
--> encapsulated within
--> > --> > --> a hop-by-hop
--> > --> > --> L2
--> > --> > --> > -->            header (and trailer). The hop-by-hop L2
--> > --> > --> encapsulation
--> > --> > --> in
--> > --> > --> > this
--> > --> > --> >
--> > --> > --> > -->            case includes the source MAC address of
--> > --> > --> the immediate
--> > --> > --> > -->            upstream RBridge transmitting the frame
--> > --> > --> and destination
--> > --> > --> MAC
--> > --> > --> > -->            address of the receiving RBridge -
--> > --> at least in
--> > --> the
--> > --> > --> unicast
--> > --> > --> > -->            forwarding case.
--> > --> > --> > -->
--> > --> > --> > --> Sgai 17> is this true also for unknown unicast?
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > That is something that will be (may be already)
--> > --> decided in the
--> > --> > --> protocol
--> > --> > --> > specification.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > -->         o  CRED Transit Table (CTT): a 
--> table that maps
--> > --> ingress
--> > --> > --> frame
--> > --> > --> > L2
--> > --> > --> > -->            destinations to egress RBridge
--> > --> addresses, used to
--> > --> > --> determine
--> > --> > --> > -->            encapsulation of ingress frames for
--> > --> transit of
--> > --> the
--> > --> > --> CRED.
--> > --> > --> > -->
--> > --> > --> > -->         o  Cooperating RBridges - those RBridges
--> > --> > --> within a single
--> > --> > --> > -->            Ethernet Subnet (broadcast 
--> domain or LAN)
--> > --> > --> not having
--> > --> > --> been
--> > --> > --> > -->            configured to ignore each other. By
--> > --> default, all
--> > --> > --> RBridges
--> > --> > --> > -->            within a single Ethernet subnet will
--> > --> cooperate
--> > --> with
--> > --> > --> each
--> > --> > --> > -->            other. It is possible for 
--> implementations
--> > --> > --> to allow for
--> > --> > --> > -->            configuration that will restrict
--> > --> > --> "cooperation" between
--> > --> > --> an
--> > --> > --> > -->            RBridge and an apparent neighboring
--> > --> RBridge.  One
--> > --> > --> reason
--> > --> > --> > why
--> > --> > --> > -->            this might occur is if the trust model
--> > --> > --> that applies in
--> > --> > --> a
--> > --> > --> > -->            particular deployment imposes 
--> a need for
--> > --> > --> configuration
--> > --> > --> of
--> > --> > --> > -->            security information.  By 
--> default no such
--> > --> > --> configuration
--> > --> > --> is
--> > --> > --> > -->            required however - should it be used in
--> > --> > --> any specific
--> > --> > --> > scenario
--> > --> > --> > -->
--> > --> > --> > -->            - it is possible (either 
--> deliberately or
--> > --> > --> inadvertently)
--> > --> > --> to
--> > --> > --> > -->            configure neighboring RBridges so
--> > --> that they do
--> > --> not
--> > --> > --> > cooperate.
--> > --> > --> > -->
--> > --> > --> > -->            In the remainder of this document,
--> > --> all RBridges
--> > --> are
--> > --> > --> assumed
--> > --> > --> > -->            to be in a cooperating (default)
--> > --> configuration.
--> > --> > --> > -->
--> > --> > --> > --> Sgai 18> can RBridges cooperate in 
--> groups, e.g. four
--> > --> Rbridges
--> > --> > --> > connected
--> > --> > --> > --> to a LAN cooperating two and two?
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > Yes.  There may be reasons why this might be done
--> > --> deliberately,
--> > --> > --> however
--> > --> > --> > - even in the absence of any "proof of concept"
--> > --> > --> justification - it is
--> > --> > --> a
--> > --> > --> > really good idea to design the protocol to be 
--> robust in
--> > --> > --> cases where a
--> > --> > --> > set of RBridges may be (mis)configured in 
--> such a way as
--> > --> > --> to be unable
--> > --> > --> to
--> > --> > --> > discover each other.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > -->         o  Ingress RBridge Tree: a tree
--> > --> computed for each
--> > --> edge
--> > --> > --> RBridge
--> > --> > --> > -->            and potentially for each VLAN 
--> in which that
--> > --> RBridge
--> > --> > --> > -->
--> > --> > --> > --> sgai 19> why for each VLAN? I got the
--> > --> impression that there
--> > --> > --> > --> was a single tree that was pruned differently for
--> > --> > --> different VLANs.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > Pruning may also take place at the ingress, if - for
--> > --> > --> example - it has
--> > --> > --> a
--> > --> > --> > subset of interfaces that are not connected to any
--> > --> egress for
--> > --> > --> particular
--> > --> > --> > VLANs.  It is a small point but, in such 
--> cases, there is
--> in
--> > --> effect
--> > --> > --> more
--> > --> > --> > than one IRT even at the ingress.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > -->            participates - for delivery of 
--> broadcast,
--> > --> > --> multicast and
--> > --> > --> > -->            flooded frames from that RBridge to all
--> > --> > --> relevant egress
--> > --> > --> > -->            RBridges. This is the 
--> point-to-multipoint
--> > --> > --> delivery tree
--> > --> > --> > used
--> > --> > --> > -->            by an ingress RBridge to deliver
--> > --> > --> multicast, broadcast
--> > --> > --> or
--> > --> > --> > -->            flooded traffic.
--> > --> > --> > -->
--> > --> > --> > --> Sgai 20> the current version of the proposal
--> > --> speaks about a
--> > --> > --> multicast
--> > --> > --> > --> address, not point-to-point.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > I did not say "point-to-point" (look again).
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > -->         o  LPT: Learned Port Table. See
--> > --> Filtering Database.
--> > --> > --> > -->
--> > --> > --> > --> Sgai 21> not proper terminology, I would use
--> > --> > --> "filtering database"
--> > --> > --> > --> everywhere.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > I am happy to remove this if there is no objection
--> > --> to my doing
--> > --> so.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> sgai 22> I wired port is Ehernet, i.e. 
--> IEEE 802.3, a
--> > --> > --> > --> wireless port is not Ethernet, it is IEEE 802.11.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > See my response to your point (sgai 8) above.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> sgai 23> they learn because STP guarantees
--> > --> > --> symmetrical forwarding
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > This (apparently) refers to the immeditately preceding
--> text:
--> > --> > --> >
--> > --> > --> >         Conventional bridges contain a 
--> learned port table
--> > --> > --> (LPT), or
--> > --> > --> >         filtering database, and a spanning tree table
--> > --> > --> (STT). The LPT
--> > --> > --> >         allows a bridge to avoid flooding all received
--> > --> > --> frames, as is
--> > --> > --> >         typical for a hub or repeater. The 
--> bridge learns
--> > --> > --> which nodes
--> > --> > --> are
--> > --> > --> >         accessible from a particular port by assuming
--> > --> > --> bi-directional
--> > --> > --> >         consistency:
--> > --> > --> >
--> > --> > --> > I'm not sure how picking at the peculiarities of
--> > --> STP behavior is
--> > --> > --> > relevant to this description.  STP results in a
--> > --> single spanning
--> > --> > --> > tree where each link is bi-directional.  This
--> > --> ensures that the
--> > --> > --> > MAC frames are forwarded in a 
--> bi-directionally consistent
--> > --> fashion.
--> > --> > --> >
--> > --> > --> > To replace this text with yours is to provide less
--> > --> information.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 24> active ports -> forwarding ports
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > "Active ports" was the exact wording 
--> suggested to me.  In
--> > --> > --> context for
--> > --> > --> > this working group "active ports" is more 
--> meaningful than
--> > --> > --> "forwarding
--> > --> > --> > ports."  For people not used to STP-speak, "forwarding
--> > --> > --> port" might be
--> > --> > --> > used to discriminate from a "code port."
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 25> there is no STT, there is a 
--> state associated
--> > --> > --> with each
--> > --> > --> port
--> > --> > --> > --> that can be: disabled, blocking, listening,
--> > --> learning, and
--> > --> > --> forwarding
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > Other than the issue with terminology, is this text
--> > --> wrong?  I am
--> > --> > --> fairly
--> > --> > --> > sure that different implementations handle the "port
--> state"
--> > --> > --> information
--> > --> > --> > in different ways, and I am also reasonably 
--> sure that a
--> > --> > --> "table" such
--> > --> > --> as
--> > --> > --> > the one described here is one of the ways it might be
--> done.
--> > --> > --> >
--> > --> > --> > However, I agree with your assertion that 
--> this is the way
--> > --> > --> that it is
--> > --> > --> > usually talked about in an IEEE context, so -
--> > --> unless there are
--> > --> > --> specific
--> > --> > --> > objections - I can change the wording to be consistent
--> > --> > --> with what you
--> > --> > --> > suggest.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> sgai 26> disabled -> blocking
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > I can make this change as well.  However, from the
--> > --> > --> perspective of what
--> > --> > --> > we are trying to do, "disabled" is potentially a more
--> > --> > --> correct term.
--> > --> > --> It
--> > --> > --> > is certainly more intuitively correct, outside of a
--> > --> > --> strictly IEEE/STP
--> > --> > --> > context.
--> > --> > --> >
--> > --> > --> > Symmetry is maintained in STP by blocking ports/links
--> > --> > --> bi-directionally.
--> > --> > --> > In such cases, a port is effectively disabled 
--> for bridges
--> > --> > --> at either
--> > --> > --> end
--> > --> > --> > of the link for which a port is blocked, is it not?
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> sgai 27> I repeat a comment that I have 
--> made to other
--> > --> > --> documents: "
--> > --> > --> > --> The discussion about VLAN needs to be much more
--> > --> > --> extensive. It is
--> > --> > --> clear
--> > --> > --> > --> from the mailing list discussion that VLANs can be
--> > --> > --> used inside the
--> > --> > --> > --> packet or in the Ethernet encapsulation of TRILL.
--> > --> > --> These are two
--> > --> > --> > --> different kinds of VLANs and their 
--> requirement need
--> > --> > --> to be stated
--> > --> > --> > --> separately. Q in Q needs also to be discussed. I
--> > --> > --> propose to define
--> > --> > --> > inner
--> > --> > --> > --> and outer VLANs (with reference to the position of
--> > --> > --> the tag in the
--> > --> > --> > frame."
--> > --> > --> > --> Here I think we are talking about outer VLANs
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > I responded to this in separate mail.  I wait to hear
--> > --> > --> other opinions
--> > --> > --> on
--> > --> > --> > this subject.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 28> IMO all RBridges must be ingress 
--> RBridges,
--> > --> > --> at least to
--> > --> > --> > support
--> > --> > --> > --> inband management, e.g. SNMP.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > No.
--> > --> > --> >
--> > --> > --> > In order to ensure symmetry with RBridges not
--> > --> > --> participating in STP,
--> > --> > --> there
--> > --> > --> > MUST be a designated RBridge that does all of the
--> > --> sending and
--> > --> > --> receiving
--> > --> > --> > of native encapsulated frames on a LAN segment.
--> > --> > --> >
--> > --> > --> > Any RBridge the loses the "Designated RBridge"
--> > --> election cannot
--> > --> be
--> > --> > --> either
--> > --> > --> > an ingress or an egress for that LAN segment.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 29> same as above
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > Same as above.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 30> I think the previous definition is not
--> needed.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > This appears to refer to:
--> > --> > --> >
--> > --> > --> >         o  Local RBridge - the RBridge that forms and
--> > --> > --> maintains the
--> > --> > --> CFT-
--> > --> > --> >            IRT entry (or entries) under 
--> discussion. The
--> > --> > --> local RBridge
--> > --> > --> >            may be an Ingress RBridge, or an egress
--> > --> RBridge with
--> > --> > --> respect
--> > --> > --> >            to any set of entries in the CFT-IRT.
--> > --> > --> >
--> > --> > --> > This defintion is needed.  It is subsequently used
--> > --> in at least 4
--> > --> > --> places.
--> > --> > --> > When discussing the behavior of a specific RBridge
--> > --> > --> relative to a peer,
--> > --> > --> > it is convenient to define the term "local RBridge."
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> sgai 31> why is it zero or more, if an RBridge
--> > --> exists, it
--> > --> must
--> > --> > --> have
--> > --> > --> > --> a an IRT, I haven't seen any discussion to support
--> > --> > --> multiple IRTs.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > This was answered previously on the mailing list.
--> > --> > --> Briefly, zero or
--> > --> > --> > more is correct, given that an RBridge may not have
--> > --> > --> forwarding entries
--> > --> > --> > for frames it has received.  In these cases, 
--> a frame is
--> > --> > --> not forwarded.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 32> I don't understand this. Since 
--> the current
--> > --> > --> proposal uses
--> > --> > --> a
--> > --> > --> > --> multicast MAC address, what is needed is a bit map
--> > --> > --> for each IRT
--> > --> > --> that
--> > --> > --> > --> says which ports are blocking and which are
--> > --> > --> forwarding. You are
--> > --> > --> > --> basically building a ST using ISIS.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > This might be the case for a specific implementation.
--> > --> > --> Whether it is
--> > --> > --> > implemented as a "bit-mask" with "non-blocking"
--> > --> > --> (forwarding) ports, or
--> > --> > --> > is implemented as a full-blown table is 
--> largely dependent
--> on
--> > --> what
--> > --> > --> other
--> > --> > --> > information the local device requires in order to
--> > --> > --> properly forwad the
--> > --> > --> > frame.  If - for example - a device has multiple
--> > --> > --> different port types,
--> > --> > --> > it may need to have more information for each port (or
--> that
--> > --> > --> information
--> > --> > --> > may be added later on).
--> > --> > --> >
--> > --> > --> > All of these are implementation choices that are
--> > --> > --> logically represented
--> > --> > --> > by the table described here.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 33> I don't get the pair.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > Since this immediately follows:
--> > --> > --> >
--> > --> > --> >         Each entry would contain an indication of
--> > --> which single
--> > --> > --> interface
--> > --> > --> >         a broadcast, multicast or flooded 
--> frame would be
--> > --> > --> forwarded for
--> > --> > --> >         each (ingress RBridge, egress RBridge) pair.
--> > --> > --> >
--> > --> > --> > I don't get what you don't get.
--> > --> > --> >
--> > --> > --> > The pair refers to the tuple "(ingress RBridge, egress
--> > --> RBridge)."
--> > --> > --> >
--> > --> > --> > This might be the point at which your earlier 
--> point (Sgai
--> 4)
--> > --> would
--> > --> > --> make
--> > --> > --> > sense to insert.  I had logically modeled 
--> this in my own
--> > --> > --> mind as two
--> > --> > --> > distinct "interfaces" (the reason I use this 
--> term, rather
--> > --> > --> thhan port),
--> > --> > --> > but I should clarify this.
--> > --> > --> >
--> > --> > --> > In any case, the entries are keyed by both ingress and
--> > --> > --> egress RBridge.
--> > --> > --> > While there will be entries for only those egress
--> > --> > --> RBridges where this
--> > --> > --> > local RBridge is on the shortest path 
--> (between the given
--> > --> > --> ingress and
--> > --> > --> > egress pair), there will be at most one entry per
--> > --> any ingress
--> > --> and
--> > --> > --> > egress pair.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 34> as a matter of fact each interface is
--> > --> > --> basically a set of
--> > --> > --> two
--> > --> > --> > --> interfaces, a regular one and a tunnel 
--> one, and the
--> > --> > --> > forwarding/blocking
--> > --> > --> > --> state may be different for the two.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > No.
--> > --> > --> >
--> > --> > --> > As per my response to your point (Sgai 28) above, not
--> > --> > --> every RBridge
--> > --> > --> has a
--> > --> > --> > "regular one" as you describe here.
--> > --> > --> >
--> > --> > --> > The forwarding/blocking state is not applicable as
--> > --> > --> RBridges don't do
--> > --> > --> STP.
--> > --> > --> >
--> > --> > --> > For the native interface, fowarding/blocking state is
--> > --> > --> analogous to the
--> > --> > --> > "Designated RBridge" election process.
--> > --> > --> >
--> > --> > --> > Since this point evidently applies to -
--> > --> > --> >
--> > --> > --> >
--> Entries
--> > --> would
--> > --> > --> also
--> > --> > --> >         contain any required encapsulation 
--> information,
--> > --> > --> etc. required
--> > --> > --> >         for forwarding on a given interface, 
--> and toward a
--> > --> > --> corresponding
--> > --> > --> >         specific egress RBridge.
--> > --> > --> >
--> > --> > --> > - your point, and my response, are related to 
--> the point
--> > --> > --> (and response)
--> > --> > --> > above (Sgai 33), and I will try to clarify this
--> > --> part as well.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 35> this protocol must be designed to avoid
--> > --> > --> transient loops,
--> > --> > --> > since
--> > --> > --> > --> transient loops of multicast/broadcast cause
--> > --> > --> broadcast storm that
--> > --> > --> are
--> > --> > --> > --> highly undesirable.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > No.
--> > --> > --> >
--> > --> > --> > The protocol needs to include a provision to prevent
--> > --> > --> _use_ of links
--> > --> > --> that
--> > --> > --> > may connect to transient loops.  Using a link-state
--> > --> > --> routing protocol
--> > --> > --> has
--> > --> > --> > clearly been demostrated to produce transient 
--> loops, but
--> > --> > --> the problem
--> > --> > --> you
--> > --> > --> > want to address has to do with using those links.
--> > --> > --> >
--> > --> > --> > A state-machine driven mechanism similar to 
--> STP might be
--> > --> > --> the approach
--> > --> > --> to
--> > --> > --> > use.
--> > --> > --> >
--> > --> > --> > Because we're incorporating TTL in the SHIM, 
--> however this
--> > --> > --> would need
--> > --> > --> to
--> > --> > --> > apply only to IRT traffic.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > -->
--> > --> > --> > --> Sgai 36> see my previous comment about VLANs
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > See my previous responses.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> sgai 37> disabled -> blocking.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > See my response to your point (sgai 26) above.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 38> for multicast/broadcast we also need to
--> > --> > --> avoid transient
--> > --> > --> > loops.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > Yes.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 39> but RBridge discovery and STP are ongoing
--> > --> > --> processes, why
--> > --> > --> do
--> > --> > --> > we
--> > --> > --> > --> want to couple their timers?
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > I am not suggesting "coupling their timers."  I am
--> > --> saying that
--> > --> the
--> > --> > --> value
--> > --> > --> > chosen for a timer (if one is used) to 
--> determine when it
--> > --> > --> is reasonable
--> > --> > --> to
--> > --> > --> > start RBridge peer discovery should take into
--> > --> account the time
--> > --> it
--> > --> > --> takes
--> > --> > --> > for the local spanning tree resolution.
--> > --> > --> >
--> > --> > --> > I feel the reason for this is self-evident 
--> but, just to
--> > --> > --> clarify, think
--> > --> > --> > about the process we're planning to use to determine
--> RBridge
--> > --> > --> nick-names.
--> > --> > --> > If we start this too early, we will be re-starting it
--> > --> > --> many times as we
--> > --> > --> > "hear from" new RBridge peers when the 
--> connecting links go
--> > --> active
--> > --> > --> after
--> > --> > --> > local bridges go to the forwarding state.  This would
--> > --> > --> apply only at
--> > --> > --> the
--> > --> > --> > system start up as - after that - you are 
--> quite correct
--> > --> > --> in asserting
--> > --> > --> it
--> > --> > --> > would be an ongoing process.
--> > --> > --> >
--> > --> > --> > Perhaps I should add some words to indicate 
--> that a delay
--> > --> > --> would not be
--> > --> > --> > necessary if the protocol mechanisms do not introduce
--> > --> > --> instability as a
--> > --> > --> > new peer is discovered.  So far, I have not seen any
--> > --> > --> indication that a
--> > --> > --> > "race-free" solution to accomplish this has 
--> been designed
--> > --> > --> - or talked
--> > --> > --> > about.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 40> there is also a requirement to time-out
--> learnt
--> > --> > --> information to
--> > --> > --> > --> maintain the filtering databases.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > There would be, if we were doing that.  Instead,
--> > --> we're adopting
--> > --> a
--> > --> > --> > link-state routing protocol and they tend to have
--> > --> that covered.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 41> periodically or on demand
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > See the response to your point (Sgai 40) above.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > --> > -->
--> > --> > --> > --> Sgai 42> potentially there is an unencapsulated
--> > --> > --> interface for each
--> > --> > --> > --> physical interface of the RBridge. It is true that
--> > --> > --> you can model
--> > --> > --> all
--> > --> > --> > --> of them as a single separate logical 
--> interface, but
--> > --> > --> then we need
--> > --> > --> to
--> > --> > --> > --> replicate the frame according to a 
--> bitmask that tells
--> on
--> > --> which
--> > --> > --> > physical
--> > --> > --> > --> interface the RBridge is designated.
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > Again, your use of a "bitmask" is an implementation
--> > --> > --> choice as opposed
--> > --> > --> > to a logical model.
--> > --> > --> >
--> > --> > --> > As you observe, I do "model all of them as a single
--> > --> > --> separate logical
--> > --> > --> > interface" and if you want to "replicate the frame
--> > --> according to
--> > --> a
--> > --> > --> > bitmask that tells on which physical interface the
--> > --> RBridge is
--> > --> > --> > designated" - you're absolutely free to do so.
--> > --> > --> >
--> > --> > --> > Personally, I think this is far too much 
--> implementation
--> > --> > --> stuff for a
--> > --> > --> > protocol specification, let alone an architecture
--> document.
--> > --> > --> >
--> > --> > --> > -->
--> > --> > --> > --> Sgai 43> can we clarify that this means 
--> "drop BPDUs".
--> > --> > --> > -->
--> > --> > --> >
--> > --> > --> > Yes.
--> > --> > --> >
--> > --> > --> > -- [snip --
--> > --> > -->
--> > -->
--> 


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1GswvE023531 for <[e-mail]>; Wed, 1 Nov 2006 08:54:58 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Nov 2006 08:54:56 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] New shim header proposal---without F-tag field
Thread-Index: Acb906n2Z8S2QHfARmG3BTYTaGT7RQAAhI1Q
From: "Silvano Gai" <[e-mail]>
To: "Russ White" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA1GswvE023531
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] New shim header proposal---without F-tag field
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 16:55:17 -0000
Status: RO
Content-Length: 1692

What is a stretch is 32K trees of 32K nodes, which is what you need if
you want to deploy the current TRILL proposal with 32K RBridges.

Eric says that we need to accommodate half a million RBridges.
Half a million tree of half a million nodes is unfeasible.

If we want to support such a large number of Rbridges, we need to modify
the current Trill proposal, reducing the number of trees that need to be
computed.

Agreed?

-- Silvano


> -----Original Message-----
> From: Russ White [mailto:[e-mail]]
> Sent: Wednesday, November 01, 2006 8:35 AM
> To: Silvano Gai
> Cc: Gray, Eric; Radia Perlman; [e-mail]
> Subject: Re: [rbridge] New shim header proposal---without F-tag field
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> >> 	I don't think there is consensus yet that we only need 16 bits
> >> for RBridge IDs.
> >
> > With 16 bits, using 1 bit to indicate unicast, we can have 32K
switches.
> > According to the current definition of TRILL, there is the need to
run
> > Djikstra on a database with 32K records, one time for the core
instance
> > and 32K times for the IRTs. This is clearly out of reach even for
the
> > most powerful CPU.
> 
> ?? Perhaps 32k trees is a stretch, but 32k nodes in a tree? I don't
> think that's really a stretch on today's processors, from the scaling
> work I've seen done in IS-IS.
> 
> :-)
> 
> Russ
> 
> - --
> [e-mail] CCIE <>< Grace Alone
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFFSMypER27sUhU9OQRAqLwAJ9FLN2YNP2mrB6i0ZcV1fxLzAT0hgCfYHYj
> 6mJCA68nQLjCD8US9nRZZag=
> =kwzq
> -----END PGP SIGNATURE-----



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1GlxrF019944 for <[e-mail]>; Wed, 1 Nov 2006 08:47:59 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Nov 2006 08:47:57 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
Thread-Index: Acb91C+EyJsTQMkqR4utslW/Th5PHQAAHlPA
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA1GlxrF019944
Cc: [e-mail]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 16:49:41 -0000
Status: RO
Content-Length: 46004

Eric,

Ethernet, 802.11, and 802.17 are three different standards.

You are confusing the fact that there are wireless router/gateway that
offer an Ethernet port and therefore an RBridge can potentially connect
to that port to access stations or other Rbridges, with the fact that it
is possible to natively design an encapsulation of TRILL over IEEE
802.11 or IEEE 802.17.

I cannot accept a definition of Ethernet that include IEEE 802.11 and
IEEE 802.17.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Wednesday, November 01, 2006 8:39 AM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: RE: [rbridge] Comments on: http://www.ietf.org/internet-
> drafts/draft-ietf-trill-rbridge-arch-01.txt
> 
> Silvano,
> 
> 	History is not particularly relevant, but the term "Ethernet"
> was originally coined by its inventor, Bob Metcalfe (who - by the
> way - did not work for DEC, but worked instead for Xerox at PARC).
> 
> 	The Ethernet standard was subsequently developed as a joint
> effort involving DEC, Intel and Xerox.
> 
> 	By stating that - when I use the term "Ethernet" - I mean to
> include all LAN technologies under IEEE 802, I'm merely introducing
> a short-hand terminology.  In that sense, I am not re-defining the
> term, I am merely saying what I mean when I say "Ethernet."  If you
> read the text, you should see that I clearly state the intention to
> define the terminology the way that it will be used in the document.
> 
> 	I believe that is an appropriate technique, in this case.  I
> also regard this part of the "feedback" as "stylistic" since you are
> objecting to my using a term in the way that I defined it.  In the
> literature, there are plenty of examples of redefining terminology
> to facilitate understanding and communication.  In this case, using
> "Ethernet" in this fashion reduces the "communication overhead" we
> will encounter if I replace that term with either a single term I
> make up from scratch, or a compound phrase such as "802.3, 802.11,
> 802.1Q, etc."
> 
> 	For many of us, the term Ethernet already encompasses these
> additional technologies.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[e-mail]]
> --> Sent: Wednesday, November 01, 2006 1:21 AM
> --> To: Gray, Eric
> --> Cc: [e-mail]
> --> Subject: RE: [rbridge] Comments on:
> --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
> --> -arch-01.txt
> -->
> -->
> --> Eric,
> -->
> --> I disagree.
> -->
> --> I don't think it is wise for TRILL to redefine the term Ethernet.
> --> Ethernet is a term that has a well known meaning in the industry.
> --> The original definition is:
> --> Digital Equipment Corporation, Intel, Xerox, The Ethernet,
> --> Version 2.0,
> --> November 1982.
> --> Which has been then standardized by IEEE 802.3.
> -->
> --> To speak about other IEEE 802 standards that are alive and
> --> used, IEEE
> --> 802.11 (Wireless LAN) and IEEE 802.17 (Resilient Packet
> --> Ring Working)
> --> have nothing to do with Ethernet.
> -->
> --> -- Silvano
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:[e-mail]]
> --> > Sent: Tuesday, October 31, 2006 2:44 PM
> --> > To: Silvano Gai
> --> > Cc: [e-mail]
> --> > Subject: RE: [rbridge] Comments on:
http://www.ietf.org/internet-
> --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
> --> >
> --> > Silvano,
> --> >
> --> > 	To be perfectly frank, I am unaware of any reason not to
> include
> --> > token ring or any other obsolete form of "Ethernet equivalent
> --> technology"
> --> > - this is one of the reason to focus on the SHIM as
> --> separate from any
> --> > specific encapsulation above or below the SHIM.
> --> >
> --> > 	If you want to check it against all 802 activities,
that's
> fine.
> --> > I would suggest, however, that even though people are
> --> realistically
> --> not
> --> > going to implement most of the hairy/scary versions in an
> --> RBridge, I
> --> do
> --> > not know of a good reason to exclude them at this point.
> --> In abstract,
> --> > it is certainly possible that people will be able to work out
> --> specifics
> --> > of implementation - if and when they decide to do so.
> --> >
> --> > 	After all, we (the industry) have been building
translation
> --> bridges
> --> > for these technologies for decades.
> --> >
> --> > 	However, I am open to scoping the architecture to apply
only
> to
> --> a
> --> > limited subset of 802 technologies, if that is what would
> --> make people
> --> > happy...
> --> >
> --> > --
> --> > Eric
> --> >
> --> > --> -----Original Message-----
> --> > --> From: Silvano Gai [mailto:[e-mail]]
> --> > --> Sent: Tuesday, October 31, 2006 5:34 PM
> --> > --> To: Gray, Eric
> --> > --> Cc: [e-mail]
> --> > --> Subject: RE: [rbridge] Comments on:
> --> > --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
> --> > --> -arch-01.txt
> --> > -->
> --> > -->
> --> > --> Eric,
> --> > -->
> --> > --> A quick reply:
> --> > --> Are you telling me that the term Ethernet includes Token
Ring,
> --> Token
> --> > --> Bus, DQDB?
> --> > -->
> --> > --> This is what you are doing when you say that Ethernet
> --> is IEEE 802
> --> > --> instead of IEEE 802.3.
> --> > -->
> --> > --> This is NOT a terminology issue. If the term Ethernet means
> --> > --> 802 I need
> --> > --> to check the operation of TRILL against all the 802
> --> technologies.
> --> > -->
> --> > --> -- Silvano
> --> > -->
> --> > --> > -----Original Message-----
> --> > --> > From: Gray, Eric [mailto:[e-mail]]
> --> > --> > Sent: Tuesday, October 31, 2006 1:46 PM
> --> > --> > To: Silvano Gai
> --> > --> > Cc: [e-mail]
> --> > --> > Subject: RE: [rbridge] Comments on:
> --> http://www.ietf.org/internet-
> --> > --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
> --> > --> >
> --> > --> >
> --> > --> >
> --> > --> > -- [snip] --
> --> > --> > -->
> --> > --> > --> Sgai 4> an RBridge must be also able to send
> --> two copies of a
> --> > --> > --> unicast/multicast/broadcast packet on the same
> --> port when it
> --> > --> > --> acts as a designated RBridge (one copy is
> --> encapsulated, the
> --> > --> > --> other not).
> --> > --> > -->
> --> > --> >
> --> > --> > This, I think, refers to the immediately preceding
> --> text in the
> --> > --> > architecture:
> --> > --> >
> --> > --> >         Forwarding information is derived from the
> --> combination
> --> of
> --> > --> >         attached MAC address learning, snooping of
> --> > --> multicast-related
> --> > --> >         protocols (e.g. - IGMP), and routing
> --> > --> advertisements and path
> --> > --> >         computations using the link-state routing
protocol.
> --> > --> >
> --> > --> > While your comment is a reasonable one - although
> --> potentially
> --> > --> > implementation specific - it does not appear to
> --> have any bearing
> --> > --> > on this text.
> --> > --> >
> --> > --> >
> --> > --> > -- [snip] --
> --> > --> > -->
> --> > --> > --> Sgai 5> here there is some confusion between
> --> 802 and 802.3
> --> > --> > -->
> --> > --> >
> --> > --> > This  refers (I believe) to the immeditately preceding
text:
> --> > --> >
> --> > --> >         The following terminology is defined in
> --> other documents.
> --> A
> --> > --> brief
> --> > --> >         definition is included in this section for
> --> > --> convenience and -
> --> > --> in
> --> > --> >         some cases - to remove any ambiguity in how the
> --> > --> term may be
> --> > --> used
> --> > --> >         in this document, as well as derivative documents
> --> > --> intended to
> --> > --> >         specify components, protocol, behavior and
> --> encapsulation
> --> > --> >         relative to the architecture specified in
> --> this document.
> --> > --> >
> --> > --> >         o  802: IEEE Specification for the Ethernet
> --> architecture,
> --> > --> i.e.,
> --> > --> >            including hubs and bridges.
> --> > --> >
> --> > --> > In this text, I explicitly state that these terms
> --> are defined
> --> > --> elsewhere.
> --> > --> > I am also trying to use the most generic definition
> --> of Ethernet
> --> > --> possible.
> --> > --> >
> --> > --> > The reason for this is that the problem statement does
> --> > --> not restrict
> --> > --> the
> --> > --> > solution to 802.3.
> --> > --> >
> --> > --> > There is some confusion in referring to 802.3 in
> --> any case: we
> --> > --> explicitly
> --> > --> > want to include 802.1Q - as well as all of its
> --> variations and
> --> > --> extensions.
> --> > --> >
> --> > --> > Consequently, we define the term Ethernet in the broadest
> --> possible
> --> > --> sense.
> --> > --> >
> --> > --> >
> --> > --> > -- [snip] --
> --> > --> > -->
> --> > --> > -->        o  Bridge Spanning Tree (BST): an Ethernet (L2,
> --> 802.1D)
> --> > --> > -->           forwarding protocol based on the topology
> --> > --> of a spanning
> --> > --> > tree.
> --> > --> > -->
> --> > --> > --> Sgai 6> I have never seen the acronym BST,
> --> everyone use STP.
> --> > --> > -->
> --> > --> >
> --> > --> > I do not know if this term is used in any of the other
> --> documents,
> --> > --> > but it is not used in this one.  Unless someone
> --> objects, I am
> --> only
> --> > --> > too happy to remove it from this document.
> --> > --> >
> --> > --> > From a historical perspective, this was defined this way
> --> > --> originally
> --> > --> > because we were re-using the term spanning tree instead
> --> > --> of IRT.  It
> --> > --> > was causing amazing communication difficulties, so
> --> we came up
> --> with
> --> > --> > the term IRT.  Now we don't need to differentiate BST.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 7> for Ethernet is better to reference 802.3
> --> > --> > -->
> --> > --> >
> --> > --> > See my response to your point (Sgai 5) above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Hub: an Ethernet (L2, 802) device with
> --> > --> multiple ports
> --> > --> which
> --> > --> > -->
> --> > --> > --> sgai 8> for Hub is better to reference 802.3
> --> > --> > -->
> --> > --> >
> --> > --> > See my response to your point (Sgai 5) above.  By the
> --> > --> definition we
> --> > --> > provide in this document, Ethernet is defined
> --> broadly to include
> --> > --> > 802 technologies.  This is reasonable, because the term
was
> --> stolen
> --> > --> > by IEEE from a technology stolen from a satellite
> --> communication
> --> > --> > protocol.  Ironic that 802.3 does not include wireless,
all
> --> things
> --> > --> > considered.  Certainly the term "Ethernet" should...
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Node: a device with an L2 (MAC) address
> --> > --> that sources
> --> > --> and/or
> --> > --> > -->            sinks L2 frames.
> --> > --> > -->
> --> > --> > --> Sgai 9> The IEEE term is "station".
> --> > --> > -->
> --> > --> >
> --> > --> > However, we in the IETF are more familiar with the
> --> term "node."
> --> > --> >
> --> > --> > This is hardly a significant issue.  if people agree that
> --> > --> we should
> --> > --> > use the term "station" as opposed to "node", then I will
> --> > --> change it.
> --> > --> >
> --> > --> > Note that we should be consistent in this usage, if we
> --> > --> decide to do
> --> > --> > yet another terminology evolution.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Segment: an Ethernet link, either a single
> --> physical
> --> > --> link or
> --> > --> > -->            emulation thereof (e.g., via hubs) or a
> --> > --> logical link or
> --> > --> > -->            emulation thereof (e.g., via bridges).
> --> > --> > -->
> --> > --> > --> Sgai 10> IEEE uses the term "LAN segment"
> --> > --> > -->
> --> > --> >
> --> > --> > I agree, however this is the definition we agreed on here.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Subnet, Ethernet: a single segment,
> --> or a set of
> --> > --> segments
> --> > --> > -->            interconnected by a CRED (see
> --> section 2.2); in
> --> the
> --> > --> latter
> --> > --> > -->
> --> > --> > --> sgai 11> There is no concept of subnet in IEEE.
> --> Subnet is
> --> > --> typically
> --> > --> > --> an IP subnet, and, even if it is common to have
> --> one subnet
> --> per
> --> > --> LAN,
> --> > --> > --> this is not the only possibility. Pragmatically
> --> IP subnets
> --> and
> --> > --> > --> Ethernet LAN are unrelated concepts.
> --> > --> > -->
> --> > --> >
> --> > --> > Again, we are defining this term for use in this
> --> > --> document.  Does its
> --> > --> > use (not its definition) cause confusion or ambiguity?
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->            case, the subnet may or may not be
> --> equivalent to
> --> a
> --> > --> single
> --> > --> > -->            segment. Also a subnet may be
> --> referred to as a
> --> > --> broadcast
> --> > --> > -->            domain or LAN. By definition, all
> --> nodes within an
> --> > --> Ethernet
> --> > --> > -->            Subnet (broadcast domain or LAN) must have
L2
> --> > --> connectivity
> --> > --> > -->            with all other nodes in the same
> --> Ethernet subnet.
> --> > --> > -->
> --> > --> > -->         o  TRILL: Transparent Interconnect over Lots
> --> > --> of Links -
> --> > --> the
> --> > --> > -->            working group and working name for the
> --> > --> problem domain
> --> > --> to be
> --> > --> > -->            addressed in this document.
> --> > --> > -->
> --> > --> > -->         o  Unicast Forwarding: forwarding methods
> --> > --> that apply to
> --> > --> frames
> --> > --> > -->            with unicast destination MAC addresses.
> --> > --> > -->
> --> > --> > -->         o  Unknown Destination - a destination
> --> for which a
> --> > --> receiving
> --> > --> > -->            device has no filtering database entry.
> --> > --> Destination
> --> > --> (layer
> --> > --> > -->
> --> > --> > --> sgai 12> the stations receive the unknown
> --> unicast and have
> --> > --> filtering
> --> > --> > --> information, only the bridges don't. I propose to
> --> > --> replace device
> --> > --> with
> --> > --> > --> bridge.
> --> > --> > -->
> --> > --> >
> --> > --> > Again, it is the intention to provide as broad a
> --> definition as
> --> > --> possible
> --> > --> > without introducing confusion or ambiguity.  An end node
> --> > --> (or station)
> --> > --> > has - in a sense - a filtering database (it's mine, or
> --> > --> it's for the
> --> > --> bit
> --> > --> > bucket).
> --> > --> >
> --> > --> > We need to explicitly include 802.1D forwarding devices
> --> > --> and RBridges.
> --> > --> >
> --> > --> > However, the definition should specify "forwarding
> --> device" - as
> --> > --> opposed
> --> > --> > to just "receiving device."
> --> > --> >
> --> > --> > I will change that.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->            2) addresses are typically "learned"
> --> by (layer 2)
> --> > --> > forwarding
> --> > --> > -->            devices via a process commonly referred to
> --> > --> as "bridge
> --> > --> > learning".
> --> > --> > -->
> --> > --> > --> Sgai 13> in IEEE, the term used is "learning" instead
> --> > --> of "bridge
> --> > --> > learning"
> --> > --> > -->
> --> > --> >
> --> > --> > However, the term defined in this document is
> --> "bridge learning."
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  VLAN: Virtual Local Area Network. VLANs in
> --> > --> general fall
> --> > --> > into
> --> > --> > -->            two categories: link (or port)
> --> specific VLANs and
> --> > --> tagged
> --> > --> > -->            VLANs. In the former case, all frames
> --> > --> forwarded and all
> --> > --> > -->            directly connected nodes are assumed to be
> --> > --> part of a
> --> > --> single
> --> > --> > -->            VLAN.  In the latter case, VLAN tagged
> --> > --> frames are used
> --> > --> to
> --> > --> > -->            distinguish which VLAN each frame is
intended
> --> for.
> --> > --> > -->
> --> > --> > --> Sgai 14> This definition is not completely correct, I
> --> prefer:
> --> > --> > -->
> --> > --> > --> VLAN technology introduces the following three
> --> basic types
> --> of
> --> > --> frame:
> --> > --> > --> a) Untagged frames;
> --> > --> > --> b) Priority-tagged frames; and
> --> > --> > --> c) VLAN-tagged frames.
> --> > --> > -->
> --> > --> > --> An untagged frame or a priority-tagged frame does not
> --> > --> carry any
> --> > --> > --> identification of the VLAN to which it belongs. Such
> --> > --> frames are
> --> > --> > --> classified as belonging to a particular VLAN based on
> --> > --> parameters
> --> > --> > --> associated with the receiving Port, or, through
> --> proprietary
> --> > --> extensions
> --> > --> > --> to IEEE 802.1Q standard, based on the data content of
> --> > --> the frame
> --> > --> (e.g.,
> --> > --> > --> MAC Address, layer 3 protocol ID, etc.).
> --> > --> > -->
> --> > --> > --> A VLAN-tagged frame carries an explicit
> --> > --> identification of the VLAN
> --> > --> to
> --> > --> > --> which it belongs; i.e., it carries a tag header
> --> that carries
> --> a
> --> > --> non-
> --> > --> > null
> --> > --> > --> VID. Such a frame is classified as belonging to a
> --> > --> particular VLAN
> --> > --> > based
> --> > --> > --> on the value of the VID that is included in the tag
> --> > --> header. The
> --> > --> > presence
> --> > --> > --> of the tag header carrying a non-null VID means that
> --> > --> some other
> --> > --> > device,
> --> > --> > --> either the originator of the frame or a
> --> VLAN-aware Bridge,
> --> has
> --> > --> mapped
> --> > --> > --> this frame into a VLAN and has inserted the
> --> appropriate VID.
> --> > --> > -->
> --> > --> >
> --> > --> > So, you're getting into the details of the
> --> technology and - in
> --> > --> particular
> --> > --> > the encapsulation.  I will expand the definition to
> --> include a
> --> > --> possibility
> --> > --> > that other criteria may be used to define a "VLAN port" -
> --> although
> --> > --> this is
> --> > --> > isomorphic to a logical model in which a device
> --> > --> implementation uses
> --> > --> some
> --> > --> > criteria to decide that a subset of the traffic received
> --> > --> on a specific
> --> > --> > physical port is to be forwarded as if received on a
> --> > --> specific logical
> --> > --> > port.
> --> > --> >
> --> > --> > The key point in this definition is that a VLAN is a
> --> > --> "Virtual LAN" -
> --> > --> > meaning
> --> > --> > it consists of a subset of the physical and L2
connectivity
> --> > --> corresponding
> --> > --> > to
> --> > --> > a "logical LAN."  The intent is to "rise above" the
> --> technological
> --> > --> > approaches
> --> > --> > and encapsulations to establish a generic definition that
> --> > --> is loosely
> --> > --> tied
> --> > --> > to
> --> > --> >
> --> > --> > ways that this generic definition is actually implemented.
> --> > --> >
> --> > --> > Again, bearing in mind the way that the term is
> --> defined, does
> --> the
> --> > --> usage of
> --> > --> > the term cause confusion or ambiguity?
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  CRED Forwarding Table (CFT): the per-hop
> --> forwarding
> --> > --> table
> --> > --> > -->            populated by the RBridge Routing Protocol;
> --> > --> forwarding
> --> > --> > within
> --> > --> > -->            the CRED is based on a lookup of the
> --> CRED Transit
> --> > --> Header
> --> > --> > -->            (CTH) encapsulated within the
> --> outermost received
> --> L2
> --> > --> header.
> --> > --> > -->            The outermost L2 encapsulation in this
> --> > --> case includes
> --> > --> the
> --> > --> > -->            source MAC address of the immediate
> --> > --> upstream RBridge
> --> > --> > -->            transmitting the frame and destination MAC
> --> > --> address of
> --> > --> the
> --> > --> > -->            receiving RBridge for use in the unicast
> --> forwarding
> --> > --> case.
> --> > --> > -->
> --> > --> > --> Sgai 15> In section 7 of
> --> > --> > -->
> --> > -->
> --> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-
> --> > --> > 00.txt
> --> > --> > --> we proposed that when two rbridges are
> --> connected by a point
> --> to
> --> > --> point
> --> > --> > --> link the outer MAC addresses may be set to a
> --> > --> predefined value in
> --> > --> > --> transmission and ignored in reception.
> --> > --> > -->
> --> > --> >
> --> > --> > I'm not sure how your proposal intends to determine that
> --> > --> a link is in
> --> > --> > fact point-to-point and does not just look that way.
> --> > --> >
> --> > --> > I prefer to use the same encapsulation in all cases where
it
> --> will
> --> > --> work.
> --> > --> >
> --> > --> > The optimization associated with using some form of
> --> > --> null-encapsulation
> --> > --> > is of dubious value, given that it may not be possible to
> --> > --> be certain a
> --> > --> > point-to-point link is - and will remain - in fact a
> --> > --> point-to-point
> --> > --> > link.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  CFT-IRT: a forwarding table used for
> --> propagation
> --> of
> --> > --> > -->            broadcast, multicast or flooded
> --> frames along the
> --> > --> Ingress
> --> > --> > -->            RBridge Tree (IRT).
> --> > --> > -->
> --> > --> > --> Sgai 16> is it a forwarding table or is it a
> --> > --> filtering database.
> --> > --> Since
> --> > --> > --> the "miss" behavior is to flood, I see it as a
> --> > --> filtering database.
> --> > --> > -->
> --> > --> >
> --> > --> > What state was "miss" behavior from - Hawaii?  :-)
> --> > --> >
> --> > --> > It is analogous to a filtering database entry, but it is
not
> --> that.
> --> > --> >
> --> > --> > Clearly there are more things in this world than can be
> --> classified
> --> > --> > in this taxonomy.  However, given these choices, it is a
> --> > --> forwarding
> --> > --> > table.
> --> > --> >
> --> > --> > This is not a misbehavior, in that the same "base" tree
> --> > --> is used for
> --> > --> > broadcast and multicast traffic as well as flooded
> --> > --> traffic.  It may
> --> > --> > be arguable that flooding is a misbehavior, but I
> --> seem to recall
> --> > --> > that people still see it as a necessary evil.
> --> > --> >
> --> > --> > It is also not "miss" behavior (as in "cache miss") in
> --> > --> the multicast
> --> > --> > and broadcast case, either.
> --> > --> >
> --> > --> > I believe the definition is quite correct and easy to
> --> understand,
> --> > --> > provided you're not reading it with preconceived
> --> misconceptions
> --> > --> > about its meaning.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  CRED Transit Header (CTH): a 'shim'
> --> header that
> --> > --> > encapsulates
> --> > --> > -->            the ingress L2 frame and persists
> --> throughout the
> --> > --> transit of
> --> > --> > a
> --> > --> >
> --> > --> > -->            CRED, which is further encapsulated within
> --> > --> a hop-by-hop
> --> > --> L2
> --> > --> > -->            header (and trailer). The hop-by-hop L2
> --> > --> encapsulation
> --> > --> in
> --> > --> > this
> --> > --> >
> --> > --> > -->            case includes the source MAC address of
> --> > --> the immediate
> --> > --> > -->            upstream RBridge transmitting the frame
> --> > --> and destination
> --> > --> MAC
> --> > --> > -->            address of the receiving RBridge -
> --> at least in
> --> the
> --> > --> unicast
> --> > --> > -->            forwarding case.
> --> > --> > -->
> --> > --> > --> Sgai 17> is this true also for unknown unicast?
> --> > --> > -->
> --> > --> >
> --> > --> > That is something that will be (may be already)
> --> decided in the
> --> > --> protocol
> --> > --> > specification.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  CRED Transit Table (CTT): a table that maps
> --> ingress
> --> > --> frame
> --> > --> > L2
> --> > --> > -->            destinations to egress RBridge
> --> addresses, used to
> --> > --> determine
> --> > --> > -->            encapsulation of ingress frames for
> --> transit of
> --> the
> --> > --> CRED.
> --> > --> > -->
> --> > --> > -->         o  Cooperating RBridges - those RBridges
> --> > --> within a single
> --> > --> > -->            Ethernet Subnet (broadcast domain or LAN)
> --> > --> not having
> --> > --> been
> --> > --> > -->            configured to ignore each other. By
> --> default, all
> --> > --> RBridges
> --> > --> > -->            within a single Ethernet subnet will
> --> cooperate
> --> with
> --> > --> each
> --> > --> > -->            other. It is possible for implementations
> --> > --> to allow for
> --> > --> > -->            configuration that will restrict
> --> > --> "cooperation" between
> --> > --> an
> --> > --> > -->            RBridge and an apparent neighboring
> --> RBridge.  One
> --> > --> reason
> --> > --> > why
> --> > --> > -->            this might occur is if the trust model
> --> > --> that applies in
> --> > --> a
> --> > --> > -->            particular deployment imposes a need for
> --> > --> configuration
> --> > --> of
> --> > --> > -->            security information.  By default no such
> --> > --> configuration
> --> > --> is
> --> > --> > -->            required however - should it be used in
> --> > --> any specific
> --> > --> > scenario
> --> > --> > -->
> --> > --> > -->            - it is possible (either deliberately or
> --> > --> inadvertently)
> --> > --> to
> --> > --> > -->            configure neighboring RBridges so
> --> that they do
> --> not
> --> > --> > cooperate.
> --> > --> > -->
> --> > --> > -->            In the remainder of this document,
> --> all RBridges
> --> are
> --> > --> assumed
> --> > --> > -->            to be in a cooperating (default)
> --> configuration.
> --> > --> > -->
> --> > --> > --> Sgai 18> can RBridges cooperate in groups, e.g. four
> --> Rbridges
> --> > --> > connected
> --> > --> > --> to a LAN cooperating two and two?
> --> > --> > -->
> --> > --> >
> --> > --> > Yes.  There may be reasons why this might be done
> --> deliberately,
> --> > --> however
> --> > --> > - even in the absence of any "proof of concept"
> --> > --> justification - it is
> --> > --> a
> --> > --> > really good idea to design the protocol to be robust in
> --> > --> cases where a
> --> > --> > set of RBridges may be (mis)configured in such a way as
> --> > --> to be unable
> --> > --> to
> --> > --> > discover each other.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Ingress RBridge Tree: a tree
> --> computed for each
> --> edge
> --> > --> RBridge
> --> > --> > -->            and potentially for each VLAN in which that
> --> RBridge
> --> > --> > -->
> --> > --> > --> sgai 19> why for each VLAN? I got the
> --> impression that there
> --> > --> > --> was a single tree that was pruned differently for
> --> > --> different VLANs.
> --> > --> > -->
> --> > --> >
> --> > --> > Pruning may also take place at the ingress, if - for
> --> > --> example - it has
> --> > --> a
> --> > --> > subset of interfaces that are not connected to any
> --> egress for
> --> > --> particular
> --> > --> > VLANs.  It is a small point but, in such cases, there is
in
> --> effect
> --> > --> more
> --> > --> > than one IRT even at the ingress.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->            participates - for delivery of broadcast,
> --> > --> multicast and
> --> > --> > -->            flooded frames from that RBridge to all
> --> > --> relevant egress
> --> > --> > -->            RBridges. This is the point-to-multipoint
> --> > --> delivery tree
> --> > --> > used
> --> > --> > -->            by an ingress RBridge to deliver
> --> > --> multicast, broadcast
> --> > --> or
> --> > --> > -->            flooded traffic.
> --> > --> > -->
> --> > --> > --> Sgai 20> the current version of the proposal
> --> speaks about a
> --> > --> multicast
> --> > --> > --> address, not point-to-point.
> --> > --> > -->
> --> > --> >
> --> > --> > I did not say "point-to-point" (look again).
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  LPT: Learned Port Table. See
> --> Filtering Database.
> --> > --> > -->
> --> > --> > --> Sgai 21> not proper terminology, I would use
> --> > --> "filtering database"
> --> > --> > --> everywhere.
> --> > --> > -->
> --> > --> >
> --> > --> > I am happy to remove this if there is no objection
> --> to my doing
> --> so.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 22> I wired port is Ehernet, i.e. IEEE 802.3, a
> --> > --> > --> wireless port is not Ethernet, it is IEEE 802.11.
> --> > --> > -->
> --> > --> >
> --> > --> > See my response to your point (sgai 8) above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 23> they learn because STP guarantees
> --> > --> symmetrical forwarding
> --> > --> > -->
> --> > --> >
> --> > --> > This (apparently) refers to the immeditately preceding
text:
> --> > --> >
> --> > --> >         Conventional bridges contain a learned port table
> --> > --> (LPT), or
> --> > --> >         filtering database, and a spanning tree table
> --> > --> (STT). The LPT
> --> > --> >         allows a bridge to avoid flooding all received
> --> > --> frames, as is
> --> > --> >         typical for a hub or repeater. The bridge learns
> --> > --> which nodes
> --> > --> are
> --> > --> >         accessible from a particular port by assuming
> --> > --> bi-directional
> --> > --> >         consistency:
> --> > --> >
> --> > --> > I'm not sure how picking at the peculiarities of
> --> STP behavior is
> --> > --> > relevant to this description.  STP results in a
> --> single spanning
> --> > --> > tree where each link is bi-directional.  This
> --> ensures that the
> --> > --> > MAC frames are forwarded in a bi-directionally consistent
> --> fashion.
> --> > --> >
> --> > --> > To replace this text with yours is to provide less
> --> information.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 24> active ports -> forwarding ports
> --> > --> > -->
> --> > --> >
> --> > --> > "Active ports" was the exact wording suggested to me.  In
> --> > --> context for
> --> > --> > this working group "active ports" is more meaningful than
> --> > --> "forwarding
> --> > --> > ports."  For people not used to STP-speak, "forwarding
> --> > --> port" might be
> --> > --> > used to discriminate from a "code port."
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 25> there is no STT, there is a state associated
> --> > --> with each
> --> > --> port
> --> > --> > --> that can be: disabled, blocking, listening,
> --> learning, and
> --> > --> forwarding
> --> > --> > -->
> --> > --> >
> --> > --> > Other than the issue with terminology, is this text
> --> wrong?  I am
> --> > --> fairly
> --> > --> > sure that different implementations handle the "port
state"
> --> > --> information
> --> > --> > in different ways, and I am also reasonably sure that a
> --> > --> "table" such
> --> > --> as
> --> > --> > the one described here is one of the ways it might be
done.
> --> > --> >
> --> > --> > However, I agree with your assertion that this is the way
> --> > --> that it is
> --> > --> > usually talked about in an IEEE context, so -
> --> unless there are
> --> > --> specific
> --> > --> > objections - I can change the wording to be consistent
> --> > --> with what you
> --> > --> > suggest.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 26> disabled -> blocking
> --> > --> > -->
> --> > --> >
> --> > --> > I can make this change as well.  However, from the
> --> > --> perspective of what
> --> > --> > we are trying to do, "disabled" is potentially a more
> --> > --> correct term.
> --> > --> It
> --> > --> > is certainly more intuitively correct, outside of a
> --> > --> strictly IEEE/STP
> --> > --> > context.
> --> > --> >
> --> > --> > Symmetry is maintained in STP by blocking ports/links
> --> > --> bi-directionally.
> --> > --> > In such cases, a port is effectively disabled for bridges
> --> > --> at either
> --> > --> end
> --> > --> > of the link for which a port is blocked, is it not?
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 27> I repeat a comment that I have made to other
> --> > --> documents: "
> --> > --> > --> The discussion about VLAN needs to be much more
> --> > --> extensive. It is
> --> > --> clear
> --> > --> > --> from the mailing list discussion that VLANs can be
> --> > --> used inside the
> --> > --> > --> packet or in the Ethernet encapsulation of TRILL.
> --> > --> These are two
> --> > --> > --> different kinds of VLANs and their requirement need
> --> > --> to be stated
> --> > --> > --> separately. Q in Q needs also to be discussed. I
> --> > --> propose to define
> --> > --> > inner
> --> > --> > --> and outer VLANs (with reference to the position of
> --> > --> the tag in the
> --> > --> > frame."
> --> > --> > --> Here I think we are talking about outer VLANs
> --> > --> > -->
> --> > --> >
> --> > --> > I responded to this in separate mail.  I wait to hear
> --> > --> other opinions
> --> > --> on
> --> > --> > this subject.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 28> IMO all RBridges must be ingress RBridges,
> --> > --> at least to
> --> > --> > support
> --> > --> > --> inband management, e.g. SNMP.
> --> > --> > -->
> --> > --> >
> --> > --> > No.
> --> > --> >
> --> > --> > In order to ensure symmetry with RBridges not
> --> > --> participating in STP,
> --> > --> there
> --> > --> > MUST be a designated RBridge that does all of the
> --> sending and
> --> > --> receiving
> --> > --> > of native encapsulated frames on a LAN segment.
> --> > --> >
> --> > --> > Any RBridge the loses the "Designated RBridge"
> --> election cannot
> --> be
> --> > --> either
> --> > --> > an ingress or an egress for that LAN segment.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 29> same as above
> --> > --> > -->
> --> > --> >
> --> > --> > Same as above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 30> I think the previous definition is not
needed.
> --> > --> > -->
> --> > --> >
> --> > --> > This appears to refer to:
> --> > --> >
> --> > --> >         o  Local RBridge - the RBridge that forms and
> --> > --> maintains the
> --> > --> CFT-
> --> > --> >            IRT entry (or entries) under discussion. The
> --> > --> local RBridge
> --> > --> >            may be an Ingress RBridge, or an egress
> --> RBridge with
> --> > --> respect
> --> > --> >            to any set of entries in the CFT-IRT.
> --> > --> >
> --> > --> > This defintion is needed.  It is subsequently used
> --> in at least 4
> --> > --> places.
> --> > --> > When discussing the behavior of a specific RBridge
> --> > --> relative to a peer,
> --> > --> > it is convenient to define the term "local RBridge."
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 31> why is it zero or more, if an RBridge
> --> exists, it
> --> must
> --> > --> have
> --> > --> > --> a an IRT, I haven't seen any discussion to support
> --> > --> multiple IRTs.
> --> > --> > -->
> --> > --> >
> --> > --> > This was answered previously on the mailing list.
> --> > --> Briefly, zero or
> --> > --> > more is correct, given that an RBridge may not have
> --> > --> forwarding entries
> --> > --> > for frames it has received.  In these cases, a frame is
> --> > --> not forwarded.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 32> I don't understand this. Since the current
> --> > --> proposal uses
> --> > --> a
> --> > --> > --> multicast MAC address, what is needed is a bit map
> --> > --> for each IRT
> --> > --> that
> --> > --> > --> says which ports are blocking and which are
> --> > --> forwarding. You are
> --> > --> > --> basically building a ST using ISIS.
> --> > --> > -->
> --> > --> >
> --> > --> > This might be the case for a specific implementation.
> --> > --> Whether it is
> --> > --> > implemented as a "bit-mask" with "non-blocking"
> --> > --> (forwarding) ports, or
> --> > --> > is implemented as a full-blown table is largely dependent
on
> --> what
> --> > --> other
> --> > --> > information the local device requires in order to
> --> > --> properly forwad the
> --> > --> > frame.  If - for example - a device has multiple
> --> > --> different port types,
> --> > --> > it may need to have more information for each port (or
that
> --> > --> information
> --> > --> > may be added later on).
> --> > --> >
> --> > --> > All of these are implementation choices that are
> --> > --> logically represented
> --> > --> > by the table described here.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 33> I don't get the pair.
> --> > --> > -->
> --> > --> >
> --> > --> > Since this immediately follows:
> --> > --> >
> --> > --> >         Each entry would contain an indication of
> --> which single
> --> > --> interface
> --> > --> >         a broadcast, multicast or flooded frame would be
> --> > --> forwarded for
> --> > --> >         each (ingress RBridge, egress RBridge) pair.
> --> > --> >
> --> > --> > I don't get what you don't get.
> --> > --> >
> --> > --> > The pair refers to the tuple "(ingress RBridge, egress
> --> RBridge)."
> --> > --> >
> --> > --> > This might be the point at which your earlier point (Sgai
4)
> --> would
> --> > --> make
> --> > --> > sense to insert.  I had logically modeled this in my own
> --> > --> mind as two
> --> > --> > distinct "interfaces" (the reason I use this term, rather
> --> > --> thhan port),
> --> > --> > but I should clarify this.
> --> > --> >
> --> > --> > In any case, the entries are keyed by both ingress and
> --> > --> egress RBridge.
> --> > --> > While there will be entries for only those egress
> --> > --> RBridges where this
> --> > --> > local RBridge is on the shortest path (between the given
> --> > --> ingress and
> --> > --> > egress pair), there will be at most one entry per
> --> any ingress
> --> and
> --> > --> > egress pair.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 34> as a matter of fact each interface is
> --> > --> basically a set of
> --> > --> two
> --> > --> > --> interfaces, a regular one and a tunnel one, and the
> --> > --> > forwarding/blocking
> --> > --> > --> state may be different for the two.
> --> > --> > -->
> --> > --> >
> --> > --> > No.
> --> > --> >
> --> > --> > As per my response to your point (Sgai 28) above, not
> --> > --> every RBridge
> --> > --> has a
> --> > --> > "regular one" as you describe here.
> --> > --> >
> --> > --> > The forwarding/blocking state is not applicable as
> --> > --> RBridges don't do
> --> > --> STP.
> --> > --> >
> --> > --> > For the native interface, fowarding/blocking state is
> --> > --> analogous to the
> --> > --> > "Designated RBridge" election process.
> --> > --> >
> --> > --> > Since this point evidently applies to -
> --> > --> >
> --> > --> >
Entries
> --> would
> --> > --> also
> --> > --> >         contain any required encapsulation information,
> --> > --> etc. required
> --> > --> >         for forwarding on a given interface, and toward a
> --> > --> corresponding
> --> > --> >         specific egress RBridge.
> --> > --> >
> --> > --> > - your point, and my response, are related to the point
> --> > --> (and response)
> --> > --> > above (Sgai 33), and I will try to clarify this
> --> part as well.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 35> this protocol must be designed to avoid
> --> > --> transient loops,
> --> > --> > since
> --> > --> > --> transient loops of multicast/broadcast cause
> --> > --> broadcast storm that
> --> > --> are
> --> > --> > --> highly undesirable.
> --> > --> > -->
> --> > --> >
> --> > --> > No.
> --> > --> >
> --> > --> > The protocol needs to include a provision to prevent
> --> > --> _use_ of links
> --> > --> that
> --> > --> > may connect to transient loops.  Using a link-state
> --> > --> routing protocol
> --> > --> has
> --> > --> > clearly been demostrated to produce transient loops, but
> --> > --> the problem
> --> > --> you
> --> > --> > want to address has to do with using those links.
> --> > --> >
> --> > --> > A state-machine driven mechanism similar to STP might be
> --> > --> the approach
> --> > --> to
> --> > --> > use.
> --> > --> >
> --> > --> > Because we're incorporating TTL in the SHIM, however this
> --> > --> would need
> --> > --> to
> --> > --> > apply only to IRT traffic.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->
> --> > --> > --> Sgai 36> see my previous comment about VLANs
> --> > --> > -->
> --> > --> >
> --> > --> > See my previous responses.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 37> disabled -> blocking.
> --> > --> > -->
> --> > --> >
> --> > --> > See my response to your point (sgai 26) above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 38> for multicast/broadcast we also need to
> --> > --> avoid transient
> --> > --> > loops.
> --> > --> > -->
> --> > --> >
> --> > --> > Yes.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 39> but RBridge discovery and STP are ongoing
> --> > --> processes, why
> --> > --> do
> --> > --> > we
> --> > --> > --> want to couple their timers?
> --> > --> > -->
> --> > --> >
> --> > --> > I am not suggesting "coupling their timers."  I am
> --> saying that
> --> the
> --> > --> value
> --> > --> > chosen for a timer (if one is used) to determine when it
> --> > --> is reasonable
> --> > --> to
> --> > --> > start RBridge peer discovery should take into
> --> account the time
> --> it
> --> > --> takes
> --> > --> > for the local spanning tree resolution.
> --> > --> >
> --> > --> > I feel the reason for this is self-evident but, just to
> --> > --> clarify, think
> --> > --> > about the process we're planning to use to determine
RBridge
> --> > --> nick-names.
> --> > --> > If we start this too early, we will be re-starting it
> --> > --> many times as we
> --> > --> > "hear from" new RBridge peers when the connecting links go
> --> active
> --> > --> after
> --> > --> > local bridges go to the forwarding state.  This would
> --> > --> apply only at
> --> > --> the
> --> > --> > system start up as - after that - you are quite correct
> --> > --> in asserting
> --> > --> it
> --> > --> > would be an ongoing process.
> --> > --> >
> --> > --> > Perhaps I should add some words to indicate that a delay
> --> > --> would not be
> --> > --> > necessary if the protocol mechanisms do not introduce
> --> > --> instability as a
> --> > --> > new peer is discovered.  So far, I have not seen any
> --> > --> indication that a
> --> > --> > "race-free" solution to accomplish this has been designed
> --> > --> - or talked
> --> > --> > about.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 40> there is also a requirement to time-out
learnt
> --> > --> information to
> --> > --> > --> maintain the filtering databases.
> --> > --> > -->
> --> > --> >
> --> > --> > There would be, if we were doing that.  Instead,
> --> we're adopting
> --> a
> --> > --> > link-state routing protocol and they tend to have
> --> that covered.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 41> periodically or on demand
> --> > --> > -->
> --> > --> >
> --> > --> > See the response to your point (Sgai 40) above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 42> potentially there is an unencapsulated
> --> > --> interface for each
> --> > --> > --> physical interface of the RBridge. It is true that
> --> > --> you can model
> --> > --> all
> --> > --> > --> of them as a single separate logical interface, but
> --> > --> then we need
> --> > --> to
> --> > --> > --> replicate the frame according to a bitmask that tells
on
> --> which
> --> > --> > physical
> --> > --> > --> interface the RBridge is designated.
> --> > --> > -->
> --> > --> >
> --> > --> > Again, your use of a "bitmask" is an implementation
> --> > --> choice as opposed
> --> > --> > to a logical model.
> --> > --> >
> --> > --> > As you observe, I do "model all of them as a single
> --> > --> separate logical
> --> > --> > interface" and if you want to "replicate the frame
> --> according to
> --> a
> --> > --> > bitmask that tells on which physical interface the
> --> RBridge is
> --> > --> > designated" - you're absolutely free to do so.
> --> > --> >
> --> > --> > Personally, I think this is far too much implementation
> --> > --> stuff for a
> --> > --> > protocol specification, let alone an architecture
document.
> --> > --> >
> --> > --> > -->
> --> > --> > --> Sgai 43> can we clarify that this means "drop BPDUs".
> --> > --> > -->
> --> > --> >
> --> > --> > Yes.
> --> > --> >
> --> > --> > -- [snip --
> --> > -->
> -->



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1GmVfl020309 for <[e-mail]>; Wed, 1 Nov 2006 08:48:31 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1GmSfK028902; Wed, 1 Nov 2006 11:48:29 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25712;  Wed, 1 Nov 2006 11:48:29 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647R99>; Wed, 1 Nov 2006 11:48:28 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Russ White <[e-mail]>, "Gray, Eric" <[e-mail]>
Date: Wed, 1 Nov 2006 11:48:28 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Comments on:	http://www.ietf.org/internet-drafts/dr	 aft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 16:49:02 -0000
Status: RO
Content-Length: 1739

Russ,

	I agree completely.

--
Eric 

--> -----Original Message-----
--> From: Russ White [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 11:27 AM
--> To: Gray, Eric
--> Cc: Silvano Gai; [e-mail]
--> Subject: Re: [rbridge] Comments on: 
--> http://www.ietf.org/internet-drafts/dr 
--> aft-ietf-trill-rbridge-arch-01.txt
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> > 	The notion of using a L2 version of ECMP is - IMO - in no way
--> > implied
--> > by the text in the charter.  Nor is there any explicit 
--> intention to preclude
--> > this type of activity - with the caveat that anyone doing 
--> so has to assume
--> > responsibility for not "breaking" the interoperability model.
--> 
--> And this is as it should be, IMHO. If you know, for 
--> certain, that your
--> entire network is made up of rbridges, rather than a 
--> mixture of various
--> types of bridging devices, then you could use L2 ECMP. If you don't,
--> then you (probably) can't.
--> 
--> I think this decision is in the hands of network operators and
--> implementors, though, not in the hands of the spec writers. 
--> If we say:
--> "X is dangerous in specific situation Y, therefore we will 
--> never allow
--> X," then we are shutting down possible avenues for 
--> growth--such as the
--> stuff we're talking about with F-Tags.
--> 
--> :-)
--> 
--> Russ
--> 
--> - --
--> [e-mail] CCIE <>< Grace Alone
--> 
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.4.2.2 (MingW32)
--> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--> 
--> iD8DBQFFSMq2ER27sUhU9OQRAkrFAJ0cDSgqRhSi5zT6SvbCOO0z4PUCcQCfQJ3l
--> 8omzi9hZhNEBFvKNWeYo1kQ=
--> =eRrz
--> -----END PGP SIGNATURE-----
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1GmATw020039 for <[e-mail]>; Wed, 1 Nov 2006 08:48:10 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1Gm6fK028892; Wed, 1 Nov 2006 11:48:06 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25680;  Wed, 1 Nov 2006 11:48:06 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647R9T>; Wed, 1 Nov 2006 11:48:05 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Russ White <[e-mail]>, "Gray, Eric" <[e-mail]>
Date: Wed, 1 Nov 2006 11:48:04 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Comments on:	http://www.ietf.org/internet-drafts/dr	 aft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 16:49:02 -0000
Status: RO
Content-Length: 1406

Russ,

	I will add the "demux text" to the definition of Node... 

--
Eric

--> -----Original Message-----
--> From: Russ White [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 11:23 AM
--> To: Gray, Eric
--> Cc: Silvano Gai; [e-mail]
--> Subject: Re: [rbridge] Comments on: 
--> http://www.ietf.org/internet-drafts/dr 
--> aft-ietf-trill-rbridge-arch-01.txt
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> > However, we in the IETF are more familiar with the term "node." 
--> > 
--> > This is hardly a significant issue.  if people agree that 
--> we should
--> > use the term "station" as opposed to "node", then I will 
--> change it.
--> 
--> I prefer node, since that's the common IETF wording, and 
--> one that people
--> will understand. It also relates to graph theory better 
--> than "station"
--> does. It might be useful to note this relationship in the 
--> definitions
--> someplace or another, but I don't see a reason to change 
--> the entire doc
--> around.
--> 
--> :-)
--> 
--> Russ
--> 
--> - --
--> [e-mail] CCIE <>< Grace Alone
--> 
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.4.2.2 (MingW32)
--> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--> 
--> iD8DBQFFSMnJER27sUhU9OQRAmEsAKDexb89IG4s4VVEdYcZ6v+mEhlcZACfUYDT
--> cw3YUKtBBTa3FI0BTaVM18o=
--> =AghD
--> -----END PGP SIGNATURE-----
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1GkPgP019270 for <[e-mail]>; Wed, 1 Nov 2006 08:46:25 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1GkOfK028812; Wed, 1 Nov 2006 11:46:24 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25378;  Wed, 1 Nov 2006 11:46:24 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647R7V>; Wed, 1 Nov 2006 11:46:23 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>
Date: Wed, 1 Nov 2006 11:46:22 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] VLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 16:47:15 -0000
Status: RO
Content-Length: 9373

Silvano,

	VLAN tag-stacking is something that is done already.  It
requires no special explanation from me, as the way it is done 
is completely orthogonal to anything we are doing here in the
IETF.  That includes anything we are doing here in the TRILL WG.

	However, in the interest of trying not to be too opaque,
ask yourself what it would mean if the "Ethertype" in the 802.1Q
encaspulation indicates that it is followed by an 802.1Q frame.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 11:23 AM
--> To: Gray, Eric
--> Cc: [e-mail]
--> Subject: RE: [rbridge] VLANs
--> 
--> Eric,
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[e-mail]]
--> > Sent: Wednesday, November 01, 2006 8:07 AM
--> > To: Silvano Gai
--> > Cc: [e-mail]
--> > Subject: RE: [rbridge] VLANs
--> > 
--> > Silvano,
--> > 
--> > 	I believe I've stated my position on using the IVLAN/OVLAN
--> > terminology, but just in case - I don't think it's necessary and
--> > I don't think it helps.
--> 
--> I think it does.
--> 
--> > 
--> > 	It seems to me that the description you provide below is an
--> > ample demonstration of the confusion that the use of these terms
--> > can introduce.
--> 
--> No, it is a demonstration of the confusion that not 
--> introducing these
--> terms creates.
--> 
--> > 
--> > 	For example, let's really complicate your example by using
--> > stacked VLAN tagging both in the tunnel encapsulation and in the
--> > native encapsulation for portions of the assumed domain. 
--> 
--> You have already mentioned this stacking and other magic that TRILL
--> plans to do with VLANs, but you have never provided a consistent
--> explanation. Is this part of TRILL or not?
--> 
--> Is TRILL defined to be mapped on a single OVLAN or on multiple? 
--> Is this written in any draft?
--> 
--> Can you explain this clearly?
--> 
--> Thank You
--> 
--> -- Silvano
--> 
-->  In the
--> > (deliberately) complicated model I've just described, what does
--> > the IVLAN/OVLAN distinction mean?
--> > 
--> > 	In fact, one reason not to distinguish the two is that - in
--> > the text you're referring to - the impact of which it is that may
--> > apply is nil.  Hence by not making a distinction, we're allowed a
--> > certain economy in communicating.
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: Silvano Gai [mailto:[e-mail]]
--> > --> Sent: Wednesday, November 01, 2006 12:55 AM
--> > --> To: Gray, Eric
--> > --> Cc: [e-mail]
--> > --> Subject: RE: [rbridge] VLANs
--> > -->
--> > -->
--> > --> Eric,
--> > -->
--> > --> I disagree and let me give you concrete examples why:
--> > -->
--> > --> draft-ietf-trill-rbridge-protocol-00.txt says:
--> > -->
--> > --> "each RBridge R1
--> > -->    will run a "core" instance of IS-IS for the core RBridge
--> > --> information,
--> > -->
--> > -->    and an instance per VLAN that R1 is attached to, for the
--> endnode
--> > -->    information for those VLANs."
--> > -->
--> > --> If we are speaking of OVLAN, IMO an RBridge runs a 
--> core instance
--> per
--> > --> each OVLAN and on that instance it propagates the endnode
--> > --> information
--> > --> for the IVLANs."
--> > -->
--> > --> " The endnode information for VLAN A, which is carried in
--> > --> the VLAN A
--> > -->    IS-IS instance injected by R1, contains:"
--> > -->
--> > --> This clearly refers to IVLAN.
--> > -->
--> > --> draft-ietf-trill-prob-01.txt says:
--> > -->
--> > --> It may alternately support
--> > -->    direct VLAN support, e.g., by the use of separate 
--> TRILL routing
--> > -->    protocol instances to separate traffic for each VLAN
--> > --> traversing a
--> > -->    TRILL solution.
--> > -->
--> > --> Is this an IVLAN or an OVLAN?
--> > -->
--> > -->
--> > --> draft-ietf-trill-rbridge-arch-01.txt says
--> > -->
--> > --> Ingress RBridge Tree: a tree computed for each edge RBridge -
--> > -->            and potentially for each VLAN in which that RBridge
--> > -->            participates
--> > -->
--> > --> I assume this is an OVLAN, I don't think TRILL computes an
--> > --> IRT for each
--> > --> IVLAN; it can prune an IRT for each VLAN.
--> > -->
--> > --> In an email to Dinesh you wrote:
--> > -->
--> > --> "Dinesh,
--> > -->
--> > --> 	We're making semantic distinctions here.  I can 
--> easily define a
--> > --> VLAN consisting of a group of RBridges that corresponds to the
--> same
--> > --> semantics as the FTAG.  "
--> > -->
--> > --> Were you referring to an IVLAN or an OVLAN?
--> > -->
--> > --> Also you claim that 16 bits are not sufficient for 
--> the RBridge ID.
--> > --> Is the RBridge ID space replicated per each OVLAN or 
--> is it shared?
--> > --> Does an RBridge have the same RBridge ID on all OVLANs?
--> > -->
--> > --> I think we need to explicitly introduce the IVLAN and OVLAN
--> > --> concepts and
--> > --> use them consistently. We don't want to hide complexity due
--> > --> to the lack
--> > --> of nomenclature.
--> > -->
--> > --> -- Silvano
--> > -->
--> > -->
--> > -->
--> > -->
--> > -->
--> > -->
--> > -->
--> > --> > -----Original Message-----
--> > --> > From: Gray, Eric [mailto:[e-mail]]
--> > --> > Sent: Tuesday, October 31, 2006 9:04 AM
--> > --> > To: Silvano Gai
--> > --> > Cc: [e-mail]
--> > --> > Subject: RE: [rbridge] VLANs
--> > --> >
--> > --> > Silvano,
--> > --> >
--> > --> > 	Actually, both "types" of VLANs are the same - applying
--> at
--> > --> > different layers, but defined using the same terminology.
--> Logic,
--> > --> > semantics and applicability are the same.
--> > --> >
--> > --> > 	For historic reasons, we are trying to avoid the terms
--> you
--> > --> > propose.  In fact, similar terms have been used 
--> previously and
--> > --> > removed as confusing.  Without constant reminders, 
--> "inner" and
--> > --> > "outer" will be taken in some instances as placement in the
--> frame
--> > --> > (as you are suggesting) or position relative to the CRED (a
--> usage
--> > --> > issue with the terms "ingress" and "egress" meaning 
--> "way in" and
--> > --> > "way out" respectively).
--> > --> >
--> > --> > 	Hence you are suggesting replacement with one potential
--> > --> > are of confusion with another one we've earlier discarded.
--> > --> >
--> > --> > 	The architecture document defines the term VLAN and - I
--> am
--> > --> > reasonably sure - uses that definition 
--> consistently.  Moreover,
--> > --> > the architecture document tries to be agnostic 
--> about the use of
--> > --> > VLANs - particularly with respect to VLAN tagged 
--> encapsulation
--> > --> > and port-based VLANs, and where these things might 
--> apply.  The
--> > --> > reason for this is simply that one aim of protocol 
--> development -
--> > --> > especially at the architectural level - should be to avoid
--> placing
--> > --> > constraints on implementation beyond those 
--> explicitly required
--> > --> > to ensure interoperability.
--> > --> >
--> > --> > --
--> > --> > Eric
--> > --> >
--> > --> > --> -----Original Message-----
--> > --> > --> From: [e-mail]
--> > --> > --> [mailto:[e-mail]] On Behalf 
--> Of Silvano Gai
--> > --> > --> Sent: Monday, October 30, 2006 12:29 PM
--> > --> > --> To: [e-mail]
--> > --> > --> Subject: [rbridge] VLANs
--> > --> > -->
--> > --> > -->
--> > --> > --> The second biggest issue I have with the four documents
--> > --> > --> (first one being
--> > --> > --> broadcast/multicast storm) is the definition of VLANs.
--> > --> > -->
--> > --> > --> I don't think the term VLAN is used consistently in
--> > --> the documents.
--> > --> > -->
--> > --> > --> 1) Sometimes VLAN refers to the VLANs present on the
--> > --> > --> untagged frames,
--> > --> > --> which must be propagated by ISIS, VLAN pruning must be
--> > --> > --> performed and so
--> > --> > --> on. They all share the same core instance of ISIS.
--> > --> > -->
--> > --> > --> 2) Sometimes VLANs refers to the fact that a CRED can be
--> > --> > --> encapsulated
--> > --> > --> into a VLAN (present as a 1Q tag in the outer 
--> header) and
--> > --> > --> therefore ISIS
--> > --> > --> will run per VLAN, i.e. there will be a core instance of
--> > --> > --> ISIS per each
--> > --> > --> VLAN. This seems to be the case in some part of the
--> > --> architectural
--> > --> > --> document.
--> > --> > -->
--> > --> > --> I propose to name the former IVLAN (inner VLAN) and the
--> latter
--> > --> OVLAN
--> > --> > --> (Outer VLAN), with reference to the position of 
--> the 1Q tag
--> > --> > --> in the frame.
--> > --> > -->
--> > --> > --> This is also very relevant for the discussion 
--> that we need
--> > --> > --> to complete
--> > --> > --> on the FTAG: it is my understanding that some 
--> folks think
--> > --> > --> that the FTAG
--> > --> > --> is not needed, since there may be an OVLAN.
--> > --> > -->
--> > --> > --> Comments?
--> > --> > -->
--> > --> > --> -- Silvano
--> > --> > -->
--> > --> > --> _______________________________________________
--> > --> > --> rbridge mailing list
--> > --> > --> [e-mail]
--> > --> > --> http://mailman.postel.org/mailman/listinfo/rbridge
--> > --> > -->
--> > -->
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1Gcdd0015761 for <[e-mail]>; Wed, 1 Nov 2006 08:38:39 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1GcbfK028665; Wed, 1 Nov 2006 11:38:37 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24832;  Wed, 1 Nov 2006 11:38:37 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647RXJ>; Wed, 1 Nov 2006 11:38:36 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>
Date: Wed, 1 Nov 2006 11:38:33 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr	aft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 16:39:45 -0000
Status: RO
Content-Length: 42808

Silvano,

	History is not particularly relevant, but the term "Ethernet"
was originally coined by its inventor, Bob Metcalfe (who - by the 
way - did not work for DEC, but worked instead for Xerox at PARC). 

	The Ethernet standard was subsequently developed as a joint 
effort involving DEC, Intel and Xerox.

	By stating that - when I use the term "Ethernet" - I mean to
include all LAN technologies under IEEE 802, I'm merely introducing 
a short-hand terminology.  In that sense, I am not re-defining the
term, I am merely saying what I mean when I say "Ethernet."  If you
read the text, you should see that I clearly state the intention to
define the terminology the way that it will be used in the document.

	I believe that is an appropriate technique, in this case.  I 
also regard this part of the "feedback" as "stylistic" since you are
objecting to my using a term in the way that I defined it.  In the
literature, there are plenty of examples of redefining terminology 
to facilitate understanding and communication.  In this case, using
"Ethernet" in this fashion reduces the "communication overhead" we
will encounter if I replace that term with either a single term I 
make up from scratch, or a compound phrase such as "802.3, 802.11, 
802.1Q, etc."

	For many of us, the term Ethernet already encompasses these
additional technologies.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 1:21 AM
--> To: Gray, Eric
--> Cc: [e-mail]
--> Subject: RE: [rbridge] Comments on: 
--> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> -arch-01.txt
--> 
--> 
--> Eric,
--> 
--> I disagree.
--> 
--> I don't think it is wise for TRILL to redefine the term Ethernet.
--> Ethernet is a term that has a well known meaning in the industry.
--> The original definition is:
--> Digital Equipment Corporation, Intel, Xerox, The Ethernet, 
--> Version 2.0,
--> November 1982.
--> Which has been then standardized by IEEE 802.3.
--> 
--> To speak about other IEEE 802 standards that are alive and 
--> used, IEEE
--> 802.11 (Wireless LAN) and IEEE 802.17 (Resilient Packet 
--> Ring Working)
--> have nothing to do with Ethernet.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[e-mail]]
--> > Sent: Tuesday, October 31, 2006 2:44 PM
--> > To: Silvano Gai
--> > Cc: [e-mail]
--> > Subject: RE: [rbridge] Comments on: http://www.ietf.org/internet-
--> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > 
--> > Silvano,
--> > 
--> > 	To be perfectly frank, I am unaware of any reason not to include
--> > token ring or any other obsolete form of "Ethernet equivalent
--> technology"
--> > - this is one of the reason to focus on the SHIM as 
--> separate from any
--> > specific encapsulation above or below the SHIM.
--> > 
--> > 	If you want to check it against all 802 activities, that's fine.
--> > I would suggest, however, that even though people are 
--> realistically
--> not
--> > going to implement most of the hairy/scary versions in an 
--> RBridge, I
--> do
--> > not know of a good reason to exclude them at this point.  
--> In abstract,
--> > it is certainly possible that people will be able to work out
--> specifics
--> > of implementation - if and when they decide to do so.
--> > 
--> > 	After all, we (the industry) have been building translation
--> bridges
--> > for these technologies for decades.
--> > 
--> > 	However, I am open to scoping the architecture to apply only to
--> a
--> > limited subset of 802 technologies, if that is what would 
--> make people
--> > happy...
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: Silvano Gai [mailto:[e-mail]]
--> > --> Sent: Tuesday, October 31, 2006 5:34 PM
--> > --> To: Gray, Eric
--> > --> Cc: [e-mail]
--> > --> Subject: RE: [rbridge] Comments on:
--> > --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> > --> -arch-01.txt
--> > -->
--> > -->
--> > --> Eric,
--> > -->
--> > --> A quick reply:
--> > --> Are you telling me that the term Ethernet includes Token Ring,
--> Token
--> > --> Bus, DQDB?
--> > -->
--> > --> This is what you are doing when you say that Ethernet 
--> is IEEE 802
--> > --> instead of IEEE 802.3.
--> > -->
--> > --> This is NOT a terminology issue. If the term Ethernet means
--> > --> 802 I need
--> > --> to check the operation of TRILL against all the 802 
--> technologies.
--> > -->
--> > --> -- Silvano
--> > -->
--> > --> > -----Original Message-----
--> > --> > From: Gray, Eric [mailto:[e-mail]]
--> > --> > Sent: Tuesday, October 31, 2006 1:46 PM
--> > --> > To: Silvano Gai
--> > --> > Cc: [e-mail]
--> > --> > Subject: RE: [rbridge] Comments on:
--> http://www.ietf.org/internet-
--> > --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > --> >
--> > --> >
--> > --> >
--> > --> > -- [snip] --
--> > --> > -->
--> > --> > --> Sgai 4> an RBridge must be also able to send 
--> two copies of a
--> > --> > --> unicast/multicast/broadcast packet on the same 
--> port when it
--> > --> > --> acts as a designated RBridge (one copy is 
--> encapsulated, the
--> > --> > --> other not).
--> > --> > -->
--> > --> >
--> > --> > This, I think, refers to the immediately preceding 
--> text in the
--> > --> > architecture:
--> > --> >
--> > --> >         Forwarding information is derived from the 
--> combination
--> of
--> > --> >         attached MAC address learning, snooping of
--> > --> multicast-related
--> > --> >         protocols (e.g. - IGMP), and routing
--> > --> advertisements and path
--> > --> >         computations using the link-state routing protocol.
--> > --> >
--> > --> > While your comment is a reasonable one - although 
--> potentially
--> > --> > implementation specific - it does not appear to 
--> have any bearing
--> > --> > on this text.
--> > --> >
--> > --> >
--> > --> > -- [snip] --
--> > --> > -->
--> > --> > --> Sgai 5> here there is some confusion between 
--> 802 and 802.3
--> > --> > -->
--> > --> >
--> > --> > This  refers (I believe) to the immeditately preceding text:
--> > --> >
--> > --> >         The following terminology is defined in 
--> other documents.
--> A
--> > --> brief
--> > --> >         definition is included in this section for
--> > --> convenience and -
--> > --> in
--> > --> >         some cases - to remove any ambiguity in how the
--> > --> term may be
--> > --> used
--> > --> >         in this document, as well as derivative documents
--> > --> intended to
--> > --> >         specify components, protocol, behavior and 
--> encapsulation
--> > --> >         relative to the architecture specified in 
--> this document.
--> > --> >
--> > --> >         o  802: IEEE Specification for the Ethernet
--> architecture,
--> > --> i.e.,
--> > --> >            including hubs and bridges.
--> > --> >
--> > --> > In this text, I explicitly state that these terms 
--> are defined
--> > --> elsewhere.
--> > --> > I am also trying to use the most generic definition 
--> of Ethernet
--> > --> possible.
--> > --> >
--> > --> > The reason for this is that the problem statement does
--> > --> not restrict
--> > --> the
--> > --> > solution to 802.3.
--> > --> >
--> > --> > There is some confusion in referring to 802.3 in 
--> any case: we
--> > --> explicitly
--> > --> > want to include 802.1Q - as well as all of its 
--> variations and
--> > --> extensions.
--> > --> >
--> > --> > Consequently, we define the term Ethernet in the broadest
--> possible
--> > --> sense.
--> > --> >
--> > --> >
--> > --> > -- [snip] --
--> > --> > -->
--> > --> > -->        o  Bridge Spanning Tree (BST): an Ethernet (L2,
--> 802.1D)
--> > --> > -->           forwarding protocol based on the topology
--> > --> of a spanning
--> > --> > tree.
--> > --> > -->
--> > --> > --> Sgai 6> I have never seen the acronym BST, 
--> everyone use STP.
--> > --> > -->
--> > --> >
--> > --> > I do not know if this term is used in any of the other
--> documents,
--> > --> > but it is not used in this one.  Unless someone 
--> objects, I am
--> only
--> > --> > too happy to remove it from this document.
--> > --> >
--> > --> > From a historical perspective, this was defined this way
--> > --> originally
--> > --> > because we were re-using the term spanning tree instead
--> > --> of IRT.  It
--> > --> > was causing amazing communication difficulties, so 
--> we came up
--> with
--> > --> > the term IRT.  Now we don't need to differentiate BST.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 7> for Ethernet is better to reference 802.3
--> > --> > -->
--> > --> >
--> > --> > See my response to your point (Sgai 5) above.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  Hub: an Ethernet (L2, 802) device with
--> > --> multiple ports
--> > --> which
--> > --> > -->
--> > --> > --> sgai 8> for Hub is better to reference 802.3
--> > --> > -->
--> > --> >
--> > --> > See my response to your point (Sgai 5) above.  By the
--> > --> definition we
--> > --> > provide in this document, Ethernet is defined 
--> broadly to include
--> > --> > 802 technologies.  This is reasonable, because the term was
--> stolen
--> > --> > by IEEE from a technology stolen from a satellite 
--> communication
--> > --> > protocol.  Ironic that 802.3 does not include wireless, all
--> things
--> > --> > considered.  Certainly the term "Ethernet" should...
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  Node: a device with an L2 (MAC) address
--> > --> that sources
--> > --> and/or
--> > --> > -->            sinks L2 frames.
--> > --> > -->
--> > --> > --> Sgai 9> The IEEE term is "station".
--> > --> > -->
--> > --> >
--> > --> > However, we in the IETF are more familiar with the 
--> term "node."
--> > --> >
--> > --> > This is hardly a significant issue.  if people agree that
--> > --> we should
--> > --> > use the term "station" as opposed to "node", then I will
--> > --> change it.
--> > --> >
--> > --> > Note that we should be consistent in this usage, if we
--> > --> decide to do
--> > --> > yet another terminology evolution.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  Segment: an Ethernet link, either a single
--> physical
--> > --> link or
--> > --> > -->            emulation thereof (e.g., via hubs) or a
--> > --> logical link or
--> > --> > -->            emulation thereof (e.g., via bridges).
--> > --> > -->
--> > --> > --> Sgai 10> IEEE uses the term "LAN segment"
--> > --> > -->
--> > --> >
--> > --> > I agree, however this is the definition we agreed on here.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  Subnet, Ethernet: a single segment, 
--> or a set of
--> > --> segments
--> > --> > -->            interconnected by a CRED (see 
--> section 2.2); in
--> the
--> > --> latter
--> > --> > -->
--> > --> > --> sgai 11> There is no concept of subnet in IEEE. 
--> Subnet is
--> > --> typically
--> > --> > --> an IP subnet, and, even if it is common to have 
--> one subnet
--> per
--> > --> LAN,
--> > --> > --> this is not the only possibility. Pragmatically 
--> IP subnets
--> and
--> > --> > --> Ethernet LAN are unrelated concepts.
--> > --> > -->
--> > --> >
--> > --> > Again, we are defining this term for use in this
--> > --> document.  Does its
--> > --> > use (not its definition) cause confusion or ambiguity?
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->            case, the subnet may or may not be 
--> equivalent to
--> a
--> > --> single
--> > --> > -->            segment. Also a subnet may be 
--> referred to as a
--> > --> broadcast
--> > --> > -->            domain or LAN. By definition, all 
--> nodes within an
--> > --> Ethernet
--> > --> > -->            Subnet (broadcast domain or LAN) must have L2
--> > --> connectivity
--> > --> > -->            with all other nodes in the same 
--> Ethernet subnet.
--> > --> > -->
--> > --> > -->         o  TRILL: Transparent Interconnect over Lots
--> > --> of Links -
--> > --> the
--> > --> > -->            working group and working name for the
--> > --> problem domain
--> > --> to be
--> > --> > -->            addressed in this document.
--> > --> > -->
--> > --> > -->         o  Unicast Forwarding: forwarding methods
--> > --> that apply to
--> > --> frames
--> > --> > -->            with unicast destination MAC addresses.
--> > --> > -->
--> > --> > -->         o  Unknown Destination - a destination 
--> for which a
--> > --> receiving
--> > --> > -->            device has no filtering database entry.
--> > --> Destination
--> > --> (layer
--> > --> > -->
--> > --> > --> sgai 12> the stations receive the unknown 
--> unicast and have
--> > --> filtering
--> > --> > --> information, only the bridges don't. I propose to
--> > --> replace device
--> > --> with
--> > --> > --> bridge.
--> > --> > -->
--> > --> >
--> > --> > Again, it is the intention to provide as broad a 
--> definition as
--> > --> possible
--> > --> > without introducing confusion or ambiguity.  An end node
--> > --> (or station)
--> > --> > has - in a sense - a filtering database (it's mine, or
--> > --> it's for the
--> > --> bit
--> > --> > bucket).
--> > --> >
--> > --> > We need to explicitly include 802.1D forwarding devices
--> > --> and RBridges.
--> > --> >
--> > --> > However, the definition should specify "forwarding 
--> device" - as
--> > --> opposed
--> > --> > to just "receiving device."
--> > --> >
--> > --> > I will change that.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->            2) addresses are typically "learned" 
--> by (layer 2)
--> > --> > forwarding
--> > --> > -->            devices via a process commonly referred to
--> > --> as "bridge
--> > --> > learning".
--> > --> > -->
--> > --> > --> Sgai 13> in IEEE, the term used is "learning" instead
--> > --> of "bridge
--> > --> > learning"
--> > --> > -->
--> > --> >
--> > --> > However, the term defined in this document is 
--> "bridge learning."
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  VLAN: Virtual Local Area Network. VLANs in
--> > --> general fall
--> > --> > into
--> > --> > -->            two categories: link (or port) 
--> specific VLANs and
--> > --> tagged
--> > --> > -->            VLANs. In the former case, all frames
--> > --> forwarded and all
--> > --> > -->            directly connected nodes are assumed to be
--> > --> part of a
--> > --> single
--> > --> > -->            VLAN.  In the latter case, VLAN tagged
--> > --> frames are used
--> > --> to
--> > --> > -->            distinguish which VLAN each frame is intended
--> for.
--> > --> > -->
--> > --> > --> Sgai 14> This definition is not completely correct, I
--> prefer:
--> > --> > -->
--> > --> > --> VLAN technology introduces the following three 
--> basic types
--> of
--> > --> frame:
--> > --> > --> a) Untagged frames;
--> > --> > --> b) Priority-tagged frames; and
--> > --> > --> c) VLAN-tagged frames.
--> > --> > -->
--> > --> > --> An untagged frame or a priority-tagged frame does not
--> > --> carry any
--> > --> > --> identification of the VLAN to which it belongs. Such
--> > --> frames are
--> > --> > --> classified as belonging to a particular VLAN based on
--> > --> parameters
--> > --> > --> associated with the receiving Port, or, through 
--> proprietary
--> > --> extensions
--> > --> > --> to IEEE 802.1Q standard, based on the data content of
--> > --> the frame
--> > --> (e.g.,
--> > --> > --> MAC Address, layer 3 protocol ID, etc.).
--> > --> > -->
--> > --> > --> A VLAN-tagged frame carries an explicit
--> > --> identification of the VLAN
--> > --> to
--> > --> > --> which it belongs; i.e., it carries a tag header 
--> that carries
--> a
--> > --> non-
--> > --> > null
--> > --> > --> VID. Such a frame is classified as belonging to a
--> > --> particular VLAN
--> > --> > based
--> > --> > --> on the value of the VID that is included in the tag
--> > --> header. The
--> > --> > presence
--> > --> > --> of the tag header carrying a non-null VID means that
--> > --> some other
--> > --> > device,
--> > --> > --> either the originator of the frame or a 
--> VLAN-aware Bridge,
--> has
--> > --> mapped
--> > --> > --> this frame into a VLAN and has inserted the 
--> appropriate VID.
--> > --> > -->
--> > --> >
--> > --> > So, you're getting into the details of the 
--> technology and - in
--> > --> particular
--> > --> > the encapsulation.  I will expand the definition to 
--> include a
--> > --> possibility
--> > --> > that other criteria may be used to define a "VLAN port" -
--> although
--> > --> this is
--> > --> > isomorphic to a logical model in which a device
--> > --> implementation uses
--> > --> some
--> > --> > criteria to decide that a subset of the traffic received
--> > --> on a specific
--> > --> > physical port is to be forwarded as if received on a
--> > --> specific logical
--> > --> > port.
--> > --> >
--> > --> > The key point in this definition is that a VLAN is a
--> > --> "Virtual LAN" -
--> > --> > meaning
--> > --> > it consists of a subset of the physical and L2 connectivity
--> > --> corresponding
--> > --> > to
--> > --> > a "logical LAN."  The intent is to "rise above" the
--> technological
--> > --> > approaches
--> > --> > and encapsulations to establish a generic definition that
--> > --> is loosely
--> > --> tied
--> > --> > to
--> > --> >
--> > --> > ways that this generic definition is actually implemented.
--> > --> >
--> > --> > Again, bearing in mind the way that the term is 
--> defined, does
--> the
--> > --> usage of
--> > --> > the term cause confusion or ambiguity?
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  CRED Forwarding Table (CFT): the per-hop
--> forwarding
--> > --> table
--> > --> > -->            populated by the RBridge Routing Protocol;
--> > --> forwarding
--> > --> > within
--> > --> > -->            the CRED is based on a lookup of the 
--> CRED Transit
--> > --> Header
--> > --> > -->            (CTH) encapsulated within the 
--> outermost received
--> L2
--> > --> header.
--> > --> > -->            The outermost L2 encapsulation in this
--> > --> case includes
--> > --> the
--> > --> > -->            source MAC address of the immediate
--> > --> upstream RBridge
--> > --> > -->            transmitting the frame and destination MAC
--> > --> address of
--> > --> the
--> > --> > -->            receiving RBridge for use in the unicast
--> forwarding
--> > --> case.
--> > --> > -->
--> > --> > --> Sgai 15> In section 7 of
--> > --> > -->
--> > --> 
--> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-
--> > --> > 00.txt
--> > --> > --> we proposed that when two rbridges are 
--> connected by a point
--> to
--> > --> point
--> > --> > --> link the outer MAC addresses may be set to a
--> > --> predefined value in
--> > --> > --> transmission and ignored in reception.
--> > --> > -->
--> > --> >
--> > --> > I'm not sure how your proposal intends to determine that
--> > --> a link is in
--> > --> > fact point-to-point and does not just look that way.
--> > --> >
--> > --> > I prefer to use the same encapsulation in all cases where it
--> will
--> > --> work.
--> > --> >
--> > --> > The optimization associated with using some form of
--> > --> null-encapsulation
--> > --> > is of dubious value, given that it may not be possible to
--> > --> be certain a
--> > --> > point-to-point link is - and will remain - in fact a
--> > --> point-to-point
--> > --> > link.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  CFT-IRT: a forwarding table used for 
--> propagation
--> of
--> > --> > -->            broadcast, multicast or flooded 
--> frames along the
--> > --> Ingress
--> > --> > -->            RBridge Tree (IRT).
--> > --> > -->
--> > --> > --> Sgai 16> is it a forwarding table or is it a
--> > --> filtering database.
--> > --> Since
--> > --> > --> the "miss" behavior is to flood, I see it as a
--> > --> filtering database.
--> > --> > -->
--> > --> >
--> > --> > What state was "miss" behavior from - Hawaii?  :-)
--> > --> >
--> > --> > It is analogous to a filtering database entry, but it is not
--> that.
--> > --> >
--> > --> > Clearly there are more things in this world than can be
--> classified
--> > --> > in this taxonomy.  However, given these choices, it is a
--> > --> forwarding
--> > --> > table.
--> > --> >
--> > --> > This is not a misbehavior, in that the same "base" tree
--> > --> is used for
--> > --> > broadcast and multicast traffic as well as flooded
--> > --> traffic.  It may
--> > --> > be arguable that flooding is a misbehavior, but I 
--> seem to recall
--> > --> > that people still see it as a necessary evil.
--> > --> >
--> > --> > It is also not "miss" behavior (as in "cache miss") in
--> > --> the multicast
--> > --> > and broadcast case, either.
--> > --> >
--> > --> > I believe the definition is quite correct and easy to
--> understand,
--> > --> > provided you're not reading it with preconceived 
--> misconceptions
--> > --> > about its meaning.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  CRED Transit Header (CTH): a 'shim' 
--> header that
--> > --> > encapsulates
--> > --> > -->            the ingress L2 frame and persists 
--> throughout the
--> > --> transit of
--> > --> > a
--> > --> >
--> > --> > -->            CRED, which is further encapsulated within
--> > --> a hop-by-hop
--> > --> L2
--> > --> > -->            header (and trailer). The hop-by-hop L2
--> > --> encapsulation
--> > --> in
--> > --> > this
--> > --> >
--> > --> > -->            case includes the source MAC address of
--> > --> the immediate
--> > --> > -->            upstream RBridge transmitting the frame
--> > --> and destination
--> > --> MAC
--> > --> > -->            address of the receiving RBridge - 
--> at least in
--> the
--> > --> unicast
--> > --> > -->            forwarding case.
--> > --> > -->
--> > --> > --> Sgai 17> is this true also for unknown unicast?
--> > --> > -->
--> > --> >
--> > --> > That is something that will be (may be already) 
--> decided in the
--> > --> protocol
--> > --> > specification.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  CRED Transit Table (CTT): a table that maps
--> ingress
--> > --> frame
--> > --> > L2
--> > --> > -->            destinations to egress RBridge 
--> addresses, used to
--> > --> determine
--> > --> > -->            encapsulation of ingress frames for 
--> transit of
--> the
--> > --> CRED.
--> > --> > -->
--> > --> > -->         o  Cooperating RBridges - those RBridges
--> > --> within a single
--> > --> > -->            Ethernet Subnet (broadcast domain or LAN)
--> > --> not having
--> > --> been
--> > --> > -->            configured to ignore each other. By 
--> default, all
--> > --> RBridges
--> > --> > -->            within a single Ethernet subnet will 
--> cooperate
--> with
--> > --> each
--> > --> > -->            other. It is possible for implementations
--> > --> to allow for
--> > --> > -->            configuration that will restrict
--> > --> "cooperation" between
--> > --> an
--> > --> > -->            RBridge and an apparent neighboring 
--> RBridge.  One
--> > --> reason
--> > --> > why
--> > --> > -->            this might occur is if the trust model
--> > --> that applies in
--> > --> a
--> > --> > -->            particular deployment imposes a need for
--> > --> configuration
--> > --> of
--> > --> > -->            security information.  By default no such
--> > --> configuration
--> > --> is
--> > --> > -->            required however - should it be used in
--> > --> any specific
--> > --> > scenario
--> > --> > -->
--> > --> > -->            - it is possible (either deliberately or
--> > --> inadvertently)
--> > --> to
--> > --> > -->            configure neighboring RBridges so 
--> that they do
--> not
--> > --> > cooperate.
--> > --> > -->
--> > --> > -->            In the remainder of this document, 
--> all RBridges
--> are
--> > --> assumed
--> > --> > -->            to be in a cooperating (default) 
--> configuration.
--> > --> > -->
--> > --> > --> Sgai 18> can RBridges cooperate in groups, e.g. four
--> Rbridges
--> > --> > connected
--> > --> > --> to a LAN cooperating two and two?
--> > --> > -->
--> > --> >
--> > --> > Yes.  There may be reasons why this might be done 
--> deliberately,
--> > --> however
--> > --> > - even in the absence of any "proof of concept"
--> > --> justification - it is
--> > --> a
--> > --> > really good idea to design the protocol to be robust in
--> > --> cases where a
--> > --> > set of RBridges may be (mis)configured in such a way as
--> > --> to be unable
--> > --> to
--> > --> > discover each other.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  Ingress RBridge Tree: a tree 
--> computed for each
--> edge
--> > --> RBridge
--> > --> > -->            and potentially for each VLAN in which that
--> RBridge
--> > --> > -->
--> > --> > --> sgai 19> why for each VLAN? I got the 
--> impression that there
--> > --> > --> was a single tree that was pruned differently for
--> > --> different VLANs.
--> > --> > -->
--> > --> >
--> > --> > Pruning may also take place at the ingress, if - for
--> > --> example - it has
--> > --> a
--> > --> > subset of interfaces that are not connected to any 
--> egress for
--> > --> particular
--> > --> > VLANs.  It is a small point but, in such cases, there is in
--> effect
--> > --> more
--> > --> > than one IRT even at the ingress.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->            participates - for delivery of broadcast,
--> > --> multicast and
--> > --> > -->            flooded frames from that RBridge to all
--> > --> relevant egress
--> > --> > -->            RBridges. This is the point-to-multipoint
--> > --> delivery tree
--> > --> > used
--> > --> > -->            by an ingress RBridge to deliver
--> > --> multicast, broadcast
--> > --> or
--> > --> > -->            flooded traffic.
--> > --> > -->
--> > --> > --> Sgai 20> the current version of the proposal 
--> speaks about a
--> > --> multicast
--> > --> > --> address, not point-to-point.
--> > --> > -->
--> > --> >
--> > --> > I did not say "point-to-point" (look again).
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->         o  LPT: Learned Port Table. See 
--> Filtering Database.
--> > --> > -->
--> > --> > --> Sgai 21> not proper terminology, I would use
--> > --> "filtering database"
--> > --> > --> everywhere.
--> > --> > -->
--> > --> >
--> > --> > I am happy to remove this if there is no objection 
--> to my doing
--> so.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> sgai 22> I wired port is Ehernet, i.e. IEEE 802.3, a
--> > --> > --> wireless port is not Ethernet, it is IEEE 802.11.
--> > --> > -->
--> > --> >
--> > --> > See my response to your point (sgai 8) above.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> sgai 23> they learn because STP guarantees
--> > --> symmetrical forwarding
--> > --> > -->
--> > --> >
--> > --> > This (apparently) refers to the immeditately preceding text:
--> > --> >
--> > --> >         Conventional bridges contain a learned port table
--> > --> (LPT), or
--> > --> >         filtering database, and a spanning tree table
--> > --> (STT). The LPT
--> > --> >         allows a bridge to avoid flooding all received
--> > --> frames, as is
--> > --> >         typical for a hub or repeater. The bridge learns
--> > --> which nodes
--> > --> are
--> > --> >         accessible from a particular port by assuming
--> > --> bi-directional
--> > --> >         consistency:
--> > --> >
--> > --> > I'm not sure how picking at the peculiarities of 
--> STP behavior is
--> > --> > relevant to this description.  STP results in a 
--> single spanning
--> > --> > tree where each link is bi-directional.  This 
--> ensures that the
--> > --> > MAC frames are forwarded in a bi-directionally consistent
--> fashion.
--> > --> >
--> > --> > To replace this text with yours is to provide less 
--> information.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 24> active ports -> forwarding ports
--> > --> > -->
--> > --> >
--> > --> > "Active ports" was the exact wording suggested to me.  In
--> > --> context for
--> > --> > this working group "active ports" is more meaningful than
--> > --> "forwarding
--> > --> > ports."  For people not used to STP-speak, "forwarding
--> > --> port" might be
--> > --> > used to discriminate from a "code port."
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 25> there is no STT, there is a state associated
--> > --> with each
--> > --> port
--> > --> > --> that can be: disabled, blocking, listening, 
--> learning, and
--> > --> forwarding
--> > --> > -->
--> > --> >
--> > --> > Other than the issue with terminology, is this text 
--> wrong?  I am
--> > --> fairly
--> > --> > sure that different implementations handle the "port state"
--> > --> information
--> > --> > in different ways, and I am also reasonably sure that a
--> > --> "table" such
--> > --> as
--> > --> > the one described here is one of the ways it might be done.
--> > --> >
--> > --> > However, I agree with your assertion that this is the way
--> > --> that it is
--> > --> > usually talked about in an IEEE context, so - 
--> unless there are
--> > --> specific
--> > --> > objections - I can change the wording to be consistent
--> > --> with what you
--> > --> > suggest.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> sgai 26> disabled -> blocking
--> > --> > -->
--> > --> >
--> > --> > I can make this change as well.  However, from the
--> > --> perspective of what
--> > --> > we are trying to do, "disabled" is potentially a more
--> > --> correct term.
--> > --> It
--> > --> > is certainly more intuitively correct, outside of a
--> > --> strictly IEEE/STP
--> > --> > context.
--> > --> >
--> > --> > Symmetry is maintained in STP by blocking ports/links
--> > --> bi-directionally.
--> > --> > In such cases, a port is effectively disabled for bridges
--> > --> at either
--> > --> end
--> > --> > of the link for which a port is blocked, is it not?
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> sgai 27> I repeat a comment that I have made to other
--> > --> documents: "
--> > --> > --> The discussion about VLAN needs to be much more
--> > --> extensive. It is
--> > --> clear
--> > --> > --> from the mailing list discussion that VLANs can be
--> > --> used inside the
--> > --> > --> packet or in the Ethernet encapsulation of TRILL.
--> > --> These are two
--> > --> > --> different kinds of VLANs and their requirement need
--> > --> to be stated
--> > --> > --> separately. Q in Q needs also to be discussed. I
--> > --> propose to define
--> > --> > inner
--> > --> > --> and outer VLANs (with reference to the position of
--> > --> the tag in the
--> > --> > frame."
--> > --> > --> Here I think we are talking about outer VLANs
--> > --> > -->
--> > --> >
--> > --> > I responded to this in separate mail.  I wait to hear
--> > --> other opinions
--> > --> on
--> > --> > this subject.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 28> IMO all RBridges must be ingress RBridges,
--> > --> at least to
--> > --> > support
--> > --> > --> inband management, e.g. SNMP.
--> > --> > -->
--> > --> >
--> > --> > No.
--> > --> >
--> > --> > In order to ensure symmetry with RBridges not
--> > --> participating in STP,
--> > --> there
--> > --> > MUST be a designated RBridge that does all of the 
--> sending and
--> > --> receiving
--> > --> > of native encapsulated frames on a LAN segment.
--> > --> >
--> > --> > Any RBridge the loses the "Designated RBridge" 
--> election cannot
--> be
--> > --> either
--> > --> > an ingress or an egress for that LAN segment.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 29> same as above
--> > --> > -->
--> > --> >
--> > --> > Same as above.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 30> I think the previous definition is not needed.
--> > --> > -->
--> > --> >
--> > --> > This appears to refer to:
--> > --> >
--> > --> >         o  Local RBridge - the RBridge that forms and
--> > --> maintains the
--> > --> CFT-
--> > --> >            IRT entry (or entries) under discussion. The
--> > --> local RBridge
--> > --> >            may be an Ingress RBridge, or an egress 
--> RBridge with
--> > --> respect
--> > --> >            to any set of entries in the CFT-IRT.
--> > --> >
--> > --> > This defintion is needed.  It is subsequently used 
--> in at least 4
--> > --> places.
--> > --> > When discussing the behavior of a specific RBridge
--> > --> relative to a peer,
--> > --> > it is convenient to define the term "local RBridge."
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> sgai 31> why is it zero or more, if an RBridge 
--> exists, it
--> must
--> > --> have
--> > --> > --> a an IRT, I haven't seen any discussion to support
--> > --> multiple IRTs.
--> > --> > -->
--> > --> >
--> > --> > This was answered previously on the mailing list.
--> > --> Briefly, zero or
--> > --> > more is correct, given that an RBridge may not have
--> > --> forwarding entries
--> > --> > for frames it has received.  In these cases, a frame is
--> > --> not forwarded.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 32> I don't understand this. Since the current
--> > --> proposal uses
--> > --> a
--> > --> > --> multicast MAC address, what is needed is a bit map
--> > --> for each IRT
--> > --> that
--> > --> > --> says which ports are blocking and which are
--> > --> forwarding. You are
--> > --> > --> basically building a ST using ISIS.
--> > --> > -->
--> > --> >
--> > --> > This might be the case for a specific implementation.
--> > --> Whether it is
--> > --> > implemented as a "bit-mask" with "non-blocking"
--> > --> (forwarding) ports, or
--> > --> > is implemented as a full-blown table is largely dependent on
--> what
--> > --> other
--> > --> > information the local device requires in order to
--> > --> properly forwad the
--> > --> > frame.  If - for example - a device has multiple
--> > --> different port types,
--> > --> > it may need to have more information for each port (or that
--> > --> information
--> > --> > may be added later on).
--> > --> >
--> > --> > All of these are implementation choices that are
--> > --> logically represented
--> > --> > by the table described here.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 33> I don't get the pair.
--> > --> > -->
--> > --> >
--> > --> > Since this immediately follows:
--> > --> >
--> > --> >         Each entry would contain an indication of 
--> which single
--> > --> interface
--> > --> >         a broadcast, multicast or flooded frame would be
--> > --> forwarded for
--> > --> >         each (ingress RBridge, egress RBridge) pair.
--> > --> >
--> > --> > I don't get what you don't get.
--> > --> >
--> > --> > The pair refers to the tuple "(ingress RBridge, egress
--> RBridge)."
--> > --> >
--> > --> > This might be the point at which your earlier point (Sgai 4)
--> would
--> > --> make
--> > --> > sense to insert.  I had logically modeled this in my own
--> > --> mind as two
--> > --> > distinct "interfaces" (the reason I use this term, rather
--> > --> thhan port),
--> > --> > but I should clarify this.
--> > --> >
--> > --> > In any case, the entries are keyed by both ingress and
--> > --> egress RBridge.
--> > --> > While there will be entries for only those egress
--> > --> RBridges where this
--> > --> > local RBridge is on the shortest path (between the given
--> > --> ingress and
--> > --> > egress pair), there will be at most one entry per 
--> any ingress
--> and
--> > --> > egress pair.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 34> as a matter of fact each interface is
--> > --> basically a set of
--> > --> two
--> > --> > --> interfaces, a regular one and a tunnel one, and the
--> > --> > forwarding/blocking
--> > --> > --> state may be different for the two.
--> > --> > -->
--> > --> >
--> > --> > No.
--> > --> >
--> > --> > As per my response to your point (Sgai 28) above, not
--> > --> every RBridge
--> > --> has a
--> > --> > "regular one" as you describe here.
--> > --> >
--> > --> > The forwarding/blocking state is not applicable as
--> > --> RBridges don't do
--> > --> STP.
--> > --> >
--> > --> > For the native interface, fowarding/blocking state is
--> > --> analogous to the
--> > --> > "Designated RBridge" election process.
--> > --> >
--> > --> > Since this point evidently applies to -
--> > --> >
--> > --> >                                                      Entries
--> would
--> > --> also
--> > --> >         contain any required encapsulation information,
--> > --> etc. required
--> > --> >         for forwarding on a given interface, and toward a
--> > --> corresponding
--> > --> >         specific egress RBridge.
--> > --> >
--> > --> > - your point, and my response, are related to the point
--> > --> (and response)
--> > --> > above (Sgai 33), and I will try to clarify this 
--> part as well.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 35> this protocol must be designed to avoid
--> > --> transient loops,
--> > --> > since
--> > --> > --> transient loops of multicast/broadcast cause
--> > --> broadcast storm that
--> > --> are
--> > --> > --> highly undesirable.
--> > --> > -->
--> > --> >
--> > --> > No.
--> > --> >
--> > --> > The protocol needs to include a provision to prevent
--> > --> _use_ of links
--> > --> that
--> > --> > may connect to transient loops.  Using a link-state
--> > --> routing protocol
--> > --> has
--> > --> > clearly been demostrated to produce transient loops, but
--> > --> the problem
--> > --> you
--> > --> > want to address has to do with using those links.
--> > --> >
--> > --> > A state-machine driven mechanism similar to STP might be
--> > --> the approach
--> > --> to
--> > --> > use.
--> > --> >
--> > --> > Because we're incorporating TTL in the SHIM, however this
--> > --> would need
--> > --> to
--> > --> > apply only to IRT traffic.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > -->
--> > --> > --> Sgai 36> see my previous comment about VLANs
--> > --> > -->
--> > --> >
--> > --> > See my previous responses.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> sgai 37> disabled -> blocking.
--> > --> > -->
--> > --> >
--> > --> > See my response to your point (sgai 26) above.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 38> for multicast/broadcast we also need to
--> > --> avoid transient
--> > --> > loops.
--> > --> > -->
--> > --> >
--> > --> > Yes.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 39> but RBridge discovery and STP are ongoing
--> > --> processes, why
--> > --> do
--> > --> > we
--> > --> > --> want to couple their timers?
--> > --> > -->
--> > --> >
--> > --> > I am not suggesting "coupling their timers."  I am 
--> saying that
--> the
--> > --> value
--> > --> > chosen for a timer (if one is used) to determine when it
--> > --> is reasonable
--> > --> to
--> > --> > start RBridge peer discovery should take into 
--> account the time
--> it
--> > --> takes
--> > --> > for the local spanning tree resolution.
--> > --> >
--> > --> > I feel the reason for this is self-evident but, just to
--> > --> clarify, think
--> > --> > about the process we're planning to use to determine RBridge
--> > --> nick-names.
--> > --> > If we start this too early, we will be re-starting it
--> > --> many times as we
--> > --> > "hear from" new RBridge peers when the connecting links go
--> active
--> > --> after
--> > --> > local bridges go to the forwarding state.  This would
--> > --> apply only at
--> > --> the
--> > --> > system start up as - after that - you are quite correct
--> > --> in asserting
--> > --> it
--> > --> > would be an ongoing process.
--> > --> >
--> > --> > Perhaps I should add some words to indicate that a delay
--> > --> would not be
--> > --> > necessary if the protocol mechanisms do not introduce
--> > --> instability as a
--> > --> > new peer is discovered.  So far, I have not seen any
--> > --> indication that a
--> > --> > "race-free" solution to accomplish this has been designed
--> > --> - or talked
--> > --> > about.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 40> there is also a requirement to time-out learnt
--> > --> information to
--> > --> > --> maintain the filtering databases.
--> > --> > -->
--> > --> >
--> > --> > There would be, if we were doing that.  Instead, 
--> we're adopting
--> a
--> > --> > link-state routing protocol and they tend to have 
--> that covered.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 41> periodically or on demand
--> > --> > -->
--> > --> >
--> > --> > See the response to your point (Sgai 40) above.
--> > --> >
--> > --> > -- [snip --
--> > --> > -->
--> > --> > --> Sgai 42> potentially there is an unencapsulated
--> > --> interface for each
--> > --> > --> physical interface of the RBridge. It is true that
--> > --> you can model
--> > --> all
--> > --> > --> of them as a single separate logical interface, but
--> > --> then we need
--> > --> to
--> > --> > --> replicate the frame according to a bitmask that tells on
--> which
--> > --> > physical
--> > --> > --> interface the RBridge is designated.
--> > --> > -->
--> > --> >
--> > --> > Again, your use of a "bitmask" is an implementation
--> > --> choice as opposed
--> > --> > to a logical model.
--> > --> >
--> > --> > As you observe, I do "model all of them as a single
--> > --> separate logical
--> > --> > interface" and if you want to "replicate the frame 
--> according to
--> a
--> > --> > bitmask that tells on which physical interface the 
--> RBridge is
--> > --> > designated" - you're absolutely free to do so.
--> > --> >
--> > --> > Personally, I think this is far too much implementation
--> > --> stuff for a
--> > --> > protocol specification, let alone an architecture document.
--> > --> >
--> > --> > -->
--> > --> > --> Sgai 43> can we clarify that this means "drop BPDUs".
--> > --> > -->
--> > --> >
--> > --> > Yes.
--> > --> >
--> > --> > -- [snip --
--> > -->
--> 


Received: from xmail02.myhosting.com (xmail02.myhosting.com [168.144.250.216]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1GYsKi013932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 1 Nov 2006 08:34:55 -0800 (PST)
Received: (qmail 4885 invoked from network); 1 Nov 2006 16:34:54 -0000
Received: from unknown (HELO [127.0.0.1]) (Authenticated-user:[e-mail]@[65.190.218.139]) (envelope-sender <[e-mail]>) by xmail02.myhosting.com (qmail-ldap-1.03) with SMTP for <[e-mail]>; 1 Nov 2006 16:34:54 -0000
Message-ID: <[e-mail]>
Date: Wed, 01 Nov 2006 11:34:49 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Silvano Gai <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] New shim header proposal---without F-tag field
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 16:35:11 -0000
Status: RO
Content-Length: 928

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


>> 	I don't think there is consensus yet that we only need 16 bits
>> for RBridge IDs.
> 
> With 16 bits, using 1 bit to indicate unicast, we can have 32K switches.
> According to the current definition of TRILL, there is the need to run
> Djikstra on a database with 32K records, one time for the core instance
> and 32K times for the IRTs. This is clearly out of reach even for the
> most powerful CPU. 

?? Perhaps 32k trees is a stretch, but 32k nodes in a tree? I don't
think that's really a stretch on today's processors, from the scaling
work I've seen done in IS-IS.

:-)

Russ

- --
[e-mail] CCIE <>< Grace Alone

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

iD8DBQFFSMypER27sUhU9OQRAqLwAJ9FLN2YNP2mrB6i0ZcV1fxLzAT0hgCfYHYj
6mJCA68nQLjCD8US9nRZZag=
=kwzq
-----END PGP SIGNATURE-----


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1GYSAU013758 for <[e-mail]>; Wed, 1 Nov 2006 08:34:28 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Nov 2006 08:34:26 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Comments on:	http://www.ietf.org/internet-drafts/dr aft-ietf-trill-rbridge-arch-01.txt
Thread-Index: Acb90oCrhGLUfrQNReet0QuPkzohEQAAOtCg
From: "Silvano Gai" <[e-mail]>
To: "Russ White" <[e-mail]>, "Gray, Eric" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA1GYSAU013758
Cc: [e-mail]
Subject: Re: [rbridge] Comments on:	http://www.ietf.org/internet-drafts/dr aft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 16:35:00 -0000
Status: RO
Content-Length: 1640

Russ,

> -----Original Message-----
> From: Russ White [mailto:[e-mail]]
> Sent: Wednesday, November 01, 2006 8:27 AM
> To: Gray, Eric
> Cc: Silvano Gai; [e-mail]
> Subject: Re: [rbridge] Comments on:
http://www.ietf.org/internet-drafts/dr
> aft-ietf-trill-rbridge-arch-01.txt
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > 	The notion of using a L2 version of ECMP is - IMO - in no way
> > implied
> > by the text in the charter.  Nor is there any explicit intention to
> preclude
> > this type of activity - with the caveat that anyone doing so has to
> assume
> > responsibility for not "breaking" the interoperability model.

Why are you breaking the interoperability model?

-- Silvano

> 
> And this is as it should be, IMHO. If you know, for certain, that your
> entire network is made up of rbridges, rather than a mixture of
various
> types of bridging devices, then you could use L2 ECMP. If you don't,
> then you (probably) can't.
> 
> I think this decision is in the hands of network operators and
> implementors, though, not in the hands of the spec writers. If we say:
> "X is dangerous in specific situation Y, therefore we will never allow
> X," then we are shutting down possible avenues for growth--such as the
> stuff we're talking about with F-Tags.
> 
> :-)
> 
> Russ
> 
> - --
> [e-mail] CCIE <>< Grace Alone
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFFSMq2ER27sUhU9OQRAkrFAJ0cDSgqRhSi5zT6SvbCOO0z4PUCcQCfQJ3l
> 8omzi9hZhNEBFvKNWeYo1kQ=
> =eRrz
> -----END PGP SIGNATURE-----



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1GSaG3011315 for <[e-mail]>; Wed, 1 Nov 2006 08:28:36 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Nov 2006 08:28:34 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
Thread-Index: Acb90ZaK/I9/0FSIS6K78/NjsyuDIAAAMI9w
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA1GSaG3011315
Cc: [e-mail]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 16:28:46 -0000
Status: RO
Content-Length: 2483

Eric,

When I propose something that is not in the charter, it is out of scope
because not in the charter; when I propose something that is in the
charter, it is out of scope because "this is not what the charter is
meant to
describe."

Let's be fair!

IMHO, if TRILL does not support Layer 2 ECMP, it is not interesting at
all for us. All the interest in replacing Spanning Tree is to get Layer
2 ECMP.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Wednesday, November 01, 2006 8:20 AM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: RE: [rbridge] Comments on: http://www.ietf.org/internet-
> drafts/draft-ietf-trill-rbridge-arch-01.txt
> 
> Silvano,
> 
> 	As I said in my other reply, this is not what the charter is
meant
> to
> describe.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[e-mail]]
> --> Sent: Wednesday, November 01, 2006 1:08 AM
> --> To: Gray, Eric
> --> Cc: [e-mail]
> --> Subject: RE: [rbridge] Comments on:
> --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
> --> -arch-01.txt
> -->
> -->
> --> Eric,
> -->
> --> The charter says:
> --> "load-splitting among multiple paths"
> --> The pragmatic way to achieve this is to implement Layer 2 ECMP
> -->
> --> -- Silvano
> -->
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:[e-mail]]
> --> > Sent: Tuesday, October 31, 2006 9:25 AM
> --> > To: Silvano Gai
> --> > Cc: [e-mail]
> --> > Subject: RE: [rbridge] Comments on:
http://www.ietf.org/internet-
> --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
> --> >
> --> > Silvano,
> --> >
> --> > 	See below...
> --> >
> --> > --
> --> > Eric
> --> >
> --> > -- [snip] --
> --> > -->
> --> > --> Sgai 2> I think we should explicitly mention layer 2
> --> multipath.
> --> > -->
> --> > -- [snip] --
> --> > -->
> --> >
> --> > What do you mean by layer 2 multipath?
> --> >
> --> > Do you mean "link bundling" or something else?
> --> >
> --> > Are we trying now to apply ECMP to routing advertisements
> --> for layer
> --> > two reachability?  That's a big step, particularly when we need
to
> --> > retain compatibility with existing 802.1 bridges.
> --> >
> --> > I don't recall seeing anything about this in the problem
statement
> --> > document, so I don't know of any reason why we should
> --> include it in
> --> > the architecture.
> --> >
> --> > --
> --> > Eric
> -->



Received: from xmail02.myhosting.com (xmail02.myhosting.com [168.144.250.216]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1GQaBF010295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 1 Nov 2006 08:26:36 -0800 (PST)
Received: (qmail 8370 invoked from network); 1 Nov 2006 16:26:35 -0000
Received: from unknown (HELO [127.0.0.1]) (Authenticated-user:[e-mail]@[65.190.218.139]) (envelope-sender <[e-mail]>) by xmail02.myhosting.com (qmail-ldap-1.03) with SMTP for <[e-mail]>; 1 Nov 2006 16:26:35 -0000
Message-ID: <[e-mail]>
Date: Wed, 01 Nov 2006 11:26:30 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Comments on:	http://www.ietf.org/internet-drafts/dr aft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 16:27:14 -0000
Status: RO
Content-Length: 1204

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


> 	The notion of using a L2 version of ECMP is - IMO - in no way
> implied
> by the text in the charter.  Nor is there any explicit intention to preclude
> this type of activity - with the caveat that anyone doing so has to assume
> responsibility for not "breaking" the interoperability model.

And this is as it should be, IMHO. If you know, for certain, that your
entire network is made up of rbridges, rather than a mixture of various
types of bridging devices, then you could use L2 ECMP. If you don't,
then you (probably) can't.

I think this decision is in the hands of network operators and
implementors, though, not in the hands of the spec writers. If we say:
"X is dangerous in specific situation Y, therefore we will never allow
X," then we are shutting down possible avenues for growth--such as the
stuff we're talking about with F-Tags.

:-)

Russ

- --
[e-mail] CCIE <>< Grace Alone

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

iD8DBQFFSMq2ER27sUhU9OQRAkrFAJ0cDSgqRhSi5zT6SvbCOO0z4PUCcQCfQJ3l
8omzi9hZhNEBFvKNWeYo1kQ=
=eRrz
-----END PGP SIGNATURE-----


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1GNQKU009193 for <[e-mail]>; Wed, 1 Nov 2006 08:23:26 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Nov 2006 08:23:24 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] VLANs
Thread-Index: Acb9z85XFD3JMROZSMi34wFx/XtyGQAAYYkA
From: "Silvano Gai" <[e-mail]>
To: "Gray, Eric" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA1GNQKU009193
Cc: [e-mail]
Subject: Re: [rbridge] VLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 16:24:47 -0000
Status: RO
Content-Length: 7651

Eric,

> -----Original Message-----
> From: Gray, Eric [mailto:[e-mail]]
> Sent: Wednesday, November 01, 2006 8:07 AM
> To: Silvano Gai
> Cc: [e-mail]
> Subject: RE: [rbridge] VLANs
> 
> Silvano,
> 
> 	I believe I've stated my position on using the IVLAN/OVLAN
> terminology, but just in case - I don't think it's necessary and
> I don't think it helps.

I think it does.

> 
> 	It seems to me that the description you provide below is an
> ample demonstration of the confusion that the use of these terms
> can introduce.

No, it is a demonstration of the confusion that not introducing these
terms creates.

> 
> 	For example, let's really complicate your example by using
> stacked VLAN tagging both in the tunnel encapsulation and in the
> native encapsulation for portions of the assumed domain. 

You have already mentioned this stacking and other magic that TRILL
plans to do with VLANs, but you have never provided a consistent
explanation. Is this part of TRILL or not?

Is TRILL defined to be mapped on a single OVLAN or on multiple? 
Is this written in any draft?

Can you explain this clearly?

Thank You

-- Silvano

 In the
> (deliberately) complicated model I've just described, what does
> the IVLAN/OVLAN distinction mean?
> 
> 	In fact, one reason not to distinguish the two is that - in
> the text you're referring to - the impact of which it is that may
> apply is nil.  Hence by not making a distinction, we're allowed a
> certain economy in communicating.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[e-mail]]
> --> Sent: Wednesday, November 01, 2006 12:55 AM
> --> To: Gray, Eric
> --> Cc: [e-mail]
> --> Subject: RE: [rbridge] VLANs
> -->
> -->
> --> Eric,
> -->
> --> I disagree and let me give you concrete examples why:
> -->
> --> draft-ietf-trill-rbridge-protocol-00.txt says:
> -->
> --> "each RBridge R1
> -->    will run a "core" instance of IS-IS for the core RBridge
> --> information,
> -->
> -->    and an instance per VLAN that R1 is attached to, for the
endnode
> -->    information for those VLANs."
> -->
> --> If we are speaking of OVLAN, IMO an RBridge runs a core instance
per
> --> each OVLAN and on that instance it propagates the endnode
> --> information
> --> for the IVLANs."
> -->
> --> " The endnode information for VLAN A, which is carried in
> --> the VLAN A
> -->    IS-IS instance injected by R1, contains:"
> -->
> --> This clearly refers to IVLAN.
> -->
> --> draft-ietf-trill-prob-01.txt says:
> -->
> --> It may alternately support
> -->    direct VLAN support, e.g., by the use of separate TRILL routing
> -->    protocol instances to separate traffic for each VLAN
> --> traversing a
> -->    TRILL solution.
> -->
> --> Is this an IVLAN or an OVLAN?
> -->
> -->
> --> draft-ietf-trill-rbridge-arch-01.txt says
> -->
> --> Ingress RBridge Tree: a tree computed for each edge RBridge -
> -->            and potentially for each VLAN in which that RBridge
> -->            participates
> -->
> --> I assume this is an OVLAN, I don't think TRILL computes an
> --> IRT for each
> --> IVLAN; it can prune an IRT for each VLAN.
> -->
> --> In an email to Dinesh you wrote:
> -->
> --> "Dinesh,
> -->
> --> 	We're making semantic distinctions here.  I can easily define a
> --> VLAN consisting of a group of RBridges that corresponds to the
same
> --> semantics as the FTAG.  "
> -->
> --> Were you referring to an IVLAN or an OVLAN?
> -->
> --> Also you claim that 16 bits are not sufficient for the RBridge ID.
> --> Is the RBridge ID space replicated per each OVLAN or is it shared?
> --> Does an RBridge have the same RBridge ID on all OVLANs?
> -->
> --> I think we need to explicitly introduce the IVLAN and OVLAN
> --> concepts and
> --> use them consistently. We don't want to hide complexity due
> --> to the lack
> --> of nomenclature.
> -->
> --> -- Silvano
> -->
> -->
> -->
> -->
> -->
> -->
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:[e-mail]]
> --> > Sent: Tuesday, October 31, 2006 9:04 AM
> --> > To: Silvano Gai
> --> > Cc: [e-mail]
> --> > Subject: RE: [rbridge] VLANs
> --> >
> --> > Silvano,
> --> >
> --> > 	Actually, both "types" of VLANs are the same - applying
at
> --> > different layers, but defined using the same terminology.
Logic,
> --> > semantics and applicability are the same.
> --> >
> --> > 	For historic reasons, we are trying to avoid the terms
you
> --> > propose.  In fact, similar terms have been used previously and
> --> > removed as confusing.  Without constant reminders, "inner" and
> --> > "outer" will be taken in some instances as placement in the
frame
> --> > (as you are suggesting) or position relative to the CRED (a
usage
> --> > issue with the terms "ingress" and "egress" meaning "way in" and
> --> > "way out" respectively).
> --> >
> --> > 	Hence you are suggesting replacement with one potential
> --> > are of confusion with another one we've earlier discarded.
> --> >
> --> > 	The architecture document defines the term VLAN and - I
am
> --> > reasonably sure - uses that definition consistently.  Moreover,
> --> > the architecture document tries to be agnostic about the use of
> --> > VLANs - particularly with respect to VLAN tagged encapsulation
> --> > and port-based VLANs, and where these things might apply.  The
> --> > reason for this is simply that one aim of protocol development -
> --> > especially at the architectural level - should be to avoid
placing
> --> > constraints on implementation beyond those explicitly required
> --> > to ensure interoperability.
> --> >
> --> > --
> --> > Eric
> --> >
> --> > --> -----Original Message-----
> --> > --> From: [e-mail]
> --> > --> [mailto:[e-mail]] On Behalf Of Silvano Gai
> --> > --> Sent: Monday, October 30, 2006 12:29 PM
> --> > --> To: [e-mail]
> --> > --> Subject: [rbridge] VLANs
> --> > -->
> --> > -->
> --> > --> The second biggest issue I have with the four documents
> --> > --> (first one being
> --> > --> broadcast/multicast storm) is the definition of VLANs.
> --> > -->
> --> > --> I don't think the term VLAN is used consistently in
> --> the documents.
> --> > -->
> --> > --> 1) Sometimes VLAN refers to the VLANs present on the
> --> > --> untagged frames,
> --> > --> which must be propagated by ISIS, VLAN pruning must be
> --> > --> performed and so
> --> > --> on. They all share the same core instance of ISIS.
> --> > -->
> --> > --> 2) Sometimes VLANs refers to the fact that a CRED can be
> --> > --> encapsulated
> --> > --> into a VLAN (present as a 1Q tag in the outer header) and
> --> > --> therefore ISIS
> --> > --> will run per VLAN, i.e. there will be a core instance of
> --> > --> ISIS per each
> --> > --> VLAN. This seems to be the case in some part of the
> --> architectural
> --> > --> document.
> --> > -->
> --> > --> I propose to name the former IVLAN (inner VLAN) and the
latter
> --> OVLAN
> --> > --> (Outer VLAN), with reference to the position of the 1Q tag
> --> > --> in the frame.
> --> > -->
> --> > --> This is also very relevant for the discussion that we need
> --> > --> to complete
> --> > --> on the FTAG: it is my understanding that some folks think
> --> > --> that the FTAG
> --> > --> is not needed, since there may be an OVLAN.
> --> > -->
> --> > --> Comments?
> --> > -->
> --> > --> -- Silvano
> --> > -->
> --> > --> _______________________________________________
> --> > --> rbridge mailing list
> --> > --> [e-mail]
> --> > --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> > -->
> -->



Received: from xmail05.myhosting.com (xmail05.myhosting.com [168.144.250.219]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1GMsiK008644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 1 Nov 2006 08:22:55 -0800 (PST)
Received: (qmail 490 invoked from network); 1 Nov 2006 16:22:39 -0000
Received: from unknown (HELO [127.0.0.1]) (Authenticated-user:[e-mail]@[65.190.218.139]) (envelope-sender <[e-mail]>) by xmail05.myhosting.com (qmail-ldap-1.03) with SMTP for <[e-mail]>; 1 Nov 2006 16:22:38 -0000
Message-ID: <[e-mail]>
Date: Wed, 01 Nov 2006 11:22:34 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Comments on:	http://www.ietf.org/internet-drafts/dr aft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 16:23:21 -0000
Status: RO
Content-Length: 859

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



> However, we in the IETF are more familiar with the term "node." 
> 
> This is hardly a significant issue.  if people agree that we should
> use the term "station" as opposed to "node", then I will change it.

I prefer node, since that's the common IETF wording, and one that people
will understand. It also relates to graph theory better than "station"
does. It might be useful to note this relationship in the definitions
someplace or another, but I don't see a reason to change the entire doc
around.

:-)

Russ

- --
[e-mail] CCIE <>< Grace Alone

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

iD8DBQFFSMnJER27sUhU9OQRAmEsAKDexb89IG4s4VVEdYcZ6v+mEhlcZACfUYDT
cw3YUKtBBTa3FI0BTaVM18o=
=AghD
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1GK3dr007863 for <[e-mail]>; Wed, 1 Nov 2006 08:20:04 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1GK2fK028351; Wed, 1 Nov 2006 11:20:02 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23550;  Wed, 1 Nov 2006 11:20:02 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647RKT>; Wed, 1 Nov 2006 11:20:01 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>
Date: Wed, 1 Nov 2006 11:20:01 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr	aft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 16:20:50 -0000
Status: RO
Content-Length: 1667

Silvano,

	As I said in my other reply, this is not what the charter is meant
to
describe.

--
Eric 

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 1:08 AM
--> To: Gray, Eric
--> Cc: [e-mail]
--> Subject: RE: [rbridge] Comments on: 
--> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> -arch-01.txt
--> 
--> 
--> Eric,
--> 
--> The charter says:
--> "load-splitting among multiple paths"
--> The pragmatic way to achieve this is to implement Layer 2 ECMP
--> 
--> -- Silvano
--> 
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[e-mail]]
--> > Sent: Tuesday, October 31, 2006 9:25 AM
--> > To: Silvano Gai
--> > Cc: [e-mail]
--> > Subject: RE: [rbridge] Comments on: http://www.ietf.org/internet-
--> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > 
--> > Silvano,
--> > 
--> > 	See below...
--> > 
--> > --
--> > Eric
--> > 
--> > -- [snip] --
--> > -->
--> > --> Sgai 2> I think we should explicitly mention layer 2 
--> multipath.
--> > -->
--> > -- [snip] --
--> > -->
--> > 
--> > What do you mean by layer 2 multipath?
--> > 
--> > Do you mean "link bundling" or something else?
--> > 
--> > Are we trying now to apply ECMP to routing advertisements 
--> for layer
--> > two reachability?  That's a big step, particularly when we need to
--> > retain compatibility with existing 802.1 bridges.
--> > 
--> > I don't recall seeing anything about this in the problem statement
--> > document, so I don't know of any reason why we should 
--> include it in
--> > the architecture.
--> > 
--> > --
--> > Eric
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1GJNuF007633 for <[e-mail]>; Wed, 1 Nov 2006 08:19:24 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1GJLfK028343; Wed, 1 Nov 2006 11:19:22 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23476;  Wed, 1 Nov 2006 11:19:21 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647RJ7>; Wed, 1 Nov 2006 11:19:20 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>, "Gray, Eric" <[e-mail]>
Date: Wed, 1 Nov 2006 11:19:20 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr	aft-ietf-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 16:19:39 -0000
Status: RO
Content-Length: 5326

Silvano,

	The first problem you're identifying is unavoidable if we intend to 
use an SPF routing protocol and we need to support multicast, broadcast 
and flooding.

	In your second problem, I believe you're reading something into the 
expression "load-splitting across multiple paths" that is not intended to 
be there.

	The intention is that we will use multiple paths because we are not
disabling links via STP.  If we use an SPF routing algorithm, instead of
STP, we will be splitting the traffic load over multiple paths.  Any more
complex form of load splitting implies sharing a lot of information about
- for example - link utilization, traffic patterns and trends, shortest 
path constraints, etc.

	The notion of using a L2 version of ECMP is - IMO - in no way
implied
by the text in the charter.  Nor is there any explicit intention to preclude
this type of activity - with the caveat that anyone doing so has to assume
responsibility for not "breaking" the interoperability model.

	Radia's discussion of how FTAG-like functionality might be done
using
the egress RBridge identifier is an example of one approach that might be
used by an ingress RBridge to split the load across multiple paths.  It is
also a good example of why this is very complicated - precisely because it
requires extending the process of setting up IRTs to include some form of
"token" used to distinguish intended paths.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 1:06 AM
--> To: Gray, Eric
--> Cc: [e-mail]
--> Subject: RE: [rbridge] Comments on: 
--> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> -arch-01.txt
--> 
--> 
--> 
--> IRTs have two problems.
--> 
--> 1) They limit the number of Rbridges in a CRED, since each 
--> switch needs
--> to run a copy of Djikstra for each IRT.
--> 
--> 2) they don't support load balancing of traffic across 
--> multiple links.
--> The charter says: "Load-splitting among multiple paths", it 
--> does not say
--> "only for unicast". TRILL needs to provide a set of trees 
--> in the CRED
--> (what I call shared trees) and let each ingress RBridge balance the
--> traffic on a subset of them.
--> 
--> In a network with 1000 RBridges, 1000 IRTs are 
--> computationally difficult
--> and don't provide load-splitting among multiple paths, 8 
--> shared trees
--> are easy to compute and provide load-splitting among multiple paths.
--> 
--> -- Silvano
--> 
--> 
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[e-mail]]
--> > Sent: Tuesday, October 31, 2006 9:19 AM
--> > To: Silvano Gai
--> > Cc: [e-mail]
--> > Subject: RE: [rbridge] Comments on: http://www.ietf.org/internet-
--> > drafts/draft-ietf-trill-rbridge-arch-01.txt
--> > 
--> > Silvano,
--> > 
--> > 	 See comments below...
--> > 
--> > --> -----Original Message-----
--> > --> From: [e-mail]
--> > --> [mailto:[e-mail]] On Behalf Of Silvano Gai
--> > --> Sent: Monday, October 30, 2006 12:13 PM
--> > --> To: [e-mail]
--> > --> Subject: [rbridge] Comments on:
--> > --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> > --> -arch-01.txt
--> > -->
--> > -->
--> > --> Comments inline marked "sgai n>"
--> > -->
--> > --> Sgai 1> This documents assumes that all multicast 
--> traffic must be
--> > --> propagated through the IRT (Ingress Rbridge Tree) and 
--> therefore
--> > --> denies any possibility for shared trees.
--> > 
--> > 
--> > I don't follow this comment.  Or perhaps I simply don't understand
--> > why this is our problem.
--> > 
--> > By creating ingress RBridge trees (as the concatenation 
--> of shortest
--> > path routes from an ingress to all egresses), we 
--> establish a "tree"
--> > which will deliver to all destinations in the broadcast 
--> domain.  If
--> > we then "prune" the tree for specific VLANs and multicast interest
--> > groups, we create "virtual trees" per-VLAN and for 
--> multicast groups.
--> > 
--> > In doing this, we are perhaps doing better than 
--> 802.1<whatever>, but
--> > we are still only trying to deliver broadcast, flooded 
--> and multicast
--> > frames to the destinations that 1) would receive them in 
--> an Ethernet
--> > network and 2) should receive them if optimizing an 
--> Ethernet network
--> > for IP multicast.
--> > 
--> > Frankly the intent to support optimization of IP 
--> multicast is a bit
--> > of a fragile compromise within the working group, but it is AFAIK
--> > what we are trying to do.
--> > 
--> > So, what I am trying to figure out is how what we're 
--> doing with the
--> > IRT differs from "shared tree" support with existing 
--> 802.1<whatever>
--> > bridges.
--> > 
--> > Are you saying that you would like RBridges to support the "shared
--> > tree" concept even though 802.1<whatever> bridges may or may not
--> > support it?
--> > 
--> > Or are you saying that there is something about the design of the
--> > ingress rbridge trees that get in the way of support for "shared
--> > trees" that might be provided in today's Ethernet bridges?
--> > 
--> > 
--> > -->
--> > --> -- Silvano
--> > -->
--> > --> --------------------------------------------------------
--> > -->
--> > --> ... snip ...
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA1G7ITO003239 for <[e-mail]>; Wed, 1 Nov 2006 08:07:19 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id kA1G7HfK028067; Wed, 1 Nov 2006 11:07:17 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22552;  Wed, 1 Nov 2006 11:07:16 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <WB647RBN>; Wed, 1 Nov 2006 11:07:15 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Silvano Gai <[e-mail]>
Date: Wed, 1 Nov 2006 11:07:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] VLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2006 16:07:39 -0000
Status: RO
Content-Length: 6680

Silvano,

	I believe I've stated my position on using the IVLAN/OVLAN
terminology, but just in case - I don't think it's necessary and
I don't think it helps.

	It seems to me that the description you provide below is an
ample demonstration of the confusion that the use of these terms
can introduce.

	For example, let's really complicate your example by using
stacked VLAN tagging both in the tunnel encapsulation and in the
native encapsulation for portions of the assumed domain.  In the
(deliberately) complicated model I've just described, what does
the IVLAN/OVLAN distinction mean?

	In fact, one reason not to distinguish the two is that - in
the text you're referring to - the impact of which it is that may
apply is nil.  Hence by not making a distinction, we're allowed a
certain economy in communicating.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[e-mail]] 
--> Sent: Wednesday, November 01, 2006 12:55 AM
--> To: Gray, Eric
--> Cc: [e-mail]
--> Subject: RE: [rbridge] VLANs
--> 
--> 
--> Eric,
--> 
--> I disagree and let me give you concrete examples why:
--> 
--> draft-ietf-trill-rbridge-protocol-00.txt says:
--> 
--> "each RBridge R1 
-->    will run a "core" instance of IS-IS for the core RBridge 
--> information,
--> 
-->    and an instance per VLAN that R1 is attached to, for the endnode 
-->    information for those VLANs."
--> 
--> If we are speaking of OVLAN, IMO an RBridge runs a core instance per
--> each OVLAN and on that instance it propagates the endnode 
--> information
--> for the IVLANs."
--> 
--> " The endnode information for VLAN A, which is carried in 
--> the VLAN A 
-->    IS-IS instance injected by R1, contains:"
--> 
--> This clearly refers to IVLAN.
--> 
--> draft-ietf-trill-prob-01.txt says:
--> 
--> It may alternately support 
-->    direct VLAN support, e.g., by the use of separate TRILL routing 
-->    protocol instances to separate traffic for each VLAN 
--> traversing a 
-->    TRILL solution.  
--> 
--> Is this an IVLAN or an OVLAN?
--> 
--> 
--> draft-ietf-trill-rbridge-arch-01.txt says
--> 
--> Ingress RBridge Tree: a tree computed for each edge RBridge - 
-->            and potentially for each VLAN in which that RBridge 
-->            participates
--> 
--> I assume this is an OVLAN, I don't think TRILL computes an 
--> IRT for each
--> IVLAN; it can prune an IRT for each VLAN.
--> 
--> In an email to Dinesh you wrote:
--> 
--> "Dinesh,
--> 
--> 	We're making semantic distinctions here.  I can easily define a
--> VLAN consisting of a group of RBridges that corresponds to the same
--> semantics as the FTAG.  "
--> 
--> Were you referring to an IVLAN or an OVLAN?
--> 
--> Also you claim that 16 bits are not sufficient for the RBridge ID.
--> Is the RBridge ID space replicated per each OVLAN or is it shared?
--> Does an RBridge have the same RBridge ID on all OVLANs?
--> 
--> I think we need to explicitly introduce the IVLAN and OVLAN 
--> concepts and
--> use them consistently. We don't want to hide complexity due 
--> to the lack
--> of nomenclature.
--> 
--> -- Silvano
--> 
--> 
--> 
--> 
--> 
-->   
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[e-mail]]
--> > Sent: Tuesday, October 31, 2006 9:04 AM
--> > To: Silvano Gai
--> > Cc: [e-mail]
--> > Subject: RE: [rbridge] VLANs
--> > 
--> > Silvano,
--> > 
--> > 	Actually, both "types" of VLANs are the same - applying at
--> > different layers, but defined using the same terminology.  Logic,
--> > semantics and applicability are the same.
--> > 
--> > 	For historic reasons, we are trying to avoid the terms you
--> > propose.  In fact, similar terms have been used previously and
--> > removed as confusing.  Without constant reminders, "inner" and
--> > "outer" will be taken in some instances as placement in the frame
--> > (as you are suggesting) or position relative to the CRED (a usage
--> > issue with the terms "ingress" and "egress" meaning "way in" and
--> > "way out" respectively).
--> > 
--> > 	Hence you are suggesting replacement with one potential
--> > are of confusion with another one we've earlier discarded.
--> > 
--> > 	The architecture document defines the term VLAN and - I am
--> > reasonably sure - uses that definition consistently.  Moreover,
--> > the architecture document tries to be agnostic about the use of
--> > VLANs - particularly with respect to VLAN tagged encapsulation
--> > and port-based VLANs, and where these things might apply.  The
--> > reason for this is simply that one aim of protocol development -
--> > especially at the architectural level - should be to avoid placing
--> > constraints on implementation beyond those explicitly required
--> > to ensure interoperability.
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: [e-mail]
--> > --> [mailto:[e-mail]] On Behalf Of Silvano Gai
--> > --> Sent: Monday, October 30, 2006 12:29 PM
--> > --> To: [e-mail]
--> > --> Subject: [rbridge] VLANs
--> > -->
--> > -->
--> > --> The second biggest issue I have with the four documents
--> > --> (first one being
--> > --> broadcast/multicast storm) is the definition of VLANs.
--> > -->
--> > --> I don't think the term VLAN is used consistently in 
--> the documents.
--> > -->
--> > --> 1) Sometimes VLAN refers to the VLANs present on the
--> > --> untagged frames,
--> > --> which must be propagated by ISIS, VLAN pruning must be
--> > --> performed and so
--> > --> on. They all share the same core instance of ISIS.
--> > -->
--> > --> 2) Sometimes VLANs refers to the fact that a CRED can be
--> > --> encapsulated
--> > --> into a VLAN (present as a 1Q tag in the outer header) and
--> > --> therefore ISIS
--> > --> will run per VLAN, i.e. there will be a core instance of
--> > --> ISIS per each
--> > --> VLAN. This seems to be the case in some part of the 
--> architectural
--> > --> document.
--> > -->
--> > --> I propose to name the former IVLAN (inner VLAN) and the latter
--> OVLAN
--> > --> (Outer VLAN), with reference to the position of the 1Q tag
--> > --> in the frame.
--> > -->
--> > --> This is also very relevant for the discussion that we need
--> > --> to complete
--> > --> on the FTAG: it is my understanding that some folks think
--> > --> that the FTAG
--> > --> is not needed, since there may be an OVLAN.
--> > -->
--> > --> Comments?
--> > -->
--> > --> -- Silvano
--> > -->
--> > --> _______________________________________________
--> > --> rbridge mailing list
--> > --> [e-mail]
--> > --> http://mailman.postel.org/mailman/listinfo/rbridge
--> > -->
-->