[rbridge] Separating endnode info from link state info

[gibanez at it.uc3m.es ( Guillermo Ibáñez )]

Guillermo Ib??ez wrote:
Thanks Radia and Joe for the clarification.
Radia,
      In your posting of past 9 March (see below) on VLANs you mention 
an optimization: to separate the endnode information from link state 
information.  This point looks important for scalability and flexibility 
of implementation. Decoupling of host information from the routing 
protocol seems important because MAC addresses are not hierarchical, do 
not consolidate.
 One form of separation  of endnode information from link state 
information (among other possible) is to use the ARP servers approach, 
extending it to "ARP&DR" servers.  Endnode-Rbridge association 
information might reside in the ARP servers and be obtained at the same 
time that endnode ARP request is replied. The ARP server replies to DR 
with destination endnode MAC and destination endnode DR's MAC so the 
routing can work with the destination DR MAC instead of endnode. The DR 
MAC is used to route till destination rbridge, the destination endnode 
MAC is used to route in the last hop.
Regarding registration, at the same time  the DR registers the 
requesting ennode at the ARP server, the DR gets also registered, 
associated to endnode.
There are other alternatives, like the DRs issuing encapsulated ARPs 
that the DR would respond with its MAC and the endnode MACs.  Although 
both alternatives can be seen as optimizations, the decision to separate 
or not endnode-DR association information from link state information is 
important. This separation provides also flexibility for implementation 
and evolution. This might be beneficial in wireless environments, where 
broadcasting a long list of hosts may be an important overhead.

Regards
Guillermo
*Radia Perlman* Radia.Perlman at Sun.COM 
<mailto:rbridge%40postel.org?Subject=%5Brbridge%5D%20VLANs&In-Reply-To=1509658726.20050304210311%40psg.com>
/Wed Mar 9 07:59:43 PST 2005/

    * Previous message: [rbridge] End station discovery/liveness
      detection
      <http://www.postel.org/pipermail/rbridge/2005-March/000237.html>
    * Next message: [rbridge] VLANs
      <http://www.postel.org/pipermail/rbridge/2005-March/000245.html>
    * *Messages sorted by:* [ date ]
      <http://www.postel.org/pipermail/rbridge/2005-March/date.html#238>
      [ thread ]
      <http://www.postel.org/pipermail/rbridge/2005-March/thread.html#238>
      [ subject ]
      <http://www.postel.org/pipermail/rbridge/2005-March/subject.html#238>
      [ author ]
      <http://www.postel.org/pipermail/rbridge/2005-March/author.html#238>

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

There are various ways that we can optimize for VLANs, and as usual, the 
choices are
a continuum of tradeoffs between optimality of memory, bandwidth, 
complexity, etc.

One thing we should do is have RBridges announce which VLANs they are 
supporting
for endnodes. This would have to be configured, which I believe it is 
done for bridges.

So each RBridge knows, for each of its links, which VLANs are allowed on 
that link.
It announces this information in its link state information.

Now all RBridges know which RBridges are attached to which VLANs.

This now allows confining the broadcast domains. Unknown destinations or 
ARP/ND
queries only need to be sent to Designated RBridges attached to the VLAN 
in which
the packet originated. Depending on the amount of traffic which is 
unicast vs
needing to be flooded (within the VLAN), there is a range of choices of 
how to get
a packet to all the nodes within the VLAN. These are the same choices as 
for multicast,
which I summarized in an earlier message, but basically it's
a) send through a spanning tree to all RBridges, and DRs only flood onto 
their LAN
to endnodes if the packet is for the right VLAN (if we did this we 
wouldn't even
need to announce in link state packets which VLANs RBridge supported)
b) send through the same single spanning tree to all RBridges, but an 
RBridge looks
downstream, and stops forwarding if there are no RBridges supporting 
that VLAN further down
c) compute per-source-RBridge trees, and when RBridge R floods a packet 
for VLAN A,
the flooding will be done based on the tree rooted at R, and pruning 
will also be done,
as per point b.

Now for known endnodes:
Especially since someone told me that people want the capability to have 
overlapping
MAC address spaces among VLANs (the node with MAC address "m" in VLAN A
might be totally different from the node "m" in VLAN B), RBridges, in 
their link
state information, should tag what VLAN "m" belongs to.

Given that R knows what VLANs MAC addresses belong to, if R does not support
VLAN B, then there is no reason for R to put MAC addresses for B in its
forwarding table. But if the endnode information is in the regular link 
state information
(assume that for now), then R will need to store it so R can participate 
in link state
flooding.

Now another optimization: Suppose you want to avoid making R know about any
endnodes except in VLANs that R supports.

Then we could do the distribution of endnode information separately from the
rest of the link state information (the "regular stuff" is the connectivity
of the network consisting of RBridges, and tagging which RBridges are in 
which
VLANs).

If R is in VLAN A, then R must inform all the other RBridges attached to 
VLAN A
of all of R's VLAN A attached endnodes. If there were enough VLAN A peers in
the campus, it would probably be simplest to just use the regular link state
flooding to distribute the information. However, if that isn't the case, 
then
the VLAN A RBridge peers could talk to each other across the cloud to 
separately
distribute their endnode information. For instance, it could be sent as
a VLAN A flood, which the core would know how to do (as per the beginning of
this note).

Now, if non-VLAN-A RBridges do not know about the MAC addresses in A,
that can't be what they base their forwarding decision on.

If RBridge is working over MPLS, this isn't a problem, since the MPLS
path leads to the egress RBridge.

If there were only pt-to-pt links (no shared media) we could have the
encapsulation header point to the egress RBridge.

But on shared media, what we can do, at a cost of only 6 additional
bytes, is to also put "egress RBridge ID" into the encapsulation header.

So before on Ethernets a packet being forwarded by RBridges looked like:

outer header: source=transmitting RBridge, dest=nexthop RBridge, protocol
type=to be defined
encapsulation header: TTL
original frame

But by making the encapsulation header include "destination RBridge",
and having the RBridges along the path forward based on that, then
they wouldn't need to be forwarding based on endnode MACs, only
RBridge MACs.

Radia







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 j4H9Gw329733 for <[e-mail]>; Tue, 17 May 2005 02:16:58 -0700 (PDT)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D1FD4495AC for <[e-mail]>; Tue, 17 May 2005 11:16:51 +0200 (CEST)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp03.uc3m.es (Postfix) with ESMTP id 1D8704958C for <[e-mail]>; Tue, 17 May 2005 11:16:51 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 17 May 2005 11:16:52 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Separating endnode info from link state info
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 17 May 2005 09:18:22 -0000
Status: RO
Content-Length: 6776

Guillermo Ib??ez wrote:
Thanks Radia and Joe for the clarification.
Radia,
      In your posting of past 9 March (see below) on VLANs you mention 
an optimization: to separate the endnode information from link state 
information.  This point looks important for scalability and flexibility 
of implementation. Decoupling of host information from the routing 
protocol seems important because MAC addresses are not hierarchical, do 
not consolidate.
 One form of separation  of endnode information from link state 
information (among other possible) is to use the ARP servers approach, 
extending it to "ARP&DR" servers.  Endnode-Rbridge association 
information might reside in the ARP servers and be obtained at the same 
time that endnode ARP request is replied. The ARP server replies to DR 
with destination endnode MAC and destination endnode DR's MAC so the 
routing can work with the destination DR MAC instead of endnode. The DR 
MAC is used to route till destination rbridge, the destination endnode 
MAC is used to route in the last hop.
Regarding registration, at the same time  the DR registers the 
requesting ennode at the ARP server, the DR gets also registered, 
associated to endnode.
There are other alternatives, like the DRs issuing encapsulated ARPs 
that the DR would respond with its MAC and the endnode MACs.  Although 
both alternatives can be seen as optimizations, the decision to separate 
or not endnode-DR association information from link state information is 
important. This separation provides also flexibility for implementation 
and evolution. This might be beneficial in wireless environments, where 
broadcasting a long list of hosts may be an important overhead.

Regards
Guillermo
*Radia Perlman* Radia.Perlman at Sun.COM 
<mailto:rbridge%40postel.org?Subject=%5Brbridge%5D%20VLANs&In-Reply-To=1509658726.20050304210311%40psg.com>
/Wed Mar 9 07:59:43 PST 2005/

    * Previous message: [rbridge] End station discovery/liveness
      detection
      <http://www.postel.org/pipermail/rbridge/2005-March/000237.html>
    * Next message: [rbridge] VLANs
      <http://www.postel.org/pipermail/rbridge/2005-March/000245.html>
    * *Messages sorted by:* [ date ]
      <http://www.postel.org/pipermail/rbridge/2005-March/date.html#238>
      [ thread ]
      <http://www.postel.org/pipermail/rbridge/2005-March/thread.html#238>
      [ subject ]
      <http://www.postel.org/pipermail/rbridge/2005-March/subject.html#238>
      [ author ]
      <http://www.postel.org/pipermail/rbridge/2005-March/author.html#238>

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

There are various ways that we can optimize for VLANs, and as usual, the 
choices are
a continuum of tradeoffs between optimality of memory, bandwidth, 
complexity, etc.

One thing we should do is have RBridges announce which VLANs they are 
supporting
for endnodes. This would have to be configured, which I believe it is 
done for bridges.

So each RBridge knows, for each of its links, which VLANs are allowed on 
that link.
It announces this information in its link state information.

Now all RBridges know which RBridges are attached to which VLANs.

This now allows confining the broadcast domains. Unknown destinations or 
ARP/ND
queries only need to be sent to Designated RBridges attached to the VLAN 
in which
the packet originated. Depending on the amount of traffic which is 
unicast vs
needing to be flooded (within the VLAN), there is a range of choices of 
how to get
a packet to all the nodes within the VLAN. These are the same choices as 
for multicast,
which I summarized in an earlier message, but basically it's
a) send through a spanning tree to all RBridges, and DRs only flood onto 
their LAN
to endnodes if the packet is for the right VLAN (if we did this we 
wouldn't even
need to announce in link state packets which VLANs RBridge supported)
b) send through the same single spanning tree to all RBridges, but an 
RBridge looks
downstream, and stops forwarding if there are no RBridges supporting 
that VLAN further down
c) compute per-source-RBridge trees, and when RBridge R floods a packet 
for VLAN A,
the flooding will be done based on the tree rooted at R, and pruning 
will also be done,
as per point b.

Now for known endnodes:
Especially since someone told me that people want the capability to have 
overlapping
MAC address spaces among VLANs (the node with MAC address "m" in VLAN A
might be totally different from the node "m" in VLAN B), RBridges, in 
their link
state information, should tag what VLAN "m" belongs to.

Given that R knows what VLANs MAC addresses belong to, if R does not support
VLAN B, then there is no reason for R to put MAC addresses for B in its
forwarding table. But if the endnode information is in the regular link 
state information
(assume that for now), then R will need to store it so R can participate 
in link state
flooding.

Now another optimization: Suppose you want to avoid making R know about any
endnodes except in VLANs that R supports.

Then we could do the distribution of endnode information separately from the
rest of the link state information (the "regular stuff" is the connectivity
of the network consisting of RBridges, and tagging which RBridges are in 
which
VLANs).

If R is in VLAN A, then R must inform all the other RBridges attached to 
VLAN A
of all of R's VLAN A attached endnodes. If there were enough VLAN A peers in
the campus, it would probably be simplest to just use the regular link state
flooding to distribute the information. However, if that isn't the case, 
then
the VLAN A RBridge peers could talk to each other across the cloud to 
separately
distribute their endnode information. For instance, it could be sent as
a VLAN A flood, which the core would know how to do (as per the beginning of
this note).

Now, if non-VLAN-A RBridges do not know about the MAC addresses in A,
that can't be what they base their forwarding decision on.

If RBridge is working over MPLS, this isn't a problem, since the MPLS
path leads to the egress RBridge.

If there were only pt-to-pt links (no shared media) we could have the
encapsulation header point to the egress RBridge.

But on shared media, what we can do, at a cost of only 6 additional
bytes, is to also put "egress RBridge ID" into the encapsulation header.

So before on Ethernets a packet being forwarded by RBridges looked like:

outer header: source=transmitting RBridge, dest=nexthop RBridge, protocol
type=to be defined
encapsulation header: TTL
original frame

But by making the encapsulation header include "destination RBridge",
and having the RBridges along the path forward based on that, then
they wouldn't need to be forwarding based on endnode MACs, only
RBridge MACs.

Radia







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 j4CKTF619338 for <[e-mail]>; Thu, 12 May 2005 13:29:15 -0700 (PDT)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 12 May 2005 13:29:08 -0700 (PDT)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 12 May 2005 13:29:08 -0700 (PDT)
Received: from [152.70.2.164] (Forwarded-For: [198.181.231.11]) by mail-srv.sfvic.sunlabs.com (mshttpd); Thu, 12 May 2005 16:29:07 -0400
Date: Thu, 12 May 2005 16:29:07 -0400
From: [e-mail]
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=iso-8859-1
Content-language: en
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-39-6-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 j4CKTF619338
Subject: Re: [rbridge] Max Network size / ARP servers
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 12 May 2005 20:30:03 -0000
Status: RO
Content-Length: 2453

