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

[Carlos Jesús Bernardos Cano <[e-mail]>]

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:
> Works for me too - which?
> 
> 
> On March 29, 2017 11:35:34 AM Jouni Korhonen <jouni.korhonen@broadcom
> .com> 
> wrote:
> 
> > Tomorrow 8-9 would be ok?
> > 
> > 
> > --
> > Jouni Korhonen, Broadcom, Core Switching Group
> > [phone]
> > 
> > 
> > 
> > > On Mar 29, 2017, at 9:33 AM, Jiangyuanlong <jiangyuanlong@huawei.
> > > com> wrote:
> > > 
> > > I am available for both time slots.
> > > Cheers,
> > > Yuanlong
> > > 
> > > From: Detnet-dp-dt [mailto:[e-mail]] On
> > > Behalf Of Lou 
> > > Berger
> > > Sent: Thursday, March 30, 2017 12:20 AM
> > > To: Balázs Varga A; [e-mail]
> > > 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 <balazs.a.varga@eric
> > > sson.com> 
> > > 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.
> > > 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.
> > > 
> > > 
> > > _______________________________________________
> > > Detnet-dp-dt mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/detnet-dp-dt
> > > 
> > > _______________________________________________
> > > Detnet-dp-dt mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/detnet-dp-dt
> > 
> > _______________________________________________
> > Detnet-dp-dt mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/detnet-dp-dt
> 
> 
> _______________________________________________
> Detnet-dp-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt