[rbridge] Simplicity verses Interesting Features (was per-VLAN instances of IS-IS)

[Eric Gray (LO/EUS)]

Silvano,

	Many people are building real products, so you needn't feel
that the fact that you are makes you somehow different from every
one else.

	As another 802 kind of guy said once, any time you deal with
customers, they want (at least) the following in your products:

o	A rich feature set
o	A low price
o	An early delivery date

Realistically, these factors push and pull each other.  In particular,
features work against both low price and early delivery.

	Apparently the customers for who you are building real products
are more interested in the first factor than they are in the others.

	That is not true for all customers.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
> Sent: Tuesday, June 19, 2007 9:13 AM
> To: Eric Gray (LO/EUS); Anoop Ghanwani
> Cc: rbridge at postel.org; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> Importance: High
> 
> 
> Eric,
> 
> You say: "we're expected to preserve forwarding symmetry".
> 
> WE ARE NOT.
> 
> Where does the current draft preserve forwarding symmetry?
> 
> In regard to your conclusions, many of us (Anoop , Dinesh and I for
> sure) are participating because we are building real products. 
> 
> I don't buy your argument that "Very uninteresting 
> (technology) is very
> good."
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
> On
> > Behalf Of Eric Gray (LO/EUS)
> > Sent: Tuesday, June 19, 2007 5:27 AM
> > To: Anoop Ghanwani
> > Cc: rbridge at postel.org; Radia Perlman
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > 
> > Anoop,
> > 
> > 	I think we strongly disagree on what it means to incorporate
> > something in the control protocol.  From there, it is likely that
> > we also disagree on how best to avoid doing so.
> > 
> > 	Figuring out how to correctly carry IGMP-snooped information
> > in TRILL protocol is effectively the same thing as incorporating
> > IGMP in the control protocol.
> > 
> > 	Making a list of everything that bridges snoop and ensuring
> > we can also include that information in IS-IS is exactly the sort
> > of thing we should be trying to avoid.  The good news is that it
> > also should be easy to avoid.
> > 
> > 	Whatever protocols we might use, TRILL is essentially a layer
> > two forwarding technology.  The messages that layer two forwarding
> > technologies want to snoop are visible to the devices involved in
> > forwarding.  Unless devices actively interfere with "normal" layer
> > two forwarding, "external" control messages should be no different
> > than any other form of data - as far as RBridges are concerned -
> > and should be forwarded in the same way.
> > 
> > 	We know that we're expected to preserve forwarding symmetry
> > - at least for the layer two encapsulation of TRILL frames. In the
> > same way, and for similar reasons, we may need to preserve path
> > congruency.  This is implicit in the decision to learn from data
> > in the unicast case.
> > 
> > 	What we don't know is the complete list of things that depend
> > on our doing that.  But we can compose a partial list, and it seems
> > to me that "snooping" (in general) is one example, OA&M may well be
> > another and there are bound to be more.
> > 
> > 	As for the notion of "crippling the technology and making it
> > very uninteresting" - well, to many people, technology becomes very
> > interesting when it is very complicated to make it work.  For the
> > users of any technology, it is only truly useful when it is not very
> > interesting.
> > 
> > 	Paraphrasing something a colleague once told me: a technology
> > is only really useful when the interesting thing in using it is not
> > about the technology, but about its use.  Put another way, you know
> > that transportation is useful when the interesting thing about using
> > it is arriving at the destination - rather than the trip itself.
> > 
> > 	Uninteresting is good.  Very uninteresting is very good.
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:anoop at brocade.com]
> > > Sent: Monday, June 18, 2007 7:08 PM
> > > To: Eric Gray (LO/EUS)
> > > Cc: rbridge at postel.org; Radia Perlman
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > Importance: High
> > >
> > >
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com]
> > > > Sent: Monday, June 18, 2007 11:43 AM
> > > > To: Anoop Ghanwani
> > > > Cc: rbridge at postel.org; Radia Perlman
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > >
> > > > Anoop,
> > > >
> > > > 	I tend to view your response below as yet another
> > > > reason why RBridges MUST use a common path for unicast and
> > > > multicast (as well as broadcast and flooded) traffic.  In
> > > > fact, it is a very good reason to limit use of "multipathing"
> > > > in general.
> > >
> > > If we do place those constraints then it would
> > > cripple the technology and make it very uninteresting
> > > (at least to me).
> > >
> > > > 	It is not clear exactly what you mean by your reference
> > > > to differences between control and data paths.  Control
> > > > messages are from one RBridge to another and - presumably -
> > > > follow the same path as data addressed from RBridge to
> > > > RBridge.  That path may be different from data transitting an
> > > > RBridge campus, but there is no RBridge "control" traffic
> > > > that transits a campus.
> > > >
> > > > 	Are you suggesting that IGMP should be treated as a
> > > > control protocol within TRILL?
> > >
> > > In this case, when I said control I meant IGMP (since
> > > that is what is being used to effect pruning).  If we
> > > snoop on the information at the edge of the trill
> > > cloud and pass this information around in IS-IS, then we don't
> > > need to worry about treating it as a separate control
> > > protocol.
> > >
> > > >
> > > > 	Nor is it very clear why this observation is specific
> > > > to our discussion of multicast optimization.  As a general
> > > > rule, if there is one reasonably well know application that
> > > > relies on path congruency for proper operation, there are
> > > > probably others.
> > > >
> > > > 	Do you think we should provide a logical
> > > > control-function "bridging" service for all such applications
> > > > as a result of path divergences we introduce?  Should we
> > > > conduct a research project to determine what other "control
> > > > protocols" we need to include in TRILL?
> > >
> > > We would need to make a list of everything that bridges
> > > snoop on and make sure we have ways of sending that
> > > around in IS-IS (if we care about those functions).
> > > I'm not aware of anything other than IGMP that trill
> > > would need to worry about, though.
> > >
> > > Anoop
> > >
> > 
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
>