Re: [trill] question to draft-ietf-trill-active-active-connection-prob-05

Liyizhou <liyizhou@huawei.com> Wed, 16 July 2014 01:32 UTC

Return-Path: <liyizhou@huawei.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214C41B29FB for <trill@ietfa.amsl.com>; Tue, 15 Jul 2014 18:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level:
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gytfV9Bvh5YP for <trill@ietfa.amsl.com>; Tue, 15 Jul 2014 18:32:55 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D66BD1B29F6 for <trill@ietf.org>; Tue, 15 Jul 2014 18:32:54 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKC02122; Wed, 16 Jul 2014 01:32:53 +0000 (GMT)
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Jul 2014 02:32:52 +0100
Received: from NKGEML503-MBX.china.huawei.com ([169.254.5.127]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 16 Jul 2014 09:32:43 +0800
From: Liyizhou <liyizhou@huawei.com>
To: Linda Dunbar <linda.dunbar@huawei.com>, "draft-ietf-trill-active-active-connection-prob.all@tools.ietf.org" <draft-ietf-trill-active-active-connection-prob.all@tools.ietf.org>
Thread-Topic: [trill] question to draft-ietf-trill-active-active-connection-prob-05
Thread-Index: Ac+geKHYnnafxlduSjKQzXaIov80DQAFsF5A
Date: Wed, 16 Jul 2014 01:32:43 +0000
Message-ID: <D408889639FC5E4FADB4E00A3E01FA8F5E8D9DA0@nkgeml503-mbx.china.huawei.com>
References: <4A95BA014132FF49AE685FAB4B9F17F645D9D27B@dfweml701-chm.china.huawei.com>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D9D27B@dfweml701-chm.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.136.126]
Content-Type: multipart/alternative; boundary="_000_D408889639FC5E4FADB4E00A3E01FA8F5E8D9DA0nkgeml503mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/trill/2m6XR_41rLeqfThW5UOioXLY7Ig
Cc: "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] question to draft-ietf-trill-active-active-connection-prob-05
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Jul 2014 01:32:58 -0000

Hi Linda,

Pls see inlines with [yz].

From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, July 16, 2014 6:04 AM
To: draft-ietf-trill-active-active-connection-prob.all@tools.ietf.org
Cc: trill@ietf.org
Subject: [trill] question to draft-ietf-trill-active-active-connection-prob-05

Dear Editors,

A few questions to this draft:

Section 2 second paragraph stated that " TRILL AF provides both per Data Label active-standby traffic spreading and loop avoidance".

TRILL AF requires one and only one appointed RBridge to ingress/egress native frames, so it doesn't provides "traffic spreading", correct?
[yz] It provides the traffic spreading based on VLAN. E.g. RB1 and RB2 are connected to the same local Ethernet. RB1 may be appointed as AF for VLAN 10 and RB2 appointed as VLAN 11. This is considered as vlan based traffic spreading for traffic  ingressing into TRILL campus.

What is "flow rather than VLAN based load balancing"? does it mean the CE has to  distribute load based on non-VLAN header fields of the packets?
[yz] VLAN based traffic spreading was explained previously. Flow based loading balancing basically talks about the MC-LAG like behaviors. Bundled links have their own way to decide which traffic sends to which member link. Mostly packets from a flow always go through the same link. Therefore traffic injecting to trill campus is considered as flow based spreading among the edge RBridges.
Please refer to section 2.1:
c)The LAALP will attempt to send all frames for a given flow on the
   same uplink. To do this, it has some unknown rule for which frames
   get sent to which  uplinks (typically based on a simple hash function
   of Layer 2 through 4 header fields).


Section 2.1:  What does it mean by "at exactly one edge group RBridge"?
a) The LAALP will deliver a frame from an endnode to TRILL at exactly one edge group RBridge.
[yz] It means a single packet will never be delivered by two or more member links of a single MC-LAG simultaneously.

Why can't LAALP assume ""these are all the MAC addresses attached""?


Section 3.3: Address Flip-Flop
Why current TRILL switches behave badly when same MAC-SA is associated with different TRILL nicknames? Why can't TRILL switches be configured to allow different TRILL nicknames to be associated with the same MAC-SA?
[yz] MAC-nickname correspondence is learned through the data frame received at the data plane. A new learning will replace the old one if source MAC-SA are the same. Current silicon is working in this way.
Different TRILL nicknames to be associated with the same MAC-SA can be implemented using control plane learning by disabling the data plane learning. You may refer to draft-zhang-trill-aa-multi-attach for details.


Section 3.4:
The flooding described in this section is no different from the "flooding" caused by aged out MAC entry in FDB, isn't it?
[yz] Right. The flooding referred here is TRILL campus flooding.

Thanks,
Yizhou

Thanks,
Linda