TSV-ART review of draft-ietf-forces-interfelfb

[Joe Touch <[e-mail]>]

Hi, all,

I've reviewed this draft as part of the TSV Area Review Team, paying
special attention to transport-related concerns. Please take these as
any other IETF last call comments.

Joe

---

The document contains two different types of transport issues: its
relation to supporting transport traffic and the way it exchanges
information between the FEs.

The document's discussion of the impact on supporting transport traffic
is sufficient. I'm not sure I concur with citing RFC5405bis as
informational, because the correctness of the proposed approach to
congestion control relies directly on definitions of controlled
environments available only in the -bis update. I would prefer that
claims using normative language necessitate using cited references as
Normative.

The document uses Ethernet as a "transport", as stated in Sec 3.1.1. The
claim that this is "simpler" than using UDP would benefit from a few
sentences of substantiation, especially because Ethernet does not
support fragmentation, which has an impact on the solutions proposed in
Sec 5.1.1 (see below).

Sec 5.1.3 indicates that packet sizes increase due to the ForCES
metadata (using encapsulation indicated in Sec 5.2), which could exceed
the Ethernet MTU as noted in Sec 5.1.1. Sec 5.1.1 suggests an approach
of falsifying MTU information, but this could also result in a reported
Ethernet MTU below the required minimum of 1500. This case should be
addressed in Sec 5.1.1.

Other comments:

Sec 5.2: The Ethertype listed should be replaced with "Ethertype-TBD"
with a corresponding note to update that text in Sec 9 / IEEE Assignment
Considerations. The draft should not use a specific unassigned value,
even if currently available, until assigned. (it currently cites
0xFEFE).  This section should also refer to the Metadata IDs directly,
either by name or by registry, as if assuming that IANA has created that
registry.

---