Subject: [rbridge] RBridge: a case of study

From: eric.gray at ericsson.com (Eric Gray)
Date: Thu, 1 Nov 2007 04:09:31 -0500

Radia,

	I don't think you've quite captured the concern.

	As a matter of practicality, it is most likely to be
the case that the (at least intended) "normal" paths across 
an RBridge campus will use either point to point, or RBridge
exclusive LAN connections.

	In these cases, what you are saying is correct.

	However, it may be the case that there are also end
stations located on a LAN connecting RBridges that are also
(perhaps mostly) used as intermediate RBridges.  

	Simple picture:
   _____             _____             _____
  /     \   +---+   /     \   +---+   /     \
 { LAN-A }--+ 1 +--{ LAN-B }--+ 2 +--{ LAN-C }
  \_____/   +---+   \_____/   +---+   \_____/
                       |
                     +-+-+
                     | 3 |
                     +-+-+
                     __|__
                    /     \
                   { LAN-D }
                    \_____/

If you consider that LAN-B may have end stations, then part 
of the "load-sharing" concern has to do with sharing "load"
associated with delivering frames to (or from) those local
end stations.  To do this, the VLAN-based DRB election may
require that multiple RBridges (1, 2 and/or 3 in this case)
- of course depending on the possibility that there are end
stations in LAN-B in more than one VLAN.

	One could argue that a scenario like this - where the
number of end-stations on LAN-B is sufficient to justify a
"load sharing" concern - is artificially "constructed" (i.e.
- unlikely to occur in a real network).  However, it is a
good idea to consider that one can arrive at this scenario,
or one very like it, as a result of a fault in a deployment 
where redundancy is provided.

	For example, this topology -
   _____         
  /     \   +---+ 
 { LAN-A }--+ 1 +-.
  \_____/   +---+  \
     |              \_ _____
   +-+-+              /     \
   | 4 |             { LAN-B }
   +-+-+             _\_____/
   __|__            /
  /     \   +---+  /
 { LAN-C }--+ 2 +-'
  \_____/   +---+

- fails to this topology (on removing RBridge 4):
   _____             _____             _____
  /     \   +---+   /     \   +---+   /     \
 { LAN-A }--+ 1 +--{ LAN-B }--+ 2 +--{ LAN-C }
  \_____/   +---+   \_____/   +---+   \_____/

