Re: [trill] [TRILL FGL] A question about RFC7172

Zouwenyu <zouwy@h3c.com> Mon, 26 May 2014 02:29 UTC

Return-Path: <zouwy@h3c.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 7086A1A01C8 for <trill@ietfa.amsl.com>; Sun, 25 May 2014 19:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.597
X-Spam-Level: ***
X-Spam-Status: No, score=3.597 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no
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 4WAaT7TRlgpO for <trill@ietfa.amsl.com>; Sun, 25 May 2014 19:29:16 -0700 (PDT)
Received: from h3cedge03-ex.h3c.com (unknown [60.191.123.56]) by ietfa.amsl.com (Postfix) with ESMTP id A86E71A01C7 for <trill@ietf.org>; Sun, 25 May 2014 19:29:15 -0700 (PDT)
Received: from H3CHUB02-EX.srv.huawei-3com.com (10.63.16.140) by h3cedge03-ex.h3c.com (172.25.12.83) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 26 May 2014 10:29:10 +0800
Received: from H3CHUB03-EX.srv.huawei-3com.com (10.63.20.169) by H3CHUB02-EX.srv.huawei-3com.com (10.63.16.140) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 26 May 2014 10:29:10 +0800
Received: from H3CMLB02-EX.srv.huawei-3com.com ([fe80::399d:90f6:c5bb:9cc0]) by H3CHUB03-EX.srv.huawei-3com.com ([fe80::c84b:4b9d:201d:b1fd%15]) with mapi id 14.01.0355.002; Mon, 26 May 2014 10:29:06 +0800
From: Zouwenyu <zouwy@h3c.com>
To: Donald Eastlake <d3e3e3@gmail.com>
Thread-Topic: [trill] [TRILL FGL] A question about RFC7172
Thread-Index: AQHPdyKMxbt3Onz3tkSV77lqjE1kdptPRUOAgALV97U=
Date: Mon, 26 May 2014 02:29:04 +0000
Message-ID: <71089ADE91738F4EB3602A5924674BF72E137C59@H3CMLB02-EX.srv.huawei-3com.com>
References: <71089ADE91738F4EB3602A5924674BF72E134C22@H3CMLB02-EX.srv.huawei-3com.com>, <CAF4+nEGYSRP-9uTYGO2dRZxCGho1Qd8dUvLD=NP0oQvba0ks3Q@mail.gmail.com>
In-Reply-To: <CAF4+nEGYSRP-9uTYGO2dRZxCGho1Qd8dUvLD=NP0oQvba0ks3Q@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.152.160.204]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/trill/BpXOR-0OF4PbYYXYYjAAbhDDjBk
Cc: "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] [TRILL FGL] A question about RFC7172
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: Mon, 26 May 2014 02:29:18 -0000

Hi Donald,

________________________________________
From: Donald Eastlake [d3e3e3@gmail.com]
Sent: Saturday, May 24, 2014 22:31
To: zouwenyu 06026
Cc: trill@ietf.org
Subject: Re: [trill] [TRILL FGL] A question about RFC7172

>Hi Wenyu,

>On Sat, May 24, 2014 at 4:00 AM, Zouwenyu <zouwy@h3c.com> wrote:
>> Hi Donald,
>>
> >    In RFC7172, there are three types of RBridge: VL RBridge, FGL-safe
> >RBridge and FGL RBridge.
>>
>>    As specified in [RFC7172], Section 8.2, the flag 1 in the TRILL-VER
>> sub-TLV should be set to indicate that a RBridge is FGL-safe.
>>
>>     For FGL-edge RBridge, the Interested Labels and Spanning Tree Roots
>> Sub-TLV which is specified in [RFC7176], Section 2.3.8, could indicate that
>> a RBridge is FGL RBridge.
>>
>>     But how to decide whether a RBridge is FGL or not, which is only a
>> transit FGL RBridge? I have not seen any TLV or flags to indicate that.

>Generally all FGL RBridges are also FGL-safe. The only difference is
>that an FGL RBridge can ingress a native frame to an FGL TRILL data
>packet and it can egress an FGL TRILL data packet to a native frame.

>If an FGL RBridge is a transit RBridge, then it is not ingressing or
>egressing, so why would any other RBridge in the TRILL campus care if
>it is an FGL RBridge or not? As long as the other RBridges know that
>it is FGL-safe, they know they can route TRILL data through it.

  In [RFC7172], Section 4.1.1, it says this words, "Ingress as a TRILL multi-destination data packet (TRILL Header M bit = 1) on a distribution tree rooted at a nickname held by an FGL RBridge or by the pseudonode of an FGL link. ". In this descriptions, does the FGL RBridge mean both FGL RBridge and FGL-safe RBridge? In this way, for a native multi-destination frame which is FGL ingressed, the ingress RB must select a tree root held by a RBridge whose flag 1 in the TRILL-VER sub-TLV is set, and do not care whether a RBridge is FGL or FGL-safe.
Does it work like this?

Thanks.
Regards,
wenyu

>Presumably the network manager knows because the network manager knows
>what the equipment they are managing can do. So if some FGL-safe
>RBridge is not advertising interest in any FGL labels in an Interested
>Labels sub-TV, the network manager would know if it could be
>configured to ingress/egress to/from FGL -- and if it was so
>configured it would then start advertising interest in one or more FGL
>labels with the Interested Labels sub-TLV.

>Does this answer your question?

>Thanks,
>Donald
>=============================
> Donald E. Eastlake 3rd   +1-508-333-2270  (cell)
> 155 Beaver Street, Milford, MA 01757 USA
> d3e3e3@gmail.com

>> Thanks.
>> Regards,
>> wenyu
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有杭州华三通信技术有限公司的保密信息,仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、
或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本
邮件!
This e-mail and its attachments contain confidential information from H3C, which is
intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender
by phone or email immediately and delete it!