[rbridge] Get IEEE 802, RE: (no subject)

[erik.nordmark at sun.com (Erik Nordmark)]

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.

    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 j413aX615498 for <[e-mail]>; Sat, 30 Apr 2005 20:36:33 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.87.130]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j413aWi7004214 for <[e-mail]>; Sat, 30 Apr 2005 21:36:32 -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 j413aUTW308874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Apr 2005 20:36:32 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sat, 30 Apr 2005 20:36:32 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
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: Sun, 01 May 2005 03:37:20 -0000
Status: RO
Content-Length: 522

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.

    Erik



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 j413R2613265; Sat, 30 Apr 2005 20:27:02 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sat, 30 Apr 2005 20:26: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: <[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="------------enigCC14C6C18E1DFC6AEE2991BD"
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: Sun, 01 May 2005 03:27:50 -0000
Status: RO
Content-Length: 1269

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



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

> 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 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)=
=2E

Joe


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

iD8DBQFCdEyAE5f5cImnZrsRAlT8AJ43rwH9vB06xaiV4wlabmIFLGabeACg2Zyh
pQO7jN1ZKBR+vZ5xOLYolrc=
=RyuR
-----END PGP SIGNATURE-----

--------------enigCC14C6C18E1DFC6AEE2991BD--


Received: from tm3.ca.alcatel.com (kanfw1.ottawa.alcatel.ca [192.75.23.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j3U54V625431 for <[e-mail]>; Fri, 29 Apr 2005 22:04:31 -0700 (PDT)
Received: from alcatel.com (localhost [127.0.0.1]) by tm3.ca.alcatel.com (8.13.0/8.13.0) with ESMTP id j3U54OlC026423; Sat, 30 Apr 2005 01:04:24 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Sat, 30 Apr 2005 01:04:03 -0400
From: Cheng-Yin Lee <[e-mail]>
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <p06200716be969e0fac11@[192.168.116.133]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] (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: Sat, 30 Apr 2005 05:05:20 -0000
Status: RO
Content-Length: 1312

Margaret,

Margaret Wasserman wrote:

> (6) How does this work relate to the new work in the IEEE on the
> Shortest Path Bridging PAR? This is a proposal in the IEEE to use an
> STP-based (or STP-like?) distance-vector-based protocol to allow for
> shortest path bridging.  Given the existence of this work in the
> IEEE, is TRILL still needed?  If so, why?  What properties (if any)
> does TRILL bring that make it worth doing in addition to the planned
> IEEE work?

My personal opinion is Shortest Path Bridging and TRILL will serve different
types of networks and markets.

My understanding of Shortest Path Bridging is that it is effectively like
distance vector [ although it assumes the same costs from source/root of tree
to destination and in the reverse path (symmetric routes), otherwise it is
reverse shortest path]. Hence, link state based TRILL should converge faster
in a richly connected, large network in the event of link/router node state
(not considering MAC addresses learning or updating, assuming a more scalable
way will be developed for this) changes.

In any case, if we may use this analogy,  both RIP and link state protocols
(OSPF/IS-IS ) are used today.
Perhaps in future, some networks may use Shortest Path Bridging while others
may use link state based TRILL.

Thanks
Cheng-Yin



Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j3U2mP624990 for <[e-mail]>; Fri, 29 Apr 2005 19:48:25 -0700 (PDT)
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j3U2r53k024616 for <[e-mail]>; Fri, 29 Apr 2005 19:53:07 -0700 (MST)
Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j3U2p3bh016854 for <[e-mail]>; Fri, 29 Apr 2005 21:51:03 -0500 (CDT)
Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id <1LP6ZSBJ>; Fri, 29 Apr 2005 22:48:21 -0400
Message-ID: <[e-mail]>
From: Eastlake III Donald-LDE008 <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Date: Fri, 29 Apr 2005 22:48:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [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: Sat, 30 Apr 2005 02:49:16 -0000
Status: RO
Content-Length: 603

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

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Erik Nordmark
Sent: Friday, April 29, 2005 9:02 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] (no subject)

...

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

...

    Erik


Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j3U11X600244 for <[e-mail]>; Fri, 29 Apr 2005 18:01:33 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.83.36]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j3U11XjG014107 for <[e-mail]>; Fri, 29 Apr 2005 18:01:33 -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 j3U11WRn117120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Apr 2005 18:01:32 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 29 Apr 2005 18:01:36 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <p06200716be969e0fac11@[192.168.116.133]>
In-Reply-To: <p06200716be969e0fac11@[192.168.116.133]>
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] (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: Sat, 30 Apr 2005 01:02:25 -0000
Status: RO
Content-Length: 6138

Margaret Wasserman wrote:

> (1) Is it (or is it not) a requirement/goal for the TRILL protocol to 
> be compatible with existing bridge/switch HW?  There are some folks 
> who would like to see TRILL defined in a way that would allow it to 
> be implemented as a SW upgrade to existing bridges/switches, but that 
> has implication for the protocol itself -- in particular, 
> decrementing a TTL or making any header changes on through traffic 
> would preclude this.

My personal take is that there are some key properties of TRILL that 
we'd want to preserve:
  - using a link state routing protocol
  - using encapsulation to carry packets between the trill devices
  - including a TTL in the encapsulation header as a "safety" should
    there be temporary routing loops

For instance, it would not make sense to me to change the TRILL approach 
to not have a ttl even if this provided a way to reuse some hardware, 
because it would change some rather fundamental architectural properties 
of TRILL.

Thus for somebody to build a trill device they'd need hardware that can 
insert and remove the encapsulation header and decrement ttl.

But if there are other issues that relate to hardware capability or 
ease, such as details of the encapsulation header (alignment, order of 
fields, etc), I suspect there is a lot of flexibility.

> (3) What (types of) mechanisms are needed for end station discovery? 
> There was a discussion on this on the list in early March, with the 
> apparent conclusion that we could use link-state for discovery of 
> directly connected nodes, but might need other mechanisms (probing?) 
> for detection of hosts connected via a hub or non-TRILL-aware bridge. 
> What mechanisms would be needed?  And what are the impacts of these 
> mechanisms on network traffic, route thrashing, etc.

I guess there are two related issues here. One is the protocol mechanism 
used to do station discovery, and the other is the degree of churn 
caused by this mechanism and whether or not this requires special 
considerations to avoid scaling issues.

In terms of the protocol mechanism, TRILL would need to support stations 
behind bridges, in which case it can't do much better than the existing 
bridge learning techniques (look at the source L2 address of received 
packets). But in such a case it might make sense to use holddown 
techniques to not cause routing updates due to station inactivity, yet 
be able to react quickly when the station moves to another rbridge.

For other types of attachments, for instance 802.11 or other protocols 
with a notion of associations, there is the option to integrate the 
rbridge functionality in the access point. In such a case the 
propagation of the L2 address into the rbridge routing can be driven 
directly by the host completing the association with the AP. This would 
offer a slight improvement over the AP/bridge interaction today, where 
the host has to send a broadcast packet to cause the bridges in the 
network to be updated with its new location.

I guess it is too early to understand the performance tradeoffs between 
the different possible approaches for how the information is learned, 
how it is timed out or updated, and when this information is added and 
removed from the trill routing information.

> (4) Which properties (if any) of the Ethernet service model may be 
> compromised or modified by TRILL.  The Ethernet service model 
> includes properties such as in-order delivery of packets, no packet 
> duplication and timing limits (among other things?  Bernard, is there 
> a definitive reference for this?).  What changes for TRILL-connected 
> links?  And, what effect would those changes have on protocols that 
> may depend on the existing Ethernet service model (such as (R)STP, 
> VLANs, ARP, ND, SEND, EAP methods, DNA...)?

For the rest of the list: The IESG and IEEE 802 had some discussions 
about this and the notes are at 
<http://www.drizzle.com/~aboba/IEEE/minutes0408.txt>

My take is that TRILL needs to document the service mode it provides.

My understanding is that IEEE 802.1 changed the service model when they 
developed RSTP, so that packet reordering and duplication is acceptable 
when there is a topology change (i.e., some bridge, port or link failing 
or being brought up).

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

> (5) Will a new (or substantially modified) routing paradigm be 
> required to do scalable Ethernet routing?  Or can this be 
> accomplished with current routing protocols, perhaps with limited 
> extensions?

I'll let Radia answer this one.

> (6) How does this work relate to the new work in the IEEE on the 
> Shortest Path Bridging PAR? This is a proposal in the IEEE to use an 
> STP-based (or STP-like?) distance-vector-based protocol to allow for 
> shortest path bridging.  Given the existence of this work in the 
> IEEE, is TRILL still needed?  If so, why?  What properties (if any) 
> does TRILL bring that make it worth doing in addition to the planned 
> IEEE work?

For those that haven't see the new PAR, it is at
<http://www.ieee802.org/1/files/public/docs2005/new-seaman-shortest-path-0305-02.pdf>

I'd be interested in what other folks think of the relationship between 
this proposed work in IEEE 802.1 and the TRILL work.

 From a quick look, the PAR doesn't seem to address the 
zero-configuration goal we've talked about for TRILL. The shortest path 
bridges need to be configured with the VLAN ID they use for their 
"personal" shortest path tree.

The fact that the PAR overloads the VLAN ID as an identifier for each 
shortest path tree, seems to mean that the product of the number of 
VLANs and the number of (shortest path) bridges might be limited to a 
total of 4096. Thus if somebody is currently using 1024 VLANs, they can 
only have 4 shortest path bridges, which seems very limiting. This seems 
quite counter to the requests we had from Alex Zinin to think about 
scalability to reasonably large networks in the context of TRILL.

    Erik


Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j3THMf622246 for <[e-mail]>; Fri, 29 Apr 2005 10:22:41 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1362A5D945 for <[e-mail]>; Fri, 29 Apr 2005 19:22:35 +0200 (CEST)
Received: from [127.0.0.1] (vpn-252-228.uc3m.es [163.117.252.228]) by smtp01.uc3m.es (Postfix) with ESMTP id A3ECD5D91C for <[e-mail]>; Fri, 29 Apr 2005 19:22:33 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 29 Apr 2005 19:22:31 +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: [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] 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, 29 Apr 2005 17:23:14 -0000
Status: RO
Content-Length: 213

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
Univ. Carlos III Madrid


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 j3SFEs601402; Thu, 28 Apr 2005 08:14:54 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 28 Apr 2005 08:14: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: <p06200716be969e0fac11@[192.168.116.133]>
In-Reply-To: <p06200716be969e0fac11@[192.168.116.133]>
X-Enigmail-Version: 0.91.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDB5BA3E1932C8776569D4544"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] (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: Thu, 28 Apr 2005 15:15:36 -0000
Status: RO
Content-Length: 5936

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



Margaret Wasserman wrote:
> As most of you probably know, the IESG has been talking about 
> chartering a TRILL WG.  There were some issues raised in response to 
> the initial charter announcement that we are working through, but in 
> the meantime, it would be great to continue the technical discussions 
> on this list and to document the results of our discussions, either 
> in a separate framework/architecture document and/or in an updated 
> version of the rbridge proposal.
> 
> I, personally, have a number of technical questions about TRILL.  I 
> think it would be helpful to discuss and answer these questions 
> within the TRILL group:
> 
> (1) Is it (or is it not) a requirement/goal for the TRILL protocol to 
> be compatible with existing bridge/switch HW?  There are some folks 
> who would like to see TRILL defined in a way that would allow it to 
> be implemented as a SW upgrade to existing bridges/switches, but that 
> has implication for the protocol itself -- in particular, 
> decrementing a TTL or making any header changes on through traffic 
> would preclude this.

An update to the rbridge I-D will be available very shortly; Radia,
Alper, and I have been doing last-minute checks on it this week.

The protocol does not modify the incoming packet - L2 or L3. It thus
supports incremental deployment and upgrade, though benefit of those
upgrades depends on linking the upgraded systems together as a 'campus'.
 The way a campus works may limit which upgraded systems can be linked
together - i.e., it *may* limit non-upgraded bridges to connect to only
one campus bridge, etc. So such upgrades may have impact only after
enough of a topology is available to make an appropriate campus.

I'm not as familiar with VLAN issues as Radia is, so she might speak to
these issues:

> (2) How will TRILL be compatible with existing (dynamic and 
> non-dynamic) VLANs?  There are really a few questions here:
> 
> (a) Is TRILL expected to run entirely under, and be invisible to, 
> existing IEEE 802 VLANs (as a replacement for (R)STP, but not for 
> VLAN)?  If so, how does TRILL address (or even pertain) to the subnet 
> limitations of current VLANs?  Eliminating this limit was discussed 
> in Radia's talk on the benefits of TRILL, but maybe our thinking has 
> evolved to the point where that no longer applies?
> 
> (b) If it doesn't run entirely under existing IEEE 802 VLANs, how 
> does TRILL handle IP subnetting and limitation of broadcast/multicast 
> domains?
> 
> (c) If TRILL does run under existing IEEE 802 VLANs, is there any 
> means to avoid unnecessary duplication of broadcast/multicast traffic 
> across TRILL-connected "links".  Is avoiding this traffic necessary 
> for the protocol?  Or merely a nice-to-have?
> 
> (d) How will TRILL interoperate with dynamic VLANs?  In particular, 
> how will TRILL work with dynamic VLANs when hosts move from one part 
> of a wireless network to another?  Today, those hosts retain their IP 
> addresses and current connections by being detected at a new location 
> and attached to a dynamic VLAN in that location.  Will this work over 
> TRILL-connected links?  What will be the impact (if any) on the time 
> it takes to establish bridging to the new location? (I'm not sure 
> that there are any issues here, I just don't understand enough about 
> how dynamic VLANs work (yet) to know if there are any).
> 
> (3) What (types of) mechanisms are needed for end station discovery? 
> There was a discussion on this on the list in early March, with the 
> apparent conclusion that we could use link-state for discovery of 
> directly connected nodes, but might need other mechanisms (probing?) 
> for detection of hosts connected via a hub or non-TRILL-aware bridge. 
> What mechanisms would be needed?  And what are the impacts of these 
> mechanisms on network traffic, route thrashing, etc.
> 
> (4) Which properties (if any) of the Ethernet service model may be 
> compromised or modified by TRILL.  The Ethernet service model 
> includes properties such as in-order delivery of packets, no packet 
> duplication and timing limits (among other things?  Bernard, is there 
> a definitive reference for this?).  What changes for TRILL-connected 
> links?  And, what effect would those changes have on protocols that 
> may depend on the existing Ethernet service model (such as (R)STP, 
> VLANs, ARP, ND, SEND, EAP methods, DNA...)?
> 
> (5) Will a new (or substantially modified) routing paradigm be 
> required to do scalable Ethernet routing?  Or can this be 
> accomplished with current routing protocols, perhaps with limited 
> extensions?
> 
> (6) How does this work relate to the new work in the IEEE on the 
> Shortest Path Bridging PAR? This is a proposal in the IEEE to use an 
> STP-based (or STP-like?) distance-vector-based protocol to allow for 
> shortest path bridging.  Given the existence of this work in the 
> IEEE, is TRILL still needed?  If so, why?  What properties (if any) 
> does TRILL bring that make it worth doing in addition to the planned 
> IEEE work?
> 
> Thanks,
> Margaret
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge

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

iD8DBQFCcP3pE5f5cImnZrsRAqGAAJ4pFFFuxc1igI4dnuFxyMydOrhKCACgpixZ
kfBcrotHv0Ph06kzMTDCoxw=
=zC1X
-----END PGP SIGNATURE-----

--------------enigDB5BA3E1932C8776569D4544--


Received: from thingmagic.com (tm-gw2.cictr.com [204.9.221.21] (may be forged)) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j3SELI614792 for <[e-mail]>; Thu, 28 Apr 2005 07:21:18 -0700 (PDT)
Received: from [212.147.29.57] (account margaret HELO [192.168.116.133]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 355718 for [e-mail]; Thu, 28 Apr 2005 10:17:29 -0400
Mime-Version: 1.0
Message-Id: <p06200716be969e0fac11@[192.168.116.133]>
Date: Thu, 28 Apr 2005 10:20:48 -0400
To: [e-mail]
From: Margaret Wasserman <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] (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: Thu, 28 Apr 2005 14:22:09 -0000
Status: RO
Content-Length: 4205

As most of you probably know, the IESG has been talking about 
chartering a TRILL WG.  There were some issues raised in response to 
the initial charter announcement that we are working through, but in 
the meantime, it would be great to continue the technical discussions 
on this list and to document the results of our discussions, either 
in a separate framework/architecture document and/or in an updated 
version of the rbridge proposal.

I, personally, have a number of technical questions about TRILL.  I 
think it would be helpful to discuss and answer these questions 
within the TRILL group:

(1) Is it (or is it not) a requirement/goal for the TRILL protocol to 
be compatible with existing bridge/switch HW?  There are some folks 
who would like to see TRILL defined in a way that would allow it to 
be implemented as a SW upgrade to existing bridges/switches, but that 
has implication for the protocol itself -- in particular, 
decrementing a TTL or making any header changes on through traffic 
would preclude this.

(2) How will TRILL be compatible with existing (dynamic and 
non-dynamic) VLANs?  There are really a few questions here:

(a) Is TRILL expected to run entirely under, and be invisible to, 
existing IEEE 802 VLANs (as a replacement for (R)STP, but not for 
VLAN)?  If so, how does TRILL address (or even pertain) to the subnet 
limitations of current VLANs?  Eliminating this limit was discussed 
in Radia's talk on the benefits of TRILL, but maybe our thinking has 
evolved to the point where that no longer applies?

(b) If it doesn't run entirely under existing IEEE 802 VLANs, how 
does TRILL handle IP subnetting and limitation of broadcast/multicast 
domains?

(c) If TRILL does run under existing IEEE 802 VLANs, is there any 
means to avoid unnecessary duplication of broadcast/multicast traffic 
across TRILL-connected "links".  Is avoiding this traffic necessary 
for the protocol?  Or merely a nice-to-have?

(d) How will TRILL interoperate with dynamic VLANs?  In particular, 
how will TRILL work with dynamic VLANs when hosts move from one part 
of a wireless network to another?  Today, those hosts retain their IP 
addresses and current connections by being detected at a new location 
and attached to a dynamic VLAN in that location.  Will this work over 
TRILL-connected links?  What will be the impact (if any) on the time 
it takes to establish bridging to the new location? (I'm not sure 
that there are any issues here, I just don't understand enough about 
how dynamic VLANs work (yet) to know if there are any).

(3) What (types of) mechanisms are needed for end station discovery? 
There was a discussion on this on the list in early March, with the 
apparent conclusion that we could use link-state for discovery of 
directly connected nodes, but might need other mechanisms (probing?) 
for detection of hosts connected via a hub or non-TRILL-aware bridge. 
What mechanisms would be needed?  And what are the impacts of these 
mechanisms on network traffic, route thrashing, etc.

(4) Which properties (if any) of the Ethernet service model may be 
compromised or modified by TRILL.  The Ethernet service model 
includes properties such as in-order delivery of packets, no packet 
duplication and timing limits (among other things?  Bernard, is there 
a definitive reference for this?).  What changes for TRILL-connected 
links?  And, what effect would those changes have on protocols that 
may depend on the existing Ethernet service model (such as (R)STP, 
VLANs, ARP, ND, SEND, EAP methods, DNA...)?

(5) Will a new (or substantially modified) routing paradigm be 
required to do scalable Ethernet routing?  Or can this be 
accomplished with current routing protocols, perhaps with limited 
extensions?

(6) How does this work relate to the new work in the IEEE on the 
Shortest Path Bridging PAR? This is a proposal in the IEEE to use an 
STP-based (or STP-like?) distance-vector-based protocol to allow for 
shortest path bridging.  Given the existence of this work in the 
IEEE, is TRILL still needed?  If so, why?  What properties (if any) 
does TRILL bring that make it worth doing in addition to the planned 
IEEE work?

Thanks,
Margaret


Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j38LiN610330 for <[e-mail]>; Fri, 8 Apr 2005 14:44:23 -0700 (PDT)
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 08 Apr 2005 14:44:15 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j38LhigU010076 for <[e-mail]>; Fri, 8 Apr 2005 14:44:10 -0700 (PDT)
Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 14:44:09 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Date: Fri, 8 Apr 2005 14:44:09 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Draft Minneapolis minutes
Thread-Index: AcU8f2JRclUmE/xPTMKvzc2O4dVGOgAAx4Bw
From: "Michael Smith \(michsmit\)" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 08 Apr 2005 21:44:09.0873 (UTC) FILETIME=[18C35010:01C53C84]
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 j38LiN610330
Subject: Re: [rbridge] Draft Minneapolis minutes
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, 08 Apr 2005 21:44:55 -0000
Status: RO
Content-Length: 3006

Erik,
My apologies, I went back and looked at the presentation.  The text
should not be removed.  It is as presented.  In the meeting, I raised
the point that the text is technically incorrect (meaning reordering is
not only during network topology changes).  My point below is that which
was discussed in the meeting when it was presented.

Thanks,
Michael

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Erik Nordmark
> Sent: Friday, April 08, 2005 2:05 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Draft Minneapolis minutes
> 
> Michael Smith (michsmit) wrote:
> 
> >>Goals:
> >>zero configuration,
> >>hosts can move without changing IP address, use best 
> pair-wise paths 
> >>and be able to load split, maybe optimize ARP / ND (don't always 
> >>flood), secure ND, hop count to reduce damage from loops, multiple 
> >>external attachment point support, no delay for new host 
> attachment, 
> >>support for multicast, to be no less secure than existing 
> bridges, no 
> >>changes to hosts, routers, or L2 bridges, support non-IP protocols, 
> >>handle IPv4&6, maybe interconnect different L2 technologies.
> >>There are lots of questions about mobility, which goals are high 
> >>level, etc.
> >>LAN Service is:
> >>broadcast domain,
> >>small probability of reordering and duplication (basically 
> only when 
> >>topology changes),
> > 
> > 
> > The text "basically only when topology changes" should be removed.
> > 
> > Rbridging will reorder during a stable topology.  The reordering in 
> > rbridges happens when learning occurs.  This is independent of 
> > topology changes.
> 
> Michael,
> 
> I don't understand the nature of your comment. The above are 
> notes from the presentation about the goals of TRILL. So are 
> you saying that 1. The minutes are incorrect, because that 
> presentation said something different?
> 2. That the goals are unreasonable and a WG should have 
> different goals?
> 3. That a particular proposed solution for TRILL might not 
> satisfy the goals?
> 
> Only #1 would be appropriate comments on the minutes, since 
> their purpose is to record what was presented/discussed at 
> the meeting.
> 
> > The point argued is that with today's rapid spanning tree there is 
> > only a remote chance of reordering and that is only during 
> a topology change.
> > Traditional spanning tree has no such reordering 
> whatsoever.  Learning 
> > occurs much more frequently as the L2 tables reach capacity due to 
> > churn of entries.  This would cause rbridges to reorder more 
> > frequently as the
> > L2 tables reach capacity (still a stable network topology).  The 
> > discussion was questioning whether the probability can be viewed as 
> > small.
> 
> This sure sounds like you are making point #3 above.
> 
>    Erik
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
> 


Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j38LYX608272 for <[e-mail]>; Fri, 8 Apr 2005 14:34:33 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j38LYWXi020749 for <[e-mail]>; Fri, 8 Apr 2005 15:34:32 -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]; Fri, 08 Apr 2005 17:34:32 -0400 (EDT)
Received: from sun.com (vpn-129-150-25-194.SFBay.Sun.COM [129.150.25.194]) 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]; Fri, 08 Apr 2005 17:34:32 -0400 (EDT)
Date: Fri, 08 Apr 2005 14:34:32 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
References: <[e-mail]> <[e-mail]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] reordering
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, 08 Apr 2005 21:34:56 -0000
Status: RO
Content-Length: 2641

