Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

From: John E Drake <[email-masked]>
Date: Sat, 3 Apr 2021 20:06:26 +0000

Hi,

As a follow-up to the email, below, that Eric and I sent in late February, here is our proposed definition of an IETF Network Slice Service:

IETF Network Slice Service - A service provider instantiates a service for a customer which is specified in terms of a set of the customer's endpoints (CEs), a set of connectivity matrices (MP2MP, P2MP, MP2P, and P2P) between subsets of these CEs and an SLO for each CE sending to each connectivity matrix.  I.e., in a given IETF network slice service there may be multiple connectivity matrices of the same or different type, each connectivity matrix may be between a different subset of CEs, and for a given connectivity matrix each sending CE has its own SLO and each SLO may be different.  It is also the case that a given sending CE may have a different SLO for each connectivity matrix to which it is sending.  Note that a given sending CEs's SLO for a given connectivity matrix applies between it and each of the receiving CEs for that connectivity matrix. 

This results in the following connectivity matrices:

	For a MP2MP connectivity matrix with N CEs, each of the N sending CEs has its own SLO and each may be different

	For a P2MP connectivity matrix, there is only one sending CE and there is only one SLO

	For a MP2P connectivity matrix with N CEs, each of the N - 1 sending CEs has its own SLO and each may be different

	For a P2P unidirectional connectivity matrix, there is only one sending CE and there is only one SLO

              For a P2P bidirectional connectivity matrix, there are two sending CEs, there are two SLOs, and each may be different 

If an IETF network slice service customer wants to have hub and spoke connectivity between N CEs in order to control how traffic is distributed between its CEs, it requests a set of N - 1 P2P unidirectional connectivity matrices, each between a sending CE spoke and the hub CE, and a P2MP connectivity matrix between the sending CE hub and the spoke CEs. 

