Skip to main content

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