[Tsv-art] draft-ietf-rtgwg-multisegment-sdwan-15 telechat Tsvart review
Wesley Eddy via Datatracker <noreply@ietf.org> Mon, 17 August 2026 19:35 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: tsv-art@ietf.org
Delivered-To: tsv-art@mail2.ietf.org
Received: from [10.244.8.14] (gaia.k8s.ietf.org [4.156.85.76]) by mail2.ietf.org (Postfix) with ESMTP id 6C8E812B3D98B; Mon, 17 Aug 2026 12:35:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1786995335; bh=q7T07rulkIF0I45zklWfMmD2mUaF7d2aP2DssLVMT00=; h=From:To:Cc:Subject:Reply-To:Date; b=iTiL1PwHutSITH0tEs/0M8+blrfMW2XdJllcMJ3TQO6+mekt3QNhDJsYyIsi2ipGQ 8drF2ni+dGbFCs5nU99mHhAGFomvaaD9uxr/nixlXXq9Op4IKMqx0rhQGl5conyjnh 3d9SiQzsX63XmmGoATKvN8ZFzajBu3OoE6NfF9xE=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Wesley Eddy via Datatracker <noreply@ietf.org>
To: tsv-art@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.71.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <178699533534.565294.565450095990839011@dt-datatracker-7c6ddbc678-86d5j>
Date: Mon, 17 Aug 2026 12:35:35 -0700
Message-ID-Hash: LVMG6NLU2UHDRFYVJHPO66EZDTX36YTH
X-Message-ID-Hash: LVMG6NLU2UHDRFYVJHPO66EZDTX36YTH
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tsv-art.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-rtgwg-multisegment-sdwan.all@ietf.org, last-call@ietf.org, rtgwg@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Wesley Eddy <wesley.m.eddy@gmail.com>
Subject: [Tsv-art] draft-ietf-rtgwg-multisegment-sdwan-15 telechat Tsvart review
List-Id: Transport Area Review Team <tsv-art.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/g_C7x5KKSjlqpOs4mu7Bhbhoe7g>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Owner: <mailto:tsv-art-owner@ietf.org>
List-Post: <mailto:tsv-art@ietf.org>
List-Subscribe: <mailto:tsv-art-join@ietf.org>
List-Unsubscribe: <mailto:tsv-art-leave@ietf.org>
Document: draft-ietf-rtgwg-multisegment-sdwan Title: Multi-segment SD-WAN via Cloud DCs Reviewer: Wesley Eddy Review result: Almost Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. I don't think this is quite ready for 2 reasons: 1) Since an additional set of headers is required (outer IP + UDP + GENEVE w/ the MultiSeg-SDWAN option), there is an obvious effect on packet size. Other than one recommendation about using a truncated HMAC value to reduce packet overhead, there doesn't seem to be any consideration around how fragmentation will be avoided or how MTUs are configured or information on them propagates within the different SD-WAN segments and tunneling protocols being stacked up. How are people doing this in practice, and are there some general guidelines and advice that should be provided? From a transport protocol perspective, I think this is a big missing aspect to the document. 2) I didn't find the document very readable in the beginning / Introduction section. It improves significantly and is fine deeper into the document, but the introduction is not helpful IMHO. The "Net2Cloud" reference is useful, but unfortunately, I found the introduction section of this particular RTGWG document a bit hard to understand in terms of specific technical problems. It has very specific protocols, architectures, and traffic flows in mind, but doesn't define them well, and expects the reader to just understand. The first paragraph jumps in discussing "SD-WAN" (without qualifying what specific approaches or technologies for SD-WAN are meant, nor even explaining the acronym). I found the diagrams later in Section 3.1 & 3.2 useful, but it would help earlier in the introduction to describe what is being discussed in terms of the cloud gateway, CPEs, etc. and where these are located or what types of connectivity, addressing, encryption, etc. exists between them.
- [Tsv-art] draft-ietf-rtgwg-multisegment-sdwan-15 … Wesley Eddy via Datatracker