RE: OMNI/OAL

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Fri, 26 March 2021 18:58 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532C13A0843 for <ipv6@ietfa.amsl.com>; Fri, 26 Mar 2021 11:58:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5p2YQIKlqZo for <ipv6@ietfa.amsl.com>; Fri, 26 Mar 2021 11:58:16 -0700 (PDT)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33EC73A083F for <6man@ietf.org>; Fri, 26 Mar 2021 11:58:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 12QIwDNE005562; Fri, 26 Mar 2021 14:58:13 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1616785093; bh=BE86BsTJCe5a4dTULuf8/pG0hoDWOwiMgBGN0C3vNlQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=R9uyxFMGqLHMEmBuOqceoqqVY98O90HOZR48XjgR+wq1pvr6qXXrFW3XPluFRy9ka Rvyb2SfAgG7W9G9TqiKcDhn9MrGe9Pk4B0rEHwAA0uQ02wL6cD45hX4lQfaFTzstyG v3j8QntS3ScI9kWrEUP8Wut71reW6+Bkwk4qGJfLD4tq/Fw9On7FEMhO7NESj1/Tn/ gSmMAfQVHIScslGF8O7jYdVqyd+qQTTdji/mC38q0AexIIpXqWwhA6B5ew0uJMFNV2 PXFIE1jQpoTULTF/GQV9tW8STt6UU2nfB+oThlaCm3VgJWXOfhfPrz1R4mxtYnJZ5X Xo0+CzsKwmFjQ==
Received: from XCH16-07-09.nos.boeing.com (xch16-07-09.nos.boeing.com [144.115.66.111]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 12QIw7KF005511 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 26 Mar 2021 14:58:07 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-09.nos.boeing.com (144.115.66.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2176.2; Fri, 26 Mar 2021 11:58:06 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2176.009; Fri, 26 Mar 2021 11:58:06 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
CC: "6man@ietf.org" <6man@ietf.org>
Subject: RE: OMNI/OAL
Thread-Topic: OMNI/OAL
Thread-Index: AdciZQMhvfUAtruMSaWjvvb9zdRzdAACxGKA
Date: Fri, 26 Mar 2021 18:58:06 +0000
Message-ID: <1cd31169563d4f5794ca985a67d6ee8f@boeing.com>
References: <98166491688341f8aa7508f4ff88cfe9@huawei.com>
In-Reply-To: <98166491688341f8aa7508f4ff88cfe9@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 3856C659795FC0DFBCC71FB7472118F1EC90988549C63F7F8A8B8BF449892AC62000:8
Content-Type: multipart/alternative; boundary="_000_1cd31169563d4f5794ca985a67d6ee8fboeingcom_"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/C13ORAnnAujDs_SwOC7veSKpJPU>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Mar 2021 18:58:21 -0000

Hi Eduard,

Thank you for your message. There are two specs to consider: 1) OMNI gives
the interface and OAL spec, and 2) AERO specifies the neighbor coordination
functions and segment routing details. Together, the specs provide the end
user with the “five M’s”: Mobility, Multilink, Multihop, Multicast and MTU.

In terms of dependencies, it is possible to use the OMNI spec for the interface
model for end systems and access routers while using something else besides
AERO in the core. Conversely, it is not possible to use AERO with any other
interface spec besides OMNI. So, that should give an idea of the dependencies.

Let me know as you come up with any questions or comments. Thanks again
for your consideration.

Fred

---

Hi Fred,
I will look at your drafts.
But even before I have looked – I am sure that it could not be the “general purpose tunneling solution”.
The problem is with the complexity of your scope.
As I understand, It is mandatory to have Mobility for your solution. Mobility should be a much bigger/complex problem compare to anything else in your draft.
There are many other use cases where tunneling does not need mobility (where infrastructure does not move). Then overlay/tunneling should be simpler.
Hence, at least 2 solutions are needed for overlay: with mobility and without.
In the ideal case, it is better if Mobility would be an additional functionality to the basic overlay (separate spec). I did not try to think about it – I am not sure that it is possible. Maybe only 2 separate solutions are possible because basic overlay should not become over-complicated.
Eduard
From: Templin (US), Fred L [mailto:Fred.L.Templin@boeing.com]
Sent: Thursday, March 25, 2021 8:26 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>>; int-area <int-area@ietf.org<mailto:int-area@ietf.org>>
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; 6man@ietf.org<mailto:6man@ietf.org>
Subject: RE: draft-ietf-intarea-tunnels concerns

Eduard, at this point I think you would need to gain a better understanding of the
OMNI/OAL proposal by reading the draft to understand what is being proposed.
You may also need to look at the AERO draft to understand how the AERO/OMNI
segment routing functions. The drafts will not be changing again unless the IETF
directs me to do so:

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