Michael Smith said:

>>
>>Rbridging will reorder during a stable topology.  The reordering in
>>rbridges happens when learning occurs.  This is independent of topology
>>changes.  
>>    
>>
To explain to the technical point you are raising to the llist (because it's
not really a change to the minutes, but is instead a technical point 
that should
be discussed on the list), the strawman draft design does have that 
property, because when endnode A
talks to endnode B, if the RBridges do not yet know where B is, they 
will send it on
a spanning tree, and when they do find out who the egress RBridge is, 
they will send it directly.

A variant that has been discussed is to use the link state information 
to calculate a per-ingress
RBridge spanning tree. Then all the paths will be optimal (except during
topology change). But of course it is more expensive
to calculate all those trees. So it's an engineering tradeoff. MOSPF 
calculated per-source
spanning trees, by the way.

All this stuff is an engineering tradeoff, so we shouldn't necessarily 
assume one thing is
cast in stone if we find out it precludes other good properties. I asked 
what protocols
still depend on in-order delivery, and it didn't seem like a lot of them 
do. And in the
installations with SNA or whatever legacy protocols we're talking about, 
they're not
forced to use RBridges...they could stick with standard bridges.

I'd hope modern protocols are not being designed that would break if 
packets get
reordered.

And if it's OK to sometimes reorder (when topology changes), then I'd 
think it couldn't
be fatal to reorder at other times too.

