[rbridge] per-VLAN instances of IS-IS

[Silvano Gai]

We had this discussion on May 8th, 2007 on this mailing list.

In a nutshell: we do ECMP only in the core, but we don't learn in the
core, so I don't see the problem.

-- Silvano

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com]
> Sent: Tuesday, June 19, 2007 7:14 AM
> To: Silvano Gai; Anoop Ghanwani
> Cc: rbridge at postel.org; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Silvano,
> 
> 	Your response is confusing.  If we are not expected to
> preserve forwarding symmetry, have we given up on presumed
> compatibility with standard bridges?
> 
> --
> 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
> >