[trill] more questions on "draft-ietf-trill-fine-labeling-01"
Linda Dunbar <linda.dunbar@huawei.com> Tue, 10 July 2012 23:05 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 1579F11E80BF for <trill@ietfa.amsl.com>; Tue, 10 Jul 2012 16:05:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.458
X-Spam-Level:
X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.140, 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 7en-CYd9mo-p for <trill@ietfa.amsl.com>; Tue, 10 Jul 2012 16:05:02 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7C35411E809F for <trill@ietf.org>; Tue, 10 Jul 2012 16:05:02 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHX39683; Tue, 10 Jul 2012 19:05:13 -0400 (EDT)
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 16:02:00 -0700
Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Tue, 10 Jul 2012 16:01:54 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Donald Eastlake <d3e3e3@gmail.com>
Thread-Topic: more questions on "draft-ietf-trill-fine-labeling-01"
Thread-Index: Ac1e7/+Wtx80f0G6TpCaa82jxaW5kw==
Date: Tue, 10 Jul 2012 23:01:52 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F63C2DDFFB@dfweml505-mbx>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.138.26]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F63C2DDFFBdfweml505mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "trill@ietf.org" <trill@ietf.org>
Subject: [trill] more questions on "draft-ietf-trill-fine-labeling-01"
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: Tue, 10 Jul 2012 23:05:04 -0000
Donald, et al, - Section 3 (page 7) 3rd paragraph: "Ethernet links between FGL TRILL switches still have only C-VLAN tagging on them" When you talk about Ethernet Links between FGL TRILL switches, the VID is the outer Ethernet header above the TRILL header. Is it always "C-VLAN"? Why have this restriction? - Section 5.1: Can FGL RBridge also do VL RBridge function? For example, when the C-VLAN of the incoming frame is the VL specifiable data label, the FGL RBridge just simply performs the VL RBridge function. Is it possible? - Same goes with Section 5.3: when X is VL specifiable only, why can't the FGL RBridge simply decapsulates the frame as regular VL RBridge? Thanks, Linda
- [trill] more questions on "draft-ietf-trill-fine-… Linda Dunbar
- Re: [trill] more questions on "draft-ietf-trill-f… Donald Eastlake