So, could someone list the protocols that break with reordering, and how 
widely
deployed they are, and whether they need the features of RBridge, or are 
doing just
fine with bridges?

If they are important, AND if they need the features of RBridges rather than
bridges, then RBridges could send unknown destination frames to
a spanning tree rooted at the ingress RBridge, and that would solve the 
problem.

The question again is, are these protocols worth the cost of computing 
all these extra trees?

On the upside if it's considered important enough to do all these trees,
the cost of the extra trees is totally internal to the RBridge (computation,
extra forwarding tables).

And on another upside of the extra trees...for multicast packets for 
high-bandwidth
applications (which will usually be IP multicast applications, so will 
be using IGMP),
having per-ingress RBridge trees, plus pruning based on IGMP snooping, 
will minimize
the number of packet-hops necessary to distribute that data.

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 j38L5t600704 for <[e-mail]>; Fri, 8 Apr 2005 14:05:55 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.81.36]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j38L5sK2017278 for <[e-mail]>; Fri, 8 Apr 2005 15:05:55 -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 j38L5rt6724740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Apr 2005 14:05:54 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 08 Apr 2005 14:05:38 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Draft Minneapolis minutes
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, 08 Apr 2005 21:06:56 -0000
Status: RO
Content-Length: 1075

Radia Perlman wrote:
> A couple of corrections:
> 
> Under "VLANs" you don't say what was presented, just the discussion 
> afterwards.
> Here's a summary of what was presented:
> 
> Presented a modified design, where the "egress RBridge" is included in 
> the header
> (between the outer header, which bridges would see, and the inner frame 
> which is
> exactly as transmitted by the endnode). Forwarding is to the egress 
> RBridge.
> This enables the core to forward solely based on egress RBridge, and not 
> need
> to have endnode addresses in forwarding tables. It also means that only 
> RBridges
> attached to a particular VLAN need to know about the endnodes in that VLAN.

