[rbridge] Differentiating multicast from unicast

[Eric.Gray at marconi.com (Gray, Eric)]

Radia,

	If I understand your meaning correctly, I think I agree.

	I believe using the 20th bit - to determine if the frame is to
be flooded, broadcast or multicast - overloads the concept somewhat
although I may not be understanding your comment.

	The reason why we've been talking about "deriving 19 bit nickname"
all along is because we were expecting to use the 20th bit to determine 
if the "nickname" label is the nickname of the ingress or the egress 
RBridge(s).

	As it happens - in the multicast, flood and broadcast cases - we 
want to use the ingress RBridge nickname (in the label) and in the one
remaining case (unicast-to-a-known-MAC-DA) we want to use the egress 
RBridge nickname.

	So the bit was always going to be used to distinguish the "send
it on the Ingress RBridge Tree" case from the "send it unicast to the
egress RBridge" case.

	However, we still want to use the appropriate outer MAC DA (i.e.
- multicast for multicast, broadcast for broadcast or unknown) as we
would otherwise not be able to take advantage of "broadcast delivery"
across a "legacy bridge" segment to deliver multicast, broadcast and
flooded frames to multiple "downstream" RBridges.  If we use unicast
MAC DA in the outer header, we will have to explicitly replicate the
frames in any upstream RBridge whenever it will be directly delivered
by that RBridge to more than one dowstream RBridge.

	In other words, given this (very simplistic) topology -

	  S-1 <---> RB-1 <---> B-1 <---> RB-2 <---> S-2
                              A
                              |
                              +---> RB-3 <---> S-3

- in order for RB-1 to deliver a frame with an unknown destination 
from segment S-1 to segments S-2 and S-3, RB-1 can use a broadcast
out header MAC DA, or it can explicitly replicate it using the MAC
DA for each of RB-2 and RB-3.

	Consequently, we need to use both the 20th bit and a correct
MAC DA in the outer encapsulation.  For one thing, we need to know
- from the outer encapsulation preferrably - whether each specific
frame is multicast (so that we might apply multicast optimization)
and (possibly) what VLAN it is part of (e.g. - if it is broadcast).

	Also see one or two other comments below.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> Sent: Thursday, June 29, 2006 1:35 PM
--> To: rbridge at postel.org
--> Subject: [rbridge] Differentiating multicast from unicast
--> 
--> The Trill protocol document refers to an expired internet draft (bryant,

--> et al) on using the pwe encoding for the shim header, and the coauthors 
--> on that document think the content should be moved into the protocol 
--> document, rather than keeping the seperate document alive and unexpired.

I am not sure that this is the appropriate course of action, but I am
okay with going this way for now.

--> 
--> Rereading the expired document, I realized that that specifies a 
--> different way of differentiating unicast from multicast than the base 
--> Trill protocol document does.

I don't think this is quite correct.  I think the base protocol document 
- as it was when we chartered the WG - implicitly made an assumption that
we would have to identify the source RBridge (ingress) for any flooded,
multicast or broadcast traffic, as it is otherwise infeasible to select
a non-looping shortest path on a hop-by-hop basis.

I don't think it has ever been a common understanding that we would be 
using an SPF routing protocol to do something strange like set up source
routed paths at the ingress.  And there is some awkwardness in using the 
ingress source MAC DA across the multiple RBridges - and inter-connecting 
LAN segments - if we intended to use the source MAC as part of the Inress 
RBridge Tree look up.

--> 
--> In the current base document, it says to differentiate based on whether
--> MAC address in the outer header is a layer 2 multicast or unicast MAC
--> address. 

Differentiate what?  Differentiate the forwarding table look up (to either
use the CFT-IRT or the CFT), to differentiate VLAN broadcasts and multicast
(so that we can optimize bandwidth utilization), or differentiate the way
that forwarding takes place in "legacy" portions of the network?

See the explanation above for why we should use both MAC and label to
differentiate these factors...

--> But in the expired pwe draft, it says to do it based on the 20th bit 
--> in the label field in the shim header (the other 19 bits in the label 
--> field used for the nickname).
-->

