Hi Joe,
Thanks for your review - responses below:
On Wed, Jun 15, 2016 at 6:40 PM, Joe Touch <touch@xxxxxxx> wrote:
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.
This has come up before. So i think we'll just make it a normative reference
in the next update (which i plan to publish after this discussion)
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).
The reference point is the common deployment use cases; within a single
rack or network owned by one admin who does all the setup.
Any suggestion on wording you'd like to see?
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.
Thanks. Will fix.
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.
Yes, this also came up in earlier review. I will upload with this fixed
as well.
Thanks again Joe for taking the time.
cheers,
jamal
---