[rbridge] RBridge: a case of study
eric.gray at ericsson.com
Wed Oct 31 10:27:18 PDT 2007
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)
_________________________ _ _
| ________________ |
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
o B is an internal port, connecting that function to an
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
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.
> -----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
More information about the rbridge