Re: [forces] AD review of draft-ietf-forces-interfelfb

Jamal Hadi Salim <> Thu, 26 May 2016 11:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B495E12D650 for <>; Thu, 26 May 2016 04:39:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GY_hPJRrU2rV for <>; Thu, 26 May 2016 04:39:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A46E12DE1A for <>; Thu, 26 May 2016 04:39:29 -0700 (PDT)
Received: by with SMTP id x7so55748749qkd.3 for <>; Thu, 26 May 2016 04:39:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vDqeKChFm8XkaRGZcAbHeQFFq8A/wJyr3wGBgihhjUc=; b=XCnIeo4Nj9EXJcLaLYDp6P3DX5kktd9E6nrhvG3qYK4p/axB2Co+EXMwtiFcVJ5JPi DpE04sBv4RVtObZgr8RRXZfzZq0vHHw9Snqfj5udpw7FFrGPUmcuGPAMikh7PghXdMMY kBG10na8Lu1pWTBJ4l2PDtQqxbA10gkTMLt7K3Dbt3x1UiTGjAbsf5+9RfJ+EOAyn3i0 I42DxfVGEtpxffFXER0hMJGsGQA4NzK1dg5qERiluep7575o6TwOxTBeDXr3Dg+MX0tY rugNgNdcp40UiPj5XA/nz7h9wOqR3QoNU/u6HkzBATdI4es7zLxxiS20GetJ1WY1twZn iN8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vDqeKChFm8XkaRGZcAbHeQFFq8A/wJyr3wGBgihhjUc=; b=D6unGigDKzKxHBFdsvWBhkUPv++FOT5UmO5IiviKHCYnebsXVUTvug+KarS4S5tL/b xTc6CfYngNobcuv/JUlyVzxh9mFRIyolG01eN1/3njx1kgEA7EAbSCBdvmcc6Nu/+Lei tIUyndBEUjBLvpJ5fRt7XvSf6kWkyme4TNjbxQqgL162Qyl0nB/Qx0vlFowxshLzMoGy 0cgf8czxgR7bkUyZyXibpVG2NTwiJC6TRMDjB5M7mTPjYqibtZwwXc06A/sk8Q+e4saW l17NooSPWz56W5br9fgw4yyPgFMIM9k1/i9mzAcVuQ6tiX0a35fd+3qz4H25QNrT4yka TOoQ==
X-Gm-Message-State: ALyK8tLoaFYSGsMWk1D9Cs7S91oBGF2vjX/MAfIXyHVI9KRPoNX5TXFyPnAcz0IIo7LRF0PdfoWaTN91uSCcSA==
X-Received: by with SMTP id n134mr8644329qkn.10.1464262768081; Thu, 26 May 2016 04:39:28 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 26 May 2016 04:39:07 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Jamal Hadi Salim <>
Date: Thu, 26 May 2016 07:39:07 -0400
Message-ID: <>
To: Alia Atlas <>
Content-Type: multipart/alternative; boundary="94eb2c095a7c26716b0533bd3ef9"
Archived-At: <>
Cc: "" <>,
Subject: Re: [forces] AD review of draft-ietf-forces-interfelfb
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: ForCES WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 May 2016 11:39:33 -0000

Hi Alia,

On Wed, May 25, 2016 at 6:03 PM, Alia Atlas <> wrote:

> As is customary - particularly with an AD sponsored draft, I have done a
> final review before requesting that this document proceed to IETF Last Call.
> First, I would like to thank Jamal and Damascene for their hard work on
> this final document and really improving it.
We wouldnt have gone this far without your dilligence to details. Thank

> Evangelos, thank you for shepherding this document.  Please do update the
> shepherd's report.  I know it has been a couple years but many on the IESG
> do read the entire shepherd's report and it needs to be up to date.
> While I do have some minor comments from my most recent review, I believe
> that these can all be fixed during IETF Last Call.  Please do so ASAP;
> draft numbers are cheap and it is highly advantageous to have folks reading
> the most recent version so they don't pick on the same issues.
Some responses to your comments below and then we can proceed to
updating and publishing.

> With the expectation that any issues found in IETF Last Call will be dealt
> with rapidly, I am placing this  on the telechat for June 16.
> Minor:
> a)In Sec 5.2:  "Ethertype 0xFEFE is to be used (XXX: Note to editor, likely
>       we wont get that value - update when available)."   PLEASE update
> this to be Ethertype TBA1 is to be used.  Then in IEEE assignment
> considerations, specify that the EtherType TBA1 requires allocation &
> possibly indicate that an experimental value of 0xFEFE has been used.  Is
> that one of the playpen EtherTypes available?

OxFEFE is not one of the available playpen  EtherTypes. We ended
enforcing the user to specify it in the deployed tools (on Linux).
So people ended using different values none of which will stick. Once
this value is issued we'll make it the default. Would be an easy 1-2
line patch.

b) In Sec 6.1.1:  Similarly, it says "If IFETYPE is absent then the standard
>       Inter-FE LFB Ethernet type is used (XXX: Note to editor, to
> be updated)."
> Please update to TBA1 and add a reference to the IEEE Assignment
> Considerations section.
Will do.

> c) In Sec 6.1.1: "Encapsulate each allowed Metadatum in a TLV. Use the
> Metaid as
>       the "type" field in the TLV header.  The TLV should be aligned to
>       32 bits.  This means you may need to add padding of zeroes to
>       ensure alignment."
> Trivial, but please clarify that the padding of zeroes is added at the end
> of the TLV.
Will do.

> d) In Sec 6.1.2: "If an unknown Metadatum id is encountered, or if the
> metaid is not in
>       the allowed filter list the implementation is expected to ignore
>       it, increment the packet error statistic and proceed processing
>       other Metadatum."
> Can you please clarify if the "packet error statistic" is incremented once
> per unknown Metadatum or metaid - or once per packet that has such a
> metadatum?  The field description makes me think it is once per packet.
> Knowing the excitement that exists around computing worst-case number of
> counter increments per packet, I hope so.
The current deployment is _per metaid_;->
But i think it makes sense to make it per packet. It is a trivial change.
I can update the doc to make it per-packet and then patch Linux version.
Would that be fine with you?

> It would also be useful to indicate which componentID is mentioned - since
> this is normative.
Parse error.  Which componentID?

> 1) Figure 6:  the title should be "Packet format definition" and not
> "Packet format suggestion".  This needs wording for a standard :-)
;-> Will fix.

> 2) Sec 5.2: "However, at the time of publication we believe
>       this is sufficient to carry all the info we need and approach
>       taken would save us 4 bytes per Metadatum transferred."
> Please reword as for a standard (e.g. "...need; this approach has been
> selected because it saves 4 bytes per metadatum transferred."
Will fix.

Alia, a pleasure as always - worth the wait to see your comments.


> Regards,
> Alia