Which - in all previous discussions - is what I believed we all assumed
to be the case (though not quite as you've stated it).

The 20th bit is used simply to determine whether the frame is being 
forwarded on the Ingress RBridge Tree or not.  In other words, the 20th
bit determines whether the look up is made against the CFT or CFT-IRT
(because the nickname in the "label" is for the egress, or the ingress,
RBridge - respectively).

--> 
--> I think I like the 20th bit method better (the one in the expired
--> pwe draft), because in theory the campus might include links other 
--> than Ethernet links, and the outer header is a link-specific header
--> that gets removed and replaced hop by hop, and there might even be 
--> a link that does not have the concept of multicast addresses (for 
--> example, if I'd been designing Ethernet addresses for the original 
--> Ethernet, I wouldn't have set aside a bit in the address...I'd have 
--> just said "an address is an address, and it's just up to receivers 
--> what to listen to--if more than one is listening it becomes a 
--> multicast").
-->

The architecture document has some stuff in it about using the fact that 
the source MAC is not re-written as yet another way to detect a loop.

I think it is simpler if the entire MAC is re-written, however - as you 
suggest/imply here - and I can make the small number of changes it takes
to make it that way there.

For one thing, re-writing the entire MAC header in an outer encapsulation
will reduce the potential for "strange cases" in "legacy" bridge learning.

--> 
--> So unless anyone objects, now that we've agreed to the 4-byte pwe-style 
--> shim header, I'll change the method of differentiating multicast from 
--> unicast to be based on the 20th bit in the label field.
-->

I do not object, as long as we understand that this does not change the
fact that we _still_ need to use multicast/broadcast MAC DAs in the MAC
header - AND we still need to use this MAC DA information as part of the
forwarding look-up.

--> 
--> And also, could someone review the IS-IS encoding? (attached below)
--> 
--> Radia
--> 
-- [SNIP] --


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5TJBGp22136 for <[e-mail]>; Thu, 29 Jun 2006 12:11:16 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k5TJB9l6014794; Thu, 29 Jun 2006 15:11:09 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA17017;  Thu, 29 Jun 2006 15:11:09 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <N1GWTKXD>; Thu, 29 Jun 2006 15:11:08 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Radia Perlman <[e-mail]>, [e-mail]
Date: Thu, 29 Jun 2006 15:11:08 -0400
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] Differentiating multicast from unicast
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, 29 Jun 2006 19:12:24 -0000
Status: RO
Content-Length: 6735

Radia,

	If I understand your meaning correctly, I think I agree.

	I believe using the 20th bit - to determine if the frame is to
be flooded, broadcast or multicast - overloads the concept somewhat
although I may not be understanding your comment.

	The reason why we've been talking about "deriving 19 bit nickname"
all along is because we were expecting to use the 20th bit to determine 
if the "nickname" label is the nickname of the ingress or the egress 
RBridge(s).

	As it happens - in the multicast, flood and broadcast cases - we 
want to use the ingress RBridge nickname (in the label) and in the one
remaining case (unicast-to-a-known-MAC-DA) we want to use the egress 
RBridge nickname.

	So the bit was always going to be used to distinguish the "send
it on the Ingress RBridge Tree" case from the "send it unicast to the
egress RBridge" case.

	However, we still want to use the appropriate outer MAC DA (i.e.
- multicast for multicast, broadcast for broadcast or unknown) as we
would otherwise not be able to take advantage of "broadcast delivery"
across a "legacy bridge" segment to deliver multicast, broadcast and
flooded frames to multiple "downstream" RBridges.  If we use unicast
MAC DA in the outer header, we will have to explicitly replicate the
frames in any upstream RBridge whenever it will be directly delivered
by that RBridge to more than one dowstream RBridge.

	In other words, given this (very simplistic) topology -

	  S-1 <---> RB-1 <---> B-1 <---> RB-2 <---> S-2
                              A
                              |
                              +---> RB-3 <---> S-3

- in order for RB-1 to deliver a frame with an unknown destination 
from segment S-1 to segments S-2 and S-3, RB-1 can use a broadcast
out header MAC DA, or it can explicitly replicate it using the MAC
DA for each of RB-2 and RB-3.

	Consequently, we need to use both the 20th bit and a correct
MAC DA in the outer encapsulation.  For one thing, we need to know
- from the outer encapsulation preferrably - whether each specific
frame is multicast (so that we might apply multicast optimization)
and (possibly) what VLAN it is part of (e.g. - if it is broadcast).

	Also see one or two other comments below.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Radia Perlman
--> Sent: Thursday, June 29, 2006 1:35 PM
--> To: [e-mail]
--> Subject: [rbridge] Differentiating multicast from unicast
--> 
--> The Trill protocol document refers to an expired internet draft (bryant,

--> et al) on using the pwe encoding for the shim header, and the coauthors 
--> on that document think the content should be moved into the protocol 
--> document, rather than keeping the seperate document alive and unexpired.

I am not sure that this is the appropriate course of action, but I am
okay with going this way for now.

--> 
--> Rereading the expired document, I realized that that specifies a 
--> different way of differentiating unicast from multicast than the base 
--> Trill protocol document does.

I don't think this is quite correct.  I think the base protocol document 
- as it was when we chartered the WG - implicitly made an assumption that
we would have to identify the source RBridge (ingress) for any flooded,
multicast or broadcast traffic, as it is otherwise infeasible to select
a non-looping shortest path on a hop-by-hop basis.

I don't think it has ever been a common understanding that we would be 
using an SPF routing protocol to do something strange like set up source
routed paths at the ingress.  And there is some awkwardness in using the 
ingress source MAC DA across the multiple RBridges - and inter-connecting 
LAN segments - if we intended to use the source MAC as part of the Inress 
RBridge Tree look up.

--> 
--> In the current base document, it says to differentiate based on whether
--> MAC address in the outer header is a layer 2 multicast or unicast MAC
--> address. 

Differentiate what?  Differentiate the forwarding table look up (to either
use the CFT-IRT or the CFT), to differentiate VLAN broadcasts and multicast
(so that we can optimize bandwidth utilization), or differentiate the way
that forwarding takes place in "legacy" portions of the network?

See the explanation above for why we should use both MAC and label to
differentiate these factors...

--> But in the expired pwe draft, it says to do it based on the 20th bit 
--> in the label field in the shim header (the other 19 bits in the label 
--> field used for the nickname).
-->

Which - in all previous discussions - is what I believed we all assumed
to be the case (though not quite as you've stated it).

The 20th bit is used simply to determine whether the frame is being 
forwarded on the Ingress RBridge Tree or not.  In other words, the 20th
bit determines whether the look up is made against the CFT or CFT-IRT
(because the nickname in the "label" is for the egress, or the ingress,
RBridge - respectively).

--> 
--> I think I like the 20th bit method better (the one in the expired
--> pwe draft), because in theory the campus might include links other 
--> than Ethernet links, and the outer header is a link-specific header
--> that gets removed and replaced hop by hop, and there might even be 
--> a link that does not have the concept of multicast addresses (for 
--> example, if I'd been designing Ethernet addresses for the original 
--> Ethernet, I wouldn't have set aside a bit in the address...I'd have 
--> just said "an address is an address, and it's just up to receivers 
--> what to listen to--if more than one is listening it becomes a 
--> multicast").
-->

The architecture document has some stuff in it about using the fact that 
the source MAC is not re-written as yet another way to detect a loop.

I think it is simpler if the entire MAC is re-written, however - as you 
suggest/imply here - and I can make the small number of changes it takes
to make it that way there.

For one thing, re-writing the entire MAC header in an outer encapsulation
will reduce the potential for "strange cases" in "legacy" bridge learning.

--> 
--> So unless anyone objects, now that we've agreed to the 4-byte pwe-style 
--> shim header, I'll change the method of differentiating multicast from 
--> unicast to be based on the 20th bit in the label field.
-->

I do not object, as long as we understand that this does not change the
fact that we _still_ need to use multicast/broadcast MAC DAs in the MAC
header - AND we still need to use this MAC DA information as part of the
forwarding look-up.

--> 
--> And also, could someone review the IS-IS encoding? (attached below)
--> 
--> Radia
--> 
-- [SNIP] --


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5THZQp16916 for <[e-mail]>; Thu, 29 Jun 2006 10:35:26 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 29 Jun 2006 10:35:14 -0700 (PDT)
Received: from sun.com ([129.150.20.235]) 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, 29 Jun 2006 10:35:13 -0700 (PDT)
Date: Thu, 29 Jun 2006 10:35:12 -0700
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]> <[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] Differentiating multicast from unicast
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, 29 Jun 2006 17:36:20 -0000
Status: RO
Content-Length: 3385

The Trill protocol document refers to an expired internet draft (bryant, 
et al)
on using the pwe encoding for the shim header,
and the coauthors on that document think the content should be moved 
into the protocol document, rather than
keeping the seperate document alive and unexpired.

Rereading the expired document, I realized that that specifies a 
different way of differentiating
unicast from multicast than the base Trill protocol document does.

In the current base document, it says to differentiate based on whether the
MAC address in the outer header is a layer 2 multicast or unicast MAC
address. But in the expired pwe draft, it says to do it based
on the 20th bit in the label field in the shim header (the other 19 bits 
in the label field used for the nickname).

I think I like the 20th bit method better (the one in the expired
pwe draft), because in theory the campus might include links other than
Ethernet links, and the outer header is a link-specific header that gets 
removed and replaced hop by hop,
and there might even be a link that does not have the concept of 
multicast addresses (for example,
if I'd been designing
Ethernet addresses for the original Ethernet, I wouldn't have set aside 
a bit in the address...I'd have just said
"an address is an address, and it's just up to receivers what to listen 
to--if more than one is listening
it becomes a multicast").

So unless anyone objects, now that we've agreed to the 4-byte pwe-style 
shim header, I'll change
the method of differentiating multicast from unicast to be based on the 
20th bit in the label field.

And also, could someone review the IS-IS encoding? (attached below)

Radia



Radia Perlman wrote:

>1) layer 3 IS-IS LSPs
>
>It would be fine to treat these like any other layer 2 multicasts.
>The only reason to do anything different would be if we want to
>optimize distribution of these to go only to links on which there
>are IS-IS routers. RBridges could recognize such packets because the
>inner header would indicate the IS-IS DSAP. So I'm assuming these
>will be encapsulated just like any layer 2 multicast.
>
>2) core IS-IS instance for RBridges (these are the IS-IS packets by
>which RBridges inform each other about RBridge-to-RBridge connectivity.
>
>Outer header:
>  Destination=new (to be assigned) layer 2 multicast address,
>   indicating "core RBridge IS-IS packet"
>  Source=transmitting RBridge
>  protocol type=encapsulated RBridge packet
>
>Shim header: TTL and ingress RBridge (in PWE format as defined in the 
>unfortunately
>expired internet draft by Bryant, et al)
>
>No inner layer 2 header: IS-IS packet immediately follows
>
>3) per-VLAN IS-IS instance for RBridges (these are the IS-IS packets by
>which RBridges in a particular VLAN inform other RBridges attached to
>the same VLAN of where the endnodes, multicast receivers, and multicast
>routers associated with that VLAN are)
>
>
>Outer header:
>  Destination=second new (to be assigned) layer 2 multicast address,
>   indicating "per-VLAN RBridge IS-IS packet"
>  Source=transmitting RBridge
>  protocol type=encapsulated RBridge packet
>
>Shim header: TTL and ingress RBridge
>
>No inner layer 2 header:, just VLAN tag,
>followed by IS-IS packet
>
>_______________________________________________
>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.11.6p2+0917/8.11.2) with ESMTP id k5SKJsp26597 for <[e-mail]>; Wed, 28 Jun 2006 13:19:55 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 225FBD59CF; Wed, 28 Jun 2006 22:19:48 +0200 (CEST)
Received: from [10.0.0.4] (39.Red-80-37-137.staticIP.rima-tde.net [80.37.137.39]) by smtp01.uc3m.es (Postfix) with ESMTP id 4465CD59B0; Wed, 28 Jun 2006 22:19:47 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 28 Jun 2006 22:19:44 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Masanori Takashima <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Comments on draft-ietf-trill-prob-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: Wed, 28 Jun 2006 20:20:07 -0000
Status: RO
Content-Length: 2212