It should be noted that per [RFC4364} section 9 (https://datatracker.ietf.org/doc/html/rfc4364#section-9) an IETF network slice service customer may actually be its own IETF network slice service provider in the same or different provider network.

For a given IETF network slice service, the IETF network slice customer and the IETF network slice provider agree, on a per-CE basis which end of the attachment circuit provides the service demarcation point.  This determines whether the attachment circuit is included in any SLOs for the subject CE.

Yours Irrespectively,

John

Juniper Business Use Only

> -----Original Message-----
> From: John E Drake
> Sent: Tuesday, February 23, 2021 9:53 AM
> To: [email-masked]; Joel M. Halpern
> <[email-masked]>; [email-masked]
> Subject: RE: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-
> definition-00
> 
> Hi,
> 
> Eric and I have reviewed the Definitions draft, the email thread with the subject
> line: Network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00,
> and the RFCs referenced in emails on that thread - 3985, 4110, 4026, 4664, and
> 8309, and we would like to propose that in the Definitions draft we replace
> 'network slice endpoint' with 'CE' and 'network slice realization endpoint' with
> 'PE', that we reference  RFCs  3985, 4110, 4026, 4664, and 8309, and that we
> replace the current figure in Endpoint section with several figures, which show
> connectivity constructs and which are consistent with these RFCs.  We would
> also like to replace 'consumer' with 'customer', add 'attachment circuit', and add
> a new term, viz, 'IETF Network Slice Service', whose definition is a set of CEs, a
> set of connectivity constructs (MP2MP, P2MP, P2P, etc.) between subsets of
> these CEs and an SLO for each CE sending to each connectivity construct.
> 
> As an aside, the Endpoint section of the Definitions draft uses the bulk of its
> prose enumerating what its endpoints are not.  Per Yakov, since there are a
> potentially infinite number of things which its endpoints are not, this is futile and
> we would like to remove that prose.
> 
> Yours Irrespectively,
> 
> Eric and John
> 
> 
> Juniper Business Use Only
> 
> > -----Original Message-----
> > From: Teas <[email-masked]> On Behalf Of
> > [email-masked]
> > Sent: Tuesday, February 16, 2021 11:59 AM
> > To: Joel M. Halpern <[email-masked]>; [email-masked]
> > Subject: Re: [Teas] network Slice Endpoint in
> > draft-ietf-teas-ietf-network-slice-
> > definition-00
> >
> > [External Email. Be cautious of content]
> >
> >
> > Re-,
> >
> > Indeed. That's need to be fixed.
> >
> > As we are on the terminology, I do also suggest that the draft is
> > updated to adhere to RFC8309. Given the recursiveness discussed in the
> > draft, having geo- coordinates interfaces is also confusing. Inspiring
> > from RFC8309 would make more sense.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Joel M. Halpern [mailto:[email-masked]] Envoyé : mardi 16
> > > février 2021 17:44 À : BOUCADAIR Mohamed TGI/OLN
> > > <[email-masked]>; [email-masked] Objet : Re: [Teas]
> > > network Slice Endpoint in draft-ietf-teas-ietf-
> > > network-slice-definition-00
> > >
> > > I would be happy to use CE and PE.  I would also be happy to use
> > > completely different words.  The current diagram and terminology
> > > makes this very confusing, and leads to problems.
> > >
> > > Yours,
> > > Joel
> > >
> > > On 2/16/2021 11:39 AM, [email-masked] wrote:
> > > > Re-,
> > > >
> > > > Please see inline.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > >> -----Message d'origine-----
> > > >> De : Teas [mailto:[email-masked]] De la part de Joel M.
> > > >> Halpern
> > > >> Envoyé : mardi 16 février 2021 17:12 À : [email-masked] Objet : Re:
> > > >> [Teas] network Slice Endpoint in draft-ietf-teas-ietf-
> > > >> network-slice-definition-00
> > > >>
> > > >> The document is not about the request from the external customer
> > > (the
> > > >> request for the end-to-end network slice). It is about the
> > > >> request from other orchestration systems to the IETF Network
> > > >> Slice
> > > management
> > > >> systems.
> > > >
> > > > [Med] ... which is still behaving as the customer role.
> > > >
> > > >   Yes, those systems need to know where they intent to
> > > >> utilize the IETF network slice.  But the IETF network slice does
> > > not
> > > >> need to know about that.
> > > >
> > > > [Med] This is what I fail to see. The orchestrator has an internal
> > > vision that is not available to the entity asking for a slice. These
> > > nodes are not even known to the "other orchestration systems" when
> > > asking for a slice.
> > > >
> > > >>
> > > >> In particular, when we get to talking about configuring the IETF
> > > >> Network Slice properties, the edge (ingress) that the IETF
> > > >> Network Slice controller controls (and corresponding egress) is
> > > >> what needs
> > > to
> > > >> be provisioned.
> > > >
> > > > [Med] Agree, but that is a distinct phase.
> > > >
> > > > BTW, ingress/egress are as a function of the traffic direction. A
> > > node (PE) may behave as both ingress and egress for the same slice.
> > > >
> > > >> It is possible that on the egress side there needs to be
> > > information
> > > >> about how to deliver the traffic externally.
> > > >
> > > > [Med] Agree. That node does not need to be visible (known in
> > > advance) to the entity that will consume the corresponding slice.
> > > >
> > > >    But that would not be
> > > >> in terms of end-points since from the perspective of the IETF
> > > Network
> > > >> Slice, on the egress that is not an endpoint of anything.
> > > >
> > > > [Med] I agree that "endpoint" is confusing. "Customer Node/Edge"
> > > > vs
> > > "Provider Edge" are my favorite here.
> > > >
> > > >>
> > > >> Yours,
> > > >> Joel
> > > >>
> > > >> On 2/16/2021 11:05 AM, [email-masked] wrote:
> > > >>> Hi Joel,
> > > >>>
> > > >>> I disagree with this note. I do think that both flavors of
> > > >> "endpoint" should be included in the draft.
> > > >>>
> > > >>> >From the customer standpoint, a slice request cannot be
> > > >> characterized by elements not visible to the customer. The scope
> > > of a
> > > >> requested slice can only be characterized between nodes that are
> > > >> known to the requestor. This is usually called, CE.
> > > >>>
> > > >>> The mapping between a CE and a network device (typically, a PE)
> > > is
> > > >> a process that is internal to the slice provider.
> > > >>>
> > > >>> The CE-PE link cannot be systematically excluded as some
> > > >>> specific
> > > >> behaviors may need to be enforced in the CE-PE link. Think about
> > > >> a slice that is implemented by means of a PE-based VPN and which
> > > >> requires some specific routing + QoS policies at the CE-PE link.
> > > >>>
> > > >>> Cheers,
> > > >>> Med
> > > >
> > > >
> > > >
> > >
> >
> _________________________________________________________________
> > ____
> > > _
> > > > ___________________________________________________
> > > >
> > > > 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 mailing list
> > [email-masked]
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!N
> > Et6yMaO-gk!TrdpM67-tg4psF0dnG7jBV9LisKHxO_oCNxmQXrJhY-
> > B6MFchY8gBvvb8CNl408$

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 3 Apr 2021 17:44:18 -0400

That seems to capture what we have been dsicussing.
Thank you,
Joel

---

From: Tarek Saad <[email-masked]>
Date: Sun, 4 Apr 2021 02:31:30 +0000

John/all,

I can glean the following from this definition. Let me know if misinterpreted.

1) A connection supporting a network slice is unidirectional. A corollary is: SLO(s) are unidirectional too.

2) From a sending CE, there are only 2 types of connectivity matrices:

  *   P2P unidirectional
  *   P2MP unidirectional

Using the above type of matrices on a sending CE, one can realize any of network slice connectivity type required – e.g., quoting your example, a MP2P can be realized by (N – 1) P2P unidirectional connectivity matrices on the sending CEs.

3) The SLOs are per matrix type – either P2P or P2MP. Is the definition anywhere precluding having multiple connectivity types of matrices from a sending CE for the same network slice?(e.g. a mix of (n x P2P) and m x P2MP connectivity matrices on the same sending CE for the same network slice)?

Regards,

Tarek

On 4/3/21, 4:06 PM, "Teas on behalf of John E Drake" <[email-masked] on behalf of jdrake=[email-masked]> wrote:

    Hi,

    IETF Network Slice Service - A service provider instantiates a service for a customer which is specified in terms of a set of the customer's endpoints (CEs), a set of connectivity matrices (MP2MP, P2MP, MP2P, and P2P) between subsets of these CEs and an SLO for each CE sending to each connectivity matrix.  I.e.,

in a given IETF network slice service there may be multiple connectivity matrices of the same or different type, each connectivity matrix may be between a different subset of CEs, and for a given connectivity matrix each sending CE has its own SLO and each SLO may be different.  It is also the case that a given sending CE may have a different SLO for each connectivity matrix to which it is sending.  Note that a given sending CEs's SLO for a given connectivity matrix applies between it and each of the receiving CEs for that connectivity matrix.

    Yours Irrespectively,

    John

    Teas mailing list

    [email-masked]

    https://www.ietf.org/mailman/listinfo/teas

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 3 Apr 2021 20:04:02 -0700

