Subject: [Detnet] I-D Action: draft-ietf-detnet-dp-sol-03.txt

From: [email-masked]
Date: Mon, 05 Mar 2018 15:49:39 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Deterministic Networking WG of the IETF.

        Title           : DetNet Data Plane Encapsulation
        Authors         : Jouni Korhonen
                          Loa Andersson
                          Yuanlong Jiang
                          Norman Finn
                          Balázs Varga
                          Janos Farkas
                          Carlos J. Bernardos
                          Tal Mizrahi
                          Lou Berger
	Filename        : draft-ietf-detnet-dp-sol-03.txt
	Pages           : 45
	Date            : 2018-03-05

Abstract:
   This document specifies Deterministic Networking data plane
   encapsulation solutions.  The described data plane solutions can be
   applied over either IP or MPLS Packet Switched Networks.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-03
https://datatracker.ietf.org/doc/html/draft-ietf-detnet-dp-sol-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-dp-sol-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Balázs Varga A <[email-masked]>
Date: Tue, 13 Mar 2018 13:01:57 +0000

Hi,

Some thoughts for organizing the dataplane related discussions at IETF 101.
I see the following open points or confusing parts in draft-ietf-detnet-dp-sol-03. 
Please treat this list as a starting point ... And extend the list with your additions.
#1 Simplification
#2 TSN incompatibility
#3 Flow identification (Transit node)
#4 Other ... (placeholder for Your view)

## 1 ## What scenarios to cover? How to simplify our "problem space"?
Section 4. is very restrictive. It picks just 2 scenarios:
"Two different cases are covered: (i) the inter-connect
scenario, in which IEEE802.1 TSN is routed over a layer-3 network
(i.e., to enlarge the layer-2 domain), and (ii) native connectivity
between DetNet-aware end systems."

However as described in section 5, much more possible scenarios exists:
We have two types of end-systems (L2 and L3) [section5.1]. We have three types of end-system connection to the DetNet domain (directly, indirectly and integrated) [section5.2]. So we have much more scenarios than the two highlighted in section 4.

Furthermore we have two type of DetNet service (DN Bridging and DN Routing) [section 5.2.1 and 5.2.2]. 

For simplification we have the following options:
A, restrict the scenarios we cover
B, use a simplified (and sometimes sub-optimal) encapsulation 

Looking to the use-cases we have defined in draft-ietf-detnet-use-cases-14 and the requirement to solve the problem of legacy (DetNet unaware) end-systems optionA seems not to be a good choice. The only valid simplification is to restrict what type of end-systems can have a DetNet connection (L2-L2 and L3-L3).

SIMPLIFICATION-1: no application-level-proxy function inside the DetNet domain

For optionB we have a solution already described in dp-sol-03: tunneling (using additional MPLS or IP header). That works with all scenarios and allow connectivity between any end-system connection types. Further arguments for tunneling: 
- works with both Detnet service type (Bridging, Routing) 
- no other option for MPLS, 
- in case of IPv6 we have strong limitations: IPv6 extension headers can only be inserted by a node that initiated the IPv6 packet

SIMPLIFICATION-2: use tunneling for DetNet flows over the DetNet domain

We have one more possibility for simplification, namely in case of network scenarios, where the DetNet domain contains multiple technology segments (IP, MPLS) and all those segments are under the same administrative control. In such scenarios we need DetNet Inter-Working Function (DN-IWF) to allow end-2-end optimization of DetNet function design (where to place them). This is described in [Section 5.3]. 

For simplification we have the following options:
a, no use of DN-IWF
b, DN-IWF friendly data plane encapsulation (same format of DetNet attributes)

SIMPLIFICATION-3: no use of DN-IWF at technology borders

## 2 ## Incompatibility with TSN
Current sequence number format of dp-sol-03 (28 bit) is incompatible with TSN R-tag (16 bit). That would make a DN-IWF between TSN and IP/MPLS domains rather challenging. 

## 3 ## Flow identification on Transit nodes
Flow identification on Transit nodes should be a relevant selection criteria for the encapsulation discussions. We have three DetNet functions defined. 
1, Congestion protection and latency control: queuing, policing, shaping.
2, Explicit routes: TE
3, Service protection: PREF, IOD (in-order-delivery)
Transit nodes are expected to deal with 1 and 2, for which they have to be able to identify DetNet flows. Therefore the encapsulation should support flow recognition on Transit nodes as well. 

I think we already had (at least) some discussion on this, but it is not described / concluded in dp-sol-03. In case of MPLS transit nodes by default consider T-label(s). In case of IP UDP ports can help a lot and it may be worth to consider combining it with IPv6-flow-label as well.

## 4 ## Other???

Any comments, additions?

Cheers
Bala'zs

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 2018. március 6. 0:50
To: [email-masked]
Cc: [email-masked]
Subject: [Detnet] I-D Action: draft-ietf-detnet-dp-sol-03.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 13 Mar 2018 14:07:16 +0000

On 13/03/2018 13:01, Balázs Varga A wrote:
> I think we already had (at least) some discussion on this, but it is not described / concluded in dp-sol-03. In case of MPLS transit nodes by default consider T-label(s).

The natural way to do this in MPLS is to follow the MS-PW model, with 
each DetNet aware hop on the DetNet path being an S-PE. Where all nodes 
along the path are DetNet aware, the T-Label is PHPed and the top label 
is an S-Label. This makes for simple processing at each relay node. We 
get the option of leaving the T-Label in place when passing through a 
zone that is not DetNet aware, and encapsulating DetNet in DetNet when 
doing aggregation.

- Stewart