Re: [Pppext] Comment related to draft-ietf-pppext-trill-protocol-01.txt

James Carlson <carlsonj@workingcode.com> Mon, 03 January 2011 19:19 UTC

Return-Path: <carlsonj@workingcode.com>
X-Original-To: pppext@core3.amsl.com
Delivered-To: pppext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084A93A6B00 for <pppext@core3.amsl.com>; Mon, 3 Jan 2011 11:19:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.672
X-Spam-Level:
X-Spam-Status: No, score=-101.672 tagged_above=-999 required=5 tests=[AWL=0.927, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUIgEXp0KeYY for <pppext@core3.amsl.com>; Mon, 3 Jan 2011 11:19:23 -0800 (PST)
Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id E40493A6B01 for <pppext@ietf.org>; Mon, 3 Jan 2011 11:19:22 -0800 (PST)
Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p03JLO20023506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Jan 2011 14:21:25 -0500 (EST)
Message-ID: <4D2221B4.3020504@workingcode.com>
Date: Mon, 03 Jan 2011 14:21:24 -0500
From: James Carlson <carlsonj@workingcode.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: Donald Eastlake <d3e3e3@gmail.com>
References: <AANLkTi=nEvL_uWiwFb9N=oC6B7_gBpLBby69UC6JT6a+@mail.gmail.com> <4D221538.4000004@workingcode.com> <AANLkTing=Vg9xkduBFkz8_F+VEXJBRd=RieegL_hyp2M@mail.gmail.com>
In-Reply-To: <AANLkTing=Vg9xkduBFkz8_F+VEXJBRd=RieegL_hyp2M@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-DCC-x.dcc-servers-Metrics: carlson; whitelist
Cc: pppext@ietf.org, Erik Nordmark <nordmark@acm.org>, Radia Perlman <radia@alum.mit.edu>
Subject: Re: [Pppext] Comment related to draft-ietf-pppext-trill-protocol-01.txt
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pppext>
List-Post: <mailto:pppext@ietf.org>
List-Help: <mailto:pppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jan 2011 19:19:24 -0000

Donald Eastlake wrote:
>>> In particular, does it cover the PPP Header, in which case I
>>> think it should be labeled "PPP FCS"? Or should the convention in PPP
>>> be to have an FCS just covering the encapsulated Ethernet frame?
>>>
>>> In any case, I think a few words about this are needed in the
>>> pppext-trill draft...
>> We don't normally do that for PPP documents -- it's assumed that the NCP
>> document just covers the bits that are particular to that NCP, and not
>> all of the common PPP bits all the way down to the bare metal -- but I
>> guess I can do that if it'll help with alignment with the other TRILL
>> documents.
> 
> Well, I would assume the RFC resulting from
> draft-ietf-pppext-trill-protocol will in some cases be read by people
> familiar with TRILL but not familiar with PPP. So, while it certainly
> doesn't need much, making it clear that there is no Ethernet FCS in
> the encapsulated material and having references pointing at the PPP
> Trailer info seem like a good idea to me.

I've made the updates for both -- making it clear that the Ethernet FCS
is not present and that the PPP FCS (if any) is used.  I'll send you a
draft to look over.

(I think that if they're reading this and don't know much about PPP, I
think they're probably in a world of hurt.  Or at least their customers
are going to be.  I'm not about to turn this simple draft into a road
map for implementation of PPP.)

>> (For what it's worth, I don't think the TRILL document should mention
>> the Ethernet FCS, either.  TRILL isn't defining Ethernet encapsulation,
>> and including those bits seems like duplication.  But I suppose that's
>> just me ...)
> 
> More than once I've gotten specific questions about whether or not the
> "encapsulated Ethernet frame" inside a TRILL Data frame includes an
> Ethernet FCS just covering the encapsulated material. So I think it is
> better that this sort of thing be mentioned.

Same planet, different universes, I guess.  ;-}

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>