[rbridge] RBridge: a case of study

Radia,

	I don't think you've quite captured the concern.

	As a matter of practicality, it is most likely to be
the case that the (at least intended) "normal" paths across 
an RBridge campus will use either point to point, or RBridge
exclusive LAN connections.

	In these cases, what you are saying is correct.

	However, it may be the case that there are also end
stations located on a LAN connecting RBridges that are also
(perhaps mostly) used as intermediate RBridges.  

	Simple picture:
   _____             _____             _____
  /     \   +---+   /     \   +---+   /     \
 { LAN-A }--+ 1 +--{ LAN-B }--+ 2 +--{ LAN-C }
  \_____/   +---+   \_____/   +---+   \_____/
                       |
                     +-+-+
                     | 3 |
                     +-+-+
                     __|__
                    /     \
                   { LAN-D }
                    \_____/

If you consider that LAN-B may have end stations, then part 
of the "load-sharing" concern has to do with sharing "load"
associated with delivering frames to (or from) those local
end stations.  To do this, the VLAN-based DRB election may
require that multiple RBridges (1, 2 and/or 3 in this case)
- of course depending on the possibility that there are end
stations in LAN-B in more than one VLAN.

	One could argue that a scenario like this - where the
number of end-stations on LAN-B is sufficient to justify a
"load sharing" concern - is artificially "constructed" (i.e.
- unlikely to occur in a real network).  However, it is a
good idea to consider that one can arrive at this scenario,
or one very like it, as a result of a fault in a deployment 
where redundancy is provided.

	For example, this topology -
   _____         
  /     \   +---+ 
 { LAN-A }--+ 1 +-.
  \_____/   +---+  \
     |              \_ _____
   +-+-+              /     \
   | 4 |             { LAN-B }
   +-+-+             _\_____/
   __|__            /
  /     \   +---+  /
 { LAN-C }--+ 2 +-'
  \_____/   +---+

- fails to this topology (on removing RBridge 4):
   _____             _____             _____
  /     \   +---+   /     \   +---+   /     \
 { LAN-A }--+ 1 +--{ LAN-B }--+ 2 +--{ LAN-C }
  \_____/   +---+   \_____/   +---+   \_____/

