[rbridge] per-VLAN instances of IS-IS

Anoop Ghanwani anoop at brocade.com
Tue Jun 19 11:21:53 PDT 2007 

Eric,

It depends on what we mean by compatibility.
One can always say that if one cares about
such and such compatibility then here's a way
to solve it.  

Even if trill were to impose the constraint 
you suggest, many things will break.  For
example, if I have a topology with a bridged
cloud between 2 trill devices, then the 
traffic going between the trill devices will
not be "snoopable" by the bridges because they
won't understand trill encapsulation.
Additionally, in the above scenario something
like MMRP would break because the ingress rBridge
would terminate the MMRP message and the
bridge cloud would never see them (that's only
logical since rBridges terminate spanning trees
and MMRP runs in the context of a spanning tree).

So rBridges aren't as transparent as we'd 
like them to be.

We have to decide what problem we are trying 
to solve and then find creative ways to work
around those issues, possibly constraining
the deployment, but without cripping the 
technology.

Anoop

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

More information about the rbridge mailing list