[rbridge] RBridge: a case of study

[Eric Gray]

James,

	That is kind of what I though, and - IMO - it seems to 
be pointless (over) specification.  Still, it's better than
other possible interpretation for what Donald was saying (see 
toward the end, below).

	Consider this simplified representation of a (specific) 
RBridge implementation:

      _________________________ _ _
     |       ________________      |
   A |    B |                |C    | D
  ---+-[*]--+    Q-Bridge    +-[?]-+---
     |      |________________|     |
     |                             |
     |            RBridge          |
     |_________________________ _ _|

	It's important to realize that this is one potential
implementation - used as an example.

	In this example:

o	A is the port connecting this RBridge to other RBridges;
o	[*] represents the process we're defining for preparing 
	a frame to be ingressed on to, or egressed off of, the
	RBridge campus;
o	B is an internal port, connecting that function to an
	internal Q-Bridge;
o	C is an internal port connecting this same internal 
	Q-Bridge to any arbitrary set of other functions within
	the implementation - possibly including other internal 
	Q-Bridges;
o	[?] represents the arbitrary (set of) internal functions
	(again, possibly including other internal Q-Bridges)
	connecting internal port C to port D;
o	D is the port connecting this RBridge to end stations 
	external to the RBridge campus.

What we would be saying - if we specify what you suggest - is 
that the VID cannot change in going from A to B (or B to A).

	That may be a very reasonable thing to say, but we have
to be careful in saying it.  It is important NOT to be saying 
that the VID cannot change in going from A to D (or D to A).  
The externally visible behavior - for this implementation may 
include changing the VID for any specific set of frames at 'B', 
at 'C', or within the set of functions represented by '[?]'.  

	This ability to change VID values is consistent with 
existing device capabilities.  There may be an administrative 
domain boundary at this device, or the device may provide a
Q-in-Q function.  If we are not saying this implementation 
will be non-conformant, it's unreasonable to disallow this.

	What I thought Donald meant by "the same" was not with
respect to the "inner" VLAN ID - but with respect to all of
the frames sent using a particular physical interface.  That
would be REALLY BAD.  It would - for example - make it very
hard to do as good a job with link utilization using RBridges
as it is already possible to do using MSTP bridges.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: James Carlson [mailto:james.d.carlson at sun.com] 
> Sent: Wednesday, October 31, 2007 10:14 AM
> To: Eric Gray
> Cc: Eastlake III Donald-LDE008; Zhi-Hern Loh; Developing a 
> hybrid router/bridge.
> Subject: Re: [rbridge] RBridge: a case of study
> Importance: High
> 
> Eric Gray writes:
> > 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?
> 
> (I'm not Donald, but ...)
> 
> My understanding was more like:
> 
>   3) Where an outer VLAN tag is present, all frames transmitted by an
>      RBridge must have the same inner and outer VLAN tag numbers.
>      Where an outer VLAN tag is not present, the implicit tag for that
>      port must match or be compatible with the inner tag.
> 
> ... which would be consistent with "traditional" bridge behavior and
> would effectively rule out the type of solution that Silvano Gai has
> been proposing.
> 
> The distinction with (2) in your list is that (2) appears to rule out
> the use of so-called "tagged" or leaf or ingress ports, forcing all
> ports to carry VLAN tags.
> 
> -- 
> James Carlson, Solaris Networking              
> <james.d.carlson at sun.com>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 
> 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> 781 442 1677
>