The interesting point - in this case - is that it seems
likely that a load-sharing election process was needed
in the initial (unbroken) topology - and MUST NOT be 
broken by the "recovery" process associated with remote
failure of RBridge 4.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
> Sent: Wednesday, October 31, 2007 5:51 PM
> To: Eric Gray
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] RBridge: a case of study
> Importance: High
> 
> Eric....if I understand your concern...
> 
> Having all RBridge-RBridge traffic between neighbor
> RBridges (RBridges on a single layer 2 cloud) take place on a 
> single VLAN
> (whether the VLAN used be configurable for that cloud, or 
> whether it's 
> always VLAN 1),
> does not preclude load splitting. "VLAN 1" as the VLAN tag in
> the outer header is just used in order to get a packet from one
> RBridge to a neighbor RBridge. Layer 3 techniques for load splitting, 
> traffic engineering, etc.,
> can be used for having RBridges choose paths across the campus. When 
> doing load
> splitting, a smart RBridge, just like a router, could choose 
> anything it 
> can see in order to decide which
> path to send a frame on, or which traffic to drop when there is
> congestion, including the inner VLAN tag. And although some might 
> consider it
> architecturally impure, there isn't anything precluding an 
> RBridge from 
> looking
> even further into the packet and making forwarding/traffic 
> splitting/traffic dropping decisions based
> on things like the diffsrv field in the IP
> header, or the TCP ports.
> 
> The outer VLAN tag is just how to wrap up the frame when 
> forwarding to 
> the next hop
> RBridge that the RBridge forwarding decision has selected for 
> this frame.
> 
> Radia
> 
> 
> 
> Eric Gray wrote:
> > Anoop,
> >
> > 	This is a generic VLAN bridging problem, commonly
> > dealt with using VLAN bridges today.  Clearly, it is not
> > the case that all VLAN bridges are required to use a 
> > common VLAN for frame forwarding.
> >
> > 	In addition, as I understand it (in part based on
> > James' reply), we are NOT saying that the common VLAN
> > you mention must be used for all frame forwarding - 
> > hence it is likely that the existence of a common VLAN
> > does not necessarily fix the problem.
> >
> > 	Just to be clear, if we were saying that a common
> > VLAN must be used for all forwarding between RBridges,
> > it quickly becomes obvious that load-sharing based on
> > VLAN separation becomes useless in practice.  If load
> > sharing based on VID is not useful, then MSTP already
> > provides L2 forwarding that makes more efficient use of
> > links than would be possible using RBridges (unless all
> > RBridge-to-RBridge connections are via P2P links).
> >
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson  
> >
> >   
> >> -----Original Message-----
> >> From: Anoop Ghanwani [mailto:anoop at brocade.com] 
> >> Sent: Wednesday, October 31, 2007 1:33 PM
> >> To: Zhi-Hern Loh; Eric Gray
> >> Cc: Developing a hybrid router/bridge.
> >> Subject: RE: [rbridge] RBridge: a case of study
> >> Importance: High
> >>
> >>
> >> Hern,
> >>
> >> That's one of the problems that we're trying to avoid
> >> by forcing all RBridges on a bridged LAN to be configured
> >> such that they are all reachable and see one another on
> >> a single VLAN.
> >>
> >> Anoop 
> >>
> >>     
> >>> -----Original Message-----
> >>> From: rbridge-bounces at postel.org 
> >>> [mailto:rbridge-bounces at postel.org] On Behalf Of Zhi-Hern Loh
> >>> Sent: Wednesday, October 31, 2007 10:17 AM
> >>> To: Eric Gray
> >>> Cc: Developing a hybrid router/bridge.
> >>> Subject: Re: [rbridge] RBridge: a case of study
> >>>
> >>> Donald,
> >>>
> >>> In addition to Eric's questions, could you (or anyone else) 
> >>> explain what would happen in the following scenario?
> >>>
> >>> Toplogy:
> >>>
> >>>                 RBa
> >>>                 /
> >>>               VID a
> >>>                /
> >>>    RBn-link X-----VID b------RBb
> >>>
> >>> Problem:
> >>>
> >>>   RBn is connected to 2 VLANs on link/port X. Connectivity to 
> >>> RBa is via VLAN a, and connectivity to RBb is via VLAN b.
> >>>
> >>>   Suppose that RBa and RBb are in the multi-destination 
> >>> distribution tree from RBn. For a multi-destination frame 
> >>> going out link/port X on RBn to RBa and RBb, what is the VID 
> >>> on the outer VLAN tag? Or could there be need to send 2 
> >>> frames, one with VID a and another with VID b?
> >>>
> >>>
> >>>
> >>> Thanks,
> >>> Hern
> >>> Fulcrum Microsystems
> >>>
> >>>
> >>> ----- Original Message -----
> >>> From: "Eric Gray" <eric.gray at ericsson.com>
> >>> To: "Eastlake III Donald-LDE008" 
> >>> <Donald.Eastlake at motorola.com>, "Zhi-Hern Loh" 
> >>>       
> >> <zloh at fulcrummicro.com>
> >>     
> >>> Cc: "Developing a hybrid router/bridge." <rbridge at postel.org>
> >>> Sent: Wednesday, October 31, 2007 4:16:33 AM (GMT-0800) 
> >>> America/Los_Angeles
> >>> Subject: RE: [rbridge] RBridge: a case of study
> >>>
> >>> Donald,
> >>>
> >>> 	When you say "would all have the same Outer [VID]"
> >>> - do you mean:
> >>>
> >>> 1) all frames MUST have the same VID within the an RBridge 
> >>>    campus,
> >>> 2) all frames forwarded from a (physical) port on one RBridge 
> >>>    to a (physical) port on another RBridge MUST have the same
> >>>    VID, or
> >>> 3) something else?
> >>>
> >>> --
> >>> Eric Gray
> >>> Principal Engineer
> >>> Ericsson  
> >>>
> >>>       
> >>>> -----Original Message-----
> >>>> From: rbridge-bounces at postel.org
> >>>> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III
> >>>> Donald-LDE008
> >>>> Sent: Wednesday, October 31, 2007 12:22 AM
> >>>> To: Zhi-Hern Loh
> >>>> Cc: Developing a hybrid router/bridge.
> >>>> Subject: Re: [rbridge] RBridge: a case of study
> >>>>
> >>>> Hi,
> >>>>
> >>>> Yes, as noted in protocol draft -05, the pseudo code was 
> >>>>         
> >> unchanged 
> >>     
> >>>> from
> >>>> -04 and is out of date.
> >>>>
> >>>> As currently being discussed, the TRILL encapsulated data being 
> >>>> forwarded out a particular physical port would all have the 
> >>>>         
> >>> same Outer 
> >>>       
> >>>> VLAN ID.
> >>>>
> >>>> Thanks,
> >>>> Donald
> >>>>
> >>>> -----Original Message-----
> >>>> From: rbridge-bounces at postel.org
> >>>> [mailto:rbridge-bounces at postel.org] On Behalf Of Zhi-Hern Loh
> >>>> Sent: Tuesday, October 30, 2007 10:54 PM
> >>>> To: Anoop Ghanwani
> >>>> Cc: Developing a hybrid router/bridge.; Radia Perlman; 
> >>>>         
> >> James Carlson
> >>     
> >>>> Subject: Re: [rbridge] RBridge: a case of study
> >>>>
> >>>>
> >>>> ----- "Anoop Ghanwani" <anoop at brocade.com> wrote:
> >>>>         
> >>>>>> -----Original Message-----
> >>>>>> From: rbridge-bounces at postel.org 
> >>>>>> [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson
> >>>>>> Sent: Tuesday, October 30, 2007 2:37 PM
> >>>>>> To: Silvano Gai
> >>>>>> Cc: Developing a hybrid router/bridge.; Radia.Perlman at Sun.COM
> >>>>>> Subject: Re: [rbridge] RBridge: a case of study
> >>>>>>
> >>>>>> Silvano Gai writes:
> >>>>>>             
> >>>>>>> Radia,
> >>>>>>>
> >>>>>>> I have added few slides to the example and I suggest that 
> >>>>>>>               
> >>>>>> we use it as 
> >>>>>>             
> >>>>>>> a possible case of study for TRILL (of course, not the 
> >>>>>>>               
> >>>> only one).
> >>>>         
> >>>>>>> Let's see if the solutions we have discussed work on this
> >>>>>>>               
> >>>>> example.
> >>>>>           
> >>>>>>> The complete case of study is at:
> >>>>>>>
> >>>>>>> http://www.ip6.com/acme-example-v1.ppt
> >>>>>>>               
> >>>>>> I have a few narrow questions that I think might help me 
> >>>>>> understand this picture a bit better.  (I probably have more 
> >>>>>> questions once I know the narrow answers.  ;-})
> >>>>>>             
> >>>>> Let me take a shot at answering these.
> >>>>>
> >>>>>           
> >>>>>>   1.  After the proposed fix, should VLAN 3 on Cloud L 
> >>>>>>             
> >>> be bridged
> >>>       
> >>>>>>       together with VLAN 3 on Cloud R, even though 
> >>>>>>             
> >> the backbone
> >>     
> >>>>> itself
> >>>>>           
> >>>>>>       doesn't directly carry VLAN 3?  (I.e., are TRILL 
> >>>>>>             
> >>>> packets with
> >>>>         
> >>>>>>       outer VLAN ID 7 or 8 and with inner VLAN 3 
> >>>>>>             
> >> present on the
> >>     
> >>>>>>       backbone?)
> >>>>>>             
> >>>>> Yes, that's pretty much what ends up happening.  
> >>>>> We have effectively extended the bridged LAN.
> >>>>>
> >>>>>           
> >>>> Anoop, I'm reading the RBridge protocol specification 
> >>>>         
> >>> version 5 and it
> >>>       
> >>>> seems to me that your comment is inconsistent with the spec. 
> >>>> In section,
> >>>> 5.2.2.3, the spec says that the outer VLAN tag of TRILL data 
> >>>> frames has
> >>>> the same VID as the inner tag. Is this section going to 
> >>>>         
> >> be changed?
> >>     
> >>>> Futhermore, if we were to use different VIDs on outer VLAN 
> >>>> tags then we
> >>>> would need to handle the multi-destination case where one 
> >>>> would need to
> >>>> send a multi-destination frame per outer VID to communicate 
> >>>> with the RBs
> >>>> in the distribution tree which are using different VIDs. Is this
> >>>> correct?
> >>>>
> >>>> Thanks,
> >>>> Hern
> >>>> Fulcrum Microsystems
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>>
> >>>       
> >
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >   
> 
> 