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

[Greg Mirsky <[e-mail]>]

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=
[e-mail]> wrote:

> 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" <
> [e-mail] on behalf of jdrake=[e-mail]>
> 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.
>
>
>
>     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: [e-mail]; Joel M. Halpern
>
>     > <[e-mail]>; [e-mail]
>
>     > 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 <[e-mail]> On Behalf Of
>
>     > > [e-mail]
>
>     > > Sent: Tuesday, February 16, 2021 11:59 AM
>
>     > > To: Joel M. Halpern <[e-mail]>; [e-mail]
>
>     > > 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:[e-mail]] Envoyé :
> mardi 16
>
>     > > > février 2021 17:44 À : BOUCADAIR Mohamed TGI/OLN
>
>     > > > <[e-mail]>; [e-mail] 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, [e-mail] wrote:
>
>     > > > > Re-,
>
>     > > > >
>
>     > > > > Please see inline.
>
>     > > > >
>
>     > > > > Cheers,
>
>     > > > > Med
>
>     > > > >
>
>     > > > >> -----Message d'origine-----
>
>     > > > >> De : Teas [mailto:[e-mail]] De la part de Joel
> M.
>
>     > > > >> Halpern
>
>     > > > >> Envoyé : mardi 16 février 2021 17:12 À : [e-mail] 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, [e-mail] 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
>
>     > > [e-mail]
>
>     > >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
>
>     > > __;!!N
>
>     > > Et6yMaO-gk!TrdpM67-tg4psF0dnG7jBV9LisKHxO_oCNxmQXrJhY-
>
>     > > B6MFchY8gBvvb8CNl408$
>
>     _______________________________________________
>
>     Teas mailing list
>
>     [e-mail]
>
>     https://www.ietf.org/mailman/listinfo/teas
>
> Juniper Business Use Only
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>