Re: [Detnet] IP dataplane
Greg Mirsky <gregimirsky@gmail.com> Sat, 13 November 2021 02:56 UTC
Return-Path: <gregimirsky@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 66B4C3A1164 for <detnet@ietfa.amsl.com>; Fri, 12 Nov 2021 18:56:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.903
X-Spam-Level: **
X-Spam-Status: No, score=2.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 1HGinybiAQ0c for <detnet@ietfa.amsl.com>; Fri, 12 Nov 2021 18:56:35 -0800 (PST)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 CC6BF3A10CF for <detnet@ietf.org>; Fri, 12 Nov 2021 18:56:27 -0800 (PST)
Received: by mail-ed1-x52f.google.com with SMTP id r12so45180884edt.6 for <detnet@ietf.org>; Fri, 12 Nov 2021 18:56:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ubNgdWY/0T2Jsu3kF98fo7MbLoevLNMAXl2fxP3yisU=; b=pZsZ1/tPVy7Ad/OKUL8AMZfQB/qlOza/HQ+eCqcrT0EEPkHT0JKNVPR04Swjg6uTHq Cm27ejSmW91Nn4dS7EIHjVaHRGr+4hQdG4P/Kl5fPoS/1v61jFamwwTLblpaHegD1LZv DHrc7ZUdxfmG6N1qf+6EUaz5oIHMnEE8isSmpnEpr6kCPBBxuG36LsO0/B6u7lo79P/6 iBdD3XnAxiQm0KCf9Vk/xanoLHbaJkqLhkHEzyXUOTzBzspJSYxkUbBeysXgQB+rSvmR Fz9wK82LAs4QH25Tftdjc7DVuxqhllwZa1u8MnC1gqsjPI5avJ/zybWFBSrX/IH6N/+H 3/2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ubNgdWY/0T2Jsu3kF98fo7MbLoevLNMAXl2fxP3yisU=; b=YXVIk2UYoXWmYVbGmZrALKSecIMpG3iSkUfdIRkZJ74+cZgeMW5fc5G2tnjAOYGcrU /+ba6tbEhskDFFTFCxUVSJbwS94GHeSHnzp84Kaxp4XlDz6ODtRP0B8NA2Xwzfl9D0e+ LkfrUqf+aB9axYJbU4KOiQMHq4SrhJM+DkCjiXQ3TQERCm6A7BA6cpYdBhJ4hSxN2NqE pJNf+SS+sXYn8fgmnPhMinHuEIrfrcsj6GOICfIQSh2CsS6rep679pGUPwDCw1s3e0Z2 FK6e/l7/Jbxv/M2sIk8GTTbXQBEHgA8j0LwkQpY2erHvtSzSyxEHW23PvJjuv8Ld44Ny XVUg==
X-Gm-Message-State: AOAM531vQ//ag0eZF77vahwdmZS/fjqJl8uTaJayULJrPQkcZcZYowoZ 2r/abyzBNLcRVhBbk8lQFZtIXFocoNNLYRNV8wg=
X-Google-Smtp-Source: ABdhPJyd2D5tu4s6sMrRFZypPM3P70hbIKuItCxfiTKTKhd9XkB6gbgJ3gDCcxpJr0Eo83fyjrn5oVa+37DrxMGcg3s=
X-Received: by 2002:a17:906:d187:: with SMTP id c7mr11250358ejz.477.1636772185617; Fri, 12 Nov 2021 18:56:25 -0800 (PST)
MIME-Version: 1.0
References: <CO1PR11MB48810E7AEBE8B42968828A46D8939@CO1PR11MB4881.namprd11.prod.outlook.com> <YYwVH0WbKlLqm4GT@faui48e.informatik.uni-erlangen.de> <4B0C152D-69D0-41C4-A466-3800A8CB0B11@cisco.com> <YY2Tv+RUCy6mXNlp@faui48e.informatik.uni-erlangen.de>
In-Reply-To: <YY2Tv+RUCy6mXNlp@faui48e.informatik.uni-erlangen.de>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 12 Nov 2021 18:56:14 -0800
Message-ID: <CA+RyBmWdAPX4_mcE6C+1cJa0XhpTZs-f7_Uw+uy1VX7r5yh1_A@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>, "detnet@ietf.org" <detnet@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b3b8e705d0a2b8b7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/mFYB2O9Iym1XMZm3-D12AvzNTHY>
Subject: Re: [Detnet] IP dataplane
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 13 Nov 2021 02:56:46 -0000
Hi Toerless, RE: aggregation in MPLS question. The aggregation in MPLS can be achieved using a hierarchical LSP. RFC 6107 <https://www.rfc-editor.org/rfc/rfc6107.html> describes how GMPLS can be used to signal dynamic hierarchical LSPs. As Pascal suggested for DetNet flow aggregation over IP, the aggregate must be seen and treated as a new DetNet flow. What are your thoughts? Regards, Greg On Thu, Nov 11, 2021 at 2:06 PM Toerless Eckert <tte@cs.fau.de> wrote: > On Thu, Nov 11, 2021 at 09:05:21AM +0000, Pascal Thubert (pthubert) wrote: > > We already spent quite a bit of effort on that. Would you kindly comment > on https://sandbox.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh-06 ? > > wht is the teal with snadbox.ietf.org, it seems not to work for me, > "rendering fails". Is this something for collaborative commenting/editing, > or is there a github too ? > > > As i mentioned in DetNet, i think it would be great if we could try to see > if/how much unification across different data-planes we can get. With > that thought in mind, it might be useful to split any work (like this > document) into > > a) an encoding idependent part describing use-cases/scenarios, > AND information model. Where information model describes > which variables we want, and where/how each of them needs to be > examined. > > b) encoding spec. Which may be as lame as an IPv6 HbH heder, or multiple, > or maybe an extension header that can be shared across IPv6 and future > MPLS. > > > f) Aggregation/disaggregation is i think a problem we can punt up from > IP layer > > to overall DetNet layer. Aka: We have no architectural design or > solution of > > this for MPLS AFAIK. But we would need reference scenarios to work > against them. > > > > IPv6 offers the capability to aggregate by encapsulating multiple > streams in one tunnel. > > The key for DetNet is that the outer tunnel must signal the needed > information for the aggregation including a new sequencing information and > packet treatment, independent of the inner signaling when tunnels, OAM or > application flows are merged. > > Sure, but how would that be fundamentally different from aggregation in > MPLS ? > Which AFAIK, we have also not yet tackled in DetNet. > > > The trick is to determine how wider the aggregation tunnel must be vs > the sum of inner flows to adapt the bounded latency, a problem that might > be related to the wide area discussion. > > Sure, but thats not an encap issue, unless you are thinking only about > the added packet header impact. > > And we also have the option to agregate even without tunneling. Just > think about all the traffic to one destination, and you just instantice > a per-destination traffic shaper on every hop, but let the controller > calculate the correct shapper parameter for the aggregate at that hop. > Not good for SP networks, but maybe for non-SP networks. > > Aka: I am not saying that we shouldn't figure out the information model > for aggregation, but its a big new building block. > > > Enjoy the rest of the week and remember the 6MAM v6ops on Friday! > > Indeed! > > You to. > > Cheers > Toerless > > > > Keep safe, > > > > Pascal > > > > Cheers > > Toerless > > > > On Wed, Nov 10, 2021 at 01:48:29PM +0000, Pascal Thubert (pthubert) > wrote: > > Thanks to both Lou and David for rewording very correctly what I was > trying to say at the meeting today. > > > > Effectively, the question is whether we need for a pure IP dataplane > that can carry the DetNet information for Forwarding and Service sublayer. > > > > Arguments on the table: > > > > - Not all DetNet environments employ MPLS and pseudowires as a basic > tool. Forcing such concepts beyond their domain may hinder adoption in pure > IP (IT) and industrial (OT) spaces. A native IP solution is desirable. Note > that IPv4 can be encapsulated in IPv6 so arguably we can live with IPv6 > signaling. > > - Hardware operation (common ASICs) need the information very early in > the packet. Digging after UDP may not be feasible in all cases. The DetNet > information cannot be missed and should be very early after the IP header > (before UDP if present). > > - An IP solution is bound to other rules than MPLS, e.g., use of EH and > encapsulation vs. stack of label. The properties of the solution might be > different and IP may possibly express richer semantics. But as of now, the > IP data plane is more limited than the MPLS one. > > - There's a need with IPv6 to encapsulate when playing with merging, > re-sourcing (for duplication and network coding), altering the destination > (to an intermediate elimination node) or changing packet header information > (e.g., sequencing); such encapsulation will hinder with the visibility of > deep information (UDP and application data), which cannot be used for > DetNet processing > > - the elimination or decapsulation node may not be the destination, but > it still needs to understand the DetNet signaling; the DetNet signaling > should be 100% L3, fully independent of L4 and above, and should not imply > that the transport is USP. > > - the 5-6 tuple points on upper layer information for a flow. DetNet may > aggregate flows (several times leading to multiple reencapsulations) > disaggregate flows (decapsulations and separation) and OAM packets. We want > the information that signals the dataplane processing independent of which > application flow / already merged and encasulated application flows / and > or OAM is transported. > > - it would make sense to build a solution that integrates well with IPv6 > state of the art, especially SRv6, and very possibly HbH which is getting > traction, see the discussion at 6MAN / v6ops on Friday. > > > > Bottom line: I disagree with adopting a document that would seem to > indicate that we're done with IP. On the contrary I believer that there's a > rich ground that we need to plow to deliver the best for IP networks. > > > > What do others think? > > > > Keep safe, > > > > Pascal Thubert > > > > _______________________________________________ > > detnet mailing list > > detnet@ietf.org > > https://www.ietf.org/mailman/listinfo/detnet > > > > -- > > --- > > tte@cs.fau.de > > > > _______________________________________________ > > detnet mailing list > > detnet@ietf.org > > https://www.ietf.org/mailman/listinfo/detnet > > -- > --- > tte@cs.fau.de > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet >
- [Detnet] IP dataplane Pascal Thubert (pthubert)
- Re: [Detnet] IP dataplane Toerless Eckert
- Re: [Detnet] IP dataplane Pascal Thubert (pthubert)
- [Detnet] 答复: IP dataplane Yangfan(Fan,IP Standards)
- Re: [Detnet] IP dataplane Toerless Eckert
- Re: [Detnet] IP dataplane Pascal Thubert (pthubert)
- Re: [Detnet] IP dataplane Greg Mirsky
- Re: [Detnet] IP dataplane Greg Mirsky