I'll add that.

> So for simplicity, I'd remove:
> 
> Radia Perlman: I wasn't provided with the whole problem, just told to
> develop a spanning protocol.
> 
> and replace it with:
> Radia Perlman: At that point in time they would never have
> considered adding an encapsulation header. It would have made
> the devices too complex and there were hard limits on
> frame sizes.

ok

    Erik


Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j38L4u600144 for <[e-mail]>; Fri, 8 Apr 2005 14:04:56 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.89.31]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j38L4tXi003694 for <[e-mail]>; Fri, 8 Apr 2005 15:04:56 -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 j38L4rqD724201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Apr 2005 14:04:54 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 08 Apr 2005 14:04:38 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Draft Minneapolis minutes
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, 08 Apr 2005 21:05:57 -0000
Status: RO
Content-Length: 2109

Michael Smith (michsmit) wrote:

>>Goals:
>>zero configuration,
>>hosts can move without changing IP address, use best 
>>pair-wise paths and be able to load split, maybe optimize ARP 
>>/ ND (don't always flood), secure ND, hop count to reduce 
>>damage from loops, multiple external attachment point 
>>support, no delay for new host attachment, support for 
>>multicast, to be no less secure than existing bridges, no 
>>changes to hosts, routers, or L2 bridges, support non-IP 
>>protocols, handle IPv4&6, maybe interconnect different L2 
>>technologies.
>>There are lots of questions about mobility, which goals are 
>>high level, etc.
>>LAN Service is:
>>broadcast domain,
>>small probability of reordering and duplication (basically 
>>only when topology changes), 
> 
> 
> The text "basically only when topology changes" should be removed.
> 
> Rbridging will reorder during a stable topology.  The reordering in
> rbridges happens when learning occurs.  This is independent of topology
> changes.  

Michael,

I don't understand the nature of your comment. The above are notes from 
the presentation about the goals of TRILL. So are you saying that
1. The minutes are incorrect, because that presentation said something 
different?
2. That the goals are unreasonable and a WG should have different goals?
3. That a particular proposed solution for TRILL might not satisfy the 
goals?

Only #1 would be appropriate comments on the minutes, since their 
purpose is to record what was presented/discussed at the meeting.

> The point argued is that with today's rapid spanning tree there is only
> a remote chance of reordering and that is only during a topology change.
> Traditional spanning tree has no such reordering whatsoever.  Learning
> occurs much more frequently as the L2 tables reach capacity due to churn
> of entries.  This would cause rbridges to reorder more frequently as the
> L2 tables reach capacity (still a stable network topology).  The
> discussion was questioning whether the probability can be viewed as
> small.

This sure sounds like you are making point #3 above.

   Erik


Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j38KAG617359 for <[e-mail]>; Fri, 8 Apr 2005 13:10:16 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j38KAFXi028580 for <[e-mail]>; Fri, 8 Apr 2005 14:10:16 -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]; Fri, 08 Apr 2005 16:10:15 -0400 (EDT)
Received: from sun.com (vpn-129-150-25-194.SFBay.Sun.COM [129.150.25.194]) 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]; Fri, 08 Apr 2005 16:10:15 -0400 (EDT)
Date: Fri, 08 Apr 2005 13:10:15 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
References: <[e-mail]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Draft Minneapolis minutes
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, 08 Apr 2005 20:10:58 -0000
Status: RO
Content-Length: 1483

