Subject: [Teas] Network slicing framework : Issue #5: Endpoints

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 27 Sep 2021 19:07:13 +0100

Hi (again),

On my slides today I presented my proposed approach for documenting
endpoints.

This is currently covered in the current draft in Section 4.2 using some
original text from the parent documents, and it needs some work.

Here is a proposal to update Section 4.2. Note that Section 5.4 is built on
some of this: I will propose an update to that in a subsequent issue.

A few minor things before we get to section 4.2

1.	The text in a number of places uses the terms CE and PE. I plan to
change these to "slice consumer edge" and "slice provider edge" because CE
and PE imply specific hardware in a classical router environment, where what
we are describing could include software components and virtual functions
etc. (It will still be useful to use CE and PE in examples when explaining
endpoints, but that needs text to say "this is just an example for
clarity".)

2. There is currently a Section 4.2.1 that reads...

|4.2.1.  IETF Network Slice Connectivity Types

|

|  The IETF Network Slice connection types can be point to point (P2P),

|  point-to-multipoint (P2MP), multipoint-to-point (MP2P), or

|  multipoint-to-multipoint (MP2MP).  They will requested by the higher

|  level operation system.

I believe that this is an orphaned section. It has nothing to do with
Section 4.2, and it is a duplication of material in Section 3.2. I plan to
delete it.

And now, here is my proposed replacement for Section 4.2...

===

4.2.  IETF Network Slice Endpoints

   As noted in Section 3.1, an IETF Network Slice is a logical network

   topology connecting a number of endpoints.  Section 3.2 goes on to

   describe how the IETF Network Slice service is composed of a set of

   one or more connection matrices that describe connectivity between

   the endpoints across the underlying network.  The connectivity types

   are: point-to-point, point-to-multipoint, multipoint-to-point, or

   multipoint-to-multipoint.

   The characteristics of IETF Network Slice Endpoints (NSEs) are as

   follows:

   o  IETF NSEs are conceptual points of connection to an IETF Network

      Slice.  As such, they serve as the IETF Network Slice ingress/

      egress points.

   o  Each NSE maps to a device, application, or a network 

      function, such as (but not limited to): routers, switches,

      firewalls, WAN, 4G/5G RAN nodes, 4G/5G Core nodes, application 

      accelerators, Deep Packet Inspection (DPI) engines, server load

      balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header 

      enrichment functions, and TCP optimizers.

   o  An NSE is identified by a unique identifier in the context of an

      IETF Network Slice customer.

   o  Each NSE is associated with a set of network-scope identifiers 

      such as IP addresses, encapsulation-specific identifiers (e.g.,

      VLAN tag, MPLS Label), interface/port numbers, node ID, etc.

   o  A combination of NSE identifier and NSE network-scope identifiers

      defines an NSE in the context of the NSC.

   o  The NSC will use the NSE network-scope identifiers as part of the

      process of realizing the IETF Network Slice.

   o  IETF NSEs are mapped to endpoints of services/tunnels/paths within

      the IETF Network Slice during its initialization and realization.

   NSEs may be in the scope of the consumer (network slice consumer edge)

   or the provider (network slice provider edge) such as, for example, in

   router networks where customer edge (CE) and provider edge (PE)

   devices fill those roles.

   For a given IETF network slice service, the IETF Network Slice 

   customer and provider agree where the endpoint (i.e., the service

   demarcation point) is located.  This determines what resources at the

   edge of the network form part of the IETF Network Slice and are 

   subject to the set of SLOs and SLEs for a specific endpoint.

   Figure 1 shows different potential scopes of an IETF Network Slice

   that are consistent with the different endpoint positions.  For the

   purpose of example and without loss of generality, the figure shows

   CE and PE nodes connected by access circuits (ACs).  Notes after

   the figure give some explanations.

          |<---------------------- (1) ---------------------->|

          |                                                   |

          | |<-------------------- (2) -------------------->| |

          | |                                               | |

          | |        |<----------- (3) ----------->|        | |

          | |        |                             |        | |

          | |        |  |<-------- (4) -------->|  |        | |

          | |        |  |                       |  |        | |

          V V   AC   V  V                       V  V   AC   V V

      +-----+   |    +-----+                 +-----+    |   +-----+

      |     |--------|     |                 |     |--------|     |

      | CE1 |   |    | PE1 |. . . . . . . . .| PE2 |    |   | CE2 |

      |     |--------|     |                 |     |--------|     |

      +-----+   |    +-----+                 +-----+    |   +-----+

         ^              ^                       ^              ^

         |              |                       |              |

         |              |                       |              |

      Customer       Provider                Provider       Customer

      Edge 1         Edge 1                  Edge 2         Edge 2

          Figure 1 : Positioning IETF Network Slice Endpoints 

   Explanatory notes for Figure 1 are as follows:

   (1) If the CE is operated by the IETF Network Slice service provider,

       then the edge of the IETF Network Slice may be within the CE.  In

       this case the slicing process may utilize resources from within 

       the CE such as buffers and queues on the outgoing interfaces.

   (2) The IETF Network Slice may be extended as far as the CE, to 

       include the AC, but not to include any part of the CE.  In this

       case, the CE may be operated by the customer or the provider.

       Slicing the resources on the AC may require the use of traffic

       tagging (such as through Ethernet VLAN tags) or may require 

       traffic policing at the AC link ends.

   (3) In another model, the endpoints of the IETF Network Slice are the

       customer-facing ports on the PEs.  This case can be managed in a

       way that is similar to a port-based VPN: each port (AC) or 

       virtual port (e.g., VLAN tag) identifies the IETF Network Slice

       and maps to an IETF Network Slice endpoint.

   (4) Finally, the endpoint of the IETF Network Slice may be within the

       PE.  In this mode, the PE classifies the traffic coming from the 

       AC according to information (such as the source and destination

       IP addresses, payload protocol and port numbers, etc.) in order

       to place it onto an IETF Network Slice.

   Note that Figure 1 shows a symmetrical positioning of endpoints, but

   this decision can be taken on a per-endpoint basis through agreement

   between the customer and provider.

   In practice, it may be necessary to map traffic not only onto an IETF

   Network Slice, but also onto a specific connectivity matrix if the 

   IETF Network Slice supports more than one connectivity matrix with a

   source at the specific endpoint.  The mechanism used will be one of

   the mechanisms described above, dependent on how the endpoint is

   realized.

===

As usual, comments are very welcome. I'll let it sit for a bit, and will
post when it seems un-disagreed. 

Remember: a posted version is not unchangeable, and comments are still
encouraged.

Best,

Adrian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Sep 2021 14:22:05 -0400

That works for me.  The notes at the end, after figure 1, are critical 
for this being coherent and consistent.

Yours,
Joel

On 9/27/2021 2:07 PM, Adrian Farrel wrote:
> Here is a proposal to update Section 4.2. Note that Section 5.4 is built 
> on some of this: I will propose an update to that in a subsequent issue.
> 
>     change these to “slice consumer edge” and “slice provider edge”
>     because CE and PE imply specific hardware in a classical router
>     environment, where what we are describing could include software
>     components and virtual functions etc. (It will still be useful to
>     use CE and PE in examples when explaining endpoints, but that needs
>     text to say “this is just an example for clarity”.)
> 
> Section 4.2, and it is a duplication of material in Section 3.2. I plan 
> to delete it.
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Tue, 28 Sep 2021 08:47:41 +0000

Hi Adrian,

1) Why do you use the term *consumer*, not customer defined in Sec. 2.1?

