Re: [Tsv-art] Tsvart last call review of draft-ietf-opsawg-vpn-common-06

mohamed.boucadair@orange.com Thu, 01 April 2021 07:14 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB383A0A1C; Thu, 1 Apr 2021 00:14:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.818
X-Spam-Level:
X-Spam-Status: No, score=-2.818 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 FEauiRjzTZCe; Thu, 1 Apr 2021 00:14:35 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8EC53A0A0B; Thu, 1 Apr 2021 00:14:34 -0700 (PDT)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar21.francetelecom.fr (ESMTP service) with ESMTPS id 4F9vZJ2MR7z7vMF; Thu, 1 Apr 2021 09:14:32 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1617261272; bh=EvkXxZRTuuGzdT+c1G3QsZGktxKYF99p80VzP7PO7Kk=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=n+h5MxrmVcMi8IC3Lf3sFKf7zwwm4HaE0tI4BJdqJivxcuw2Y4oiToaAZBTwJ2RGi +bIOw28wWkLH/IDFnLSe11wRuJl53SM8xlExVmEn/L8PPn8sOOQ+uDCrHglEoBeNyY DNjiwcvH5vYkgYeg3ErinFE451RQdOFqH9bH5oWWA1O8ZQ25ysy9QBSs/fMawBTddA Zm/0vxn8NZ6O3P/UMXbYA3xOHwYTRIODuimRbXKW0wIo5uj/Q+KCIPexCK0bfz2jCH 24ujhNZIqg7qkBJl+BT2nWJetCrd1lMPzmkYW/nWNbWwybqVIs7qYU2k4W42PN6CNh u9EXQQQ0yJu3Q==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 4F9vZJ0PCTzCqkT; Thu, 1 Apr 2021 09:14:32 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: Wesley Eddy <wes@mti-systems.com>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "draft-ietf-opsawg-vpn-common.all@ietf.org" <draft-ietf-opsawg-vpn-common.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: Tsvart last call review of draft-ietf-opsawg-vpn-common-06
Thread-Index: AQHXJb+I+PxOYhT/J02cRGSG5XqoUaqfK6Bg
Date: Thu, 1 Apr 2021 07:14:31 +0000
Message-ID: <6069_1617261272_606572D8_6069_343_1_787AE7BB302AE849A7480A190F8B93303536132C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <161714825572.5340.7227743193048443349@ietfa.amsl.com>
In-Reply-To: <161714825572.5340.7227743193048443349@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/cZNLlCauIMWYr1gXUW75nNEK_kk>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-opsawg-vpn-common-06
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Thu, 01 Apr 2021 07:14:40 -0000

Hi Wes,

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Wesley Eddy via Datatracker [mailto:noreply@ietf.org]
> Envoyé : mercredi 31 mars 2021 01:51
> À : tsv-art@ietf.org
> Cc : draft-ietf-opsawg-vpn-common.all@ietf.org; last-call@ietf.org;
> opsawg@ietf.org
> Objet : Tsvart last call review of draft-ietf-opsawg-vpn-common-06
> 
> 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.
> 
> (1) I noticed in the "qos-classification-policy" there is "l4"
> support either TCP or UDP.  It isn't clear if other transport
> protocols are purposefully not included.

[Med] We wanted to focus in this version of the spec on transport protocols that are widely supported in the context of VPN services. The module can be extended in the future with l4-specific features, if needed. We will clarify that scope in the document.

  Should this also support
> SCTP and/or DCCP, or other transport protocol numbers in general?

[Med] Any transport protocol (including DCCP, SCTP) can be included in:

          |  |  |  |     +-- protocol?                         uint8

Additional transport-specific parameters can be included as part of the l4, but only tcp and udp branches are listed in this version. 

Future augmentation of the module can for example specify DCCP or SCTP if there is such need. See for example what we did in https://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-22#section-7 vs. RFC8512. 

> Are the QUIC aspects that might be matched contained within the UDP
> fields supported?

[Med] There is at least UDP ports that can be used for a specific QUIC application binding (HTTP). Relying on some of the information that is visible in the public header (connection-id, for example) may not be reliable.

> 
> (2) Is the allowable MTU another aspect of VPN services that should
> be able to be expressed?

[Med] Good point. This is actually covered in modules that use the vpn-common, see for example: draft-ietf-opsawg-l3sm-l3nm:

             +--rw vpn-network-accesses
                +--rw vpn-network-access* [id]
                   ...
                   +--rw service
                      +--rw input-bandwidth     uint64
                      +--rw output-bandwidth    uint64
                      +--rw mtu                 uint16

> 
> (3) ICMP isn't mentioned as an identity type, and I wondered if this
> should be.

[Med] We don't define it here as it was not used in modules that uses this one (e.g., draft-ietf-opsawg-l3sm-l3nm). Thanks. 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.