[rbridge] per-VLAN instances of IS-IS

Silvano Gai sgai at nuovasystems.com
Thu Jun 21 07:09:42 PDT 2007 

Sure

-- Silvano

> -----Original Message-----
> From: Radia Perlman [mailto:Radia.Perlman at sun.com]
> Sent: Wednesday, June 20, 2007 1:00 PM
> To: Anoop Ghanwani
> Cc: Eric Gray (LO/EUS); Silvano Gai; rbridge at postel.org
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> I'm also assuming we are doing multipathing, not just of unicast, but
> also multicast.
> 
> Radia
> 
> 
> Anoop Ghanwani wrote:
> > 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
> >>>>>>

More information about the rbridge mailing list