[rbridge] How are packets/link without a VLAN tag handled ina bridged network today?

[dsholland at avaya.com (Holland, David (David))]

Radia,

As Anoop observed the specifics are documented in 802.1Q, the switch
implementation I referrred to is compliant (so I described the switch
behavior).

Again, as Anoop pointed out the switch may be configured to preserve or
strip tags before forwarding. Typically users configure the links to end
nodes as clear (no tag) to support older implementations that are not
VLAN aware. The only VLAN aware "end" nodes I know of are IP phones, and
these usually have embedded L2 switch chips (Zultys etc.)

David

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Thursday, December 29, 2005 10:52 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] How are packets/link without a VLAN tag handled
ina bridged network today?

Thanks!

So, there is a specific special "untagged" VLAN, which is "marked" by
the absence of a VLAN tag. As opposed to a meaning that this packet
should go to everyone, which I could also imagine.

Another question then...if bridges add the VLAN tag (and therefore
endnodes are unaware of VLAN tags), then how is it possible to support a
link with multiple VLANs? Wouldn't endnodes get confused because they
will see packets from other VLANs? I'd assume that unless endnodes are
VLAN-aware, and put in their own tags, that it would be illegal for a
link to support multiple VLANs. Is this true?

And...are you saying that this is not written down anywhere, but just
observed based on how some particular vendor implemented it?

Thanks again!

Radia



Holland, David (David) wrote:

>Radia,
>
>My experience from working on switch/router "brand z", is that the 
>behavior for "a" (below) is correct.
>
>In the "b" case the packet is NOT flooded to the other vlans UNLESS 
>those ports are also participating in the (default) untagged vlan by 
>configuration.
>
>For item "c": Yes the link can support all VLANS or only selected
VLANS.
>The configuration options allow for the bridge to automatically bind 
>the link to all VLANs for which tag values are observed (or only those 
>received on the link or only those manually administered). This 
>provides for trunking links.
>
>David
>
>-----Original Message-----
>From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On

>Behalf Of Radia Perlman
>Sent: Thursday, December 29, 2005 8:21 PM
>To: Developing a hybrid router/bridge.
>Subject: [rbridge] How are packets/link without a VLAN tag handled in a

>bridged network today?
>
>I guessed at the behavior once, to someone who was following 802.1 
>better than I have been, and he verified that I was correct at the 
>time, but I've forgotten what my conjecture was. Does anyone know how 
>the following cases are handled?
>
>Suppose a bridged network has some links configured as VLAN A, and 
>others configured as VLAN B, and some links that are not configured as 
>either VLAN A or VLAN B. Let's say that links La1 and La2 are 
>configured as VLAN A, links Lb1 and Lb2 are configured as Lb, and links

>Lc1 and Lc2 are not configured to reside in either VLAN A or VLAN B.
>
>Let's further assume that it is the bridges that put on the VLAN tags.
>
>What happens in the following cases?
>
>a) A layer 2 multicast packet originates at La1. Certainly the first 
>bridge adds a VLAN A tag to the packet, and delivers the packet to La2.
>However, does it also deliver it to Lc1 and Lc2? (I'd be very surprised

>if the answer to this was yes...I assume the packet will ONLY get 
>delivered to links that are specifically marked as supporting VLAN A).
>
>b) A layer 2 multicast packet originates at Lc1. I assume the behavior 
>in this case is that the first bridge does NOT add a VLAN tag to the 
>packet. I can imagine either in this case that the packet is ONLY 
>delivered to Lc2 (i.e., other links that are not configured as 
>belonging to any VLAN), but I suspect the packet is delivered to ALL 
>links, i.e., in this case, La1, La2, Lb1, Lb2, and Lc2, and without a
VLAN tag.
>This would mean that endnodes in VLAN A and endnodes in VLAN B will see

>this packet, so perhaps it's the other behavior (that it's only 
>delivered to links that are not configured as being in any VLAN).
>
>c) If it is the bridge, rather than endnodes that put on the VLAN tag, 
>is it legal for a link to support multiple VLANs? It would make sense 
>for the answer to this to be no, in which case I suspect the answer to
>b) above would be more likely to be "don't deliver to any links that 
>have been configured to be in any VLAN", since I suspect "unmarked
VLAN"
>is treated as a special case VLAN.
>
>Radia
>
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>
>
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://www.postel.org/mailman/listinfo/rbridge




Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBUNlvi05541 for <[e-mail]>; Fri, 30 Dec 2005 15:47:57 -0800 (PST)
Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by nj300815-ier2.net.avaya.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBUNkNI5019038 for <[e-mail]>; Fri, 30 Dec 2005 18:46:23 -0500
Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id jBUNixqD016112 for <[e-mail]>; Fri, 30 Dec 2005 18:44:59 -0500 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Date: Fri, 30 Dec 2005 18:47:56 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] How are packets/link without a VLAN tag handled ina	bridged network today?
Thread-Index: AcYM9fkOrBR112EFTTOKEa/oK70+pQAnu+KQ
From: "Holland, David \(David\)" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-Scanner: InterScan AntiVirus for Sendmail
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 jBUNlvi05541
Subject: Re: [rbridge] How are packets/link without a VLAN tag handled ina	bridged network today?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Dec 2005 23:48:55 -0000
Status: RO
Content-Length: 5059

Radia,

As Anoop observed the specifics are documented in 802.1Q, the switch
implementation I referrred to is compliant (so I described the switch
behavior).

Again, as Anoop pointed out the switch may be configured to preserve or
strip tags before forwarding. Typically users configure the links to end
nodes as clear (no tag) to support older implementations that are not
VLAN aware. The only VLAN aware "end" nodes I know of are IP phones, and
these usually have embedded L2 switch chips (Zultys etc.)

David

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Thursday, December 29, 2005 10:52 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] How are packets/link without a VLAN tag handled
ina bridged network today?

Thanks!

So, there is a specific special "untagged" VLAN, which is "marked" by
the absence of a VLAN tag. As opposed to a meaning that this packet
should go to everyone, which I could also imagine.

Another question then...if bridges add the VLAN tag (and therefore
endnodes are unaware of VLAN tags), then how is it possible to support a
link with multiple VLANs? Wouldn't endnodes get confused because they
will see packets from other VLANs? I'd assume that unless endnodes are
VLAN-aware, and put in their own tags, that it would be illegal for a
link to support multiple VLANs. Is this true?

And...are you saying that this is not written down anywhere, but just
observed based on how some particular vendor implemented it?

Thanks again!

Radia



Holland, David (David) wrote:

>Radia,
>
>My experience from working on switch/router "brand z", is that the 
>behavior for "a" (below) is correct.
>
>In the "b" case the packet is NOT flooded to the other vlans UNLESS 
>those ports are also participating in the (default) untagged vlan by 
>configuration.
>
>For item "c": Yes the link can support all VLANS or only selected
VLANS.
>The configuration options allow for the bridge to automatically bind 
>the link to all VLANs for which tag values are observed (or only those 
>received on the link or only those manually administered). This 
>provides for trunking links.
>
>David
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On

>Behalf Of Radia Perlman
>Sent: Thursday, December 29, 2005 8:21 PM
>To: Developing a hybrid router/bridge.
>Subject: [rbridge] How are packets/link without a VLAN tag handled in a

>bridged network today?
>
>I guessed at the behavior once, to someone who was following 802.1 
>better than I have been, and he verified that I was correct at the 
>time, but I've forgotten what my conjecture was. Does anyone know how 
>the following cases are handled?
>
>Suppose a bridged network has some links configured as VLAN A, and 
>others configured as VLAN B, and some links that are not configured as 
>either VLAN A or VLAN B. Let's say that links La1 and La2 are 
>configured as VLAN A, links Lb1 and Lb2 are configured as Lb, and links

>Lc1 and Lc2 are not configured to reside in either VLAN A or VLAN B.
>
>Let's further assume that it is the bridges that put on the VLAN tags.
>
>What happens in the following cases?
>
>a) A layer 2 multicast packet originates at La1. Certainly the first 
>bridge adds a VLAN A tag to the packet, and delivers the packet to La2.
>However, does it also deliver it to Lc1 and Lc2? (I'd be very surprised

>if the answer to this was yes...I assume the packet will ONLY get 
>delivered to links that are specifically marked as supporting VLAN A).
>
>b) A layer 2 multicast packet originates at Lc1. I assume the behavior 
>in this case is that the first bridge does NOT add a VLAN tag to the 
>packet. I can imagine either in this case that the packet is ONLY 
>delivered to Lc2 (i.e., other links that are not configured as 
>belonging to any VLAN), but I suspect the packet is delivered to ALL 
>links, i.e., in this case, La1, La2, Lb1, Lb2, and Lc2, and without a
VLAN tag.
>This would mean that endnodes in VLAN A and endnodes in VLAN B will see

>this packet, so perhaps it's the other behavior (that it's only 
>delivered to links that are not configured as being in any VLAN).
>
>c) If it is the bridge, rather than endnodes that put on the VLAN tag, 
>is it legal for a link to support multiple VLANs? It would make sense 
>for the answer to this to be no, in which case I suspect the answer to
>b) above would be more likely to be "don't deliver to any links that 
>have been configured to be in any VLAN", since I suspect "unmarked
VLAN"
>is treated as a special case VLAN.
>
>Radia
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

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




Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBU43Ii28876 for <[e-mail]>; Thu, 29 Dec 2005 20:03:18 -0800 (PST)
Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.92.1.67]) by palrel12.hp.com (Postfix) with ESMTP id BBB5B3702E for <[e-mail]>; Thu, 29 Dec 2005 20:03:12 -0800 (PST)
Received: from cacexc06.americas.cpqcorp.net ([16.92.1.28]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);  Thu, 29 Dec 2005 20:03:12 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Thu, 29 Dec 2005 20:03:10 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] How are packets/link without a VLAN tag handled in a bridged network today?
Thread-Index: AcYM4JS4Gwj6Fuc9SRSARoH9xGG2BQAE4C8g
From: "Ghanwani, Anoop" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 30 Dec 2005 04:03:12.0618 (UTC) FILETIME=[F3F68CA0:01C60CF5]
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 jBU43Ii28876
Subject: Re: [rbridge] How are packets/link without a VLAN tag handled in a bridged network today?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Dec 2005 04:03:58 -0000
Status: RO
Content-Length: 3935

Radia,

IEEE 802.1Q does not allow a port to not be 
in any VLAN.  In other words, every port must 
be in at least one VLAN, and every port has a 
PVID which says what you should do with untagged 
frames from that port.  Therefore, an 802.1Q
device will not allow you to do what you say
in (1) and (2) for lc1 and lc2.  

By default all ports are in VLAN 1 and all ports 
have a PVID equal to VLAN 1, and they are 
configured to send traffic untagged on that VLAN.  
The user creates VLANs and can start reassigning 
ports to them.

Once a frame is inside the switch, the switch
always knows which VLAN the packet belongs to
(based on the above) and will only forward 
the frame to ports that are members of that
VLAN (regardless of whether it is unicast,
multicast, broadcast, or "unknown DA").  
Of course, if the DA is known, it gets 
forwarded only to one port.

Once we work with these assumptions, (1) and 
(2) are non-issues.

As for (3), yes, a port can be a member of 
multiple VLANs.  In that case, untagged traffic
arriving at the port gets assigned the PVID.
When you send traffic out, there is a parameter
to control whether or not a given VLAN should
be tagged/untagged before sending the frame
out.

Hope this helps.

Anoop 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Radia Perlman
> Sent: Thursday, December 29, 2005 5:21 PM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] How are packets/link without a VLAN tag 
> handled in a bridged network today?
> 
> I guessed at the behavior once, to someone who was following 802.1 
> better than I have
> been, and he verified that I was correct at the time, but 
> I've forgotten 
> what my
> conjecture was. Does anyone know how the following cases are handled?
> 
> Suppose a bridged network has some links configured
> as VLAN A, and others configured as VLAN B, and some links 
> that are not 
> configured
> as either VLAN A or VLAN B. Let's say that links La1 and La2 
> are configured
> as VLAN A, links Lb1 and Lb2 are configured as Lb, and links 
> Lc1 and Lc2 
> are not configured
> to reside in either VLAN A or VLAN B.
> 
> Let's further assume that it is the bridges that put on the VLAN tags.
> 
> What happens in the following cases?
> 
> a) A layer 2 multicast packet originates at La1. Certainly 
> the first bridge
> adds a VLAN A tag to the packet, and delivers the packet to 
> La2. However,
> does it also deliver it to Lc1 and Lc2? (I'd be very surprised if the 
> answer to this
> was yes...I assume the packet will ONLY get delivered to 
> links that are
> specifically marked as supporting VLAN A).
> 
> b) A layer 2 multicast packet originates at Lc1. I assume the 
> behavior 
> in this case
> is that the first bridge does NOT add a VLAN tag to the packet. I can 
> imagine either
> in this case that the packet is ONLY delivered to Lc2 (i.e., 
> other links 
> that are not
> configured as belonging to any VLAN), but I suspect the packet is 
> delivered to
> ALL links, i.e., in this case, La1, La2, Lb1, Lb2, and Lc2, 
> and without 
> a VLAN tag.
> This would mean that endnodes in VLAN A and endnodes in VLAN 
> B will see 
> this packet, so
> perhaps it's the other behavior (that it's only delivered to 
> links that 
> are not configured as being
> in any VLAN).
> 
> c) If it is the bridge, rather than endnodes that put on the 
> VLAN tag, 
> is it legal for a link
> to support multiple VLANs? It would make sense for the answer 
> to this to 
> be no, in which
> case I suspect the answer to b) above would be more likely to 
> be "don't 
> deliver to any links
> that have been configured to be in any VLAN", since I suspect 
> "unmarked 
> VLAN" is treated as a special
> case VLAN.
> 
> Radia
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
> 


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBU3qDi26704 for <[e-mail]>; Thu, 29 Dec 2005 19:52:13 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 29 Dec 2005 19:52:08 -0800 (PST)
Received: from sun.com ([129.150.24.250]) 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 Dec 2005 19:52:06 -0800 (PST)
Date: Thu, 29 Dec 2005 19:52:09 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] How are packets/link without a VLAN tag handled in a	bridged network today?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Dec 2005 03:52:58 -0000
Status: RO
Content-Length: 4085

Thanks!

So, there is a specific special "untagged" VLAN, which is "marked" by 
the absence of a VLAN tag. As opposed
to a meaning that this packet should go to everyone, which I could also 
imagine.

Another question then...if bridges add the VLAN tag (and therefore 
endnodes are unaware of
VLAN tags), then how is it possible to support a link with multiple 
VLANs? Wouldn't endnodes
get confused because they will see packets from other VLANs? I'd assume 
that unless endnodes
are VLAN-aware, and put in their own tags, that it would be illegal for 
a link to support
multiple VLANs. Is this true?

And...are you saying that this is not written down anywhere, but just 
observed based on how
some particular vendor implemented it?

Thanks again!

Radia



Holland, David (David) wrote:

>Radia,
>
>My experience from working on switch/router "brand z", is that the
>behavior for "a" (below) is correct.
>
>In the "b" case the packet is NOT flooded to the other vlans UNLESS
>those ports are also participating in the (default) untagged vlan by
>configuration. 
>
>For item "c": Yes the link can support all VLANS or only selected VLANS.
>The configuration options allow for the bridge to automatically bind the
>link to all VLANs for which tag values are observed (or only those
>received on the link or only those manually administered). This provides
>for trunking links.
>
>David
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
>Behalf Of Radia Perlman
>Sent: Thursday, December 29, 2005 8:21 PM
>To: Developing a hybrid router/bridge.
>Subject: [rbridge] How are packets/link without a VLAN tag handled in a
>bridged network today?
>
>I guessed at the behavior once, to someone who was following 802.1
>better than I have been, and he verified that I was correct at the time,
>but I've forgotten what my conjecture was. Does anyone know how the
>following cases are handled?
>
>Suppose a bridged network has some links configured as VLAN A, and
>others configured as VLAN B, and some links that are not configured as
>either VLAN A or VLAN B. Let's say that links La1 and La2 are configured
>as VLAN A, links Lb1 and Lb2 are configured as Lb, and links Lc1 and Lc2
>are not configured to reside in either VLAN A or VLAN B.
>
>Let's further assume that it is the bridges that put on the VLAN tags.
>
>What happens in the following cases?
>
>a) A layer 2 multicast packet originates at La1. Certainly the first
>bridge adds a VLAN A tag to the packet, and delivers the packet to La2.
>However, does it also deliver it to Lc1 and Lc2? (I'd be very surprised
>if the answer to this was yes...I assume the packet will ONLY get
>delivered to links that are specifically marked as supporting VLAN A).
>
>b) A layer 2 multicast packet originates at Lc1. I assume the behavior
>in this case is that the first bridge does NOT add a VLAN tag to the
>packet. I can imagine either in this case that the packet is ONLY
>delivered to Lc2 (i.e., other links that are not configured as belonging
>to any VLAN), but I suspect the packet is delivered to ALL links, i.e.,
>in this case, La1, La2, Lb1, Lb2, and Lc2, and without a VLAN tag.
>This would mean that endnodes in VLAN A and endnodes in VLAN B will see
>this packet, so perhaps it's the other behavior (that it's only
>delivered to links that are not configured as being in any VLAN).
>
>c) If it is the bridge, rather than endnodes that put on the VLAN tag,
>is it legal for a link to support multiple VLANs? It would make sense
>for the answer to this to be no, in which case I suspect the answer to
>b) above would be more likely to be "don't deliver to any links that
>have been configured to be in any VLAN", since I suspect "unmarked VLAN"
>is treated as a special case VLAN.
>
>Radia
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>



Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBU3bLi24090 for <[e-mail]>; Thu, 29 Dec 2005 19:37:21 -0800 (PST)
Received: from tierw.net.avaya.com (h198-152-13-100.avaya.com [198.152.13.100]) by co300216-ier2.net.avaya.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBU2a5u9000683 for <[e-mail]>; Thu, 29 Dec 2005 21:36:05 -0500
Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id jBU3MPYZ006088 for <[e-mail]>; Thu, 29 Dec 2005 22:22:26 -0500 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Date: Thu, 29 Dec 2005 22:37:18 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] How are packets/link without a VLAN tag handled in abridged network today?
Thread-Index: AcYM4Ma9h6lxkIfzTsuYib3T2Lyl+AADQ1gAAAEGF5A=
From: "Holland, David \(David\)" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-Scanner: InterScan AntiVirus for Sendmail
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 jBU3bLi24090
Subject: Re: [rbridge] How are packets/link without a VLAN tag handled in abridged network today?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Dec 2005 03:37:58 -0000
Status: RO
Content-Length: 3620

Oh, and by correct I mean you would not be surprised ;-)

Sorry about the lack of clarity. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Holland, David (David)
Sent: Thursday, December 29, 2005 10:18 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] How are packets/link without a VLAN tag handled
in abridged network today?

Radia,

My experience from working on switch/router "brand z", is that the
behavior for "a" (below) is correct.

In the "b" case the packet is NOT flooded to the other vlans UNLESS
those ports are also participating in the (default) untagged vlan by
configuration. 

For item "c": Yes the link can support all VLANS or only selected VLANS.
The configuration options allow for the bridge to automatically bind the
link to all VLANs for which tag values are observed (or only those
received on the link or only those manually administered). This provides
for trunking links.

David

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Thursday, December 29, 2005 8:21 PM
To: Developing a hybrid router/bridge.
Subject: [rbridge] How are packets/link without a VLAN tag handled in a
bridged network today?

I guessed at the behavior once, to someone who was following 802.1
better than I have been, and he verified that I was correct at the time,
but I've forgotten what my conjecture was. Does anyone know how the
following cases are handled?

Suppose a bridged network has some links configured as VLAN A, and
others configured as VLAN B, and some links that are not configured as
either VLAN A or VLAN B. Let's say that links La1 and La2 are configured
as VLAN A, links Lb1 and Lb2 are configured as Lb, and links Lc1 and Lc2
are not configured to reside in either VLAN A or VLAN B.

Let's further assume that it is the bridges that put on the VLAN tags.

What happens in the following cases?

a) A layer 2 multicast packet originates at La1. Certainly the first
bridge adds a VLAN A tag to the packet, and delivers the packet to La2.
However, does it also deliver it to Lc1 and Lc2? (I'd be very surprised
if the answer to this was yes...I assume the packet will ONLY get
delivered to links that are specifically marked as supporting VLAN A).

b) A layer 2 multicast packet originates at Lc1. I assume the behavior
in this case is that the first bridge does NOT add a VLAN tag to the
packet. I can imagine either in this case that the packet is ONLY
delivered to Lc2 (i.e., other links that are not configured as belonging
to any VLAN), but I suspect the packet is delivered to ALL links, i.e.,
in this case, La1, La2, Lb1, Lb2, and Lc2, and without a VLAN tag.
This would mean that endnodes in VLAN A and endnodes in VLAN B will see
this packet, so perhaps it's the other behavior (that it's only
delivered to links that are not configured as being in any VLAN).

c) If it is the bridge, rather than endnodes that put on the VLAN tag,
is it legal for a link to support multiple VLANs? It would make sense
for the answer to this to be no, in which case I suspect the answer to
b) above would be more likely to be "don't deliver to any links that
have been configured to be in any VLAN", since I suspect "unmarked VLAN"
is treated as a special case VLAN.

Radia

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


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




Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBU3I4i19985 for <[e-mail]>; Thu, 29 Dec 2005 19:18:04 -0800 (PST)
Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by nj300815-ier2.net.avaya.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBU3GXMm019264 for <[e-mail]>; Thu, 29 Dec 2005 22:16:33 -0500
Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id jBU3F5qD012251 for <[e-mail]>; Thu, 29 Dec 2005 22:15:06 -0500 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Date: Thu, 29 Dec 2005 22:18:02 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] How are packets/link without a VLAN tag handled in a bridged network today?
Thread-Index: AcYM4Ma9h6lxkIfzTsuYib3T2Lyl+AADQ1gA
From: "Holland, David \(David\)" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-Scanner: InterScan AntiVirus for Sendmail
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 jBU3I4i19985
Subject: Re: [rbridge] How are packets/link without a VLAN tag handled in a bridged network today?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Dec 2005 03:18:59 -0000
Status: RO
Content-Length: 3077

Radia,

My experience from working on switch/router "brand z", is that the
behavior for "a" (below) is correct.

In the "b" case the packet is NOT flooded to the other vlans UNLESS
those ports are also participating in the (default) untagged vlan by
configuration. 

For item "c": Yes the link can support all VLANS or only selected VLANS.
The configuration options allow for the bridge to automatically bind the
link to all VLANs for which tag values are observed (or only those
received on the link or only those manually administered). This provides
for trunking links.

David

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Thursday, December 29, 2005 8:21 PM
To: Developing a hybrid router/bridge.
Subject: [rbridge] How are packets/link without a VLAN tag handled in a
bridged network today?

I guessed at the behavior once, to someone who was following 802.1
better than I have been, and he verified that I was correct at the time,
but I've forgotten what my conjecture was. Does anyone know how the
following cases are handled?

Suppose a bridged network has some links configured as VLAN A, and
others configured as VLAN B, and some links that are not configured as
either VLAN A or VLAN B. Let's say that links La1 and La2 are configured
as VLAN A, links Lb1 and Lb2 are configured as Lb, and links Lc1 and Lc2
are not configured to reside in either VLAN A or VLAN B.

Let's further assume that it is the bridges that put on the VLAN tags.

What happens in the following cases?

a) A layer 2 multicast packet originates at La1. Certainly the first
bridge adds a VLAN A tag to the packet, and delivers the packet to La2.
However, does it also deliver it to Lc1 and Lc2? (I'd be very surprised
if the answer to this was yes...I assume the packet will ONLY get
delivered to links that are specifically marked as supporting VLAN A).

b) A layer 2 multicast packet originates at Lc1. I assume the behavior
in this case is that the first bridge does NOT add a VLAN tag to the
packet. I can imagine either in this case that the packet is ONLY
delivered to Lc2 (i.e., other links that are not configured as belonging
to any VLAN), but I suspect the packet is delivered to ALL links, i.e.,
in this case, La1, La2, Lb1, Lb2, and Lc2, and without a VLAN tag.
This would mean that endnodes in VLAN A and endnodes in VLAN B will see
this packet, so perhaps it's the other behavior (that it's only
delivered to links that are not configured as being in any VLAN).

c) If it is the bridge, rather than endnodes that put on the VLAN tag,
is it legal for a link to support multiple VLANs? It would make sense
for the answer to this to be no, in which case I suspect the answer to
b) above would be more likely to be "don't deliver to any links that
have been configured to be in any VLAN", since I suspect "unmarked VLAN"
is treated as a special case VLAN.

Radia

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




Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBU1Kci27429 for <[e-mail]>; Thu, 29 Dec 2005 17:20:38 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 29 Dec 2005 17:20:31 -0800 (PST)
Received: from sun.com ([129.150.24.250]) 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 Dec 2005 17:20:29 -0800 (PST)
Date: Thu, 29 Dec 2005 17:20:32 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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] How are packets/link without a VLAN tag handled in a bridged network today?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Dec 2005 01:20:57 -0000
Status: RO
Content-Length: 2075

I guessed at the behavior once, to someone who was following 802.1 
better than I have
been, and he verified that I was correct at the time, but I've forgotten 
what my
conjecture was. Does anyone know how the following cases are handled?

Suppose a bridged network has some links configured
as VLAN A, and others configured as VLAN B, and some links that are not 
configured
as either VLAN A or VLAN B. Let's say that links La1 and La2 are configured
as VLAN A, links Lb1 and Lb2 are configured as Lb, and links Lc1 and Lc2 
are not configured
to reside in either VLAN A or VLAN B.

Let's further assume that it is the bridges that put on the VLAN tags.

What happens in the following cases?

a) A layer 2 multicast packet originates at La1. Certainly the first bridge
adds a VLAN A tag to the packet, and delivers the packet to La2. However,
does it also deliver it to Lc1 and Lc2? (I'd be very surprised if the 
answer to this
was yes...I assume the packet will ONLY get delivered to links that are
specifically marked as supporting VLAN A).

b) A layer 2 multicast packet originates at Lc1. I assume the behavior 
in this case
is that the first bridge does NOT add a VLAN tag to the packet. I can 
imagine either
in this case that the packet is ONLY delivered to Lc2 (i.e., other links 
that are not
configured as belonging to any VLAN), but I suspect the packet is 
delivered to
ALL links, i.e., in this case, La1, La2, Lb1, Lb2, and Lc2, and without 
a VLAN tag.
This would mean that endnodes in VLAN A and endnodes in VLAN B will see 
this packet, so
perhaps it's the other behavior (that it's only delivered to links that 
are not configured as being
in any VLAN).

c) If it is the bridge, rather than endnodes that put on the VLAN tag, 
is it legal for a link
to support multiple VLANs? It would make sense for the answer to this to 
be no, in which
case I suspect the answer to b) above would be more likely to be "don't 
deliver to any links
that have been configured to be in any VLAN", since I suspect "unmarked 
VLAN" is treated as a special
case VLAN.

Radia



Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBPLTTw27996 for <[e-mail]>; Sun, 25 Dec 2005 13:29:29 -0800 (PST)
Received: by zproxy.gmail.com with SMTP id o37so1298165nzf for <[e-mail]>; Sun, 25 Dec 2005 13:29:28 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=A7vl0lGUR05Azgup0kU17qWVTOdaf9j/Bb7tmSl8fpXoltzxKw86fv/+1p5ATtfiCHuPyXdIM0eu3fXxgTME9au7mMZaKE6DKBF6Q5F+NJ6QXRXG5EH+omIDwWWyK3FJEA1K+A1fpqTEdPuCbAg/VAAJzaX5jKrCQxa/I20RNWw=
Received: by 10.65.105.12 with SMTP id h12mr2191051qbm; Sun, 25 Dec 2005 13:29:28 -0800 (PST)
Received: by 10.65.103.12 with HTTP; Sun, 25 Dec 2005 13:29:28 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sun, 25 Dec 2005 13:29:28 -0800
From: Guy Hutchison <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_34618_14477551.1135546168685"
References: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 25 Dec 2005 21:30:10 -0000
Status: RO
Content-Length: 1930

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

On 12/21/05, Christian Huitema <[e-mail]> wrote:
>
>
> The IEEE is working on a better solution for access control to wired
> networks. It will probably involved some level of layer 2 encryption.
> SEND probably needs to evolve in a same way. If it does evolve, then
> there could be an additional requirement, i.e. accept the presence of
> relays on path.


The IEEE layer 2 solution is standards 802.1AE and 802.1af.  1AE provides
hop-by-hop per-packet message authentication and optional encryption; 1af
extends 802.1X to work with the 802.1AE.

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

<br><br><div><span class=3D"gmail_quote">On 12/21/05, <b class=3D"gmail_sen=
dername">Christian Huitema</b> &lt;<a href=3D"mailto:[e-mail]=
oft.com" target=3D"_blank" onclick=3D"return top.js.OpenExtLink(window,even=
t,this)">
[e-mail]</a>&gt; wrote:</span><blockquote class=3D"gma=
il_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0=
pt 0pt 0.8ex; padding-left: 1ex;">
<br>The IEEE is working on a better solution for access control to wired<br=
>networks. It will probably involved some level of layer 2 encryption.
<br>SEND probably needs to evolve in a same way. If it does evolve, then<br=
>there could be an additional requirement, i.e. accept the presence of<br>r=
elays on path.</blockquote><div><br>The IEEE layer 2 solution is standards=
=20
802.1AE and 802.1af.&nbsp; 1AE provides hop-by-hop per-packet message authe=
ntication and optional encryption; 1af extends 802.1X to work with the 802.=
1AE.<br><br></div></div><br>


------=_Part_34618_14477551.1135546168685--


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBNH76w09563; Fri, 23 Dec 2005 09:07:06 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 23 Dec 2005 09:07:07 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 23 Dec 2005 17:08:02 -0000
Status: RO
Content-Length: 4392

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



Guillermo Ib??ez wrote:
> I agree with the idea of directing broadcasts as unicast (my proposal 
> for ARP Servers/Registrars in Abridges draft also uses unicast), but I 
> am a bit lost : How can the first Rbridge know which is the target's 
> designated Rbridge if the destianion host'sMAC is unknown?.

That would be a 'cache miss', and MUST result in a broadcast. We're
still assuming an ARP cache at the DRs.

It's only under a 'hit' that a unicast can be provided.

Joe

> Joe Touch wrote:
> 
> 
> Directing broadcasts as unicast (as suggested below) is probably a
> better idea in general than replaying given security considerations.
> 
> Joe
> 
> Radia Perlman wrote:
>  
> 
> 
>>And even without modifying SEND, it's possible to do a compromise 
>>optimization.
>>The totally nonoptimized thing is to flood the ARP/ND query, and have each
>>Designated RBridge decapsulate and send it on each of the links. The 
>>most optimized thing
>>is to have the first RBridge send the ARP/ND response to the querier.
> 
>>An in-between
>>thing that works with current SEND (and probably any possible variation 
>>that it might
>>evolve into) is to have the first RBridge send the query to the target's 
>>designated RBridge,
>>who would send the query to the target, get a response, and send it back.
> 
>>Radia
> 
> 
> 
>>Christian Huitema wrote:
> 
> 
> 
> 
> 
>>>>>	In addition, since the RBridge enjoys a man-in-the-middle
>>>>>   
>>>>>
>>>>>         
>>>>>
> 
>>>position,
> 
> 
> 
>>>     
> 
> 
>>>>>it is likely that implementers may well implement some hack or
>>>>>   
>>>>>
>>>>>         
>>>>>
> 
>>>another
> 
> 
> 
>>>     
> 
> 
>>>>>to get around this.
>>>>>   
>>>>>
>>>>>         
>>>>>
> 
>>>SEND is explicitly designed to prevent this kind of hacks.
> 
> 
> 
> 
>>>     
> 
> 
>>>>There doesn't need to be a hack - though I expect that would be
>>>>prohibited by the security model in SEND anyway. But SEND doesn't
>>>>prohibit sharing the keys, which the rbridge could be party to.
>>>> 
>>>>
>>>>       
>>>>
> 
>>>Well, there is no explicit protocol to share the keys used in SEND. One
>>>might argue that sharing these keys would in fact be a gross security
>>>violation. The keys are cryptographically linked to the IPv6 address,
>>>and could be used for many applications besides security the IPV6/MAC
>>>address mapping. There have been proposal to use them for IPSEC and for
>>>Mobile IP.
> 
>>>Now, we could question the value of securing the mapping between IP
>>>address and MAC address in a switched/routed environment. After all,
>>>even if the mapping was secure, the relays could still decide to rewrite
>>>the MAC address, and deliver the packets to whatever point they feel is
>>>appropriate. SEND can hardly provide a protection against that. One
>>>possible outcome would be to recognize that SEND, as currently
>>>specified, is not really secure.
> 
>>>In fact, we went through a similar analysis of the value of 802.1X
>>>access controls for wired networks. In wireless networks, 802.1X
>>>associates a MAC address with an encryption context on the access point.
>>>But on wired networks, 802.1X only "authorises a MAC address", without
>>>any further protection. Insert a hub on the path, and all kinds of
>>>interesting attacks become possible.
> 
>>>The IEEE is working on a better solution for access control to wired
>>>networks. It will probably involved some level of layer 2 encryption.
>>>SEND probably needs to evolve in a same way. If it does evolve, then
>>>there could be an additional requirement, i.e. accept the presence of
>>>relays on path.
> 
>>>-- Christian Huitema
> 
> 
>>>_______________________________________________
>>>rbridge mailing list
>>>[e-mail]
>>>http://www.postel.org/mailman/listinfo/rbridge
> 
> 
>>>     
> 
> 
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
> 
> 
> 
_______________________________________________
rbridge mailing list
[e-mail]
http://www.postel.org/mailman/listinfo/rbridge

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

iD8DBQFDrC67E5f5cImnZrsRAg6JAKC62gRQxx5fmJIIoXm+Ttk9NTG35ACeI8tM
y0BqOQY/g0VdKJ+9whD8pZc=
=R2iu
-----END PGP SIGNATURE-----


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 jBNG5Kw23738 for <[e-mail]>; Fri, 23 Dec 2005 08:05:21 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id BC7DB9DF5C for <[e-mail]>; Fri, 23 Dec 2005 17:05:13 +0100 (CET)
Received: from [163.117.203.198] (unknown [163.117.203.198]) by smtp01.uc3m.es (Postfix) with ESMTP id 834429D387 for <[e-mail]>; Fri, 23 Dec 2005 17:05:12 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 23 Dec 2005 17:05:11 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 23 Dec 2005 16:06:09 -0000
Status: RO
Content-Length: 4405

I agree with the idea of directing broadcasts as unicast (my proposal 
for ARP Servers/Registrars in Abridges draft also uses unicast), but I 
am a bit lost : How can the first Rbridge know which is the target's 
designated Rbridge if the destianion host'sMAC is unknown?. Perhaps I 
misunderstood something.
Guillermo
Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Directing broadcasts as unicast (as suggested below) is probably a
>better idea in general than replaying given security considerations.
>
>Joe
>
>Radia Perlman wrote:
>  
>
>>And even without modifying SEND, it's possible to do a compromise 
>>optimization.
>>The totally nonoptimized thing is to flood the ARP/ND query, and have each
>>Designated RBridge decapsulate and send it on each of the links. The 
>>most optimized thing
>>is to have the first RBridge send the ARP/ND response to the querier.
>>
>>An in-between
>>thing that works with current SEND (and probably any possible variation 
>>that it might
>>evolve into) is to have the first RBridge send the query to the target's 
>>designated RBridge,
>>who would send the query to the target, get a response, and send it back.
>>
>>Radia
>>
>>
>>
>>Christian Huitema wrote:
>>
>>
>>    
>>
>>>>>	In addition, since the RBridge enjoys a man-in-the-middle
>>>>>    
>>>>>
>>>>>          
>>>>>
>>>position,
>>>
>>>
>>>
>>>      
>>>
>>>>>it is likely that implementers may well implement some hack or
>>>>>    
>>>>>
>>>>>          
>>>>>
>>>another
>>>
>>>
>>>
>>>      
>>>
>>>>>to get around this.
>>>>>    
>>>>>
>>>>>          
>>>>>
>>>SEND is explicitly designed to prevent this kind of hacks.
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>There doesn't need to be a hack - though I expect that would be
>>>>prohibited by the security model in SEND anyway. But SEND doesn't
>>>>prohibit sharing the keys, which the rbridge could be party to.
>>>>  
>>>>
>>>>        
>>>>
>>>Well, there is no explicit protocol to share the keys used in SEND. One
>>>might argue that sharing these keys would in fact be a gross security
>>>violation. The keys are cryptographically linked to the IPv6 address,
>>>and could be used for many applications besides security the IPV6/MAC
>>>address mapping. There have been proposal to use them for IPSEC and for
>>>Mobile IP.
>>>
>>>Now, we could question the value of securing the mapping between IP
>>>address and MAC address in a switched/routed environment. After all,
>>>even if the mapping was secure, the relays could still decide to rewrite
>>>the MAC address, and deliver the packets to whatever point they feel is
>>>appropriate. SEND can hardly provide a protection against that. One
>>>possible outcome would be to recognize that SEND, as currently
>>>specified, is not really secure.
>>>
>>>In fact, we went through a similar analysis of the value of 802.1X
>>>access controls for wired networks. In wireless networks, 802.1X
>>>associates a MAC address with an encryption context on the access point.
>>>But on wired networks, 802.1X only "authorises a MAC address", without
>>>any further protection. Insert a hub on the path, and all kinds of
>>>interesting attacks become possible.
>>>
>>>The IEEE is working on a better solution for access control to wired
>>>networks. It will probably involved some level of layer 2 encryption.
>>>SEND probably needs to evolve in a same way. If it does evolve, then
>>>there could be an additional requirement, i.e. accept the presence of
>>>relays on path.
>>>
>>>-- Christian Huitema
>>>
>>>
>>>_______________________________________________
>>>rbridge mailing list
>>>[e-mail]
>>>http://www.postel.org/mailman/listinfo/rbridge
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>>    
>>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDquNTE5f5cImnZrsRAu9UAKCAHqIrk064jiQ0bd02O2NtVPBUzwCfQhzB
>/hm9XmTTp2h25Gn92MieJ3w=
>=fMOQ
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

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



Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBMHX0w26980; Thu, 22 Dec 2005 09:33:00 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 22 Dec 2005 09:33:07 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 22 Dec 2005 17:35:04 -0000
Status: RO
Content-Length: 3545

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

Directing broadcasts as unicast (as suggested below) is probably a
better idea in general than replaying given security considerations.

Joe

Radia Perlman wrote:
> And even without modifying SEND, it's possible to do a compromise 
> optimization.
> The totally nonoptimized thing is to flood the ARP/ND query, and have each
> Designated RBridge decapsulate and send it on each of the links. The 
> most optimized thing
> is to have the first RBridge send the ARP/ND response to the querier.
> 
> An in-between
> thing that works with current SEND (and probably any possible variation 
> that it might
> evolve into) is to have the first RBridge send the query to the target's 
> designated RBridge,
> who would send the query to the target, get a response, and send it back.
> 
> Radia
> 
> 
> 
> Christian Huitema wrote:
> 
> 
>>>>	In addition, since the RBridge enjoys a man-in-the-middle
>>>>     
>>>>
>>
>>position,
>> 
>>
>>
>>>>it is likely that implementers may well implement some hack or
>>>>     
>>>>
>>
>>another
>> 
>>
>>
>>>>to get around this.
>>>>     
>>>>
>>
>>SEND is explicitly designed to prevent this kind of hacks.
>>
>> 
>>
>>
>>>There doesn't need to be a hack - though I expect that would be
>>>prohibited by the security model in SEND anyway. But SEND doesn't
>>>prohibit sharing the keys, which the rbridge could be party to.
>>>   
>>>
>>
>>Well, there is no explicit protocol to share the keys used in SEND. One
>>might argue that sharing these keys would in fact be a gross security
>>violation. The keys are cryptographically linked to the IPv6 address,
>>and could be used for many applications besides security the IPV6/MAC
>>address mapping. There have been proposal to use them for IPSEC and for
>>Mobile IP.
>>
>>Now, we could question the value of securing the mapping between IP
>>address and MAC address in a switched/routed environment. After all,
>>even if the mapping was secure, the relays could still decide to rewrite
>>the MAC address, and deliver the packets to whatever point they feel is
>>appropriate. SEND can hardly provide a protection against that. One
>>possible outcome would be to recognize that SEND, as currently
>>specified, is not really secure.
>>
>>In fact, we went through a similar analysis of the value of 802.1X
>>access controls for wired networks. In wireless networks, 802.1X
>>associates a MAC address with an encryption context on the access point.
>>But on wired networks, 802.1X only "authorises a MAC address", without
>>any further protection. Insert a hub on the path, and all kinds of
>>interesting attacks become possible.
>>
>>The IEEE is working on a better solution for access control to wired
>>networks. It will probably involved some level of layer 2 encryption.
>>SEND probably needs to evolve in a same way. If it does evolve, then
>>there could be an additional requirement, i.e. accept the presence of
>>relays on path.
>>
>>-- Christian Huitema
>>
>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>> 
>>
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge

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

iD8DBQFDquNTE5f5cImnZrsRAu9UAKCAHqIrk064jiQ0bd02O2NtVPBUzwCfQhzB
/hm9XmTTp2h25Gn92MieJ3w=
=fMOQ
-----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 jBLLAiw06657 for <[e-mail]>; Wed, 21 Dec 2005 13:10:44 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 21 Dec 2005 13:10:38 -0800 (PST)
Received: from sun.com ([129.150.24.250]) 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 Dec 2005 13:10:38 -0800 (PST)
Date: Wed, 21 Dec 2005 13:10:38 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 21 Dec 2005 21:11:49 -0000
Status: RO
Content-Length: 2820

And even without modifying SEND, it's possible to do a compromise 
optimization.
The totally nonoptimized thing is to flood the ARP/ND query, and have each
Designated RBridge decapsulate and send it on each of the links. The 
most optimized thing
is to have the first RBridge send the ARP/ND response to the querier.

An in-between
thing that works with current SEND (and probably any possible variation 
that it might
evolve into) is to have the first RBridge send the query to the target's 
designated RBridge,
who would send the query to the target, get a response, and send it back.

Radia



Christian Huitema wrote:

>>>	In addition, since the RBridge enjoys a man-in-the-middle
>>>      
>>>
>position,
>  
>
>>>it is likely that implementers may well implement some hack or
>>>      
>>>
>another
>  
>
>>>to get around this.
>>>      
>>>
>
>SEND is explicitly designed to prevent this kind of hacks.
> 
>  
>
>>There doesn't need to be a hack - though I expect that would be
>>prohibited by the security model in SEND anyway. But SEND doesn't
>>prohibit sharing the keys, which the rbridge could be party to.
>>    
>>
>
>Well, there is no explicit protocol to share the keys used in SEND. One
>might argue that sharing these keys would in fact be a gross security
>violation. The keys are cryptographically linked to the IPv6 address,
>and could be used for many applications besides security the IPV6/MAC
>address mapping. There have been proposal to use them for IPSEC and for
>Mobile IP.
>
>Now, we could question the value of securing the mapping between IP
>address and MAC address in a switched/routed environment. After all,
>even if the mapping was secure, the relays could still decide to rewrite
>the MAC address, and deliver the packets to whatever point they feel is
>appropriate. SEND can hardly provide a protection against that. One
>possible outcome would be to recognize that SEND, as currently
>specified, is not really secure.
>
>In fact, we went through a similar analysis of the value of 802.1X
>access controls for wired networks. In wireless networks, 802.1X
>associates a MAC address with an encryption context on the access point.
>But on wired networks, 802.1X only "authorises a MAC address", without
>any further protection. Insert a hub on the path, and all kinds of
>interesting attacks become possible.
>
>The IEEE is working on a better solution for access control to wired
>networks. It will probably involved some level of layer 2 encryption.
>SEND probably needs to evolve in a same way. If it does evolve, then
>there could be an additional requirement, i.e. accept the presence of
>relays on path.
>
>-- Christian Huitema
>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>



Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBLKnuw00660 for <[e-mail]>; Wed, 21 Dec 2005 12:49:56 -0800 (PST)
Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499);  Wed, 21 Dec 2005 12:49:50 -0800
Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 21 Dec 2005 12:49:50 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Dec 2005 12:49:49 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.89]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Dec 2005 12:49:49 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 21 Dec 2005 12:49:49 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] ARP proxying
Thread-Index: AcYFskGvErI99ttlR+iTMb4g0Ppd4gAulx1w
From: "Christian Huitema" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 21 Dec 2005 20:49:49.0956 (UTC) FILETIME=[15DD3440:01C60670]
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 jBLKnuw00660
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 21 Dec 2005 20:50:44 -0000
Status: RO
Content-Length: 1948

> > 	In addition, since the RBridge enjoys a man-in-the-middle
position,
> > it is likely that implementers may well implement some hack or
another
> > to get around this.

SEND is explicitly designed to prevent this kind of hacks.
 
> There doesn't need to be a hack - though I expect that would be
> prohibited by the security model in SEND anyway. But SEND doesn't
> prohibit sharing the keys, which the rbridge could be party to.

Well, there is no explicit protocol to share the keys used in SEND. One
might argue that sharing these keys would in fact be a gross security
violation. The keys are cryptographically linked to the IPv6 address,
and could be used for many applications besides security the IPV6/MAC
address mapping. There have been proposal to use them for IPSEC and for
Mobile IP.

Now, we could question the value of securing the mapping between IP
address and MAC address in a switched/routed environment. After all,
even if the mapping was secure, the relays could still decide to rewrite
the MAC address, and deliver the packets to whatever point they feel is
appropriate. SEND can hardly provide a protection against that. One
possible outcome would be to recognize that SEND, as currently
specified, is not really secure.

In fact, we went through a similar analysis of the value of 802.1X
access controls for wired networks. In wireless networks, 802.1X
associates a MAC address with an encryption context on the access point.
But on wired networks, 802.1X only "authorises a MAC address", without
any further protection. Insert a hub on the path, and all kinds of
interesting attacks become possible.

The IEEE is working on a better solution for access control to wired
networks. It will probably involved some level of layer 2 encryption.
SEND probably needs to evolve in a same way. If it does evolve, then
there could be an additional requirement, i.e. accept the presence of
relays on path.

-- Christian Huitema




Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBLI1qw09161; Wed, 21 Dec 2005 10:01:52 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 21 Dec 2005 10:01:59 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <03fb01c605af$9f3d05b0$[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] TRILL Meeting Minutes?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 21 Dec 2005 18:03:09 -0000
Status: RO
Content-Length: 977

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

Hi, Erik,

This looks good; the (minor) suggestion is to check for names in the
text. Mine and Susan Hares appear to be in-line, rather than left-most
in a case or two (i.e., a missing carriage return here and there).

Joe

Erik Nordmark wrote:
> Erik Nordmark wrote:
> 
>>Spencer Dawkins wrote:
>>
>>
>>>Hi, Erik,
>>>
>>>https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64 
>>>is showing no meeting minutes for TRILL.
> 
> 
> I've uploaded some minutes. If folks have any corrections let me know.
> 
>     Erik
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDqZiXE5f5cImnZrsRAn3qAJwLbvyF7Gfr0pfp9DSgRZCOnJxxJQCfTPUE
jIp6OWdsotg7JFwYuYncgn0=
=Be66
-----END PGP SIGNATURE-----


Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBLAvDw11268 for <[e-mail]>; Wed, 21 Dec 2005 02:57:13 -0800 (PST)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id DA1CF8372F for <[e-mail]>; Wed, 21 Dec 2005 11:57:06 +0100 (CET)
Received: from [163.117.203.116] (unknown [163.117.203.116]) by smtp03.uc3m.es (Postfix) with ESMTP id DAF7F83707 for <[e-mail]>; Wed, 21 Dec 2005 11:57:05 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 21 Dec 2005 11:57:01 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 21 Dec 2005 10:58:00 -0000
Status: RO
Content-Length: 5986

I agree with Radia term "ARP optimization" where no specificity is 
desired or required, and with Joe's term "ARP replay" when an accurate 
description is needed.
Guillermo

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Guillermo Ib??ez wrote:
>  
>
>>I agree we must look for a different term.
>>English is not my mother tongue so I beg your pardon in advance if it 
>>sounds bizarre (weird). How about ARP "recording"  or "storing" (just to 
>>differentiate). 
>>    
>>
>
>These are nuances on the idea of caching - they address capturing and
>retaining ARPs seen on the net. The key feature of what is being
>proposed is to then replay them as if they came from the original source.
>
>I found a couple of other possibilities, but each isn't as accurate as
>replay, IMO:
>
>	- repeater
>		typically this indicates the copy of an incoming frame
>		is sent on an outgoing link; in our case, we want the
>		copy to be generated in response to the ARP request,
>		not just to relay the ARP reply
>
>	- relay
>		same issue as repeater
>
>IMO, replay is the most accurate for this kind of optimization, with
>'spoofing' just as accurate but with a strong hint that the spoofer is
>malicious.
>
>PS - it would be useful to see RFC3756 regarding this issue, and RFC3971
>which appears to defeat such optimization in an rbridge.
>
>- ----
>
>That said, I agree with Radia if the term "ARP/ND optiimization" is the
>general term. I also agree that replying with the destination's MAC is
>the right answer; at no point should non-Rbridge nodes on the net ever
>know - or need to know - about the MAC of an rbridge device, IMO.
>
>  
>
>>In the drat Abridges I use ARP "registering", but this 
>>is an intentional operation.
>>    
>>
>
>That sounds right for what is intended there.
>
>Joe
>
>  
>
>>Guillermo
>>
>>Gray, Eric wrote:
>>
>>
>>    
>>
>>>Joe,
>>>
>>>--> > 	The fact that RFC 925 describes using a cache or ARP 
>>>--> > entries as a basis for what RFC 1009 subsequently defines as
>>>--> > ARP caching (or "the ARP hack"), in no way implies that this 
>>>-->
>>>--> proxy ARP in 1009. 
>>>
>>>Yeah, meant to say "proxy ARP" instead of "ARP caching".
>>>
>>>--> > is what anyone would generally refer to as ARP caching.  In
>>>--> > fact, one use for the cache defined in RFC 925 is the MAC DA
>>>--> > "translation" that occurs in traversing an Internet Gateway
>>>--> > (router).
>>>--> 
>>>--> Except that the rules for ARP caching are the same for all ARP caches -
>>>--> regarding cache refresh, timeout, etc. That's why it's useful and
>>>--> important to consider them equivalent.
>>>
>>>Earlier (Friday, 12/16), in a post on this same subject, Radia said
>>>(in part) 
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>>b) getting rid of stale ARP caches faster by sometimes (we'd have 
>>>>>to decide >>under what circumstances) sending the ARP query directly
>>>>>to the assumed target's link, and making the target respond.
>>>>>    
>>>>>
>>>>>          
>>>>>
>>>I am unclear how this behavior is a significant departure from a
>>>typical ARP cache implementation in a host or router.
>>>
>>>--> > 	While it is clearly too late to change the prior usage,
>>>--> > the function described in RFC 1009 would be better termed an
>>>--> > "ARP Translation" than an "ARP Proxy".
>>>--> 
>>>--> That would require our redefining that term, as well as corresponding
>>>--> proxy terms in other widespread use - notably web proxy. 
>>>
>>>Argument for the sake of argument.  You and I both agree that
>>>we shouldn't use "ARP Proxy" or "Proxy ARP" in this context.
>>>That was abundantly clear in the remainder of the text, as was
>>>also the fact that I am not arguing to change the past.
>>>
>>>--> Proxying in these cases, as well as in general English, 
>>>--> refers to one party _representing_ another, not trying to 
>>>--> fake being another.
>>>
>>>Exactly!  Glad we agree...
>>>
>>>--> > 	I think many of us are convinced that "ARP Proxy" can't
>>>--> > be used because of earlier (historical) reasons (whether we
>>>--> > regard those as in error or not).  I do not think the term
>>>--> > "ARP Replay" is sufficiently descriptive and I believe that
>>>--> > the suggestion is made pejoratively - in what certainly looks
>>>--> > like an attempt to prejudice the working group against any
>>>--> > such discussion.
>>>--> 
>>>--> This _is_ a replay, with all the good AND bad associations. It's
>>>--> useful to consider those issues, e.g., that replay won't work if
>>>--> proper anti-replay measures are implemented.
>>>
>>>I disagree.  Apparently, your offer for someone else to suggest a
>>>term was not genuine as you appear unwilling to accept any such
>>>suggestion.
>>>
>>>Or perhaps it is just me.  Anybody else care to suggest a term?
>>>
>>>--> -----Original Message-----
>>>--> From: [e-mail] 
>>>--> [mailto:[e-mail]] On Behalf Of Joe Touch
>>>--> Sent: Monday, December 19, 2005 11:22 AM
>>>--> To: Developing a hybrid router/bridge.
>>>--> Subject: Re: [rbridge] ARP proxying
>>>--> 
>>>--> _______________________________________________
>>>--> rbridge mailing list
>>>--> [e-mail]
>>>--> http://www.postel.org/mailman/listinfo/rbridge
>>>--> 
>>>_______________________________________________
>>>rbridge mailing list
>>>[e-mail]
>>>http://www.postel.org/mailman/listinfo/rbridge
>>>
>>>
>>>
>>>      
>>>
>>    
>>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDqFwpE5f5cImnZrsRAhhIAJ0SoTf2TX2YFrx8FTSYt9j97B/cYwCeLpaG
>lY0fTqVQ3AMYFHRdqPTQLGE=
>=7HhS
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

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



Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBKNKsw28156 for <[e-mail]>; Tue, 20 Dec 2005 15:20:54 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.108.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id jBKNKr4u002610 for <[e-mail]>; Tue, 20 Dec 2005 15:20:53 -0800 (PST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jBKNKpRW745869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 20 Dec 2005 15:20:52 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 20 Dec 2005 15:20:48 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Erik Nordmark <[e-mail]>
References: <03fb01c605af$9f3d05b0$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] TRILL Meeting Minutes?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2005 23:21:47 -0000
Status: RO
Content-Length: 268

Erik Nordmark wrote:
> Spencer Dawkins wrote:
> 
>> Hi, Erik,
>>
>> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64 
>> is showing no meeting minutes for TRILL.

I've uploaded some minutes. If folks have any corrections let me know.

    Erik


Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBKMfaw15641 for <[e-mail]>; Tue, 20 Dec 2005 14:41:36 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id jBKMfZdK016837 for <[e-mail]>; Tue, 20 Dec 2005 14:41:35 -0800 (PST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jBKMfWiN716341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 20 Dec 2005 14:41:34 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 20 Dec 2005 14:41:32 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <03fb01c605af$9f3d05b0$[e-mail]>
In-Reply-To: <03fb01c605af$9f3d05b0$[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] TRILL Meeting Minutes?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2005 22:42:36 -0000
Status: RO
Content-Length: 395

Spencer Dawkins wrote:
> Hi, Erik,
> 
> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64 is 
> showing no meeting minutes for TRILL.
> 
> Is there anything we can do to help?

Yell at the INT and RTG ADs for having been standing in the way of 
getting a co-chair for 5 months perhaps? ;-)

I'll get some minutes in tonight, before leaving on vacation tomorrow.

    Erik


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBKM8aw04809; Tue, 20 Dec 2005 14:08:36 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 20 Dec 2005 14:08:41 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2005 22:09:38 -0000
Status: RO
Content-Length: 4961

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

Agreed.

Radia Perlman wrote:
> I wasn't arguing about changing the mechanism (that the first RBridge 
> responds to an
> ARP/ND query with the target's MAC address). I was just saying that I 
> don't want the
> name to change if we make slight changes to how it works. So the only 
> thing I was
> arguing was to use the term "ARP/ND optimization" rather than "replay" 
> "proxy" or
> whatever, which seem to have specific and different meanings to people.
> 
> I always think it's useful to consider all sorts of variants of a 
> scheme, and to think about their
> pluses and minuses. I wasn't advocating answering anything other than 
> with the target's MAC address,
> because after carefully considering the implications of the 
> alternatives, we concluded answering
> with the target's MAC address was the best choice.
> 
> So the only point of my note is that we come up with a generic name for 
> the mechanism, or the
> problem we are solving, and then in the spec we say exactly how it 
> works, rather than choosing
> a name that we think will define the mechanism just by its name.
> 
> So...we're all agreeing, right? We'll call it "ARP/ND optimization", the 
> main mechanism will be
> that an RBridge responds to an ARP/ND query with the target's MAC 
> address (if known),
> and we might also suggest states when something more drastic is done 
> rather than depending on
> the RBridge's cache being correct.
> 
> Radia
> 
> 
> 
> Joe Touch wrote:
> 
> 
> 
> 
> Radia Perlman wrote:
>  
> 
> 
>>How about just "ARP/ND optimization". That means that we don't have to 
>>give a name
>>to the actual mechanism...I think that term would be clearly implying 
>>that there are various
>>mechanisms that could do this. I'd hate to have to change the word if we 
>>decided that
>>the Designated RBridge on the querier's link should respond with any of 
>>the following:
> 
>>a) the target's MAC
> 
> 
> 
> That corresponds to what I was calling "ARP replay"
> 
>  
> 
> 
>>b) the DB's MAC
> 
> 
> 
> That corresponds to proxy ARP, and works only if the DB then translates
> that to the MAC of the destination for every frame.
> 
>  
> 
> 
>>c) the egress RBridge's MAC
> 
> 
> 
> That doesn't appear to work; the node sending the ARP request would then
> send unencapsulated traffic to the egress, defeating the 'routing'
> inside the rbridge campus.
> 
>  
> 
> 
>>d) a logical MAC address meaning "my DB's MAC".
> 
> 
> 
> I'm not sure how this differs from (b), except to use a logical MAC
> rather than the physical MAC. The effect would be the same.
> 
> Of the above, only (a) will continue to work if the rbridges are swapped
> with bridges, e.g., for maintenance or due to device failure.
> 
>  
> 
> 
>>There were other alternatives discussed, including not optimizing 
>>ARP/ND...just forwarding them like any other L2 multicast, as well as
>>sending directly to the assumed DB of the target, and forcing the
>>actual target to respond. I think, as I said, that perhaps one of
>>these alternatives should be done sometimes, in case the cache is
>>stale. In DECnet we had a "tryhard" bit that was used primarily in
>>the interface from layer 4 to layer 3 inside a node, which said "get
>>rid of caches that might be stale", which was invoked if layer 4 was
>>having a hard time making a connection to a target. It might be nice
>>to add such signalling from endnode to RBridge at some point, but we
>>don't need it now.
> 
> 
> 
> Stale caches are only one issue; how the caches are refreshed is
> another. Typical ARP caches are refreshed when _either_ they are
> referenced locally or when a new ARP reply is seen (source address of
> the entry in question, see RFC1122 sec 2.3.2.1). It would be hard to
> flush entries in a cache that are nonlocal - as per that section. I.e.,
> if the cache is moved from the host, it needs to have the signalling
> described above at a minimum.
> 
> The other issue is the 'silent relocation' - when a node's MAC address
> changes, or when it silently moves from the segment of one DR to
> another. In either case, traffic will be misdirected until the receiver
> speaks up, but there would be no reason for the receiver to do so.
> 
> As a result, it would be useful to consider the advice of RFC1122 (same
> section) on proxy ARP - to limit the rbridge caching of replies to 1
> minute max, regardless of refresh.
> 
> Joe
_______________________________________________
rbridge mailing list
[e-mail]
http://www.postel.org/mailman/listinfo/rbridge

> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDqIDpE5f5cImnZrsRAva8AKCzS8aer5twE5dSPr0yE8fyhbGaCACg5Kwq
4Q/9YMH6bgTpotAZKMI7Cgc=
=F7NK
-----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 jBKM2tw03375 for <[e-mail]>; Tue, 20 Dec 2005 14:02:55 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 20 Dec 2005 14:02:49 -0800 (PST)
Received: from sun.com ([129.150.24.250]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 20 Dec 2005 14:02:49 -0800 (PST)
Date: Tue, 20 Dec 2005 14:02:46 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2005 22:03:46 -0000
Status: RO
Content-Length: 4689

I wasn't arguing about changing the mechanism (that the first RBridge 
responds to an
ARP/ND query with the target's MAC address). I was just saying that I 
don't want the
name to change if we make slight changes to how it works. So the only 
thing I was
arguing was to use the term "ARP/ND optimization" rather than "replay" 
"proxy" or
whatever, which seem to have specific and different meanings to people.

I always think it's useful to consider all sorts of variants of a 
scheme, and to think about their
pluses and minuses. I wasn't advocating answering anything other than 
with the target's MAC address,
because after carefully considering the implications of the 
alternatives, we concluded answering
with the target's MAC address was the best choice.

So the only point of my note is that we come up with a generic name for 
the mechanism, or the
problem we are solving, and then in the spec we say exactly how it 
works, rather than choosing
a name that we think will define the mechanism just by its name.

So...we're all agreeing, right? We'll call it "ARP/ND optimization", the 
main mechanism will be
that an RBridge responds to an ARP/ND query with the target's MAC 
address (if known),
and we might also suggest states when something more drastic is done 
rather than depending on
the RBridge's cache being correct.

Radia



Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Radia Perlman wrote:
>  
>
>>How about just "ARP/ND optimization". That means that we don't have to 
>>give a name
>>to the actual mechanism...I think that term would be clearly implying 
>>that there are various
>>mechanisms that could do this. I'd hate to have to change the word if we 
>>decided that
>>the Designated RBridge on the querier's link should respond with any of 
>>the following:
>>
>>a) the target's MAC
>>    
>>
>
>That corresponds to what I was calling "ARP replay"
>
>  
>
>>b) the DB's MAC
>>    
>>
>
>That corresponds to proxy ARP, and works only if the DB then translates
>that to the MAC of the destination for every frame.
>
>  
>
>>c) the egress RBridge's MAC
>>    
>>
>
>That doesn't appear to work; the node sending the ARP request would then
>send unencapsulated traffic to the egress, defeating the 'routing'
>inside the rbridge campus.
>
>  
>
>>d) a logical MAC address meaning "my DB's MAC".
>>    
>>
>
>I'm not sure how this differs from (b), except to use a logical MAC
>rather than the physical MAC. The effect would be the same.
>
>Of the above, only (a) will continue to work if the rbridges are swapped
>with bridges, e.g., for maintenance or due to device failure.
>
>  
>
>>There were other alternatives discussed, including not optimizing 
>>ARP/ND...just forwarding them like any other L2 multicast, as well as
>>sending directly to the assumed DB of the target, and forcing the
>>actual target to respond. I think, as I said, that perhaps one of
>>these alternatives should be done sometimes, in case the cache is
>>stale. In DECnet we had a "tryhard" bit that was used primarily in
>>the interface from layer 4 to layer 3 inside a node, which said "get
>>rid of caches that might be stale", which was invoked if layer 4 was
>>having a hard time making a connection to a target. It might be nice
>>to add such signalling from endnode to RBridge at some point, but we
>>don't need it now.
>>    
>>
>
>Stale caches are only one issue; how the caches are refreshed is
>another. Typical ARP caches are refreshed when _either_ they are
>referenced locally or when a new ARP reply is seen (source address of
>the entry in question, see RFC1122 sec 2.3.2.1). It would be hard to
>flush entries in a cache that are nonlocal - as per that section. I.e.,
>if the cache is moved from the host, it needs to have the signalling
>described above at a minimum.
>
>The other issue is the 'silent relocation' - when a node's MAC address
>changes, or when it silently moves from the segment of one DR to
>another. In either case, traffic will be misdirected until the receiver
>speaks up, but there would be no reason for the receiver to do so.
>
>As a result, it would be useful to consider the advice of RFC1122 (same
>section) on proxy ARP - to limit the rbridge caching of replies to 1
>minute max, regardless of refresh.
>
>Joe
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDqHgrE5f5cImnZrsRAhAVAJ0Rd6WqA5m1kRvUcqxjrhZfjirLdACfRxEk
>hE4Zdhs0Ij3mQQVUc+m71uE=
>=yOXx
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>



Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBKLr4w00131 for <[e-mail]>; Tue, 20 Dec 2005 13:53:04 -0800 (PST)
Received: from s73602 (unknown[65.104.224.98]) by comcast.net (rwcrmhc13) with SMTP id <200512202152570150047at9e>; Tue, 20 Dec 2005 21:52:57 +0000
Message-ID: <03fb01c605af$9f3d05b0$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "TRILL/RBRIDGE WG" <[e-mail]>
Date: Tue, 20 Dec 2005 15:52:05 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] TRILL Meeting Minutes?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2005 21:53:35 -0000
Status: RO
Content-Length: 184

Hi, Erik,

https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64 is 
showing no meeting minutes for TRILL.

Is there anything we can do to help?

Thanks,

Spencer 



Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBKLoYw29344; Tue, 20 Dec 2005 13:50:34 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 20 Dec 2005 13:50:40 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2005 21:52:25 -0000
Status: RO
Content-Length: 1328

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



Gray, Eric wrote:
> Joe,
> 
> 	Thanks for the explanation.
> 
> 	I will leave this to be argued by those who are strong proponents 
> of ARP/ND Optimization.  I think the idea has value, but it is not my
> battle.
> 
> 	However, in general, the trust model implicit in a bridged network
> (and further implied by the zero-configuration objective) is one in which
> it is likely that security mechanisms such as these are not used. 

Hard to say. It's more useful in wireless scenarios, but even then the
infrastructure is typically trusted (see below).

> Most
> likely, ARP/ND Optimization can be turned on and off in those RBridges 
> that implement it.
> 
> 	In addition, since the RBridge enjoys a man-in-the-middle position,
> it is likely that implementers may well implement some hack or another
> to get around this.

There doesn't need to be a hack - though I expect that would be
prohibited by the security model in SEND anyway. But SEND doesn't
prohibit sharing the keys, which the rbridge could be party to.

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

iD8DBQFDqHywE5f5cImnZrsRAg/QAJ0fUiMS1PbtS8BSmur2ckoRno09tgCfQASM
DLWi5sZHlLirBJKKZNVe7C4=
=q5ew
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBKLVIw22083; Tue, 20 Dec 2005 13:31:18 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 20 Dec 2005 13:31:23 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2005 21:31:55 -0000
Status: RO
Content-Length: 3049

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



Radia Perlman wrote:
> How about just "ARP/ND optimization". That means that we don't have to 
> give a name
> to the actual mechanism...I think that term would be clearly implying 
> that there are various
> mechanisms that could do this. I'd hate to have to change the word if we 
> decided that
> the Designated RBridge on the querier's link should respond with any of 
> the following:
> 
> a) the target's MAC

That corresponds to what I was calling "ARP replay"

> b) the DB's MAC

That corresponds to proxy ARP, and works only if the DB then translates
that to the MAC of the destination for every frame.

> c) the egress RBridge's MAC

That doesn't appear to work; the node sending the ARP request would then
send unencapsulated traffic to the egress, defeating the 'routing'
inside the rbridge campus.

> d) a logical MAC address meaning "my DB's MAC".

I'm not sure how this differs from (b), except to use a logical MAC
rather than the physical MAC. The effect would be the same.

Of the above, only (a) will continue to work if the rbridges are swapped
with bridges, e.g., for maintenance or due to device failure.

> There were other alternatives discussed, including not optimizing 
> ARP/ND...just forwarding them like any other L2 multicast, as well as
> sending directly to the assumed DB of the target, and forcing the
> actual target to respond. I think, as I said, that perhaps one of
> these alternatives should be done sometimes, in case the cache is
> stale. In DECnet we had a "tryhard" bit that was used primarily in
> the interface from layer 4 to layer 3 inside a node, which said "get
> rid of caches that might be stale", which was invoked if layer 4 was
> having a hard time making a connection to a target. It might be nice
> to add such signalling from endnode to RBridge at some point, but we
> don't need it now.

Stale caches are only one issue; how the caches are refreshed is
another. Typical ARP caches are refreshed when _either_ they are
referenced locally or when a new ARP reply is seen (source address of
the entry in question, see RFC1122 sec 2.3.2.1). It would be hard to
flush entries in a cache that are nonlocal - as per that section. I.e.,
if the cache is moved from the host, it needs to have the signalling
described above at a minimum.

The other issue is the 'silent relocation' - when a node's MAC address
changes, or when it silently moves from the segment of one DR to
another. In either case, traffic will be misdirected until the receiver
speaks up, but there would be no reason for the receiver to do so.

As a result, it would be useful to consider the advice of RFC1122 (same
section) on proxy ARP - to limit the rbridge caching of replies to 1
minute max, regardless of refresh.

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

iD8DBQFDqHgrE5f5cImnZrsRAhAVAJ0Rd6WqA5m1kRvUcqxjrhZfjirLdACfRxEk
hE4Zdhs0Ij3mQQVUc+m71uE=
=yOXx
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBKLTJw21525 for <[e-mail]>; Tue, 20 Dec 2005 13:29:20 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBKLTDdJ020170 for <[e-mail]>; Tue, 20 Dec 2005 16:29:13 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA12794 for <[e-mail]>; Tue, 20 Dec 2005 16:29:12 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <ZF3J3J93>; Tue, 20 Dec 2005 16:29:12 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Tue, 20 Dec 2005 16:29:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2005 21:29:35 -0000
Status: RO
Content-Length: 2234

Joe,

	Thanks for the explanation.

	I will leave this to be argued by those who are strong proponents 
of ARP/ND Optimization.  I think the idea has value, but it is not my
battle.

	However, in general, the trust model implicit in a bridged network
(and further implied by the zero-configuration objective) is one in which
it is likely that security mechanisms such as these are not used.  Most
likely, ARP/ND Optimization can be turned on and off in those RBridges 
that implement it.

	In addition, since the RBridge enjoys a man-in-the-middle position,
it is likely that implementers may well implement some hack or another
to get around this.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Joe Touch
--> Sent: Tuesday, December 20, 2005 3:58 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] ARP proxying
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Gray, Eric wrote:
--> > Joe,
--> > 
--> > 	Your references to RFC 3756 and RFC 3971 are just a bit opaque.
--> > Would you care to expand on what the relationship might 
--> be between what 
--> > we're talking about and IPv6 neighbor discovery security issues?
--> 
--> Sorry - of course.
--> 
--> IPv6 ND has a variant which is intended to address security issues.
--> 
--> RFC3756 describes the threat models, including replay issues.
--> 
--> RFC3971 describes a Standards-Track protocol called SEND - 
--> secure ND,
--> one feature of which is to defeat replay attacks.
--> 
--> The proposed behavior of DR rbridges in "ND optimization" would be
--> defeated by SEND, *unless* the DR had a copy of the keys used to
--> authenticate sources. A simple replay would be defeated.
--> 
--> Joe
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDqHBTE5f5cImnZrsRAm5YAKC+UCE8lZsnNVB3DPZt+eF2BQRL0ACgoGmg
--> 3Xjk/0V3KbRT1iO0XjwWP/A=
--> =cKwk
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBKKvnw12176; Tue, 20 Dec 2005 12:57:49 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 20 Dec 2005 12:57:55 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2005 20:58:36 -0000
Status: RO
Content-Length: 1008

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



Gray, Eric wrote:
> Joe,
> 
> 	Your references to RFC 3756 and RFC 3971 are just a bit opaque.
> Would you care to expand on what the relationship might be between what 
> we're talking about and IPv6 neighbor discovery security issues?

Sorry - of course.

IPv6 ND has a variant which is intended to address security issues.

RFC3756 describes the threat models, including replay issues.

RFC3971 describes a Standards-Track protocol called SEND - secure ND,
one feature of which is to defeat replay attacks.

The proposed behavior of DR rbridges in "ND optimization" would be
defeated by SEND, *unless* the DR had a copy of the keys used to
authenticate sources. A simple replay would be defeated.

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

iD8DBQFDqHBTE5f5cImnZrsRAm5YAKC+UCE8lZsnNVB3DPZt+eF2BQRL0ACgoGmg
3Xjk/0V3KbRT1iO0XjwWP/A=
=cKwk
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBKKESw01133 for <[e-mail]>; Tue, 20 Dec 2005 12:14:28 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBKKEHdJ018648 for <[e-mail]>; Tue, 20 Dec 2005 15:14:18 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA03341 for <[e-mail]>; Tue, 20 Dec 2005 15:14:17 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <ZF3J3HLK>; Tue, 20 Dec 2005 15:14:17 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Tue, 20 Dec 2005 15:14:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id jBKKESw01133
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2005 20:14:42 -0000
Status: RO
Content-Length: 6611

Joe,

	Your references to RFC 3756 and RFC 3971 are just a bit opaque.
Would you care to expand on what the relationship might be between what 
we're talking about and IPv6 neighbor discovery security issues?

--
Eric 

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Joe Touch
--> Sent: Tuesday, December 20, 2005 2:32 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] ARP proxying
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Guillermo Ib??ez wrote:
--> > I agree we must look for a different term.
--> > English is not my mother tongue so I beg your pardon in 
--> advance if it 
--> > sounds bizarre (weird). How about ARP "recording"  or 
--> "storing" (just to 
--> > differentiate). 
--> 
--> These are nuances on the idea of caching - they address 
--> capturing and
--> retaining ARPs seen on the net. The key feature of what is being
--> proposed is to then replay them as if they came from the 
--> original source.
--> 
--> I found a couple of other possibilities, but each isn't as 
--> accurate as
--> replay, IMO:
--> 
--> 	- repeater
--> 		typically this indicates the copy of an incoming frame
--> 		is sent on an outgoing link; in our case, we want the
--> 		copy to be generated in response to the ARP request,
--> 		not just to relay the ARP reply
--> 
--> 	- relay
--> 		same issue as repeater
--> 
--> IMO, replay is the most accurate for this kind of optimization, with
--> 'spoofing' just as accurate but with a strong hint that the 
--> spoofer is
--> malicious.
--> 
--> PS - it would be useful to see RFC3756 regarding this 
--> issue, and RFC3971
--> which appears to defeat such optimization in an rbridge.
--> 
--> - ----
--> 
--> That said, I agree with Radia if the term "ARP/ND 
--> optiimization" is the
--> general term. I also agree that replying with the 
--> destination's MAC is
--> the right answer; at no point should non-Rbridge nodes on 
--> the net ever
--> know - or need to know - about the MAC of an rbridge device, IMO.
--> 
--> > In the drat Abridges I use ARP "registering", but this 
--> > is an intentional operation.
--> 
--> That sounds right for what is intended there.
--> 
--> Joe
--> 
--> > Guillermo
--> > 
--> > Gray, Eric wrote:
--> > 
--> > 
--> >>Joe,
--> >>
--> >>--> > 	The fact that RFC 925 describes using a cache or ARP 
--> >>--> > entries as a basis for what RFC 1009 subsequently defines as
--> >>--> > ARP caching (or "the ARP hack"), in no way implies 
--> that this 
--> >>-->
--> >>--> proxy ARP in 1009. 
--> >>
--> >>Yeah, meant to say "proxy ARP" instead of "ARP caching".
--> >>
--> >>--> > is what anyone would generally refer to as ARP caching.  In
--> >>--> > fact, one use for the cache defined in RFC 925 is the MAC DA
--> >>--> > "translation" that occurs in traversing an Internet Gateway
--> >>--> > (router).
--> >>--> 
--> >>--> Except that the rules for ARP caching are the same 
--> for all ARP caches -
--> >>--> regarding cache refresh, timeout, etc. That's why 
--> it's useful and
--> >>--> important to consider them equivalent.
--> >>
--> >>Earlier (Friday, 12/16), in a post on this same subject, 
--> Radia said
--> >>(in part) 
--> >>
--> >> 
--> >>
--> >>
--> >>>>b) getting rid of stale ARP caches faster by sometimes 
--> (we'd have 
--> >>>>to decide >>under what circumstances) sending the ARP 
--> query directly
--> >>>>to the assumed target's link, and making the target respond.
--> >>>>     
--> >>>>
--> >>
--> >>I am unclear how this behavior is a significant departure from a
--> >>typical ARP cache implementation in a host or router.
--> >>
--> >>--> > 	While it is clearly too late to change the prior usage,
--> >>--> > the function described in RFC 1009 would be better termed an
--> >>--> > "ARP Translation" than an "ARP Proxy".
--> >>--> 
--> >>--> That would require our redefining that term, as well 
--> as corresponding
--> >>--> proxy terms in other widespread use - notably web proxy. 
--> >>
--> >>Argument for the sake of argument.  You and I both agree that
--> >>we shouldn't use "ARP Proxy" or "Proxy ARP" in this context.
--> >>That was abundantly clear in the remainder of the text, as was
--> >>also the fact that I am not arguing to change the past.
--> >>
--> >>--> Proxying in these cases, as well as in general English, 
--> >>--> refers to one party _representing_ another, not trying to 
--> >>--> fake being another.
--> >>
--> >>Exactly!  Glad we agree...
--> >>
--> >>--> > 	I think many of us are convinced that "ARP Proxy" can't
--> >>--> > be used because of earlier (historical) reasons (whether we
--> >>--> > regard those as in error or not).  I do not think the term
--> >>--> > "ARP Replay" is sufficiently descriptive and I believe that
--> >>--> > the suggestion is made pejoratively - in what 
--> certainly looks
--> >>--> > like an attempt to prejudice the working group against any
--> >>--> > such discussion.
--> >>--> 
--> >>--> This _is_ a replay, with all the good AND bad 
--> associations. It's
--> >>--> useful to consider those issues, e.g., that replay 
--> won't work if
--> >>--> proper anti-replay measures are implemented.
--> >>
--> >>I disagree.  Apparently, your offer for someone else to suggest a
--> >>term was not genuine as you appear unwilling to accept any such
--> >>suggestion.
--> >>
--> >>Or perhaps it is just me.  Anybody else care to suggest a term?
--> >>
--> >>--> -----Original Message-----
--> >>--> From: [e-mail] 
--> >>--> [mailto:[e-mail]] On Behalf Of Joe Touch
--> >>--> Sent: Monday, December 19, 2005 11:22 AM
--> >>--> To: Developing a hybrid router/bridge.
--> >>--> Subject: Re: [rbridge] ARP proxying
--> >>--> 
--> >>--> _______________________________________________
--> >>--> rbridge mailing list
--> >>--> [e-mail]
--> >>--> http://www.postel.org/mailman/listinfo/rbridge
--> >>--> 
--> >>_______________________________________________
--> >>rbridge mailing list
--> >>[e-mail]
--> >>http://www.postel.org/mailman/listinfo/rbridge
--> >>
--> >> 
--> >>
--> > 
--> > 
--> 
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDqFwpE5f5cImnZrsRAhhIAJ0SoTf2TX2YFrx8FTSYt9j97B/cYwCeLpaG
--> lY0fTqVQ3AMYFHRdqPTQLGE=
--> =7HhS
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBKJpOw24098 for <[e-mail]>; Tue, 20 Dec 2005 11:51:25 -0800 (PST)
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B41652596D5 for <[e-mail]>; Tue, 20 Dec 2005 20:50:35 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30510-10 for <[e-mail]>; Tue, 20 Dec 2005 20:50:32 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1BB042596CB for <[e-mail]>; Tue, 20 Dec 2005 20:50:32 +0100 (CET)
Date: Tue, 20 Dec 2005 20:54:06 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail] .marconi.com>	<[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2005 19:51:35 -0000
Status: RO
Content-Length: 1119

--On tirsdag, desember 20, 2005 10:51:33 -0800 Radia Perlman 
<[e-mail]> wrote:

> How about just "ARP/ND optimization". That means that we don't have to
> give a name
> to the actual mechanism...I think that term would be clearly implying
> that there are various
> mechanisms that could do this. I'd hate to have to change the word if we
> decided that
> the Designated RBridge on the querier's link should respond with any of
> the following:
>
> a) the target's MAC
> b) the DB's MAC
> c) the egress RBridge's MAC
> d) a logical MAC address meaning "my DB's MAC".
>
> I considered all of these possibilities, and discussed it with a few
> people. We concluded
> that target's MAC was most logical, though any of the above would work.

"ARP/ND optimization" is a fine name.
I don't think either of b), c) or d) would work (for some definition of 
"work") - if you instantiated any of them, the RBridges would have to 
inspect every single packet with such a destination MAC, verify that the 
content was an IP packet, and forwarding based on the L3 address.

I don't think that's a bridge any more.




Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBKJVlw17638; Tue, 20 Dec 2005 11:31:47 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 20 Dec 2005 11:31:53 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.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]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2005 19:32:52 -0000
Status: RO
Content-Length: 5258

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



Guillermo Ib??ez wrote:
> I agree we must look for a different term.
> English is not my mother tongue so I beg your pardon in advance if it 
> sounds bizarre (weird). How about ARP "recording"  or "storing" (just to 
> differentiate). 

These are nuances on the idea of caching - they address capturing and
retaining ARPs seen on the net. The key feature of what is being
proposed is to then replay them as if they came from the original source.

I found a couple of other possibilities, but each isn't as accurate as
replay, IMO:

	- repeater
		typically this indicates the copy of an incoming frame
		is sent on an outgoing link; in our case, we want the
		copy to be generated in response to the ARP request,
		not just to relay the ARP reply

	- relay
		same issue as repeater

IMO, replay is the most accurate for this kind of optimization, with
'spoofing' just as accurate but with a strong hint that the spoofer is
malicious.

PS - it would be useful to see RFC3756 regarding this issue, and RFC3971
which appears to defeat such optimization in an rbridge.

- ----

That said, I agree with Radia if the term "ARP/ND optiimization" is the
general term. I also agree that replying with the destination's MAC is
the right answer; at no point should non-Rbridge nodes on the net ever
know - or need to know - about the MAC of an rbridge device, IMO.

> In the drat Abridges I use ARP "registering", but this 
> is an intentional operation.

That sounds right for what is intended there.

Joe

> Guillermo
> 
> Gray, Eric wrote:
> 
> 
>>Joe,
>>
>>--> > 	The fact that RFC 925 describes using a cache or ARP 
>>--> > entries as a basis for what RFC 1009 subsequently defines as
>>--> > ARP caching (or "the ARP hack"), in no way implies that this 
>>-->
>>--> proxy ARP in 1009. 
>>
>>Yeah, meant to say "proxy ARP" instead of "ARP caching".
>>
>>--> > is what anyone would generally refer to as ARP caching.  In
>>--> > fact, one use for the cache defined in RFC 925 is the MAC DA
>>--> > "translation" that occurs in traversing an Internet Gateway
>>--> > (router).
>>--> 
>>--> Except that the rules for ARP caching are the same for all ARP caches -
>>--> regarding cache refresh, timeout, etc. That's why it's useful and
>>--> important to consider them equivalent.
>>
>>Earlier (Friday, 12/16), in a post on this same subject, Radia said
>>(in part) 
>>
>> 
>>
>>
>>>>b) getting rid of stale ARP caches faster by sometimes (we'd have 
>>>>to decide >>under what circumstances) sending the ARP query directly
>>>>to the assumed target's link, and making the target respond.
>>>>     
>>>>
>>
>>I am unclear how this behavior is a significant departure from a
>>typical ARP cache implementation in a host or router.
>>
>>--> > 	While it is clearly too late to change the prior usage,
>>--> > the function described in RFC 1009 would be better termed an
>>--> > "ARP Translation" than an "ARP Proxy".
>>--> 
>>--> That would require our redefining that term, as well as corresponding
>>--> proxy terms in other widespread use - notably web proxy. 
>>
>>Argument for the sake of argument.  You and I both agree that
>>we shouldn't use "ARP Proxy" or "Proxy ARP" in this context.
>>That was abundantly clear in the remainder of the text, as was
>>also the fact that I am not arguing to change the past.
>>
>>--> Proxying in these cases, as well as in general English, 
>>--> refers to one party _representing_ another, not trying to 
>>--> fake being another.
>>
>>Exactly!  Glad we agree...
>>
>>--> > 	I think many of us are convinced that "ARP Proxy" can't
>>--> > be used because of earlier (historical) reasons (whether we
>>--> > regard those as in error or not).  I do not think the term
>>--> > "ARP Replay" is sufficiently descriptive and I believe that
>>--> > the suggestion is made pejoratively - in what certainly looks
>>--> > like an attempt to prejudice the working group against any
>>--> > such discussion.
>>--> 
>>--> This _is_ a replay, with all the good AND bad associations. It's
>>--> useful to consider those issues, e.g., that replay won't work if
>>--> proper anti-replay measures are implemented.
>>
>>I disagree.  Apparently, your offer for someone else to suggest a
>>term was not genuine as you appear unwilling to accept any such
>>suggestion.
>>
>>Or perhaps it is just me.  Anybody else care to suggest a term?
>>
>>--> -----Original Message-----
>>--> From: [e-mail] 
>>--> [mailto:[e-mail]] On Behalf Of Joe Touch
>>--> Sent: Monday, December 19, 2005 11:22 AM
>>--> To: Developing a hybrid router/bridge.
>>--> Subject: Re: [rbridge] ARP proxying
>>--> 
>>--> _______________________________________________
>>--> rbridge mailing list
>>--> [e-mail]
>>--> http://www.postel.org/mailman/listinfo/rbridge
>>--> 
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>>
>> 
>>
> 
> 

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

iD8DBQFDqFwpE5f5cImnZrsRAhhIAJ0SoTf2TX2YFrx8FTSYt9j97B/cYwCeLpaG
lY0fTqVQ3AMYFHRdqPTQLGE=
=7HhS
-----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 jBKIpdw04297 for <[e-mail]>; Tue, 20 Dec 2005 10:51:39 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 20 Dec 2005 10:51:32 -0800 (PST)
Received: from sun.com ([129.150.24.250]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 20 Dec 2005 10:51:32 -0800 (PST)
Date: Tue, 20 Dec 2005 10:51:33 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 8BIT
X-Accept-Language: en-us, en
References: <[e-mail]> <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2005 18:52:52 -0000
Status: RO
Content-Length: 5474

How about just "ARP/ND optimization". That means that we don't have to 
give a name
to the actual mechanism...I think that term would be clearly implying 
that there are various
mechanisms that could do this. I'd hate to have to change the word if we 
decided that
the Designated RBridge on the querier's link should respond with any of 
the following:

a) the target's MAC
b) the DB's MAC
c) the egress RBridge's MAC
d) a logical MAC address meaning "my DB's MAC".

I considered all of these possibilities, and discussed it with a few 
people. We concluded
that target's MAC was most logical, though any of the above would work. 
I was using
the term "ARP/ND proxy" all along and it didn't seem to confuse anyone, 
but I don't
care about the words...just how the thing works.

There were other alternatives discussed, including not optimizing 
ARP/ND...just forwarding
them like any other L2 multicast, as well as sending directly to the 
assumed DB of the target,
and forcing the actual target to respond. I think, as I said, that 
perhaps one of these
alternatives should be done sometimes, in case the cache is stale. In 
DECnet we had
a "tryhard" bit that was used primarily in the interface from layer 4 to 
layer 3 inside a node,
which said "get rid of caches that might be stale", which was invoked if 
layer 4 was having
a hard time making a connection to a target. It might be nice to add 
such signalling
from endnode to RBridge at some point, but we don't need it now.

If people care, even though I suspect it's alread in the email archives 
somewhere, I can explain
why responding with the target's MAC seemed the best of the alternatives.

Radia



Guillermo Ib??ez wrote:

>I agree we must look for a different term.
>English is not my mother tongue so I beg your pardon in advance if it 
>sounds bizarre (weird). How about ARP "recording"  or "storing" (just to 
>differentiate). In the drat Abridges I use ARP "registering", but this 
>is an intentional operation.
>Guillermo
>
>Gray, Eric wrote:
>
>  
>
>>Joe,
>>
>>--> > 	The fact that RFC 925 describes using a cache or ARP 
>>--> > entries as a basis for what RFC 1009 subsequently defines as
>>--> > ARP caching (or "the ARP hack"), in no way implies that this 
>>-->
>>--> proxy ARP in 1009. 
>>
>>Yeah, meant to say "proxy ARP" instead of "ARP caching".
>>
>>--> > is what anyone would generally refer to as ARP caching.  In
>>--> > fact, one use for the cache defined in RFC 925 is the MAC DA
>>--> > "translation" that occurs in traversing an Internet Gateway
>>--> > (router).
>>--> 
>>--> Except that the rules for ARP caching are the same for all ARP caches -
>>--> regarding cache refresh, timeout, etc. That's why it's useful and
>>--> important to consider them equivalent.
>>
>>Earlier (Friday, 12/16), in a post on this same subject, Radia said
>>(in part) 
>>
>> 
>>
>>    
>>
>>>>b) getting rid of stale ARP caches faster by sometimes (we'd have 
>>>>to decide >>under what circumstances) sending the ARP query directly
>>>>to the assumed target's link, and making the target respond.
>>>>     
>>>>
>>>>        
>>>>
>>I am unclear how this behavior is a significant departure from a
>>typical ARP cache implementation in a host or router.
>>
>>--> > 	While it is clearly too late to change the prior usage,
>>--> > the function described in RFC 1009 would be better termed an
>>--> > "ARP Translation" than an "ARP Proxy".
>>--> 
>>--> That would require our redefining that term, as well as corresponding
>>--> proxy terms in other widespread use - notably web proxy. 
>>
>>Argument for the sake of argument.  You and I both agree that
>>we shouldn't use "ARP Proxy" or "Proxy ARP" in this context.
>>That was abundantly clear in the remainder of the text, as was
>>also the fact that I am not arguing to change the past.
>>
>>--> Proxying in these cases, as well as in general English, 
>>--> refers to one party _representing_ another, not trying to 
>>--> fake being another.
>>
>>Exactly!  Glad we agree...
>>
>>--> > 	I think many of us are convinced that "ARP Proxy" can't
>>--> > be used because of earlier (historical) reasons (whether we
>>--> > regard those as in error or not).  I do not think the term
>>--> > "ARP Replay" is sufficiently descriptive and I believe that
>>--> > the suggestion is made pejoratively - in what certainly looks
>>--> > like an attempt to prejudice the working group against any
>>--> > such discussion.
>>--> 
>>--> This _is_ a replay, with all the good AND bad associations. It's
>>--> useful to consider those issues, e.g., that replay won't work if
>>--> proper anti-replay measures are implemented.
>>
>>I disagree.  Apparently, your offer for someone else to suggest a
>>term was not genuine as you appear unwilling to accept any such
>>suggestion.
>>
>>Or perhaps it is just me.  Anybody else care to suggest a term?
>>
>>--> -----Original Message-----
>>--> From: [e-mail] 
>>--> [mailto:[e-mail]] On Behalf Of Joe Touch
>>--> Sent: Monday, December 19, 2005 11:22 AM
>>--> To: Developing a hybrid router/bridge.
>>--> Subject: Re: [rbridge] ARP proxying
>>--> 
>>--> _______________________________________________
>>--> rbridge mailing list
>>--> [e-mail]
>>--> http://www.postel.org/mailman/listinfo/rbridge
>>--> 
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>>
>> 
>>
>>    
>>
>
>  
>



Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBKHmCw13324 for <[e-mail]>; Tue, 20 Dec 2005 09:48:12 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 895689E3A5 for <[e-mail]>; Tue, 20 Dec 2005 18:48:06 +0100 (CET)
Received: from [163.117.203.116] (unknown [163.117.203.116]) by smtp01.uc3m.es (Postfix) with ESMTP id 505899DD50 for <[e-mail]>; Tue, 20 Dec 2005 18:48:05 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 20 Dec 2005 18:48:04 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2005 17:48:45 -0000
Status: RO
Content-Length: 3795

I agree we must look for a different term.
English is not my mother tongue so I beg your pardon in advance if it 
sounds bizarre (weird). How about ARP "recording"  or "storing" (just to 
differentiate). In the drat Abridges I use ARP "registering", but this 
is an intentional operation.
Guillermo

Gray, Eric wrote:

>Joe,
>
>--> > 	The fact that RFC 925 describes using a cache or ARP 
>--> > entries as a basis for what RFC 1009 subsequently defines as
>--> > ARP caching (or "the ARP hack"), in no way implies that this 
>-->
>--> proxy ARP in 1009. 
>
>Yeah, meant to say "proxy ARP" instead of "ARP caching".
>
>--> > is what anyone would generally refer to as ARP caching.  In
>--> > fact, one use for the cache defined in RFC 925 is the MAC DA
>--> > "translation" that occurs in traversing an Internet Gateway
>--> > (router).
>--> 
>--> Except that the rules for ARP caching are the same for all ARP caches -
>--> regarding cache refresh, timeout, etc. That's why it's useful and
>--> important to consider them equivalent.
>
>Earlier (Friday, 12/16), in a post on this same subject, Radia said
>(in part) 
>
>  
>
>>>b) getting rid of stale ARP caches faster by sometimes (we'd have 
>>>to decide >>under what circumstances) sending the ARP query directly
>>>to the assumed target's link, and making the target respond.
>>>      
>>>
>
>I am unclear how this behavior is a significant departure from a
>typical ARP cache implementation in a host or router.
>
>--> > 	While it is clearly too late to change the prior usage,
>--> > the function described in RFC 1009 would be better termed an
>--> > "ARP Translation" than an "ARP Proxy".
>--> 
>--> That would require our redefining that term, as well as corresponding
>--> proxy terms in other widespread use - notably web proxy. 
>
>Argument for the sake of argument.  You and I both agree that
>we shouldn't use "ARP Proxy" or "Proxy ARP" in this context.
>That was abundantly clear in the remainder of the text, as was
>also the fact that I am not arguing to change the past.
>
>--> Proxying in these cases, as well as in general English, 
>--> refers to one party _representing_ another, not trying to 
>--> fake being another.
>
>Exactly!  Glad we agree...
>
>--> > 	I think many of us are convinced that "ARP Proxy" can't
>--> > be used because of earlier (historical) reasons (whether we
>--> > regard those as in error or not).  I do not think the term
>--> > "ARP Replay" is sufficiently descriptive and I believe that
>--> > the suggestion is made pejoratively - in what certainly looks
>--> > like an attempt to prejudice the working group against any
>--> > such discussion.
>--> 
>--> This _is_ a replay, with all the good AND bad associations. It's
>--> useful to consider those issues, e.g., that replay won't work if
>--> proper anti-replay measures are implemented.
>
>I disagree.  Apparently, your offer for someone else to suggest a
>term was not genuine as you appear unwilling to accept any such
>suggestion.
>
>Or perhaps it is just me.  Anybody else care to suggest a term?
>
>--> -----Original Message-----
>--> From: [e-mail] 
>--> [mailto:[e-mail]] On Behalf Of Joe Touch
>--> Sent: Monday, December 19, 2005 11:22 AM
>--> To: Developing a hybrid router/bridge.
>--> Subject: Re: [rbridge] ARP proxying
>--> 
>--> _______________________________________________
>--> rbridge mailing list
>--> [e-mail]
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> 
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

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



Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBKHeow11275 for <[e-mail]>; Tue, 20 Dec 2005 09:40:50 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F03049E6BD; Tue, 20 Dec 2005 18:40:44 +0100 (CET)
Received: from [163.117.203.116] (unknown [163.117.203.116]) by smtp01.uc3m.es (Postfix) with ESMTP id D32EF9E631; Tue, 20 Dec 2005 18:40:43 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 20 Dec 2005 18:40:43 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS Issue #11 -> now ARCH issue #6
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2005 17:41:41 -0000
Status: RO
Content-Length: 3290

I agree. The terms should be cristal clear to get efficient shared use.
Guillermo

Gray, Eric wrote:

>Erik,
>
>	I agree with dropping the definitions for the terms
>internal and external.  For the most part, where people
>have been using the terms, the meaning intended could be
>either explicitly or implicitly determined from context.
>It has largely been the fact that we had defined these
>terms in at least one document, expected everyone to use 
>them as defined and were having difficulty doing so that
>has caused a lot of the confusion.
>
>--
>Eric
>
>--> -----Original Message-----
>--> From: [e-mail] 
>--> [mailto:[e-mail]] On Behalf Of Erik Nordmark
>--> Sent: Monday, December 19, 2005 7:01 AM
>--> To: Developing a hybrid router/bridge.
>--> Subject: Re: [rbridge] PS Issue #11 -> now ARCH issue #6
>--> 
>--> Joe Touch wrote:
>--> 
>--> > Internal/external as used in the PS doc is specific to protocols
>--> > 'inside' the solution. It is not used the same way in the 
>--> arch document
>--> > (internal/external interfaces).
>--> > 
>--> > That difference needs to be made more clear.
>--> 
>--> 
>--> Or maybe not. Having two different definitions of internal 
>--> and external 
>--> in different documents doesn't improve comprehension.
>--> 
>--> Do we even need any such terms? If not, then we can get rid of any 
>--> confusion by just deleting the terms. Where are the terms 
>--> actually used 
>--> and useful?
>--> 
>--> A rbridge device will be capable of interaction with end 
>--> nodes (station) 
>--> on any interface, by sending and receiving non-encapsulated 
>--> frames. And 
>--> in general it must assume that an end node can exist on any of its 
>--> interfaces, since there can be hubs.
>--> A rbridge device will also be capable of interaction with 
>--> other rbridges 
>--> on any interface, as part of some rbridge discovery/hello 
>--> mechanism as 
>--> well as sending and receiving encapsulate frames.
>--> 
>--> Also, the rbridges in a campus create an overlay topology 
>--> through their 
>--> operation.
>--> 
>--> But I'm pretty sure we can describe all this without needing any 
>--> "internal" or "external" terms.
>--> 
>--> 
>--> Later you wrote:
>--> > The issue isn't that the meaning is hard to understand; 
>--> the issue is
>--> > that the term is inaccurate. Hosts can - and will - sit on that
>--> > interface. I was trying to reserve internal/external for 
>--> a distinction
>--> > between traffic between rbridges and traffic from 
>--> ingress/egress to
>--> > hosts - where inside/outside meant 'inside the campus' 
>--> (invisible to
>--> > hosts) and 'outside to the hosts' (visible to hosts).
>--> 
>--> This is the distinction between encapsulated and non-encapsulated 
>--> frames, right?
>--> 
>--> 
>-->     Erik
>--> _______________________________________________
>--> rbridge mailing list
>--> [e-mail]
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> 
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

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



Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBKHdEw10490 for <[e-mail]>; Tue, 20 Dec 2005 09:39:15 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3903D9E6A0; Tue, 20 Dec 2005 18:39:09 +0100 (CET)
Received: from [163.117.203.116] (unknown [163.117.203.116]) by smtp01.uc3m.es (Postfix) with ESMTP id A4A499E67C; Tue, 20 Dec 2005 18:39:07 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 20 Dec 2005 18:39:07 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2005 17:39:39 -0000
Status: RO
Content-Length: 10362

This is from Radia's draft may 2005:

I would add explicitely that Designated RBridge forward and receives all 
trafic from/to the link.

Guillermo



"2.3. Designated RBridge 

   It is useful for one RBridge on each link to have special duties. 
   Thus one RBridge per link should be elected Designated RBridge. IS-IS 
   already holds such an election. 

   The Designated RBridge is the one on the link that will learn the 
   identities of attached endnodes, initiate a distributed ARP when an 
   ARP query is received for an unknown destination, and answer ARP 
   queries when the target node is known. 


 
 
Perlman                Expires November 2, 2005                [Page 7] "


Gray, Eric wrote:

>Guillermo (or anybody else),
>
>	Could somebody either provide a pointer to earlier
>discussion/summary, or provide a brief summary of what we
>would use a Designated RBridge for and how it would work?
>
>	I think a lot of questions have come up recently 
>that have some bearing on the applicability of designated 
>RBridges...
>
>--
>Eric
>
>--> -----Original Message-----
>--> From: [e-mail] 
>--> [mailto:[e-mail]] On Behalf Of Saikat Ray
>--> Sent: Saturday, December 17, 2005 10:53 AM
>--> To: Guillermo Ib??ez
>--> Cc: Developing a hybrid router/bridge.
>--> Subject: Re: [rbridge] it's time to summarize things
>--> 
>--> This was also discussed :) I raised precisely the same 
>--> issues. Please see
>--> 
>--> http://www.postel.org/pipermail/rbridge/2005-October/000687.html
>--> 
>--> Radia had sent a reply, which I couldn't find in the list. 
>--> Anyway, it is
>--> sufficient that RBridges see the BPDU's to stop packet 
>--> forwarding when a
>--> legacy spanning tree starts to change, they do not need to 
>--> be a part of
>--> the spanning tree for this purpose. But I agree that 
>--> merging the spanning
>--> tree root bridge selection process with DR selection seems 
>--> to be a nice
>--> idea.
>--> 
>--> On Sat, 17 Dec 2005, [ISO-8859-1] Guillermo Ib??ez wrote:
>--> 
>--> >
>--> > Saikat, see below
>--> > Guillermo
>--> >
>--> >
>--> > Saikat Ray wrote:
>--> >
>--> > >>Saikat Ray wrote:
>--> > >>
>--> > >>
>--> > >>
>--> > >>>The simplest, if not the most rigorous, explanation is 
>--> as follows. Replace
>--> > >>>each legacy part of the network by a hub (i.e., first 
>--> remove all RBridges
>--> > >>>
>--> > >>>
>--> > >>>from the topology. Then choose a legacy bridge and 
>--> replace this bridge and
>--> > >>
>--> > >>
>--> > >>>all legacy bridges that have a path to it by a single 
>--> hub, and let all
>--> > >>>end-hosts served by those legacy bridges be connected 
>--> to this hub. Repeat
>--> > >>>this procedure until all legacy bridges are replaced. 
>--> Then finally put the
>--> > >>>RBridges back.). Now, one and only one RBridge 
>--> forwards and receives
>--> > >>>unencapsulated packets from each hub (through 
>--> designated RBridge).
>--> > >>>
>--> > >>>
>--> > >>>
>--> > >>But what happens when two separate hubs with separate RBridges
>--> > >>forwarding each one traffic are connected
>--> > >>by a link restoration between them?. A single "hub" 
>--> will be created with
>--> > >>two Designated RBridges till the
>--> > >>detect the situation. How (and how fast), the DR 
>--> election mechanims
>--> > >>should work in this situation?
>--> > >>Guillermo
>--> > >>
>--> > >>
>--> > >
>--> > >This was discussed long before. The frequency of RBridge 
>--> hello messages
>--> > >will determine the length of transience (once a hello is 
>--> sent, the
>--> > >presence of two RBridges on the same "hub" will be 
>--> detected). Radia had
>--> > >some comments about the numerical value of the 
>--> frequency, which I do not
>--> > >remember; it is in one of the emails on the list :)
>--> > >
>--> > >
>--> > >
>--> > Well, it seems then that we can have loops for all that time.  If
>--> > subsecond intervals are needed, Hello Time must be
>--> > lower than 1 second. I find this mechanism more costly 
>--> than using RSTP,
>--> > (already used by the bridges in the hub) to detect the double DR
>--> > situation.  By using the Root bridge election mechanism of
>--> > RSTP (via colocated bridge), the process uses the 
>--> standard RSTP BPDUs
>--> > and selects in a reliable form a unique Root bridge and 
>--> DR, assuming the
>--> > default bridge priority of bridges for election is worse than the
>--> > default priority of Rbridges (this can be defined at 
>--> will).  Although it
>--> > means a small dependency on the 802.1D standard, it seems 
>--> more advisable
>--> > to rely in a standard mechanism to act in a consistent way than
>--> > duplicate the mechanism and ignore RSTP protocol to obtain full
>--> > independency.
>--> > Rbridges ignoring fully RSTP BPDUs means all that means 
>--> for knowing
>--> > "link" and tree status are dropped, the risk for malfunction is
>--> > increased as  long as Rbridges ignore BPDU information as useless.
>--> > One difference is that if DR Hello messages are not received, or
>--> > messages from new bridges appear, Rbridges might use 
>--> received RSTP BPDU
>--> > information to confirm the cause and motivation of messages, so
>--> > decisions more consistent with RSTP can be taken.
>--> > Perhaps the main argument is that Root bridge election 
>--> stops inmediatly
>--> > the frame forwarding in link (hub) blocking the loop, 
>--> while via DR, the
>--> > stopping is done by Rbridges election. That is not the 
>--> case if spanning
>--> > tree remains active while two DRs coexist on the link 
>--> reinjecting the
>--> > traffic in the link through the Rbridge campus. The 
>--> process requires
>--> > full communication between Rbridges through the link 
>--> while there is a
>--> > loop on it.  Root bridge election does not.
>--> > Guillermo
>--> >
>--> > >> Thus for
>--> > >>
>--> > >>
>--> > >>
>--> > >>>a loop formation, a packet must loop back to a 
>--> designated RBridge, which is
>--> > >>>not possible since RBridges use their own spanning 
>--> tree for sending
>--> > >>>(encapsulated) broadcast traffic.
>--> > >>>
>--> > >>>Hope this helps.
>--> > >>>
>--> > >>>
>--> > >>>
>--> > >>>
>--> > >>>
>--> > >>>>-----Original Message-----
>--> > >>>>From: [e-mail] 
>--> [mailto:[e-mail]] On
>--> > >>>>Behalf Of Tim Shepard
>--> > >>>>Sent: Thursday, December 15, 2005 6:42 PM
>--> > >>>>To: Developing a hybrid router/bridge.
>--> > >>>>Cc: [e-mail]; 'Joe Touch'
>--> > >>>>Subject: Re: [rbridge] it's time to summarize things
>--> > >>>>
>--> > >>>>
>--> > >>>>
>--> > >>>>
>--> > >>>>
>--> > >>>>
>--> > >>>>>Let us suppose that an RBridge is connected to a 
>--> legacy bridge's port
>--> > >>>>>directly, and all RBridges block BPDUs. Then the 
>--> RBridge looks like,
>--> > >>>>>
>--> > >>>>>
>--> > >>>>>
>--> > >>>>>
>--> > >>>>from
>--> > >>>>
>--> > >>>>
>--> > >>>>
>--> > >>>>
>--> > >>>>>the perspective of the legacy brige, either (i) a 
>--> single end-host (with
>--> > >>>>>
>--> > >>>>>
>--> > >>>>>
>--> > >>>>>
>--> > >>>>the
>--> > >>>>
>--> > >>>>
>--> > >>>>
>--> > >>>>
>--> > >>>>>MAC address that of the RBridge) if the RBridge is 
>--> not the designated
>--> > >>>>>RBridge, or (ii) a shared media (like a hub; is the 
>--> standard term
>--> > >>>>>"segment"?) with potentially a lot of MAC addresses 
>--> attached to it (in
>--> > >>>>>
>--> > >>>>>
>--> > >>>>>
>--> > >>>>>
>--> > >>>>fact,
>--> > >>>>[....]
>--> > >>>>
>--> > >>>>
>--> > >>>>
>--> > >>>>
>--> > >>>>>So what exactly do you think is the problem with ARP?
>--> > >>>>>
>--> > >>>>>
>--> > >>>>>
>--> > >>>>>
>--> > >>>>I'm not sure I follow all of the postings on this issue.
>--> > >>>>
>--> > >>>>But after reading through this thread, I'm still left 
>--> wondering what
>--> > >>>>is supposed to make sure packets don't loop forever 
>--> when there are a
>--> > >>>>mix of bridges and rbridges plugged together (in some 
>--> crazy accidental
>--> > >>>>way, creating whatever kind of loop involving bridges 
>--> and rbridges
>--> > >>>>that causes the most trouble).
>--> > >>>>
>--> > >>>>It seems to me that if rbridges block the spanning 
>--> tree forming
>--> > >>>>packets, but do forward (e.g.) ARP traffic, then 
>--> there could be loops
>--> > >>>>that are not broken by either the rbridge system or 
>--> the usual bridge
>--> > >>>>spanning-tree-forming algorithm.
>--> > >>>>
>--> > >>>>Could someone explain succinctly (for someone who is 
>--> just barely
>--> > >>>>following this thread) how a system (of mixed bridges 
>--> and rbridges,
>--> > >>>>plugged together by some Byzantine net admin) will 
>--> ensure that packets
>--> > >>>>are not forwarded in a loop?
>--> > >>>>
>--> > >>>>(And ARP is a good example, since it is supposed to 
>--> go everywhere, but
>--> > >>>>not loop.)
>--> > >>>>
>--> > >>>>
>--> > >>>>Or will there be configuration rules that forbid some 
>--> ways of plugging
>--> > >>>>together bridges and rbridges?
>--> > >>>>
>--> > >>>>			-Tim Shepard
>--> > >>>>			 [e-mail]
>--> > >>>>_______________________________________________
>--> > >>>>rbridge mailing list
>--> > >>>>[e-mail]
>--> > >>>>http://www.postel.org/mailman/listinfo/rbridge
>--> > >>>>
>--> > >>>>
>--> > >>>>
>--> > >>>>
>--> > >>>_______________________________________________
>--> > >>>rbridge mailing list
>--> > >>>[e-mail]
>--> > >>>http://www.postel.org/mailman/listinfo/rbridge
>--> > >>>
>--> > >>>
>--> > >>>
>--> > >>>
>--> > >>>
>--> > >>--
>--> > >>Guillermo Ib??ez
>--> > >>Departamento de Ingenier?a Telem?tica
>--> > >>Universidad Carlos III de Madrid
>--> > >>1.1.B.11 Colmenarejo 91-6241393
>--> > >>4.1.F.13 Legan?s 91-6248794
>--> > >>
>--> > >>
>--> > >>
>--> > >
>--> > >
>--> > >
>--> >
>--> > --
>--> > Guillermo Ib??ez
>--> > Departamento de Ingenier?a Telem?tica
>--> > Universidad Carlos III de Madrid
>--> > 1.1.B.11 Colmenarejo 91-6241393
>--> > 4.1.F.13 Legan?s 91-6248794
>--> >
>--> >
>--> _______________________________________________
>--> rbridge mailing list
>--> [e-mail]
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> 
>
>  
>

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



Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBJMpsw22857; Mon, 19 Dec 2005 14:51:54 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 19 Dec 2005 14:51:59 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Touch <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2005 22:52:42 -0000
Status: RO
Content-Length: 3113

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



Joe Touch wrote:
> 
> 
> Gray, Eric wrote:
> ...
> 
>>>--> > is what anyone would generally refer to as ARP caching.  In
>>>--> > fact, one use for the cache defined in RFC 925 is the MAC DA
>>>--> > "translation" that occurs in traversing an Internet Gateway
>>>--> > (router).
>>>--> 
>>>--> Except that the rules for ARP caching are the same for all ARP caches -
>>>--> regarding cache refresh, timeout, etc. That's why it's useful and
>>>--> important to consider them equivalent.
>>>
>>>Earlier (Friday, 12/16), in a post on this same subject, Radia said
>>>(in part) 
>>>
>>>
>>>>>b) getting rid of stale ARP caches faster by sometimes (we'd have 
>>>>>to decide >>under what circumstances) sending the ARP query directly
>>>>>to the assumed target's link, and making the target respond.
>>>
>>>I am unclear how this behavior is a significant departure from a
>>>typical ARP cache implementation in a host or router.
> 
> 
> ARP caches don't typically remove non-stale entries of their own accord;
> when they do, they don't emit ARP requests except based on a trigger of
> need (e.g., a cache miss of an IP packet to be emitted).
> 
> ARP caches are typically updated by ARP activity as snooped on the wire,
> i.e., if a new ARP request or response would replace an entry, the entry
> is silently updated.
> 
> ...
> 
>>>--> > 	I think many of us are convinced that "ARP Proxy" can't
>>>--> > be used because of earlier (historical) reasons (whether we
>>>--> > regard those as in error or not).  I do not think the term
>>>--> > "ARP Replay" is sufficiently descriptive and I believe that
>>>--> > the suggestion is made pejoratively - in what certainly looks
>>>--> > like an attempt to prejudice the working group against any
>>>--> > such discussion.
>>>--> 
>>>--> This _is_ a replay, with all the good AND bad associations. It's
>>>--> useful to consider those issues, e.g., that replay won't work if
>>>--> proper anti-replay measures are implemented.
>>>
>>>I disagree.  Apparently, your offer for someone else to suggest a
>>>term was not genuine as you appear unwilling to accept any such
>>>suggestion.
> 
> 
> Your suggestion was to use ARP caching. We agree not to try to redefine
> proxy ARP, but ARP caching has an equally old and established
> definition. While it is part of proxy ARP and ARP replay (or whatever
> the latter ends up being called), it's clear it isn't appropriate to
> describe it either.
           ^^

to describe what it is that rbridges should/could do for optimization...

> 
> It would also be useful to explain how you disagree with my assessment
> of how this IS replay (i.e., did you mean it is NOT replay, it is NOT
> useful to consider the issues, or that what we're asking an rbridge to
> do would continue to work in the presence of anti-replay?)
> 
> JOe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDpzmPE5f5cImnZrsRAo0bAKCE9yOomiMsIjYHugwjGe7t22//TQCgo/2V
a1xccwstrrvs8hH+faTq5tw=
=nc+I
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBJMnfw22356; Mon, 19 Dec 2005 14:49:41 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 19 Dec 2005 14:49:46 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2005 22:50:46 -0000
Status: RO
Content-Length: 2899

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



Gray, Eric wrote:
...
> --> > is what anyone would generally refer to as ARP caching.  In
> --> > fact, one use for the cache defined in RFC 925 is the MAC DA
> --> > "translation" that occurs in traversing an Internet Gateway
> --> > (router).
> --> 
> --> Except that the rules for ARP caching are the same for all ARP caches -
> --> regarding cache refresh, timeout, etc. That's why it's useful and
> --> important to consider them equivalent.
> 
> Earlier (Friday, 12/16), in a post on this same subject, Radia said
> (in part) 
> 
>>>b) getting rid of stale ARP caches faster by sometimes (we'd have 
>>>to decide >>under what circumstances) sending the ARP query directly
>>>to the assumed target's link, and making the target respond.
> 
> I am unclear how this behavior is a significant departure from a
> typical ARP cache implementation in a host or router.

ARP caches don't typically remove non-stale entries of their own accord;
when they do, they don't emit ARP requests except based on a trigger of
need (e.g., a cache miss of an IP packet to be emitted).

ARP caches are typically updated by ARP activity as snooped on the wire,
i.e., if a new ARP request or response would replace an entry, the entry
is silently updated.

...
> --> > 	I think many of us are convinced that "ARP Proxy" can't
> --> > be used because of earlier (historical) reasons (whether we
> --> > regard those as in error or not).  I do not think the term
> --> > "ARP Replay" is sufficiently descriptive and I believe that
> --> > the suggestion is made pejoratively - in what certainly looks
> --> > like an attempt to prejudice the working group against any
> --> > such discussion.
> --> 
> --> This _is_ a replay, with all the good AND bad associations. It's
> --> useful to consider those issues, e.g., that replay won't work if
> --> proper anti-replay measures are implemented.
> 
> I disagree.  Apparently, your offer for someone else to suggest a
> term was not genuine as you appear unwilling to accept any such
> suggestion.

Your suggestion was to use ARP caching. We agree not to try to redefine
proxy ARP, but ARP caching has an equally old and established
definition. While it is part of proxy ARP and ARP replay (or whatever
the latter ends up being called), it's clear it isn't appropriate to
describe it either.

It would also be useful to explain how you disagree with my assessment
of how this IS replay (i.e., did you mean it is NOT replay, it is NOT
useful to consider the issues, or that what we're asking an rbridge to
do would continue to work in the presence of anti-replay?)

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

iD8DBQFDpzkKE5f5cImnZrsRAsJiAJwMja0uTyMUEVZdzqLIHAYck6vJtACg+o2Z
ZVxnIbPbIOUMkT5wwqpf+vo=
=xszf
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBJIEOw02865 for <[e-mail]>; Mon, 19 Dec 2005 10:14:24 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBJIEIdJ021204 for <[e-mail]>; Mon, 19 Dec 2005 13:14:18 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA12790 for <[e-mail]>; Mon, 19 Dec 2005 13:14:18 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <ZF3JMZNX>; Mon, 19 Dec 2005 13:14:17 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Mon, 19 Dec 2005 13:14:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2005 18:15:30 -0000
Status: RO
Content-Length: 3081

Joe,

--> > 	The fact that RFC 925 describes using a cache or ARP 
--> > entries as a basis for what RFC 1009 subsequently defines as
--> > ARP caching (or "the ARP hack"), in no way implies that this 
-->
--> proxy ARP in 1009. 

Yeah, meant to say "proxy ARP" instead of "ARP caching".

--> > is what anyone would generally refer to as ARP caching.  In
--> > fact, one use for the cache defined in RFC 925 is the MAC DA
--> > "translation" that occurs in traversing an Internet Gateway
--> > (router).
--> 
--> Except that the rules for ARP caching are the same for all ARP caches -
--> regarding cache refresh, timeout, etc. That's why it's useful and
--> important to consider them equivalent.

Earlier (Friday, 12/16), in a post on this same subject, Radia said
(in part) 

>> b) getting rid of stale ARP caches faster by sometimes (we'd have 
>> to decide >>under what circumstances) sending the ARP query directly
>> to the assumed target's link, and making the target respond.

I am unclear how this behavior is a significant departure from a
typical ARP cache implementation in a host or router.

--> > 	While it is clearly too late to change the prior usage,
--> > the function described in RFC 1009 would be better termed an
--> > "ARP Translation" than an "ARP Proxy".
--> 
--> That would require our redefining that term, as well as corresponding
--> proxy terms in other widespread use - notably web proxy. 

Argument for the sake of argument.  You and I both agree that
we shouldn't use "ARP Proxy" or "Proxy ARP" in this context.
That was abundantly clear in the remainder of the text, as was
also the fact that I am not arguing to change the past.

--> Proxying in these cases, as well as in general English, 
--> refers to one party _representing_ another, not trying to 
--> fake being another.

Exactly!  Glad we agree...

--> > 	I think many of us are convinced that "ARP Proxy" can't
--> > be used because of earlier (historical) reasons (whether we
--> > regard those as in error or not).  I do not think the term
--> > "ARP Replay" is sufficiently descriptive and I believe that
--> > the suggestion is made pejoratively - in what certainly looks
--> > like an attempt to prejudice the working group against any
--> > such discussion.
--> 
--> This _is_ a replay, with all the good AND bad associations. It's
--> useful to consider those issues, e.g., that replay won't work if
--> proper anti-replay measures are implemented.

I disagree.  Apparently, your offer for someone else to suggest a
term was not genuine as you appear unwilling to accept any such
suggestion.

Or perhaps it is just me.  Anybody else care to suggest a term?

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Joe Touch
--> Sent: Monday, December 19, 2005 11:22 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] ARP proxying
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBJHphw24749; Mon, 19 Dec 2005 09:51:43 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 19 Dec 2005 09:51:46 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS Issue #11 -> now ARCH issue #6
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2005 17:53:58 -0000
Status: RO
Content-Length: 2990

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



Erik Nordmark wrote:
> Joe Touch wrote:
> 
> 
>>Internal/external as used in the PS doc is specific to protocols
>>'inside' the solution. It is not used the same way in the arch document
>>(internal/external interfaces).
>>
>>That difference needs to be made more clear.
> 
> Or maybe not. Having two different definitions of internal and external 
> in different documents doesn't improve comprehension.

The term 'inside' in the PS doc refers to components and protocols local
to the solution, rather than those that are visible to the rest of the
L2 network.

The terms 'internal interface' and 'external interface' in the ARCH doc
is consistent with the terms 'inside' and 'outside' in the PS, but is
specific to a component of the described architecture.

We can try to pick mutually exclusive adjectives throughout, but in this
case the use is consistent, and the terms sufficiently qualified
(interface) to be clear.

> Do we even need any such terms? If not, then we can get rid of any 
> confusion by just deleting the terms. Where are the terms actually used 
> and useful?

Grep for them in the docs; if there's a way to get rid of them without
being too roundabout, fine. However, they've been used pervasively in
discussions of the protocols and mechanisms.

> A rbridge device will be capable of interaction with end nodes (station) 
> on any interface, by sending and receiving non-encapsulated frames. And 
> in general it must assume that an end node can exist on any of its 
> interfaces, since there can be hubs.
> A rbridge device will also be capable of interaction with other rbridges 
> on any interface, as part of some rbridge discovery/hello mechanism as 
> well as sending and receiving encapsulate frames.
> 
> Also, the rbridges in a campus create an overlay topology through their 
> operation.
> 
> But I'm pretty sure we can describe all this without needing any 
> "internal" or "external" terms.

Perhaps, but why? It's clear enough from the above.

> Later you wrote:
> 
>>The issue isn't that the meaning is hard to understand; the issue is
>>that the term is inaccurate. Hosts can - and will - sit on that
>>interface. I was trying to reserve internal/external for a distinction
>>between traffic between rbridges and traffic from ingress/egress to
>>hosts - where inside/outside meant 'inside the campus' (invisible to
>>hosts) and 'outside to the hosts' (visible to hosts).
> 
> This is the distinction between encapsulated and non-encapsulated 
> frames, right?

If we're talking about frames, yes. But what about the protocol to
manage the paths of encapsulated frames? That's unnecessarily awkward,
compared to 'internal routing protocol'.

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

iD8DBQFDpvMyE5f5cImnZrsRArJDAJ93GPU/yR6sGUTMElJh7Z6qMhXgPACg5Ke9
c75/zCYBHfS8D1LIwgS1SrU=
=ulKb
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBJHnUw23893 for <[e-mail]>; Mon, 19 Dec 2005 09:49:55 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBJHnJdJ020655; Mon, 19 Dec 2005 12:49:20 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA09953;  Mon, 19 Dec 2005 12:49:19 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <ZF3JMYSP>; Mon, 19 Dec 2005 12:49:18 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "Erik Nordmark ([e-mail])" <[e-mail]>
Date: Mon, 19 Dec 2005 12:49:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: Re: [rbridge] PS Issue #11 -> now ARCH issue #6
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2005 17:51:02 -0000
Status: RO
Content-Length: 2805

Erik,

	I agree with dropping the definitions for the terms
internal and external.  For the most part, where people
have been using the terms, the meaning intended could be
either explicitly or implicitly determined from context.
It has largely been the fact that we had defined these
terms in at least one document, expected everyone to use 
them as defined and were having difficulty doing so that
has caused a lot of the confusion.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Erik Nordmark
--> Sent: Monday, December 19, 2005 7:01 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS Issue #11 -> now ARCH issue #6
--> 
--> Joe Touch wrote:
--> 
--> > Internal/external as used in the PS doc is specific to protocols
--> > 'inside' the solution. It is not used the same way in the 
--> arch document
--> > (internal/external interfaces).
--> > 
--> > That difference needs to be made more clear.
--> 
--> 
--> Or maybe not. Having two different definitions of internal 
--> and external 
--> in different documents doesn't improve comprehension.
--> 
--> Do we even need any such terms? If not, then we can get rid of any 
--> confusion by just deleting the terms. Where are the terms 
--> actually used 
--> and useful?
--> 
--> A rbridge device will be capable of interaction with end 
--> nodes (station) 
--> on any interface, by sending and receiving non-encapsulated 
--> frames. And 
--> in general it must assume that an end node can exist on any of its 
--> interfaces, since there can be hubs.
--> A rbridge device will also be capable of interaction with 
--> other rbridges 
--> on any interface, as part of some rbridge discovery/hello 
--> mechanism as 
--> well as sending and receiving encapsulate frames.
--> 
--> Also, the rbridges in a campus create an overlay topology 
--> through their 
--> operation.
--> 
--> But I'm pretty sure we can describe all this without needing any 
--> "internal" or "external" terms.
--> 
--> 
--> Later you wrote:
--> > The issue isn't that the meaning is hard to understand; 
--> the issue is
--> > that the term is inaccurate. Hosts can - and will - sit on that
--> > interface. I was trying to reserve internal/external for 
--> a distinction
--> > between traffic between rbridges and traffic from 
--> ingress/egress to
--> > hosts - where inside/outside meant 'inside the campus' 
--> (invisible to
--> > hosts) and 'outside to the hosts' (visible to hosts).
--> 
--> This is the distinction between encapsulated and non-encapsulated 
--> frames, right?
--> 
--> 
-->     Erik
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBJGjHw05045 for <[e-mail]>; Mon, 19 Dec 2005 08:45:17 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBJGj7dJ019004; Mon, 19 Dec 2005 11:45:07 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA01744;  Mon, 19 Dec 2005 11:45:06 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <ZF3JMWHZ>; Mon, 19 Dec 2005 11:45:06 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Mon, 19 Dec 2005 11:45:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id jBJGjHw05045
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2005 16:45:25 -0000
Status: RO
Content-Length: 9189

Guillermo (or anybody else),

	Could somebody either provide a pointer to earlier
discussion/summary, or provide a brief summary of what we
would use a Designated RBridge for and how it would work?

	I think a lot of questions have come up recently 
that have some bearing on the applicability of designated 
RBridges...

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Saikat Ray
--> Sent: Saturday, December 17, 2005 10:53 AM
--> To: Guillermo Ib??ez
--> Cc: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] it's time to summarize things
--> 
--> This was also discussed :) I raised precisely the same 
--> issues. Please see
--> 
--> http://www.postel.org/pipermail/rbridge/2005-October/000687.html
--> 
--> Radia had sent a reply, which I couldn't find in the list. 
--> Anyway, it is
--> sufficient that RBridges see the BPDU's to stop packet 
--> forwarding when a
--> legacy spanning tree starts to change, they do not need to 
--> be a part of
--> the spanning tree for this purpose. But I agree that 
--> merging the spanning
--> tree root bridge selection process with DR selection seems 
--> to be a nice
--> idea.
--> 
--> On Sat, 17 Dec 2005, [ISO-8859-1] Guillermo Ib??ez wrote:
--> 
--> >
--> > Saikat, see below
--> > Guillermo
--> >
--> >
--> > Saikat Ray wrote:
--> >
--> > >>Saikat Ray wrote:
--> > >>
--> > >>
--> > >>
--> > >>>The simplest, if not the most rigorous, explanation is 
--> as follows. Replace
--> > >>>each legacy part of the network by a hub (i.e., first 
--> remove all RBridges
--> > >>>
--> > >>>
--> > >>>from the topology. Then choose a legacy bridge and 
--> replace this bridge and
--> > >>
--> > >>
--> > >>>all legacy bridges that have a path to it by a single 
--> hub, and let all
--> > >>>end-hosts served by those legacy bridges be connected 
--> to this hub. Repeat
--> > >>>this procedure until all legacy bridges are replaced. 
--> Then finally put the
--> > >>>RBridges back.). Now, one and only one RBridge 
--> forwards and receives
--> > >>>unencapsulated packets from each hub (through 
--> designated RBridge).
--> > >>>
--> > >>>
--> > >>>
--> > >>But what happens when two separate hubs with separate RBridges
--> > >>forwarding each one traffic are connected
--> > >>by a link restoration between them?. A single "hub" 
--> will be created with
--> > >>two Designated RBridges till the
--> > >>detect the situation. How (and how fast), the DR 
--> election mechanims
--> > >>should work in this situation?
--> > >>Guillermo
--> > >>
--> > >>
--> > >
--> > >This was discussed long before. The frequency of RBridge 
--> hello messages
--> > >will determine the length of transience (once a hello is 
--> sent, the
--> > >presence of two RBridges on the same "hub" will be 
--> detected). Radia had
--> > >some comments about the numerical value of the 
--> frequency, which I do not
--> > >remember; it is in one of the emails on the list :)
--> > >
--> > >
--> > >
--> > Well, it seems then that we can have loops for all that time.  If
--> > subsecond intervals are needed, Hello Time must be
--> > lower than 1 second. I find this mechanism more costly 
--> than using RSTP,
--> > (already used by the bridges in the hub) to detect the double DR
--> > situation.  By using the Root bridge election mechanism of
--> > RSTP (via colocated bridge), the process uses the 
--> standard RSTP BPDUs
--> > and selects in a reliable form a unique Root bridge and 
--> DR, assuming the
--> > default bridge priority of bridges for election is worse than the
--> > default priority of Rbridges (this can be defined at 
--> will).  Although it
--> > means a small dependency on the 802.1D standard, it seems 
--> more advisable
--> > to rely in a standard mechanism to act in a consistent way than
--> > duplicate the mechanism and ignore RSTP protocol to obtain full
--> > independency.
--> > Rbridges ignoring fully RSTP BPDUs means all that means 
--> for knowing
--> > "link" and tree status are dropped, the risk for malfunction is
--> > increased as  long as Rbridges ignore BPDU information as useless.
--> > One difference is that if DR Hello messages are not received, or
--> > messages from new bridges appear, Rbridges might use 
--> received RSTP BPDU
--> > information to confirm the cause and motivation of messages, so
--> > decisions more consistent with RSTP can be taken.
--> > Perhaps the main argument is that Root bridge election 
--> stops inmediatly
--> > the frame forwarding in link (hub) blocking the loop, 
--> while via DR, the
--> > stopping is done by Rbridges election. That is not the 
--> case if spanning
--> > tree remains active while two DRs coexist on the link 
--> reinjecting the
--> > traffic in the link through the Rbridge campus. The 
--> process requires
--> > full communication between Rbridges through the link 
--> while there is a
--> > loop on it.  Root bridge election does not.
--> > Guillermo
--> >
--> > >> Thus for
--> > >>
--> > >>
--> > >>
--> > >>>a loop formation, a packet must loop back to a 
--> designated RBridge, which is
--> > >>>not possible since RBridges use their own spanning 
--> tree for sending
--> > >>>(encapsulated) broadcast traffic.
--> > >>>
--> > >>>Hope this helps.
--> > >>>
--> > >>>
--> > >>>
--> > >>>
--> > >>>
--> > >>>>-----Original Message-----
--> > >>>>From: [e-mail] 
--> [mailto:[e-mail]] On
--> > >>>>Behalf Of Tim Shepard
--> > >>>>Sent: Thursday, December 15, 2005 6:42 PM
--> > >>>>To: Developing a hybrid router/bridge.
--> > >>>>Cc: [e-mail]; 'Joe Touch'
--> > >>>>Subject: Re: [rbridge] it's time to summarize things
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>>Let us suppose that an RBridge is connected to a 
--> legacy bridge's port
--> > >>>>>directly, and all RBridges block BPDUs. Then the 
--> RBridge looks like,
--> > >>>>>
--> > >>>>>
--> > >>>>>
--> > >>>>>
--> > >>>>from
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>>the perspective of the legacy brige, either (i) a 
--> single end-host (with
--> > >>>>>
--> > >>>>>
--> > >>>>>
--> > >>>>>
--> > >>>>the
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>>MAC address that of the RBridge) if the RBridge is 
--> not the designated
--> > >>>>>RBridge, or (ii) a shared media (like a hub; is the 
--> standard term
--> > >>>>>"segment"?) with potentially a lot of MAC addresses 
--> attached to it (in
--> > >>>>>
--> > >>>>>
--> > >>>>>
--> > >>>>>
--> > >>>>fact,
--> > >>>>[....]
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>>So what exactly do you think is the problem with ARP?
--> > >>>>>
--> > >>>>>
--> > >>>>>
--> > >>>>>
--> > >>>>I'm not sure I follow all of the postings on this issue.
--> > >>>>
--> > >>>>But after reading through this thread, I'm still left 
--> wondering what
--> > >>>>is supposed to make sure packets don't loop forever 
--> when there are a
--> > >>>>mix of bridges and rbridges plugged together (in some 
--> crazy accidental
--> > >>>>way, creating whatever kind of loop involving bridges 
--> and rbridges
--> > >>>>that causes the most trouble).
--> > >>>>
--> > >>>>It seems to me that if rbridges block the spanning 
--> tree forming
--> > >>>>packets, but do forward (e.g.) ARP traffic, then 
--> there could be loops
--> > >>>>that are not broken by either the rbridge system or 
--> the usual bridge
--> > >>>>spanning-tree-forming algorithm.
--> > >>>>
--> > >>>>Could someone explain succinctly (for someone who is 
--> just barely
--> > >>>>following this thread) how a system (of mixed bridges 
--> and rbridges,
--> > >>>>plugged together by some Byzantine net admin) will 
--> ensure that packets
--> > >>>>are not forwarded in a loop?
--> > >>>>
--> > >>>>(And ARP is a good example, since it is supposed to 
--> go everywhere, but
--> > >>>>not loop.)
--> > >>>>
--> > >>>>
--> > >>>>Or will there be configuration rules that forbid some 
--> ways of plugging
--> > >>>>together bridges and rbridges?
--> > >>>>
--> > >>>>			-Tim Shepard
--> > >>>>			 [e-mail]
--> > >>>>_______________________________________________
--> > >>>>rbridge mailing list
--> > >>>>[e-mail]
--> > >>>>http://www.postel.org/mailman/listinfo/rbridge
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>_______________________________________________
--> > >>>rbridge mailing list
--> > >>>[e-mail]
--> > >>>http://www.postel.org/mailman/listinfo/rbridge
--> > >>>
--> > >>>
--> > >>>
--> > >>>
--> > >>>
--> > >>--
--> > >>Guillermo Ib??ez
--> > >>Departamento de Ingenier?a Telem?tica
--> > >>Universidad Carlos III de Madrid
--> > >>1.1.B.11 Colmenarejo 91-6241393
--> > >>4.1.F.13 Legan?s 91-6248794
--> > >>
--> > >>
--> > >>
--> > >
--> > >
--> > >
--> >
--> > --
--> > Guillermo Ib??ez
--> > Departamento de Ingenier?a Telem?tica
--> > Universidad Carlos III de Madrid
--> > 1.1.B.11 Colmenarejo 91-6241393
--> > 4.1.F.13 Legan?s 91-6248794
--> >
--> >
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBJGMHw28332; Mon, 19 Dec 2005 08:22:17 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 19 Dec 2005 08:22:10 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig20A0E5FD7094A046609B427A"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2005 16:22:45 -0000
Status: RO
Content-Length: 3975

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



Gray, Eric wrote:
> Joe,
>=20
> 	Are you sure that you're not deliberately trying to make
> things more difficult to understand?

As Harald said, we need to use existing terms in existing ways. Both
proxy ARP and ARP caching are existing, well-defined terms, and neither
applies to what we have been describing for rbridges.

> 	Caching - in general - is well understood.  The form of
> storing ARP entries in passing - in order to reduce ARP traffic
> across the RBridge campus - that I have seen described on this
> list so far, is directly analogous to any number of different
> "Caching" uses.

Analogous perhaps, and certainly proxy ARP and ARP reply, as well as end
nodes internally, all use caches.

> 	The fact that RFC 925 describes using a cache or ARP=20
> entries as a basis for what RFC 1009 subsequently defines as
> ARP caching (or "the ARP hack"), in no way implies that this=20

proxy ARP in 1009.

> is what anyone would generally refer to as ARP caching.  In
> fact, one use for the cache defined in RFC 925 is the MAC DA
> "translation" that occurs in traversing an Internet Gateway
> (router).

Except that the rules for ARP caching are the same for all ARP caches -
regarding cache refresh, timeout, etc. That's why it's useful and
important to consider them equivalent.

> 	While it is clearly too late to change the prior usage,
> the function described in RFC 1009 would be better termed an
> "ARP Translation" than an "ARP Proxy".

That would require our redefining that term, as well as corresponding
proxy terms in other widespread use - notably web proxy. Proxying in
these cases, as well as in general English, refers to one party
_representing_ another, not trying to fake being another.

> 	I think many of us are convinced that "ARP Proxy" can't
> be used because of earlier (historical) reasons (whether we
> regard those as in error or not).  I do not think the term
> "ARP Replay" is sufficiently descriptive and I believe that
> the suggestion is made pejoratively - in what certainly looks
> like an attempt to prejudice the working group against any
> such discussion.

This _is_ a replay, with all the good AND bad associations. It's useful
to consider those issues, e.g., that replay won't work if proper
anti-replay measures are implemented.

> 	Therefore, I again suggest using the term ARP Caching.
>=20
> 	I don't really care that hosts do it.  I don't care that
> Disk Drive controllers do it.  I don't care that Web sites do
> it.  I just want us to settle on a term that is consistent with
> what is described and is not chosen to add unwanted freight.

It's not consistent with the well-established use of the term in IETF
Standards documents, which means (IMO) that's not a viable option.

Joe

>=20
> --
> Eric
>=20
> --- [SNIP] ---
>=20
> --> Gray, Eric wrote:
> --> > Radia/Joe,
> --> >=20
> --> > 	We can call it ARP caching (which would make some sense
> --> > - possibly more than ARP replay),=20
> -->=20
> --> ARP caching is what hosts and proxy ARP-ing routers already do (ala=

> --> RFC1122). See TCP/IP Illustrated, Vol 1, section 4.3.
> -->=20
>=20
> --- [SNIP] ---
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


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

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

iD8DBQFDpt4yE5f5cImnZrsRAs7jAKCzATZec5FSBFBxl41qpIAR6lkiJQCfaH0k
g3dpu4dl3ayuqgboh1VztnU=
=bZLH
-----END PGP SIGNATURE-----

--------------enig20A0E5FD7094A046609B427A--


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 jBJFw7w20104 for <[e-mail]>; Mon, 19 Dec 2005 07:58:07 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBJFw1dJ017537 for <[e-mail]>; Mon, 19 Dec 2005 10:58:01 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24949 for <[e-mail]>; Mon, 19 Dec 2005 10:58:01 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <ZF3JM42W>; Mon, 19 Dec 2005 10:58:00 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Mon, 19 Dec 2005 10:58:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2005 15:58:24 -0000
Status: RO
Content-Length: 1902

Joe,

	Are you sure that you're not deliberately trying to make
things more difficult to understand?

	Caching - in general - is well understood.  The form of
storing ARP entries in passing - in order to reduce ARP traffic
across the RBridge campus - that I have seen described on this
list so far, is directly analogous to any number of different
"Caching" uses.

	The fact that RFC 925 describes using a cache or ARP 
entries as a basis for what RFC 1009 subsequently defines as
ARP caching (or "the ARP hack"), in no way implies that this 
is what anyone would generally refer to as ARP caching.  In
fact, one use for the cache defined in RFC 925 is the MAC DA
"translation" that occurs in traversing an Internet Gateway
(router).

	While it is clearly too late to change the prior usage,
the function described in RFC 1009 would be better termed an
"ARP Translation" than an "ARP Proxy".

	I think many of us are convinced that "ARP Proxy" can't
be used because of earlier (historical) reasons (whether we
regard those as in error or not).  I do not think the term
"ARP Replay" is sufficiently descriptive and I believe that
the suggestion is made pejoratively - in what certainly looks
like an attempt to prejudice the working group against any
such discussion.

	Therefore, I again suggest using the term ARP Caching.

	I don't really care that hosts do it.  I don't care that
Disk Drive controllers do it.  I don't care that Web sites do
it.  I just want us to settle on a term that is consistent with
what is described and is not chosen to add unwanted freight.

--
Eric

--- [SNIP] ---

--> Gray, Eric wrote:
--> > Radia/Joe,
--> > 
--> > 	We can call it ARP caching (which would make some sense
--> > - possibly more than ARP replay), 
--> 
--> ARP caching is what hosts and proxy ARP-ing routers already do (ala
--> RFC1122). See TCP/IP Illustrated, Vol 1, section 4.3.
--> 

--- [SNIP] ---


Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBJCedw26503 for <[e-mail]>; Mon, 19 Dec 2005 04:40:39 -0800 (PST)
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E50DB2596F5 for <[e-mail]>; Mon, 19 Dec 2005 13:39:50 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10389-03 for <[e-mail]>; Mon, 19 Dec 2005 13:39:47 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 17B5C2596E9 for <[e-mail]>; Mon, 19 Dec 2005 13:39:45 +0100 (CET)
Date: Mon, 19 Dec 2005 08:04:22 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-ID: <084781DB97DD47ED5946EFCD@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <[e-mail] .marconi.com>	<[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========D8717B1B2162D90267BF=========="
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Network size (Re:  it's time to summarize things)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2005 12:41:24 -0000
Status: RO
Content-Length: 2031

--==========D8717B1B2162D90267BF==========
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I think I stick to my original proposal:

the protocol MUST function effectively in deployments of:

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

My reasoning is that if we find that a proposal is effective only at=20
smaller sizes than this, we should reject the proposal outright, and not=20
waste time on discussion.

Having size limits like "at least as great as can be accomplished..." can=20
easily lead to us re-fighting the issue of "how big can the networks be=20
using protocol X" when evaluation time comes around.

There's nothing magic about these numbers. But they're easy to measure.

--On 16. desember 2005 12:21 +0100 Guillermo Ib=C3=A1=C3=B1ez =
<[e-mail]>=20
wrote:

> Just to elaborate on the ambiguity of saying
>
> "MUST work for LANs of a size
> at least as great as can be accomplished using 802.1 bridges."
>
> Using Multiple Spanning Tree Protocol (802.1Q) with a lot of MSTP
> regions, very big networks can be built, although quite complex to
> configure and manage.
> Using RSTP with point to point links, my understanding is that it seems
> there is no real limit to  network size, although % of network
> utilization will be very low and root bridge will become congested. If
> there are shared links in the network, (situation like STP)  then the
> port state transitions to forwarding are governed by timers,  with  max
> values  of 30 seconds. Network size is then limited, as in STP.




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

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

iD8DBQFDplt2OMj+2+WY0F4RAmzBAKD0siR+Y6EO6x17hEQZmVNfIibouQCg+mlq
IuzaNVnL53OGaGPLTpxKGjo=
=zHzx
-----END PGP SIGNATURE-----

--==========D8717B1B2162D90267BF==========--



Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBJC17w17039 for <[e-mail]>; Mon, 19 Dec 2005 04:01:07 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.224.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id jBJC17dK025423 for <[e-mail]>; Mon, 19 Dec 2005 04:01:07 -0800 (PST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jBJC14en832806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 19 Dec 2005 04:01:06 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 19 Dec 2005 04:01:03 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS Issue #11 -> now ARCH issue #6
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2005 12:01:36 -0000
Status: RO
Content-Length: 1679

Joe Touch wrote:

> Internal/external as used in the PS doc is specific to protocols
> 'inside' the solution. It is not used the same way in the arch document
> (internal/external interfaces).
> 
> That difference needs to be made more clear.


Or maybe not. Having two different definitions of internal and external 
in different documents doesn't improve comprehension.

Do we even need any such terms? If not, then we can get rid of any 
confusion by just deleting the terms. Where are the terms actually used 
and useful?

A rbridge device will be capable of interaction with end nodes (station) 
on any interface, by sending and receiving non-encapsulated frames. And 
in general it must assume that an end node can exist on any of its 
interfaces, since there can be hubs.
A rbridge device will also be capable of interaction with other rbridges 
on any interface, as part of some rbridge discovery/hello mechanism as 
well as sending and receiving encapsulate frames.

Also, the rbridges in a campus create an overlay topology through their 
operation.

But I'm pretty sure we can describe all this without needing any 
"internal" or "external" terms.


Later you wrote:
> The issue isn't that the meaning is hard to understand; the issue is
> that the term is inaccurate. Hosts can - and will - sit on that
> interface. I was trying to reserve internal/external for a distinction
> between traffic between rbridges and traffic from ingress/egress to
> hosts - where inside/outside meant 'inside the campus' (invisible to
> hosts) and 'outside to the hosts' (visible to hosts).

This is the distinction between encapsulated and non-encapsulated 
frames, right?


    Erik


Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBIJnrw00972 for <[e-mail]>; Sun, 18 Dec 2005 11:49:53 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B2DDF9E493; Sun, 18 Dec 2005 20:49:47 +0100 (CET)
Received: from [163.117.203.254] (unknown [163.117.203.254]) by smtp01.uc3m.es (Postfix) with ESMTP id 5829E9E3C6; Sun, 18 Dec 2005 20:49:46 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sun, 18 Dec 2005 20:49:46 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Saikat Ray <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 18 Dec 2005 19:50:14 -0000
Status: RO
Content-Length: 8157

I was not aware of this mail. I am glad to know you see it in the same 
way.  I see it more than an optimization, a way  to make consistent 
operation, although very loosely coupled, between RSTP and  RBridges IS-IS.
Guillermo

Saikat Ray wrote:

>This was also discussed :) I raised precisely the same issues. Please see
>
>http://www.postel.org/pipermail/rbridge/2005-October/000687.html
>
>Radia had sent a reply, which I couldn't find in the list. Anyway, it is
>sufficient that RBridges see the BPDU's to stop packet forwarding when a
>legacy spanning tree starts to change, they do not need to be a part of
>the spanning tree for this purpose. But I agree that merging the spanning
>tree root bridge selection process with DR selection seems to be a nice
>idea.
>
>On Sat, 17 Dec 2005, [ISO-8859-1] Guillermo Ib??ez wrote:
>
>  
>
>>Saikat, see below
>>Guillermo
>>
>>
>>Saikat Ray wrote:
>>
>>    
>>
>>>>Saikat Ray wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>The simplest, if not the most rigorous, explanation is as follows. Replace
>>>>>each legacy part of the network by a hub (i.e., first remove all RBridges
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>from the topology. Then choose a legacy bridge and replace this bridge and
>>>>
>>>>
>>>>        
>>>>
>>>>>all legacy bridges that have a path to it by a single hub, and let all
>>>>>end-hosts served by those legacy bridges be connected to this hub. Repeat
>>>>>this procedure until all legacy bridges are replaced. Then finally put the
>>>>>RBridges back.). Now, one and only one RBridge forwards and receives
>>>>>unencapsulated packets from each hub (through designated RBridge).
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>But what happens when two separate hubs with separate RBridges
>>>>forwarding each one traffic are connected
>>>>by a link restoration between them?. A single "hub" will be created with
>>>>two Designated RBridges till the
>>>>detect the situation. How (and how fast), the DR election mechanims
>>>>should work in this situation?
>>>>Guillermo
>>>>
>>>>
>>>>        
>>>>
>>>This was discussed long before. The frequency of RBridge hello messages
>>>will determine the length of transience (once a hello is sent, the
>>>presence of two RBridges on the same "hub" will be detected). Radia had
>>>some comments about the numerical value of the frequency, which I do not
>>>remember; it is in one of the emails on the list :)
>>>
>>>
>>>
>>>      
>>>
>>Well, it seems then that we can have loops for all that time.  If
>>subsecond intervals are needed, Hello Time must be
>>lower than 1 second. I find this mechanism more costly than using RSTP,
>>(already used by the bridges in the hub) to detect the double DR
>>situation.  By using the Root bridge election mechanism of
>>RSTP (via colocated bridge), the process uses the standard RSTP BPDUs
>>and selects in a reliable form a unique Root bridge and DR, assuming the
>>default bridge priority of bridges for election is worse than the
>>default priority of Rbridges (this can be defined at will).  Although it
>>means a small dependency on the 802.1D standard, it seems more advisable
>>to rely in a standard mechanism to act in a consistent way than
>>duplicate the mechanism and ignore RSTP protocol to obtain full
>>independency.
>>Rbridges ignoring fully RSTP BPDUs means all that means for knowing
>>"link" and tree status are dropped, the risk for malfunction is
>>increased as  long as Rbridges ignore BPDU information as useless.
>>One difference is that if DR Hello messages are not received, or
>>messages from new bridges appear, Rbridges might use received RSTP BPDU
>>information to confirm the cause and motivation of messages, so
>>decisions more consistent with RSTP can be taken.
>>Perhaps the main argument is that Root bridge election stops inmediatly
>>the frame forwarding in link (hub) blocking the loop, while via DR, the
>>stopping is done by Rbridges election. That is not the case if spanning
>>tree remains active while two DRs coexist on the link reinjecting the
>>traffic in the link through the Rbridge campus. The process requires
>>full communication between Rbridges through the link while there is a
>>loop on it.  Root bridge election does not.
>>Guillermo
>>
>>    
>>
>>>>Thus for
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>a loop formation, a packet must loop back to a designated RBridge, which is
>>>>>not possible since RBridges use their own spanning tree for sending
>>>>>(encapsulated) broadcast traffic.
>>>>>
>>>>>Hope this helps.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [e-mail] [mailto:[e-mail]] On
>>>>>>Behalf Of Tim Shepard
>>>>>>Sent: Thursday, December 15, 2005 6:42 PM
>>>>>>To: Developing a hybrid router/bridge.
>>>>>>Cc: [e-mail]; 'Joe Touch'
>>>>>>Subject: Re: [rbridge] it's time to summarize things
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>Let us suppose that an RBridge is connected to a legacy bridge's port
>>>>>>>directly, and all RBridges block BPDUs. Then the RBridge looks like,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>from
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>the perspective of the legacy brige, either (i) a single end-host (with
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>MAC address that of the RBridge) if the RBridge is not the designated
>>>>>>>RBridge, or (ii) a shared media (like a hub; is the standard term
>>>>>>>"segment"?) with potentially a lot of MAC addresses attached to it (in
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>fact,
>>>>>>[....]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>So what exactly do you think is the problem with ARP?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>I'm not sure I follow all of the postings on this issue.
>>>>>>
>>>>>>But after reading through this thread, I'm still left wondering what
>>>>>>is supposed to make sure packets don't loop forever when there are a
>>>>>>mix of bridges and rbridges plugged together (in some crazy accidental
>>>>>>way, creating whatever kind of loop involving bridges and rbridges
>>>>>>that causes the most trouble).
>>>>>>
>>>>>>It seems to me that if rbridges block the spanning tree forming
>>>>>>packets, but do forward (e.g.) ARP traffic, then there could be loops
>>>>>>that are not broken by either the rbridge system or the usual bridge
>>>>>>spanning-tree-forming algorithm.
>>>>>>
>>>>>>Could someone explain succinctly (for someone who is just barely
>>>>>>following this thread) how a system (of mixed bridges and rbridges,
>>>>>>plugged together by some Byzantine net admin) will ensure that packets
>>>>>>are not forwarded in a loop?
>>>>>>
>>>>>>(And ARP is a good example, since it is supposed to go everywhere, but
>>>>>>not loop.)
>>>>>>
>>>>>>
>>>>>>Or will there be configuration rules that forbid some ways of plugging
>>>>>>together bridges and rbridges?
>>>>>>
>>>>>>			-Tim Shepard
>>>>>>			 [e-mail]
>>>>>>_______________________________________________
>>>>>>rbridge mailing list
>>>>>>[e-mail]
>>>>>>http://www.postel.org/mailman/listinfo/rbridge
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>_______________________________________________
>>>>>rbridge mailing list
>>>>>[e-mail]
>>>>>http://www.postel.org/mailman/listinfo/rbridge
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>--
>>>>Guillermo Ib??ez
>>>>Departamento de Ingenier?a Telem?tica
>>>>Universidad Carlos III de Madrid
>>>>1.1.B.11 Colmenarejo 91-6241393
>>>>4.1.F.13 Legan?s 91-6248794
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>>--
>>Guillermo Ib??ez
>>Departamento de Ingenier?a Telem?tica
>>Universidad Carlos III de Madrid
>>1.1.B.11 Colmenarejo 91-6241393
>>4.1.F.13 Legan?s 91-6248794
>>
>>
>>    
>>
>
>  
>

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



Received: from psychopathy.seas.upenn.edu (psychopathy.SEAS.upenn.edu [158.130.65.164]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBHFrRe04950 for <[e-mail]>; Sat, 17 Dec 2005 07:53:27 -0800 (PST)
Received: from red.seas.upenn.edu (RED.seas.upenn.edu [158.130.64.176]) by psychopathy.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id jBHFrKdo017337; Sat, 17 Dec 2005 10:53:20 -0500
Received: from red.seas.upenn.edu (localhost [127.0.0.1]) by red.seas.upenn.edu (8.12.10/8.12.9) with ESMTP id jBHFrF7i014343; Sat, 17 Dec 2005 10:53:20 -0500 (EST)
Received: from localhost (saikat@localhost) by red.seas.upenn.edu (8.12.10/8.12.9/Submit) with ESMTP id jBHFr9v8014340; Sat, 17 Dec 2005 10:53:10 -0500 (EST)
Date: Sat, 17 Dec 2005 10:53:09 -0500 (EST)
From: Saikat Ray <[e-mail]>
To: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
X-Spam-Status: -2.82 ALL_TRUSTED
X-Scanned-By: MIMEDefang 2.49 on 158.130.65.164
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 jBHFrRe04950
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 17 Dec 2005 15:54:11 -0000
Status: RO
Content-Length: 7254

This was also discussed :) I raised precisely the same issues. Please see

http://www.postel.org/pipermail/rbridge/2005-October/000687.html

Radia had sent a reply, which I couldn't find in the list. Anyway, it is
sufficient that RBridges see the BPDU's to stop packet forwarding when a
legacy spanning tree starts to change, they do not need to be a part of
the spanning tree for this purpose. But I agree that merging the spanning
tree root bridge selection process with DR selection seems to be a nice
idea.

On Sat, 17 Dec 2005, [ISO-8859-1] Guillermo Ib??ez wrote:

>
> Saikat, see below
> Guillermo
>
>
> Saikat Ray wrote:
>
> >>Saikat Ray wrote:
> >>
> >>
> >>
> >>>The simplest, if not the most rigorous, explanation is as follows. Replace
> >>>each legacy part of the network by a hub (i.e., first remove all RBridges
> >>>
> >>>
> >>>from the topology. Then choose a legacy bridge and replace this bridge and
> >>
> >>
> >>>all legacy bridges that have a path to it by a single hub, and let all
> >>>end-hosts served by those legacy bridges be connected to this hub. Repeat
> >>>this procedure until all legacy bridges are replaced. Then finally put the
> >>>RBridges back.). Now, one and only one RBridge forwards and receives
> >>>unencapsulated packets from each hub (through designated RBridge).
> >>>
> >>>
> >>>
> >>But what happens when two separate hubs with separate RBridges
> >>forwarding each one traffic are connected
> >>by a link restoration between them?. A single "hub" will be created with
> >>two Designated RBridges till the
> >>detect the situation. How (and how fast), the DR election mechanims
> >>should work in this situation?
> >>Guillermo
> >>
> >>
> >
> >This was discussed long before. The frequency of RBridge hello messages
> >will determine the length of transience (once a hello is sent, the
> >presence of two RBridges on the same "hub" will be detected). Radia had
> >some comments about the numerical value of the frequency, which I do not
> >remember; it is in one of the emails on the list :)
> >
> >
> >
> Well, it seems then that we can have loops for all that time.  If
> subsecond intervals are needed, Hello Time must be
> lower than 1 second. I find this mechanism more costly than using RSTP,
> (already used by the bridges in the hub) to detect the double DR
> situation.  By using the Root bridge election mechanism of
> RSTP (via colocated bridge), the process uses the standard RSTP BPDUs
> and selects in a reliable form a unique Root bridge and DR, assuming the
> default bridge priority of bridges for election is worse than the
> default priority of Rbridges (this can be defined at will).  Although it
> means a small dependency on the 802.1D standard, it seems more advisable
> to rely in a standard mechanism to act in a consistent way than
> duplicate the mechanism and ignore RSTP protocol to obtain full
> independency.
> Rbridges ignoring fully RSTP BPDUs means all that means for knowing
> "link" and tree status are dropped, the risk for malfunction is
> increased as  long as Rbridges ignore BPDU information as useless.
> One difference is that if DR Hello messages are not received, or
> messages from new bridges appear, Rbridges might use received RSTP BPDU
> information to confirm the cause and motivation of messages, so
> decisions more consistent with RSTP can be taken.
> Perhaps the main argument is that Root bridge election stops inmediatly
> the frame forwarding in link (hub) blocking the loop, while via DR, the
> stopping is done by Rbridges election. That is not the case if spanning
> tree remains active while two DRs coexist on the link reinjecting the
> traffic in the link through the Rbridge campus. The process requires
> full communication between Rbridges through the link while there is a
> loop on it.  Root bridge election does not.
> Guillermo
>
> >> Thus for
> >>
> >>
> >>
> >>>a loop formation, a packet must loop back to a designated RBridge, which is
> >>>not possible since RBridges use their own spanning tree for sending
> >>>(encapsulated) broadcast traffic.
> >>>
> >>>Hope this helps.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: [e-mail] [mailto:[e-mail]] On
> >>>>Behalf Of Tim Shepard
> >>>>Sent: Thursday, December 15, 2005 6:42 PM
> >>>>To: Developing a hybrid router/bridge.
> >>>>Cc: [e-mail]; 'Joe Touch'
> >>>>Subject: Re: [rbridge] it's time to summarize things
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Let us suppose that an RBridge is connected to a legacy bridge's port
> >>>>>directly, and all RBridges block BPDUs. Then the RBridge looks like,
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>from
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>the perspective of the legacy brige, either (i) a single end-host (with
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>the
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>MAC address that of the RBridge) if the RBridge is not the designated
> >>>>>RBridge, or (ii) a shared media (like a hub; is the standard term
> >>>>>"segment"?) with potentially a lot of MAC addresses attached to it (in
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>fact,
> >>>>[....]
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>So what exactly do you think is the problem with ARP?
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>I'm not sure I follow all of the postings on this issue.
> >>>>
> >>>>But after reading through this thread, I'm still left wondering what
> >>>>is supposed to make sure packets don't loop forever when there are a
> >>>>mix of bridges and rbridges plugged together (in some crazy accidental
> >>>>way, creating whatever kind of loop involving bridges and rbridges
> >>>>that causes the most trouble).
> >>>>
> >>>>It seems to me that if rbridges block the spanning tree forming
> >>>>packets, but do forward (e.g.) ARP traffic, then there could be loops
> >>>>that are not broken by either the rbridge system or the usual bridge
> >>>>spanning-tree-forming algorithm.
> >>>>
> >>>>Could someone explain succinctly (for someone who is just barely
> >>>>following this thread) how a system (of mixed bridges and rbridges,
> >>>>plugged together by some Byzantine net admin) will ensure that packets
> >>>>are not forwarded in a loop?
> >>>>
> >>>>(And ARP is a good example, since it is supposed to go everywhere, but
> >>>>not loop.)
> >>>>
> >>>>
> >>>>Or will there be configuration rules that forbid some ways of plugging
> >>>>together bridges and rbridges?
> >>>>
> >>>>			-Tim Shepard
> >>>>			 [e-mail]
> >>>>_______________________________________________
> >>>>rbridge mailing list
> >>>>[e-mail]
> >>>>http://www.postel.org/mailman/listinfo/rbridge
> >>>>
> >>>>
> >>>>
> >>>>
> >>>_______________________________________________
> >>>rbridge mailing list
> >>>[e-mail]
> >>>http://www.postel.org/mailman/listinfo/rbridge
> >>>
> >>>
> >>>
> >>>
> >>>
> >>--
> >>Guillermo Ib??ez
> >>Departamento de Ingenier?a Telem?tica
> >>Universidad Carlos III de Madrid
> >>1.1.B.11 Colmenarejo 91-6241393
> >>4.1.F.13 Legan?s 91-6248794
> >>
> >>
> >>
> >
> >
> >
>
> --
> Guillermo Ib??ez
> Departamento de Ingenier?a Telem?tica
> Universidad Carlos III de Madrid
> 1.1.B.11 Colmenarejo 91-6241393
> 4.1.F.13 Legan?s 91-6248794
>
>


Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [216.148.227.154]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBHECCe13709 for <[e-mail]>; Sat, 17 Dec 2005 06:12:12 -0800 (PST)
Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165]) by comcast.net (rwcrmhc14) with SMTP id <20051217141205014008kvqqe>; Sat, 17 Dec 2005 14:12:05 +0000
Message-ID: <027301c60313$bfa60bb0$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
Date: Sat, 17 Dec 2005 08:11:17 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 17 Dec 2005 14:13:08 -0000
Status: RO
Content-Length: 1392

Without discussing whether it's a good idea or not, the "decisions more 
consistent with RSTP" function seems more like a performance optimization 
that isn't required for correct operation. Could this be something we don't 
define, but vendors making real Rbridges just decide to do? Like sniffing 
multicast control packets?

Spencer

p.s. Before we generate a whole lot more text - is there a canonical 
capitialization of RBRIDGE? I'm seeing all-caps, initial caps, and no caps 
in my own e-mail (which is usually matching the capitalization in e-mail I'm 
replying to), and it would be nice if (for example) all the TRILL documents 
used the same convention...

----- Original Message ----- 
From: "Guillermo Ib??ez" <[e-mail]>
To: "Saikat Ray" <[e-mail]>; "Developing a hybrid 
router/bridge." <[e-mail]>
Sent: Saturday, December 17, 2005 3:09 AM
Subject: Re: [rbridge] it's time to summarize things

Rbridges ignoring fully RSTP BPDUs means all that means for knowing
"link" and tree status are dropped, the risk for malfunction is
increased as  long as Rbridges ignore BPDU information as useless.
One difference is that if DR Hello messages are not received, or
messages from new bridges appear, Rbridges might use received RSTP BPDU
information to confirm the cause and motivation of messages, so
decisions more consistent with RSTP can be taken. 



Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBH9A5e15523 for <[e-mail]>; Sat, 17 Dec 2005 01:10:05 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B127F84C31; Sat, 17 Dec 2005 10:09:58 +0100 (CET)
Received: from [163.117.203.229] (unknown [163.117.203.229]) by smtp02.uc3m.es (Postfix) with ESMTP id 6170A84B99; Sat, 17 Dec 2005 10:09:57 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 17 Dec 2005 10:09:54 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Saikat Ray <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 17 Dec 2005 09:11:10 -0000
Status: RO
Content-Length: 6412

Saikat, see below
Guillermo


Saikat Ray wrote:

>>Saikat Ray wrote:
>>
>>    
>>
>>>The simplest, if not the most rigorous, explanation is as follows. Replace
>>>each legacy part of the network by a hub (i.e., first remove all RBridges
>>>      
>>>
>>>from the topology. Then choose a legacy bridge and replace this bridge and
>>    
>>
>>>all legacy bridges that have a path to it by a single hub, and let all
>>>end-hosts served by those legacy bridges be connected to this hub. Repeat
>>>this procedure until all legacy bridges are replaced. Then finally put the
>>>RBridges back.). Now, one and only one RBridge forwards and receives
>>>unencapsulated packets from each hub (through designated RBridge).
>>>
>>>      
>>>
>>But what happens when two separate hubs with separate RBridges
>>forwarding each one traffic are connected
>>by a link restoration between them?. A single "hub" will be created with
>>two Designated RBridges till the
>>detect the situation. How (and how fast), the DR election mechanims
>>should work in this situation?
>>Guillermo
>>    
>>
>
>This was discussed long before. The frequency of RBridge hello messages
>will determine the length of transience (once a hello is sent, the
>presence of two RBridges on the same "hub" will be detected). Radia had
>some comments about the numerical value of the frequency, which I do not
>remember; it is in one of the emails on the list :)
>
>  
>
Well, it seems then that we can have loops for all that time.  If
subsecond intervals are needed, Hello Time must be
lower than 1 second. I find this mechanism more costly than using RSTP,
(already used by the bridges in the hub) to detect the double DR
situation.  By using the Root bridge election mechanism of
RSTP (via colocated bridge), the process uses the standard RSTP BPDUs
and selects in a reliable form a unique Root bridge and DR, assuming the
default bridge priority of bridges for election is worse than the
default priority of Rbridges (this can be defined at will).  Although it
means a small dependency on the 802.1D standard, it seems more advisable
to rely in a standard mechanism to act in a consistent way than
duplicate the mechanism and ignore RSTP protocol to obtain full
independency.
Rbridges ignoring fully RSTP BPDUs means all that means for knowing
"link" and tree status are dropped, the risk for malfunction is
increased as  long as Rbridges ignore BPDU information as useless.
One difference is that if DR Hello messages are not received, or
messages from new bridges appear, Rbridges might use received RSTP BPDU
information to confirm the cause and motivation of messages, so
decisions more consistent with RSTP can be taken.
Perhaps the main argument is that Root bridge election stops inmediatly
the frame forwarding in link (hub) blocking the loop, while via DR, the
stopping is done by Rbridges election. That is not the case if spanning
tree remains active while two DRs coexist on the link reinjecting the
traffic in the link through the Rbridge campus. The process requires
full communication between Rbridges through the link while there is a
loop on it.  Root bridge election does not.
Guillermo

>> Thus for
>>
>>    
>>
>>>a loop formation, a packet must loop back to a designated RBridge, which is
>>>not possible since RBridges use their own spanning tree for sending
>>>(encapsulated) broadcast traffic.
>>>
>>>Hope this helps.
>>>
>>>
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: [e-mail] [mailto:[e-mail]] On
>>>>Behalf Of Tim Shepard
>>>>Sent: Thursday, December 15, 2005 6:42 PM
>>>>To: Developing a hybrid router/bridge.
>>>>Cc: [e-mail]; 'Joe Touch'
>>>>Subject: Re: [rbridge] it's time to summarize things
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Let us suppose that an RBridge is connected to a legacy bridge's port
>>>>>directly, and all RBridges block BPDUs. Then the RBridge looks like,
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>from
>>>>
>>>>
>>>>        
>>>>
>>>>>the perspective of the legacy brige, either (i) a single end-host (with
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>the
>>>>
>>>>
>>>>        
>>>>
>>>>>MAC address that of the RBridge) if the RBridge is not the designated
>>>>>RBridge, or (ii) a shared media (like a hub; is the standard term
>>>>>"segment"?) with potentially a lot of MAC addresses attached to it (in
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>fact,
>>>>[....]
>>>>
>>>>
>>>>        
>>>>
>>>>>So what exactly do you think is the problem with ARP?
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>I'm not sure I follow all of the postings on this issue.
>>>>
>>>>But after reading through this thread, I'm still left wondering what
>>>>is supposed to make sure packets don't loop forever when there are a
>>>>mix of bridges and rbridges plugged together (in some crazy accidental
>>>>way, creating whatever kind of loop involving bridges and rbridges
>>>>that causes the most trouble).
>>>>
>>>>It seems to me that if rbridges block the spanning tree forming
>>>>packets, but do forward (e.g.) ARP traffic, then there could be loops
>>>>that are not broken by either the rbridge system or the usual bridge
>>>>spanning-tree-forming algorithm.
>>>>
>>>>Could someone explain succinctly (for someone who is just barely
>>>>following this thread) how a system (of mixed bridges and rbridges,
>>>>plugged together by some Byzantine net admin) will ensure that packets
>>>>are not forwarded in a loop?
>>>>
>>>>(And ARP is a good example, since it is supposed to go everywhere, but
>>>>not loop.)
>>>>
>>>>
>>>>Or will there be configuration rules that forbid some ways of plugging
>>>>together bridges and rbridges?
>>>>
>>>>			-Tim Shepard
>>>>			 [e-mail]
>>>>_______________________________________________
>>>>rbridge mailing list
>>>>[e-mail]
>>>>http://www.postel.org/mailman/listinfo/rbridge
>>>>
>>>>
>>>>        
>>>>
>>>_______________________________________________
>>>rbridge mailing list
>>>[e-mail]
>>>http://www.postel.org/mailman/listinfo/rbridge
>>>
>>>
>>>
>>>      
>>>
>>--
>>Guillermo Ib??ez
>>Departamento de Ingenier?a Telem?tica
>>Universidad Carlos III de Madrid
>>1.1.B.11 Colmenarejo 91-6241393
>>4.1.F.13 Legan?s 91-6248794
>>
>>    
>>
>
>  
>

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




Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBH91Ye14176 for <[e-mail]>; Sat, 17 Dec 2005 01:01:34 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E2FDA847BC; Sat, 17 Dec 2005 10:01:27 +0100 (CET)
Received: from [163.117.203.229] (unknown [163.117.203.229]) by smtp02.uc3m.es (Postfix) with ESMTP id 4B33683665; Sat, 17 Dec 2005 10:01:26 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 17 Dec 2005 10:01:26 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "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: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 17 Dec 2005 09:02:04 -0000
Status: RO
Content-Length: 1118

I agree.
Guillermo

Gray, Eric wrote:

>Guillermo,
>
>	I think it might be slightly more correct to say that ARP 
><whatever> using some (yet to be defined) approach is considered 
>an acceptable optimization.  It is also correct to say that - in
>cases where a designated RBridge is (s)elected this would be the
>reasonable place to do ARP <whatever>.
>
>	Consequently, it follows that ARP <whatever> should be an
>acceptable optimization for at least the designated RBridge.
>
>	Just connecting the dots...
>
>--
>Eric
>
>--> -----Original Message-----
>--> From: [e-mail] 
>--> [mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
>--> Sent: Friday, December 16, 2005 10:17 AM
>--> To: Developing a hybrid router/bridge.
>--> Subject: Re: [rbridge] it's time to summarize things
>--> 
>--> ARP Proxying by the Designated Rbridge was considered an acceptable 
>--> optimization,  right?
>--> GI
>--> Joe Touch wrote:
>--> 
>
>  
>

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



Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBH8t1e12831 for <[e-mail]>; Sat, 17 Dec 2005 00:55:01 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1697E84C61 for <[e-mail]>; Sat, 17 Dec 2005 09:54:55 +0100 (CET)
Received: from [163.117.203.229] (unknown [163.117.203.229]) by smtp02.uc3m.es (Postfix) with ESMTP id 06CF384C7A for <[e-mail]>; Sat, 17 Dec 2005 09:54:54 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 17 Dec 2005 09:54:51 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 17 Dec 2005 08:56:06 -0000
Status: RO
Content-Length: 4336

Joe,

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Radia Perlman wrote:
>  
>
>>I'm changing the subject line to make it easier, as least for me, to
>>find mail on specific issues.
>>
>>I remember writing up alternatives for ARP/ND proxying and
>>sending the choices and pros and cons to the list, and I'm not sure there
>>was ever strong opinions voiced on any of them.
>>However, I am quite sure the WG did not rule
>>out ARP proxying.
>>
>>I prefer ARP proxying, rather than treating ARP like any other L2 traffic.
>>We could make things a bit fancier, for instance,
>>a) further cutting down on
>>traffic by having an RBridge suppress an ARP request to a particular 
>>target if
>>it knows that another one has occurred recently (either because it
>>iniated it as ingress RBridge or because it forwarded the encapsulated ARP
>>query)
>>b) getting rid of stale ARP caches faster by sometimes (we'd have to decide
>>under what circumstances) sending the ARP query directly to the
>>assumed target's link, and making the target respond.
>>
>>Joe...you seem to be definitively stating that the WG has ruled out 
>>ARP/ND proxy.
>>    
>>
>
>We need to be clear about the difference between ARP Proxy and ARP
>Replay. Replay is closer to what we have always been talking about. We
>never talked about proxying.
>
>For proxying to work:
>
>	1- a designated rbridge would intercept an ARP
> 	and reply with its own MAC address
>  
>
This seems to be right for the term "proxying"

>2- the rbridge would need to know to which egress to forward
>	the packet
>

>3- the egress would need to know the MAC on the destination LAN
>  
>
>steps 2 and 3 involve a new set of state in the rbridge campus that we
>haven't talked about.
>
>  
>
To provide some ideas on 2 and 3  you mention, in the Abridges draft  
recently submitted, determination
of destination host MAC address (ARP  resolution) and destination 
Rbridge (Abridge) are performed
simultaneously by the ARP/AB server (they were registered together by 
the host Agent Bridge).

>My impression is thus that we've been talking about replay more than
>proxy. Correct me (anyone) if that's not accurate...
>
>  
>
I do not know if "replay" is the best suited term, but I agree that 
proxying is not accurate.

Guillermo

>Joe
>
>  
>
>>I may have missed some of the emails on the list (it's *really* hard
>>to keep up with the volume of traffic). Was this debated and concluded 
>>somehow?
>>Or were you just misremembering? Ruling proxy out is definitely a change 
>>from
>>the original intent, and changes such as this should not be done 
>>arbitrarily.
>>
>>Radia
>>
>>
>>
>>
>>Guillermo Ib??ez wrote:
>>
>>
>>    
>>
>>>ARP Proxying by the Designated Rbridge was considered an acceptable 
>>>optimization,  right?
>>>GI
>>>Joe Touch wrote:
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>Guillermo Ib??ez wrote:
>>>>
>>>>
>>>>  
>>>>
>>>>
>>>>        
>>>>
>>>>>>My understanding was that Rbridges would do ARP proxying and would 
>>>>>>forward ARP requests to other Rbridges. Am I still right?.
>>>>>>   
>>>>>>
>>>>>>      
>>>>>>
>>>>>>            
>>>>>>
>>>>Not proxying; they forward ARPs like all other L2 traffic. They don't
>>>>generate ARPs directed at their own L2 addresses in response to seeing
>>>>other ARPs (proxying).
>>>>
>>>>Joe
>>>>
>>>>
>>>>
>>>>------------------------------------------------------------------------
>>>>
>>>>_______________________________________________
>>>>rbridge mailing list
>>>>[e-mail]
>>>>http://www.postel.org/mailman/listinfo/rbridge
>>>>
>>>>
>>>>  
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>>    
>>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDoy3iE5f5cImnZrsRAt5qAKC9NMQuOkDFJuBg5uT8PQQBywFmhgCdEA2v
>IQMHjRlNxrTNAsFDK7jRkrc=
>=3qHZ
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

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



Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBH8gDe10616 for <[e-mail]>; Sat, 17 Dec 2005 00:42:14 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A1C4784CB8 for <[e-mail]>; Sat, 17 Dec 2005 09:42:07 +0100 (CET)
Received: from [163.117.203.229] (unknown [163.117.203.229]) by smtp02.uc3m.es (Postfix) with ESMTP id 73DF284C89 for <[e-mail]>; Sat, 17 Dec 2005 09:42:06 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 17 Dec 2005 09:42:06 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 17 Dec 2005 08:43:04 -0000
Status: RO
Content-Length: 3278

I agree fully with Radia.
In the recently submitted Abridges draft I propose the use of a kind ARP 
servers/registrars that splits the addresses to be resolved via hashing 
of IP address. Each server is responsible for caching the set of IP 
addresses that satisfies the same hash(IP) result (a hash length of a 
few bits may be sufficient to distribute the load among several 
servers). This requires a previous registering of the IP address-MAC 
address  that is performed by the Rbridge (Agent Bridge of host) upon 
detection of a  packet originated by  host "new" to the Abridge. This 
mechanism may also be used to reduce ARP based attacks by tightly 
controlling registration.
 Guillermo

Radia Perlman wrote:

>I'm changing the subject line to make it easier, as least for me, to
>find mail on specific issues.
>
>I remember writing up alternatives for ARP/ND proxying and
>sending the choices and pros and cons to the list, and I'm not sure there
>was ever strong opinions voiced on any of them.
>However, I am quite sure the WG did not rule
>out ARP proxying.
>
>I prefer ARP proxying, rather than treating ARP like any other L2 traffic.
>We could make things a bit fancier, for instance,
>a) further cutting down on
>traffic by having an RBridge suppress an ARP request to a particular 
>target if
>it knows that another one has occurred recently (either because it
>iniated it as ingress RBridge or because it forwarded the encapsulated ARP
>query)
>b) getting rid of stale ARP caches faster by sometimes (we'd have to decide
>under what circumstances) sending the ARP query directly to the
>assumed target's link, and making the target respond.
>
>Joe...you seem to be definitively stating that the WG has ruled out 
>ARP/ND proxy.
>I may have missed some of the emails on the list (it's *really* hard
>to keep up with the volume of traffic). Was this debated and concluded 
>somehow?
>Or were you just misremembering? Ruling proxy out is definitely a change 
>from
>the original intent, and changes such as this should not be done 
>arbitrarily.
>
>Radia
>
>
>
>
>Guillermo Ib??ez wrote:
>
>  
>
>>ARP Proxying by the Designated Rbridge was considered an acceptable 
>>optimization,  right?
>>GI
>>Joe Touch wrote:
>>
>> 
>>
>>    
>>
>>>Guillermo Ib??ez wrote:
>>>
>>>
>>>   
>>>
>>>      
>>>
>>>>>My understanding was that Rbridges would do ARP proxying and would 
>>>>>forward ARP requests to other Rbridges. Am I still right?.
>>>>>    
>>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>Not proxying; they forward ARPs like all other L2 traffic. They don't
>>>generate ARPs directed at their own L2 addresses in response to seeing
>>>other ARPs (proxying).
>>>
>>>Joe
>>>
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>rbridge mailing list
>>>[e-mail]
>>>http://www.postel.org/mailman/listinfo/rbridge
>>>
>>>
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

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



Received: from 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 jBH4TMe21771 for <[e-mail]>; Fri, 16 Dec 2005 20:29:22 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 16 Dec 2005 20:29:14 -0800 (PST)
Received: from sun.com ([129.150.24.253]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 16 Dec 2005 20:29:13 -0800 (PST)
Date: Fri, 16 Dec 2005 20:29:11 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 17 Dec 2005 04:30:04 -0000
Status: RO
Content-Length: 234

I believe the ARP/ND optimization does need to be in the draft, because the
solutions we've talked about need to be done by all RBridges.

Radia

Gray, Eric wrote:

>
>	Is this in the WG charter?  Should it be?
>
>--
>Eric
>
>
>  
>



Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBH0qde02389; Fri, 16 Dec 2005 16:52:39 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 16:52:41 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 17 Dec 2005 00:53:17 -0000
Status: RO
Content-Length: 3007

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



Gray, Eric wrote:
> Radia/Joe,
> 
> 	We can call it ARP caching (which would make some sense
> - possibly more than ARP replay), 

ARP caching is what hosts and proxy ARP-ing routers already do (ala
RFC1122).
See TCP/IP Illustrated, Vol 1, section 4.3.

> ARP replay or ARP Proxy.  I
> am not sure where Joe's definition of "proxy" comes from, but
> - if we assume that definition, then ARP proxy is not what we
> have talked about at all.

FWIW, proxy ARP is in RFC1009, as referred to by RFC1122.
See TCP/IP Illustrated, Vol 1, section 4.6, which describes it in detail
as I have, and equates it to "promiscuous ARP" and the "ARP hack".

> 	However, ARP proxy/caching/replay/<whatever> is really
> an optimization - similar to the multicast optimizations of
> Sue's draft.  I am reasonably sure that it does not need to
> be part of the base-line RBridge specification in order to be
> of use (again, much like the multicast optimization).
> 
> 	Is this in the WG charter?  Should it be?

Optimizations don't need to be in the charter, IMO.

Joe

> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [e-mail] 
> --> [mailto:[e-mail]] On Behalf Of Radia Perlman
> --> Sent: Friday, December 16, 2005 4:37 PM
> --> To: Developing a hybrid router/bridge.
> --> Subject: Re: [rbridge] ARP proxying
> --> 
> --> Yes Joe, you are right. This was a confusion over the word. 
> --> I have used
> --> "ARP proxy" to mean someone replies to the request, whether 
> --> it be with
> --> the target's actual MAC address, or with one's own MAC 
> --> address. So with
> --> your definition ("proxy" means you reply with your own MAC 
> --> address), 
> --> then you
> --> are right...we do not want RBridges to do ARP proxy. But we
> --> do want them to do ARP replay.
> --> 
> --> I suspect I'm not the only one who uses "ARP proxy" in the 
> --> more general way,
> --> so we have to be careful not to confuse people when we say 
> --> RBridges will
> --> not do it.
> --> 
> --> But whatever we call things, I'm glad we aren't disagreeing 
> --> about how 
> --> the thing
> --> works functionally.
> --> 
> --> Radia
> --> 
> --> 
> --> 
> --> Joe Touch wrote:
> --> 
> --> >_______________________________________________
> --> >rbridge mailing list
> --> >[e-mail]
> --> >http://www.postel.org/mailman/listinfo/rbridge
> --> >  
> --> >
> --> 
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://www.postel.org/mailman/listinfo/rbridge
> --> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDo2FZE5f5cImnZrsRAt53AKDXYGv0yJ1e18id8x0EvenAYndYzQCfcRpz
FXLJinZjfIcmaQWVRr/FedU=
=LdZJ
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBH0jFe00012; Fri, 16 Dec 2005 16:45:15 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 16:45:16 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 17 Dec 2005 00:46:08 -0000
Status: RO
Content-Length: 1030

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



Gray, Eric wrote:
> Joe, et al,
> 
> --> Guillermo Ib??ez wrote:
> --> >> My understanding was that Rbridges would do ARP proxying and would 
> --> >> forward ARP requests to other Rbridges. Am I still right?.
> --> 
> --> Not proxying; they forward ARPs like all other L2 traffic. They don't
> --> generate ARPs directed at their own L2 addresses in response to seeing
> --> other ARPs (proxying).
> --> 
> --> Joe 
> 
> Just to be clear, no device generates ARPs directed at their own L2 address.

Also, devices DO issue ARPs sent to broadcast asking about their own L2s
(though that's not what I meant above). They're called "gratuitous
ARPs", and are used to check for machines on the net with colliding IP
addresses.

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

iD8DBQFDo1+cE5f5cImnZrsRAs4zAKDomQo+gNpNK/mO6uIhiydtlNA3BACcC5Ok
vTILYQmK4uSz9d8RsbX42bs=
=bQGu
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGNi1e12538 for <[e-mail]>; Fri, 16 Dec 2005 15:44:02 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBGNhtdJ020096 for <[e-mail]>; Fri, 16 Dec 2005 18:43:56 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA27610 for <[e-mail]>; Fri, 16 Dec 2005 18:43:55 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLP0GT>; Fri, 16 Dec 2005 18:43:54 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Fri, 16 Dec 2005 18:43:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 23:45:04 -0000
Status: RO
Content-Length: 6209

Radia/Joe,

	We can call it ARP caching (which would make some sense
- possibly more than ARP replay), ARP replay or ARP Proxy.  I
am not sure where Joe's definition of "proxy" comes from, but
- if we assume that definition, then ARP proxy is not what we
have talked about at all.

	However, ARP proxy/caching/replay/<whatever> is really
an optimization - similar to the multicast optimizations of
Sue's draft.  I am reasonably sure that it does not need to
be part of the base-line RBridge specification in order to be
of use (again, much like the multicast optimization).

	Is this in the WG charter?  Should it be?

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Radia Perlman
--> Sent: Friday, December 16, 2005 4:37 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] ARP proxying
--> 
--> Yes Joe, you are right. This was a confusion over the word. 
--> I have used
--> "ARP proxy" to mean someone replies to the request, whether 
--> it be with
--> the target's actual MAC address, or with one's own MAC 
--> address. So with
--> your definition ("proxy" means you reply with your own MAC 
--> address), 
--> then you
--> are right...we do not want RBridges to do ARP proxy. But we
--> do want them to do ARP replay.
--> 
--> I suspect I'm not the only one who uses "ARP proxy" in the 
--> more general way,
--> so we have to be careful not to confuse people when we say 
--> RBridges will
--> not do it.
--> 
--> But whatever we call things, I'm glad we aren't disagreeing 
--> about how 
--> the thing
--> works functionally.
--> 
--> Radia
--> 
--> 
--> 
--> Joe Touch wrote:
--> 
--> >-----BEGIN PGP SIGNED MESSAGE-----
--> >Hash: SHA1
--> >
--> >
--> >
--> >Radia Perlman wrote:
--> >  
--> >
--> >>I'm changing the subject line to make it easier, as least 
--> for me, to
--> >>find mail on specific issues.
--> >>
--> >>I remember writing up alternatives for ARP/ND proxying and
--> >>sending the choices and pros and cons to the list, and 
--> I'm not sure there
--> >>was ever strong opinions voiced on any of them.
--> >>However, I am quite sure the WG did not rule
--> >>out ARP proxying.
--> >>
--> >>I prefer ARP proxying, rather than treating ARP like any 
--> other L2 traffic.
--> >>We could make things a bit fancier, for instance,
--> >>a) further cutting down on
--> >>traffic by having an RBridge suppress an ARP request to a 
--> particular 
--> >>target if
--> >>it knows that another one has occurred recently (either because it
--> >>iniated it as ingress RBridge or because it forwarded the 
--> encapsulated ARP
--> >>query)
--> >>b) getting rid of stale ARP caches faster by sometimes 
--> (we'd have to decide
--> >>under what circumstances) sending the ARP query directly to the
--> >>assumed target's link, and making the target respond.
--> >>
--> >>Joe...you seem to be definitively stating that the WG has 
--> ruled out 
--> >>ARP/ND proxy.
--> >>    
--> >>
--> >
--> >We need to be clear about the difference between ARP Proxy and ARP
--> >Replay. Replay is closer to what we have always been 
--> talking about. We
--> >never talked about proxying.
--> >
--> >For proxying to work:
--> >
--> >	1- a designated rbridge would intercept an ARP
--> > 	and reply with its own MAC address
--> >
--> >	2- the rbridge would need to know to which egress to forward
--> >	the packet
--> >
--> >	3- the egress would need to know the MAC on the destination LAN
--> >
--> >steps 2 and 3 involve a new set of state in the rbridge 
--> campus that we
--> >haven't talked about.
--> >
--> >My impression is thus that we've been talking about replay 
--> more than
--> >proxy. Correct me (anyone) if that's not accurate...
--> >
--> >Joe
--> >
--> >  
--> >
--> >>I may have missed some of the emails on the list (it's 
--> *really* hard
--> >>to keep up with the volume of traffic). Was this debated 
--> and concluded 
--> >>somehow?
--> >>Or were you just misremembering? Ruling proxy out is 
--> definitely a change 
--> >>from
--> >>the original intent, and changes such as this should not be done 
--> >>arbitrarily.
--> >>
--> >>Radia
--> >>
--> >>
--> >>
--> >>
--> >>Guillermo Ib??ez wrote:
--> >>
--> >>
--> >>    
--> >>
--> >>>ARP Proxying by the Designated Rbridge was considered an 
--> acceptable 
--> >>>optimization,  right?
--> >>>GI
--> >>>Joe Touch wrote:
--> >>>
--> >>>
--> >>>
--> >>>
--> >>>      
--> >>>
--> >>>>Guillermo Ib??ez wrote:
--> >>>>
--> >>>>
--> >>>>  
--> >>>>
--> >>>>
--> >>>>        
--> >>>>
--> >>>>>>My understanding was that Rbridges would do ARP 
--> proxying and would 
--> >>>>>>forward ARP requests to other Rbridges. Am I still right?.
--> >>>>>>   
--> >>>>>>
--> >>>>>>      
--> >>>>>>
--> >>>>>>            
--> >>>>>>
--> >>>>Not proxying; they forward ARPs like all other L2 
--> traffic. They don't
--> >>>>generate ARPs directed at their own L2 addresses in 
--> response to seeing
--> >>>>other ARPs (proxying).
--> >>>>
--> >>>>Joe
--> >>>>
--> >>>>
--> >>>>
--> >>>>--------------------------------------------------------
--> ----------------
--> >>>>
--> >>>>_______________________________________________
--> >>>>rbridge mailing list
--> >>>>[e-mail]
--> >>>>http://www.postel.org/mailman/listinfo/rbridge
--> >>>>
--> >>>>
--> >>>>  
--> >>>>
--> >>>>        
--> >>>>
--> >>>
--> >>>      
--> >>>
--> >>_______________________________________________
--> >>rbridge mailing list
--> >>[e-mail]
--> >>http://www.postel.org/mailman/listinfo/rbridge
--> >>    
--> >>
--> >-----BEGIN PGP SIGNATURE-----
--> >Version: GnuPG v1.2.4 (MingW32)
--> >Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> >
--> >iD8DBQFDoy3iE5f5cImnZrsRAt5qAKC9NMQuOkDFJuBg5uT8PQQBywFmhgCdEA2v
--> >IQMHjRlNxrTNAsFDK7jRkrc=
--> >=3qHZ
--> >-----END PGP SIGNATURE-----
--> >_______________________________________________
--> >rbridge mailing list
--> >[e-mail]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGNhDe12297 for <[e-mail]>; Fri, 16 Dec 2005 15:43:13 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBGNh3dJ020076; Fri, 16 Dec 2005 18:43:04 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA27515;  Fri, 16 Dec 2005 18:43:03 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLP0F7>; Fri, 16 Dec 2005 18:43:02 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Harald Tveit Alvestrand'" <[e-mail]>
Date: Fri, 16 Dec 2005 18:43:01 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] ARP <whatever> (was  it's time to summarize things)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 23:44:07 -0000
Status: RO
Content-Length: 1659

Harald,

	What is described in RFC 925 appears to be an interesting 
precursor to what Routers do, without actually using the word
router.  Equally interesting is the fact that it does not use
the word "proxy" (or anything, in fact, containing the syllable
"prox") either.

	However, I am fine with not using the terms "proxy ARP" or
"ARP proxy."

--
Eric

--> -----Original Message-----
--> From: Harald Tveit Alvestrand [mailto:[e-mail]] 
--> Sent: Friday, December 16, 2005 6:22 PM
--> To: Developing a hybrid router/bridge.; Gray, Eric
--> Subject: Re: [rbridge] ARP <whatever> (was it's time to 
--> summarize things)
--> 
--> 
--> 
--> --On fredag, desember 16, 2005 14:53:05 -0800 Joe Touch 
--> <[e-mail]> 
--> wrote:
--> 
--> >> As far as the "confusion" over ARP proxy, I am happy to use a
--> >> different word if it is confusing.  However, ARP proxy - in the
--> >> sense that I've interpreted it in the past is "proxying" the ARP
--> >> service.  That means essentially what Radia said - i.e. - close
--> >> in meaning to a name service proxy (but also similar to caching).
--> >
--> > The term "proxy ARP' is a well-known term on routers that 
--> does what I
--> > described; it is described in Cisco literature as such.
--> 
--> "Proxy ARP" has numerous citations in RFCs dating back to 
--> RFC 1009; I 
--> haven't been able to find "the" authoritative description 
--> in 5 mins of 
--> searching, but some pointers point back to RFC 925 
--> "Multi-LAN Address 
--> Resolution", which seems to describe what I think of when I 
--> say "proxy ARP".
--> 
--> Let's not try to change the meaning of that term.
--> 
--> 
--> 


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGNYae09146; Fri, 16 Dec 2005 15:34:36 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 15:34:38 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 23:35:15 -0000
Status: RO
Content-Length: 2243

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



Gray, Eric wrote:
> Joe, et al,
> 
> --> Guillermo Ib??ez wrote:
> --> >> My understanding was that Rbridges would do ARP proxying and would 
> --> >> forward ARP requests to other Rbridges. Am I still right?.
> --> 
> --> Not proxying; they forward ARPs like all other L2 traffic. They don't
> --> generate ARPs directed at their own L2 addresses in response to seeing
> --> other ARPs (proxying).
> --> 
> --> Joe 
> 
> Just to be clear, no device generates ARPs directed at their own L2 address.

Sure -

Proxy ARP =

1. device sees ARP responses (and sometimes infers MAC:IP correlactions
from other packets, such as ARP requests or other traffic) on one
interface and caches the MAC:IP data.

2. device sees ARP requests for IP addresses in its MAC:IP cache on a
different interface, and sends ARP responses with its own MAC address

- ---

Replay ARP

1. device sees .... (as above) on one interface

2. device sends a spoofed ARP response (either a replay of a seen ARP
response, or a new response based on its MAC:IP cache), i.e., with the
MAC address from the cache (NOT its own MAC address)

> Ethernet ARP responses contain the MAC address to be used (as a MAC DA) to 
> reach a specific (usually higher layer) non-MAC address.  In this
> discussion,
> we are pretty much exclusively talking about IP ARP.

Agreed.

Joe

> 
> --> -----Original Message-----
> --> From: [e-mail] 
> --> [mailto:[e-mail]] On Behalf Of Joe Touch
> --> Sent: Friday, December 16, 2005 10:09 AM
> --> To: Developing a hybrid router/bridge.
> --> Subject: Re: [rbridge] it's time to summarize things
> --> 
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://www.postel.org/mailman/listinfo/rbridge
> --> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDo08OE5f5cImnZrsRAvn3AJ9m0sgxouQoR1JrhiynsPTafin2vACglH9Y
oV2V4jBhkd1VQwL1adALcgU=
=1DjG
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGNSCe07043; Fri, 16 Dec 2005 15:28:12 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 15:28:14 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]	.marconi.com> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP <whatever> (was  it's time to summarize things)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 23:29:41 -0000
Status: RO
Content-Length: 1509

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



Harald Tveit Alvestrand wrote:
> 
> --On fredag, desember 16, 2005 14:53:05 -0800 Joe Touch <[e-mail]> 
> wrote:
> 
> 
>>>As far as the "confusion" over ARP proxy, I am happy to use a
>>>different word if it is confusing.  However, ARP proxy - in the
>>>sense that I've interpreted it in the past is "proxying" the ARP
>>>service.  That means essentially what Radia said - i.e. - close
>>>in meaning to a name service proxy (but also similar to caching).
>>
>>The term "proxy ARP' is a well-known term on routers that does what I
>>described; it is described in Cisco literature as such.
> 

> "Proxy ARP" has numerous citations in RFCs dating back to RFC 1009; I 
> haven't been able to find "the" authoritative description in 5 mins of 
> searching, but some pointers point back to RFC 925 "Multi-LAN Address 
> Resolution", which seems to describe what I think of when I say "proxy ARP".

I was not able to find the word 'proxy' in RFC 925.

The definition in 1009 is exactly what I have been using.

> Let's not try to change the meaning of that term.

I think we've agreed not to. There doesn't appear to be a good term for
replaying a cached ARP response, which is not what proxy ARP does.

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

iD8DBQFDo02OE5f5cImnZrsRArQdAKD2w2IeQ7sVfUxs2R33DhWHBt63bgCg7yWo
vZ7YmTkQWK5QGkNnN0o46Lg=
=gSYm
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGNNfe05451 for <[e-mail]>; Fri, 16 Dec 2005 15:23:42 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBGNNZdJ019711 for <[e-mail]>; Fri, 16 Dec 2005 18:23:36 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA25509 for <[e-mail]>; Fri, 16 Dec 2005 18:23:35 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLP9VV>; Fri, 16 Dec 2005 18:23:34 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Fri, 16 Dec 2005 18:23:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id jBGNNfe05451
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 23:24:02 -0000
Status: RO
Content-Length: 1102

Joe, et al,

--> Guillermo Ib??ez wrote:
--> >> My understanding was that Rbridges would do ARP proxying and would 
--> >> forward ARP requests to other Rbridges. Am I still right?.
--> 
--> Not proxying; they forward ARPs like all other L2 traffic. They don't
--> generate ARPs directed at their own L2 addresses in response to seeing
--> other ARPs (proxying).
--> 
--> Joe 

Just to be clear, no device generates ARPs directed at their own L2 address.

Ethernet ARP responses contain the MAC address to be used (as a MAC DA) to 
reach a specific (usually higher layer) non-MAC address.  In this
discussion,
we are pretty much exclusively talking about IP ARP.

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Joe Touch
--> Sent: Friday, December 16, 2005 10:09 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] it's time to summarize things
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGNMte05041; Fri, 16 Dec 2005 15:22:55 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 15:22:57 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: Re: [rbridge] ARP <whatever> (was  it's time to summarize things)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 23:23:19 -0000
Status: RO
Content-Length: 2993

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



Gray, Eric wrote:
> Joe, 
> 
> --- [SNIP] ---
> --> > 
> --> > However, ARP caching (in a sense similar to web caching) has a
> --> > "spin" (if you will) that includes mechanisms (such as Radia
> --> > suggested) for handling these problems.
> --> 
> --> That's a well-known term on the host side; caching prevents 
> --> the ARP from being emitted in the first place.
> -->
> 
> This is slightly over-simplified.  Host ARP cache entries may 
> also become stale and this is corrected using one of (at least) 
> two approaches: ICMP redirect and periodic ARP emission.  Most
> of the time, ARP cache at the host results in less ARP traffic
> on the network.
> 
> In this sense, this is a more than fair analog to what we have
> discussed relative to RBridge ARP <whatever>.

Host ARP caches do not report responses on the line; that is the focus
of the analog. Both router proxy ARP and ARP replay rely on local caches
which have the same characteristics of host caches you note above, so
that is assumed.

> In the same sense, I doubt that anyone is talking about strict
> ARP replay.  Like "spoofing", "replay" is usually associated 
> with an "attack."

The difference between replay and an attack is intent; this is benign
replay. If you prefer another term, let us know (I couldn't think of
anything as accurate as replay that was useful).

> I guess I didn't finish making my point relative to routers and
> "ARP proxy".  There is a largish difference between being an
> "ARP proxy" in the IP forwarding sense and providing an "ARP 
> (service) proxy."  Routers do not "proxy" an ARP service.  From
> a routers perspective, its MAC is the correct DA for traffic on
> a local (stub) subnet destined to a remote subnet(via the router
> in question), so it isn't answering on behalf of another device.

The 'proxy' in proxy ARP is that the router decides to emit such ARPs
based on seeing ARP responses on another interface - which is the device
on whose behalf it is answering. The intent is to emulate having the ARP
pass through the router, via redirection.

However, ICMP redirects are not the same as proxy ARPs. ICMP redirects
make the host send traffic to the IP address of the router. Proxy ARPs
fake the host into thinking it's talking to the desired endpoint when
it's really talking to the router.

> Perhaps the Cisco folks used the term Proxy because they were
> not familiar with the term Avatar.  Whatever.

Avatar implies proxy + manifestation in human form. There's little human
about what's going on here ;-)

> However, I can see where the confusion comes from, so I think it 
> is best to avoid it.

Agreed - is there a better, less derogatory term for replay?

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

iD8DBQFDo0xRE5f5cImnZrsRAm1pAJ4iEQgwH9xdnIclveLf6bW2nXD4+QCeOxoh
gdpFttgP6G5FRJPetk46mBA=
=Io11
-----END PGP SIGNATURE-----


Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGNJGe03617 for <[e-mail]>; Fri, 16 Dec 2005 15:19:16 -0800 (PST)
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 052712580E1; Sat, 17 Dec 2005 00:18:29 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21184-10; Sat, 17 Dec 2005 00:18:25 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 73CCF2580D3; Sat, 17 Dec 2005 00:18:25 +0100 (CET)
Date: Sat, 17 Dec 2005 00:22:05 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>, "Gray, Eric" <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail] .marconi.com> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP <whatever> (was  it's time to summarize things)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 23:20:12 -0000
Status: RO
Content-Length: 897

--On fredag, desember 16, 2005 14:53:05 -0800 Joe Touch <[e-mail]> 
wrote:

>> As far as the "confusion" over ARP proxy, I am happy to use a
>> different word if it is confusing.  However, ARP proxy - in the
>> sense that I've interpreted it in the past is "proxying" the ARP
>> service.  That means essentially what Radia said - i.e. - close
>> in meaning to a name service proxy (but also similar to caching).
>
> The term "proxy ARP' is a well-known term on routers that does what I
> described; it is described in Cisco literature as such.

"Proxy ARP" has numerous citations in RFCs dating back to RFC 1009; I 
haven't been able to find "the" authoritative description in 5 mins of 
searching, but some pointers point back to RFC 925 "Multi-LAN Address 
Resolution", which seems to describe what I think of when I say "proxy ARP".

Let's not try to change the meaning of that term.





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 jBGNFse02662 for <[e-mail]>; Fri, 16 Dec 2005 15:15:54 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBGNFidJ019586; Fri, 16 Dec 2005 18:15:45 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA24742;  Fri, 16 Dec 2005 18:15:44 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLP9PG>; Fri, 16 Dec 2005 18:15:43 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
Date: Fri, 16 Dec 2005 18:15:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id jBGNFse02662
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 23:16:02 -0000
Status: RO
Content-Length: 889

Guillermo,

	I think it might be slightly more correct to say that ARP 
<whatever> using some (yet to be defined) approach is considered 
an acceptable optimization.  It is also correct to say that - in
cases where a designated RBridge is (s)elected this would be the
reasonable place to do ARP <whatever>.

	Consequently, it follows that ARP <whatever> should be an
acceptable optimization for at least the designated RBridge.

	Just connecting the dots...

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Guillermo Ib??ez
--> Sent: Friday, December 16, 2005 10:17 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] it's time to summarize things
--> 
--> ARP Proxying by the Designated Rbridge was considered an acceptable 
--> optimization,  right?
--> GI
--> Joe Touch wrote:
--> 


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 jBGNDMe01578 for <[e-mail]>; Fri, 16 Dec 2005 15:13:22 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBGND0dJ019557; Fri, 16 Dec 2005 18:13:04 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA24474;  Fri, 16 Dec 2005 18:13:00 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLP9MZ>; Fri, 16 Dec 2005 18:12:59 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Joe Touch'" <[e-mail]>
Date: Fri, 16 Dec 2005 18:12:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: Re: [rbridge] ARP <whatever> (was  it's time to summarize things)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 23:14:44 -0000
Status: RO
Content-Length: 1513

Joe, 

--- [SNIP] ---
--> > 
--> > However, ARP caching (in a sense similar to web caching) has a
--> > "spin" (if you will) that includes mechanisms (such as Radia
--> > suggested) for handling these problems.
--> 
--> That's a well-known term on the host side; caching prevents 
--> the ARP from being emitted in the first place.
-->

This is slightly over-simplified.  Host ARP cache entries may 
also become stale and this is corrected using one of (at least) 
two approaches: ICMP redirect and periodic ARP emission.  Most
of the time, ARP cache at the host results in less ARP traffic
on the network.

In this sense, this is a more than fair analog to what we have
discussed relative to RBridge ARP <whatever>.

In the same sense, I doubt that anyone is talking about strict
ARP replay.  Like "spoofing", "replay" is usually associated 
with an "attack."

I guess I didn't finish making my point relative to routers and
"ARP proxy".  There is a largish difference between being an
"ARP proxy" in the IP forwarding sense and providing an "ARP 
(service) proxy."  Routers do not "proxy" an ARP service.  From
a routers perspective, its MAC is the correct DA for traffic on
a local (stub) subnet destined to a remote subnet(via the router
in question), so it isn't answering on behalf of another device.

Perhaps the Cisco folks used the term Proxy because they were
not familiar with the term Avatar.  Whatever.

However, I can see where the confusion comes from, so I think it 
is best to avoid it.

--
Eric


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGMr3e26180; Fri, 16 Dec 2005 14:53:03 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 14:53:05 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: Re: [rbridge] ARP <whatever> (was  it's time to summarize things)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 22:54:16 -0000
Status: RO
Content-Length: 2159

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



Gray, Eric wrote:
> Joe,
> 
> --> I'm not aware ARP Replay being called Proxy ARP - is anyone else? Is
> --> there a better name than ARP Replay?
> 
> ARP Replay might be clearer in indicating the inherent problems
> you pointed out (the implication of "replay" is the potential
> for "stale" information).
> 
> However, ARP caching (in a sense similar to web caching) has a
> "spin" (if you will) that includes mechanisms (such as Radia
> suggested) for handling these problems.

That's a well-known term on the host side; caching prevents the ARP from
being emitted in the first place.

> As far as the "confusion" over ARP proxy, I am happy to use a
> different word if it is confusing.  However, ARP proxy - in the
> sense that I've interpreted it in the past is "proxying" the ARP 
> service.  That means essentially what Radia said - i.e. - close
> in meaning to a name service proxy (but also similar to caching).

The term "proxy ARP' is a well-known term on routers that does what I
described; it is described in Cisco literature as such.

> What you are talking about is more like ARP spoofing, or ARP for
> higher layer (i.e. - layer 3) forwarding.

Spoofing is an attack version of proxy ARP. There are legitimate
versions as well.

> I don't believe I've
> ever heard that called ARP proxy, but it might be.  If that is
> the case, then by all means, use a different term. 
>  
> 
> --> -----Original Message-----
> --> From: [e-mail] 
> --> [mailto:[e-mail]] On Behalf Of Joe Touch
> --> Sent: Friday, December 16, 2005 10:58 AM
> --> To: Developing a hybrid router/bridge.
> --> Subject: Re: [rbridge] it's time to summarize things
> --> 
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://www.postel.org/mailman/listinfo/rbridge
> --> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDo0VRE5f5cImnZrsRAp4uAJ9ZQ2wn1+CWr7sPJUlzeba9tkIn5QCgkIyD
EEE8GhvV1eLaLO6Kp2pEm0c=
=SdWG
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGMnJe25105 for <[e-mail]>; Fri, 16 Dec 2005 14:49:19 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBGMn5dJ019212; Fri, 16 Dec 2005 17:49:05 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA22189;  Fri, 16 Dec 2005 17:49:04 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLP8Z5>; Fri, 16 Dec 2005 17:49:03 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Joe Touch'" <[e-mail]>
Date: Fri, 16 Dec 2005 17:49:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: Re: [rbridge] ARP <whatever> (was  it's time to summarize things)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 22:50:12 -0000
Status: RO
Content-Length: 1447

Joe,

--> I'm not aware ARP Replay being called Proxy ARP - is anyone else? Is
--> there a better name than ARP Replay?

ARP Replay might be clearer in indicating the inherent problems
you pointed out (the implication of "replay" is the potential
for "stale" information).

However, ARP caching (in a sense similar to web caching) has a
"spin" (if you will) that includes mechanisms (such as Radia
suggested) for handling these problems.

As far as the "confusion" over ARP proxy, I am happy to use a
different word if it is confusing.  However, ARP proxy - in the
sense that I've interpreted it in the past is "proxying" the ARP 
service.  That means essentially what Radia said - i.e. - close
in meaning to a name service proxy (but also similar to caching).

What you are talking about is more like ARP spoofing, or ARP for
higher layer (i.e. - layer 3) forwarding.  I don't believe I've
ever heard that called ARP proxy, but it might be.  If that is
the case, then by all means, use a different term. 
 

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Joe Touch
--> Sent: Friday, December 16, 2005 10:58 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] it's time to summarize things
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGLfZe06397; Fri, 16 Dec 2005 13:41:35 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 13:41:37 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 21:42:22 -0000
Status: RO
Content-Length: 4857

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



Radia Perlman wrote:
> Yes Joe, you are right. This was a confusion over the word. I have used
> "ARP proxy" to mean someone replies to the request, whether it be with
> the target's actual MAC address, or with one's own MAC address. So with
> your definition ("proxy" means you reply with your own MAC address), 
> then you
> are right...we do not want RBridges to do ARP proxy. But we
> do want them to do ARP replay.
> 
> I suspect I'm not the only one who uses "ARP proxy" in the more general way,
> so we have to be careful not to confuse people when we say RBridges will
> not do it.

Right - I checked online and most of the times Proxy ARP is used it
means what routers do, rather than replay. I didn't see any other uses,
so I'll add both definitions to the PAS doc.

> But whatever we call things, I'm glad we aren't disagreeing about how 
> the thing
> works functionally.

I'll put that in the list of things to update (issues list, but listed
as resolved).

Joe



> 
> Radia
> 
> 
> 
> Joe Touch wrote:
> 
> 
> 
> 
> Radia Perlman wrote:
>  
> 
> 
>>I'm changing the subject line to make it easier, as least for me, to
>>find mail on specific issues.
> 
>>I remember writing up alternatives for ARP/ND proxying and
>>sending the choices and pros and cons to the list, and I'm not sure there
>>was ever strong opinions voiced on any of them.
>>However, I am quite sure the WG did not rule
>>out ARP proxying.
> 
>>I prefer ARP proxying, rather than treating ARP like any other L2 traffic.
>>We could make things a bit fancier, for instance,
>>a) further cutting down on
>>traffic by having an RBridge suppress an ARP request to a particular 
>>target if
>>it knows that another one has occurred recently (either because it
>>iniated it as ingress RBridge or because it forwarded the encapsulated ARP
>>query)
>>b) getting rid of stale ARP caches faster by sometimes (we'd have to decide
>>under what circumstances) sending the ARP query directly to the
>>assumed target's link, and making the target respond.
> 
>>Joe...you seem to be definitively stating that the WG has ruled out 
>>ARP/ND proxy.
> 
> 
> 
> We need to be clear about the difference between ARP Proxy and ARP
> Replay. Replay is closer to what we have always been talking about. We
> never talked about proxying.
> 
> For proxying to work:
> 
> 	1- a designated rbridge would intercept an ARP
> 	and reply with its own MAC address
> 
> 	2- the rbridge would need to know to which egress to forward
> 	the packet
> 
> 	3- the egress would need to know the MAC on the destination LAN
> 
> steps 2 and 3 involve a new set of state in the rbridge campus that we
> haven't talked about.
> 
> My impression is thus that we've been talking about replay more than
> proxy. Correct me (anyone) if that's not accurate...
> 
> Joe
> 
>  
> 
> 
>>I may have missed some of the emails on the list (it's *really* hard
>>to keep up with the volume of traffic). Was this debated and concluded 
>>somehow?
>>Or were you just misremembering? Ruling proxy out is definitely a change 
>>from
>>the original intent, and changes such as this should not be done 
>>arbitrarily.
> 
>>Radia
> 
> 
> 
> 
>>Guillermo Ib??ez wrote:
> 
> 
> 
> 
> 
>>>ARP Proxying by the Designated Rbridge was considered an acceptable 
>>>optimization,  right?
>>>GI
>>>Joe Touch wrote:
> 
> 
> 
> 
>>>     
> 
> 
>>>>Guillermo Ib??ez wrote:
>>>>
>>>>
>>>> 
>>>>
>>>>
>>>>       
>>>>
>>>>
>>>>>>My understanding was that Rbridges would do ARP proxying and would 
>>>>>>forward ARP requests to other Rbridges. Am I still right?.
>>>>>>  
>>>>>>
>>>>>>     
>>>>>>
>>>>>>           
>>>>>>
>>>>
>>>>Not proxying; they forward ARPs like all other L2 traffic. They don't
>>>>generate ARPs directed at their own L2 addresses in response to seeing
>>>>other ARPs (proxying).
>>>>
>>>>Joe
>>>>
>>>>
>>>>
>>>>------------------------------------------------------------------------
>>>>
>>>>_______________________________________________
>>>>rbridge mailing list
>>>>[e-mail]
>>>>http://www.postel.org/mailman/listinfo/rbridge
>>>>
>>>>
>>>> 
>>>>
>>>>       
>>>>
> 
>>>     
> 
> 
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
> 
> 
> 
_______________________________________________
rbridge mailing list
[e-mail]
http://www.postel.org/mailman/listinfo/rbridge

> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDozSRE5f5cImnZrsRAmS9AKDodPaqQ3/riGgb5JoRn54NgnJ5sACfUmXm
8Kg6CAEQsY1WJpfnkrCIn7w=
=wJOz
-----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 jBGLbVe04933 for <[e-mail]>; Fri, 16 Dec 2005 13:37:31 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 16 Dec 2005 13:37:26 -0800 (PST)
Received: from sun.com ([129.150.24.253]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 16 Dec 2005 13:37:26 -0800 (PST)
Date: Fri, 16 Dec 2005 13:37:26 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 8BIT
X-Accept-Language: en-us, en
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 21:38:15 -0000
Status: RO
Content-Length: 4360

Yes Joe, you are right. This was a confusion over the word. I have used
"ARP proxy" to mean someone replies to the request, whether it be with
the target's actual MAC address, or with one's own MAC address. So with
your definition ("proxy" means you reply with your own MAC address), 
then you
are right...we do not want RBridges to do ARP proxy. But we
do want them to do ARP replay.

I suspect I'm not the only one who uses "ARP proxy" in the more general way,
so we have to be careful not to confuse people when we say RBridges will
not do it.

But whatever we call things, I'm glad we aren't disagreeing about how 
the thing
works functionally.

Radia



Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Radia Perlman wrote:
>  
>
>>I'm changing the subject line to make it easier, as least for me, to
>>find mail on specific issues.
>>
>>I remember writing up alternatives for ARP/ND proxying and
>>sending the choices and pros and cons to the list, and I'm not sure there
>>was ever strong opinions voiced on any of them.
>>However, I am quite sure the WG did not rule
>>out ARP proxying.
>>
>>I prefer ARP proxying, rather than treating ARP like any other L2 traffic.
>>We could make things a bit fancier, for instance,
>>a) further cutting down on
>>traffic by having an RBridge suppress an ARP request to a particular 
>>target if
>>it knows that another one has occurred recently (either because it
>>iniated it as ingress RBridge or because it forwarded the encapsulated ARP
>>query)
>>b) getting rid of stale ARP caches faster by sometimes (we'd have to decide
>>under what circumstances) sending the ARP query directly to the
>>assumed target's link, and making the target respond.
>>
>>Joe...you seem to be definitively stating that the WG has ruled out 
>>ARP/ND proxy.
>>    
>>
>
>We need to be clear about the difference between ARP Proxy and ARP
>Replay. Replay is closer to what we have always been talking about. We
>never talked about proxying.
>
>For proxying to work:
>
>	1- a designated rbridge would intercept an ARP
> 	and reply with its own MAC address
>
>	2- the rbridge would need to know to which egress to forward
>	the packet
>
>	3- the egress would need to know the MAC on the destination LAN
>
>steps 2 and 3 involve a new set of state in the rbridge campus that we
>haven't talked about.
>
>My impression is thus that we've been talking about replay more than
>proxy. Correct me (anyone) if that's not accurate...
>
>Joe
>
>  
>
>>I may have missed some of the emails on the list (it's *really* hard
>>to keep up with the volume of traffic). Was this debated and concluded 
>>somehow?
>>Or were you just misremembering? Ruling proxy out is definitely a change 
>>from
>>the original intent, and changes such as this should not be done 
>>arbitrarily.
>>
>>Radia
>>
>>
>>
>>
>>Guillermo Ib??ez wrote:
>>
>>
>>    
>>
>>>ARP Proxying by the Designated Rbridge was considered an acceptable 
>>>optimization,  right?
>>>GI
>>>Joe Touch wrote:
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>Guillermo Ib??ez wrote:
>>>>
>>>>
>>>>  
>>>>
>>>>
>>>>        
>>>>
>>>>>>My understanding was that Rbridges would do ARP proxying and would 
>>>>>>forward ARP requests to other Rbridges. Am I still right?.
>>>>>>   
>>>>>>
>>>>>>      
>>>>>>
>>>>>>            
>>>>>>
>>>>Not proxying; they forward ARPs like all other L2 traffic. They don't
>>>>generate ARPs directed at their own L2 addresses in response to seeing
>>>>other ARPs (proxying).
>>>>
>>>>Joe
>>>>
>>>>
>>>>
>>>>------------------------------------------------------------------------
>>>>
>>>>_______________________________________________
>>>>rbridge mailing list
>>>>[e-mail]
>>>>http://www.postel.org/mailman/listinfo/rbridge
>>>>
>>>>
>>>>  
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>>    
>>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDoy3iE5f5cImnZrsRAt5qAKC9NMQuOkDFJuBg5uT8PQQBywFmhgCdEA2v
>IQMHjRlNxrTNAsFDK7jRkrc=
>=3qHZ
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>



Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGLTJe02953; Fri, 16 Dec 2005 13:29:19 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 13:29:21 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 21:30:28 -0000
Status: RO
Content-Length: 4396

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



Saikat Ray wrote:
> The simplest, if not the most rigorous, explanation is as follows. Replace
> each legacy part of the network by a hub (i.e., first remove all RBridges
> from the topology. Then choose a legacy bridge and replace this bridge and
> all legacy bridges that have a path to it by a single hub, and let all
> end-hosts served by those legacy bridges be connected to this hub. Repeat
> this procedure until all legacy bridges are replaced. Then finally put the
> RBridges back.). Now, one and only one RBridge forwards and receives
> unencapsulated packets from each hub (through designated RBridge). Thus for
> a loop formation, a packet must loop back to a designated RBridge, which is
> not possible since RBridges use their own spanning tree for sending
> (encapsulated) broadcast traffic.

Here's a variant that maps to only existing technologies:

	- remove the rbridges (as Saikat said)
		this leaves some number of disconnected
		bridged ethernet segments

	- replace the entirety of each bridged ethernet segment
	with a single hub (again, as Saikat said)
		I'm not positive this is valid; it will
		be if you replace the segment with a bridge, though.
		I'm worried about doubly-connected hosts, etc.

	- replace the rbridge campus with a bridge
		FORCE that bridge to be the root of the spanning tree

*IF* there is at most one rbridge campus in a LAN *AND* that campus can
end up knowing it is root of all the edge spanning trees, there can't be
a loop.

The key are the IF and AND clauses.

The IF is effectively forced by the HELLO messages; all rbridge devices
will coalesce into a single campus. This means you can't use multiple
campuses to handle scalability in a LAN, however.

The AND is assumed; if there is any other device that tries the same
trick and makes the same assumption (whether another rbridge, or an
rbridge-like system that doesn't use rbridge messages), the assumption
will be invalid.

Joe


> 
> Hope this helps.
> 
> 
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On
>>Behalf Of Tim Shepard
>>Sent: Thursday, December 15, 2005 6:42 PM
>>To: Developing a hybrid router/bridge.
>>Cc: [e-mail]; 'Joe Touch'
>>Subject: Re: [rbridge] it's time to summarize things
>>
>>
>>
>>>Let us suppose that an RBridge is connected to a legacy bridge's port
>>>directly, and all RBridges block BPDUs. Then the RBridge looks like,
>>
>>from
>>
>>>the perspective of the legacy brige, either (i) a single end-host (with
>>
>>the
>>
>>>MAC address that of the RBridge) if the RBridge is not the designated
>>>RBridge, or (ii) a shared media (like a hub; is the standard term
>>>"segment"?) with potentially a lot of MAC addresses attached to it (in
>>
>>fact,
>>[....]
>>
>>>So what exactly do you think is the problem with ARP?
>>
>>
>>I'm not sure I follow all of the postings on this issue.
>>
>>But after reading through this thread, I'm still left wondering what
>>is supposed to make sure packets don't loop forever when there are a
>>mix of bridges and rbridges plugged together (in some crazy accidental
>>way, creating whatever kind of loop involving bridges and rbridges
>>that causes the most trouble).
>>
>>It seems to me that if rbridges block the spanning tree forming
>>packets, but do forward (e.g.) ARP traffic, then there could be loops
>>that are not broken by either the rbridge system or the usual bridge
>>spanning-tree-forming algorithm.
>>
>>Could someone explain succinctly (for someone who is just barely
>>following this thread) how a system (of mixed bridges and rbridges,
>>plugged together by some Byzantine net admin) will ensure that packets
>>are not forwarded in a loop?
>>
>>(And ARP is a good example, since it is supposed to go everywhere, but
>>not loop.)
>>
>>
>>Or will there be configuration rules that forbid some ways of plugging
>>together bridges and rbridges?
>>
>>			-Tim Shepard
>>			 [e-mail]
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDozGxE5f5cImnZrsRAp52AJoDJK5R9khUkkMo9TTDNBqKftcAZACfeefA
ajxeO9YPH9+MkJBwbaww00E=
=MENV
-----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 jBGLJCe00341 for <[e-mail]>; Fri, 16 Dec 2005 13:19:12 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 16 Dec 2005 13:19:07 -0800 (PST)
Received: from sun.com ([129.150.24.253]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 16 Dec 2005 13:19:07 -0800 (PST)
Date: Fri, 16 Dec 2005 13:19:05 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]> <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 21:20:03 -0000
Status: RO
Content-Length: 1341

Pekka Savola wrote:

>That's one darned big and convoluted summary.
>  
>



Is that a way of saying you volunteer to do the next summary? :-)

Actually, there's enough volume of email at this point that it would be good
to have another summary. My preference would be to separate out
different technical issues and do separate summaries of each, rather than
a "summary of the state of the mailing list". Perhaps the issues at this 
point
are whether to participate in spanning tree (I strongly vote that RBridges
drop spanning tree messages, with the option to build a colocated 
bridge/RBridge,
but certainly not to have RBridges merge spanning trees), whether to do
proxy ARP/ND (I vote yes), and perhaps there are other issues I've missed.

Anyway...I think it's useful for anyone, at any point, to do a summary, so
if you have the energy, it would be much appreciated. In my view of
how a mortal can follow a mailing list without spending full time on the one
mailing list, is that once someone does a summary, all previous emails can
be ignored...anyone that doesn't think the summary is accurate can send
reply to the summary. And there would need to be some sort of sequence
number on email messages so we know which ones are
before and which after a summary, but I'm assuming the time stamp will 
be good enough.

Thanks,

Radia



Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGLD4e28263; Fri, 16 Dec 2005 13:13:04 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 13:13:06 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 21:14:25 -0000
Status: RO
Content-Length: 3351

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



Radia Perlman wrote:
> I'm changing the subject line to make it easier, as least for me, to
> find mail on specific issues.
> 
> I remember writing up alternatives for ARP/ND proxying and
> sending the choices and pros and cons to the list, and I'm not sure there
> was ever strong opinions voiced on any of them.
> However, I am quite sure the WG did not rule
> out ARP proxying.
> 
> I prefer ARP proxying, rather than treating ARP like any other L2 traffic.
> We could make things a bit fancier, for instance,
> a) further cutting down on
> traffic by having an RBridge suppress an ARP request to a particular 
> target if
> it knows that another one has occurred recently (either because it
> iniated it as ingress RBridge or because it forwarded the encapsulated ARP
> query)
> b) getting rid of stale ARP caches faster by sometimes (we'd have to decide
> under what circumstances) sending the ARP query directly to the
> assumed target's link, and making the target respond.
> 
> Joe...you seem to be definitively stating that the WG has ruled out 
> ARP/ND proxy.

We need to be clear about the difference between ARP Proxy and ARP
Replay. Replay is closer to what we have always been talking about. We
never talked about proxying.

For proxying to work:

	1- a designated rbridge would intercept an ARP
 	and reply with its own MAC address

	2- the rbridge would need to know to which egress to forward
	the packet

	3- the egress would need to know the MAC on the destination LAN

steps 2 and 3 involve a new set of state in the rbridge campus that we
haven't talked about.

My impression is thus that we've been talking about replay more than
proxy. Correct me (anyone) if that's not accurate...

Joe

> I may have missed some of the emails on the list (it's *really* hard
> to keep up with the volume of traffic). Was this debated and concluded 
> somehow?
> Or were you just misremembering? Ruling proxy out is definitely a change 
> from
> the original intent, and changes such as this should not be done 
> arbitrarily.
> 
> Radia
> 
> 
> 
> 
> Guillermo Ib??ez wrote:
> 
> 
>>ARP Proxying by the Designated Rbridge was considered an acceptable 
>>optimization,  right?
>>GI
>>Joe Touch wrote:
>>
>> 
>>
>>
>>>Guillermo Ib??ez wrote:
>>>
>>>
>>>   
>>>
>>>
>>>>>My understanding was that Rbridges would do ARP proxying and would 
>>>>>forward ARP requests to other Rbridges. Am I still right?.
>>>>>    
>>>>>
>>>>>       
>>>>>
>>>
>>>Not proxying; they forward ARPs like all other L2 traffic. They don't
>>>generate ARPs directed at their own L2 addresses in response to seeing
>>>other ARPs (proxying).
>>>
>>>Joe
>>>
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>rbridge mailing list
>>>[e-mail]
>>>http://www.postel.org/mailman/listinfo/rbridge
>>>
>>>
>>>   
>>>
>>
>> 
>>
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDoy3iE5f5cImnZrsRAt5qAKC9NMQuOkDFJuBg5uT8PQQBywFmhgCdEA2v
IQMHjRlNxrTNAsFDK7jRkrc=
=3qHZ
-----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 jBGL4Ce25739 for <[e-mail]>; Fri, 16 Dec 2005 13:04:12 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 16 Dec 2005 13:04:04 -0800 (PST)
Received: from sun.com ([129.150.24.253]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 16 Dec 2005 13:04:04 -0800 (PST)
Date: Fri, 16 Dec 2005 13:04:06 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 8BIT
X-Accept-Language: en-us, en
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] ARP proxying
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 21:06:07 -0000
Status: RO
Content-Length: 2118

I'm changing the subject line to make it easier, as least for me, to
find mail on specific issues.

I remember writing up alternatives for ARP/ND proxying and
sending the choices and pros and cons to the list, and I'm not sure there
was ever strong opinions voiced on any of them.
However, I am quite sure the WG did not rule
out ARP proxying.

I prefer ARP proxying, rather than treating ARP like any other L2 traffic.
We could make things a bit fancier, for instance,
a) further cutting down on
traffic by having an RBridge suppress an ARP request to a particular 
target if
it knows that another one has occurred recently (either because it
iniated it as ingress RBridge or because it forwarded the encapsulated ARP
query)
b) getting rid of stale ARP caches faster by sometimes (we'd have to decide
under what circumstances) sending the ARP query directly to the
assumed target's link, and making the target respond.

Joe...you seem to be definitively stating that the WG has ruled out 
ARP/ND proxy.
I may have missed some of the emails on the list (it's *really* hard
to keep up with the volume of traffic). Was this debated and concluded 
somehow?
Or were you just misremembering? Ruling proxy out is definitely a change 
from
the original intent, and changes such as this should not be done 
arbitrarily.

Radia




Guillermo Ib??ez wrote:

>ARP Proxying by the Designated Rbridge was considered an acceptable 
>optimization,  right?
>GI
>Joe Touch wrote:
>
>  
>
>>Guillermo Ib??ez wrote:
>> 
>>
>>    
>>
>>>>My understanding was that Rbridges would do ARP proxying and would 
>>>>forward ARP requests to other Rbridges. Am I still right?.
>>>>     
>>>>
>>>>        
>>>>
>>Not proxying; they forward ARPs like all other L2 traffic. They don't
>>generate ARPs directed at their own L2 addresses in response to seeing
>>other ARPs (proxying).
>>
>>Joe
>>
>> 
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>> 
>>
>>    
>>
>
>  
>



Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGGpIe11656 for <[e-mail]>; Fri, 16 Dec 2005 08:51:19 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBGGpCdJ011724 for <[e-mail]>; Fri, 16 Dec 2005 11:51:12 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA05403 for <[e-mail]>; Fri, 16 Dec 2005 11:51:12 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLPRKG>; Fri, 16 Dec 2005 11:51:11 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Fri, 16 Dec 2005 11:51:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 16:52:04 -0000
Status: RO
Content-Length: 1828

Guillermo,

	See below...

--
Eric 

--- [SNIP] ---
--> >
--> >So, I would argue for this position: we won't deliberately restrict
--> >LAN size scalability unless we run into issues that require it and
--> >we won't specify anything more than "MUST work for LANs of a size
--> >at least as great as can be accomplished using 802.1 bridges."
--> >
--> >  
--> >
--> This ("as great as using 802.1 bridges2) perhaps is not very precise....

--> The target of 100.000 hosts is clear,  aggresive enough  and allows 
--> scalability evaluation of the solutions.
--> 

The point is that scalability and (larger) LAN sizes is _not_ an objective.
Clearly any attempt to specify precise values for size/scalability is also
an attempt to make these into objectives.

The real objective is that the service provided by RBridges - in general -
should not be worse than that available from bridges - and that is what a
statement like the one I suggested makes sense.  However, we have to keep 
our eyes on the ball.  It may turn out that realistic applications for
RBridges are typically small numbers of high capacity devices in a dense
campus configuration where efficient use of _expensive_ interfaces and
infrastructure is a more compelling objective than scalability of campus
size.

--> My opinion is that introducing additional functionality and complexity 
--> like Rbridges in campuses should provide some  extra benefits, allowing 
--> larger network sizes. If we keep current network sizes as target, then 
--> the problem statement is just to replace so called switching routers or 
--> multilayer switches and the like with  an hybrid device using MAC
routing, 
--> withina a single IP subnet. 

In my opinion, that could very well be true, but it would require a explicit
modification of the WG charter.
 
--> 
--- [SNIP] ---


Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGFwae27975; Fri, 16 Dec 2005 07:58:36 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 07:58:29 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0AC7AE0F5B1C20B0DDAD6823"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 15:59:24 -0000
Status: RO
Content-Length: 2339

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

There are two ARP issues to be considered:

Proxy ARP, no - i.e., there should be no point at which an rbridge
preemptively replies to an incoming ARP with an ARP reply with its own
MAC address. Rbridge MAC addresses should never appear in external node
(host/router) ARP tables.

The optimization we discussed is based on snooping and reply via replay,
which could be called ARP Replay, i.e., to emit the ARP that the rbridge
thinks will be emitted from the ultimate destination, rather than to
broadcast the ARP throughout in search of that host. There are issues
with that procedure - notably, when nodes silently renumber, where that
replayed reply could be in error, which need to be considered, but
that's a later discussion.

I'm not aware ARP Replay being called Proxy ARP - is anyone else? Is
there a better name than ARP Replay?

Joe

Guillermo Ib=E1=F1ez wrote:
> ARP Proxying by the Designated Rbridge was considered an acceptable=20
> optimization,  right?
> GI
> Joe Touch wrote:
>=20
>> Guillermo Ib=E1=F1ez wrote:
>> =20
>>
>>>> My understanding was that Rbridges would do ARP proxying and would=20
>>>> forward ARP requests to other Rbridges. Am I still right?.
>>>>     =20
>>>>
>> Not proxying; they forward ARPs like all other L2 traffic. They don't
>> generate ARPs directed at their own L2 addresses in response to seeing=

>> other ARPs (proxying).
>>
>> Joe
>>
>> =20
>>
>> ----------------------------------------------------------------------=
--
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://www.postel.org/mailman/listinfo/rbridge
>> =20
>>
>=20


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

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

iD8DBQFDouQlE5f5cImnZrsRAgdMAKCRnT4AnlJeh2Puq80DtW70eW0LSwCfWfbF
1oUO/MxwWJzpmOtBhim5Aq4=
=8Hk0
-----END PGP SIGNATURE-----

--------------enig0AC7AE0F5B1C20B0DDAD6823--


Received: from psychopathy.seas.upenn.edu (psychopathy.seas.upenn.edu [158.130.65.164]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGFVae20841 for <[e-mail]>; Fri, 16 Dec 2005 07:31:36 -0800 (PST)
Received: from red.seas.upenn.edu (RED.seas.upenn.edu [158.130.64.176]) by psychopathy.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id jBGFVVMC009056; Fri, 16 Dec 2005 10:31:31 -0500
Received: from red.seas.upenn.edu (localhost [127.0.0.1]) by red.seas.upenn.edu (8.12.10/8.12.9) with ESMTP id jBGFVV7i021464; Fri, 16 Dec 2005 10:31:31 -0500 (EST)
Received: from localhost (saikat@localhost) by red.seas.upenn.edu (8.12.10/8.12.9/Submit) with ESMTP id jBGFVUPT021461; Fri, 16 Dec 2005 10:31:30 -0500 (EST)
Date: Fri, 16 Dec 2005 10:31:30 -0500 (EST)
From: Saikat Ray <[e-mail]>
To: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
X-Spam-Status: -2.82 ALL_TRUSTED
X-Scanned-By: MIMEDefang 2.49 on 158.130.65.164
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 jBGFVae20841
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 15:32:07 -0000
Status: RO
Content-Length: 4169

> Saikat Ray wrote:
>
> >The simplest, if not the most rigorous, explanation is as follows. Replace
> >each legacy part of the network by a hub (i.e., first remove all RBridges
> >from the topology. Then choose a legacy bridge and replace this bridge and
> >all legacy bridges that have a path to it by a single hub, and let all
> >end-hosts served by those legacy bridges be connected to this hub. Repeat
> >this procedure until all legacy bridges are replaced. Then finally put the
> >RBridges back.). Now, one and only one RBridge forwards and receives
> >unencapsulated packets from each hub (through designated RBridge).
> >
> But what happens when two separate hubs with separate RBridges
> forwarding each one traffic are connected
> by a link restoration between them?. A single "hub" will be created with
> two Designated RBridges till the
> detect the situation. How (and how fast), the DR election mechanims
> should work in this situation?
> Guillermo

This was discussed long before. The frequency of RBridge hello messages
will determine the length of transience (once a hello is sent, the
presence of two RBridges on the same "hub" will be detected). Radia had
some comments about the numerical value of the frequency, which I do not
remember; it is in one of the emails on the list :)

>
>
>  Thus for
>
> >a loop formation, a packet must loop back to a designated RBridge, which is
> >not possible since RBridges use their own spanning tree for sending
> >(encapsulated) broadcast traffic.
> >
> >Hope this helps.
> >
> >
> >
> >>-----Original Message-----
> >>From: [e-mail] [mailto:[e-mail]] On
> >>Behalf Of Tim Shepard
> >>Sent: Thursday, December 15, 2005 6:42 PM
> >>To: Developing a hybrid router/bridge.
> >>Cc: [e-mail]; 'Joe Touch'
> >>Subject: Re: [rbridge] it's time to summarize things
> >>
> >>
> >>
> >>
> >>>Let us suppose that an RBridge is connected to a legacy bridge's port
> >>>directly, and all RBridges block BPDUs. Then the RBridge looks like,
> >>>
> >>>
> >>from
> >>
> >>
> >>>the perspective of the legacy brige, either (i) a single end-host (with
> >>>
> >>>
> >>the
> >>
> >>
> >>>MAC address that of the RBridge) if the RBridge is not the designated
> >>>RBridge, or (ii) a shared media (like a hub; is the standard term
> >>>"segment"?) with potentially a lot of MAC addresses attached to it (in
> >>>
> >>>
> >>fact,
> >>[....]
> >>
> >>
> >>>So what exactly do you think is the problem with ARP?
> >>>
> >>>
> >>I'm not sure I follow all of the postings on this issue.
> >>
> >>But after reading through this thread, I'm still left wondering what
> >>is supposed to make sure packets don't loop forever when there are a
> >>mix of bridges and rbridges plugged together (in some crazy accidental
> >>way, creating whatever kind of loop involving bridges and rbridges
> >>that causes the most trouble).
> >>
> >>It seems to me that if rbridges block the spanning tree forming
> >>packets, but do forward (e.g.) ARP traffic, then there could be loops
> >>that are not broken by either the rbridge system or the usual bridge
> >>spanning-tree-forming algorithm.
> >>
> >>Could someone explain succinctly (for someone who is just barely
> >>following this thread) how a system (of mixed bridges and rbridges,
> >>plugged together by some Byzantine net admin) will ensure that packets
> >>are not forwarded in a loop?
> >>
> >>(And ARP is a good example, since it is supposed to go everywhere, but
> >>not loop.)
> >>
> >>
> >>Or will there be configuration rules that forbid some ways of plugging
> >>together bridges and rbridges?
> >>
> >>			-Tim Shepard
> >>			 [e-mail]
> >>_______________________________________________
> >>rbridge mailing list
> >>[e-mail]
> >>http://www.postel.org/mailman/listinfo/rbridge
> >>
> >>
> >
> >_______________________________________________
> >rbridge mailing list
> >[e-mail]
> >http://www.postel.org/mailman/listinfo/rbridge
> >
> >
> >
>
> --
> Guillermo Ib??ez
> Departamento de Ingenier?a Telem?tica
> Universidad Carlos III de Madrid
> 1.1.B.11 Colmenarejo 91-6241393
> 4.1.F.13 Legan?s 91-6248794
>


Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGFGne15846 for <[e-mail]>; Fri, 16 Dec 2005 07:16:50 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4093384BF2 for <[e-mail]>; Fri, 16 Dec 2005 16:16:40 +0100 (CET)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp02.uc3m.es (Postfix) with ESMTP id B616184BE5 for <[e-mail]>; Fri, 16 Dec 2005 16:16:39 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 16:16:39 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 15:17:03 -0000
Status: RO
Content-Length: 849

ARP Proxying by the Designated Rbridge was considered an acceptable 
optimization,  right?
GI
Joe Touch wrote:

>Guillermo Ib??ez wrote:
>  
>
>>>My understanding was that Rbridges would do ARP proxying and would 
>>>forward ARP requests to other Rbridges. Am I still right?.
>>>      
>>>
>
>Not proxying; they forward ARPs like all other L2 traffic. They don't
>generate ARPs directed at their own L2 addresses in response to seeing
>other ARPs (proxying).
>
>Joe
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

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



Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGFBRe14109; Fri, 16 Dec 2005 07:11:27 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 07:11:20 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<006201c601ba$6193f870$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig41F7A78FA3F29083F5AF817B"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 15:12:09 -0000
Status: RO
Content-Length: 1115

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



Guillermo Ib=E1=F1ez wrote:
=2E..
>> My understanding is "like a router that only has MAC addresses in its =

>> routing and forwarding tables".
>> =20
>>
> Assuming that this includes that Rbridges have lists of host MACs =20
> associated with every Rbridge MAC

That's described in the ARCH document - only the ingress/egress rbrodges
need such tables, called Campus Transit Tables therein (see Sec 3.3).

Joe


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

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

iD8DBQFDotkYE5f5cImnZrsRAh/zAJ9CbecAjysC+7IJbGCoqaxqGpSuzACg1Ove
e/SJNLG244axZyZfFLvqlA4=
=maih
-----END PGP SIGNATURE-----

--------------enig41F7A78FA3F29083F5AF817B--


Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGF8he13331; Fri, 16 Dec 2005 07:08:43 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 07:08:30 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0297201B136109CEF6066CE9"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 15:09:06 -0000
Status: RO
Content-Length: 1036

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



Guillermo Ib=E1=F1ez wrote:
>> My understanding was that Rbridges would do ARP proxying and would=20
>> forward ARP requests to other Rbridges. Am I still right?.

Not proxying; they forward ARPs like all other L2 traffic. They don't
generate ARPs directed at their own L2 addresses in response to seeing
other ARPs (proxying).

Joe


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

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

iD8DBQFDothzE5f5cImnZrsRAnWUAJ9Rub/ZLbf7KFOm8R8C+AqDFpAmowCg5O9m
rm7pfgnpVa0OXMdHtwm4gCI=
=HT6Z
-----END PGP SIGNATURE-----

--------------enig0297201B136109CEF6066CE9--


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 jBGCkPe08268 for <[e-mail]>; Fri, 16 Dec 2005 04:46:26 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3FBFE9E60E; Fri, 16 Dec 2005 13:46:13 +0100 (CET)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp01.uc3m.es (Postfix) with ESMTP id 5781F9EF71; Fri, 16 Dec 2005 12:39:49 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 12:39:49 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 12:47:09 -0000
Status: RO
Content-Length: 3661

Saikat Ray wrote:

>The simplest, if not the most rigorous, explanation is as follows. Replace
>each legacy part of the network by a hub (i.e., first remove all RBridges
>from the topology. Then choose a legacy bridge and replace this bridge and
>all legacy bridges that have a path to it by a single hub, and let all
>end-hosts served by those legacy bridges be connected to this hub. Repeat
>this procedure until all legacy bridges are replaced. Then finally put the
>RBridges back.). Now, one and only one RBridge forwards and receives
>unencapsulated packets from each hub (through designated RBridge).
>
But what happens when two separate hubs with separate RBridges 
forwarding each one traffic are connected
by a link restoration between them?. A single "hub" will be created with 
two Designated RBridges till the
detect the situation. How (and how fast), the DR election mechanims 
should work in this situation?
Guillermo


 Thus for

>a loop formation, a packet must loop back to a designated RBridge, which is
>not possible since RBridges use their own spanning tree for sending
>(encapsulated) broadcast traffic.
>
>Hope this helps.
>
>  
>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On
>>Behalf Of Tim Shepard
>>Sent: Thursday, December 15, 2005 6:42 PM
>>To: Developing a hybrid router/bridge.
>>Cc: [e-mail]; 'Joe Touch'
>>Subject: Re: [rbridge] it's time to summarize things
>>
>>
>>    
>>
>>>Let us suppose that an RBridge is connected to a legacy bridge's port
>>>directly, and all RBridges block BPDUs. Then the RBridge looks like,
>>>      
>>>
>>from
>>    
>>
>>>the perspective of the legacy brige, either (i) a single end-host (with
>>>      
>>>
>>the
>>    
>>
>>>MAC address that of the RBridge) if the RBridge is not the designated
>>>RBridge, or (ii) a shared media (like a hub; is the standard term
>>>"segment"?) with potentially a lot of MAC addresses attached to it (in
>>>      
>>>
>>fact,
>>[....]
>>    
>>
>>>So what exactly do you think is the problem with ARP?
>>>      
>>>
>>I'm not sure I follow all of the postings on this issue.
>>
>>But after reading through this thread, I'm still left wondering what
>>is supposed to make sure packets don't loop forever when there are a
>>mix of bridges and rbridges plugged together (in some crazy accidental
>>way, creating whatever kind of loop involving bridges and rbridges
>>that causes the most trouble).
>>
>>It seems to me that if rbridges block the spanning tree forming
>>packets, but do forward (e.g.) ARP traffic, then there could be loops
>>that are not broken by either the rbridge system or the usual bridge
>>spanning-tree-forming algorithm.
>>
>>Could someone explain succinctly (for someone who is just barely
>>following this thread) how a system (of mixed bridges and rbridges,
>>plugged together by some Byzantine net admin) will ensure that packets
>>are not forwarded in a loop?
>>
>>(And ARP is a good example, since it is supposed to go everywhere, but
>>not loop.)
>>
>>
>>Or will there be configuration rules that forbid some ways of plugging
>>together bridges and rbridges?
>>
>>			-Tim Shepard
>>			 [e-mail]
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>>    
>>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

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



Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGBLae18398 for <[e-mail]>; Fri, 16 Dec 2005 03:21:37 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A5C7A9E215 for <[e-mail]>; Fri, 16 Dec 2005 12:21:30 +0100 (CET)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp01.uc3m.es (Postfix) with ESMTP id C5CAB9E210 for <[e-mail]>; Fri, 16 Dec 2005 12:21:29 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 12:21:29 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 11:22:07 -0000
Status: RO
Content-Length: 3932

Just to elaborate on the ambiguity of saying

"MUST work for LANs of a size
at least as great as can be accomplished using 802.1 bridges."

Using Multiple Spanning Tree Protocol (802.1Q) with a lot of MSTP 
regions, very big networks can be built, although quite complex to 
configure and manage.
Using RSTP with point to point links, my understanding is that it seems 
there is no real limit to  network size, although % of network 
utilization will be very low and root bridge will become congested. If 
there are shared links in the network, (situation like STP)  then the 
port state transitions to forwarding are governed by timers,  with  max 
values  of 30 seconds. Network size is then limited, as in STP.

Guillermo

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Agreed.... with the caveat below
>
>Gray, Eric wrote:
>  
>
>>Spencer,
>>
>>	In the WG charter, it stipulates the following as
>>design goals:
>>
>>- Minimal or no configuration required
>>- Load-splitting among multiple paths
>>- Routing loop mitigation (possibly through a TTL field)
>>- Support of multiple points of attachment
>>- Support for broadcast and multicast
>>- No significant service delay after attachment
>>- No less secure than existing bridged solutions
>>
>>Note that this list does not include "Support for a larger broadcast
>>domain."
>>
>>However, if we can make layer 2 networking more efficient - thereby
>>overcoming some of the issues that limit current workable maximum
>>LAN size - we will most likely see LAN sizes increase again until
>>they are approaching a new maximum size.
>>
>>This is less a goal, then a probable outcome.  It is hard to state
>>"LAN sizes will increase until they work about as poorly as they do
>>now" as a goal - at least while keeping a straight face.  
>>
>>While I think we can all agree - at least in principle - that it is
>>probably not desirable to deliberately put cruft into the protocol
>>to prevent this from happening, I don't think we can get rock solid
>>consensus as to how much larger we might want to target.  I think
>>the given goals are aggressive enough.
>>
>>So, I would argue for this position: we won't deliberately restrict
>>LAN size scalability unless we run into issues that require it and
>>we won't specify anything more than "MUST work for LANs of a size
>>at least as great as can be accomplished using 802.1 bridges."
>>
>>I believe this is consistent with what we've all been saying, but I
>>am open to the possibility that I may have misunderstood someone,
>>somewhere along the line...
>>    
>>
>
>FWIW, this is basically what the current PAS states, though some have
>raised it as a possible concern.
>
>Joe
>
>  
>
>>--
>>Eric
>>
>>--- [SNIP] ---
>>
>>--> 
>>--> >> --> if not, then can there be broadcast storms?
>>--> >>
>>--> >> Certainly not worse than currently, except to the extent that
>>--> >> an RBridge campus enhanced broadcast domain _might_ be larger.
>>--> 
>>--> Eric - is this just saying that someone may want to try for 100,000 MAC 
>>--> addresses in one RBRIDGE campus? Or did you mean more than this?
>>--> 
>>--> >> --> if not, then will broadcast be supported?
>>--> >> -->
>>--> >>
>>--- [SNIP] --- 
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>>    
>>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDofPWE5f5cImnZrsRAqWgAKCLZu4u/kG6rHRd47aXTAPeA9sjHACdF5MN
>r4wQKmB85gf/RGEG7ElV9gg=
>=vcJf
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

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



Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGANre04597 for <[e-mail]>; Fri, 16 Dec 2005 02:23:53 -0800 (PST)
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 16 Dec 2005 11:23:49 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBGANiFZ004583;  Fri, 16 Dec 2005 11:23:45 +0100 (MET)
Received: from [10.61.80.197] (ams-clip-vpn-dhcp4294.cisco.com [10.61.80.197]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA12363; Fri, 16 Dec 2005 10:23:43 GMT
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 10:23:43 +0000
From: Stewart Bryant <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
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=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 10:25:50 -0000
Status: RO
Content-Length: 4446

Gray, Eric wrote:

>Stuart,
>
>	First, thank you very much for providing a concrete
>example of the "optimality issues" Guillermo brought up 
>earlier.
>
>	Let me try to address the figure below as follows:
>
>1) we have already talked about the fact that an RBridge 
>   implementation may include colocated bridge functionality
>   and that this colocated bridge may be configured with a
>   high priority so that it will become the root for any
>   connected bridge spanning tree.
>2) we said that we will include a statement to this effect
>   in RBridge/TRILL specifications.  Based on the example
>   you provide, I am even willing to concede that doing so
>   should be recommended.
>3) The separation of RBridge _implementation_ into one or
>   more logical bridges and a (central/hub) RBridge allows
>   for specification of the RBridge component orthogonally
>   relative to the specification of bridge behavior (which
>   is a] done already and b] not under our purview anyway).
>4) Even though this scenario strongly implies the need for
>   a colocated bridge, in fairness, the scenario is based 
>   on the topological assumption that there is a(t least 
>   one) bridge to the right of the figure shown.
>
>To show that you can get the exact same result without a
>colocated bridge, consider the following modification to
>your proposed scenario:
>
>      +----+
> -----|    |    L1
> -----| B1 |----------> B3 <---> To RBridge campus <-+
> -----|    |                                         |
>      +----+                                         |
>         |                                           |
>         | L3                                        |
>         |                                           |
>      +----+                                         |
> -----|    |    L2                                   |
> -----| B2 |----------> B4 <---> To RBridge campus <-+
> -----|    |
>      +----+
>
>Given that your scenario assumes the presence of at least
>one bridge to the right (core-ward), then this transform
>simply means that a few of those existing bridges will not
>be scrapped when the rest are.  Configuring B3 and B4 with 
>higher priority makes this work in exactly the same way 
>that Guillermo's colocated bridge functionality would.
>
>  
>
I do not see how this solves the problem.

Only one of B3 or B4 can become root, so S will appear
to the right of B3, or B4, but not both.

The only way to load share traffic if for root to appear
inside the RBridge cloud. Is that what we are doing?

- Stewart

>--
>Eric 
>
>--> -----Original Message-----
>--> From: [e-mail] 
>--> [mailto:[e-mail]] On Behalf Of Stewart Bryant
>--> Sent: Thursday, December 15, 2005 9:54 AM
>--> To: Radia Perlman
>--> Cc: Developing a hybrid router/bridge.
>--> Subject: Re: [rbridge] it's time to summarize things
>--> 
>--> Radia Perlman wrote:
>--> 
>--> > I think I might need a picture of what you're saying, but 
>--> > I think it's just the opposite. RBridges can path split, 
>--> > just like routers can, whereas if the spanning tree turns
>--> > off one of the links, then a bridge would only use one of
>--> > the paths.
>--> 
>--> The SPT situation is as follows:
>--> 
>-->      +----+
>--> -----|    |    L1
>--> -----| B1 |---------->To core
>--> -----|    |
>-->      +----+
>-->         |
>-->         | L3
>-->         |
>-->      +----+
>--> -----|    |    L2
>--> -----| B2 |---------->To core
>--> -----|    |
>-->      +----+
>--> 
>--> You want
>--> B1 to connect a bunch of systems to the main network via L1
>--> B2 to connect a different bunch of systems to the main 
>--> network via L2
>--> 
>--> So you set B1 and B2 with low priority, so the root is to the
>--> right in the main network, and the ports connecting B1 and B2 to L3
>--> go into blocking.
>--> 
>--> Say most of the traffic is to some server S. This traffic will
>--> be load balanced over both links L1 and L2.
>--> 
>--> Now replace the core with an Rbridge network, but leave B1 and B2
>--> running SPT (because you can't upgrade the wiring closets - 
>--> there are too many of them)
>--> 
>--> How does the traffic from B1 and B2 to S get load balanced
>--> via L1 and L2?
>--> 
>--> - Stewart
>--> 
>--> 
>--> 
>--> _______________________________________________
>--> rbridge mailing list
>--> [e-mail]
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> 
>
>
>  
>


Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGAJae03665 for <[e-mail]>; Fri, 16 Dec 2005 02:19:37 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C90479E346 for <[e-mail]>; Fri, 16 Dec 2005 11:19:30 +0100 (CET)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp01.uc3m.es (Postfix) with ESMTP id 2FC2E9E33C for <[e-mail]>; Fri, 16 Dec 2005 11:19:30 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 11:19:30 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <006201c601ba$6193f870$[e-mail]>
In-Reply-To: <006201c601ba$6193f870$[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 10:20:00 -0000
Status: RO
Content-Length: 3223

Spencer Dawkins wrote:

>Eric and Joe,
>
>You guys are having a great time, but this may be a good opportunity for a 
>"me, too", building towards the day when Erik tries to figure out what 
>consensus looks like ...
>
>  
>
>>>--> If a campus is not "like" either a bridge or a hub, someone needs to
>>>--> describe what it does - either in terms of another viable L2 analog,
>>>--> or in terms of how it interacts with each level of protocol:
>>>      
>>>
>
>My understanding is "like a router that only has MAC addresses in its 
>routing and forwarding tables".
>  
>
Assuming that this includes that Rbridges have lists of host MACs  
associated with every Rbridge MAC

>  
>
>>>--> - do external nodes address traffic to the ingress?
>>>--> I have been assuming NO.
>>>
>>>That is correct.
>>>      
>>>
>
>I agree ("correct").
>
>  
>
I agree

>>>--> if they do, then a lot of protocols are affected
>>>--> and need modification and/or proxying.
>>>-->
>>>--> - do external bridges address traffic to rbridges?
>>>--> (basically BPDUs)
>>>--> I have been assuming YES.
>>>
>>>That is incorrect.
>>>      
>>>
>
>I agree (with "incorrect").
>
>  
>
I agree with incorrect.

>>Understood, at least assuming the BLOCK and PARTICIPATE cases. For
>>TRANSPARENT, this is still correct.
>>    
>>
>
>I agree with this also, which is one of the things that bothers me about 
>TRANSPARENT.
>
>  
>
>>>--> if not, then how do bridges know to forward
>>>--> traffic to the ingresses?
>>>
>>>The same way they always do.  That is, they learn about the
>>>MAC addresses from traffic they see coming from the direction
>>>of the RBridge campus, so they know to forward traffic with
>>>a MAC DA toward the MAC SA they've learned earlier.
>>>
>>>This is what makes the RBridge campus look like a collection
>>>of MAC sources/sinks on a common Ethernet link.
>>>
>>>Naturally, the process will be (as usual in 802.1 networks)
>>>"primed" by either by broadcast (e.g. ARP) or by flooding.
>>>      
>>>
>>Agreed.
>>    
>>
>
>I agree (with "Agreed").
>  
>
I agree also . I would formulate like:  ".....to the ingresses? :  
According to IEEE 802.1D."

>  
>
>>>--> if not, then can there be broadcast storms?
>>>
>>>Certainly not worse than currently, except to the extent that
>>>an RBridge campus enhanced broadcast domain _might_ be larger.
>>>      
>>>
>
>Eric - is this just saying that someone may want to try for 100,000 MAC 
>addresses in one RBRIDGE campus? Or did you mean more than this?
>
>  
>
>>>--> if not, then will broadcast be supported?
>>>-->
>>>
>>>Yes, of course.
>>>
>>>      
>>>
>
>I agree (with "Yes, of course").
>  
>
Yes, of course

>  
>
>>>-->
>>>--> (this is not necessarily a complete list, but it's a start;
>>>--> anyone want to answer it?)
>>>
>>>Many people probably could.  What about somebody else?
>>>      
>>>
>
>Hope this helps! Others?
>
>Spencer 
>
>  
>
I hope too .. :-)
Guillermo

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

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



Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGA7Ee00424 for <[e-mail]>; Fri, 16 Dec 2005 02:07:15 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B56729E0EA for <[e-mail]>; Fri, 16 Dec 2005 11:07:08 +0100 (CET)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp01.uc3m.es (Postfix) with ESMTP id 2D37F9E08D for <[e-mail]>; Fri, 16 Dec 2005 11:07:08 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 11:07:08 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 10:08:07 -0000
Status: RO
Content-Length: 3083

Gray, Eric wrote:

>Spencer,
>
>	In the WG charter, it stipulates the following as
>design goals:
>
>- Minimal or no configuration required
>- Load-splitting among multiple paths
>- Routing loop mitigation (possibly through a TTL field)
>- Support of multiple points of attachment
>- Support for broadcast and multicast
>- No significant service delay after attachment
>- No less secure than existing bridged solutions
>
>Note that this list does not include "Support for a larger broadcast
>domain."
>
>However, if we can make layer 2 networking more efficient - thereby
>overcoming some of the issues that limit current workable maximum
>LAN size - we will most likely see LAN sizes increase again until
>they are approaching a new maximum size.
>
>This is less a goal, then a probable outcome.  It is hard to state
>"LAN sizes will increase until they work about as poorly as they do
>now" as a goal - at least while keeping a straight face.  
>
>While I think we can all agree - at least in principle - that it is
>probably not desirable to deliberately put cruft into the protocol
>to prevent this from happening, I don't think we can get rock solid
>consensus as to how much larger we might want to target.  I think
>the given goals are aggressive enough.
>
>So, I would argue for this position: we won't deliberately restrict
>LAN size scalability unless we run into issues that require it and
>we won't specify anything more than "MUST work for LANs of a size
>at least as great as can be accomplished using 802.1 bridges."
>
>  
>
This ("as great as using 802.1 bridges2) perhaps is not very precise.... 
The target of 100.000
hosts is clear,  aggresive enough  and allows scalability evaluation of 
the solutions.
My opinion is that introducing additional functionality and complexity 
like Rbridges in campuses
should provide some  extra benefits, allowing larger network sizes. If 
we keep current network
sizes as target, then the problem statement is just to replace so called 
switching routers or multilayer switches
 and the like with  an hybrid device using MAC routing, withina a single 
IP subnet.  

>I believe this is consistent with what we've all been saying, but I
>am open to the possibility that I may have misunderstood someone,
>somewhere along the line...
>
>--
>Eric
>
>--- [SNIP] ---
>
>--> 
>--> >> --> if not, then can there be broadcast storms?
>--> >>
>--> >> Certainly not worse than currently, except to the extent that
>--> >> an RBridge campus enhanced broadcast domain _might_ be larger.
>--> 
>--> Eric - is this just saying that someone may want to try for 100,000 MAC 
>--> addresses in one RBRIDGE campus? Or did you mean more than this?
>--> 
>--> >> --> if not, then will broadcast be supported?
>--> >> -->
>--> >>
>--- [SNIP] --- 
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

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



Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBG9ZNe22334 for <[e-mail]>; Fri, 16 Dec 2005 01:35:24 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1C5BA9EF1B for <[e-mail]>; Fri, 16 Dec 2005 10:35:18 +0100 (CET)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp01.uc3m.es (Postfix) with ESMTP id 48BA99EF14 for <[e-mail]>; Fri, 16 Dec 2005 10:35:17 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 10:35:17 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 09:36:02 -0000
Status: RO
Content-Length: 3895

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Gray, Eric wrote:
>  
>
>>Joe,
>>
>>	We're getting closer, maybe, on this one.  Please
>>see below...
>>
>>__
>>Eric
>>
>>--> -----Original Message-----
>>--> From: Joe Touch [mailto:[e-mail]] 
>>--> Sent: Thursday, December 15, 2005 12:11 PM
>>--> To: Gray, Eric
>>--> Cc: [e-mail]; 'Developing a hybrid router/bridge.'
>>--> Subject: Re: [rbridge] it's time to summarize things
>>--> 
>>--> 
>>--> 
>>--> Gray, Eric wrote:
>>--> > Joe,
>>--> > 
>>--> > 	I've addressed this issue before, just as you have
>>--> > raised it before.
>>--> > 
>>--> > 	Assuming that "external nodes" below refers to the
>>--> > portions of the L2 broadcast domain that are topologically
>>--> > outside of the RBridge campus, the RBridge campus actually
>>--> > looks to external nodes as if it is a (possibly largish)
>>--> > collection of L2 frame sources and sinks.
>>--> 
>>--> For internal traffic, sure. For ingress/egress traffic, 
>>--> this would need to hijack ARP to work.
>>--> 
>>
>>Why?  ARP, at least the ARP I am familiar with, allows for the
>>conversion of an IP address into a LAN-local MAC address (much
>>the same as DNS allows for conversion of a network name into an
>>IP address).
>>
>>The RBridge campus forwards ARP - just as the local and remote 
>>LAN segments do - and the appropriate entity (an L2 source/sink
>>such as a router or host) responds.  Why would RBridges care
>>about - or interfer with - ARP?
>>    
>>
>
>Because somehow the traffic from external nodes needs to arrive at
>ingresses. Ingresses don't have (or at least don't use) external
>addresses; the traffic from external nodes needs to arrive at ingresses
>based on the external spanning trees, NOT based on being addressed to
>ingresses.
>
>In fact, there is NO external traffic that should ever be directed at an
>ingress address - thus I believe that rbridge campuses do not
>participate in ARP. That is a substantial difference from a router,
>which DO participate in ARP.
>  
>
My understanding was that Rbridges would do ARP proxying and would 
forward ARP requests to other Rbridges. Am I still right?.

>Which means that the rbridge campus does NOT look like a collection of
>sources and sinks to external devices w.r.t. ingress/egress traffic. The
>only aspect in which rbridges DO look like conventional sources/sinks is
>for internal traffic.
>
>  
>
>>--> To external nodes, the rbridge MUST act like a transit, not 
>>--> a source or sink.
>>-->
>>
>>I think we're in agreement here.  My statement was as to how the
>>RBridge campus "appears" to the rest of the network.  Yours is to 
>>how an RBridge campus "acts."
>>    
>>
>
>I'm confused about the difference. If all you mean by source/sink is
>'traffic goes in that direction', then you're talking about
>upstream/downstream channels, not sources or sinks. IMO, a source/sink
>appears as a source/destination in a packet haeader, and (I now think we
>agree) that never happens for ingress/egress traffic.
>
>  
>
>>Obviously the campus does not "act" like a source or sink.  If it
>>did, it would be a gibbering black-hole.  It merely appears like
>>a collection of sources or sinks to external nodes.
>>    
>>
>
>I'm not sure how that description is useful. Can you explain how?
>
>Joe
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDob2UE5f5cImnZrsRAsUaAJ44nwX7pA7yBDIGpwXKPtkcZA0kaACeNyeg
>hco5aPY+Wji9vTw8f94UCnU=
>=nqbN
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

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



Received: from netcore.fi (netcore.fi [193.94.160.1]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBG6oPe15066 for <[e-mail]>; Thu, 15 Dec 2005 22:50:25 -0800 (PST)
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jBG6oIL29929 for <[e-mail]>; Fri, 16 Dec 2005 08:50:18 +0200
Date: Fri, 16 Dec 2005 08:50:18 +0200 (EET)
From: Pekka Savola <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 06:50:55 -0000
Status: RO
Content-Length: 236

That's one darned big and convoluted summary.

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


Received: from alva.home (dsl092-066-146.bos1.dsl.speakeasy.net [66.92.66.146]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBG1Cse23365 for <[e-mail]>; Thu, 15 Dec 2005 17:12:54 -0800 (PST)
Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1En49I-0005TS-00; Thu, 15 Dec 2005 20:12:40 -0500
From: Tim Shepard <[e-mail]>
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
In-reply-to: Your message of Thu, 15 Dec 2005 19:10:52 -0500. <[e-mail]> 
Date: Thu, 15 Dec 2005 20:12:40 -0500
Message-Id: <[e-mail]>
Sender: Tim Shepard <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 01:13:54 -0000
Status: RO
Content-Length: 123

> Hope this helps.

Yes, that helps.  Thanks.   I should have looked in the draft.

			-Tim Shepard
			 [e-mail]


Received: from stag.seas.upenn.edu (stag.seas.upenn.edu [158.130.70.79]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBG08ve04643 for <[e-mail]>; Thu, 15 Dec 2005 16:08:58 -0800 (PST)
Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by stag.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id jBG08tkj010917 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 15 Dec 2005 19:08:56 -0500
Message-Id: <[e-mail]>
From: "Saikat Ray" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 15 Dec 2005 19:10:52 -0500
Organization: University of Pennsylvania
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
thread-index: AcYB0ZjM5LDeiiAPRc2LesIqKh8qnQAAeKVg
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] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2005 00:09:56 -0000
Status: RO
Content-Length: 2896

The simplest, if not the most rigorous, explanation is as follows. Replace
each legacy part of the network by a hub (i.e., first remove all RBridges
from the topology. Then choose a legacy bridge and replace this bridge and
all legacy bridges that have a path to it by a single hub, and let all
end-hosts served by those legacy bridges be connected to this hub. Repeat
this procedure until all legacy bridges are replaced. Then finally put the
RBridges back.). Now, one and only one RBridge forwards and receives
unencapsulated packets from each hub (through designated RBridge). Thus for
a loop formation, a packet must loop back to a designated RBridge, which is
not possible since RBridges use their own spanning tree for sending
(encapsulated) broadcast traffic.

Hope this helps.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Tim Shepard
> Sent: Thursday, December 15, 2005 6:42 PM
> To: Developing a hybrid router/bridge.
> Cc: [e-mail]; 'Joe Touch'
> Subject: Re: [rbridge] it's time to summarize things
> 
> 
> > Let us suppose that an RBridge is connected to a legacy bridge's port
> > directly, and all RBridges block BPDUs. Then the RBridge looks like,
> from
> > the perspective of the legacy brige, either (i) a single end-host (with
> the
> > MAC address that of the RBridge) if the RBridge is not the designated
> > RBridge, or (ii) a shared media (like a hub; is the standard term
> > "segment"?) with potentially a lot of MAC addresses attached to it (in
> fact,
> [....]
> > So what exactly do you think is the problem with ARP?
> 
> 
> I'm not sure I follow all of the postings on this issue.
> 
> But after reading through this thread, I'm still left wondering what
> is supposed to make sure packets don't loop forever when there are a
> mix of bridges and rbridges plugged together (in some crazy accidental
> way, creating whatever kind of loop involving bridges and rbridges
> that causes the most trouble).
> 
> It seems to me that if rbridges block the spanning tree forming
> packets, but do forward (e.g.) ARP traffic, then there could be loops
> that are not broken by either the rbridge system or the usual bridge
> spanning-tree-forming algorithm.
> 
> Could someone explain succinctly (for someone who is just barely
> following this thread) how a system (of mixed bridges and rbridges,
> plugged together by some Byzantine net admin) will ensure that packets
> are not forwarded in a loop?
> 
> (And ARP is a good example, since it is supposed to go everywhere, but
> not loop.)
> 
> 
> Or will there be configuration rules that forbid some ways of plugging
> together bridges and rbridges?
> 
> 			-Tim Shepard
> 			 [e-mail]
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge



Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFNkNe27681 for <[e-mail]>; Thu, 15 Dec 2005 15:46:23 -0800 (PST)
Received: from s73602 (unknown[65.104.224.98]) by comcast.net (sccrmhc14) with SMTP id <20051215234617014002bj6ce>; Thu, 15 Dec 2005 23:46:17 +0000
Message-ID: <026a01c601d1$a1478790$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Thu, 15 Dec 2005 17:45:28 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 23:47:40 -0000
Status: RO
Content-Length: 2993

Eric and Joe,

Ack.

And thanks for laying it out this way.

Spencer


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Agreed.... with the caveat below
>
> Gray, Eric wrote:
>> Spencer,
>>
>> In the WG charter, it stipulates the following as
>> design goals:
>>
>> - Minimal or no configuration required
>> - Load-splitting among multiple paths
>> - Routing loop mitigation (possibly through a TTL field)
>> - Support of multiple points of attachment
>> - Support for broadcast and multicast
>> - No significant service delay after attachment
>> - No less secure than existing bridged solutions
>>
>> Note that this list does not include "Support for a larger broadcast
>> domain."
>>
>> However, if we can make layer 2 networking more efficient - thereby
>> overcoming some of the issues that limit current workable maximum
>> LAN size - we will most likely see LAN sizes increase again until
>> they are approaching a new maximum size.
>>
>> This is less a goal, then a probable outcome.  It is hard to state
>> "LAN sizes will increase until they work about as poorly as they do
>> now" as a goal - at least while keeping a straight face.
>>
>> While I think we can all agree - at least in principle - that it is
>> probably not desirable to deliberately put cruft into the protocol
>> to prevent this from happening, I don't think we can get rock solid
>> consensus as to how much larger we might want to target.  I think
>> the given goals are aggressive enough.
>>
>> So, I would argue for this position: we won't deliberately restrict
>> LAN size scalability unless we run into issues that require it and
>> we won't specify anything more than "MUST work for LANs of a size
>> at least as great as can be accomplished using 802.1 bridges."
>>
>> I believe this is consistent with what we've all been saying, but I
>> am open to the possibility that I may have misunderstood someone,
>> somewhere along the line...
>
> FWIW, this is basically what the current PAS states, though some have
> raised it as a possible concern.
>
> Joe
>
>>
>> --
>> Eric
>>
>> --- [SNIP] ---
>>
>> -->
>> --> >> --> if not, then can there be broadcast storms?
>> --> >>
>> --> >> Certainly not worse than currently, except to the extent that
>> --> >> an RBridge campus enhanced broadcast domain _might_ be larger.
>> -->
>> --> Eric - is this just saying that someone may want to try for 100,000 
>> MAC
>> --> addresses in one RBRIDGE campus? Or did you mean more than this?
>> -->
>> --> >> --> if not, then will broadcast be supported?
>> --> >> -->
>> --> >>
>> --- [SNIP] --- 
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://www.postel.org/mailman/listinfo/rbridge
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFDofPWE5f5cImnZrsRAqWgAKCLZu4u/kG6rHRd47aXTAPeA9sjHACdF5MN
> r4wQKmB85gf/RGEG7ElV9gg=
> =vcJf
> -----END PGP SIGNATURE----- 



Received: from alva.home (dsl092-066-146.bos1.dsl.speakeasy.net [66.92.66.146]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFNgAe26443 for <[e-mail]>; Thu, 15 Dec 2005 15:42:10 -0800 (PST)
Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1En2jb-0005Op-00; Thu, 15 Dec 2005 18:42:03 -0500
From: Tim Shepard <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-reply-to: Your message of Thu, 15 Dec 2005 14:38:02 -0500. <[e-mail]> 
Date: Thu, 15 Dec 2005 18:42:03 -0500
Message-Id: <[e-mail]>
Sender: Tim Shepard <[e-mail]>
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] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 23:42:55 -0000
Status: RO
Content-Length: 1573

> Let us suppose that an RBridge is connected to a legacy bridge's port
> directly, and all RBridges block BPDUs. Then the RBridge looks like, from
> the perspective of the legacy brige, either (i) a single end-host (with the
> MAC address that of the RBridge) if the RBridge is not the designated
> RBridge, or (ii) a shared media (like a hub; is the standard term
> "segment"?) with potentially a lot of MAC addresses attached to it (in fact,
[....]
> So what exactly do you think is the problem with ARP?


I'm not sure I follow all of the postings on this issue.

But after reading through this thread, I'm still left wondering what
is supposed to make sure packets don't loop forever when there are a
mix of bridges and rbridges plugged together (in some crazy accidental
way, creating whatever kind of loop involving bridges and rbridges
that causes the most trouble).

It seems to me that if rbridges block the spanning tree forming
packets, but do forward (e.g.) ARP traffic, then there could be loops
that are not broken by either the rbridge system or the usual bridge
spanning-tree-forming algorithm.

Could someone explain succinctly (for someone who is just barely
following this thread) how a system (of mixed bridges and rbridges,
plugged together by some Byzantine net admin) will ensure that packets
are not forwarded in a loop?

(And ARP is a good example, since it is supposed to go everywhere, but
not loop.)


Or will there be configuration rules that forbid some ways of plugging
together bridges and rbridges?

			-Tim Shepard
			 [e-mail]


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFN3le14341; Thu, 15 Dec 2005 15:03:47 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 15 Dec 2005 15:03:48 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 23:08:16 -0000
Status: RO
Content-Length: 4993

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

See below...

> Joe,
> 
> 	Please see below...
> 
> --
> Eric 
> 
> --> -----Original Message-----
> --> From: Joe Touch [mailto:[e-mail]] 
> --> Sent: Thursday, December 15, 2005 2:02 PM
> --> To: Gray, Eric
> --> Cc: [e-mail]; 'Developing a hybrid router/bridge.'
> --> Subject: Re: [rbridge] it's time to summarize things
> --> 
> --> -----BEGIN PGP SIGNED MESSAGE-----
> --> Hash: SHA1
> --> 
> --> 
> --> 
> --> Gray, Eric wrote:
> --> > Joe,
> --> > 
> --> > 	We're getting closer, maybe, on this one.  Please
> --> > see below...
> --> > 
> --> > __
> --> > Eric
> --> > 
> --> > --> -----Original Message-----
> --> > --> From: Joe Touch [mailto:[e-mail]] 
> --> > --> Sent: Thursday, December 15, 2005 12:11 PM
> --> > --> To: Gray, Eric
> --> > --> Cc: [e-mail]; 'Developing a hybrid 
> --> router/bridge.'
> --> > --> Subject: Re: [rbridge] it's time to summarize things
> --> > --> 
> --> > --> 
> --> > --> 
> --> > --> Gray, Eric wrote:
> --> > --> > Joe,
> --> > --> > 
> --> > --> > 	I've addressed this issue before, just as you have
> --> > --> > raised it before.
> --> > --> > 
> --> > --> > 	Assuming that "external nodes" below refers to the
> --> > --> > portions of the L2 broadcast domain that are topologically
> --> > --> > outside of the RBridge campus, the RBridge campus actually
> --> > --> > looks to external nodes as if it is a (possibly largish)
> --> > --> > collection of L2 frame sources and sinks.
> --> > --> 
> --> > --> For internal traffic, sure. For ingress/egress traffic, 
> --> > --> this would need to hijack ARP to work.
> --> > --> 
> --> > 
> --> > Why?  ARP, at least the ARP I am familiar with, allows for the
> --> > conversion of an IP address into a LAN-local MAC address (much
> --> > the same as DNS allows for conversion of a network name into an
> --> > IP address).
> --> > 
> --> > The RBridge campus forwards ARP - just as the local and remote 
> --> > LAN segments do - and the appropriate entity (an L2 source/sink
> --> > such as a router or host) responds.  Why would RBridges care
> --> > about - or interfer with - ARP?
> --> 
> --> Because somehow the traffic from external nodes needs to arrive at
> --> ingresses. Ingresses don't have (or at least don't use) external
> --> addresses; the traffic from external nodes needs to arrive at ingresses
> --> based on the external spanning trees, NOT based on being addressed to
> --> ingresses.
> --> 
> 
> You are confusing STP with bridge learning - not even close to 
> the same thing.

Spanning trees and bridge learning together (otherwise it won't get to
the ingress more than one bridge away).
...

> --> In fact, there is NO external traffic that should ever be directed
> --> at an ingress address - thus I believe that rbridge campuses do not
> --> participate in ARP. That is a substantial difference from a router,
> --> which DO participate in ARP.
> --> 
> 
> Again, you're being to litteral.

If we're correcting spelling, it's "literal". ;-)

The rest of this line is based on the assumption that "source/sink"
means source/destination address, which we agree it does not as you were
using it. So it seems moot - we agree, I think.
...

> --> > Obviously the campus does not "act" like a source or sink.  If it
> --> > did, it would be a gibbering black-hole.  It merely appears like
> --> > a collection of sources or sinks to external nodes.
> --> 
> --> I'm not sure how that description is useful. Can you explain how?
> 
> Hopefully I have.  I did this earlier too, and thought it
> had taken, but here we are going through it again.  
> 
> I invite your attention to my E-Mail on the subject of 
> "RBridge/bridge interaction", dated Fri 10/21/2005 2:59 PM.

It was Guillermo who introduced the terms source and sink in all
messages from you on that date, in his note from 10/20/2005,
Message-ID: <[e-mail]>

In that text, the terms SOURCE/SINK were in reference to the BPDUs, not
other L2 packets to be sourced or sunk. His description there matches
more of what I consider a version of "PARTICIPATE", i.e.,:

			incoming BPDUs		outgoing BPDUs
			(to the rbridge)	(emitted by the rbridge)

BLOCK			silently sink		never source

PARTICIPATE-bridge	accept as if 1 bridge	emit as if 1 bridge
(compute what is emitted as if the entire campus is a single bridge)

PARTICIPATE-root	accept as if root	emit as if root
(Guillermo's suggestion, the one that I think BLOCK really maps to,
and which assumes election to root; I would prefer PARTICIPATE-bridge
that behaves this way ONLY if election is won)

TRANSPARENT		accept and ->		send a copy to all
						ports except the one
						the BPDU enters



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

iD8DBQFDofZUE5f5cImnZrsRAoqGAJ9DQh5vm4a65UWW3Kz0IbMrGmljAQCgu6x8
bQU89YnqNLFMFmK/i5L8ChE=
=vi82
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFMrAe11101; Thu, 15 Dec 2005 14:53:10 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 15 Dec 2005 14:53:10 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 22:54:05 -0000
Status: RO
Content-Length: 2838

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

Agreed.... with the caveat below

Gray, Eric wrote:
> Spencer,
> 
> 	In the WG charter, it stipulates the following as
> design goals:
> 
> - Minimal or no configuration required
> - Load-splitting among multiple paths
> - Routing loop mitigation (possibly through a TTL field)
> - Support of multiple points of attachment
> - Support for broadcast and multicast
> - No significant service delay after attachment
> - No less secure than existing bridged solutions
> 
> Note that this list does not include "Support for a larger broadcast
> domain."
> 
> However, if we can make layer 2 networking more efficient - thereby
> overcoming some of the issues that limit current workable maximum
> LAN size - we will most likely see LAN sizes increase again until
> they are approaching a new maximum size.
> 
> This is less a goal, then a probable outcome.  It is hard to state
> "LAN sizes will increase until they work about as poorly as they do
> now" as a goal - at least while keeping a straight face.  
> 
> While I think we can all agree - at least in principle - that it is
> probably not desirable to deliberately put cruft into the protocol
> to prevent this from happening, I don't think we can get rock solid
> consensus as to how much larger we might want to target.  I think
> the given goals are aggressive enough.
> 
> So, I would argue for this position: we won't deliberately restrict
> LAN size scalability unless we run into issues that require it and
> we won't specify anything more than "MUST work for LANs of a size
> at least as great as can be accomplished using 802.1 bridges."
> 
> I believe this is consistent with what we've all been saying, but I
> am open to the possibility that I may have misunderstood someone,
> somewhere along the line...

FWIW, this is basically what the current PAS states, though some have
raised it as a possible concern.

Joe

> 
> --
> Eric
> 
> --- [SNIP] ---
> 
> --> 
> --> >> --> if not, then can there be broadcast storms?
> --> >>
> --> >> Certainly not worse than currently, except to the extent that
> --> >> an RBridge campus enhanced broadcast domain _might_ be larger.
> --> 
> --> Eric - is this just saying that someone may want to try for 100,000 MAC 
> --> addresses in one RBRIDGE campus? Or did you mean more than this?
> --> 
> --> >> --> if not, then will broadcast be supported?
> --> >> -->
> --> >>
> --- [SNIP] --- 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDofPWE5f5cImnZrsRAqWgAKCLZu4u/kG6rHRd47aXTAPeA9sjHACdF5MN
r4wQKmB85gf/RGEG7ElV9gg=
=vcJf
-----END PGP SIGNATURE-----


Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.77.83]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFMOAe01858 for <[e-mail]>; Thu, 15 Dec 2005 14:24:10 -0800 (PST)
Received: from s73602 (unknown[65.104.224.98]) by comcast.net (sccrmhc13) with SMTP id <2005121522240401300o1b4ae>; Thu, 15 Dec 2005 22:24:04 +0000
Message-ID: <023301c601c6$251c93a0$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]><006201c601ba$6193f870$[e-mail]> <[e-mail]>
Date: Thu, 15 Dec 2005 16:23:15 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 22:24:53 -0000
Status: RO
Content-Length: 506

"Snort"... Hilarious.

>>>Understood, at least assuming the BLOCK and PARTICIPATE cases. For
>>>TRANSPARENT, this is still correct.
>>
>> I agree with this also, which is one of the things that bothers me about
>> TRANSPARENT.
>
> Presumably you would agree with the corrected version (agreed for BLOCK
> and TRANSPARENT, but not PARTICIPATE)?
>
> Joe

I was reading as fast as you were typing, apparently. I misread the question 
completely, so wasn't even answering the same question.

Sorry!

Spencer 



Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFM2Me20201; Thu, 15 Dec 2005 14:02:22 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 15 Dec 2005 14:02:23 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <006201c601ba$6193f870$[e-mail]>
In-Reply-To: <006201c601ba$6193f870$[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 22:04:36 -0000
Status: RO
Content-Length: 2438

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



Spencer Dawkins wrote:
> Eric and Joe,
> 
> You guys are having a great time, but this may be a good opportunity for a 
> "me, too", building towards the day when Erik tries to figure out what 
> consensus looks like ...
> 
> 
>>>--> If a campus is not "like" either a bridge or a hub, someone needs to
>>>--> describe what it does - either in terms of another viable L2 analog,
>>>--> or in terms of how it interacts with each level of protocol:
> 
> My understanding is "like a router that only has MAC addresses in its 
> routing and forwarding tables".

Routers have other things:
	- for multipoint L2s, their interfaces have MAC addresses
	- they also have IP addresses
		even those with unnumbered (at L3) interfaces
		have a router ID number

All these addresses are externaly visible and used by nodes on the LAN
to address things TO the router's ingress.

What are the equivalent addresses here?

We already have an L2 device that works just like a router (at least
internally), lacking interface MAC addresses but possessing a node ID
MAC address - it's called a bridge. That's why I keep thinking of this
as being one large bridge. Because that's what "like a router that only
has MAC addresses in its routing and forwarding tables" _IS_. The
difference is that we're 'peeking inside' the bridge to talk about the
rbridge components and how they interconnect...

>>>--> - do external nodes address traffic to the ingress?
>>>--> I have been assuming NO.
>>>
>>>That is correct.
> 
> 
> I agree ("correct").
> 
> 
>>>--> if they do, then a lot of protocols are affected
>>>--> and need modification and/or proxying.
>>>-->
>>>--> - do external bridges address traffic to rbridges?
>>>--> (basically BPDUs)
>>>--> I have been assuming YES.
>>>
>>>That is incorrect.
> 
> 
> I agree (with "incorrect").
> 
> 
>>Understood, at least assuming the BLOCK and PARTICIPATE cases. For
>>TRANSPARENT, this is still correct.
> 
> I agree with this also, which is one of the things that bothers me about 
> TRANSPARENT.

Presumably you would agree with the corrected version (agreed for BLOCK
and TRANSPARENT, but not PARTICIPATE)?

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

iD8DBQFDoefvE5f5cImnZrsRAmv2AJ9DqiLvQgyJ5Yn32JJvbGjNh0hNtgCfdZ4x
IdAeZmcqA0LdSCxvaRZ5jLA=
=ngIe
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFM1de20143 for <[e-mail]>; Thu, 15 Dec 2005 14:01:40 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBFM1PdJ025244; Thu, 15 Dec 2005 17:01:26 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA17485;  Thu, 15 Dec 2005 17:01:25 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BL340Q>; Thu, 15 Dec 2005 17:01:25 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Spencer Dawkins'" <[e-mail]>
Date: Thu, 15 Dec 2005 17:01:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 22:02:39 -0000
Status: RO
Content-Length: 2116

Spencer,

	In the WG charter, it stipulates the following as
design goals:

- Minimal or no configuration required
- Load-splitting among multiple paths
- Routing loop mitigation (possibly through a TTL field)
- Support of multiple points of attachment
- Support for broadcast and multicast
- No significant service delay after attachment
- No less secure than existing bridged solutions

Note that this list does not include "Support for a larger broadcast
domain."

However, if we can make layer 2 networking more efficient - thereby
overcoming some of the issues that limit current workable maximum
LAN size - we will most likely see LAN sizes increase again until
they are approaching a new maximum size.

This is less a goal, then a probable outcome.  It is hard to state
"LAN sizes will increase until they work about as poorly as they do
now" as a goal - at least while keeping a straight face.  

While I think we can all agree - at least in principle - that it is
probably not desirable to deliberately put cruft into the protocol
to prevent this from happening, I don't think we can get rock solid
consensus as to how much larger we might want to target.  I think
the given goals are aggressive enough.

So, I would argue for this position: we won't deliberately restrict
LAN size scalability unless we run into issues that require it and
we won't specify anything more than "MUST work for LANs of a size
at least as great as can be accomplished using 802.1 bridges."

I believe this is consistent with what we've all been saying, but I
am open to the possibility that I may have misunderstood someone,
somewhere along the line...

--
Eric

--- [SNIP] ---

--> 
--> >> --> if not, then can there be broadcast storms?
--> >>
--> >> Certainly not worse than currently, except to the extent that
--> >> an RBridge campus enhanced broadcast domain _might_ be larger.
--> 
--> Eric - is this just saying that someone may want to try for 100,000 MAC 
--> addresses in one RBRIDGE campus? Or did you mean more than this?
--> 
--> >> --> if not, then will broadcast be supported?
--> >> -->
--> >>
--- [SNIP] --- 


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFLdxe11764; Thu, 15 Dec 2005 13:39:59 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 15 Dec 2005 13:40:00 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 21:41:28 -0000
Status: RO
Content-Length: 895

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



Gray, Eric wrote:
> Joe,
> 
> 	Just to clarify, see comment/question below...
> 
> --
> Eric
> 
> --> > --> 
> --> > --> 	- do external bridges address traffic to rbridges?
> --> > --> 	(basically BPDUs)
> --> > --> 		I have been assuming YES.
> --> > 
> --> > That is incorrect.
> --> 
> --> Understood, at least assuming the BLOCK and PARTICIPATE cases. For
> --> TRANSPARENT, this is still correct.
> --> 
> 
> 	I think you meant to say:
> 
> --> Understood, at least assuming the BLOCK and TRANSPARENT cases. For
> --> PARTICIPATE, this is still correct.


Agreed (sorry; long day).

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

iD8DBQFDoeKwE5f5cImnZrsRAuBdAJ4sR0S4Dx3mICbHf95pGy0/TOrMwACcDS4u
xiR+HIGdvOgiCbeZRU2G0uc=
=yOjY
-----END PGP SIGNATURE-----


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 jBFLZge10328 for <[e-mail]>; Thu, 15 Dec 2005 13:35:42 -0800 (PST)
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 Dec 2005 16:35:37 -0500
X-IronPort-AV: i="3.99,258,1131339600";  d="scan'208"; a="77823160:sNHT29800348"
Received: from RussPC (rtp-vpn1-181.cisco.com [10.82.224.181]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBFLZXUS027691;  Thu, 15 Dec 2005 16:35:34 -0500 (EST)
Received: from [127.0.0.1] by RussPC (PGP Universal service); Thu, 15 Dec 2005 16:35:34 -0500
X-PGP-Universal: processed; by RussPC on Thu, 15 Dec 2005 16:35:34 -0500
Message-ID: <[e-mail]>
Date: Thu, 15 Dec 2005 16:35:27 -0500
From: Russ White <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Type: text/plain; charset="UTF-8"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 21:35:59 -0000
Status: RO
Content-Length: 500

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


> So being an rbridge breaks broadcast, so ARP, DHCP, etc. won't work.

As long as a broadcast or multicast can be described as an L2 
destination an rbridge will understand, it doesn't break anything.

:-)

Russ

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


-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.3 (Build 2932)

iQA/AwUBQ6HhphEdu7FIVPTkEQLv/QCgnrbd19bQctyAcW7ijIfTK6NB0AQAn2IL
gv2Kc+88Ob4j0tOuE3Z5srFl
=8yIY
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFL2Te14239 for <[e-mail]>; Thu, 15 Dec 2005 13:02:29 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBFL2CdJ024152; Thu, 15 Dec 2005 16:02:12 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA10181;  Thu, 15 Dec 2005 16:02:12 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BL3S9B>; Thu, 15 Dec 2005 16:02:11 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Joe Touch'" <[e-mail]>
Date: Thu, 15 Dec 2005 16:02:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 21:02:56 -0000
Status: RO
Content-Length: 497

Joe,

	Just to clarify, see comment/question below...

--
Eric

--> > --> 
--> > --> 	- do external bridges address traffic to rbridges?
--> > --> 	(basically BPDUs)
--> > --> 		I have been assuming YES.
--> > 
--> > That is incorrect.
--> 
--> Understood, at least assuming the BLOCK and PARTICIPATE cases. For
--> TRANSPARENT, this is still correct.
--> 

	I think you meant to say:

--> Understood, at least assuming the BLOCK and TRANSPARENT cases. For
--> PARTICIPATE, this is still correct.


Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [63.240.77.81]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFL0Ve13705 for <[e-mail]>; Thu, 15 Dec 2005 13:00:31 -0800 (PST)
Received: from s73602 (unknown[65.104.224.98]) by comcast.net (sccrmhc11) with SMTP id <20051215205951011004ncm7e>; Thu, 15 Dec 2005 20:59:51 +0000
Message-ID: <006201c601ba$6193f870$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Thu, 15 Dec 2005 14:59:02 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 21:00:54 -0000
Status: RO
Content-Length: 2392

Eric and Joe,

You guys are having a great time, but this may be a good opportunity for a 
"me, too", building towards the day when Erik tries to figure out what 
consensus looks like ...

>> --> If a campus is not "like" either a bridge or a hub, someone needs to
>> --> describe what it does - either in terms of another viable L2 analog,
>> --> or in terms of how it interacts with each level of protocol:

My understanding is "like a router that only has MAC addresses in its 
routing and forwarding tables".

>> --> - do external nodes address traffic to the ingress?
>> --> I have been assuming NO.
>>
>> That is correct.

I agree ("correct").

>> --> if they do, then a lot of protocols are affected
>> --> and need modification and/or proxying.
>> -->
>> --> - do external bridges address traffic to rbridges?
>> --> (basically BPDUs)
>> --> I have been assuming YES.
>>
>> That is incorrect.

I agree (with "incorrect").

> Understood, at least assuming the BLOCK and PARTICIPATE cases. For
> TRANSPARENT, this is still correct.

I agree with this also, which is one of the things that bothers me about 
TRANSPARENT.

>> --> if not, then how do bridges know to forward
>> --> traffic to the ingresses?
>>
>> The same way they always do.  That is, they learn about the
>> MAC addresses from traffic they see coming from the direction
>> of the RBridge campus, so they know to forward traffic with
>> a MAC DA toward the MAC SA they've learned earlier.
>>
>> This is what makes the RBridge campus look like a collection
>> of MAC sources/sinks on a common Ethernet link.
>>
>> Naturally, the process will be (as usual in 802.1 networks)
>> "primed" by either by broadcast (e.g. ARP) or by flooding.
>
> Agreed.

I agree (with "Agreed").

>> --> if not, then can there be broadcast storms?
>>
>> Certainly not worse than currently, except to the extent that
>> an RBridge campus enhanced broadcast domain _might_ be larger.

Eric - is this just saying that someone may want to try for 100,000 MAC 
addresses in one RBRIDGE campus? Or did you mean more than this?

>> --> if not, then will broadcast be supported?
>> -->
>>
>> Yes, of course.
>>

I agree (with "Yes, of course").

>> -->
>> --> (this is not necessarily a complete list, but it's a start;
>> --> anyone want to answer it?)
>>
>> Many people probably could.  What about somebody else?

Hope this helps! Others?

Spencer 



Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFKeee07989; Thu, 15 Dec 2005 12:40:40 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 15 Dec 2005 12:40:41 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 20:41:24 -0000
Status: RO
Content-Length: 5834

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



Gray, Eric wrote:
> Joe,
> 
> 	We may be closer on this one too.  Again, please see
> below...
> 
> --
> Eric 
> 
> 
> --> 
> --> Gray, Eric wrote:
> --> > Joe,
> --> > 
> --> > 	Taking things too litterally - so as to make them seem
> --> > ridiculous - is an argument style, not a communication skill.
> --> > Are we arguing to a purpose, or are we trying to communicate?
> --> > 
> --> > 	The phrase "like being a router" is a very far cry from 
> --> > "being exactly like a router", and the phrase "the destination 
> --> > is a layer 2 address rather than an IP address" implies a lot 
> --> > of things about the differences between a router and an RBridge.
> --> 
> --> Agreed, but it has already proven useful in eliciting the idea 
> --> that rbridges have external addresses that external hosts know 
> --> about (which I disagree with).
> 
> I think I know how you got this interpretation out of what was
> said, but it is an incorrect interpretation.
> 
> When saying "the destination is a layer 2 address rather than an IP 
> address" the routing analog is fairly accurate.  That is, instead
> of routing based on IP addresses, routing is based on layer 2 (MAC)
> addresses.
> 
> In the same way that the IP address for the local router is usually
> not used in forwarding IP traffic (unless the traffic is destined
> for the router), RBridge addresses are not typically used to forward 
> layer 2 traffic to non-RBridge destinations.  One key exception to
> this is when forwarding traffic using tunneling encapsulation from
> one RBridge to another.

Agreed.

> Hosts in a common broadcast domain containing an RBridge campus are
> not aware of the RBridge campus.  Same for routers and for routers
> and hosts talking to each other.
> 
> Consequently, there is nothing to disagree with here.

That's good.

> --> I have been very specific about the idea of being "like a bridge" or
> --> "like a hub"; it allows me to encapsulate a lot of rules about what 
> --> the campus would do, w.r.t. nodes, bridges, etc.
> --> 
> --> If a campus is not "like" either a bridge or a hub, someone needs to
> --> describe what it does - either in terms of another viable L2 analog,
> --> or in terms of how it interacts with each level of protocol:
> --> 
> --> 	- do external nodes address traffic to the ingress?
> --> 		I have been assuming NO.
> 
> That is correct.
> 
> --> 		if they do, then a lot of protocols are affected
> --> 		and need modification and/or proxying.
> --> 
> --> 	- do external bridges address traffic to rbridges?
> --> 	(basically BPDUs)
> --> 		I have been assuming YES.
> 
> That is incorrect.

Understood, at least assuming the BLOCK and PARTICIPATE cases. For
TRANSPARENT, this is still correct.

> --> 		if not, then how do bridges know to forward
> --> 		traffic to the ingresses?
> 
> The same way they always do.  That is, they learn about the
> MAC addresses from traffic they see coming from the direction
> of the RBridge campus, so they know to forward traffic with
> a MAC DA toward the MAC SA they've learned earlier.
> 
> This is what makes the RBridge campus look like a collection
> of MAC sources/sinks on a common Ethernet link.
> 
> Naturally, the process will be (as usual in 802.1 networks) 
> "primed" by either by broadcast (e.g. ARP) or by flooding.

Agreed.

> --> 		if not, then can there be broadcast storms?
> 
> Certainly not worse than currently, except to the extent that
> an RBridge campus enhanced broadcast domain _might_ be larger.
> 
> --> 		if not, then will broadcast be supported?
> -->
> 
> Yes, of course.
> 
> --> 
> --> (this is not necessarily a complete list, but it's a start; 
> --> anyone want to answer it?)
> 
> Many people probably could.  What about somebody else?

OK - the answer to that list will help. IMO, the key for BLOCK is that
it's isomorphic to "PARTICIPATE as the root bridge" AFIACT. If not, then
what's the difference?

So far, all I can tell is that BLOCK means the campus as a whole will
"act like it's been elected root bridge" without having such an
election. That sounds unnecessarily dangerous to assume to me.

Joe

> 
> --> 
> --> Joe
> --> 
> --> > 
> --> > --
> --> > Eric
> --> > 
> --> > --> Routers do NOT propagate broadcasts at either L2 or L3.
> --> > --> 
> --> > --> So being an rbridge breaks broadcast, so ARP, DHCP, etc. won't
> work.
> --> > --> 
> --> > --> Joe
> --> > -->
> --> > --> Gray, Eric wrote:
> --> > --> Radia,
> --> > -->  
> --> > --> 	Very well put.
> --> > --> 
> --> > --> --> Being an RBridge is really like being a router, but the
> --> > --> --> destination is a layer 2 address rather than an IP address.
> --> > --> --> 
> --> > --> --> Radia
> --> > --> --> 
> --> > --> 
> --> > --> --
> --> > --> Eric
> --> > --> _______________________________________________
> --> > --> rbridge mailing list
> --> > --> [e-mail]
> --> > --> http://www.postel.org/mailman/listinfo/rbridge
> --> > 
> --> > --> -----Original Message-----
> --> > --> From: [e-mail] 
> --> > --> [mailto:[e-mail]] On Behalf Of Joe Touch
> --> > --> Sent: Thursday, December 15, 2005 11:08 AM
> --> > --> To: Developing a hybrid router/bridge.
> --> > --> Cc: [e-mail]
> --> > --> Subject: Re: [rbridge] it's time to summarize things
> --> > --> 
> --> > --> _______________________________________________
> --> > --> rbridge mailing list
> --> > --> [e-mail]
> --> > --> http://www.postel.org/mailman/listinfo/rbridge
> --> > --> 
> --> 
> --> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDodTJE5f5cImnZrsRAmRmAKCTqpT5gEl0a/Ukk4ILZznkmP20FwCgtw1r
3qk8LvkOBEZ7k6heAT3fOUU=
=bFus
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFKeSe07953 for <[e-mail]>; Thu, 15 Dec 2005 12:40:28 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBFKeEdJ023747; Thu, 15 Dec 2005 15:40:14 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA06741;  Thu, 15 Dec 2005 15:40:14 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BL3R0P>; Thu, 15 Dec 2005 15:40:13 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Joe Touch'" <[e-mail]>
Date: Thu, 15 Dec 2005 15:40:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 20:41:00 -0000
Status: RO
Content-Length: 5244

Joe,

	Please see below...

--
Eric 

--> -----Original Message-----
--> From: Joe Touch [mailto:[e-mail]] 
--> Sent: Thursday, December 15, 2005 2:02 PM
--> To: Gray, Eric
--> Cc: [e-mail]; 'Developing a hybrid router/bridge.'
--> Subject: Re: [rbridge] it's time to summarize things
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Gray, Eric wrote:
--> > Joe,
--> > 
--> > 	We're getting closer, maybe, on this one.  Please
--> > see below...
--> > 
--> > __
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: Joe Touch [mailto:[e-mail]] 
--> > --> Sent: Thursday, December 15, 2005 12:11 PM
--> > --> To: Gray, Eric
--> > --> Cc: [e-mail]; 'Developing a hybrid 
--> router/bridge.'
--> > --> Subject: Re: [rbridge] it's time to summarize things
--> > --> 
--> > --> 
--> > --> 
--> > --> Gray, Eric wrote:
--> > --> > Joe,
--> > --> > 
--> > --> > 	I've addressed this issue before, just as you have
--> > --> > raised it before.
--> > --> > 
--> > --> > 	Assuming that "external nodes" below refers to the
--> > --> > portions of the L2 broadcast domain that are topologically
--> > --> > outside of the RBridge campus, the RBridge campus actually
--> > --> > looks to external nodes as if it is a (possibly largish)
--> > --> > collection of L2 frame sources and sinks.
--> > --> 
--> > --> For internal traffic, sure. For ingress/egress traffic, 
--> > --> this would need to hijack ARP to work.
--> > --> 
--> > 
--> > Why?  ARP, at least the ARP I am familiar with, allows for the
--> > conversion of an IP address into a LAN-local MAC address (much
--> > the same as DNS allows for conversion of a network name into an
--> > IP address).
--> > 
--> > The RBridge campus forwards ARP - just as the local and remote 
--> > LAN segments do - and the appropriate entity (an L2 source/sink
--> > such as a router or host) responds.  Why would RBridges care
--> > about - or interfer with - ARP?
--> 
--> Because somehow the traffic from external nodes needs to arrive at
--> ingresses. Ingresses don't have (or at least don't use) external
--> addresses; the traffic from external nodes needs to arrive at ingresses
--> based on the external spanning trees, NOT based on being addressed to
--> ingresses.
--> 

You are confusing STP with bridge learning - not even close to 
the same thing.

If a bridge does not hear BPDUs on an interface, that interface
will not be put in a non-forwarding mode.  This corresponds to 
a LAN stub.

Because the bridge will not put that interface in non-forwarding
mode, it will receive broadcast and flooded frames on that link
from frame sources within and beyond the RBridge campus.

It will learn the MAC SAs from those frames and it will construct
learning database entries accordingly.  So will all the other 
bridges on the spanning tree.  Consequently, in a way so glaringly
obvious as to be perfectly clear to even the most casual observer,
the local LAN segment will learn how to forward packets across the
(invisible) RBridge campus.

--> In fact, there is NO external traffic that should ever be directed
--> at an ingress address - thus I believe that rbridge campuses do not
--> participate in ARP. That is a substantial difference from a router,
--> which DO participate in ARP.
--> 

Again, you're being to litteral.

--> Which means that the rbridge campus does NOT look like a collection of
--> sources and sinks to external devices w.r.t. ingress/egress traffic. The
--> only aspect in which rbridges DO look like conventional sources/sinks is
--> for internal traffic.
--> 

I don't follow how you arrive at this conclusion.  Perhaps you 
don't any more.

--> > --> To external nodes, the rbridge MUST act like a transit, not 
--> > --> a source or sink.
--> > -->
--> > 
--> > I think we're in agreement here.  My statement was as to how the
--> > RBridge campus "appears" to the rest of the network.  Yours is to 
--> > how an RBridge campus "acts."
--> 
--> I'm confused about the difference. If all you mean by source/sink
--> is 'traffic goes in that direction', then you're talking about
--> upstream/downstream channels, not sources or sinks. IMO, a source/sink
--> appears as a source/destination in a packet haeader, and (I now think we
--> agree) that never happens for ingress/egress traffic.
--> 

I don't follow how you arrive at this conclusion.  Perhaps you 
don't any more.

--> > Obviously the campus does not "act" like a source or sink.  If it
--> > did, it would be a gibbering black-hole.  It merely appears like
--> > a collection of sources or sinks to external nodes.
--> 
--> I'm not sure how that description is useful. Can you explain how?
-->

Hopefully I have.  I did this earlier too, and thought it
had taken, but here we are going through it again.  

I invite your attention to my E-Mail on the subject of 
"RBridge/bridge interaction", dated Fri 10/21/2005 2:59 PM.
 
--> Joe
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDob2UE5f5cImnZrsRAsUaAJ44nwX7pA7yBDIGpwXKPtkcZA0kaACeNyeg
--> hco5aPY+Wji9vTw8f94UCnU=
--> =nqbN
--> -----END PGP SIGNATURE-----
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFKEFe00552 for <[e-mail]>; Thu, 15 Dec 2005 12:14:16 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBFKDadJ023157; Thu, 15 Dec 2005 15:13:37 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA03320;  Thu, 15 Dec 2005 15:13:36 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BL3RCB>; Thu, 15 Dec 2005 15:13:35 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Joe Touch'" <[e-mail]>
Date: Thu, 15 Dec 2005 15:13:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 20:15:37 -0000
Status: RO
Content-Length: 4735

Joe,

	We may be closer on this one too.  Again, please see
below...

--
Eric 


--> 
--> Gray, Eric wrote:
--> > Joe,
--> > 
--> > 	Taking things too litterally - so as to make them seem
--> > ridiculous - is an argument style, not a communication skill.
--> > Are we arguing to a purpose, or are we trying to communicate?
--> > 
--> > 	The phrase "like being a router" is a very far cry from 
--> > "being exactly like a router", and the phrase "the destination 
--> > is a layer 2 address rather than an IP address" implies a lot 
--> > of things about the differences between a router and an RBridge.
--> 
--> Agreed, but it has already proven useful in eliciting the idea 
--> that rbridges have external addresses that external hosts know 
--> about (which I disagree with).
--> 

I think I know how you got this interpretation out of what was
said, but it is an incorrect interpretation.

When saying "the destination is a layer 2 address rather than an IP 
address" the routing analog is fairly accurate.  That is, instead
of routing based on IP addresses, routing is based on layer 2 (MAC)
addresses.

In the same way that the IP address for the local router is usually
not used in forwarding IP traffic (unless the traffic is destined
for the router), RBridge addresses are not typically used to forward 
layer 2 traffic to non-RBridge destinations.  One key exception to
this is when forwarding traffic using tunneling encapsulation from
one RBridge to another.

Hosts in a common broadcast domain containing an RBridge campus are
not aware of the RBridge campus.  Same for routers and for routers
and hosts talking to each other.

Consequently, there is nothing to disagree with here.

--> I have been very specific about the idea of being "like a bridge" or
--> "like a hub"; it allows me to encapsulate a lot of rules about what 
--> the campus would do, w.r.t. nodes, bridges, etc.
--> 
--> If a campus is not "like" either a bridge or a hub, someone needs to
--> describe what it does - either in terms of another viable L2 analog,
--> or in terms of how it interacts with each level of protocol:
--> 
--> 	- do external nodes address traffic to the ingress?
--> 		I have been assuming NO.

That is correct.

--> 		if they do, then a lot of protocols are affected
--> 		and need modification and/or proxying.
--> 
--> 	- do external bridges address traffic to rbridges?
--> 	(basically BPDUs)
--> 		I have been assuming YES.

That is incorrect.

--> 		if not, then how do bridges know to forward
--> 		traffic to the ingresses?
--> 

The same way they always do.  That is, they learn about the
MAC addresses from traffic they see coming from the direction
of the RBridge campus, so they know to forward traffic with
a MAC DA toward the MAC SA they've learned earlier.

This is what makes the RBridge campus look like a collection
of MAC sources/sinks on a common Ethernet link.

Naturally, the process will be (as usual in 802.1 networks) 
"primed" by either by broadcast (e.g. ARP) or by flooding.

--> 		if not, then can there be broadcast storms?
-->

Certainly not worse than currently, except to the extent that
an RBridge campus enhanced broadcast domain _might_ be larger.

--> 		if not, then will broadcast be supported?
-->

Yes, of course.

--> 
--> (this is not necessarily a complete list, but it's a start; 
--> anyone want to answer it?)

Many people probably could.  What about somebody else?

--> 
--> Joe
--> 
--> > 
--> > --
--> > Eric
--> > 
--> > --> Routers do NOT propagate broadcasts at either L2 or L3.
--> > --> 
--> > --> So being an rbridge breaks broadcast, so ARP, DHCP, etc. won't
work.
--> > --> 
--> > --> Joe
--> > -->
--> > --> Gray, Eric wrote:
--> > --> Radia,
--> > -->  
--> > --> 	Very well put.
--> > --> 
--> > --> --> Being an RBridge is really like being a router, but the
--> > --> --> destination is a layer 2 address rather than an IP address.
--> > --> --> 
--> > --> --> Radia
--> > --> --> 
--> > --> 
--> > --> --
--> > --> Eric
--> > --> _______________________________________________
--> > --> rbridge mailing list
--> > --> [e-mail]
--> > --> http://www.postel.org/mailman/listinfo/rbridge
--> > 
--> > --> -----Original Message-----
--> > --> From: [e-mail] 
--> > --> [mailto:[e-mail]] On Behalf Of Joe Touch
--> > --> Sent: Thursday, December 15, 2005 11:08 AM
--> > --> To: Developing a hybrid router/bridge.
--> > --> Cc: [e-mail]
--> > --> Subject: Re: [rbridge] it's time to summarize things
--> > --> 
--> > --> _______________________________________________
--> > --> rbridge mailing list
--> > --> [e-mail]
--> > --> http://www.postel.org/mailman/listinfo/rbridge
--> > --> 
--> 
--> 


Received: from stag.seas.upenn.edu (stag.seas.upenn.edu [158.130.70.79]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFJa8e19103 for <[e-mail]>; Thu, 15 Dec 2005 11:36:08 -0800 (PST)
Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by stag.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id jBFJa6ef020377 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 15 Dec 2005 14:36:06 -0500
Message-Id: <[e-mail]>
From: "Saikat Ray" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>, "'Joe Touch'" <[e-mail]>
Date: Thu, 15 Dec 2005 14:38:02 -0500
Organization: University of Pennsylvania
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
thread-index: AcYBqo98f14ZY1TaRkywNoT0Yo7VWAAAVMuA
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 19:36:55 -0000
Status: RO
Content-Length: 1829

> Because somehow the traffic from external nodes needs to arrive at
> ingresses. Ingresses don't have (or at least don't use) external
> addresses; the traffic from external nodes needs to arrive at ingresses
> based on the external spanning trees, NOT based on being addressed to
> ingresses.

Let us suppose that an RBridge is connected to a legacy bridge's port
directly, and all RBridges block BPDUs. Then the RBridge looks like, from
the perspective of the legacy brige, either (i) a single end-host (with the
MAC address that of the RBridge) if the RBridge is not the designated
RBridge, or (ii) a shared media (like a hub; is the standard term
"segment"?) with potentially a lot of MAC addresses attached to it (in fact,
all the MAC addresses whose packets this designated RBridge forwards),
including the MAC address of the RBridge, but no other legacy bridge, if the
RBridge is the designated RBridge. In both cases, that port of the legacy
bridge will be in the forwarding state. Thus, any broadcast traffic,
including ARP packets, will reach the RBridge. The ARP packet will then be
encapsulated and forwarded over the RBridge-based broadcast tree by the
designated RBridge, and decapsulated and forwarded over every legacy part by
each designated RBridge. Now suppose that the inquirer end-host has MAC
address A and it was looking for MAC address B. Then, in the reverse path,
all the legacy bridges that form the legacy part of the network that holds
the end-host with MAC address B will associate the MAC address A with the
"direction" of the RBridge that is designated for this legacy part, and the
answer to the ARP query will also come back (as a unicast traffic) without
any problem. The ARP (and any broadcast traffic) cannot loop in the
steady-state.

So what exactly do you think is the problem with ARP?



Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFJ1ee07646; Thu, 15 Dec 2005 11:01:40 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 15 Dec 2005 11:01:40 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 19:04:03 -0000
Status: RO
Content-Length: 3352

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



Gray, Eric wrote:
> Joe,
> 
> 	We're getting closer, maybe, on this one.  Please
> see below...
> 
> __
> Eric
> 
> --> -----Original Message-----
> --> From: Joe Touch [mailto:[e-mail]] 
> --> Sent: Thursday, December 15, 2005 12:11 PM
> --> To: Gray, Eric
> --> Cc: [e-mail]; 'Developing a hybrid router/bridge.'
> --> Subject: Re: [rbridge] it's time to summarize things
> --> 
> --> 
> --> 
> --> Gray, Eric wrote:
> --> > Joe,
> --> > 
> --> > 	I've addressed this issue before, just as you have
> --> > raised it before.
> --> > 
> --> > 	Assuming that "external nodes" below refers to the
> --> > portions of the L2 broadcast domain that are topologically
> --> > outside of the RBridge campus, the RBridge campus actually
> --> > looks to external nodes as if it is a (possibly largish)
> --> > collection of L2 frame sources and sinks.
> --> 
> --> For internal traffic, sure. For ingress/egress traffic, 
> --> this would need to hijack ARP to work.
> --> 
> 
> Why?  ARP, at least the ARP I am familiar with, allows for the
> conversion of an IP address into a LAN-local MAC address (much
> the same as DNS allows for conversion of a network name into an
> IP address).
> 
> The RBridge campus forwards ARP - just as the local and remote 
> LAN segments do - and the appropriate entity (an L2 source/sink
> such as a router or host) responds.  Why would RBridges care
> about - or interfer with - ARP?

Because somehow the traffic from external nodes needs to arrive at
ingresses. Ingresses don't have (or at least don't use) external
addresses; the traffic from external nodes needs to arrive at ingresses
based on the external spanning trees, NOT based on being addressed to
ingresses.

In fact, there is NO external traffic that should ever be directed at an
ingress address - thus I believe that rbridge campuses do not
participate in ARP. That is a substantial difference from a router,
which DO participate in ARP.

Which means that the rbridge campus does NOT look like a collection of
sources and sinks to external devices w.r.t. ingress/egress traffic. The
only aspect in which rbridges DO look like conventional sources/sinks is
for internal traffic.

> --> To external nodes, the rbridge MUST act like a transit, not 
> --> a source or sink.
> -->
> 
> I think we're in agreement here.  My statement was as to how the
> RBridge campus "appears" to the rest of the network.  Yours is to 
> how an RBridge campus "acts."

I'm confused about the difference. If all you mean by source/sink is
'traffic goes in that direction', then you're talking about
upstream/downstream channels, not sources or sinks. IMO, a source/sink
appears as a source/destination in a packet haeader, and (I now think we
agree) that never happens for ingress/egress traffic.

> Obviously the campus does not "act" like a source or sink.  If it
> did, it would be a gibbering black-hole.  It merely appears like
> a collection of sources or sinks to external nodes.

I'm not sure how that description is useful. Can you explain how?

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

iD8DBQFDob2UE5f5cImnZrsRAsUaAJ44nwX7pA7yBDIGpwXKPtkcZA0kaACeNyeg
hco5aPY+Wji9vTw8f94UCnU=
=nqbN
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFIWqe28582 for <[e-mail]>; Thu, 15 Dec 2005 10:32:53 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBFIWadJ020957; Thu, 15 Dec 2005 13:32:36 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA18982;  Thu, 15 Dec 2005 13:32:35 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BL3NF3>; Thu, 15 Dec 2005 13:32:34 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Joe Touch'" <[e-mail]>
Date: Thu, 15 Dec 2005 13:32:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 18:34:00 -0000
Status: RO
Content-Length: 1768

Joe,

	We're getting closer, maybe, on this one.  Please
see below...

__
Eric

--> -----Original Message-----
--> From: Joe Touch [mailto:[e-mail]] 
--> Sent: Thursday, December 15, 2005 12:11 PM
--> To: Gray, Eric
--> Cc: [e-mail]; 'Developing a hybrid router/bridge.'
--> Subject: Re: [rbridge] it's time to summarize things
--> 
--> 
--> 
--> Gray, Eric wrote:
--> > Joe,
--> > 
--> > 	I've addressed this issue before, just as you have
--> > raised it before.
--> > 
--> > 	Assuming that "external nodes" below refers to the
--> > portions of the L2 broadcast domain that are topologically
--> > outside of the RBridge campus, the RBridge campus actually
--> > looks to external nodes as if it is a (possibly largish)
--> > collection of L2 frame sources and sinks.
--> 
--> For internal traffic, sure. For ingress/egress traffic, 
--> this would need to hijack ARP to work.
--> 

Why?  ARP, at least the ARP I am familiar with, allows for the
conversion of an IP address into a LAN-local MAC address (much
the same as DNS allows for conversion of a network name into an
IP address).

The RBridge campus forwards ARP - just as the local and remote 
LAN segments do - and the appropriate entity (an L2 source/sink
such as a router or host) responds.  Why would RBridges care
about - or interfer with - ARP?

--> To external nodes, the rbridge MUST act like a transit, not 
--> a source or sink.
-->

I think we're in agreement here.  My statement was as to how the
RBridge campus "appears" to the rest of the network.  Yours is to 
how an RBridge campus "acts."

Obviously the campus does not "act" like a source or sink.  If it
did, it would be a gibbering black-hole.  It merely appears like
a collection of sources or sinks to external nodes.


Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFHc0e11245; Thu, 15 Dec 2005 09:38:00 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 15 Dec 2005 09:37:53 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF4B66997AA4BCD4A38EB4EE2"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 17:39:08 -0000
Status: RO
Content-Length: 3413

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



Gray, Eric wrote:
> Joe,
>=20
> 	Taking things too litterally - so as to make them seem
> ridiculous - is an argument style, not a communication skill.
> Are we arguing to a purpose, or are we trying to communicate?
>=20
> 	The phrase "like being a router" is a very far cry from=20
> "being exactly like a router", and the phrase "the destination=20
> is a layer 2 address rather than an IP address" implies a lot=20
> of things about the differences between a router and an RBridge.

Agreed, but it has already proven useful in eliciting the idea that
rbridges have external addresses that external hosts know about (which I
disagree with).

I have been very specific about the idea of being "like a bridge" or
"like a hub"; it allows me to encapsulate a lot of rules about what the
campus would do, w.r.t. nodes, bridges, etc.

If a campus is not "like" either a bridge or a hub, someone needs to
describe what it does - either in terms of another viable L2 analog, or
in terms of how it interacts with each level of protocol:

	- do external nodes address traffic to the ingress?
		I have been assuming NO.
		if they do, then a lot of protocols are affected
		and need modification and/or proxying.

	- do external bridges address traffic to rbridges?
	(basically BPDUs)
		I have been assuming YES.
		if not, then how do bridges know to forward
		traffic to the ingresses?

		if not, then can there be broadcast storms?
		if not, then will broadcast be supported?

(this is not necessarily a complete list, but it's a start; anyone want
to answer it?)

Joe

>=20
> --
> Eric
>=20
> --> Routers do NOT propagate broadcasts at either L2 or L3.
> -->=20
> --> So being an rbridge breaks broadcast, so ARP, DHCP, etc. won't work=
=2E
> -->=20
> --> Joe
> -->
> --> Gray, Eric wrote:
> --> Radia,
> --> =20
> --> 	Very well put.
> -->=20
> --> --> Being an RBridge is really like being a router, but the
> --> --> destination is a layer 2 address rather than an IP address.
> --> -->=20
> --> --> Radia
> --> -->=20
> -->=20
> --> --
> --> Eric
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://www.postel.org/mailman/listinfo/rbridge
>=20
> --> -----Original Message-----
> --> From: [e-mail]=20
> --> [mailto:[e-mail]] On Behalf Of Joe Touch
> --> Sent: Thursday, December 15, 2005 11:08 AM
> --> To: Developing a hybrid router/bridge.
> --> Cc: [e-mail]
> --> Subject: Re: [rbridge] it's time to summarize things
> -->=20
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://www.postel.org/mailman/listinfo/rbridge
> -->=20


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

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

iD8DBQFDoanxE5f5cImnZrsRAo3UAJ91a6emHJ+LMLlplh7EAyIJMe+xUQCdFjzb
RRSiWnZxibyj/ghjKWY88F4=
=QLGJ
-----END PGP SIGNATURE-----

--------------enigF4B66997AA4BCD4A38EB4EE2--


Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFHX8e10035; Thu, 15 Dec 2005 09:33:08 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 15 Dec 2005 09:33:01 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6819076A2FC63F4B2D216B4F"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 17:34:19 -0000
Status: RO
Content-Length: 9296

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



Gray, Eric wrote:
> =20
>=20
>=20
> --> Gray, Eric wrote:
> --> > Radia and all,=20
> --> >=20
> --> > 	I've included some detailed responses below, but the=20
> --> > short answer is that I completely agree with Radia...
> --> >=20
> --> > --
> --> > Eric
> --> >=20
> --> > ----> > -----Original Message-----
> --> > ----> > From: [e-mail]=20
> --> > ----> > [mailto:[e-mail]] On Behalf Of Radia Pe=
rlman
> --> > ----> > Sent: Thursday, December 15, 2005 1:02 AM
> --> > ----> > To: Developing a hybrid router/bridge.
> --> > ----> > Subject: Re: [rbridge] it's time to summarize things
> --> > ----> >=20
> --> > ----> >=20
> --> > ----> >=20
> --> > ----> > Joe Touch wrote On 12/14/05 21:33,:
> --> > ----> > --> >=20
> --> > ----> >=20
> --> > ----> > --> > Routers terminate L2 broadcasts. Rbridges cannot.
> Routers decrement L3
> --> > ----> > --> > TTLs. Rbridges cannot. So the assertion that an rbr=
idge
> campus should
> --> > ----> > --> > drop BPDUs - just like routers - doesn't follow.
> --> > ----> >=20
> --> > ----> > I really don't understand what you're saying. RBridges ca=
n
> --> > ----> > terminate some L2 broadcasts, in particular, spanning tre=
e
> messages.
> --> > ----> > True, RBridges will not decrement L3 TTLs.
> --> >=20
> --> > At one point, we were talking about a TTL field in the encapsulat=
ion
> --> > for RBridge to RBridge tunneled packets.  I am not sure what happ=
ened
> --> > to that idea.
> -->
> --> The TTL is still there, but does NOT (and cannot) affect the L3 TTL=
=2E If
> --> it does, IP all 1's broadcast will fail. I was speaking only about =
the
> --> effect on the L3 TTL.
>=20
> Well, then, what's the problem?  If the concern is about
> potentially (probably short term) looping of L2 traffic
> (especially L2 broadcast/multicast) traffic, and there is
> a loop mitigation technique in the works, then this is a
> "fairie" problem.
>=20
> In that case, I think the case for dropping BPDUs is even
> stronger.

OK - if the idea is:
	- drop BPDUs
	- *assume* the rbridge campus is root
	- allow loops and broadcast storms
Sure. ;-(

> -->
> --> > ----> > And perhaps the assertion that RBridges should drop BPDUs=
 does
> not
> --> > ----> > follow from the previous two sentences, but regardless, t=
hey
> --> > ----> > should drop BPDUs because that's what works, that's what =
is
> --> > ----> > simple, that's what makes the combination of bridging and=

> RBridging
> --> > ----> > more robust than bridging alone, that's what preserves
> transparency
> --> > ----> > to layer 3 and yet increases robustness.
> --> >=20
> --> > Clearly I completely agree with this argument.
> --> >=20
> --> > ----> > --> >=20
> --> > ----> > --> > So at the very least we need to explain the reason =
for
> this behavior
> --> > ----> > --> > more clearly, in a way that does not refer to route=
rs as
> equivalent.
> --> > ----> >=20
> --> > ----> > Hopefully the above explains why it has to work this way.=
 We
> want
> --> > ----> > to break up the spanning tree into smaller and smaller
> spanning
> --> > ----> > trees, hopefully eventually getting rid of them entirely =
and
> --> > ----> > just having one big link state routed zero configuration =

> --> > ----> > infrastructure.
> --> > ----> >=20
> --> >=20
> --> > I believe this is consistent with the WG's charatered objectives.=

> --> >=20
> --> > ----> >=20
> --> > ----> > --> >=20
> --> > ----> > --> > AFAICT, having an rbridge campus drop BPDUs makes s=
ense
> only by
> --> > ----> > --> > effectively considering the rbridge campus as the r=
oot
> of all trees,
> --> > ----> > --> > but that presumes it is always _the_ root (that the=
re is
> only one
> --> > ----> > --> > 'drops BPDU' system per bridged LAN). Since there's=
 no
> way to enforce
> --> > ----> > --> > that assertion, it seems problematic.
> --> > ----> > --> >=20
> --> > ----> > --> > Joe
> --> > ----> >=20
> --> > ----> > The above paragraph makes absolutely no sense to me.
> --> > ----> >=20
> --> > ----> > Routers drop spanning tree messages, and the world winds =
up
> with
> --> > ----> > lots of isolated spanning trees. The same thing happens w=
ith
> --> > ----> > RBridges. If there were a problem with doing it this way,=

> --> > ----> > IP mixed with bridges would not work.
> --> > ----> >=20
> --> >=20
> --> > The argument that edge RBridges should do something about BPDUs
> --> > (other than drop them) proceeds from a suspicion that RBridges=20
> --> > will not always be able to detect a loop that is external to the
> --> > RBridge campus.  This implies that <something--> > - out of eithe=
r
> --> > malicious design or accident - will consistently drop RBridge=20
> --> > hello/discovery PDUs.
> -->=20
> --> Or, along Guillermo's line, that the rbridge cannot ensure that it =
is
> --> the root of the external spanning trees.
>=20
> The task of "[ensuring] that [the RBridge) is the root of the external
> spanning [tree]" is orthogonal to specification of RBridge functionalit=
y.
> It is handled - within implementations - by colocation of logical bridg=
e
> functionality.

Not everyone is assuming that. If we do assume that, then it's hard to
assert that the rbridge campus (rbridges + logical bridge function)
'blocks' anything.

> As it is orthogonal, we need do no more than mention it
> and get on with the (already plentiful) work at hand.  Since I believe
> we have pretty much universal agreement that we should mention it, then=

> why are we still discussing it?

I'm not sure we're all on that page.

We do have other work: in particular, my impression has always been that
the rbridge is invisible to external hosts - it should be, and it must
be. Radia's recent posts hint otherwise, which would require
*substantial* changes to a number of protocols at both L2 and L3 to
preserve L2 functionality through the rbridge+stub system.


> --> > Unless we decide to use BPDUs, this is a paranoid suspicion.
> --> > Bridges do not consistenly drop any kind of frames unless this
> --> > is part of the specified behavior for bridges.  The same will
> --> > also apply to other technologies.
> -->=20
> --> bridges expect that of other L2 devices, yet we're deciding to drop=

> --> BPDUs. Is it paranoid for a burgler to expect to be burgled?
>=20
> I think the term is "burglar", but we don't need to make that
> an architectural issue...  :-)
>=20
> Bridges are a reasonably well understood technology that has
> been around for quite a while.
>=20
> When RBridges are an equally well understood technology, that
> has been around approximately the same amount of time, I am
> sure that this issue will come up.
>=20
> In the meantime, it is paranoid to assume that any existing=20
> forwarding devices will arbitrarily decide to junk RBridge
> control PDUs. =20
>=20
> If it ever becomes a problem, deal with it when it comes up.

Why let it be a floating problem? Making the campus the root will do the
same thing, and we know it has no remaining issues. And we also know
what to do *when* an rbridge campus loses root election -  regardless of
the reason. Robustness was a requirement, right?

>=20
> -->
> --> > There is a possibility that RBridge interactions may interfere
> --> > with propagation of RBridge hello/discovery PDUs, but we are in
> --> > the process of defining how RBridges work - so we can finesse
> --> > that as we go along, by either prohibiting anti-social behviors
> --> > or by specifying how such interactions can work.
> --> >=20
> --> > So, as Radia says, there is no reason what-so-ever to encourage
> --> > RBridges to particpate in STP/RSTP.
> --> >=20
> --> > ----> > Radia
> --> > ----> >=20
> --> > ----> > _______________________________________________
> --> > ----> > rbridge mailing list
> --> > ----> > [e-mail]
> --> > ----> > http://www.postel.org/mailman/listinfo/rbridge
> --> > ----> >=20
> --> > _______________________________________________
> --> > rbridge mailing list
> --> > [e-mail]
> --> > http://www.postel.org/mailman/listinfo/rbridge
> --> -----Original Message-----
> --> From: [e-mail]=20
> --> [mailto:[e-mail]] On Behalf Of Joe Touch
> --> Sent: Thursday, December 15, 2005 11:07 AM
> --> To: Developing a hybrid router/bridge.
> --> Cc: '[e-mail]'
> --> Subject: Re: [rbridge] it's time to summarize things
> -->=20
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://www.postel.org/mailman/listinfo/rbridge
> -->=20


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

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

iD8DBQFDoajNE5f5cImnZrsRAtgyAJ9hvP97W4ED6C/6JP2Crm5eBOXAJQCfYX0D
hs1SZC/sgt/hXYA65zAkAVs=
=vsTS
-----END PGP SIGNATURE-----

--------------enig6819076A2FC63F4B2D216B4F--


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 jBFHQXe08050 for <[e-mail]>; Thu, 15 Dec 2005 09:26:33 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBFHQGdJ019540; Thu, 15 Dec 2005 12:26:16 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA09946;  Thu, 15 Dec 2005 12:26:15 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BL3KW8>; Thu, 15 Dec 2005 12:26:15 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Joe Touch'" <[e-mail]>
Date: Thu, 15 Dec 2005 12:26:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 17:27:04 -0000
Status: RO
Content-Length: 1473

Joe,

	Taking things too litterally - so as to make them seem
ridiculous - is an argument style, not a communication skill.
Are we arguing to a purpose, or are we trying to communicate?

	The phrase "like being a router" is a very far cry from 
"being exactly like a router", and the phrase "the destination 
is a layer 2 address rather than an IP address" implies a lot 
of things about the differences between a router and an RBridge.

--
Eric

--> Routers do NOT propagate broadcasts at either L2 or L3.
--> 
--> So being an rbridge breaks broadcast, so ARP, DHCP, etc. won't work.
--> 
--> Joe
-->
--> Gray, Eric wrote:
--> Radia,
-->  
--> 	Very well put.
--> 
--> --> Being an RBridge is really like being a router, but the
--> --> destination is a layer 2 address rather than an IP address.
--> --> 
--> --> Radia
--> --> 
--> 
--> --
--> Eric
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Joe Touch
--> Sent: Thursday, December 15, 2005 11:08 AM
--> To: Developing a hybrid router/bridge.
--> Cc: [e-mail]
--> Subject: Re: [rbridge] it's time to summarize things
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFHCKe03971 for <[e-mail]>; Thu, 15 Dec 2005 09:12:20 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBFHC5dJ019270; Thu, 15 Dec 2005 12:12:06 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA08219;  Thu, 15 Dec 2005 12:12:05 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BL3KGK>; Thu, 15 Dec 2005 12:12:05 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Joe Touch'" <[e-mail]>
Date: Thu, 15 Dec 2005 12:12:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 17:13:03 -0000
Status: RO
Content-Length: 7134

 


--> Gray, Eric wrote:
--> > Radia and all, 
--> > 
--> > 	I've included some detailed responses below, but the 
--> > short answer is that I completely agree with Radia...
--> > 
--> > --
--> > Eric
--> > 
--> > ----> > -----Original Message-----
--> > ----> > From: [e-mail] 
--> > ----> > [mailto:[e-mail]] On Behalf Of Radia Perlman
--> > ----> > Sent: Thursday, December 15, 2005 1:02 AM
--> > ----> > To: Developing a hybrid router/bridge.
--> > ----> > Subject: Re: [rbridge] it's time to summarize things
--> > ----> > 
--> > ----> > 
--> > ----> > 
--> > ----> > Joe Touch wrote On 12/14/05 21:33,:
--> > ----> > --> > 
--> > ----> > 
--> > ----> > --> > Routers terminate L2 broadcasts. Rbridges cannot.
Routers decrement L3
--> > ----> > --> > TTLs. Rbridges cannot. So the assertion that an rbridge
campus should
--> > ----> > --> > drop BPDUs - just like routers - doesn't follow.
--> > ----> > 
--> > ----> > I really don't understand what you're saying. RBridges can
--> > ----> > terminate some L2 broadcasts, in particular, spanning tree
messages.
--> > ----> > True, RBridges will not decrement L3 TTLs.
--> > 
--> > At one point, we were talking about a TTL field in the encapsulation
--> > for RBridge to RBridge tunneled packets.  I am not sure what happened
--> > to that idea.
-->
--> The TTL is still there, but does NOT (and cannot) affect the L3 TTL. If
--> it does, IP all 1's broadcast will fail. I was speaking only about the
--> effect on the L3 TTL.

Well, then, what's the problem?  If the concern is about
potentially (probably short term) looping of L2 traffic
(especially L2 broadcast/multicast) traffic, and there is
a loop mitigation technique in the works, then this is a
"fairie" problem.

In that case, I think the case for dropping BPDUs is even
stronger.

-->
--> > ----> > And perhaps the assertion that RBridges should drop BPDUs does
not
--> > ----> > follow from the previous two sentences, but regardless, they
--> > ----> > should drop BPDUs because that's what works, that's what is
--> > ----> > simple, that's what makes the combination of bridging and
RBridging
--> > ----> > more robust than bridging alone, that's what preserves
transparency
--> > ----> > to layer 3 and yet increases robustness.
--> > 
--> > Clearly I completely agree with this argument.
--> > 
--> > ----> > --> > 
--> > ----> > --> > So at the very least we need to explain the reason for
this behavior
--> > ----> > --> > more clearly, in a way that does not refer to routers as
equivalent.
--> > ----> > 
--> > ----> > Hopefully the above explains why it has to work this way. We
want
--> > ----> > to break up the spanning tree into smaller and smaller
spanning
--> > ----> > trees, hopefully eventually getting rid of them entirely and
--> > ----> > just having one big link state routed zero configuration 
--> > ----> > infrastructure.
--> > ----> > 
--> > 
--> > I believe this is consistent with the WG's charatered objectives.
--> > 
--> > ----> > 
--> > ----> > --> > 
--> > ----> > --> > AFAICT, having an rbridge campus drop BPDUs makes sense
only by
--> > ----> > --> > effectively considering the rbridge campus as the root
of all trees,
--> > ----> > --> > but that presumes it is always _the_ root (that there is
only one
--> > ----> > --> > 'drops BPDU' system per bridged LAN). Since there's no
way to enforce
--> > ----> > --> > that assertion, it seems problematic.
--> > ----> > --> > 
--> > ----> > --> > Joe
--> > ----> > 
--> > ----> > The above paragraph makes absolutely no sense to me.
--> > ----> > 
--> > ----> > Routers drop spanning tree messages, and the world winds up
with
--> > ----> > lots of isolated spanning trees. The same thing happens with
--> > ----> > RBridges. If there were a problem with doing it this way,
--> > ----> > IP mixed with bridges would not work.
--> > ----> > 
--> > 
--> > The argument that edge RBridges should do something about BPDUs
--> > (other than drop them) proceeds from a suspicion that RBridges 
--> > will not always be able to detect a loop that is external to the
--> > RBridge campus.  This implies that <something--> > - out of either
--> > malicious design or accident - will consistently drop RBridge 
--> > hello/discovery PDUs.
--> 
--> Or, along Guillermo's line, that the rbridge cannot ensure that it is
--> the root of the external spanning trees.

The task of "[ensuring] that [the RBridge) is the root of the external
spanning [tree]" is orthogonal to specification of RBridge functionality.
It is handled - within implementations - by colocation of logical bridge
functionality.  As it is orthogonal, we need do no more than mention it
and get on with the (already plentiful) work at hand.  Since I believe
we have pretty much universal agreement that we should mention it, then
why are we still discussing it?

--> 
--> > Unless we decide to use BPDUs, this is a paranoid suspicion.
--> > Bridges do not consistenly drop any kind of frames unless this
--> > is part of the specified behavior for bridges.  The same will
--> > also apply to other technologies.
--> 
--> bridges expect that of other L2 devices, yet we're deciding to drop
--> BPDUs. Is it paranoid for a burgler to expect to be burgled?

I think the term is "burglar", but we don't need to make that
an architectural issue...  :-)

Bridges are a reasonably well understood technology that has
been around for quite a while.

When RBridges are an equally well understood technology, that
has been around approximately the same amount of time, I am
sure that this issue will come up.

In the meantime, it is paranoid to assume that any existing 
forwarding devices will arbitrarily decide to junk RBridge
control PDUs.  

If it ever becomes a problem, deal with it when it comes up.

-->
--> > There is a possibility that RBridge interactions may interfere
--> > with propagation of RBridge hello/discovery PDUs, but we are in
--> > the process of defining how RBridges work - so we can finesse
--> > that as we go along, by either prohibiting anti-social behviors
--> > or by specifying how such interactions can work.
--> > 
--> > So, as Radia says, there is no reason what-so-ever to encourage
--> > RBridges to particpate in STP/RSTP.
--> > 
--> > ----> > Radia
--> > ----> > 
--> > ----> > _______________________________________________
--> > ----> > rbridge mailing list
--> > ----> > [e-mail]
--> > ----> > http://www.postel.org/mailman/listinfo/rbridge
--> > ----> > 
--> > _______________________________________________
--> > rbridge mailing list
--> > [e-mail]
--> > http://www.postel.org/mailman/listinfo/rbridge
--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Joe Touch
--> Sent: Thursday, December 15, 2005 11:07 AM
--> To: Developing a hybrid router/bridge.
--> Cc: '[e-mail]'
--> Subject: Re: [rbridge] it's time to summarize things
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFHBWe03882; Thu, 15 Dec 2005 09:11:32 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 15 Dec 2005 09:11:21 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3FA147258A0E58291FB2878E"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 17:13:01 -0000
Status: RO
Content-Length: 3895

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



Gray, Eric wrote:
> Joe,
>=20
> 	I've addressed this issue before, just as you have
> raised it before.
>=20
> 	Assuming that "external nodes" below refers to the
> portions of the L2 broadcast domain that are topologically
> outside of the RBridge campus, the RBridge campus actually
> looks to external nodes as if it is a (possibly largish)
> collection of L2 frame sources and sinks.

For internal traffic, sure. For ingress/egress traffic, this would need
to hijack ARP to work.

To external nodes, the rbridge MUST act like a transit, not a source or
sink.

> 	In other words, from the perspective of any existing=20
> technology, external nodes (those that are outside of the
> RBridge campus) see what looks like a shared ethernet link
> with (possibly very many) directly attached L2 sources and
> sinks.
>=20
> 	On the other hand, non-RBridge nodes that make up a
> part of the infrastructure within the campus see only the
> RBridges themselves (along with possibly locally attached
> L2 sources and sinks) as L2 sources and sinks.
>=20
> 	We have to be careful about understanding this.  For
> one thing, we have to realize that - within this common L2
> broadcast domain - there can be no "back-routes" by which
> an external node can become confused in filtering database
> learning as a result of "hearing" the same source MAC from
> more than one direction.  But this can be managed - mostly
> because "external" (outside the RBridge campus) back-routes
> cannot exist (any such back-route indicates that RBridges
> are connected over it and it is therefore not ouside of the
> RBridge campus).
>=20
> 	Inside the RBridge campus, ambiguity is resolved by
> IS-IS routing, and by well-made RBridge implementations.
>=20
> --
> Eric
>=20
> --> -----Original Message-----
> --> From: [e-mail]=20
> --> [mailto:[e-mail]] On Behalf Of Joe Touch
> --> Sent: Thursday, December 15, 2005 11:03 AM
> --> To: [e-mail]; Developing a hybrid router/bridge.
> --> Subject: Re: [rbridge] it's time to summarize things
> -->=20
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://www.postel.org/mailman/listinfo/rbridge
> -->
>=20
> Earlier, you wrote (paraphrased for context):
>=20
>> An RBridge campus should look like a single broadcast domain
>> to layer 3 devices, but that doesn't mean an RBridge should
>> participate in spanning tree, any more than that if it had
>> two token ring interfaces, that it should pass the token from
>> one interface to another. (though hopefully this analogy won't=20
>> confuse people, since a station on a token ring *does* have to
>> pass the token within that ring...
>> however an Ethernet endnode does NOT have to participate
>> in spanning tree (nor should it), and likewise, an RBridge
>> does not have to participate in spanning tree.
>=20
> That logic is makes as much (or as little) sense as an rbridge
> correlating to a router. Routers and hosts on L2 are L2 sources=20
> and L2 sinks. To the existing L2, external traffic transits the=20
> rbridge; the rbridge sources and sinks no traffic to these=20
> external nodes.=20


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

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

iD8DBQFDoaO+E5f5cImnZrsRAk32AKDHOUog0p5uMLn1k2+76kBcXviM8ACdFgOf
UqEAiXke/V3xBajMwfVkwQE=
=8R+a
-----END PGP SIGNATURE-----

--------------enig3FA147258A0E58291FB2878E--


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 jBFGsPe28407 for <[e-mail]>; Thu, 15 Dec 2005 08:54:25 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBFGs8dJ018857; Thu, 15 Dec 2005 11:54:09 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA05511;  Thu, 15 Dec 2005 11:54:08 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BL3JNX>; Thu, 15 Dec 2005 11:54:08 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Joe Touch'" <[e-mail]>
Date: Thu, 15 Dec 2005 11:54:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 16:54:59 -0000
Status: RO
Content-Length: 2836

Joe,

	I've addressed this issue before, just as you have
raised it before.

	Assuming that "external nodes" below refers to the
portions of the L2 broadcast domain that are topologically
outside of the RBridge campus, the RBridge campus actually
looks to external nodes as if it is a (possibly largish)
collection of L2 frame sources and sinks.

	In other words, from the perspective of any existing 
technology, external nodes (those that are outside of the
RBridge campus) see what looks like a shared ethernet link
with (possibly very many) directly attached L2 sources and
sinks.

	On the other hand, non-RBridge nodes that make up a
part of the infrastructure within the campus see only the
RBridges themselves (along with possibly locally attached
L2 sources and sinks) as L2 sources and sinks.

	We have to be careful about understanding this.  For
one thing, we have to realize that - within this common L2
broadcast domain - there can be no "back-routes" by which
an external node can become confused in filtering database
learning as a result of "hearing" the same source MAC from
more than one direction.  But this can be managed - mostly
because "external" (outside the RBridge campus) back-routes
cannot exist (any such back-route indicates that RBridges
are connected over it and it is therefore not ouside of the
RBridge campus).

	Inside the RBridge campus, ambiguity is resolved by
IS-IS routing, and by well-made RBridge implementations.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Joe Touch
--> Sent: Thursday, December 15, 2005 11:03 AM
--> To: [e-mail]; Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] it's time to summarize things
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
-->

Earlier, you wrote (paraphrased for context):

> An RBridge campus should look like a single broadcast domain
> to layer 3 devices, but that doesn't mean an RBridge should
> participate in spanning tree, any more than that if it had
> two token ring interfaces, that it should pass the token from
> one interface to another. (though hopefully this analogy won't 
> confuse people, since a station on a token ring *does* have to
> pass the token within that ring...
> however an Ethernet endnode does NOT have to participate
> in spanning tree (nor should it), and likewise, an RBridge
> does not have to participate in spanning tree.

That logic is makes as much (or as little) sense as an rbridge
correlating to a router. Routers and hosts on L2 are L2 sources 
and L2 sinks. To the existing L2, external traffic transits the 
rbridge; the rbridge sources and sinks no traffic to these 
external nodes. 



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 jBFGX5e22408 for <[e-mail]>; Thu, 15 Dec 2005 08:33:05 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBFGWsdJ018371; Thu, 15 Dec 2005 11:32:54 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA02748;  Thu, 15 Dec 2005 11:32:54 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BL324Z>; Thu, 15 Dec 2005 11:32:53 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Stewart Bryant <[e-mail]>
Date: Thu, 15 Dec 2005 11:32:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 16:34:06 -0000
Status: RO
Content-Length: 4034

Stuart,

	First, thank you very much for providing a concrete
example of the "optimality issues" Guillermo brought up 
earlier.

	Let me try to address the figure below as follows:

1) we have already talked about the fact that an RBridge 
   implementation may include colocated bridge functionality
   and that this colocated bridge may be configured with a
   high priority so that it will become the root for any
   connected bridge spanning tree.
2) we said that we will include a statement to this effect
   in RBridge/TRILL specifications.  Based on the example
   you provide, I am even willing to concede that doing so
   should be recommended.
3) The separation of RBridge _implementation_ into one or
   more logical bridges and a (central/hub) RBridge allows
   for specification of the RBridge component orthogonally
   relative to the specification of bridge behavior (which
   is a] done already and b] not under our purview anyway).
4) Even though this scenario strongly implies the need for
   a colocated bridge, in fairness, the scenario is based 
   on the topological assumption that there is a(t least 
   one) bridge to the right of the figure shown.

To show that you can get the exact same result without a
colocated bridge, consider the following modification to
your proposed scenario:

      +----+
 -----|    |    L1
 -----| B1 |----------> B3 <---> To RBridge campus <-+
 -----|    |                                         |
      +----+                                         |
         |                                           |
         | L3                                        |
         |                                           |
      +----+                                         |
 -----|    |    L2                                   |
 -----| B2 |----------> B4 <---> To RBridge campus <-+
 -----|    |
      +----+

Given that your scenario assumes the presence of at least
one bridge to the right (core-ward), then this transform
simply means that a few of those existing bridges will not
be scrapped when the rest are.  Configuring B3 and B4 with 
higher priority makes this work in exactly the same way 
that Guillermo's colocated bridge functionality would.

--
Eric 

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Stewart Bryant
--> Sent: Thursday, December 15, 2005 9:54 AM
--> To: Radia Perlman
--> Cc: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] it's time to summarize things
--> 
--> Radia Perlman wrote:
--> 
--> > I think I might need a picture of what you're saying, but 
--> > I think it's just the opposite. RBridges can path split, 
--> > just like routers can, whereas if the spanning tree turns
--> > off one of the links, then a bridge would only use one of
--> > the paths.
--> 
--> The SPT situation is as follows:
--> 
-->      +----+
--> -----|    |    L1
--> -----| B1 |---------->To core
--> -----|    |
-->      +----+
-->         |
-->         | L3
-->         |
-->      +----+
--> -----|    |    L2
--> -----| B2 |---------->To core
--> -----|    |
-->      +----+
--> 
--> You want
--> B1 to connect a bunch of systems to the main network via L1
--> B2 to connect a different bunch of systems to the main 
--> network via L2
--> 
--> So you set B1 and B2 with low priority, so the root is to the
--> right in the main network, and the ports connecting B1 and B2 to L3
--> go into blocking.
--> 
--> Say most of the traffic is to some server S. This traffic will
--> be load balanced over both links L1 and L2.
--> 
--> Now replace the core with an Rbridge network, but leave B1 and B2
--> running SPT (because you can't upgrade the wiring closets - 
--> there are too many of them)
--> 
--> How does the traffic from B1 and B2 to S get load balanced
--> via L1 and L2?
--> 
--> - Stewart
--> 
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFG8Be14958; Thu, 15 Dec 2005 08:08:11 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 15 Dec 2005 08:08:04 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig86D1A730EA6FB29F275760A4"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 16:09:14 -0000
Status: RO
Content-Length: 1207

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

Routers do NOT propagate broadcasts at either L2 or L3.

So being an rbridge breaks broadcast, so ARP, DHCP, etc. won't work.

Joe

Gray, Eric wrote:
> Radia,
> =20
> 	Very well put.
>=20
> --> Being an RBridge is really like being a router, but the
> --> destination is a layer 2 address rather than an IP address.
> -->=20
> --> Radia
> -->=20
>=20
> --
> Eric
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


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

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

iD8DBQFDoZTkE5f5cImnZrsRAuFsAKC2T289g0Sl4155qCTUeEpwTaOhBwCgg7fl
13sWOwjsDVCai1dhpR6WulM=
=2nfL
-----END PGP SIGNATURE-----

--------------enig86D1A730EA6FB29F275760A4--


Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFG6me14505; Thu, 15 Dec 2005 08:06:48 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 15 Dec 2005 08:06:41 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3A905FB0ED55B20E0E879EFF"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 16:08:23 -0000
Status: RO
Content-Length: 5367

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



Gray, Eric wrote:
> Radia and all,=20
>=20
> 	I've included some detailed responses below, but the=20
> short answer is that I completely agree with Radia...
>=20
> --
> Eric
>=20
> --> -----Original Message-----
> --> From: [e-mail]=20
> --> [mailto:[e-mail]] On Behalf Of Radia Perlman
> --> Sent: Thursday, December 15, 2005 1:02 AM
> --> To: Developing a hybrid router/bridge.
> --> Subject: Re: [rbridge] it's time to summarize things
> -->=20
> -->=20
> -->=20
> --> Joe Touch wrote On 12/14/05 21:33,:
> --> >=20
> -->=20
> --> > Routers terminate L2 broadcasts. Rbridges cannot. Routers decreme=
nt L3
> --> > TTLs. Rbridges cannot. So the assertion that an rbridge campus sh=
ould
> --> > drop BPDUs - just like routers - doesn't follow.
> -->=20
> --> I really don't understand what you're saying. RBridges can
> --> terminate some L2 broadcasts, in particular, spanning tree messages=
=2E
> --> True, RBridges will not decrement L3 TTLs.
>=20
> At one point, we were talking about a TTL field in the encapsulation
> for RBridge to RBridge tunneled packets.  I am not sure what happened
> to that idea.

The TTL is still there, but does NOT (and cannot) affect the L3 TTL. If
it does, IP all 1's broadcast will fail. I was speaking only about the
effect on the L3 TTL.

> --> And perhaps the assertion that RBridges should drop BPDUs does not
> --> follow from the previous two sentences, but regardless, they
> --> should drop BPDUs because that's what works, that's what is
> --> simple, that's what makes the combination of bridging and RBridging=

> --> more robust than bridging alone, that's what preserves transparency=

> --> to layer 3 and yet increases robustness.
>=20
> Clearly I completely agree with this argument.
>=20
> --> >=20
> --> > So at the very least we need to explain the reason for this behav=
ior
> --> > more clearly, in a way that does not refer to routers as equivale=
nt.
> -->=20
> --> Hopefully the above explains why it has to work this way. We want
> --> to break up the spanning tree into smaller and smaller spanning
> --> trees, hopefully eventually getting rid of them entirely and
> --> just having one big link state routed zero configuration=20
> --> infrastructure.
> -->=20
>=20
> I believe this is consistent with the WG's charatered objectives.
>=20
> -->=20
> --> >=20
> --> > AFAICT, having an rbridge campus drop BPDUs makes sense only by
> --> > effectively considering the rbridge campus as the root of all tre=
es,
> but
> --> > that presumes it is always _the_ root (that there is only one 'dr=
ops
> --> > BPDU' system per bridged LAN). Since there's no way to enforce th=
at
> --> > assertion, it seems problematic.
> --> >=20
> --> > Joe
> -->=20
> --> The above paragraph makes absolutely no sense to me.
> -->=20
> --> Routers drop spanning tree messages, and the world winds up with
> --> lots of isolated spanning trees. The same thing happens with
> --> RBridges. If there were a problem with doing it this way,
> --> IP mixed with bridges would not work.
> -->=20
>=20
> The argument that edge RBridges should do something about BPDUs
> (other than drop them) proceeds from a suspicion that RBridges=20
> will not always be able to detect a loop that is external to the
> RBridge campus.  This implies that <something> - out of either
> malicious design or accident - will consistently drop RBridge=20
> hello/discovery PDUs.

Or, along Guillermo's line, that the rbridge cannot ensure that it is
the root of the external spanning trees.

> Unless we decide to use BPDUs, this is a paranoid suspicion.
> Bridges do not consistenly drop any kind of frames unless this
> is part of the specified behavior for bridges.  The same will
> also apply to other technologies.

bridges expect that of other L2 devices, yet we're deciding to drop
BPDUs. Is it paranoid for a burgler to expect to be burgled?

> There is a possibility that RBridge interactions may interfere
> with propagation of RBridge hello/discovery PDUs, but we are in
> the process of defining how RBridges work - so we can finesse
> that as we go along, by either prohibiting anti-social behviors
> or by specifying how such interactions can work.
>=20
> So, as Radia says, there is no reason what-so-ever to encourage
> RBridges to particpate in STP/RSTP.
>=20
> --> Radia
> -->=20
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://www.postel.org/mailman/listinfo/rbridge
> -->=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


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

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

iD8DBQFDoZSRE5f5cImnZrsRAq6lAJ4mzrNtyntAIOpOIQX1XsAy4bvXTQCfQ4Rv
TqUrs49ChqyfnUMYw2FRH34=
=vMyO
-----END PGP SIGNATURE-----

--------------enig3A905FB0ED55B20E0E879EFF--


Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFG36e12967; Thu, 15 Dec 2005 08:03:06 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 15 Dec 2005 08:02:59 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>	<05b901c60136$077b2310$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3CDE727C7FC20742E4B410C5"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 16:04:14 -0000
Status: RO
Content-Length: 4445

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



Radia Perlman wrote:
> Yes Spencer,
>=20
> You understood my note, and I'm glad you
> agree with it. Apparently there was some confusion about
> taking the phrase "looking like a bridge" too literally.
>=20
> An RBridge campus should look like a single broadcast domain
> to layer 3 devices,

L3 has two kinds of broadcast: all 1's, and subnet.

All 1's corresponds directly to an L2 broadcast domain; subnet
broadcasts are depricated so we can skip them.

> but that doesn't mean an RBridge should participate
> in spanning tree, any more
> than that if it had two token ring interfaces, that it should
> pass the token from one interface to another. (though hopefully
> this analogy won't confuse people, since a station on a
> token ring *does* have to pass the token within that ring...
> however an Ethernet endnode does NOT have to participate
> in spanning tree (nor should it), and likewise, an RBridge
> does not have to participate in spanning tree.

That logic is makes as much (or as little) sense as an rbridge
correlating to a router. Routers and hosts on L2 are L2 sources and L2
sinks. To the existing L2, external traffic transits the rbridge; the
rbridge sources and sinks no traffic to these external nodes.

> I think people were perhaps getting hung up on "layer n". Whatever
> you call it, bridges are a lower layer than RBridges, and
> RBridges are a lower layer than IP. So we could call RBridges
> layer 2.5 if we insisted on giving them a layer name.
>=20
> Radia
>=20
>=20
>=20
> Spencer Dawkins wrote On 12/14/05 21:11,:
>> Dear All (following up from Radia's note),
>>
>>
>>
>>> I just got back from a bunch of travel, and was trying to catch
>>> up on the mailing list, and it's really so long.
>>>
>>> It looks like the thread of whether RBridges participate
>>> in spanning tree popped up again. I thought that had been
>>> resolved.
>>>
>>> RBridges should NOT participate in spanning tree, which means
>>> they should DROP spanning tree messages.
>>>
>>> An RBridge should NOT merge spanning trees. It should terminate
>>> spanning trees, just like routers do.
>>
>> I believe one idea has contributed to this - the idea that an RBRIDGE =
campus=20
>> should look like a single very large bridge at its interfaces, which i=
mplies=20
>> (in at least some e-mail) that it participates in the same spanning tr=
ee on=20
>> both sides.
>>
>> My apologies for cut-and-pasting, but the discussion has looked like t=
his,=20
>> in recent e-mail:
>>
>>
>>> --> > --> #1 resolve recommendations for the three modes of
>>> --> BSTP messages:
>>> --> > -->    (is this part of the PS or ARCH?)
>>> --> > --> participate
>>> --> > --> forward
>>> --> > --> block
>>> --> >
>>> --> > Block by default.  Optional configuration for forwarding and/or=

>>> --> > participating MAY be allowed but SHOULD be considered sub-optim=
al.
>>> -->
>>> --> Forward maps to what hubs do.
>>> --> Participate maps to what bridges do.
>>
>> My understanding of Radia's note is that an RBRIDGE campus looks like =
one=20
>> very large router at its interfaces (no spanning tree, so no spanning =
tree=20
>> merge).
>>
>> If I am not misunderstanding Radia's note, I like this answer, because=
 it=20
>> looked like a lot of work to figure out what to do, in order to look l=
ike=20
>> one very large bridge. If this is the high-order bit, things are clear=
er.
>>
>> Am I reading the note correctly? And do others agree?
>>
>> Spencer=20
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://www.postel.org/mailman/listinfo/rbridge
>=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


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

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

iD8DBQFDoZOzE5f5cImnZrsRAraIAJsGWC2AA+cldQridL+Z+veoWPtq9ACdE8x1
tvPldb3FsH6LVv882Pa740U=
=bCMw
-----END PGP SIGNATURE-----

--------------enig3CDE727C7FC20742E4B410C5--


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 jBFG0ce12055 for <[e-mail]>; Thu, 15 Dec 2005 08:00:38 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBFG0VdJ017582; Thu, 15 Dec 2005 11:00:31 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27975;  Thu, 15 Dec 2005 11:00:30 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BL3HJM>; Thu, 15 Dec 2005 11:00:30 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: [e-mail]
Date: Thu, 15 Dec 2005 11:00:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 16:00:52 -0000
Status: RO
Content-Length: 179

Radia,
 
	Very well put.

--> Being an RBridge is really like being a router, but the
--> destination is a layer 2 address rather than an IP address.
--> 
--> Radia
--> 

--
Eric


Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFFwee11041; Thu, 15 Dec 2005 07:58:40 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 15 Dec 2005 07:58:29 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig87A42F173317B240EA9E59D5"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 15:59:08 -0000
Status: RO
Content-Length: 1487

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



Radia Perlman wrote:
=2E..
>> AFAICT, having an rbridge campus drop BPDUs makes sense only by
>> effectively considering the rbridge campus as the root of all trees, b=
ut
>> that presumes it is always _the_ root (that there is only one 'drops
>> BPDU' system per bridged LAN). Since there's no way to enforce that
>> assertion, it seems problematic.
>>
>> Joe
>=20
> The above paragraph makes absolutely no sense to me.
>=20
> Routers drop spanning tree messages, and the world winds up with
> lots of isolated spanning trees. The same thing happens with
> RBridges. If there were a problem with doing it this way,
> IP mixed with bridges would not work.


IP mixed with bridges breaks L2 broadcast - on purpose. I was assuming
that rbridges did NOT do this. Is this incorrect?

Joe


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

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

iD8DBQFDoZKpE5f5cImnZrsRAjAEAKDge5IXsqm79j+N9Ay2zSme2/LMxgCeMDDH
YDnMSc72r0z3eOCZIULKjXw=
=PW52
-----END PGP SIGNATURE-----

--------------enig87A42F173317B240EA9E59D5--


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 jBFFuge10540 for <[e-mail]>; Thu, 15 Dec 2005 07:56:42 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBFFuYdJ017450; Thu, 15 Dec 2005 10:56:34 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27180;  Thu, 15 Dec 2005 10:56:33 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BL3HCQ>; Thu, 15 Dec 2005 10:56:33 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Stewart Bryant <[e-mail]>
Date: Thu, 15 Dec 2005 10:56:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 15:56:57 -0000
Status: RO
Content-Length: 2745

Stewart,

	I am not sure I understand your statement.  Maybe you 
could put together a little ASCII art picture to make it 
clearer?  :-)

	Guessing what you mean, however, I get this picture:

                   ,---> RB1 <---> *
                  /
      * <----> (?)
                  \
                   `---> RB2 <---> *

Where * = rest-of-world AND (?) = whatever-is-in-your-closet

In order to understand why RB1 and RB2 might not be able to
operate in a load distribution model, we really have to know
more about - at least - what is in the rest-of-world, from a
topology and devices perspective. Where, for instance is the
RBridge campus?

	Another picture that might apply to your question is:

                   ____
                  /    \
      * <----> (?)      RB1 <---> *
                  \____/

In this picture, we need to know a lot less about the topology
of the rest-of-world.  With STP, RB1 almost certainly will put 
one of the two interfaces to whatever-is-in-your-closet in the 
non-forwarding mode while - without STP it never has to. 

In that case, the service (efficiency) without STP is better.

The question is whether or not we can specify the behavior of
RBridges within a TRILL architecture such that the first figure
above can be made to have the simpler world-view and many of
the same advantages of the second figure above.

I believe we can, assuming that the RBridge campus extends to
the right side in such a way that RB1 and RB2 are part of the
same RBridge campus on that side.  I also believe we can if 
we can stop arguing about whether or not we should.  I am sure 
I am not misreading the WG charter when I interpret what it 
says to mean that we should look to make things work this way.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Stewart Bryant
--> Sent: Thursday, December 15, 2005 3:49 AM
--> To: [e-mail]; Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] it's time to summarize things
--> 
--> Radia
--> 
--> >
--> >It looks like the thread of whether RBridges participate
--> >in spanning tree popped up again. I thought that had been
--> >resolved.
--> >
--> >RBridges should NOT participate in spanning tree, which means
--> >they should DROP spanning tree messages.
--> >  
--> >
--> 
--> Which surely means that a dual connected wiring closet gets
--> worse service from an RBridge network than a ST network
--> (because all the traffic goes one way rather than being
--> shared over both paths).
--> 
--> Stewart
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFFXfe04683 for <[e-mail]>; Thu, 15 Dec 2005 07:33:42 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBFFXYdJ016824; Thu, 15 Dec 2005 10:33:34 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23499;  Thu, 15 Dec 2005 10:33:33 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BL3GC8>; Thu, 15 Dec 2005 10:33:32 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 15 Dec 2005 10:33:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 15:33:52 -0000
Status: RO
Content-Length: 3809

Radia and all, 

	I've included some detailed responses below, but the 
short answer is that I completely agree with Radia...

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Radia Perlman
--> Sent: Thursday, December 15, 2005 1:02 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] it's time to summarize things
--> 
--> 
--> 
--> Joe Touch wrote On 12/14/05 21:33,:
--> > 
--> 
--> > Routers terminate L2 broadcasts. Rbridges cannot. Routers decrement L3
--> > TTLs. Rbridges cannot. So the assertion that an rbridge campus should
--> > drop BPDUs - just like routers - doesn't follow.
--> 
--> I really don't understand what you're saying. RBridges can
--> terminate some L2 broadcasts, in particular, spanning tree messages.
--> True, RBridges will not decrement L3 TTLs.

At one point, we were talking about a TTL field in the encapsulation
for RBridge to RBridge tunneled packets.  I am not sure what happened
to that idea.

--> And perhaps the assertion that RBridges should drop BPDUs does not
--> follow from the previous two sentences, but regardless, they
--> should drop BPDUs because that's what works, that's what is
--> simple, that's what makes the combination of bridging and RBridging
--> more robust than bridging alone, that's what preserves transparency
--> to layer 3 and yet increases robustness.

Clearly I completely agree with this argument.

--> > 
--> > So at the very least we need to explain the reason for this behavior
--> > more clearly, in a way that does not refer to routers as equivalent.
--> 
--> Hopefully the above explains why it has to work this way. We want
--> to break up the spanning tree into smaller and smaller spanning
--> trees, hopefully eventually getting rid of them entirely and
--> just having one big link state routed zero configuration 
--> infrastructure.
--> 

I believe this is consistent with the WG's charatered objectives.

--> 
--> > 
--> > AFAICT, having an rbridge campus drop BPDUs makes sense only by
--> > effectively considering the rbridge campus as the root of all trees,
but
--> > that presumes it is always _the_ root (that there is only one 'drops
--> > BPDU' system per bridged LAN). Since there's no way to enforce that
--> > assertion, it seems problematic.
--> > 
--> > Joe
--> 
--> The above paragraph makes absolutely no sense to me.
--> 
--> Routers drop spanning tree messages, and the world winds up with
--> lots of isolated spanning trees. The same thing happens with
--> RBridges. If there were a problem with doing it this way,
--> IP mixed with bridges would not work.
--> 

The argument that edge RBridges should do something about BPDUs
(other than drop them) proceeds from a suspicion that RBridges 
will not always be able to detect a loop that is external to the
RBridge campus.  This implies that <something> - out of either
malicious design or accident - will consistently drop RBridge 
hello/discovery PDUs.

Unless we decide to use BPDUs, this is a paranoid suspicion.
Bridges do not consistenly drop any kind of frames unless this
is part of the specified behavior for bridges.  The same will
also apply to other technologies.

There is a possibility that RBridge interactions may interfere
with propagation of RBridge hello/discovery PDUs, but we are in
the process of defining how RBridges work - so we can finesse
that as we go along, by either prohibiting anti-social behviors
or by specifying how such interactions can work.

So, as Radia says, there is no reason what-so-ever to encourage
RBridges to particpate in STP/RSTP.

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


Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFFMne01364 for <[e-mail]>; Thu, 15 Dec 2005 07:22:49 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 49F499E3FE for <[e-mail]>; Thu, 15 Dec 2005 16:22:43 +0100 (CET)
Received: from [163.117.139.76] (gibanez.it.uc3m.es [163.117.139.76]) by smtp01.uc3m.es (Postfix) with ESMTP id B74799E231 for <[e-mail]>; Thu, 15 Dec 2005 16:22:40 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 15 Dec 2005 16:22:39 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 15:23:51 -0000
Status: RO
Content-Length: 1747

   Stewart,
    You are right. The core, whatever formed by bridges or Rbridges, 
must "take charge" of the traffic. Letting spanning trees to be
built freely leads to lose control and suboptimality.
Guillermo

Stewart Bryant wrote:

>Radia Perlman wrote:
>
>  
>
>>I think I might need a picture of what you're saying, but I think it's 
>>just the
>>opposite. RBridges can path split, just like routers can, whereas if the
>>spanning tree turns off one of the links, then a bridge would only use 
>>one of
>>the paths.
>>    
>>
>
>The SPT situation is as follows:
>
>     +----+
>-----|    |    L1
>-----| B1 |---------->To core
>-----|    |
>     +----+
>        |
>        | L3
>        |
>     +----+
>-----|    |    L2
>-----| B2 |---------->To core
>-----|    |
>     +----+
>
>You want
>B1 to connect a bunch of systems to the main network via L1
>B2 to connect a different bunch of systems to the main network via L2
>
>So you set B1 and B2 with low priority, so the root is to the
>right in the main network, and the ports connecting B1 and B2 to L3
>go into blocking.
>
>Say most of the traffic is to some server S. This traffic will
>be load balanced over both links L1 and L2.
>
>Now replace the core with an Rbridge network, but leave B1 and B2
>running SPT (because you can't upgrade the wiring closets - there are
>too many of them)
>
>How does the traffic from B1 and B2 to S get load balanced
>via L1 and L2?
>
>- Stewart
>
>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

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



Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFF82e27132 for <[e-mail]>; Thu, 15 Dec 2005 07:08:03 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B30139E134; Thu, 15 Dec 2005 16:07:56 +0100 (CET)
Received: from [163.117.139.76] (gibanez.it.uc3m.es [163.117.139.76]) by smtp01.uc3m.es (Postfix) with ESMTP id DA32E9E185; Thu, 15 Dec 2005 16:07:55 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 15 Dec 2005 16:07:54 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 15:08:53 -0000
Status: RO
Content-Length: 5708

Radia,
        

Radia Perlman wrote:

>I just got back from a bunch of travel, and was trying to catch
>up on the mailing list, and it's really so long.
>
>It looks like the thread of whether RBridges participate
>in spanning tree popped up again. I thought that had been
>resolved.
>
>RBridges should NOT participate in spanning tree, which means
>they should DROP spanning tree messages.
>
>An RBridge should NOT merge spanning trees. It should terminate
>spanning trees, just like routers do.
>
>However things have
>to work properly if two of an RBridge's ports are in the same
>broadcast domain (either because they are the same
>physical link or because a path of bridges connects those
>two ports of the RBridge. Just like routers handle this case just
>fine, RBridges will handle the case just fine.
>
>One person (I forget who) brought up a case ahile ago where they thought
>it would be advantageous for an RBridge to participate in
>spanning tree (so that it could cause itself to be
>elected Root).
>
I am the person you refer.

> I'm not convinced this is an important
>feature, but it can be handled by having the RBridge
>pretend to be two boxes glued together: an ordinary bridge,
>directly connected to the port, with a point-to-point imaginary
>link to an RBridge. The person agreed this idea could be
>built, and would give any advantages that might be gained
>by having RBridges particpate in spanning tree, while
>still maintaining the simple premise that RBridges,
>like routers, operate above spanning tree, and do nothing
>with spanning tree other than recognize that layer 2
>multicast address and drop packets sent to that address.
>  
>
I do agree

>If this (i.e., RBridges drop spanning tree messages)
>is not the understanding at this point, can someone
>summarize (succinctly, without cutting and
>pasting from zillions of email messages, which I find
>hard to follow) what the problem with this is?
>
>  
>
There is a lot of discussion going on . I make here some fast comments 
to state my position.
The point is that in my opinion DR election among Rbridges connected to 
same "link" (stp bridged area)
may be performed by the Root bridge election mechanism or a combined 
mechanism of both(DR and root election) , to be designed. I see 
advantages in this use of integration with the frame forwarding 
mechanism of stp (root bridge is the best position for it and for 
ingressing traffic into the Rbridge campus)
The current discussion on alternative modes (BLOCK, PARTICIPATE, etc) 
reflects the dilemma that derives from the need  Rbridges have to 
*control the tree connected to them*, to ingress and egrees traffic 
from/to them.
I see two options for predecibility of network.
1.-If only one Rbridge is allowed to become DR (i.e.root) of its link, 
some Rbridges (those not being elected) will not forward traffic of some 
ot the links they are connected to, because other connected Rbridge does 
the forwarding.
2.- If we allow any Rbridge to ingress/egress traffic to the Rbridge 
campus  we need to allow to split the link spanning tree in to 
independent segments, each one connected to an Rbridge (acting as 
independent root bridge or something equivalent). This goes a bit 
against the "unique" spanning tree dogma, but can be safe in an Rbridge 
controlled environment, provided each Rbridge acts as Root bridge to 
inject traffic to core network.
In my opinion, much of the complexitiy and confusion derives from the 
decision to allow bridges to interpose between Rbridges.
This makes many  links internal (whenever there is another Rbridge 
heard) and external (whenever they have an end system connected) at the 
same time. Using this term  in this way is  only confusing.
This flexibility of allowing standard bridges betwen Rbridges, as you 
know well, implies also the need to rewrite the destination Rbridge in 
the frame header at each hop with the next hop, a not very nice feature 
of the protocol proposed.  I find excesive in this case the price paid 
for  full compatibility with standard bridges.
In my recently submitted I-D draft   
(http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt)  
I  propose, among other variants to Rbridges,  the topological 
restriction of  Rbridges being connected directly  by point to point 
links (which make sense talking of  campus network cores, oriented to 
performance).  By using an automatic compatibility mechanism like the 
one used in 802.1D for compatibility between STP and RSTP protocols, a 
port will set itself as "internal"  (core port in the draft) if it hears 
Rbridge hellos (or Rbridge related BPDUs) and  as "external" port 
("access" port) port mode. In this way the "external" links are excluded 
from the Rbridge core and the obtained core is fully composed of 
interconnected Rbridges.
In RSTP, a port hearing STP BPDUs in its link, switches to STP mode. It 
initializes to RSTP mode if it hears RSTP BPDUs upon initialization. 
(Protocol migration state machine).

As a summary I would say that it is difficult to ignore completely stp 
and links, Rbridges must PARTICIPATE in stp only as Root bridges or end 
nodes.
The compatibility clause (B-RB implementation) is acceptable, although 
is not perfect in my opinion  because I see the participation as Root as 
important for controlling the tree below Rbridge and to perform the DR 
function.
Guillermo

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

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



Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFEsFe23232 for <[e-mail]>; Thu, 15 Dec 2005 06:54:15 -0800 (PST)
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 15 Dec 2005 15:54:09 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBFEs6FZ020167;  Thu, 15 Dec 2005 15:54:07 +0100 (MET)
Received: from [64.103.64.233] (dhcp-rea-gp250-64-103-64-233.cisco.com [64.103.64.233]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA11695; Thu, 15 Dec 2005 14:54:05 GMT
Message-ID: <[e-mail]>
Date: Thu, 15 Dec 2005 14:54:05 +0000
From: Stewart Bryant <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 14:55:00 -0000
Status: RO
Content-Length: 1155

Radia Perlman wrote:

> I think I might need a picture of what you're saying, but I think it's 
> just the
> opposite. RBridges can path split, just like routers can, whereas if the
> spanning tree turns off one of the links, then a bridge would only use 
> one of
> the paths.

The SPT situation is as follows:

     +----+
-----|    |    L1
-----| B1 |---------->To core
-----|    |
     +----+
        |
        | L3
        |
     +----+
-----|    |    L2
-----| B2 |---------->To core
-----|    |
     +----+

You want
B1 to connect a bunch of systems to the main network via L1
B2 to connect a different bunch of systems to the main network via L2

So you set B1 and B2 with low priority, so the root is to the
right in the main network, and the ports connecting B1 and B2 to L3
go into blocking.

Say most of the traffic is to some server S. This traffic will
be load balanced over both links L1 and L2.

Now replace the core with an Rbridge network, but leave B1 and B2
running SPT (because you can't upgrade the wiring closets - there are
too many of them)

How does the traffic from B1 and B2 to S get load balanced
via L1 and L2?

- Stewart





Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBFEjBe20996 for <[e-mail]>; Thu, 15 Dec 2005 06:45:11 -0800 (PST)
Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165]) by comcast.net (rwcrmhc12) with SMTP id <20051215144505014008pd1qe>; Thu, 15 Dec 2005 14:45:05 +0000
Message-ID: <068601c60186$06c58050$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]><[e-mail]> <[e-mail]><[e-mail]> <[e-mail]>
Date: Thu, 15 Dec 2005 08:44:16 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 14:45:53 -0000
Status: RO
Content-Length: 1856

Hi, Stewart,

I *know* that I need a picture of what you're saying. My immediate reaction 
was exactly the same as Radia's. I definitely want to better understand why 
I don't understand what you're saying.

In general, there are IP guys in this working group (I am one of them) with 
a decent understanding of bridging, but without a detailed knowledge of 
corner cases. If people who DO have a detailed knowledge of corner cases can 
explain fairly precisely what the situation is, it would help those of us 
who don't have that knowledge.

And, of course, the alternative is having a few people doing the work and 
everyone else trusting them, which can happen perfectly well without an IETF 
working group at all :-)

Thanks,

Spencer


>I think I might need a picture of what you're saying, but I think it's
> just the
> opposite. RBridges can path split, just like routers can, whereas if the
> spanning tree turns off one of the links, then a bridge would only use
> one of
> the paths.
>
> As I said, not sure of the exact topology you mean by "dual connected
> wiring closet"
> (please supply picture), but if that topology works with routers, then
> it will
> work with RBridges. Being an RBridge is really like being a router, but
> the destination is a layer
> 2 address rather than an IP address.
>
> Radia
>
>
>
> Stewart Bryant wrote:
>
>> Radia
>>
>>>
>>> It looks like the thread of whether RBridges participate
>>> in spanning tree popped up again. I thought that had been
>>> resolved.
>>>
>>> RBridges should NOT participate in spanning tree, which means
>>> they should DROP spanning tree messages.
>>>
>>>
>>
>> Which surely means that a dual connected wiring closet gets
>> worse service from an RBridge network than a ST network
>> (because all the traffic goes one way rather than being
>> shared over both paths).
>>
>> Stewart 



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 jBFDqhe07740 for <[e-mail]>; Thu, 15 Dec 2005 05:52:43 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 15 Dec 2005 05:52:34 -0800 (PST)
Received: from sun.com ([129.150.24.128]) 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, 15 Dec 2005 05:52:34 -0800 (PST)
Date: Thu, 15 Dec 2005 05:52:35 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Stewart Bryant <[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]> <[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: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 13:52:58 -0000
Status: RO
Content-Length: 1069

I think I might need a picture of what you're saying, but I think it's 
just the
opposite. RBridges can path split, just like routers can, whereas if the
spanning tree turns off one of the links, then a bridge would only use 
one of
the paths.

As I said, not sure of the exact topology you mean by "dual connected 
wiring closet"
(please supply picture), but if that topology works with routers, then 
it will
work with RBridges. Being an RBridge is really like being a router, but 
the destination is a layer
2 address rather than an IP address.

Radia



Stewart Bryant wrote:

> Radia
>
>>
>> It looks like the thread of whether RBridges participate
>> in spanning tree popped up again. I thought that had been
>> resolved.
>>
>> RBridges should NOT participate in spanning tree, which means
>> they should DROP spanning tree messages.
>>  
>>
>
> Which surely means that a dual connected wiring closet gets
> worse service from an RBridge network than a ST network
> (because all the traffic goes one way rather than being
> shared over both paths).
>
> Stewart




Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBF8nMe22218 for <[e-mail]>; Thu, 15 Dec 2005 00:49:22 -0800 (PST)
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 15 Dec 2005 09:49:16 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBF8nDFZ002246;  Thu, 15 Dec 2005 09:49:13 +0100 (MET)
Received: from [10.61.65.8] (ams-clip-vpn-dhcp264.cisco.com [10.61.65.8]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA09699; Thu, 15 Dec 2005 08:49:11 GMT
Message-ID: <[e-mail]>
Date: Thu, 15 Dec 2005 08:49:10 +0000
From: Stewart Bryant <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 08:49:53 -0000
Status: RO
Content-Length: 457

Radia

>
>It looks like the thread of whether RBridges participate
>in spanning tree popped up again. I thought that had been
>resolved.
>
>RBridges should NOT participate in spanning tree, which means
>they should DROP spanning tree messages.
>  
>

Which surely means that a dual connected wiring closet gets
worse service from an RBridge network than a ST network
(because all the traffic goes one way rather than being
shared over both paths).

Stewart


Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBF622e13084 for <[e-mail]>; Wed, 14 Dec 2005 22:02:02 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jBF6223F006721 for <[e-mail]>; Wed, 14 Dec 2005 23:02:02 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 15 Dec 2005 01:02:02 -0500 (EST)
Received: from Sun.COM (sr1-umpk-19.SFBay.Sun.COM [129.146.11.205]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Thu, 15 Dec 2005 01:02:02 -0500 (EST)
Date: Wed, 14 Dec 2005 22:02:01 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 06:03:54 -0000
Status: RO
Content-Length: 1801

Joe Touch wrote On 12/14/05 21:33,:
> 

> Routers terminate L2 broadcasts. Rbridges cannot. Routers decrement L3
> TTLs. Rbridges cannot. So the assertion that an rbridge campus should
> drop BPDUs - just like routers - doesn't follow.

I really don't understand what you're saying. RBridges can
terminate some L2 broadcasts, in particular, spanning tree messages.
True, RBridges will not decrement L3 TTLs.
And perhaps the assertion that RBridges should drop BPDUs does not
follow from the previous two sentences, but regardless, they
should drop BPDUs because that's what works, that's what is
simple, that's what makes the combination of bridging and RBridging
more robust than bridging alone, that's what preserves transparency
to layer 3 and yet increases robustness.
> 
> So at the very least we need to explain the reason for this behavior
> more clearly, in a way that does not refer to routers as equivalent.

Hopefully the above explains why it has to work this way. We want
to break up the spanning tree into smaller and smaller spanning
trees, hopefully eventually getting rid of them entirely and
just having one big link state routed zero configuration infrastructure.


> 
> AFAICT, having an rbridge campus drop BPDUs makes sense only by
> effectively considering the rbridge campus as the root of all trees, but
> that presumes it is always _the_ root (that there is only one 'drops
> BPDU' system per bridged LAN). Since there's no way to enforce that
> assertion, it seems problematic.
> 
> Joe

The above paragraph makes absolutely no sense to me.

Routers drop spanning tree messages, and the world winds up with
lots of isolated spanning trees. The same thing happens with
RBridges. If there were a problem with doing it this way,
IP mixed with bridges would not work.

Radia



Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBF5dRe08023 for <[e-mail]>; Wed, 14 Dec 2005 21:39:27 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jBF5dQ3F020163 for <[e-mail]>; Wed, 14 Dec 2005 22:39:26 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 15 Dec 2005 00:39:26 -0500 (EST)
Received: from Sun.COM (sr1-umpk-19.SFBay.Sun.COM [129.146.11.205]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Thu, 15 Dec 2005 00:39:26 -0500 (EST)
Date: Wed, 14 Dec 2005 21:39:25 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <05b901c60136$077b2310$[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214
References: <[e-mail]> <[e-mail]> <[e-mail]> <05b901c60136$077b2310$[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 05:39:50 -0000
Status: RO
Content-Length: 2978

Yes Spencer,

You understood my note, and I'm glad you
agree with it. Apparently there was some confusion about
taking the phrase "looking like a bridge" too literally.

An RBridge campus should look like a single broadcast domain
to layer 3 devices, but that doesn't mean an RBridge should participate
in spanning tree, any more
than that if it had two token ring interfaces, that it should
pass the token from one interface to another. (though hopefully
this analogy won't confuse people, since a station on a
token ring *does* have to pass the token within that ring...
however an Ethernet endnode does NOT have to participate
in spanning tree (nor should it), and likewise, an RBridge
does not have to participate in spanning tree.

I think people were perhaps getting hung up on "layer n". Whatever
you call it, bridges are a lower layer than RBridges, and
RBridges are a lower layer than IP. So we could call RBridges
layer 2.5 if we insisted on giving them a layer name.

Radia



Spencer Dawkins wrote On 12/14/05 21:11,:
> Dear All (following up from Radia's note),
> 
> 
> 
>>I just got back from a bunch of travel, and was trying to catch
>>up on the mailing list, and it's really so long.
>>
>>It looks like the thread of whether RBridges participate
>>in spanning tree popped up again. I thought that had been
>>resolved.
>>
>>RBridges should NOT participate in spanning tree, which means
>>they should DROP spanning tree messages.
>>
>>An RBridge should NOT merge spanning trees. It should terminate
>>spanning trees, just like routers do.
> 
> 
> I believe one idea has contributed to this - the idea that an RBRIDGE campus 
> should look like a single very large bridge at its interfaces, which implies 
> (in at least some e-mail) that it participates in the same spanning tree on 
> both sides.
> 
> My apologies for cut-and-pasting, but the discussion has looked like this, 
> in recent e-mail:
> 
> 
>>--> > --> #1 resolve recommendations for the three modes of
>>--> BSTP messages:
>>--> > -->    (is this part of the PS or ARCH?)
>>--> > --> participate
>>--> > --> forward
>>--> > --> block
>>--> >
>>--> > Block by default.  Optional configuration for forwarding and/or
>>--> > participating MAY be allowed but SHOULD be considered sub-optimal.
>>-->
>>--> Forward maps to what hubs do.
>>--> Participate maps to what bridges do.
> 
> 
> My understanding of Radia's note is that an RBRIDGE campus looks like one 
> very large router at its interfaces (no spanning tree, so no spanning tree 
> merge).
> 
> If I am not misunderstanding Radia's note, I like this answer, because it 
> looked like a lot of work to figure out what to do, in order to look like 
> one very large bridge. If this is the high-order bit, things are clearer.
> 
> Am I reading the note correctly? And do others agree?
> 
> Spencer 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge



Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBF5Xne06499; Wed, 14 Dec 2005 21:33:49 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 14 Dec 2005 21:33:38 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0F339CD7F59B55172D4991D1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 05:38:51 -0000
Status: RO
Content-Length: 1910

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



Radia Perlman wrote:
> I just got back from a bunch of travel, and was trying to catch
> up on the mailing list, and it's really so long.
>=20
> It looks like the thread of whether RBridges participate
> in spanning tree popped up again. I thought that had been
> resolved.
>=20
> RBridges should NOT participate in spanning tree, which means
> they should DROP spanning tree messages.
>=20
> An RBridge should NOT merge spanning trees. It should terminate
> spanning trees, just like routers do.

I'm one of the ones confused by the use of routers as an analog.

Routers terminate L2 broadcasts. Rbridges cannot. Routers decrement L3
TTLs. Rbridges cannot. So the assertion that an rbridge campus should
drop BPDUs - just like routers - doesn't follow.

So at the very least we need to explain the reason for this behavior
more clearly, in a way that does not refer to routers as equivalent.

AFAICT, having an rbridge campus drop BPDUs makes sense only by
effectively considering the rbridge campus as the root of all trees, but
that presumes it is always _the_ root (that there is only one 'drops
BPDU' system per bridged LAN). Since there's no way to enforce that
assertion, it seems problematic.

Joe



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

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

iD8DBQFDoQA2E5f5cImnZrsRAhtHAJsFaPm8ZcXl6zollBbt5RWFR0rbVACeNXMa
cBgWRnAe0luYuktwJLMylg8=
=xjl7
-----END PGP SIGNATURE-----

--------------enig0F339CD7F59B55172D4991D1--


Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBF5CXe01447 for <[e-mail]>; Wed, 14 Dec 2005 21:12:33 -0800 (PST)
Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165]) by comcast.net (rwcrmhc13) with SMTP id <20051215051227015004u0mte>; Thu, 15 Dec 2005 05:12:27 +0000
Message-ID: <05b901c60136$077b2310$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]><[e-mail]> <[e-mail]>
Date: Wed, 14 Dec 2005 23:11:38 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 05:12:53 -0000
Status: RO
Content-Length: 1738

Dear All (following up from Radia's note),


>I just got back from a bunch of travel, and was trying to catch
> up on the mailing list, and it's really so long.
>
> It looks like the thread of whether RBridges participate
> in spanning tree popped up again. I thought that had been
> resolved.
>
> RBridges should NOT participate in spanning tree, which means
> they should DROP spanning tree messages.
>
> An RBridge should NOT merge spanning trees. It should terminate
> spanning trees, just like routers do.

I believe one idea has contributed to this - the idea that an RBRIDGE campus 
should look like a single very large bridge at its interfaces, which implies 
(in at least some e-mail) that it participates in the same spanning tree on 
both sides.

My apologies for cut-and-pasting, but the discussion has looked like this, 
in recent e-mail:

> --> > --> #1 resolve recommendations for the three modes of
> --> BSTP messages:
> --> > -->    (is this part of the PS or ARCH?)
> --> > --> participate
> --> > --> forward
> --> > --> block
> --> >
> --> > Block by default.  Optional configuration for forwarding and/or
> --> > participating MAY be allowed but SHOULD be considered sub-optimal.
> -->
> --> Forward maps to what hubs do.
> --> Participate maps to what bridges do.

My understanding of Radia's note is that an RBRIDGE campus looks like one 
very large router at its interfaces (no spanning tree, so no spanning tree 
merge).

If I am not misunderstanding Radia's note, I like this answer, because it 
looked like a lot of work to figure out what to do, in order to look like 
one very large bridge. If this is the high-order bit, things are clearer.

Am I reading the note correctly? And do others agree?

Spencer 



Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBF1WWe10336 for <[e-mail]>; Wed, 14 Dec 2005 17:32:32 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jBF1WV3F020202 for <[e-mail]>; Wed, 14 Dec 2005 18:32:31 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Wed, 14 Dec 2005 20:32:31 -0500 (EST)
Received: from Sun.COM (sr1-umpk-19.SFBay.Sun.COM [129.146.11.205]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 14 Dec 2005 20:32:31 -0500 (EST)
Date: Wed, 14 Dec 2005 17:32:30 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214
References: <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] it's time to summarize things
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2005 01:32:55 -0000
Status: RO
Content-Length: 1812

I just got back from a bunch of travel, and was trying to catch
up on the mailing list, and it's really so long.

It looks like the thread of whether RBridges participate
in spanning tree popped up again. I thought that had been
resolved.

RBridges should NOT participate in spanning tree, which means
they should DROP spanning tree messages.

An RBridge should NOT merge spanning trees. It should terminate
spanning trees, just like routers do.

However things have
to work properly if two of an RBridge's ports are in the same
broadcast domain (either because they are the same
physical link or because a path of bridges connects those
two ports of the RBridge. Just like routers handle this case just
fine, RBridges will handle the case just fine.

One person (I forget who) brought up a case ahile ago where they thought
it would be advantageous for an RBridge to participate in
spanning tree (so that it could cause itself to be
elected Root). I'm not convinced this is an important
feature, but it can be handled by having the RBridge
pretend to be two boxes glued together: an ordinary bridge,
directly connected to the port, with a point-to-point imaginary
link to an RBridge. The person agreed this idea could be
built, and would give any advantages that might be gained
by having RBridges particpate in spanning tree, while
still maintaining the simple premise that RBridges,
like routers, operate above spanning tree, and do nothing
with spanning tree other than recognize that layer 2
multicast address and drop packets sent to that address.

If this (i.e., RBridges drop spanning tree messages)
is not the understanding at this point, can someone
summarize (succinctly, without cutting and
pasting from zillions of email messages, which I find
hard to follow) what the problem with this is?

Radia



Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBEMXbe19246; Wed, 14 Dec 2005 14:33:37 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 14 Dec 2005 14:31:40 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Arch Issue #1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 14 Dec 2005 22:34:08 -0000
Status: RO
Content-Length: 16781

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



Gray, Eric wrote:
> Joe,
> 
> 	We're not converging in this discussion and part of the
> reason why appears to be that there is still some considerable
> confusion about the first principles of what we're trying to 
> accomplish, and how those principles affect the architecture.
> 
> 	Consequently, I believe we should break this discussion up 
> and start new discussions on the following NEW architectural 
> issues:
> 
> o What Are the Important Aspects of Bridge Behavior and How Do
>   They Impact RBridges and/or the TRILL Architecture?
> o What is the Role of the Hello Protocol?
> o What Are the Assumptions About How Hello Protocol Works?
> o How do RBridge Campus Models map to BPDU Handling Modes?
> o (When) Does Block (BPDU Handling Mode) Work?
> o Sub-Optimality Issues of Block Mode(s)
> o What Does Participate (BPDU Handling Mode) Mean?
> o Sub-Optimality Issues of Participate Mode(s)
> o What Does Forward (BPDUs) Mean?
> o Sub-Optimality Issues of Forward Mode(s)]

These sound good to me.

> To close on relatively minor sub-issues:
> 
> -> > Many things do not participate in STP now and some forward 
> -> > (like the above) while others block.
> ->
> -> Far as I've been able to find out, the things that block are 
> -> known as "broken". 
> 
> Nice, ringing, phraseology - however, not true.
> 
> Let's take a typical current technology - bridging-capable
> routers.
> 
> Word around this list is that routers (want to) terminate 
> a broadcast domain at each router interface.

As per RFC1812.

> Sadly, they 
> don't always have the option to do this.

That's when they're not routers anymore.

> If a broadcast domain on one router interface surreptitiously
> becomes connected to a broadcast domain on another interface
> of the same router, one of three things happens:
> 
> 1) The network breaks (not the most robust alternative)

This seems like the right thing; the network breaks when you break its
protocol requirements.

> 2) The router switches to bridging mode between the now
>    connected interfaces (including participating in STP)

At that point it behaves like a bridge connected to a router, i.e., that
the bridge connects the two interfaces, which are also bridged to the
router. That's fine, and understandable as a commercial device.

> 3) The router recognizes that the two interfaces share
>    a common broadcast domain and adopts a reasonable mode
>    of operation consistent with this knowledge (including 
>    load sharing, ARP sharing, etc. - and _NOT_ including 
>    STP participation or forwarding).

That's when the router is starting to second-guess what it means do be a
bridge, 'assuming' it knows what to forward and why. And when the
second-guessing is incorrect, things (predictably) break.

> You might ask "why would a router adopt behavior number
> 3 when behavior number 2 works?"

Indeed ;-)

> To answer this, look at these two scenarios:
> 
> 1)         (N1)        (N2)        (N3)
>                \_    _/    \_    _/
>                  \  /        \  /
>                   R1          R2
>                 _/  \_      _/  \_
>                /      \    /      \
>            (N4)        (N5)        (N6)
>                \_                _/
>                  \_____    _____/
>                        \  /
>                         B*
> 
> 2)         (N1)        (N2)        (N3)
>                \_    _/    \_    _/
>                  \  /        \  /
>                   R1          R2
>                 _/  \_      _/  \_
>                /      \    /      \
>            (N4)        (N5)        (N6)
>                \_    _/
>                  \  /
>                   B*
> 
> In both of these cases, separately routed networks have
> become a single broadcast domain through the addition of
> a new bridge (B*) added between the previously separate
> networks (N4+N6 in example 1 and N4+N5 in example 2).
> 
> So, the answer to the question above is that there is no
> _good_ reason why scenario 1 should work and scenario 2
> should not. 

Agreed.

> However, a very quick analysis will tell you
> that scenario 1 works.  N4+N6 is topologically identical
> to either N2 or N5 in that it connects R1 to R2.

Agreed.

> Consequently, scenario 2 should work

Agreed.

> and - by analogy -
> the _best_mode_ would be for it to work in the same way
> that scenario 1 works. This mode is both less traumatic
> and more efficient...

This is the point where second-guessing comes in. That's what STP is
there for - so the router doesn't have to second-guess.

> -> If you can point to something specific that blocks that is 
> -> widely used - or that is compliant with spec - that'd be 
> -> useful.
> 
> So this is a rediculous request. 

We're talking about protocols; the spec I'm referring to is 802.1D (or
thereabouts), i.e., STP (and its derivatives).

I'm asking why we are trying to support something. Either that something
is compliant with the spec OR it's in wide use. Both of those are
reasons to support it.

If all it does is violate the spec, then what's the point in trying to
support it?

> The "spec" you refer to
> is presumably the 802.1 specification, consequently it is
> not possible to "point to something that blocks [and] is
> compliant with the spec"

I used "or", not "and".

> and it is not very interesting to
> "point to something that blocks [or] is complaint with the 
> spec".

I said "blocks that is widely used".

I intended the latter alternative to be "blocks that is compliant with
the spec" (i.e., a valid interpretation of the spec that allows blocking).

> Simply consider that not everything in the world is going
> to be consistent with the spec and yet things still work.

This argues that 'we' should violate the spec (i.e., not based on
whether others have before). How can we assert stability or safety of a
system where we violate an exising spec, when that stability/safety
assumes that all successors obey _our_ spec?

> -> > ---> > 
> -> > ---> > Participate maps to what bridges do.
> -> > 
> -> > Most bridges.  Mostly agree.
> -> > 
> -> > ---> > 
> -> > ---> > As a result, either of those can easily be considered as 
> -> > ---> > default cases, though forward is clearly suboptimal.
> -> > 
> -> > "Participate" can be sub-optimal as well, assuming that we're
> -> > talking about simple participation.
> -> > 
> -> > In simple participation, an RBridge participates with bridges
> -> > both internal and external to the RBridge campus. This makes
> -> > for a single spanning tree and effectively cancels any hopes
> -> > we might have for efficient use of bandwidth - even internal
> -> > to the RBridge campus.
> -> 
> -> We haven't talked about the internal transit requirements before;
> -> bridges there ARE going run STP/MSTP and coalesce into trees anyway 
> -> (you can't stop that). It doesn't matter if such trees touch two 
> -> rbridges - there can still be independent paths between the rbridges 
> -> (though that needs to be engineered; if they connect anywhere in the 
> -> middle, the as you note, the bridging will end up killing the 
> -> possibility of multipath).
> 
> We have talked about this, unless you've been letting someone
> else use your E-Mail account.
> 
> You argued - fairly convincingly - that it would not normally
> be possible for there to be more than one RBridge campus in a
> single broadcast domain.  How did you suppose this to be the
> case if we were not considering "internal transit requirements"?

The more recent point is that such requirements persist whether there is
more than one rbridge campus or not, since you cannot know whether there
are such multiple bridges.

> -> > In order for this approach to work, internal RBridge 
> -> > interfaces MUST be eligible to be put in a non-forwarding 
> -> > state by the STP, and - once this is done - they cannot be
> -> > used by SPF frame forwarding.
> -> 
> -> We really need to resolve the discussion of what an 'internal 
> -> rbridge interface' is before this sentence can be interpreted 
> -> completely.
> 
> I don't think anyone other than you is having trouble with 
> the meaning of 'internal rbridge interface' in this context.

Few others have participated in this part of the discussion except you,
Guillermo, and I. It's hard to assert anything general given three inputs.

> It is simply an interface that forms a circuit either with 
> one or more additional RBridges, or zero or more additional
> RBridges and another interface of itself.  That is, if the 
> RBridge is an ingress or egress RBridge, an internal RBridge 
> interface is one on which it will transmit frames it is the 
> ingress for, or receives frames it is the egress for.

The issue isn't that the meaning is hard to understand; the issue is
that the term is inaccurate. Hosts can - and will - sit on that
interface. I was trying to reserve internal/external for a distinction
between traffic between rbridges and traffic from ingress/egress to
hosts - where inside/outside meant 'inside the campus' (invisible to
hosts) and 'outside to the hosts' (visible to hosts).

It's not clear what 'internal' implies in the definition above, or why
it's useful to consider rbridge-rbridge interfaces the same way as
rbridge-self interfaces.

> The definition - if you want to be picky about it - can be
> harder to get your head around than the concept it defines.
> See the figure (about 2 inches) below...
> 
> -> However, putting an interface (any interface) into a nonforwarding 
> -> state is just what a root bridge would do anyway, which is why I 
> -> consider this a variant of PARTICIPATE.
> 
> Yes, that is what a bridges do, but I think you'll find a root 
> bridge typically does not have any non-forwarding interfaces.

Given two or more interfaces on the same non-bridged segment, the root
bridge should not forward between those.

> But this is not the point.  If one of the working group goals
> is to make efficient use of link bandwidth, then - in the figure
> below - we do not want any 'internal RBridge interfaces' to be in
> a non-forwarding mode.

See above. That's why I don't like that definition of internal.

>       __________
>      /     i.1_ \    ___ i.3
>     (      i.2_>RB-1<___ 1.4
>      \          /
>       \ campus /            i.1 and i.2 are internal interfaces
>        \______/             i.3 and i.4 are external interfaces
> 
> That is to say, RB-1 _might_ put i.3 or i.4 in non-forwarding
> mode (I do not consider this either necessary or ideal), but 
> it should not put i.1 or i.2 in non-forwarding mode.  That is
> why blocking STP is the optimal approach.

The above seems to imply that i.1 and i.2 carry encapsulated traffic and
i.3 and i.4 do not; if _that_ is the definition of internal/external, I
agree. But not otherwise.

> -> > More complex participation - which is what I suspect you are
> -> > referring to - would be along the lines of treating external
> -> > interfaces of all RBridges in a single campus as part of a
> -> > single large bridge (you've previously argued that an RBridge 
> -> > campus may be viewed as a single "virtual bridge").  This is
> -> > more complicated because the STP block and forward decisions
> -> > for all such external interfaces now needs to be collectively
> -> > made (and maintained) across a number of RBridges (all of them
> -> > within a campus). 
> -> 
> -> Those decisions already need to be coordinated. Until you decide 
> -> what's in and out of an rbridge, you don't know what 'internal' 
> -> means anyway.
> 
> These decisions do not have to be "coordinated" in the same sense
> that they would be coordinated between interfaces of a single box.
> 
> What we've talked about so far (in terms of coordination) is how
> we might use IS-IS to share information among RBridges that will
> allow each edge RBridge to build what is effectively a filtering
> database.  The model for frame forwarding within a RBridge campus
> is supposed to be based on routing rather than bridging.
> 
> Consequently, the decision as to which external interfaces are 
> used to (receive) ingress and (transmit) egress frames is both 
> a local decision (which must be made consistently) and a result
> of collective forwarding based on frame routing within a campus.

Agreed - that seems to refer implicitly back to the tunnels I was
referring to.

> In other words, frames should be allowed to arrive at an egress
> RBridge by whatever interface happens to correspond to the SPF
> path to that egress from any ingress.

I'm not sure what the point of this assertion is.

> The bit of coordination that we need to work out is along the 
> lines of who is the designated egress for what frames when more
> that one RBridge is connected to the same 'external' LAN segment.

Agreed.

> -> > That would be a non-trivial exercise using your favorite proprietary 
> -> > approach; it would be impossible to standardize.
> -> 
> -> Things like the HELLO protocol already start in this direction; 
> -> are you suggesting that HELLO will be impossible to standardize? ;-)
> -> 
> 
> In what way is the HELLO protocol going to be involved in working
> out forwarding between RBridges?  As far as I know, in absolutely
> _no_way_ at all.
> 
> HELLO protocol is involved in determing neighbor relationships and
> indirectly allows RBridges to determine campus topology.  That can
> certainly be done.
> 
> Based on the neighbor relationships that RBridges determine, they
> then use link-state routing to determine topology and - finally -
> SPF to determine forwarding. 
> 
> Saying that the HELLO protocol is involved in determining forwarding
> is getting a little ahead of ourselves... 

That's why I said "start in this direction" rather than solve it.
They're clearly involved in the first phase, though.

> -> > For one thing, assuming that the hello/discovery protocol uses
> -> > an appropriate communication layer, then the hello/discovery
> -> > messages MUST be delivered over any non-disfunctional path.
> -> 
> -> Bridges think that's true for BPDUs too; if rbridges block them,
> -> then it is the rbridge that becomes the disfunctional component.
> -> 
> 
> RBridges are not bridges.  Maybe we should call them NBridges
> to make that clearer?

Rbridges are not bridges, but I still think the correct (and best) model
for an rbridge campus is a bridge.

> -> > [D]evices (other than RBridges) will not be able to 
> -> > distinguish RBridge hello/discovery messages from any
> -> > other traffic.
> -> 
> -> Will they be encrypted? If not, we cannot make this assumption.
> -> 
> 
> Let's not be cryptic.  There's a difference between:
> 
> A) being able to distinguish RBridge hello/discovery messages 
>    through some deliberate analysis of frames based on - at 
>    least - a priori knowledge of the existence of RBridges, 
>    TRILL and the hello and discovery protocols, and 

It depends on what the messages look like. If they're broadcast frames
of a control type with a content that is unrecognized, they could be
blocked without a-priori knowledge of their existence.

> B) being unable to distinguish RBridge hello/discovery messages 
>    because they are frames like every other frame it is the 
>    fundamental purpose of LAN devices to forward.

So YOU are allowed to assume that bridges will forward HELLOs because
they ought to be handled like any other frame. The rbridge campus is
supposed to look like a single L2, but rbridges can block BPDUs (which
is never done inside an L2), so the bridges cannot expect similar known
behavior that you expect?

> LAN devices - because they are in the business of forwarding
> frames - will not reject some frames and pass others without
> some prior knowledge and justification.

See above for an example.

> We need to make sure
> that we do not choose a poor frame format that we know will
> be rejected by existing technology and we need to rely on a
> belief that future technologies will not decide to discard 
> TRILL hello/discovery frames without due consideration of the
> effects of doing so.
> 
> Any other set of assumptions is essentially pathological.
> 
> Due consideration is what we are in the process of doing now.
> Note that "due consideration" and "slavish compliance" are 
> not the same thing.  If we want to do something different, we
> are free to do so, as long as we consider the implications.

And the benefits, and whether the benefits outweigh the implications.

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

iD8DBQFDoJ1ME5f5cImnZrsRAsjHAKDaoZYQADNwrcJM6x4hkltrTc+93gCgjT77
f8O0Ev2k0UFzU+kfLacdsMU=
=UWrp
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBEKafe11512 for <[e-mail]>; Wed, 14 Dec 2005 12:36:41 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBEKaZdJ002181 for <[e-mail]>; Wed, 14 Dec 2005 15:36:35 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA02101 for <[e-mail]>; Wed, 14 Dec 2005 15:36:35 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLN2Q3>; Wed, 14 Dec 2005 15:36:34 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Wed, 14 Dec 2005 15:36:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Arch Issue #1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 14 Dec 2005 20:37:01 -0000
Status: RO
Content-Length: 12127

Joe,

	We're not converging in this discussion and part of the
reason why appears to be that there is still some considerable
confusion about the first principles of what we're trying to 
accomplish, and how those principles affect the architecture.

	Consequently, I believe we should break this discussion up 
and start new discussions on the following NEW architectural 
issues:

o What Are the Important Aspects of Bridge Behavior and How Do
  They Impact RBridges and/or the TRILL Architecture?
o What is the Role of the Hello Protocol?
o What Are the Assumptions About How Hello Protocol Works?
o How do RBridge Campus Models map to BPDU Handling Modes?
o (When) Does Block (BPDU Handling Mode) Work?
o Sub-Optimality Issues of Block Mode(s)
o What Does Participate (BPDU Handling Mode) Mean?
o Sub-Optimality Issues of Participate Mode(s)
o What Does Forward (BPDUs) Mean?
o Sub-Optimality Issues of Forward Mode(s)

To close on relatively minor sub-issues:

-> > Many things do not participate in STP now and some forward 
-> > (like the above) while others block.
->
-> Far as I've been able to find out, the things that block are 
-> known as "broken". 

Nice, ringing, phraseology - however, not true.

Let's take a typical current technology - bridging-capable
routers.

Word around this list is that routers (want to) terminate 
a broadcast domain at each router interface.  Sadly, they 
don't always have the option to do this.

If a broadcast domain on one router interface surreptitiously
becomes connected to a broadcast domain on another interface
of the same router, one of three things happens:

1) The network breaks (not the most robust alternative)
2) The router switches to bridging mode between the now
   connected interfaces (including participating in STP)
3) The router recognizes that the two interfaces share
   a common broadcast domain and adopts a reasonable mode
   of operation consistent with this knowledge (including 
   load sharing, ARP sharing, etc. - and _NOT_ including 
   STP participation or forwarding).

You might ask "why would a router adopt behavior number
3 when behavior number 2 works?"

To answer this, look at these two scenarios:

1)         (N1)        (N2)        (N3)
               \_    _/    \_    _/
                 \  /        \  /
                  R1          R2
                _/  \_      _/  \_
               /      \    /      \
           (N4)        (N5)        (N6)
               \_                _/
                 \_____    _____/
                       \  /
                        B*

2)         (N1)        (N2)        (N3)
               \_    _/    \_    _/
                 \  /        \  /
                  R1          R2
                _/  \_      _/  \_
               /      \    /      \
           (N4)        (N5)        (N6)
               \_    _/
                 \  /
                  B*

In both of these cases, separately routed networks have
become a single broadcast domain through the addition of
a new bridge (B*) added between the previously separate
networks (N4+N6 in example 1 and N4+N5 in example 2).

So, the answer to the question above is that there is no
_good_ reason why scenario 1 should work and scenario 2
should not.  However, a very quick analysis will tell you
that scenario 1 works.  N4+N6 is topologically identical
to either N2 or N5 in that it connects R1 to R2.

Consequently, scenario 2 should work and - by analogy -
the _best_mode_ would be for it to work in the same way
that scenario 1 works.  This mode is both less traumatic
and more efficient...

-> If you can point to something specific that blocks that is 
-> widely used - or that is compliant with spec - that'd be 
-> useful.
-> 

So this is a rediculous request.  The "spec" you refer to
is presumably the 802.1 specification, consequently it is
not possible to "point to something that blocks [and] is
compliant with the spec" and it is not very interesting to
"point to something that blocks [or] is complaint with the 
spec".

Simply consider that not everything in the world is going
to be consistent with the spec and yet things still work.

-> > ---> > 
-> > ---> > Participate maps to what bridges do.
-> > 
-> > Most bridges.  Mostly agree.
-> > 
-> > ---> > 
-> > ---> > As a result, either of those can easily be considered as 
-> > ---> > default cases, though forward is clearly suboptimal.
-> > 
-> > "Participate" can be sub-optimal as well, assuming that we're
-> > talking about simple participation.
-> > 
-> > In simple participation, an RBridge participates with bridges
-> > both internal and external to the RBridge campus. This makes
-> > for a single spanning tree and effectively cancels any hopes
-> > we might have for efficient use of bandwidth - even internal
-> > to the RBridge campus.
-> 
-> We haven't talked about the internal transit requirements before;
-> bridges there ARE going run STP/MSTP and coalesce into trees anyway 
-> (you can't stop that). It doesn't matter if such trees touch two 
-> rbridges - there can still be independent paths between the rbridges 
-> (though that needs to be engineered; if they connect anywhere in the 
-> middle, the as you note, the bridging will end up killing the 
-> possibility of multipath).
-> 

We have talked about this, unless you've been letting someone
else use your E-Mail account.

You argued - fairly convincingly - that it would not normally
be possible for there to be more than one RBridge campus in a
single broadcast domain.  How did you suppose this to be the
case if we were not considering "internal transit requirements"?

-> > In order for this approach to work, internal RBridge 
-> > interfaces MUST be eligible to be put in a non-forwarding 
-> > state by the STP, and - once this is done - they cannot be
-> > used by SPF frame forwarding.
-> 
-> We really need to resolve the discussion of what an 'internal 
-> rbridge interface' is before this sentence can be interpreted 
-> completely.
-> 

I don't think anyone other than you is having trouble with 
the meaning of 'internal rbridge interface' in this context.
It is simply an interface that forms a circuit either with 
one or more additional RBridges, or zero or more additional
RBridges and another interface of itself.  That is, if the 
RBridge is an ingress or egress RBridge, an internal RBridge 
interface is one on which it will transmit frames it is the 
ingress for, or receives frames it is the egress for.

The definition - if you want to be picky about it - can be
harder to get your head around than the concept it defines.
See the figure (about 2 inches) below...

-> However, putting an interface (any interface) into a nonforwarding 
-> state is just what a root bridge would do anyway, which is why I 
-> consider this a variant of PARTICIPATE.

Yes, that is what a bridges do, but I think you'll find a root 
bridge typically does not have any non-forwarding interfaces.

But this is not the point.  If one of the working group goals
is to make efficient use of link bandwidth, then - in the figure
below - we do not want any 'internal RBridge interfaces' to be in
a non-forwarding mode.

      __________
     /     i.1_ \    ___ i.3
    (      i.2_>RB-1<___ 1.4
     \          /
      \ campus /            i.1 and i.2 are internal interfaces
       \______/             i.3 and i.4 are external interfaces

That is to say, RB-1 _might_ put i.3 or i.4 in non-forwarding
mode (I do not consider this either necessary or ideal), but 
it should not put i.1 or i.2 in non-forwarding mode.  That is
why blocking STP is the optimal approach.

-> 
-> > More complex participation - which is what I suspect you are
-> > referring to - would be along the lines of treating external
-> > interfaces of all RBridges in a single campus as part of a
-> > single large bridge (you've previously argued that an RBridge 
-> > campus may be viewed as a single "virtual bridge").  This is
-> > more complicated because the STP block and forward decisions
-> > for all such external interfaces now needs to be collectively
-> > made (and maintained) across a number of RBridges (all of them
-> > within a campus). 
-> 
-> Those decisions already need to be coordinated. Until you decide 
-> what's in and out of an rbridge, you don't know what 'internal' 
-> means anyway.

These decisions do not have to be "coordinated" in the same sense
that they would be coordinated between interfaces of a single box.

What we've talked about so far (in terms of coordination) is how
we might use IS-IS to share information among RBridges that will
allow each edge RBridge to build what is effectively a filtering
database.  The model for frame forwarding within a RBridge campus
is supposed to be based on routing rather than bridging.

Consequently, the decision as to which external interfaces are 
used to (receive) ingress and (transmit) egress frames is both 
a local decision (which must be made consistently) and a result
of collective forwarding based on frame routing within a campus.

In other words, frames should be allowed to arrive at an egress
RBridge by whatever interface happens to correspond to the SPF
path to that egress from any ingress.

The bit of coordination that we need to work out is along the 
lines of who is the designated egress for what frames when more
that one RBridge is connected to the same 'external' LAN segment.

-> 
-> > That would be a non-trivial exercise using your favorite proprietary 
-> > approach; it would be impossible to standardize.
-> 
-> Things like the HELLO protocol already start in this direction; 
-> are you suggesting that HELLO will be impossible to standardize? ;-)
-> 

In what way is the HELLO protocol going to be involved in working
out forwarding between RBridges?  As far as I know, in absolutely
_no_way_ at all.

HELLO protocol is involved in determing neighbor relationships and
indirectly allows RBridges to determine campus topology.  That can
certainly be done.

Based on the neighbor relationships that RBridges determine, they
then use link-state routing to determine topology and - finally -
SPF to determine forwarding. 

Saying that the HELLO protocol is involved in determining forwarding
is getting a little ahead of ourselves... 

-> > For one thing, assuming that the hello/discovery protocol uses
-> > an appropriate communication layer, then the hello/discovery
-> > messages MUST be delivered over any non-disfunctional path.
-> 
-> Bridges think that's true for BPDUs too; if rbridges block them,
-> then it is the rbridge that becomes the disfunctional component.
-> 

RBridges are not bridges.  Maybe we should call them NBridges
to make that clearer?

-> > [D]evices (other than RBridges) will not be able to 
-> > distinguish RBridge hello/discovery messages from any
-> > other traffic.
-> 
-> Will they be encrypted? If not, we cannot make this assumption.
-> 

Let's not be cryptic.  There's a difference between:

A) being able to distinguish RBridge hello/discovery messages 
   through some deliberate analysis of frames based on - at 
   least - a priori knowledge of the existence of RBridges, 
   TRILL and the hello and discovery protocols, and 

B) being unable to distinguish RBridge hello/discovery messages 
   because they are frames like every other frame it is the 
   fundamental purpose of LAN devices to forward.

LAN devices - because they are in the business of forwarding
frames - will not reject some frames and pass others without
some prior knowledge and justification.  We need to make sure
that we do not choose a poor frame format that we know will
be rejected by existing technology and we need to rely on a
belief that future technologies will not decide to discard 
TRILL hello/discovery frames without due consideration of the
effects of doing so.

Any other set of assumptions is essentially pathological.

Due consideration is what we are in the process of doing now.
Note that "due consideration" and "slavish compliance" are 
not the same thing.  If we want to do something different, we
are free to do so, as long as we consider the implications.


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 jBCJeU012374 for <[e-mail]>; Mon, 12 Dec 2005 11:40:30 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jBCJeKdJ011044 for <[e-mail]>; Mon, 12 Dec 2005 14:40:20 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA16039 for <[e-mail]>; Mon, 12 Dec 2005 14:40:19 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLKR9M>; Mon, 12 Dec 2005 14:40:19 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Mon, 12 Dec 2005 14:40:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2005 19:40:47 -0000
Status: RO
Content-Length: 2536

Alia,

	I completely agree, now that I understand your earlier
comments a little better.  Suggesting use of a configurable
random "seed" value as an example of a mechanism to avoid
synchronization/correlation is okay.  Other approaches exist
as well - such as changing to use a different hash algorithm
(if that applies) or adding a shift or rotation operation to
the existing selection scheme.

	It is interesting to note that the effort to avoid the
synchronization problem must be stated as a _desirable_ goal
rather than a _requirement_ simply because - short of knowing
exactly what algorithms might be used and exactly what chain
of events can result in excessive correlation in arbitrarily 
many combinations of multipath selection schemes - it is hard 
to declare definitively that any specific avoidance approach 
will always work.

	I believe that - in other places - we have suggested
that whatever scheme might be used in any implementation, it
should include configurable parameters that may be used to
de-correlate the selection process from similar selection 
processes applied elsewhere in the network.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Alia Atlas
--> Sent: Saturday, December 10, 2005 3:04 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS issue #4
--> 
--> Eric,
--> 
--> On 12/9/05, Gray, Eric <[e-mail]> wrote:
--> >         Surely you don't really believe that a high level
--> > statement like "persistent re-ordering of flows MUST be
--> > avoided" is even close to the same as "and while you are
--> > doing that, make sure you twiddle this and tweak that."
--> 
--> Of course not - but we were talking in part about the 
--> tweaking of which
--> bits should be consulted, such as whether MAC addresses and VLANs
--> should be considered, or IP addresses, etc.  I agree that it's a bad
--> idea to include too much implementation detail, but I'm also not for
--> deliberate obfuscation.  I'm certainly not suggesting that 
--> one should
--> prescribe an algorithm; pointing out that randomness is needed to
--> ensure good multi-hop load-balancing doesn't strike me as being in
--> quite the same camp.  It's not like I'm saying how that 
--> randomness is
--> introduced, what that seed could be, etc.
--> 
--> Alia
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBACnD007077 for <[e-mail]>; Sat, 10 Dec 2005 04:49:13 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 60FF39E0B7 for <[e-mail]>; Sat, 10 Dec 2005 13:49:06 +0100 (CET)
Received: from [163.117.203.92] (unknown [163.117.203.92]) by smtp01.uc3m.es (Postfix) with ESMTP id 0139E9DFB1 for <[e-mail]>; Sat, 10 Dec 2005 13:49:03 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 10 Dec 2005 13:48:58 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Arch Issue #2 and #3
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2005 12:49:42 -0000
Status: RO
Content-Length: 8442

Gray, Eric wrote:

>Joe,
>
>	Please see additional comments in-line below...
>
>--
>Eric 
>
>--> -----Original Message-----
>--> From: [e-mail] 
>--> [mailto:[e-mail]] On Behalf Of Joe Touch
>--> Sent: Thursday, December 08, 2005 4:49 PM
>--> To: Developing a hybrid router/bridge.
>--> Subject: Re: [rbridge] Arch Issue #2 and #3
>--> 
>--> -----BEGIN PGP SIGNED MESSAGE-----
>--> Hash: SHA1
>--> 
>--> 
>--> 
>--> Gray, Eric wrote:
>--> > --> 
>--> > --> #2 is an rbridge the DR of the edge STPs?
>--> > 
>--> > It may be.  This relates to architectural issue #3 - see below.
>--> > 
>--> > --> 
>--> > --> #3 do rbridges have proxy bridges at their edges (see Radia's post
>of
>--> > --> 10/21/2005)?
>--> > --> (see Guillermo's text below)
>--> > 
>--> > Radia explicitly suggested this in order to propose that this is 
>--> > out of scope for the TRILL working group.
>--> 
>--> My impression was more that this was a way to implement PARTICIPATE...
>
>Actually, I cannot determine how it is possible to derive
>that impression - at least within the RBridge context.
>
>Radia's assumption in her description is that the RBridge
>portion of the described hybrid _implementation_ would be
>_blocking_ STP.  Otherwise, there would be no requirement
>to include the logical, in-line, bridge.
>
>While you could argue that such an _implementation_ does
>participate in STP, its participation is limited and aimed
>at a single-minded purpose - i.e. - establishing itself as
>the spanning tree root.  Because the RBridge in this mode
>would be blocking STP, the in-line bridge has nothing of
>any topological significance to add to STP other than to
>nominate itself (forcefully) as a root candidate for the
>spanning tree.
>  
>
Good explanation. Radia's proposal  was a way to keep BLOCK as the basis 
while allowing
participation as root bridge. The main point is that, in my opinion,  
Rbridge
 participation in STP may limit to (but it is important) contend  as 
candidate for
 root bridge election. The position of root is the ideal to  forward 
traffic in and out of
link (external link interfaces). The other interfaces  of Rbridges will 
connect to the internal
 links as endnodes, without emitting BPDUs.
The crucial difference against PARTICIPATE is that Rbridges MUST NEVER be
 in the middle of a spanning tree, they can only behave as root bridge 
or endnodes.
Guillermo

>The proposal was very clearly to demonstrate that what
>Guillermo wanted could be _implemented_ orthogonally to 
>specification of base-line RBridge behavior.
>
>  
>
True.

>--> 
>--> or actually a variant of BLOCK (see my other message)
>
>Blocking of STP is assumed in this model.  I believe if 
>you were to talk to Radia, you would discover that she 
>has assumed STP blocking behavior from the beginning and
>has not seen any reason to change that assumption.  But,
>don't take my opinion on the matter, ask her...
>--> > An RBridge may be collocated with any number of bridges.  An RBRidge
>--> > implementation may logically connect such a collocated bridge in-line
>--> > with any of its interfaces.
>--> > 
>--> > In this case, it is possible to build an RBridge implementation that
>--> > participates in STP/RSTP and it is possible to configure the in-line
>--> > bridge in such a way as to guarantee that it will become the root of
>--> > the STP.
>--> 
>--> Can you force a single bridge to be root of an STP? If so, what happens
>--> when two such bridges are on the same segment? (that seems to be the
>rub)...
>
>No rub to it, and this is precisely why Radia made this 
>proposal.  I was objecting to the implied configuration
>requirements and Guillermo was firm in requiring a way
>to do it.
>
>The way that you can "force a single bridge to be root
>of an STP" is via configuration.  Clearly it is possible
>to configure two bridges on the same segment to have the
>same priority in the root selection process and that is
>why the process has tie-breaking provisions.  That is 
>also the reason why it is (and MUST be) strictly a
>configuration option.
>  
>
I just want to clarify that via default configuration of lower priority 
value for bridges collocated to Rbridges,
we can ensure "default" (if nobody configures anything) election of an 
Rbridge (the one with lowest MAC address)
at each link.

>--> 
>--> Joe
>--> 
>--> > 
>--> > This is not required of an RBridge implementation - even if it were
>--> > to turn out to be a common implementation case.  Rather, this is an
>--> > offered example - by way of proof of concept - that we do not need 
>--> > to define this behavior as part of base-line RBridge behavior.
>--> > 
>--> > Speaking of orthogonality, this discussion (below) will be included 
>--> > in the next iteration of TRILL routing requirements, when it is 
>--> > submitted.  Assuming that draft eventually becomes a WG draft, you 
>--> > may want to simply refer to that document in the architecture draft.
>--> > 
>--> > --> - -----
>--> > --> 
>--> > --> Guillermo's text for ARCH #3:
>--> > --> 
>--> > --> RBridge indirect participation in bridged island spanning tree.
>--> > --> - 
>--> ---------------------------------------------------------------
>--> > --> RBridges by default do not participate in spanning tree in other
>way
>--> > --> than ignoring received BPDUs. It is an objective of RBridge
>--> > --> specification to be independent of bridges specifications as much
>as
>--> > --> possible.
>--> > --> 
>--> > --> However it may be convenient for RBridges in some circumstances to
>--> > --> participate in the spanning tree and contend to be root bridge of
>the
>--> > --> spanning tree formed in the bridged island they are attached to.
>In
>--> > --> these cases it is possible to build a device that's logically the
>same
>--> > --> as a bridge glued onto an RBridge. The following schema applies:
>--> > --> 
>--> > -->                         ?-----------?
>--> > -->        bridged island-----B1----RB1 ?
>--> > -->                         ?-----------?
>--> > --> 
>--> > -->                         RBridge/bridge box
>--> > --> 
>--> > --> where B1 is a bridge with two ports...a pt-to-pt link to RBRidge
>RB1,
>--> > --> and a link to the bridged LAN. The "RB1" portion of this box acts
>as
>--> > --> an standard RBridge, it neither forwards, nor initiates spanning
>tree
>--> > --> messages. The "B1" portion acts as two-port standard 802.1D
>bridge, 
>--> > --> and does participate in spanning tree. Its priority for root
>election 
>--> > --> can be set in the standard way. To minimize configurafion, it may 
>--> > --> be convenient in some implementations to make the standard B1
>bridge 
>--> > --> priority a function of the configurable RBridge priority for IS-IS
>
>--> > --> Designated RBridge election. In this way Designated RBridge will 
>--> > --> participate and contend (as B1) to be elected also as root bridge
>of 
>--> > --> the bridged island and only one priority configuration is
>required.
>--> > --> 
>--> > --> If (in environments using such implementations) the default bridge
>--> > --> priority for B1 is lower than standard bridge priority, by default
>--> > --> RBridges/bridges like B1 shown will become roots of their bridged
>--> > --> islands, contending only with other RBridges connected to same
>island
>--> > --> for root election. It is not mandatory for RBridges becombined
>bridge/
>--> > --> RBridges.
>--> > --> 
>--> > --> - -------
>--> > --> 
>--> > 
>--> > --
>--> > Eric
>--> > _______________________________________________
>--> > rbridge mailing list
>--> > [e-mail]
>--> > http://www.postel.org/mailman/listinfo/rbridge
>--> -----BEGIN PGP SIGNATURE-----
>--> Version: GnuPG v1.2.4 (MingW32)
>--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>--> 
>--> iD8DBQFDmKpIE5f5cImnZrsRAs/tAKCRkMxmz15gopFBmeHSJ5xZOfz4owCeMznn
>--> DIBxUhcFFdtcp5K3KvwZRWU=
>--> =yueR
>--> -----END PGP SIGNATURE-----
>--> _______________________________________________
>--> rbridge mailing list
>--> [e-mail]
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> 
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

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



Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBA9oT028008 for <[e-mail]>; Sat, 10 Dec 2005 01:50:30 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2CA7784ABF for <[e-mail]>; Sat, 10 Dec 2005 10:50:23 +0100 (CET)
Received: from [163.117.203.92] (unknown [163.117.203.92]) by smtp02.uc3m.es (Postfix) with ESMTP id 6C32B84C76 for <[e-mail]>; Sat, 10 Dec 2005 10:50:21 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 10 Dec 2005 10:50:21 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: multipart/alternative; boundary="------------080905080809010604070800"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] draft-gibanez-trill-abridge-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2005 09:51:31 -0000
Status: RO
Content-Length: 11605

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

    I have submitted  a draft (see below), with a proposal able to scale 
to large Ethernet campus networks, based on multiple self-rooted 
spanning trees (AMSTP protocol),  two  hierarchical spanning tree layers 
(AMSTP and RSTP), and optional  ARP  server/registrars.  To prevent 
confusion with Rbridges, I use the term Abridges (Alternative or 
Adaptive Routing Bridges).  I hope you will find it interesting.
Regards
Guillermo

Date: Fri, 09 Dec 2005 15:50:01 -0500
From: [e-mail] <mailto:[e-mail]>
Subject: I-D ACTION:draft-gibanez-trill-abridge-00

To: [e-mail] <mailto:[e-mail]>
Message-ID: <[e-mail] 
<mailto:[e-mail]>>
Content-Type: text/plain; charset="us-ascii"

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


       Title           : Abridges as Rbridges: Transparent Routing with  
Simplified Multiple Spanning Trees
       Author(s)       : G. Ibanez, et al.
       Filename        : draft-gibanez-trill-abridge-00.txt
       Pages           : 17
       Date            : 2005-12-9

Rbridges are link layer devices that use routing protocols as a control
plane but do not target to scale up to large campus networks. This
document contains an alternative proposal to link-state Rbridges, named
Abridges. Abridges overcome Rbridges L2 network size restrictions
allowing applicability to very large Ethernet campus networks while
maintaining zero configuration and high performance, by assuming a
topological restriction that is automatically performed. The proposal
includes a two-layered network architecture with two hierarchical
independent spanning tree layers. Expected convergence is fast, probably
below two seconds.

Abridges use multiple simplified spanning trees rooted at core edge
bridges  to  achieve  results  comparable  to  Rbridges  with  lower
computational complexity. Two implementation variants of simplified
multiple spanning trees are proposed: The first one is a fundamental
simplification of the standard Multiple Spanning Tree protocol and the
second one (still in a very preliminary stage) consists of an N-multiple
simultaneous execution of the Rapid Spanning Tree protocol at each
Rbridge.
An optional mechanism of ARP/Abridge servers/registrars (with load
splitting) is proposed to limit ARP traffic in large scale Ethernet
networks and to enhance scalability and security. This mechanism can
 also be used for host-Designated Rbridge resolution as an alternative
 to the interchange of Hosts Lists between Rbridges.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt 
<http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt>

--------------080905080809010604070800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
&nbsp;&nbsp;&nbsp; I have submitted&nbsp; a draft (see below), with a proposal able to
scale to large Ethernet campus networks, based on multiple self-rooted
spanning trees (AMSTP protocol),&nbsp; two&nbsp; hierarchical spanning tree
layers (AMSTP and RSTP), and optional&nbsp; ARP&nbsp; server/registrars.&nbsp; To
prevent confusion with Rbridges, I use the term Abridges (Alternative
or Adaptive Routing Bridges).&nbsp; I hope you will find it interesting. <br>
Regards<br>
Guillermo<br>
<br>
<pre class="moz-signature" cols="72">Date: Fri, 09 Dec 2005 15:50:01 -0500
From: <a onclick="return top.js.OpenExtLink(window,event,this)"
 href="mailto:[e-mail]">[e-mail]</a>
Subject: I-D ACTION:draft-gibanez-trill-abridge-00</pre>
<div id="mb_0"><wbr>To: <a
 onclick="return top.js.OpenExtLink(window,event,this)"
 href="mailto:[e-mail]">[e-mail]</a><br>
Message-ID: &lt;<a
 onclick="return top.js.OpenExtLink(window,event,this)"
 href="mailto:[e-mail]">[e-mail]<wbr>.org</a>&gt;<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
A New Internet-Draft is available from the on-line Internet-Drafts
directories.<br>
<br>
<MailScannerScript16117 script><!--
D(["mb","<br /> &nbsp; &nbsp; &nbsp; &nbsp;Title &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : Abridges as Rbridges: Transparent Routing with<br /> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Simplified Multiple Spanning Trees<br /> &nbsp; &nbsp; &nbsp; &nbsp;Author(s) &nbsp; &nbsp; &nbsp; : G. Ibanez, et al.<br /> &nbsp; &nbsp; &nbsp; &nbsp;Filename &nbsp; &nbsp; &nbsp; &nbsp;: draft-gibanez-trill-abridge-00<wbr />.txt<br /> &nbsp; &nbsp; &nbsp; &nbsp;Pages &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : 17<br /> &nbsp; &nbsp; &nbsp; &nbsp;Date &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;: 2005-12-9<br /><br />Rbridges are link layer devices that use routing protocols as a control<br />plane but do not target to scale up to large campus networks. This<br />document contains an alternative proposal to link-state Rbridges, named<br />Abridges. Abridges overcome Rbridges L2 network size restrictions<br />allowing applicability to very large Ethernet camp
us networks while<br />maintaining zero configuration and high performance, by assuming a<br />topological restriction that is automatically performed. The proposal<br />includes a two-layered network architecture with two hierarchical<br />independent spanning tree layers. Expected convergence is fast, probably<br />below two seconds.<br /><br />Abridges use multiple simplified spanning trees rooted at core edge<br />bridges &nbsp;to &nbsp;achieve &nbsp;results &nbsp;comparable &nbsp;to &nbsp;Rbridges &nbsp;with &nbsp;lower<br />computational complexity. Two implementation variants of simplified<br />multiple spanning trees are proposed: The first one is a fundamental<br />simplification of the standard Multiple Spanning Tree protocol and the<br />second one (still in a very preliminary stage) consists of an N-multiple<br />simultaneous execution of the Rapid Spanning Tree protocol at each<br />Rbridge.<br />An optional mechanism of ARP/Abridge servers/registrars (with load<
br />splitting) is proposed to limit ARP traffic in large scale Ethernet<br />networks and to enhance scalability and security. This mechanism can also be used for host-Designated Rbridge resolution as an alternative to the interchange of Hosts Lists between Rbridges.<br />",1]
);

//--></MailScannerScript16117><br>
&nbsp; &nbsp; &nbsp; &nbsp;Title &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : Abridges as Rbridges: Transparent Routing
with&nbsp; Simplified Multiple Spanning Trees<br>
&nbsp; &nbsp; &nbsp; &nbsp;Author(s) &nbsp; &nbsp; &nbsp; : G. Ibanez, et al.<br>
&nbsp; &nbsp; &nbsp; &nbsp;Filename &nbsp; &nbsp; &nbsp; &nbsp;: draft-gibanez-trill-abridge-00<wbr>.txt<br>
&nbsp; &nbsp; &nbsp; &nbsp;Pages &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : 17<br>
&nbsp; &nbsp; &nbsp; &nbsp;Date &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;: 2005-12-9<br>
<br>
Rbridges are link layer devices that use routing protocols as a control<br>
plane but do not target to scale up to large campus networks. This<br>
document contains an alternative proposal to link-state Rbridges, named<br>
Abridges. Abridges overcome Rbridges L2 network size restrictions<br>
allowing applicability to very large Ethernet campus networks while<br>
maintaining zero configuration and high performance, by assuming a<br>
topological restriction that is automatically performed. The proposal<br>
includes a two-layered network architecture with two hierarchical<br>
independent spanning tree layers. Expected convergence is fast, probably<br>
below two seconds.<br>
<br>
Abridges use multiple simplified spanning trees rooted at core edge<br>
bridges &nbsp;to &nbsp;achieve &nbsp;results &nbsp;comparable &nbsp;to &nbsp;Rbridges &nbsp;with &nbsp;lower<br>
computational complexity. Two implementation variants of simplified<br>
multiple spanning trees are proposed: The first one is a fundamental<br>
simplification of the standard Multiple Spanning Tree protocol and the<br>
second one (still in a very preliminary stage) consists of an N-multiple<br>
simultaneous execution of the Rapid Spanning Tree protocol at each<br>
Rbridge.<br>
An optional mechanism of ARP/Abridge servers/registrars (with load<br>
splitting) is proposed to limit ARP traffic in large scale Ethernet<br>
networks
and to enhance scalability and security. This mechanism can<br>
&nbsp;also be
used for host-Designated Rbridge resolution as an alternative<br>
&nbsp;to the
interchange of Hosts Lists between Rbridges.<br>
<MailScannerScript16117 script><!--
D(["mb","<br />A URL for this Internet-Draft is:<br /><a onclick\u003d\"return top.js.OpenExtLink(window,event,this)\" href\u003d\"http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt\" target\u003d_blank>http://www.ietf.org/internet<wbr />-drafts/draft-gibanez-trill<wbr /\>-abridge-00.txt</a><br /><br />To remove yourself from the I-D Announcement list, send a message to<br /><a onclick\u003d\"return top.js.OpenExtLink(window,event,this)\" href\u003d\"mailto:[e-mail]\">[e-mail]</a> with the word unsubscribe in the body of the message.<br />You can also visit <a onclick\u003d\"return top.js.OpenExtLink(window,event,this)\" href\u003d\"https://www1.ietf.org/mailman/listinfo/I-D-announce\" target\u003d_blank>https://www1.ietf.org/mailman<wbr />/listinfo/I-D-announce</a><br />to change your subscription settings.<br /><br /><br />Internet-Drafts are also available by anonymous FTP. Login with the username<br />&quot;an
onymous&quot; and a password of your e-mail address. After logging in,<br />type &quot;cd internet-drafts&quot; and then<br /> &nbsp; &nbsp; &nbsp; &nbsp;&quot;get draft-gibanez-trill-abridge-00<wbr />.txt&quot;.<br /><br /\>A list of Internet-Drafts directories can be found in<br /><a onclick\u003d\"return top.js.OpenExtLink(window,event,this)\" href\u003d\"http://www.ietf.org/shadow.html\" target\u003d_blank>http://www.ietf.org/shadow<wbr />.html</a><br />or <a onclick\u003d\"return top.js.OpenExtLink(window,event,this)\" href\u003d\"ftp://ftp.ietf.org/ietf/1shadow-sites.txt\" target\u003d_blank>ftp://ftp.ietf.org/ietf<wbr />/1shadow-sites.txt</a><br /><br /><br />Internet-Drafts can also be obtained by e-mail.<br /><br />Send a message to:<br /> &nbsp; &nbsp; &nbsp; &nbsp;<a onclick\u003d\"return top.js.OpenExtLink(window,event,this)\" href\u003d\"mailto:[e-mail]\">[e-mail]</a>.<br />In the body type:<br /> &nbsp; &nbsp; &nbsp; &nbsp;&quot;FILE /internet-
drafts/draft-gibanez-trill-abridge-00.txt&quot;.<br /><br />NOTE: &nbsp; The mail server at <a onclick\u003d\"return top.js.OpenExtLink(window,event,this)\" href\u003d\"http://ietf.org\" target\u003d_blank>",1]
);

//--></MailScannerScript16117><br>
A URL for this Internet-Draft is:<br>
<a onclick="return top.js.OpenExtLink(window,event,this)"
 href="http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt"
 target="_blank">http://www.ietf.org/internet<wbr>-drafts/draft-gibanez-trill<wbr>-abridge-00.txt</a></div>
</body>
</html>

--------------080905080809010604070800--


Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBA83d006241 for <[e-mail]>; Sat, 10 Dec 2005 00:03:39 -0800 (PST)
Received: by zproxy.gmail.com with SMTP id 13so1011679nzp for <[e-mail]>; Sat, 10 Dec 2005 00:03:38 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jtVcYumFPu474kFAuNH2l0lvhDg8WJSXeJ4zQw3smCzKJo8WxWrb0zjdzXNBUxGhszIwbgDDzJCDUTDsQ1o+IUm2weSr2gHLCDdtKLE37T3IPo7iUl0ed682bF5i0xFzji3K8nSiJRJAzd87iLJay1Kt3kV5SPCnA12xIZsOYf8=
Received: by 10.64.3.11 with SMTP id 11mr2455qbc; Sat, 10 Dec 2005 00:03:38 -0800 (PST)
Received: by 10.64.24.2 with HTTP; Sat, 10 Dec 2005 00:03:38 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sat, 10 Dec 2005 00:03:38 -0800
From: Alia Atlas <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <[e-mail]>
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 jBA83d006241
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2005 08:04:39 -0000
Status: RO
Content-Length: 894

Eric,

On 12/9/05, Gray, Eric <[e-mail]> wrote:
>         Surely you don't really believe that a high level
> statement like "persistent re-ordering of flows MUST be
> avoided" is even close to the same as "and while you are
> doing that, make sure you twiddle this and tweak that."

Of course not - but we were talking in part about the tweaking of which
bits should be consulted, such as whether MAC addresses and VLANs
should be considered, or IP addresses, etc.  I agree that it's a bad
idea to include too much implementation detail, but I'm also not for
deliberate obfuscation.  I'm certainly not suggesting that one should
prescribe an algorithm; pointing out that randomness is needed to
ensure good multi-hop load-balancing doesn't strike me as being in
quite the same camp.  It's not like I'm saying how that randomness is
introduced, what that seed could be, etc.

Alia


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB9MDP024826 for <[e-mail]>; Fri, 9 Dec 2005 14:13:25 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB9MDJdJ018021 for <[e-mail]>; Fri, 9 Dec 2005 17:13:19 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA29571 for <[e-mail]>; Fri, 9 Dec 2005 17:13:19 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BL2BJ5>; Fri, 9 Dec 2005 17:13:18 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Fri, 9 Dec 2005 17:13:17 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2005 22:14:37 -0000
Status: RO
Content-Length: 4250

Alia,

	Surely you don't really believe that a high level
statement like "persistent re-ordering of flows MUST be
avoided" is even close to the same as "and while you are 
doing that, make sure you twiddle this and tweak that."

	This discussion, high level and detail, has come
up numerous times in the past few years.  While I have
seen people add a high-level comment similar to the one
above to documents that eventually became RFCs, I have
not seen people successfully detail how to do it.  I
believe that most people believe it is just a bad idea
to include too much detail in normative text.  I'd be 
happy to hear of counter-examples, however.

	There is a certain amount of "mom and apple-pie" 
that makes sense to add to a standard protocol spec. 
Beyond that is simply filler...

--
Eric	

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Alia Atlas
--> Sent: Friday, December 09, 2005 1:40 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS issue #4
--> 
--> Eric,
--> On 12/9/05, Gray, Eric <[e-mail]> wrote:
--> >         Actually, this is getting more into implementation
--> > than I believe we should.  It may be sufficient for us to
--> > recommend injection of some random factor into <whatever>
--> > path selection algorithm - obviously during initialization
--> > - in order to avoid synchronization problems during path
--> > selections.
--> 
--> If we feel the need to discuss that there is a hashing algorithm
--> to avoid frequent per-flow re-ordering, then I'd have just have
--> that recommendation.
--> 
--> >         Conversely, we could view this as telling people not
--> > to build bad implementations - which is not what we should
--> > be doing.
--> 
--> One could view telling people not to reorder flows as the 
--> same thing.
--> 
--> Alia
--> 
--> >         After all, our employers are not generally motivated
--> > to tell other companies how to build a better mouse trap.
--> >
--> > --
--> > Eric
--> >
--> > --> -----Original Message-----
--> > --> From: [e-mail]
--> > --> [mailto:[e-mail]] On Behalf Of Alia Atlas
--> > --> Sent: Friday, December 09, 2005 2:24 AM
--> > --> To: Developing a hybrid router/bridge.
--> > --> Subject: Re: [rbridge] PS issue #4
--> > -->
--> > --> On 12/8/05, Gray, Eric <[e-mail]> wrote:
--> > --> >         Any specific path selection algorithm 
--> affects only the
--> > --> > device making the path selection.  That means it comes under
--> > --> > the heading of "what I do in my box is my own business."
--> > --> >
--> > --> >         What really needs to be said - particularly 
--> at a level
--> > --> > of "architecture" is that devices using multiple paths to
--> > --> > forward frames MUST use some path selection algorithm that
--> > --> > will prevent persistent re-ordering of frames within flows.
--> > -->
--> > --> It may also be worthwhile to point out that a different
--> > --> seed into the
--> > --> hash function at each
--> > --> point is important to improve load-balancing at 
--> different rbridges
--> > --> along a path.  Otherwise, there is the risk that, in the
--> > --> trivial case,
--> > --> only traffic with hash x will reach an rbridge from a 
--> particular
--> > --> interface so that when that rbridge tries to 
--> load-balance by using
--> > --> hash x and y, it only has hash x traffic and no
--> > --> load-balancing occurs.
--> > -->
--> > --> I think this is important at the "architecture' 
--> because, without it,
--> > --> load-balancing is at risk of working very poorly for 
--> sequential
--> > --> rbridges that have ecmp.
--> > -->
--> > --> Alia
--> > --> _______________________________________________
--> > --> rbridge mailing list
--> > --> [e-mail]
--> > --> http://www.postel.org/mailman/listinfo/rbridge
--> > -->
--> > _______________________________________________
--> > rbridge mailing list
--> > [e-mail]
--> > http://www.postel.org/mailman/listinfo/rbridge
--> >
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB9IeH013753 for <[e-mail]>; Fri, 9 Dec 2005 10:40:18 -0800 (PST)
Received: by zproxy.gmail.com with SMTP id z6so982420nzd for <[e-mail]>; Fri, 09 Dec 2005 10:40:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dvKMkbtWl+UOG56gC/PvEkkDKsiud8GvSg0w7V749jFo5bz0suQ9+Le10Junu2WYug64HMF/jtYqvwMyWKyUD3tKE1P9HHYqLcLqjx5TgiogutRel5UgqQsUCP5Meus2EB/uRqJ8H273ztlHCOXC4Jwi4LAkszai0OzF2BBBnAM=
Received: by 10.64.49.5 with SMTP id w5mr1717qbw; Fri, 09 Dec 2005 10:40:17 -0800 (PST)
Received: by 10.64.24.2 with HTTP; Fri, 9 Dec 2005 10:40:17 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 9 Dec 2005 10:40:17 -0800
From: Alia Atlas <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <[e-mail]>
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 jB9IeH013753
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2005 18:40:35 -0000
Status: RO
Content-Length: 2709

Eric,
On 12/9/05, Gray, Eric <[e-mail]> wrote:
>         Actually, this is getting more into implementation
> than I believe we should.  It may be sufficient for us to
> recommend injection of some random factor into <whatever>
> path selection algorithm - obviously during initialization
> - in order to avoid synchronization problems during path
> selections.

If we feel the need to discuss that there is a hashing algorithm
to avoid frequent per-flow re-ordering, then I'd have just have
that recommendation.

>         Conversely, we could view this as telling people not
> to build bad implementations - which is not what we should
> be doing.

One could view telling people not to reorder flows as the same thing.

Alia

>         After all, our employers are not generally motivated
> to tell other companies how to build a better mouse trap.
>
> --
> Eric
>
> --> -----Original Message-----
> --> From: [e-mail]
> --> [mailto:[e-mail]] On Behalf Of Alia Atlas
> --> Sent: Friday, December 09, 2005 2:24 AM
> --> To: Developing a hybrid router/bridge.
> --> Subject: Re: [rbridge] PS issue #4
> -->
> --> On 12/8/05, Gray, Eric <[e-mail]> wrote:
> --> >         Any specific path selection algorithm affects only the
> --> > device making the path selection.  That means it comes under
> --> > the heading of "what I do in my box is my own business."
> --> >
> --> >         What really needs to be said - particularly at a level
> --> > of "architecture" is that devices using multiple paths to
> --> > forward frames MUST use some path selection algorithm that
> --> > will prevent persistent re-ordering of frames within flows.
> -->
> --> It may also be worthwhile to point out that a different
> --> seed into the
> --> hash function at each
> --> point is important to improve load-balancing at different rbridges
> --> along a path.  Otherwise, there is the risk that, in the
> --> trivial case,
> --> only traffic with hash x will reach an rbridge from a particular
> --> interface so that when that rbridge tries to load-balance by using
> --> hash x and y, it only has hash x traffic and no
> --> load-balancing occurs.
> -->
> --> I think this is important at the "architecture' because, without it,
> --> load-balancing is at risk of working very poorly for sequential
> --> rbridges that have ecmp.
> -->
> --> Alia
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://www.postel.org/mailman/listinfo/rbridge
> -->
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
>


Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB9IUq010845; Fri, 9 Dec 2005 10:30:52 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 09 Dec 2005 10:30:47 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig18D959BE4F0C748FB97E558B"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS Issue #11 -> now ARCH issue #6
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2005 18:31:50 -0000
Status: RO
Content-Length: 12522

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

See below.

> Gray, Eric wrote:
>> Joe,
>>=20
>> 	See even more comments embedded below...
>>=20
>> --
>> Eric=20
>>=20
>> --> -----Original Message-----
>> --> From: [e-mail]=20
>> --> [mailto:[e-mail]] On Behalf Of Joe Touch
>> --> Sent: Thursday, December 08, 2005 5:17 PM
>> --> To: Developing a hybrid router/bridge.
>> --> Subject: Re: [rbridge] PS Issue #11 -> now ARCH issue #6
>> -->=20
>>=20
>>=20
>> Gray, Eric wrote:
>>> -->=20
>>> --> #11 internal/external, inside/outside terminology
>>> -->     there is one objection to these terms as topological;
>>> -->     the draft intends to define them sufficiently
>>> -->     does this need to be addressed further?
>>=20
>>> This is not a Problem Statement Issue because these terms are
>>> defined in draft-touch-trill-rbridge-arch, rather than in
>>> draft-touch-trill-prob.  Consequently, this is an issue with
>>> the Architectural document, if not precisely an architectural
>>> issue.
>>=20
>> Yup - needs to be moved to the other doc. Let's call this ARCH issue #=
6
>> then (see header).
>=20
> In this case, the PS/ARCH issue is that definitions need
> to be moved to the PS document, from the ARCH document.

Internal/external as used in the PS doc is specific to protocols
'inside' the solution. It is not used the same way in the arch document
(internal/external interfaces).

That difference needs to be made more clear.

> Issues relating to the specific definitions are issues for
> whatever document they are currently in.

Agreed.

>>> The draft definitions are not sufficiently clear on the current=20
>>> iteration.
>>=20
>>> The definitions offered there were -=20
>>=20
>>> -> o  External (to a campus): describes communication on the
>>> non-rbridge=20
>>> ->    components of an Ethernet link subnet, notably not between=20
>>> ->    rbridges or between non-rbridges and rbridges.
>>=20
>> The last part is a bug i.e., 'or between non-rbridges and rbridges'. I=
t
>> should be omitted.
>>=20
> The entire statement is hard to parse, even if we were
> to agree that this is basically what we want to say.  We
> are not agreed, at this point, but a better way to say
> what I think you are trying to say is:
>=20
> o  External (to a campus): describes communication between non-rbridge
>    components of an Ethernet subnet.
> =20
> As I have said numerous times, I have problems with your=20
> definition, but - even if the WG were to decide to adopt
> it - it is not necessary to make it hard to understand by
> decorating it with redundancy...

The non-redundent portion is that the definition focuses on the
communication - rather than the interface.

>>> -> ... [snip] ...
>>> ->=20
>>> -> o  Internal (to a campus): describes communication between rbridge=
=20
>>> ->    devices; this communication may traverse external devices, but
>>> is=20
>>> ->    still considered internal.=20
>>=20
>>> Clearer wording was suggested on this list some time ago.
>>=20
>> The previous proposal had problems:
>
> Which were?  The only indication I have seen that=20
> there were "problems" is in the way that the present
> definition has simply refused to get better.

I have listed the problem below.

> Why not be more specific?

Again, the problem below.

>>> External links/interfaces are those that do not connect to a
>>> cooperating RBridge; internal links/interfaces are those that
>>> do.=20
>>=20
>> what does "connect" mean?
>> 	a) physically connect (probably not)
> =20
> Although, actually, yes in a subset of cases.

That is a trivial subset that we aren't defining rbridges for, so
there's no utility in focusing on that.

>> 	b) attached to the same bridged segment (won't work - see below)
>>=20
> And this is the rest of the cases.  I will address your=20
> issues below.
> =20
>> 	b) communicate directly
>> 		(that's the spirit of what I ended up using)
>=20
> What does "communicate" mean?  Do they gossip among themselves?
> Are they mutual participants in RBridge protocols exchanges, or
> is it sufficient that they pass data in common?  If they are=20
> mutual participants, are they "connected" by some media that we=20
> have determined is "in-scope" for TRILL, or does any connection
> count?
> =20
>> what is being connected?
>> 	the above lists only one end ('to a cooperating rbridge')
> =20
> "Connected" and "being connected" are obviously synonymous.
> =20
> Kind of like "picky" and "being picky" :-)
> =20
>> why is 'cooperating' required?
>>=20
> This is not a new term.  It was introduced weeks (months?)=20
> ago when we were talking about the meaning of "internal"
> and "external".=20

The whole point of an issues list is to have the discussion in a way
that we can refer to. I am hoping posts will enough context for that to
happen.

> It is possible to have multiple RBridge
> "campi" if the RBridges between them are configured not
> to cooperate with each other in hello/discovery protocol.

If that's true (and I hope it is), then BLOCK is absolutely out of the
question - there's no way to avoid loops back and forth between the
campuses (campi is preferred in latin, not English ;-)

> In such a case, and assuming STP blocking, the separate=20
> campi simply do not see each other, even though they are
> "connected" via some media, and "communicate" at the data
> plane level just fine.
>=20
>> Consider the following (all rbridge and bridges shown;=20
>> hosts connect to all devices):
>>=20
>>                r1----r2------b1
>>                |     |       |
>>                |     |       |
>>                r3----r4------b2
>>=20
>>=20
>> is r2-b1 internal or external?
>>=20
>> I would think it is external, since the HELLO would prevent a tunnel
>> being created on r2-b1-b2-r4
>=20
> Huh?  Absolutely not true.  Although it is interesting that=20
> you're assuming that "tunnels" are created.

That's how an rbridge works - the encapsulation headers are tunnels
between ingress and egress rbridges.

> The path - which could become a tunnel if frames are transported
> over it using RBridge-to-Rbridge encapsulation - r2-b1-b2-r4 is
> simply and obviously not a preferred path.  Should it become the
> preferred path, then it will obviously be used to tunnel frames
> between r2 and r4.  Why would we want to assume that another link=20
> going away between r2 and r4 would suddenly make r2-b1-b2-r4 into
> an internal communication (path) or connection?  Let's not confuse
> the terms "internal" and "preferred."

I use the term 'internal' for the tunnels, and external for everything
else. Otherwise, the only thing 'internal' means is 'possible path for a
tunnel' - but that's not really internal. If it's not the active path of
the traffic, it's external.

I.e., your version of 'internal' is more like 'potentially internal'.

> If that _is_ what it means, then it is not a particularly useful
> term...
>=20
> =20
>> However, this definition makes them internal.
> =20
> And, so they are.

What is the point of calling them internal? ALL interfaces that are to
non-stub bridged segments will be internal, but they're not used for
rbridge-rbridge communication.

>> In particular, this definition makes all links/interfaces internal if
>> they connect to an 'external' bridged segment that reconnects to the
>> rbridge elsewhere.
> =20
> Brilliant!  And, of course, absolutely true.  It would be nice
> if this meant we are in agreement - but I believe I detect a
> small bit of irony in your use of single quotes above.

Yes - I don't see what the utility in flagging the world as internal
when they're not actually used for internal communication.

There are paths that are used for internal (rbridge-rbridge)
communication and those that are not. That seems to be what the point of
internal is.

> This happens to be exactly what you convinced me of when last=20
> we had this discussion.  Note, you convinced me!
> =20
> Take - for example - the below figure:
> =20
> =20
>  ---> rb1 <---> rb2 <---> b1 <----> b2 <---> rb3 <---> rb4 <---
>        |         |         |        |         |         |
>        +-> rb5 <-+         +-> b3 <-+         +-> rb6 <-+
>=20
> Earlier, you persuaded me that - as long as rb2 and rb3 are=20
> connected, and not configured to ignore each other - (rb1, rb2, rb5)
> and (rb3, rb4, rb6) are not separate RBridge campi but are instead
> a single RBridge campus.  This, you argued is true because the fact
> that rb2 and rb3 are connected (and communicating control protocol)
> to each other makes the "link" between rb2 and rb3 "internal".

That discussion was before we talked about external hosts hanging off of
b1 (or b2 or b3). In that case, the link acts both internal and
external; we need to distinguish between the two uses.

> Now, take this picture and modify it as shown below:
> =20
>  ---> rb1 <---> rb2 <---> b1 <----> b2 <---> rb3 <---> rb4 <---
>        |         |         |        |         |         |
>        +-> rb5 <-+         +-> b3 <-+         +-> rb6 <-+
>             |                  |
>             +------> b4 <------+
>=20
> The new link, rb5-b4-b3-b2-rb3, is also an internal connection.
> If, for example, the physical connection rb2<->b1 were to go=20
> down, that link (rb5-b4-b3-b2-rb3) would be the only internal
> connection between rb2 and rb3.

This, as well as when hosts exist on those bridges, is why interfaces
and links should not be called 'internal' IMO.

> Similarly, the new link in the above picture - rb5-b4-b3-b1-rb2
> - is also an internal connection.  If we were to subsequently
> lose the (apparently unrelated) connection b2<->rb3, would the
> link rb5-b4-b3-b1-rb2 suddenly become an external link?

This is again the reason internal/external should describe
communication, not links or interfaces.

> It was arguments along this line that originally caused me to
> understand your assertion that you could not normally have two
> or more RBridge campi in the same broadcast domain.
> =20
> Have you forgotten your own arguments?

I have remembered the subsequent resolution of the internal/external
terms with the dual use of a bridged segment - remember? ;-)

> =20
>>> Whether or not non-Bridge devices exist on - or are part=20
>>> of - a link between cooperating RBridges is irrelevant.  The
>>> existing attempt to somehow include the possibility of other
>>> devices as part of a link between RBridges in the definition
>>> of internal and external is only confusing.
>>=20
>>> I believe that the confusion stems from an attempt to allow
>>> for required communications between RBridges and other types
>>> of devices.  This confusion is one strong indication of why
>>> no such communications should be required.
>>=20
>> Rbridges need to talk to bridges at some point; otherwise there's no
>> ingress or egress ;-)
>>=20
> "Talk to" is, I presume, synonymous with "communicate."
>=20
> There is a clear distinction between data-plane and control
> plane communication.

There are four kinds of communication that muddy the data/control
distinction:

	- bridged segment data
	- bridged segment control (e.g., BPDUs)
	- rbridge control (non-ecapsulated HELLO, encapsulated IS-IS)
	- rbridge data (encapsulated)

IMO, the internal/external is defined by encapsulation, not data/control.=


> Once we are in agreement that "internal" and "external" are
> "topological" constructs,

We are not ;-)

> then it should be a simple step to
> agree that an "ingress" is how you get from "external" to=20
> "internal" and an "egress" is how you get from "internal"
>  to "external". =20
> =20
> We don't need to try to make this harder than it is, abusing
> common usage of very well understood terminology.

Agreed. But how do we resolve the fact that internal/external is NOT
topological except to refer to the encapsulation headers instead?

Joe



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

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

iD8DBQFDmc1XE5f5cImnZrsRAm2pAKDHJPevAyYkhP8sjITF64S2Px8EbQCgjWoB
6EzCajZtukXt6bqb6yiNbBs=
=8CqV
-----END PGP SIGNATURE-----

--------------enig18D959BE4F0C748FB97E558B--


Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB9Htj029655; Fri, 9 Dec 2005 09:55:45 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 09 Dec 2005 09:55:38 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA3E6286DEE293022A7BA910C"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Arch Issue #1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2005 17:56:31 -0000
Status: RO
Content-Length: 9015

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



Gray, Eric wrote:
> Joe,
>=20
> 	Please see in-line below...
>=20
> --
> Eric
>=20
> -->=20
> --> Gray, Eric wrote:
> --> > -->=20
> --> > --> #1 resolve recommendations for the three modes of=20
> --> BSTP messages:
> --> > -->    (is this part of the PS or ARCH?)
> --> > --> 	participate
> --> > --> 	forward
> --> > --> 	block
> --> >=20
> --> > Block by default.  Optional configuration for forwarding and/or
> --> > participating MAY be allowed but SHOULD be considered sub-optimal=
=2E
> -->=20
> --> Forward maps to what hubs do.
>=20
> Hubs, repeaters and simple "Work-Group Switches".=20

Those are all what I've been calling 'hubs'.

> Mnay things
> do not participate in STP now and some forward (like the above)
> while others block.

Far as I've been able to find out, the things that block are known as
"broken". If you can point to something specific that blocks that is
widely used - or that is compliant with spec - that'd be useful.

> -->=20
> --> Participate maps to what bridges do.
>=20
> Most bridges.  Mostly agree.
>=20
> -->=20
> --> As a result, either of those can easily be considered as=20
> --> default cases, though forward is clearly suboptimal.
>=20
> "Participate" can be sub-optimal as well, assuming that we're
> talking about simple participation.
>=20
> In simple participation, an RBridge participates with bridges
> both internal and external to the RBridge campus. This makes
> for a single spanning tree and effectively cancels any hopes
> we might have for efficient use of bandwidth - even internal
> to the RBridge campus.

We haven't talked about the internal transit requirements before;
bridges there ARE going run STP/MSTP and coalesce into trees anyway (you
can't stop that). It doesn't matter if such trees touch two rbridges -
there can still be independent paths between the rbridges (though that
needs to be engineered; if they connect anywhere in the middle, the as
you note, the bridging will end up killing the possibility of multipath).=


> In order for this approach to work,
> internal RBridge interfaces MUST be eligible to be put in a
> non-forwarding state by the STP, and - once this is done -=20
> they cannot be used by SPF frame forwarding.

We really need to resolve the discussion of what an 'internal rbridge
interface' is before this sentence can be interpreted completely.

However, putting an interface (any interface) into a nonforwarding state
is just what a root bridge would do anyway, which is why I consider this
a variant of PARTICIPATE.

> More complex participation - which is what I suspect you are
> referring to - would be along the lines of treating external
> interfaces of all RBridges in a single campus as part of a
> single large bridge (you've previously argued that an RBridge=20
> campus may be viewed as a single "virtual bridge").  This is
> more complicated because the STP block and forward decisions
> for all such external interfaces now needs to be collectively
> made (and maintained) across a number of RBridges (all of them
> within a campus).=20

Those decisions already need to be coordinated. Until you decide what's
in and out of an rbridge, you don't know what 'internal' means anyway.

> That would be a non-trivial exercise using
> your favorite proprietary approach; it would be impossible to
> standardize.

Things like the HELLO protocol already start in this direction; are you
suggesting that HELLO will be impossible to standardize? ;-)

> Neither form of participation is preferrable, in the former=20
> case because it is sub-optimal and the latter because of the
> complexity involved.  So the question is can participation be=20
> avoided?=20
>=20
> See below for the answer to this question...
>=20
> -->=20
> --> As to block:
> -->=20
> --> 1. it seems clear that it works only under a certain set of=20
> --> assumptions about ALL other L2 devices:
> -->=20
> --> 	a) ALL other L2 devices MUST pass rbridge's HELLO messages
> -->=20
> --> 	b) ALL other L2 devices MUST NOT also BLOCK
> -->=20
> --> Neither rule can be assumed about an rbridge; by symmetry,=20
> --> why can we assume them about all past and future L2 devices?
>=20
> So, these assumptions are an over-simplification of the problem
> space.
>=20
> For one thing, assuming that the hello/discovery protocol uses
> an appropriate communication layer, then the hello/discovery
> messages MUST be delivered over any non-disfunctional path.

Bridges think that's true for BPDUs too; if rbridges block them, then it
is the rbridge that becomes the disfunctional component.

> There is - by the way - nothing we can, or should try to, do=20
> about disfunctional paths.

Agreed - except not creating them either ;-)

> There is a potential issue with uni-directional communication=20
> paths, but this is addressed by the same approach we've already=20
> discussed for detecting transitive RBridge connectivity.  That
> is, hello/discovery messages are relayed, at least one time,=20
> from all RBridge interfaces (potentially excepting the one on
> which an RBridge receives them), until the are returned to the
> originating RBridge.  This has the effect of letting RBridges
> know which of their interfaces are "internal" and which are=20
> external.  Because messages are forwarded on every RBridge
> interface, this will also detect unidirectional closure.
>=20
> Admittedly, it may be early to establish that this is the way
> that RBridge discovery will work, but the above description=20
> has been mentioned before and certainly can be used as a proof
> of concept demonstration that there is at least one approach=20
> that resolves the issues.
>=20
> Note that using such an approach eliminates issues with any
> potentially anti-social behavior on the part of other devices
> in the LAN.  Paths over which hello/discovery traffic is not
> delivered (is blocked) will not cause loops in other data-plane
> traffic forwarding because devices (other than RBridges) will
> not be able to distinguish RBridge hello/discovery messages
> from any other traffic.

Will they be encrypted? If not, we cannot make this assumption.

> -->=20
> --> 2. BLOCK + HELLO is basically just a variant of an STP=20
> --> where the rbridge is in a privileged position of 'ultimate=20
> --> root' (which is  why it works when the two assumptions=20
> --> above are valid).
>=20
> I disagree that the scenarios in which this approach works
> are limited to this scenario.=20
>=20
> The hello/discovery protocol would derive its properties from
> IGP routing, rather than from bridging and should not involve
> - or directly interact with - bridge control protocol in any=20
> way.
>=20
> See the explanation above...
>=20
> -->=20
> --> We can already assume that STP (or MSTP) works where STP (/MSTP) is=

> --> supported; why not just PARTICIPATE in STP at that point?
>=20
> I believe the reasons for not participating in STP have been=20
> made abundantly clear.
>=20
> -->=20
> --> The HELLOs are just equivalent to BPDUs that discover which edge po=
rts
> --> are connected on the outside anyway. Why not just BPDUs at that poi=
nt?
>=20
> I disagree that hello/discovery messages are anything at all
> like BPDUs.  They are used purely for peer discovery and to
> make the coarse topological distinction between internal and
> external links/interfaces.  They do not get directly involved
> in SPF path calculations once a set of interfaces is found to
> be internal to the RBridge campus.

That's just what BPDUs would do if this were a root. HELLO presumes that
the rbridge is the absolute root; whenever that assumption is incorrect,
there are problems that cannot be resolved.

Joe

>=20
> -->=20
> --> Joe
> --> -----BEGIN PGP SIGNATURE-----
> --> Version: GnuPG v1.2.4 (MingW32)
> --> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> -->=20
> --> iD8DBQFDmKg+E5f5cImnZrsRAku1AKCNmYMTRjr1gRToob+Uh6LV443DcgCffQ1Q
> --> 0DAGlCFmevHRYsQ6yyHgHeY=3D
> --> =3D4ck0
> --> -----END PGP SIGNATURE-----
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://www.postel.org/mailman/listinfo/rbridge
> -->=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


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

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

iD8DBQFDmcUbE5f5cImnZrsRApY4AJoDtVWa1kHoDc5rOZ+AC7Igfg8C9wCeMRNW
0XLF4j6xAo9G8orQkDKEV4k=
=hG62
-----END PGP SIGNATURE-----

--------------enigA3E6286DEE293022A7BA910C--


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 jB9Hdp023488 for <[e-mail]>; Fri, 9 Dec 2005 09:39:51 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB9HdjdJ012185 for <[e-mail]>; Fri, 9 Dec 2005 12:39:45 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA26885 for <[e-mail]>; Fri, 9 Dec 2005 12:39:45 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLHY16>; Fri, 9 Dec 2005 12:39:43 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Fri, 9 Dec 2005 12:39:43 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS Issue #11 -> now ARCH issue #6
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2005 17:40:35 -0000
Status: RO
Content-Length: 9252

Joe,

	See even more comments embedded below...

--
Eric 

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Joe Touch
--> Sent: Thursday, December 08, 2005 5:17 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS Issue #11 -> now ARCH issue #6
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Gray, Eric wrote:
--> > --> 
--> > --> #11 internal/external, inside/outside terminology
--> > -->     there is one objection to these terms as topological;
--> > -->     the draft intends to define them sufficiently
--> > -->     does this need to be addressed further?
--> > 
--> > This is not a Problem Statement Issue because these terms are
--> > defined in draft-touch-trill-rbridge-arch, rather than in
--> > draft-touch-trill-prob.  Consequently, this is an issue with
--> > the Architectural document, if not precisely an architectural
--> > issue.
--> 
--> Yup - needs to be moved to the other doc. Let's call this ARCH issue #6
--> then (see header).

In this case, the PS/ARCH issue is that definitions need
to be moved to the PS document, from the ARCH document.

Issues relating to the specific definitions are issues for
whatever document they are currently in.

--> 
--> > The draft definitions are not sufficiently clear on the current 
--> > iteration.
--> > 
--> > The definitions offered there were - 
--> > 
--> > -> o  External (to a campus): describes communication on the
non-rbridge 
--> > ->    components of an Ethernet link subnet, notably not between 
--> > ->    rbridges or between non-rbridges and rbridges.
--> 
--> The last part is a bug i.e., 'or between non-rbridges and rbridges'. It
--> should be omitted.

The entire statement is hard to parse, even if we were
to agree that this is basically what we want to say.  We
are not agreed, at this point, but a better way to say
what I think you are trying to say is:

o  External (to a campus): describes communication between non-rbridge
   components of an Ethernet subnet.

As I have said numerous times, I have problems with your 
definition, but - even if the WG were to decide to adopt
it - it is not necessary to make it hard to understand by
decorating it with redundancy...

--> 
--> > ->
--> > -> ... [snip] ...
--> > -> 
--> > -> o  Internal (to a campus): describes communication between rbridge 
--> > ->    devices; this communication may traverse external devices, but
is 
--> > ->    still considered internal. 
--> >
--> > Clearer wording was suggested on this list some time ago.
--> 
--> The previous proposal had problems:

Which were?  The only indication I have seen that 
there were "problems" is in the way that the present
definition has simply refused to get better.

Why not be more specific?

--> 
--> > External links/interfaces are those that do not connect to a
--> > cooperating RBridge; internal links/interfaces are those that
--> > do. 
--> 
--> what does "connect" mean?
--> 	a) physically connect (probably not)

Although, actually, yes in a subset of cases.

--> 	b) attached to the same bridged segment (won't work - see below)

And this is the rest of the cases.  I will address your 
issues below.

--> 	b) communicate directly
--> 		(that's the spirit of what I ended up using)

What does "communicate" mean?  Do they gossip among themselves?
Are they mutual participants in RBridge protocols exchanges, or
is it sufficient that they pass data in common?  If they are 
mutual participants, are they "connected" by some media that we 
have determined is "in-scope" for TRILL, or does any connection
count?

--> 
--> what is being connected?
--> 	the above lists only one end ('to a cooperating rbridge')

"Connected" and "being connected" are obviously synonymous.

Kind of like "picky" and "being picky" :-)

--> 
--> why is 'cooperating' required?

This is not a new term.  It was introduced weeks (months?) 
ago when we were talking about the meaning of "internal"
and "external".  It is possible to have multiple RBridge
"campi" if the RBridges between them are configured not
to cooperate with each other in hello/discovery protocol.

In such a case, and assuming STP blocking, the separate 
campi simply do not see each other, even though they are
"connected" via some media, and "communicate" at the data
plane level just fine.

--> 
--> Consider the following (all rbridge and bridges shown; 
--> hosts connect to all devices):
--> 
-->                r1----r2------b1
-->                |     |       |
-->                |     |       |
-->                r3----r4------b2
--> 
--> 
--> is r2-b1 internal or external?
--> 
--> I would think it is external, since the HELLO would prevent a tunnel
--> being created on r2-b1-b2-r4

Huh?  Absolutely not true.  Although it is interesting that 
you're assuming that "tunnels" are created.

The path - which could become a tunnel if frames are transported
over it using RBridge-to-Rbridge encapsulation - r2-b1-b2-r4 is
simply and obviously not a preferred path.  Should it become the
preferred path, then it will obviously be used to tunnel frames
between r2 and r4.  Why would we want to assume that another link 
going away between r2 and r4 would suddenly make r2-b1-b2-r4 into
an internal communication (path) or connection?  Let's not confuse
the terms "internal" and "preferred."

If that _is_ what it means, then it is not a particularly useful
term...

--> 
--> However, this definition makes them internal.

And, so they are.

--> 
--> In particular, this definition makes all links/interfaces internal if
--> they connect to an 'external' bridged segment that reconnects to the
--> rbridge elsewhere.

Brilliant!  And, of course, absolutely true.  It would be nice
if this meant we are in agreement - but I believe I detect a
small bit of irony in your use of single quotes above.

This happens to be exactly what you convinced me of when last 
we had this discussion.  Note, you convinced me!

Take - for example - the below figure:


 ---> rb1 <---> rb2 <---> b1 <----> b2 <---> rb3 <---> rb4 <---
       |         |         |        |         |         |
       +-> rb5 <-+         +-> b3 <-+         +-> rb6 <-+

Earlier, you persuaded me that - as long as rb2 and rb3 are 
connected, and not configured to ignore each other - (rb1, rb2, rb5)
and (rb3, rb4, rb6) are not separate RBridge campi but are instead
a single RBridge campus.  This, you argued is true because the fact
that rb2 and rb3 are connected (and communicating control protocol)
to each other makes the "link" between rb2 and rb3 "internal".

Now, take this picture and modify it as shown below:

 ---> rb1 <---> rb2 <---> b1 <----> b2 <---> rb3 <---> rb4 <---
       |         |         |        |         |         |
       +-> rb5 <-+         +-> b3 <-+         +-> rb6 <-+
            |                  |
            +------> b4 <------+

The new link, rb5-b4-b3-b2-rb3, is also an internal connection.
If, for example, the physical connection rb2<->b1 were to go 
down, that link (rb5-b4-b3-b2-rb3) would be the only internal
connection between rb2 and rb3.

Similarly, the new link in the above picture - rb5-b4-b3-b1-rb2
- is also an internal connection.  If we were to subsequently
lose the (apparently unrelated) connection b2<->rb3, would the
link rb5-b4-b3-b1-rb2 suddenly become an external link?

It was arguments along this line that originally caused me to
understand your assertion that you could not normally have two
or more RBridge campi in the same broadcast domain.

Have you forgotten your own arguments?

--> 
--> > Whether or not non-Bridge devices exist on - or are part 
--> > of - a link between cooperating RBridges is irrelevant.  The
--> > existing attempt to somehow include the possibility of other
--> > devices as part of a link between RBridges in the definition
--> > of internal and external is only confusing.
--> > 
--> > I believe that the confusion stems from an attempt to allow
--> > for required communications between RBridges and other types
--> > of devices.  This confusion is one strong indication of why
--> > no such communications should be required.
--> 
--> Rbridges need to talk to bridges at some point; otherwise there's no
--> ingress or egress ;-)

"Talk to" is, I presume, synonymous with "communicate."

There is a clear distinction between data-plane and control
plane communication.

Once we are in agreement that "internal" and "external" are
"topological" constructs, then it should be a simple step to
agree that an "ingress" is how you get from "external" to 
"internal" and an "egress" is how you get from "internal"
to "external".  

We don't need to try to make this harder than it is, abusing
common usage of very well understood terminology.

--> 
--> Joe
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDmLC+E5f5cImnZrsRAlXZAKCJZsBCaNsffdCBZThm+9Ca6WLxPwCfbdXV
--> 5KCUBeCNg2oelTukVeU1mMA=
--> =PF20
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB9GbR002122 for <[e-mail]>; Fri, 9 Dec 2005 08:37:27 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB9GbLdJ010746 for <[e-mail]>; Fri, 9 Dec 2005 11:37:22 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA19450 for <[e-mail]>; Fri, 9 Dec 2005 11:37:21 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLHV8K>; Fri, 9 Dec 2005 11:37:20 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Fri, 9 Dec 2005 11:37:19 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Arch Issue #2 and #3
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2005 16:38:48 -0000
Status: RO
Content-Length: 7020

Joe,

	Please see additional comments in-line below...

--
Eric 

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Joe Touch
--> Sent: Thursday, December 08, 2005 4:49 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Arch Issue #2 and #3
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Gray, Eric wrote:
--> > --> 
--> > --> #2 is an rbridge the DR of the edge STPs?
--> > 
--> > It may be.  This relates to architectural issue #3 - see below.
--> > 
--> > --> 
--> > --> #3 do rbridges have proxy bridges at their edges (see Radia's post
of
--> > --> 10/21/2005)?
--> > --> (see Guillermo's text below)
--> > 
--> > Radia explicitly suggested this in order to propose that this is 
--> > out of scope for the TRILL working group.
--> 
--> My impression was more that this was a way to implement PARTICIPATE...

Actually, I cannot determine how it is possible to derive
that impression - at least within the RBridge context.

Radia's assumption in her description is that the RBridge
portion of the described hybrid _implementation_ would be
_blocking_ STP.  Otherwise, there would be no requirement
to include the logical, in-line, bridge.

While you could argue that such an _implementation_ does
participate in STP, its participation is limited and aimed
at a single-minded purpose - i.e. - establishing itself as
the spanning tree root.  Because the RBridge in this mode
would be blocking STP, the in-line bridge has nothing of
any topological significance to add to STP other than to
nominate itself (forcefully) as a root candidate for the
spanning tree.

The proposal was very clearly to demonstrate that what
Guillermo wanted could be _implemented_ orthogonally to 
specification of base-line RBridge behavior.

--> 
--> or actually a variant of BLOCK (see my other message)

Blocking of STP is assumed in this model.  I believe if 
you were to talk to Radia, you would discover that she 
has assumed STP blocking behavior from the beginning and
has not seen any reason to change that assumption.  But,
don't take my opinion on the matter, ask her...

--> 
--> > An RBridge may be collocated with any number of bridges.  An RBRidge
--> > implementation may logically connect such a collocated bridge in-line
--> > with any of its interfaces.
--> > 
--> > In this case, it is possible to build an RBridge implementation that
--> > participates in STP/RSTP and it is possible to configure the in-line
--> > bridge in such a way as to guarantee that it will become the root of
--> > the STP.
--> 
--> Can you force a single bridge to be root of an STP? If so, what happens
--> when two such bridges are on the same segment? (that seems to be the
rub)...

No rub to it, and this is precisely why Radia made this 
proposal.  I was objecting to the implied configuration
requirements and Guillermo was firm in requiring a way
to do it.

The way that you can "force a single bridge to be root
of an STP" is via configuration.  Clearly it is possible
to configure two bridges on the same segment to have the
same priority in the root selection process and that is
why the process has tie-breaking provisions.  That is 
also the reason why it is (and MUST be) strictly a
configuration option.

--> 
--> Joe
--> 
--> > 
--> > This is not required of an RBridge implementation - even if it were
--> > to turn out to be a common implementation case.  Rather, this is an
--> > offered example - by way of proof of concept - that we do not need 
--> > to define this behavior as part of base-line RBridge behavior.
--> > 
--> > Speaking of orthogonality, this discussion (below) will be included 
--> > in the next iteration of TRILL routing requirements, when it is 
--> > submitted.  Assuming that draft eventually becomes a WG draft, you 
--> > may want to simply refer to that document in the architecture draft.
--> > 
--> > --> - -----
--> > --> 
--> > --> Guillermo's text for ARCH #3:
--> > --> 
--> > --> RBridge indirect participation in bridged island spanning tree.
--> > --> - 
--> ---------------------------------------------------------------
--> > --> RBridges by default do not participate in spanning tree in other
way
--> > --> than ignoring received BPDUs. It is an objective of RBridge
--> > --> specification to be independent of bridges specifications as much
as
--> > --> possible.
--> > --> 
--> > --> However it may be convenient for RBridges in some circumstances to
--> > --> participate in the spanning tree and contend to be root bridge of
the
--> > --> spanning tree formed in the bridged island they are attached to.
In
--> > --> these cases it is possible to build a device that's logically the
same
--> > --> as a bridge glued onto an RBridge. The following schema applies:
--> > --> 
--> > -->                         ?-----------?
--> > -->        bridged island-----B1----RB1 ?
--> > -->                         ?-----------?
--> > --> 
--> > -->                         RBridge/bridge box
--> > --> 
--> > --> where B1 is a bridge with two ports...a pt-to-pt link to RBRidge
RB1,
--> > --> and a link to the bridged LAN. The "RB1" portion of this box acts
as
--> > --> an standard RBridge, it neither forwards, nor initiates spanning
tree
--> > --> messages. The "B1" portion acts as two-port standard 802.1D
bridge, 
--> > --> and does participate in spanning tree. Its priority for root
election 
--> > --> can be set in the standard way. To minimize configurafion, it may 
--> > --> be convenient in some implementations to make the standard B1
bridge 
--> > --> priority a function of the configurable RBridge priority for IS-IS

--> > --> Designated RBridge election. In this way Designated RBridge will 
--> > --> participate and contend (as B1) to be elected also as root bridge
of 
--> > --> the bridged island and only one priority configuration is
required.
--> > --> 
--> > --> If (in environments using such implementations) the default bridge
--> > --> priority for B1 is lower than standard bridge priority, by default
--> > --> RBridges/bridges like B1 shown will become roots of their bridged
--> > --> islands, contending only with other RBridges connected to same
island
--> > --> for root election. It is not mandatory for RBridges becombined
bridge/
--> > --> RBridges.
--> > --> 
--> > --> - -------
--> > --> 
--> > 
--> > --
--> > Eric
--> > _______________________________________________
--> > rbridge mailing list
--> > [e-mail]
--> > http://www.postel.org/mailman/listinfo/rbridge
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDmKpIE5f5cImnZrsRAs/tAKCRkMxmz15gopFBmeHSJ5xZOfz4owCeMznn
--> DIBxUhcFFdtcp5K3KvwZRWU=
--> =yueR
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB9GFE025699 for <[e-mail]>; Fri, 9 Dec 2005 08:15:15 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB9GF8dJ010023 for <[e-mail]>; Fri, 9 Dec 2005 11:15:09 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA16060 for <[e-mail]>; Fri, 9 Dec 2005 11:15:08 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLH47J>; Fri, 9 Dec 2005 11:15:07 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Fri, 9 Dec 2005 11:15:06 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Arch Issue #1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2005 16:15:32 -0000
Status: RO
Content-Length: 5982

Joe,

	Please see in-line below...

--
Eric

--> 
--> Gray, Eric wrote:
--> > --> 
--> > --> #1 resolve recommendations for the three modes of 
--> BSTP messages:
--> > -->    (is this part of the PS or ARCH?)
--> > --> 	participate
--> > --> 	forward
--> > --> 	block
--> > 
--> > Block by default.  Optional configuration for forwarding and/or
--> > participating MAY be allowed but SHOULD be considered sub-optimal.
--> 
--> Forward maps to what hubs do.

Hubs, repeaters and simple "Work-Group Switches".  Mnay things
do not participate in STP now and some forward (like the above)
while others block.

--> 
--> Participate maps to what bridges do.

Most bridges.  Mostly agree.

--> 
--> As a result, either of those can easily be considered as 
--> default cases, though forward is clearly suboptimal.

"Participate" can be sub-optimal as well, assuming that we're
talking about simple participation.

In simple participation, an RBridge participates with bridges
both internal and external to the RBridge campus. This makes
for a single spanning tree and effectively cancels any hopes
we might have for efficient use of bandwidth - even internal
to the RBridge campus.  In order for this approach to work,
internal RBridge interfaces MUST be eligible to be put in a
non-forwarding state by the STP, and - once this is done - 
they cannot be used by SPF frame forwarding.

More complex participation - which is what I suspect you are
referring to - would be along the lines of treating external
interfaces of all RBridges in a single campus as part of a
single large bridge (you've previously argued that an RBridge 
campus may be viewed as a single "virtual bridge").  This is
more complicated because the STP block and forward decisions
for all such external interfaces now needs to be collectively
made (and maintained) across a number of RBridges (all of them
within a campus).  That would be a non-trivial exercise using
your favorite proprietary approach; it would be impossible to
standardize.

Neither form of participation is preferrable, in the former 
case because it is sub-optimal and the latter because of the
complexity involved.  So the question is can participation be 
avoided? 

See below for the answer to this question...

--> 
--> As to block:
--> 
--> 1. it seems clear that it works only under a certain set of 
--> assumptions about ALL other L2 devices:
--> 
--> 	a) ALL other L2 devices MUST pass rbridge's HELLO messages
--> 
--> 	b) ALL other L2 devices MUST NOT also BLOCK
--> 
--> Neither rule can be assumed about an rbridge; by symmetry, 
--> why can we assume them about all past and future L2 devices?

So, these assumptions are an over-simplification of the problem
space.

For one thing, assuming that the hello/discovery protocol uses
an appropriate communication layer, then the hello/discovery
messages MUST be delivered over any non-disfunctional path.

There is - by the way - nothing we can, or should try to, do 
about disfunctional paths.

There is a potential issue with uni-directional communication 
paths, but this is addressed by the same approach we've already 
discussed for detecting transitive RBridge connectivity.  That
is, hello/discovery messages are relayed, at least one time, 
from all RBridge interfaces (potentially excepting the one on
which an RBridge receives them), until the are returned to the
originating RBridge.  This has the effect of letting RBridges
know which of their interfaces are "internal" and which are 
external.  Because messages are forwarded on every RBridge
interface, this will also detect unidirectional closure.

Admittedly, it may be early to establish that this is the way
that RBridge discovery will work, but the above description 
has been mentioned before and certainly can be used as a proof
of concept demonstration that there is at least one approach 
that resolves the issues.

Note that using such an approach eliminates issues with any
potentially anti-social behavior on the part of other devices
in the LAN.  Paths over which hello/discovery traffic is not
delivered (is blocked) will not cause loops in other data-plane
traffic forwarding because devices (other than RBridges) will
not be able to distinguish RBridge hello/discovery messages
from any other traffic.

--> 
--> 2. BLOCK + HELLO is basically just a variant of an STP 
--> where the rbridge is in a privileged position of 'ultimate 
--> root' (which is  why it works when the two assumptions 
--> above are valid).

I disagree that the scenarios in which this approach works
are limited to this scenario. 

The hello/discovery protocol would derive its properties from
IGP routing, rather than from bridging and should not involve
- or directly interact with - bridge control protocol in any 
way.

See the explanation above...

--> 
--> We can already assume that STP (or MSTP) works where STP (/MSTP) is
--> supported; why not just PARTICIPATE in STP at that point?

I believe the reasons for not participating in STP have been 
made abundantly clear.

--> 
--> The HELLOs are just equivalent to BPDUs that discover which edge ports
--> are connected on the outside anyway. Why not just BPDUs at that point?

I disagree that hello/discovery messages are anything at all
like BPDUs.  They are used purely for peer discovery and to
make the coarse topological distinction between internal and
external links/interfaces.  They do not get directly involved
in SPF path calculations once a set of interfaces is found to
be internal to the RBridge campus.

--> 
--> Joe
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDmKg+E5f5cImnZrsRAku1AKCNmYMTRjr1gRToob+Uh6LV443DcgCffQ1Q
--> 0DAGlCFmevHRYsQ6yyHgHeY=
--> =4ck0
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB9GBs024489; Fri, 9 Dec 2005 08:11:54 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 09 Dec 2005 08:11:49 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA8D0F03A0C77C698914A63BA"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Arch Issue #2 and #3
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2005 16:12:41 -0000
Status: RO
Content-Length: 5792

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



Guillermo Ib=E1=F1ez wrote:
>=20
> Joe Touch wrote:
>=20
>=20
>=20
> Gray, Eric wrote:
> =20
>=20
>>>> -->=20
>>>> --> #2 is an rbridge the DR of the edge STPs?
>>>>
>>>> It may be.  This relates to architectural issue #3 - saee below.
>>>>
>>>> -->=20
>>>> --> #3 do rbridges have proxy bridges at their edges (see Radia's po=
st of
>>>> --> 10/21/2005)?
>>>> --> (see Guillermo's text below)
>>>>
>>>> Radia explicitly suggested this in order to propose that this is=20
>>>> out of scope for the TRILL working group.
>>>>   =20
>>>>
> My impression was more that this was a way to implement PARTICIPATE...
>=20
> or actually a variant of BLOCK (see my other message)
>=20
> =20
>=20
>>>> An RBridge may be collocated with any number of bridges.  An RBRidge=

>>>> implementation may logically connect such a collocated bridge in-lin=
e
>>>> with any of its interfaces.
>>>>
>>>> In this case, it is possible to build an RBridge implementation that=

>>>> participates in STP/RSTP and it is possible to configure the in-line=

>>>> bridge in such a way as to guarantee that it will become the root of=

>>>> the STP.
>>>>   =20
>>>>
> Can you force a single bridge to be root of an STP? If so, what happens=

> when two such bridges are on the same segment? (that seems to be the ru=
b)...
>=20
> Joe
> =20
>=20
>> The bridge (of the two)  with lower bridge identity=3D priority value =
+=20
>> MAC address will be elected as root bridge.
>> Guillermo

Right. So absolutely NO way to *force* a single bridge to win root
election (if there were such a way, they'd conflict and need such a tie
break; there's no way for BOTH to win such a tie).

Joe

>=20
> =20
>=20
>>>> This is not required of an RBridge implementation - even if it were
>>>> to turn out to be a common implementation case.  Rather, this is an
>>>> offered example - by way of proof of concept - that we do not need=20
>>>> to define this behavior as part of base-line RBridge behavior.
>>>>
>>>> Speaking of orthogonality, this discussion (below) will be included =

>>>> in the next iteration of TRILL routing requirements, when it is=20
>>>> submitted.  Assuming that draft eventually becomes a WG draft, you=20
>>>> may want to simply refer to that document in the architecture draft.=

>>>>
>>>> --> - -----
>>>> -->=20
>>>> --> Guillermo's text for ARCH #3:
>>>> -->=20
>>>> --> RBridge indirect participation in bridged island spanning tree.
>>>> --> - --------------------------------------------------------------=
-
>>>> --> RBridges by default do not participate in spanning tree in other=
 way
>>>> --> than ignoring received BPDUs. It is an objective of RBridge
>>>> --> specification to be independent of bridges specifications as muc=
h as
>>>> --> possible.
>>>> -->=20
>>>> --> However it may be convenient for RBridges in some circumstances =
to
>>>> --> participate in the spanning tree and contend to be root bridge o=
f the
>>>> --> spanning tree formed in the bridged island they are attached to.=
 In
>>>> --> these cases it is possible to build a device that's logically th=
e same
>>>> --> as a bridge glued onto an RBridge. The following schema applies:=

>>>> -->=20
>>>> -->                         =A1-----------=A1
>>>> -->        bridged island-----B1----RB1 =A1
>>>> -->                         =A1-----------=A1
>>>> -->=20
>>>> -->                         RBridge/bridge box
>>>> -->=20
>>>> --> where B1 is a bridge with two ports...a pt-to-pt link to RBRidge=
 RB1,
>>>> --> and a link to the bridged LAN. The "RB1" portion of this box act=
s as
>>>> --> an standard RBridge, it neither forwards, nor initiates spanning=
 tree
>>>> --> messages. The "B1" portion acts as two-port standard 802.1D brid=
ge,=20
>>>> --> and does participate in spanning tree. Its priority for root ele=
ction=20
>>>> --> can be set in the standard way. To minimize configurafion, it ma=
y=20
>>>> --> be convenient in some implementations to make the standard B1 br=
idge=20
>>>> --> priority a function of the configurable RBridge priority for IS-=
IS=20
>>>> --> Designated RBridge election. In this way Designated RBridge will=
=20
>>>> --> participate and contend (as B1) to be elected also as root bridg=
e of=20
>>>> --> the bridged island and only one priority configuration is requir=
ed.
>>>> -->=20
>>>> --> If (in environments using such implementations) the default brid=
ge
>>>> --> priority for B1 is lower than standard bridge priority, by defau=
lt
>>>> --> RBridges/bridges like B1 shown will become roots of their bridge=
d
>>>> --> islands, contending only with other RBridges connected to same i=
sland
>>>> --> for root election. It is not mandatory for RBridges becombined b=
ridge/
>>>> --> RBridges.
>>>> -->=20
>>>> --> - -------
>>>> -->=20
>>>>
>>>> --
>>>> Eric
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> [e-mail]
>>>> http://www.postel.org/mailman/listinfo/rbridge
>>>>   =20
>>>>
_______________________________________________
rbridge mailing list
[e-mail]
http://www.postel.org/mailman/listinfo/rbridge
>>

>>



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

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

iD8DBQFDmazFE5f5cImnZrsRAn/eAJ4kM1qU7x2+1VUgDR8nKkHp7aA4xACgz3FE
8hggPU4X+td5na2e9/70Ihs=
=Pmrv
-----END PGP SIGNATURE-----

--------------enigA8D0F03A0C77C698914A63BA--


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 jB9Eng000724 for <[e-mail]>; Fri, 9 Dec 2005 06:49:42 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB9EnbdJ007611 for <[e-mail]>; Fri, 9 Dec 2005 09:49:37 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA03956 for <[e-mail]>; Fri, 9 Dec 2005 09:49:33 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLHRST>; Fri, 9 Dec 2005 09:49:31 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Fri, 9 Dec 2005 09:49:30 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2005 14:50:37 -0000
Status: RO
Content-Length: 2172

Alia,

	Actually, this is getting more into implementation 
than I believe we should.  It may be sufficient for us to
recommend injection of some random factor into <whatever>
path selection algorithm - obviously during initialization
- in order to avoid synchronization problems during path
selections.  

	Conversely, we could view this as telling people not 
to build bad implementations - which is not what we should 
be doing.

	After all, our employers are not generally motivated
to tell other companies how to build a better mouse trap.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Alia Atlas
--> Sent: Friday, December 09, 2005 2:24 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS issue #4
--> 
--> On 12/8/05, Gray, Eric <[e-mail]> wrote:
--> >         Any specific path selection algorithm affects only the
--> > device making the path selection.  That means it comes under
--> > the heading of "what I do in my box is my own business."
--> >
--> >         What really needs to be said - particularly at a level
--> > of "architecture" is that devices using multiple paths to
--> > forward frames MUST use some path selection algorithm that
--> > will prevent persistent re-ordering of frames within flows.
--> 
--> It may also be worthwhile to point out that a different 
--> seed into the
--> hash function at each
--> point is important to improve load-balancing at different rbridges
--> along a path.  Otherwise, there is the risk that, in the 
--> trivial case,
--> only traffic with hash x will reach an rbridge from a particular
--> interface so that when that rbridge tries to load-balance by using
--> hash x and y, it only has hash x traffic and no 
--> load-balancing occurs.
--> 
--> I think this is important at the "architecture' because, without it,
--> load-balancing is at risk of working very poorly for sequential
--> rbridges that have ecmp.
--> 
--> Alia
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [216.148.227.154]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB9Csd028071 for <[e-mail]>; Fri, 9 Dec 2005 04:54:39 -0800 (PST)
Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165]) by comcast.net (rwcrmhc14) with SMTP id <20051209125431014008hs61e>; Fri, 9 Dec 2005 12:54:31 +0000
Message-ID: <3ff401c5fcbf$9320ca80$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]><3b7401c5fc36$4b50fec0$[e-mail]> <[e-mail]>
Date: Fri, 9 Dec 2005 06:53:38 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2005 12:55:32 -0000
Status: RO
Content-Length: 1481

Thanks (to Guillermo) for providing this pointer.

I wasn't trying to imply that we could ignore the proposal, I just didn't 
have a reference that we could use to consider it.

I still agree with Eric on "don't expect both in the same bridged network, 
but don't break when someone (accidentally) turns on both in the same 
bridged network".

Spencer

----- Original Message ----- 
From: "Guillermo Ib??ez" <[e-mail]>

>>Since Shortest Path Bridging appears to target a similar problem
>>space, I don't think it makes sense for us to try to compete with
>>that as a solution.  However, we will need to establish that we
>>are not "breaking" it either...
>
>Agree - my point here was more like "this only exists as a tutorial
>presentation so far, we'll need to come back to it when we are closer to
>publishing".
>
>Spencer
>
>
The proposal of this document on Shortest Path Bridging  is far more
than a "tutorial" to be ignored.

http://www.ieee802.org/1/files/public/docs2005/new-seaman-shortest-path-0305-02.pdf
Regards
Guillermo

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

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

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



Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB9AQH023712 for <[e-mail]>; Fri, 9 Dec 2005 02:26:17 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 077A284C84 for <[e-mail]>; Fri,  9 Dec 2005 11:26:11 +0100 (CET)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp02.uc3m.es (Postfix) with ESMTP id 5B06F84B25 for <[e-mail]>; Fri,  9 Dec 2005 11:26:10 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 09 Dec 2005 11:26:10 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] MAC aggregation in rbridge? UETS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2005 10:26:33 -0000
Status: RO
Content-Length: 2783

 This additional document from IEEE Global Communications Newsletter 
October 2005, may help to better understand the UETS proposal, mentioned 
in my previous mail,   that includes MAC aggregation.
http://www.lmdata.es/uets/uets-gcn.pdf
Guillermo

Guillermo Ib??ez wrote:

>Sakku, Steven,
>
>Just for  information on MAC aggregation, you can find here a link to a 
>proposal  originated by Jose  Morales, based on private MAC  addresses 
>assignment by ISPs (and the like), that allows aggregation.  I have no 
>defined position on this proposal, but there are interesting aspects on 
>it to analyze. Regarding upper layers the proposal is quite radical.
>Guillermo
>
> http://www.lmdata.es/uets/uets-cm1.pdf
>
>Steven Bakker wrote:
>
>  
>
>>On Wed, 2005-12-07 at 12:32 +0200, Saku Ytti wrote:
>>
>> 
>>
>>    
>>
>>>I was thinking about the feasibility of supporting MAC address aggregation
>>>in rbridges. How I think it could work in most simple way is that each rbridge
>>>has it's own MAC 'prefix' and it then performs MAC rewrite on it's 'edge'
>>>port, effectively changing the original MAC to rbridge prefix+ifindex. Then
>>>you'd have aggregated MAC TLV with mask to propagate the information.
>>>   
>>>
>>>      
>>>
>>Mmmh, sounds like a L2 NAT? Just as in L3 (IPv4) NAT, L2 NAT has the
>>potential to break many things. Right off the bat, I can tell you it
>>will break ARP since ARP packets carry MAC address information in their
>>payload. This means that for L2 NAT to work, your rbridges need to know
>>about possible protocol and rewrite payloads, recalculate checksums,
>>etc. This is not going to work. And even if it could, would that scale
>>to 10GE and higher speeds? That's an awful lot of rewriting...
>>
>> 
>>
>>    
>>
>>>Is this feasible? Is this needed or is it more sane to just grow
>>>TCAM sizes?
>>>   
>>>
>>>      
>>>
>>IMO, it is unfeasible, unnecessary, and very undesired. Wearing the hat
>>of my current employer (large scale Internet exchange), I like the idea
>>of rbridge for its potential to better utilise the available links and
>>efficiently route traffic. I pretty much have all the TCAM I need.
>>
>>MAC aggregation might make sense if there were some kind of structure on
>>the allocation of addresses (as in IPv4/v6), but there is not.
>>
>>Regards,
>>Steven
>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>>
>> 
>>
>>    
>>
>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

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



Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB9A6N018079 for <[e-mail]>; Fri, 9 Dec 2005 02:06:23 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 29A3884807 for <[e-mail]>; Fri,  9 Dec 2005 11:06:17 +0100 (CET)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp02.uc3m.es (Postfix) with ESMTP id 91D9384772 for <[e-mail]>; Fri,  9 Dec 2005 11:06:16 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 09 Dec 2005 11:06:16 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <3b7401c5fc36$4b50fec0$[e-mail]>
In-Reply-To: <3b7401c5fc36$4b50fec0$[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2005 10:07:23 -0000
Status: RO
Content-Length: 1697

Spencer Dawkins wrote:

>>--> #1 which version of ethernet is the baseline?
>>--> STP, RSTP, VLAN, provider bridges, wireless,
>>--> shortest path bridging, etc.
>>--> (this will help us determine what terminology to use)
>>
>>IMO, STP/RST, and VLAN.  Wireless is a possibility to the extent
>>that it is directly compatible with 802.1 (STP/RSTP) and VLAN.
>>
>>I am not sure what you mean by provider bridges, but assuming
>>it is like a WAN bridging service, this SHOULD be transparent
>>to RBridges and may be included.
>>    
>>
>
>I meant 802.1ad - Provider Bridges, which has gotten as far as sponsor 
>ballot. It's not unreasonable to wonder about 802.1ah - Provider Backbone 
>Bridges, but that's not nearly as far down the specification process.
>
>  
>
>>Since Shortest Path Bridging appears to target a similar problem
>>space, I don't think it makes sense for us to try to compete with
>>that as a solution.  However, we will need to establish that we
>>are not "breaking" it either...
>>    
>>
>
>Agree - my point here was more like "this only exists as a tutorial 
>presentation so far, we'll need to come back to it when we are closer to 
>publishing".
>
>Spencer 
>  
>
The proposal of this document on Shortest Path Bridging  is far more 
than a "tutorial" to be ignored.

http://www.ieee802.org/1/files/public/docs2005/new-seaman-shortest-path-0305-02.pdf
Regards
Guillermo

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

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



Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB99vb015167 for <[e-mail]>; Fri, 9 Dec 2005 01:57:37 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8FC4B84CDA for <[e-mail]>; Fri,  9 Dec 2005 10:57:31 +0100 (CET)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp02.uc3m.es (Postfix) with ESMTP id EC69084C51 for <[e-mail]>; Fri,  9 Dec 2005 10:57:30 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 09 Dec 2005 10:57:30 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Arch Issue #1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2005 09:58:29 -0000
Status: RO
Content-Length: 2157

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Gray, Eric wrote:
>  
>
>>--> 
>>--> #1 resolve recommendations for the three modes of BSTP messages:
>>-->    (is this part of the PS or ARCH?)
>>--> 	participate
>>--> 	forward
>>--> 	block
>>
>>Block by default.  Optional configuration for forwarding and/or
>>participating MAY be allowed but SHOULD be considered sub-optimal.
>>    
>>
>
>Forward maps to what hubs do.
>
>Participate maps to what bridges do.
>
>As a result, either of those can easily be considered as default cases,
>though forward is clearly suboptimal.
>
>As to block:
>
>1. it seems clear that it works only under a certain set of assumptions
>about ALL other L2 devices:
>
>	a) ALL other L2 devices MUST pass rbridge's HELLO messages
>
>	b) ALL other L2 devices MUST NOT also BLOCK
>
>Neither rule can be assumed about an rbridge; by symmetry, why can we
>assume them about all past and future L2 devices?
>
>2. BLOCK + HELLO is basically just a variant of an STP where the rbridge
>is in a privileged position of 'ultimate root' (which is why it works
>when the two assumptions above are valid).
>
>We can already assume that STP (or MSTP) works where STP (/MSTP) is
>supported; why not just PARTICIPATE in STP at that point?
>
>The HELLOs are just equivalent to BPDUs that discover which edge ports
>are connected on the outside anyway. Why not just BPDUs at that point?
>  
>
So the DR election might be replaced by root bridge election. This is in 
line with my proposal related with the edge Rbridge being root bridge of 
the link.

>Joe
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDmKg+E5f5cImnZrsRAku1AKCNmYMTRjr1gRToob+Uh6LV443DcgCffQ1Q
>0DAGlCFmevHRYsQ6yyHgHeY=
>=4ck0
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

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



Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB99qe013641 for <[e-mail]>; Fri, 9 Dec 2005 01:52:41 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 96F7184C7E for <[e-mail]>; Fri,  9 Dec 2005 10:52:34 +0100 (CET)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp02.uc3m.es (Postfix) with ESMTP id 91DA884C13 for <[e-mail]>; Fri,  9 Dec 2005 10:52:33 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 09 Dec 2005 10:52:33 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Arch Issue #2 and #3
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2005 09:53:48 -0000
Status: RO
Content-Length: 4893

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Gray, Eric wrote:
>  
>
>>--> 
>>--> #2 is an rbridge the DR of the edge STPs?
>>
>>It may be.  This relates to architectural issue #3 - saee below.
>>
>>--> 
>>--> #3 do rbridges have proxy bridges at their edges (see Radia's post of
>>--> 10/21/2005)?
>>--> (see Guillermo's text below)
>>
>>Radia explicitly suggested this in order to propose that this is 
>>out of scope for the TRILL working group.
>>    
>>
>
>My impression was more that this was a way to implement PARTICIPATE...
>
>or actually a variant of BLOCK (see my other message)
>
>  
>
>>An RBridge may be collocated with any number of bridges.  An RBRidge
>>implementation may logically connect such a collocated bridge in-line
>>with any of its interfaces.
>>
>>In this case, it is possible to build an RBridge implementation that
>>participates in STP/RSTP and it is possible to configure the in-line
>>bridge in such a way as to guarantee that it will become the root of
>>the STP.
>>    
>>
>
>Can you force a single bridge to be root of an STP? If so, what happens
>when two such bridges are on the same segment? (that seems to be the rub)...
>
>Joe
>  
>
The bridge (of the two)  with lower bridge identity= priority value + 
MAC address will be elected as root bridge.
Guillermo

>  
>
>>This is not required of an RBridge implementation - even if it were
>>to turn out to be a common implementation case.  Rather, this is an
>>offered example - by way of proof of concept - that we do not need 
>>to define this behavior as part of base-line RBridge behavior.
>>
>>Speaking of orthogonality, this discussion (below) will be included 
>>in the next iteration of TRILL routing requirements, when it is 
>>submitted.  Assuming that draft eventually becomes a WG draft, you 
>>may want to simply refer to that document in the architecture draft.
>>
>>--> - -----
>>--> 
>>--> Guillermo's text for ARCH #3:
>>--> 
>>--> RBridge indirect participation in bridged island spanning tree.
>>--> - ---------------------------------------------------------------
>>--> RBridges by default do not participate in spanning tree in other way
>>--> than ignoring received BPDUs. It is an objective of RBridge
>>--> specification to be independent of bridges specifications as much as
>>--> possible.
>>--> 
>>--> However it may be convenient for RBridges in some circumstances to
>>--> participate in the spanning tree and contend to be root bridge of the
>>--> spanning tree formed in the bridged island they are attached to. In
>>--> these cases it is possible to build a device that's logically the same
>>--> as a bridge glued onto an RBridge. The following schema applies:
>>--> 
>>-->                         ?-----------?
>>-->        bridged island-----B1----RB1 ?
>>-->                         ?-----------?
>>--> 
>>-->                         RBridge/bridge box
>>--> 
>>--> where B1 is a bridge with two ports...a pt-to-pt link to RBRidge RB1,
>>--> and a link to the bridged LAN. The "RB1" portion of this box acts as
>>--> an standard RBridge, it neither forwards, nor initiates spanning tree
>>--> messages. The "B1" portion acts as two-port standard 802.1D bridge, 
>>--> and does participate in spanning tree. Its priority for root election 
>>--> can be set in the standard way. To minimize configurafion, it may 
>>--> be convenient in some implementations to make the standard B1 bridge 
>>--> priority a function of the configurable RBridge priority for IS-IS 
>>--> Designated RBridge election. In this way Designated RBridge will 
>>--> participate and contend (as B1) to be elected also as root bridge of 
>>--> the bridged island and only one priority configuration is required.
>>--> 
>>--> If (in environments using such implementations) the default bridge
>>--> priority for B1 is lower than standard bridge priority, by default
>>--> RBridges/bridges like B1 shown will become roots of their bridged
>>--> islands, contending only with other RBridges connected to same island
>>--> for root election. It is not mandatory for RBridges becombined bridge/
>>--> RBridges.
>>--> 
>>--> - -------
>>--> 
>>
>>--
>>Eric
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>>    
>>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDmKpIE5f5cImnZrsRAs/tAKCRkMxmz15gopFBmeHSJ5xZOfz4owCeMznn
>DIBxUhcFFdtcp5K3KvwZRWU=
>=yueR
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

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



Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB97ON006320 for <[e-mail]>; Thu, 8 Dec 2005 23:24:23 -0800 (PST)
Received: by wproxy.gmail.com with SMTP id 55so1164675wri for <[e-mail]>; Thu, 08 Dec 2005 23:24:23 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=t/dALqdLnxFbb4ZYFyg+YVPv/alZIIQjc4ZDBqTFkPdE4NAl7NIf1enzYKbFJuIIgznM9aTEVx8rfVDAd88FdivAMaM6O6g11tmqMkPChcsug34UA+cVbRve9ORjhKNcgQQf5deKn1bD3aEPyYf3R8nXQpsEaQXobCjU8ZkmxvU=
Received: by 10.64.24.4 with SMTP id 4mr1135qbx; Thu, 08 Dec 2005 23:24:22 -0800 (PST)
Received: by 10.64.24.2 with HTTP; Thu, 8 Dec 2005 23:24:22 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 8 Dec 2005 23:24:22 -0800
From: Alia Atlas <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <[e-mail]>
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 jB97ON006320
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2005 07:25:21 -0000
Status: RO
Content-Length: 1090

On 12/8/05, Gray, Eric <[e-mail]> wrote:
>         Any specific path selection algorithm affects only the
> device making the path selection.  That means it comes under
> the heading of "what I do in my box is my own business."
>
>         What really needs to be said - particularly at a level
> of "architecture" is that devices using multiple paths to
> forward frames MUST use some path selection algorithm that
> will prevent persistent re-ordering of frames within flows.

It may also be worthwhile to point out that a different seed into the
hash function at each
point is important to improve load-balancing at different rbridges
along a path.  Otherwise, there is the risk that, in the trivial case,
only traffic with hash x will reach an rbridge from a particular
interface so that when that rbridge tries to load-balance by using
hash x and y, it only has hash x traffic and no load-balancing occurs.

I think this is important at the "architecture' because, without it,
load-balancing is at risk of working very poorly for sequential
rbridges that have ecmp.

Alia


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB92JQ024249; Thu, 8 Dec 2005 18:19:26 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 08 Dec 2005 18:17:24 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <36bb01c5fb65$75c91bf0$[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2005 02:20:33 -0000
Status: RO
Content-Length: 1207

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



Harald Tveit Alvestrand wrote:
...
>>An alternative would be to allow multipath but limit it for a flow. Here
>>a flow would be for a single source or destination ethernet address
>>('external' address). That would allow for multipath for internal
>>destination addresses (multipath to destination) but retain ordering per
>>'flow' (in this case the internal addresses act as ports).
> 
> when you say "limit it for a flow", do you mean "do not allow persistent 
> reordering within a flow"?

Yes.

> and when you say "flow", do you mean "all packets with the same (external) 
> Source address and the same (extrernal) destination address"?
> If that's what you mean, I think you're trying to say the same thing I am 
> trying to say.... that's progress...

Basically. Could also mean VLAN group; anything that doesn't affect TCP
;-) I.e., what Eric said (trying to be general enough to avoid IPR).

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

iD8DBQFDmOk0E5f5cImnZrsRAtRmAJ4/EIMMZro9jRB280tFTOKi5UgEcACgxuWm
nMNe35R3tXyXuHyR7T7iJEo=
=etDs
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB90j8016132; Thu, 8 Dec 2005 16:45:08 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 08 Dec 2005 16:43:06 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2005 01:00:18 -0000
Status: RO
Content-Length: 2966

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



Gray, Eric wrote:
> Joe,
> 
> 	This would work, as long as you don't use the wording 
> you suggest.

Fine with me.

> 	It is one thing to say "use a technique that will ensure
> that order is preserved within flows" and another to say "use
> a technique that will ensure that order is preserved on a per
> flow basis."
> 
> 	One common technique is to use a simple hash function
> where the number of hash-results is equal to the number of 
> alternatives from which the path selection processor has to
> select.  What goes into the hash function may include the
> fields you mention - though it may also use other inputs and
> other techniques.
> 
> 	Which is by way of a segue into another snag in word
> choices: you don't want to specify an exact algorithm.  Down
> that path we will find IPR pit-falls.  
> 
> 	Any specific path selection algorithm affects only the 
> device making the path selection.  That means it comes under
> the heading of "what I do in my box is my own business."
> 
> 	What really needs to be said - particularly at a level
> of "architecture" is that devices using multiple paths to
> forward frames MUST use some path selection algorithm that 
> will prevent persistent re-ordering of frames within flows.

Agreed.

Anybody else want to agree, and we can close this issue and put the
proposed text in the ISSUES doc? ;-)

Joe

> 
> 	It may be worth-while to point out that some of the 
> available path selection algorithms have built in sanity
> checks that can be reasonably proficient in detecting cases
> in which flow discrimination will not be effective (such as
> in the encrypted case Harald refers to).  
> 
> 	Also, it is worth noting that there is only one place 
> that encryption of the inner Ethernet header may reasonably 
> be expected to occur and that is at the ingress RBridge.  
> Prior to that point, the un-encrypted header was required 
> for forwarding.  As a result, it is certainly possible for
> the ingress RBridge to make a path selection based on the
> un-encrypted inner header information.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [e-mail] 
> --> [mailto:[e-mail]] On Behalf Of Joe Touch
> --> Sent: Thursday, December 08, 2005 12:05 PM
> --> To: Developing a hybrid router/bridge.
> --> Subject: Re: [rbridge] PS issue #4
> --> 
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://www.postel.org/mailman/listinfo/rbridge
> --> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDmNMaE5f5cImnZrsRAsH9AJoCPy6XvCLBsW4vaQ0SlXFa8+yqRQCg8xcw
14i0uxbROimGruVpRjMuBXs=
=tmhg
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8Loxr18196; Thu, 8 Dec 2005 13:50:59 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 08 Dec 2005 13:48:56 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Arch Issue #2 and #3
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 23:51:51 -0000
Status: RO
Content-Length: 4372

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



Gray, Eric wrote:
> --> 
> --> #2 is an rbridge the DR of the edge STPs?
> 
> It may be.  This relates to architectural issue #3 - saee below.
> 
> --> 
> --> #3 do rbridges have proxy bridges at their edges (see Radia's post of
> --> 10/21/2005)?
> --> (see Guillermo's text below)
> 
> Radia explicitly suggested this in order to propose that this is 
> out of scope for the TRILL working group.

My impression was more that this was a way to implement PARTICIPATE...

or actually a variant of BLOCK (see my other message)

> An RBridge may be collocated with any number of bridges.  An RBRidge
> implementation may logically connect such a collocated bridge in-line
> with any of its interfaces.
> 
> In this case, it is possible to build an RBridge implementation that
> participates in STP/RSTP and it is possible to configure the in-line
> bridge in such a way as to guarantee that it will become the root of
> the STP.

Can you force a single bridge to be root of an STP? If so, what happens
when two such bridges are on the same segment? (that seems to be the rub)...

Joe

> 
> This is not required of an RBridge implementation - even if it were
> to turn out to be a common implementation case.  Rather, this is an
> offered example - by way of proof of concept - that we do not need 
> to define this behavior as part of base-line RBridge behavior.
> 
> Speaking of orthogonality, this discussion (below) will be included 
> in the next iteration of TRILL routing requirements, when it is 
> submitted.  Assuming that draft eventually becomes a WG draft, you 
> may want to simply refer to that document in the architecture draft.
> 
> --> - -----
> --> 
> --> Guillermo's text for ARCH #3:
> --> 
> --> RBridge indirect participation in bridged island spanning tree.
> --> - ---------------------------------------------------------------
> --> RBridges by default do not participate in spanning tree in other way
> --> than ignoring received BPDUs. It is an objective of RBridge
> --> specification to be independent of bridges specifications as much as
> --> possible.
> --> 
> --> However it may be convenient for RBridges in some circumstances to
> --> participate in the spanning tree and contend to be root bridge of the
> --> spanning tree formed in the bridged island they are attached to. In
> --> these cases it is possible to build a device that's logically the same
> --> as a bridge glued onto an RBridge. The following schema applies:
> --> 
> -->                         ?-----------?
> -->        bridged island-----B1----RB1 ?
> -->                         ?-----------?
> --> 
> -->                         RBridge/bridge box
> --> 
> --> where B1 is a bridge with two ports...a pt-to-pt link to RBRidge RB1,
> --> and a link to the bridged LAN. The "RB1" portion of this box acts as
> --> an standard RBridge, it neither forwards, nor initiates spanning tree
> --> messages. The "B1" portion acts as two-port standard 802.1D bridge, 
> --> and does participate in spanning tree. Its priority for root election 
> --> can be set in the standard way. To minimize configurafion, it may 
> --> be convenient in some implementations to make the standard B1 bridge 
> --> priority a function of the configurable RBridge priority for IS-IS 
> --> Designated RBridge election. In this way Designated RBridge will 
> --> participate and contend (as B1) to be elected also as root bridge of 
> --> the bridged island and only one priority configuration is required.
> --> 
> --> If (in environments using such implementations) the default bridge
> --> priority for B1 is lower than standard bridge priority, by default
> --> RBridges/bridges like B1 shown will become roots of their bridged
> --> islands, contending only with other RBridges connected to same island
> --> for root election. It is not mandatory for RBridges becombined bridge/
> --> RBridges.
> --> 
> --> - -------
> --> 
> 
> --
> Eric
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDmKpIE5f5cImnZrsRAs/tAKCRkMxmz15gopFBmeHSJ5xZOfz4owCeMznn
DIBxUhcFFdtcp5K3KvwZRWU=
=yueR
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8MIXr00669; Thu, 8 Dec 2005 14:18:33 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 08 Dec 2005 14:16:30 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS Issue #11 -> now ARCH issue #6
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 23:50:43 -0000
Status: RO
Content-Length: 3277

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



Gray, Eric wrote:
> --> 
> --> #11 internal/external, inside/outside terminology
> -->     there is one objection to these terms as topological;
> -->     the draft intends to define them sufficiently
> -->     does this need to be addressed further?
> 
> This is not a Problem Statement Issue because these terms are
> defined in draft-touch-trill-rbridge-arch, rather than in
> draft-touch-trill-prob.  Consequently, this is an issue with
> the Architectural document, if not precisely an architectural
> issue.

Yup - needs to be moved to the other doc. Let's call this ARCH issue #6
then (see header).

> The draft definitions are not sufficiently clear on the current 
> iteration.
> 
> The definitions offered there were - 
> 
> -> o  External (to a campus): describes communication on the non-rbridge 
> ->    components of an Ethernet link subnet, notably not between 
> ->    rbridges or between non-rbridges and rbridges.

The last part is a bug i.e., 'or between non-rbridges and rbridges'. It
should be omitted.

> ->
> -> ... [snip] ...
> -> 
> -> o  Internal (to a campus): describes communication between rbridge 
> ->    devices; this communication may traverse external devices, but is 
> ->    still considered internal. 
>
> Clearer wording was suggested on this list some time ago.

The previous proposal had problems:

> External links/interfaces are those that do not connect to a
> cooperating RBridge; internal links/interfaces are those that
> do. 

what does "connect" mean?
	a) physically connect (probably not)
	b) attached to the same bridged segment (won't work - see below)
	b) communicate directly
		(that's the spirit of what I ended up using)

what is being connected?
	the above lists only one end ('to a cooperating rbridge')

why is 'cooperating' required?

Consider the following (all rbridge and bridges shown; hosts connect to
all devices):

               r1----r2------b1
               |     |       |
               |     |       |
               r3----r4------b2


is r2-b1 internal or external?

I would think it is external, since the HELLO would prevent a tunnel
being created on r2-b1-b2-r4

However, this definition makes them internal.

In particular, this definition makes all links/interfaces internal if
they connect to an 'external' bridged segment that reconnects to the
rbridge elsewhere.

> Whether or not non-Bridge devices exist on - or are part 
> of - a link between cooperating RBridges is irrelevant.  The
> existing attempt to somehow include the possibility of other
> devices as part of a link between RBridges in the definition
> of internal and external is only confusing.
> 
> I believe that the confusion stems from an attempt to allow
> for required communications between RBridges and other types
> of devices.  This confusion is one strong indication of why
> no such communications should be required.

Rbridges need to talk to bridges at some point; otherwise there's no
ingress or egress ;-)

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

iD8DBQFDmLC+E5f5cImnZrsRAlXZAKCJZsBCaNsffdCBZThm+9Ca6WLxPwCfbdXV
5KCUBeCNg2oelTukVeU1mMA=
=PF20
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8NBEr23901; Thu, 8 Dec 2005 15:11:14 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 08 Dec 2005 15:09:11 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.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]
Subject: Re: [rbridge] PS Issue #2
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 23:47:43 -0000
Status: RO
Content-Length: 1076

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



Guillermo Ib??ez wrote:
> 
> Gray, Eric wrote:
> 
> 
>>--> 
>>--> #2 should the solution apply to current ethernet scales or not?
>>--> 	and if so, what are current ethernet scales?
>>--> 	Harald proposed as a starting point:
>>--> 	* 1000 end-hosts in a single bridged LAN of 100 bridges
>>--> 	* [100,000] end-hosts inside 1000 VLANs served by [10,000] bridges
>>
>>Yes, at least.
>> 
>>
> 
> 100.000 end-hosts seems a reasonable target per campus. Bigger 
> aggregations seem to exceed campus environment, they are more "provider" 
> environments. Some routers are assumed at the campus border that will 
> break the campus.
> The 10.000 bridges are a total of bridges and Rbridges? How many  
> Rbridges maximum,  10.000?

O(rbridges) ought to be O(bridges), IMO.

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

iD8DBQFDmL0XE5f5cImnZrsRAm2IAJsHrykyLyfm/jB9xxuP/LyXEQqQsACggj/K
rlnBnpvsQ6me1v96N4I8ujI=
=p3SM
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8LgGr14193; Thu, 8 Dec 2005 13:42:16 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 08 Dec 2005 13:40:14 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Arch Issue #1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 23:28:43 -0000
Status: RO
Content-Length: 1612

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



Gray, Eric wrote:
> --> 
> --> #1 resolve recommendations for the three modes of BSTP messages:
> -->    (is this part of the PS or ARCH?)
> --> 	participate
> --> 	forward
> --> 	block
> 
> Block by default.  Optional configuration for forwarding and/or
> participating MAY be allowed but SHOULD be considered sub-optimal.

Forward maps to what hubs do.

Participate maps to what bridges do.

As a result, either of those can easily be considered as default cases,
though forward is clearly suboptimal.

As to block:

1. it seems clear that it works only under a certain set of assumptions
about ALL other L2 devices:

	a) ALL other L2 devices MUST pass rbridge's HELLO messages

	b) ALL other L2 devices MUST NOT also BLOCK

Neither rule can be assumed about an rbridge; by symmetry, why can we
assume them about all past and future L2 devices?

2. BLOCK + HELLO is basically just a variant of an STP where the rbridge
is in a privileged position of 'ultimate root' (which is why it works
when the two assumptions above are valid).

We can already assume that STP (or MSTP) works where STP (/MSTP) is
supported; why not just PARTICIPATE in STP at that point?

The HELLOs are just equivalent to BPDUs that discover which edge ports
are connected on the outside anyway. Why not just BPDUs at that point?

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

iD8DBQFDmKg+E5f5cImnZrsRAku1AKCNmYMTRjr1gRToob+Uh6LV443DcgCffQ1Q
0DAGlCFmevHRYsQ6yyHgHeY=
=4ck0
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8Lqir19107; Thu, 8 Dec 2005 13:52:45 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 08 Dec 2005 13:50:42 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #7
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 23:27:57 -0000
Status: RO
Content-Length: 1290

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



Gray, Eric wrote:
> Joe,
> 
> 	I am still not sure why the document needs to differentiate 
> moving hosts from moving bridges.  The distinction is quite obvious,
> isn't it?

The two affect rbridges differently - one affects the tables at the
edge, the other affects the edge STPs. Both affect routing.

Both seem to require discussion w.r.t. rbridge flux under edge flux.

Joe

> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [e-mail] 
> --> [mailto:[e-mail]] On Behalf Of Joe Touch
> --> Sent: Wednesday, December 07, 2005 3:08 PM
> --> To: Developing a hybrid router/bridge.
> --> Subject: Re: [rbridge] PS issue #7
> --> 
> --> _______________________________________________
> --> rbridge mailing list
> --> [e-mail]
> --> http://www.postel.org/mailman/listinfo/rbridge
> --> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDmKqyE5f5cImnZrsRAsL/AJ9PpshokdmcTN08JFg0ewGJshirAgCg0BZA
3JO+7lGXKDwLrWg8bHZzKOs=
=5Aq5
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8LhGr14627; Thu, 8 Dec 2005 13:43:16 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 08 Dec 2005 13:41:13 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Arch Issue #5
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 23:24:20 -0000
Status: RO
Content-Length: 758

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



Gray, Eric wrote:
> --> 
> --> #5 change 'external protocols' section to 'interaction with 802.1D'
> --> 
> 
> Yes.  However, if you are going to include a section for interactions
> with 802.1D, does that mean I should omit the samesection in the routing
> requirements draft?

Architecture interactions with 802.1D aren't the same as routing
interactions with 802.1D - at least I'm presuming they're not. If they
are, then yes. If not, then no...

Joe

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

iD8DBQFDmKh5E5f5cImnZrsRAhjLAKC7Ab23YnKAGnfdQ3zt7E3/eF2rugCdFzot
wRvZge0xYEVURpd/dH7rGC4=
=1KDv
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8MTlr05762 for <[e-mail]>; Thu, 8 Dec 2005 14:29:47 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8MTedJ023195 for <[e-mail]>; Thu, 8 Dec 2005 17:29:41 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA10282 for <[e-mail]>; Thu, 8 Dec 2005 17:29:40 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLG6JB>; Thu, 8 Dec 2005 17:29:40 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 17:29:39 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 23:18:49 -0000
Status: RO
Content-Length: 5113

Joe,

	This would work, as long as you don't use the wording 
you suggest.

	It is one thing to say "use a technique that will ensure
that order is preserved within flows" and another to say "use
a technique that will ensure that order is preserved on a per
flow basis."

	One common technique is to use a simple hash function
where the number of hash-results is equal to the number of 
alternatives from which the path selection processor has to
select.  What goes into the hash function may include the
fields you mention - though it may also use other inputs and
other techniques.

	Which is by way of a segue into another snag in word
choices: you don't want to specify an exact algorithm.  Down
that path we will find IPR pit-falls.  

	Any specific path selection algorithm affects only the 
device making the path selection.  That means it comes under
the heading of "what I do in my box is my own business."

	What really needs to be said - particularly at a level
of "architecture" is that devices using multiple paths to
forward frames MUST use some path selection algorithm that 
will prevent persistent re-ordering of frames within flows.

	It may be worth-while to point out that some of the 
available path selection algorithms have built in sanity
checks that can be reasonably proficient in detecting cases
in which flow discrimination will not be effective (such as
in the encrypted case Harald refers to).  

	Also, it is worth noting that there is only one place 
that encryption of the inner Ethernet header may reasonably 
be expected to occur and that is at the ingress RBridge.  
Prior to that point, the un-encrypted header was required 
for forwarding.  As a result, it is certainly possible for
the ingress RBridge to make a path selection based on the
un-encrypted inner header information.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Joe Touch
--> Sent: Thursday, December 08, 2005 12:05 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS issue #4
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Harald Tveit Alvestrand wrote:
--> > 
--> > --On onsdag, desember 07, 2005 12:45:19 -0800 Joe Touch 
--> <[e-mail]> 
--> > wrote:
--> > 
--> > 
--> >>>>The latter affects whether multipath forwarding is supported inside
the
--> >>>>rbridge and whether it also requires reordering facilities at the
egress.
--> >>>
--> >>>multipath between a single source/destination pair may be troublesome
--> >>>enough that we should not attempt it.....
--> >>
--> >>Isn't that one of the opportunities we wanted to support, though?
--> >>
--> >>It's already supported by the Internet protocols we're considering
--> >>(e.g., IS-IS - see RFC2991). As per below, do we want to prohibit it
--> >>outright, or assert that IF equal-cost multipath is used then
reordering
--> >>mitigation (and perhaps latency smoothing) needs to occur?
--> > 
--> > 
--> > from RFC 2991:
--> > 
--> >    All of the problems outlined in the previous section arise when
--> >    packets in the same unicast or multicast "flow" are split among
--> >    multiple paths.  The natural solution is therefore to ensure that
--> >    packets for the same flow always use the same path.
--> > 
--> > I think it makes sense to say:
--> > 
--> > - we don't require that multipath for one source-destination pair be 
--> > supported
--> > - IF multipath for one source-destination pair is available, and can 
--> > cause persistent reordering, we need reordering mitigation in order 
--> > to be consistent with the Ethernet service model
--> > 
--> > I'm troubled by the implicit layer violation in the multipath
algorithm 
--> > trying to detect "flows" at a higher level such as TCP sessions.
--> > (for extra complexity, add IPSec or encryption at Ethernet layer....
both 
--> > would make most flow-detection algorithms go haywire....)
--> > 
--> >                    Harald
--> 
--> This is an easy position to adopt, but I'm wondering whether anyone
--> considers the result overly restrictive - esp. where addressing the
--> limitations of STPs (even MSTP) using Internet-style routing is the
--> issue (where Internet routing is still embracing multipath).
--> 
--> An alternative would be to allow multipath but limit it for a flow. 
--> Here a flow would be for a single source or destination ethernet 
--> address ('external' address). That would allow for multipath for 
--> internal destination addresses (multipath to destination) but retain 
--> ordering per 'flow' (in this case the internal addresses act as ports).
--> 
--> Joe
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDmGeeE5f5cImnZrsRAsClAJ4krvsFpljd4/kF2+GtvLvJ51Th+ACdGkDb
--> J2cAghjITlOjYdkBBFm2/OI=
--> =8F9a
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8M4Yr24386 for <[e-mail]>; Thu, 8 Dec 2005 14:04:35 -0800 (PST)
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 483F42596FC for <[e-mail]>; Thu,  8 Dec 2005 23:03:53 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21510-07 for <[e-mail]>; Thu,  8 Dec 2005 23:03:49 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 06E082596FF for <[e-mail]>; Thu,  8 Dec 2005 23:03:49 +0100 (CET)
Date: Thu, 08 Dec 2005 23:06:57 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <36bb01c5fb65$75c91bf0$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 22:27:10 -0000
Status: RO
Content-Length: 1546

--On torsdag, desember 08, 2005 09:04:30 -0800 Joe Touch <[e-mail]> 
wrote:

>> I'm troubled by the implicit layer violation in the multipath algorithm
>> trying to detect "flows" at a higher level such as TCP sessions.
>> (for extra complexity, add IPSec or encryption at Ethernet layer....
>> both  would make most flow-detection algorithms go haywire....)
>>
>>                    Harald
>
> This is an easy position to adopt, but I'm wondering whether anyone
> considers the result overly restrictive - esp. where addressing the
> limitations of STPs (even MSTP) using Internet-style routing is the
> issue (where Internet routing is still embracing multipath).

I considered 2991 to be saying "it's wise to be somewhat restrictive"... 
and think that our specs should say "we SHOULD be restrictive", or perhaps 
even "we MUST"...

> An alternative would be to allow multipath but limit it for a flow. Here
> a flow would be for a single source or destination ethernet address
> ('external' address). That would allow for multipath for internal
> destination addresses (multipath to destination) but retain ordering per
> 'flow' (in this case the internal addresses act as ports).

when you say "limit it for a flow", do you mean "do not allow persistent 
reordering within a flow"?
and when you say "flow", do you mean "all packets with the same (external) 
Source address and the same (extrernal) destination address"?
If that's what you mean, I think you're trying to say the same thing I am 
trying to say.... that's progress...




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 jB8Ka7r14647 for <[e-mail]>; Thu, 8 Dec 2005 12:36:08 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8187E9E33E for <[e-mail]>; Thu,  8 Dec 2005 21:36:01 +0100 (CET)
Received: from [163.117.203.228] (unknown [163.117.203.228]) by smtp01.uc3m.es (Postfix) with ESMTP id 9BB529E330 for <[e-mail]>; Thu,  8 Dec 2005 21:36:00 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 08 Dec 2005 21:36:00 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS Issue #3
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 21:02:18 -0000
Status: RO
Content-Length: 1926

Gray, Eric wrote:

>--> 
>--> #3 IF size is an issue...
>--> 	what limits the size? STP/RSTP or broadcast traffic, or both?
>
>Not sure what we mean by "size" here and how this differs from
>"scale."
>
>Obviously, an RBridge campus is limited to the size of workable
>STP/RSTP solutions only in the fully-meshed connectivity case.
>The complete solution may be several times as large given that
>STP/RSTP domains exterior to the campus are made smaller.  In
>addition, some proposed campus topologies will allow for smaller
>STP/RSTP domains even within the RBridge campus. 
>  
>
The concept of a core formed by only  Rbridges, each ingress Rbridge 
being the root (or annex to root bridge) of an RSTP/STP  of standard 
bridges provides network predictability and scalability, besides getting 
rid of the need to modify the frame at each Rbridge hop with the next 
hop Rbridge address.
Guillermo

>Employing multicast routing techniques against L2 multicast, may
>allow for a larger broadcast domain as well.  This is especially
>true given flooding within RBridge campi will be significantly
>less than in a typical 802.1 LAN.
>
>However, the size of the broadcast domain including exterior LAN
>segments will ultimately determine the maximum "size" (at least
>size measured as numbers of contiguous LAN segments).
>  
>
ARP traffic estimations should be done with and without ARP proxies to 
evaluate both the bandwidth (less critical, given
its abundance :1 Gb, 10 Gb Ethernet )  and, most important, the ARP 
processing effort at endnodes  (all network endnodes must process a 
cach? miss ARP).
Guillermo

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

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



Received: from [206.117.31.208] (guest-208.isi.edu [206.117.31.208] (may be forged)) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8JxCr28283; Thu, 8 Dec 2005 11:59:12 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 08 Dec 2005 11:59:12 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA5FC0438695E12A980172BD3"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS Issue #9
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 20:59:24 -0000
Status: RO
Content-Length: 1718

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



Gray, Eric wrote:
> -->=20
> --> #9 which addresses are not forwarded? (related to ARCH #1)
> -->=20
> --> Bridge Group Address 01-80-C2-00-00-00 , used for frames=20
> --> transporting BPDUs
> -->
> --> Pause Frame address 01-80-C2-00-00-01.
> -->
> --> Besides I am not sure but addresses 01-80-C2-00-00-00 to=20
> --> 01-80-C2-00-00-0F
>=20
> This (last statement) appears to be incomplete.  What exactly
> is the issue associated with this last statement?

"may fall into the same category"

> In general, 802.1 bridges on one side of an RBridge should be
> transparent from a bridging protocol perspective.  They may
> communicate with each other via individual MAC or IP addresses
> but bridge control frames should be blocked.
>=20
> This is necessary in order to realize advantages associated=20
> with partitioning bridge control-domains...
>=20
> --
> Eric
>=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


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

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

iD8DBQFDmJCQE5f5cImnZrsRAg13AJ9cVDs2NmA7JPHDsxDd006O/zgxxACeMdWE
ImDHbk/KEVqI4k2YcIkdUV8=
=9GBA
-----END PGP SIGNATURE-----

--------------enigA5FC0438695E12A980172BD3--


Received: from [206.117.31.208] (guest-208.isi.edu [206.117.31.208] (may be forged)) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8JwYr27853; Thu, 8 Dec 2005 11:58:34 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 08 Dec 2005 11:58:33 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7CAA5FEEEDE15D4C072CED8D"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS Issue #7
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 20:59:17 -0000
Status: RO
Content-Length: 1607

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

As clarification, "ISSUE" means open item to be discussed. Some are
debatable concepts; some are issues that need clarification; some (like
this) are just issues that I need to get around to adding to the text.

Those latter issues would benefit from some help, though.

Joe

Gray, Eric wrote:
> -->=20
> --> #7 differentiate between host reattachment effects
> -->    and bridge reattachment effects; the latter impact the STP more
>=20
> Yes, but what exactly is the issue?
>=20
> Two statements can be made relative to this:
> 1) host re-attachment impacts learning/reachability-advertisement more.=

> 2) bridge re-attachment impacts STP/RSTP more.
>=20
> I believe these two statements to be factual observations, rather than
> issues.
>=20
> --
> Eric
>=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


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

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

iD8DBQFDmJBpE5f5cImnZrsRAgcqAKDi9Mzj67EBHTAKEMU3GSwLj47NOwCfYKoV
xOpvg+Qxlkae0pXFm8BMeL4=
=PfR2
-----END PGP SIGNATURE-----

--------------enig7CAA5FEEEDE15D4C072CED8D--


Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8KVqr12520 for <[e-mail]>; Thu, 8 Dec 2005 12:31:54 -0800 (PST)
Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165]) by comcast.net (rwcrmhc13) with SMTP id <200512082031440150052imle>; Thu, 8 Dec 2005 20:31:44 +0000
Message-ID: <3b7401c5fc36$4b50fec0$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
Date: Thu, 8 Dec 2005 14:30:56 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 20:46:27 -0000
Status: RO
Content-Length: 1120

> --> #1 which version of ethernet is the baseline?
> --> STP, RSTP, VLAN, provider bridges, wireless,
> --> shortest path bridging, etc.
> --> (this will help us determine what terminology to use)
>
> IMO, STP/RST, and VLAN.  Wireless is a possibility to the extent
> that it is directly compatible with 802.1 (STP/RSTP) and VLAN.
>
> I am not sure what you mean by provider bridges, but assuming
> it is like a WAN bridging service, this SHOULD be transparent
> to RBridges and may be included.

I meant 802.1ad - Provider Bridges, which has gotten as far as sponsor 
ballot. It's not unreasonable to wonder about 802.1ah - Provider Backbone 
Bridges, but that's not nearly as far down the specification process.

> Since Shortest Path Bridging appears to target a similar problem
> space, I don't think it makes sense for us to try to compete with
> that as a solution.  However, we will need to establish that we
> are not "breaking" it either...

Agree - my point here was more like "this only exists as a tutorial 
presentation so far, we'll need to come back to it when we are closer to 
publishing".

Spencer 



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 jB8KHAr05873 for <[e-mail]>; Thu, 8 Dec 2005 12:17:11 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1B0DF9E2D8 for <[e-mail]>; Thu,  8 Dec 2005 21:17:04 +0100 (CET)
Received: from [163.117.203.228] (unknown [163.117.203.228]) by smtp01.uc3m.es (Postfix) with ESMTP id 4C4A09E2AA for <[e-mail]>; Thu,  8 Dec 2005 21:17:03 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 08 Dec 2005 21:17:03 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS Issue #2
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 20:17:27 -0000
Status: RO
Content-Length: 982

Gray, Eric wrote:

>--> 
>--> #2 should the solution apply to current ethernet scales or not?
>--> 	and if so, what are current ethernet scales?
>--> 	Harald proposed as a starting point:
>--> 	* 1000 end-hosts in a single bridged LAN of 100 bridges
>--> 	* [100,000] end-hosts inside 1000 VLANs served by [10,000] bridges
>
>Yes, at least.
>  
>
100.000 end-hosts seems a reasonable target per campus. Bigger 
aggregations seem to exceed campus environment, they are more "provider" 
environments. Some routers are assumed at the campus border that will 
break the campus.
The 10.000 bridges are a total of bridges and Rbridges? How many  
Rbridges maximum,  10.000?
Guillermo

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

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



Received: from 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 jB8JRIr14068 for <[e-mail]>; Thu, 8 Dec 2005 11:27:22 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8JR4dJ019344 for <[e-mail]>; Thu, 8 Dec 2005 14:27:08 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA17624 for <[e-mail]>; Thu, 8 Dec 2005 14:27:04 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLG48B>; Thu, 8 Dec 2005 14:27:04 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 14:27:03 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #11
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 20:04:19 -0000
Status: RO
Content-Length: 3220

Spencer/Joe,

	This E-Mail is rich with stuff I think needs clarification.

	The statement that all bridges are "outside" is part of the
confusion generating definition of "external" included in the TRILL
architecture draft.  Joe has indicated that he needs to change his
referencs to "external protocol interactions" to "interactions with
802.1D bridges".  In general, we need to move away from thinking of
interactions as "internal" or "external" based on who you're talking
to rather than where they are.

	There is more to the notion of "inside" (can we use consistent
terminology?) - or "internal" than the fact that traffic is tunneled
between RBridges.  There is also the fact that RBridges discover one
another over internal links, that IS-IS is used to determine routing
over internal paths and that - because the traffic is tunneled within
an RBridge campus - the traffic arriving at any ingress may take more 
than one path to arrive at a given egress, as long as appropriate 
steps are taken to ensure that frame ordering for individual frame 
streams is usually preserved.

	Also, unless things have changed in how bridges typically handle
STP, the opportunity for race conditions is very small.  Forwarding
between RBridges will not occur until STP has been resolved among any
bridges involved in the connecting links.  Bridges usually (I can't 
recall if it is a requirement) do not forward while resolving STP.  I
am fairly sure that this is also true for RSTP.

	There will be SPF recalculations, however, if the RBrdiges do
not employ a hold-down timer sufficient to allow for all links to
become available.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Spencer Dawkins
--> Sent: Wednesday, December 07, 2005 4:23 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS issue #11
--> 
--> Hi, Joe,
--> 
--> Thanks for your help as I catch up ...
--> 
--> >> In the following picture, are the (inside?) bridges in the middle of
the
--> >> rbridge campus part of the same (outside?) spanning tree, or does
what
--> >> happens inside the campus show up outside the campus?
--> >
--> > The same issue applies - all bridges are 'outside'. It's only traffic
--> > that's considered to be inside or outside. This is because the traffic
--> > between rbridge nodes is tunneled, and it is the tunnel that is
--> > 'inside'. As a result, bridges may transit tunneled traffic, but they
--> > never appear as bridges inside the tunnel, and so are never 'inside'
the
--> > rbridge.
--> 
--> I'm wondering if we have the potential for race conditions as bridges 
--> between rbridges recompute a spanning tree while rbridges are
distributing 
--> link state updates, but at worst, I'm thinking this might involve one
extra 
--> path change during routing changes - not oscillating. Maybe this is
worth 
--> revisiting when we're more solid on the protocol description, but it's 
--> probably premature now.
--> 
--> Again, thanks!
--> 
--> Spencer 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8JZ2r17628 for <[e-mail]>; Thu, 8 Dec 2005 11:35:02 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8JYtdJ019490 for <[e-mail]>; Thu, 8 Dec 2005 14:34:56 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA18869 for <[e-mail]>; Thu, 8 Dec 2005 14:34:55 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLGVG6>; Thu, 8 Dec 2005 14:34:55 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 14:34:55 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 20:01:45 -0000
Status: RO
Content-Length: 2539

Harald,

	I agree with your concerns about layer violations - particularly
to the IP/TCP level.  However, if a source destination pair is defined
by RBridge ingress/egress MAC addresses, then it may be very reasonable
to allow use of any VLAN id as a "flow distinguisher".

--
Eric 

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Harald 
--> Tveit Alvestrand
--> Sent: Thursday, December 08, 2005 1:45 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS issue #4
--> 
--> 
--> 
--> --On onsdag, desember 07, 2005 12:45:19 -0800 Joe Touch 
--> <[e-mail]> 
--> wrote:
--> 
--> >>> The latter affects whether multipath forwarding is 
--> supported inside the
--> >>> rbridge and whether it also requires reordering 
--> facilities at the
--> >>> egress.
--> >>
--> >> multipath between a single source/destination pair may 
--> be troublesome
--> >> enough that we should not attempt it.....
--> >
--> > Isn't that one of the opportunities we wanted to support, though?
--> >
--> > It's already supported by the Internet protocols we're considering
--> > (e.g., IS-IS - see RFC2991). As per below, do we want to 
--> prohibit it
--> > outright, or assert that IF equal-cost multipath is used 
--> then reordering
--> > mitigation (and perhaps latency smoothing) needs to occur?
--> 
--> from RFC 2991:
--> 
-->    All of the problems outlined in the previous section arise when
-->    packets in the same unicast or multicast "flow" are split among
-->    multiple paths.  The natural solution is therefore to ensure that
-->    packets for the same flow always use the same path.
--> 
--> I think it makes sense to say:
--> 
--> - we don't require that multipath for one 
--> source-destination pair be 
--> supported
--> - IF multipath for one source-destination pair is 
--> available, and can cause 
--> persistent reordering, we need reordering mitigation in order to be 
--> consistent with the Ethernet service model
--> 
--> I'm troubled by the implicit layer violation in the 
--> multipath algorithm 
--> trying to detect "flows" at a higher level such as TCP sessions.
--> (for extra complexity, add IPSec or encryption at Ethernet 
--> layer.... both 
--> would make most flow-detection algorithms go haywire....)
--> 
-->                    Harald
--> 
--> 
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8Jour24619 for <[e-mail]>; Thu, 8 Dec 2005 11:50:57 -0800 (PST)
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E5A0C259737 for <[e-mail]>; Thu,  8 Dec 2005 20:50:14 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17632-02 for <[e-mail]>; Thu,  8 Dec 2005 20:50:11 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id B987B259735 for <[e-mail]>; Thu,  8 Dec 2005 20:50:11 +0100 (CET)
Date: Thu, 08 Dec 2005 20:53:20 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail] s.marconi.com>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 19:51:26 -0000
Status: RO
Content-Length: 338

--On torsdag, desember 08, 2005 12:07:24 -0500 "Gray, Eric" 
<[e-mail]> wrote:

> I am not sure what you mean by provider bridges, but assuming
> it is like a WAN bridging service, this SHOULD be transparent
> to RBridges and may be included.

This is 802.1ad (just about finished) and 802.1ah (in progress). Stay away.





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 jB8J2fr01842 for <[e-mail]>; Thu, 8 Dec 2005 11:02:42 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id DA4CC9DF8F for <[e-mail]>; Thu,  8 Dec 2005 20:02:07 +0100 (CET)
Received: from [163.117.203.228] (unknown [163.117.203.228]) by smtp01.uc3m.es (Postfix) with ESMTP id EB2C19DF2F for <[e-mail]>; Thu,  8 Dec 2005 20:02:06 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 08 Dec 2005 20:02:04 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <367d01c5fb61$0e1b8050$[e-mail]>
In-Reply-To: <367d01c5fb61$0e1b8050$[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 19:32:41 -0000
Status: RO
Content-Length: 2335

This document details  more on Shortest Path Bridging than documents 
mentioned.
http://www.ieee802.org/1/files/public/docs2005/new-seaman-shortest-path-0305-02.pdf
Regards
Guillermo

Spencer Dawkins wrote:

>Strongly agree that we need an answer to
>
>#1 which version of ethernet is the baseline?
>   STP, RSTP, VLAN, provider bridges, wireless,
>   shortest path bridging, etc.
>   (this will help us determine what terminology to use)
>
>and suggest that the answer is "at least RSTP/IEEE 802.1D-2004" (to avoid 
>spending a lot of energy comparing Rbridge to RSTP late in the game, when 
>someone notices that comparing to traditional STP isn't useful).
>
>I am not aware of any text describing shortest path bridging in IEEE 802.1, 
>much less an approved specification. There are no documents listed at 
>http://www.ieee802.org/1/pages/802.1aq.html. The closest I can come to a 
>reference is for a tutorial given by Norm Finn this past summer (at 
>http://grouper.ieee.org/groups/802/802_tutorials/july05/nfinn-shortest-path-bridging.pdf) 
>(and, by the way, Mick Seaman's tutorial from the same session, at 
>http://grouper.ieee.org/groups/802/802_tutorials/july05/tutorial-seaman-bridging-technology-0507-01.pdf, 
>is also helpful background). So I don't think we can use "shortest path 
>bridging" as a baseline now.
>
>I don't see that wireless (IEEE 802.11/16/etc) is going to have an effect on 
>bridging behavior (these are PHY/MAC specifications, right?) - except that 
>an Rbridge could announce that it now knows a new MAC address based on 
>wireless registration, instead of waiting for traffic and learning from 
>source addresses.
>
>I don't see that provider/provider backbone bridges, etc. 
>(http://www.ieee802.org/1/pages/802.1ad.html, 
>http://www.ieee802.org/1/pages/802.1ah.html) are immediately relevant, 
>except that if Rbridges "snoop" other protocols, they need to be able to 
>decapsulate down to the protocols they are snooping.
>
>If I misunderstood, please correct me, of course :-)
>
>Spencer 
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

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



Received: from 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 jB8J7Wr04503 for <[e-mail]>; Thu, 8 Dec 2005 11:07:36 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8J7PdJ018612 for <[e-mail]>; Thu, 8 Dec 2005 14:07:26 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14496 for <[e-mail]>; Thu, 8 Dec 2005 14:07:25 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLG4CA>; Thu, 8 Dec 2005 14:07:24 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 14:07:24 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #7
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 19:30:25 -0000
Status: RO
Content-Length: 2032

Joe,

	I am still not sure why the document needs to differentiate 
moving hosts from moving bridges.  The distinction is quite obvious,
isn't it?

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Joe Touch
--> Sent: Wednesday, December 07, 2005 3:08 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS issue #7
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Spencer Dawkins wrote:
--> > I'm coming up with a big "huh?" on this one...
--> > 
--> > #7 differentiate between host reattachment effects
--> >    and bridge reattachment effects; the latter impact the STP more
--> > 
--> > Host attachment doesn't impact STP at all, does it? I thought that was
the 
--> > whole point of aging filtering table entries (since STP doesn't
actually 
--> > know that my laptop has moved, so bridges that were properly filtering
my 
--> > packets out until I moved are continuing to filter them out after I
moved, 
--> > and I'm waiting for bridges to either learn where I am now from
packets that 
--> > I'm now transmitting or forget where I used to be (if I'm not
transmitting 
--> > any traffic).
--> > 
--> > Please correct me if I'm misunderstanding this...
--> 
--> Bridge reattachment affects STP, but host reattachment affects the
--> caches at the edge. They affect different aspects of the stability of
--> forwarding overall. (I can update the issue item to reflect this - the
--> document does not yet differentiate these issues though).
--> 
--> Joe
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDl0ERE5f5cImnZrsRAqIiAJ9X4NqMD7h/cFL5iVYASbHByRFl/wCggM9x
--> oefVKloP/e7hRPvCtw47z7s=
--> =7dVH
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8IsMr28051 for <[e-mail]>; Thu, 8 Dec 2005 10:54:23 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8IsGdJ018232 for <[e-mail]>; Thu, 8 Dec 2005 13:54:16 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA12795 for <[e-mail]>; Thu, 8 Dec 2005 13:54:15 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLGTRV>; Thu, 8 Dec 2005 13:54:15 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 13:54:15 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id jB8IsMr28051
Subject: [rbridge] Arch Issue #2 and #3
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 19:19:24 -0000
Status: RO
Content-Length: 3469

--> 
--> #2 is an rbridge the DR of the edge STPs?

It may be.  This relates to architectural issue #3 - saee below.

--> 
--> #3 do rbridges have proxy bridges at their edges (see Radia's post of
--> 10/21/2005)?
--> (see Guillermo's text below)

Radia explicitly suggested this in order to propose that this is 
out of scope for the TRILL working group.

An RBridge may be collocated with any number of bridges.  An RBRidge
implementation may logically connect such a collocated bridge in-line
with any of its interfaces.

In this case, it is possible to build an RBridge implementation that
participates in STP/RSTP and it is possible to configure the in-line
bridge in such a way as to guarantee that it will become the root of
the STP.

This is not required of an RBridge implementation - even if it were
to turn out to be a common implementation case.  Rather, this is an
offered example - by way of proof of concept - that we do not need 
to define this behavior as part of base-line RBridge behavior.

Speaking of orthogonality, this discussion (below) will be included 
in the next iteration of TRILL routing requirements, when it is 
submitted.  Assuming that draft eventually becomes a WG draft, you 
may want to simply refer to that document in the architecture draft.

--> - -----
--> 
--> Guillermo's text for ARCH #3:
--> 
--> RBridge indirect participation in bridged island spanning tree.
--> - ---------------------------------------------------------------
--> RBridges by default do not participate in spanning tree in other way
--> than ignoring received BPDUs. It is an objective of RBridge
--> specification to be independent of bridges specifications as much as
--> possible.
--> 
--> However it may be convenient for RBridges in some circumstances to
--> participate in the spanning tree and contend to be root bridge of the
--> spanning tree formed in the bridged island they are attached to. In
--> these cases it is possible to build a device that's logically the same
--> as a bridge glued onto an RBridge. The following schema applies:
--> 
-->                         ?-----------?
-->        bridged island-----B1----RB1 ?
-->                         ?-----------?
--> 
-->                         RBridge/bridge box
--> 
--> where B1 is a bridge with two ports...a pt-to-pt link to RBRidge RB1,
--> and a link to the bridged LAN. The "RB1" portion of this box acts as
--> an standard RBridge, it neither forwards, nor initiates spanning tree
--> messages. The "B1" portion acts as two-port standard 802.1D bridge, 
--> and does participate in spanning tree. Its priority for root election 
--> can be set in the standard way. To minimize configurafion, it may 
--> be convenient in some implementations to make the standard B1 bridge 
--> priority a function of the configurable RBridge priority for IS-IS 
--> Designated RBridge election. In this way Designated RBridge will 
--> participate and contend (as B1) to be elected also as root bridge of 
--> the bridged island and only one priority configuration is required.
--> 
--> If (in environments using such implementations) the default bridge
--> priority for B1 is lower than standard bridge priority, by default
--> RBridges/bridges like B1 shown will become roots of their bridged
--> islands, contending only with other RBridges connected to same island
--> for root election. It is not mandatory for RBridges becombined bridge/
--> RBridges.
--> 
--> - -------
--> 

--
Eric


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 jB8J3mr02319 for <[e-mail]>; Thu, 8 Dec 2005 11:03:48 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8J3cdJ018514 for <[e-mail]>; Thu, 8 Dec 2005 14:03:38 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14076 for <[e-mail]>; Thu, 8 Dec 2005 14:03:38 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLGT84>; Thu, 8 Dec 2005 14:03:37 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 14:03:37 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #2
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 19:13:22 -0000
Status: RO
Content-Length: 1391

Spencer,

	I agree.

--
Eric 

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Spencer Dawkins
--> Sent: Wednesday, December 07, 2005 2:18 PM
--> To: TRILL/RBRIDGE WG
--> Subject: [rbridge] PS issue #2
--> 
--> #2 should the solution apply to current ethernet scales or not?
-->    and if so, what are current ethernet scales?
-->    Harald proposed as a starting point:
-->    * 1000 end-hosts in a single bridged LAN of 100 bridges
-->    * 100.000 end-hosts inside 1000 VLANs served by 10.000 bridges
--> 
--> FWIW, I was reviewing a proposed customer deployment 
--> yesterday that included 
--> 5000 end-hosts in a single bridged LAN of 120 bridges...
--> 
--> A quick look at the IEEE tutorial archives turned up 
--> "Deploying the world's 
--> largest IEEE 802.11b campus", at 
--> http://www.ieee802.org/802_tutorials/nov03/www.wireless.ubc.
--> ca-IEEE-Nov2003.ppt, 
--> with 5000 end-hosts and 1200 APs/200 distribution switches 
--> (I assume 
--> "distribution switches" == "bridges", in this context).
--> 
--> I'd like our definition of "current ethernet scales" to 
--> accommodate these, I 
--> think...
--> 
--> Thanks,
--> 
--> Spencer 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8J2fr01848 for <[e-mail]>; Thu, 8 Dec 2005 11:02:42 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8J2ZdJ018471 for <[e-mail]>; Thu, 8 Dec 2005 14:02:35 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13856 for <[e-mail]>; Thu, 8 Dec 2005 14:02:35 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLGT6S>; Thu, 8 Dec 2005 14:02:34 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 14:02:34 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Arch Issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 19:09:57 -0000
Status: RO
Content-Length: 761

--> 
--> #4 Giullermo's subcase?
-->    address interior packets to egress rather than next-hop
-->    (isn't egress also in there, in the inner shim header?)

I think we should reject this proposal as irelevant to base-line
RBridge functionality.  This is a proposed optimization, and it
should be compatible with existing proposals for RBridge base-
line functionality - however it is not necessary to either do 
this optimization in any RBridge implementation or adopt the
compexity associated with it at this stage.

I think it is reasonable for Guillermo to submit a new draft
detailing how this would work as an additional option - similar
to the proposal to take advantage of multicast routing.

It does not need to be part of the architecture.

--
Eric


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 jB8Iuir29063 for <[e-mail]>; Thu, 8 Dec 2005 10:56:49 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8IucdJ018292 for <[e-mail]>; Thu, 8 Dec 2005 13:56:38 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA13054 for <[e-mail]>; Thu, 8 Dec 2005 13:56:37 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLGTTT>; Thu, 8 Dec 2005 13:56:22 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 13:56:19 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Arch Issue #5
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 18:59:24 -0000
Status: RO
Content-Length: 255

--> 
--> #5 change 'external protocols' section to 'interaction with 802.1D'
--> 

Yes.  However, if you are going to include a section for interactions
with 802.1D, does that mean I should omit the samesection in the routing
requirements draft?

--
Eric


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 jB8IVcr18555 for <[e-mail]>; Thu, 8 Dec 2005 10:31:38 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8IVVdJ017698 for <[e-mail]>; Thu, 8 Dec 2005 13:31:32 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA09942 for <[e-mail]>; Thu, 8 Dec 2005 13:31:31 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLGSXT>; Thu, 8 Dec 2005 13:31:31 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 13:31:30 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] PS Issue #12
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 18:42:43 -0000
Status: RO
Content-Length: 1581

--> 
--> #12 address VLAN configuration requirements

As one of the principal intentions of this effort is to allow
for configuration free operation, then inclusion of VLAN as a
preferred support goal, implies that we should make an effort
to allow for the potential of configuration free VLAN support
if and when possible.

As pointed out previously, configuration of VLAN information
is not required in conventional bridges - yet conventional
bridges are fully capable of supporting VLANs. Consequently,
as a minimum, it should be possible for a RBridge to support
VLANs in a siimlar fashion.

However, one of the additional goals of this effort is to make
use of redundant paths, and one way to accomplish this is to
use VLAN identifiers as a part of the path selection criteria.
Using VLAN identifiers ensures that traffic within a VLAN is
not subject to potential re-ordering as a result of using more
than one path, since all of the traffic sharing a common VLAN
identifier will follow the same selected path.

This use of VLAN identifiers does not require configuration of
VLAN information.

VLAN configuration is required for mapping VLAN identifiers in
different scope where an identifier used on one interface (and
in one scope) is equivalent to an identifier on other interfaces
in different scope(s).  

VLAN configuration may be required if an RBridge implementation 
supports (limited) VLAN-to-VLAN routing capabilities.

In both of these cases, this SHOULD be functionality unrelated 
to the TRILL architecture and SHOULD - therefore - be out of 
scope.  

--
Eric



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 jB8Iaer20834 for <[e-mail]>; Thu, 8 Dec 2005 10:36:41 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8IaYdJ017835 for <[e-mail]>; Thu, 8 Dec 2005 13:36:35 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA10688 for <[e-mail]>; Thu, 8 Dec 2005 13:36:34 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLGS94>; Thu, 8 Dec 2005 13:36:34 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 13:36:34 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Arch Issue #1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 18:37:34 -0000
Status: RO
Content-Length: 289

--> 
--> #1 resolve recommendations for the three modes of BSTP messages:
-->    (is this part of the PS or ARCH?)
--> 	participate
--> 	forward
--> 	block

Block by default.  Optional configuration for forwarding and/or
participating MAY be allowed but SHOULD be considered sub-optimal.



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 jB8IH8r11591 for <[e-mail]>; Thu, 8 Dec 2005 10:17:09 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8IH2dJ017409 for <[e-mail]>; Thu, 8 Dec 2005 13:17:03 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08349 for <[e-mail]>; Thu, 8 Dec 2005 13:17:01 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLGS28>; Thu, 8 Dec 2005 13:17:01 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 13:16:58 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] PS Issue #11
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 18:28:23 -0000
Status: RO
Content-Length: 1695

--> 
--> #11 internal/external, inside/outside terminology
-->     there is one objection to these terms as topological;
-->     the draft intends to define them sufficiently
-->     does this need to be addressed further?

This is not a Problem Statement Issue because these terms are
defined in draft-touch-trill-rbridge-arch, rather than in
draft-touch-trill-prob.  Consequently, this is an issue with
the Architectural document, if not precisely an architectural
issue.

The draft definitions are not sufficiently clear on the current 
iteration.

The definitions offered there were - 

-> o  External (to a campus): describes communication on the non-rbridge 
->    components of an Ethernet link subnet, notably not between 
->    rbridges or between non-rbridges and rbridges. 
->
-> ... [snip] ...
-> 
-> o  Internal (to a campus): describes communication between rbridge 
->    devices; this communication may traverse external devices, but is 
->    still considered internal. 

Clearer wording was suggested on this list some time ago.

External links/interfaces are those that do not connect to a
cooperating RBridge; internal links/interfaces are those that
do.  Whether or not non-Bridge devices exist on - or are part 
of - a link between cooperating RBridges is irrelevant.  The
existing attempt to somehow include the possibility of other
devices as part of a link between RBridges in the definition
of internal and external is only confusing.

I believe that the confusion stems from an attempt to allow
for required communications between RBridges and other types
of devices.  This confusion is one strong indication of why
no such communications should be required.

--
Eric


Received: from ytti.fi (ytti.fi [62.236.255.178]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8I7Ur07264 for <[e-mail]>; Thu, 8 Dec 2005 10:07:30 -0800 (PST)
Received: by ytti.fi (Postfix, from userid 1000) id 429AFEFED5; Thu,  8 Dec 2005 20:07:23 +0200 (EET)
Date: Thu, 8 Dec 2005 20:07:22 +0200
From: Saku Ytti <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.11
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] [[e-mail]: Re:  MAC aggregation in rbridge?]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 18:21:41 -0000
Status: RO
Content-Length: 2159

 Apparently I haven't setup folder-hook, thus source address was wrong,
and email is sitting somewhere in queue waiting manual approval.

 And yeah, if course rbridge prefix + ifindex, isn't enough, either
prefix+ifindex+increment, or just prefix+increment.  But seems
that it was understood what I ment from the replies.

----- Forwarded message from Saku Ytti <[e-mail]> -----

From: Saku Ytti <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] MAC aggregation in rbridge?
Date: Wed, 7 Dec 2005 14:46:21 +0200

On (2005-12-07 13:29 +0100), Steven Bakker wrote:
 
> Mmmh, sounds like a L2 NAT? Just as in L3 (IPv4) NAT, L2 NAT has the
> potential to break many things. Right off the bat, I can tell you it
> will break ARP since ARP packets carry MAC address information in their
> payload. This means that for L2 NAT to work, your rbridges need to know
> about possible protocol and rewrite payloads, recalculate checksums,
> etc. This is not going to work. And even if it could, would that scale
> to 10GE and higher speeds? That's an awful lot of rewriting...

 Rewriting is already done in some IP-DSLAM (well just really bridges
with ethernet trunk, no routing) applications, but you typically want
to butt in to ARP's there anyhow. But still, your observation
is valid and it might be more pain than gain.

> IMO, it is unfeasible, unnecessary, and very undesired. Wearing the hat
> of my current employer (large scale Internet exchange), I like the idea
> of rbridge for its potential to better utilise the available links and
> efficiently route traffic. I pretty much have all the TCAM I need.

 Wearing the hat of any metro service provider today, amount of 
MAC addresses you can populate is quite small (think of lot L2 islands
connected via VPLS etc, think of providing ethernet-dslam bitstream)

> MAC aggregation might make sense if there were some kind of structure on
> the allocation of addresses (as in IPv4/v6), but there is not.

 Hence hierarchy needs to be forced, which is, undoubtfully most 
questionable part of it.

-- 
  ++ytti

----- End forwarded message -----

-- 
  ++ytti


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8H5vr07871; Thu, 8 Dec 2005 09:05:57 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 08 Dec 2005 09:04:30 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <36bb01c5fb65$75c91bf0$[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 17:56:58 -0000
Status: RO
Content-Length: 2590

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



Harald Tveit Alvestrand wrote:
> 
> --On onsdag, desember 07, 2005 12:45:19 -0800 Joe Touch <[e-mail]> 
> wrote:
> 
> 
>>>>The latter affects whether multipath forwarding is supported inside the
>>>>rbridge and whether it also requires reordering facilities at the
>>>>egress.
>>>
>>>multipath between a single source/destination pair may be troublesome
>>>enough that we should not attempt it.....
>>
>>Isn't that one of the opportunities we wanted to support, though?
>>
>>It's already supported by the Internet protocols we're considering
>>(e.g., IS-IS - see RFC2991). As per below, do we want to prohibit it
>>outright, or assert that IF equal-cost multipath is used then reordering
>>mitigation (and perhaps latency smoothing) needs to occur?
> 
> 
> from RFC 2991:
> 
>    All of the problems outlined in the previous section arise when
>    packets in the same unicast or multicast "flow" are split among
>    multiple paths.  The natural solution is therefore to ensure that
>    packets for the same flow always use the same path.
> 
> I think it makes sense to say:
> 
> - we don't require that multipath for one source-destination pair be 
> supported
> - IF multipath for one source-destination pair is available, and can cause 
> persistent reordering, we need reordering mitigation in order to be 
> consistent with the Ethernet service model
> 
> I'm troubled by the implicit layer violation in the multipath algorithm 
> trying to detect "flows" at a higher level such as TCP sessions.
> (for extra complexity, add IPSec or encryption at Ethernet layer.... both 
> would make most flow-detection algorithms go haywire....)
> 
>                    Harald

This is an easy position to adopt, but I'm wondering whether anyone
considers the result overly restrictive - esp. where addressing the
limitations of STPs (even MSTP) using Internet-style routing is the
issue (where Internet routing is still embracing multipath).

An alternative would be to allow multipath but limit it for a flow. Here
a flow would be for a single source or destination ethernet address
('external' address). That would allow for multipath for internal
destination addresses (multipath to destination) but retain ordering per
'flow' (in this case the internal addresses act as ports).

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

iD8DBQFDmGeeE5f5cImnZrsRAsClAJ4krvsFpljd4/kF2+GtvLvJ51Th+ACdGkDb
J2cAghjITlOjYdkBBFm2/OI=
=8F9a
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8HtYr01284 for <[e-mail]>; Thu, 8 Dec 2005 09:55:34 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8HtRdJ016960 for <[e-mail]>; Thu, 8 Dec 2005 12:55:28 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA05916 for <[e-mail]>; Thu, 8 Dec 2005 12:55:27 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLGRR0>; Thu, 8 Dec 2005 12:55:26 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 12:55:26 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] PS Issue #10
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 17:56:24 -0000
Status: RO
Content-Length: 120

--> 
--> #10 use campus (seemed to be agreement at the meeting)
-->     or use "pool" or "set"

Use "campus".

--
Eric



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 jB8Hs1r00612 for <[e-mail]>; Thu, 8 Dec 2005 09:54:01 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8HrpdJ016944 for <[e-mail]>; Thu, 8 Dec 2005 12:53:55 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA05749 for <[e-mail]>; Thu, 8 Dec 2005 12:53:51 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLGRQJ>; Thu, 8 Dec 2005 12:53:50 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 12:53:48 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] PS Issue #9
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 17:54:24 -0000
Status: RO
Content-Length: 753

--> 
--> #9 which addresses are not forwarded? (related to ARCH #1)
--> 
--> Bridge Group Address 01-80-C2-00-00-00 , used for frames 
--> transporting BPDUs
-->
--> Pause Frame address 01-80-C2-00-00-01.
-->
--> Besides I am not sure but addresses 01-80-C2-00-00-00 to 
--> 01-80-C2-00-00-0F

This (last statement) appears to be incomplete.  What exactly
is the issue associated with this last statement?

In general, 802.1 bridges on one side of an RBridge should be
transparent from a bridging protocol perspective.  They may
communicate with each other via individual MAC or IP addresses
but bridge control frames should be blocked.

This is necessary in order to realize advantages associated 
with partitioning bridge control-domains...

--
Eric



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 jB8Hl0r27271 for <[e-mail]>; Thu, 8 Dec 2005 09:47:00 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8HkrdJ016800 for <[e-mail]>; Thu, 8 Dec 2005 12:46:54 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA04841 for <[e-mail]>; Thu, 8 Dec 2005 12:46:53 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLGRHM>; Thu, 8 Dec 2005 12:46:52 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 12:46:52 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] PS Issue #8
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 17:50:24 -0000
Status: RO
Content-Length: 627

--> 
--> #8 discuss broadcast vs. subnet broadcast vs. multicast support
--> 	who gets a copy of multicast? all ports, or just subscribed?

The base-line RBridge functionality should assume that any RBridge
MAY treat all multicast traffic the same as broadcast traffic.

The baseline MUST NOT preclude RBridge implementations from being
able to handle multicast traffic using a more optimal approach.

It is appropriate to include development of how to do this as an
item in the TRILL working group charter.  

It is not approriate to otheriwse address this in any great detail
as part of the current problem statement draft.



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 jB8Hfqr24942 for <[e-mail]>; Thu, 8 Dec 2005 09:41:56 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8HfjdJ016628 for <[e-mail]>; Thu, 8 Dec 2005 12:41:46 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA04004 for <[e-mail]>; Thu, 8 Dec 2005 12:41:45 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLGQ0M>; Thu, 8 Dec 2005 12:41:44 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 12:41:44 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] PS Issue #7
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 17:44:26 -0000
Status: RO
Content-Length: 423

--> 
--> #7 differentiate between host reattachment effects
-->    and bridge reattachment effects; the latter impact the STP more

Yes, but what exactly is the issue?

Two statements can be made relative to this:
1) host re-attachment impacts learning/reachability-advertisement more.
2) bridge re-attachment impacts STP/RSTP more.

I believe these two statements to be factual observations, rather than
issues.

--
Eric



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 jB8HPWr16999 for <[e-mail]>; Thu, 8 Dec 2005 09:25:32 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8HPGdJ016222 for <[e-mail]>; Thu, 8 Dec 2005 12:25:16 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA01945 for <[e-mail]>; Thu, 8 Dec 2005 12:25:16 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLGQLT>; Thu, 8 Dec 2005 12:25:15 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 12:25:15 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] PS Issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 17:26:24 -0000
Status: RO
Content-Length: 338

--> 
--> #4 delivery requirements:
--> 	a) is in-order required?
--> 	b) is no-duplication required?
--> 

Transient out of order delivery and infrequent duplication is
permissible.

Persistent in-order delivery is a requirement between any given
source-destination pair (i.e. - in-order from any source, or to
any destination).

--
Eric


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 jB8HM5r15249 for <[e-mail]>; Thu, 8 Dec 2005 09:22:05 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8HLtdJ016153 for <[e-mail]>; Thu, 8 Dec 2005 12:21:56 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA01496 for <[e-mail]>; Thu, 8 Dec 2005 12:21:55 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLGQHJ>; Thu, 8 Dec 2005 12:21:54 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 12:21:53 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] PS Issue #3
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 17:24:05 -0000
Status: RO
Content-Length: 965

--> 
--> #3 IF size is an issue...
--> 	what limits the size? STP/RSTP or broadcast traffic, or both?

Not sure what we mean by "size" here and how this differs from
"scale."

Obviously, an RBridge campus is limited to the size of workable
STP/RSTP solutions only in the fully-meshed connectivity case.
The complete solution may be several times as large given that
STP/RSTP domains exterior to the campus are made smaller.  In
addition, some proposed campus topologies will allow for smaller
STP/RSTP domains even within the RBridge campus. 

Employing multicast routing techniques against L2 multicast, may
allow for a larger broadcast domain as well.  This is especially
true given flooding within RBridge campi will be significantly
less than in a typical 802.1 LAN.

However, the size of the broadcast domain including exterior LAN
segments will ultimately determine the maximum "size" (at least
size measured as numbers of contiguous LAN segments).

--
Eric



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 jB8GoYr29211 for <[e-mail]>; Thu, 8 Dec 2005 08:50:34 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8GoRdJ015476 for <[e-mail]>; Thu, 8 Dec 2005 11:50:28 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27948 for <[e-mail]>; Thu, 8 Dec 2005 11:50:27 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLGPFV>; Thu, 8 Dec 2005 11:50:27 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 11:50:26 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 17:11:19 -0000
Status: RO
Content-Length: 2061

Harald,

 	See below...

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Harald 
--> Tveit Alvestrand
--> Sent: Wednesday, December 07, 2005 3:37 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS issue #4
--> 
--> 
--> 
--> --On onsdag, desember 07, 2005 12:12:14 -0800 Joe Touch 
--> <[e-mail]> 
--> wrote:
--> 
--> > Which requirement:
--> >
--> > a) that reordering is a transient possibility
--> >
--> > b) that persistent reordering is acceptable
--> >
--> > The latter affects whether multipath forwarding is supported inside
the
--> > rbridge and whether it also requires reordering facilities at the
egress.
--> 
--> multipath between a single source/destination pair may be troublesome 
--> enough that we should not attempt it.

I disagree.

In point-to-point technologies, it is often the case that point-to-point
links are "bundled" - either to create an effectively larger "link", or 
to allow for efficient load sharing/distribution.

If multiple similar "cost" paths exist between an RBridge within a campus
(including the egress) and the egress RBridge for any given destination,
then using each of these multiple paths is very similar to (if not exactly
the same as) link-bundling.

This is a reasonably well understood technology.

--> .... I don't think there is an ordering requirement for packets between 
--> different source/destination pairs.

I agree, but would add that the same applies to both different sources and
different destinations, separately, as well.

--> 
--> I don't think that persistent reordering (that is, reordering when the 
--> network is not being perturbed) is acceptable - if severe, it 
--> *significantly*  degrades TCP performance, if nothing else.

I agree, but strongly suspect that this is not what was being suggested.

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


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8H9Vr09489 for <[e-mail]>; Thu, 8 Dec 2005 09:09:31 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8H9OdJ015898 for <[e-mail]>; Thu, 8 Dec 2005 12:09:25 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA00071 for <[e-mail]>; Thu, 8 Dec 2005 12:09:23 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLGPZ2>; Thu, 8 Dec 2005 12:09:23 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 12:09:22 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] PS Issue #2
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 17:10:23 -0000
Status: RO
Content-Length: 315

--> 
--> #2 should the solution apply to current ethernet scales or not?
--> 	and if so, what are current ethernet scales?
--> 	Harald proposed as a starting point:
--> 	* 1000 end-hosts in a single bridged LAN of 100 bridges
--> 	* [100,000] end-hosts inside 1000 VLANs served by [10,000] bridges

Yes, at least.



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 jB8H7Wr08587 for <[e-mail]>; Thu, 8 Dec 2005 09:07:33 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8H7QdJ015867 for <[e-mail]>; Thu, 8 Dec 2005 12:07:27 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA29824 for <[e-mail]>; Thu, 8 Dec 2005 12:07:25 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLGPWS>; Thu, 8 Dec 2005 12:07:25 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 12:07:24 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] PS issue #1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 17:08:23 -0000
Status: RO
Content-Length: 842

--> 
--> #1 which version of ethernet is the baseline?
--> 	STP, RSTP, VLAN, provider bridges, wireless,
--> 	shortest path bridging, etc.
--> 	(this will help us determine what terminology to use)

IMO, STP/RST, and VLAN.  Wireless is a possibility to the extent
that it is directly compatible with 802.1 (STP/RSTP) and VLAN.

We should not be in the role of trying to make inompatibilties
already extant in Ethernet-like technologies go away.

I am not sure what you mean by provider bridges, but assuming
it is like a WAN bridging service, this SHOULD be transparent
to RBridges and may be included.

Since Shortest Path Bridging appears to target a similar problem
space, I don't think it makes sense for us to try to compete with 
that as a solution.  However, we will need to establish that we
are not "breaking" it either...

--
Eric



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 jB8Gcgr23998 for <[e-mail]>; Thu, 8 Dec 2005 08:38:42 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB8GcadJ015246 for <[e-mail]>; Thu, 8 Dec 2005 11:38:36 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26394 for <[e-mail]>; Thu, 8 Dec 2005 11:38:35 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLG3Z9>; Thu, 8 Dec 2005 11:38:35 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Thu, 8 Dec 2005 11:38:34 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 17:02:21 -0000
Status: RO
Content-Length: 4009

Spencer, et al,

Once upon a time, some "higher layer" communication protocols treated
out of order delivery as a communication failure.  For such protocols,
even transient out of order delivery would be unacceptable.

However...

As far as I know, the increasingly common assumption that occasional 
out of order delivery is okay has not led to a lot of loud complaints,
so it is possibly safe to assume that out of order delivery during a
network transient condition is okay for all currently in use "higher
layer" communication protocols.

However, the comment below that persistent out of order delivery must
be okay if we want to allow multiple path use is simply not true.

As has been said on this list before, even though many "higher layer" 
protocols can handle out of order delivery, practically all of them -
most notably including TCP/IP - are optimized for in order delivery.

Consequently, concepts like "link bundling" and ECMP have long taken
this into account and employ any of a number of techniques to ensure
that streams of packets (or frames) from any given source to a given
destination are not persistently delivered over variable paths.

Since using multiple paths across an Ethernet network is precisely
analogous to link bundling, clearly the same techniques apply in the
TRILL/RBridge case as well.

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Joe Touch
--> Sent: Wednesday, December 07, 2005 3:12 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS issue #4
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Spencer Dawkins wrote:
--> > While looking at
--> > 
--> > #4 delivery requirements:
--> >    a) is in-order required?
--> >    b) is no-duplication required?
--> > 
--> > I tripped over some unexpected good news: IEEE 802.1D-2004 does seem
to 
--> > understand that trading off in-order and no-duplication guarantees for

--> > performance makes sense (ex. Section 6.3.3, "NOTE 2-Frame misordering

--> > and duplication (6.3.4) does not occur during normal operation. When  
--> > RSTP is configuring or reconfiguring the network (see Clause 17),
there 
--> > is an increased and implementation-dependent probability that frames
that 
--> > are in transit will be misordered or duplicated as network paths
change, 
--> > since a Bridge can buffer frames awaiting transmission through its
Ports. 
--> > Since the probability of duplication or misordering occurring as a
result 
--> > of reconfiguration is small, and the frequency of physical network
failures 
--> > leading to reconfiguration is also generally small, the degradation of
the 
--> > properties of the MAC service is considered to be negligible."
--> > 
--> > This was a huge improvement over the situation in IEEE 802.17/RPR
several 
--> > years ago, when we assumed (IIRC, because we were explicitly told)
that no 
--> > tradeoff was possible.
--> > 
--> > As the note goes on to say, there are LLC-level protocols that don't 
--> > tolerate out-of-order delivery, but anything running over TCP is
protected 
--> > from misordering, and anything running over UDP should already be
dealing 
--> > with reordering, so I think that for our purposes, we can say that
meeting 
--> > these requirements in normal operation is "good enough".
--> 
--> Which requirement:
--> 
--> a) that reordering is a transient possibility
--> 
--> b) that persistent reordering is acceptable
--> 
--> The latter affects whether multipath forwarding is supported inside the
--> rbridge and whether it also requires reordering facilities at the
egress.
--> 
--> > Although I'm getting off-topic, I note that letting TCPs see
reordering 
--> > during path changes is not a bad thing, since it's a clue that
available 
--> > path bandwidth may be changing...
--> 
--> The Internet doesn't tend to want to think a link layer has volatile
--> properties in general, though.
--> 
--> Joe
--> 


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 jB87QEr17184 for <[e-mail]>; Wed, 7 Dec 2005 23:26:15 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 97DEC9E20D for <[e-mail]>; Thu,  8 Dec 2005 08:26:08 +0100 (CET)
Received: from [163.117.203.228] (unknown [163.117.203.228]) by smtp01.uc3m.es (Postfix) with ESMTP id D2EBA9E26D for <[e-mail]>; Thu,  8 Dec 2005 08:26:07 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 08 Dec 2005 08:26:07 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <36bb01c5fb65$75c91bf0$[e-mail]>	<[e-mail]> <370201c5fb6f$5ec64180$[e-mail]>
In-Reply-To: <370201c5fb6f$5ec64180$[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 07:34:03 -0000
Status: RO
Content-Length: 1658

Spencer Dawkins wrote:

>Hi, Joe,
>
>  
>
>>>As the note goes on to say, there are LLC-level protocols that don't
>>>tolerate out-of-order delivery, but anything running over TCP is 
>>>protected
>>>from misordering, and anything running over UDP should already be dealing
>>>with reordering, so I think that for our purposes, we can say that 
>>>meeting
>>>these requirements in normal operation is "good enough".
>>>      
>>>
>>Which requirement:
>>
>>a) that reordering is a transient possibility
>>
>>b) that persistent reordering is acceptable
>>
>>The latter affects whether multipath forwarding is supported inside the
>>rbridge and whether it also requires reordering facilities at the egress.
>>    
>>
>
>"Reordering is a transient possibility". I think that persistent reordering 
>will not be acceptable (for both technical and political reasons).
>  
>
I fully agree. Reordering  is only acceptable as transitory event.

>  
>
>>>Although I'm getting off-topic, I note that letting TCPs see reordering
>>>during path changes is not a bad thing, since it's a clue that available
>>>path bandwidth may be changing...
>>>      
>>>
>>The Internet doesn't tend to want to think a link layer has volatile
>>properties in general, though.
>>    
>>
>
>(I hope no one ever runs IP over wireless link layers :-) but I do 
>understand your point) 
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

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



Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB86grr00214 for <[e-mail]>; Wed, 7 Dec 2005 22:42:54 -0800 (PST)
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B7CB259732 for <[e-mail]>; Thu,  8 Dec 2005 07:42:12 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29753-07 for <[e-mail]>; Thu,  8 Dec 2005 07:42:09 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id D684A25972E for <[e-mail]>; Thu,  8 Dec 2005 07:42:08 +0100 (CET)
Date: Thu, 08 Dec 2005 07:45:13 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <36bb01c5fb65$75c91bf0$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2005 06:49:27 -0000
Status: RO
Content-Length: 1589

--On onsdag, desember 07, 2005 12:45:19 -0800 Joe Touch <[e-mail]> 
wrote:

>>> The latter affects whether multipath forwarding is supported inside the
>>> rbridge and whether it also requires reordering facilities at the
>>> egress.
>>
>> multipath between a single source/destination pair may be troublesome
>> enough that we should not attempt it.....
>
> Isn't that one of the opportunities we wanted to support, though?
>
> It's already supported by the Internet protocols we're considering
> (e.g., IS-IS - see RFC2991). As per below, do we want to prohibit it
> outright, or assert that IF equal-cost multipath is used then reordering
> mitigation (and perhaps latency smoothing) needs to occur?

from RFC 2991:

   All of the problems outlined in the previous section arise when
   packets in the same unicast or multicast "flow" are split among
   multiple paths.  The natural solution is therefore to ensure that
   packets for the same flow always use the same path.

I think it makes sense to say:

- we don't require that multipath for one source-destination pair be 
supported
- IF multipath for one source-destination pair is available, and can cause 
persistent reordering, we need reordering mitigation in order to be 
consistent with the Ethernet service model

I'm troubled by the implicit layer violation in the multipath algorithm 
trying to detect "flows" at a higher level such as TCP sessions.
(for extra complexity, add IPSec or encryption at Ethernet layer.... both 
would make most flow-detection algorithms go haywire....)

                   Harald






Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB7MAtr17805; Wed, 7 Dec 2005 14:10:55 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 07 Dec 2005 14:13:05 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <370701c5fb6f$f3ac1590$[e-mail]>	<[e-mail]> <373301c5fb74$7164d9a0$[e-mail]>
In-Reply-To: <373301c5fb74$7164d9a0$[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #11
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 22:12:30 -0000
Status: RO
Content-Length: 2106

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



Spencer Dawkins wrote:
> Hi, Joe,
> 
> Thanks for your help as I catch up ...
> 
> 
>>>In the following picture, are the (inside?) bridges in the middle of the
>>>rbridge campus part of the same (outside?) spanning tree, or does what
>>>happens inside the campus show up outside the campus?
>>
>>The same issue applies - all bridges are 'outside'. It's only traffic
>>that's considered to be inside or outside. This is because the traffic
>>between rbridge nodes is tunneled, and it is the tunnel that is
>>'inside'. As a result, bridges may transit tunneled traffic, but they
>>never appear as bridges inside the tunnel, and so are never 'inside' the
>>rbridge.
> 
> I'm wondering if we have the potential for race conditions as bridges 
> between rbridges recompute a spanning tree while rbridges are distributing 
> link state updates,

There are cases in PARTICIPATE where that might matter, but in most
cases it should not, and it can't for TRANSPARENT or BLOCK. In any case
where the rbridge campus acts as a unit, it's not changing its
relationship to the edge trees even though it changes internally, so
there should be no race.

The only race would be when an rbridge device moves around within a
campus (unplug from one place and replug elsewhere), but in that case
there ought to be default rules about what to do until the trees on
either side (inside, outside) are stable.

?  but at worst, I'm thinking this might involve one extra
> path change during routing changes - not oscillating. Maybe this is worth 
> revisiting when we're more solid on the protocol description, but it's 
> probably premature now.
> 
> Again, thanks!
> 
> Spencer 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDl15xE5f5cImnZrsRAi5TAKCnz+F3AUoeCUpk2SH+YzcXhHIJBACgiCQJ
5b1PJYREmivnztaLy6VmIuc=
=i/v6
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB7Lx3r13906 for <[e-mail]>; Wed, 7 Dec 2005 13:59:04 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jB7LwvdJ028268 for <[e-mail]>; Wed, 7 Dec 2005 16:58:58 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA07461 for <[e-mail]>; Wed, 7 Dec 2005 16:58:57 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <X2BLFSF6>; Wed, 7 Dec 2005 16:58:56 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Wed, 7 Dec 2005 16:58:46 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 21:59:19 -0000
Status: RO
Content-Length: 3226

 

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Joe Touch
--> Sent: Wednesday, December 07, 2005 3:12 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS issue #4
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Spencer Dawkins wrote:
--> > While looking at
--> > 
--> > #4 delivery requirements:
--> >    a) is in-order required?
--> >    b) is no-duplication required?
--> > 
--> > I tripped over some unexpected good news: IEEE 
--> 802.1D-2004 does seem to 
--> > understand that trading off in-order and no-duplication 
--> guarantees for 
--> > performance makes sense (ex. Section 6.3.3, "NOTE 2-Frame 
--> misordering and 
--> > duplication (6.3.4) does not occur during normal 
--> operation. When RSTP is 
--> > configuring or reconfiguring the network (see Clause 17), 
--> there is an 
--> > increased and implementation-dependent probability that 
--> frames that are in 
--> > transit will be misordered or duplicated as network paths 
--> change, since a 
--> > Bridge can buffer frames awaiting transmission through 
--> its Ports. Since the 
--> > probability of duplication or misordering occurring as a 
--> result of 
--> > reconfiguration is small, and the frequency of physical 
--> network failures 
--> > leading to reconfiguration is also generally small, the 
--> degradation of the 
--> > properties of the MAC service is considered to be negligible."
--> > 
--> > This was a huge improvement over the situation in IEEE 
--> 802.17/RPR several 
--> > years ago, when we assumed (IIRC, because we were 
--> explicitly told) that no 
--> > tradeoff was possible.
--> > 
--> > As the note goes on to say, there are LLC-level protocols 
--> that don't 
--> > tolerate out-of-order delivery, but anything running over 
--> TCP is protected 
--> > from misordering, and anything running over UDP should 
--> already be dealing 
--> > with reordering, so I think that for our purposes, we can 
--> say that meeting 
--> > these requirements in normal operation is "good enough".
--> 
--> Which requirement:
--> 
--> a) that reordering is a transient possibility
--> 
--> b) that persistent reordering is acceptable
--> 
--> The latter affects whether multipath forwarding is 
--> supported inside the
--> rbridge and whether it also requires reordering facilities 
--> at the egress.
--> 
--> > Although I'm getting off-topic, I note that letting TCPs 
--> see reordering 
--> > during path changes is not a bad thing, since it's a clue 
--> that available 
--> > path bandwidth may be changing...
--> 
--> The Internet doesn't tend to want to think a link layer has volatile
--> properties in general, though.
--> 
--> Joe
--> 
--> 
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDl0IeE5f5cImnZrsRAixWAJ4+GkRB1jnxDPbhmODpm1gjr1ywvACfdaQc
--> t1j8uOgMK1AYCKkRw3q+pps=
--> =Ode4
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB7LOTr01935 for <[e-mail]>; Wed, 7 Dec 2005 13:24:29 -0800 (PST)
Received: from s73602 (unknown[65.104.224.98]) by comcast.net (rwcrmhc12) with SMTP id <20051207212423014007o2bie>; Wed, 7 Dec 2005 21:24:23 +0000
Message-ID: <373301c5fb74$7164d9a0$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <370701c5fb6f$f3ac1590$[e-mail]> <[e-mail]>
Date: Wed, 7 Dec 2005 15:23:16 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #11
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 21:25:13 -0000
Status: RO
Content-Length: 1051

Hi, Joe,

Thanks for your help as I catch up ...

>> In the following picture, are the (inside?) bridges in the middle of the
>> rbridge campus part of the same (outside?) spanning tree, or does what
>> happens inside the campus show up outside the campus?
>
> The same issue applies - all bridges are 'outside'. It's only traffic
> that's considered to be inside or outside. This is because the traffic
> between rbridge nodes is tunneled, and it is the tunnel that is
> 'inside'. As a result, bridges may transit tunneled traffic, but they
> never appear as bridges inside the tunnel, and so are never 'inside' the
> rbridge.

I'm wondering if we have the potential for race conditions as bridges 
between rbridges recompute a spanning tree while rbridges are distributing 
link state updates, but at worst, I'm thinking this might involve one extra 
path change during routing changes - not oscillating. Maybe this is worth 
revisiting when we're more solid on the protocol description, but it's 
probably premature now.

Again, thanks!

Spencer 



Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB7L5Gr25667; Wed, 7 Dec 2005 13:05:16 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 07 Dec 2005 13:07:26 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <370701c5fb6f$f3ac1590$[e-mail]>
In-Reply-To: <370701c5fb6f$f3ac1590$[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #11
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 21:06:27 -0000
Status: RO
Content-Length: 2756

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



Spencer Dawkins wrote:
> I apologize for not sending mail on this issue when it confused me the first 
> time...
> 
> Just to be clear (to me?), when we talk about
> 
> #11 internal/external, inside/outside terminology
>     there is one objection to these terms as topological;
>     the draft intends to define them sufficiently
>     does this need to be addressed further?
> 
> In the following picture (constant-width fonts will help a lot on this), 
> assume that "b"s are bridges, "r"s are rbridges, and "e"s are end stations. 
> Are the set of bridges connecting to e1 part of the same spanning tree as 
> the set of bridges connecting to e2?

That depends on TRANSPARENT, PARTICIPATE, or BLOCK. In BLOCK, e.g., no;
in TRANSPARENT, yes; in PARTICIPATE, that depends on the algorithm used
(i.e., there's a mode that Radia proposed - see ARCH ISSUE #3 - which
would be 'no', but in other cases it might be 'yes').

None of that affects this issue, though...

> e1 -- b --- b ----------- b
>         \   |             |
>           \ |             |
>             b --- r ----- r
>                   |       |
>                   |       | (rbridge campus)
>                   |       |
>                   r ----- r -- b -- b
>                   |               \ |
>                   b --------------- b -- e2
> 
> 
> In the following picture, are the (inside?) bridges in the middle of the 
> rbridge campus part of the same (outside?) spanning tree, or does what 
> happens inside the campus show up outside the campus?

The same issue applies - all bridges are 'outside'. It's only traffic
that's considered to be inside or outside. This is because the traffic
between rbridge nodes is tunneled, and it is the tunnel that is
'inside'. As a result, bridges may transit tunneled traffic, but they
never appear as bridges inside the tunnel, and so are never 'inside' the
rbridge.

> e1 -- b --- b ---------- b
>         \   |            |
>           \ |            |
>             b -- r --b-- r
>                  | /   \ |
>                  b ----- b (rbridge campus)
>                  | \   / |
>                  r --b-- r -- b -- b
>                  |               \ |
>                  b --------------- b -- e2
> 
> All clues are graciously accepted!
> 
> Thanks,
> 
> Spencer
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDl08OE5f5cImnZrsRAr5OAKC8u+2DSVHBqW9CMhAW+lI7sU4i2QCeKqJA
kY5/8Ur9lfZwNjvR+pa2Or8=
=Mxbr
-----END PGP SIGNATURE-----


Received: from rwcrmhc12.comcast.net ([216.148.227.153]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB7KqLr21955 for <[e-mail]>; Wed, 7 Dec 2005 12:52:21 -0800 (PST)
Received: from s73602 (unknown[65.104.224.98]) by comcast.net (rwcrmhc13) with SMTP id <200512072052100150047f3ge>; Wed, 7 Dec 2005 20:52:14 +0000
Message-ID: <370701c5fb6f$f3ac1590$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "TRILL/RBRIDGE WG" <[e-mail]>
Date: Wed, 7 Dec 2005 14:51:04 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] PS issue #11
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 20:53:17 -0000
Status: RO
Content-Length: 1520

I apologize for not sending mail on this issue when it confused me the first 
time...

Just to be clear (to me?), when we talk about

#11 internal/external, inside/outside terminology
    there is one objection to these terms as topological;
    the draft intends to define them sufficiently
    does this need to be addressed further?

In the following picture (constant-width fonts will help a lot on this), 
assume that "b"s are bridges, "r"s are rbridges, and "e"s are end stations. 
Are the set of bridges connecting to e1 part of the same spanning tree as 
the set of bridges connecting to e2?


e1 -- b --- b ----------- b
        \   |             |
          \ |             |
            b --- r ----- r
                  |       |
                  |       | (rbridge campus)
                  |       |
                  r ----- r -- b -- b
                  |               \ |
                  b --------------- b -- e2


In the following picture, are the (inside?) bridges in the middle of the 
rbridge campus part of the same (outside?) spanning tree, or does what 
happens inside the campus show up outside the campus?


e1 -- b --- b ---------- b
        \   |            |
          \ |            |
            b -- r --b-- r
                 | /   \ |
                 b ----- b (rbridge campus)
                 | \   / |
                 r --b-- r -- b -- b
                 |               \ |
                 b --------------- b -- e2

All clues are graciously accepted!

Thanks,

Spencer






Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.152]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB7KmAr20799 for <[e-mail]>; Wed, 7 Dec 2005 12:48:10 -0800 (PST)
Received: from s73602 (unknown[65.104.224.98]) by comcast.net (rwcrmhc12) with SMTP id <20051207204756014007o03ie>; Wed, 7 Dec 2005 20:48:01 +0000
Message-ID: <370201c5fb6f$5ec64180$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <36bb01c5fb65$75c91bf0$[e-mail]> <[e-mail]>
Date: Wed, 7 Dec 2005 14:46:50 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 20:49:58 -0000
Status: RO
Content-Length: 1190

Hi, Joe,

>> As the note goes on to say, there are LLC-level protocols that don't
>> tolerate out-of-order delivery, but anything running over TCP is 
>> protected
>> from misordering, and anything running over UDP should already be dealing
>> with reordering, so I think that for our purposes, we can say that 
>> meeting
>> these requirements in normal operation is "good enough".
>
> Which requirement:
>
> a) that reordering is a transient possibility
>
> b) that persistent reordering is acceptable
>
> The latter affects whether multipath forwarding is supported inside the
> rbridge and whether it also requires reordering facilities at the egress.

"Reordering is a transient possibility". I think that persistent reordering 
will not be acceptable (for both technical and political reasons).

>> Although I'm getting off-topic, I note that letting TCPs see reordering
>> during path changes is not a bad thing, since it's a clue that available
>> path bandwidth may be changing...
>
> The Internet doesn't tend to want to think a link layer has volatile
> properties in general, though.

(I hope no one ever runs IP over wireless link layers :-) but I do 
understand your point) 



Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB7Kh9r19378; Wed, 7 Dec 2005 12:43:09 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 07 Dec 2005 12:45:19 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <36bb01c5fb65$75c91bf0$[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 20:44:24 -0000
Status: RO
Content-Length: 1471

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



Harald Tveit Alvestrand wrote:
> 
> --On onsdag, desember 07, 2005 12:12:14 -0800 Joe Touch <[e-mail]> 
> wrote:
> 
> 
>>Which requirement:
>>
>>a) that reordering is a transient possibility
>>
>>b) that persistent reordering is acceptable
>>
>>The latter affects whether multipath forwarding is supported inside the
>>rbridge and whether it also requires reordering facilities at the egress.
> 
> multipath between a single source/destination pair may be troublesome 
> enough that we should not attempt it.....

Isn't that one of the opportunities we wanted to support, though?

It's already supported by the Internet protocols we're considering
(e.g., IS-IS - see RFC2991). As per below, do we want to prohibit it
outright, or assert that IF equal-cost multipath is used then reordering
mitigation (and perhaps latency smoothing) needs to occur?

> I don't think there is an 
> ordering requirement for packets between different source/destination pairs.
> 
> I don't think that persistent reordering (that is, reordering when the 
> network is not being perturbed) is acceptable - if severe, it 
> *significantly*  degrades TCP performance, if nothing else.

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

iD8DBQFDl0nfE5f5cImnZrsRAso1AKDoe/jOnm3eYvGWFoGEMzdSgAwM1wCg8Tfj
Mif/JpmxpvfTYCH/NEU85YE=
=+Hst
-----END PGP SIGNATURE-----


Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB7KYQr16556 for <[e-mail]>; Wed, 7 Dec 2005 12:34:26 -0800 (PST)
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ADC1325972C for <[e-mail]>; Wed,  7 Dec 2005 21:33:45 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09219-01 for <[e-mail]>; Wed,  7 Dec 2005 21:33:42 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 57C5D25972B for <[e-mail]>; Wed,  7 Dec 2005 21:33:42 +0100 (CET)
Date: Wed, 07 Dec 2005 21:36:44 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <36bb01c5fb65$75c91bf0$[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 20:35:21 -0000
Status: RO
Content-Length: 771

--On onsdag, desember 07, 2005 12:12:14 -0800 Joe Touch <[e-mail]> 
wrote:

> Which requirement:
>
> a) that reordering is a transient possibility
>
> b) that persistent reordering is acceptable
>
> The latter affects whether multipath forwarding is supported inside the
> rbridge and whether it also requires reordering facilities at the egress.

multipath between a single source/destination pair may be troublesome 
enough that we should not attempt it..... I don't think there is an 
ordering requirement for packets between different source/destination pairs.

I don't think that persistent reordering (that is, reordering when the 
network is not being perturbed) is acceptable - if severe, it 
*significantly*  degrades TCP performance, if nothing else.





Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB7KA4r09622; Wed, 7 Dec 2005 12:10:04 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 07 Dec 2005 12:12:14 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <36bb01c5fb65$75c91bf0$[e-mail]>
In-Reply-To: <36bb01c5fb65$75c91bf0$[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 20:10:33 -0000
Status: RO
Content-Length: 2448

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



Spencer Dawkins wrote:
> While looking at
> 
> #4 delivery requirements:
>    a) is in-order required?
>    b) is no-duplication required?
> 
> I tripped over some unexpected good news: IEEE 802.1D-2004 does seem to 
> understand that trading off in-order and no-duplication guarantees for 
> performance makes sense (ex. Section 6.3.3, "NOTE 2-Frame misordering and 
> duplication (6.3.4) does not occur during normal operation. When RSTP is 
> configuring or reconfiguring the network (see Clause 17), there is an 
> increased and implementation-dependent probability that frames that are in 
> transit will be misordered or duplicated as network paths change, since a 
> Bridge can buffer frames awaiting transmission through its Ports. Since the 
> probability of duplication or misordering occurring as a result of 
> reconfiguration is small, and the frequency of physical network failures 
> leading to reconfiguration is also generally small, the degradation of the 
> properties of the MAC service is considered to be negligible."
> 
> This was a huge improvement over the situation in IEEE 802.17/RPR several 
> years ago, when we assumed (IIRC, because we were explicitly told) that no 
> tradeoff was possible.
> 
> As the note goes on to say, there are LLC-level protocols that don't 
> tolerate out-of-order delivery, but anything running over TCP is protected 
> from misordering, and anything running over UDP should already be dealing 
> with reordering, so I think that for our purposes, we can say that meeting 
> these requirements in normal operation is "good enough".

Which requirement:

a) that reordering is a transient possibility

b) that persistent reordering is acceptable

The latter affects whether multipath forwarding is supported inside the
rbridge and whether it also requires reordering facilities at the egress.

> Although I'm getting off-topic, I note that letting TCPs see reordering 
> during path changes is not a bad thing, since it's a clue that available 
> path bandwidth may be changing...

The Internet doesn't tend to want to think a link layer has volatile
properties in general, though.

Joe


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

iD8DBQFDl0IeE5f5cImnZrsRAixWAJ4+GkRB1jnxDPbhmODpm1gjr1ywvACfdaQc
t1j8uOgMK1AYCKkRw3q+pps=
=Ode4
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB7K5Zr08236; Wed, 7 Dec 2005 12:05:35 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 07 Dec 2005 12:07:45 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <36c401c5fb67$d77b6a40$[e-mail]>
In-Reply-To: <36c401c5fb67$d77b6a40$[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] PS issue #7
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 20:07:00 -0000
Status: RO
Content-Length: 1313

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



Spencer Dawkins wrote:
> I'm coming up with a big "huh?" on this one...
> 
> #7 differentiate between host reattachment effects
>    and bridge reattachment effects; the latter impact the STP more
> 
> Host attachment doesn't impact STP at all, does it? I thought that was the 
> whole point of aging filtering table entries (since STP doesn't actually 
> know that my laptop has moved, so bridges that were properly filtering my 
> packets out until I moved are continuing to filter them out after I moved, 
> and I'm waiting for bridges to either learn where I am now from packets that 
> I'm now transmitting or forget where I used to be (if I'm not transmitting 
> any traffic).
> 
> Please correct me if I'm misunderstanding this...

Bridge reattachment affects STP, but host reattachment affects the
caches at the edge. They affect different aspects of the stability of
forwarding overall. (I can update the issue item to reflect this - the
document does not yet differentiate these issues though).

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

iD8DBQFDl0ERE5f5cImnZrsRAqIiAJ9X4NqMD7h/cFL5iVYASbHByRFl/wCggM9x
oefVKloP/e7hRPvCtw47z7s=
=7dVH
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB7K3Xr07595; Wed, 7 Dec 2005 12:03:33 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 07 Dec 2005 12:05:43 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] MAC aggregation in rbridge?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 20:04:42 -0000
Status: RO
Content-Length: 2230

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

The edge devices seem to be just as complex in either case (translate
vs. encapsulate); with encapsulation, there are only as many internal
addresses as edge devices, whereas with translation there could be many
more.

Given the current assumption of encapsulation, what is the gain of a
translation-based system?

Joe

Harald Tveit Alvestrand wrote:
> My thought would be that transporting the source and destination MAC 
> end-to-end is part of the Ethernet model, and we therefore have to respect 
> it in any viable Rbridge design.
> 
> Of course, if you use encapsulation, the rbridges are free to do whatever 
> they want to do with the MAC of the "envelope" (if there is one).
> 
>                         Harald
> 
> (note: encapsulating in IPv4 gives you hierarchy for free, and makes the 
> envelope have 32 bits less space used on address than Mac-in-Mac.... tongue 
> only slightly in cheek....)
> 
> --On onsdag, desember 07, 2005 12:32:35 +0200 Saku Ytti 
> <[e-mail]> wrote:
> 
> 
>>Hey,
>>
>> I was thinking about the feasibility of supporting MAC address
>>aggregation in rbridges. How I think it could work in most simple way is
>>that each rbridge has it's own MAC 'prefix' and it then performs MAC
>>rewrite on it's 'edge' port, effectively changing the original MAC to
>>rbridge prefix+ifindex. Then you'd have aggregated MAC TLV with mask to
>>propagate the information.
>>
>> In more complex scenario, there could be more hierarchy and aggregation
>>depending on topology got from SPF.
>>
>> Is this feasible? Is this needed or is it more sane to just grow
>>TCAM sizes?
>>
>>--
>>  ++ytti
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>>
> 
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDl0CXE5f5cImnZrsRAsLjAJ4q6yqoB76xYPTNHEVyp9bipoevPgCdHnkr
fuCm2HOp3utOFz/vXKZizac=
=M+0N
-----END PGP SIGNATURE-----


Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB7JsFr04348 for <[e-mail]>; Wed, 7 Dec 2005 11:54:15 -0800 (PST)
Received: from s73602 (unknown[65.104.224.98]) by comcast.net (rwcrmhc13) with SMTP id <200512071954100150046vlge>; Wed, 7 Dec 2005 19:54:10 +0000
Message-ID: <36c401c5fb67$d77b6a40$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "TRILL/RBRIDGE WG" <[e-mail]>
Date: Wed, 7 Dec 2005 13:53:05 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] PS issue #7
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 19:55:14 -0000
Status: RO
Content-Length: 707

I'm coming up with a big "huh?" on this one...

#7 differentiate between host reattachment effects
   and bridge reattachment effects; the latter impact the STP more

Host attachment doesn't impact STP at all, does it? I thought that was the 
whole point of aging filtering table entries (since STP doesn't actually 
know that my laptop has moved, so bridges that were properly filtering my 
packets out until I moved are continuing to filter them out after I moved, 
and I'm waiting for bridges to either learn where I am now from packets that 
I'm now transmitting or forget where I used to be (if I'm not transmitting 
any traffic).

Please correct me if I'm misunderstanding this...

Thanks,

Spencer 



Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB7Jger01090 for <[e-mail]>; Wed, 7 Dec 2005 11:42:41 -0800 (PST)
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F2EBA25972A for <[e-mail]>; Wed,  7 Dec 2005 20:41:55 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07778-01 for <[e-mail]>; Wed,  7 Dec 2005 20:41:51 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 81CD7259723 for <[e-mail]>; Wed,  7 Dec 2005 20:41:51 +0100 (CET)
Date: Wed, 07 Dec 2005 20:44:53 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] MAC aggregation in rbridge?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 19:43:18 -0000
Status: RO
Content-Length: 1384

My thought would be that transporting the source and destination MAC 
end-to-end is part of the Ethernet model, and we therefore have to respect 
it in any viable Rbridge design.

Of course, if you use encapsulation, the rbridges are free to do whatever 
they want to do with the MAC of the "envelope" (if there is one).

                        Harald

(note: encapsulating in IPv4 gives you hierarchy for free, and makes the 
envelope have 32 bits less space used on address than Mac-in-Mac.... tongue 
only slightly in cheek....)

--On onsdag, desember 07, 2005 12:32:35 +0200 Saku Ytti 
<[e-mail]> wrote:

> Hey,
>
>  I was thinking about the feasibility of supporting MAC address
> aggregation in rbridges. How I think it could work in most simple way is
> that each rbridge has it's own MAC 'prefix' and it then performs MAC
> rewrite on it's 'edge' port, effectively changing the original MAC to
> rbridge prefix+ifindex. Then you'd have aggregated MAC TLV with mask to
> propagate the information.
>
>  In more complex scenario, there could be more hierarchy and aggregation
> depending on topology got from SPF.
>
>  Is this feasible? Is this needed or is it more sane to just grow
> TCAM sizes?
>
> --
>   ++ytti
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
>






Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB7JbDr28392 for <[e-mail]>; Wed, 7 Dec 2005 11:37:13 -0800 (PST)
Received: from s73602 (unknown[65.104.224.98]) by comcast.net (rwcrmhc13) with SMTP id <2005120719370701500475que>; Wed, 7 Dec 2005 19:37:07 +0000
Message-ID: <36bb01c5fb65$75c91bf0$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "TRILL/RBRIDGE WG" <[e-mail]>
Date: Wed, 7 Dec 2005 13:36:02 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] PS issue #4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 19:38:37 -0000
Status: RO
Content-Length: 1704

While looking at

#4 delivery requirements:
   a) is in-order required?
   b) is no-duplication required?

I tripped over some unexpected good news: IEEE 802.1D-2004 does seem to 
understand that trading off in-order and no-duplication guarantees for 
performance makes sense (ex. Section 6.3.3, "NOTE 2-Frame misordering and 
duplication (6.3.4) does not occur during normal operation. When RSTP is 
configuring or reconfiguring the network (see Clause 17), there is an 
increased and implementation-dependent probability that frames that are in 
transit will be misordered or duplicated as network paths change, since a 
Bridge can buffer frames awaiting transmission through its Ports. Since the 
probability of duplication or misordering occurring as a result of 
reconfiguration is small, and the frequency of physical network failures 
leading to reconfiguration is also generally small, the degradation of the 
properties of the MAC service is considered to be negligible."

This was a huge improvement over the situation in IEEE 802.17/RPR several 
years ago, when we assumed (IIRC, because we were explicitly told) that no 
tradeoff was possible.

As the note goes on to say, there are LLC-level protocols that don't 
tolerate out-of-order delivery, but anything running over TCP is protected 
from misordering, and anything running over UDP should already be dealing 
with reordering, so I think that for our purposes, we can say that meeting 
these requirements in normal operation is "good enough".

Although I'm getting off-topic, I note that letting TCPs see reordering 
during path changes is not a bad thing, since it's a clue that available 
path bandwidth may be changing...

Spencer 



Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB7JJdr21952 for <[e-mail]>; Wed, 7 Dec 2005 11:19:39 -0800 (PST)
Received: from s73602 (unknown[65.104.224.98]) by comcast.net (rwcrmhc13) with SMTP id <20051207191934015004770ae>; Wed, 7 Dec 2005 19:19:34 +0000
Message-ID: <36af01c5fb63$0220df50$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "TRILL/RBRIDGE WG" <[e-mail]>
Date: Wed, 7 Dec 2005 13:18:29 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] PS issue #2
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 19:20:14 -0000
Status: RO
Content-Length: 841

#2 should the solution apply to current ethernet scales or not?
   and if so, what are current ethernet scales?
   Harald proposed as a starting point:
   * 1000 end-hosts in a single bridged LAN of 100 bridges
   * 100.000 end-hosts inside 1000 VLANs served by 10.000 bridges

FWIW, I was reviewing a proposed customer deployment yesterday that included 
5000 end-hosts in a single bridged LAN of 120 bridges...

A quick look at the IEEE tutorial archives turned up "Deploying the world's 
largest IEEE 802.11b campus", at 
http://www.ieee802.org/802_tutorials/nov03/www.wireless.ubc.ca-IEEE-Nov2003.ppt, 
with 5000 end-hosts and 1200 APs/200 distribution switches (I assume 
"distribution switches" == "bridges", in this context).

I'd like our definition of "current ethernet scales" to accommodate these, I 
think...

Thanks,

Spencer 



Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB7J6Cr17744 for <[e-mail]>; Wed, 7 Dec 2005 11:06:12 -0800 (PST)
Received: from s73602 (unknown[65.104.224.98]) by comcast.net (rwcrmhc11) with SMTP id <2005120719052901300bghare>; Wed, 7 Dec 2005 19:05:35 +0000
Message-ID: <367d01c5fb61$0e1b8050$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "TRILL/RBRIDGE WG" <[e-mail]>
Date: Wed, 7 Dec 2005 13:04:20 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] PS issue #1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 19:07:11 -0000
Status: RO
Content-Length: 1789

Strongly agree that we need an answer to

#1 which version of ethernet is the baseline?
   STP, RSTP, VLAN, provider bridges, wireless,
   shortest path bridging, etc.
   (this will help us determine what terminology to use)

and suggest that the answer is "at least RSTP/IEEE 802.1D-2004" (to avoid 
spending a lot of energy comparing Rbridge to RSTP late in the game, when 
someone notices that comparing to traditional STP isn't useful).

I am not aware of any text describing shortest path bridging in IEEE 802.1, 
much less an approved specification. There are no documents listed at 
http://www.ieee802.org/1/pages/802.1aq.html. The closest I can come to a 
reference is for a tutorial given by Norm Finn this past summer (at 
http://grouper.ieee.org/groups/802/802_tutorials/july05/nfinn-shortest-path-bridging.pdf) 
(and, by the way, Mick Seaman's tutorial from the same session, at 
http://grouper.ieee.org/groups/802/802_tutorials/july05/tutorial-seaman-bridging-technology-0507-01.pdf, 
is also helpful background). So I don't think we can use "shortest path 
bridging" as a baseline now.

I don't see that wireless (IEEE 802.11/16/etc) is going to have an effect on 
bridging behavior (these are PHY/MAC specifications, right?) - except that 
an Rbridge could announce that it now knows a new MAC address based on 
wireless registration, instead of waiting for traffic and learning from 
source addresses.

I don't see that provider/provider backbone bridges, etc. 
(http://www.ieee802.org/1/pages/802.1ad.html, 
http://www.ieee802.org/1/pages/802.1ah.html) are immediately relevant, 
except that if Rbridges "snoop" other protocols, they need to be able to 
decapsulate down to the protocols they are snooping.

If I misunderstood, please correct me, of course :-)

Spencer 



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 jB7G3Er21084 for <[e-mail]>; Wed, 7 Dec 2005 08:03:14 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 336F69DF75 for <[e-mail]>; Wed,  7 Dec 2005 17:03:08 +0100 (CET)
Received: from [163.117.139.223] (gibanez.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with ESMTP id 7468A9D85A for <[e-mail]>; Wed,  7 Dec 2005 17:03:07 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 07 Dec 2005 17:03:06 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] MAC aggregation in rbridge?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 16:04:16 -0000
Status: RO
Content-Length: 2098

Sakku, Steven,

Just for  information on MAC aggregation, you can find here a link to a 
proposal  originated by Jose  Morales, based on private MAC  addresses 
assignment by ISPs (and the like), that allows aggregation.  I have no 
defined position on this proposal, but there are interesting aspects on 
it to analyze. Regarding upper layers the proposal is quite radical.
Guillermo

 http://www.lmdata.es/uets/uets-cm1.pdf

Steven Bakker wrote:

>On Wed, 2005-12-07 at 12:32 +0200, Saku Ytti wrote:
>
>  
>
>> I was thinking about the feasibility of supporting MAC address aggregation
>>in rbridges. How I think it could work in most simple way is that each rbridge
>>has it's own MAC 'prefix' and it then performs MAC rewrite on it's 'edge'
>>port, effectively changing the original MAC to rbridge prefix+ifindex. Then
>>you'd have aggregated MAC TLV with mask to propagate the information.
>>    
>>
>
>Mmmh, sounds like a L2 NAT? Just as in L3 (IPv4) NAT, L2 NAT has the
>potential to break many things. Right off the bat, I can tell you it
>will break ARP since ARP packets carry MAC address information in their
>payload. This means that for L2 NAT to work, your rbridges need to know
>about possible protocol and rewrite payloads, recalculate checksums,
>etc. This is not going to work. And even if it could, would that scale
>to 10GE and higher speeds? That's an awful lot of rewriting...
>
>  
>
>> Is this feasible? Is this needed or is it more sane to just grow
>>TCAM sizes?
>>    
>>
>
>IMO, it is unfeasible, unnecessary, and very undesired. Wearing the hat
>of my current employer (large scale Internet exchange), I like the idea
>of rbridge for its potential to better utilise the available links and
>efficiently route traffic. I pretty much have all the TCAM I need.
>
>MAC aggregation might make sense if there were some kind of structure on
>the allocation of addresses (as in IPv4/v6), but there is not.
>
>Regards,
>Steven
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>




Received: from betonmix.noc.ams-ix.net ([e-mail] [193.194.136.135]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB7CTrr24995 for <[e-mail]>; Wed, 7 Dec 2005 04:29:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by betonmix.noc.ams-ix.net (Postfix) with ESMTP id 898C8FA880; Wed,  7 Dec 2005 13:29:51 +0100 (CET)
Received: from localhost.localdomain (betonmix.noc.ams-ix.net [193.194.136.135]) by betonmix.noc.ams-ix.net (Postfix) with ESMTP id 61ACCFA86E; Wed,  7 Dec 2005 13:29:51 +0100 (CET)
From: Steven Bakker <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Organization: Amsterdam Internet Exchange (AMS-IX)
Date: Wed, 07 Dec 2005 13:29:50 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.2 (2.4.2-1.1.fc4.nr) 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at betonmix.noc.ams-ix.net
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] MAC aggregation in rbridge?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 12:30:19 -0000
Status: RO
Content-Length: 1445

On Wed, 2005-12-07 at 12:32 +0200, Saku Ytti wrote:

>  I was thinking about the feasibility of supporting MAC address aggregation
> in rbridges. How I think it could work in most simple way is that each rbridge
> has it's own MAC 'prefix' and it then performs MAC rewrite on it's 'edge'
> port, effectively changing the original MAC to rbridge prefix+ifindex. Then
> you'd have aggregated MAC TLV with mask to propagate the information.

Mmmh, sounds like a L2 NAT? Just as in L3 (IPv4) NAT, L2 NAT has the
potential to break many things. Right off the bat, I can tell you it
will break ARP since ARP packets carry MAC address information in their
payload. This means that for L2 NAT to work, your rbridges need to know
about possible protocol and rewrite payloads, recalculate checksums,
etc. This is not going to work. And even if it could, would that scale
to 10GE and higher speeds? That's an awful lot of rewriting...

>  Is this feasible? Is this needed or is it more sane to just grow
> TCAM sizes?

IMO, it is unfeasible, unnecessary, and very undesired. Wearing the hat
of my current employer (large scale Internet exchange), I like the idea
of rbridge for its potential to better utilise the available links and
efficiently route traffic. I pretty much have all the TCAM I need.

MAC aggregation might make sense if there were some kind of structure on
the allocation of addresses (as in IPv4/v6), but there is not.

Regards,
Steven



Received: from ytti.fi (ytti.fi [62.236.255.178]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB7AWgr21619 for <[e-mail]>; Wed, 7 Dec 2005 02:32:42 -0800 (PST)
Received: by ytti.fi (Postfix, from userid 1000) id E9E1397BA6; Wed,  7 Dec 2005 12:32:35 +0200 (EET)
Date: Wed, 7 Dec 2005 12:32:35 +0200
From: Saku Ytti <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.11
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] MAC aggregation in rbridge?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 10:33:06 -0000
Status: RO
Content-Length: 584

Hey,

 I was thinking about the feasibility of supporting MAC address aggregation
in rbridges. How I think it could work in most simple way is that each rbridge
has it's own MAC 'prefix' and it then performs MAC rewrite on it's 'edge'
port, effectively changing the original MAC to rbridge prefix+ifindex. Then
you'd have aggregated MAC TLV with mask to propagate the information.

 In more complex scenario, there could be more hierarchy and aggregation
depending on topology got from SPF.

 Is this feasible? Is this needed or is it more sane to just grow
TCAM sizes?

-- 
  ++ytti


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB70vXr19669; Tue, 6 Dec 2005 16:57:33 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 06 Dec 2005 16:59:42 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <BDD1451F2D3F7999934B11CD@B50854F0A9192E8EC6CDA126>
In-Reply-To: <BDD1451F2D3F7999934B11CD@B50854F0A9192E8EC6CDA126>
X-Enigmail-Version: 0.91.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]
Subject: [rbridge] PS and ARCH issues
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2005 00:58:10 -0000
Status: RO
Content-Length: 5619

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

Hi, all,

There have been a few responses, most recently Harald's, which suggest
we start a list of issues for the problem statement doc. Here's a first
cut - not intended to be complete, but a reasonable start (I hope).

I propose that if you want to discuss an issue, please post a note with
the following subject (e.g.):

	PS issue #3
	ARCH issue #4

That'll help us track things until (and if) we use a proper issues tracker.

PLEASE POST ANY ISSUES I MISSED as "PS issue NWE" or "ARCH issue NEW" ;
I will assign numbers to them and post the master list at
www.postel.org/rbridge

These lists are posted there (in a few minutes) as well...

Joe

- -----------
PS issues:

#1 which version of ethernet is the baseline?
	STP, RSTP, VLAN, provider bridges, wireless,
	shortest path bridging, etc.
	(this will help us determine what terminology to use)

#2 should the solution apply to current ethernet scales or not?
	and if so, what are current ethernet scales?
	Harald proposed as a starting point:
	* 1000 end-hosts in a single bridged LAN of 100 bridges
	* 100.000 end-hosts inside 1000 VLANs served by 10.000 bridges

#3 IF size is an issue...
	what limits the size? STP/RSTP or broadcast traffic, or both?

#4 delivery requirements:
	a) is in-order required?
	b) is no-duplication required?

#6 address MSTP regions (esp sec 2.2)
	as a way to limit STP scale/reconfiguration
IEEE 802.1Q  Multiple Spanning Tree Protocol.
Tutorial available : "Understanding Multiple Spanning Tree Protocol" at
www.cisco.com

#7 differentiate between host reattachment effects
   and bridge reattachment effects; the latter impact the STP more

#8 discuss broadcast vs. subnet broadcast vs. multicast support
	who gets a copy of multicast? all ports, or just subscribed?

#9 which addresses are not forwarded? (related to ARCH #1)

Bridge Group Address 01-80-C2-00-00-00 , used for frames transporting
BPDUs
Pause Frame address 01-80-C2-00-00-01.
Besides I am not sure but addresses 01-80-C2-00-00-00 to 01-80-C2-00-00-0F

#10 use campus (seemed to be agreement at the meeting)
    or use "pool" or "set"

#11 internal/external, inside/outside terminology
    there is one objection to these terms as topological;
    the draft intends to define them sufficiently
    does this need to be addressed further?

#12 address VLAN configuration requirements

#13 need configuration time examples
    e.g. references to published research and a summary that shows how
    small changes can have large effects

#14 add risks of TRANSPARENT (larger trees, slower to converge, etc.)

#15 sec 2.3 should be more clear about referring to computing backups to
use in case of failure - not that extra links makes routing easier.

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

ARCH ISSUES

#1 resolve recommendations for the three modes of BSTP messages:
   (is this part of the PS or ARCH?)
	participate
	forward
	block

#2 is an rbridge the DR of the edge STPs?

#3 do rbridges have proxy bridges at their edges (see Radia's post of
10/21/2005)?
(see Guillermo's text below)

#4 Giullermo's subcase?
   address interior packets to egress rather than next-hop
   (isn't egress also in there, in the inner shim header?)

#5 change 'external protocols' section to 'interaction with 802.1D'

- -----

Guillermo's text for ARCH #3:

RBridge indirect participation in bridged island spanning tree.
- ---------------------------------------------------------------
RBridges by default do not participate in spanning tree in other way
than ignoring received BPDUs. It is an objective of RBridge
specification to be independent of bridges specifications as much as
possible.

However it may be convenient for RBridges in some circumstances to
participate in the spanning tree and contend to be root bridge of the
spanning tree formed in the bridged island they are attached to. In
these cases it is possible to build a device that's logically the same
as a bridge glued onto an RBridge. The following schema applies:

                        ?-----------?
       bridged island-----B1----RB1 ?
                        ?-----------?

                        RBridge/bridge box

where B1 is a bridge with two ports...a pt-to-pt link to RBRidge RB1,
and a link to the bridged LAN. The "RB1" portion of this box acts as an
standard RBridge, it neither forwards, nor initiates spanning tree
messages. The "B1" portion acts as two-port standard 802.1D bridge, and
does participate in spanning tree. Its priority for root election can be
set in the standard way. To minimize configurafion, it may be convenient
in some implementations to make the standard B1 bridge priority a
function of the configurable RBridge priority for IS-IS Designated
RBridge election. In this way Designated RBridge will participate and
contend (as B1) to be elected also as root bridge of the bridged island
and only one priority configuration is required.

If (in environments using such implementations) the default bridge
priority for B1 is lower than standard bridge priority, by default
RBridges/bridges like B1 shown will become roots of their bridged
islands, contending only with other RBridges connected to same island
for root election. It is not mandatory for RBridges be
combined bridge/RBridges.

- -------

















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

iD8DBQFDljP+E5f5cImnZrsRAgP1AKC9uKQx2rU7XhWA8hUBso6zjIcDVwCdFvsf
KnKuXdsSscIJtGO7oEFI3a8=
=NCkl
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB6Nw5r00898; Tue, 6 Dec 2005 15:58:05 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 06 Dec 2005 16:00:14 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <BDD1451F2D3F7999934B11CD@B50854F0A9192E8EC6CDA126>
In-Reply-To: <BDD1451F2D3F7999934B11CD@B50854F0A9192E8EC6CDA126>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Notes on draft-touch-trill-prob-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Dec 2005 23:59:09 -0000
Status: RO
Content-Length: 637

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

Some of my own comments below:

Harald Tveit Alvestrand wrote:
> Summary:
> 
> Good start. Much to be done.
> 
> - Key issue:

I've added these to the 'list of issues' for this doc.

Some of the other details raised issue-level items; others are more
edit-level. I'll send a more detailed summary of which are which in a
few days.

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

iD8DBQFDliYOE5f5cImnZrsRAgS6AKDiIAihzhAG6zMkQI6KWs6Qj1UnZgCdF2CY
pL0cfoNKswdT6XofRyjXZUs=
=x8Ok
-----END PGP SIGNATURE-----


Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB1Ln8E11883; Thu, 1 Dec 2005 13:49:08 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 01 Dec 2005 13:51:11 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] (R)bridging dissimilar media
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2005 21:54:06 -0000
Status: RO
Content-Length: 2330

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

Why would it matter?

I would expect TRILL to depend primarily on the more conventional
link-layer accessibility that 802.1 provides, independent of the media.

(i.e., dependent on the link layer, but not the media)

Joe

Templin, Fred L wrote:
> I was more or less thinking the former, i.e., from one side
> of an Rbridge to the other. Some seem to believe that only
> a router can be used in this instance and the dissimilar
> media need to be considered as separate logical IP subnets.
> Is there some magic in TRILL that would make it so that
> two or more segments of dissimilar media could appear to
> be part of the same logical IP subnet?
> 
> Fred
> [e-mail]
>  
> 
> 
>>-----Original Message-----
>>From: Spencer Dawkins [mailto:[e-mail]] 
>>Sent: Thursday, December 01, 2005 7:59 AM
>>To: Developing a hybrid router/bridge.
>>Subject: Re: [rbridge] (R)bridging dissimilar media
>>
>>Fred,
>>
>>Just so I understand the question, are you thinking of 
>>dissimilar media from 
>>one side of an RBRIDGE to the other, or are you thinking of 
>>dissimilar media 
>>from one side of an RBRIDGE campus (dare I use this word?) to 
>>the other - a 
>>slightly broader question?
>>
>>Thanks,
>>
>>Spencer
>>
>>Harald Tveit Alvestrand wrote:
>>
>>
>>>How dissimilar were you thinking of?
>>>
>>>My immediate thought is that the media has to offer the Ethernet
>>>service model, which means support for multicast & broadcast, so ATM
>>>won't qualify, but 802.11 will....
>>>
>>>--On 30. november 2005 08:17 -0800 "Templin, Fred L"
>>><[e-mail]> wrote:
>>>
>>>
>>>>Does the TRILL approach extend to support (R)bridging of
>>>>dissimilar media?
>>>>
>>>>Fred
>>>>[e-mail] 
>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>>
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDj3BPE5f5cImnZrsRAnsHAJ0agxJ3qz604aWyHsMiFfyWgZJmUACg1Uxf
tP/0SzPJVfbQ5/Ad2QBO8Qk=
=QJdu
-----END PGP SIGNATURE-----


Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB1GRIE23769 for <[e-mail]>; Thu, 1 Dec 2005 08:27:18 -0800 (PST)
Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA07027 for <[e-mail]>; Thu, 1 Dec 2005 08:27:04 -0800 (PST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jB1GR4x08144 for <[e-mail]>; Thu, 1 Dec 2005 08:27:04 -0800 (PST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 1 Dec 2005 08:26:28 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 1 Dec 2005 08:26:28 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] (R)bridging dissimilar media
Thread-Index: AcX2keo8Icj/ans5SES8llOhRGRFXAAAX13w
From: "Templin, Fred L" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 01 Dec 2005 16:26:28.0613 (UTC) FILETIME=[FB449B50:01C5F693]
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 jB1GRIE23769
Subject: Re: [rbridge] (R)bridging dissimilar media
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2005 16:28:59 -0000
Status: RO
Content-Length: 1614

I was more or less thinking the former, i.e., from one side
of an Rbridge to the other. Some seem to believe that only
a router can be used in this instance and the dissimilar
media need to be considered as separate logical IP subnets.
Is there some magic in TRILL that would make it so that
two or more segments of dissimilar media could appear to
be part of the same logical IP subnet?

Fred
[e-mail]
 

> -----Original Message-----
> From: Spencer Dawkins [mailto:[e-mail]] 
> Sent: Thursday, December 01, 2005 7:59 AM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] (R)bridging dissimilar media
> 
> Fred,
> 
> Just so I understand the question, are you thinking of 
> dissimilar media from 
> one side of an RBRIDGE to the other, or are you thinking of 
> dissimilar media 
> from one side of an RBRIDGE campus (dare I use this word?) to 
> the other - a 
> slightly broader question?
> 
> Thanks,
> 
> Spencer
> 
> Harald Tveit Alvestrand wrote:
> 
> > How dissimilar were you thinking of?
> >
> > My immediate thought is that the media has to offer the Ethernet
> > service model, which means support for multicast & broadcast, so ATM
> > won't qualify, but 802.11 will....
> >
> > --On 30. november 2005 08:17 -0800 "Templin, Fred L"
> > <[e-mail]> wrote:
> >
> >> Does the TRILL approach extend to support (R)bridging of
> >> dissimilar media?
> >>
> >> Fred
> >> [e-mail] 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
> 


Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB1G0iE14884 for <[e-mail]>; Thu, 1 Dec 2005 08:00:44 -0800 (PST)
Received: from s73602 (unknown[65.104.224.98]) by comcast.net (rwcrmhc11) with SMTP id <2005120116003801300or8bge>; Thu, 1 Dec 2005 16:00:39 +0000
Message-ID: <219801c5f690$36b96390$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <7CD51C7073574923C6EF1251@B50854F0A9192E8EC6CDA126>
Date: Thu, 1 Dec 2005 09:59:13 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] (R)bridging dissimilar media
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2005 16:02:45 -0000
Status: RO
Content-Length: 753

Fred,

Just so I understand the question, are you thinking of dissimilar media from 
one side of an RBRIDGE to the other, or are you thinking of dissimilar media 
from one side of an RBRIDGE campus (dare I use this word?) to the other - a 
slightly broader question?

Thanks,

Spencer

Harald Tveit Alvestrand wrote:

> How dissimilar were you thinking of?
>
> My immediate thought is that the media has to offer the Ethernet
> service model, which means support for multicast & broadcast, so ATM
> won't qualify, but 802.11 will....
>
> --On 30. november 2005 08:17 -0800 "Templin, Fred L"
> <[e-mail]> wrote:
>
>> Does the TRILL approach extend to support (R)bridging of
>> dissimilar media?
>>
>> Fred
>> [e-mail] 



Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB19UtE07851 for <[e-mail]>; Thu, 1 Dec 2005 01:30:55 -0800 (PST)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 49D66831F9 for <[e-mail]>; Thu,  1 Dec 2005 10:30:49 +0100 (CET)
Received: from [163.117.203.82] (unknown [163.117.203.82]) by smtp03.uc3m.es (Postfix) with ESMTP id 409FE83203 for <[e-mail]>; Thu,  1 Dec 2005 10:30:48 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 01 Dec 2005 10:30:47 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]	.com> <7CD51C7073574923C6EF1251@B50854F0A9192E8EC6CDA126>
In-Reply-To: <7CD51C7073574923C6EF1251@B50854F0A9192E8EC6CDA126>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] (R)bridging dissimilar media
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2005 09:34:48 -0000
Status: RO
Content-Length: 1715

802.11 would be worth a detailed analysis (to be included in the draft). 
One aspect is the inter Access Point communication for tracking movin 
endnodes (stations). For instance, consider the scenario when a station 
moves from the reach of one Access Point to another AP area, the "new" 
AP broadcasts  the new station in the fixed network, the DR shall learn 
this new endnode and include in its host list announcements.  "Previous" 
AP shall cancel the endnode from his announced host list. It also 
applies to fixed networks case. The simultaneous announcement of a 
specific host by two Rbridges may be  solved by selecting as owner of 
host the Rbridge with most recent announcement of the two.
Guillermo

Harald Tveit Alvestrand wrote:

> How dissimilar were you thinking of?
>
> My immediate thought is that the media has to offer the Ethernet 
> service model, which means support for multicast & broadcast, so ATM 
> won't qualify, but 802.11 will....
>
> --On 30. november 2005 08:17 -0800 "Templin, Fred L" 
> <[e-mail]> wrote:
>
>> Does the TRILL approach extend to support (R)bridging of
>> dissimilar media?
>>
>> Fred
>> [e-mail]
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://www.postel.org/mailman/listinfo/rbridge
>>
>>
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

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



Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB18MqE17739 for <[e-mail]>; Thu, 1 Dec 2005 00:22:52 -0800 (PST)
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 63905259722 for <[e-mail]>; Thu,  1 Dec 2005 09:22:15 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24619-03 for <[e-mail]>; Thu,  1 Dec 2005 09:22:10 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4804825970C for <[e-mail]>; Thu,  1 Dec 2005 09:22:10 +0100 (CET)
Date: Thu, 01 Dec 2005 09:22:33 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-ID: <7CD51C7073574923C6EF1251@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <[e-mail] .com>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========ADBA00ADA17D5B9E728B=========="
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] (R)bridging dissimilar media
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2005 08:23:21 -0000
Status: RO
Content-Length: 1097

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

How dissimilar were you thinking of?

My immediate thought is that the media has to offer the Ethernet service=20
model, which means support for multicast & broadcast, so ATM won't qualify, =

but 802.11 will....

--On 30. november 2005 08:17 -0800 "Templin, Fred L"=20
<[e-mail]> wrote:

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




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

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

iD8DBQFDjrLJOMj+2+WY0F4RAvYEAJ4isj1jmuemBEjWnM1YFxR6kr488wCeI1XY
2qSHdok+yG+EkW/wHdbKvkE=
=+cZ/
-----END PGP SIGNATURE-----

--==========ADBA00ADA17D5B9E728B==========--