2) Is it reasonable that a flow specified by 5tuple is included as one of networkscope-identifiers?

3) This is not objection, but just my impression in terms of (2) and (3) in Figure 1.
It should depend on each operator, but from my experience, the demarcation device is placed between L3VPN CE and PE routers usually at the customer premises, the customer owes the responsibility from the customer facing port of that device. In IX service case, the customer must prepares their attachment circuit to meet-me patch-panel port inside our central office to connect IX switch. Anyway, the demarcation point is somewhere on the AC in these cases.
The text is better to imply this.

Thanks,
Kenichi

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Joel M. Halpern
Sent: Tuesday, September 28, 2021 3:22 AM
To: [email-masked]; [email-masked]
Subject: Re: [Teas] Network slicing framework : Issue #5: Endpoints

That works for me.  The notes at the end, after figure 1, are critical for this being coherent and consistent.

Yours,
Joel

On 9/27/2021 2:07 PM, Adrian Farrel wrote:
> This is currently covered in the current draft in Section 4.2 using 
> some original text from the parent documents, and it needs some work.
> 
> Here is a proposal to update Section 4.2. Note that Section 5.4 is 
> built on some of this: I will propose an update to that in a subsequent issue.
> 
> |  The IETF Network Slice connection types can be point to point 
> |(P2P),
> 
> |  multipoint-to-multipoint (MP2MP).  They will requested by the 
> |higher
> 
> Section 4.2, and it is a duplication of material in Section 3.2. I 
> plan to delete it.
> 
> As usual, comments are very welcome. I'll let it sit for a bit, and 
> will post when it seems un-disagreed.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 Sep 2021 10:37:17 +0100

