Re: [trill] FW: New Version Notification for draft-tissa-trill-mt-encode-01.txt

Donald Eastlake <> Thu, 12 July 2012 15:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CF1F21F880B for <>; Thu, 12 Jul 2012 08:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.206
X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XFUaSVT1lAvk for <>; Thu, 12 Jul 2012 08:26:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7E2D121F8723 for <>; Thu, 12 Jul 2012 08:26:18 -0700 (PDT)
Received: by yenq13 with SMTP id q13so2756294yen.31 for <>; Thu, 12 Jul 2012 08:26:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=s7o6pANsbm9Bs/oe3cTMCHhr9i4JcMVaDpj/AuiYX48=; b=MEqAmx06O2zTSn16Ure6/27vC8T95WACGkIIhvhWTzKi9W+0Udpu/i3HpPx+j/cd4x jsGA7UTUPhaBp3unZWyCjpFi6Fv9cFsZs46GrzcMr49wzeRwap96ncYQOpBR7VJMuaLV Rt2GJJ86DuzWs2uFz0jxlQLsy9qGJCkcmDONH7X0Vzj93BghIaM5cC8GxIMl+SibNOkH 3nDmEOMt1tug4OQFnt+6//ycpyRySUjz1NkqgULsn0ypudOhc27BpZ6ZS+vf95WQKiRm Fluee/7lieA8/ZokVCg3x0J5cIlvvZmmNB4UsC0Gc1iY5BN9JUR0Rvv79conu4RXEKuI 1W5A==
Received: by with SMTP id ip8mr17947094igc.50.1342106811430; Thu, 12 Jul 2012 08:26:51 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 12 Jul 2012 08:26:25 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Donald Eastlake <>
Date: Thu, 12 Jul 2012 11:26:25 -0400
Message-ID: <>
To: Naveen Nimmu <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "" <>
Subject: Re: [trill] FW: New Version Notification for draft-tissa-trill-mt-encode-01.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Jul 2012 15:26:20 -0000

A few comments:

It seems to me that the top level difficulty with this draft is that
it assumes that TRILL is an Ethernet protocol. But it isn't. Where do
these tags go in the TRILL Data frame on a PPP link [RFC6361] or in
the possible IPv4/6 link format in draft-mrw-trill-over-ip or in the
possible MPLS TRILL Data format in draft-ietf-l2vpn-trill-evpn? You
could put new tags after the Inner.VLAN or you could expand the TRILL
Header but trying to put new tags in front of the TRILL Header seems
problematic and also guarantees that only new hardware can process the
frame at all.

Ignoring the above problem and commenting on the multi-topology and
nickname expansion aspects of the draft:

I'm not sure why the topology ID tag has 16 bits of topology when all
the other IS-IS related topology things I know about have 12 bits of
topology ID and, in the real world, I understand it is very rare to
use more than around 8 topologies. Also, the interesting alternative
of encoding the topology in the Outer.VLAN tag, which only works on
Ethernet links, would tend to use the 12-bit VLAN ID for topology
although I suppose, depending on how big a change you are making in
the port silicon, you could repurpose the priority and DEI bits...
Anyway, having a few reserved flag bits sometimes turns out to be
extremely useful so I'm thinking that sticking with 12 bits would be
better. And, in any case, redefining the content of the VLAN tag while
continuing to use the C-VLAN Ethertype would be viewed as a problem by

I'm not sure why there has to be an MT Capability bit. Wouldn't just
not including the MT TLV be a good enough indication if you required
even an MT capable RBridge only participating in base topology zero to
include the MT TLV?

If you are going to expand the nickname space, I don't quite see why
you only add 8 bits and why, it appears, you are going for a larger
flat nickname space. There is power in hierarchy. Perhaps you mean for
the 8 bits to be used somewhat hierarchically for naming areas in
multi-level or the like but it doesn't sound like that. Going to a
flat 24-bit nickname seems like it, in general, requires new silicon
and biases the design towards high end switches with bigger tables,
etc. If you need new silicon anyway, I think that adding 16-bits with
a fixed hierarchy split of the upper and lower 16-bit parts and using
something like the "swap nickname" logic suggest in
draft-perlman-trill-rbridge-mulilevel-04.txt would enable forwarding
tables to remain small and better support a wider range of switches.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

On Mon, Jun 18, 2012 at 3:12 PM, Naveen Nimmu <> wrote:
> A new version of this draft is posted. This version adds  proposed  extensions to support TRILL nickname space from 16bits to 24 bits.
> Please review and provide feedback.
> Thanks
> \naveen
> -----Original Message-----
> From: []
> Sent: Monday, June 18, 2012 8:13 AM
> To:
> Cc:;; Naveen Nimmu;
> Subject: New Version Notification for draft-tissa-trill-mt-encode-01.txt
> A new version of I-D, draft-tissa-trill-mt-encode-01.txt
> has been successfully submitted by Tissa Senevirathne and posted to the
> IETF repository.
> Filename:        draft-tissa-trill-mt-encode
> Revision:        01
> Title:           Multi Topology Encoding within TRILL data frames
> Creation date:   2012-06-17
> WG ID:           Individual Submission
> Number of pages: 12
> URL:   
> Status:
> Htmlized:
> Diff:  
> Abstract:
>    Two alternate methods of encoding Multi Topology Identifier within
>    the TRILL data frames are presented. Methods proposed herein do not
>    require overloading TRILL RBridge nickname to encode Multi Topology
>    Identifier. A method that expands TRILL nickname space from 16bits
>    to 24 bits is also presented in this draft.
> The IETF Secretariat
> _______________________________________________
> trill mailing list