A couple of corrections:

Under "VLANs" you don't say what was presented, just the discussion 
afterwards.
Here's a summary of what was presented:

Presented a modified design, where the "egress RBridge" is included in 
the header
(between the outer header, which bridges would see, and the inner frame 
which is
exactly as transmitted by the endnode). Forwarding is to the egress 
RBridge.
This enables the core to forward solely based on egress RBridge, and not 
need
to have endnode addresses in forwarding tables. It also means that only 
RBridges
attached to a particular VLAN need to know about the endnodes in that VLAN.

******
As for my answer to Bob Hinden...the comment in the minutes was really 
sort of
a joke that I was making, and not the real answer. After I made the 
comment about
being guilty of doing what is one of my pet peeves (solving one thing 
rather than
looking at the bigger picture), I said what the real answer was, which
was that at that point in time they would never have considered adding
an encapsulation header. It would have made the devices too complex, and 
there were
hard limits on frame sizes.

So for simplicity, I'd remove:

Radia Perlman: I wasn't provided with the whole problem, just told to
develop a spanning protocol.

and replace it with:
Radia Perlman: At that point in time they would never have
considered adding an encapsulation header. It would have made
the devices too complex and there were hard limits on
frame sizes.






Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j38IdF620764 for <[e-mail]>; Fri, 8 Apr 2005 11:39:15 -0700 (PDT)
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 08 Apr 2005 11:38:40 -0700
X-IronPort-AV: i="3.92,88,1112598000";  d="scan'208"; a="247671012:sNHT2035657616"
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j38IbpER021309 for <[e-mail]>; Fri, 8 Apr 2005 11:38:38 -0700 (PDT)
Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 11:38:36 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Date: Fri, 8 Apr 2005 11:38:36 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Draft Minneapolis minutes
Thread-Index: AcU8YNgVegMfwovMR4S77kN/O8KwhQABvRsA
From: "Michael Smith \(michsmit\)" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 08 Apr 2005 18:38:36.0808 (UTC) FILETIME=[2CF06880:01C53C6A]
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 j38IdF620764
Subject: Re: [rbridge] Draft Minneapolis minutes
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, 08 Apr 2005 18:40:43 -0000
Status: RO
Content-Length: 9316