I do agree. It seems that, as shown in the second paper, (I cite 
aproximately "...when the network gets partitioned and the part that 
does not
contain the previous root bridge has a cycle, a count to infinity may 
occur"). 
Regards
Guillermo

Masanori Takashima wrote:

>Hi,
>
>I think, in addition, that those two papers are helpful to understand
>RSTP causing large changes. Especially, the latter one shows us how
>bad it is when root bridge in outside ring disappers. Russ expains
>that root bridge is inside ring, but the paper explains root bridge in
>outside ring.
>
>- A. Myers, T. E. Ng, and H. Zhang. Rethinking the Service Model:
>Scaling Ethernet to a Million Nodes. In Third Workshop on Hot Topics
>in networks (HotNets-III), Mar. 2004.
>- K. Elmeleegy, A.L. Cox and T. E. Ng, On Count-to-Infinity Induced
>Forwarding Loops in Ethernet Networks. In Infocom '06, April. 2006.
>
>
>Masanori
>-------------------------------------------
>  
>
>>   The spanning tree is dependent on the way a set of bridges are
>>   interconnected, i.e., the link layer topology. Small changes in this
>>   topology can cause large changes in the spanning tree. Changes in the
>>   spanning tree can take time to propagate and converge.
>>
>>   [QUESTION: is there a good visual example of this, one that we can
>>   walk through in the description?]
>>
>>I think the absolute worst case is when one of the branches connected
>>to the root bridge fails, causing a large number of ports to
>>block and unblock before the network would reconverge. Perhaps a ring
>>would show enough to explain, however (?):
>>
>>A----B----C----D----E
>>|                                        |
>>+-----F-----G-------+
>>
>>If A is the root bridge, then we can assume the paths A->B->C->D and
>>A->F->G->E are the two open paths, while the D->E link is blocked in
>>both directions (just using hop count). If the A->B link fails, then E
>>must unblock its port to D for traffic to flow again, but it may
>>require recomputation of the entire tree through BPDUs, I think (?).
>>    
>>
>_______________________________________________
>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.171]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5SJibp15763 for <[e-mail]>; Wed, 28 Jun 2006 12:44:37 -0700 (PDT)
Received: by ug-out-1314.google.com with SMTP id j3so3126778ugf for <[e-mail]>; Wed, 28 Jun 2006 12:44:31 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CiUgeqH04XxlPlUxo7t/W0sAH7bL92TewhHZ8GbMBX2uhU0Ww9t3VT0oB53pGAUE75XxZl7IjNuJUtc4NU53w3qWiIMBYO5IrHPpI2dhZlrf62hRRxqhAKpZlFt35co4+zB0MY+7U4anDWF+m7dJuTCFFhTfHxuQDMvUEQDGNGI=
Received: by 10.66.219.11 with SMTP id r11mr1082960ugg; Wed, 28 Jun 2006 12:44:31 -0700 (PDT)
Received: by 10.66.218.14 with HTTP; Wed, 28 Jun 2006 12:44:31 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 28 Jun 2006 15:44:31 -0400
From: "Masanori Takashima" <[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-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Comments on draft-ietf-trill-prob-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: Wed, 28 Jun 2006 19:45:29 -0000
Status: RO
Content-Length: 1754

Hi,

I think, in addition, that those two papers are helpful to understand
RSTP causing large changes. Especially, the latter one shows us how
bad it is when root bridge in outside ring disappers. Russ expains
that root bridge is inside ring, but the paper explains root bridge in
outside ring.

- A. Myers, T. E. Ng, and H. Zhang. Rethinking the Service Model:
Scaling Ethernet to a Million Nodes. In Third Workshop on Hot Topics
in networks (HotNets-III), Mar. 2004.
- K. Elmeleegy, A.L. Cox and T. E. Ng, On Count-to-Infinity Induced
Forwarding Loops in Ethernet Networks. In Infocom '06, April. 2006.


Masanori
-------------------------------------------
>    The spanning tree is dependent on the way a set of bridges are
>    interconnected, i.e., the link layer topology. Small changes in this
>    topology can cause large changes in the spanning tree. Changes in the
>    spanning tree can take time to propagate and converge.
>
>    [QUESTION: is there a good visual example of this, one that we can
>    walk through in the description?]
>
> I think the absolute worst case is when one of the branches connected
> to the root bridge fails, causing a large number of ports to
> block and unblock before the network would reconverge. Perhaps a ring
> would show enough to explain, however (?):
>
> A----B----C----D----E
> |                                        |
> +-----F-----G-------+
>
> If A is the root bridge, then we can assume the paths A->B->C->D and
> A->F->G->E are the two open paths, while the D->E link is blocked in
> both directions (just using hop count). If the A->B link fails, then E
> must unblock its port to D for traffic to flow again, but it may
> require recomputation of the entire tree through BPDUs, I think (?).


Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5NIBxp29954 for <[e-mail]>; Fri, 23 Jun 2006 11:11:59 -0700 (PDT)
Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k5NIBwSq000250 for <[e-mail]>; Fri, 23 Jun 2006 11:11:58 -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 k5NIBv8O025486 for <[e-mail]>; Fri, 23 Jun 2006 13:11:58 -0500 (CDT)
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, 23 Jun 2006 14:11:56 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: TRILL Montreal agenda posted
Thread-Index: AcaW8IOF3QcRm+S6R3mjOt1JqHEW7A==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
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 k5NIBxp29954
Subject: [rbridge] TRILL Montreal agenda posted
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, 23 Jun 2006 18:12:17 -0000
Status: RO
Content-Length: 433

Hi,

The tentative agenda for the Montreal TRILL meeting next month has been
posted at http://www3.ietf.org/proceedings/06jul/agenda/trill.txt.
People should send me presentations so they can also be posted in
advance.

By the way, if you are not too familiar with the IETF, there is a new
draft of a revised version of the "Tao of the IETF" document:
http://www.ietf.org/internet-drafts/draft-hoffman-taobis-08.txt.

Thanks,
Donald


Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5N0Q0p15229 for <[e-mail]>; Thu, 22 Jun 2006 17:26:00 -0700 (PDT)
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 22 Jun 2006 20:25:54 -0400
X-IronPort-AV: i="4.06,167,1149480000";  d="scan'208"; a="90833143:sNHT33804300"
Received: from [10.20.218.174] (rtp-vpn3-395.cisco.com [10.82.217.141]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5N0Prno000989;  Thu, 22 Jun 2006 20:25:53 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 22 Jun 2006 20:25:57 -0400
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
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] Use of the term "campus"
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, 23 Jun 2006 00:26:28 -0000
Status: RO
Content-Length: 5581

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


LAN seems to me to be the best term, or "broadcast domain," but then,
that's too long, probably.

:-)

Russ

Guillermo Ib??ez wrote:
> Eric,
> The term LAN seems the closest. If new terms are allowed, what about 
> campuswide LAN (CLAN) ?  
> Regards
> Guillermo
> 
> Gray, Eric wrote:
> 
>> Guillermo,
>>
>> 	It's not particularly useful to try to resolve all of
>> these terminology inconsistencies in any general sense.
>>
>> 	For example, the argument that "campus" as used to mean
>> "site" is more consistent with "bridge connected network" than
>> "LAN" is, makes some stark assumptions about how someone sets
>> up their network within a site and/or across multiple sites.
>>
>> 	I've certainly seen networks where a single site has
>> many different IP subnets (frequently separated by routers), 
>> and I've even seen a few networks where a single LAN spans 
>> several sites. (What is a L2VPN for, otherwise?)
>>
>> 	What I'm trying to do is to get us using some terms
>> consistently - without necessarily making up some non-sense
>> syllables as we go along.
>>
>> 	I believe "LAN" as I described it is consistent in 
>> comparison with "VLAN" - meaning that a LAN is a single
>> broadcast domain in the normal sense but this may change
>> as a result of virtualization.
>>
>> 	But if nobody else agrees with this, then somebody
>> needs to suggest an alternative term to replace campus in
>> the sense that we've been discussing it on this list for 
>> about a year now.  If not, then I guess I'll have to make 
>> something up.
>>
>> 	One thing we keep losing sight of here is that this
>> solution is supposed to support VLANs, which is not at all
>> the same as "not support anything else."
>>
>> --
>> Eric
>>
>> --> -----Original Message-----
>> --> From: Guillermo Ib??ez [mailto:[e-mail]] 
>> --> Sent: Thursday, June 22, 2006 3:05 PM
>> --> To: Radia Perlman
>> --> Cc: Joe Touch; Gray, Eric; [e-mail]
>> --> Subject: Re: [rbridge] Use of the term "campus"
>> --> 
>> --> I meant routers in the sense tthat current campus networks include 
>> --> routers/multilayer switches. I agree with Radia that in the 
>> --> Rbridges 
>> --> context the routers are at the edge of campus.
>> --> The term corporate network is used sometimes for a network covering 
>> --> different distant sites. Intranet might coincide in 
>> --> coverage, although 
>> --> in meaning usually is used as oposed to extranet or Internet.
>> --> Guillermo
>> --> 
>> --> Radia Perlman wrote:
>> --> 
>> --> > I agree with Guillermo...that "campus" covers not just 
>> --> the rbridges, 
>> --> > but the LAN segments and the attached nodes.
>> --> > But I wouldn't include segments connected via routers. For that, 
>> --> > perhaps "corporate network" or "intranet".
>> --> >
>> --> > (I did reply, but I said "reply" rather than "reply 
>> --> all"...I forgot 
>> --> > that this mailing list no longer has "reply-to"
>> --> > set to the list).
>> --> >
>> --> > Radia
>> --> >
>> --> > Guillermo Ib??ez wrote:
>> --> >
>> --> >> Eric,
>> --> >> The usual meaning of  campus network IMHO, refers to a  
>> --> set of  LANs 
>> --> >> covering several buildings, normally including routers 
>> --> or multilayer 
>> --> >> switches, switches and end nodes.
>> --> >> To use a campus for the set of RBridges on a segment seems a bit 
>> --> >> confusing.  The  LAN segment term seems correct.
>> --> >> Regards
>> --> >> Guillermo
>> --> >> Joe Touch wrote:
>> --> >>
>> --> >>> Gray, Eric wrote:
>> --> >>>  
>> --> >>>
>> --> >>>> Radia,
>> --> >>>>
>> --> >>>>     I am having some trouble resolving the use of "campus"
>> --> >>>> in the currently available protocol specification with 
>> --> the way that 
>> --> >>>> it has been used in other documents, mailing list
>> --> >>>> discussion, etc.
>> --> >>>>
>> --> >>>>     In the protocol specification, "campus" is defined as
>> --> >>>> synonymous with the usual definition of "LAN".  Is this use
>> --> >>>> central to the rest of the document?  If so, can we use the
>> --> >>>> word "LAN" instead?
>> --> >>>>   
>> --> >>>
>> --> >>>
>> --> >>>
>> --> >>> I thought:
>> --> >>>
>> --> >>>     - segment
>> --> >>>         what 802 refers to when describing an ethernet LAN
>> --> >>>         or a single VLAN on a VLAN-capable network
>> --> >>>
>> --> >>>     - campus
>> --> >>>         the set of rbridges on a segment that cooperate
>> --> >>>         together
>> --> >>>
>> --> >>> I don't know if 802 has a term that describes the set 
>> --> of all VLANs that
>> --> >>> share an infrastructure.
>> --> >>>
>> --> >>> I would avoid the term LAN, as it could mean VLAN or 
>> --> segment, and I
>> --> >>> don't think that's the intent.
>> --> >>>
>> --> >>> Joe
>> --> >>>
>> --> >>>  
>> --> >>>
>> --> >>> 
>> --> ------------------------------------------------------------
>> --> ------------ 
>> --> >>>
>> --> >>>
>> --> >>> _______________________________________________
>> --> >>> rbridge mailing list
>> --> >>> [e-mail]
>> --> >>> http://mailman.postel.org/mailman/listinfo/rbridge
>> --> >>>  
>> --> >>>
>> --> >
>> --> 
>>  
>>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEmzUUER27sUhU9OQRAhIEAJ9FHrQLwESdZ5Bzr0xnH3Wa9ebdvgCg0wrH
3bMzOuth2mMnetBPbGRVZkc=
=JGzT
-----END PGP SIGNATURE-----


Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5MKjBp06022 for <[e-mail]>; Thu, 22 Jun 2006 13:45:11 -0700 (PDT)
Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5MKiY212092; Thu, 22 Jun 2006 13:44:34 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 22 Jun 2006 13:46:06 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
References: <[e-mail]> <[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="------------enig0B7F30259CE106E9BD7A8BAC"
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] Use of the term "campus"
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, 22 Jun 2006 20:46:07 -0000
Status: RO
Content-Length: 6133

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

