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

["Ogaki, Kenichi" <[e-mail]>]

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 <[e-mail]> On Behalf Of Joel M. Halpern
Sent: Tuesday, September 28, 2021 3:22 AM
To: [e-mail]; [e-mail]
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:
> 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
> 
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
> 

_______________________________________________
Teas mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/teas