Subject: [rbridge] Two "shared VLAN" alternative proposals

From: anoop at brocade.com (Anoop Ghanwani)
Date: Mon, 7 May 2007 11:49:02 -0700

Eric/Radia,

Thanks for the responses.  I wouldn't even consider
the second scenario below to be multipathing.  That's
a different issue altogether.

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.

I think at the very least this issue ought to be clarified
further in the draft.  If there are problems with supporting
ECMP, those problems should be pointed out, so that people
understand where they can/cannot deploy ECMP.

Anoop

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com] 
> Sent: Thursday, April 26, 2007 11:26 AM
> To: Anoop Ghanwani; J. R. Rivers; Caitlin Bestler; Silvano 
> Gai; Radia Perlman; rbridge at postel.org
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> 
> Anoop,
> 
> 	There are (at least) two possible interpretations of 
> what is meant by "multi-pathing."
> 
> 	One is the sort of multipathing that is roughly 
> analogous to either link-bundling (at L2) or ECMP (usually 
> for L3 routing).
> 
> 	The other is the sort that has to do with the more 
> general form of "load-sharing" - i.e. - simply trying to 
> ensure that all possible links are being used, roughly at 
> some proportional ratio relative to their capacities.  This 
> form of multi-pathing is not dependent on multiple-path use 
> for essentially the same traffic (i.e. - as defined by 
> edge-to-edge unidirectional forwarding).
> 
> 	I believe that many people (especially those who are 
> not completely up to speed on - for example - MSTP) are 
> thinking of the second form of "multi-pathing" when they 
> refer to this term.
> When using MSTP, there are no unused links and load-sharing 
> is a natural consequence of the assignment of VIDs on the 
> basis of separate spanning tree instances.
> 
> 	As you may know, there are problems that must be 
> addressed in using the first form of multi-pathing scheme if 
> we need to be able to maintain forwarding symmetry on an 
> end-point pair basis.  
> These difficulties are reduced by using a hierarchical 
> (tunneled) overlay with RBridges, but they are not eliminated...
> 
> Thanks!
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:anoop at brocade.com]
> > Sent: Tuesday, April 24, 2007 9:14 PM
> > To: J. R. Rivers; Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); 
> > Radia Perlman; rbridge at postel.org
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > Importance: High
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: rbridge-bounces at postel.org
> > > [mailto:rbridge-bounces at postel.org] On Behalf Of J. R. Rivers
> > > Sent: Tuesday, April 03, 2007 3:47 PM
> > > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); 
> Radia Perlman; 
> > > rbridge at postel.org
> > > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> > > 
> > > 
> > > I would have thought that RBridges are "better bridges" 
> > > because they allow multi-pathing at layer 2 creating 
> significantly 
> > > more available bandwidth and with a deployment cost/complexity 
> > > relatively close to
> > > 802.1 bridges.
> > 
> > Is TRILL going to solve the multipathing problem?
> > 
> > From
> > http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-r
> > eqs-02.txt
> >    However, support for multi-pathing is potentially 
> problematic and 
> > is
> >    assumed - in this document - to be a non-goal.  Multi-path 
> > forwarding
> >    has the potential to confound the bridge learning process.
> > 
> > Anoop
> > 
>

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 07 May 2007 20:27:34 -0700

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

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Mon, 7 May 2007 21:17:33 -0700

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

> 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

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Tue, 8 May 2007 10:23:07 -0500

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  

> 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

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Tue, 8 May 2007 09:14:31 -0700

Section 4.1 of the requirements doc. 

> Silvano Gai; rbridge at postel.org
> 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.
> >
> >   
>

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Tue, 8 May 2007 12:07:16 -0500

Anoop,

	I suspect that the statement to which you refer (in the
section on interactions between routing and bridging) could be
removed without loss of content.

	It is intended to address the issue of explicitly using
any ECMP support provided by - or using - any existing routing
protocols.  I doubt that it is really necessary to explicitly
say that.

	Since maintaining symmetric routing is a non-goal in an
IP routing protocol, and maintaining symmetric forwarding is a
very important requirement for support of bridge learning, it
is intended to say that support for ECMP in any candidate RP
is not a goal (or crtieria) that would be used to select it for
use by TRILL.

	I have to say that the tendency to think of the routing