I'd prefer using an existing term for an exisitng idea; so far, we're
either talking about an ethernet segment (i.e., a broadcast domain) or a
LAN.

Joe


Guillermo Ib=E1=F1ez wrote:
> Eric,
> The term LAN seems the closest. If new terms are allowed, what about=20
> campuswide LAN (CLAN) ? =20
> Regards
> Guillermo
>=20
> Gray, Eric wrote:
>=20
>> Guillermo,
>>
>> 	It's not particularly useful to try to resolve all of
>> these terminology inconsistencies in any general sense.
>>
>> 	For example, the argument that "campus" as used to mean
>> "site" is more consistent with "bridge connected network" than
>> "LAN" is, makes some stark assumptions about how someone sets
>> up their network within a site and/or across multiple sites.
>>
>> 	I've certainly seen networks where a single site has
>> many different IP subnets (frequently separated by routers),=20
>> and I've even seen a few networks where a single LAN spans=20
>> several sites. (What is a L2VPN for, otherwise?)
>>
>> 	What I'm trying to do is to get us using some terms
>> consistently - without necessarily making up some non-sense
>> syllables as we go along.
>>
>> 	I believe "LAN" as I described it is consistent in=20
>> comparison with "VLAN" - meaning that a LAN is a single
>> broadcast domain in the normal sense but this may change
>> as a result of virtualization.
>>
>> 	But if nobody else agrees with this, then somebody
>> needs to suggest an alternative term to replace campus in
>> the sense that we've been discussing it on this list for=20
>> about a year now.  If not, then I guess I'll have to make=20
>> something up.
>>
>> 	One thing we keep losing sight of here is that this
>> solution is supposed to support VLANs, which is not at all
>> the same as "not support anything else."
>>
>> --
>> Eric
>>
>> --> -----Original Message-----
>> --> From: Guillermo Ib=E1=F1ez [mailto:[e-mail]]=20
>> --> Sent: Thursday, June 22, 2006 3:05 PM
>> --> To: Radia Perlman
>> --> Cc: Joe Touch; Gray, Eric; [e-mail]
>> --> Subject: Re: [rbridge] Use of the term "campus"
>> -->=20
>> --> I meant routers in the sense tthat current campus networks include=
=20
>> --> routers/multilayer switches. I agree with Radia that in the=20
>> --> Rbridges=20
>> --> context the routers are at the edge of campus.
>> --> The term corporate network is used sometimes for a network coverin=
g=20
>> --> different distant sites. Intranet might coincide in=20
>> --> coverage, although=20
>> --> in meaning usually is used as oposed to extranet or Internet.
>> --> Guillermo
>> -->=20
>> --> Radia Perlman wrote:
>> -->=20
>> --> > I agree with Guillermo...that "campus" covers not just=20
>> --> the rbridges,=20
>> --> > but the LAN segments and the attached nodes.
>> --> > But I wouldn't include segments connected via routers. For that,=
=20
>> --> > perhaps "corporate network" or "intranet".
>> --> >
>> --> > (I did reply, but I said "reply" rather than "reply=20
>> --> all"...I forgot=20
>> --> > that this mailing list no longer has "reply-to"
>> --> > set to the list).
>> --> >
>> --> > Radia
>> --> >
>> --> > Guillermo Ib=E1=F1ez wrote:
>> --> >
>> --> >> Eric,
>> --> >> The usual meaning of  campus network IMHO, refers to a =20
>> --> set of  LANs=20
>> --> >> covering several buildings, normally including routers=20
>> --> or multilayer=20
>> --> >> switches, switches and end nodes.
>> --> >> To use a campus for the set of RBridges on a segment seems a bi=
t=20
>> --> >> confusing.  The  LAN segment term seems correct.
>> --> >> Regards
>> --> >> Guillermo
>> --> >> Joe Touch wrote:
>> --> >>
>> --> >>> Gray, Eric wrote:
>> --> >>> =20
>> --> >>>
>> --> >>>> Radia,
>> --> >>>>
>> --> >>>>     I am having some trouble resolving the use of "campus"
>> --> >>>> in the currently available protocol specification with=20
>> --> the way that=20
>> --> >>>> it has been used in other documents, mailing list
>> --> >>>> discussion, etc.
>> --> >>>>
>> --> >>>>     In the protocol specification, "campus" is defined as
>> --> >>>> synonymous with the usual definition of "LAN".  Is this use
>> --> >>>> central to the rest of the document?  If so, can we use the
>> --> >>>> word "LAN" instead?
>> --> >>>>  =20
>> --> >>>
>> --> >>>
>> --> >>>
>> --> >>> I thought:
>> --> >>>
>> --> >>>     - segment
>> --> >>>         what 802 refers to when describing an ethernet LAN
>> --> >>>         or a single VLAN on a VLAN-capable network
>> --> >>>
>> --> >>>     - campus
>> --> >>>         the set of rbridges on a segment that cooperate
>> --> >>>         together
>> --> >>>
>> --> >>> I don't know if 802 has a term that describes the set=20
>> --> of all VLANs that
>> --> >>> share an infrastructure.
>> --> >>>
>> --> >>> I would avoid the term LAN, as it could mean VLAN or=20
>> --> segment, and I
>> --> >>> don't think that's the intent.
>> --> >>>
>> --> >>> Joe
>> --> >>>
>> --> >>> =20
>> --> >>>
>> --> >>>=20
>> --> ------------------------------------------------------------
>> --> ------------=20
>> --> >>>
>> --> >>>
>> --> >>> _______________________________________________
>> --> >>> rbridge mailing list
>> --> >>> [e-mail]
>> --> >>> http://mailman.postel.org/mailman/listinfo/rbridge
>> --> >>> =20
>> --> >>>
>> --> >
>> -->=20
>> =20
>>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge


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

iD8DBQFEmwGOE5f5cImnZrsRAuvzAKCN01NThGd/0W0M/tEgKh4xJI3UQQCfWabx
gkTx/zKJHuxZ7QT+Sk9PoqA=
=l/92
-----END PGP SIGNATURE-----

--------------enig0B7F30259CE106E9BD7A8BAC--


Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5MKaJp03533 for <[e-mail]>; Thu, 22 Jun 2006 13:36:20 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F1851D5A67; Thu, 22 Jun 2006 22:36:13 +0200 (CEST)
Received: from [10.0.0.4] (39.Red-80-37-137.staticIP.rima-tde.net [80.37.137.39]) by smtp01.uc3m.es (Postfix) with ESMTP id B547FD5A5D; Thu, 22 Jun 2006 22:36:12 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 22 Jun 2006 22:36:11 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "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]
Subject: Re: [rbridge] Use of the term "campus"
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, 22 Jun 2006 20:37:18 -0000
Status: RO
Content-Length: 4721

Eric,
The term LAN seems the closest. If new terms are allowed, what about 
campuswide LAN (CLAN) ?  
Regards
Guillermo

Gray, Eric wrote:

