[manet] Re: Rtgdir last call review of draft-ietf-manet-dlep-da-credit-extension-18

[Donald Eastlake <[e-mail]>]

Hi Sandy,

Note that
https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-da-credit-extension-19
has been posted if you would like to look at the changes.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]


On Wed, Nov 20, 2024 at 9:21 PM <[e-mail]> wrote:

> Hi Donald,
>
> thank you for your responding!
>
> looking forward for the update.
>
> Thanks,
>
> Sandy
>
>
> <http://www.zte.com.cn/>
>
>
> <http://www.zte.com.cn/>
> Original
> *From: *DonaldEastlake <[e-mail]>
> *To: *张征00007940;
> *Cc: *[e-mail] <[e-mail]>;
> [e-mail] <
> [e-mail]>;[e-mail]
> <[e-mail]>;[e-mail] <[e-mail]>;
> *Date: *2024年11月21日 07:21
> *Subject: **Re: Rtgdir last call review of
> draft-ietf-manet-dlep-da-credit-extension-18*
> Hi,
>
> Thanks for your review. See below.
>
> On Tue, Aug 6, 2024 at 3:39 AM Zheng Zhang via Datatracker
> <[e-mail]> wrote:
> > Reviewer: Zheng Zhang
> > Review result: Has Issues
> >
> > Hello,
> >
> >...
> >
> > 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
> >
> > ...
> >
> > 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?
>
> See below.
>
>
> > 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.
>
> OK.
>
> > 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.
>
> It seems to be an example of "... multiple ... DSCPs". While the
> sentence might not be necessary, I don't see how it hurts anything.
>
> > 98    ...
> > 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.
>
> As provided in RFC 8175:
>         Extensions supported by
>    an implementation MUST be declared to potential DLEP participants
>    using the Extensions Supported Data Item (Section 13.6).  Once both
>    DLEP participants have exchanged initialization Messages, an
>    implementation MUST NOT emit any Message, Signal, Data Item, or
>    status code associated with an extension that was not specified in
>    the received initialization Message from its peer.
>
> Some words about this or pointer to the above could be included in the
> ether-credit-extension and da-credit-extension drafts.
>
>
> > 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?
>
> Traffic classification information is provided in the Session
> Initialization Response Message and can be changed in the Session
> Update Message. As provided in Section 2.3.1 of
> draft-ietf-manet-dlep-traffic-classifiction:
>    In cases where both Traffic Classification Sub-Data Item types are
>    defined, matching on Ethernet information takes precedence. More
>    specifically, when a packet matches both a DSCP indicated in a
>    DiffServ Traffic Classification Sub-Data Item (Section 2.2) and a
>    VID/PCP identified in an Ethernet Traffic Classification Sub-Data
>    Item (Section 2.3), then the TID associated with the matching
>    VLAN/PCP MUST be used.
>
> Some words about this or pointer to the above could be included in the
> ether-credit-extension and da-credit-extension drafts.
>
> > 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.
>
>
> I am not sure exactly what you are looking for. I expect we will be making some
> changes to the Security Considerations section based on the changes
> that reviewers have requested in drat-ietf-dlep-ether-credit-extension-06.
>
> > 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.
>
> OK.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  [e-mail]
>
> > [End of Review]
>
>
>