[OPSAWG] draft-ietf-opsawg-sap: Attachement Circuits définition

mohamed.boucadair@orange.com Thu, 16 February 2023 12:59 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 B2ED3C169510 for <opsawg@ietfa.amsl.com>; Thu, 16 Feb 2023 04:59:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Level:
X-Spam-Status: No, score=-2.795 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3in4eR__8iCM for <opsawg@ietfa.amsl.com>; Thu, 16 Feb 2023 04:59:41 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D79C16B5A0 for <opsawg@ietf.org>; Thu, 16 Feb 2023 04:59:20 -0800 (PST)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) (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 opfednr22.francetelecom.fr (ESMTP service) with ESMTPS id 4PHZlV3KRHz10B6; Thu, 16 Feb 2023 13:59:18 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1676552358; bh=rxIeGsQiq/10Cyu5oK6l4G9u8G/FAzdLerVgLt1K+/8=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=SHIbLSPCCy+uYlNZYpd7NSF3+cUED04gSlR0anCC74niDBC0EwowmXnIBHzk19ieg p5IHV3uKvBkXm9nKpgLODLrdRxVHcWi9Hz/FAhmNrBtXQ4l+NB0iOA8rzcMUeRTZch u+NYCZbNEjg0+2h3inA/XXqlNsex6vsrzBWSics60u1SaHkzQok8m9bIdC/0pMkWzN 77n6fuurznbS3UlmZkdfaadg1Hu+bmhS1xRscKJzuHFQdnqmLpPm+rL0DSSIMjVTyM 7v8HzRuduCJZQF4AgaY0VLdCjtFG4MPhbJB1oIPO3hz8zEaRziT8ySNHmDKXDpu4gL DoyuOSuRvZoAQ==
From: mohamed.boucadair@orange.com
To: "opsawg@ietf.org" <opsawg@ietf.org>, Robert Wilton <rwilton@cisco.com>
CC: "Wubo (lana)" <lana.wubo@huawei.com>, Richard Roberts <rroberts@juniper.net>, Oscar González de Dios <oscar.gonzalezdedios@telefonica.com>, Samier Barguil <samier.barguil_giraldo@nokia.com>, JACQUENET Christian INNOV/NET <christian.jacquenet@orange.com>
Thread-Topic: draft-ietf-opsawg-sap: Attachement Circuits définition
Thread-Index: AdlCANtlhksgAPTQR6S5KFyEd/izUw==
Content-Class:
Date: Thu, 16 Feb 2023 12:59:17 +0000
Message-ID: <24377_1676552358_63EE28A6_24377_107_30_1787ffd1647e400abfa5e5081dd60b40@orange.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=2023-02-16T12:18:46Z; 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=24e99d8d-607c-45fe-a0c0-cbbddbf9e7f2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.115.27.51]
Content-Type: multipart/alternative; boundary="_000_1787ffd1647e400abfa5e5081dd60b40orangecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/_Iiv16zSUnnGuSxywvXlROqh2AI>
Subject: [OPSAWG] draft-ietf-opsawg-sap: Attachement Circuits définition
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
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, 16 Feb 2023 12:59:45 -0000

Hi all,

As part of the ongoing effort to expose attachment circuits as a service, we figured out that there is a need to clearly separate the notions of "attachment circuits" vs. "bearers" and clearly identify the physical setup vs. required properties over that layer to actually be able to exchange data. The current use of these terms in existing RFCs [1] may be perceived as inconsistent. We are currently discussing (AC Definition Pull Request #32 · boucadair/attachment-circuit-model<https://github.com/boucadair/attachment-circuit-model/pull/32/files> and  bearer definition Pull Request #26 · boucadair/attachment-circuit-model (github.com)<https://github.com/boucadair/attachment-circuit-model/pull/26/files>) to define these two concepts.

However, Bo raised a comment about the AC definition in draft-ietf-opsawg-sap: The suggestion distinction between bearer and AC is nullified if we also accept that AC covers the physical link. In order to avoid that confusion, I suggest we make this simple change to draft-ietf-opsawg-sap:

===
OLD:
   Attachment Circuit (AC):  A channel that connects a Customer Edge
      (CE) to a Provider Edge (PE).  The AC may be a physical or logical
      link (Section 6.1 of [RFC4026]).

NEW:

   Attachment Circuit (AC):  A channel that connects a Customer Edge

      (CE) to a Provider Edge (PE).
===

Unless there are objections, I will propose this change during AUTH48 of the SAP draft.

Thank you.

Cheers,
Med

[1]: Excerpts from the existing RFCs.

RFC4026:

   In a Layer 2 VPN the CE is attached to PE via an Attachment Circuit

   (AC).  The AC may be a physical or logical link.

RFC4364 (L3VPN):

   Routers can be attached to each other, or to end systems, in a

   variety of different ways: PPP connections, ATM Virtual Circuits

   (VCs), Frame Relay VCs, ethernet interfaces, Virtual Local Area

   Networks (VLANs) on ethernet interfaces, GRE tunnels, Layer 2

   Tunneling Protocol (L2TP) tunnels, IPsec tunnels, etc.  We will use

   the term "attachment circuit" to refer generally to some such means

   of attaching to a router.  An attachment circuit may be the sort of

   connection that is usually thought of as a "data link", or it may be

   a tunnel of some sort; what matters is that it be possible for two

   devices to be network layer peers over the attachment circuit.

RFC4646 (L2VPN):

   In any type of L2VPN, a CE device attaches to a PE device via some

   sort of circuit or virtual circuit.  We will call this an "Attachment

   Circuit" (AC).  We use this term very generally; an Attachment

   Circuit may be a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port,

   a VLAN, a PPP connection on a physical interface, a PPP session from

   an L2TP tunnel, an MPLS LSP, etc.  The CE device may be a router, a

   switch, a host, or just about anything, which the customer needs

   hooked up to the VPN.  An AC carries a frame between CE and PE, or

   vice versa.

RFC8299 (L3SM):

   A "site" is composed of at least one "site-network-access" and, in

   the case of multihoming, may have multiple site-network-access

   points.  The site-network-access attachment is done through a

   "bearer" with an "ip-connection" on top.  The bearer refers to

   properties of the attachment that are below Layer 3, while the

   connection refers to properties oriented to the Layer 3 protocol.

   The bearer may be allocated dynamically by the SP, and the customer

   may provide some constraints or parameters to drive the placement of

   the access.

RFC8466 (L2SM):

   A site contains at least one network access (i.e., site network

   accesses providing access to the sites, as defined in Section 5.3.2),

   and there may be multiple network accesses in the case of

   multihoming.  Site-to-network-access attachment is done through a

   bearer with a Layer 2 connection on top.  The bearer refers to

   properties of the attachment that are below Layer 2, while the

   connection refers to Layer 2 protocol-oriented properties.

RFC9291 (L2NM):

   Similar to Section 3 of [RFC8466], CE to PE attachment is achieved

   through a bearer with a Layer 2 connection on top.  The bearer refers

   to properties of the attachment that are below Layer 2, while the

   connection refers to Layer 2 protocol-oriented properties.

RFC9182 (L3NM):

   A site, as per [RFC4176], represents a VPN customer's location that

   is connected to the service provider network via a CE-PE link, which

   can access at least one VPN.  The connection from the site to the

   service provider network is the bearer.  Every site is associated

   with a list of bearers.  A bearer is the Layer 2 connection with the

   site.

_________________________________________________________________________________________________________________________

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.