Re: [Detnet] IPv6 encapsulation in dataplane doc

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

Hello Pascal,
Thanks, that was great clarification and now I see your valid points much better.
Cheers
Bala'zs

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[e-mail]] 
Sent: 2018. február 12. 20:31
To: Balázs Varga A <[e-mail]>; Jouni <[e-mail]>; Lou Berger <[e-mail]>
Cc: [e-mail]
Subject: RE: [Detnet] IPv6 encapsulation in dataplane doc

Hello Balázs

- Why no seq.num in IP? That would mean no PREF, no IOD function within DetNet domain Which is an IP PSN.

> Sorry, I was unclear and I agree with you. There would not be one provided the source, but then the ingress edge would need to encapsulate the packet. In which case it would set the next  as destination and insert a DestOpt before the routing header if any. 

> Note that if have not (Yet? Should we???) looked at a way to express the ladder as a routing header. Till then, the most sensible thing is to send the packet unicast to the next Relay node (next relays if this node is a replicator). We still may indicate intermediate transit nodes as a routing header though. The DestOpt would then be after the routing header, not before.

--------------------

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

> I would say that these functions are closely related to traditional capabilities of a L4 transport. TCP reorders the bytes in the stream and provides ARQ which is an alternate to FEC. MP TCP distributes packets over different paths. Doing those functions at L4 allows real end to end service even if there is no specialized NIC. It keeps the IP layer intact which seemed to be a goal in that discussion. It allows features like Network Coding which are certainly easier to do high in the stack of a host system than in a line card or a fast path in a router.

- Checking L4 within the DetNet domain would require DPI, what I guess we do not want.

> Architecturally speaking, the L4 transport implements a detnet service layer though it would not be done at DetNet WG. When that L4 transport is enabled, some service layer functions provided by the network would not be used, or would rely on their own sequencing. I'm not excluding that vendors could propose some DPI for very specific applications, e.g. recognizing a particular industrial protocol and routing it differently, say over a DetNet path. But this is an implementation game and I do not see what's there for us to standardize.

------------------------

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

> I mean that an application on a device that was designed before TSN and that does not connect to the controller and that may not participate to PTP may still benefit from DetNet. But even if the application needs are roughly known, the granularity of the TSPEC may not be the one TSN expects. There is a need for an adaptation to absorb the burst that a strict ingress filtering may treat too violently. Reference here is to CIR in frame relay networks serving TCP and SNA flows. Disserving would be a more proper term, I have a long history on implementing that, and I would like to avoid going through that pain again.

What I meant with Wi-Fi is different; I showed that in some cases we really need the PREF from the source node if it is a wireless node. Because the losses mostly happen on the radio hop. I had in mind that with a form of multicast, the source STA could send a single packet to 2 or more Ingress Routers connected to different APs, and then all the received copies would follow their own DetNet path.

Take care,

Pascal



-----Original Message-----
From: detnet [mailto:[e-mail]] On Behalf Of Balázs Varga A
Sent: lundi 12 février 2018 17:37
To: Pascal Thubert (pthubert) <[e-mail]>; Jouni <[e-mail]>; Lou Berger <[e-mail]>
Cc: [e-mail]
Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc

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

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