>Guillermo,
>
>	It's not particularly useful to try to resolve all of
>these terminology inconsistencies in any general sense.
>
>	For example, the argument that "campus" as used to mean
>"site" is more consistent with "bridge connected network" than
>"LAN" is, makes some stark assumptions about how someone sets
>up their network within a site and/or across multiple sites.
>
>	I've certainly seen networks where a single site has
>many different IP subnets (frequently separated by routers), 
>and I've even seen a few networks where a single LAN spans 
>several sites. (What is a L2VPN for, otherwise?)
>
>	What I'm trying to do is to get us using some terms
>consistently - without necessarily making up some non-sense
>syllables as we go along.
>
>	I believe "LAN" as I described it is consistent in 
>comparison with "VLAN" - meaning that a LAN is a single
>broadcast domain in the normal sense but this may change
>as a result of virtualization.
>
>	But if nobody else agrees with this, then somebody
>needs to suggest an alternative term to replace campus in
>the sense that we've been discussing it on this list for 
>about a year now.  If not, then I guess I'll have to make 
>something up.
>
>	One thing we keep losing sight of here is that this
>solution is supposed to support VLANs, which is not at all
>the same as "not support anything else."
>
>--
>Eric
>
>--> -----Original Message-----
>--> From: Guillermo Ib??ez [mailto:[e-mail]] 
>--> Sent: Thursday, June 22, 2006 3:05 PM
>--> To: Radia Perlman
>--> Cc: Joe Touch; Gray, Eric; [e-mail]
>--> Subject: Re: [rbridge] Use of the term "campus"
>--> 
>--> I meant routers in the sense tthat current campus networks include 
>--> routers/multilayer switches. I agree with Radia that in the 
>--> Rbridges 
>--> context the routers are at the edge of campus.
>--> The term corporate network is used sometimes for a network covering 
>--> different distant sites. Intranet might coincide in 
>--> coverage, although 
>--> in meaning usually is used as oposed to extranet or Internet.
>--> Guillermo
>--> 
>--> Radia Perlman wrote:
>--> 
>--> > I agree with Guillermo...that "campus" covers not just 
>--> the rbridges, 
>--> > but the LAN segments and the attached nodes.
>--> > But I wouldn't include segments connected via routers. For that, 
>--> > perhaps "corporate network" or "intranet".
>--> >
>--> > (I did reply, but I said "reply" rather than "reply 
>--> all"...I forgot 
>--> > that this mailing list no longer has "reply-to"
>--> > set to the list).
>--> >
>--> > Radia
>--> >
>--> > Guillermo Ib??ez wrote:
>--> >
>--> >> Eric,
>--> >> The usual meaning of  campus network IMHO, refers to a  
>--> set of  LANs 
>--> >> covering several buildings, normally including routers 
>--> or multilayer 
>--> >> switches, switches and end nodes.
>--> >> To use a campus for the set of RBridges on a segment seems a bit 
>--> >> confusing.  The  LAN segment term seems correct.
>--> >> Regards
>--> >> Guillermo
>--> >> Joe Touch wrote:
>--> >>
>--> >>> Gray, Eric wrote:
>--> >>>  
>--> >>>
>--> >>>> Radia,
>--> >>>>
>--> >>>>     I am having some trouble resolving the use of "campus"
>--> >>>> in the currently available protocol specification with 
>--> the way that 
>--> >>>> it has been used in other documents, mailing list
>--> >>>> discussion, etc.
>--> >>>>
>--> >>>>     In the protocol specification, "campus" is defined as
>--> >>>> synonymous with the usual definition of "LAN".  Is this use
>--> >>>> central to the rest of the document?  If so, can we use the
>--> >>>> word "LAN" instead?
>--> >>>>   
>--> >>>
>--> >>>
>--> >>>
>--> >>> I thought:
>--> >>>
>--> >>>     - segment
>--> >>>         what 802 refers to when describing an ethernet LAN
>--> >>>         or a single VLAN on a VLAN-capable network
>--> >>>
>--> >>>     - campus
>--> >>>         the set of rbridges on a segment that cooperate
>--> >>>         together
>--> >>>
>--> >>> I don't know if 802 has a term that describes the set 
>--> of all VLANs that
>--> >>> share an infrastructure.
>--> >>>
>--> >>> I would avoid the term LAN, as it could mean VLAN or 
>--> segment, and I
>--> >>> don't think that's the intent.
>--> >>>
>--> >>> Joe
>--> >>>
>--> >>>  
>--> >>>
>--> >>> 
>--> ------------------------------------------------------------
>--> ------------ 
>--> >>>
>--> >>>
>--> >>> _______________________________________________
>--> >>> 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.11.6p2+0917/8.11.2) with ESMTP id k5MJRQp12078 for <[e-mail]>; Thu, 22 Jun 2006 12:27:26 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k5MJRIl6020081; Thu, 22 Jun 2006 15:27:18 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA12798;  Thu, 22 Jun 2006 15:27:18 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <N1GWKZTS>; Thu, 22 Jun 2006 15:27:17 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
Date: Thu, 22 Jun 2006 15:27:17 -0400
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 k5MJRQp12078
Cc: [e-mail]
Subject: Re: [rbridge] Use of the term "campus"
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, 22 Jun 2006 19:28:16 -0000
Status: RO
Content-Length: 4438

Guillermo,

	It's not particularly useful to try to resolve all of
these terminology inconsistencies in any general sense.

	For example, the argument that "campus" as used to mean
"site" is more consistent with "bridge connected network" than
"LAN" is, makes some stark assumptions about how someone sets
up their network within a site and/or across multiple sites.

	I've certainly seen networks where a single site has
many different IP subnets (frequently separated by routers), 
and I've even seen a few networks where a single LAN spans 
several sites. (What is a L2VPN for, otherwise?)

	What I'm trying to do is to get us using some terms
consistently - without necessarily making up some non-sense
syllables as we go along.

	I believe "LAN" as I described it is consistent in 
comparison with "VLAN" - meaning that a LAN is a single
broadcast domain in the normal sense but this may change
as a result of virtualization.

	But if nobody else agrees with this, then somebody
needs to suggest an alternative term to replace campus in
the sense that we've been discussing it on this list for 
about a year now.  If not, then I guess I'll have to make 
something up.

	One thing we keep losing sight of here is that this
solution is supposed to support VLANs, which is not at all
the same as "not support anything else."

--
Eric

--> -----Original Message-----
--> From: Guillermo Ib??ez [mailto:[e-mail]] 
--> Sent: Thursday, June 22, 2006 3:05 PM
--> To: Radia Perlman
--> Cc: Joe Touch; Gray, Eric; [e-mail]
--> Subject: Re: [rbridge] Use of the term "campus"
--> 
--> I meant routers in the sense tthat current campus networks include 
--> routers/multilayer switches. I agree with Radia that in the 
--> Rbridges 
--> context the routers are at the edge of campus.
--> The term corporate network is used sometimes for a network covering 
--> different distant sites. Intranet might coincide in 
--> coverage, although 
--> in meaning usually is used as oposed to extranet or Internet.
--> Guillermo
--> 
--> Radia Perlman wrote:
--> 
--> > I agree with Guillermo...that "campus" covers not just 
--> the rbridges, 
--> > but the LAN segments and the attached nodes.
--> > But I wouldn't include segments connected via routers. For that, 
--> > perhaps "corporate network" or "intranet".
--> >
--> > (I did reply, but I said "reply" rather than "reply 
--> all"...I forgot 
--> > that this mailing list no longer has "reply-to"
--> > set to the list).
--> >
--> > Radia
--> >
--> > Guillermo Ib??ez wrote:
--> >
--> >> Eric,
--> >> The usual meaning of  campus network IMHO, refers to a  
--> set of  LANs 
--> >> covering several buildings, normally including routers 
--> or multilayer 
--> >> switches, switches and end nodes.
--> >> To use a campus for the set of RBridges on a segment seems a bit 
--> >> confusing.  The  LAN segment term seems correct.
--> >> Regards
--> >> Guillermo
--> >> Joe Touch wrote:
--> >>
--> >>> Gray, Eric wrote:
--> >>>  
--> >>>
--> >>>> Radia,
--> >>>>
--> >>>>     I am having some trouble resolving the use of "campus"
--> >>>> in the currently available protocol specification with 
--> the way that 
--> >>>> it has been used in other documents, mailing list
--> >>>> discussion, etc.
--> >>>>
--> >>>>     In the protocol specification, "campus" is defined as
--> >>>> synonymous with the usual definition of "LAN".  Is this use
--> >>>> central to the rest of the document?  If so, can we use the
--> >>>> word "LAN" instead?
--> >>>>   
--> >>>
--> >>>
--> >>>
--> >>> I thought:
--> >>>
--> >>>     - segment
--> >>>         what 802 refers to when describing an ethernet LAN
--> >>>         or a single VLAN on a VLAN-capable network
--> >>>
--> >>>     - campus
--> >>>         the set of rbridges on a segment that cooperate
--> >>>         together
--> >>>
--> >>> I don't know if 802 has a term that describes the set 
--> of all VLANs that
--> >>> share an infrastructure.
--> >>>
--> >>> I would avoid the term LAN, as it could mean VLAN or 
--> segment, and I
--> >>> don't think that's the intent.
--> >>>
--> >>> Joe
--> >>>
--> >>>  
--> >>>
--> >>> 
--> ------------------------------------------------------------
--> ------------ 
--> >>>
--> >>>
--> >>> _______________________________________________
--> >>> 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.11.6p2+0917/8.11.2) with ESMTP id k5MJ6np06033 for <[e-mail]>; Thu, 22 Jun 2006 12:06:49 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k5MJ6al6019486; Thu, 22 Jun 2006 15:06:37 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA09605;  Thu, 22 Jun 2006 15:06:36 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <N1GWKYXW>; Thu, 22 Jun 2006 15:06:36 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Radia Perlman <[e-mail]>
Date: Thu, 22 Jun 2006 15:06:35 -0400
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 k5MJ6np06033
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Use of the term "campus"
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, 22 Jun 2006 19:07:19 -0000
Status: RO
Content-Length: 3274

Radia,

	Like I said, that's fine with me.  Unfortunately, I 
inherited the term "campus" - as it is used in CFT and CTT
- from the previously-existing document.

	CFT is the abstract definition of a table we use
to determine how to forward an RBridge encapsulated frame
from one RBridge to another.  CTT is the abstract definition 
of the table we use to determine what encapsulation to use 
for any specific un-encasulated frame to be forwarded via 
one or more RBridges.  These terms - not invented by me - 
are dependent on the understanding that the campus consists 
of RBridges and "tunnels" between them (corresponding to 
paths for forwarding RBridge encasulated frames).

	What do you suggest should be used instead?

--
Eric

--> -----Original Message-----
--> From: Radia Perlman [mailto:[e-mail]] 
--> Sent: Thursday, June 22, 2006 2:55 PM
--> To: Guillermo Ib??ez
--> Cc: Joe Touch; Gray, Eric; [e-mail]
--> Subject: Re: [rbridge] Use of the term "campus"
--> 
--> I agree with Guillermo...that "campus" covers not just the 
--> rbridges, but 
--> the LAN segments and the attached nodes.
--> But I wouldn't include segments connected via routers. For 
--> that, perhaps 
--> "corporate network" or "intranet".
--> 
--> (I did reply, but I said "reply" rather than "reply 
--> all"...I forgot that 
--> this mailing list no longer has "reply-to"
--> set to the list).
--> 
--> Radia
--> 
--> Guillermo Ib??ez wrote:
--> 
--> > Eric,
--> > The usual meaning of  campus network IMHO, refers to a  
--> set of  LANs 
--> > covering several buildings, normally including routers or 
--> multilayer 
--> > switches, switches and end nodes.
--> > To use a campus for the set of RBridges on a segment seems a bit 
--> > confusing.  The  LAN segment term seems correct.
--> > Regards
--> > Guillermo
--> > Joe Touch wrote:
--> >
--> >> Gray, Eric wrote:
--> >>  
--> >>
--> >>> Radia,
--> >>>
--> >>>     I am having some trouble resolving the use of "campus"
--> >>> in the currently available protocol specification with 
--> the way that 
--> >>> it has been used in other documents, mailing list
--> >>> discussion, etc.
--> >>>
--> >>>     In the protocol specification, "campus" is defined as
--> >>> synonymous with the usual definition of "LAN".  Is this use
--> >>> central to the rest of the document?  If so, can we use the
--> >>> word "LAN" instead?
--> >>>   
--> >>
--> >>
--> >> I thought:
--> >>
--> >>     - segment
--> >>         what 802 refers to when describing an ethernet LAN
--> >>         or a single VLAN on a VLAN-capable network
--> >>
--> >>     - campus
--> >>         the set of rbridges on a segment that cooperate
--> >>         together
--> >>
--> >> I don't know if 802 has a term that describes the set of 
--> all VLANs that
--> >> share an infrastructure.
--> >>
--> >> I would avoid the term LAN, as it could mean VLAN or 
--> segment, and I
--> >> don't think that's the intent.
--> >>
--> >> Joe
--> >>
--> >>  
--> >>
--> >> 
--> ------------------------------------------------------------
--> ------------
--> >>
--> >> _______________________________________________
--> >> 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.11.6p2+0917/8.11.2) with ESMTP id k5MJ5Vp05661 for <[e-mail]>; Thu, 22 Jun 2006 12:05:32 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A8F42D53FF; Thu, 22 Jun 2006 21:05:25 +0200 (CEST)
Received: from [10.0.0.4] (39.Red-80-37-137.staticIP.rima-tde.net [80.37.137.39]) by smtp01.uc3m.es (Postfix) with ESMTP id 64EDBD54B9; Thu, 22 Jun 2006 21:05:24 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 22 Jun 2006 21:05:22 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Use of the term "campus"
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, 22 Jun 2006 19:06:15 -0000
Status: RO
Content-Length: 2459

I meant routers in the sense tthat current campus networks include 
routers/multilayer switches. I agree with Radia that in the Rbridges 
context the routers are at the edge of campus.
The term corporate network is used sometimes for a network covering 
different distant sites. Intranet might coincide in coverage, although 
in meaning usually is used as oposed to extranet or Internet.
Guillermo

Radia Perlman wrote:

> I agree with Guillermo...that "campus" covers not just the rbridges, 
> but the LAN segments and the attached nodes.
> But I wouldn't include segments connected via routers. For that, 
> perhaps "corporate network" or "intranet".
>
> (I did reply, but I said "reply" rather than "reply all"...I forgot 
> that this mailing list no longer has "reply-to"
> set to the list).
>
> Radia
>
> Guillermo Ib??ez wrote:
>
>> Eric,
>> The usual meaning of  campus network IMHO, refers to a  set of  LANs 
>> covering several buildings, normally including routers or multilayer 
>> switches, switches and end nodes.
>> To use a campus for the set of RBridges on a segment seems a bit 
>> confusing.  The  LAN segment term seems correct.
>> Regards
>> Guillermo
>> Joe Touch wrote:
>>
>>> Gray, Eric wrote:
>>>  
>>>
>>>> Radia,
>>>>
>>>>     I am having some trouble resolving the use of "campus"
>>>> in the currently available protocol specification with the way that 
>>>> it has been used in other documents, mailing list
>>>> discussion, etc.
>>>>
>>>>     In the protocol specification, "campus" is defined as
>>>> synonymous with the usual definition of "LAN".  Is this use
>>>> central to the rest of the document?  If so, can we use the
>>>> word "LAN" instead?
>>>>   
>>>
>>>
>>>
>>> I thought:
>>>
>>>     - segment
>>>         what 802 refers to when describing an ethernet LAN
>>>         or a single VLAN on a VLAN-capable network
>>>
>>>     - campus
>>>         the set of rbridges on a segment that cooperate
>>>         together
>>>
>>> I don't know if 802 has a term that describes the set of all VLANs that
>>> share an infrastructure.
>>>
>>> I would avoid the term LAN, as it could mean VLAN or segment, and I
>>> don't think that's the intent.
>>>
>>> Joe
>>>
>>>  
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> _______________________________________________
>>> 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.11.6p2+0917/8.11.2) with ESMTP id k5MIukp02560 for <[e-mail]>; Thu, 22 Jun 2006 11:56:46 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k5MIubl6019138; Thu, 22 Jun 2006 14:56:37 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA08003;  Thu, 22 Jun 2006 14:56:36 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <N1GWKYJX>; Thu, 22 Jun 2006 14:56:35 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
Date: Thu, 22 Jun 2006 14:56:34 -0400
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 k5MIukp02560
Cc: [e-mail]
Subject: Re: [rbridge] Use of the term "campus"
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, 22 Jun 2006 18:57:08 -0000
Status: RO
Content-Length: 2987

Yes, that is the usual meaning of "campus" as a quasi-generic
term.  One could argue that this dates back to using the term
campus as equivalent to site.

Because we're talking exclusively of device-relative topology
- as opposed to location-relative topology (geography?) - we
can agree to discount the use of the term "campus" as it might
apply to buildings and sites.

The problem is that a lot of "stuff" is defined around the way
that we've used the term "campus" in this (TRILL) context.  If
we define it a different way, or decide to use a different term,
that's fine with me.  I just have to change a lot of text around
other terms such as -

CTT - Campus Transit Table
CFT - Campus Forwarding Table
CFT-IRT - Campus Forwarding Table - Ingress RBridge Tree

- as well as a lot of textual descriptions and places where we
just use the derived acronyms (assuming the "new" term doesn't 
start with a "C").

Actually, I'm disappointed that we're having this discussion
again - and doubly so because I'm the one that had to bring it
up.

--> -----Original Message-----
--> From: Guillermo Ib??ez [mailto:[e-mail]] 
--> Sent: Thursday, June 22, 2006 2:47 PM
--> To: Joe Touch
--> Cc: Gray, Eric; [e-mail]; [e-mail]
--> Subject: Re: [rbridge] Use of the term "campus"
--> 
-->  Eric,
-->  The usual meaning of  campus network IMHO, refers to a  
--> set of  LANs 
--> covering several buildings, normally including routers or 
--> multilayer 
--> switches, switches and end nodes.
--> To use a campus for the set of RBridges on a segment seems a bit 
--> confusing.  The  LAN segment term seems correct.
--> Regards
--> Guillermo
--> Joe Touch wrote:
--> 
--> >Gray, Eric wrote:
--> >  
--> >
--> >>Radia,
--> >>
--> >>	I am having some trouble resolving the use of "campus"
--> >>in the currently available protocol specification with the 
--> >>way that it has been used in other documents, mailing list
--> >>discussion, etc.
--> >>
--> >>	In the protocol specification, "campus" is defined as
--> >>synonymous with the usual definition of "LAN".  Is this use
--> >>central to the rest of the document?  If so, can we use the
--> >>word "LAN" instead?
--> >>    
--> >>
--> >
--> >I thought:
--> >
--> >	- segment
--> >		what 802 refers to when describing an ethernet LAN
--> >		or a single VLAN on a VLAN-capable network
--> >
--> >	- campus
--> >		the set of rbridges on a segment that cooperate
--> >		together
--> >
--> >I don't know if 802 has a term that describes the set of 
--> all VLANs that
--> >share an infrastructure.
--> >
--> >I would avoid the term LAN, as it could mean VLAN or segment, and I
--> >don't think that's the intent.
--> >
--> >Joe
--> >
--> >  
--> >
--> >-----------------------------------------------------------
--> -------------
--> >
--> >_______________________________________________
--> >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.11.6p2+0917/8.11.2) with ESMTP id k5MItTp02074 for <[e-mail]>; Thu, 22 Jun 2006 11:55:29 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 22 Jun 2006 11:55:22 -0700 (PDT)
Received: from sun.com ([129.150.22.193]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Thu, 22 Jun 2006 11:55:22 -0700 (PDT)
Date: Thu, 22 Jun 2006 11:55:25 -0700
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]> <[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], Joe Touch <[e-mail]>
Subject: Re: [rbridge] Use of the term "campus"
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, 22 Jun 2006 18:56:08 -0000
Status: RO
Content-Length: 1951

I agree with Guillermo...that "campus" covers not just the rbridges, but 
the LAN segments and the attached nodes.
But I wouldn't include segments connected via routers. For that, perhaps 
"corporate network" or "intranet".

