[rbridge] Two "shared VLAN" alternative proposals

[Eric Gray (LO/EUS)]

Silvano,

	One thing you might want to realize is that you can do
an ECMP like function in an 802.1Q-based network using MSTP.
Hence, the use of STP - alone - is not a deciding criteria.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
> Sent: Wednesday, May 09, 2007 10:06 AM
> To: Eric Gray (LO/EUS); Anoop Ghanwani; Radia Perlman
> Cc: J. R. Rivers; Caitlin Bestler; rbridge at postel.org
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> Importance: High
> 
> 
> Eric,
> 
> In a TRILL domain you can do ECMP,
> outside no, since there is Spanning Tree.
> 
> It is that simple.
> 
> -- Silvano
> 
> P.S. I am VERY familiar with the application Anoop is looking at.
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com]
> > Sent: Wednesday, May 09, 2007 6:50 AM
> > To: Anoop Ghanwani; Silvano Gai; Radia Perlman
> > Cc: J. R. Rivers; Caitlin Bestler; rbridge at postel.org
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > 
> > I agree with Anoop.  The assumption that someone might only do
> > ECMP in the core is simply that - as assumption.  Further - as
> > Anoop directly states - the assumption that topology can be
> > cleanly segregated into "core" and "edge" is also JUST an
> > assumption.
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:anoop at brocade.com]
> > > Sent: Tuesday, May 08, 2007 7:29 PM
> > > To: Silvano Gai; Eric Gray (LO/EUS); Radia Perlman
> > > Cc: J. R. Rivers; Caitlin Bestler; rbridge at postel.org
> > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > Importance: High
> > >
> > >
> > > That's assumes that one restricts the topology
> > > to a clean edge-core-edge design where bridges
> > > are present only at the edges (if at all).
> > >
> > > The general case where you have a random mix
> > > of bridges and rbridges is where the problem lies.
> > >
> > > Anoop
> > >
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:sgai at nuovasystems.com]
> > > > Sent: Tuesday, May 08, 2007 1:23 PM
> > > > To: Eric Gray (LO/EUS); Radia Perlman; Anoop Ghanwani
> > > > Cc: J. R. Rivers; Caitlin Bestler; rbridge at postel.org
> > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > >
> > > >
> > > > 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, May 08, 2007 8:23 AM
> > > > > To: Silvano Gai; Radia Perlman; Anoop Ghanwani
> > > > > Cc: J. R. Rivers; Caitlin Bestler; rbridge at postel.org
> > > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > > >
> > > > > Silvano,
> > > > >
> > > > > 	The possibility of frame re-ordering using ECMP is not
> the
> > only
> > > > > concern.  A more significant issue is that schemes that exist
> for
> > > > > trying to avoid re-ordering may not guarantee symmetric frame
> > > > > delivery.
> > > > >
> > > > > --
> > > > > Eric Gray
> > > > > Principal Engineer
> > > > > Ericsson
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Silvano Gai [mailto:sgai at nuovasystems.com]
> > > > > > Sent: Tuesday, May 08, 2007 12:18 AM
> > > > > > To: Radia Perlman; Anoop Ghanwani
> > > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler;
> > > > > > rbridge at postel.org
> > > > > > Subject: RE: [rbridge] Two "shared VLAN" 
> alternative proposals
> > > > > >
> > > > > >
> > > > > > The protocol specs states:
> > > > > >
> > > > > >    The main idea is to have RBridges run a link 
> state protocol
> > > > > > amongst
> > > > > >    themselves. This enables them to have enough 
> information to
> > > > > > compute
> > > > > >    pairwise optimal paths for unicast, and to calculate
> > > > distribution
> > > > > >    trees for delivery of frames either to unknown
> > > destinations, or
> > > > to
> > > > > >    multicast/broadcast groups.
> > > > > >
> > > > > >    ECMP (Equal Cost MultiPath) may be supported, but it may
> > > > introduce
> > > > > >    frame reordering.
> > > > > >
> > > > > >
> > > > > > I think this is correct.
> > > > > >
> > > > > > -- Silvano
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Radia Perlman [mailto:Radia.Perlman at sun.com]
> > > > > > > Sent: Monday, May 07, 2007 8:28 PM
> > > > > > > To: Anoop Ghanwani
> > > > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin Bestler;
> Silvano
> > > > Gai;
> > > > > > > rbridge at postel.org
> > > > > > > Subject: Re: [rbridge] Two "shared VLAN" alternative
> proposals
> > > > > > >
> > > > > > > Which draft says that multipathing (allowing more than
> > > > one path to
> > > > a
> > > > > > > destination)
> > > > > > > is a nongoal? The architecture document, problem 
> statement,
> or
> > > > > > protocol
> > > > > > > spec?
> > > > > > >
> > > > > > > Radia
> > > > > > >
> > > > > > >
> > > > > > > Anoop Ghanwani wrote:
> > > > > > > >
> > > > > > > > According to Radia's response, she thinks
> > > > multipathing is being
> > > > > > > > addressed and yet the draft explicitly  mentions it as a
> > > > > > > > non-goal so there seems to be a bit of a disconnect.
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > >
> > >
>