[rbridge] per-VLAN instances of IS-IS

Thu Jun 21 07:07:45 PDT 2007

Anoop,

I agree with Donald,

I think the draft is fine, it does not prevent ECMP.
No protocol that I know specify how "to determine flows".

I don't see any action needed.

-- Silvano

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Wednesday, June 20, 2007 12:37 PM
> To: Anoop Ghanwani
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> Anoop,
> 
> What exactly do you think we need to do and to get consensus on?
> 
> I think it is clear enough from the draft that an ingress Rbridge can
> multipath multidestination traffic by selecting different tree roots
for
> different frames. So the only question is unicast. Other than a few
> words saying that don't have to always send unicast traffic on the one
> path selected by the tie breaker rule, but MAY multipath, what more is
> needed?
> 
> Presumably the tricky thing is how best to determine flows, where
frames
> in a flow would follow only one of the multiple paths, except during
> transients. I don't think the TRILL WG should get into defining
flows...
> 
> Donald
> 
> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Anoop Ghanwani
> Sent: Wednesday, June 20, 2007 2:43 PM
> To: Eric Gray (LO/EUS); Silvano Gai
> Cc: rbridge at postel.org; Radia Perlman
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> Personally, I would like the group to get to a
> consensus on the ECMP issue fairly quickly.
> 
> I too, just like Silvano, thought it was going
> to be done.
> 
> Anoop
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com]
> > Sent: Wednesday, June 20, 2007 7:29 AM
> > To: Silvano Gai; Anoop Ghanwani
> > Cc: rbridge at postel.org; Radia Perlman
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> >
> > Silvano,
> >
> > 	Yes, that was probably discussed earlier in May.
> >
> > 	AFAIK, discussion != consensus.
> >
> > 	Possibly your customers need to explain to you that the
> > difference between "core" and "not core" is not always as
> > clear cut as you apparently think it is.  Nor is it
> > necessarily going to be simple for a device to determine
> > which of the available equal cost paths only contain core elements.
> >
> > 	Also, ECMP - at least in the traditional sense - takes
> > place where equal costs exist in a "routing" domain.  That is
> > at least as likely to occur in locii containing one or more
> > edge components, as it is anywhere else.
> >
> > 	There are certainly limited applications - typically
> > requiring careful configuration to restrict ECMP-like
> > activity to very specifically defined equal cost paths -
> > where it will be possible to say "we do ECMP only in the
> > core."  I personally wonder why link-bundling wouldn't be a
> > better solution in those cases, however.
> >
> > Thanks!
> >
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> >
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:sgai at nuovasystems.com]
> > > Sent: Tuesday, June 19, 2007 11:39 PM
> > > 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
> > >
> > > 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
> > > > >
> > >
> >
> 
> _______________________________________________
> 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