(I did reply, but I said "reply" rather than "reply all"...I forgot that 
this mailing list no longer has "reply-to"
set to the list).

Radia

Guillermo Ib??ez wrote:

> Eric,
> The usual meaning of  campus network IMHO, refers to a  set of  LANs 
> covering several buildings, normally including routers or multilayer 
> switches, switches and end nodes.
> To use a campus for the set of RBridges on a segment seems a bit 
> confusing.  The  LAN segment term seems correct.
> Regards
> Guillermo
> Joe Touch wrote:
>
>> Gray, Eric wrote:
>>  
>>
>>> Radia,
>>>
>>>     I am having some trouble resolving the use of "campus"
>>> in the currently available protocol specification with the way that 
>>> it has been used in other documents, mailing list
>>> discussion, etc.
>>>
>>>     In the protocol specification, "campus" is defined as
>>> synonymous with the usual definition of "LAN".  Is this use
>>> central to the rest of the document?  If so, can we use the
>>> word "LAN" instead?
>>>   
>>
>>
>> I thought:
>>
>>     - segment
>>         what 802 refers to when describing an ethernet LAN
>>         or a single VLAN on a VLAN-capable network
>>
>>     - campus
>>         the set of rbridges on a segment that cooperate
>>         together
>>
>> I don't know if 802 has a term that describes the set of all VLANs that
>> share an infrastructure.
>>
>> I would avoid the term LAN, as it could mean VLAN or segment, and I
>> don't think that's the intent.
>>
>> Joe
>>
>>  
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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.11.6p2+0917/8.11.2) with ESMTP id k5MIl0p28908 for <[e-mail]>; Thu, 22 Jun 2006 11:47:00 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CC47DD5B35; Thu, 22 Jun 2006 20:46:53 +0200 (CEST)
Received: from [10.0.0.4] (39.Red-80-37-137.staticIP.rima-tde.net [80.37.137.39]) by smtp01.uc3m.es (Postfix) with ESMTP id 4F043D5B12; Thu, 22 Jun 2006 20:46:52 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 22 Jun 2006 20:46:49 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Touch <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: [rbridge] Use of the term "campus"
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, 22 Jun 2006 18:48:05 -0000
Status: RO
Content-Length: 1434

 Eric,
 The usual meaning of  campus network IMHO, refers to a  set of  LANs 
covering several buildings, normally including routers or multilayer 
switches, switches and end nodes.
To use a campus for the set of RBridges on a segment seems a bit 
confusing.  The  LAN segment term seems correct.
Regards
Guillermo
Joe Touch wrote:

>Gray, Eric wrote:
>  
>
>>Radia,
>>
>>	I am having some trouble resolving the use of "campus"
>>in the currently available protocol specification with the 
>>way that it has been used in other documents, mailing list
>>discussion, etc.
>>
>>	In the protocol specification, "campus" is defined as
>>synonymous with the usual definition of "LAN".  Is this use
>>central to the rest of the document?  If so, can we use the
>>word "LAN" instead?
>>    
>>
>
>I thought:
>
>	- segment
>		what 802 refers to when describing an ethernet LAN
>		or a single VLAN on a VLAN-capable network
>
>	- campus
>		the set of rbridges on a segment that cooperate
>		together
>
>I don't know if 802 has a term that describes the set of all VLANs that
>share an infrastructure.
>
>I would avoid the term LAN, as it could mean VLAN or segment, and I
>don't think that's the intent.
>
>Joe
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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.11.6p2+0917/8.11.2) with ESMTP id k5MI9Pp16015 for <[e-mail]>; Thu, 22 Jun 2006 11:09:25 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k5MI9Cl6017787; Thu, 22 Jun 2006 14:09:13 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA01405;  Thu, 22 Jun 2006 14:09:12 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <N1GWKWNR>; Thu, 22 Jun 2006 14:09:12 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Joe Touch <[e-mail]>
Date: Thu, 22 Jun 2006 14:09:11 -0400
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], [e-mail]
Subject: Re: [rbridge] Use of the term "campus"
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, 22 Jun 2006 18:10:12 -0000
Status: RO
Content-Length: 2129

Joe,

	Your definition for "campus" is very close to my own
understanding, as well.  Meanwhile, we have the term "segment" 
and the term "LAN" that occasionally over-lap.

	From back in the days when I worked almost exclusively
with bridges and hubs (1989-1994), we used the term "segment"
to mean "the bit between bridges" since that was what would
be isolated if a bridged network became "segmented" (by losing
a bridge).

	Also, most people usually refer to a "LAN" as a broadcast 
domain.  Otherwise the term "VLAN" (as "Virtual LAN") becomes
excessively cumbersome to deal with.

	I admit all of these terms have overlap and ambiguity in
the rest of the world, but can we use them consistently in the
set of TRILL documents?

	I'm perfectly happy to accept the definition of "campus"
provided in the protocol specification, but then I need a new
term for "the set of rbridges that cooperate together."

--> -----Original Message-----
--> From: Joe Touch [mailto:[e-mail]] 
--> Sent: Thursday, June 22, 2006 1:59 PM
--> To: Gray, Eric
--> Cc: [e-mail]; [e-mail]
--> Subject: Re: [rbridge] Use of the term "campus"
--> 
--> 
--> 
--> Gray, Eric wrote:
--> > Radia,
--> > 
--> > 	I am having some trouble resolving the use of "campus"
--> > in the currently available protocol specification with the 
--> > way that it has been used in other documents, mailing list
--> > discussion, etc.
--> > 
--> > 	In the protocol specification, "campus" is defined as
--> > synonymous with the usual definition of "LAN".  Is this use
--> > central to the rest of the document?  If so, can we use the
--> > word "LAN" instead?
--> 
--> I thought:
--> 
--> 	- segment
--> 		what 802 refers to when describing an ethernet LAN
--> 		or a single VLAN on a VLAN-capable network
--> 
--> 	- campus
--> 		the set of rbridges on a segment that cooperate
--> 		together
--> 
--> I don't know if 802 has a term that describes the set of 
--> all VLANs that
--> share an infrastructure.
--> 
--> I would avoid the term LAN, as it could mean VLAN or segment, and I
--> don't think that's the intent.
--> 
--> Joe
--> 
--> 


Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5MHwEp12107 for <[e-mail]>; Thu, 22 Jun 2006 10:58:14 -0700 (PDT)
Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5MHv4227176; Thu, 22 Jun 2006 10:57:04 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 22 Jun 2006 10:58:35 -0700
From: Joe Touch <[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]>
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7E47E2998C5E15DB79BCCF6E"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: [rbridge] Use of the term "campus"
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, 22 Jun 2006 17:59:18 -0000
Status: RO
Content-Length: 1542

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



Gray, Eric wrote:
> Radia,
>=20
> 	I am having some trouble resolving the use of "campus"
> in the currently available protocol specification with the=20
> way that it has been used in other documents, mailing list
> discussion, etc.
>=20
> 	In the protocol specification, "campus" is defined as
> synonymous with the usual definition of "LAN".  Is this use
> central to the rest of the document?  If so, can we use the
> word "LAN" instead?

I thought:

	- segment
		what 802 refers to when describing an ethernet LAN
		or a single VLAN on a VLAN-capable network

	- campus
		the set of rbridges on a segment that cooperate
		together

I don't know if 802 has a term that describes the set of all VLANs that
share an infrastructure.

I would avoid the term LAN, as it could mean VLAN or segment, and I
don't think that's the intent.

Joe


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

iD8DBQFEmtpLE5f5cImnZrsRAmtYAKCOdAZDIqOqDVRaLbiOGX1CH4r6cACdFtlJ
fKpsvH4PhlV3TOUDxkD08sE=
=U8ys
-----END PGP SIGNATURE-----

--------------enig7E47E2998C5E15DB79BCCF6E--


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5MHeCp06067 for <[e-mail]>; Thu, 22 Jun 2006 10:40:12 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k5MHe5l6017014; Thu, 22 Jun 2006 13:40:05 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA27885;  Thu, 22 Jun 2006 13:40:05 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <N1GWKVK0>; Thu, 22 Jun 2006 13:40:05 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: [e-mail]
Date: Thu, 22 Jun 2006 13:40:04 -0400
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: [rbridge] Use of the term "campus"
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, 22 Jun 2006 17:41:03 -0000
Status: RO
Content-Length: 405

Radia,

	I am having some trouble resolving the use of "campus"
in the currently available protocol specification with the 
way that it has been used in other documents, mailing list
discussion, etc.

	In the protocol specification, "campus" is defined as
synonymous with the usual definition of "LAN".  Is this use
central to the rest of the document?  If so, can we use the
word "LAN" instead?

--
Eric


Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5MFqcp26152 for <[e-mail]>; Thu, 22 Jun 2006 08:52:38 -0700 (PDT)
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 22 Jun 2006 08:52:30 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.06,166,1149490800";  d="scan'208"; a="30257102:sNHT21909600"
Received: from [192.168.1.153] (rtp-vpn1-520.cisco.com [10.82.226.8]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5MFqTno023786 for <[e-mail]>; Thu, 22 Jun 2006 11:52:30 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 22 Jun 2006 11:52:32 -0400
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530)
MIME-Version: 1.0
To: [e-mail]
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Comments on draft-ietf-trill-prob-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: Thu, 22 Jun 2006 15:53:13 -0000
Status: RO
Content-Length: 3172

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


Just some comments below that might help...

:-)

Russ

==

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

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

