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 >>>> >>> >> >> >
- [Detnet] IPv6 encapsulation in dataplane doc Pascal Thubert (pthubert)
- Re: [Detnet] IPv6 encapsulation in dataplane doc Lou Berger
- Re: [Detnet] IPv6 encapsulation in dataplane doc Jouni
- Re: [Detnet] IPv6 encapsulation in dataplane doc Jouni
- Re: [Detnet] IPv6 encapsulation in dataplane doc Pascal Thubert (pthubert)
- Re: [Detnet] IPv6 encapsulation in dataplane doc Jouni
- Re: [Detnet] IPv6 encapsulation in dataplane doc Lou Berger
- Re: [Detnet] IPv6 encapsulation in dataplane doc Jouni
- Re: [Detnet] IPv6 encapsulation in dataplane doc Lou Berger
- Re: [Detnet] IPv6 encapsulation in dataplane doc Jouni
- Re: [Detnet] IPv6 encapsulation in dataplane doc Pascal Thubert (pthubert)
- Re: [Detnet] IPv6 encapsulation in dataplane doc Lou Berger
- Re: [Detnet] IPv6 encapsulation in dataplane doc Balázs Varga A
- Re: [Detnet] IPv6 encapsulation in dataplane doc Andrew G. Malis
- Re: [Detnet] IPv6 encapsulation in dataplane doc Andrew G. Malis
- Re: [Detnet] IPv6 encapsulation in dataplane doc Pascal Thubert (pthubert)
- Re: [Detnet] IPv6 encapsulation in dataplane doc Lou Berger
- Re: [Detnet] IPv6 encapsulation in dataplane doc Balázs Varga A