Reviewer: Zheng Zhang Review result: Has Issues Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. 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 Thanks to Ronald in 't Velt for his shepherd work, which showed the discussion process of this draft in great detail, and helped us understand the relationship between this draft and several other drafts. 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? 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. 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. 97 98 The extension defined in this document is referred to as "DiffServ 99 Aware Credit Window" or, more simply, the "DA Credit" extension. The 100 reader should be familiar with both the traffic classification and 101 credit window control mechanisms defined in 102 [I-D.ietf-manet-dlep-traffic-classification] and 103 [I-D.ietf-manet-dlep-credit-flow-control]. 104 105 This document defines a new DLEP Extension Type Value in Section 2 106 which is used to indicate support for the extension. 107 1081.1. Key Words 109 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 115 1162. Extension Usage and Identification 117 118 The extension defined in this document is composed of the mechanisms 119 and processing defined in 120 [I-D.ietf-manet-dlep-traffic-classification] and 121 [I-D.ietf-manet-dlep-credit-flow-control]. To indicate that the 122 DiffServ Aware Credit Window Extension is to be used, an 123 implementation MUST include the DiffServ Aware Credit Window Type 124 Value in the Extensions Supported Data Item. The Extensions 125 Supported Data Item is sent and processed according to [RFC8175]. 126 Any implementation that indicates use of the DiffServ Aware Credit 127 Window Extension MUST support all Messages, Data Items, the DiffServ 128 Traffic Classification Sub-Data Item, and all related processing 129 defined in [I-D.ietf-manet-dlep-traffic-classification] and 130 [I-D.ietf-manet-dlep-credit-flow-control]. 131 132 The DiffServ Aware Credit Window Extension Type Value is TBA1, see 133 Section 5. 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. 146 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? 162 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. 173 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. [End of Review] -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
