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

[Jouni Korhonen <[e-mail]>]

Thanks for doing the writeup! My comments inline.


> On Mar 29, 2017, at 8:42 AM, Balázs Varga A <[e-mail]> 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
>  
> My interpretation on the Flow-ID and its scalability. Please comment.

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.
> 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.

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.


> 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. 

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
> 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

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. 

> - 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.

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).


>  
> 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.

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

- Jouni


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