IETF Logo Mail Archive

Re: [trill] New version : TRILL Smart Endnodes draft

Linda Dunbar <linda.dunbar@huawei.com> Thu, 10 January 2013 17:42 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB6921F8A27 for <trill@ietfa.amsl.com>; Thu, 10 Jan 2013 09:42:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.298
X-Spam-Level:
X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkS8EF6sEk8S for <trill@ietfa.amsl.com>; Thu, 10 Jan 2013 09:42:50 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 126C821F89FC for <trill@ietf.org>; Thu, 10 Jan 2013 09:42:48 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANJ25784; Thu, 10 Jan 2013 17:42:47 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 Jan 2013 17:41:31 +0000
Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 Jan 2013 17:42:45 +0000
Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Thu, 10 Jan 2013 09:42:39 -0800
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Radia Perlman <radiaperlman@gmail.com>, Phanidhar Koganti <pkoganti@brocade.com>
Thread-Topic: [trill] New version : TRILL Smart Endnodes draft
Thread-Index: AQHN7eZvBDHzFA5/eke6FKO9FjPC95hC0tRg
Date: Thu, 10 Jan 2013 17:42:38 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6450E0647@dfweml505-mbx>
References: <D5A6F3355F664C40AFB65BB1277D8D450186C7F7AD@MAAX7MCDC101.APAC.DELL.COM> <6895EAE0CA8DEE40B92D7CA88BB521F32414007827@HQ1-EXCH02.corp.brocade.com> <CAFOuuo7t8xt8Z1mx78G2SsE8tkmAMNs44xd11Mc43S1_WfH6RA@mail.gmail.com>
In-Reply-To: <CAFOuuo7t8xt8Z1mx78G2SsE8tkmAMNs44xd11Mc43S1_WfH6RA@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.150.48]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F6450E0647dfweml505mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "d3e3e3@gmail.com" <d3e3e3@gmail.com>, "Kesava_Vijaya_Krupak@Dell.com" <Kesava_Vijaya_Krupak@dell.com>, "hu.fangwei@zte.com.cn" <hu.fangwei@zte.com.cn>, "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] New version : TRILL Smart Endnodes draft
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 10 Jan 2013 17:42:51 -0000

Radia,

Questions inserted below:


a) When the packet reaches the egress RB I am presuming there will be a inner-MAC lookup to deliver the packet to the egress end-node.

correct...when egress RB R has to look up the inner MAC address E, which it has to do anyway without smart endnodes, in order to choose which port to forward it on.  With smart endnodes, when R looks up MAC address E, it not only discovers which port to send it on, but that E is "smart", in which case R must leave the TRILL encapsulation

[Linda] Why can't the egress RB R simply decapsulates the TRILL header and forward the data frame towards the attached end nodes? Regardless if the DA is smart node or not?
So RB processing is much simpler. It doesn't have to attach different Ethernet header based on the inner DA. The smart node can receive Ethernet frames anyway (for communication within the directly attached LAN).

Thanks, Linda

v2.23.0 | Report a Bug | By Email