Re: [Detnet] IPv6 encapsulation in dataplane doc

"Andrew G. Malis" <agmalis@gmail.com> Mon, 12 February 2018 19:14 UTC

Return-Path: <agmalis@gmail.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5DD12D885 for <detnet@ietfa.amsl.com>; Mon, 12 Feb 2018 11:14:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoinzuHyKa73 for <detnet@ietfa.amsl.com>; Mon, 12 Feb 2018 11:14:52 -0800 (PST)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC265126C0F for <detnet@ietf.org>; Mon, 12 Feb 2018 11:14:51 -0800 (PST)
Received: by mail-oi0-x22f.google.com with SMTP id 24so12007187oij.3 for <detnet@ietf.org>; Mon, 12 Feb 2018 11:14:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=830A+UMtwY6EtIFNiJdKp590WvEt9CzGV+IX8krRl7Q=; b=aF+enYO1pnpCMW+h7jk64lDfsRrm9hDYjKneNwMzJ1aGjfHHDc/KqcDjlN4YpTWsFb XoP8b2qUt6Tyyz8dN+gwwkdQq+PIw9MHaQSSanyidU8FDV0iiwtqsCq/QPvZ3maQGb1/ AzolvXLG+XSVRvPy4vnHApQIoGyQJVSiagkQFeJ3JwQl9RPIOgbnfoKbSkQly6AquxF8 28kR97tkQfhVP3C1MkRDaWjY/qp+6l6/g8+iX1Ep1YX467pRz9Vas9QbnWA9f8ZGKefh 5ouKnCzL8Tylv27h3uXDicKN0lm7GY/4BcoCrOP4xgQdr9lkQn0bb11gkZuKRyDPp5GY xuOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=830A+UMtwY6EtIFNiJdKp590WvEt9CzGV+IX8krRl7Q=; b=d/8PFEHNPZjRXBvbvuM4tf98tg8uZzMrb5BN2tLKqP+RjSktphfx/tvwF9YbSlKH7w u1W2/v3g8RpA95WPpy0y8l5u153rn3hFzGvfFBE0fpbIEH6wTdkR6je7MdgRT1qctR6z 27RmoTLAMo/zM4WHC47DWC0P0po7EaXBdHs7iO4shD3qshofTHvyyOXOjDmB01y9O3n9 oz2I1NnPfIZquK98BvpVp9j5Pf1tCmyaPCfYc5U6lIrCmkmTfXFflq6jFQa+rdYEAnTZ vi8Wyr3DtTszv5gNiL98bR5ZsEZ9hFlu+XDT7m0C9NeOgam0GK8JbGfrDm6BOGFa4qnm 01Qw==
X-Gm-Message-State: APf1xPDQx6wv1A2lYW8EioI8/49jf/sc9aK+BA6ytV6gIPiFkBBLAAPF ZO+8JokhbMDhuvaSw5RQ1dEOKK9s8oEcH8kgoK4=
X-Google-Smtp-Source: AH8x227gqU6fLk736rxpR8uhbP+Iw4TmkWu5dXAZ+zxqxNz4uGGnhEbYeSNE6zEbFD8jSYdud+diaf1oFYgAp6a9cL4=
X-Received: by 10.202.80.200 with SMTP id e191mr8877611oib.333.1518462891087; Mon, 12 Feb 2018 11:14:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.21.72 with HTTP; Mon, 12 Feb 2018 11:14:30 -0800 (PST)
In-Reply-To: <1ecb9fc9-de35-c543-f53a-6640fddf2079@labn.net>
References: <cff50c52d2f945cfa8eff149f5242fb0@XCH-RCD-001.cisco.com> <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <22c101d3a0bc$5795b080$06c11180$@gmail.com> <b17a1c79-010d-b4a0-aa07-8182b72f2577@labn.net> <00A9AB24-830A-46C7-B3DB-5C17D2AC91EC@gmail.com> <b9c9fe85-fbd9-9859-51ca-27c9bda061a5@labn.net> <7CF3359D-204E-46E9-B7C6-B6134120502E@gmail.com> <d879c877a1a04760920c9c9c3edbe6e0@XCH-RCD-001.cisco.com> <1ecb9fc9-de35-c543-f53a-6640fddf2079@labn.net>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Mon, 12 Feb 2018 14:14:30 -0500
Message-ID: <CAA=duU0fgVx+eqE-YRePz-QCfU107Jcu-2iSn8=+YvC+XmYKBQ@mail.gmail.com>
To: Lou Berger <lberger@labn.net>
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Jouni <jouni.nospam@gmail.com>, "detnet@ietf.org" <detnet@ietf.org>
Content-Type: multipart/alternative; boundary="001a113b02b43a5aa6056508b166"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/Q2KaVFAGJdxFjcpaupi07xizcqg>
Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Feb 2018 19:14:56 -0000

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 <lberger@labn.net> 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:jouni.nospam@gmail.com]
>> Sent: dimanche 11 février 2018 22:43
>> To: Lou Berger <lberger@labn.net>
>> Cc: Pascal Thubert (pthubert) <pthubert@cisco.com>; detnet@ietf.org
>> 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:detnet-bounces@ietf.org] *On Behalf Of *Lou
>>>>>> Berger
>>>>>> *Sent:* Wednesday, February 7, 2018 17:00 PM
>>>>>> *To:* Pascal Thubert (pthubert) <pthubert@cisco.com>;
>>>>>> detnet@ietf.org
>>>>>> *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)"
>>>>>> <pthubert@cisco.com <mailto:pthubert@cisco.com>> 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
>>>>>>    detnet@ietf.org <mailto:detnet%40ietf.org>
>>>>>>    https://www.ietf.org/mailman/listinfo/detnet
>>>>>>
>>>>>>
>>>> _______________________________________________
>> detnet mailing list
>> detnet@ietf.org
>> https://www.ietf.org/mailman/listinfo/detnet
>>
>>
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet
>