Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-over-udp-ip-07: (with DISCUSS)

Stewart Bryant <stewart.bryant@gmail.com> Thu, 03 December 2020 17:25 UTC

Return-Path: <stewart.bryant@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 2B6993A0983; Thu, 3 Dec 2020 09:25:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 uyiyhkuvJezz; Thu, 3 Dec 2020 09:25:39 -0800 (PST)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 2964B3A09C0; Thu, 3 Dec 2020 09:25:39 -0800 (PST)
Received: by mail-wr1-x432.google.com with SMTP id r3so2697399wrt.2; Thu, 03 Dec 2020 09:25:39 -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=VM5T5neYcuVMDyIuMXRwntkCmYhx1i1nW+EbREZfSKk=; b=D+RiNK6lsn5AODIUbtQBW0NNQ1zHu0aKORgvcMgCHg0s5rbixU81oBLySVpvfJHpmj hsk1XaCbMaNLvmdxokHr2/yLhrhVTnLLVjJwHWhxNxNWhslludvqbnghkWsVMzAUfpqO 7oWOXBcJV5iGUMRL7LnS3UoDCHnLqplnvIOb9pfcn7Fj82mqkbmiEbLq9booeByd6QMD 6x10TMc5zFvwWScsVMgYJ+8fNnLAuza6+09ThK35AwvSkNLvdF+ytM5ZbpTDKL5ZejnF yU2zDE6/6OM2wdOcY2/0cULWopcgf7YAdfvu+CTnApN2Hw0GhC8VFptQyH91JswDV/V0 FxfQ==
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=VM5T5neYcuVMDyIuMXRwntkCmYhx1i1nW+EbREZfSKk=; b=UxBpQafW8qMW8DLDDia2FDcHzx7/y6xpH9tspR9lz9CAKA609TyuPhv0PBKnyVebfc aUiujVE95AGEaUa8rS4yU7yAvFGY7+a3vFgpwa+UdR34xjiv2Kw07vdf/NgXht2nMZpx 1gSqx0ULEEn4B0F1zNvwz3LR2xcvcyf1aBEJENj250VgfpKl7GJNwTtlEJgh9GqxSftE f1TRxYUU8IQIv1I25X8rfdfvkX+FnSEIV13QJodmv8ThYYBXNTBZRK++XDFv15ZE4ntV kaLCjAaQXL3EXaCUGRbTZWzTnRgQy/1Jh4c/3yQrC9X/9r7+CSFDywYZ0yOtCFVYG4I1 u+dw==
X-Gm-Message-State: AOAM5338k64vKG9DEVFlDvobPw8IXoisimfDvh7cIKRAy5Q989EigVqc ChmoTRPGXbotQrJRKMwB8oE=
X-Google-Smtp-Source: ABdhPJxUHFbW7UukQcaP9L5VVBbjAVWB3Zsum1drEzU8YKJ7+qgjL4RSouzjbCCQV+NjB8+dW9VJLQ==
X-Received: by 2002:adf:e44d:: with SMTP id t13mr262800wrm.144.1607016337376; Thu, 03 Dec 2020 09:25:37 -0800 (PST)
Received: from broadband.bt.com ([2a00:23c5:3395:c901:1972:4835:2824:4f5f]) by smtp.gmail.com with ESMTPSA id f4sm10734wmb.47.2020.12.03.09.25.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 09:25:36 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <MN2PR19MB404587BFFC59E419FE36B2EB83F30@MN2PR19MB4045.namprd19.prod.outlook.com>
Date: Thu, 3 Dec 2020 17:25:34 +0000
Cc: Stewart Bryant <stewart.bryant@gmail.com>, =?utf-8?Q?Bal=C3=A1zs_Varga_A?= <balazs.a.varga=40ericsson.com@dmarc.ietf.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>, The IESG <iesg@ietf.org>, "eagros@dolby.com" <eagros@dolby.com>, "detnet@ietf.org" <detnet@ietf.org>, "draft-ietf-detnet-mpls-over-udp-ip@ietf.org" <draft-ietf-detnet-mpls-over-udp-ip@ietf.org>, "detnet-chairs@ietf.org" <detnet-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <10D78603-1939-43EB-8EAC-676A20078710@gmail.com>
References: <160692402637.11206.9329606236693711643@ietfa.amsl.com> <AM0PR0702MB3603B5136717E3A0A6123934ACF30@AM0PR0702MB3603.eurprd07.prod.outlook.com> <MN2PR19MB404587BFFC59E419FE36B2EB83F30@MN2PR19MB4045.namprd19.prod.outlook.com>
To: "Black, David" <David.Black@dell.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/fE8Ih-yi6uHLmpjAg9bfS_Ci9VQ>
Subject: Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-over-udp-ip-07: (with DISCUSS)
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: Thu, 03 Dec 2020 17:25:41 -0000

I am not sure I understand why any additional text is needed.

