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

[Jamal Hadi Salim <[e-mail]>]

Hi Joe,
Thanks for your review - responses below:

On Wed, Jun 15, 2016 at 6:40 PM, Joe Touch <[e-mail]> 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

---
>
>
>
>