And to underline what Joe said, yes, a good case can be made for the usefulness
of having multiple spanning trees (to minimize number of packet-hops for
the core to distribute packets within a single VLAN, or for optimized IP multicast, or
to avoid out of order delivery when switching between destination unknown and destination
known). It's easy to compute multiple spanning trees by
running a single link state instance (which gives enough information to calculate per-VLAN
spanning trees, or per-ingress Rbridge spanning trees. I'm not sure I would explain multiple
spanning trees as making this more scalable, but rather as optimizing multicast delivery.
The scaling improvement comes in when endnode location advertisement is confined to
the RBridges that support that VLAN.

Radia

----- Original Message -----
From: Joe Touch <[e-mail]>
Date: Thursday, May 12, 2005 4:00 pm
Subject: Re: [rbridge] Max Network size / ARP servers

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Guillermo Ib??ez wrote:
> ...
> >>>>>Some measurements on ARP load are available at:   
> >>>>>http://100x100network.org/papers/myers-hotnets2004.pdf
> >>>>>       
> >> 
> >>> Myers extrapolations in the paper are higher ( I do not know 
> his 
> >>> rationale) than mine.
> >> 
> >> There are also other economies of scale possible in an RBridge -
> >> broadcasts can be more efficient than in a spanning tree 
> because there
> >> can be multiple broadcast trees inside the RBridge campus.
> >> 
> > Sorry, I do not catch this argument. Multiple spanning trees are 
> not 
> > exclusive of Rbridges, any bridge can use them (with MSTP or 
> future 
> > simplifications or evolutions of it).
> 
> We already note the need to use multiple spanning trees in RBridge to
> match the way routing supports multiple paths, as well as for 
> differentVLANs.
> 
> I.e., the need for multiple spanning trees is already assumed in
> RBridges for other reasons. Agreed, it's not unique to RBridges, but
> it's already there at least.
> 
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFCg7XsE5f5cImnZrsRAnr/AJ982BN5t6UEnmiwNn8SfECIO0jhmACgiuao
> 01WJDByU8Funcu2FYoJBP+g=
> =eE69
> -----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 j4CK2i610849; Thu, 12 May 2005 13:02:50 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 12 May 2005 13:00:44 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <000001c5509e$c809d6b0$[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[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-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size / ARP servers
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 12 May 2005 20:04:31 -0000
Status: RO
Content-Length: 1274

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



Guillermo Ib??ez wrote:
...
>>>>>Some measurements on ARP load are available at:   
>>>>>http://100x100network.org/papers/myers-hotnets2004.pdf
>>>>>       
>> 
>>> Myers extrapolations in the paper are higher ( I do not know his 
>>> rationale) than mine.
>> 
>> There are also other economies of scale possible in an RBridge -
>> broadcasts can be more efficient than in a spanning tree because there
>> can be multiple broadcast trees inside the RBridge campus.
>> 
> Sorry, I do not catch this argument. Multiple spanning trees are not 
> exclusive of Rbridges, any bridge can use them (with MSTP or future 
> simplifications or evolutions of it).

We already note the need to use multiple spanning trees in RBridge to
match the way routing supports multiple paths, as well as for different
VLANs.

I.e., the need for multiple spanning trees is already assumed in
RBridges for other reasons. Agreed, it's not unique to RBridges, but
it's already there at least.

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

iD8DBQFCg7XsE5f5cImnZrsRAnr/AJ982BN5t6UEnmiwNn8SfECIO0jhmACgiuao
01WJDByU8Funcu2FYoJBP+g=
=eE69
-----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 j4CIBq604758 for <[e-mail]>; Thu, 12 May 2005 11:11:53 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7BFC65D89C for <[e-mail]>; Thu, 12 May 2005 20:11:46 +0200 (CEST)
Received: from [163.117.252.226] (vpn-252-226.uc3m.es [163.117.252.226]) by smtp01.uc3m.es (Postfix) with ESMTP id 3910A5D8AA for <[e-mail]>; Thu, 12 May 2005 20:11:45 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 12 May 2005 20:11:41 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge]  Control plane scalability
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 12 May 2005 18:13:22 -0000
Status: RO
Content-Length: 3757

  [rbridge] Control plane scalability

*
*Guillermo Ib??ez wrote:
Alex,
      I join this discussion a bit late..., but it looks still quite 
open and your main points look unanswered.
      I support the idea of  a "cloud of rbridges"  supporting a 
50.000-100.000  hosts  networks and 1000 VLANs.  I see this kind of 
"target" network for rbridges somewhere  in the middle between current 
enterprise networks and MANs. It makes little sense to design new 
devices for current network sizes.  One key difference of thowever is 
that there would be only one administrator/owner of the complete network 
and hosts.
      The topology  that I think might scale is to consider two levels: 
a core of rbridges strongly interconnected with multiple spanning trees, 
rooted (preferably, for optimum path) each tree at each edge rbridge. 
Every edge  rbridge acts also as the root of its own spanning tree 
network (second level) below. The path from host to host in this type of 
network may be optimum for traffic crossing the core (the dominant part 
of traffic in the current client-server model) if one of the edge 
bridges in the core path is the root.
      To progress on scalability discussion I would suggest first to 
agree on maximum network size to set a basis for scalability 
discussions. Once the size limit is set, it is easier to choose between 
multi-topology and multi-instance solutions.
*      *The contradiction and difficulty I see with handling VLANs is 
that VLANs may collide  a bit  with the selfconfiguration objective, 
unless VLAN assignment is fully automatic and VLAN to tree association 
is also automatic, as it is the case of VLAN tag (in the core) 
associated to MAC address of edge bridge, like in Global Open Ethernet 
[NEC, Iwata].
    
Guillermo
*
Alex Zinin* zinin at psg.com 
<mailto:rbridge%40postel.org?Subject=%5Brbridge%5D%20Control%20plane%20scalability&In-Reply-To=p06200714be4e9a4e4b59%40%5B10%5C.0%5C.0%5C.171%5D>
/Fri Mar 4 15:39:17 PST 2005/
------------------------------------------------------------------------

Margaret,

  Sounds like an interesting topic :)

-- 
Alex
http://www.psg.com/~zinin <http://www.psg.com/%7Ezinin>

Friday, March 4, 2005, 3:13:33 PM, Margaret Wasserman wrote:

>/ Hi Alex,
/
>>>/  Are you planning to build one massive device that would run all of the
/>>>/  bridging and routing for this 50,000 node network?
/>>/
/>>/Margaret, when building switched Ethernet networks today, folks don't build
/>>/different broadcast domains using separate sets of single-VLAN 
/>>/devices. Neither
/>>/they use a single massive device to connect all stations 50,000 as you suggest
/>>/above. They build VLANs using multi-VLAN switches connected by VLAN trunks.
/>>/Those VLANs are distributed location-wise, and switches in the core of the
/>>/network have visibility to most (if not all) VLANs through those trunks.
/
>/ Yes, I am somewhat aware of these deployments, but I don't understand why
/>/ this implies that the core switches would be rbridges and/or why they would be
/>/ part of most of the rbridge clouds.
/
>/ Maybe we can talk about this when we have a whiteboard handy?  I'm not
/>/ trying to score debating points here .  I think we're just thinking 
/>/ about this differently,
/>/ and I'd like to understand how you believe the topology will work as opposed
/>/ to how I think it will work.
/
>/ Margaret
/

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

    * Previous message: [rbridge] Control plane scalability
      <http://www.postel.org/pipermail/rbridge/2005-March/000234.html>
    * Next message: [rbridge] Need scribe and jabber scribe for
      tomorrows TRILL
      <http://www.postel.org/pipermail/rbridge/2005-March/000239.html>



Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j4CEc2620212 for <[e-mail]>; Thu, 12 May 2005 07:38:02 -0700 (PDT)
Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 12 May 2005 20:16:42 +0530
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.93,100,1114972200";  d="scan'208"; a="34362209:sNHT25473800"
Received: from codc-mira-1.cisco.com (IDENT:[e-mail] [192.122.173.20]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4CK6dKh002889; Thu, 12 May 2005 20:06:39 GMT
Received: from [10.77.202.135] ([10.77.202.135]) by codc-mira-1.cisco.com (MOS 3.4.6-GR) with ESMTP id AJW84787; Thu, 12 May 2005 20:07:49 +0530 (IST)
Message-ID: <[e-mail]>
Date: Thu, 12 May 2005 20:07:49 +0530
From: Ganesh CS <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], "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: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Existing issues in root bridge selection for LANs.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 12 May 2005 14:39:19 -0000
Status: RO
Content-Length: 2114

Hi Greg,
Greg Daley wrote:
[cut]

>>>I'm not sure if the RB as Root Bridge idea is always beneficial, but
>>>would it be worth looking into?
>>>      
>>>
>>I think so.
>>I think we also need to figure out how to get smooth failover when RB1 
>>fails and we want the designed bridge for the sub-topology to become 
>>RB2, and have the bridges quickly discard their learned information 
>>which points at the dead RB1.
>>Having the designated RB look like the root bridge to the rest of the 
>>bridges (or look like the shortest cost to the root bridge) is one way 
>>to make the failover smooth for the bridges.
>>But there might be other ways to accomplish this.
>>    
>>
>
>It's fairly simple, with the way that root bridge selection works
>in 802.1D, to just make the bridge ID preference higher
>(making it slightly less desirable) for the backup.
>  
>
Here are we talking about Rbridges running 802.1D as well on the edges 
connecting to 802.1D based bridges or Rbridges will not run 802.1D ?
In the former case, default bridge priority of Rbridges can be set to 
make them more preferred so that RB1 to RB2 bridge fail over is smooth.
In the latter case, a mechanism such as the one you have described is 
required. I have a question here. Assuming such a mechanism is in place 
then consider the following diag.

       R1        R2
       |         |
      RB3       RB4
       |         |
       |         |
     <cloud of bridges>
      |          |
     RB1        RB2
      |          |
      |          |
     R4         R3

Here RB1 and RB2 will be trying to make their neighbors as root. From 
the other end, RB3 and RB4 will also be involved in a similar effort. 
How do we detect/accomodate this case ?

Ganesh

>The minor trick is to allow explicit configuration of other bridges
>as root, where the automated root isn't going to be suitable (for
>example, the 'top' network). This reduces the administrative load to
>a single LAN though.
>
>Greg
>_______________________________________________
>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 j4C83H611125 for <[e-mail]>; Thu, 12 May 2005 01:03:18 -0700 (PDT)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id DD2C649F1C for <[e-mail]>; Thu, 12 May 2005 10:02:38 +0200 (CEST)
Received: from [163.117.252.226] (vpn-252-226.uc3m.es [163.117.252.226]) by smtp02.uc3m.es (Postfix) with ESMTP id 579F349CDF for <[e-mail]>; Thu, 12 May 2005 10:02:38 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 12 May 2005 10:02:38 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <000001c5509e$c809d6b0$[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[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-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size / ARP servers
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 12 May 2005 08:03:46 -0000
Status: RO
Content-Length: 2792

Guillermo Ib??ez wrote:

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Guillermo Ib??ez wrote:
>...
>  
>
>> would consider big  a network (single broadcast domain) with  25.000
>>-100.000 hosts. But this could fall short.
>>As stated in the paper,  the ARP cache policy in hosts (Windows) is as 
>>follows:  unused entries in last two minutes expire, the refreshed ones 
>>are allowed a maximum of 10 minutes, then a new  ARP request will be 
>>sent. Measurements, (see below at the end of mail) are based on the 
>>current caching at endhosts, so the caching effect  is already included. 
>>Regarding snooping, I agree that snooping of broadcast responses at 
>>proxy-ARPs will reduce the load.
>>    
>>
>
>We agree that this is a problem for a sufficiently large network. As
>I've already noted, there are two things RBridges are not uniquely
>trying to solve:
>	a) increased size of L2 subnets
>	b) insecurity of ARP
>
>Solutions to either should work fine in an RBridge scenario, but are not
>part of the prerequisites of the RBridge architecture.
>
>Although an RBridge may encourage large subnets - larger than are
>currently typical - so do large L2 switches. There are solutions in that
>space to reduce broadcasts (IGMP snooping, proxy ARP, etc.) that might
>apply just fine here, but aren't worth (IMO) mentioning explicitly.
>
>  
>
Agreed, no explicit recommendation of any procedure to reduce broadcasts.

>As you noted, there are plenty of challenges with proxy ARP - hashing,
>load balancing, fault tolerance, etc. But all those solutions will
>benefit all L2 subnet systems, and are not specific to RBridges.
>
>...
>  
>
>>>>Some measurements on ARP load are available at:   
>>>>http://100x100network.org/papers/myers-hotnets2004.pdf
>>>>        
>>>>
Myers extrapolations in the paper are higher ( I do not know his 
rationale) than mine.

>There are also other economies of scale possible in an RBridge -
>broadcasts can be more efficient than in a spanning tree because there
>can be multiple broadcast trees inside the RBridge campus.
>
>  
>
Sorry, I do not catch this argument. Multiple spanning trees are not 
exclusive of Rbridges, any bridge can use them (with MSTP or future 
simplifications or evolutions of it).

>Overall, as said before, I don't think this is an issue specific to
>RBridges. Does anyone else??
>  
>
>Joe
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFCgorBE5f5cImnZrsRAkaUAKDZQjpYaUGIpK/MvUJ3JSTTKkRwZACffAy3
>+PD5qUt+CspyFRTAjks1XVg=
>=ciB6
>-----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 j4BMkI603442; Wed, 11 May 2005 15:46:18 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 11 May 2005 15:44:17 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <000001c5509e$c809d6b0$[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[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-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size / ARP servers
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 11 May 2005 22:47:18 -0000
Status: RO
Content-Length: 2733

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



Guillermo Ib??ez wrote:
...
>  would consider big  a network (single broadcast domain) with  25.000
> -100.000 hosts. But this could fall short.
> As stated in the paper,  the ARP cache policy in hosts (Windows) is as 
> follows:  unused entries in last two minutes expire, the refreshed ones 
> are allowed a maximum of 10 minutes, then a new  ARP request will be 
> sent. Measurements, (see below at the end of mail) are based on the 
> current caching at endhosts, so the caching effect  is already included. 
> Regarding snooping, I agree that snooping of broadcast responses at 
> proxy-ARPs will reduce the load.

We agree that this is a problem for a sufficiently large network. As
I've already noted, there are two things RBridges are not uniquely
trying to solve:
	a) increased size of L2 subnets
	b) insecurity of ARP

Solutions to either should work fine in an RBridge scenario, but are not
part of the prerequisites of the RBridge architecture.

Although an RBridge may encourage large subnets - larger than are
currently typical - so do large L2 switches. There are solutions in that
space to reduce broadcasts (IGMP snooping, proxy ARP, etc.) that might
apply just fine here, but aren't worth (IMO) mentioning explicitly.

As you noted, there are plenty of challenges with proxy ARP - hashing,
load balancing, fault tolerance, etc. But all those solutions will
benefit all L2 subnet systems, and are not specific to RBridges.

...
>>>Some measurements on ARP load are available at:   
>>>http://100x100network.org/papers/myers-hotnets2004.pdf
...
> I did not refer to this paper to support the solution proposed, but only 
> as reference for the ARP measurements provided. Results were:  89 ARPs 
> per second on average in a 2.456 hosts network, with peak load of 1150 
> ARPs/second. For a network with 25.000 hosts (ten times size), this 
> means  900 ARPs /second on average and 11.500 ARPs packets (peak) to 
> process on every  host.

Just because there are 10x as many hosts doesn't mean there will be 10x
as many ARPs, notably because there won't typically be 10x as many
routers to the rest of the Internet.

There are also other economies of scale possible in an RBridge -
broadcasts can be more efficient than in a spanning tree because there
can be multiple broadcast trees inside the RBridge campus.

Overall, as said before, I don't think this is an issue specific to
RBridges. Does anyone else??

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

