[rbridge] per-VLAN instances of IS-IS
Anoop Ghanwani
anoop at brocade.com
Thu Jun 21 09:33:05 PDT 2007
I was just responding to Eric's comment about
lack of consensus for ECMP. It looks like we
have that.
I didn't mention anything about flows, so
that's not a concern for me.
Anoop
> -----Original Message-----
> From: Silvano Gai [mailto:sgai at nuovasystems.com]
> Sent: Thursday, June 21, 2007 7:08 AM
> To: Eastlake III Donald-LDE008; Anoop Ghanwani
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
>
>
> 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
>
More information about the rbridge
mailing list