We agree that Detnet fulfils the requirements to run with no c/s, and adding a c/s is going to degrade performance since forwarders in routers cannot see the whole of the packet in the fast path and so using a c/s is actually going to degrade the detent performance in many cases by adding latency.

So if we are going add text I think we need to add a warning not to use the c/s unless you have special h/w to support its calculation automatically.

On the other hand we could without risk remain silent and leave this to the implementors & operators to agree since there is no interoperability issue.

- Stewart

> On 2 Dec 2020, at 22:40, Black, David <David.Black@dell.com> wrote:
> 
> Hi Balazs,
> 
> Digging in a little deeper, I concur with Magnus's underlying concern that this draft ought to say something about UDP checksums with IPv6.  There's a useful starting point at the end of the Introduction (Section 1):
> 
>   As specified in [RFC7510]: "MPLS-in-UDP MUST NOT be used over the
>   general Internet, or over non-cooperating network operators, to carry
>   traffic that is not congestion controlled."  This does apply to
>   DetNet networks as this document focuses on solutions for networks
>   that are under a single administrative control or within a closed
>   group of administrative control.
> 
> That suggests that the first two exceptions (a & b)  in Section 3.1 of RFC 7510 (both of which involve single administrative control) are more likely to apply to DetNet than the third one (c, based on higher layer recovery and/or error tolerance).  It could be helpful to say that in an added paragraph on UDP checksums (for both v4 and v6) at the end of Section 4 in this draft.
> 
> I would also suggest aligning the text quoted above (from the end of Section 1) with the text used in exceptions a. & b. in Section 3.1 of RFC 7510, as I think roughly the same scope is intended.  In particular, it appears to me that this draft's notion of "closed group of administrative control" would fall under the notion of "single administrative control" in RFC 7510 (FWIW, I'm an author of RFC 7510).
> 
> The suggestion to add use/non-use of UDP checksum to the list of management and control information in Section 5 is a good idea - that addition ought to cite Section 3.1 of RFC 7510 for the conditions under which the UDP checksum may be disabled for IPv6 (per RFC 7510, UDP checksum for IPv6 "MUST be implemented" for MPLS-in-UDP).
> 
> Thanks, --David
> 
>> -----Original Message-----
>> From: detnet <detnet-bounces@ietf.org> On Behalf Of Balázs Varga A
>> Sent: Wednesday, December 2, 2020 12:25 PM
>> To: Magnus Westerlund; The IESG
>> Cc: eagros@dolby.com; detnet@ietf.org; draft-ietf-detnet-mpls-over-udp-
>> ip@ietf.org; detnet-chairs@ietf.org
>> Subject: Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-over-
>> udp-ip-07: (with DISCUSS)
>> 
>> 
>> [EXTERNAL EMAIL]
>> 
>> Hi,
>> 
>> Chapter 5. of draft-ietf-detnet-mpls-over-udp-ip provides a _non-exhaustive_ list of
>> control and management plane information.
>> DetNet does not changes rules of rfc7510: if the exceptions listed in 3.1 of rfc7510
>> applies, then using zero checksum is allowed; otherwise not.
>> 
>> A possible solution can be to add an additional information element to the list in
>> chapter 5, which allow or not the usage of zero-checksum.
>> 
>> Thanks & Cheers
>> Bala'zs
>> 
>> 
>> -----Original Message-----
>> From: detnet <detnet-bounces@ietf.org> On Behalf Of Magnus Westerlund via
>> Datatracker
>> Sent: Wednesday, December 2, 2020 4:47 PM
>> To: The IESG <iesg@ietf.org>
>> Cc: eagros@dolby.com; detnet@ietf.org; draft-ietf-detnet-mpls-over-udp-
>> ip@ietf.org; detnet-chairs@ietf.org
>> Subject: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-over-udp-
>> ip-07: (with DISCUSS)
>> 
>> Magnus Westerlund has entered the following ballot position for
>> draft-ietf-detnet-mpls-over-udp-ip-07: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all email
>> addresses included in the To and CC lines. (Feel free to cut this introductory
>> paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-over-udp-ip/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> So there might be something missing here in regards to zero-checksum in UDP
>> when using IPv6. So Section 3.1 in RFC 7510 discusses this for MPLS over UDP and
>> have some considerations that needs to be done if one are intending to use zero
>> checksum. To me it appears that DETNET flows can not be guaranteed to always
>> fulfill these, and in case you think you can motivate it should probably be stated
>> explicitly and normatively allow it. So if it can't be guaranteed to fulfill these
>> requirements then the next question exists: Do the possibility to use zero-checksum
>> for this flow become something the control plane needs to signal it?
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> detnet mailing list
>> detnet@ietf.org
>> https://www.ietf.org/mailman/listinfo/detnet
>> 
>> _______________________________________________
>> detnet mailing list
>> detnet@ietf.org
>> https://www.ietf.org/mailman/listinfo/detnet