[rbridge] Consensus Check: C-Tags

[Caitlin Bestler]

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
> points:
> 
> 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.