Re: [OPSAWG] [IETF-OPSAWG-WG/lxnm] inbound/outbound terminology (Issue #353)

mohamed.boucadair@orange.com Thu, 28 October 2021 12:38 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AE93A0CED for <opsawg@ietfa.amsl.com>; Thu, 28 Oct 2021 05:38:37 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 434ADk2rt51Y for <opsawg@ietfa.amsl.com>; Thu, 28 Oct 2021 05:38:31 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (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 0A00B3A0DFE for <opsawg@ietf.org>; Thu, 28 Oct 2021 05:38:31 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) (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 opfedar23.francetelecom.fr (ESMTP service) with ESMTPS id 4Hg4q91lGYzBt6Y; Thu, 28 Oct 2021 14:38:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1635424709; bh=q4reQZd3OrmvnwMKnRgJIHnAeqbxCoLqP0MwJbSSZM4=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=w3MzPzV2uEUvthK2u39hMFi/ZkBgEVtuaH98GcFE4NFo3rr2UisBhc2D83QSrPCXT oW0apOUsPTwwTP7hkjlvYvoXebbG4QQhBNZLF9sg+OA4YkhmEqlBCxiZQ5n6fFxKTz 4warIIEauG/D9wnJSKZhjbhioUH+KiZDDyxyzJ7Ge7aPizQlwWOMpVi6gMZ3W1gW2k goWMqZ2EkeJtDRQJIAUuPopWCSFVezxAdxkGKV3SvVZhHvOjfG7/MyHPxMu+E7Smt7 jvhdh4eKJWLtH3quVp1KVz5wOjmfVpOjseomirF/GMoFWPJHYs0sUEGXRK6unLqkbA NJ+LCfflAmWgg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar01.francetelecom.fr (ESMTP service) with ESMTPS id 4Hg4q90cpNzBrM6; Thu, 28 Oct 2021 14:38:29 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: Julian Lucek <jlucek@juniper.net>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: [IETF-OPSAWG-WG/lxnm] inbound/outbound terminology (Issue #353)
Thread-Index: AQHXyk6eDjDx/FKXyki4H9XbUBoAfavm3WcAgAEPL5A=
Content-Class:
Date: Thu, 28 Oct 2021 12:38:27 +0000
Message-ID: <18574_1635424709_617A99C5_18574_414_1_787AE7BB302AE849A7480A190F8B933035436F0E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <IETF-OPSAWG-WG/lxnm/issues/353@github.com> <IETF-OPSAWG-WG/lxnm/issues/353/953059202@github.com>
In-Reply-To: <IETF-OPSAWG-WG/lxnm/issues/353/953059202@github.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2021-10-28T05:57:27Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=9eeacee8-149b-4fe4-9cfc-7a58e55aa092; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.114.13.245]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933035436F0EOPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/xq4o7KezD41pVaIiZ_SwCgrVqGY>
Subject: Re: [OPSAWG] [IETF-OPSAWG-WG/lxnm] inbound/outbound terminology (Issue #353)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Oct 2021 12:38:37 -0000

Hi Julian,

Moving the discussion to the list to have more eyes from the WG on this particular point:

“But I would urge you to change the terminology to "PE-to-CE-bandwidth" /"CE-to-PE-bandwidth" to make it super-explicit, the current terminology has been causing endless confusion to implementers (I realise it's inherited from the service models, but changing the terminology in LXNM would cure the problem well)”
All, Julian raised early this week a comment about an L2NM terminology we are inheriting from the service model. The full context of this discussion can be seen at: https://github.com/IETF-OPSAWG-WG/lxnm/issues/353.

Cheers,
Med

De : julianL999 <notifications@github.com>
Envoyé : mercredi 27 octobre 2021 17:46
À : IETF-OPSAWG-WG/lxnm <lxnm@noreply.github.com>
Cc : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; Comment <comment@noreply.github.com>
Objet : Re: [IETF-OPSAWG-WG/lxnm] inbound/outbound terminology (Issue #353)


Hi Med

In https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l2nm-09 it says as follows, maybe it is a typo?

container svc-outbound-bandwidth {
if-feature "vpn-common:outbound-bw";
description
"From the PE perspective, the service outbound
bandwidth of the connection.";

But I would urge you to change the terminology to "PE-to-CE-bandwidth" /"CE-to-PE-bandwidth" to make it super-explicit, the current terminology has been causing endless confusion to implementers (I realise it's inherited from the service models, but changing the terminology in LXNM would cure the problem well)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://github.com/IETF-OPSAWG-WG/lxnm/issues/353#issuecomment-953059202>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADXR6VZSFIYRMPT32WGNE3DUJAUFNANCNFSM5GXLDWMQ>.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

_________________________________________________________________________________________________________________________

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.