[Detnet] AD review of draft-ietf-detnet-controller-plane-framework-11

[Ketan Talaulikar <[e-mail]>]

Hello Authors/WG,

Thanks for your work on this document. I found it to be very well written
and easy to follow. I believe it will serve as a good foundation for
further work.

The document is mostly ready. I do have a few
comments/suggestions/questions that I am providing below inline in the
idnits output of v11 of the document. Please check for the tag <EoRv11> at
the end of the email and if you don't find it then likely the email has
been truncated; you should then look at the WG mailer archive for the full
version.

Thanks,
Ketan

Detail review follows:

13      Deterministic Networking (DetNet) Controller Plane Framework
14            draft-ietf-detnet-controller-plane-framework-11

<major> The title, abstract, and introduction talk about "controller" while
much of sections 3 and 4 seem open to both (centralized) controller,
distributed control plane or a mix of both. I am left wondering whether
using
"control plane" instead of "controller plane" is a more suitable title ...

152   *  Allow flow instantiation requests to originate in an end
153      application (via an Application Programming Interface (API), via
154      static provisioning, or via a dynamic control plane, such as a
155      centralized SDN controller or distributed signaling protocols.

<nit> please expand SDN

162   *  Also in the case of the DetNet MPLS data plane, support the DetNet
163      service sub-layer, which provides DetNet service functions such as
164      protection and reordering through the use of packet replication,
165      duplicate elimination, and packet ordering functions (PREOF).

<nit> Please put reference to RFC8665 where the PREOF term is defined.

260 3.2.  SDN/Fully Centralized Control Plane

262   In the fully SDN/centralized configuration model, flow/UNI
263   information is transmitted from a Centralized User Controller or from
264   applications via an API/ northbound interface to a Centralized
265   Controlle.  Network node configurations for DetNet flows are

<nit> s/Controlle/Controller

290   1.  Controller collects topology information and DetNet capabilities
291       of the network nodes via an IGP and/or BGP-LS [RFC7752];

<minor> 7752 has been obsoleted by 9552

377 4.3.  PREOF Support

379   DetNet path redundancy is supported via packet replication, duplicate
380   elimination, and packet ordering functions (PREOF).  A DetNet flow is
381   replicated and goes through multiple networks paths to avoid packet
382   loss caused by device or link failures.  In general, current control
383   plane mechanisms that can be used to establish an explicit path,
384   whether distributed or centralized, support point-to-point (P2P) and
385   point-to-multipoint (P2MP) path establishment.  PREOF requires the
386   ability to compute and establish a set of multiple paths (e.g.,
387   multiple LSP segments in an MPLS network) from the point(s) of packet
388   replication to the point(s) of packet merging and ordering.  Mapping

<question> Do these paths need to be disjoint?

403   In traditional MPLS domains, a dynamic control plane using
404   distributed signaling protocols is typically used for the
405   distribution of MPLS labels used for forwarding MPLS packets.  The
406   dynamic signaling protocols most commonly used for label distribution
407   are LDP [RFC5036], RSVP-TE, and BGP [RFC8277] (which enables BGP/
408   MPLS-based Layer 3 VPNs [RFC4384] and Layer 2 VPNs [RFC7432]).

<major> EVPN has been missed which seems quite the popular flavor these days
:-) ... I bring it up because we are talking service labels and their
signaling protocols below. Also pick the best/closest reference (if
possible)
for RSVP-TE.

448   Note that the DetNet MPLS and IP data planes described in [RFC8964]
449   and [RFC8939] were constructed to be compatible with both types of
450   segment routing, SR-MPLS [RFC8660] and SRv6 [RFC8754].

<minor> In addition to RFC8754, please also add RFC8986 for SRv6 - that is
the
spec which introduced the ability to define behaviors and functionalities
that
can be associated with SRv6 SIDs (and which could be leveraged by DetNet).

 473 5.1.1.2.  Passive PM

475   Passive PM monitors the actual service traffic in a network domain in
476   order to measure its performance without having a detrimental affect
477   on the network.  As compared to Active PM, Passive PM is much
478   preferred for use in DetNet domains.

<major> Any reference or pointer to how Passive PM works? Is it by adding
some
OAM bits in the data packets itself, or some other techniques?

511 8.  Security Considerations

513   This document provides a framework for the DetNet controller plane,
514   and does not include any protocol specifications.  Any future
515   specification that is defined to support the DetNet controller plane
516   is expected to include appropriate security considerations.  For
517   overall security considerations of DetNet see [RFC8655] and
518   [I-D.ietf-detnet-security]

<minor> Are there any security requirements or aspects related to DetNet
Control(ler) Plane that should be identified here?

<EoRv11>