[manet] Re: Rtgdir last call review of draft-ietf-manet-dlep-da-credit-extension-18

Donald Eastlake <d3e3e3@gmail.com> Mon, 16 December 2024 05:05 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932ACC14F682; Sun, 15 Dec 2024 21:05:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Level:
X-Spam-Status: No, score=-1.855 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4yJN85t7azf; Sun, 15 Dec 2024 21:05:15 -0800 (PST)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D4AC14F6BC; Sun, 15 Dec 2024 21:05:15 -0800 (PST)
Received: by mail-qk1-x735.google.com with SMTP id af79cd13be357-7b6ea711805so354633985a.1; Sun, 15 Dec 2024 21:05:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734325514; x=1734930314; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JPSw+IV6tZdnq7+NNj1l46lCVSVKM/KcmfTy3/l7pFU=; b=UPigoVEWjL33s2Lzc0KOill2aYrlcf289rRVW6vrYooFjvWsf5raDqCy0e8vw/MwcK GEwdmVCt8/bD8+FbjlxOGMQWViBokfypkVDL34iOUU3BoHXRLD57hJbUzc0+5vjAC8vT qQlpprXbsbtTtv/tuxUU9AwgduZG8v5Xpoi3MAxrRjw4eIMS4oiabp/MbB1GZOEpIO8N ZLczunyooEHXNWK51rYdq9JKgMVjbi/nsjxIfX1MDKSvQ6IgajvFtljW/TSFzr+Z3JUh CK7VGB7CtG625rrWTdHofurgu3ydQm8poC9UAjoOKmvFZJajWfnt5Z/7rT3B2soTKgGm 1AcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734325514; x=1734930314; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JPSw+IV6tZdnq7+NNj1l46lCVSVKM/KcmfTy3/l7pFU=; b=k5VwSoAG3P1SLdFtKjKIeu7EoG0tTnLfgysfSyJtpZd1zh7Yl+mcyICahY/WMyzeD3 0JxPdfv0eQtuPJ9KT9htU7vRI08NjYyQV64K8ned8GVJyOgun4PelDl1sqVh239mNO8b NGXKN6w0fQrJDEUmdvAFpRrzAyGOGk2vb9QQqSqJe548qD+qBES6GzbhOq9714V4eSp0 zLjI6iWzKceZa4RMM6HDSUpdQm3cHGxb53M+ZMyaeX78Q8TSvUUL49qwslgOfNHGOAxB 1MXeFyJWwK5N95i4NX20zvkjAM3PjqHfTpZIluy+QP8BQNGCaToWRBuqiMRW+BvNTDTf r1Tg==
X-Forwarded-Encrypted: i=1; AJvYcCVoWLmv5M8usf8R6z2cVRoLYgQTIyIw8uLtntzZ3ayXLToc9eKG5bdJXkTrFVmSeeUVneVUBHDezJ5TnsT4Zs5z1AyWoeB3LM7t+a5755/CAsNQEaEBWYkhaQkoC8A=@ietf.org, AJvYcCXJdLkwwjXku4xB6z/gGluiv+VG+48eOuPdygr2uNVjmZpIU5zo3xKBge+9XYgfTKgO3vpjY+M=@ietf.org, AJvYcCXbW/0TNob9bEDqc4DwtVDOu6jZ0KMB1w/Vg30KWYit00/Oixn9EnRMqEI6Gx958wndtaUNYVcBvRl5@ietf.org
X-Gm-Message-State: AOJu0YxunOLdp7UBteMj7HAmmx7nzqZbtGszFaKftWnX81Hd3w8NLRuS j4M3bez7vNHgan9ALJGeZoBJ7MbUnajVVezmnlDTTumT4lI1fT4+qU/Dpkd6HZA9aBBgSQLdF3h UceLqGrxS7tkVvM4nMjPGrVSnududK6BF
X-Gm-Gg: ASbGncv+efnmKhoTNRJQ+XYkBYLuwhJKO7sFFOdAGGI9YMDBZ9IL1OYOi0l+ogEJJRA ylwHStmVW72/L3uryTtNnBLhCT9prhnrZB09f6CA=
X-Google-Smtp-Source: AGHT+IGJIsHPDM6YJiBtVDtxYSQRvtIuGQbqneNJr2BzlAZiEv5+KQnIDsvsYD7VA++N5VWStRPiPC1StB9ivdJfr74=
X-Received: by 2002:a05:620a:8807:b0:7b6:dc74:82b1 with SMTP id af79cd13be357-7b6fbecaf7amr1920048985a.7.1734325514202; Sun, 15 Dec 2024 21:05:14 -0800 (PST)
MIME-Version: 1.0
References: <CAF4+nEG2aeM8NXuvQ9APnx_+yFPrMFV22CexFsPQM-Qx-oizjw@mail.gmail.com> <20241125091819967HZo7DPvL2q9f_2-HuVwvL@zte.com.cn>
In-Reply-To: <20241125091819967HZo7DPvL2q9f_2-HuVwvL@zte.com.cn>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Mon, 16 Dec 2024 00:05:03 -0500
Message-ID: <CAF4+nEHDmSz-sPR2bdaacQRq8RjogfY-Si+u6=CRcA0j7fXZ3g@mail.gmail.com>
To: zhang.zheng@zte.com.cn
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: PWIENPF2C6RPK3WSRVW4BMB5BAURJCIV
X-Message-ID-Hash: PWIENPF2C6RPK3WSRVW4BMB5BAURJCIV
X-MailFrom: d3e3e3@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-manet.ietf.org-0; header-match-manet.ietf.org-1; header-match-manet.ietf.org-2; header-match-manet.ietf.org-3; header-match-manet.ietf.org-4; header-match-manet.ietf.org-5; header-match-manet.ietf.org-6; header-match-manet.ietf.org-7; header-match-manet.ietf.org-8; header-match-manet.ietf.org-9; header-match-manet.ietf.org-10; header-match-manet.ietf.org-11; header-match-manet.ietf.org-12; header-match-manet.ietf.org-13; header-match-manet.ietf.org-14; header-match-manet.ietf.org-15; header-match-manet.ietf.org-16; header-match-manet.ietf.org-17; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: rtg-dir@ietf.org, draft-ietf-manet-dlep-da-credit-extension.all@ietf.org, last-call@ietf.org, manet@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [manet] Re: Rtgdir last call review of draft-ietf-manet-dlep-da-credit-extension-18
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/_Z_T0fYO-wWK71OiTlyE5A-8rAk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Owner: <mailto:manet-owner@ietf.org>
List-Post: <mailto:manet@ietf.org>
List-Subscribe: <mailto:manet-join@ietf.org>
List-Unsubscribe: <mailto:manet-leave@ietf.org>

