Subject: [Teas] Slicing Framework Open issue #2 : SDPs, SAPs, and SEPs

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 25 Mar 2022 09:34:41 -0000

Hi,

Second issue.

The document uses the term Service Demarcation Point (SDP). This was
introduced to get us round the many problems with "end point", "slice end
point", CE, PE, etc.

Part of the problem was caused by the variations in different deployment
models that meant that the service could be delivered at different places
(see Figure 1 in the draft). 

While SDP did the job in the context of this document, it was noted that
draft-ietf-opsawg-sap defines the more generic term "Service Attachment
Point (SAP)" as "abstraction of the network reference points where network
services can be delivered to customers." 

To handle this, our draft currently says (Section 2.1)...

      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.

I believe that this is enough of a cross-reference and we don't need to go
any further.

At the same time, draft-kaliraj-idr-bgp-classful-transport-planes introduces
"Service End point (SEP)" as "the Protocol-Nexthop address carried in a BGP
Update message for a service or overlay route."

This seems a little specific to the BGP-based realization (with or without a
tunnelling protocol), and is probably not something we should mention in our
draft.

Thus, I propose to make no changes for this point.

Any concerns?

Cheers,
Adrian

---

From: <[email-masked]>
Date: Fri, 25 Mar 2022 09:49:57 +0000

Re-,

Agree with your assessment.  

I trust the authors of draft-kaliraj-idr-bgp-classful-transport-planes will consider adding text vs. SAP similar to what you have in Section 2.1. 

Cheers,
Med

> -----Message d'origine-----
> De : Teas <[email-masked]> De la part de Adrian Farrel
> Envoyé : vendredi 25 mars 2022 10:35
> À : [email-masked]
> Objet : [Teas] Slicing Framework Open issue #2 : SDPs, SAPs, and SEPs
> 
> Hi,
> 
> Second issue.
> 
> introduced to get us round the many problems with "end point", "slice
> end point", CE, PE, etc.
> 
> models that meant that the service could be delivered at different
> places (see Figure 1 in the draft).
> 
> Point (SAP)" as "abstraction of the network reference points where
> network services can be delivered to customers."
> 
> I believe that this is enough of a cross-reference and we don't need to
> go any further.
> 
> 
> At the same time, draft-kaliraj-idr-bgp-classful-transport-planes
> introduces "Service End point (SEP)" as "the Protocol-Nexthop address
> carried in a BGP Update message for a service or overlay route."
> 
> This seems a little specific to the BGP-based realization (with or
> without a tunnelling protocol), and is probably not something we should
> mention in our draft.
> 
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

_________________________________________________________________________________________________________________________

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.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 25 Mar 2022 16:19:22 +0000

Actually both proposals resolve some of the (late) comments I just raised in my review...and I agree with both.

Thanks
Daniele  

> -----Original Message-----
> From: Teas <[email-masked]> On Behalf Of
> [email-masked]
> Sent: den 25 mars 2022 10:50
> To: [email-masked]; [email-masked]
> Subject: Re: [Teas] Slicing Framework Open issue #2 : SDPs, SAPs, and SEPs
> 
> Re-,
> 
> I trust the authors of draft-kaliraj-idr-bgp-classful-transport-planes will consider
> adding text vs. SAP similar to what you have in Section 2.1.
> 
> Cheers,
> Med
> 
> > De : Teas <[email-masked]> De la part de Adrian Farrel Envoyé :
> > vendredi 25 mars 2022 10:35 À : [email-masked] Objet : [Teas] Slicing
> > Framework Open issue #2 : SDPs, SAPs, and SEPs
> >
> > Hi,
> >
> > Second issue.
> >
> > Part of the problem was caused by the variations in different
> > deployment models that meant that the service could be delivered at
> > different places (see Figure 1 in the draft).
> >
> > While SDP did the job in the context of this document, it was noted
> > that draft-ietf-opsawg-sap defines the more generic term "Service
> > Attachment Point (SAP)" as "abstraction of the network reference
> > points where network services can be delivered to customers."
> >
> > I believe that this is enough of a cross-reference and we don't need
> > to go any further.
> >
> >
> > without a tunnelling protocol), and is probably not something we
> > should mention in our draft.
> >
> >
> _________________________________________________________________
> ________________________________________________________
> 
> 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.

---

From: Kiran Ietf <[email-masked]>
Date: Fri, 25 Mar 2022 11:19:42 -0700

Yes, SAP sounds   better.
  
  Connecting to first issue on definition   , I was wondering     if it would   make more sense to call them NSSAP (or network slice service attachment point)? Since now we   explicitly describe a   network slice service in the   document and that’s what these SAPs will provide. So it’s not any generic service but the one specified for    slices.

 Regards  
Kiran

  
  
