Re: [trill] Poll for WG adoption of draft-zhang-trill-aa-multi-attach

Mingui Zhang <> Tue, 22 July 2014 19:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 53CD51A01BD; Tue, 22 Jul 2014 12:50:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0LkP2rTisKRz; Tue, 22 Jul 2014 12:50:40 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A88B11A0126; Tue, 22 Jul 2014 12:50:39 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BHM52391; Tue, 22 Jul 2014 19:50:38 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 22 Jul 2014 20:50:37 +0100
Received: from ([]) by ([]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 03:50:34 +0800
From: Mingui Zhang <>
To: "" <>, "" <>, trill <>
Thread-Topic: [trill] Poll for WG adoption of draft-zhang-trill-aa-multi-attach
Thread-Index: AQHPpNleHAj1NmuNH0e9K9hadP5vbJusZtBw
Date: Tue, 22 Jul 2014 19:50:32 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4552F0907735844E9204A62BBDD325E76A0E9A2Ankgeml508mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [trill] Poll for WG adoption of draft-zhang-trill-aa-multi-attach
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Jul 2014 19:50:43 -0000

Hi Ting

Thanks for the comments. Please find the responses inline.


From: trill [] On Behalf Of
Sent: Monday, July 21, 2014 7:46 PM
To:; trill
Subject: Re: [trill] Poll for WG adoption of draft-zhang-trill-aa-multi-attach

Hi authors,

I have some questions about this draft:

1、How to check all the RBs'MC-LAG-GROUP-RBRIDGES tlvs are received by remote RBs?

2、If the MC-LAG-GROUP-RBRIDGES tlvs of one member are lost, the remote RB how to install the MAC tabel will have issues.

[Mingui] These TLVs are carried in ISIS LSPs and ISIS provides the _reliable_ flooding to its peers. As we know, PSNP and CSNP are designed for this purpose.

3、Section 5.5, load balance on remote RB, does the fib on the hardware only install one entry?

[Mingui] Yes, it does.

Then how to differ the flip-flop if it can be randomly selected.

[Mingui] Exactly, it is a pseudo-random selection method (See bullet 1, Section 5.3 of draft-ietf-trill-esadi-09 ). For this method, the output (i.e., the egress RBridge) for each MACx  at a specific ingress RBridge is unique. This is why we don’t worry about the flip-flop. Having said that, for different MACx in a specific DL, the egress RBridge can be different. So the load balance is achieved.

4、As shown in Figure 3.1, RB1/RB2/RB3 learn the MAC of H1-4, if each RB in the same MC-LAG has to advertise the MC-LAG-GROUP-MAC tlv,
   it seems unnecessary and adds the difficulty of RB4's control plane processing; alternatively, we could let only one RB advertises the MC-LAG-GROUP-MAC tlv,

[Mingui] Due to the hashing function, MACx may only be learned by a unique receiver RBridge rather than all of them. So each RBridge has to advertise the MC-LAG-GROUP-MAC tlv. For those MACy that has already been advertised, implementations could let only one member RBridge to advertise it. But it will undermine the reliability and introduce the complexity on the selection of the one RBridge.

This is actually not new for this draft. For a MACz which is attached to multiple edge RBridges, the plain ESADI will let those multiple edge RBridges advertise it as well.

   as described in question 2, how to install the MAC table arises.

[Mingui] I think this issue had been cleared  above.