The interesting point - in this case - is that it seems
likely that a load-sharing election process was needed
in the initial (unbroken) topology - and MUST NOT be 
broken by the "recovery" process associated with remote
failure of RBridge 4.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
> Sent: Wednesday, October 31, 2007 5:51 PM
> To: Eric Gray
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] RBridge: a case of study
> Importance: High
> 
> Eric....if I understand your concern...
> 
> Having all RBridge-RBridge traffic between neighbor
> RBridges (RBridges on a single layer 2 cloud) take place on a 
> single VLAN
> (whether the VLAN used be configurable for that cloud, or 
> whether it's 
> always VLAN 1),
> does not preclude load splitting. "VLAN 1" as the VLAN tag in
> the outer header is just used in order to get a packet from one
> RBridge to a neighbor RBridge. Layer 3 techniques for load splitting, 
> traffic engineering, etc.,
> can be used for having RBridges choose paths across the campus. When 
> doing load
> splitting, a smart RBridge, just like a router, could choose 
> anything it 
> can see in order to decide which
> path to send a frame on, or which traffic to drop when there is
> congestion, including the inner VLAN tag. And although some might 
> consider it
> architecturally impure, there isn't anything precluding an 
> RBridge from 
> looking
> even further into the packet and making forwarding/traffic 
> splitting/traffic dropping decisions based
> on things like the diffsrv field in the IP
> header, or the TCP ports.
> 
> The outer VLAN tag is just how to wrap up the frame when 
> forwarding to 
> the next hop
> RBridge that the RBridge forwarding decision has selected for 
> this frame.
> 
> Radia
> 
> 
> 
> Eric Gray wrote:
> > Anoop,
> >
> > 	This is a generic VLAN bridging problem, commonly
> > dealt with using VLAN bridges today.  Clearly, it is not
> > the case that all VLAN bridges are required to use a 
> > common VLAN for frame forwarding.
> >
> > 	In addition, as I understand it (in part based on
> > James' reply), we are NOT saying that the common VLAN
> > you mention must be used for all frame forwarding - 
> > hence it is likely that the existence of a common VLAN
> > does not necessarily fix the problem.
> >
> > 	Just to be clear, if we were saying that a common
> > VLAN must be used for all forwarding between RBridges,
> > it quickly becomes obvious that load-sharing based on
> > VLAN separation becomes useless in practice.  If load
> > sharing based on VID is not useful, then MSTP already
> > provides L2 forwarding that makes more efficient use of
> > links than would be possible using RBridges (unless all
> > RBridge-to-RBridge connections are via P2P links).
> >
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson  
> >
> >   
> >> -----Original Message-----
> >> From: Anoop Ghanwani [mailto:anoop at brocade.com] 
> >> Sent: Wednesday, October 31, 2007 1:33 PM
> >> To: Zhi-Hern Loh; Eric Gray
> >> Cc: Developing a hybrid router/bridge.
> >> Subject: RE: [rbridge] RBridge: a case of study
> >> Importance: High
> >>
> >>
> >> Hern,
> >>
> >> That's one of the problems that we're trying to avoid
> >> by forcing all RBridges on a bridged LAN to be configured
> >> such that they are all reachable and see one another on
> >> a single VLAN.
> >>
> >> Anoop 
> >>
> >>     
> >>> -----Original Message-----
> >>> From: rbridge-bounces at postel.org 
> >>> [mailto:rbridge-bounces at postel.org] On Behalf Of Zhi-Hern Loh
> >>> Sent: Wednesday, October 31, 2007 10:17 AM
> >>> To: Eric Gray
> >>> Cc: Developing a hybrid router/bridge.
> >>> Subject: Re: [rbridge] RBridge: a case of study
> >>>
> >>> Donald,
> >>>
> >>> In addition to Eric's questions, could you (or anyone else) 
> >>> explain what would happen in the following scenario?
> >>>
> >>> Toplogy:
> >>>
> >>>                 RBa
> >>>                 /
> >>>               VID a
> >>>                /
> >>>    RBn-link X-----VID b------RBb
> >>>
> >>> Problem:
> >>>
> >>>   RBn is connected to 2 VLANs on link/port X. Connectivity to 
> >>> RBa is via VLAN a, and connectivity to RBb is via VLAN b.
> >>>
> >>>   Suppose that RBa and RBb are in the multi-destination 
> >>> distribution tree from RBn. For a multi-destination frame 
> >>> going out link/port X on RBn to RBa and RBb, what is the VID 
> >>> on the outer VLAN tag? Or could there be need to send 2 
> >>> frames, one with VID a and another with VID b?
> >>>
> >>>
> >>>
> >>> Thanks,
> >>> Hern
> >>> Fulcrum Microsystems
> >>>
> >>>
> >>> ----- Original Message -----
> >>> From: "Eric Gray" <eric.gray at ericsson.com>
> >>> To: "Eastlake III Donald-LDE008" 
> >>> <Donald.Eastlake at motorola.com>, "Zhi-Hern Loh" 
> >>>       
> >> <zloh at fulcrummicro.com>
> >>     
> >>> Cc: "Developing a hybrid router/bridge." <rbridge at postel.org>
> >>> Sent: Wednesday, October 31, 2007 4:16:33 AM (GMT-0800) 
> >>> America/Los_Angeles
> >>> Subject: RE: [rbridge] RBridge: a case of study
> >>>
> >>> Donald,
> >>>
> >>> 	When you say "would all have the same Outer [VID]"
> >>> - do you mean:
> >>>
> >>> 1) all frames MUST have the same VID within the an RBridge 
> >>>    campus,
> >>> 2) all frames forwarded from a (physical) port on one RBridge 
> >>>    to a (physical) port on another RBridge MUST have the same
> >>>    VID, or
> >>> 3) something else?
> >>>
> >>> --
> >>> Eric Gray
> >>> Principal Engineer
> >>> Ericsson  
> >>>
> >>>       
> >>>> -----Original Message-----
> >>>> From: rbridge-bounces at postel.org
> >>>> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III
> >>>> Donald-LDE008
> >>>> Sent: Wednesday, October 31, 2007 12:22 AM
> >>>> To: Zhi-Hern Loh
> >>>> Cc: Developing a hybrid router/bridge.
> >>>> Subject: Re: [rbridge] RBridge: a case of study
> >>>>
> >>>> Hi,
> >>>>
> >>>> Yes, as noted in protocol draft -05, the pseudo code was 
> >>>>         
> >> unchanged 
> >>     
> >>>> from
> >>>> -04 and is out of date.
> >>>>
> >>>> As currently being discussed, the TRILL encapsulated data being 
> >>>> forwarded out a particular physical port would all have the 
> >>>>         
> >>> same Outer 
> >>>       
> >>>> VLAN ID.
> >>>>
> >>>> Thanks,
> >>>> Donald
> >>>>
> >>>> -----Original Message-----
> >>>> From: rbridge-bounces at postel.org
> >>>> [mailto:rbridge-bounces at postel.org] On Behalf Of Zhi-Hern Loh
> >>>> Sent: Tuesday, October 30, 2007 10:54 PM
> >>>> To: Anoop Ghanwani
> >>>> Cc: Developing a hybrid router/bridge.; Radia Perlman; 
> >>>>         
> >> James Carlson
> >>     
> >>>> Subject: Re: [rbridge] RBridge: a case of study
> >>>>
> >>>>
> >>>> ----- "Anoop Ghanwani" <anoop at brocade.com> wrote:
> >>>>         
> >>>>>> -----Original Message-----
> >>>>>> From: rbridge-bounces at postel.org 
> >>>>>> [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson
> >>>>>> Sent: Tuesday, October 30, 2007 2:37 PM
> >>>>>> To: Silvano Gai
> >>>>>> Cc: Developing a hybrid router/bridge.; Radia.Perlman at Sun.COM
> >>>>>> Subject: Re: [rbridge] RBridge: a case of study
> >>>>>>
> >>>>>> Silvano Gai writes:
> >>>>>>             
> >>>>>>> Radia,
> >>>>>>>
> >>>>>>> I have added few slides to the example and I suggest that 
> >>>>>>>               
> >>>>>> we use it as 
> >>>>>>             
> >>>>>>> a possible case of study for TRILL (of course, not the 
> >>>>>>>               
> >>>> only one).
> >>>>         
> >>>>>>> Let's see if the solutions we have discussed work on this
> >>>>>>>               
> >>>>> example.
> >>>>>           
> >>>>>>> The complete case of study is at:
> >>>>>>>
> >>>>>>> http://www.ip6.com/acme-example-v1.ppt
> >>>>>>>               
> >>>>>> I have a few narrow questions that I think might help me 
> >>>>>> understand this picture a bit better.  (I probably have more 
> >>>>>> questions once I know the narrow answers.  ;-})
> >>>>>>             
> >>>>> Let me take a shot at answering these.
> >>>>>
> >>>>>           
> >>>>>>   1.  After the proposed fix, should VLAN 3 on Cloud L 
> >>>>>>             
> >>> be bridged
> >>>       
> >>>>>>       together with VLAN 3 on Cloud R, even though 
> >>>>>>             
> >> the backbone
> >>     
> >>>>> itself
> >>>>>           
> >>>>>>       doesn't directly carry VLAN 3?  (I.e., are TRILL 
> >>>>>>             
> >>>> packets with
> >>>>         
> >>>>>>       outer VLAN ID 7 or 8 and with inner VLAN 3 
> >>>>>>             
> >> present on the
> >>     
> >>>>>>       backbone?)
> >>>>>>             
> >>>>> Yes, that's pretty much what ends up happening.  
> >>>>> We have effectively extended the bridged LAN.
> >>>>>
> >>>>>           
> >>>> Anoop, I'm reading the RBridge protocol specification 
> >>>>         
> >>> version 5 and it
> >>>       
> >>>> seems to me that your comment is inconsistent with the spec. 
> >>>> In section,
> >>>> 5.2.2.3, the spec says that the outer VLAN tag of TRILL data 
> >>>> frames has
> >>>> the same VID as the inner tag. Is this section going to 
> >>>>         
> >> be changed?
> >>     
> >>>> Futhermore, if we were to use different VIDs on outer VLAN 
> >>>> tags then we
> >>>> would need to handle the multi-destination case where one 
> >>>> would need to
> >>>> send a multi-destination frame per outer VID to communicate 
> >>>> with the RBs
> >>>> in the distribution tree which are using different VIDs. Is this
> >>>> correct?
> >>>>
> >>>> Thanks,
> >>>> Hern
> >>>> Fulcrum Microsystems
> >>>>
> >>>> _______________________________________________
> >>>> rbridge mailing list
> >>>> rbridge at postel.org
> >>>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>>
> >>>> _______________________________________________
> >>>> rbridge mailing list
> >>>> rbridge at postel.org
> >>>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>>
> >>>>         
> >>> _______________________________________________
> >>> rbridge mailing list
> >>> rbridge at postel.org
> >>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>
> >>>       
> >
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >   
> 
>

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Sat, 3 Nov 2007 12:38:52 -0400