Hi Sandy,

On Sun, Nov 24, 2024 at 8:18 PM <zhang.zheng@zte.com.cn> wrote:
> Hi Donald,
>
> thanks for the update!
>
> The new version looks good to me.
>
> One suggestion is regarding the security considerations section, since the abbreviation 'PCP' and 'VID' appear for the first time in the document, it would be better to add the full names.

These have been expanded in revision
draft-ietf-manet-dlep-da-credit-extension-20. A similar improvement
has been made in draft-ietf-manet-dlep-ether-credit-extension-08.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com

> Thanks,
> Sandy
>
>
>
> Original
> From: DonaldEastlake <d3e3e3@gmail.com>
> To: 张征00007940;
> Cc: rtg-dir@ietf.org <rtg-dir@ietf.org>;draft-ietf-manet-dlep-da-credit-extension.all@ietf.org <draft-ietf-manet-dlep-da-credit-extension.all@ietf.org>;last-call@ietf.org <last-call@ietf.org>;manet@ietf.org <manet@ietf.org>;
> Date: 2024年11月25日 04:53
> Subject: Re: Rtgdir last call review of draft-ietf-manet-dlep-da-credit-extension-18
> Hi Sandy,
>
> Note that https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-da-credit-extension-19 has been posted if you would like to look at the changes.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e3e3@gmail.com
>
>
> On Wed, Nov 20, 2024 at 9:21 PM <zhang.zheng@zte.com.cn> wrote:
>>
>> Hi Donald,
>>
>> thank you for your responding!
>>
>> looking forward for the update.
>>
>> Thanks,
>>
>> Sandy
>>
>>
>>
>> Original
>> From: DonaldEastlake <d3e3e3@gmail.com>
>> To: 张征00007940;
>> Cc: rtg-dir@ietf.org <rtg-dir@ietf.org>;draft-ietf-manet-dlep-da-credit-extension.all@ietf.org <draft-ietf-manet-dlep-da-credit-extension.all@ietf.org>;last-call@ietf.org <last-call@ietf.org>;manet@ietf.org <manet@ietf.org>;
>> Date: 2024年11月21日 07:21
>> Subject: Re: Rtgdir last call review of draft-ietf-manet-dlep-da-credit-extension-18
>> Hi,
>>
>> Thanks for your review. See below.
>>
>> On Tue, Aug 6, 2024 at 3:39 AM Zheng Zhang via Datatracker
>> <noreply@ietf.org> wrote:
>> > Reviewer: Zheng Zhang
>> > Review result: Has Issues
>> >
>> > Hello,
>> >
>> >...
>> >
>> > Document: draft-ietf-manet-dlep-da-credit-extension-18
>> > Reviewer: Zheng(Sandy) Zhang
>> > Review Date: 06 Aug 2024
>> > IETF LC End Date: n/a
>> > Intended Status: Standards Track
>> >
>> > ...
>> >
>> > Summary: As an independent standard track draft, This draft needs
>> > clarification on some details: Major Issues: 1. Is this extension
>> > usable only when both the router and the modem support it? 2. If you
>> > need to use it when both the router and the modem support it, then
>> > in section 3 the "Management Considerations" must make this
>> > clear. And it is necessary to explain the detailed impact on session
>> > establishment. 3. Can this extension be used together with “IEEE
>> > 802.1Q Aware Credit Window” defined in
>> > draft-ietf-manet-dlep-ether-credit-extension?  If so, how do we
>> > determine the priority?
>>
>> See below.
>>
>> > Detailed Review (provided below with major/minor/nits tagging in IDnits o/p):
>> >
>> > 65 1.  Introduction
>> > 66
>> > 67    The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175].
>> > 68    This protocol provides the exchange of link related control
>> > 69    information between DLEP peers.  DLEP peers are comprised of a modem
>> > 70    and a router.  DLEP defines a base set of mechanisms as well as
>> > 71    support for possible extensions.  This document defines one such
>> > 72    extension.
>> > 73
>> > 74    The DLEP specification does not include any flow control capability..
>> > 75    There are various flow control techniques theoretically possible with
>> > 76    DLEP.  This document defines a DLEP extension which provides a
>> > 77    DiffServ-based flow control mechanism for traffic sent from a router
>> > 78    to a modem.  Flow control is provided using one or more logical
>> > 79    "Credit Windows", each of which will typically be supported by an
>> > 80    associated virtual or physical queue.  A router will use traffic flow
>> > 81    classification information provided by the modem to identify which
>> > 82    traffic is associated with each credit window.  Credit windows may be
>> > 83    shared or dedicated on a per flow basis.  See
>> > 84    [I-D.berger-manet-dlep-ether-credit-extension] for an Ethernet-based
>> > 85    version of credit window flow control.
>> >
>> > [nits] [I-D.berger-manet-dlep-ether-credit-extension] needs to be replaced by
>> > the adopted working group document.
>>
>> OK.
>>
>> > 86
>> > 87    This document uses the traffic classification and credit window
>> > 88    control mechanisms defined in
>> > 89    [I-D.ietf-manet-dlep-traffic-classification] and
>> > 90    [I-D.ietf-manet-dlep-credit-flow-control] to provide credit window
>> > 91    based flow control based on DLEP destinations and DiffServ [RFC2475]
>> > 92    DSCPs (differentiated services codepoints).  The defined mechanism
>> > 93    allows for credit windows to be shared across traffic sent to
>> > 94    multiple DLEP destinations and DSCPs, or used exclusively for traffic
>> > 95    sent to a particular destination and/or DSCP.  The extension also
>> > 96    supports the "wildcard" matching of any DSCP.
>> >
>> > [minor] The last sentence has no direct relevance to this draft.
>>
>> It seems to be an example of "... multiple ... DSCPs". While the
>> sentence might not be necessary, I don't see how it hurts anything.
>>
>> > 98    ...
>> > 134
>> > 1353.  Management Considerations
>> > 136
>> > 137   This section provides several network management guidelines to
>> > 138   implementations supporting the DiffServ Aware Credit Window
>> > 139   Extension.
>> > 140
>> > 141   The use of the extension defined in this document SHOULD be
>> > 142   configurable on both modems and routers.
>> > 143
>> > 144   Modems SHOULD support the configuration of DSCP to credit window
>> > 145   (queue) mapping.
>> >
>> > [major] If the above "SHOULD" need to be replaced with "MUST"? If not, it is
>> > necessary to clarify the processing process when one party does not support it.
>>
>> As provided in RFC 8175:
>>         Extensions supported by
>>    an implementation MUST be declared to potential DLEP participants
>>    using the Extensions Supported Data Item (Section 13.6).  Once both
>>    DLEP participants have exchanged initialization Messages, an
>>    implementation MUST NOT emit any Message, Signal, Data Item, or
>>    status code associated with an extension that was not specified in
>>    the received initialization Message from its peer.
>>
>> Some words about this or pointer to the above could be included in the
>> ether-credit-extension and da-credit-extension drafts.
>>
>> > 147   Modems MAY support the configuration of the number of credit windows
>> > 148   (queues) to advertise to a router.
>> > 149
>> > 150   Routers may have limits on the number of queues that they can support
>> > 151   and, perhaps, even limits in supported credit window combinations,
>> > 152   e.g., if per destination queues can even be supported at all.  When
>> > 153   modem-provided credit window information exceeds the capabilities of
>> > 154   a router, the router SHOULD use a subset of the provided credit
>> > 155   windows.  Alternatively, a router MAY reset the session and indicate
>> > 156   that the extension is not supported.  In either case, the mismatch of
>> > 157   capabilities SHOULD be reported to the user via normal network
>> > 158   management mechanisms, e.g., user interface or error logging.
>> > 159
>> > 160   In all cases, if credit windows are in use, traffic for which credits
>> > 161   are not available MUST NOT be sent to the modem by the router.
>> >
>> > [major] The above three paragraphs are completely same with
>> > draft-ietf-manet-dlep-credit-flow-control section 2.4. However, it is not
>> > directly related to this draft. It is recommended to add here the impact of
>> > this extension on the session establishment between the Router and the Modem,
>> > as well as the impact if the configuration changes. And if this extension can
>> > be used together with “IEEE 802.1Q Aware Credit Window” defined in
>> > draft-ietf-manet-dlep-ether-credit-extension, Which one has higher priority?
>>
>> Traffic classification information is provided in the Session
>> Initialization Response Message and can be changed in the Session
>> Update Message. As provided in Section 2.3.1 of
>> draft-ietf-manet-dlep-traffic-classifiction:
>>    In cases where both Traffic Classification Sub-Data Item types are
>>    defined, matching on Ethernet information takes precedence. More
>>    specifically, when a packet matches both a DSCP indicated in a
>>    DiffServ Traffic Classification Sub-Data Item (Section 2.2) and a
>>    VID/PCP identified in an Ethernet Traffic Classification Sub-Data
>>    Item (Section 2.3), then the TID associated with the matching
>>    VLAN/PCP MUST be used.
>>
>> Some words about this or pointer to the above could be included in the
>> ether-credit-extension and da-credit-extension drafts.
>>
>> > 1634.  Security Considerations
>> > 164
>> > 165   This document defines a DLEP extension that uses DLEP mechanisms and
>> > 166   the credit window control and flow mechanisms defined in
>> > 167   [I-D.ietf-manet-dlep-traffic-classification] and
>> > 168   [I-D.ietf-manet-dlep-credit-flow-control].  The defined extension
>> > 169   exposes vulnerabilities similar to existing DLEP messages, e.g., an
>> > 170   injected message resizes a credit window to a value that results in a
>> > 171   denial of service.  The security mechanisms documented in [RFC8175]
>> > 172   can be applied equally to the mechanism defined in this document.
>> >
>> > [major] If the extension configuration changes affects the session
>> > establishment between the Router and the Modem, the potential security impact
>> > needs to be clarified.
>>
>> I am not sure exactly what you are looking for. I expect we will be making some
>> changes to the Security Considerations section based on the changes
>> that reviewers have requested in drat-ietf-dlep-ether-credit-extension-06.
>>
>> > 1745.  IANA Considerations
>> > 175
>> > 176   This document requests one assignment by IANA.  All assignments are
>> > 177   to registries defined by [RFC8175].
>> > 178
>> > 1795.1.  Extension Type Value
>> > 180
>> > 181   This document requests 1 new assignment to the DLEP Extensions
>> > 182   Registry named "Extension Type Values" in the range with the
>> > 183   "Specification Required" policy.  The requested value is as follows:
>> > 184
>> > 185
>> > 186                  +======+==============================+
>> > 187                  | Code | Description                  |
>> > 188                  +======+==============================+
>> > 189                  | TBA1 | DiffServ Aware Credit Window |
>> > 190                  +------+------------------------------+
>> > 191
>> > 192                  Table 1: Requested Extension Type Value
>> >
>> > [nits] There is only one application, which can be merged into the main section.
>>
>> OK.
>>
>> Thanks,
>> Donald
>> ===============================
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  2386 Panoramic Circle, Apopka, FL 32703 USA
>>  d3e3e3@gmail.com
>>
>> > [End of Review]
>>
>>
>