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

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 12 Oct 2006 13:50:08 -0700

Joe,

IMHO TRILL will be valuable in HPC and Datacenters, where high
bisectional bandwidth is a must, and in Enterprise Backbone. In the last
3 to 5 years, in this kind of applications:
1) I haven't seen a hub
2) All links are full-duplex
3) I haven't seen wireless
4) The existing switches support large jumbo frames
5) Almost all links are fiber
6) The attacks are originated by the host, not by the switches
7) Backbones are shared by different applications

IMHO, if we want to design something that addresses user needs, we need
to keep this in mind.

-- Silvano

> -----Original Message-----
> From: Joe Touch [mailto:touch at ISI.EDU]
> Sent: Thursday, October 12, 2006 1:30 PM
> To: Silvano Gai
> Cc: Caitlin Bestler; rbridge at postel.org; Radia Perlman
> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?
> 
> 
> 
> Silvano Gai wrote:
> > Catlin,
> >
> > I didn't reply to your last point
> >
> >> I am assuming there is no desire to replicate IPSEC funcationality
> >> at L2 then *all* of the L2 headers may be forged. I don't see how
> >> you can claim that any specific one is more trustworthy than
> >> the others.
> >
> > Even without IPsec, RBridges can authenticate to each other and
forging
> > an RBridge is much more difficult that using a readily available
program
> > on your PC to spoof the IP or MAC address.
> 
> I don't need to spoof another rbridge to inject spoofed traffic; I
just
> need to see the traffic going by; I can do that by plugging in a hub
and
> running tcpdump.
> Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 12 Oct 2006 13:52:43 -0700

Silvano Gai wrote:
> bisectional bandwidth is a must, and in Enterprise Backbone. 

Sure, but that's not the only place they will be deployed. Please review
the P&AS.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061012/1eb48c2f/signature.bin

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Thu, 12 Oct 2006 14:05:21 -0700

Silvano Gai wrote:
> Joe,
> 
> IMHO TRILL will be valuable in HPC and Datacenters, where
> high bisectional bandwidth is a must, and in Enterprise Backbone. In
> the last 3 to 5 years, in this kind of applications:
> 1) I haven't seen a hub
> 4) The existing switches support large jumbo frames 5) Almost all
> links are fiber 6) The attacks are originated by the host, not by the
> switches 7) Backbones are shared by different applications
> 
> IMHO, if we want to design something that addresses user
> needs, we need to keep this in mind.
> 

The environment you describe is indeed an important one.
It is also the environment that has the *least* need for
wire-mechanisms to detect intruders. The main support
for security in data center environments that the RBridge
drafts should have is to make certain that we do NOT require
dynamic learning of MAC addresses, and be very clear that
MAC locations MAY be administratively configured.

---

From: edbowen at us.ibm.com (Ed Bowen)
Date: Fri, 13 Oct 2006 09:29:01 -0400

Joe,

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?

Ed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20061013/a1fb5cbf/attachment.html

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 13 Oct 2006 07:08:45 -0700

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?
> 
> Ed

TRILL applies anytime the cross-section bandwidth of a set of deployed
bridges is constrained because of the spanning tree algorithm rather
than the link capacity.

Again, please review the problem and applicability statement and the
working group charter.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061013/e873dad9/signature.bin

---

From: edbowen at us.ibm.com (Ed Bowen)
Date: Fri, 13 Oct 2006 11:12:11 -0400

Joe,

> bridges is constrained because of the spanning tree algorithm rather

Exactly, I know of no operational experience that this constraint is
significant outside the Cluster/Datacenter/Enterprise-Backbone
environments. I can imagine theoretical problems in other areas, but I know
of no operational experience to prove the need. Do you?

> Again, please review the problem and applicability statement and the

Done. Didn't see anything to make me believe otherwise. Did I miss
something?

Ed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20061013/57253365/attachment-0001.html

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 13 Oct 2006 08:19:27 -0700

Ed Bowen wrote:
> environments. I can imagine theoretical problems in other areas, but I
> know of no operational experience to prove the need. Do you?

Operational experience is not the only thing that drives the IETF
process. Please review the Tao of the IETF.

> Done. Didn't see anything to make me believe otherwise. Did I miss

That document doesn't define this as an operational enterprise issue,
nor does the charter.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061013/516bc67f/signature.bin

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 13 Oct 2006 08:52:13 -0700

The situation that originally inspired this design was the huge hospital 
network that was something like
14 hops across and had zillions of nodes (forgot the size) that was all 
bridged. Apparently people like
the operational simplicity of bridges, and build large networks. Routing 
should be at layer 3, and the
Ethernet header was not designed to be a layer 3 header. The Ethernet 
designers never envisioned it
to be something that would be forwarded, or else, for instance, they'd 
have a TTL.

So this is useful wherever people want an IP network that requires 
minimal management but still
reasonable paths, etc.

Radia

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 13 Oct 2006 12:01:13 -0400

Hi,
 
