Re: [trill] Two comments on draft-ietf-trill-aa-multi-attach-00

Mingui Zhang <> Thu, 31 July 2014 09:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E4D6A1A0A9E for <>; Thu, 31 Jul 2014 02:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 glLPJI8qAtRE for <>; Thu, 31 Jul 2014 02:54:21 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 883581A0AA3 for <>; Thu, 31 Jul 2014 02:54:20 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BKT16555; Thu, 31 Jul 2014 09:54:18 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 31 Jul 2014 10:54:18 +0100
Received: from ([]) by ([]) with mapi id 14.03.0158.001; Thu, 31 Jul 2014 17:54:07 +0800
From: Mingui Zhang <>
To: Haoweiguo <>
Thread-Topic: Two comments on draft-ietf-trill-aa-multi-attach-00
Thread-Index: AQHPrIwLZl7xxZ/tJk2SEirtXwgFFpu53u9Q
Date: Thu, 31 Jul 2014 09:54:06 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "" <>
Subject: Re: [trill] Two comments on draft-ietf-trill-aa-multi-attach-00
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: Thu, 31 Jul 2014 09:54:23 -0000

Hi Weiguo,

Thanks for posting the comments to the list. Let me clarify them.

1. It's possible to design a DF election algorithm to meet the 'single exit point' requirement. It did not become our design due to the complexity. The hashing function is a mandatory function of MC-LAG, we believe it's simpler to make use of it to determine the single exit point. 

2. I think we have covered the scenarios about "local bias forwarding procedures" in Appendix a, d and e. This behavior is actually not new staff. Please see paragraph 3 of Section in RFC 6325. (There was ever a lot of discussion about this issue.)

"For all multi-destination native frames, RB1 forwards the frame in
   native form to its links..."

The basic idea is that if there are end nodes that can be reached from local ports, packets should be bounced to these ports rather than hair-pined to these end nodes across the TRILL campus. Since the hair-pin has been cut off by the split-horizon. 


>-----Original Message-----
>From: Haoweiguo
>Sent: Thursday, July 31, 2014 2:53 PM
>To: Mingui Zhang
>Subject: Two comments on draft-ietf-trill-aa-multi-attach-00
>Hi Mingui,
>In section 5.3.1, no duplication mechanism is described. I think DF election
>should be used instead of HASH mechanism.
>It's hard to realize consistent cross RBridge HASH algorithm, each RBridge
>should know other RBridge's local port and port up/down state, i have not ever
>seen similar implementation in industry.
>In section 5.3.2 , split-horizon mechanism is described. I think the solution had
>better add local bias forwarding procedures.
>I think the solution should be local bias forwarding plus split-horizon based on
>ingress nickname. What's local bias forwarding behavior? If there are multiple
>ESs(assuming ES1 and ES2 are in same VLAN) are connected to same RBridge of
>RB1,  when RB1 receives BUM traffic from ES1, it should local forwarded to ES2
>no matter the DF state on the port connecting to ES2, this is called Local bias
>forwarding behavior.
>Then RB1 injects the BUM traffic to TRILL campus and forward to RB2, if local
>port belongs to a MC-LAG and the MC-LAG attaches to RB1, then RB2 should
>drop the traffic to the local port based on ingress nickname tracking and