See below at @@@

-----Original Message-----
From: James Carlson [mailto:james.d.carlson at sun.com] 
Sent: Wednesday, October 31, 2007 10:14 AM
To: Eric Gray
Cc: Eastlake III Donald-LDE008; Zhi-Hern Loh; Developing a hybrid
router/bridge.

>    to a (physical) port on another RBridge MUST have the same

(I'm not Donald, but ...)

@@@ Well, I am Donald and I meant something like (2) but a bit narrower.
I would have said "all TRILL frames" because "all frames" is way too
inclusive. What about control frames like 802.1AB? Furthermore, in the
case of point-to-point links between two Rbridges (i.e., no bridges or
end station connections in between), as far as I can see there is no
particular utility in considering the TRILL frames to have any external
VLAN coloring and certainly no need for them to be outer tagged with a
VLAN ID or priority.

My understanding was more like:

  3) Where an outer VLAN tag is present, all frames transmitted by an
     RBridge must have the same inner and outer VLAN tag numbers.
     Where an outer VLAN tag is not present, the implicit tag for that
     port must match or be compatible with the inner tag.

... which would be consistent with "traditional" bridge behavior and
would effectively rule out the type of solution that Silvano Gai has
been proposing.

@@@ Well, your version of (3) above is, as I recall, roughly how things
were in draft -04. However, by -05 posted in July of this year (except
in the pseudo code which is clearly labeled as still being that from
-04), in order to actually provide the promised optimal pair-wise
routing, the Outer and Inner VLANs are completely decoupled. See, for
example, Section 4.1.2 of -05. And some recent proposals suggest using a
single Outer VLAN ID on a link. 

