[rbridge] Consensus Check: C-Tags
Caitlin.Bestler at neterion.com
Tue Apr 8 07:57:11 PDT 2008
Eric Gray wrote:
> As a response to the general question - together with a response to
> the follow-on response so far - I would like to make the following
> 1) I am very uncomfortable with explicitly limiting the applicability
> of RBridges to the case where "Enterprise" is defined specifically
> to exclude service provider networks (remember that an SP is also
> an "Enterprise" - unless explicitly excluded).
> 2) I agree with Dinesh that we should not explicitly exclude S-TAGs,
> even though it is (as Donald points out) necessary to be specific
> in a protocol specification. A key reason for this is that - in
> the case where a SP might want to use RBridges to support their
> own use of an Ethernet (or Ethernet-like) infratructure (which
> very-well might include both C-TAGs and S-TAGs).
> 3) One way to get around this is to state - up-front - that the use
> of C-TAGs is assumed in the protocol specification, but there is
> no intention to prohibit use of S-TAGs, and probably further say
> that any additional specification required to support S-TAGs is
> out of scope in this protocol specification.
> 4) The concerns expressed by Caitlin are not - and should not be -
> relevant to the protocol specification (especailly if scoped as
> I suggest above), since they are very explicitly related to an
> implementation (or assumptions about implementations) that may
> not be true for every implementation, and could very well be
> avoided entirely by simply making the implementation choice to
> onyl support C-TAGs.
A set of RBridges collectively implement a single distributed database
of VLAN IDs and end station addresses (FID + MAC Address).
Depending on what semantics are expected with "supporting S-Tags" that
means that the VLAN IDs being tracked either become 13 or 24 bits
rather than 12.
Because this information is shared it is *not* limited to any
single implementation unless there is a clear definition that
allows RBRidges to be explicitly customer scoped, and only the
"Provider RBridges" would have to deal with the issues of S-Tags.
Stating that for *this* document, the only form of Q-Tag supported
is a C-Tag does that. And yes, somebody could define how a Provider
RBridge would work in a separate document.
More information about the rbridge