Re: [Teas] A question on the definitions of SDP and SAP

Greg Mirsky <gregimirsky@gmail.com> Tue, 22 March 2022 13:50 UTC

Return-Path: <gregimirsky@gmail.com>
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 C93303A1010; Tue, 22 Mar 2022 06:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jCJ-T7oZPFQ8; Tue, 22 Mar 2022 06:50:19 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 5B33F3A0A94; Tue, 22 Mar 2022 06:50:19 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id u3so24110717ljd.0; Tue, 22 Mar 2022 06:50:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b4xH6mpgERkXBJ1UqVzRJuqckCtL3TmXCqshpAExG0Q=; b=IndVTGZ1X1xI15JeRuHL49r/7Zq/AXdzFVzE6/58p7QBG2pztZwtBeBwo+98iRQ0z0 KGIUOoRjyOoWX9s98BRTViljz0jW+Q5e2pHSNvNs4YO68z9zaqdneUB+aVt9AcTjBTgT k1jUyIuP0xfZ1LhtOILor0cNaEUnHQV5cRq4l3A93wDFNZ5KR0MCpCI1zM9hRn3yr94H TFYvCptfUNrni1H/VIjtHrYpTkYi/of7VTFT0iU80cv9xShSZGzaS6lZyD212P583JOm e0R9EyJuoqCmlvdX/kZL5noMv1sE3HrgDQz2XTVrcyu1ZDDD21tkZi32eq/QYHedaF/0 kkZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b4xH6mpgERkXBJ1UqVzRJuqckCtL3TmXCqshpAExG0Q=; b=LHfDTEOrJWVLrqxImbKMCV8UevXEizugRhGuaRC7PWk8gwxudLmG5RmvmOdtVkcZ9z 54neg/9lX7HYN0MfykRbshDf4JwCma4UbFo+IsJE6tJNMDvcIxVlvlofOr1+JzM1ommS vPk92jopa1DJXzASJyj2WhLjrWcIecpNrNxvRiPnNqwueWFiz3B1xgAqG9tBKkrxmDi0 4aTtdmSvhph1cjkfYsO+0W//WNi5ZG47YTxIXHS//2FS40oUlKaL3ixlkSlQyaLIgtFY fb2hliy4lurUm6P5HhruiPpcvuCC5Qmgc3fppqVbCCtjWmnQPovlVAOKf2ryv6WKklSE 4TWQ==
X-Gm-Message-State: AOAM532GXH8ww7YZM+zVZDkokG1sl+nJpAkx95O5MUFvvS8Rk0a8GD+x VHB1XeGq2RanPTcSXTDAU2lZtNLxI4xumVg4IWA=
X-Google-Smtp-Source: ABdhPJzD57kiC0wQ6ilGPKabIEHFBTc6WwJZ1evFGCH66LAnkBFPy/YsdcMe+nwdIR+wwpqRpuoeUxhO0hOt+9ryQO8=
X-Received: by 2002:a05:651c:1501:b0:249:8d28:5659 with SMTP id e1-20020a05651c150100b002498d285659mr3932822ljf.138.1647957016817; Tue, 22 Mar 2022 06:50:16 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <27185_1647953014_6239C476_27185_267_1_e1ff0f7649024e2799d5339a3b8cad87@orange.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 22 Mar 2022 06:50:04 -0700
Message-ID: <CA+RyBmU7On+Yc2FWuRHLK5gkA4K0pRgHHO171Xr4HJnOXs0heg@mail.gmail.com>
To: Med Boucadair <mohamed.boucadair@orange.com>
Cc: Adrian Farrel <adrian@olddog.co.uk>, TEAS WG <teas@ietf.org>, opsawg <opsawg@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000097b39605dacee478"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Z1U9303T72IinE0JVGozN5lEw0s>
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 13:50:25 -0000

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 <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 <gregimirsky@gmail.com>
> *Envoyé :* mardi 22 mars 2022 10:34
> *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
> *Cc :* Adrian Farrel <adrian@olddog.co.uk>; TEAS WG <teas@ietf.org>;
> opsawg <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 <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 <gregimirsky@gmail.com>
> *Envoyé :* lundi 21 mars 2022 12:17
> *À :* Adrian Farrel <adrian@olddog.co.uk>; TEAS WG <teas@ietf.org>;
> opsawg <opsawg@ietf.org>; BOUCADAIR Mohamed INNOV/NET <
> mohamed.boucadair@orange.com>
> *Objet :* A question on the definitions of SDP and SAP
>
>
>
> Hi Adrian,
>
> I've read the draft-ietf-teas-ietf-network-slices
> <https://datatracker.ietf.org/doc/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
> draft-ietf-opsawg-sap
> <https://datatracker.ietf.org/doc/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.
>
>