iD8DBQFCgorBE5f5cImnZrsRAkaUAKDZQjpYaUGIpK/MvUJ3JSTTKkRwZACffAy3
+PD5qUt+CspyFRTAjks1XVg=
=ciB6
-----END PGP SIGNATURE-----


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 j4BDbE609259 for <[e-mail]>; Wed, 11 May 2005 06:37:15 -0700 (PDT)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 329E14A4FA for <[e-mail]>; Wed, 11 May 2005 15:37:08 +0200 (CEST)
Received: from [163.117.139.216] (gibanez.it.uc3m.es [163.117.139.216]) by smtp02.uc3m.es (Postfix) with ESMTP id 1E74D4A575 for <[e-mail]>; Wed, 11 May 2005 15:37:08 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 11 May 2005 15:37:08 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <000001c5509e$c809d6b0$[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[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-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size / ARP servers
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 11 May 2005 13:37:33 -0000
Status: RO
Content-Length: 4924

Guillermo Iba?ez wrote:

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Guillermo Ib??ez wrote:
>...
>  
>
>>We must be aware of the high cost of ARP processing cost in hosts of a 
>>big network under the basic broadcast ARP approach.
>>    
>>
>
>It's a question of what BIG means. First, broadcast is the backup
>anyway. Second, caching at endhosts and snooping of broadcast responses
>reduces request load.
>  
>
I would consider big  a network (single broadcast domain) with  25.000 
-100.000 hosts. But this could fall short.
As stated in the paper,  the ARP cache policy in hosts (Windows) is as 
follows:  unused entries in last two minutes expire, the refreshed ones 
are allowed a maximum of 10 minutes, then a new  ARP request will be 
sent. Measurements, (see below at the end of mail) are based on the 
current caching at endhosts, so the caching effect  is already included. 
Regarding snooping, I agree that snooping of broadcast responses at 
proxy-ARPs will reduce the load.

>Finally, I may be in the minority here, but this has nothing to do with
>RBridge. I don't see the primary benefit of RBridge to support scaling
>to millions of nodes on an L2 net, nor do I see it as an opportunity to
>rewrite how ARP is implemented.
>
>Knwon optimizations can always be applied, but the core of its operation
>in this regard is to support conventional broadcast services. ARP is no
>different than any other broadcast service in that regard.
>  
>
Conventional broadcast services must be supported. The difference of ARP 
vs other broadcast services I see is the load imposed to hosts in big 
networks.

>...
>  
>
>>ARP servers can support replication. The point is whether it is an
>>objective to improve ARP security or the current situation is acceptable 
>>in the foreseable big networks.
>>    
>>
>
>RBridges are designed to replace bridges to improve routing, not to
>improve ARP security - the latter of which needs its own solution. Given
>that solution, it can certainly be supported in an RBridge, but I don't
>see why we would consider RBridges to uniqely enable or require it.
>
>  
>
I agree ARP is a side  issue for Rbridges, but as Rbridges usage may 
increase sharply the broadcast domain size, they are indirectly the 
cause of the load to hosts, so it can not be ignored.

>...
>  
>
>>>>What does the ARP server do with a request of the destination if it
>>>>hasn't seen any communication from that host before?
>>>>        
>>>>
>>Flooding, of course. Flooding is unavoidable at the end, but must be
>>kept to a minimum for big networks to not use up hosts processing power.
>>    
>>
>...
>  
>
>>>>What I would like to see is a comparison between  the cach?s 
>>>>(distributed server/register) approach  with the current ARP proxy 
>>>>approach considering all aspects: engineering, security, broadcast 
>>>>volume, etc
>>>>        
>>>>
>>>See LANE and other NBMA literature. There are benefits, but there are
>>>also substantial robustness issues. Note that we can do NOTHING to avoid
>>>flooding when speaking to systems that haven't spoken yet - we won't
>>>find them at all unless the ARP emerges at the right egress link (L2
>>>network), and there's no way to know a-priori which one that will be.
>>>
>>>      
>>>
>>I will look at it, but I do not think it is the same thing.
>>    
>>
>
>Both use the same solution to avoiding broadcast - a centralized ARP server.
>
>  
>
Not exactly one centralized server. There would be  multiple servers 
with distributed load (by IP hashing), each of partial servers may  have 
replication. An specific protocol  would be required for it. We can 
think also on Distributed Hash Tables but performance does not seem 
adequate.

>>>Some measurements on ARP load are available at:   
>>>http://100x100network.org/papers/myers-hotnets2004.pdf
>>>      
>>>
>
>That paper has some interesting positions, but that would be open
>research. When a solution has been developed and tested, it might be
>considered for standardization. Since this is not an IRTF effort,
>though, that would be future work, IMO.
>
>Joe
>  
>
I did not refer to this paper to support the solution proposed, but only 
as reference for the ARP measurements provided. Results were:  89 ARPs 
per second on average in a 2.456 hosts network, with peak load of 1150 
ARPs/second. For a network with 25.000 hosts (ten times size), this 
means  900 ARPs /second on average and 11.500 ARPs packets (peak) to 
process on every  host.

Guillermo

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



Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j4B0I0608424 for <[e-mail]>; Tue, 10 May 2005 17:18:01 -0700 (PDT)
Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 11 May 2005 09:17:54 +0900 (KST)
Received: from Alperyegin ([105.144.29.41]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 11 May 2005 09:17:53 +0900 (KST)
Date: Tue, 10 May 2005 17:17:11 -0700
From: Alper Yegin <[e-mail]>
In-reply-to: <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Message-id: <00e201c555be$c8c15db0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size / ARP servers
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 11 May 2005 00:18:27 -0000
Status: RO
Content-Length: 601

> RBridges are designed to replace bridges to improve routing, not to
> improve ARP security - the latter of which needs its own solution.
Given
> that solution, it can certainly be supported in an RBridge, but I
don't
> see why we would consider RBridges to uniqely enable or require it.

I agree. Use of an ARP server may be an additional optimization which
can be built on top of Rbridged network, much like other types of
networks. But I think we can and shall keep this separate unless there
is some specific Rbridge feature that requires presence of ARP servers
(which I can't see....)

Alper




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 j4AIpw626905; Tue, 10 May 2005 11:51:58 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 10 May 2005 11:49:56 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <000001c5509e$c809d6b0$[e-mail]>	<[e-mail]>	<[e-mail]>	<[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-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size / ARP servers
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 10 May 2005 18:53:30 -0000
Status: RO
Content-Length: 2919

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



Guillermo Ib??ez wrote:
...
> We must be aware of the high cost of ARP processing cost in hosts of a 
> big network under the basic broadcast ARP approach.

It's a question of what BIG means. First, broadcast is the backup
anyway. Second, caching at endhosts and snooping of broadcast responses
reduces request load.

Finally, I may be in the minority here, but this has nothing to do with
RBridge. I don't see the primary benefit of RBridge to support scaling
to millions of nodes on an L2 net, nor do I see it as an opportunity to
rewrite how ARP is implemented.

Knwon optimizations can always be applied, but the core of its operation
in this regard is to support conventional broadcast services. ARP is no
different than any other broadcast service in that regard.

...
> ARP servers can support replication. The point is whether it is an
> objective to improve ARP security or the current situation is acceptable 
> in the foreseable big networks.

RBridges are designed to replace bridges to improve routing, not to
improve ARP security - the latter of which needs its own solution. Given
that solution, it can certainly be supported in an RBridge, but I don't
see why we would consider RBridges to uniqely enable or require it.

...
>>>What does the ARP server do with a request of the destination if it
>>>hasn't seen any communication from that host before?
>
> Flooding, of course. Flooding is unavoidable at the end, but must be
> kept to a minimum for big networks to not use up hosts processing power.
...
>>>What I would like to see is a comparison between  the cach?s 
>>>(distributed server/register) approach  with the current ARP proxy 
>>>approach considering all aspects: engineering, security, broadcast 
>>>volume, etc
>> 
>> See LANE and other NBMA literature. There are benefits, but there are
>> also substantial robustness issues. Note that we can do NOTHING to avoid
>> flooding when speaking to systems that haven't spoken yet - we won't
>> find them at all unless the ARP emerges at the right egress link (L2
>> network), and there's no way to know a-priori which one that will be.
>> 
> I will look at it, but I do not think it is the same thing.

Both use the same solution to avoiding broadcast - a centralized ARP server.

>> Some measurements on ARP load are available at:   
>> http://100x100network.org/papers/myers-hotnets2004.pdf

That paper has some interesting positions, but that would be open
research. When a solution has been developed and tested, it might be
considered for standardization. Since this is not an IRTF effort,
though, that would be future work, IMO.

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

iD8DBQFCgQJUE5f5cImnZrsRAnCTAKD5v0cnZuarZZrNnn673nsNYQzZzACcCMz1
nDUUaT/jinVhlwJxYltXwq4=
=G783
-----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 j4A8ne615254 for <[e-mail]>; Tue, 10 May 2005 01:49:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id B75B04937F for <[e-mail]>; Tue, 10 May 2005 10:49:34 +0200 (CEST)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp03.uc3m.es (Postfix) with ESMTP id 645EC49338; Tue, 10 May 2005 10:49:26 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 10 May 2005 10:49:27 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <000001c5509e$c809d6b0$[e-mail]>	<[e-mail]>	<[e-mail]>	<[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-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size / ARP servers
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 10 May 2005 08:50:51 -0000
Status: RO
Content-Length: 6287

Guillermo Ib??ez wrote:

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Guillermo Ib??ez wrote:
>  
>
>>>>>>I wonder if an ARP server/registrar approach can be foreseen as an 
>>>>>>alternative or complementary strategy.  The Designated Rbridge registers 
>>>>>>each host, when an ARP is received, at a (distributed) ARP server.
>>>>>>            
>>>>>>
>>>>>When an ARP reply is received, that can be done. But the first ARP to an
>>>>>otherwise unknown host, which has silently attached to a stub at an
>>>>>RBridge ingress, is unknown. The only way to find it is to flood.
>>>>>          
>>>>>
>>>>True. But this is the only case.
>>>>        
>>>>
>>>The problem is that it's the defining case. All others can, as you
>>>observe, be optimized with a variety of engineering solutions. IMO, none
>>>are all that interesting - ARP already caches at the endhost anyway.
>>>      
>>>
>>Yes.  But till then you avoid in many cases to do flood.
>>    
>>
>
>I'm not convinced about the "many" part; as I mentioned, the endsystems
>cache. There are also snooping issues - ARP replies, if broadcast, can
>preload these caches. By looking for ways to avoid flooding, we avoid
>some of the optimizations already designed into ARP.
>
>  
>

>That said, this is where a good study would help; it's premature to do
>anything except provide basic functionality (broadcast ARP) and mention
>that optimizations MAY be useful, IMO.
>
>  
>
We must be aware of the high cost of ARP processing cost in hosts of a 
big network under the basic broadcast ARP approach.

>>>>>>This 
>>>>>>can help to enforce security (like preventing MAC spoofing) and  also 
>>>>>>ensure ARP resolution in one step without broadcast. 
>>>>>>            
>>>>>>
>>>>>Correct the above if not correct, but assuming that there is no way to
>>>>>secure ARP that doesn't modify ARP too.
>>>>>          
>>>>>
>>>>ARP query would be performed by the Designated Router (encapsulated 
>>>>query directed to the ARP server).
>>>>        
>>>>
>>>The ARPs are originated outside the campus; the two options are to
>>>encapsulate the ARP and broadcast it or to encapsulate it and send it to
>>>an internal cache (the ARP server). Neither is secure, since they are
>>>triggered by external, unauthenticated ARPs.
>>>
>>>      
>>>
>>I do not understand this "outside" origination of ARPs.  My 
>>understanding is that ARPs are sent by local hosts or routers.
>>    
>>
>
>I've been speaking of ARPs as originating outside the RBridge, from
>hosts connected to egress RBridges. Those ARPs are not performed by the
>Designated Router; they just arrive at the egress.
>
>The discussion of Designated Routers in the I-D is an optimization; I've
>been speaking of the base case. Base case ARPs cannot be authenticated.
>
>>>>I am not expert, but I guess the 
>>>>server can autenticate the DRs.
>>>>        
>>>>
>>>Sure - but that only authenticates the internal cache; there's no way to
>>>authenticate the initial broadcast whose reply is used to populate the
>>>cache.
>>> 
>>>      
>>>
>>But the cach?, as a centralized point, can detect duplicated addresses 
>>and other abnormal behaviour....
>>    
>>
>
>Sure - but at what cost? Central point of failure? That's not an
>acceptable trade-off, especially to enforce ARP properties that are
>generally not enforced on conventional Ethernet LANs.
>
>...
>  
>
ARP servers can support replication. The point is whether it is an 
objective to improve ARP security or the current situation is acceptable 
in the foreseable big networks.

>>>>An ARP cache query from host would produce from DR two 
>>>>packets : a registration of originating host at ARP registrar and an ARP 
>>>>query of destination host at ARP server. 
>>>>        
>>>>
>>>What does the ARP server do with a request of the destination if it
>>>hasn't seen any communication from that host before?
>>>
>>>      
>>>
>>Flooding, of course. Flooding is unavoidable at the end, but must be 
>>kept to a minimum for big networks to not use up hosts processing power.
>>    
>>
>
>Agreed. But L2 semantics include flooding; ARP isn't the only use of
>broadcast.
>  
>
Rigth. But I do not think much flooding will be received by hosts due to 
unknown host destination. The host response triggers the MAC learning.

>  
>
>>We can think of new mechanisms for cach?s (ARP servers), as they 
>>implement a centralized function for a set of IP addresses, to track 
>>hosts mobility.
>>    
>>
>
>What you're proposing is to turn an RBridge into an NBMA (non-broadcast,
>multiaccess network), and to push ARP into a server, ala ATM LAN
>Emulation (LANE). I see that as a step backwards, esp. because, as noted
>above, ARP isn't the only use of broadcast.
>
>  
>
May be I am misunderstood. I do not exclude broadcast, only broadcast 
for ARP.

>>What I would like to see is a comparison between  the cach?s 
>>(distributed server/register) approach  with the current ARP proxy 
>>approach considering all aspects: engineering, security, broadcast 
>>volume, etc
>>    
>>
>
>See LANE and other NBMA literature. There are benefits, but there are
>also substantial robustness issues. Note that we can do NOTHING to avoid
>flooding when speaking to systems that haven't spoken yet - we won't
>find them at all unless the ARP emerges at the right egress link (L2
>network), and there's no way to know a-priori which one that will be.
>
>  
>
I will look at it, but I do not think it is the same thing.

>If we include a cache, we run the risk of having the cache semantics of
>the endsystem collide with that of the network cache. Overall, I'd say
>let's build an RBridge with broadcast and let's show that the load is a
>big enough problem to deal with it first.
>  
>
Some measurements on ARP load are available at:   
http://100x100network.org/papers/myers-hotnets2004.pdf
Guillermo

>Joe
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFCf+R+E5f5cImnZrsRAspuAKDsoKdE7mjnWVafIlgtfda2JXdLfwCgoHcn
>oYZ1MjPaGdRLSmKtUQnlm/U=
>=d26+
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>




Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j4A4Ov606362 for <[e-mail]>; Mon, 9 May 2005 21:24:58 -0700 (PDT)
Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <[e-mail]> for [e-mail]; Tue, 10 May 2005 14:22:09 +1000
Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EFB61AB547; Tue, 10 May 2005 14:22:08 +1000 (EST)
Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id C23004FB0B; Tue, 10 May 2005 14:22:08 +1000 (EST)
Date: Tue, 10 May 2005 14:22:06 +1000
From: Greg Daley <[e-mail]>
In-reply-to: <[e-mail]>
To: Erik Nordmark <[e-mail]>
Message-id: <[e-mail]>
Organization: Monash University
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en, en-us
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Existing issues in root bridge selection for LANs.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
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: Tue, 10 May 2005 04:25:50 -0000
Status: RO
Content-Length: 3295

Hi Erik,


Erik Nordmark wrote:
[cut]
>> Your diagram is a useful one, since it illustrates non-Trill capable
>> routers in the network.
> 
> 
> Yes, but my figure, repeated below, might not be that representative for 
> a real network:
>  >>     <rest of LAN up here>
>  >>      |                |
>  >>     RB1              RB2
>  >>      |                |
>  >>      -------------------
>  >>      |    |      |
>  >>     H1    H2     R1
> 
> I real enterprise LAN of reasonable size is probably going to have some 
> edge switches connecting to hosts, and a layer of distribution switches, 
> which connect to the routers. So a more natural picture would be with 
> the routers on "top", perhaps connected to the RBs without any 
> intervening bridges:
> 
>       R1        R2
>        |         |
>       RB3       RB4
>        | \     /  |
>        |  \   /   |
>      <rest of LAN up here, with additional "leafs" like the one below
>      attached to it>
>       |                |
>      RB1              RB2
>       |                |
>       -------------------
>       |    |
>      H1    H2
> 
>> In those situations the Internet Router is likely to be the best
>> root bridge of all, and its adjacent bridge is likely to not be a Trill
>> device, and is not likely to be able to automatically configure.
> 
> 
> But if the toplogy is more like the picture above, then there is no 
> issue with a 802.1D spanning tree between R1 and RB3 etc.
> You'd still have a bridge spanning tree for the ("----") bridged 
> sub-topology at the bottom, but for that one getting the root close/at 
> the RB is good enough.

Even if the lower topology is more complex (distribution switches,
redundant paths), the spanning tree rooted at the active Rbridge
is optimal for a stub LAN.

In fact, the more (simple) cycles in the bridges, the better the
performance is compared to other roots.

[cut]
> 
> 
> I'm still failing to draw the topology from your description. Sorry.
> (Perhaps you can glue me in off-line.)

I guess there's no rush yet.

I was just saying that negotiation can be explicit on the legacy LAN
(like OSPF Designated Router negotiation) or through voodoo which
doesn't exchange signaling on the legacy LAN (but uses rbridge
link-state knowledge).

>> I'm not sure if the RB as Root Bridge idea is always beneficial, but
>> would it be worth looking into?
> 
> 
> I think so.
> I think we also need to figure out how to get smooth failover when RB1 
> fails and we want the designed bridge for the sub-topology to become 
> RB2, and have the bridges quickly discard their learned information 
> which points at the dead RB1.
> Having the designated RB look like the root bridge to the rest of the 
> bridges (or look like the shortest cost to the root bridge) is one way 
> to make the failover smooth for the bridges.
> But there might be other ways to accomplish this.

It's fairly simple, with the way that root bridge selection works
in 802.1D, to just make the bridge ID preference higher
(making it slightly less desirable) for the backup.

The minor trick is to allow explicit configuration of other bridges
as root, where the automated root isn't going to be suitable (for
example, the 'top' network). This reduces the administrative load to
a single LAN though.

Greg


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 j49MVO601919; Mon, 9 May 2005 15:31:24 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 09 May 2005 15:30:22 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <000001c5509e$c809d6b0$[e-mail]>	<[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-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 09 May 2005 22:32:27 -0000
Status: RO
Content-Length: 5010

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



Guillermo Ib??ez wrote:
>>>>>I wonder if an ARP server/registrar approach can be foreseen as an 
>>>>>alternative or complementary strategy.  The Designated Rbridge registers 
>>>>>each host, when an ARP is received, at a (distributed) ARP server.
>> 
>>>>When an ARP reply is received, that can be done. But the first ARP to an
>>>>otherwise unknown host, which has silently attached to a stub at an
>>>>RBridge ingress, is unknown. The only way to find it is to flood.
>> 
>>>True. But this is the only case.
>> 
>> The problem is that it's the defining case. All others can, as you
>> observe, be optimized with a variety of engineering solutions. IMO, none
>> are all that interesting - ARP already caches at the endhost anyway.
> 
> Yes.  But till then you avoid in many cases to do flood.

I'm not convinced about the "many" part; as I mentioned, the endsystems
cache. There are also snooping issues - ARP replies, if broadcast, can
preload these caches. By looking for ways to avoid flooding, we avoid
some of the optimizations already designed into ARP.

That said, this is where a good study would help; it's premature to do
anything except provide basic functionality (broadcast ARP) and mention
that optimizations MAY be useful, IMO.

>>>>>This 
>>>>>can help to enforce security (like preventing MAC spoofing) and  also 
>>>>>ensure ARP resolution in one step without broadcast. 
>> 
>>>>Correct the above if not correct, but assuming that there is no way to
>>>>secure ARP that doesn't modify ARP too.
>> 
>>>ARP query would be performed by the Designated Router (encapsulated 
>>>query directed to the ARP server).
>> 
>> The ARPs are originated outside the campus; the two options are to
>> encapsulate the ARP and broadcast it or to encapsulate it and send it to
>> an internal cache (the ARP server). Neither is secure, since they are
>> triggered by external, unauthenticated ARPs.
>> 
> I do not understand this "outside" origination of ARPs.  My 
> understanding is that ARPs are sent by local hosts or routers.

I've been speaking of ARPs as originating outside the RBridge, from
hosts connected to egress RBridges. Those ARPs are not performed by the
Designated Router; they just arrive at the egress.

The discussion of Designated Routers in the I-D is an optimization; I've
been speaking of the base case. Base case ARPs cannot be authenticated.

>>>I am not expert, but I guess the 
>>>server can autenticate the DRs.
>> 
>> Sure - but that only authenticates the internal cache; there's no way to
>> authenticate the initial broadcast whose reply is used to populate the
>> cache.
>>  
> But the cach?, as a centralized point, can detect duplicated addresses 
> and other abnormal behaviour....

Sure - but at what cost? Central point of failure? That's not an
acceptable trade-off, especially to enforce ARP properties that are
generally not enforced on conventional Ethernet LANs.

...
>>>An ARP cache query from host would produce from DR two 
>>>packets : a registration of originating host at ARP registrar and an ARP 
>>>query of destination host at ARP server. 
>> 
>> What does the ARP server do with a request of the destination if it
>> hasn't seen any communication from that host before?
>> 
> Flooding, of course. Flooding is unavoidable at the end, but must be 
> kept to a minimum for big networks to not use up hosts processing power.

Agreed. But L2 semantics include flooding; ARP isn't the only use of
broadcast.

> We can think of new mechanisms for cach?s (ARP servers), as they 
> implement a centralized function for a set of IP addresses, to track 
> hosts mobility.

What you're proposing is to turn an RBridge into an NBMA (non-broadcast,
multiaccess network), and to push ARP into a server, ala ATM LAN
Emulation (LANE). I see that as a step backwards, esp. because, as noted
above, ARP isn't the only use of broadcast.

> What I would like to see is a comparison between  the cach?s 
> (distributed server/register) approach  with the current ARP proxy 
> approach considering all aspects: engineering, security, broadcast 
> volume, etc

See LANE and other NBMA literature. There are benefits, but there are
also substantial robustness issues. Note that we can do NOTHING to avoid
flooding when speaking to systems that haven't spoken yet - we won't
find them at all unless the ARP emerges at the right egress link (L2
network), and there's no way to know a-priori which one that will be.

If we include a cache, we run the risk of having the cache semantics of
the endsystem collide with that of the network cache. Overall, I'd say
let's build an RBridge with broadcast and let's show that the load is a
big enough problem to deal with it first.

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

iD8DBQFCf+R+E5f5cImnZrsRAspuAKDsoKdE7mjnWVafIlgtfda2JXdLfwCgoHcn
oYZ1MjPaGdRLSmKtUQnlm/U=
=d26+
-----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 j479KF618592 for <[e-mail]>; Sat, 7 May 2005 02:20:16 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6F9D75DA7D for <[e-mail]>; Sat,  7 May 2005 11:20:09 +0200 (CEST)
Received: from [163.117.252.248] (vpn-252-248.uc3m.es [163.117.252.248]) by smtp01.uc3m.es (Postfix) with ESMTP id 1E5615DAFA for <[e-mail]>; Sat,  7 May 2005 11:20:08 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Sat, 07 May 2005 11:20:08 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <000001c5509e$c809d6b0$[e-mail]>	<[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-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 07 May 2005 09:21:17 -0000
Status: RO
Content-Length: 4796

Guiillermo Iba?ez wrote:


Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Guillermo Ib??ez wrote:
>  
>
>>...
>>    
>>
>>>>I wonder if an ARP server/registrar approach can be foreseen as an 
>>>>alternative or complementary strategy.  The Designated Rbridge registers 
>>>>each host, when an ARP is received, at a (distributed) ARP server.
>>>>        
>>>>
>>>When an ARP reply is received, that can be done. But the first ARP to an
>>>otherwise unknown host, which has silently attached to a stub at an
>>>RBridge ingress, is unknown. The only way to find it is to flood.
>>>
>>>      
>>>
>>True. But this is the only case.
>>    
>>
>
>The problem is that it's the defining case. All others can, as you
>observe, be optimized with a variety of engineering solutions. IMO, none
>are all that interesting - ARP already caches at the endhost anyway.
>
>  
>
Yes.  But till then you avoid in many cases to do flood.

>>>>This 
>>>>can help to enforce security (like preventing MAC spoofing) and  also 
>>>>ensure ARP resolution in one step without broadcast. 
>>>>        
>>>>
>>>Correct the above if not correct, but assuming that there is no way to
>>>secure ARP that doesn't modify ARP too.
>>> 
>>>      
>>>
>>ARP query would be performed by the Designated Router (encapsulated 
>>query directed to the ARP server).
>>    
>>
>
>The ARPs are originated outside the campus; the two options are to
>encapsulate the ARP and broadcast it or to encapsulate it and send it to
>an internal cache (the ARP server). Neither is secure, since they are
>triggered by external, unauthenticated ARPs.
>
>  
>
I do not understand this "outside" origination of ARPs.  My 
understanding is that ARPs are sent by local hosts or routers.

>>I am not expert, but I guess the 
>>server can autenticate the DRs.
>>    
>>
>
>Sure - but that only authenticates the internal cache; there's no way to
>authenticate the initial broadcast whose reply is used to populate the
>cache.
>  
>
But the cach?, as a centralized point, can detect duplicated addresses 
and other abnormal behaviour....

>  
>
>>I agree that a host may spoof its MAC 
>>but security measures are possible both at the ARP server (the spoofed 
>>host is registered in same server) and at the DR (attacks and  behaviour 
>>will likely concentrate on a certain port of  DR) 
>>    
>>
>
>Why bother? As above, we already need to support broadcast ARP to
>bootstrap. Besides, securing the internal protocol complicates the
>deployment. There's little utility to securing the ARP cache
>communication this way, IMO, unless you've already secured internal
>control communication (e.g., routing) for other reasons.
>
>  
>
>>>>The point is to 
>>>>distribute the load of ARP registry and queries between multiple ARP 
>>>>servers. This may be based on IP hashing.
>>>>        
>>>>
>>>Sure, hashing will direct you to the right cache. But how does that
>>>cache know what to reply? It can't unless IT floods; that's the catch-22.
>>>
>>>      
>>>
>>The cach? knows the content because it is the unique both server and 
>>registrar for the IP addresses set. Prior to that query, upon first ARP 
>>issued  the host was registered by the DR at that cach?, based on its 
>>hash(IP). 
>>    
>>
>
>ARP may announce the location of the ARP sender, but doesn't announce
>the location of the ARP reply. Both need to be snooped to load the
>cache. The trouble is the first ARP _to_ any new IP address must always
>be broadcast; by definition, it won't be in the cache.
>
>  
>
>>An ARP cache query from host would produce from DR two 
>>packets : a registration of originating host at ARP registrar and an ARP 
>>query of destination host at ARP server. 
>>    
>>
>
>What does the ARP server do with a request of the destination if it
>hasn't seen any communication from that host before?
>  
>
Flooding, of course. Flooding is unavoidable at the end, but must be 
kept to a minimum for big networks to not use up hosts processing power.
We can think of new mechanisms for cach?s (ARP servers), as they 
implement a centralized function for a set of IP addresses, to track 
hosts mobility.
What I would like to see is a comparison between  the cach?s 
(distributed server/register) approach  with the current ARP proxy 
approach considering all aspects: engineering, security, broadcast 
volume, etc
Guillermo

>Joe.
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFCe57JE5f5cImnZrsRApfnAKCiYVfTjaHuLK4wnf+ckpsU8E0b5QCg+jLm
>BFwBjuirgR1GlaSbFy0044Q=
>=dWU9
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>



Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j46LQD612198 for <[e-mail]>; Fri, 6 May 2005 14:26:13 -0700 (PDT)
Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 07 May 2005 06:25:41 +0900 (KST)
Received: from Alperyegin ([105.144.29.41]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Sat, 07 May 2005 06:25:41 +0900 (KST)
Date: Fri, 06 May 2005 14:25:04 -0700
From: Alper Yegin <[e-mail]>
In-reply-to: <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Message-id: <067c01c55282$12dd5b50$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 06 May 2005 21:27:04 -0000
Status: RO
Content-Length: 1607

> > Even than the host needs to perform some tests to know it is still
> > connected to the same IP subnet. Like the reachability test outlined
in
> > http://ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-11.txt . The
> > test is using ARP....
> 
> It CAN use that test, but doesn't have to. There are devices that
don't
> bother to say anything until they have something to say, rather than
> just when an interface regains signal...
> 
> (which is why the DHC draft above isn't a requirement, but an
> optimization).

I don't expect all hosts to be implementing this draft overnite. So, I'm
not proposing to take this as the baseline "host behavior." In that
sense I agree with you. I just wanted to note that, for any reasonable
host that moves around and cares to establish reachability as fast as
possible, it is reasonable to expect them to do something. The
reachability test mentioned in that I-D is an example.

> >>Sure. But this is, in a lot of ways, just another version of an
> >>optimization. We definitely need to cover the case where the
> >>optimization isn't in place anyway...
> >
> >
> > I agree.....
> >
> > Let's not rely on presence of optimizations. Nevertheless let's
> > enumerate them, so that people don't think they are always stuck
with
> > the worst case scenario.
> 
> I'm not arguing against discussing optimizations at all; just that we
> need to implement the base case regardless. And to make sure the
> optimizations don't come with any downside (i.e., when they fail, they
> shouldn't interfere with what would have happened were they not
there).

I agree.

Alper





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 j46LDT609011 for <[e-mail]>; Fri, 6 May 2005 14:13:29 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.228.50]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j46LDSQ1010713;  Fri, 6 May 2005 14:13:28 -0700 (PDT)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j46LDQoM588143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 May 2005 14:13:27 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 06 May 2005 14:13:33 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [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-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Existing issues in root bridge selection for LANs.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 06 May 2005 21:14:19 -0000
Status: RO
Content-Length: 4327

Greg Daley wrote:


>> If you are assuming that the RSTP protocol terminates at the rbridges, 
>> then you end up with a sub-topology of the LAN with e.g.
>>
>>     <rest of LAN up here>
>>      |                |
>>     RB1              RB2
>>      |                |
>>      -------------------
>>      |    |      |
>>     H1    H2     R1
>>
>> Where the line is the middle is made up of bridges.
>> Thus the issue is where RSTP places the root bridge in this 
>> sub-topology of the whole LAN.


> My guess (still not checked generally) is that if more traffic is
> flowing into and out of one RBridge, then it will be the best place
> to have a root (for scalability and traffic dimensioning purposes).

That's probably the case.

> Your diagram is a useful one, since it illustrates non-Trill capable
> routers in the network.

Yes, but my figure, repeated below, might not be that representative for 
a real network:
 >>     <rest of LAN up here>
 >>      |                |
 >>     RB1              RB2
 >>      |                |
 >>      -------------------
 >>      |    |      |
 >>     H1    H2     R1

I real enterprise LAN of reasonable size is probably going to have some 
edge switches connecting to hosts, and a layer of distribution switches, 
which connect to the routers. So a more natural picture would be with 
the routers on "top", perhaps connected to the RBs without any 
intervening bridges:

       R1        R2
        |         |
       RB3       RB4
        | \     /  |
        |  \   /   |
      <rest of LAN up here, with additional "leafs" like the one below
      attached to it>
       |                |
      RB1              RB2
       |                |
       -------------------
       |    |
      H1    H2

> In those situations the Internet Router is likely to be the best
> root bridge of all, and its adjacent bridge is likely to not be a Trill
> device, and is not likely to be able to automatically configure.

But if the toplogy is more like the picture above, then there is no 
issue with a 802.1D spanning tree between R1 and RB3 etc.
You'd still have a bridge spanning tree for the ("----") bridged 
sub-topology at the bottom, but for that one getting the root close/at 
the RB is good enough.

> Here it's likely that the root bridge will have to be selected manually,
> although there may be a case for automatic root bridge selection on
> one of the Trill devices, over default preference devices if it is
> likely to be a big traffic generator.

There is still the option to do manual things, but it is worth while to 
think of what LAN topologies look like today, and whether TRILL can 
automatically come up with a reasonable thing for such topologies.
The topology between the RBridges is already handled by using the 
link-state routing protocol, and your suggestion to handle the "leaf" 
bridged sub-topologies by placing their root bridge at/close to the RB 
is a good one.

>>> Alternatively, if no routing protocol is explicitly used on the legacy
>>> LAN, routers within the trill cloud which know they are attached to the
>>> same legacy LAN can determine from their trill routing knowledge which
>>> is the best root.
> 
> I was thinking that if the trill devices are connected to the same trill
> cloud ("above" the RBs in the diagram), they could do the root
> preference election on the "above" side, based on link-state
> knowledge from the "below" LAN.
> 
> This was basically an off-the-cuff idea though.  It's probably better to
> run the lot on the "below" side to handle disjoint Trill domains
> connecting to the same legacy LAN.

I'm still failing to draw the topology from your description. Sorry.
(Perhaps you can glue me in off-line.)

> I'm not sure if the RB as Root Bridge idea is always beneficial, but
> would it be worth looking into?

I think so.
I think we also need to figure out how to get smooth failover when RB1 
fails and we want the designed bridge for the sub-topology to become 
RB2, and have the bridges quickly discard their learned information 
which points at the dead RB1.
Having the designated RB look like the root bridge to the rest of the 
bridges (or look like the shortest cost to the root bridge) is one way 
to make the failover smooth for the bridges.
But there might be other ways to accomplish this.

    Erik


Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j46L9i607668 for <[e-mail]>; Fri, 6 May 2005 14:09:44 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.226.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j46L9hi7013735 for <[e-mail]>; Fri, 6 May 2005 15:09:44 -0600 (MDT)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j46L9g4m587158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 May 2005 14:09:43 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 06 May 2005 14:09:49 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <061c01c55277$253eb6a0$[e-mail]>
In-Reply-To: <061c01c55277$253eb6a0$[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 06 May 2005 21:10:27 -0000
Status: RO
Content-Length: 867

Alper Yegin wrote:
>>only when you don't have config info. If you move ethernets within an
>>enterprise (i.e., within a campus deployment), you don't necessarily
>>contact DHCP when you move.
> 
> 
> Even than the host needs to perform some tests to know it is still
> connected to the same IP subnet. Like the reachability test outlined in
> http://ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-11.txt . The
> test is using ARP....

Yes, but many/most existing implementations do not perform such checks.
When I move my host from one Ethernet switch port to another, or 
associated with a different 802.11 AP, the stack silently assumes that 
this is the same IP subnet as before.
While we have a DNA WG and the above draft which tries to make this work 
better, I don't think TRILL should assume that such mechanisms are 
implemented in all the hosts.

    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 j46KOL613789; Fri, 6 May 2005 13:24:21 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 06 May 2005 13:26:27 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <061c01c55277$253eb6a0$[e-mail]>
In-Reply-To: <061c01c55277$253eb6a0$[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 06 May 2005 20:25:05 -0000
Status: RO
Content-Length: 1643

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



Alper Yegin wrote:
>>only when you don't have config info. If you move ethernets within an
>>enterprise (i.e., within a campus deployment), you don't necessarily
>>contact DHCP when you move.
> 
> 
> Even than the host needs to perform some tests to know it is still
> connected to the same IP subnet. Like the reachability test outlined in
> http://ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-11.txt . The
> test is using ARP....

It CAN use that test, but doesn't have to. There are devices that don't
bother to say anything until they have something to say, rather than
just when an interface regains signal...

(which is why the DHC draft above isn't a requirement, but an optimization).

>>Sure. But this is, in a lot of ways, just another version of an
>>optimization. We definitely need to cover the case where the
>>optimization isn't in place anyway...
> 
> 
> I agree.....
> 
> Let's not rely on presence of optimizations. Nevertheless let's
> enumerate them, so that people don't think they are always stuck with
> the worst case scenario.

I'm not arguing against discussing optimizations at all; just that we
need to implement the base case regardless. And to make sure the
optimizations don't come with any downside (i.e., when they fail, they
shouldn't interfere with what would have happened were they not there).

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

iD8DBQFCe9LzE5f5cImnZrsRAtMXAJ98S8NGHMu4lEdExldbH2kSG/5MOACfVCh1
qamtga+t5CzS0GLbiKF8e04=
=8CrL
-----END PGP SIGNATURE-----


Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j46K7c609199 for <[e-mail]>; Fri, 6 May 2005 13:07:38 -0700 (PDT)
Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 07 May 2005 05:07:27 +0900 (KST)
Received: from Alperyegin ([105.144.29.41]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <[e-mail]> for [e-mail]; Sat, 07 May 2005 05:07:27 +0900 (KST)
Date: Fri, 06 May 2005 13:06:51 -0700
From: Alper Yegin <[e-mail]>
In-reply-to: <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Message-id: <061c01c55277$253eb6a0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 06 May 2005 20:08:02 -0000
Status: RO
Content-Length: 760

> only when you don't have config info. If you move ethernets within an
> enterprise (i.e., within a campus deployment), you don't necessarily
> contact DHCP when you move.

Even than the host needs to perform some tests to know it is still
connected to the same IP subnet. Like the reachability test outlined in
http://ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-11.txt . The
test is using ARP....

 
> Sure. But this is, in a lot of ways, just another version of an
> optimization. We definitely need to cover the case where the
> optimization isn't in place anyway...

I agree.....

Let's not rely on presence of optimizations. Nevertheless let's
enumerate them, so that people don't think they are always stuck with
the worst case scenario.

Alper




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 j46Hxh628154; Fri, 6 May 2005 10:59:43 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 06 May 2005 11:01:49 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 06 May 2005 18:01:15 -0000
Status: RO
Content-Length: 6634

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



Gray, Eric wrote:
> 
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]]On
>>Behalf Of Joe Touch
>>Sent: Friday, May 06, 2005 12:44 PM
>>To: Developing a hybrid router/bridge.
>>Subject: Re: [rbridge] Max Network size
> 
> 
> [.. SNIP ..]
> 
> 
> 
>>Guillermo Ib??ez wrote:
>>
>>>...
>>>
>>>>> I wonder if an ARP server/registrar approach can be foreseen 
>>>>> as an alternative or complementary strategy. The Designated 
>>>>> Rbridge registers each host, when an ARP is received, at a
>>>>> (distributed) ARP server.
>>>> 
>>>> When an ARP reply is received, that can be done. But the first
>>>> ARP to an otherwise unknown host, which has silently attached
>>>> to a stub at an RBridge ingress, is unknown. The only way to
>>>> find it is to flood.
>>>
>>>True. But this is the only case.
>>
>>The problem is that it's the defining case. All others can, as you
>>observe, be optimized with a variety of engineering solutions. IMO, none
>>are all that interesting - ARP already caches at the endhost anyway.
> 
> I had a similar discussion with a colleague a few years back.
> Apparently, there are a growing number of networks where it's
> not necessary to flood packets.

Not IP over Ethernet. ;-)

> This is the case whenever an attaching host is required to do
> something active before it can go into a passive mode - such 
> as obtain IP address, default router, DNS server, etc. from a 
> DHCP server.

You can assert that sort of requirement for a deployment, but it's not
part of ethernet, IP, DHCP, or DNS. E.g., DHCP helps configure you, but
only when you don't have config info. If you move ethernets within an
enterprise (i.e., within a campus deployment), you don't necessarily
contact DHCP when you move.

> Given the prevalence of dynamic address configuration at this
> time, there are plenty of examples of networks where it is not
> possible for a host to "silently attach".

But they can silently move. And dynamic configuration is never a
requirement of any of these protocols; it may be the requirement of a
deployment. We don't want RBridge to be limited to those sorts of
deployments.

> While this creates interesting points of confusion since some
> people may have direct experience with networks like this that
> (ostensibly) work, the fact is that working with a network of
> this type presents special problems and is not ubiquitously
> possible as of yet.

Agreed...

>>>>>This 
>>>>>can help to enforce security (like preventing MAC spoofing) and  also 
>>>>>ensure ARP resolution in one step without broadcast. 
>>>>
>>>>Correct the above if not correct, but assuming that there is no way to
>>>>secure ARP that doesn't modify ARP too.
>>>> 
>>>
>>>ARP query would be performed by the Designated Router (encapsulated 
>>>query directed to the ARP server).
>>
>>The ARPs are originated outside the campus; the two options are to
>>encapsulate the ARP and broadcast it or to encapsulate it and send it to
>>an internal cache (the ARP server). Neither is secure, since they are
>>triggered by external, unauthenticated ARPs.
>>
>>
>>>I am not expert, but I guess the 
>>>server can autenticate the DRs.
>>
>>Sure - but that only authenticates the internal cache; there's no way to
>>authenticate the initial broadcast whose reply is used to populate the
>>cache.
>>
>>
>>>I agree that a host may spoof its MAC 
>>>but security measures are possible both at the ARP server (the spoofed 
>>>host is registered in same server) and at the DR (attacks and  behaviour
>>>will likely concentrate on a certain port of  DR) 
>>
>>Why bother? As above, we already need to support broadcast ARP to
>>bootstrap. Besides, securing the internal protocol complicates the
>>deployment. There's little utility to securing the ARP cache
>>communication this way, IMO, unless you've already secured internal
>>control communication (e.g., routing) for other reasons.
>>
>>
>>>>> The point is to distribute the load of ARP registry and
>>>>> queries between multiple ARP servers. This may be based on IP
>>>>> hashing.
>>>> 
>>>> Sure, hashing will direct you to the right cache. But how does
>>>> that cache know what to reply? It can't unless IT floods;
>>>> that's the catch-22.
>>>
>>>The cach? knows the content because it is the unique both server and 
>>>registrar for the IP addresses set. Prior to that query, upon first ARP 
>>>issued  the host was registered by the DR at that cach?, based on its 
>>>hash(IP). 
>>
>>ARP may announce the location of the ARP sender, but doesn't announce
>>the location of the ARP reply. Both need to be snooped to load the
>>cache. The trouble is the first ARP _to_ any new IP address must always
>>be broadcast; by definition, it won't be in the cache.
> 
> For the same reason, this is not always the case.  If it is likely
> that every host will know the IP (and MAC) address of a default
> router, all ARP traffic from that point on may be unicast directed 
> to the default router.

Only if it only talks to the router or IP addresses elsewhere; IP
addresses within the LAN won't be handled.

> This can be a big if, however, in some networks and should not be
> assumed.
> 
>>>An ARP cache query from host would produce from DR two 
>>>packets : a registration of originating host at ARP registrar and an ARP
>>>query of destination host at ARP server. 
>>
>>What does the ARP server do with a request of the destination if it
>>hasn't seen any communication from that host before?
> 
> It could respond exactly as it would if the host was not attached.
> This could be appropriate behavior in networks where silent host
> attachment is a non-starter anyway.

Yes - we could prohibit silent attachment and silent movement. How, in
that case, does the first communication ensue? You need to force
something outside the RBridge system (DHCP server, default router, etc.)
to do something it doesn't do now...

> The poster-child example is the typical small network with a single
> DHCP server that also happens to be the Internet attachment point,
> firewall, NAT and default router.  This is the increasingly common
> - but not (yet) universal - case.

Sure. But this is, in a lot of ways, just another version of an
optimization. We definitely need to cover the case where the
optimization isn't in place anyway...

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

iD8DBQFCe7ENE5f5cImnZrsRAlEqAJ4jS9SKWVumA04Jww7dEtiliX/piwCgrLF4
pMbithlRy+9xumBJbx2Tmtc=
=qG76
-----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 j46HWC620119 for <[e-mail]>; Fri, 6 May 2005 10:32:12 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j46HW3WW008548 for <[e-mail]>; Fri, 6 May 2005 13:32:07 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA25257 for <[e-mail]>; Fri, 6 May 2005 13:32:03 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <J70JY23A>; Fri, 6 May 2005 13:32:02 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Routing Bridges'" <[e-mail]>
Date: Fri, 6 May 2005 13:31:54 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-39-6-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 j46HWC620119
Subject: Re: [rbridge] Max Network size
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 06 May 2005 17:33:03 -0000
Status: RO
Content-Length: 5174

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Joe Touch
> Sent: Friday, May 06, 2005 12:44 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Max Network size

[.. SNIP ..]


> Guillermo Ib??ez wrote:
> > ...
> >>>I wonder if an ARP server/registrar approach can be foreseen as an 
> >>>alternative or complementary strategy.  The Designated Rbridge
registers 
> >>>each host, when an ARP is received, at a (distributed) ARP server.
> >> 
> >> When an ARP reply is received, that can be done. But the first ARP to
an
> >> otherwise unknown host, which has silently attached to a stub at an
> >> RBridge ingress, is unknown. The only way to find it is to flood.
> >> 
> > True. But this is the only case.
> 
> The problem is that it's the defining case. All others can, as you
> observe, be optimized with a variety of engineering solutions. IMO, none
> are all that interesting - ARP already caches at the endhost anyway.
> 

I had a similar discussion with a colleague a few years back.
Apparently, there are a growing number of networks where it's
not necessary to flood packets.

This is the case whenever an attaching host is required to do
something active before it can go into a passive mode - such 
as obtain IP address, default router, DNS server, etc. from a 
DHCP server.

Given the prevalence of dynamic address configuration at this
time, there are plenty of examples of networks where it is not
possible for a host to "silently attach".

While this creates interesting points of confusion since some
people may have direct experience with networks like this that
(ostensibly) work, the fact is that working with a network of
this type presents special problems and is not ubiquitously
possible as of yet.

> 
> >>>This 
> >>>can help to enforce security (like preventing MAC spoofing) and  also 
> >>>ensure ARP resolution in one step without broadcast. 
> >> 
> >> Correct the above if not correct, but assuming that there is no way to
> >> secure ARP that doesn't modify ARP too.
> >>  
> > ARP query would be performed by the Designated Router (encapsulated 
> > query directed to the ARP server).
> 
> The ARPs are originated outside the campus; the two options are to
> encapsulate the ARP and broadcast it or to encapsulate it and send it to
> an internal cache (the ARP server). Neither is secure, since they are
> triggered by external, unauthenticated ARPs.
> 
> > I am not expert, but I guess the 
> > server can autenticate the DRs.
> 
> Sure - but that only authenticates the internal cache; there's no way to
> authenticate the initial broadcast whose reply is used to populate the
> cache.
> 
> > I agree that a host may spoof its MAC 
> > but security measures are possible both at the ARP server (the spoofed 
> > host is registered in same server) and at the DR (attacks and  behaviour

> > will likely concentrate on a certain port of  DR) 
> 
> Why bother? As above, we already need to support broadcast ARP to
> bootstrap. Besides, securing the internal protocol complicates the
> deployment. There's little utility to securing the ARP cache
> communication this way, IMO, unless you've already secured internal
> control communication (e.g., routing) for other reasons.
> 
> >>>The point is to 
> >>>distribute the load of ARP registry and queries between multiple ARP 
> >>>servers. This may be based on IP hashing.
> >> 
> >> Sure, hashing will direct you to the right cache. But how does that
> >> cache know what to reply? It can't unless IT floods; that's the
catch-22.
> >> 
> > The cach? knows the content because it is the unique both server and 
> > registrar for the IP addresses set. Prior to that query, upon first ARP 
> > issued  the host was registered by the DR at that cach?, based on its 
> > hash(IP). 
> 
> ARP may announce the location of the ARP sender, but doesn't announce
> the location of the ARP reply. Both need to be snooped to load the
> cache. The trouble is the first ARP _to_ any new IP address must always
> be broadcast; by definition, it won't be in the cache.
>

For the same reason, this is not always the case.  If it is likely
that every host will know the IP (and MAC) address of a default
router, all ARP traffic from that point on may be unicast directed 
to the default router.

This can be a big if, however, in some networks and should not be
assumed.


> 
> > An ARP cache query from host would produce from DR two 
> > packets : a registration of originating host at ARP registrar and an ARP

> > query of destination host at ARP server. 
> 
> What does the ARP server do with a request of the destination if it
> hasn't seen any communication from that host before?

It could respond exactly as it would if the host was not attached.
This could be appropriate behavior in networks where silent host
attachment is a non-starter anyway.

The poster-child example is the typical small network with a single
DHCP server that also happens to be the Internet attachment point,
firewall, NAT and default router.  This is the increasingly common
- but not (yet) universal - case.

> 
> Joe
> 
>   [.. 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 j46Gfl604570; Fri, 6 May 2005 09:41:47 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 06 May 2005 09:43:53 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <000001c5509e$c809d6b0$[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-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 06 May 2005 16:42:02 -0000
Status: RO
Content-Length: 3540

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



Guillermo Ib??ez wrote:
> ...
>>>I wonder if an ARP server/registrar approach can be foreseen as an 
>>>alternative or complementary strategy.  The Designated Rbridge registers 
>>>each host, when an ARP is received, at a (distributed) ARP server.
>> 
>> When an ARP reply is received, that can be done. But the first ARP to an
>> otherwise unknown host, which has silently attached to a stub at an
>> RBridge ingress, is unknown. The only way to find it is to flood.
>> 
> True. But this is the only case.

The problem is that it's the defining case. All others can, as you
observe, be optimized with a variety of engineering solutions. IMO, none
are all that interesting - ARP already caches at the endhost anyway.

>>>This 
>>>can help to enforce security (like preventing MAC spoofing) and  also 
>>>ensure ARP resolution in one step without broadcast. 
>> 
>> Correct the above if not correct, but assuming that there is no way to
>> secure ARP that doesn't modify ARP too.
>>  
> ARP query would be performed by the Designated Router (encapsulated 
> query directed to the ARP server).

The ARPs are originated outside the campus; the two options are to
encapsulate the ARP and broadcast it or to encapsulate it and send it to
an internal cache (the ARP server). Neither is secure, since they are
triggered by external, unauthenticated ARPs.

> I am not expert, but I guess the 
> server can autenticate the DRs.

Sure - but that only authenticates the internal cache; there's no way to
authenticate the initial broadcast whose reply is used to populate the
cache.

> I agree that a host may spoof its MAC 
> but security measures are possible both at the ARP server (the spoofed 
> host is registered in same server) and at the DR (attacks and  behaviour 
> will likely concentrate on a certain port of  DR) 

Why bother? As above, we already need to support broadcast ARP to
bootstrap. Besides, securing the internal protocol complicates the
deployment. There's little utility to securing the ARP cache
communication this way, IMO, unless you've already secured internal
control communication (e.g., routing) for other reasons.

>>>The point is to 
>>>distribute the load of ARP registry and queries between multiple ARP 
>>>servers. This may be based on IP hashing.
>> 
>> Sure, hashing will direct you to the right cache. But how does that
>> cache know what to reply? It can't unless IT floods; that's the catch-22.
>> 
> The cach? knows the content because it is the unique both server and 
> registrar for the IP addresses set. Prior to that query, upon first ARP 
> issued  the host was registered by the DR at that cach?, based on its 
> hash(IP). 

ARP may announce the location of the ARP sender, but doesn't announce
the location of the ARP reply. Both need to be snooped to load the
cache. The trouble is the first ARP _to_ any new IP address must always
be broadcast; by definition, it won't be in the cache.

> An ARP cache query from host would produce from DR two 
> packets : a registration of originating host at ARP registrar and an ARP 
> query of destination host at ARP server. 

What does the ARP server do with a request of the destination if it
hasn't seen any communication from that host before?

Joe


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

iD8DBQFCe57JE5f5cImnZrsRApfnAKCiYVfTjaHuLK4wnf+ckpsU8E0b5QCg+jLm
BFwBjuirgR1GlaSbFy0044Q=
=dWU9
-----END PGP SIGNATURE-----


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 j46GCU626289 for <[e-mail]>; Fri, 6 May 2005 09:12:30 -0700 (PDT)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0E35C49D72 for <[e-mail]>; Fri,  6 May 2005 18:12:24 +0200 (CEST)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp02.uc3m.es (Postfix) with ESMTP id 9E25849D82 for <[e-mail]>; Fri,  6 May 2005 18:12:23 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 06 May 2005 18:12:23 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <000001c5509e$c809d6b0$[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-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 06 May 2005 16:13:01 -0000
Status: RO
Content-Length: 4571

Guillermo Ib??ez wrote:

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Guillermo Ib??ez wrote:
>  
>
>>Guillermo Ib??ez wrote:
>>
>>Joe Touch wrote:
>>
>>
>>    
>>
>>>Guillermo Ib??ez wrote:
>>>...
>>>
>>>
>>>
>>>      
>>>
>>>>I agree with your view, except about ARP. 
>>>>Is there any estimation on the ARP load expected on Rbridges as ARP 
>>>>proxies and hosts in general (ARPs unsolved by proxies)?
>>>>I wonder whether the Rbridges are the most suited devices to handle many 
>>>>ARP requests. For big networks like this it might be worth to consider 
>>>>the use of separate ARP servers distributed over the subnetwork instead 
>>>>of ARP proxies at Rbridges.
>>>>  
>>>>
>>>>        
>>>>
>>>I am anticipating that RBridges should handle ARPs via broadcast as a
>>>default; we're looking into proxy-ARP based on knowledge of ingress
>>>locations, to reduce ARP load. That solution would need to be fault
>>>tolerant to loss of the proxy mechanism, whether distributed or at a server.
>>>
>>>Joe
>>>
>>>
>>>
>>>      
>>>
>>Right. Default must always be ARP broadcast.  I understand that in this 
>>case the frame is not encapsulated,  just forwarded by Rbridge.
>>    
>>
>
>All packets arriving at an egress are always encapsulated, including
>ARPs. The only non-encapsulated packets inside an RBridge campus would
>be RBridge control traffic, e.g., routing protocols and encapsulation
>table setup.
>  
>
>> ARP load is somewhat reduced in the core  by diffusing ARP to Rbridges 
>>via a specific multicast address iso broadcast address . But still the 
>>cost of local ARPs issued by each Rbridge at the ends may be significative.
>>    
>>
>
>Sure - ARPs not only flood the RBridge campus, but also the stubs that
>attach. But that's a property of all L2 networks; broadcasts broadcast.
>
>  
>
>>I wonder if an ARP server/registrar approach can be foreseen as an 
>>alternative or complementary strategy.  The Designated Rbridge registers 
>>each host, when an ARP is received, at a (distributed) ARP server.
>>    
>>
>
>When an ARP reply is received, that can be done. But the first ARP to an
>otherwise unknown host, which has silently attached to a stub at an
>RBridge ingress, is unknown. The only way to find it is to flood.
>
>  
>
True. But this is the only case.

>>This 
>>can help to enforce security (like preventing MAC spoofing) and  also 
>>ensure ARP resolution in one step without broadcast. 
>>    
>>
>
>Correct the above if not correct, but assuming that there is no way to
>secure ARP that doesn't modify ARP too.
>  
>
ARP query would be performed by the Designated Router (encapsulated 
query directed to the ARP server). I am not expert, but I guess the 
server can autenticate the DRs. I agree that a host may spoof  its MAC 
but security measures are possible both at the ARP server (the spoofed 
host is registered in same server) and at the DR (attacks and  behaviour 
will likely concentrate on a certain port of  DR)   

>  
>
>>The point is to 
>>distribute the load of ARP registry and queries between multiple ARP 
>>servers. This may be based on IP hashing.
>>    
>>
>
>Sure, hashing will direct you to the right cache. But how does that
>cache know what to reply? It can't unless IT floods; that's the catch-22.
>
>Joe
>
>  
>
The cach? knows the content because it is the unique both server and 
registrar for the IP addresses set. Prior to that query, upon first ARP 
issued  the host was registered by the DR at that cach?, based on its 
hash(IP) . An ARP cache query from host would produce from DR two 
packets : a registration of originating host at ARP registrar and an ARP 
query of destination host at ARP server. 
Regards
Guillermo

>>Regards
>>Guillermo
>>
>>
>>    
>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>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
>
>iD8DBQFCe5ChE5f5cImnZrsRAhYCAKCTK+bm/VtZ/7yGtU4Qi12pEC8B0QCfSJv0
>Iv1gD4eJ7OyDsvTkRCB/ZXg=
>=DzCO
>-----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 j46FfN616654; Fri, 6 May 2005 08:41:23 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 06 May 2005 08:43:29 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <000001c5509e$c809d6b0$[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-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 06 May 2005 15:42:03 -0000
Status: RO
Content-Length: 3288

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



Guillermo Ib??ez wrote:
> Guillermo Ib??ez wrote:
> 
> Joe Touch wrote:
> 
> 
>>Guillermo Ib??ez wrote:
>>...
>> 
>>
>>
>>>I agree with your view, except about ARP. 
>>>Is there any estimation on the ARP load expected on Rbridges as ARP 
>>>proxies and hosts in general (ARPs unsolved by proxies)?
>>>I wonder whether the Rbridges are the most suited devices to handle many 
>>>ARP requests. For big networks like this it might be worth to consider 
>>>the use of separate ARP servers distributed over the subnetwork instead 
>>>of ARP proxies at Rbridges.
>>>   
>>>
>>
>>I am anticipating that RBridges should handle ARPs via broadcast as a
>>default; we're looking into proxy-ARP based on knowledge of ingress
>>locations, to reduce ARP load. That solution would need to be fault
>>tolerant to loss of the proxy mechanism, whether distributed or at a server.
>>
>>Joe
>>
>> 
>>
> 
> Right. Default must always be ARP broadcast.  I understand that in this 
> case the frame is not encapsulated,  just forwarded by Rbridge.

All packets arriving at an egress are always encapsulated, including
ARPs. The only non-encapsulated packets inside an RBridge campus would
be RBridge control traffic, e.g., routing protocols and encapsulation
table setup.

>  ARP load is somewhat reduced in the core  by diffusing ARP to Rbridges 
> via a specific multicast address iso broadcast address . But still the 
> cost of local ARPs issued by each Rbridge at the ends may be significative.

Sure - ARPs not only flood the RBridge campus, but also the stubs that
attach. But that's a property of all L2 networks; broadcasts broadcast.

> I wonder if an ARP server/registrar approach can be foreseen as an 
> alternative or complementary strategy.  The Designated Rbridge registers 
> each host, when an ARP is received, at a (distributed) ARP server.

When an ARP reply is received, that can be done. But the first ARP to an
otherwise unknown host, which has silently attached to a stub at an
RBridge ingress, is unknown. The only way to find it is to flood.

> This 
> can help to enforce security (like preventing MAC spoofing) and  also 
> ensure ARP resolution in one step without broadcast. 

Correct the above if not correct, but assuming that there is no way to
secure ARP that doesn't modify ARP too.

> The point is to 
> distribute the load of ARP registry and queries between multiple ARP 
> servers. This may be based on IP hashing.

Sure, hashing will direct you to the right cache. But how does that
cache know what to reply? It can't unless IT floods; that's the catch-22.

Joe

> Regards
> Guillermo
> 
> 
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>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

iD8DBQFCe5ChE5f5cImnZrsRAhYCAKCTK+bm/VtZ/7yGtU4Qi12pEC8B0QCfSJv0
Iv1gD4eJ7OyDsvTkRCB/ZXg=
=DzCO
-----END PGP SIGNATURE-----


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 j46FRD612441 for <[e-mail]>; Fri, 6 May 2005 08:27:13 -0700 (PDT)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7A62349F50 for <[e-mail]>; Fri,  6 May 2005 17:27:06 +0200 (CEST)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp02.uc3m.es (Postfix) with ESMTP id 3642C49F49 for <[e-mail]>; Fri,  6 May 2005 17:27:06 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 06 May 2005 17:27:06 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <000001c5509e$c809d6b0$[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-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 06 May 2005 15:28:29 -0000
Status: RO
Content-Length: 1890

Guillermo Ib??ez wrote:

Joe Touch wrote:

>Guillermo Ib??ez wrote:
>...
>  
>
>>I agree with your view, except about ARP. 
>>Is there any estimation on the ARP load expected on Rbridges as ARP 
>>proxies and hosts in general (ARPs unsolved by proxies)?
>>I wonder whether the Rbridges are the most suited devices to handle many 
>>ARP requests. For big networks like this it might be worth to consider 
>>the use of separate ARP servers distributed over the subnetwork instead 
>>of ARP proxies at Rbridges.
>>    
>>
>
>I am anticipating that RBridges should handle ARPs via broadcast as a
>default; we're looking into proxy-ARP based on knowledge of ingress
>locations, to reduce ARP load. That solution would need to be fault
>tolerant to loss of the proxy mechanism, whether distributed or at a server.
>
>Joe
>
>  
>
Right. Default must always be ARP broadcast.  I understand that in this 
case the frame is not encapsulated,  just forwarded by Rbridge.
 ARP load is somewhat reduced in the core  by diffusing ARP to Rbridges 
via a specific multicast address iso broadcast address . But still the 
cost of local ARPs issued by each Rbridge at the ends may be significative.
I wonder if an ARP server/registrar approach can be foreseen as an 
alternative or complementary strategy.  The Designated Rbridge registers 
each host, when an ARP is received, at a (distributed) ARP server. This 
can help to enforce security (like preventing MAC spoofing) and  also 
ensure ARP resolution in one step without broadcast. The point is to 
distribute the load of ARP registry and queries between multiple ARP 
servers. This may be based on IP hashing.
Regards
Guillermo

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



Received: from [192.168.1.47] (pool-71-106-98-38.lsanca.dsl-w.verizon.net [71.106.98.38]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j46EdW626692; Fri, 6 May 2005 07:39:32 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 06 May 2005 07:39:27 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <000001c5509e$c809d6b0$[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFE40DB14BF6A56F7552BCEA1"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 06 May 2005 14:40:12 -0000
Status: RO
Content-Length: 1476

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



Guillermo Ib=E1=F1ez wrote:
=2E..
> I agree with your view, except about ARP.=20
> Is there any estimation on the ARP load expected on Rbridges as ARP=20
> proxies and hosts in general (ARPs unsolved by proxies)?
> I wonder whether the Rbridges are the most suited devices to handle man=
y=20
> ARP requests. For big networks like this it might be worth to consider =

> the use of separate ARP servers distributed over the subnetwork instead=
=20
> of ARP proxies at Rbridges.

I am anticipating that RBridges should handle ARPs via broadcast as a
default; we're looking into proxy-ARP based on knowledge of ingress
locations, to reduce ARP load. That solution would need to be fault
tolerant to loss of the proxy mechanism, whether distributed or at a serv=
er.

Joe


--------------enigFE40DB14BF6A56F7552BCEA1
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.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCe4GfE5f5cImnZrsRAp1qAKDdGz7qyHac2O72wiANWkfmjs3sVwCcDSO5
eZt1rFtrjNxtWrJCR4cSJes=
=aDVa
-----END PGP SIGNATURE-----

--------------enigFE40DB14BF6A56F7552BCEA1--


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 j468X8623710 for <[e-mail]>; Fri, 6 May 2005 01:33:08 -0700 (PDT)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6F03E4922B for <[e-mail]>; Fri,  6 May 2005 10:33:01 +0200 (CEST)
Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp03.uc3m.es (Postfix) with ESMTP id 17B36491E3 for <[e-mail]>; Fri,  6 May 2005 10:33:01 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 06 May 2005 10:33:01 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <000001c5509e$c809d6b0$[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-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 06 May 2005 08:34:03 -0000
Status: RO
Content-Length: 4898

Joe Touch wrote:

>Guillermo Ib??ez wrote:
>  
>
>>Hello Joe,
>>
>>More on maximum network size.
>>    
>>
>
>As a prelude, YES - lots of engineering issues...
>
>  
>
>>-So we can expect, for a network with one hundred thousand hosts, rbridges
>>with tables of that size. OK?
>>(No problem so far).
>>    
>>
>
>Ingresses need to have enough information to encapsulate based on
>destination host MAC address; that can be accomplished two ways:
>	- full tables carried at each ingress
>		which would be hard to compress, but might
>		be hashable
>	- internal bootstrap
>		1) internal 'ARP' when a previously unknown
>		MAC arrives at the ingress, resolving to a cached
>		entry
>
>		2) implied 'ARP' by broadcasting the packet
>		with the successful egress back-propagating
>		the entry later
>
>I suspect a combination may be required, since there will be packets
>whose MAC may not be knowable at the egress (silently attached), so we
>may have to flood the network to even find the right egress to use. This
>is no different from what bridges do, though...
>
>  
>
>>-Scalable routing between Rbridges: my understanding is that MAC addresses
>>are used for routing between them. Although the number of bridges will no be
>>too high (i.e thousands), I do not understand well the meaning of
>>"scalability of routing" as the flat addresses used do not permit route
>>aggregation. I did not follow the routing discussiong so may be I missed
>>something.
>>    
>>
>
>Yes, we need a routing protocol that can scale. Note, however, that
>we're forwarding internally ONLY on the destination rbridge address, NOT
>the original packet's MAC address. So the number of entries is the
>number of egresses, NOT the number of end hosts.
>
>The tradeoff is in the encapsulation table size (first item above);
>_that_ table is O(# attached hosts), whereas the routing is O(# egresses).
>
>  
>
>>Rbridge types
>>- You mention "interior" Rbridges and "edge" Rbridges. Do you see any
>>functional differentiation between these two types ?
>>    
>>
>
>Egress nodes need encapsulation tables and forwarding tables; interior
>nodes just need forwarding tables and could be cheaper.
>
>  
>
>>In this case handled it
>>could be handled by self configuration (upon detection of hosts an interior
>>bridge becomes edge bridge). My understanding is that  there are no
>>functional differentiation of Rbridges, but engineering differences to
>>optimize between "core" Rbridges and "access" Rbridges. Right?  
>>    
>>
>
>A edge bridge can easily function as interior; an interior might not
>function as an edge. This may favor a single integrated design. The
>behavior is configured on a per-MAC basis (traffic coming from another
>rbridge in your campus is internal; all other traffic is external). This
>should be very easy to automate, IMO (do an echo algorithm to find all
>connected rbridges, declare that one campus unless manually configured
>not to, and use those MACs as internal traffic).
>
>The distinction based on device is better for describing the system, but
>in practice I would expect it would be per-MAC, not per-box.
>
>I hope this all helps - I can add it to the doc.
>
>Joe
>
>  
>
>>Regards
>>Guillermo Iba?ez
>>
>>-----Mensaje original-----
>>De: [e-mail] [mailto:[e-mail]] En nombre
>>de Joe Touch
>>Enviado el: domingo, 01 de mayo de 2005 5:27
>>Para: Developing a hybrid router/bridge.
>>Asunto: Re: [rbridge] Max Network size
>>
>>
>>
>>
>>Guillermo Ib??ez wrote:
>>
>>    
>>
>>>I have a question:
>>>  What is the maximum network size (number of hosts) 
>>>required/expected
>>>in TRILL? May be it was already stated somewhere, I am not aware of it.
>>>Regards
>>>Guillermo Ib??ez
>>>      
>>>
>>There is no limit of design; it is based on the capability of edge RBridges
>>to handle encapsulation tables, as well as of interior RBridges to have
>>scalable routing.
>>
>>We expect to scale to numbers of hosts much higher than current bridges,
>>but it's hard to predict what the knee of the design curve will be (IMO).
>>
>>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
>  
>
I agree with your view, except about ARP. 
Is there any estimation on the ARP load expected on Rbridges as ARP 
proxies and hosts in general (ARPs unsolved by proxies)?
I wonder whether the Rbridges are the most suited devices to handle many 
ARP requests. For big networks like this it might be worth to consider 
the use of separate ARP servers distributed over the subnetwork instead 
of ARP proxies at Rbridges.
Regards
Guillermo


Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j44IMp624324 for <[e-mail]>; Wed, 4 May 2005 11:22:51 -0700 (PDT)
Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 05 May 2005 03:22:44 +0900 (KST)
Received: from Alperyegin ([105.253.155.11]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Thu, 05 May 2005 03:22:44 +0900 (KST)
Date: Wed, 04 May 2005 11:22:03 -0700
From: Alper Yegin <[e-mail]>
In-reply-to: <[e-mail]>
To: [e-mail], "'Developing a hybrid router/bridge.'" <[e-mail]>, "'Erik Nordmark'" <[e-mail]>
Message-id: <03f501c550d6$2dd0cfd0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Existing issues in root bridge selection for LANs.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 04 May 2005 18:23:49 -0000
Status: RO
Content-Length: 544

> I'm not sure if the RB as Root Bridge idea is always beneficial, but
> would it be worth looking into?

I think it is more likely to be beneficial, given that it is (they are)
used as the ingress and egress to the rest of the LAN (ie, connecting
bridged segment to the rest of the LAN). But of course, if there is
heavy traffic local to the bridged segment (below RB(s)), then all the
bets are off. 

I think it can be a good default choice, that can be overridden by
manual config or any other dynamic mechanism (if there is any).

Alper




Received: from [70.213.121.51] (51.sub-70-213-121.myvzw.com [70.213.121.51]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j44Fsr619954; Wed, 4 May 2005 08:54:53 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 04 May 2005 08:54:46 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <000001c5509e$c809d6b0$[e-mail]>
In-Reply-To: <000001c5509e$c809d6b0$[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA329E1CC08CEBA2E56C090EC"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 04 May 2005 15:55:52 -0000
Status: RO
Content-Length: 4824

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



Guillermo Ib=E1=F1ez wrote:
> Hello Joe,
>=20
> More on maximum network size.

As a prelude, YES - lots of engineering issues...

> -So we can expect, for a network with one hundred thousand hosts, rbrid=
ges
> with tables of that size. OK?
> (No problem so far).

Ingresses need to have enough information to encapsulate based on
destination host MAC address; that can be accomplished two ways:
	- full tables carried at each ingress
		which would be hard to compress, but might
		be hashable
	- internal bootstrap
		1) internal 'ARP' when a previously unknown
		MAC arrives at the ingress, resolving to a cached
		entry

		2) implied 'ARP' by broadcasting the packet
		with the successful egress back-propagating
		the entry later

I suspect a combination may be required, since there will be packets
whose MAC may not be knowable at the egress (silently attached), so we
may have to flood the network to even find the right egress to use. This
is no different from what bridges do, though...

> -Scalable routing between Rbridges: my understanding is that MAC addres=
ses
> are used for routing between them. Although the number of bridges will =
no be
> too high (i.e thousands), I do not understand well the meaning of
> "scalability of routing" as the flat addresses used do not permit route=

> aggregation. I did not follow the routing discussiong so may be I misse=
d
> something.

Yes, we need a routing protocol that can scale. Note, however, that
we're forwarding internally ONLY on the destination rbridge address, NOT
the original packet's MAC address. So the number of entries is the
number of egresses, NOT the number of end hosts.

The tradeoff is in the encapsulation table size (first item above);
_that_ table is O(# attached hosts), whereas the routing is O(# egresses)=
=2E

> Rbridge types
> - You mention "interior" Rbridges and "edge" Rbridges. Do you see any
> functional differentiation between these two types ?

Egress nodes need encapsulation tables and forwarding tables; interior
nodes just need forwarding tables and could be cheaper.

> In this case handled it
> could be handled by self configuration (upon detection of hosts an inte=
rior
> bridge becomes edge bridge). My understanding is that  there are no
> functional differentiation of Rbridges, but engineering differences to
> optimize between "core" Rbridges and "access" Rbridges. Right? =20

A edge bridge can easily function as interior; an interior might not
function as an edge. This may favor a single integrated design. The
behavior is configured on a per-MAC basis (traffic coming from another
rbridge in your campus is internal; all other traffic is external). This
should be very easy to automate, IMO (do an echo algorithm to find all
connected rbridges, declare that one campus unless manually configured
not to, and use those MACs as internal traffic).

The distinction based on device is better for describing the system, but
in practice I would expect it would be per-MAC, not per-box.

I hope this all helps - I can add it to the doc.

Joe

> Regards
> Guillermo Iba=F1ez
>=20
> -----Mensaje original-----
> De: [e-mail] [mailto:[e-mail]] En n=
ombre
> de Joe Touch
> Enviado el: domingo, 01 de mayo de 2005 5:27
> Para: Developing a hybrid router/bridge.
> Asunto: Re: [rbridge] Max Network size
>=20
>=20
>=20
>=20
> Guillermo Ib=E1=F1ez wrote:
>=20
>>I have a question:
>>   What is the maximum network size (number of hosts)=20
>>required/expected
>>in TRILL? May be it was already stated somewhere, I am not aware of it.=

>>Regards
>>Guillermo Ib=E1=F1ez
>=20
>=20
> There is no limit of design; it is based on the capability of edge RBri=
dges
> to handle encapsulation tables, as well as of interior RBridges to have=

> scalable routing.
>=20
> We expect to scale to numbers of hosts much higher than current bridges=
,
> but it's hard to predict what the knee of the design curve will be (IMO=
).
>=20
> Joe
>=20
>=20
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


--------------enigA329E1CC08CEBA2E56C090EC
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.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCePBGE5f5cImnZrsRAqwXAKDuc3KEMB695R0EAsb3CTcQ2Fpo9gCePjs8
gWqVSVhelHlsJWYqF9/Vjxo=
=5XGF
-----END PGP SIGNATURE-----

--------------enigA329E1CC08CEBA2E56C090EC--


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 j44Bje627949 for <[e-mail]>; Wed, 4 May 2005 04:45:41 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E3E455D9B1 for <[e-mail]>; Wed,  4 May 2005 13:45:33 +0200 (CEST)
Received: from 11B111 (unknown [163.117.54.184]) by smtp01.uc3m.es (Postfix) with ESMTP id 522AB5D9CA for <[e-mail]>; Wed,  4 May 2005 13:45:33 +0200 (CEST)
From: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Wed, 4 May 2005 13:45:33 +0200
Message-ID: <000001c5509e$c809d6b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-ISI-4-39-6-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 j44Bje627949
Subject: Re: [rbridge] Max Network size
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 04 May 2005 11:45:47 -0000
Status: RO
Content-Length: 1806

Hello Joe,


More on maximum network size.
-So we can expect, for a network with one hundred thousand hosts, rbridges
with tables of that size. OK?
(No problem so far).
-Scalable routing between Rbridges: my understanding is that MAC addresses
are used for routing between them. Although the number of bridges will no be
too high (i.e thousands), I do not understand well the meaning of
"scalability of routing" as the flat addresses used do not permit route
aggregation. I did not follow the routing discussiong so may be I missed
something.

Rbridge types
- You mention "interior" Rbridges and "edge" Rbridges. Do you see any
functional differentiation between these two types ? In this case handled it
could be handled by self configuration (upon detection of hosts an interior
bridge becomes edge bridge). My understanding is that  there are no
functional differentiation of Rbridges, but engineering differences to
optimize between "core" Rbridges and "access" Rbridges. Right?  
 
Regards
Guillermo Iba?ez

-----Mensaje original-----
De: [e-mail] [mailto:[e-mail]] En nombre
de Joe Touch
Enviado el: domingo, 01 de mayo de 2005 5:27
Para: Developing a hybrid router/bridge.
Asunto: Re: [rbridge] Max Network size




Guillermo Ib??ez wrote:
> I have a question:
>    What is the maximum network size (number of hosts) 
> required/expected
> in TRILL? May be it was already stated somewhere, I am not aware of it.
> Regards
> Guillermo Ib??ez

There is no limit of design; it is based on the capability of edge RBridges
to handle encapsulation tables, as well as of interior RBridges to have
scalable routing.

We expect to scale to numbers of hosts much higher than current bridges,
but it's hard to predict what the knee of the design curve will be (IMO).

Joe




Received: from [64.134.119.190] (dhcp64-134-119-190.casa.mia.wayport.net [64.134.119.190]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j44BIJ620685; Wed, 4 May 2005 04:18:19 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 04 May 2005 04:18:15 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig84E1084EFF505EA145FF1281"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Existing issues in root bridge selection for LANs.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 04 May 2005 11:18:47 -0000
Status: RO
Content-Length: 1349

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



Erik Nordmark wrote:
...
> Hmm - a term like "TRILL routers" might be a bit confusing.
> We need to be able to discuss networks which have
>   - L2 endpoints
> 	IP hosts
> 	IP routers
>   - Existing bridges
>   - TRILL devices (aka rbridges)
> 
> When I want to draw diagrams showing routers R1, R2, bridges (B1, B2, 
> ..), hosts (H1, H2, ..) I've found it useful to pick another letter for 
> the hybrid TRILL devices, so I've used "T".
> But a term like "trillers" for these devices is a bit odd. I guess we 
> could use Rbridges and name them RB1, RB2, etc.

We use the term rbridges in the current ID, and label them RB1, RB2,
etc. as you note.

Joe

--------------enig84E1084EFF505EA145FF1281
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.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCeK93E5f5cImnZrsRAsq2AKCBVNnn3K2Z9DV3xgjokorJZ9DRIwCfXX1Z
IpOy3R2acv3Iz9h7P4HiVDc=
=wDe8
-----END PGP SIGNATURE-----

--------------enig84E1084EFF505EA145FF1281--


Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j443G5610041 for <[e-mail]>; Tue, 3 May 2005 20:16:05 -0700 (PDT)
Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <[e-mail]> for [e-mail]; Wed, 04 May 2005 13:15:46 +1000
Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7E364AB542; Wed, 04 May 2005 13:15:46 +1000 (EST)
Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 604584FB03; Wed, 04 May 2005 13:15:46 +1000 (EST)
Date: Wed, 04 May 2005 13:15:41 +1000
From: Greg Daley <[e-mail]>
In-reply-to: <[e-mail]>
To: Erik Nordmark <[e-mail]>
Message-id: <[e-mail]>
Organization: Monash University
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en, en-us
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Existing issues in root bridge selection for LANs.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 May 2005 03:16:44 -0000
Status: RO
Content-Length: 4961

Hi Erik,

Sorry about not knowing the right terms to use.

I'll try to adopt the ones you used.

Erik Nordmark wrote:
> Greg Daley wrote:
> 
>> Given that each trill network interfaces with a legacy 802.1 LAN,
>> some work to choose a good root for the 802.1D spanning-tree in each
>> LAN would be useful to reduce the aggregate traffic load on the network.
> 
> 
> Ah - sorry for the misunderstanding.
> Exactly what makes sense in this case has to do with both the details of 
> how rbridges interact with bridges, and what network topology gets 
> deployed.

Yes, definitely.

I'd be interested to see if the model is applicable though,
so that I can determine if I need to go off and do more analysis
of the potential benefits.

>> This doesn't require modification to the 802.1D mechanism, except
>> that devices which know they are closer to the ingress/egress of
>> the network can make their chances better.
>>
>> The original idea I had was before my rbridge awareness (notice that
>> the router R in the network wasn't considered).  Where trill routers
>> are present, they have direct knowledge that they are at the edge
>> of a LAN, and are potential ingress/egress points.
> 
> 
> Hmm - a term like "TRILL routers" might be a bit confusing.
> We need to be able to discuss networks which have
>  - L2 endpoints
>     IP hosts
>     IP routers
>  - Existing bridges
>  - TRILL devices (aka rbridges)
> 
> When I want to draw diagrams showing routers R1, R2, bridges (B1, B2, 
> ..), hosts (H1, H2, ..) I've found it useful to pick another letter for 
> the hybrid TRILL devices, so I've used "T".
> But a term like "trillers" for these devices is a bit odd. I guess we 
> could use Rbridges and name them RB1, RB2, etc.

OK, I'll put T, for Trill or Terminus Bridges... or something.

>> It's possible to use trill's routing protocol on the legacy LAN
>> to elect which of the trill routers will be the most preferred root
>> (rather than for exchange of link state).
> 
> 
> If you are assuming that the RSTP protocol terminates at the rbridges, 
> then you end up with a sub-topology of the LAN with e.g.
> 
>     <rest of LAN up here>
>      |                |
>     RB1              RB2
>      |                |
>      -------------------
>      |    |      |
>     H1    H2     R1
> 
> Where the line is the middle is made up of bridges.
> Thus the issue is where RSTP places the root bridge in this sub-topology 
> of the whole LAN.
> 
> Do I understand your case correctly?

Yes.

> Note that RB1 and RB2 needs to elect one of them to be the forwarder 
> between the sub-topology and the rest of the LAN, to make sure that the 
> learning tables in the bridges don't flap from seeing packets from the 
> same source MAC address sometimes come from RB1 and other times from 
> RB2. The bridges will then forward packets based on the port they 
> learned the MAC address on, i.e. back towards the RB that forwarded 
> packets "in".
> 
> Depending on the bridge topology "below" RB1 and RB2, it might very well 
> make sense to have the RSTP root bridge be close to RB1/RB2.
> It might even make sense to have RB1/RB2 to act as a bridge on the lower 
> interface so that itself can become the root bridge.

This is what I was thinking was particularly applicable to Trill.

> But a lot of this depends on the topology and traffic patterns "below" 
> the RBs in the figure.

Indeed. That's the case.

My guess (still not checked generally) is that if more traffic is
flowing into and out of one RBridge, then it will be the best place
to have a root (for scalability and traffic dimensioning purposes).

Your diagram is a useful one, since it illustrates non-Trill capable
routers in the network.

In those situations the Internet Router is likely to be the best
root bridge of all, and its adjacent bridge is likely to not be a Trill
device, and is not likely to be able to automatically configure.

Here it's likely that the root bridge will have to be selected manually,
although there may be a case for automatic root bridge selection on
one of the Trill devices, over default preference devices if it is
likely to be a big traffic generator.

>> Alternatively, if no routing protocol is explicitly used on the legacy
>> LAN, routers within the trill cloud which know they are attached to the
>> same legacy LAN can determine from their trill routing knowledge which
>> is the best root.
> 
> 
> I didn't understand this part.

I was thinking that if the trill devices are connected to the same trill
cloud ("above" the RBs in the diagram), they could do the root
preference election on the "above" side, based on link-state
knowledge from the "below" LAN.

This was basically an off-the-cuff idea though.  It's probably better to
run the lot on the "below" side to handle disjoint Trill domains
connecting to the same legacy LAN.



I'm not sure if the RB as Root Bridge idea is always beneficial, but
would it be worth looking into?

Greg


Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j441Ga610835 for <[e-mail]>; Tue, 3 May 2005 18:16:36 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.108.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j441GXi7016819;  Tue, 3 May 2005 19:16:34 -0600 (MDT)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j441GVAG339938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 May 2005 18:16:33 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 03 May 2005 18:16:35 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [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: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Existing issues in root bridge selection for LANs.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 04 May 2005 01:16:42 -0000
Status: RO
Content-Length: 3097

Greg Daley wrote:

> Given that each trill network interfaces with a legacy 802.1 LAN,
> some work to choose a good root for the 802.1D spanning-tree in each
> LAN would be useful to reduce the aggregate traffic load on the network.

Ah - sorry for the misunderstanding.
Exactly what makes sense in this case has to do with both the details of 
how rbridges interact with bridges, and what network topology gets deployed.


> This doesn't require modification to the 802.1D mechanism, except
> that devices which know they are closer to the ingress/egress of
> the network can make their chances better.
> 
> The original idea I had was before my rbridge awareness (notice that
> the router R in the network wasn't considered).  Where trill routers
> are present, they have direct knowledge that they are at the edge
> of a LAN, and are potential ingress/egress points.

Hmm - a term like "TRILL routers" might be a bit confusing.
We need to be able to discuss networks which have
  - L2 endpoints
	IP hosts
	IP routers
  - Existing bridges
  - TRILL devices (aka rbridges)

When I want to draw diagrams showing routers R1, R2, bridges (B1, B2, 
..), hosts (H1, H2, ..) I've found it useful to pick another letter for 
the hybrid TRILL devices, so I've used "T".
But a term like "trillers" for these devices is a bit odd. I guess we 
could use Rbridges and name them RB1, RB2, etc.

> It's possible to use trill's routing protocol on the legacy LAN
> to elect which of the trill routers will be the most preferred root
> (rather than for exchange of link state).

If you are assuming that the RSTP protocol terminates at the rbridges, 
then you end up with a sub-topology of the LAN with e.g.

	<rest of LAN up here>
	 |                |
	RB1              RB2
	 |                |
	 -------------------
	 |    |      |
	H1    H2     R1

Where the line is the middle is made up of bridges.
Thus the issue is where RSTP places the root bridge in this sub-topology 
of the whole LAN.

Do I understand your case correctly?

Note that RB1 and RB2 needs to elect one of them to be the forwarder 
between the sub-topology and the rest of the LAN, to make sure that the 
learning tables in the bridges don't flap from seeing packets from the 
same source MAC address sometimes come from RB1 and other times from 
RB2. The bridges will then forward packets based on the port they 
learned the MAC address on, i.e. back towards the RB that forwarded 
packets "in".

Depending on the bridge topology "below" RB1 and RB2, it might very well 
make sense to have the RSTP root bridge be close to RB1/RB2.
It might even make sense to have RB1/RB2 to act as a bridge on the lower 
interface so that itself can become the root bridge.
But a lot of this depends on the topology and traffic patterns "below" 
the RBs in the figure.

> Alternatively, if no routing protocol is explicitly used on the legacy
> LAN, routers within the trill cloud which know they are attached to the
> same legacy LAN can determine from their trill routing knowledge which
> is the best root.

I didn't understand this part.

    Erik



Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j440Tn627980 for <[e-mail]>; Tue, 3 May 2005 17:29:49 -0700 (PDT)
Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <[e-mail]> for [e-mail]; Wed, 04 May 2005 10:29:17 +1000
Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D5A1FAB544; Wed, 04 May 2005 10:29:16 +1000 (EST)
Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 67DFC4FB04; Wed, 04 May 2005 10:29:16 +1000 (EST)
Date: Wed, 04 May 2005 10:29:10 +1000
From: Greg Daley <[e-mail]>
In-reply-to: <[e-mail]>
To: Erik Nordmark <[e-mail]>
Message-id: <[e-mail]>
Organization: Monash University
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en, en-us
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922
References: <[e-mail]> <[e-mail]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Existing issues in root bridge selection for LANs.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 May 2005 00:30:45 -0000
Status: RO
Content-Length: 2826

Hi Erik,

Erik Nordmark wrote:
> Greg Daley wrote:
> 
>> Hi,
>>
>> Here's the idea I was thinking about a while ago, which
>> looks applicable to rbridge.  More work needs to be done,
>> to ensure that the mean path cost is always lower, but
>> I'd guess it's a fairly good bet to never be worse if
>> most of the traffic exists the LAN.
> 
> 
> Given that TRILL will use a use a link-state routing protocol to find 
> the pair-wise shortest paths (without any configuration of any device), 
> I don't see how this applies to TRILL.
> 
> Are your proposing some improvements to the IEEE 802.1 protocols?

Given that each trill network interfaces with a legacy 802.1 LAN,
some work to choose a good root for the 802.1D spanning-tree in each
LAN would be useful to reduce the aggregate traffic load on the network.

This doesn't require modification to the 802.1D mechanism, except
that devices which know they are closer to the ingress/egress of
the network can make their chances better.

The original idea I had was before my rbridge awareness (notice that
the router R in the network wasn't considered).  Where trill routers
are present, they have direct knowledge that they are at the edge
of a LAN, and are potential ingress/egress points.

It's possible to use trill's routing protocol on the legacy LAN
to elect which of the trill routers will be the most preferred root
(rather than for exchange of link state).

Alternatively, if no routing protocol is explicitly used on the legacy
LAN, routers within the trill cloud which know they are attached to the
same legacy LAN can determine from their trill routing knowledge which
is the best root.

>> This means that all switches have the same default
>> priority, and MAC addresses (as provided in the
>> lower order bits of the switch's BridgeID),
>> will be used to break ties between switches.
>>
>> Therefore unless a manual priority configuration is
>> provided, MAC switch vendors with the lowest IEEE OUI
>> will win. 
> 
> 
> My understanding is that manual configuration is used in enterprise 
> Ethernets, which among other things ensure that the root bridge is close 
> to the routers.

Yes.  Terrible isn't it!?

:)

The point I was making was that manual configuration is needed,
which means that the traffic flows need to be known
(in that case by an administrator).  The same technique could be
applied automatically or heuristically.

I guess that if there's a requirement for trill/rbridge systems
to interconnect bunches of old gear, you don't want to pick a root
in each "area" manually.

The trill routers should be able to select/elect themselves as the
most likely root bridge (barring explicit manual configuration
perhaps??).  I think Radia's point was that this adds stability.
My point was that the aggregate traffic load may be smaller.

Greg


Received: from [166.153.50.193] (193.sub-166-153-50.myvzw.com [166.153.50.193]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j43I9w617873; Tue, 3 May 2005 11:09:59 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 03 May 2005 11:09:53 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC3141F76BA060BAE616629D7"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] updated internet draft - draft-perlman-rbridge-03.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 03 May 2005 18:10:45 -0000
Status: RO
Content-Length: 2253

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

Hi, all,

A revised RBridge I-D has been submitted and will be available in the
usual places shortly; in the meantime, a copy is available at

	http://www.isi.edu/touch/pubs/draft-perlman-rbridge-03.txt

FYI...

Joe

----------

Network Working Group                                        R. Perlman
Internet Draft                                                      Sun
Expires: November 2005                                         J. Touch
                                                                USC/ISI
                                                               A. Yegin
                                                                Samsung
                                                            May 2, 2005

                       RBridges: Transparent Routing
                       draft-perlman-rbridge-03.txt
...

Abstract

   RBridges provide the ability to have an entire campus, with multiple
   physical links, look to IP like a single subnet. The design allows
   for zero configuration of switches within a campus, optimal pair-wise
   routing, safe forwarding even during periods of temporary loops, and
   the ability to cut down on ARP/ND traffic. The design also supports
   VLANs, and allows forwarding tables to be based on RBridge
   destinations (rather than endnode destinations), which allows
   internal routing tables to be substantially smaller than in
   conventional bridge systems.

   This document is a work in progress; we invite you to participate on
   the mailing list at http://www.postel.org/RBridge


--------------enigC3141F76BA060BAE616629D7
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.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCd75xE5f5cImnZrsRAnAxAKDVHtRPR3SsshyZqzzonyLmv1YlZwCfUAm9
/AeRwjOnn88WFXGdsz2GjzY=
=xpN+
-----END PGP SIGNATURE-----

--------------enigC3141F76BA060BAE616629D7--


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 j43H0D622000 for <[e-mail]>; Tue, 3 May 2005 10:00:13 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.56.144]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j43H0BjG013444;  Tue, 3 May 2005 10:00:11 -0700 (PDT)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j43H08o4120497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 May 2005 10:00:09 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 03 May 2005 10:00:12 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323)
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: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Existing issues in root bridge selection for LANs.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 03 May 2005 17:01:05 -0000
Status: RO
Content-Length: 1040

Greg Daley wrote:
> Hi,
> 
> Here's the idea I was thinking about a while ago, which
> looks applicable to rbridge.  More work needs to be done,
> to ensure that the mean path cost is always lower, but
> I'd guess it's a fairly good bet to never be worse if
> most of the traffic exists the LAN.

Given that TRILL will use a use a link-state routing protocol to find 
the pair-wise shortest paths (without any configuration of any device), 
I don't see how this applies to TRILL.

Are your proposing some improvements to the IEEE 802.1 protocols?

> This means that all switches have the same default
> priority, and MAC addresses (as provided in the
> lower order bits of the switch's BridgeID),
> will be used to break ties between switches.
> 
> Therefore unless a manual priority configuration is
> provided, MAC switch vendors with the lowest IEEE OUI
> will win. 

My understanding is that manual configuration is used in enterprise 
Ethernets, which among other things ensure that the root bridge is close 
to the routers.

    Erik


Received: from [70.213.116.138] (138.sub-70-213-116.myvzw.com [70.213.116.138]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j43EaQ602316; Tue, 3 May 2005 07:36:27 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 03 May 2005 07:36:18 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig19DCFF86923ACDA4DCA9D6BC"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 03 May 2005 14:36:39 -0000
Status: RO
Content-Length: 1914

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



Greg Daley wrote:
> Hi Joe,
>=20
> Joe Touch wrote:
>=20
>>Guillermo Ib=E1=F1ez wrote:
>>
>>
>>>I have a question:
>>>  What is the maximum network size (number of hosts) required/expected=
=20
>>>in TRILL? May be it was already stated somewhere, I am not aware of it=
=2E
>>>Regards
>>>Guillermo Ib=E1=F1ez
>>
>>
>>There is no limit of design; it is based on the capability of edge
>>RBridges to handle encapsulation tables, as well as of interior RBridge=
s
>>to have scalable routing.
>>
>>We expect to scale to numbers of hosts much higher than current bridges=
,
>> but it's hard to predict what the knee of the design curve will be (IM=
O).
>=20
>=20
> If I recall, the only explicit mentions about size (apart from Alex's
> routing cost overview) are that we don't want to scale to metropolis
> (Sydney?) size.
>=20
> Greg

I believe there may be limits to the geographic scale, since some
protocols (e.g., MAC, ARP) have timing expectations. There are systems
that have tried to overcome this (L2VPN), but I'm not as familiar with
how well their results work in that regard.

But the question focused on number of hosts, and I believe that
limitation is based on engineering, not architecture.

Joe


--------------enig19DCFF86923ACDA4DCA9D6BC
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.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCd4xiE5f5cImnZrsRArdiAJ0WWXYHb9POSXg1fA1sW2wkXZ5LdQCggh22
q0/RFEpxNoQ3IXVg2KAHh9Q=
=QNKh
-----END PGP SIGNATURE-----

--------------enig19DCFF86923ACDA4DCA9D6BC--


Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j432aC628257 for <[e-mail]>; Mon, 2 May 2005 19:36:12 -0700 (PDT)
Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <[e-mail]> for [e-mail]; Tue, 03 May 2005 12:35:40 +1000
Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C18D3AB544	for <[e-mail]>; Tue, 03 May 2005 12:35:40 +1000 (EST)
Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id A0C344FB06	for <[e-mail]>; Tue, 03 May 2005 12:35:40 +1000 (EST)
Date: Tue, 03 May 2005 12:35:35 +1000
From: Greg Daley <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
Organization: Monash University
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 8BIT
X-Accept-Language: en, en-us
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922
References: <[e-mail]> <[e-mail]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Max Network size
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
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: Tue, 03 May 2005 02:36:29 -0000
Status: RO
Content-Length: 752

Hi Joe,

Joe Touch wrote:
> 
> Guillermo Ib??ez wrote:
> 
>>I have a question:
>>   What is the maximum network size (number of hosts) required/expected 
>>in TRILL? May be it was already stated somewhere, I am not aware of it.
>>Regards
>>Guillermo Ib??ez
> 
> 
> There is no limit of design; it is based on the capability of edge
> RBridges to handle encapsulation tables, as well as of interior RBridges
> to have scalable routing.
> 
> We expect to scale to numbers of hosts much higher than current bridges,
>  but it's hard to predict what the knee of the design curve will be (IMO).

If I recall, the only explicit mentions about size (apart from Alex's
routing cost overview) are that we don't want to scale to metropolis
(Sydney?) size.

Greg


Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j432X8627537 for <[e-mail]>; Mon, 2 May 2005 19:33:08 -0700 (PDT)
Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <[e-mail]> for [e-mail]; Tue, 03 May 2005 12:32:56 +1000
Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 80C28AB542	for <[e-mail]>; Tue, 03 May 2005 12:32:56 +1000 (EST)
Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 6521B4FB04	for <[e-mail]>; Tue, 03 May 2005 12:32:56 +1000 (EST)
Date: Tue, 03 May 2005 12:32:56 +1000
From: Greg Daley <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
Organization: Monash University
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en, en-us
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Existing issues in root bridge selection for LANs.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
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: Tue, 03 May 2005 02:33:30 -0000
Status: RO
Content-Length: 5258

Hi,

Here's the idea I was thinking about a while ago, which
looks applicable to rbridge.  More work needs to be done,
to ensure that the mean path cost is always lower, but
I'd guess it's a fairly good bet to never be worse if
most of the traffic exists the LAN.

Most edge LANs today have the bulk of the hosts' traffic
leaving the LAN through at most one or two ports.
The traffic in many cases is sourced or sunk from devices
in the LAN (it is essentially a stub LAN), and the data
travells to the Internet, or to off-link servers, through
IP routers.

Unmodified Spanning Tree algorithm as implemented in
ethernet switches today will produce a spanning tree,
which is not guaranteed to be one which is anchored
near to the IP routers.

This is because the bridge priority of switches is
typically provided with a default higher order (2) octets of
the Bridge Identifier with a value of 32768.

This means that all switches have the same default
priority, and MAC addresses (as provided in the
lower order bits of the switch's BridgeID),
will be used to break ties between switches.

Therefore unless a manual priority configuration is
provided, MAC switch vendors with the lowest IEEE OUI
will win.  When the same IEEE OUI is part of the
bridge Identifier of all participating switches,
the oldest switch (with the lowest sequence within
the OUI) will always be elected as root bridge.

The default settings for the path cost in spanning tree
protocol are symmetric for all systems.  This is regardless
of the importance or topological placement of a particular switch.

Other dynamic systems which automatically configure STP bridge
priorities may be useful (such as distance from routers). By
preferring to choose switches closer to egress IP routers,
lower mean path costs would be achieved for devices communicating
through the router, which is a common technique in Internet
connected systems.

As an example, there's a tight mesh of switches on a LAN:

All links are 100mbps, with switches indexed A-L, and
a router R connected through two links to H and L
and queueing delay is negligible.

A---B---C---D
   \   \   \   \
    E---F---G---H--R
     \   \   \   \/
      I---J---K---L

Since A has the lowset MAC address, and all link costs
are equal, that means that all costs are calculated
with reference to the distance from those nodes connected
to A.

If we choose the links AB, AE, nodes B and E are connected
to the tree node set [A] with cost c.

EI, EF, BC are then connected to the tree nodes [A,B,E],
with cost c.

The tree-node set is now [A,B,E,I,F,C]. The nearest adjacent
links are: IJ, FJ, FG, CG, CD.  Spanning tree protocol
will deterministically choose one of each (tie break being the
mac address).  The links FJ, CG and CD are added to the
link set, and the tree-node set is [AB, AE, EI, EF, BC, FJ, CG, CD].

Adding H and K to the set follows the same pattern.
In this case, there are equal cost links, with the links
GK, DH having the lowest origin MAC address.

Subsequently the link HL is added to the spanning tree set.
the Links HR and LR are kept open since the switches H and L
are designated bridges for that LAN segment.

The MST based on A is therefore:

AB, AE, EI, EF, BC, FJ, CG, CD, GK, DH, HL.


A---B---C---D
   \   \   \   \
    E-X-F-X-G-X-H--R
     \   \   \   \/
      I-X-J-X-K-X-L

In this case, if traffic for the router is evenly
distributed amongst the switches (My guess is that
it won't, but this will do for now), the mean
distance travelled by packets is proportional to:

Sum k=A to L ( mst_A_cost_distance(k,R) )/ 12

Since we have a uniform set of links.

==> Sum k=A to L (c * mst_A_hops(k,R)) /12

==> c * Sum ..( mst_A_hops(k,R)).
==> c * ( 5 + 4 + 3 + 2 + 6 + 5 + 4 + 1 + 7 + 6 + 5 + 1) /12
Router mean cost MST c * 49/12 == 4.083
Router worst cost (A) = 7

If instead we built the root spanning tree from either of the
switches on connected links from R, we would gain the following
MSTs, and costs:

A---B---C---D
   \   \   \   \
    E---F---G---H--R
     \   \   \   \/
      I---J---K---L


Based on H:

HD, HG, HL, GK, DC, GF, CB,  FE, FJ, EI, BA.


A---B---C---D
   X   X   X   \
    E---F---G---H--R
     \   \   \   \/
      I-X-J-X-K-X-L

Router Mean cost (H) =
c*(5 + 4 + 3 + 2 + 4 + 3 + 2 + 1 + 5 + 4 + 3 + 2)/12

Router Mean cost (H) = c * 3.16
Router Worst cost (H) = 5


A---B---C---D
   \   \   \   \
    E---F---G---H--R
     \   \   \   \/
      I---J---K---L

Based on L:


A---B---C---D
   X   X   X   \
    E---F---G---H--R
     X   X   X   \/
      I---J---K---L

LH, LK, KJ, HG, HD, DC, GF, JI, CB, FE, BA

== c*(6 + 5 + 4 + 3 + 5 + 4 + 3 + 2 + 4 + 3 + 2 + 1)/12

Router Mean cost (L)= c* 3.5
Router Worst cost (L) = c * 6

As you can see, lower mean path costs are achieved in
this example, when choosing a root anchored close
to the router.

Actual costs are dependent, in this case, on MAC
address placement. Investigation would have to be undertaken
to determine how significant the tie-breaking measures
are..

As an idea though, if a heuristic solution exists which allows
routers to modify their root-bridge preference if they are
adjacent to an IP Router, this would allow selection
of MST-Roots which provide better mean and worst router
trip costs.


Greg


Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j432GH622900 for <[e-mail]>; Mon, 2 May 2005 19:16:18 -0700 (PDT)
Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <[e-mail]> for [e-mail]; Tue, 03 May 2005 12:15:11 +1000
Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B7FBBAB545	for <[e-mail]>; Tue, 03 May 2005 12:15:10 +1000 (EST)
Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 87F264FB11	for <[e-mail]>; Tue, 03 May 2005 12:15:09 +1000 (EST)
Date: Tue, 03 May 2005 12:14:56 +1000
From: Greg Daley <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
Organization: Monash University
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en, en-us
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922
References: <p06200716be969e0fac11@[192.168.116.133]> <[e-mail]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Margaret's question about VLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
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: Tue, 03 May 2005 02:16:32 -0000
Status: RO
Content-Length: 2596

Hi Radia,

Radia Perlman wrote:
[cut]
> I think there is one optimization I'd propose to make
> dynamic VLANs work better, and which probably we should do anyway, even 
> without
> dynamic VLANs, which is to allow configuration of "priority" for an 
> RBridge to
> be chosen Root for a spanning tree to be computed from the link state 
> database.
> We should have an RBridge R not only inject "I am attached to VLAN A" into
> the link state protocol, but it should also have a configurable 
> priority, so that
> it says "I am attached to VLAN A, and I have priority x for being the 
> tree root for
> the VLAN A spanning tree". That way, if R keeps "changing its mind" 
> about whether
> it's attached to VLAN A (based on whether there are any endnodes 
> attached at this
> moment), it will be less disruptive to the VLAN A spanning tree (since the
> root won't be changing). Even without VLANs, where the entire campus is one
> broadcast domain, I could imagine someone wanting to tweak which Rbridge is
> the root of the computed spanning tree (the one for unknown 
> destinations, and for
> multicasts).

This actually helps to reduce the total cost of bridging in the spanning
tree where there is assymmetric traffic in the bridged network.

The existing STP doesn't include measurements of traffic flows in its
root bridge calculations.

If there's an RBridge which is likely to be the STP source or sink of a
lot of traffic, I think it's easy to show that even with symmetric
segment cost metrics, the sum of the traffic costs to the exit point is
lower when the entry/exit point is root bridge.

I'd have to revisit the calculation of this, but the idea has been
kicking around for a while. I'll post some of my thinking on this in the 
next mail.

> Even if it's not a parameter, I could imagine having an RBridge inject a 
> default priority
> if it's hard-configured to be attached to VLAN A, and a different 
> default priority if
> its attachment to VLAN A might be transitory (because it's based on what 
> endnodes happen
> to be attached).

This is a fair assumption.  I'm not sure how IS-IS would do this, but
if it was OSPF, you could have the Designated Router with the lowest
metric (likely to be selected as the best), and the Backup Designated
Router as the next most likely (with a slightly bigger preference
value), for simplicity's sake.

When links went up or down, and an STP recalculation was required, the
routers could advertise their preferences based on their Routing
protocol status within the LAN (and maybe use their 802 MAC addresses
as a tiebreaker).

Greg


Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j4316M608113 for <[e-mail]>; Mon, 2 May 2005 18:06:22 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j4316Li7019048 for <[e-mail]>; Mon, 2 May 2005 19:06:22 -0600 (MDT)
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]; Mon, 02 May 2005 21:06:21 -0400 (EDT)
Received: from sun.com (vpn-129-150-26-57.SFBay.Sun.COM [129.150.26.57]) 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]; Mon, 02 May 2005 21:06:21 -0400 (EDT)
Date: Mon, 02 May 2005 18:06:21 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <p06200716be969e0fac11@[192.168.116.133]>
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
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
References: <p06200716be969e0fac11@[192.168.116.133]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Margaret's question about VLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 03 May 2005 01:07:35 -0000
Status: RO
Content-Length: 2015

Margaret Wasserman wrote:

>(2) How will TRILL be compatible with existing (dynamic and 
>non-dynamic) VLANs?
>

I was thinking about why it might be relevant how an RBridge learned 
that its link
was in VLAN A, whether it was configured, or found out because an endnode
attached (and the endnode knows what VLAN it's in or the RBridge figures it
out based on the endnode's IP address or something?) The current 
proposed design
seems compatible with both dynamic and non-dynamic VLANs.

However, now that you mention it, assuming by "dynamic VLAN", you mean
a link that becomes a VLAN A link because a VLAN A node attaches
to it, and stops being a VLAN A link when the endnode goes away),
I think there is one optimization I'd propose to make
dynamic VLANs work better, and which probably we should do anyway, even 
without
dynamic VLANs, which is to allow configuration of "priority" for an 
RBridge to
be chosen Root for a spanning tree to be computed from the link state 
database.
We should have an RBridge R not only inject "I am attached to VLAN A" into
the link state protocol, but it should also have a configurable 
priority, so that
it says "I am attached to VLAN A, and I have priority x for being the 
tree root for
the VLAN A spanning tree". That way, if R keeps "changing its mind" 
about whether
it's attached to VLAN A (based on whether there are any endnodes 
attached at this
moment), it will be less disruptive to the VLAN A spanning tree (since the
root won't be changing). Even without VLANs, where the entire campus is one
broadcast domain, I could imagine someone wanting to tweak which Rbridge is
the root of the computed spanning tree (the one for unknown 
destinations, and for
multicasts).

Even if it's not a parameter, I could imagine having an RBridge inject a 
default priority
if it's hard-configured to be attached to VLAN A, and a different 
default priority if
its attachment to VLAN A might be transitory (because it's based on what 
endnodes happen
to be attached).

Radia




Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j4313m607502 for <[e-mail]>; Mon, 2 May 2005 18:03:48 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j4313li7017679 for <[e-mail]>; Mon, 2 May 2005 19:03:48 -0600 (MDT)
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]; Mon, 02 May 2005 21:03:47 -0400 (EDT)
Received: from sun.com (vpn-129-150-26-57.SFBay.Sun.COM [129.150.26.57]) 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]; Mon, 02 May 2005 21:03:47 -0400 (EDT)
Date: Mon, 02 May 2005 18:03:46 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <p06200716be969e0fac11@[192.168.116.133]>
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
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
References: <p06200716be969e0fac11@[192.168.116.133]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Margaret's question about VLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 03 May 2005 01:04:29 -0000
Status: RO
Content-Length: 2015

Margaret Wasserman wrote:

>(2) How will TRILL be compatible with existing (dynamic and 
>non-dynamic) VLANs?
>

I was thinking about why it might be relevant how an RBridge learned 
that its link
was in VLAN A, whether it was configured, or found out because an endnode
attached (and the endnode knows what VLAN it's in or the RBridge figures it
out based on the endnode's IP address or something?) The current 
proposed design
seems compatible with both dynamic and non-dynamic VLANs.

However, now that you mention it, assuming by "dynamic VLAN", you mean
a link that becomes a VLAN A link because a VLAN A node attaches
to it, and stops being a VLAN A link when the endnode goes away),
I think there is one optimization I'd propose to make
dynamic VLANs work better, and which probably we should do anyway, even 
without
dynamic VLANs, which is to allow configuration of "priority" for an 
RBridge to
be chosen Root for a spanning tree to be computed from the link state 
database.
We should have an RBridge R not only inject "I am attached to VLAN A" into
the link state protocol, but it should also have a configurable 
priority, so that
it says "I am attached to VLAN A, and I have priority x for being the 
tree root for
the VLAN A spanning tree". That way, if R keeps "changing its mind" 
about whether
it's attached to VLAN A (based on whether there are any endnodes 
attached at this
moment), it will be less disruptive to the VLAN A spanning tree (since the
root won't be changing). Even without VLANs, where the entire campus is one
broadcast domain, I could imagine someone wanting to tweak which Rbridge is
the root of the computed spanning tree (the one for unknown 
destinations, and for
multicasts).

Even if it's not a parameter, I could imagine having an RBridge inject a 
default priority
if it's hard-configured to be attached to VLAN A, and a different 
default priority if
its attachment to VLAN A might be transitory (because it's based on what 
endnodes happen
to be attached).

Radia




Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j42IgY614634 for <[e-mail]>; Mon, 2 May 2005 11:42:34 -0700 (PDT)
Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.92.1.67]) by palrel11.hp.com (Postfix) with ESMTP id 4C6E57770 for <[e-mail]>; Mon,  2 May 2005 11:42:22 -0700 (PDT)
Received: from cacexc06.americas.cpqcorp.net ([16.92.1.28]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);  Mon, 2 May 2005 11:41:29 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 2 May 2005 11:41:28 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Get IEEE 802, RE:  (no subject)
Thread-Index: AcVOAGZCFPMLdnfKSmm6uKvYbgQBXQBRB8Gg
From: "Ghanwani, Anoop" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 02 May 2005 18:41:29.0201 (UTC) FILETIME=[8D9B7E10:01C54F46]
X-ISI-4-39-6-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 j42IgY614634
Subject: Re: [rbridge] Get IEEE 802, RE:  (no subject)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 02 May 2005 18:44:58 -0000
Status: RO
Content-Length: 1278

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Erik Nordmark
> Sent: Saturday, April 30, 2005 8:37 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Get IEEE 802, RE: (no subject)
> 
> Eastlake III Donald-LDE008 wrote:
> > For IEEE 802 standards that are at least six months old and 
> for some drafts, free download is available under the "Get 
> IEEE 802" program. See http://standards.ieee.org/getieee802/.
> 
> Thanks.
> 
> 802.1D-2004 talks about the aspects of MAC service (reordering, 
> duplication, etc) in section 6.3 which is probably sufficient to 
> understand the MAC service. However, the normative reference 
> for the MAC 
> service is ISO/IEC 15802-1, and it seems like ISO charges 
> money for that 
> one.

The IEEE specs are republished as ISO specs so that they have 
international applicability.  The ISO spec will usually have the 
corresponding ANSI/IEEE specification number listed.  For example, 
15802-5-1998 is simply a replublished version of IEEE 802.1G.  
I don't what the corresponding IEEE spec is for ISO/IEC 15802-1, 
but if you do, and if that has been updated recently by the IEEE,
it would be safe to use the IEEE one as a normative reference.

Anoop


Received: from mailserv.hatterasnetworks.com (mailserv.hatterasnetworks.com [63.89.58.4]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j41DZl609941 for <[e-mail]>; Sun, 1 May 2005 06:35:48 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Date: Sun, 1 May 2005 09:35:41 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: rbridge Digest, Vol 11, Issue 5
Thread-Index: AcVNty1ZIKY+fv41Shumo9CPq7536gAmyeO6
From: "Matt Squire" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by boreas.isi.edu id j41DZl609941
Subject: Re: [rbridge] rbridge Digest, Vol 11, Issue 5
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-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, 01 May 2005 13:36:22 -0000
Status: RO
Content-Length: 325

 
All IEEE specifications are available free in electronic PDF form after being published for 6 months.  See http://standards.ieee.org/getieee802/.  
 
- Matt

	
	AFAIK one has to pay to access the IEEE 802.1 standards documents, and
	googling for the relevant terms seem to find mostly things about some
	TRILL BoF :-)