TIME-SHARED LINK – DRNI LEARNING
1
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.
2
From axbq-haddock-intra-das-link-0711-v02.pdf
- The Steady State Problem
X
C
6 Gateway X learned A 
Gateway C 7
learned Z 
DA = A – that is learned 8
but SA = Z, and we don’t
know where that is …
5
B
Y
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
Z
A
 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 AC conversation gets replicated on the
IPL / Network Link of the remote network to no purpose.
3
axbq-haddock-intra-das-link-0711-v02.pdf
So what ?
Mitigation possibilities include (in no particular order) :

1.
eliminate the IPL / Network Link timeshare mode.
2.
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 ?
3.
re-visit MAC learning synchronisation :
 Exchange “MACs learned from DRNI” enables Gateways
to learn unicast routes for all conversations.
4.
there must be others ?
4
From axbq-haddock-intra-das-link-0711-v02.pdf
- Step 2 – the problem summary
X
C
B
Y
Z
A
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.
5
From axbq-haddock-intra-das-link-0711-v02.pdf
- a possible solution.
B
Y
Z
A
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
6
REPRESENTING THE RELATIONSHIP
BETWEEN DRNI (MASK) VARIABLES
7
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
&
aAggAdminServiceConvMap
 Conversation-sensitive LACP
per port  aggregate
Collection_Conv_Mask
&
Port Conversation ID
&

&
Actor_Oper_Port_State.Dist
updateConversationMask
Comp_Oper_Conv_Mask
per port  aggregate
receivedConversationMaskTLV
?
Per Agg. Port Variables
 updateConversationMask
Port_Oper_Conv_Mask
?
Partner_Oper_Conv_Mask
Per Aggregator Variables
Per Aggregator Attributes
8