Erik,
One comment inline. 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Erik Nordmark
> Sent: Friday, April 08, 2005 10:23 AM
> To: [e-mail]
> Subject: [rbridge] Draft Minneapolis minutes
> 
> 
> I just realized I need to get these submitted today. So 
> please send in any corrections you have.
> 
>     Erik
> 
> TRILL
> BoF Chair Erik Nordmark <[e-mail]>
> 
> 1. Welcome and Administrivia, Erik Nordmark
> -------------------------------------------
> 
> Scribe: Donald Eastlake, ...
> 
> 2. Problem statement discussion, Erik Nordmark
> ----------------------------------------------
> 
> Including the "service" that a cloud of hybrid devices will 
> provide, whether it is equivalent to IEEE 802.1D devices, or 
> handles IP packets differently.
> When is it ok to reorder packets? MTU considerations?
> 
> L2 solutions have many benefits. Will use IEEE 802 networks 
> as an example but can apply to Fibrechannel, MPLS, etc.
> We also have L3 technology which may provide benefits in 
> terms of robustness, etc.
> There is a desire to combine the above to create best of both 
> worlds for a LAN (where a LAN is approximately a broadcast 
> domain). Motivations:
> better robustness, better aggregate bandwidth than L2 
> bridges, better latency, user of shortest path, ability to 
> interconnect different L2 types?, bigger LANs?
> 
> TRILL Model
> Goals:
> zero configuration,
> hosts can move without changing IP address, use best 
> pair-wise paths and be able to load split, maybe optimize ARP 
> / ND (don't always flood), secure ND, hop count to reduce 
> damage from loops, multiple external attachment point 
> support, no delay for new host attachment, support for 
> multicast, to be no less secure than existing bridges, no 
> changes to hosts, routers, or L2 bridges, support non-IP 
> protocols, handle IPv4&6, maybe interconnect different L2 
> technologies.
> There are lots of questions about mobility, which goals are 
> high level, etc.
> LAN Service is:
> broadcast domain,
> small probability of reordering and duplication (basically 
> only when topology changes), 

The text "basically only when topology changes" should be removed.

Rbridging will reorder during a stable topology.  The reordering in
rbridges happens when learning occurs.  This is independent of topology
changes.  

The point argued is that with today's rapid spanning tree there is only
a remote chance of reordering and that is only during a topology change.
Traditional spanning tree has no such reordering whatsoever.  Learning
occurs much more frequently as the L2 tables reach capacity due to churn
of entries.  This would cause rbridges to reorder more frequently as the
L2 tables reach capacity (still a stable network topology).  The
discussion was questioning whether the probability can be viewed as
small.


>MTU (most LANs have uniform MTUs).
> Question of fitting L2 info into current size caches...
> Q: What about wireless?
> Nordmark: TRILL is independent of whether links are wireless.
> Which LAN service does IP need?
> Some special cases for IPv4/IPv6 ARP may improve service but 
> perhaps it is better if ARP doesn't need special treatment.
> 
> 3. Threats and security considerations, Marcelo Bagnulo.
> --------------------------------------------------------
> 
> Security goals: minimum is same as current bridges.
> New features may enable usage beyond the capabilities of 
> classic bridges.
> ...
> Examples of attacks presented for bridges and Rbridges.
> Q: Does this security analysis take into account all of the 
> ongoing and proposed security and QoS work in IEEE 802.1?
> Nordmark: No.
> Q: Why are we considering these details presuming a solution?
> Nordmark: It is good to start considering security from the beginning.
> Mark Townsley: This is a little deep for this stage although 
> some good things came out of it. Let's move on.
> 
> 4. ARP/ND and Broadcast/Multicast Issues
> ----------------------------------------
> 
> Joe Touch and Yu-Shun Wang (presented by Yu-Shun Wang as Joe 
> Touch had a
> conflict)
> Various questions of exact size of network, what a campus 
> means, what a bridge is, what the goals are, ... DAD ... DNA 
> ... Real networks all have VLANs.
> Q: How can you detect a device if it's moving and not 
> connected and someone takes its MAC address?
> Wang: Not worried about MAC addresses, I was talking about 
> IPv4/6 addresses.
> Q: Are you trying to solve duplicate MAC address problem?
> Wang: No.
> 
> 5. Requirements on routing protocols, Alex Zinin, [e-mail]
> ---------------------------------------------------------------
> 
> Alex presented considerable material on scalability functions 
> for different types of overhead.
> Paul Congdon: Do you consider dynamic VLAN formation in the core?
> Zinin: No, only static VLAN in my analysis so far.
> ...
> Margaret Wasserman: Do you have a comparison with RSTP?
> Zinin: Not in this presentation.
> ...
> Reachability is less volatile than activity.
> ...
> Advantages of reachability. "CNLS(?)" announces all hosts and works.
> The built in protocol limits on update rates are not enough 
> to assure stability.
> Recommend using a single routing instance over all VLANs but 
> restricted flooding of information only to nodes that need 
> that information.
> Q: Are you assuming station number scales with VLANs?
> A: No, but there are typically more stations in systems with 
> many VLANs.
> 
> 6. TRILL issue: VLANs, Radia Perlman
> ------------------------------------
> ...
> Margaret Wasserman: Would Rbridge flooding zones be IP subnets?
> Radia Perlman: No. [Later Radia posted an email saying that 
> different Rbridge VLANs would be separate IP subnets.]
> Wasserman: What would happen with mobility?
> Perlman: You can keep same IP if you move.
> Comment: All this should be compared with what's in 802.1, 
> 802.1ah, MAC in MAC encapsulation, etc.
> Q: GVRPN MAC tunneling... Is there parallel work in L2VPN?
> Daly: Reminds me of similar aspects of RFC 2357(?) Like MPLS.
> Q: What is the scope? Looks like BGPv3, ..., in same enterprise.
> Nordmark: This is not being proposed for the Internet backbone.
> Q: Is there a conflict with L2VPN? Both seem to be used for 
> aggregation.
> 
> 7. Connecting different L2 types, Radia Perlman
> -----------------------------------------------
> 
> Forwarding between different link types works for IP but 
> probably too hard in general for incompatible link types. 
> This presentation of mine is to try to convince people NOT to 
> include Rbridging different types of links in the scope of 
> the proposed WG.
> Comments: All comments made opposed doing this between 
> different types of links.
> 
> 8. Discussion
> -------------
> 
> Nordmark: The intended network scope where this would be 
> applied is not "provider" but "local".
> Comment: "Provider" is not the same as "wide area".
> Comment: We should figure out what has been done elsewhere.
> Nordmark: I've been looking for that. No one else is doing 
> shortest path.
> Comment: Big overlap with L2VPN. VPLS area in L2VPN. Shortest 
> path for unicast. GMPLS. Issues with packet re-ordering and 
> MAC address. The alternative of encapsulating in IP header 
> means you can then just use IP on intermediate nodes so only 
> edge devices need to learn MAC addresses.
> Nordmark: But IP does not autoconfigure.
> Paul Congdon: There seems to be more awareness of what 802.1 is doing.
> Original list of goals included shortest path. That is not 
> addressed by IEEE 802.1 but I think the other goals are 
> addressed by 802.1.
> Nordmark: Link state with limited flooding would solve 
> scalability. That technique might also fit into L2VPN.
> Bob Hinden: Haven't heard clear case as to why this is better 
> than alternatives.
> Nordmark: shortest path, nothing else provides it.
> Hinden: You can do a lot of things with routers, can you do 
> something better with them?
> Nordmark: We've tried that with the ZROUTER BoF. I was there. 
> But you still have to change address when you move.
> Hinden to Radia: Why didn't you invent this when you invented 
> STP (the spanning tree protocol)?
> Radia Perlman: I wasn't provided with the whole problem, just 
> told to develop a spanning protocol.
> Zinin: Big difference between this and L2VPN is that L2VPN 
> uses IP while this defines forwarding and routing in L2. X 
> does solve the problem with state in core devices but that's 
> not the problem. Critical problem is edge bridge problem. 
> Would rather try to solve problem with IP.
> Nordmark: We tried that and gave up.
> Margaret Wasserman: How many in the room are on the rbridge 
> mailing list and read it? (Many hand go up.)
> Wasserman: How many have support from their management to 
> work on this?
> Quite a few indicate they do.)
> Wasserman: Three choice poll:
> (1) ready to work on this,
> (2) interesting think but we need to look further,
> (3) no work should be done on this in the IETF.
> (1)	~10.
> (2)	Many
> (3)	~12.
> Wasserman: The rough consensus is to look into this further.
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
> 


Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j38HN0629008 for <[e-mail]>; Fri, 8 Apr 2005 10:23:00 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.85.105]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j38HMxXi023425 for <[e-mail]>; Fri, 8 Apr 2005 11:23:00 -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 j38HMwee624980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Apr 2005 10:22:58 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 08 Apr 2005 10:22:42 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
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: [rbridge] Draft Minneapolis minutes
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, 08 Apr 2005 17:23:54 -0000
Status: RO
Content-Length: 7721

