[rbridge] per-VLAN instances of IS-IS

Thu Jun 21 07:14:18 PDT 2007

Anoop,

It is OK to agree to disagree with Eric.

The current draft says:
"ECMP (Equal Cost MultiPath) may be supported, but it may introduce
frame reordering."

Donald has offered to add some additional wording.

I think we are fine

-- Silvano

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Anoop Ghanwani
> Sent: Wednesday, June 20, 2007 1:33 PM
> To: Eastlake III Donald-LDE008
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> We need to convince Eric that we have
> consensus.  He doesn't seem to think so.
> 
> Anoop
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008
> > [mailto:Donald.Eastlake at motorola.com]
> > 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