Re: [Detnet] IP dataplane

Toerless Eckert <tte@cs.fau.de> Wed, 10 November 2021 18:53 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 DF4263A128C for <detnet@ietfa.amsl.com>; Wed, 10 Nov 2021 10:53:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Level:
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 gYiaJOFmyBkZ for <detnet@ietfa.amsl.com>; Wed, 10 Nov 2021 10:53:27 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835553A128F for <detnet@ietf.org>; Wed, 10 Nov 2021 10:53:26 -0800 (PST)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id D0160548019; Wed, 10 Nov 2021 19:53:19 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id BC8CE4E9D53; Wed, 10 Nov 2021 19:53:19 +0100 (CET)
Date: Wed, 10 Nov 2021 19:53:19 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>
Cc: "detnet@ietf.org" <detnet@ietf.org>
Message-ID: <YYwVH0WbKlLqm4GT@faui48e.informatik.uni-erlangen.de>
References: <CO1PR11MB48810E7AEBE8B42968828A46D8939@CO1PR11MB4881.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CO1PR11MB48810E7AEBE8B42968828A46D8939@CO1PR11MB4881.namprd11.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/UfpYqgbSGn0KYKdiaGM1JbJk9mQ>
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: Wed, 10 Nov 2021 18:53:32 -0000

Hi Pascal

Thanks for the email, it touches on a lot of good points. Let me give some opinions from my side

a) I too would like to see that we do get all of the detnet services for a pure
   IP data plane, and not only some short-term IP over MPLS workarounds.

b) I have no strong opinions yet what this means for the document in question.
   Maybe it would suffice to more clearly describe the scope of any current
   "workaround" or "incomplete" IP dataplane documents as such - to make readers
   understand that these solutions may not be good for best-long-term deployments.
   Just an idea.

c) As i said in my slot today, it would help to have more audio discussion time.
   Hopefully we can start such "design-team" meetings..

d) I have not really considered the 'E'limination or othre DetNet service layer
   functions since our old BIER-TE extension work. I think it would be great
   to have some writeup of reference example use cases where this is done, so that
   one had a more concrete reference when designing an appropriate solution.

e) Right now i am roughly thinking that for bounded latency we would want a 
   Hop-By-Hop header with sequence number and appropriate bounded latency paramer(s).
   If we had such a header, we could perform elimination of course also from
   fields in the packet header and not need to rewrite IP header addresses along
   the path. Lets see what fridays 6man meetin brings up avbout the future of HBH.

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.

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