Subject: [rbridge] TTL only - was RE: New fields in shim header?

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 18 Oct 2006 11:18:12 -0700

Catlin,

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Caitlin Bestler
> Sent: Wednesday, October 18, 2006 10:41 AM
> To: Erik Nordmark; Ed Bowen
> Cc: rbridge at postel.org; rbridge-bounces at postel.org; Radia Perlman; Joe
> Touch
> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?
> 
> rbridge-bounces at postel.org wrote:
> > Ed Bowen wrote:
> >
> >> What is the operational experience that indicates the requirement
for
> >> the other environments?  I am not aware of anyone who plans to
> >> install TRILL outside of the environment Silvano outlines. What
need
> >> would motivate these additional environments?
> >
> > Here is one data point, which isn't central to TRILL but
> > illustrate the possibilities.
> >
> > Barnard Aboba made the observation a long time ago that using
> > TRILL in wireless access points would solve certain existing issues.
> >
> > By advertising the MAC address in the link-state routing
> > protocol when the station has associated, then moving from
> > one AP to another is less disruptive. Today one has to rely
> > on the station transmitting packets via the new AP in order
> > for the learning bridges to find update the learning tables.
> >
> 
> The same advantages will apply to live migration of virtual machines
> within a subnet. Indeed, a believe virtualization may be a major
> factor in the need for RBridges. VMs mean more MAC addresses per
> physical host, and the desire to support live migration increases
> the desire for larger subnets.
> 

I really don't understand this. 
Why does virtualization imply larger subnets? 
Why is TRILL better with larger subnets?
How does TRILL support better virtualization than IEEE 802.1D?

-- Silvano

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Wed, 18 Oct 2006 11:24:33 -0700

Silvano Gai wrote:
>> On Behalf Of Caitlin Bestler Sent: Wednesday, October 18, 2006 10:41
>> AM 
>> Cc: rbridge at postel.org; rbridge-bounces at postel.org; Radia Perlman;
>> Joe Touch Subject: Re: [rbridge] TTL only - was RE: New fields in
>> shim header? 
>> 
>>>> for the other environments?  I am not aware of anyone who plans to
>>>> need would motivate these additional environments?
>>> 
>>> Here is one data point, which isn't central to TRILL but illustrate
>>> the possibilities. 
>>> 
>>> Barnard Aboba made the observation a long time ago that using TRILL
>>> in wireless access points would solve certain existing issues.
>>> 
>>> By advertising the MAC address in the link-state routing protocol
>>> when the station has associated, then moving from one AP to another
>>> is less disruptive. Today one has to rely on the station
>>> transmitting packets via the new AP in order for the learning
>>> bridges to find update the learning tables.
>>> 
>> 

a) more MAC addresses per physical host.
b) the desire to merge IP subnets to allow migration of VMs.
   You cannot maintain an existing TCP connection and move the host
   to a new subnet, the destination IP address will be wrong.

> Why is TRILL better with larger subnets?

If each bridge can easily track EVERY mac address in the subnet
then there would be little benefit to having an RBridge.

> How does TRILL support better virtualization than IEEE 802.1D?

For the same reason Bernard Aboba cited on wireless. An set of
RBridges can distribute the new location information more
efficiently than existing bridges. Migrating a VM to a new
physial host isn't much fun if all the TCP connections
time out before the subnet learns to forward packets to
the correct new location.