Why not ask the question the other way? If Rbridges exist, why would
anyone want to use an old fashioned STP or RSTP based bridge?  :-)
Simplifying a lot, Rbridges make better use of available links while
various forms of spanning tree work by turning off and thus wasting
links. 
 
Of course there are some reasons, like Rbridges probably require greater
computational resources and bandwidth for routing messages. But as
computation gets cheaper and link bandwidth keeps rising, these factors
become less significant...
 
While I suppose this is all an interesting discussion, I personally
don't think it actually has much effect on the Rbridge specification. As
long as rbridges are to be applicable where high end bridges are
currently used, then they need to be able to support VLANs, optimize
multicast, etc. Whether or not they are beneficial where mid or lower
range bridges are used seems less important.
 
Donald

________________________________

From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Ed Bowen
Sent: Friday, October 13, 2006 9:29 AM
To: Joe Touch
Cc: rbridge at postel.org; rbridge-bounces at postel.org; Radia Perlman
Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?

Joe, 

Ed

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Fri, 13 Oct 2006 09:43:03 -0700

rbridge-bounces at postel.org wrote:
> Hi,
> 
> Why not ask the question the other way? If Rbridges exist,
> why would anyone want to use an old fashioned STP or RSTP
> based bridge?  :-) Simplifying a lot, Rbridges make better
> use of available links while various forms of spanning tree
> work by turning off and thus wasting links.
> 
> Of course there are some reasons, like Rbridges probably
> require greater computational resources and bandwidth for
> routing messages. But as computation gets cheaper and link
> bandwidth keeps rising, these factors become less significant...
> 
> While I suppose this is all an interesting discussion, I
> personally don't think it actually has much effect on the
> Rbridge specification. As long as rbridges are to be
> applicable where high end bridges are currently used, then
> they need to be able to support VLANs, optimize multicast,
> etc. Whether or not they are beneficial where mid or lower

At the minimum there is the need for phased deployment.
I doubt there are many sites that would agree to bring
the entire subnet down so that every existing bridge
can be replaced instantly.

RBRidges can also make sense to provide a large campus wide
network connecting many departments/floors/rooms (not just
racks in a data center). In a campus deployment I suspect
that conventional Bridges will be around at least as long
as IPv4.

---

From: dwfedyk at nortel.com (Don Fedyk)
Date: Fri, 13 Oct 2006 13:05:45 -0400

Hi Donald 

> work by turning off and thus wasting links. 

I think this is an oversimplifying statement. Rbridge leverages link
state for better plug and play use of network topologies.  This fucntion
is superior to STP or RSTP. But if you are engineering the bridged
network there are other options besides STP/RSTP and I don't see these
capabilities in Rbridge. 

Regards,
Don 

<snip>

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 13 Oct 2006 11:01:23 -0700

>network there are other options besides STP/RSTP and I don't see these
Does your comment relate to the extra potential fields? There are two of 
the proposed fields
that I could imagine would enable engineering the network: F-tag and 
ingress RBridge.

I'd imagine that the F-tag would enable
engineering of the paths to dynamically choose different types of paths 
based on different types
of traffic.

And the ingress-RBridge (for unicast traffic) could also be used to 
choose paths based not just on
destination address, but source RBridge (some favored portion of the net 
hanging off RBridge R1).
The mailing list discussion (as much as I could follow) seems to assume 
that ingress RBridge is for
filtering spoofed source address, but I agree that use of it would be 
better done by trusting all the RBridges
and letting the first RBridge discard spoofed packets. However, a 
different use of ingress RBridge could
be for choosing paths based not just on egress but also on ingress RBridge.

So, would these two fields help for providing engineering of paths?

Radia

---

From: dwfedyk at nortel.com (Don Fedyk)
Date: Fri, 13 Oct 2006 14:51:23 -0400

Hi Radia 

> >I think this is an oversimplifying statement. RBridge leverages link 
> >state for better plug and play use of network topologies.  This 
> >fucntion is superior to STP or RSTP. But if you are engineering the 
> >bridged network there are other options besides STP/RSTP and I don't 
> >see these capabilities in RBridge.
> >
> Does your comment relate to the extra potential fields? There 
> are two of the proposed fields that I could imagine would 
> enable engineering the network: F-tag and ingress RBridge.

