Thank you for your liaison. We believe that we understand your request, and your suggestion that (as an option) the failure of one of the links in an aggregation should cause failure of the entire aggregation. We hope that the following information and observations will be of use in the development of your protection switching mechanisms. The link aggregation specification (see references below) provides for the maintenance and access to the same link parameters (speed of the link, quality of the link as measured through accumulation of frame error counts etc.) as would be available for a simple, non-aggregated link. To the extent that decisions on the use (or not) of a single link can be made using these parameters, those decisions can also be made for an aggregate, without any further protocol development on our part. We would suggest that the component of such a decision that relates to whether the bandwidth or available rate is sufficient, or that an alternate be selected by protection switching, be based on the aAggDataRate parameter, rather than on the loss of one (or any given number) of individual links. Such a rate threshold approach would provide the flexibility to allow provision of more links in an aggregate that strictly necessary to meet the bandwidth requirement, and to address other types of links (such as 802.16) whose bandwidth might vary quite independently of their inclusion within an aggregate. We have found it generally important to address the case of a link or set of links entering service, as well as failure cases, and the parameters made available for an aggregate as a whole can also be used as the threshold criteria for starting to use the aggregation. Without trying to define a standard in this liaison letter, one can also imagine adding timing constraints to such threshold criteria, thus providing the hysteresis necessary to avoid frequent changes of operational status. Control over the operational status (ifOperStatus) of an aggregated link could be specified as a shim positioned immediately above the link aggregation sublayer, with the shim also providing any necessary local indication to your protection switching protocols. However we would note that experience in our security work has been that it is generally undesirable to deny access completely to any operational link, but instead to restrict access to that link. The restricted access permits the use of those in-band protocols that may be required for management discovery or remedial action. If your protection switching protocols do not require interruption of the data flow prior to switching traffic from an unsatisfactory link, but simply redirect traffic away from that link, no shim may be required -- protection signaling may be expressed as a direct consequence of the link parameters mentioned above. If, on the other hand, the protection switching is expected to occur through detection of a data plane interruption for one or more monitored service instances, a shim with filtering capability may be desirable or existing filtering capabilities may be used. As an example, security provisions for unauthorized connectivity typically make use of an 'Unauthenticated VLAN', with access to other VLANs being denied until authentication and authorization is complete. In principle a shim, if required, could be defined by any standards body, including but not limited to, ITU-T, IEEE, or IETF. If the use of some sort of selective control is indicated, 802.1 might be able to assist in identifying an appropriate existing control and would welcome further liaison. In an environment where many connections are distributed over paths according to their capacity we have considered the adjustment of local path cost parameters, according to available data rate, in the cases where an algorithm is used that fully distributes topology computation (e.g. for MSTP). Where topology computation or selection between alternated pre-computed topologies is performed only by selected nodes, it is possible that you might wish to use the link parameters described above to initiate protection switching only for service instances in excess of the currently available bandwidth. Such a refinement would not, we believe, require any further work on our part. Alternatively it is conceivable that the locally available rate could be signaled, though we have no current work that targets rate signaling for provider networks. We hope that you will find this information useful, and look forward to our continuing co-operation. The following references provide more detail. IEEE Std. 802.3-2005 Clause 43.1.3, Figure 43-1. IEEE Std. 802.3-2005 Clause 30.7.1.1.16 aAggDataRate IETF RFC 2863 (Draft standard) "The Interfaces Group MIB". P802.1ag (CFM) Clause 6.1 IEEE Std. 802.1AE MAC Security Clause 11 802.3 Fig. 43-1 shows the relationship among the physical links and the aggregated link. The Interfaces MIB module, or IF-MIB, defined in IETF RFC 2863 (Draft standard) "The Interfaces Group MIB" is often used to access the individual interfaces among those in a stack of interfaces and protocol elements such as shown in 802.3 Figure 43-1. IEEE Std. 802.3-2005 Clause 30.7.1.1.6 defines the read-only variable "aAggDataRate". This variable indicates the aggregate speed of the aggregated link, and can be used to indicate the loss or gain of a link. P802.1ag clause 6.1 and clause 6.1.5 in general describes the use of protocol shims in more detail. IEEE Std. 802.1AE Clause 11 provides examples of the use of shims with link aggregation.