Insert new subclause 6.7.5 as shown:
6.7.5 LACP Configuration for Dual-homed Systems
A Link Aggregation System is said to be dual-homed (or multi-homed) when it has a set of Aggregation Ports intended to be connected to two (or more) Partner Systems with the restriction that only one LAG is formed from that set of Aggregation Ports. This restriction is achieved by configuring the Administrative Keys, and assigning the Operational Keys, such that:
a)All Aggregation Ports in the set are allocated the same Operational Key value, and that value is different than the Operational Key value allocated to any Aggregation Ports that are not in the set; and
b)Only one Aggregator has an Operational Key value that is the same as the Operational Key value of the Aggregation Ports in the set.
The result is that only one Aggregator is available for the set of Aggregation Ports.
Figure 6-37 shows two examples of dual-homed systems. In Figure 6-37a the dual-homed System is connected to two different Partner Systems. In this case the two Aggregation Ports cannot select the same Aggregator, and only one Aggregator is available, so the selection logic will cause one Aggregation Port to be SELECTED and one Aggregation Port to be UNSELECTED or STANDBY. Should the link that is initially SELECTED fail, the other will transition to SELECTED.
In Figure 6-37b the dual-homed System is connected to two different Portal Systems in a DRNI Portal (9.1). The normal DRNI operation allows both Portal Systems to present themselves as a single Partner System with the same Operational Key value on both links, resulting in both links become active in a single LAG. If the Intra-Portal Link (IPL) fails, however, the two Portal Systems will use different Operational Key values which prevents both links from forming a single LAG. In this case the restriction that the dual-homed system only has a single Aggregator available for these Aggregation Ports results in one Aggregation Port being SELECTED and the other UNSELECTED.
In both cases the recommended default configuration of 6.4.14.2 would cause both links to become active in separate LAGs, with the resulting possibility of forming a data loop. Using the restricted configuration for a dual-homed System guarantees that no loop is formed without relying on any external loop prevention protocol.
Insert the following paragraph to the end of 9.3.2 (prior to 9.3.2.1):
The operation of the DR Function state machines and Control Protocol specified in the following sections assures that if a loss of connectivityvia the IPL results in a Portal System being unable to communicate with other Portal Systems in the Portal, those Portal Systems will used different Operational Key values in LACPDUs exchanged on the Aggregation Links attached to the Portal Systems. This prevents Aggregation Links attached to Portal Systems that cannot communicate via an IPL from being selected for the same LAG. It is possible that these Aggregation Links could become operationalin separate LAGs, however, potentially creating a communication loop through the LACP partner of the Portal Systems. To prevent this loop it is essential that the LACP partner of the DRNI Portal be configured such that there is one and only one Aggregator with the same key value as the Aggregation Ports connected to the DRNI Portal (6.7.5).
{Editor’s Note: The following is alternative text for 6.7.5 that defines “dual-homed” only in the context of a DRNI Portal:}
A Link Aggregation System is said to be “dual-homed” (or “multi-homed”) when it connects to two (or three) Portal Systems in a DRNI Portal (9.1), with one or more links connected to each Portal System. In this scenario it is highly recommended that only one Aggregator is configured with the same Administrative and Operational Key value as is used by the Aggregation Ports connected to the Portal Systems. This will assure that only one LAG connects the LACP System to the Portal.
If there are multiple Aggregators with the same Key value as is used by the Aggregation Ports connected to the Portal Systems, then it is possible that multiple LAGs could connect the LACP System to the Portal. This could occur if the Portal Systems are unable to operate as a Portal due to mis-wiring, mis-configuration, or an inability to exchange DRCPDUs due to a failure of the Intra-Portal Link. If multiple LAGs connect the LACP System to the Portal there is the possibility of forming a data loop that cannot be prevented by LACP or DRCP operation, and would depend on a network-wide loop prevention protocol (e.g. RSTP). Configuring the LACP System such that only one LAG can connect to the Portal prevents the formation of loops without relying on a network-wide loop prevention protocol.