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

Hi Greg, Adrian & Med

Great observation Greg.

Myself and Kaliraj have draft below Classful Transport Planes (BGP CT) that
has been discussed with Color Aware Routing (CAR) on IDR that uses the term
SEP which I believe has similarities to SAP and SDP both of which have
adoption call approaching.

SEP in the CT draft is any PE nodes and I believe SDP and SAP as well
terminate on a PE node.

BGP CT
https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes-13

CT is in the same vein of BGP-LU and creates a discrete VPN-like Transport
RIB for inter-as options stitching of discrete desperate underlay
transports next-hop-self with end to end Service overlay LSP
next-hop-unchanged used for example as a discrete Carrier of Carriers RIB
(CSC).

SEP : Service End point, the PNH of a Service route.

PNH : Protocol-Nexthop address carried in a BGP Update message. ( PE loopback)

   The PNH of the overlay route is also referred to as "service
   endpoint" (SEP).  The service endpoint may exist in the same domain
   as the service ingress node or lie in a different domain, adjacent or
   non-adjacent.  In the former case, reachability to the SEP is
   provided by an intra-domain tunneling protocol, and in the latter
   case, reachability to the SEP is via BGP transport families.

SAP

https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sap-02

   This document augments the 'ietf-network' data model by adding the
   concept of Service Attachment Points (SAPs).  The Service Attachment
   Points are the network reference points to which network services,
   such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual
   Private Network (L2VPN), can be attached.  Both User-Network
   Interface (UNI) and Network-to-Network Interface (NNI) are supported
   in the SAP data model.

Many Thanks

Gyan

On Tue, Mar 22, 2022 at 5:35 AM Greg Mirsky <gregimirsky@gmail.com> wrote:

> 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.
>>
>> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*