[Teas] Re: Opsdir last call review of draft-ietf-teas-applicability-actn-slicing-07
Adrian Farrel <adrian@olddog.co.uk> Tue, 13 August 2024 22:23 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91903C14F73E; Tue, 13 Aug 2024 15:23:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.806
X-Spam-Level:
X-Spam-Status: No, score=-2.806 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=olddog.co.uk
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 FL3gMadk4A-t; Tue, 13 Aug 2024 15:23:49 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9896C151063; Tue, 13 Aug 2024 15:23:46 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.7/8.14.7) with ESMTP id 47DMNfUY006584; Tue, 13 Aug 2024 23:23:41 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7F5584604B; Tue, 13 Aug 2024 23:23:41 +0100 (BST)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 72D954604A; Tue, 13 Aug 2024 23:23:41 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS; Tue, 13 Aug 2024 23:23:41 +0100 (BST)
Received: from LAPTOPK7AS653V (14.62.90.146.dyn.plus.net [146.90.62.14]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.7/8.14.7) with ESMTP id 47DMNexL004049 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Aug 2024 23:23:40 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Joe Clarke' <jclarke@cisco.com>, ops-dir@ietf.org
References: <172355676902.854616.9874061624740834216@dt-datatracker-6df4c9dcf5-t2x2k>
In-Reply-To: <172355676902.854616.9874061624740834216@dt-datatracker-6df4c9dcf5-t2x2k>
Date: Tue, 13 Aug 2024 23:23:40 +0100
Organization: Old Dog Consulting
Message-ID: <008a01daedcf$739cccc0$5ad66640$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFoyfmQeulpinfIW+oEbUiQOqutAbMKAuMQ
Content-Language: en-gb
X-Originating-IP: 146.90.62.14
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding; s= 20221128; bh=TjKVdVLrRCm8wOs/ZDly9WBxMiE27f8n/nnlIrCZxYM=; b=id1 qKC5GepRwcFVbNDvWps36Xj9v3dJtUJILVZhV1mPI90bBwG5kDxZzSs6hw1eOwWt miMJ7dsoHopNWbqJ1LZfgwcRBkJIO0AniHtSXNYpxLVeWwE46khrVTlAtSBbPRtu DFSwu9k6vfk9NtLwNmY3k92b7JFFB6SFPoCQmw1OtO3dwaaRXwdcq7/r1os+Bqt+ HIdIMPb6koLuEI+f1ibeZr86CAGXI17OlgFfKNTihwSg3wSI0dFzuwhK17MUaYfO hqb4wd9HGWeSmnOwF4pEyW6S4E1gJZ0Cd5Xcch4VUfAmGxIEHdFSa64ZamaxIJTG w6fn4jo+dL6b3OWK/Vg==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-28352.003
X-TM-AS-Result: No--3.107-10.0-31-10
X-imss-scan-details: No--3.107-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28352.003
X-TMASE-Result: 10--3.107400-10.000000
X-TMASE-MatchedRID: L8tZF6zWW2rxIbpQ8BhdbI61Z+HJnvsOC/ExpXrHizwWn6/ikoy0wv+Y Kp2Mb6xJh7w8b9AwvtVJK0sOkwpp0qNu8YiLlIJQHWRJEfGP5nlBHuVYxc8DWyIqpZjtBYB7rtH 7vXQMnkMEFVW4kSfTg5W3mL+rnGfaBgS8h0wy9EPrCzoWXDcUYkxUJyPnqTyGyIKHzIGoT60bgh xWG5I0ZeCvRZnq77Kla3SQL1+CYqyqqDZNJlQWvQrcxrzwsv5uBPY4SegK3jxwWqz418L/l6PFj JEFr+ol4e8/DBwuXGd0HSe131POnjsAVzN+Ov/sXPNY4qHopWzalQ3xAzqousTtoeXOAlIDcVFC DGP/LwzoQ0sLRlYaxw==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Message-ID-Hash: EBTGCXLJZUG2NSHETSWO7ROFIDLZYAKE
X-Message-ID-Hash: EBTGCXLJZUG2NSHETSWO7ROFIDLZYAKE
X-MailFrom: adrian@olddog.co.uk
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-teas.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-teas-applicability-actn-slicing.all@ietf.org, last-call@ietf.org, teas@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Reply-To: adrian@olddog.co.uk
Subject: [Teas] Re: Opsdir last call review of draft-ietf-teas-applicability-actn-slicing-07
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/2t_Ia5XuckFVTWZBanm-rMqv1Zo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Owner: <mailto:teas-owner@ietf.org>
List-Post: <mailto:teas@ietf.org>
List-Subscribe: <mailto:teas-join@ietf.org>
List-Unsubscribe: <mailto:teas-leave@ietf.org>
Hi Joe, Thanks for taking the time. > I found the document very informative and clear on both the > ACTN and network slicing fronts. Admittedly, there are a lot of moving parts > in TEAS that are referenced by this document, and I'm sure many operational > items when it comes to implementations (the excellent examples in this document > highlight these complexities). > > In terms of this document, I have one question. When I look at how the other > work with augment the service-level YANG modules and specifically figure 6, why > aren't the network models (e.g., L2NM and L3NM) referenced? I'd think they > might be more useful in figure 6 than a direct approach to the physical device > interface. Right, so possibly some confusion. As noted in RFC 9291 and RFC 9182, the L2NM and L3NM models sit at the level of "service delivery models" between the service orchestrator and the network orchestrator. Specifically, it is not a "network configuration interface" In ACTN terms, this matches the XMI shown in Figure 1 of our draft. Better still, on Figures 2 and 3. As noted, the XMI is an "internal" interface of the MDSC so, when we get to Figure 6, the L2NM and L3NM models don't appear. I think, however, we should find a way to mention the L2NM and L3NM models for completeness. Probably, in Section 4: OLD Note 2 - The Service Orchestrator-to-MDSC Interface (XMI) is an interface between two MDSC functional elements encompassing different MDSC service-related functions which is not defined in [RFC8453]. NEW Note 2 - The Service Orchestrator-to-MDSC Interface (XMI) is an interface between two MDSC functional elements encompassing different MDSC service-related functions which is not defined in [RFC8453]. Depending on the function being delivered, the XMI might be realised by the Layer 2 VPN Network Management YANG model [RFC9291] or the Layer 3 VPN Network Management YANG model [RFC9182]. END Would that help? Cheers, Adrian
- [Teas] Opsdir last call review of draft-ietf-teas… Joe Clarke via Datatracker
- [Teas] Re: Opsdir last call review of draft-ietf-… Adrian Farrel
- [Teas] Re: Opsdir last call review of draft-ietf-… Joe Clarke (jclarke)
- [Teas] Re: Opsdir last call review of draft-ietf-… daniel