Re: [Detnet] IPv6 encapsulation in dataplane doc

[Lou Berger <[e-mail]>]

Hi Pascal,

On 2/12/2018 5:30 AM, Pascal Thubert (pthubert) wrote:
> 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.
if you substitute "encode" with "signal", I agree.

> - DetNet may provide PREF/IOD from the edge ingress. DetNet would provide its own sequencing based on reception order at ingress edge.
I'm not sure edge ingress is right here.  an IP host may still be a 
DetNet edge, but PREF may on start at the DetNet/MPLS ingress.

> - 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.
are you talking 802.1cb or detnet PREF? if the former, yes, if the 
latter this is FFS for IP only detnet.

> - 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.
Yes (from my personal view)
> 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.
I don't think there has any proposal for this discussed in the WG either 
way.

> - 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.
agreed, as would be any changes in TCP congestion control modes to take 
advantage of DetNet allocations.


> Do we agree?
I hope so!

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