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