Hi Tarek,
thank you for bringing up these questions. I've been thinking, playing in
my mind with the SLO in a network slice.
I agree that the SLO is for an ordered pair of CEs, and thus it is
unidirectional regardless of the connection matrix. But I think that there
might be a use case for a bidirectional P2P connection, especially if [A,
B] and [B, A] SLOs are identical. Also, a bidirectional P2P connection
might be a useful construct when directions are sharing each other fate
under the protection switchover scenario.

What are your thoughts?

Regards,
Greg

On Sat, Apr 3, 2021 at 7:31 PM Tarek Saad <tsaad=
[email-masked]> wrote:

>    - P2P unidirectional
>    - P2MP unidirectional
> Using the above type of matrices on a sending CE, one can realize any of
> network slice connectivity type required – e.g., quoting your example, a
> MP2P can be realized by (N – 1) P2P unidirectional connectivity matrices on
> the sending CEs.
>
>
>
> 3) The SLOs are per matrix type – either P2P or P2MP. Is the definition
> anywhere precluding having multiple connectivity types of matrices from a
> sending CE for the same network slice?(e.g. a mix of (n x P2P) and m x P2MP
> connectivity matrices on the same sending CE for the same network slice)?
>
>
>
> Regards,
>
> Tarek
>
>
>
> On 4/3/21, 4:06 PM, "Teas on behalf of John E Drake" <
> [email-masked] on behalf of jdrake=[email-masked]>
> wrote:
>
>
>
>     Hi,
>
>
>
>     As a follow-up to the email, below, that Eric and I sent in late
> February, here is our proposed definition of an IETF Network Slice Service:
>
>
>
>
>
>     IETF Network Slice Service - A service provider instantiates a service
> for a customer which is specified in terms of a set of the customer's
> endpoints (CEs), a set of connectivity matrices (MP2MP, P2MP, MP2P, and
> P2P) between subsets of these CEs and an SLO for each CE sending to each
> connectivity matrix.  I.e.,
>
> in a given IETF network slice service there may be multiple connectivity
> matrices of the same or different type, each connectivity matrix may be
> between a different subset of CEs, and for a given connectivity matrix each
> sending CE has its own SLO and each SLO may be different.  It is also the
> case that a given sending CE may have a different SLO for each connectivity
> matrix to which it is sending.  Note that a given sending CEs's SLO for a
> given connectivity matrix applies between it and each of the receiving CEs
> for that connectivity matrix.
>
>
>
>              For a MP2MP connectivity matrix with N CEs, each of the N
> sending CEs has its own SLO and each may be different
>
>
>
>              For a MP2P connectivity matrix with N CEs, each of the N - 1
> sending CEs has its own SLO and each may be different
>
>
>
>                   For a P2P bidirectional connectivity matrix, there are
> two sending CEs, there are two SLOs, and each may be different
>
>
>
>     If an IETF network slice service customer wants to have hub and spoke
> connectivity between N CEs in order to control how traffic is distributed
> between its CEs, it requests a set of N - 1 P2P unidirectional connectivity
> matrices, each between a sending CE spoke and the hub CE, and a P2MP
> connectivity matrix between the sending CE hub and the spoke CEs.
>
>
>
>     It should be noted that per [RFC4364} section 9 (
> https://datatracker.ietf.org/doc/html/rfc4364#section-9) an IETF network
> slice service customer may actually be its own IETF network slice service
> provider in the same or different provider network.
>
>
>
>     For a given IETF network slice service, the IETF network slice
> customer and the IETF network slice provider agree, on a per-CE basis which
> end of the attachment circuit provides the service demarcation point.  This
> determines whether the attachment circuit is included in any SLOs for the
> subject CE.
>
>
>
>     Yours Irrespectively,
>
>
>
>     John
>
>
>
>
>
>     > line: Network Slice Endpoint in
> draft-ietf-teas-ietf-network-slice-definition-00,
>
> and
> have

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 4 Apr 2021 13:21:06 +0100

Hi,

1.	I think John’s text is a very good starting point. Thanks for that. Stick it in the draft and we can polish it.
2.	Connection constructs are not simply rooted at *a* CE because mp2p, mp2mp.
3.	Yes, a slice service may include multiple connection constructs
4.	Yes, an SLO applies to a sender’s data within a single connection construct. A connection construct may have one sender (p2p, p2mp) or multiple senders (mp2p, mp2mp).
5.	Yes, a bidirectional connection construct may exist, but it doesn’t have to have symmetric SLOs. (Actually it is an mp2mp services with only two end points.) So, yes, two SLOs for a bidirectional p2p connections, and those SLOs may be identical.

Best,

Adrian

From: Teas <[email-masked]> On Behalf Of Greg Mirsky
Sent: 04 April 2021 04:04
To: Tarek Saad <tsaad=[email-masked]>
Cc: Kireeti Kompella <[email-masked]>; Manish Gupta <[email-masked]>; [email-masked]; John E Drake <jdrake=[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi Tarek,

thank you for bringing up these questions. I've been thinking, playing in my mind with the SLO in a network slice.

I agree that the SLO is for an ordered pair of CEs, and thus it is unidirectional regardless of the connection matrix. But I think that there might be a use case for a bidirectional P2P connection, especially if [A, B] and [B, A] SLOs are identical. Also, a bidirectional P2P connection might be a useful construct when directions are sharing each other fate under the protection switchover scenario.

What are your thoughts?

Regards,

Greg

On Sat, Apr 3, 2021 at 7:31 PM Tarek Saad <tsaad=[email-masked] <mailto:[email-masked]> > wrote:

John/all,

*	P2P unidirectional
*	P2MP unidirectional

 Regards,

Tarek

 On 4/3/21, 4:06 PM, "Teas on behalf of John E Drake" <[email-masked] <mailto:[email-masked]>  on behalf of jdrake=[email-masked] <mailto:[email-masked]> > wrote:

     Hi,

---

From: John E Drake <[email-masked]>
Date: Sun, 4 Apr 2021 16:04:27 +0000

Greg,

“For a P2P bidirectional connectivity matrix, there are two sending CEs, there are two SLOs, and each may be different”

 Yours Irrespectively,
John

Juniper Business Use Only
From: Greg Mirsky <[email-masked]>
Sent: Saturday, April 3, 2021 11:04 PM
To: Tarek Saad <[email-masked]>
Cc: John E Drake <[email-masked]>; [email-masked]; Joel M. Halpern <[email-masked]>; [email-masked]; Kireeti Kompella <[email-masked]>; Manish Gupta <[email-masked]>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi Tarek,

What are your thoughts?

Regards,
Greg

On Sat, Apr 3, 2021 at 7:31 PM Tarek Saad <tsaad=[email-masked]<mailto:[email-masked]>> wrote:

John/all,

  *   P2P unidirectional
  *   P2MP unidirectional

Regards,

Tarek

On 4/3/21, 4:06 PM, "Teas on behalf of John E Drake" <[email-masked]<mailto:[email-masked]> on behalf of jdrake=[email-masked]<mailto:[email-masked]>> wrote:

    Hi,

    It should be noted that per [RFC4364} section 9 (https://datatracker.ietf.org/doc/html/rfc4364#section-9<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4364*section-9__;Iw!!NEt6yMaO-gk!Re9TWXBB48lKs2jUNTw2_iNuEZL2_61UYeKvK_n59MV7lfMPJ91pTywhv9jHWzc$>) an IETF network slice service customer may actually be its own IETF network slice service provider in the same or different provider network.

    Yours Irrespectively,

    John

    > To: [email-masked]<mailto:[email-masked]>; Joel M. Halpern

    > <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

    > > From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of

    > > [email-masked]<mailto:[email-masked]>

    > > To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

    > > > De : Joel M. Halpern [mailto:[email-masked]<mailto:[email-masked]>] Envoyé : mardi 16

    > > > <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> Objet : Re: [Teas]

    > > > On 2/16/2021 11:39 AM, [email-masked]<mailto:[email-masked]> wrote:

    > > > >> De : Teas [mailto:[email-masked]<mailto:[email-masked]>] De la part de Joel M.

    > > > >> Envoyé : mardi 16 février 2021 17:12 À : [email-masked]<mailto:[email-masked]> Objet : Re:

    > > > >> On 2/16/2021 11:05 AM, [email-masked]<mailto:[email-masked]> wrote:

    > > [email-masked]<mailto:[email-masked]>

    > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas>

    Teas mailing list

    [email-masked]<mailto:[email-masked]>

    https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Re9TWXBB48lKs2jUNTw2_iNuEZL2_61UYeKvK_n59MV7lfMPJ91pTywhOXK0tfI$>

Juniper Business Use Only
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Re9TWXBB48lKs2jUNTw2_iNuEZL2_61UYeKvK_n59MV7lfMPJ91pTywhOXK0tfI$>

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Sun, 4 Apr 2021 18:01:35 +0000

Hi all,

I see we are iterating around the CE acronym but not always with the same expansion, so this is a question for clarification in order to be sure we consider the proper expansion/term on definitions draft. On John’s mail about IETF Network Slice Service definition (thanks for the proposed text, by the way) CE is associated to customer's endpoints, while usually the term (even for the same referenced RFC4364 in John’s mail) CE is associated to customer edge. I agree that for the definition of the slice service we need the notion of endpoint. Then, should we consider customer edge endpoint (CEE) for that?

This would avoid misassumptions on CE meaning (remember we originally assumed network slice endpoint with that same idea, but clearly CE-related terminology is preferred by the WG for expressing customer view).

Thanks for any further clarification on the points of view of the WG.

Best regards

Luis

De: Teas <[email-masked]> En nombre de John E Drake
Enviado el: domingo, 4 de abril de 2021 18:04
Para: Greg Mirsky <[email-masked]>; Tarek Saad <[email-masked]>
CC: Kireeti Kompella <[email-masked]>; Manish Gupta <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]; [email-masked]
Asunto: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Greg,

 Yours Irrespectively,
John

Juniper Business Use Only
From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, April 3, 2021 11:04 PM
To: Tarek Saad <[email-masked]<mailto:[email-masked]>>
Cc: John E Drake <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Manish Gupta <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi Tarek,

What are your thoughts?

Regards,
Greg

John/all,

·         P2P unidirectional

·         P2MP unidirectional

Regards,

Tarek

    Hi,

    Yours Irrespectively,

    John

    Teas mailing list

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: John E Drake <[email-masked]>
Date: Sun, 4 Apr 2021 18:42:39 +0000

Luis,

There are [CE, AC, PE] tuples at every service edge, and as indicated in my email, the customer and the provider decide which end of the AC is the service demarcation point;  i.e., whether the AC is included in the SLO.

Thanks,

John

Sent from my iPhone

On Apr 4, 2021, at 2:02 PM, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]> wrote:

Hi all,

Best regards

Luis

Greg,

 Yours Irrespectively,
John

Hi Tarek,

What are your thoughts?

Regards,
Greg

John/all,

·         P2P unidirectional

·         P2MP unidirectional

Regards,

Tarek

    Hi,

    Yours Irrespectively,

    John

    Teas mailing list

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________
Teas mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Szg0xFgXcD86x_IAFr2FwWJgj3XjliUdMTB6-x4gadBhtoJHCdhAzWq6pmHUfEo$

---

From: Tarek Saad <[email-masked]>
Date: Sun, 4 Apr 2021 20:10:20 +0000

Yes, this is my point. Using the two basic constructs (below), one can realize the more complex connectivity types.

  *   P2P unidirectional
  *   P2MP unidirectional
Also, I am in favor of renaming the above to:

  *   Connection
  *   Connection group (to distinguish it from P2MP multicast)

Regards,
Tarek

On 4/4/21, 12:04 PM, "John E Drake" <[email-masked]<mailto:[email-masked]>> wrote:

Greg,

 Yours Irrespectively,
John

Hi Tarek,

What are your thoughts?

Regards,
Greg

John/all,

·         P2P unidirectional

·         P2MP unidirectional

Regards,

Tarek

    Hi,

    Yours Irrespectively,

    John

    Teas mailing list

---

From: Tarek Saad <[email-masked]>
Date: Sun, 4 Apr 2021 20:19:56 +0000

Hi Adrian,

Thanks.

On 4/4/21, 8:21 AM, "Adrian Farrel" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

2.       Connection constructs are not simply rooted at *a* CE because mp2p, mp2mp.
[TS]: I’m quoting from below, to realize the MP2P, one would require N-1 P2P unidirectional connections (on sending CEs), and 1 P2MP unidirectional connection on the hub.

“    If an IETF network slice service customer wants to have hub and spoke connectivity between N CEs in order to control how traffic is distributed between its CEs, it requests a set of N - 1 P2P unidirectional connectivity matrices, each between a sending CE spoke and the hub CE, and a P2MP connectivity matrix between the sending CE hub and the spoke CEs.“

[TS]: OK, good.

4.       Yes, an SLO applies to a sender’s data within a single connection construct. A connection construct may have one sender (p2p, p2mp) or multiple senders (mp2p, mp2mp).
[TS]: with the two basic constructs (unidirectional connection, and connection group) rooted on the respective CE, one can realize the above connectivity..

5.       Yes, a bidirectional connection construct may exist, but it doesn’t have to have symmetric SLOs. (Actually it is an mp2mp services with only two end points.) So, yes, two SLOs for a bidirectional p2p connections, and those SLOs may be identical.
[TS]: Agreed, but to realize bidirectional connectivity, I require 2 unidirectional connection constructs whose SLOs may or may not be same.

Regards,
Tarek

Best,
Adrian

Hi Tarek,

What are your thoughts?

Regards,
Greg

John/all,

2) >From a sending CE, there are only 2 types of connectivity matrices:

