[rbridge] Consensus Check: C-Tags

[Eric Gray]

Caitlin,

	I think it is obvious that the issues you raise only exist
if the protocol specification is already over-specifying details 
of TRILL's use of Ethernet as a transport mechanism.

	In other specifications - within the IETF - where we have
needed to interface with Ethernet encapsulation, we have used a
common "interface" model that allows implementations to use any
form of defined Ethernet encapsulation available (provided they
can conform at the protocol level with a common interface model).

	On the specific potential conflict instance you point out - 
i.e. - the possibility that an S-TAG may be associated with a
larger number of VIDs than a C-TAG, I think you may be confusing
S-TAGs with the combination of S-TAGs and I-TAGs (defined in IEEE
802.1ah - which is not yet a standard, though it soon will be).
See the quote from 802.1Q-2006 that I provided in my response to
James Carlson, to see why it is obvious that the actual S-TAG does
not itself provide a larger VID space.  

	I-TAGs are used in conjunction with S-TAGs only at the PBB 
ingress and egress (I-component, in IEEE-ese).  It is possible 
that defining how an RBridge might also be an I-Component may 
require additional specification.  I doubt it - but this may be 
the case if we over-specify requirements in TRILL for using any 
specific Ethernet technologies.

	Part of the reason I doubt further explicit specification is
need in TRILL, is because the issue you are raising is not only 
limited to a specific implementation - it also would only apply 
to a specific deployment and configuration (i.e. - one in which 12 
bits of VID is insufficient to provide unambiguous differentiation 
of backbone services using the S-TAG).  Given that the size of a 
network (whether SP or Enterprise), for which this would be true, 
would probably overwhelm IS-IS routing scalability flat-out from 
the start, I question the reason why we should base our discussion 
on this case.

	In any case, the discussion is on whether or not S-TAGs 
should be explicitly disallowed in TRILL protocol specification
- not whether or not PBB (802.1ah) should be.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Caitlin Bestler [mailto:Caitlin.Bestler at neterion.com] 
> Sent: Tuesday, April 08, 2008 10:57 AM
> To: Eric Gray; Eastlake III Donald-LDE008; Dinesh G Dutt
> Cc: Rbridge at postel.org
> Subject: RE: [rbridge] Consensus Check: C-Tags
> Importance: High
> 
> 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.
> 
>