Subject: [Detnet-dp-dt] Flow-ID vs. scalability (further thoughts to dinner discussion)

From: Balázs Varga A <[email-masked]>
Date: Wed, 29 Mar 2017 15:42:50 +0000

Hi All,
I have some thoughts below regarding the Flow-ID discussion at yesterday dinner.
Could we gain that we are at the same location and have a side meeting
today (afternoon or evening) or tomorrow (afternoon)?
Cheers
Bala'zs

My interpretation on the Flow-ID and its scalability. Please comment.
Let's list the end-systems together with their used encapsulation.
Starting with how it works with a TSN host and a TSN domain:
- TSN (L2) host: host is not IP aware, flow is directly encapsulated in Ethernet.
A StreamID is used constructed by "src-MAC + UniqueID" as per IEEE:
"The StreamID includes the following subcomponents:
- A 48-bit MAC Address associated with the Talker sourcing the
stream to the bridged network.
- A 16-bit unsigned integer value, Unique ID, used to distinguish
among multiple streams sourced by the same Talker."
The UniqeID is not traveling with the Ethernet frame, but the multicast dst-MAC
can be used to find out the UniqueID. So the uniqueness of StreamID achieved,
it includes the source identification and scales well.

We can do something similarly for IP hosts and a DetNet domain:
- DetNet aware IP host: flow is encapsulated in "PW over IP". Seq.num and
Flow-ID added by the host. So if we would like to have an analogy with TSN, the
flow can be unambiguously identified by the "src-IP + Flow-ID". That would scale
and is similar to TSN.

However the difference is that in case of TSN we have just a single forwarding
paradigm: Ethernet bridging. The src-MAC and dst-MAC are visible for all
intermediate bridges, so the flow can be identified without any difficulties.

In the "dp-sol-draft" we have defined the Flow-ID somewhat different to avoid
DPI (i.e., checking src/dst MAC/IP addresses) during transport to recognize the flows.
The Flow-ID is placed in the PW encapsulation header, so easy to find it and use it
whatever DetNet domain (IP or MPLS) you are crossing.

In case of DetNet we have two forwarding paradigm: (i) IP routing and (ii) MPLS
switching. Therefore checking the "src-IP + Flow-ID" is somewhat more complicated
for intermediate nodes. For example, in case of MPLS the "src-IP" is in the
encapsulation payload, so we need DPI.
Furthermore if we interconnect TSN End-systems over DetNet there is no "src-IP".
So we have solved the difficulties with "src-IP" by defining the "Flow-ID" as to be
unique with all the concerns regarding scalability.

So what could be a better approach if we intend to solve scalability. We need two IDs.
(1) one identifying the source of the flow and (2) an other one to distinguish multiple
flows sent by the same source. For the second one we already have the Flow-ID.
What could be selected for the first one?
- src-MAC: not visible in many cases (e.g., source behind a routed domain, etc.)
- src-IP: may not present (e.g., in case of TSN host)
- PW-label: it is always present.
- new field: to be defined in the encapsulation
Making the PW-label source specific and constant during transport sounds similar as
segment routing, however here we have to allocate label space for hosts and not
per network nodes. So it may hurt scalability again.

What about the new field? And we do not have to define a pretty new one just
extend and add structure to the already defined "DetNet flow identity word".
- 16 bit Flow-ID: distinguish flows per source (same size as for TSN ! )
- 46 bit Src-ID: distinguish the source
- 1 bit: direction bit
- 1 bit: reserved
So we are adding 64 bit instead of 32 in order to ensure scalability ...
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |r|D|                           46 bit src identity             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      src identity cont.       |     16 bit flow identity      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In the src-ID you can map a unique ID for sources. Some possible examples:
- L2 host: src-MAC without BC-bit and Local-administration-bit (48-2=46 bits)
- L3 (IPv4) host: src-IP address + zeros to fill up the field
- L3 (IPv6) host: IPv6 host have 128 bit src-IP, so we may need a preconfigured
ID for the IPv6 host used for DetNet purposes.

Thanks if You have read so far ...

Note: For the scenario with DetNet unaware IP host(s): host sends flow needing
DetNet treatment. First DA-T-PE has to create the PW encapsulation (adding
seq.num and Flow-ID). It is a task of the DA-T-PE to create the field values as
specified above.

---

From: Lou Berger <[email-masked]>
Date: Wed, 29 Mar 2017 11:19:41 -0500

Great idea.  I can get a room assigned. How about 2pm today or first thing 
tomorrow -8 or 9?

Lou

On March 29, 2017 10:43:32 AM Balázs Varga A <[email-masked]> 
wrote:

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

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 29 Mar 2017 09:22:05 -0700

Thanks for doing the writeup! My comments inline.

> On Mar 29, 2017, at 8:42 AM, Balázs Varga A <[email-masked]> wrote:
> 
> Hi All, 
> Bala’zs

My first reaction to this is that we need to scope the scale. Flow-ID us unique within what? It is not internet but a lot smaller scope. So far we have mostly been circulating around a network scoped by a label stack. That is max 20 bits of “scale” independent of the depth of the stack. No one seemed to have an issue with this.

> Let’s list the end-systems together with their used encapsulation.
> A StreamID is used constructed by “src-MAC + UniqueID” as per IEEE:
> “The StreamID includes the following subcomponents:
> among multiple streams sourced by the same Talker.”
> - DetNet aware IP host: flow is encapsulated in “PW over IP”. Seq.num and
> flow can be unambiguously identified by the “src-IP + Flow-ID”. That would scale
> and is similar to TSN. 
>  
> In the “dp-sol-draft” we have defined the Flow-ID somewhat different to avoid

I am very pro for unified flow identification mechanism that is the same from the processing and on-wire format point of view independent of the PSN. That’s a great feature.

