Re: [Tsv-art] Tsvart last call review of draft-ietf-detnet-mpls-05

Balázs Varga A <balazs.a.varga@ericsson.com> Wed, 15 April 2020 07:32 UTC

Return-Path: <balazs.a.varga@ericsson.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4583A109D; Wed, 15 Apr 2020 00:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.268
X-Spam-Level:
X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 g7F_EDSkN20P; Wed, 15 Apr 2020 00:32:06 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70055.outbound.protection.outlook.com [40.107.7.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1023A109C; Wed, 15 Apr 2020 00:32:05 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PN/s66WywkBZudCcF544Pscqkhkeoe01Itb3d1xE5Uav0fE4iNClxbiikOw76Rx9dmKSiN2nZ11mLC5km7DlRTygpX84etRGKal+MMBs+6/Bwe1yGLuPFD+mdJJYR586BJ5aWitW4pJJOmE8CVjzm2ZjGEt3Zy/DASPM9WK6mAuxfG2CIxrs8246C2ah0ueDz3iR2s8+Myme1Kf9W2t35C/vEnQmS0JqBF9x+Uvh0bI13nNNqrGDE2GQL80X6mVmEOOcnURGzA9Cku+7v+wSbB2x20xZIBellGoxrLEd5ir7JSssD3L5b0nVzGpov5tgBxijMjUOeE0vwUAKxc6tDA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j0yu92vhZGUh7cx6lEt9W2mm53kRfHU0/Ja65RANmvM=; b=hqwR+a3tgScQ1J1zVD8A323btV5aaHmQzmnlhw5VU9imX8R4hWd8xKJlpAYELtiWv6VMeRQj9fcq6EgeTrcECsNT2y5g2YQ3ExmmjUDkiI+RPvekLCtHCtOXT+PLsyp11EmlFVuR1ZeZ1yE6um9ty/QzgSX+ixZ7sT46AHeYwijS2dt2/K4kHkuPzLWKRiUsq7S7trXOX1AkSNWwFKDnEJs6E+ZZppkJnDIYzrnc3csp4pRgBF0rlntHLFJCkuI5ZBBmda8ZIKQKxwE1aQkWwNPFbikyO5OioKBEvQROasfyCJaljOwVWwYp1EjP0w0ZH+ydeZAdQuuk5I1lz88Jhw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j0yu92vhZGUh7cx6lEt9W2mm53kRfHU0/Ja65RANmvM=; b=oXhUi2NSTKp8UXCMRxRG7YAxEX3nfPSQt71/cVcYCo3vCEI9PaG751liRuON+FOqqjfWbe++OR+IfSfEfkN6QVE96UcJm39ptux/U0lGDKJoR1FER+rj5QtYjrEcw5mDX1sxQmbjSmMcb+qETE45o1lXElVhK1WqMMpUSeVLe88=
Received: from AM0PR0702MB3603.eurprd07.prod.outlook.com (2603:10a6:208:22::25) by AM0PR0702MB3683.eurprd07.prod.outlook.com (2603:10a6:208:16::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.12; Wed, 15 Apr 2020 07:32:02 +0000
Received: from AM0PR0702MB3603.eurprd07.prod.outlook.com ([fe80::9c11:1589:8e18:5209]) by AM0PR0702MB3603.eurprd07.prod.outlook.com ([fe80::9c11:1589:8e18:5209%3]) with mapi id 15.20.2921.024; Wed, 15 Apr 2020 07:32:02 +0000
From: =?utf-8?B?QmFsw6F6cyBWYXJnYSBB?= <balazs.a.varga@ericsson.com>
To: =?utf-8?B?TWljaGFlbCBUw7x4ZW4=?= <tuexen@fh-muenster.de>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "last-call@ietf.org" <last-call@ietf.org>, "detnet@ietf.org" <detnet@ietf.org>, "draft-ietf-detnet-mpls.all@ietf.org" <draft-ietf-detnet-mpls.all@ietf.org>
Thread-Topic: Tsvart last call review of draft-ietf-detnet-mpls-05
Thread-Index: AQHV+xcxhqoZGhGq0EKRWwvNtUw3mqh55YyA
Date: Wed, 15 Apr 2020 07:32:02 +0000
Message-ID: <AM0PR0702MB360375EF1CEA08AFFB22485FACDB0@AM0PR0702MB3603.eurprd07.prod.outlook.com>
References: <158431049935.18052.15833035673726505804@ietfa.amsl.com>
In-Reply-To: <158431049935.18052.15833035673726505804@ietfa.amsl.com>
Accept-Language: hu-HU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.a.varga@ericsson.com;
x-originating-ip: [188.143.71.76]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4842bff1-cd43-41e1-edb5-08d7e10f1763
x-ms-traffictypediagnostic: AM0PR0702MB3683:
x-microsoft-antispam-prvs: <AM0PR0702MB368378FA4A9E72622428E438ACDB0@AM0PR0702MB3683.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0374433C81
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0702MB3603.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(396003)(136003)(366004)(346002)(376002)(64756008)(66476007)(66556008)(85182001)(186003)(66574012)(26005)(6506007)(110136005)(4326008)(55016002)(478600001)(8676002)(54906003)(86362001)(81156014)(66946007)(66446008)(85202003)(9686003)(71200400001)(8936002)(7696005)(76116006)(53546011)(33656002)(52536014)(316002)(2906002)(5660300002); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 823a3ffw9KUVZ65TzVyY9KjT2iZr+a8O48BE+lyIWnn5/ZpkUngiSTEDzbNwLAPI39GAzAgLDsL6W7V6X6EtTWdhNYieYgUkZHG+h31X/ZX1A/VELxi6rO7/KJeKaIpmkbVFbFyLr36/RnGrkXWtCONBtHDVFOYMWvPgm6LvbEG9qMtLawQrACoRj7sgXpUHquiKcZ9M8MQhRu8WQBhBO6pnf/8qpIh8O9lWBo7YZkfe5RPBjWN2tbGjZv8IKDPWMIUt58b7DvRDDUMg4N6z+/M2rG0ZWDwiGRcwywdSbgSdyU7X7ZevKbG7CRkKo1fySWMBM4p454syNYxUHgbyXyXe1G8ep1HDH0jXtQsFxb+kfc/kw8NKsVLDxuDpSqhbAZnCMR63QxtwnVzm5R4WVFJbzqi3zt9PBBnwKuIK6F+56wq8p2SQrsPnYsOF3sCj
x-ms-exchange-antispam-messagedata: b5WWVtZEnkE8abhfrb0RmZj9OlH+Ca6ukbiM9g6LDK99gf4f3YRvG8XvqB6v02vskPPqHkAkamKpxpwQFEM5g3wggDfhUQiTM7CLFuN03BbCkZm4QZgZB0TG6t0F+3nj5qOaYaG8bYD6/ZBCrLSMQQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4842bff1-cd43-41e1-edb5-08d7e10f1763
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2020 07:32:02.8618 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: dOpIxPHfVXmphqiUAkvCbQHfnx4EiD6B4BfqT+MRKvZN8z9XTI8AYfdnvnsHulIVMBIdk+N1aD4mTgGu8qqHoxIWsOnHf9VTqVlN2ZostVk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3683
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/epa5-LHhW39c77gr2jm-WmZF4x8>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-detnet-mpls-05
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Apr 2020 07:32:07 -0000

Hi Michael,

Thanks for the review. 

The sequence number space is a circular one, similar to sequence number used in 
IEEE TSN (Time-Sensitive Networks) or rfc4385. Regarding the control word we 
refer to rfc4385. d-CW differs from rfc4385, that 0 (zero) is part of the sequence 
number space.

We have text to highlight these below Figure 5.:
" ... The values carried in this field can wrap
   and it is important to note that zero (0) is a valid field value. "

If You think that would make the text clearer I can add a specific text to highlight 
the circular characteristics of the sequence number space. This change would be 
immediately after Figure 5, where Sequence Number bits are defined.

OLD
"   Sequence Number (bits 4 to 31)
      An unsigned value implementing the DetNet sequence number."
NEW
"   Sequence Number (bits 4 to 31)
      An unsigned value implementing the DetNet sequence number.
      The sequence number space is a circular one."

Does it resolve your concerns?

Thanks
Bala'zs


-----Original Message-----
From: Michael Tüxen via Datatracker <noreply@ietf.org> 
Sent: Sunday, March 15, 2020 11:15 PM
To: tsv-art@ietf.org
Cc: last-call@ietf.org; detnet@ietf.org; draft-ietf-detnet-mpls.all@ietf.org
Subject: Tsvart last call review of draft-ietf-detnet-mpls-05

Reviewer: Michael Tüxen
Review result: Ready with Issues

This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information.

When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review.

The document is in general pretty generic, so I don't know if the following was discussed on the mailing list and is described in other documents, but I think it should be described here or at least pointers to the specification describing it should be inserted.

The problems I see are related to the Sequence Number you introduce in Figure 5. If, used it is a 16-bit or 28 bit number. From the example you provide, it seems that it is used like a Serial Number as described in RFC 1982. The receiver uses this number for the PEF and POF. If this is correct, this puts a limitation regarding the number of outstanding packets on the sender. I don't see this limit being mentioned and I don't see how this limit is enforced, since there does not seem to be an acknowledgement.
The document states that an implementation MAY limit the maximum number of sequence numbers being tracked. What happens if the receiver runs out of this limit? How does a receiver protect itself against a sender playing games with the sequence number? Limiting the resources is only a MAY, so how is this done in the general case?