IETF Logo Mail Archive

Re: [trill] Comments on draft-dunbar-trill-directory-assisted-encap

Linda Dunbar <linda.dunbar@huawei.com> Sat, 03 August 2013 06:40 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 31EB921E8055 for <trill@ietfa.amsl.com>; Fri, 2 Aug 2013 23:40:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoita9dNXuBM for <trill@ietfa.amsl.com>; Fri, 2 Aug 2013 23:40:52 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2E20F21F8528 for <trill@ietf.org>; Fri, 2 Aug 2013 23:40:51 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVR65333; Sat, 03 Aug 2013 06:40:49 +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.7; Sat, 3 Aug 2013 07:39:11 +0100
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 3 Aug 2013 07:39:29 +0100
Received: from DFWEML509-MBB.china.huawei.com ([169.254.2.150]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Fri, 2 Aug 2013 23:39:24 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "hu.fangwei@zte.com.cn" <hu.fangwei@zte.com.cn>, "trill@ietf.org" <trill@ietf.org>
Thread-Topic: [trill] Comments on draft-dunbar-trill-directory-assisted-encap
Thread-Index: AQHOjc0haY/DvGwH5UiYOaL3v+46bZmDCrpA
Date: Sat, 03 Aug 2013 06:39:23 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B59D4E@dfweml509-mbb.china.huawei.com>
References: <OF10955279.2DB02A44-ON48257BB9.002D2B5B-48257BB9.00307306@zte.com.cn>
In-Reply-To: <OF10955279.2DB02A44-ON48257BB9.002D2B5B-48257BB9.00307306@zte.com.cn>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.201.194.87]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645B59D4Edfweml509mbbchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [trill] Comments on draft-dunbar-trill-directory-assisted-encap
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: Sat, 03 Aug 2013 06:40:57 -0000

Fang Wei,

Sorry for the delayed response. Answers to your comments are inserted below:

From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of hu.fangwei@zte.com.cn
Sent: Wednesday, July 31, 2013 10:49 AM
To: trill@ietf.org
Subject: [trill] Comments on draft-dunbar-trill-directory-assisted-encap


Hi, Linda

I have several comments:

(1) We say that E1 is the "Non-RBridge Nodes", R1 is the local edge RBridge. E1 will encapsulate the TRILL encapsuation with the ingress nickname as "Phantom nickname", and  egress nickname as the nickname of R1(we say it N1). The encapuslation frame will be forwarded to R1. My question is that, how R1 know that the trill encapuslation frame is sent by E1(Non-RBridge node)?

[Linda] There is an Ethernet header in front of the RBridge header. R1 knows that the frame from is from E1 from the MAC-SA.


(2) The concept of  'TRILL   Encapsulating node'' or ''Simplified RBridge' is defined in section 3. But it never used in the document. Is it the same meaning with non-RBridge nodes?

[Linda] We call a non-RBridge nodes that can encapsulate TRILL header as "TRILL Encapsulating node", or "Directory reliant smart end node". We can finalize the term when going through the WG adoption.

Linda



Fangwei

Regards

v2.23.0 | Report a Bug | By Email