Hi Kenichi,

> 1) Why do you use the term *consumer*, not customer defined in Sec. 2.1?

Oh, I screwed up big time.

Sorry everyone.

"CUSTOMER" 

> 2) Is it reasonable that a flow specified by 5tuple is included as one of networkscope-identifiers?

Yes. If you look at the endpoint figure, I think this is consistent with the 4th option - endpoint is within the PE. That is, flow classification is performed to place the traffic onto the correct connectivity matrix.

> It should depend on each operator, but from my experience, the demarcation device is
> placed between L3VPN CE and PE routers usually at the customer premises, the customer
> owes the responsibility from the customer facing port of that device. In IX service case,
> the customer must prepares their attachment circuit to meet-me patch-panel port inside
> our central office to connect IX switch. Anyway, the demarcation point is somewhere on
> the AC in these cases.
>

Absolutely, the choice of all of the options is dependent on the operator (although also dependent on what their vendor has implemented!)

I think that you are right. In many cases, following the port-based VPN model is convenient and clear. In other cases, of course, the service may be being provided between different subdivisions of an organisation (e.g., IP slice to support 5G slice) or completely internal to an organisation (so that the consumer and provider parts are all buried inside one device).

I will try to make sure the text is clear on this point (but happy to receive specific suggestions)

Best,
Adrian

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Joel M. Halpern
Sent: Tuesday, September 28, 2021 3:22 AM
To: [email-masked]; [email-masked]
Subject: Re: [Teas] Network slicing framework : Issue #5: Endpoints

Yours,
Joel

---

From: <[email-masked]>
Date: Wed, 29 Sep 2021 09:34:44 +0000

Hi Adrian,

Thank you for your effort.

Please see inline.

Cheers,
Med

De : Teas <[email-masked]> De la part de Adrian Farrel
Envoyé : lundi 27 septembre 2021 20:07
À : [email-masked]
Objet : [Teas] Network slicing framework : Issue #5: Endpoints

Hi (again),

On my slides today I presented my proposed approach for documenting endpoints.

This is currently covered in the current draft in Section 4.2 using some original text from the parent documents, and it needs some work.

Here is a proposal to update Section 4.2. Note that Section 5.4 is built on some of this: I will propose an update to that in a subsequent issue.

  1.  The text in a number of places uses the terms CE and PE. I plan to change these to "slice consumer edge" and "slice provider edge" because CE and PE imply specific hardware in a classical router environment, where what we are describing could include software components and virtual functions etc. (It will still be useful to use CE and PE in examples when explaining endpoints, but that needs text to say "this is just an example for clarity".)

[Med] Not sure this is worth to be done:

* CE and PE stand also for Customer Edge and Provider Edge, not only Customer/Provider Equipment.

* when dealing with a customer-provider interaction, a physical demarcation is likely to needed to delimit the responsibilities.

* Prefixing all the terms with "slice" does not bring much value other than creating more and more acronyms.

* I prefer to have a sentence to explain that these entities are functional/logical entities + do not make any assumption where they are provided using hardware, virtualization, etc.

|

I believe that this is an orphaned section. It has nothing to do with Section 4.2, and it is a duplication of material in Section 3.2. I plan to delete it.

===

   one or more connection matrices

[Med] s/connection matrices/connectivity matrices

that describe connectivity between

   the endpoints across the underlying network

[Med] I suggest: s/between the endpoints across/that involve the endpoints. The reasoning for the proposal is to cover cases where the connectivity matrices include an Internet gateway or a node that is not a customer endpoint.

.  The connectivity types

   follows:

      egress points.

[Med] I guess this is about customer endpoints as the text states "connection to an ..". Otherwise, an endpoint ** is part ** of the network slice (PE, SF, for example).

[Med] s/network-scope/provider-scope.

[Med] The previous two bullets are examples to realize this one. I would place them as sub-bullets of this one.

          |                                                   |

          | |                                               | |

          | |        |                             |        | |

          | |        |  |                       |  |        | |

          V V   AC   V  V                       V  V   AC   V V

         ^              ^                       ^              ^

         |              |                       |              |

         |              |                       |              |

   realized.

===

As usual, comments are very welcome. I'll let it sit for a bit, and will post when it seems un-disagreed.

Remember: a posted version is not unchangeable, and comments are still encouraged.

