To CCAMP WG co-chairs and IEEE-IETF liaisons:
From: 802.1

Thank you for your query of September 2006, reproduced below so that it is
clear what question is being answered:
"We have a question arising from this liaison and our reading of the
relevant standards documents as follows.

The liaison says: "Translation of 802.1Q S-VLAN tags (with 12 bit VIDs) is
supported at S-tagged service interfaces, as an option, by the IEEE Std
802.1ad Provider Bridging amendment to IEEE Std 802.1Q." While this text in
itself is clear it leaves open the question of whether "S-tagged Service
interfaces" is the only type of interface where Translation of 802.1Q S-VLAN
tags is supported. It is our understanding that IEEE Std 802.1ad does not
preclude the translation of 802.1Q S-VLAN tags at any S-tagged interface.
Thus, this translation would be allowed at Provider Network Ports, not just
at Customer Network Ports. Can you please confirm whether this is the
correct interpretation of the IEEE Std802.1ad amendment to the IEEE Std
802.1Q?"

In answer we should make it clear that IEEE Std 802.1ad and subsequent
amendments to IEEE Std 802.1Q (such as P802.1ah Provider Backbone Bridges)
describe a number of things:

a) Basic architectural components, that can be used to compose conformant
systems.

b) Conformant systems, comprising one or more components, e.g. a Provider
Edge Bridge comprises an S-VLAN component and (possibly) a number of C-VLAN
components.

c) Reference network architectures, that are used to describe, justify, and
verify the utility and completeness of the capabilities provided by
conformant systems and to provide a basis for the design of control
protocols and management capabilities.

d) Control protocols to be used by cooperating conformant systems, within
the range of potential network architectures that we understand.

e) Management of systems and components.

Within the above taxonomy it is clear that tag translation is permitted at
the ports of S-VLAN components (802.1Q/1ad clause 5.6.1) and is currently
explicitly disallowed at the ports of C-VLAN components (802.1Q/1ad clause
5.5). The former was allowed, among other reasons, to allow tag translation
at ports that are at the edge of the provider network. The latter was
forbidden to guard against needless operational problems in the original
environments targeted by VLANs. This latter restriction is likely to be
lifted in the very limited case of the use of multiple VIDs to support
Shortest Path Bridging (P802.1aq) within regions in a network, and the
lifting of the restriction will be accompanied by very explicit control
protocol additions to MSTP to manage the use of VIDs. Similar control
protocol additions have been proposed to segregate the use of VIDs for other
protocols - e.g. to partition the VID space so that some VIDs can be used
for traffic engineering - so that any given physical network does not have
to be either upgraded all in an instant to allow changes in the control
protocols or devoted to one control protocol philosophy rather than another.

So you need to be aware that the use of tag translation will require
explicit support by any control protocol that carries tags within its data
fields. There is a difference in setting an objective to:

i) be interoperable with data plane protocols specified by 802.1 in the
strictly narrow context of transmission and reception through a single port

ii) exhibit data plane behavior that is consistent with the inclusion of a
conformant component within an arbitrary system

iii) exhibit the data plane, manageability, and management behavior required
for a claim of conformance to one of the systems specified in 802.1Q/1ad
clause 5

iv) exhibit interoperable and useful behavior within the context of a
network comprising 802.1Q/1ad conformant systems.

We would encourage you to develop your specifications in such a way as to
promote both interoperability and co-existence in a network, and advise that
you carefully study the use of the existing 802.1 control protocols and the
support that they would require for tag translation, and do not assume that
a given physical network will be entirely controlled by any given new and
never to be superseded protocol. We have to say that the future development
of 802.1 protocols cannot be constrained by the deployment of networks that,
while comprising conformant components, depart significantly from the
reference network architectures we have considered.

By using conformant components in a network in novel ways, you may have to
develop tag translation support for future control plane protocols -
including understanding the format and translating tags in frames that are
explicitly designed to be forwarded as ordinary data and may (possibly) be
covered by integrity protection measures to prevent their modification.

In addition to the above, of course, some attention has to be paid to the
results of management operations that may be surprising if the person or
entity carrying out those operations is not aware of the existence of tag
translation in a particular network.

A further orthogonal factor you should consider is that tag translation is
an implementation option, i.e. equipment conformant to 802.1Q can omit this
capability.

In conclusion we would like to thank you for your liaison and your
cooperative spirit, and appreciate the value that can be added to the
existing bridge solutions by the development of control plane philosophies
for a broader range of applications.

Regards,
Tony Jeffree
802.1 Chair