I was referring to the fact that RBridge is more plug and play and
implicitly engineered rather than explicitly engineered.  The way I see
it RBridge creates a topology and does a good job of utilizing that
topology but it is a connectionless view.  So Donald's comment was too
broad in my opinion (IE why isn't the world all RBridge). I'm not
arguing for more engineering in the case of RBridge I'm just saying it
is more like a connectionless IP network. Plug and play with some knobs
for control. 

Myself and some others are working on means to explicitly engineer
Ethernet traffic but we find that engineering bridged networks exists to
a degree with combinations of static assigned paths and these
technologies can make use of all links. What I'm working on is more
analogous to MPLS and no I'm not arguing that it should be applied to
all bridged networks it is too big a hammer for many situations. 

> engineering of the paths to dynamically choose different 
> types of paths based on different types of traffic.

Like Diff serv? Yes but this is with in the connectionless topology
context. 

> 
> And the ingress-RBridge (for unicast traffic) could also be 
> used to choose paths based not just on destination address, 
> but source RBridge (some favored portion of the net hanging 
> off RBridge R1).
Like an ECMP algorithm. Again within the connectionless context. 

Regards,
Don 

> The mailing list discussion (as much as I could follow) seems 
> to assume that ingress RBridge is for filtering spoofed 
> source address, but I agree that use of it would be better 
> done by trusting all the RBridges and letting the first 
> RBridge discard spoofed packets. However, a different use of 
> ingress RBridge could be for choosing paths based not just on 
> egress but also on ingress RBridge.
>

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Fri, 13 Oct 2006 11:57:42 -0700

rbridge-bounces at postel.org wrote:
>> see these capabilities in Rbridge.
>> 

Given that an RBridge is presumably a single administrative domain,
why would you use the ingress-RBridge to *infer* a class of service
rather than just stating the class of service in the F-Tag?

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 13 Oct 2006 12:20:41 -0700

>rather than just stating the class of service in the F-Tag?
I agree that for RBridges, source address filtering is best done at the 
ingress RBridge, and that
our trust model is that RBridges should trust each other not to forge 
the header fields. So that use
of ingress RBridge in the shim header doesn't seem too compelling.

So let's see if the field makes sense for service classes.

It seems like there are two types of classes of service:
a) those that affect the forwarding decision
b) those that affect how you handle the packet (as in priority queue).

********
Let's first examine the use of ingress RBridge for the first type of 
service class:

The simplest forwarding decision is a single forwarding table, and you 
do a lookup based on destination
address.

To use F-tags, you'd need a different forwarding table for each F-tag.

To also base forwarding decisions based on ingress RBridge, I guess 
you'd need to multiply the
number of forwarding tables by the number of ingress RBridges? That 
certainly seems impractical.
If you trust the ingress RBridge to put in the right F-tag, it seems 
like you wouldn't need both fields.

*******
So, that leaves only one rationale I think for ingress RBridge...which 
is for priority, but the MPLS-like
header already has a priority field.

The only thing I can think of is that different portions of the 
RBridged-topology would have different
priorities for different ingress RBridges.

And speaking of filtering...I think my posts to rbridge aren't getting 
through, or at any rate, have a very
long delay (as in many hours).

Radia

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Fri, 13 Oct 2006 13:53:46 -0700

I can see a few other possibilitites for the use of a source Rbridge field.
- Consider for example, we want to return an error or send a 
notification to the ingress Rbridge from the middle of the network, 
analogous to an ICMP message. With the source RBridge, you know who to 
send it to.
- It allows hardware-based learning
- It assists in network trouble-shooting

Dinesh
Radia Perlman wrote:
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 13 Oct 2006 17:51:13 -0400

Hi Don,

I didn't suggest that 'the world be all Rbridges'. I asked, as a
rhetorical question, what might be bad about replacing all bridges with
Rbridges? Looks like both of us think that people who want to do MPLS
traffic engineering or the like, would look to LSRs or similar devices
rather than either bridges or rbridges.

Donald

PS: In answer to another comment, as far as I can see Rbridges do
support incremental deployment. You can replace your bridges by rbridges
one at a time, if you wish to do so.

-----Original Message-----
From: Don Fedyk [mailto:dwfedyk at nortel.com] 
Sent: Friday, October 13, 2006 2:51 PM
To: Radia Perlman
Cc: Eastlake III Donald-LDE008; rbridge at postel.org
Subject: RE: [rbridge] Range of appllicability (was Re: TTL only - was
RE: New fields in shim header?)

Hi Radia 

...

...

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Wed, 18 Oct 2006 09:59:02 -0700

> - It assists in network trouble-shooting

Dinesh,

I'd be interested in understanding the error reporting and 
trouble-shooting aspects a bit more.

Link state routing protocols have been used for IP traffic for a long 
time, and the operational tools used to not include the ability to tell 
the ingress (first) IS-IS/OSPF router something. The error reporting is 
just ICMP errors that are sent back to the IP source of the packet, plus 
MIBs and the like which allows network managers to observe the routers.

We could choose to just rely on the same approach for RBridges, in which 
case an ingress rbridge address isn't required.

Or we could try to come up with different way to trouble-shoot RBridged 
networks, but I certainly don't feel I understand what such a solution 
would look like. Would it mean we (or IEEE 802) would need to define L2 
error messages that can be sent back similar in spirit to ICMP? Would we 
need to invent a L2 or RBridge "traceroute" application?

Given that both IP networks using link-state routing protocols, and IEEE 
802.1D networks get away without reporting errors to the ingress, I 
think we need to understand this space quite a bit more before embarking 
down that path.

Regards,
    Erik

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Wed, 18 Oct 2006 10:22:10 -0700

> outside of the environment Silvano outlines. What need would motivate these

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.

    Erik

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Wed, 18 Oct 2006 10:41:27 -0700

rbridge-bounces at postel.org wrote:
>> 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.