Re: [Tsv-art] Tsvart last call review of draft-ietf-detnet-flow-information-model-11

Balázs Varga A <balazs.a.varga@ericsson.com> Fri, 27 November 2020 14:44 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 1D4DF3A0EF4; Fri, 27 Nov 2020 06:44:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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 ghgcAsWZ353e; Fri, 27 Nov 2020 06:44:43 -0800 (PST)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2089.outbound.protection.outlook.com [40.107.21.89]) (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 95E8E3A0EF2; Fri, 27 Nov 2020 06:44:42 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mx2l8I1Yz8h0oflYOtZuFyziQJZeyxXvKRoVnJZkNoFipz3p7ybMIN3XFbVhRKaYCFUM+1PX90XJbO65KGLUyGN7oLS/MH6VllS9fU3Ad36iR2Pn/qPntbhQTvvE0SMOV1MiVLOCWLd833qgTgFyEas6YeIq4wjS8zDwtLF99ekioo67RnMT96PfiHIpwYRaHqHebU/a7bhtbgbH07C69cWDlaJnlUdg56AwAOaNEHr0X/MhzPTxFiT0EDr1VgM1psDd9RL3L0kf4bKR8m5HojqawMev56iUWewXxckLJXUY2DnLhJaWbhbXIikXc+DOFm2VBEmVD5HOLzp76P4wBA==
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=bzVTzTPJJ1VVJILmeskXmAEnLL+82EoG+bEheDjhM5I=; b=hbS19u8WXqzx8h4pxFHFkDW2OOfDOnpAvTpqw17wuZV0joy3qkL8fcugKyREuVua/maimLD/xxAHfLJmUKSWvVgJOMDwt59Zjq5v3cO2A5KL503U9YXFpwN7wM2GNrY3z2v5lK+SkN4auHsnCuy5Li0X1oIPmvfk+sjJyeqAukSG4a9tuAnHrjWBn+3F93EHJE9ymWUhPqdSH33k1QLT+KDv9WJy2S/gplYUq25q4uf5zD3YMGVbPnokyBnKZMDfaKXFE5so8JpRJnsOdD3UKCI5ZGOksuFte9ZqSNznGsgFC5i62/QbsG+nWNixDYcpo/Nww87YyLFdSFUtooe32g==
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=bzVTzTPJJ1VVJILmeskXmAEnLL+82EoG+bEheDjhM5I=; b=mqfkzz70CK5WXu81ieHgYIqhYRgCrRY4WfwjlBI8I2BSFU4VvlEpXh0zAFOXKHThNypvtORBS8mKnQCaeqO3hcdnyRuZxUVd6D9i1v+NKBl7Zbl2YQYKBP/mPVCn4pXtF5Kxc5EtUrmCFNaLky/Si40uPzMNG9ZQy9OiP+/cYWk=
Received: from AM0PR0702MB3603.eurprd07.prod.outlook.com (2603:10a6:208:22::25) by AM4PR07MB3220.eurprd07.prod.outlook.com (2603:10a6:205:8::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.9; Fri, 27 Nov 2020 14:44:40 +0000
Received: from AM0PR0702MB3603.eurprd07.prod.outlook.com ([fe80::9580:e13a:7917:16dd]) by AM0PR0702MB3603.eurprd07.prod.outlook.com ([fe80::9580:e13a:7917:16dd%3]) with mapi id 15.20.3611.022; Fri, 27 Nov 2020 14:44:40 +0000
From: =?utf-8?B?QmFsw6F6cyBWYXJnYSBB?= <balazs.a.varga@ericsson.com>
To: Lou Berger <lberger@labn.net>, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "detnet@ietf.org" <detnet@ietf.org>, "draft-ietf-detnet-flow-information-model.all@ietf.org" <draft-ietf-detnet-flow-information-model.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: Tsvart last call review of draft-ietf-detnet-flow-information-model-11
Thread-Index: AQHWtH9PLoUqtRoW1kmmDjiM7DWrmqnaJaHwgAH4d4CAAA7fIA==
Date: Fri, 27 Nov 2020 14:44:40 +0000
Message-ID: <AM0PR0702MB36033AA39F6E39F1E33FEC53ACF80@AM0PR0702MB3603.eurprd07.prod.outlook.com>
References: <160469618665.20223.2730384752002027021@ietfa.amsl.com> <AM0PR0702MB36035E9217B8115BAFB747F5ACF90@AM0PR0702MB3603.eurprd07.prod.outlook.com> <00838a04-350c-2c68-9644-886b8330ce9c@labn.net>
In-Reply-To: <00838a04-350c-2c68-9644-886b8330ce9c@labn.net>
Accept-Language: hu-HU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: labn.net; dkim=none (message not signed) header.d=none;labn.net; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [94.21.57.97]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1f4ec383-7302-4461-7b8c-08d892e2f86e
x-ms-traffictypediagnostic: AM4PR07MB3220:
x-microsoft-antispam-prvs: <AM4PR07MB32205C974D73C6F2C634CEA5ACF80@AM4PR07MB3220.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: X/CyfqQQ1+woxuyrRlwOfx7ANRbC4hd2wNi15MYHjnxsgnFl2SoEGWDbEEJie8pyrJqlB9H/F3G33f3vvDd9NKbmW6Maooujr0luM9yQno8qhyZNeY0kEJ3WrQrctQZfLezfAw7n4yA6UeI6areQNJh1+pi/7BPnZqJrfUn7IetznKEFDJ2yt6XnQjGfGN3b26FfG4pXCK6kn9L3B82mU/WKOts8+60YZHaKSjE4fQjVeqqiQ81+wThSXzjzRz7E6k1iRShbYZaQL6V8PYee+dBiku9Q69IBK0rJHvN7ecBqgVVRLERQEsu2V8RkkOsMwXLZMNGXPfCm+979YGLcqacKUeE83xtCaOGY0Gv1BSMB6E9L0yee3lTorhHiPTY02rYAErTyyBgctRWMSE1lfQ==
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; SFS:(4636009)(39860400002)(376002)(396003)(346002)(136003)(366004)(9686003)(2906002)(55016002)(8676002)(8936002)(76116006)(66946007)(66476007)(64756008)(66556008)(66446008)(52536014)(66574015)(83380400001)(4326008)(316002)(478600001)(6506007)(54906003)(110136005)(53546011)(966005)(71200400001)(26005)(85202003)(86362001)(186003)(85182001)(7696005)(33656002)(5660300002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?L0RnRWUwSm1xY3dwOGNpUXFvdDdGcHV5dWxhQWw2cnczWk1PeHNBQiszRjBM?= =?utf-8?B?dFR6U3gwS2lEb0tjcDdadE5aeVdSWXRoRzk4a0pXQkhZVTJTQVdCWmRuWTR6?= =?utf-8?B?b0N3Y3l5eTN1a1loYS9MQXN3SFQxWENwTmcwQVdSSDdFeDkrMmYySldYQUNx?= =?utf-8?B?WUVpM01GeUNKMERJY09HK01jcUttU2FwTXVDQVJCWnVGQmZnRGxQeFkrTjg0?= =?utf-8?B?SnlFT2t1Z01sRGdrU0VsTXdHckdpYkZPaFgwSlhpYW1RRDJIQTZQOTJSOHZJ?= =?utf-8?B?ZjU1VFVId3JmZWxqam1QTms0MjJqaG1EU29tb3hDVXJncmpqUlRnSzB5bXQ0?= =?utf-8?B?MkxZMno5b2xvYzJ6Nm16cGI5Y1lJVVp5eHc3SFJmREI2VzBvdkhlei85STVm?= =?utf-8?B?bXFaTGxPaWs2cUpmQ0ZidjRMeXhBV3pqd2d4ZDlCOCs3cjJCS1hVMmxvd3hM?= =?utf-8?B?TkRHRTlNNlRCbytLQzVzaWRVYUVSemllOGU3NkVjMDlNTUJCV2xGTlRuczAy?= =?utf-8?B?b2JBVmhHUDRPRkJJditjTVd0cG1nYlJiVVk0SEdpMVYrR3BmcW9SOTNXZFBQ?= =?utf-8?B?RFpQM1l0T1BicitjL3M0d3I2M1ZhbEtIOEhxSTd2Ukt1cU81SzE1UlU0RWln?= =?utf-8?B?RzBlNU1IUGZMTUQ3TkU4WTZUZlFDbHdVR3g4QVQ2NG16aklCbi80TzQvaXFu?= =?utf-8?B?RzZCRHduS2NCano0OUI1ZnVjTG8yWXU4NjNTSGVMajk1VWNWdDhrUnhvU0xn?= =?utf-8?B?bTJjaEJKSnVOdUQ3VXJNc3J1NXkzdXZoWHVCS0I2dk9pVkpCNGp1K2Zla1cy?= =?utf-8?B?WlNRUWl0djNnR2xkWjlMMi9RT0NEZ0tpZFVzbHhRQ2pZSS9rZml4WWI0Mjd2?= =?utf-8?B?Q0JBdGh6TEE1QW1ld3pNNXdwdS9naTBxdEhYWXV5N0tGV0taTlBYWG5SYnZs?= =?utf-8?B?a3NLaUVLZ0FKSTJMZUhKMnBTVG9tY3pORjJaSWRObUNYKzc3RGZsMUdjbnMr?= =?utf-8?B?d2phZmdYZTlCOS9xRHRnMHBRUVFEMkFlYTVydFp3Qjk5ay9Tc2dVeUhDWFlU?= =?utf-8?B?TWVwWU5yTTQ3QlUxUUZITHdjcGRFK1NpeXUvMFZWdG11eDlpbXhkNjRwWk0r?= =?utf-8?B?c05pOGJRR01GOWZzMmc2NmdGaW5nNkxQeGJ6bEZGQ0NhbktPdEQxUVdUdmlk?= =?utf-8?B?ZGVEZTdrVVRsNEhHZWRmOE9paGp4SlRHTWhwT3g3MVVrYUk4RGpHSndnb0wv?= =?utf-8?B?V3JwWjVSOFArQWtSVzNMOEZZK1lEclpOS2JaVmNuZG55dVcyalRBT24rSGlq?= =?utf-8?Q?DH4Y6L77Sxc7c=3D?=
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-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR0702MB3603.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1f4ec383-7302-4461-7b8c-08d892e2f86e
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2020 14:44:40.0356 (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: cezsEkk+rIoENn1tbA4udsLYE3m7HI6gTBIscM3sUa938NkJMXiiaMZataFPrQ6AiA+MHICtsjylVtSIT9gBKYt5aJLKfogRBI115QNgCxY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3220
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/nY8EjzXtrwgqhd5sPXE9gJJyW1I>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-detnet-flow-information-model-11
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: Fri, 27 Nov 2020 14:44:45 -0000

Hi Lou,

Yes, that was wrong. Furthermore, it is always great to be in-line with TSN definitions as well.
I will correct it.
<NEW>
"DnServiceRank value 0 is the highest priority."
<END>

Cheers
Bala'zs

-----Original Message-----
From: Lou Berger <lberger@labn.net> 
Sent: Friday, November 27, 2020 2:45 PM
To: Balázs Varga A <balazs.a.varga@ericsson.com>om>; Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>be>; tsv-art@ietf.org
Cc: detnet@ietf.org; draft-ietf-detnet-flow-information-model.all@ietf.org; last-call@ietf.org
Subject: Re: Tsvart last call review of draft-ietf-detnet-flow-information-model-11

Hi Balázs

Are you sure about this:

           ... High value rank gets preferred over a low value one.

I think this the opposite of what we normally do, for example:

[https://tools.ietf.org/html/rfc3209#section-4.7.1]

     "The value 0 is the highest priority."

[https://tools.ietf.org/html/rfc5440#section-7.11]

     "The value 0 is the highest priority."

[https://tools.ietf.org/html/rfc2328 and https://tools.ietf.org/html/rfc1195]

throughout the docs and in the algorithm sections: lowest cost/metric is considered better

Lou


On 11/26/2020 4:14 AM, Balázs Varga A wrote:
> Hi Olivier,
>
> Many thanks for your great review. Please see my comments inline (noted <BV>).
>
> Changes are included: 
> https://protect2.fireeye.com/v1/url?k=dee2e172-8179d836-dee2a1e9-861d4
> 1abace8-9257af7700956e47&q=1&e=c6fd3bf1-3566-493c-be5c-8b64514e8a3e&u=
> https%3A%2F%2Fgithub.com%2Fdetnet-wg%2Fdraft-ietf-detnet-flow-informat
> ion-model%2Fcommit%2F5aed47ec5b0215cf4b6ac16d67271fe7387f7179%23diff-6
> 49f76b4565f6dacda6b86e0092367053c96a461fb5b114a62facdde502db7e7
>
> Please, let us know if you intend to finetune the resolution of your comments.
>
> Thanks & Cheers
> Bala'zs
>
> -----Original Message-----
> From: Olivier Bonaventure via Datatracker <noreply@ietf.org>
> Sent: Friday, November 6, 2020 9:56 PM
> To: tsv-art@ietf.org
> Cc: detnet@ietf.org; 
> draft-ietf-detnet-flow-information-model.all@ietf.org; 
> last-call@ietf.org
> Subject: Tsvart last call review of 
> draft-ietf-detnet-flow-information-model-11
>
> Reviewer: Olivier Bonaventure
> Review result: Almost Ready
>
> 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.
>
> This review was requested in a very short period of time and I could not read all the Detnet related materials. I focus on issues that could be relevant for the transport area.
>
> The introduction indicates that the Detnet architecture supports IP and MPLS flows, but section 5.4.2 indicates that and IP flow can be specified using the following attributes :
>
>    a.  SourceIpAddress
>     b.  DestinationIpAddress
>     c.  IPv6FlowLabel
>     d.  Dscp (attribute)
>     e.  Protocol
>     f.  SourcePort
>     g.  DestinationPort
>     h.  IPSecSpi
>
> I would personally qualify the flows that include transport layer information as layer-4 and not IP flows. Maybe a note in the introduction should be mentioned. In the document, it is unclear to me whether some of these attributes are optional or can be specified as wild cards. Maybe this is described in another document.
>
> <BV> Yes, these attributes are defined in [I-D.ietf-detnet-ip] and they can be specified as wild cards. For a given network scenario some of them or all of them may be used. In case of using e, f, and g, for DetNet IP Flow Identification then as you wrote it can be treated as layer-4 flow.
> In section 5.4.2. the sentence before the attribute list points explicitly to [I-D.ietf-detnet-ip]. I have added a note at the end of the section.
> <NEW Text>
>     Using wild cards for these attributes are specified in [I-D.ietf-detnet-ip].
> <END>
>
>
>
> The information model defines various attributes. Some of the definitions are very precise and mention the measurement unit. For others, this is less clear.
> For example, intervals are defined in units of nanoseconds, but payloadsize is not defined as a number of bytes.
>
> <BV> Right. I have added new text to clarify this in section 5.5 in the paragraph after the list of those attributes.
> <OLD Text>
>    These attributes can be used to describe any type of traffic (e.g.,
>     CBR, VBR, etc.) and can be used during resource allocation to
>     represent worst case scenarios.
> <NEW Text>
>     These attributes can be used to describe any type of traffic (e.g.,
>     CBR, VBR, etc.) and can be used during resource allocation to
>     represent worst case scenarios. Interval is specified as an integer
>     number of nanoseconds. MaxPayloadSize is specified in octets
>     per second.
> <END>
>
>
>
> Some information elements appear unclear to an external observer like me:
>
> 5.9.4.  Maximum Loss of the DetNet Flow
>
>     MaxLoss defines the maximum Packet Loss Ratio (PLR) requirement for
>     the DetNet flow between the Ingress and Egress(es).
>
> There is no measurement interval define for the packet loss ratio.
>
> <BV> Right. Proposed correction.
> <OLD Text>
>     MaxLoss defines the maximum Packet Loss Ratio (PLR) requirement for
>     the DetNet flow between the Ingress and Egress(es).
> <NEW Text>
>     MaxLoss defines the maximum Packet Loss Ratio (PLR) requirement for
>     the DetNet flow between the Ingress and Egress(es) and the loss
>     measurement interval.
> <END>
>
>
> 5.9.6.  Maximum Misordering Tolerance of the DetNet Flow
>
> The definition is unclear and does not make it easy to measure this 
> value
>
> <BV> Right. Current text add some hints for measurement, but added some more clarification. Proposed correction.
> <OLD Text>
>     MaxMisordering describes the tolerable maximum number of packets that
>     can be received out of order.  The maximum allowed misordering can be
>     measured for example based on sequence number.  The value zero for
>     the maximum allowed misordering indicates that in order delivery is
>     required, misordering cannot be tolerated.
> <NEW Text>
>     MaxMisordering describes the tolerable maximum number of packets
>     that can be received out of order. The value zero for the maximum
>     allowed misordering indicates that in order delivery is required,
>     misordering cannot be tolerated.
>
>     The maximum allowed misordering can be measured for example based
>     on sequence number. The difference of sequence number values in
>     consecutive packets at the Egress cannot be bigger than
>     "MaxMisordering + 1".
> <END>
>
>
> 6.3.1.  Minimum Bandwidth of the DetNet Service
>
> >From the definition, it is unclear to me whether the payload only is
>> used to
> compute the bandwidth or whether this includes the headers and if so 
> which
>
> <BV> Right. It excludes additional DetNet header (if any). Proposed clarification.
> <OLD Text>
>     MinBandwidth is the minimum bandwidth that has to be guaranteed for
>     the DetNet service.  MinBandwidth is specified in octets per second.
> <NEW Text>
>     MinBandwidth is the minimum bandwidth that has to be guaranteed for
>     the DetNet service.  MinBandwidth is specified in octets per second and
>     excludes additional DetNet header (if any).
> <END>
>
>
>
> I was surprised by the following paragraph
>
> 6.4.  Connectivity Type of the DetNet Service
>
>     Two connectivity types are distinguished: point-to-point (p2p) and
>     point-to-multipoint (p2mp).  Connectivity type p2mp is created by a
>     transport layer function (e.g., p2mp LSP).  (Note: mp2mp connectivity
>     is a superposition of p2mp connections.)
>
> Does the note precludes the utilisation of multicast to support the detnet service ? If so, I don't think that this restriction should be part of an information model. It should be specified in an architecture document.
>
> <BV> Right, text is rather misleading and not accurate enough. Multicast is allowed. Proposed clarification.
> <OLD Text>
>     Two connectivity types are distinguished: point-to-point (p2p) and
>     point-to-multipoint (p2mp).  Connectivity type p2mp is created by a
>     transport layer function (e.g., p2mp LSP).  (Note: mp2mp connectivity
>     is a superposition of p2mp connections.) <NEW Text>
>     Two connectivity types are distinguished: point-to-point (p2p) and
>     point-to-multipoint (p2mp).  Connectivity type p2mp may be created by a
>     forwarding function (e.g., p2mp LSP).  (Note: from service perspective
>     mp2mp connectivity can be treated as a superposition of p2mp
>     connections.)
> <END>
>
>
> 6.6.  Rank of the DetNet Service
>
>     The DnServiceRank attribute provides the rank of a service instance
>     relative to other services in the DetNet domain.  DnServiceRank
>     (range: 0-255) is used by the network in case of network resource
>     limitation scenarios.
>
> >From this description I do not know whether a high value rank gets more
> resource than a low value one. I would suggest to clarify this in the definition of the rank.
>
> <BV> Right. :--))) Proposed clarification. Sentence added at the end of the paragraph.
> <OLD Text>
>     The DnServiceRank attribute provides the rank of a service instance
>     relative to other services in the DetNet domain.  DnServiceRank
>     (range: 0-255) is used by the network in case of network resource
>     limitation scenarios.
> <NEW Text>
>     The DnServiceRank attribute provides the rank of a service instance
>     relative to other services in the DetNet domain.  DnServiceRank
>     (range: 0-255) is used by the network in case of network resource
>     limitation scenarios. High value rank gets preferred over a low value
>     one.
> <END>
>