> switching. Therefore checking the “src-IP + Flow-ID” is somewhat more complicated
> for intermediate nodes. For example, in case of MPLS the “src-IP” is in the

It is not just about DPI. When the packet goes through the hardware, remembering something that you already “saw and processed” is not for free.

> Furthermore if we interconnect TSN End-systems over DetNet there is no “src-IP”.
> So we have solved the difficulties with “src-IP” by defining the “Flow-ID” as to be
> extend and add structure to the already defined “DetNet flow identity word”.
> So we are adding 64 bit instead of 32 in order to ensure scalability …
>       0                   1                   2                   3

A lot of IPv4 networks are using RFC1918 address space. You take two packets from different networks and the likelihood of a collision is great. 

> ID for the IPv6 host used for DetNet purposes.

Or part of the prefix or use 62 bits of the IID (most host implementations randomize the IID these days anyway).

>  
> Thanks if You have read so far …

So essentially we just double the id space.. and add helping the uniqueness by adding the non-uniqueness guaranteeing source identity. Given that just having 62 bit random might be equally good (see the precoding work on IPv6 randomized IIDs or CGAs or Stable and Opaque IIDs).

> seq.num and Flow-ID). It is a task of the DA-T-PE to create the field values as

I think this was already stated in the current draft for DA-T-PE functions - for the current CW & flow-id.

- Jouni

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 29 Mar 2017 16:33:39 +0000

I am available for both time slots.
Cheers,
Yuanlong

From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, March 30, 2017 12:20 AM
To: Balázs Varga A; [email-masked]
Subject: Re: [Detnet-dp-dt] Flow-ID vs. scalability (further thoughts to dinner discussion)

Great idea.  I can get a room assigned. How about 2pm today or first thing tomorrow -8 or 9?

Lou

On March 29, 2017 10:43:32 AM Balázs Varga A <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,
I have some thoughts below regarding the Flow-ID discussion at yesterday dinner.
Could we gain that we are at the same location and have a side meeting
today (afternoon or evening) or tomorrow (afternoon)?
Cheers
Bala’zs

_______________________________________________
Detnet-dp-dt mailing list
[email-masked]<mailto:Detnet-dp-dt%40ietf.org>
https://www.ietf.org/mailman/listinfo/detnet-dp-dt

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 29 Mar 2017 09:34:55 -0700

Tomorrow 8-9 would be ok?

-- 
Jouni Korhonen, Broadcom, Core Switching Group
+1-408-391-7160

> On Mar 29, 2017, at 9:33 AM, Jiangyuanlong <[email-masked]> wrote:
> 
> On March 29, 2017 10:43:32 AM Balázs Varga A <[email-masked]> wrote:
> 
> Hi All,

---

From: Balázs Varga A <[email-masked]>
Date: Wed, 29 Mar 2017 16:36:19 +0000

Excellent. I would prefer today 2:00pm. Cheers Bala’zs

From: Lou Berger [mailto:[email-masked]]
Sent: Wednesday, March 29, 2017 11:20 AM
To: Balázs Varga A <[email-masked]>; [email-masked]
Subject: Re: [Detnet-dp-dt] Flow-ID vs. scalability (further thoughts to dinner discussion)

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 29 Mar 2017 13:23:37 -0500

It's too late to schedule a room. Let's meet outside veyvey 4 and see if 
it's open...
Lou

On March 29, 2017 11:37:27 AM Balázs Varga A <[email-masked]> 
wrote:

> On March 29, 2017 10:43:32 AM Balázs Varga A 
> <[email-masked]<mailto:[email-masked]>> wrote:
> Hi All,

---

From: Lou Berger <[email-masked]>
Date: Wed, 29 Mar 2017 13:31:16 -0500

Works for me too - which?

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 30 Mar 2017 17:57:11 +0200

Sorry guys, I didn't see these e-mails in time. In case you are
planning to meet later today or tomorrow, please let me know.

Thanks,

Carlos

On Wed, 2017-03-29 at 13:31 -0500, Lou Berger wrote:
> > > From: Detnet-dp-dt [mailto:[email-masked]] On
> > > Behalf Of Lou 
> > > Berger
> > > Subject: Re: [Detnet-dp-dt] Flow-ID vs. scalability (further
> > > thoughts to 
> > > dinner discussion)
> > > 
> > > I have some thoughts below regarding the Flow-ID discussion at
> > > yesterday 
> > > dinner.
> > > - TSN (L2) host: host is not IP aware, flow is directly
> > > encapsulated in 
> > > Ethernet.
> > > flow can be unambiguously identified by the “src-IP + Flow-ID”.
> > > That would 
> > > scale
> > > and is similar to TSN.
> > > 
> > > DPI (i.e., checking src/dst MAC/IP addresses) during transport to
> > > recognize 
> > > the flows.
> > > The Flow-ID is placed in the PW encapsulation header, so easy to
> > > find it 
> > > and use it
> > > switching. Therefore checking the “src-IP + Flow-ID” is somewhat
> > > more 
> > > complicated
> > > Furthermore if we interconnect TSN End-systems over DetNet there
> > > is no 
> > > “src-IP”.
> > > So we have solved the difficulties with “src-IP” by defining the
> > > “Flow-ID” 
> > > as to be
> > > So what could be a better approach if we intend to solve
> > > scalability. We 
> > > need two IDs.
> > > (1) one identifying the source of the flow and (2) an other one
> > > to 
> > > distinguish multiple
> > > - src-MAC: not visible in many cases (e.g., source behind a
> > > routed domain, 
> > > etc.)
> > > Making the PW-label source specific and constant during transport
> > > sounds 
> > > similar as
> > >       0                   1                   2                  
> > >  3