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

[Ketan Talaulikar <[e-mail]>]

Hi Xuesong,

Thanks for your responses and for posting the draft update. I've initiated
the IETF LC.

Thanks,
Ketan


On Sat, Jun 28, 2025 at 8:33 AM Xuesong Geng <[e-mail]> wrote:

> Hi Ketan,
>
>
>
> Thank you for the detailed review and valuable comments. The document has
> been updated and A diff from the previous version is available at:
>
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-detnet-controller-plane-framework-12
>
> Please also find some response to your comments inline.
>
>
>
> Best
>
> Xuesong
>
>
>
> *From:* Ketan Talaulikar [mailto:[e-mail]]
> *Sent:* Thursday, June 5, 2025 1:57 PM
> *To:* [e-mail]
> *Cc:* [e-mail]
> *Subject:* AD review of draft-ietf-detnet-controller-plane-framework-11
>
>
>
> 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 ...
>
>
>
> [Xuesong] Thank you for the observation. It is followed the definition in
> DetNet architecture. Thanks Lou to provide detailed explanation about the
> terminology here.
>
>
>
> 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
>
>
>
> [Xuesong] SDN has been expanded to "Software Defined Networking" in the
> updated version.
>
>
>
> 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.
>
>
>
> [Xuesong] A reference to RFC8665 has been added when introducing the PREOF
> term.
>
>
>
> 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
>
>
>
> [Xuesong] Typo corrected as suggested.
>
>
>
> 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
>
>
>
> [Xuesong] Reference updated to point to RFC9552.
>
>
>
>
>
> 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?
>
>
>
> [Xuesong] Disjoint paths are recommended for PREOF to provide path
> diversity and maximize fault tolerance, while not strictly required.
>
>
>
>
>
> 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.
>
>
>
> [Xuesong]EVPN has been added along with a reference to RFC7432. For
> RSVP-TE, we updated the reference to RFC3209, which is the primary
> reference for RSVP-TE signaling.
>
>
>
> 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).
>
>
>
> [Xuesong] RFC8986 has been added alongside RFC8754 in the updated version.
>
>
>
>
>
>  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?
>
>
>
> [Xuesong] Passive PM may rely on techniques such as in-band telemetry,
> e.g., IOAM. A reference to [RFC9326] (IOAM) has been included to illustrate
> such mechanisms.
>
>
>
> 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?
>
>
>
> [Xuesong] Thank you for the suggestion. At this stage, no specific
> security considerations unique to the DetNet controller plane have been
> identified. The existing references to general DetNet security
> considerations in [RFC8655] and [I-D.ietf-detnet-security] remain
> applicable. Future work may address more detailed security aspects as
> needed.
>
>
>
> <EoRv11>
>
>
>