As can be seen in the drafts, only end systems or near-end systems need to fragment
or reassemble, and iperf3 shows that that can be done at the O(10Gbps) level or even
higher which is plenty good enough for leaf networks. The core only needs to forward
OAL carrier packets with sizes determined by the MPS and as such are guaranteed not
to trip over an MTU restriction, and with line rate forwarding enabled.

Please have  a look and let us know what you think.

Fred

---

Fred,
You could not considerably cut traffic by talking about core boxes.
The modern design (DC at any layers) may not have any core router for the country as big as 80M of population. I did careful calculations for many countries.
Because of Direct lambda from aggregation to the limited number of DC or peering points.
But you could say that only the downstream interface should do fragmentation/reassembly. Uplink could be cheaper.
Hence, /2 is a reasonable assumption.
It is still huge.

My personal estimation that FBB would go flat at 3Mbps, MBB at 1Mbps (5+ years) average per subs in the busy hour.
Let average household would be 2.6 persons (I know many countries, but I did never research for the world).
7.8B of MBB subscribers. 3B of FBB. Something like 17Pbps of real traffic.
/2 to see downlink only. But *4 for redundancy and reasonable port utilization.
Who would pay for the different hardware 34Ptbs?

The numbers above could be calculated more carefully. The model could be more accurate.
But No, massive fragmentation would never happen.
Eduard
From: Templin (US), Fred L [mailto:Fred.L.Templin@boeing.com]
Sent: Thursday, March 25, 2021 7:34 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>>; int-area <int-area@ietf.org<mailto:int-area@ietf.org>>
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; 6man@ietf.org<mailto:6man@ietf.org>
Subject: RE: draft-ietf-intarea-tunnels concerns

Eduard, I am meaning to represent this as a general purpose solution. Performance
critical routers in the middle of the network will never be asked to reassemble – only
end systems or leaf network routers near the end systems will fragment, and only
end systems or routers near the end systems will need to reassemble.

You are right that OMNI/OAL are not meaning to invalidate all other tunneling
solutions, however they will improve the integrity of other tunneling solutions.
Remember that tunnels over IPv4 that set DF=0 and do not include an integrity
check are open to corruption. OMNI/OAL when used in the presence of those
other tunnel types closes the integrity gap.

Fred

---

Hi Fred,
As I remember, you do not try to invalidate all other tunneling solutions.
draft-ietf-intarea-tunnels is doing exactly this.

IMHO: If some hardware achievement would not give us reassembly almost for free
Then the general solution should not assume reassembly because it is still very expensive for hardware at tunnel end points.
Overlay/Underlay is very popular our days – we would see more and more tunneling. SRv6 is the best example based on RFC 2473.

But it could be fine for your environment because overall performance would not go many Tbps per 1 gateway.
It is still possible to rely on something like Network Processor.
You would do some tradeoff between cost and flexibility. A little more cost for your environment should not be the problem.
Eduard
From: Templin (US), Fred L [mailto:Fred.L.Templin@boeing.com]
Sent: Thursday, March 25, 2021 6:12 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>>; int-area <int-area@ietf.org<mailto:int-area@ietf.org>>
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; 6man@ietf.org<mailto:6man@ietf.org>
Subject: RE: draft-ietf-intarea-tunnels concerns

Eduard, I did a quick pass through the intarea discussions and I see points raised that
have been repeated many times since Y2K and even since much longer before that.
Thankfully, there is now a solution called the “OMNI Adaptation Layer (OAL)”:

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

Some might say that it is the “second-coming of AAL5”, and it is true there are
many similarities. Like IP over ATM, the OMNI interface has an MTU/MRU visible
to the IP layer and set to 9180 bytes since that is the maximum size that can be
well protected by CRC32. Like AAL5, within the OMNI interface the OAL has a
“cell size” that determines the size of each fragment that will be produced by
the adaptation layer below IP.

Unlike AAL5 where the cell size is fixed at 48 octets, however, the OAL sets
both a minimum cell size (termed “minimum Maximum Payload Size (MPS)”)
and a possibly larger per-path MPS discovered using probes if necessary. The
minimum/path MPS is the maximum-sized RFC2473 fragment that the OAL
can sneak through the path and be assured it won’t be dropped (silently or
otherwise) due to a size restriction. Without any probing, the minimum MPS
that can be assumed is 576 minus encapsulation overhead (i.e., the IPv4
minimum EMTU_R). But unlike AAL5, the OAL can always strive to find a
larger per-path MPS.

There is more to be said about the OAL, but I will leave it at that for now.
We can talk about PTB “hard” and “soft” errors later if there is interest.

Fred