Re: [Int-area] [v6ops] draft-ietf-intarea-tunnels concerns

Joe, the AERO/OMNI drafts I cited both state up front:

  “The OMNI interface observes the link nature of tunnels, including the Maximum Transmission Unit (MTU),
  Maximum Reassembly Unit (MRU) and the role of fragmentation and reassembly [I-D.ietf-intarea-tunnels].”

https://datatracker.ietf.org/doc/draft-templin-6man-aero/
https://datatracker.ietf.org/doc/draft-templin-6man-omni/

So, the spirit of the proposals intend to honor intarea-tunnels. AERO/OMNI go on to employ RFC2473,
and end up looking a lot like AAL5 only adapted to networks with heterogeneous cell sizes instead of the
fixed ATM cell which I guess is only 48 usable bytes. By giving the OAL source a fixed known *minimum*
cell size but allowing it to discover larger *per-path* cell size values, the service is both robust and efficient.

So, the AERO/OMNI specs are parked unless and until I receive direction from the IETF. If some details
were missed I apologize and those can be cleaned up based on review input. If the whole thing is somehow
flawed, I would be very surprised.

So, I am in the same boat as you in terms of wondering what the next step is in terms of progressing
the documents?

Fred

Hi, Eduard,

I’ve repeatedly addressed these, so in the same spirit of “putting it all in one place”, here are the answers.

Joe

On Mar 25, 2021, at 3:52 AM, Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> wrote:

Hi Experts,
I have not received answers (after a long message thread) for me to understand:

1.       It is assumed by the draft that Data Plane in the transit router operates right now exactly like a host. Then Generalization is attempted for IP stack operation like on a host.
It is not the case. Moreover, it is not possible in principle because the hardware is ASIC managing traffic flow, but the host is CPU “running to completion” for control flow. The architecture of hardware is completely different.

Tunnel endpoints act like hosts. ASIC hardware can and does support fragmentation and reassembly at high speeds, and has *for decades* (all ATM hardware did this).

2.       It is additional complexity: 2 MTUs for one virtual interface instead of the current 1 in all real data planes. 1st MTU is the buffer size - called “Tunnel MTU”. 2nd MTU is the old tunnel MTU- called “MAP”.

They exist, whether you consider them complex or not. Sometimes they’re the same value (i.e., when no fragmentation is supported over the tunnel) and sometimes they’re fixed and known a-priori, but none of that changes that.

It looks extremely bad after the decision that 1st MTU (buffer size) is static till some miracle would explain to us how it would become dynamic in the future.

Nobody has claimed that the tunnel pathMTU (MAP in draft-tunnels) or EMTU_R (true tunnel MTU) cannot change.

3.       The draft has deprecated PMTUD and introduced fragmentation instead of it.

Draft-tunnels is intended as BCP. It has no power to deprecate.

Draft-tunnels does not imply that PMTUD should be used less frequently; it merely repeats the observation known for over 20 yrs that ICMPs are largely blocked and reliance on PMTUD is only asking to experience black-holes.

To be precise: for all bulk traffic that would happen between MTUs.
Moreover, It is not explained what to do for tunneling that does not want fragmentation now (currently prefer PMTUD). Should all tunnels support fragmentation from now on? (L2TPv3, VxLAN, MPLS, RFC 2473)

Any tunnel that is used directly recursively (X over X, i.e., L2TPv2 over L2TPv3, etc.) must have an EMTU_R larger than its pathMTU. If it does not, it cannot support that use.

Those are factual observations, not requirements to specifications claims.

4.       If PMTUD is deprecated, then why it is still used for the 2nd interface MTU? If it is dead, then it is dead, right? Anyone could have the conclusion that the 2nd MTU is static too.

PLPMTUD does not use ICMPs but still relies on these two MTUs.

5.       The draft does break all tunneling specifications. Is everything should be changed in production? It is the cost. For what reason?

Draft-tunnels breaks nothing; it observes that some tunneling specifications *are already inherently broken*.

Seeing a broken window and reporting it does not mean that you broke that window.

It does affect IPv6 too – I had stumbled upon this problem from that direction. RFC 2473 is the best tunneling spec that would be damaged severely.

RFC2473 has errors - as noted in Sec 5.2 of v10 of draft-tunnels.

I welcome discussion on those errors as well as how draft-tunnels should proceed. It is intended for BCP, which cannot update other docs - but it does not itself specify anything. But it could (should?) update all the standards noted in Sec 5.2.

Can anyone suggest how best to do that?

Hence, 6man and v6ops on the copy.

I decided to leave it here for the people that may search for it in the future.

Same here.

Eduard
_______________________________________________
v6ops mailing list
v6ops@ietf.org<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops