[Tsv-art] Tsvart early review of draft-ietf-idr-bgp-ct-27

Olivier Bonaventure via Datatracker <noreply@ietf.org> Wed, 13 March 2024 08:26 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tsv-art@ietf.org
Delivered-To: tsv-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA6FC1519B7; Wed, 13 Mar 2024 01:26:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Olivier Bonaventure via Datatracker <noreply@ietf.org>
To: tsv-art@ietf.org
Cc: draft-ietf-idr-bgp-ct.all@ietf.org, idr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.8.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171031839656.20965.4998933435663604624@ietfa.amsl.com>
Reply-To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Date: Wed, 13 Mar 2024 01:26:36 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/hml_nr-BAbzXk7RnKCCy-EVXLuw>
Subject: [Tsv-art] Tsvart early review of draft-ietf-idr-bgp-ct-27
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Mar 2024 08:26:36 -0000

Reviewer: Olivier Bonaventure
Review result: On the Right Track

I reviewed this document for tsvart with a focus on issues related to the
transport area. The document defines BGP extensions to enable service providers
to deploy inter domain services based on different types of tunnels with MPLS
used as an example. The objective of the document is to provide different types
of services using these tunnels.

>From the viewpoint of the transport area, there are two important points that
need to be discussed when considering such tunnels: - MTU problems if the
tunnel configurations differ - DSCP issues if DSPC is used to provide non-best
effort services

These two issues are not discussed in the document. This could be a design
choice, but then I would suggest to explicitly document it. For the MTU
problem, it could be useful to mention that operators should coordinate the MTU
of the tunnels used to prevent PATHMTU discovery problems that could appear in
deployments.

For the DSCP issue, it is unclear from the document whether DSCP will be used.
The document specifies that different operators could use different BGP
codepoints and that these codepoints could be mapped from one operator to
another, but there is not discussion about the same problem for DSCP in the
data plane. RFC5462 defines E-LSPs and L-LSPs, but it is unclear from the draft
whether any of these types of LSPs are used. This should be discussed in the
paper as this will have an impact for some deployments.