I think the absolute worst case is when one of the branches connected
to the root bridge fails, causing a large number of ports to
block and unblock before the network would reconverge. Perhaps a ring
would show enough to explain, however (?):

A----B----C----D----E
|                                        |
+-----F-----G-------+

If A is the root bridge, then we can assume the paths A->B->C->D and
A->F->G->E are the two open paths, while the D->E link is blocked in
both directions (just using hop count). If the A->B link fails, then E
must unblock its port to D for traffic to flow again, but it may
require recomputation of the entire tree through BPDUs, I think (?).

==

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

I don't think we are trying to address this in TRILL (?).

==

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

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

I'm not certain you need any reference on this, I would guess it's
pretty self evident (?).

==

3.5. Multiple Attachments

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

I'm not certain what this section would cover, as well. It might
mention that while, in STP, a single NIC with multiple attachments to
a single spanning tree will always only get traffic over one of the
two attachment points (I don't see how it would work otherwise??),
with TRILL, it's actually possibly to load share between the
attachment points. I don't know if this is worth calling out, or
worrying about, though, in this specific document, since this is a
problem statement, and this has never been noted as a problem in STP.

==


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

iD8DBQFEmry/ER27sUhU9OQRAo+QAKDpNZ9EKzknNW9IrcNZ+EZP0p+G8QCgiOAt
787vOw0eIg6Yy4ZzA7TdC1A=
=QuVe
-----END PGP SIGNATURE-----


Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5MFKfp15590 for <[e-mail]>; Thu, 22 Jun 2006 08:20:41 -0700 (PDT)
Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5MFG2215267; Thu, 22 Jun 2006 08:16:02 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 22 Jun 2006 08:17:33 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]> <[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="------------enig28B0AB749E7A0962F64F3426"
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] RBridges and IS-IS packets, revisited
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, 22 Jun 2006 15:21:12 -0000
Status: RO
Content-Length: 1554

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



Radia Perlman wrote:
> I think we never decided on this. Encoding is not a very interesting=20
> thing, but
> we should decide. I have a few questions.
>=20
> a) Any reason to optimize sending of layer 3 IS-IS packets?

There might be, but that's just an optimization, like other L3
optimizations (e.g., IP multicast).

=2E..
> c) I assume layer 2 multicast addresses are basically free, and if I=20
> understood Dino's
> email from a few weeks ago, he'd prefer using a different MAC multicast=
=20
> address for
> RBridge IS-IS packets than ordinary encapsulated data packets, so that =

> RBridges will
> know they should process the packets.

I was assuming we would get a separate L2 address for rbridge control
info, and that they'd be multicast as with other L2 control. Are you
asking whether we need multiple such addresses, or just one?

Joe


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

iD8DBQFEmrSNE5f5cImnZrsRAgmuAJ4wVPYbwRu1FrAHQ8OkcdizisnUlACg6DF1
g8YfFdCijUVW+Sd/hoGNPzc=
=cf+b
-----END PGP SIGNATURE-----

--------------enig28B0AB749E7A0962F64F3426--


Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5MDZ4p10448 for <[e-mail]>; Thu, 22 Jun 2006 06:35:04 -0700 (PDT)
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 Jun 2006 09:35:01 -0400
X-IronPort-AV: i="4.06,166,1149480000";  d="scan'208"; a="90773340:sNHT28044616"
Received: from [192.168.1.153] (rtp-vpn1-520.cisco.com [10.82.226.8]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5MDYwYL027681;  Thu, 22 Jun 2006 09:34:58 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 22 Jun 2006 09:35:00 -0400
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] RBridges and IS-IS packets, revisited
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, 22 Jun 2006 13:36:06 -0000
Status: RO
Content-Length: 1998

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


> a) Any reason to optimize sending of layer 3 IS-IS packets? RBridges
> can know which links contain IS-IS routers because IS-IS routers send
> IS Hellos. If RBridges told each other "I am attached to an IS-IS
> router", then IS-IS Link state packets and hellos (This is layer 3
> I'm talking about) only need to get sent to links that contain IS-IS
> routers.

I wouldn't try do this.... The first question that springs to mind is,
if you're going to optimize for IS-IS, why not for all the other routing
protocols that use link local multicast, as well, such as OSPF, EIGRP,
and RIPv2? The problem I see is that it would interfere with the three
way handshake used in many RP's, and possibly with OSPF DR election. I
would just leave it....

> b) Do IS-IS Routers actually use VLANs? Do people partition their 
> bridged topology into VLANs and run different instances of layer 3
> IS-IS (or OSPF) for each VLAN? Not sure why people would do this, but
> oh well. I think it isn't hard to avoid breaking this functionality,
> so it should probably be designed to allow it. But I'm just curious 
> if anyone would use it, and perhaps even get a clue as to why.

Yes, they do.... For normal L3 IS-IS packets, though, we should just
encap in the correct vlan shim header, and send it out, just like any
other broadcast (link local multicast) packet.

> c) I assume layer 2 multicast addresses are basically free, and if I
>  understood Dino's email from a few weeks ago, he'd prefer using a
> different MAC multicast address for RBridge IS-IS packets than
> ordinary encapsulated data packets, so that RBridges will know they
> should process the packets.

This is what I'd prefer, as well.

:-)

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

iD8DBQFEmpyEER27sUhU9OQRAisGAKC2XXUYXCLqmORiO4HmQaoluFB2PACg24X9
JcCMdSpTFnfkRVk57WOLz/g=
=ExYB
-----END PGP SIGNATURE-----


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5M6Nbp04277 for <[e-mail]>; Wed, 21 Jun 2006 23:23:38 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 21 Jun 2006 23:23:32 -0700 (PDT)
Received: from sun.com ([129.150.22.193]) 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, 21 Jun 2006 23:23:30 -0700 (PDT)
Date: Wed, 21 Jun 2006 23:23:33 -0700
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=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] Proposed encoding for IS-IS packets
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, 22 Jun 2006 06:23:59 -0000
Status: RO
Content-Length: 1494

1) layer 3 IS-IS LSPs

It would be fine to treat these like any other layer 2 multicasts.
The only reason to do anything different would be if we want to
optimize distribution of these to go only to links on which there
are IS-IS routers. RBridges could recognize such packets because the
inner header would indicate the IS-IS DSAP. So I'm assuming these
will be encapsulated just like any layer 2 multicast.

2) core IS-IS instance for RBridges (these are the IS-IS packets by
which RBridges inform each other about RBridge-to-RBridge connectivity.

Outer header:
  Destination=new (to be assigned) layer 2 multicast address,
   indicating "core RBridge IS-IS packet"
  Source=transmitting RBridge
  protocol type=encapsulated RBridge packet

Shim header: TTL and ingress RBridge (in PWE format as defined in the 
unfortunately
expired internet draft by Bryant, et al)

No inner layer 2 header: IS-IS packet immediately follows

3) per-VLAN IS-IS instance for RBridges (these are the IS-IS packets by
which RBridges in a particular VLAN inform other RBridges attached to
the same VLAN of where the endnodes, multicast receivers, and multicast
routers associated with that VLAN are)


Outer header:
  Destination=second new (to be assigned) layer 2 multicast address,
   indicating "per-VLAN RBridge IS-IS packet"
  Source=transmitting RBridge
  protocol type=encapsulated RBridge packet

Shim header: TTL and ingress RBridge

No inner layer 2 header:, just VLAN tag,
followed by IS-IS packet



Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5M4lmp08757 for <[e-mail]>; Wed, 21 Jun 2006 21:47:48 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 21 Jun 2006 21:47:29 -0700 (PDT)
Received: from sun.com ([129.150.22.193]) 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, 21 Jun 2006 21:47:27 -0700 (PDT)
Date: Wed, 21 Jun 2006 21:47:30 -0700
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: [rbridge] RBridges and IS-IS packets, revisited
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, 22 Jun 2006 04:48:16 -0000
Status: RO
Content-Length: 1605

I think we never decided on this. Encoding is not a very interesting 
thing, but
we should decide. I have a few questions.

a) Any reason to optimize sending of layer 3 IS-IS packets? RBridges can 
know which links
contain IS-IS routers because IS-IS routers send IS Hellos. If RBridges 
told each other
"I am attached to an IS-IS router", then IS-IS Link state packets and 
hellos (This is
layer 3 I'm talking about) only need to get sent to links that contain 
IS-IS routers.

I'm assuming we don't care about optimizing this, though perhaps we 
should on the last
hop (don't decapsulate layer 3 IS-IS traffic onto links for which you 
are Designated
RBridge and know there are no IS-IS routers there)

b) Do IS-IS Routers actually use VLANs? Do people partition their 
bridged topology into
VLANs and run different instances of layer 3 IS-IS (or OSPF) for each 
VLAN? Not sure
why people would do this, but oh well. I think it isn't hard to avoid 
breaking this
functionality, so it should probably be designed to allow it. But I'm 
just curious
if anyone would use it, and perhaps even get a clue as to why.

c) I assume layer 2 multicast addresses are basically free, and if I 
understood Dino's
email from a few weeks ago, he'd prefer using a different MAC multicast 
address for
RBridge IS-IS packets than ordinary encapsulated data packets, so that 
RBridges will
know they should process the packets.

d) I'll send a proposal for the encoding of the 3 types of IS-IS packets 
(encapsulated layer
3 IS-IS packets, core instance RBridge IS-IS, per-VLAN RBridge IS-IS) in
a subsequent email

Radia