Best,

Adrian

_________________________________________________________________________________________________________________________

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: "Adrian Farrel" <[email-masked]>
Date: Wed, 29 Sep 2021 11:35:26 +0100

Thanks, Med, useful.

In line, 

Adrian.

* CE and PE stand also for Customer Edge and Provider Edge, not only
Customer/Provider Equipment. 

* when dealing with a customer-provider interaction, a physical demarcation
is likely to needed to delimit the responsibilities. 

* Prefixing all the terms with "slice" does not bring much value other than
creating more and more acronyms. 

* I prefer to have a sentence to explain that these entities are
functional/logical entities + do not make any assumption where they are
provided using hardware, virtualization, etc. 

[AF] OK. That is good to hear, because I think I was trying to be sensitive
to you in  particular (you're the person who helped make it clear that
endpoints might not just be equipment).

But see below for the discussion of nodes that are not customer endpoints.

[snip]

|

 

===

[AF] ack

[Med] I suggest: s/between the endpoints across/that involve the endpoints./
The reasoning for the proposal is to cover cases where the connectivity
matrices include an Internet gateway or a node that is not a customer
endpoint.  

[AF] I don't think I understand your point. To say that connectivity
"involves" endpoints seems ambiguous to me (can an endpoint be a transit
node on a connection?). I think the connectivity is between endpoints.

The term "customer endpoint" should have the same meaning as "service
endpoint" in our context. That is, an endpoint is a service delivery point.

Actually, this is part of the reason to not use CE/PE, but a new term that
is intended to more clearly include any node that is a service delivery
point.

.  The connectivity types

   follows:

      egress points.

[Med] I guess this is about customer endpoints as the text states
"connection to an ..". Otherwise, an endpoint ** is part ** of the network
slice (PE, SF, for example). 

[AF] You are using "customer endpoint" again, which is your term. I'm not
sure that saying the endpoint is part of the slice (or not) is helpful. Is
the surface of the ocean part of the ocean?

[AF] OK

[Med] The previous two bullets are examples to realize this one. I would
place them as sub-bullets of this one.  

[AF] OK

          |                                                   |

          | |                                               | |

          | |        |                             |        | |

          | |        |  |                       |  |        | |

          V V   AC   V  V                       V  V   AC   V V

         ^              ^                       ^              ^

         |              |                       |              |

         |              |                       |              |

   realized.

===

Best,

Adrian

____________________________________________________________________________
_____________________________________________
 
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: <[email-masked]>
Date: Wed, 29 Sep 2021 11:14:50 +0000

Re-,

Thanks, Adrian,

Please see inline.

Cheers,
Med

Orange Restricted
De : Adrian Farrel <[email-masked]>
Envoyé : mercredi 29 septembre 2021 12:35
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; [email-masked]
Objet : RE: [Teas] Network slicing framework : Issue #5: Endpoints

Thanks, Med, useful.

In line,
Adrian.

[Med] I suggest: s/between the endpoints across/that involve the endpoints./ The reasoning for the proposal is to cover cases where the connectivity matrices include an Internet gateway or a node that is not a customer endpoint.

[AF] I don't think I understand your point. To say that connectivity "involves" endpoints seems ambiguous to me (can an endpoint be a transit node on a connection?). I think the connectivity is between endpoints.

[Med] Not necessary because we may consider wildcards (e.g., CE_1 to ANY). Consider, for example, a slice that is designed to provide global connectivity to a CE (Internet, typically). The scope of the connectivity service here isn't delimited by two endpoints even if the network service realization will involve some specific endpoints (e.g., Internet Gateways or service functions). Another example of a slice that does not include two endpoints may be a slice service that is optimized sub-x ms DNS traffic. The guarantees won't be expressed in term of DNS resolution time between a CE and a DNS server, as ANY DNS resolution from that CE. And so on.

The term "customer endpoint" should have the same meaning as "service endpoint" in our context. That is, an endpoint is a service delivery point.

Actually, this is part of the reason to not use CE/PE, but a new term that is intended to more clearly include any node that is a service delivery point.

.  The connectivity types

   follows:

      egress points.

[AF] You are using "customer endpoint" again, which is your term. I'm not sure that saying the endpoint is part of the slice (or not) is helpful. Is the surface of the ocean part of the ocean?

[Med] Maybe because I'm approaching this from a service perspective, I'm sensitive to this distinction between "being part" of "connect to". I think we can gain some clarity by having this bullet positioned once we introduce the distinction between CE and PE.