DLEP IEEE 802.1Q Aware Credit Window Extension
draft-ietf-manet-dlep-ether-credit-extension-08
Yes
Jim Guichard
No Objection
Erik Kline
John Scudder
Murray Kucherawy
Orie Steele
Zaheduzzaman Sarker
No Record
Francesca Palombini
Warren Kumari
Note: This ballot was opened for revision 08 and is now closed.
Jim Guichard
Yes
Deb Cooley
No Objection
Comment
(2025-02-02)
Sent
Section 4: If changes are made to update the Security Consideration sections of draft-ietf-manet-dlep-traffic-classification and draft-ietf-manet-dlep-credit-flow-control, I recommend this draft reference one or both of those drafts. Section 4: Wildcards are literally mentioned only in the Introduction and here. I certainly don't mind the recommendation in this section, but should this be a standalone paragraph? And should it appear in some/all of the other drafts in the group? Section 4, last sentence: Does this apply to the wildcard topic? Or something else, maybe the second sentence? I think this section could use some restructuring.
Erik Kline
No Objection
Gunter Van de Velde
No Objection
Comment
(2025-02-03)
Sent
# Gunter Van de Velde, RTG AD, comments for draft-ietf-manet-dlep-ether-credit-extension-08 # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-manet-dlep-ether-credit-extension-08.txt # Many thanks for to He Jia for the RTGDIR reviews # Most of the non-blocking observations are clarifications and readability suggestions # Detailed Review # =============== 72 The DLEP specification does not include any flow control capability. 73 There are various flow control techniques theoretically possible with 74 DLEP. This document defines a DLEP extension which provides an 75 Ethernet-based flow control mechanism for traffic sent from a router 76 to a modem. Flow control is provided using one or more logical 77 "Credit Windows", each of which will typically be supported by an 78 associated virtual or physical queue. A router will use traffic flow 79 classification information provided by the modem to identify which 80 traffic is associated with each credit window. Credit windows may be 81 shared or dedicated on a per flow basis. See 82 [I-D.ietf-manet-dlep-da-credit-extension] for a DiffServ-based 83 version of credit window flow control. As specified in Section 2.3.1 84 of [I-D.ietf-manet-dlep-traffic-classification], when both DiffServ 85 and Ethernet traffic classification are specified for a flow, the 86 Ethertype information takes precedence. GV> When the word "capability" is used, then my routing brain gets triggered by IGP TLVs and BGP capability negotiation principles. I suspect that what the authors are trying to say is that DLEP does not specify any flow control procedures. GV> In addition I tried streamline the remaining part of the text also. What do you think of following rewrite: " The DLEP specification does not define any flow control mechanisms. While various flow control techniques could be theoretically implemented with DLEP, this document specifies a DLEP extension that introduces an Ethernet-based flow control mechanism for traffic transmitted from a router to a modem. This mechanism utilizes one or more logical "Credit Windows", each of which is typically associated with a virtual or physical queue. The router leverages traffic flow classification information provided by the modem to determine the appropriate credit window for a given traffic flow. Credit windows may be allocated on either a shared or a per-flow basis. For a DiffServ-based approach to credit window flow control, refer to [I-D.ietf-manet-dlep-da-credit-extension]. As specified in Section 2.3.1 of [I-D.ietf-manet-dlep-traffic-classification], when both DiffServ and Ethernet traffic classification are applied to a flow, Ethertype-based classification takes precedence. " 88 This document uses the traffic classification and credit window 89 control mechanisms defined in 90 [I-D.ietf-manet-dlep-traffic-classification] and 91 [I-D.ietf-manet-dlep-credit-flow-control] to provide credit window 92 based flow control based on DLEP destinations and Ethernet VLANs and 93 Priority Code Points. Ethernet Priority Code Point support is 94 defined as part of the IEEE 802.1Q [IEEE8021Q] tag format and 95 includes a 3-bit "PCP" field. The tag format also includes a 12-bit 96 VLAN identifier (VID) field. The defined mechanism allows for credit 97 windows to be shared across traffic sent to multiple DLEP 98 destinations, Virtual Area Netwokrs (VLANs), and Priority Code Points 99 (PCPs), or used exclusively for traffic sent to a particular 100 destination and/or VLAN and/or PCP. The extension also supports the 101 "wildcard" matching of any PCP or VID. GV> What about: " This document leverages the traffic classification and credit window control mechanisms defined in [I-D.ietf-manet-dlep-traffic-classification] and [I-D.ietf-manet-dlep-credit-flow-control] to enable credit window-based flow control based on DLEP destinations, Ethernet VLANs, and Priority Code Points (PCPs). Ethernet PCP support is specified as part of the IEEE 802.1Q [IEEE8021Q] tag format, which includes a 3-bit "PCP" field. The tag format also incorporates a 12-bit "VLAN Identifier (VID)" field. The defined mechanism allows credit windows to be shared across traffic destined for multiple DLEP destinations, Virtual Local Area Networks (VLANs), and PCPs, or to be dedicated exclusively to traffic associated with a specific destination, VLAN, and/or PCP. Additionally, this extension supports "wildcard" matching for any PCP or VID. " 166 Modems MAY support the configuration of the number of credit windows 167 (queues) to advertise to a router. 168 169 Routers may have limits on the number of queues that they can support 170 and limits on supported credit window combinations. Per destination 171 queues might not be supported at all. When modem-provided credit 172 window information exceeds the capabilities of a router, the router 173 SHOULD use a subset of the provided credit windows. Alternatively, a 174 router MAY reset the session and indicate that the extension is not 175 supported. In either case, the mismatch of capabilities SHOULD be 176 reported to the user via normal network management mechanisms such as 177 user interface messages or error logging. 178 179 In all cases, if credit windows are in use, traffic for which credits 180 are not available MUST NOT be sent to the modem by the router. GV> I find this not so easy to parse. What about the following textblob instead: " Modems MAY support configuration of the number of credit windows (queues) that they advertise to a router. Routers may impose limitations on the number of queues they can support and on the allowable credit window configurations. In some cases, per-destination queues may not be supported. If the credit window information provided by the modem exceeds the router’s capabilities, the router SHOULD utilize a subset of the advertised credit windows. Alternatively, the router MAY reset the session and indicate that the extension is not supported. In either case, any mismatch in capabilities SHOULD be reported to the user through standard network management mechanisms, such as user interface notifications or error logging. Regardless of implementation, if credit windows are in use, the router MUST NOT send traffic to the modem unless sufficient credits are available. " Kind Regards, Gunter Van de Velde Routing Area Director
John Scudder
No Objection
Mahesh Jethanandani
No Objection
Comment
(2025-02-01)
Sent
------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- Some of the text in this cluster of documents is repeated across the documents. The nits therefore follow some of that duplicated text. All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 1, paragraph 1 > The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175]. > This protocol provides the exchange of link related control > information between DLEP peers. DLEP peers consist of a modem and a > router. DLEP defines a base set of mechanisms as well as support for > possible extensions. This document defines one such extension. s/This protocol/The protocol/ Document references draft-ietf-manet-dlep-credit-flow-control-16, but -17 is the latest available revision. Section 1, paragraph 2 > ws may be shared or dedicated on a per flow basis. See [I-D.ietf-manet-dlep-d > ^^^^^^^^ In this context, "per-flow" forms an adjective and is spelled with a hyphen.
Murray Kucherawy
No Objection
Orie Steele
No Objection
Paul Wouters
No Objection
Comment
(2025-02-03)
Not sent
I support Deb's DISCUSS/Comments on security
Roman Danyliw
No Objection
Comment
(2025-02-04)
Not sent
Thank you to Behcet Sarikaya for the GENART review.
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection
Comment
(2025-02-06)
Sent
# Éric Vyncke, INT AD, comments for draft-ietf-manet-dlep-ether-credit-extension-08 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Ronald in 't Velt for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. Other thanks to Carlos Bernardos, the Internet directorate reviewer (at my request), please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-manet-dlep-ether-credit-extension-08-intdir-telechat-bernardos-2025-02-04/ (and I have read Donald's reply) I hope that this review helps to improve the document, Regards, -éric ## COMMENTS (non-blocking) ### Section 1 Should the 'unidirectional' nature of this I-D be reflected in the title ? Based on `This document defines a DLEP extension which provides an Ethernet-based flow control mechanism for traffic sent from a router to a modem` Suggest introducing "PCP" acronym when "Priority Code Points" first appears.
Francesca Palombini
No Record
Warren Kumari
No Record