Re: [Detnet] IPv6 encapsulation in dataplane doc

[Balázs Varga A <[e-mail]>]

Hi Pascal,

I have a lot of sympathy on your view.
- OK: "DetNet would provide its own sequencing based on reception order at ingress edge."
- OK: "ingress edge may be a NIC card"
- OK: "avoid DPI"

However I have some questions for clarification on your final conclusions:
- Why no seq.num in IP? That would mean no PREF, no IOD function within the DetNet domain
Which is an IP PSN.
- What would be the gain from a "L4 transport designed to provide PREF, IOD, FEC, ... "?
I mean that would be a duplicate, as in the DetNet network You would have the same function.
Checking L4 within the DetNet domain would require DPI, what I guess we do not want.
- I am also somewhat confused by your WiFi example. I mean in TSN/DetNet scenarios 
end-systems are always assumed to be in sync with their controller(s). So I do not agree with
this statement: "Existing industrial devices can claim a rough need for a given rate but were 
not necessarily designed to provide guarantees for burstiness in DetNet terms." 

Thanks & Cheers
Bala'zs

-----Original Message-----
From: detnet [mailto:[e-mail]] On Behalf Of Pascal Thubert (pthubert)
Sent: 2018. február 12. 11:30
To: Jouni <[e-mail]>; Lou Berger <[e-mail]>
Cc: [e-mail]
Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc

Hello Jouni and Lou:

Just to make sure we are on the same line:

- IPvX (==v4/v6) would signal the flow implicitly - derived from the tuples- but not the source sequencing. No need to change IP.

- DetNet may provide PREF/IOD from the edge ingress. DetNet would provide its own sequencing based on reception order at ingress edge.

- The  ingress edge may be a NIC card in the originating node. It would be operating below IPvX and possibly equipped with 2 Ethernet ports and capable of PREF.

- Anything above IP is beyond charter. A upper layer sequence may be visible in the L4-transport or at the application layer but DetNet will not look for it. A snooping edge device doing DPI may dig in the packet and find information for packet identification and ordering, for a particular application, and that is beyond the interests of the WG.

- A L4 transport may be designed to provide PREF, IOD, FEC (network coding) and whatever else needed. This would be done in TSV Area with DetNet's blessing.

Do we agree?

Pascal

-----Original Message-----
From: Jouni [mailto:[e-mail]] 
Sent: dimanche 11 février 2018 22:43
To: Lou Berger <[e-mail]>
Cc: Pascal Thubert (pthubert) <[e-mail]>; [e-mail]
Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc



>>>> * End systems cannot participate to DetNet service layer packet 
>>>> elimination & duplication business. If they still do e.g. using 
>>>> DetNet DstOpt that is separate from subnet/transport layer provided service.
>>> 
>>> True, end station participation in PREF wouldn't be possible in this 
>>> simplified approach for IP, but the end stations *could* still 
>>> participate in the equivalent function provided by a sub-net layer 
>>> such as TSN. So end to end detnet traffic protection is not 
>>> possible, but it doesn't mean it can't be provided by lower network 
>>> layers.  The gain here is a simplified and unified IP solution and 
>>> simplified host processing/support, albeit with a loss of one of the 
>>> three end to end detnet service attributes.
>> 
>> Yes, that's true (as I already clarified in my latest mail to Pascal).
>> 
> 
> yes.  It's good for all to remember that DetNet is just as much (if 
> not
> more) about supporting explicit routes with congestion protection and 
> latency control....

Indeed..

>>>> * Different subnet/transport layer segments in the DetNet domain 
>>>> are likely to use their own sequencing and duplication & 
>>>> elimination solutions. I am not sure how independent those will be 
>>>> e.g., is the sequence numbering unified across or only per segment. 
>>>> The former is not IMO easy and the latter easily reduces to single 
>>>> points between segments to handle number book keeping properly.
>>> 
>>> Agreed.  The question for the WG is this a reasonable compromise in 
>>> order to in our *initial* solution defined by the WG.  -- Nothing 
>>> says we can't come back and improve on this in the future, but it 
>>> will allow us to get *something* useful defined with less complexity.
>> 
>> I would first specify the required steps that make IP as-is work within one subnet/transport layer segment. That should be an achievable goal with a limitation of e.g. a single interconnection point between subnet/transport layer segments of different types/solutions. 
>> 
> 
> sure. as long as one of the 'attached stations' can be a router.

Yes. That's the plan at least from my side.

- Juoni


