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

"Evangelos Haleplidis" <> Wed, 22 June 2016 20:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B07F12DBF2; Wed, 22 Jun 2016 13:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hTKqbIY_nXK5; Wed, 22 Jun 2016 13:50:30 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED0DD12D9CD; Wed, 22 Jun 2016 13:50:29 -0700 (PDT)
Received: by with SMTP id a66so22143353wme.0; Wed, 22 Jun 2016 13:50:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=dtlA8EB+TZdwlz2x+IV2V2/+jUePbhzodEZ0Fr23ASw=; b=go1cAMbc8GycOPwnSXaD3kGezyteenAKZV6x+G9DJj+JSV7iiORtc5Je/u714exuCD R+aQltOEGwBs4pY3yf+bp+8OKQd7jSIYQfIOKT+goIKHm7Il1jG63GJ3qokTSd2094Lt 1d2Vwy9ZTvaQj1xd4Ze71/KOnXxPFZUBccOrEl6ofg/evlkYj9JFPlTFDi7ZkRM5O9Ep 8wLFdverqs262Bb9bODzdZwqE/poVHy0lg2uv1jzQgW41P8i+iQfCgydtBcdbLj6yyY2 QRwzeRa6SuMgBGqc64cR5TmbexgIT8u3klXzt1JNmwlBUVwfZqF3LSQONJJ8xpbypSds hrTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=dtlA8EB+TZdwlz2x+IV2V2/+jUePbhzodEZ0Fr23ASw=; b=ksijcc4pLGw8bX3v4s7NYmjv9bS8EH1xhMl1H1sjG2zMQJywyU8dKQyAuhK0Hhsj86 7qOeLytSX+KZwqd1buBGTnUYREfnqJuoVTkaGOZx6b4S7W9CsPPcFq//WrEa5Kj7kZDs LyHN9UrwVW0ymt9DltXkPOWmVFNN7vxkOiVI9y+PAOdDR3iOH029GJQXpvz0qlDYzg/3 d9eqGVggpDxFKPxuqRvI+iTKeFQ9Kyr+Svb0Xe2Ub+cXpN0RPmh6Yr6EHs/7idy55Vrs +75DC/oOal6knMQz/TYsh+/o7Hnqm9ObOnqPPsTbKFGmf3WbiYStKuw2dRZnXAJIzF4+ s1uQ==
X-Gm-Message-State: ALyK8tI75w1qm5qUSuoynXJUYJovQyP2FvQbJFTfw8uThGSoencH5Xe4JLg+X3yQ/9pRHQ==
X-Received: by with SMTP id bd1mr28804003wjc.109.1466628628221; Wed, 22 Jun 2016 13:50:28 -0700 (PDT)
Received: from EhalepXPS ( []) by with ESMTPSA id p191sm557982wme.7.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 22 Jun 2016 13:50:27 -0700 (PDT)
From: Evangelos Haleplidis <>
To: 'Alia Atlas' <>,,
References: <>
In-Reply-To: <>
Date: Wed, 22 Jun 2016 23:50:23 +0300
Message-ID: <008901d1ccc7$b3b11460$1b133d20$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_008A_01D1CCE0.D8FE4C60"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdG20UVypjSTgiohS1SKiCAJlydZvAV9cQaQ
Content-Language: en-us
Archived-At: <>
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: Wed, 22 Jun 2016 20:50:34 -0000

Greetings Alia,


You may have already seen that Jamal has made a new submission for the interfe-lfb and I have updated the shepherd writeup.

Let me know if you want the writeup to contain more details.





From: Alia Atlas [] 
Sent: Thursday, May 26, 2016 01:03
To:; Evangelos Haleplidis;
Subject: AD review of draft-ietf-forces-interfelfb



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.


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.


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.




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?


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.


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.


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. 


It would also be useful to indicate which componentID is mentioned - since this is normative.




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


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."