The distinction with (2) in your list is that (2) appears to rule out
the use of so-called "tagged" or leaf or ingress ports, forcing all
ports to carry VLAN tags.

@@@ I find your above statement a bit confusing. Item (2) seems to be
talking about TRILL frames between Rbridges which doesn't have anything
to do with ingressing native frames.

@@@ Thanks,
@@@ Donald

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Sat, 3 Nov 2007 13:16:54 -0400

Hern,

Your question is the same as my question in point 2 of my mail at
http://www.postel.org/pipermail/rbridge/2007-October/002584.html.
The way things are described in the text of draft -05, I think you would
indeed have to send some TRILL data frames multiple times. That is why
there is currently discussion of ways to avoid this problem while
maintaining our charter goal of optional pairwise routing.

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Anoop Ghanwani

Hern,

Anoop 

> <Donald.Eastlake at motorola.com>, "Zhi-Hern Loh" <zloh at fulcrummicro.com>
> > Yes, as noted in protocol draft -05, the pseudo code was unchanged 
> > from
> > -04 and is out of date.
> > 
> > Cc: Developing a hybrid router/bridge.; Radia Perlman; James Carlson
> > > >       together with VLAN 3 on Cloud R, even though the backbone
> > > itself
> > > >       outer VLAN ID 7 or 8 and with inner VLAN 3 present on the
> > > >       backbone?)
> > > 
> > the same VID as the inner tag. Is this section going to be changed?
> >