· P2P unidirectional

· P2MP unidirectional

 Regards,

Tarek

     Hi,

     It should be noted that per [RFC4364} section 9 (https://datatracker.ietf.org/doc/html/rfc4364#section-9<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4364*section-9__;Iw!!NEt6yMaO-gk!WHFr7oDhtlR3DK2AParJ1Ca-QP2Y0pbvYA1LAeSQO1_0Fa29p8kgaurw0vnG2Q$>) an IETF network slice service customer may actually be its own IETF network slice service provider in the same or different provider network.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 4 Apr 2021 21:43:27 +0100

Hi Tarek,

[AF] I am always cautious of content, but never more so than when it comes with a warning attached.

[AF] Well, yes, that’s a quote, but it’s a quote about hub and spoke, not about mp2pm in general. He only reason you’d do that is if you want to control/specify a hub CE. Elsewise, you’d just ask for an MP2MP connectivity service and let the network get on with it.

[TS]: OK, good.

[AF] Realizing connectivity is, of course, interesting both to the vendor and the service provider, but it is a very different thing from the requested service. Yes, you could ask a customer to work out that they need n p2p connections and how to group them to build the service they want, but you wouldn’t (if you wanted their business). You would ask them to specify the set of senders and the set of receivers, and you (the operator) would work out what to do under the covers.

[AF] I have some sympathy with noting that p2p is only a special case of mp2mp, and that leads me to note that the general case can be stated as a list of senders and a list of receivers (with overlap of the sets allowed) and no need to describe the connectivity construct. On the other hand, people generally like the short hand that a connectivity construct yields.

[AF] I believe that is what I wrote, yes.

Cheers,

Adrian

From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf Of Greg Mirsky
Sent: 04 April 2021 04:04
To: Tarek Saad <tsaad=[email-masked] <mailto:tsaad=[email-masked]> >
Cc: Kireeti Kompella <[email-masked] <mailto:[email-masked]> >; Manish Gupta <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; John E Drake <jdrake=[email-masked] <mailto:jdrake=[email-masked]> >; Joel M. Halpern <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi Tarek,

What are your thoughts?

Regards,

Greg

John/all,

*     P2P unidirectional

*     P2MP unidirectional

 Regards,

Tarek

     Hi,

     It should be noted that per [RFC4364} section 9 (https://datatracker.ietf.org/doc/html/rfc4364#section-9 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4364*section-9__;Iw!!NEt6yMaO-gk!WHFr7oDhtlR3DK2AParJ1Ca-QP2Y0pbvYA1LAeSQO1_0Fa29p8kgaurw0vnG2Q$> ) an IETF network slice service customer may actually be its own IETF network slice service provider in the same or different provider network.

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 6 Apr 2021 16:51:43 +0200

Hi,

For fixing the terminology, we need as well consider the transport slicing with 3GPP/O-RAN use cases, where mobile functions requiring transport interconnections reside in telco clouds (DC location). In most based deployments scenario, DC is his connected to the transport network via two DC gateways (DCGW) with VLAN handover to transport PE. So, this is perfect match to PE-CE terminology, where DCGW is CE, and transport router facing DCGW is PE.

However, in smaller telco cloud locations, we should expect collapsed DCGW+PE design, without physical separation between DCGW (a la ‘CE’) and PE. So, kind of collapsed PE+CE node. Inside DC the underlay could be anything: VLANs, or some tunnels (e.g. VxLAN, MPLSoUDP, SRoUDP, upcoming Geneve, ….), depending on the actual DC design. Whatever is being defined as the network slices, must take in the consideration above use case as well.

Thanks,
Krzysztof

> On 2021 -Apr-04, at 20:42, John E Drake <jdrake=[email-masked]> wrote:
> 
> Luis,
> 
>> On Apr 4, 2021, at 2:02 PM, LUIS MIGUEL CONTRERAS MURILLO <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
>> De: Teas <[email-masked] <mailto:[email-masked]>> En nombre de John E Drake
>> Para: Greg Mirsky <[email-masked] <mailto:[email-masked]>>; Tarek Saad <[email-masked] <mailto:[email-masked]>>
>> CC: Kireeti Kompella <[email-masked] <mailto:[email-masked]>>; Manish Gupta <[email-masked] <mailto:[email-masked]>>; Joel M. Halpern <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>> From: Greg Mirsky <[email-masked] <mailto:[email-masked]>> 
>> To: Tarek Saad <[email-masked] <mailto:[email-masked]>>
>> Cc: John E Drake <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Joel M. Halpern <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Kireeti Kompella <[email-masked] <mailto:[email-masked]>>; Manish Gupta <[email-masked] <mailto:[email-masked]>>
>> On Sat, Apr 3, 2021 at 7:31 PM Tarek Saad <tsaad=[email-masked] <mailto:[email-masked]>> wrote:
>> John/all,
>> 
>>  
>> 
>> On 4/3/21, 4:06 PM, "Teas on behalf of John E Drake" <[email-masked] <mailto:[email-masked]> on behalf of jdrake=[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>  
>> 
>>     Hi,
>> 
>>  
>> 
>>     It should be noted that per [RFC4364} section 9 (https://datatracker.ietf.org/doc/html/rfc4364#section-9 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4364*section-9__;Iw!!NEt6yMaO-gk!Re9TWXBB48lKs2jUNTw2_iNuEZL2_61UYeKvK_n59MV7lfMPJ91pTywhv9jHWzc$>) an IETF network slice service customer may actually be its own IETF network slice service provider in the same or different provider network.
>> 
>>  
>> 
>>     > To: [email-masked] <mailto:[email-masked]>; Joel M. Halpern
>> 
>>     > <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>>     > > From: Teas <[email-masked] <mailto:[email-masked]>> On Behalf Of
>> 
>>     > > [email-masked] <mailto:[email-masked]>
>>     > > To: Joel M. Halpern <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>>     > > > De : Joel M. Halpern [mailto:[email-masked] <mailto:[email-masked]>] Envoyé : mardi 16
>> 
>>     > > > <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]> Objet : Re: [Teas]
>> 
>>     > > > On 2/16/2021 11:39 AM, [email-masked] <mailto:[email-masked]> wrote:
>> 
>>     > > > > Re-,
>> 
>>     > > > >
>> 
>>     > > > > Please see inline.
>> 
>>     > > > >
>> 
>>     > > > > Cheers,
>> 
>>     > > > > Med
>> 
>>     > > > >
>> 
>>     > > > >> De : Teas [mailto:[email-masked] <mailto:[email-masked]>] De la part de Joel M.
>> 
>>     > > > >> Halpern
>> 
>>     > > > >> Envoyé : mardi 16 février 2021 17:12 À : [email-masked] <mailto:[email-masked]> Objet : Re:
>> 
>>     > > > >> On 2/16/2021 11:05 AM, [email-masked] <mailto:[email-masked]> wrote:
>> 
>>     > > > >>> Hi Joel,
>> 
>>     > > > >>>
>> 
>>     > > [email-masked] <mailto:[email-masked]>
>>     > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas>
>>     > > __;!!N
>> 
>>     [email-masked] <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Re9TWXBB48lKs2jUNTw2_iNuEZL2_61UYeKvK_n59MV7lfMPJ91pTywhOXK0tfI$>
>>  
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Re9TWXBB48lKs2jUNTw2_iNuEZL2_61UYeKvK_n59MV7lfMPJ91pTywhOXK0tfI$>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Szg0xFgXcD86x_IAFr2FwWJgj3XjliUdMTB6-x4gadBhtoJHCdhAzWq6pmHUfEo$ <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Szg0xFgXcD86x_IAFr2FwWJgj3XjliUdMTB6-x4gadBhtoJHCdhAzWq6pmHUfEo$> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>

---

From: John E Drake <[email-masked]>
Date: Tue, 6 Apr 2021 15:02:46 +0000

Sent from my iPhone

On Apr 6, 2021, at 10:52 AM, Krzysztof Szarkowicz <[email-masked]> wrote:

Hi,

Thanks,
Krzysztof

On 2021 -Apr-04, at 20:42, John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>> wrote:

Luis,

Thanks,

John

Sent from my iPhone

On Apr 4, 2021, at 2:02 PM, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Best regards

Luis

De: Teas <[email-masked]<mailto:[email-masked]>> En nombre de John E Drake
Enviado el: domingo, 4 de abril de 2021 18:04
Para: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Tarek Saad <[email-masked]<mailto:[email-masked]>>
CC: Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Manish Gupta <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Asunto: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Greg,

 Yours Irrespectively,

John

Hi Tarek,

What are your thoughts?

Regards,
Greg

John/all,

•         P2P unidirectional

•         P2MP unidirectional

Regards,

Tarek

    Hi,

    Yours Irrespectively,

    John

    Teas mailing list

https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Uo9ATMZdnjZp0EH_lgNd9Wlr49UT-GmRt_6zqwTcjyubewqJWM2ATNpCTNW5C18$>

---

From: John E Drake <[email-masked]>
Date: Tue, 6 Apr 2021 15:07:18 +0000

Krzysztof,

We have already indicated that CEs, ACs, and PEs may all be virtualized and I’ll make sure that a figure depicting it is included.

Yours Irrespectively,

John

Juniper Business Use Only
From: Krzysztof Szarkowicz <[email-masked]>
Sent: Tuesday, April 6, 2021 10:52 AM
To: John E Drake <[email-masked]>
Cc: Luis Miguel Contreras Murillo <[email-masked]>; Greg Mirsky <[email-masked]>; Tarek Saad <[email-masked]>; Manish Gupta <[email-masked]>; [email-masked]; Kireeti Kompella <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi,

Thanks,
Krzysztof

Luis,

Thanks,

John
Sent from my iPhone

Hi all,

Best regards

Luis

Greg,

 Yours Irrespectively,
John

Hi Tarek,

What are your thoughts?

Regards,
Greg

John/all,

•         P2P unidirectional

•         P2MP unidirectional

Regards,

Tarek

    Hi,

    Yours Irrespectively,

    John

    Teas mailing list

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Szg0xFgXcD86x_IAFr2FwWJgj3XjliUdMTB6-x4gadBhtoJHCdhAzWq6pmHUfEo$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Szg0xFgXcD86x_IAFr2FwWJgj3XjliUdMTB6-x4gadBhtoJHCdhAzWq6pmHUfEo$>
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Uo9ATMZdnjZp0EH_lgNd9Wlr49UT-GmRt_6zqwTcjyubewqJWM2ATNpCTNW5C18$>

---

From: <[email-masked]>
Date: Tue, 6 Apr 2021 15:35:22 +0000

Hi John, all, 

Please some first comments see inline. 

Cheers,
Med

> De : John E Drake [mailto:[email-masked]]
> Envoyé : samedi 3 avril 2021 22:06
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>; Joel M.
> Halpern <[email-masked]>; [email-masked]
> Cc : Manish Gupta <[email-masked]>; Kireeti Kompella
> <[email-masked]>
> Objet : RE: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-
> IETF Network Slice Service - A service provider instantiates a
> service for a customer which is specified in terms of a set of the
> customer's endpoints (CEs)

[Med] The following text is connectivity-centric. I thought the WG wanted the service to cover other components than connectivity. We should capture this in the definition before we focus on the connectivity component. An easy first fix would be to indicate that CEs are where the service is delivered.     

, a set of connectivity matrices (MP2MP,
> P2MP, MP2P, and P2P) between subsets of these CEs

[Med] I'm afraid this is restrictive. Please refer to https://datatracker.ietf.org/doc/html/rfc7297#section-3.2 for a notion of reachability scope that is more generic than only matrices **between** CEs.   

 and an SLO for each
> CE sending to each connectivity matrix.

[Med] Not sure why there is a restriction to **an** SLO and why this is bound to a "CE sending ...". The connectivity component of a slice may be a receive-only service. There is no sending CE in such case. We need to cover these cases as well. 

  I.e., in a given IETF
> network slice service there may be multiple connectivity matrices of
> the same or different type, each connectivity matrix may be between a
> different subset of CEs, and for a given connectivity matrix each
> sending CE has its own SLO and each SLO may be different.  It is also
> the case that a given sending CE may have a different SLO for each
> connectivity matrix to which it is sending.  Note that a given
> sending CEs's SLO for a given connectivity matrix applies between it
> and each of the receiving CEs for that connectivity matrix.
> 
> connectivity between N CEs in order to control how traffic is
> distributed between its CEs, it requests a set of N - 1 P2P
> unidirectional connectivity matrices, each between a sending CE spoke
> and the hub CE, and a P2MP connectivity matrix between the sending CE
> hub and the spoke CEs.
> 
> It should be noted that per [RFC4364} section 9
> (https://datatracker.ietf.org/doc/html/rfc4364#section-9) an IETF
> network slice service customer may actually be its own IETF network
> slice service provider in the same or different provider network.
> 
> customer and the IETF network slice provider agree, on a per-CE basis
> which end of the attachment circuit provides the service demarcation
> point.  This determines whether the attachment circuit is included in
> any SLOs for the subject CE.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> > Eric and I have reviewed the Definitions draft, the email thread
> with
> > the subject
> > and the RFCs referenced in emails on that thread - 3985, 4110,
> 4026,
> > 4664, and 8309, and we would like to propose that in the
> Definitions
> > draft we replace 'network slice endpoint' with 'CE' and 'network
> slice
> > realization endpoint' with 'PE', that we reference  RFCs  3985,
> 4110,
> > 4026, 4664, and 8309, and that we replace the current figure in
> > Endpoint section with several figures, which show connectivity
> > constructs and which are consistent with these RFCs.  We would also
> > like to replace 'consumer' with 'customer', add 'attachment
> circuit',
> > and add a new term, viz, 'IETF Network Slice Service', whose
> > definition is a set of CEs, a set of connectivity constructs
> (MP2MP, P2MP, P2P, etc.) between subsets of these CEs and an SLO for
> each CE sending to each connectivity construct.
> >
> > As an aside, the Endpoint section of the Definitions draft uses the
> > bulk of its prose enumerating what its endpoints are not.  Per
> Yakov,
> > since there are a potentially infinite number of things which its
> > endpoints are not, this is futile and we would like to remove that
> prose.
> >
> > Yours Irrespectively,
> >
> > Eric and John
> >
> >
> > > updated to adhere to RFC8309. Given the recursiveness discussed
> in
> > > the draft, having geo- coordinates interfaces is also confusing.
> > > Inspiring from RFC8309 would make more sense.
> > >
> > > Cheers,
> > > Med
> > >
> > > > De : Joel M. Halpern [mailto:[email-masked]] Envoyé :
> mardi
> > > > 16 février 2021 17:44 À : BOUCADAIR Mohamed TGI/OLN
> > > > vision that is not available to the entity asking for a slice.
> > > > These nodes are not even known to the "other orchestration
> > > > systems" when asking for a slice.
> > > > >
> > > > >>
> > > > >> In particular, when we get to talking about configuring the
> > > > >> IETF Network Slice properties, the edge (ingress) that the
> IETF
> > > > > BTW, ingress/egress are as a function of the traffic
> direction.
> > > > > A
> > > > >> requested slice can only be characterized between nodes that
> > > > >> are known to the requestor. This is usually called, CE.
> > > > >>>
> > > > >> behaviors may need to be enforced in the CE-PE link. Think
> > > > >> about a slice that is implemented by means of a PE-based VPN
> > > > >> and which requires some specific routing + QoS policies at
> the CE-PE link.
> > > > >>>
> > > > >>> Cheers,
> > > > >>> Med
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > > > > Ce message et ses pieces jointes peuvent contenir des
> > > > > informations confidentielles ou privilegiees et ne doivent
> donc
> > > > > pas etre
> > > > diffuses,
> > > > susceptibles d'alteration, Orange decline toute responsabilite
> si
> > > > ce message a ete altere, deforme ou falsifie. Merci.
> > > > >
> > > 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,

_________________________________________________________________________________________________________________________

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: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 6 Apr 2021 18:22:57 +0200

John,

OK. What are the attributes to identify such virtualized CE (in the context of telco cloud)?

Cheers,
Krzysztof

> On 2021 -Apr-06, at 17:07, John E Drake <[email-masked]> wrote:
> 
> Krzysztof,
>  
> From: Krzysztof Szarkowicz <[email-masked] <mailto:[email-masked]>> 
> To: John E Drake <[email-masked] <mailto:[email-masked]>>
> Cc: Luis Miguel Contreras Murillo <[email-masked] <mailto:[email-masked]>>; Greg Mirsky <[email-masked] <mailto:[email-masked]>>; Tarek Saad <[email-masked] <mailto:[email-masked]>>; Manish Gupta <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Kireeti Kompella <[email-masked] <mailto:[email-masked]>>; Joel M. Halpern <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On 2021 -Apr-04, at 20:42, John E Drake <jdrake=[email-masked] <mailto:jdrake=[email-masked]>> wrote:
>  
> Luis,
>  
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Szg0xFgXcD86x_IAFr2FwWJgj3XjliUdMTB6-x4gadBhtoJHCdhAzWq6pmHUfEo$ <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Szg0xFgXcD86x_IAFr2FwWJgj3XjliUdMTB6-x4gadBhtoJHCdhAzWq6pmHUfEo$> 
> https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Uo9ATMZdnjZp0EH_lgNd9Wlr49UT-GmRt_6zqwTcjyubewqJWM2ATNpCTNW5C18$>

---

From: <[email-masked]>
Date: Tue, 6 Apr 2021 16:32:34 +0000

Re-,

This can be a tunnel endpoint or any component that is visible to the slice customer.

Please remember that such separation/identification is needed anyway to delimit the service scope, and particularly for slice service assurance purposes.

Cheers,
Med

De : Krzysztof Szarkowicz [mailto:[email-masked]]
Envoyé : mardi 6 avril 2021 18:23
À : John E Drake <[email-masked]>
Cc : Luis Miguel Contreras Murillo <[email-masked]>; Greg Mirsky <[email-masked]>; Tarek Saad <[email-masked]>; Manish Gupta <[email-masked]>; [email-masked]; Kireeti Kompella <[email-masked]>; Joel M. Halpern <[email-masked]>; BOUCADAIR Mohamed TGI/OLN <[email-masked]>
Objet : Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

John,

Cheers,
Krzysztof

On 2021 -Apr-06, at 17:07, John E Drake <[email-masked]<mailto:[email-masked]>> wrote:

Krzysztof,

Yours Irrespectively,

John

Juniper Business Use Only
From: Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, April 6, 2021 10:52 AM
To: John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: Luis Miguel Contreras Murillo <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Tarek Saad <[email-masked]<mailto:[email-masked]>>; Manish Gupta <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi,

Thanks,
Krzysztof

Luis,

Thanks,

John
Sent from my iPhone

Hi all,

Best regards

Luis

Greg,

 Yours Irrespectively,
John

Hi Tarek,

What are your thoughts?

Regards,
Greg

John/all,

•         P2P unidirectional

•         P2MP unidirectional

Regards,

Tarek

    Hi,

    Yours Irrespectively,

    John

    Teas mailing list