> 
>> After that look into solving multiple interconnection points.. and there the L4 path that Pascal mentioned or that IPv6 DetNet DstOpt of mine could be way forward.
>> 
> 
> yes, this would be good follow on work...
> 
> Cheers,
> Lou
>> - Jouni
>> 
>> 
>>> 
>>> 
>>>> 
>>>> Regardless the above I am keen to explore this alternative approach..
>>>> 
>>> 
>>> Great - look forward to hear the results!
>>> Lou
>>> 
>>>> 
>>>> -          Jouni
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> *From:* detnet [mailto:[e-mail]] *On Behalf Of *Lou 
>>>> Berger
>>>> *Sent:* Wednesday, February 7, 2018 17:00 PM
>>>> *To:* Pascal Thubert (pthubert) <[e-mail]>; 
>>>> [e-mail]
>>>> *Subject:* Re: [Detnet] IPv6 encapsulation in dataplane doc
>>>> 
>>>> 
>>>> 
>>>> Pascal/all,
>>>> 
>>>> At the last interim a proposal was made to simplify IP processing, 
>>>> at least for the initial detnet solution, by leaving PREF to the 
>>>> subnet/transport layers (i.e., TSN and MPLS) and providing DetNet 
>>>> flow identification based on typical IP 5-tuple perhaps + dscp. 
>>>> This approach has several benefits beyond simplification, notably 
>>>> it will work for both ipv4 and IPv6, and doesn't require any 
>>>> modification to encapsulation / formats.
>>>> 
>>>> It would be really valuable to get feedback from the whole working 
>>>> group if this simplification is acceptable or has unacceptable limitations.
>>>> 
>>>> Lou
>>>> 
>>>> On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)"
>>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>>   Dear all
>>>> 
>>>> 
>>>> 
>>>>   This is about the IPv6 encapsulation and more precisely
>>>> 
>>>> 
>>>> 
>>>>                           Therefore, if a DetNet-aware end system 
>>>> only
>>>> 
>>>>      inserted the DetNet Destination Option into the IPv6 but e.g., 
>>>> a
>>>> 
>>>>      DetNet Edge node is configured to enforce an explicit route 
>>>> for the
>>>> 
>>>>      IPv6 packet using a source routing header, then it has no 
>>>> other
>>>> 
>>>>      possibility than add an outer tunneling IPv6 header with 
>>>> required
>>>> 
>>>>      extension headers in it.  The processing of IPv6 packets in a 
>>>> DetNet
>>>> 
>>>>      Edge node is discussed further in Section 6.4.1
>>>>   <https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-01#section-6.4.1>.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>   With the current spec, a source sends a DetNet packet as
>>>> 
>>>> 
>>>> 
>>>>                       +---------------------------------+
>>>> 
>>>>                       |                                 |
>>>> 
>>>>                       |           DetNet Flow           |
>>>> 
>>>>                       |             Payload             |
>>>> 
>>>>                       |                                 |
>>>> 
>>>>                       /---------------------------------\
>>>> 
>>>>                       H   Optional DetNet DstOpt Hdr    H
>>>> 
>>>>                       \---------------------------------/
>>>> 
>>>>                       |          IPv6 header            |
>>>> 
>>>>                       |     (with set Flow label)       |
>>>> 
>>>>                       +---------------------------------+
>>>> 
>>>> 
>>>> 
>>>>   And then the ingress node needs to re-encapsulate as
>>>> 
>>>> 
>>>> 
>>>>                       +---------------------------------+
>>>> 
>>>>                       |                                 |
>>>> 
>>>>                       |           DetNet Flow           |
>>>> 
>>>>                       |             Payload             |
>>>> 
>>>>                      |                                 |
>>>> 
>>>>                       /---------------------------------\
>>>> 
>>>>                       H        DetNet DstOpt Hdr        H
>>>> 
>>>>                       \---------------------------------/
>>>> 
>>>>                       |          IPv6 header            |
>>>> 
>>>>                       |     (with set Flow label)       |
>>>> 
>>>>                       +=================================+
>>>> 
>>>>                       |          Routing header         |
>>>> 
>>>>                       /---------------------------------\
>>>> 
>>>>                       H        DetNet DstOpt Hdr        H
>>>> 
>>>>                       \---------------------------------/
>>>> 
>>>>                       |          IPv6 header            |
>>>> 
>>>>                       |     (with set Flow label)       |
>>>> 
>>>>                       +---------------------------------+
>>>> 
>>>> 
>>>> 
>>>>   This creates a duplication of the DetNet Destination Option.
>>>> 
>>>> 
>>>> 
>>>>   There are alternatives
>>>> 
>>>> 
>>>> 
>>>>   a)  whereby the packet is tunneled from the source to the detnet
>>>>   ingress, and based on its state the DetNet ingress accepts the
>>>>   packet, processes it and then resends it. The tunneled version of
>>>>   this could be:
>>>> 
>>>> 
>>>> 
>>>>                       +---------------------------------+
>>>> 
>>>>                       |                                 |
>>>> 
>>>>                       |           DetNet Flow           |
>>>> 
>>>>                       |             Payload             |
>>>> 
>>>>                       |                                 |
>>>> 
>>>>                       +---------------------------------+
>>>> 
>>>>                       |          IPv6 header            |
>>>> 
>>>>                       |   (dest = final destination)    |
>>>> 
>>>>                       /=================================\
>>>> 
>>>>                       H   Optional DetNet DstOpt Hdr    H
>>>> 
>>>>                       \---------------------------------/
>>>> 
>>>>                       |          IPv6 header            |
>>>> 
>>>>                       |   (dest = DetNet ingress edge)  |
>>>> 
>>>>                       |     (with set Flow label)       |
>>>> 
>>>>                       +---------------------------------+
>>>> 
>>>> 
>>>> 
>>>>   Which allows the ingress to tunnel to the egress as follows:
>>>> 
>>>>                       +---------------------------------+
>>>> 
>>>>                       |                                 |
>>>> 
>>>>                       |           DetNet Flow           |
>>>> 
>>>>                       |             Payload             |
>>>> 
>>>>                       |                                 |
>>>> 
>>>>                       +---------------------------------+
>>>> 
>>>>                       |          IPv6 header            |
>>>> 
>>>>                       |      (to final destination)     |
>>>> 
>>>>                       +=================================+
>>>> 
>>>>                       |          Routing header         |
>>>> 
>>>>                       /---------------------------------\
>>>> 
>>>>                       H   Optional DetNet DstOpt Hdr    H
>>>> 
>>>>                       \---------------------------------/
>>>> 
>>>>                       |          IPv6 header            |
>>>> 
>>>>                       |   (dest = DetNet egress edge)   |
>>>> 
>>>>                       |     (with set Flow label)       |
>>>> 
>>>>                       +---------------------------------+
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>   b)  whereby the PREF is done by the end nodes and the tunnel is
>>>>   transport only, meaning that there are 2 tunnels A and B and that
>>>>   the source sends twice a packet like this:
>>>> 
>>>> 
>>>> 
>>>>                       +---------------------------------+
>>>> 
>>>>                       |                                 |
>>>> 
>>>>                       |           DetNet Flow           |
>>>> 
>>>>                       |             Payload             |
>>>> 
>>>>                       |                                 |
>>>> 
>>>>                       /---------------------------------\
>>>> 
>>>>                       H   Optional DetNet DstOpt Hdr    H
>>>> 
>>>>                       \---------------------------------/
>>>> 
>>>>                       |          IPv6 header            |
>>>> 
>>>>                       |   (dest = DetNet ingress edge X)|
>>>> 
>>>>                       |     (with set Flow label)       |
>>>> 
>>>>                       +---------------------------------+
>>>> 
>>>> 
>>>> 
>>>>   And then the ingress node needs to re-encapsulate as
>>>> 
>>>> 
>>>> 
>>>>                       +---------------------------------+
>>>> 
>>>>                       |                                 |
>>>> 
>>>>                       |           DetNet Flow           |
>>>> 
>>>>                       |             Payload             |
>>>> 
>>>>                      |                                 |
>>>> 
>>>>                       /---------------------------------\
>>>> 
>>>>                       H        DetNet DstOpt Hdr        H
>>>> 
>>>>                       \---------------------------------/
>>>> 
>>>>                       |          IPv6 header            |
>>>> 
>>>>                       |   (dest = final destination)    |
>>>> 
>>>>                       |     (with set Flow label)       |
>>>> 
>>>>                       +=================================+
>>>> 
>>>>                       |          Routing header         |
>>>> 
>>>>                       +---------------------------------+
>>>> 
>>>>                       |          IPv6 header            |
>>>> 
>>>>                       |   (dest = DetNet egress edge X) |
>>>> 
>>>>                       |     (with set Flow label)       |
>>>> 
>>>>                       +---------------------------------+
>>>> 
>>>> 
>>>> 
>>>>   Cheers,
>>>> 
>>>> 
>>>> 
>>>>   Pascal
>>>> 
>>>>   _______________________________________________
>>>>   detnet mailing list
>>>>   [e-mail] <mailto:detnet%40ietf.org>
>>>>   https://www.ietf.org/mailman/listinfo/detnet
>>>> 
>>> 
>> 
>> 
> 

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