Re: [Teas] A question on the definitions of SDP and SAP
Adrian Farrel <adrian@olddog.co.uk> Tue, 22 March 2022 20:49 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 E8FFA3A11DE; Tue, 22 Mar 2022 13:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 AGdnhh9gHH04; Tue, 22 Mar 2022 13:49:08 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDCC73A11A7; Tue, 22 Mar 2022 13:49:03 -0700 (PDT)
Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta5.iomartmail.com (8.14.7/8.14.7) with ESMTP id 22MKn0C7019188; Tue, 22 Mar 2022 20:49:00 GMT
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B446B46052; Tue, 22 Mar 2022 20:48:59 +0000 (GMT)
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4DC5B460A8; Tue, 22 Mar 2022 20:48:19 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs4.iomartmail.com (Postfix) with ESMTPS; Tue, 22 Mar 2022 20:48:19 +0000 (GMT)
Received: from LAPTOPK7AS653V ([85.255.232.179]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.7/8.14.7) with ESMTP id 22MKmG61013766 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Mar 2022 20:48:17 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Henderickx, Wim (Nokia - BE/Antwerp)'" <wim.henderickx@nokia.com>, 'Greg Mirsky' <gregimirsky@gmail.com>, 'Med Boucadair' <mohamed.boucadair@orange.com>
Cc: 'opsawg' <opsawg@ietf.org>, 'TEAS WG' <teas@ietf.org>
References: <CA+RyBmXKneDhX7yELTrhEEL19iL9rATtW_ZSvgceEh6ygP3uYQ@mail.gmail.com> <10787_1647863403_6238666B_10787_254_8_102a93ddc2d248dda598226a48932b5b@orange.com> <CA+RyBmX5DUiMPPDmBM-f6johCd9f9Yraybv1hXPBUdfnW1k_3Q@mail.gmail.com> <27185_1647953014_6239C476_27185_267_1_e1ff0f7649024e2799d5339a3b8cad87@orange.com> <CA+RyBmU7On+Yc2FWuRHLK5gkA4K0pRgHHO171Xr4HJnOXs0heg@mail.gmail.com> <AM0PR07MB44975AABAB8DFDE7C1A4944B83179@AM0PR07MB4497.eurprd07.prod.outlook.com>
In-Reply-To: <AM0PR07MB44975AABAB8DFDE7C1A4944B83179@AM0PR07MB4497.eurprd07.prod.outlook.com>
Date: Tue, 22 Mar 2022 20:48:16 -0000
Organization: Old Dog Consulting
Message-ID: <076d01d83e2e$28cf4680$7a6dd380$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_076E_01D83E2E.28D56100"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQKNvFqu5zHlIyUWZF+EfMKH8dNougLQCEkxAP7MhHADBJ7M8wM1XlK2AY170xurBC6JgA==
X-Originating-IP: 85.255.232.179
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-8.6.0.1018-26788.003
X-TM-AS-Result: No--41.716-10.0-31-10
X-imss-scan-details: No--41.716-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-8.6.1018-26788.003
X-TMASE-Result: 10--41.716500-10.000000
X-TMASE-MatchedRID: vJMTL+QvMTfuYusHgJkgymjJpufOqOIAhg/Tt7otYdjUGvnBZfthDUL4 Gvf0ETK1kRd+Ol+M6+zsrfmvTLX/nqEUhcR6XTllThn37FFP5A2d41voTK+t/OHTrDSrqn2sXSU THwU7DvjxTTcuPGYLElL+KwgRcYO/F+qQpCWTUjk2LwvzxRX0gBUHiwnRYYCaSUy34bcFHJsKoi VTDA+B7PP3uahlKArx7Ef9eUvyqg4BGmsibWGTbToSfZud5+GgfL8fHUCAmutDqDYelNe6m+89K 3XPGe2rmtZidqL7KSfx1mYZBZwMLkAvdL4TzpZNrthpnZXZolDuUsaVMCjJLVUusegvV0lI0Azk L0EkK+dYKJTez2dVw8Mj4/rpvity/cdhqO7KmN/B0/7xhd4BycK+joM7FGIarzDWgA8A6o67e+L 1LmVkzbkhSsI6HQ6YYkckb91vQ/6dVNZaI2n6/5naxzJFBx6vz5ZiODdbPIpVcXP3eMLfFxM3st fQ7DPMFmWqlR96txBxfIDwLEi3oRRi7uo8yw3gSwrH9PjbP+xQaeT8v2nXiAkt9MvPhDUYg9Vun vWXLaTPTCeLFrwRK87lGSrK26cDqi7APU2cO5q4xL6LFePa56RWBmIlbOTgwdmEWGIDvPx16JC+ U8oiC4m6jS5qCaYaQgnYkPpNmtdlpnrSNHj3mMLxCdsZaEALniWZGbPZkxYidWE+jNsv6c5Vez6 FHId/HBunSHImBEIFNKJusObD8/rNPkGWAHDflwT0XposETV0Tsch72XSbJ/vLk4ECKhoNtrqBJ tuOX6I40w6RysGJoc7+Qb8+03p/HTKStsDGMIh+cXdVp/Twpsoi2XrUn/JlR1cT9YafQW4mGhlp KkDnu03P1hii2skuaN8gZEMR2aw7M6dyuYKg4VH0dq7wY7up8Odl1VwpCSUTGVAhB5EbQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/RzBvbzHHFJVZn9pAJXFjj2tLd6o>
Subject: Re: [Teas] A question on the definitions of SDP and SAP
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2022 20:49:20 -0000
Hi Wim, Youre welcome to shime whenever you want. I think it is important, in this discussion, to reflect that the service is not the realisation. For the main part, this document describes the service and, while it must allow for multiple realisations, it does not attempt detailed descriptions. Cheers, Adrian From: Teas <teas-bounces@ietf.org> On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp) Sent: 22 March 2022 14:09 To: Greg Mirsky <gregimirsky@gmail.com>; Med Boucadair <mohamed.boucadair@orange.com> Cc: Adrian Farrel <adrian@olddog.co.uk>; opsawg <opsawg@ietf.org>; TEAS WG <teas@ietf.org> Subject: Re: [Teas] A question on the definitions of SDP and SAP Sorry the shime in late in this thread but there is one thing still bothering or I wanted to highlight. Maybe we can do another thread if needed. Here is the thing I am struggling with in the current draft, which is what I call multiplexing or what I sometime call mapping. My understanding so far is we have SDP and connectivity construct to represent a slice In reality I believe or in my view: we have SDP a forwarder of some sort (it is dependent on the connectivity matrix) a connectivity matrix On top we have some multiplexing and mapping into these constructs. So in my view you can implement the slices in various ways. I am using 3GPP as the endpoints radio in this case And my examples are not exhaustive but I am using to show what I mean with multiplexing/mapping e.g. * Slice1 -> Radio vlan 1 sdp 1 fwd ctx 1 connectivity matrix 1 * Slice2 -> radio vlan 2 sdp 1 fwd ctx 2 connectivity matrix 2 Or * Slice1 -> Radio vlan 1 sdp 1 fwd ctx 1 connectivity matrix 1 * Slice2 -> radio vlan 2 sdp 1 fwd ctx 1 connectivity matrix 2 Or * Slice1 -> Radio flow label 1 sdp 1 fwd ctx 1 connectivity matrix 1 * Slice2 -> radio flow label 2 sdp 1 fwd ctx 2 connectivity matrix 2 Or * Slice1 -> Radio flow label 1 sdp 1 fwd ctx 1 connectivity matrix 1 * Slice2 -> radio flow label 2 sdp 1 fwd ctx 1 connectivity matrix 2 Also would be good to see if this is covered how this maps in the current framework. From: Teas <teas-bounces@ietf.org <mailto:teas-bounces@ietf.org> > on behalf of Greg Mirsky <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com> > Date: Tuesday, 22 March 2022 at 14:50 To: Med Boucadair <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> > Cc: Adrian Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> >, opsawg <opsawg@ietf.org <mailto:opsawg@ietf.org> >, TEAS WG <teas@ietf.org <mailto:teas@ietf.org> > Subject: Re: [Teas] A question on the definitions of SDP and SAP Hi Med, thank you for the additional information. In my understanding, please correct me if it is off, L3 and L2 VPNs are technologies that can be used to realize an IETF Network Slice. If that is the case, then the SAP in, for example, an L3 VPN is also SDP of the IETF Network Slice. Am I missing something? Kind regards, Greg On Tue, Mar 22, 2022 at 5:43 AM < <mailto:mohamed.boucadair@orange.com> mohamed.boucadair@orange.com> wrote: Hi Greg, Other examples can be an L3 VPN network access (RFC9182) or L2 VPN network access (draft-ietf-opsawg-l2nm). FWIW, the SAP spec include these notes: (1) For example, this concept is used to decide where to attach and, thus, deliver the service in the Layer 3 VPN Service Model (L3SM) [RFC8299] and the Layer 2 VPN Service Model (L2SM) [RFC8466]. It can also be used to retrieve where services, such as the Layer 3 VPN Network Model (L3NM) [RFC9182], and the Layer 2 VPN Network Model (L2NM) [I-D.ietf-opsawg-l2nm], are delivered to customers. (2) For example, 'sap-id' may be the VPN network access identifier in Section 7.6 of [RFC9182]. An example to illustrate the use of this attribute during service creation is provided in Appendix D. Cheers, Med De : Greg Mirsky < <mailto:gregimirsky@gmail.com> gregimirsky@gmail.com> Envoyé : mardi 22 mars 2022 10:34 À : BOUCADAIR Mohamed INNOV/NET < <mailto:mohamed.boucadair@orange.com> mohamed.boucadair@orange.com> Cc : Adrian Farrel < <mailto:adrian@olddog.co.uk> adrian@olddog.co.uk>; TEAS WG < <mailto:teas@ietf.org> teas@ietf.org>; opsawg < <mailto:opsawg@ietf.org> opsawg@ietf.org> Objet : Re: A question on the definitions of SDP and SAP Hi Med, thank you for pointing this out to me. I have a follow-up question. If I understand that note correctly, SDP is positioned as an example, a realization of SAP in IETF Network Slice. What could be other examples or realizations of SAP? Regards, Greg On Mon, Mar 21, 2022 at 4:50 AM < <mailto:mohamed.boucadair@orange.com> mohamed.boucadair@orange.com> wrote: Hi Greg, The slice draft already says the following: An SDP may be abstracted as a Service Attachment Point (SAP) [I-D.ietf-opsawg-sap] for the purpose generalizing the concept across multiple service types and representing it in management and configuration systems. Cheers, Med De : Greg Mirsky < <mailto:gregimirsky@gmail.com> gregimirsky@gmail.com> Envoyé : lundi 21 mars 2022 12:17 À : Adrian Farrel < <mailto:adrian@olddog.co.uk> adrian@olddog.co.uk>; TEAS WG < <mailto:teas@ietf.org> teas@ietf.org>; opsawg < <mailto:opsawg@ietf.org> opsawg@ietf.org>; BOUCADAIR Mohamed INNOV/NET < <mailto:mohamed.boucadair@orange.com> mohamed.boucadair@orange.com> Objet : A question on the definitions of SDP and SAP Hi Adrian, I've read the <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/> draft-ietf-teas-ietf-network-slices (many thanks for all your work on it!) and I've got a question. It appears to me that the definition of a Service Demarcation Point section 2.1) as the point of where the IETF Network Slice service is delivered by the provider to a customer is similar to the definition of a Service Attachment Point in <https://datatracker.ietf.org/doc/draft-ietf-opsawg-sap/> draft-ietf-opsawg-sap as an "abstraction of the network reference points where network services can be delivered to customers." Hence my question. Is there an intended difference between SDP and SAP that is indicated by using different terms? Regards, Greg ____________________________________________________________________________ _____________________________________________ 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. ____________________________________________________________________________ _____________________________________________ 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.
- [Teas] A question on the definitions of SDP and S… Greg Mirsky
- Re: [Teas] A question on the definitions of SDP a… mohamed.boucadair
- Re: [Teas] A question on the definitions of SDP a… Adrian Farrel
- Re: [Teas] A question on the definitions of SDP a… Greg Mirsky
- Re: [Teas] A question on the definitions of SDP a… mohamed.boucadair
- Re: [Teas] [OPSAWG] A question on the definitions… Gyan Mishra
- Re: [Teas] A question on the definitions of SDP a… Greg Mirsky
- Re: [Teas] A question on the definitions of SDP a… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [Teas] A question on the definitions of SDP a… mohamed.boucadair
- Re: [Teas] A question on the definitions of SDP a… Adrian Farrel
- Re: [Teas] A question on the definitions of SDP a… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [Teas] [**EXTERNAL**] Re: A question on the d… Rokui, Reza