IETF Logo Mail Archive

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

Linda Dunbar <linda.dunbar@huawei.com> Thu, 10 January 2013 18:18 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 C168721F8A11 for <trill@ietfa.amsl.com>; Thu, 10 Jan 2013 10:18:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.448
X-Spam-Level:
X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 mgDvJwj+ypRF for <trill@ietfa.amsl.com>; Thu, 10 Jan 2013 10:18:51 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AFE9221F8A3E for <trill@ietf.org>; Thu, 10 Jan 2013 10:18:49 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANJ27181; Thu, 10 Jan 2013 18:18:47 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 Jan 2013 18:17:46 +0000
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 Jan 2013 18:18:47 +0000
Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Thu, 10 Jan 2013 10:18:42 -0800
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Radia Perlman <radiaperlman@gmail.com>
Thread-Topic: [trill] New version : TRILL Smart Endnodes draft
Thread-Index: AQHN7eZvBDHzFA5/eke6FKO9FjPC95hC0tRggACOc4D//3yQEA==
Date: Thu, 10 Jan 2013 18:18:41 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6450E06CD@dfweml505-mbx>
References: <D5A6F3355F664C40AFB65BB1277D8D450186C7F7AD@MAAX7MCDC101.APAC.DELL.COM> <6895EAE0CA8DEE40B92D7CA88BB521F32414007827@HQ1-EXCH02.corp.brocade.com> <CAFOuuo7t8xt8Z1mx78G2SsE8tkmAMNs44xd11Mc43S1_WfH6RA@mail.gmail.com> <4A95BA014132FF49AE685FAB4B9F17F6450E0647@dfweml505-mbx> <CAFOuuo7B74Y4iptName9fcXzYfarhV79t2_V7zPsDoBncsLFig@mail.gmail.com>
In-Reply-To: <CAFOuuo7B74Y4iptName9fcXzYfarhV79t2_V7zPsDoBncsLFig@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.192.11.236]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F6450E06CDdfweml505mbx_"
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 18:18:53 -0000

Radia,

It would be much simpler to let the egress RBridge send a freshly learned mapping to the Smart node when decapsulating a TRILL frame. By doing so, the (egress) RBridge doesn't have make any change to its current learning processing
If the RBridge can't keep up all the learned mapping due to massive number of end nodes, the egress RBridge doesn't  have to cache the mapping (or set the timer for the cache very small).

You can use the Hello message between RBridge and smart node to carry this mapping information.

Alternatively, let the Smart Node be assisted by Directory Servers, which makes lot of sense in Data Center environment.

Linda

From: Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Thursday, January 10, 2013 11:54 AM
To: Linda Dunbar
Cc: Phanidhar Koganti; d3e3e3@gmail.com; Kesava_Vijaya_Krupak@Dell.com; hu.fangwei@zte.com.cn; trill@ietf.org
Subject: Re: [trill] New version : TRILL Smart Endnodes draft

The reason RB has to leave it encapsulated when forwarding to a smart endnode is for the case where the smart endnode will be learning (destination MAC, egress nickname) from received traffic.

Radia
On Thu, Jan 10, 2013 at 9:42 AM, Linda Dunbar <linda.dunbar@huawei.com<mailto:linda.dunbar@huawei.com>> wrote:
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


_______________________________________________
trill mailing list
trill@ietf.org<mailto:trill@ietf.org>
https://www.ietf.org/mailman/listinfo/trill

v2.23.0 | Report a Bug | By Email