[rbridge] Two "shared VLAN" alternative proposals

[Eric Gray (LO/EUS)]

Silvano,

	So, you're assuming multi-pathing (lets ignore the
"equal cost" part of this, for now) by selecting more
than one "tunnel" at the ingress RBridge as alternative
forwarding paths.

	This protects legacy bridges (somewhat) because
the only MAC learning that applies is the learning of
RBridge MAC addresses, and you're further assuming that
there will necessarily be enough reverse-path traffic
between any pair of RBridges to ensure that the legacy
bridges do not age out RBridge MAC addresses.

	These are reasonable assumptions, but they are 
still assumptions.

	However, this is not ECMP as might be typically 
applied with shortest path routing (where an equal cost 
path may exist between any router in the routing domain 
and a specific destination network).  Which goes back
to why this was stated as a "non-goal" in the RR draft.

--
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.
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > >
> > >
>