I just realized I need to get these submitted today. So please send in
any corrections you have.

    Erik

TRILL
BoF Chair Erik Nordmark <[e-mail]>

1. Welcome and Administrivia, Erik Nordmark
-------------------------------------------

Scribe: Donald Eastlake, ...

2. Problem statement discussion, Erik Nordmark
----------------------------------------------

Including the "service" that a cloud of hybrid devices will provide,
whether it is equivalent to IEEE 802.1D devices, or handles IP packets
differently.
When is it ok to reorder packets? MTU considerations?

L2 solutions have many benefits. Will use IEEE 802 networks as an
example but can apply to Fibrechannel, MPLS, etc.
We also have L3 technology which may provide benefits in terms of
robustness, etc.
There is a desire to combine the above to create best of both worlds for
a LAN (where a LAN is approximately a broadcast domain). Motivations:
better robustness, better aggregate bandwidth than L2 bridges, better
latency, user of shortest path, ability to interconnect different L2
types?, bigger LANs?

TRILL Model
Goals:
zero configuration,
hosts can move without changing IP address,
use best pair-wise paths and be able to load split,
maybe optimize ARP / ND (don't always flood), secure ND,
hop count to reduce damage from loops,
multiple external attachment point support,
no delay for new host attachment,
support for multicast,
to be no less secure than existing bridges,
no changes to hosts, routers, or L2 bridges,
support non-IP protocols,
handle IPv4&6,
maybe interconnect different L2 technologies.
There are lots of questions about mobility, which goals are high level, etc.
LAN Service is:
broadcast domain,
small probability of reordering and duplication (basically only when
topology changes),
MTU (most LANs have uniform MTUs).
Question of fitting L2 info into current size caches...
Q: What about wireless?
Nordmark: TRILL is independent of whether links are wireless.
Which LAN service does IP need?
Some special cases for IPv4/IPv6 ARP may improve service but perhaps it
is better if ARP doesn't need special treatment.

3. Threats and security considerations, Marcelo Bagnulo.
--------------------------------------------------------

Security goals: minimum is same as current bridges.
New features may enable usage beyond the capabilities of classic bridges.
...
Examples of attacks presented for bridges and Rbridges.
Q: Does this security analysis take into account all of the ongoing and
proposed security and QoS work in IEEE 802.1?
Nordmark: No.
Q: Why are we considering these details presuming a solution?
Nordmark: It is good to start considering security from the beginning.
Mark Townsley: This is a little deep for this stage although some good
things came out of it. Let's move on.

4. ARP/ND and Broadcast/Multicast Issues
----------------------------------------

Joe Touch and Yu-Shun Wang (presented by Yu-Shun Wang as Joe Touch had a
conflict)
Various questions of exact size of network, what a campus means, what a
bridge is, what the goals are, ... DAD ... DNA ... Real networks all
have VLANs.
Q: How can you detect a device if it's moving and not connected and
someone takes its MAC address?
Wang: Not worried about MAC addresses, I was talking about IPv4/6 addresses.
Q: Are you trying to solve duplicate MAC address problem?
Wang: No.

5. Requirements on routing protocols, Alex Zinin, [e-mail]
---------------------------------------------------------------

Alex presented considerable material on scalability functions for
different types of overhead.
Paul Congdon: Do you consider dynamic VLAN formation in the core?
Zinin: No, only static VLAN in my analysis so far.
...
Margaret Wasserman: Do you have a comparison with RSTP?
Zinin: Not in this presentation.
...
Reachability is less volatile than activity.
...
Advantages of reachability. "CNLS(?)" announces all hosts and works.
The built in protocol limits on update rates are not enough to assure
stability.
Recommend using a single routing instance over all VLANs but restricted
flooding of information only to nodes that need that information.
Q: Are you assuming station number scales with VLANs?
A: No, but there are typically more stations in systems with many VLANs.

6. TRILL issue: VLANs, Radia Perlman
------------------------------------
...
Margaret Wasserman: Would Rbridge flooding zones be IP subnets?
Radia Perlman: No. [Later Radia posted an email saying that different
Rbridge VLANs would be separate IP subnets.]
Wasserman: What would happen with mobility?
Perlman: You can keep same IP if you move.
Comment: All this should be compared with what's in 802.1, 802.1ah, MAC
in MAC encapsulation, etc.
Q: GVRPN MAC tunneling... Is there parallel work in L2VPN?
Daly: Reminds me of similar aspects of RFC 2357(?) Like MPLS.
Q: What is the scope? Looks like BGPv3, ..., in same enterprise.
Nordmark: This is not being proposed for the Internet backbone.
Q: Is there a conflict with L2VPN? Both seem to be used for aggregation.

7. Connecting different L2 types, Radia Perlman
-----------------------------------------------

Forwarding between different link types works for IP but probably too
hard in general for incompatible link types. This presentation of mine
is to try to convince people NOT to include Rbridging different types of
links in the scope of the proposed WG.
Comments: All comments made opposed doing this between different types
of links.

8. Discussion
-------------

Nordmark: The intended network scope where this would be applied is not
"provider" but "local".
Comment: "Provider" is not the same as "wide area".
Comment: We should figure out what has been done elsewhere.
Nordmark: I've been looking for that. No one else is doing shortest path.
Comment: Big overlap with L2VPN. VPLS area in L2VPN. Shortest path for
unicast. GMPLS. Issues with packet re-ordering and MAC address. The
alternative of encapsulating in IP header means you can then just use IP
on intermediate nodes so only edge devices need to learn MAC addresses.
Nordmark: But IP does not autoconfigure.
Paul Congdon: There seems to be more awareness of what 802.1 is doing.
Original list of goals included shortest path. That is not addressed by
IEEE 802.1 but I think the other goals are addressed by 802.1.
Nordmark: Link state with limited flooding would solve scalability. That
technique might also fit into L2VPN.
Bob Hinden: Haven't heard clear case as to why this is better than
alternatives.
Nordmark: shortest path, nothing else provides it.
Hinden: You can do a lot of things with routers, can you do something
better with them?
Nordmark: We've tried that with the ZROUTER BoF. I was there. But you
still have to change address when you move.
Hinden to Radia: Why didn't you invent this when you invented STP (the
spanning tree protocol)?
Radia Perlman: I wasn't provided with the whole problem, just told to
develop a spanning protocol.
Zinin: Big difference between this and L2VPN is that L2VPN uses IP while
this defines forwarding and routing in L2. X does solve the problem with
state in core devices but that's not the problem. Critical problem is
edge bridge problem. Would rather try to solve problem with IP.
Nordmark: We tried that and gave up.
Margaret Wasserman: How many in the room are on the rbridge mailing list
and read it? (Many hand go up.)
Wasserman: How many have support from their management to work on this?
Quite a few indicate they do.)
Wasserman: Three choice poll:
(1) ready to work on this,
(2) interesting think but we need to look further,
(3) no work should be done on this in the IETF.
(1)	~10.
(2)	Many
(3)	~12.
Wasserman: The rough consensus is to look into this further.