Hi,
Thanks for your review. See below.
On Tue, Aug 6, 2024 at 3:39 AM Zheng Zhang via Datatracker
<noreply@xxxxxxxx> 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@xxxxxxxxx
> [End of Review]
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
