Re: [Detnet] IPv6 encapsulation in dataplane doc

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 12 February 2018 10:30 UTC

Return-Path: <pthubert@cisco.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 D61CC1273E2 for <detnet@ietfa.amsl.com>; Mon, 12 Feb 2018 02:30:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level:
X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 pHyFeQECI_lw for <detnet@ietfa.amsl.com>; Mon, 12 Feb 2018 02:30:15 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEB3F124BFA for <detnet@ietf.org>; Mon, 12 Feb 2018 02:30:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14589; q=dns/txt; s=iport; t=1518431414; x=1519641014; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KhnzOKIbfKpm+iLwifZb4bctMoXBF12Mehkku4HNf3Q=; b=BRP/mb/HfDIE/Gmg1eDy4gxkCyl2L9UfxZiN3CCOW1XwlDiRstqprxvC KQB2qNUz3XVucbU+HMJ0Y7eeC9Gwgr2l7dANKq4w+NxogH5+XbRoeQlMT 6KS0AFz/GQsTVAyIvoBnyAjM2B9lNqOC6gaBsVQ/GTQx8UvWpxjs+xfLq 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DBAAAlbIFa/4oNJK1cGQEBAQEBAQEBAQEBAQcBAQEBAYNSZnAoCo1/jiOCAoEXh3+OQhWCAwoYC4RJTwKCSFQYAQIBAQEBAQECayiFIwEBAQMBAQFqAggDDAQCAQgRBAEBAScHIQYLFAkIAgQBDQUIE4oCAw0IELBLhzYNgTGCDQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2EfIIVgVeBaIMugmtEAQECAYE2GAEBhXogBYpriC+QXzUJAogehAiEUoUBgw+RPo4CSIkhAhEZAYE7AR85gVBwFT2CRgmEbQF4AYpAgSWBFwEBAQ
X-IronPort-AV: E=Sophos;i="5.46,501,1511827200"; d="scan'208";a="69611921"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2018 10:30:14 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w1CAUDdM002075 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 12 Feb 2018 10:30:13 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 12 Feb 2018 04:30:13 -0600
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Mon, 12 Feb 2018 04:30:13 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Jouni <jouni.nospam@gmail.com>, Lou Berger <lberger@labn.net>
CC: "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: [Detnet] IPv6 encapsulation in dataplane doc
Thread-Index: AdOgFyOl9vKMd7+3Skyj/a0jCzTraQAP298AACYDgIAAQYLPAABsVvAAAALSj4AAAI9ZgAAMJTaw
Date: Mon, 12 Feb 2018 10:30:00 +0000
Deferred-Delivery: Mon, 12 Feb 2018 10:29:08 +0000
Message-ID: <d879c877a1a04760920c9c9c3edbe6e0@XCH-RCD-001.cisco.com>
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>
In-Reply-To: <7CF3359D-204E-46E9-B7C6-B6134120502E@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.228.216.16]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/8DvYuC0G617RuYWnIzARcRgm7Rg>
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 10:30:18 -0000

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: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#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
>>>>   detnet@ietf.org <mailto:detnet%40ietf.org>
>>>>   https://www.ietf.org/mailman/listinfo/detnet
>>>> 
>>> 
>> 
>> 
>