[rbridge] Consensus Check: C-Tags

[Caitlin Bestler]

Dinesh Dutt wrote:
> 
> I agree with all points that Eric makes here. Consider the following
> scenarios:
> - Rbridges are used within the provider backbone that isn't interested
>   in doing much with ISIDs
> - Rbridges are used within the enterprise but using S-Tags to carry
the
>   DEI bit.
> 
> I understand that there are complications if you attempt to mix C-Tags
> and S-Tags. That is why I'm fine with Rbridges stating that they're
> talking about C-Tags only. I don't want it to explicitly state that
> S-Tags are prohibited.
> 
> As Caitlin pointed out in an earlier email, STag is merely the
> ethertype to carry the VLAN info (same size, 12b since that is
> how big the field is in the Stag as well)
> 

To tie this in with some other recent threads, if we view RBridge as
a consumer of 802.1 services then the encapsulated 802.3 frame shown
in the protocol document is merely illustrative of how we presume
those 802.1 and 802.3 services will generate the frame.

Technically, all the RBridge specifies is the *information* that goes
in the outer Ethernet frame and then the enclosed payload (with the
TRILL Header, Inner Etherent Header and Ethernet Payload).

Perhaps we need some language that clarifies that *any* 802.1 service
the conveys the Trill Frame to the next hop RBridge meets the needs
of this document.

With that approach actual products would be totally free to make use
of S-Tags, just a long as S-Tag semantics did not penetrate the shared
RBridge forwarding information. Two RBridges are "adjacent" is there is
an 802.1 service that allows them to exchange encapsulated TRILL frames.
We can illustrate an 802.3 encapsulation using the C-TAG ethertype
without explicitly listing all other possible 802.1 services that could
deliver TRILL frames (such as using S-Tags, 802.11, metro Ethernet,
etc.).

That would let us focus on RBridge semantics, and let 802.1 focus on
C-Tags vs. S-Tags, etc.