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

Hi Gunter,

On Mon, Feb 3, 2025 at 11:04 AM Gunter Van de Velde via Datatracker
<[email protected]> wrote:
> Gunter Van de Velde has entered the following ballot position for
> draft-ietf-manet-dlep-ether-credit-extension-08: No Objection
>
> ...
>
> ----------------------------------------------------------------------
> 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 the 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. "

That re-wording looks good to me./

> 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. "

Looks good to me.

> 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. "

This text also seems reasonable to me..

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email protected]

> Kind Regards,
> Gunter Van de Velde
> Routing Area Director
>
>
>

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