[manet] Gunter Van de Velde's No Objection on draft-ietf-man et-dlep-ether-credit-extension-08: (with COMMENT)

Gunter Van de Velde has entered the following ballot position for
draft-ietf-manet-dlep-ether-credit-extension-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-ether-credit-extension/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# 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



_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]