Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt
Linda Dunbar <linda.dunbar@huawei.com> Mon, 19 November 2012 20:53 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 CD95D21F8753 for <trill@ietfa.amsl.com>; Mon, 19 Nov 2012 12:53:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.409
X-Spam-Level:
X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, 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 ryDUKAUfDjND for <trill@ietfa.amsl.com>; Mon, 19 Nov 2012 12:53:18 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C249921F8768 for <trill@ietf.org>; Mon, 19 Nov 2012 12:53:16 -0800 (PST)
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 AMY36101; Mon, 19 Nov 2012 20:53:12 +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; Mon, 19 Nov 2012 20:52:42 +0000
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.3; Mon, 19 Nov 2012 20:53:09 +0000
Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Mon, 19 Nov 2012 12:53:06 -0800
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Thomas Narten <narten@us.ibm.com>, Erik Nordmark <nordmark@acm.org>
Thread-Topic: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt
Thread-Index: AQHNwqzc/scuXvCj5EaZk4DoqUzctJfxzbyA///cWTA=
Date: Mon, 19 Nov 2012 20:53:05 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645098C4C@dfweml505-mbx>
References: <CAF4+nEH9_MkMTDDG7jn_xipXV-feu4Xy0GyH9NyNO_5EaNw3nQ@mail.gmail.com> <50A4095E.80009@acm.org> <201211191459.qAJExZdv001769@cichlid.raleigh.ibm.com>
In-Reply-To: <201211191459.qAJExZdv001769@cichlid.raleigh.ibm.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.170]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt
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: Mon, 19 Nov 2012 20:53:18 -0000
Thomas, Your comments are for "fine labeling" draft but not to "directory framework", is it? Linda > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf > Of Thomas Narten > Sent: Monday, November 19, 2012 9:00 AM > To: Erik Nordmark > Cc: trill@ietf.org > Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory- > framework-01.txt > > I have read the document, and want to raise some basic questions about > this document. > > An original premise for this document was that it would use the same > Ethertype=0x8100 encoding for the inner header as the the base > protocol. This was done for backwards-compatability with base RBs and > to allow non-FGL aware RBs to forward FGL frames. Under this > assumption, having the labels split into two different parts using > separate fields made sense. > > However, with the -01 revision, the above assumption has been thrown > out. FGLs now use a different ethertype encoding, and various parts of > the document make it clear that an RB operates in either FGL or VL > mode, with no overlap or backwards compatability. RBs implementing VL > are not supposed to receive or process FGL formatted TRILL data > frames. > > Given that, I do not see a compelling justification for retaining the > "double tagging" encoding format the current document > supports. Specifically, I'd suggest: > > 1) not having separate high-order and low-order FGL fields; just > define one field that is 24 bits long. > > 2) Remove the second ethertype=0x893B field completely. We are just > wasting 2 bytes. (the field serves no useful purpose and must always > hold the value of 0x893B.) > > 3) While I don't have a strong opinion either way, I would also like > to see a justification for having an "Alternate Priority" field. The > base TRILL protocol doesn't have one. Why is it needed for FGLs? > > Under the previous encapsulation format, we got the extra priority > "for free" since it was part of the TAG, but I'd like to see the > rational/use case for having this extra field stand on its own > merits. Is this just a "what the heck, why not" field? Or is there a > compelling use case for it? > > I am also uncomfortable with some of the wording in the document > regarding "silicon". > > > 2. Silicon Considerations > > > > Fine-grained labeling (FGL) should, to the extent practical, > use > > existing features, processing, and fields that are already > > supported in at least some fast path silicon implementations > that > > currently support the TRILL base protocol. > > This makes sense. We do not want to pick encodings that will be > problematatic for silicon (generally). However, we also need to > balance such a desire against not restricting our design solely to > favor, say, one particular implementation. (I am not suggesting that > is being done here, just pointing out that if the current encoding > does favor certain implementations, we need to be upfront about that, > and discuss the implications openly.) > > > 2. Silicon Considerations: Existing TRILL fast path silicon chips > can > > perform base TRILL Header insertion and removal to support > ingress > > and egress. In addition, it is believed that most such silicon > > chips can also perform the native frame to FGL mapping and the > > encoding of the FGL as specified herein, as well as the inverse > > decoding and mapping. Some existing silicon can perform only > one > > of these operations on a frame in the fast path and is thus not > > suitable to implement fast path TRILL FGL processing; however, > > other existing chips are believed to be able to perform both > > operations on the same frame in the fast path and are suitable > for > > FGL implementation. > > My impression in talking to folk familiar with silicon implementations > is that silicon has gotten pretty good at being able to extract fields > from fixed arbitrary offsets into a packet. Thus, while they may be > able to extract the two separate labels and combine them (as the > current proposal calls for), they can just as easily extract a single > label of 24 bits. > > If we are going to stick with the current encoding, I'd like to hear > directly from the silicon implementors why that is *necessary* and why > they cannot support the more natural/obvious format for 24-bit labels. > > I have additional comments on the draft, but they may not be relevant > depending on how the above points are resolved. > > Thomas > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill
- [trill] WG Last Call: draft-ietf-trill-directory-… Donald Eastlake
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Linda Dunbar
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Erik Nordmark
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Radia Perlman
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Erik Nordmark
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Linda Dunbar
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Sam Aldrin
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Thomas Narten
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Linda Dunbar
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Linda Dunbar
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Yizhou Li
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Black, David
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Linda Dunbar
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Donald Eastlake
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Black, David
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Donald Eastlake