Re: [Detnet] IPv6 encapsulation in dataplane doc

[Lou Berger <[e-mail]>]

I thought I heard IP over mpls not mpls over IP, although this is certainly 
possible but my bet is that this a third document or at least a new section.

I expect that this will come up on Wednesdays interim...

Lou


On February 12, 2018 2:16:05 PM "Andrew G. Malis" <[e-mail]> wrote:

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