Skip to main content

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

Request Review of draft-ietf-forces-interfelfb
Requested revision 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 M. Joachimpillai , Jamal Hadi Salim
I-D 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 (Shucheng) LIU (diff)
Rtgdir Early review of -01 by Joel M. Halpern (diff)
Rtgdir Early review of -01 by Susan Hares (diff)
Assignment Reviewer Will (Shucheng) LIU
State Completed
Request Last Call review on draft-ietf-forces-interfelfb by Ops Directorate Assigned
Reviewed revision 02 (document currently at 06)
Result Has nits
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