requirements draft as if it was somehow imposing requirements 
on TRILL (as opposed to stating TRILL's requirements of routing)
is a recurring problem.  The fact that the only thing we are
producing that is like a "TRILL requirements" document is the 
"Problem Statement and Applicability" draft, is not helping to
make this less confusing.  People see the term "Requirements"
in the RR draft and say "ahh, here's where TRILL requirements
are defined..."

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Tuesday, May 08, 2007 12:15 PM
> To: Radia Perlman

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Tue, 8 May 2007 13:23:16 -0700

We do ECMP only in the core, but we don't learn in the core, so I don't
see the problem.

-- Silvano

> 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

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Tue, 8 May 2007 16:29:19 -0700

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 

> Sent: Tuesday, May 08, 2007 1:23 PM
> To: Eric Gray (LO/EUS); Radia Perlman; Anoop Ghanwani
> We do ECMP only in the core, but we don't learn in the core, 
> so I don't see the problem.
> 
> -- 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
> > 
> > > > Which draft says that multipathing (allowing more than 
> one path to
> a
> > > > destination)
> > > > > non-goal so there seems to be a bit of a disconnect.
> > > > >
> > > > >
> > >
> > >
>

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Tue, 8 May 2007 18:57:54 -0700

I don't think so, the inner MAC is not learnt by bridges if the frame is
TRILL encapsulated

-- Silvano

> Sent: Tuesday, May 08, 2007 4:29 PM
> To: Silvano Gai; Eric Gray (LO/EUS); Radia Perlman
> > > >    trees for delivery of frames either to unknown destinations,
or
> > to

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 9 May 2007 08:49:59 -0500

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  

> Sent: Tuesday, May 08, 2007 7:29 PM
> > > >    trees for delivery of frames either to unknown 
> destinations, or
> > to

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 9 May 2007 07:05:30 -0700

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.

> Sent: Wednesday, May 09, 2007 6:50 AM
> To: Anoop Ghanwani; Silvano Gai; Radia Perlman
the
> only
Silvano
> > > Gai;
or
> > > > > protocol

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 9 May 2007 09:22:35 -0500

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  

> Sent: Wednesday, May 09, 2007 10:06 AM
> To: Eric Gray (LO/EUS); Anoop Ghanwani; Radia Perlman
> > > > > >    The main idea is to have RBridges run a link 
> state protocol
> > > > > > amongst
> > > > > >    themselves. This enables them to have enough 
> information to
> > > > > > compute

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 9 May 2007 09:25:50 -0500

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

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 9 May 2007 07:33:50 -0700

Not for the same VLAN

-- Silvano

> Sent: Wednesday, May 09, 2007 7:26 AM
> To: Silvano Gai; Anoop Ghanwani; Radia Perlman
> > > > > > concern.  A more significant issue is that schemes that
exist
> > for
> > > > > > >    ECMP (Equal Cost MultiPath) may be supported, but it
may
> > > > > introduce

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 9 May 2007 07:37:58 -0700

Eric,

> Sent: Wednesday, May 09, 2007 7:23 AM

It is equal cost because IS-IS is limited to equal cost. If we were
using EIGRP we can also support Non Equal Cost Multi Path.

> bridges do not age out RBridge MAC addresses.

There are for sure the IS-IS messages, they are enough to reach this
goal.

> and a specific destination network). 

This was just to simplify the explanation; of course an equal cost path
may exist between any RBridge in the RBridge domain.

 Which goes back
> to why this was stated as a "non-goal" in the RR draft.

For us it is the ONLY goal

-- Silvano

exist
may

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 9 May 2007 09:45:33 -0500

Silvano,

	Like I said, the statement may be removed from the 
RR draft as far as I am concerned.  If that is what the
WG wants to do, and it is okay with the IESG document
shepherd, then I can certainly make that change.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Wednesday, May 09, 2007 10:38 AM
> > > > > > > > > > addressed and yet the draft explicitly  
> mentions it as
> a

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 9 May 2007 11:10:56 -0400

I do not believe Silvano's use of "core" has anything at all to do with
topology. By "core" I believe he meant the Rbridges and the encapsulated
tunnels between them. Everything else is "edge" whether it is a simple
point-to-point physical link from one Rbridge to one end station or a
bridged LAN with many Rbridges attached. I think a clean distinction
between "core" and "edge" in this specific sense can always be made.

Someone doing some ECMP thing outside this core is outside our scope.

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Eric Gray (LO/EUS)
Sent: Wednesday, May 09, 2007 9:50 AM
To: Anoop Ghanwani; Silvano Gai; Radia Perlman
Cc: rbridge at postel.org
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals

--
Eric Gray
Principal Engineer
Ericsson  

> > > > > > non-goal so there seems to be a bit of a disconnect.

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 9 May 2007 10:38:59 -0500

Donald,

	In the sense that you use, this makes sense - except that
the semantic problem still exists.  You are describing a context
for forwarding, not a forwarding device.

	In other words, you are describing "core" forwarding, and
not "core" RBridges.

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Wednesday, May 09, 2007 11:11 AM
> To: rbridge at postel.org
> [mailto:rbridge-bounces at postel.org] On
> exist for 
> > > > >    The main idea is to have RBridges run a link state 
> protocol 
> > > > > amongst
> > > > > > Cc: Eric Gray (LO/EUS); J. R. Rivers; Caitlin 
> Bestler; Silvano
> > > Gai;
> > > > > > rbridge at postel.org
> > > > > > is a nongoal? The architecture document, problem 
> statement, or
> > > > > protocol
> > > > > > spec?
> > > > > >
> > > > > > Radia
> > > > > >
> > > > > >
> > > > > > Anoop Ghanwani wrote:
> > > > > > >