Re: [Detnet] IPv6 encapsulation in dataplane doc

["Andrew G. Malis" <[e-mail]>]

Whoops, that was a typo, should be RFC 7510, not 7520.

Cheers,
Andy


On Mon, Feb 12, 2018 at 2:14 PM, Andrew G. Malis <[e-mail]> wrote:

> Lou and Pascal,
>
> On the most recent interim call, we discussed an encapsulation for IPv4
> and IPv6 that reused the MPLS encapsulation inside UDP inside IP (ala RFC
> 7520). This works for both v4 and v6, obviously.  Or at least that’s how I
> interpreted the conversation at the time and the following notes from the
> Etherpad:
>
> Jouni: Good point. Prob with IP is have been narrow focused on carrying
> DetNet info. But if can assume that in a DetNet domain for routed traffic,
> transport below is TSN or equivalent, e.g. MPLS, then what we do at IP
> layer is just routing or mapping flows into MPLS tunnels. An underlay and
> then just do routing.
> Lou: Is that assuming that PREF always done by e.g. TSN layer?
> Jouni: Yes.
> Jouni: Then starts looking like over PWs as we discussed earlier.
> Lou: Others find this approach acceptable? This proposal fits within our
> charter and process, and is more like what some hoped to see from our
> process. Do we, the people building the solution, like this approach or
> find it objectionable?
> Jouni: Starting to like this idea.
> Lou: So next rev of draft will propose largely common approach on v4 and
> v6, i.e. 5-tuple, depends on TSN and MPLS to provide transport and PREF
> functions?
>
> So is this still the case, and what we should expect to see in the next
> revision of the draft?
>
> Thanks,
> Andy
>
>
> On Mon, Feb 12, 2018 at 11:25 AM, Lou Berger <[e-mail]> wrote:
>
>> 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#se
>>>>>>> ction-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
>>
>
>