Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt

[Joe Touch <[e-mail]>]

Hi, Fred,

Thanks for the feedback. Let's assume I incorporate the nits/bugs and I
address any clarifications when I get to them in detail, so I'll jump
only to the deeper issues below...

Joe


On 3/28/2017 9:36 AM, Templin, Fred L wrote:
> Here are my comments for this draft. Mostly editorial, but some substantial.
> I also noticed several indications that further work was needed in some
> sections. Will those sections be worked before publication?
As per Mark's presentation, it depends on whether this doc stays
informational (as was adopted) or becomes BCP (as we think it probably
should).

If informational, much of Section 5 will be removed. If not, then that
will be fleshed out.

> 10) Section 4.2.1, bulleted list toward bottom of section, tunnel
>    "atom" is a very strange word to me. Tunnel "cell"?

The concept of an atomic packet was defined in RFC 6864. This is derived
from that. Cell would be introducing a new term, one that is overloaded
with ATM, which we want to avoid.

> 13) Section 4.2.2, final sentence is incorrect. RFC4821-style MTU
>     probing cannot be used by tunnels due to ECMP because the probe
>     packets may take a different path than the data packets. That
>     is why AERO no longer uses RFC4821 probing.

Regarding ECMP issues, I think we need to wrap this issue up. Here's
what I propose:

- point out that ECMP causes problems with PMTUD (and can cause problems
with PLMTUD).
- an interface has two choices:
    - keep track of PMTU based on other packet context (flowID or next
header info)
    - merge PMTU feedback, taking the MIN of reported values

There's no magic here. It's a lot like multicast - either keep track in
a way that you *think* correlates to the different PMTU feedback or take
the MIN.

The current doc does need a scrub to make this point clearly and
consistently.

> 14) Section 4.2.2, should include discussion of how common tunnel
>     specs regard EMTU_R and the tunnel atom (cell) size. Namely,
>     many common specs assume larger EMTU_R and tunnel cell sizes
>     than are guaranteed by RFC1122 and RFC2460. That means that
>     these tunnel specs are relying on operational assurances of
>     larger values than the IPv4 and IPv6 minimums. Since they are
>     already published as standards, this document needs to explain
>     how they are able to operate without fragmentation.
I'll see what I can do to add that point; I'm hoping to not need to cite
dozens of examples, though.

> 17) Section 4.2.3 cites RFC4821, but PLPMTUD cannot be used by
>     tunnels due to ECMP.
I disagree; it can, but the system needs to either take the MIN or have
a way to decouple discovered PMTUs in way that can be trusted to
reasonably correspond to the ECMP splitting.

> 20) Section 4.3.3, fourth paragraph, "A multipoint tunnel MUST
>     have support for broadcast and multicast" - I think this
>     would be better as a "SHOULD". RFC2529 and AERO support
>     multicast, but RFC5214 does not yet it is widely deployed.

Multicast or its equivalent. Otherwise, you can't support IPv6
multicast, which is a required capability of IPv6.
> 23) Section 5.1, first sub-bullet under "Tunnels must obey core IP
>     requirements", Are you meaning to talk about IPv4 DF=1?

Yes, and that should be made more explicit. Also honoring the EMTU_R
limits until told otherwise.

-----