---

From: james.d.carlson at sun.com (James Carlson)
Date: Mon, 5 Nov 2007 10:15:58 -0500

> From: James Carlson [mailto:james.d.carlson at sun.com] 
[...]
> Eric Gray writes:
[...]
> >    to a (physical) port on another RBridge MUST have the same
[...]
> VLAN coloring and certainly no need for them to be outer tagged with a

I mostly agree with that.  In fact, I think that's a desirable end
state for TRILL, when all other bridges are obsolete.  Having no VLAN
tag on the outside makes a lot of sense there.

(I think omitting the priority makes a bit less sense to me, though.
Wouldn't you want the priority value set on an 802.1q header with VLAN
ID 0 in this case?)

I think the question is how to get there when there are networks that
are half-TRILL and half-otherwise.

> were in draft -04.

Yes.

> However, by -05 posted in July of this year (except

As long as these things are manually configured, as described in
4.1.2, I don't see a problem.

As I understood Silvano Gai's discussion, it seemed he didn't want to
have those things be manually configured, so the RBridges would
somehow "find" each other on whatever underlying outer VLAN IDs might
be available and then forward packets without regard to the
restrictions placed on those other VLANs.

Perhaps I've misunderstood *that* part of it, but it's that part that
I wanted to clarify.

> to do with ingressing native frames.

The original statement said this:

     VID [...]

Packets that don't have VLAN tags (such as those on "tagged" ports)
don't have ID numbers.

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Mon, 5 Nov 2007 14:45:26 -0600

Radia,

	On looking at this again, it seems as if you've tried to
answer a question I am not asking.  

	I will try this again.   Please see in-line below.

--
Eric Gray
Principal Engineer
Ericsson  

> Having all RBridge-RBridge traffic between neighbor RBridges 
> (RBridges on a single layer 2 cloud) take place on a single 
> VLAN (whether the VLAN used be configurable for that cloud, 
> or whether it's always VLAN 1), does not preclude load 
> splitting. 

For some types of load splitting, what you're saying may be
correct.  At the egress from, and ingress to, the RBridge
campus, the only form of load-splitting that we have talked
about thus far is based on the DRB election process - in
combination with VLAN-specific DRB election.

The why's and wherefore's of the issues of other forms of 
load splitting at the campus edge have to do with the need
to have symmetrical frame delivery - and that's a discussion 
complex enough to ignore (because it is irrelevant) in this 
discussion.

For this particular form of load-splitting, obviously using
only one VLAN for forwarding precludes it.

>
> "VLAN 1" as the VLAN tag in the outer header is just used in 
> order to get a packet from one RBridge to a neighbor RBridge.
> Layer 3 techniques for load splitting, traffic engineering, 
> etc., can be used for having RBridges choose paths across the
> campus. When doing load splitting, a smart RBridge, just like
> a router, could choose anything it can see in order to decide
> which path to send a frame on, or which traffic to drop when
> there is congestion, including the inner VLAN tag. 
> And although some might consider it architecturally impure,
> there isn't anything precluding an RBridge from looking
> splitting/traffic dropping decisions based on things like the
> diffsrv field in the IP header, or the TCP ports.

And this is where we're missing the point.  If there is only 
one DRB for a given TRILL link, only that device will act as 
egress from, and ingress to, the link.

Many of the clever load-splitting approaches out there will
break a layer 2 network because they lead to asymmetrical
forwarding.

> forwarding to the next hop RBridge that the RBridge forwarding
> decision has selected for this frame.

And - for the case where the forwarding RBridge is not the DRB
- it is necessary for the frame to traverse the local network
twice; once with TRILL encaps and again without.  It is quite
likely that this will often result in the DRB forwarding frames
onto a local bridged LAN for a VLAN that it would otherwise not
participate in.

> Radia

My earlier response pointed out - possibly at too much length - 
that you CANNOT assume that a link that provides egress from the
RBridge campus is not also a link between RBridges, nor that a
link between RBridges is not also an egress/ingress point.

I thought this obvious because I did qualify the concern by the
words "based on VLAN separation" - in reference to the specific
mechanism by which load-splitting would occur.  Even if we are
talking about traffic that is not going to be egressed onto the 
local link, this statement would have been true.

All of that said, if you are referring JUST to traffic that is 
literally traversing the local link, then what you say is true.
The DRB election does not apply in that case.  However, that is 
not the way I initially interpretted what you said.

In part, that is because of the earlier statement from Donald
- regarding the use of a single VLAN ID for all traffic sent on
any physical interface.

If that is not what you were referring to, then my objection to 
the idea is simply that it's unnecessarily restrictive and may, 
in fact, interfere with deployment.

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Tue, 6 Nov 2007 16:58:44 -0500

See below at ### 

-----Original Message-----
From: James Carlson [mailto:james.d.carlson at sun.com] 
Sent: Monday, November 05, 2007 10:16 AM
To: Eastlake III Donald-LDE008
Cc: Developing a hybrid router/bridge.
Subject: RE: [rbridge] RBridge: a case of study

[...]
[...]
[...]

### The way I look at it, the VLAN coloring and priority of a frame are
meta data associated with the frame. The priority is used in queuing
decisions related to processing and transmitting the frame. Just what
Q-tag gets put on the transmitted frame depends on configuration.

### If a link is point-to-point between Rbridges, there is no need for
an outer VLAN ID. If it is a data frame, the actual VLAN ID of the data
is in the inner Q-tag and so easily available to the next Rbridge for
its decision processes. Similarly, I don't see any reason for priority
in the outer Q-tag. It's not as if a piece of wire is going to look at
the priority and re-order frames. If it is a data frame, the actual
priority of the data is in the inner Q-tag and so is easily available to
the next Rbridge.

### TRILL core IS-IS frames, of course, are different. They don't have
any inner Q-tag because the don't have any inherent VLAN coloring and
they only go one hop anyway. An Rbridge might want to associate
"priority 7" or whatever as meta data with the core IS-IS frame while it
is internal to the Rbridge and that could effect transmission queuing
but there is no particular reason for there to be a priority tag on it
over a point-to-point link. The next Rbridge will see that it is a core
IS-IS message, will probably treat it a bit differently for processing,
and give it to its core IS-IS instance.

### Thanks,
### Donald

...

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Wed, 7 Nov 2007 10:53:08 -0600

Donald,

	Speaking of meta-data, I find it very difficult to 
figure out who you're responding to when you use the @@@ 
and ### notation.

	It looks as if you're responding (with ###) to James 
Carlson's response to your earlier mail (with @@@), which
was itsef a reply to James' response to me.  Have I got it
figured out right?

	In any case, I have to disagree with your assertion 
that "coloring" does not make sense on a P2P link.  While
your assertion that a wire is not going to queue frames,
or make decisions based on priority, the next hop RBridge
is going to do so.

	One of the obvious examples of where either the PCP
or the VID might be useful additional information can be 
seen by analogy with what a service provider might need to
do in transporting customer frames.  An SP may have a way
to map the customer's frames to compatible PCP and VID -
used to provide some form of assured service, for example
- that is compatible with but not the same as the PCP and
VID used by the customer.  In this case, the customer's
frame PCP and VID are not useful when forwarding frames
across the SP backbone, but the customer's PCP and VID
MUST be preserved.

	I know that - thus far - we've not opened the door 
in our charter to talk about the application of RBridge
technology to anything other than enterprise networks.
Yet the analogy still applies even in the enterprise.

	Even if you feel that this technology will not be
applied to even such an enterprise, I can see little 
value in specifying "extra stuff" just to make the work
we're doing unusable for such applications.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Tuesday, November 06, 2007 4:59 PM
> To: James Carlson