>   
> On Mar 25, 2022 at 9:20 AM,  <Daniele Ceccarelli (mailto:daniele.ceccarelli=[email-masked])>  wrote:
>   
>   
>   
>  Actually both proposals resolve some of the (late) comments I just raised in my review...and I agree with both. Thanks Daniele  >  -----Original Message-----  >  From: Teas  <[email-masked]>  On Behalf Of  >  [email-masked]  >  Sent: den 25 mars 2022 10:50  >  To: [email-masked]; [email-masked]  >  Subject: Re: [Teas] Slicing Framework Open issue #2 : SDPs, SAPs, and SEPs  >   >  Re-,  >   >  Agree with your assessment.  >   >  I trust the authors of draft-kaliraj-idr-bgp-classful-transport-planes will consider  >  adding text vs. SAP similar to what you have in Section 2.1.  >   >  Cheers,  >  Med  >   >   >  -----Message d'origine-----  >   >  De : Teas  <[email-masked]>  De la part de Adrian Farrel Envoyé :  >   >  vendredi 25 mars 2022 10:35 À : [email-masked] Objet : [Teas] Slicing  >   >  Framework Open issue #2 : SDPs, SAPs, and SEPs  >   >   >   >  Hi,  >   >   >   >  Second issue.  >   >   >   >  The document uses the term Service Demarcation Point (SDP). This was  >   >  introduced to get us round the many problems with "end point", "slice  >   >  end point", CE, PE, etc.  >   >   >   >  Part of the problem was caused by the variations in different  >   >  deployment models that meant that the service could be delivered at  >   >  different places (see Figure 1 in the draft).  >   >   >   >  While SDP did the job in the context of this document, it was noted  >   >  that draft-ietf-opsawg-sap defines the more generic term "Service  >   >  Attachment Point (SAP)" as "abstraction of the network reference  >   >  points where network services can be delivered to customers."  >   >   >   >  To handle this, our draft currently says (Section 2.1)...  >   >   >   >  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.  >   >   >   >  I believe that this is enough of a cross-reference and we don't need  >   >  to go any further.  >   >   >   >   >   >  At the same time, draft-kaliraj-idr-bgp-classful-transport-planes  >   >  introduces "Service End point (SEP)" as "the Protocol-Nexthop address  >   >  carried in a BGP Update message for a service or overlay route."  >   >   >   >  This seems a little specific to the BGP-based realization (with or  >   >  without a tunnelling protocol), and is probably not something we  >   >  should mention in our draft.  >   >   >   >   >   >  Thus, I propose to make no changes for this point.  >   >   >   >  Any concerns?  >   >   >   >  Cheers,  >   >  Adrian  >   >   >   >  _______________________________________________  >   >  Teas mailing list  >   >  [email-masked]  >   >  https://www.ietf.org/mailman/listinfo/teas  >   >  _________________________________________________________________  >  ________________________________________________________  >   >  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 mailing list  >  [email-masked]  >  https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list [email-masked] https://www.ietf.org/mailman/listinfo/teas  
>
>

---

From: t petch <[email-masked]>
Date: Thu, 31 Mar 2022 17:24:00 +0100

> Thus, I propose to make no changes for this point.

I just commented on the OPSAWG list that the definition of SAP, in a 
single sentence is, word for word, identical with the definition of 
Termination Point, also in a single sentence, in the Network RFC (whose 
number eludes me).  (Termination Point is widely used in TEAS documents 
as you will know). I stopped reading -sap at that point; the author 
assures me that if I plough on all will become clear but I think that it 
needs to be clearer earlier so as yet I am unclear about the distinction 
between SAP and TP.

Also, SAP has been in use for many decades in the context of ISO, IEEE 
and so on (by many people including I) and since I am unclear what an 
opsawg-sap is, I do not know how this relates to an ISO SAP.

As you say at the start, there are many terms in use in this area and I 
suspect that most are ill-defined (opsawg-sap also defines PE and CE and 
other WG may have other definitions of these two); these terms tend to 
lack a rigorous test to apply to say whether or not an entity is a .. 
well, how about TLA?

Tom Petch

> .

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 1 Apr 2022 00:35:55 -0400

My vote is to leave as is as SDP.

Reason being is the word “Demark” has wider scope where the word
“attachment” is more along the lines of the word “end” and going down the
road of PE / CE like terms which we are tying to stay clear of.

As well SAP in an abstraction of network  along the lines of PE/CE L2NM and
L3NM services.

So term SAP is more limited where SDP is more general which is what we want
and covers all of our basis for realizing an IETF network slice.

Kind Regards

Gyan

On Thu, Mar 31, 2022 at 12:25 PM t petch <[email-masked]> wrote:

> go
> introduces
> without a
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*