Subject: [Teas-ns-dt] Traffic (address?) type information

From: Eric Gray <[email-masked]>
Date: Mon, 1 Jun 2020 15:53:48 +0000

On the question of possibly including the traffic types (IPv4, IPv6, Ethernet, unstructured) as an additional parameter of a Transport Slice service:

I guess I really need to ask this question, first:

Under what circumstances would this information not be explicitly known in advance by whatever higher-level entity it is that is making the request (via the TSC NBI) for a transport slice service?

If the higher-level entity does not know what the available capabilities are for making transport slice service requests (i.e. - what connection points are available, how those connection points are to be reached, what PDU format they are capable of handling, etc.), it is likely that this higher-level will need to make arbitrarily many requests before arriving at a combination that works (i.e. - the NBI interaction results in success), as it goes through an iterative "guessing" process.

It may be that there are multiple ways of doing this, but I believe it is likely to be the common case that traffic is expected to arrive at a transport slice service ingress with a specifically defined format and encapsulation that allows that ingress logical device to determine to which transport slice that traffic applies.  Further, I also believe it very likely that the payload (at least) of the received traffic is expected to be delivered via the transport slice service (exactly as is) to the transport slice service egress.

Are these assumption incorrect?

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 2 Jun 2020 01:20:31 +0000

I agree with Eric. TSC NBI and then service request for TS need to include ingress attributes to TS.

The purpose of TSC NBI is to allow outside of transport network(e.g, 3GPP system, customer) to control TS. Traffic comes from the outside actually, and therefore TSC NBI should include such ingress information. If not, TSC needs other interaction methods to understand it in addition to TSC NBI. It would lack usability of NBI...I think.

Tomo

---
************************************************************
Tomonobu Niwa
KDDI Corporation
TEL: +81-80-5074-9346
E-Mail: [email-masked]
************************************************************

-----Original Message-----
From: Teas-ns-dt <[email-masked]> On Behalf Of Eric Gray
Sent: Tuesday, June 2, 2020 12:54 AM
To: [email-masked]
Subject: [Teas-ns-dt] Traffic (address?) type information

If the higher-level entity does not know what the available capabilities are for making transport slice service requests (i.e. – what connection points are available, how those connection points are to be reached, what PDU format they are capable of handling, etc.), it is likely that this higher-level will need to make arbitrarily many requests before arriving at a combination that works (i.e. – the NBI interaction results in success), as it goes through an iterative “guessing” process.

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 1 Jun 2020 23:51:35 -0700

Eric,

The answer is as usual - it depends.
If the service provided is protocol aware and mapping is 1:1 (L3VPN/EVPN/VPLS/VPWS) then traffic type must be communicated and must match.
Example:
Routed service: L3VPN - CE-PE traffic type must match for a service to work, e.g IPv4 for IPv4 L3VPN and IPv6 for IPv6 L3VPN
Bridged service: L2VPN - same here, a match is mandatory for the service to work, hence we signal end point semantics.

However if the service is protocol unaware (typically would be a low(er) layer),  optical service doesn’t care about what kind of traffic it transports, L2VPN in general doesn’t care whether it is IPv4 or IPv6, etc

Cheers,
Jeff
On Jun 1, 2020, 8:59 AM -0700, Eric Gray <eric.gray=[email-masked]>, wrote:
> --
> Teas-ns-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt