TIME-SHARED LINK – DRNI LEARNING
From axbq-haddock-intra-das-link-0711-v02 From axbq-haddock-intra-das-link-0711-v02.pdf – the use case we are considering The difference between case 2a and 2b is that there is no predetermined link selection. When transmitting to the DRNI this means the link selected is on the first DRNI node encountered by the frame. In terms of gateway selection this means a DRNI node is the gateway for any frame received on any link that is not directly connected to the other DRNI node. When receiving from the DRNI node that receives the frame is also the gateway for that frame.
From axbq-haddock-intra-das-link-0711-v02 From axbq-haddock-intra-das-link-0711-v02.pdf - The Steady State Problem A Z 5 Y 6 DA = A, SA = Z Gateway Y must flood to IPL AND LAG - Y does not know if A is on-net or remote : - could be top left 8 DA = A – that is learned but SA = Z, and we don’t know where that is … C X B Gateway C learned Z Gateway X learned A 7 Every frame of the A Z conversation is propagated on-net, and also along the B C link, thence to X where it is discarded (2nd Gateway); Every frame of the Z A conversation is propagated on-net, and also along the Y X link, thence to C where it is discarded (2nd Gateway); Net-net, the entire AC conversation gets replicated on the IPL / Network Link of the remote network to no purpose.
axbq-haddock-intra-das-link-0711-v02.pdf So what ? Mitigation possibilities include (in no particular order) : eliminate the IPL / Network Link timeshare mode. impose topology restrictions associated with the use of the IPL / Network Link timeshare mode e.g. only p2p service between over DRNI is supported in this mode; no MAC learning needed, simple VLAN forwarding rules “just work” others ? re-visit MAC learning synchronisation : Exchange “MACs learned from DRNI” enables Gateways to learn unicast routes for all conversations. there must be others ?
From axbq-haddock-intra-das-link-0711-v02 From axbq-haddock-intra-das-link-0711-v02.pdf - Step 2 – the problem summary A Z Y C X B Learning phase 2 Y propagates Z’s reply on learned route (via B), it must also replicate it to the DRNI (towards X), because the route could originate at S (top L), and Y is “1st Gateway” for route to S; To solve this, B must communicate to Y whence the original packet with SA = A came.
From axbq-haddock-intra-das-link-0711-v02.pdf - a possible solution. Z Y B From axbq-haddock-intra-das-link-0711-v02.pdf - a possible solution. A simple solution would be to use a modified MAC learning process : When B learns a source MAC in the normal way on any non-IPL link, it unicasts a control packet () on the IPL only, qualifying the source as { on-net, from-DRNI, local-time-out, unknown }, which is used to modify the attributes of the SA MAC also learned at Y by normal mechanisms (so MAC aging is handled by normal means). This MAC source communication does not need to be totally reliable : a lost packet results only in inefficiency, not failure (see slide 3), but transmission x 3 on first learning a MAC would be sensible, and repeating the MAC source qualification packet at infrequent intervals (e.g. MAC age-out time / 3 ?) will ensure sync in long term
REPRESENTING THE RELATIONSHIP BETWEEN DRNI (MASK) VARIABLES
Conversation_PortList[] Trying to make sense of the Conversation-sensitive frame collection and distributionVariables Port Algorithm TLV Port Conv ID Digest TLV aAggConversationAdminPort Conversation Mask TLV Port Conv Svc Map TLV Conversation_PortList[] Service ID & Conversation-sensitive LACP aAggAdminServiceConvMap Collection_Conv_Mask per port aggregate & Port Conversation ID & & Actor_Oper_Port_State.Dist updateConversationMask per port aggregate Comp_Oper_Conv_Mask receivedConversationMaskTLV ? updateConversationMask ? Per Agg. Port Variables Port_Oper_Conv_Mask Partner_Oper_Conv_Mask Per Aggregator Variables Per Aggregator Attributes