Re: [Detnet] IPv6 encapsulation in dataplane doc
Jouni <jouni.nospam@gmail.com> Sun, 11 February 2018 20:06 UTC
Return-Path: <jouni.nospam@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 C86B412704A for <detnet@ietfa.amsl.com>; Sun, 11 Feb 2018 12:06:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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 6WpijcV8AaAP for <detnet@ietfa.amsl.com>; Sun, 11 Feb 2018 12:06:15 -0800 (PST)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 AE50D12700F for <detnet@ietf.org>; Sun, 11 Feb 2018 12:06:14 -0800 (PST)
Received: by mail-lf0-x229.google.com with SMTP id q194so17779480lfe.13 for <detnet@ietf.org>; Sun, 11 Feb 2018 12:06:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5wD8aFo06ALLm/L7pChm7YbaZ2Gf9IW8wrvwdIsvCKc=; b=tP9V5qBHga+1MAs2dw0CjoLH90QgI32Q5VWx6xPeWCyzAlaSCGFGRDJpQoINHVzzIu 8cRGGec8kBdUwBQaJhEyErkQztbCrkW7CS6n2aPXsCqz8eQtvkrYVnkjVxI/KTeHDsq3 cGI7bK1KGdUEWlbxsAsSlEMzs1fLv7Vxz9eYAqKteZ+GrSCigLuPnjUrwWAlNE9rVESf WMYf1Ylpx32sh8NG9YNQEnY3EbProJA2uA2wmQj8OoDLcjTlOdtbV9Nm1VjXHBIcDXsS q8qVFjzVSoTtKF3RJ34eHMKx8PSTMkBKl7fHq4F+KXPfOn9zOkDbM8liTsS72yxRrL9Y Hr4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5wD8aFo06ALLm/L7pChm7YbaZ2Gf9IW8wrvwdIsvCKc=; b=rugLHJxlR/C5DqCMJ9oljjdZwsgsBwcpOPRIftyFKg/kmD0zuZKVcchrhXZ0sQytxB Wn8Newhy5zTworvxsdx/5qsSLvKZiDWM6Q9oBViSy4v2p2lMhvmqiZ79WobLgVJGfBRE HCEF9yyT9wF3gwO8vLpGigd2eIj6gZUInhg0oj+LAak5mZGyGqh5h9O7Ep49Jq5k/dcd uM6p5FLk9wTUuU5ucoWtQumVKWxbM6UcOfGmi6SmZ3rTBBYSoD7o2BO8Tthn96UYm6Yj 8vuelLTSP0Yz8M0E2A8gHpHn7okesNc+sjfno+nNizY2K/m/OnGTrktJDhkAHd95mweF bnKw==
X-Gm-Message-State: APf1xPADHUKgk+wwHNH3pniafCDpuK5Dhjbx4SMS1qyLPQq1e2/ZRt00 ZILWYjViS8bKVpo1YlY/OK8=
X-Google-Smtp-Source: AH8x224PRFxgzly4RwOF7V1pXZfzncqBKloGUkZ5hyHCtCBmPNO18r/GtmRo2bSof1W0Iy3J+Mcs+g==
X-Received: by 10.46.114.10 with SMTP id n10mr6159916ljc.74.1518379572859; Sun, 11 Feb 2018 12:06:12 -0800 (PST)
Received: from jounis-imac.home ([83.150.126.201]) by smtp.gmail.com with ESMTPSA id r9sm1307787ljc.18.2018.02.11.12.06.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 11 Feb 2018 12:06:11 -0800 (PST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Jouni <jouni.nospam@gmail.com>
In-Reply-To: <b17a1c79-010d-b4a0-aa07-8182b72f2577@labn.net>
Date: Sun, 11 Feb 2018 22:06:02 +0200
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, detnet@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <00A9AB24-830A-46C7-B3DB-5C17D2AC91EC@gmail.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>
To: Lou Berger <lberger@labn.net>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/Dt9g013FxmaTR6ICo4UwDZ4FbYY>
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: Sun, 11 Feb 2018 20:06:18 -0000
Hi, Inline.. > On 09 Feb 2018, at 18:23, Lou Berger <lberger@labn.net> wrote: > > Hi Jouni, > > > On 02/08/2018 04:08 AM, Jouni wrote: >> Hi, >> >> >> >> Yes, we discussed this to an extent in the last call. I’ve been thinking >> this a bit more lately (cross country skiing conditions have been great >> thus you got a lot of time while on the skiing tracks ;) Few >> concerns/points to think I see here are: > > I'm jealous! > >> >> * 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). >> * 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. 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. - 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