Last Call Review of draft-ietf-forces-interfelfb-02

Request Review of draft-ietf-forces-interfelfb
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-06-28
Requested 2016-06-02
Authors Damascane Joachimpillai, Jamal Hadi Salim
Draft last updated 2016-06-29
Completed reviews Genart Last Call review of -04 by Russ Housley (diff)
Genart Telechat review of -05 by Russ Housley (diff)
Opsdir Last Call review of -02 by Will LIU (diff)
Rtgdir Early review of -01 by Joel Halpern (diff)
Rtgdir Early review of -01 by Susan Hares (diff)
Assignment Reviewer Will LIU
State Completed
Review review-ietf-forces-interfelfb-02-opsdir-lc-liu-2016-06-29
Reviewed rev. 02 (document currently at 06)
Review result Has Nits
Review completed: 2016-06-29


Hi all,


(Sorry for being late due to travelling. )

I have reviewed draft-ietf-forces-interfelfb-05 as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving
 the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.


“This document describes how to extend the ForCES LFB topology across FEs by defining the Inter-FE LFB Class.  The Inter-FE LFB Class provides the ability to pass data and metadata across FEs without needing any changes
 to the ForCES specification.  The document focuses on Ethernet transport.”


My overall view of the document is 'Ready with nits' for publication.


* Section 1.2, page 3:


> 1.2.  Definitions


>    This document reiterates the terminology defined in several ForCES

>    documents [RFC3746], [RFC5810], [RFC5811], and [RFC5812] [RFC7391]

>    [RFC7408] for the sake of contextual clarity.


Either repeat the whole definitions, or state, for each term, which RFC defines which. otherwise, the reader will have to go through all these RFCs to look up each of the terms.



* Section 3.1, page 4:

>  lower

>       transports could be defined to carry the data and metadata it is


Missing comma after "metadata".



* Section 3.2


Why not provide IPv6 use cases, instead?



* Section 3.2.1, page 4:

>    A sample LFB topology depicted in Figure 1 demonstrates a service

>    graph for delivering basic IPV4 forwarding service within one FE.

>    For the purpose of illustration


s/IPV4/IPv4/. Same elsewhere.



* Section, page 6.


Please prevent the figures from being split into two pages.



* Section 5.1.3:


Maybe you should probably evaluate how the reduction in MTU size might potentially lead to Path-MTU Discovery problems?



* Section 6.1.1, page 15:

>    o  If the optional IFETYPE is present, set the Ethernet type to the

>       value found in IFETYPE.  If IFETYPE is absent then the standard

>       Inter-FE LFB Ethernet type is used (XXX: Note to editor, to be

>       updated).


"note to the editor" ? When to update?




Will (Shucheng LIU)


Shucheng LIU (Will), Ph.D.

Senior Researcher & Standard Representative, Project Manager

Huawei Technologies Co.,Ltd

liushucheng at