Re: [dtn] [EXT] Robert Wilton's Discuss on draft-ietf-dtn-dtnma-10: (with DISCUSS and COMMENT)

["Birrane, Edward J." <[e-mail]>]

Rob,

  Thank you for the review of this document.

  Some responses and recommendations are in-line below.  To the best of my ability, I have tried to enumerate individual responses as EJB_D# (for discusses) and EJB_C# (for comments) to help track the conversation. 

  Something that I think is important to call out early (hence here) is that this document is not meant to provide a "competing" or a "start from scratch" architecture for network management. It is meant to express, as a logical level, the approach for managing in a DTN environment.  As you mention, some of the things we are discussing do not exist yet, but there is some work proceeding.  Adopting that work so that the physical architecture and implementations can map to this logical architecture is how we have envisioned our way forward.

-Ed

---
Edward J. Birrane, III, Ph.D. (he/him/his)
Chief Engineer, Space Networking
Space Systems Implementation Branch
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
  

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> I have raised a discuss because of how this document is framed:
> 
> - It explains some of the requirements that are specific to managing devices
> in
> DTNs.  For me, the key one really being the unreliable availability of the
> network meaning synchronous RPCs are not a great idea, and there is a
> stronger
> emphasis on remote agents.

EJB_D0: I think we agree here that DTN management has unique properties.


 
> - It then critiques the existing IETF network management architecture, but
> this
> description seems to be incorrect and inaccurate in various places.

EJB_D1: This section is not meant to be a critique of the existing management architecture. In September of 2021 when this document was originally titled "draft-ietf-dtn-ama" you requested that this document change, in part, to document specific requirements for DTNs and understand "what aspects of those requirements are not met by current network management protocols (NECONF, RESTCONF, CORECONF), YANG." (link to tail end of that thread is here: https://mailarchive.ietf.org/arch/msg/dtn/Yq9zJi8lcQTjEOMtLhLf1-F0mlA/). 

EJB_D1: In June of 2023 an early opsdir review of draft-ietf-dtn-dtnma-5 was performed, which made suggestions on improving Section 5 (and other parts of the document).  All requested updates were agreed upon and incorporated into the dtnma document.  That review can be located at: https://mailarchive.ietf.org/arch/msg/dtn/QQ1lr9r8ytHP7Z7iFHWgzJHYEkA/

EJB_D1: All of which is to say that the intent of Section 5 is simply to respond to the request to explain where there are currently unmet gaps. 

EJB_D1: We would recommend taking an editing pass through Section 5 to remove any language which would be critical of existing architecture (at large) which was never the intent and to be more clear that this is relating to the specific case of DTNs. And to remove unnecessary details from that section as these ecosystems, by their nature, will continue to evolve over time. 



> - It then uses that critique as a justification as to why the existing IETF
> network management solutions cannot be used out of the box to meet the
> requirements of the DTN architecture.  Whilst I agree that this is true - I
> also think that with a relatively small amount of work, or enhancements

EJB_D2: I also agree that this is true, and think that we can make a clearer expression of that for Section 5, as I recommend in EJB_D1.



> (many
> of which are in the process of being pursued for other reasons), it would be
> possible to extend the existing IETF network management architecture to
> work
> for DTN.  I.e., I don't regard the existing text in sections 5 and 6 to really
> justify a new management architecture rather that reusing and extending
> what is

EJB_D3: I believe we also mostly agree with this statement. For example, subsequent work for this should endeavor to use YANG for modeling autonomy capabilities and we would expect protocols such as RESTCONF and CORECONF (where those are options) to be able to transport information between managed and managing devices.

EJB_D3: Recommend that we make this intent clearer in Section 5 to avoid a misreading.



> already there.  This doesn't mean that a new architecture is not justified,
> only that I think that this document currently doesn't really do a good job of
> making the case.  Hence, I wonder whether the real justification is because

EJB_D4: I think that if we agree that there are unmet needs for the DTN environment (EJB_D2) and that the architecture determined to be needed by the DTNWG for DTN management can be worked in large part with existing structures (EJB_D3) then I hope this addresses the expressed concern here.



> the
> proposed management architecture is much closer to how these devices are
> managed today and hence it is less of shift in mindset?

EJB_D5: This approach does represent how some devices are managed today, but also how they are likely to be managed for some time to come (this does include many space platforms). To that extent, we did not intend this architecture to be part of work in a research group.

EJB_D5: Part of the motivation of this work is to explain how trusted autonomy approaches in this area could be well expressed using the capabilities of IETF mechanisms (as discussed in EJB_D3). 



> - Finally, I haven't reviewed the proposed architecture in great detail, but I
> think that the command based aspect of it, is potentially inferior to the
> intent based approach in regular network management architecture, that I
> believe is a more robust approach.

EJB_D6: I am not sure if this is part of the overall discuss, but many platforms operating in often disconnected environments will first rely on the determinism of a command-based approach. That is not mutually exclusive to also having an intent-based approach. Intent-based approaches might be dangerous in networks that you cannot reach physically and cannot query synchronously (including the query of adjacent nodes). The possibility of applications and systems managed within a DTN diverging in an unanticipated way could make it too risky for only intent-based approaches.  I do think there is room for command-based approaches. 

EJB_D6: Would some additional language here to explain the benefit of command-based approaches over intent-based approaches help make sure this point of view is better explained?



> (2) p 0, sec
> 
>    This document describes a DTN management architecture (DTNMA)
>    suitable for managing devices in any challenged environment but, in
>    particular, those communicating using the DTN Bundle Protocol (BP).
>    Operating over BP requires an architecture that neither presumes
>    synchronized transport behavior nor relies on query-response
>    mechanisms.  Implementations compliant with this DTNMA should expect
>    to successfully operate in extremely challenging conditions, such as
>    over uni-directional links and other places where BP is the preferred
>    transport.
> 
> As per my other comments, because I believe that the existing IETF network
> management architecture already does, or is mostly on the path to
> supporting
> many of the requirements, then if a new management architecture is
> required
> here, then I think that its scope should be narrowed to only work over the BP
> protocol.

EJB_D7: Since this an informational document, I am not sure that would be a normative statement were we to add it.

EJB_D7: Further, we would not want to create an impression that protocols such as CORECONF could not carry this information, even in a BP network.



> Specifically, I think that it is much better for the wider industry to converge
> on using the existing NETCONF/RESTCONF/CORECONF + YANG(XML, JSON,
> CBOR+/-SIDs)
> architecture where possible rather than fragmenting to different competing
> solutions.

EJB_D8: Hopefully this is at least partially addressed in EJB_D3. 


 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> (3) p 4, sec 1.2.  Requirements Language
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> this
>    document are to be interpreted as described in [RFC2119].
> 
> Please update this to use the newer requirements text in RFC 8174.

EJB_C1: Pursuant to other review, since we removed the single "MUST" in this document, we will also remove this section.


 
> (4) p 18, sec 5.2.  XML-Based Protocols
> 
>    Several network management protocols, including NETCONF [RFC6241],
>    RESTCONF [RFC8040], and CORECONF [I-D.ietf-core-comi], share the same
>    XML information set [xml-infoset] to describe the abstract data model
>    necessary to manage the configuration of network devices.  Each
>    protocol, however, provides a different encoding of that XML
>    information set.
> 
> I don't think that it is correct to describe these protocols to be XML based,
> and to list them under an "XML-Based Protocol" section.
>
> Whilst it was correct that NETCONF and YANG were originally standardised
> for
> using XML, they have, or are, all somewhat evolving beyond that:
> 
> - YANG already has JSON, and CBOR+/-SIDs encodings in addition to XML.
> 
> - RESTCONF is HTML based rather than XML, and already supports XML and
> JSON
> encodings of the YANG data, with CBOR surely to follow.
> 
> - NETCONF is still XML based, but really the RPCs are defined in YANG, and
> we
> are already considering enhancing a future version of NETCONF to support a
> CBOR
> based encoding, primarily for streamed operational data.
> 
> - CORECONF isn't XML based, but instead uses a CoAP based tight encoding
> of
> HTML verbs with CBOR encoding of the YANG data.
>
> (5) p 18, sec 5.2.1.  The YANG Data Model
> 
>    *  YANG notifications [RFC8639] and YANG-Push notifications [RFC8641]
>       allow a client to subscribe to the delivery of specific containers
>       or data nodes defined in the model, either on a periodic or "on
>       change" basis.  These notification events can be filtered
>       according to XPath [xpath] or subtree [RFC6241] filtering as
>       described in [RFC8639] Section 2.2.
> 
> Today, some of YANG Push is quite heavy weight, i.e., the resync
> requirement,
> and some of the on-change requirements, but I suspect that a future lighter
> version of YANG Push may happen (that is closer to how gNMI telemetry
> works).
>
> (6) p 19, sec 5.2.1.  The YANG Data Model
> 
>    1.  Size.  Data nodes within a YANG model are referenced by a
>        verbose, string-based path of the module, sub-module, container,
>        and any data nodes such as lists, leaf-lists, or leaves, without
>        any explicit hierarchical organization based on data or object
>        type.  Existing efforts to make compressed identifies for YANG
>        objects (such as SIDs) are still relatively verbose (~8 bytes per
>        item) and do not natively support ways to glob multiple SIDs.
> 
> On the wire, I would expect CBOR SIDs to probably average of being 2 bytes
> each, depending on how the models are structured.  The CBOR SID encoding
> only
> encodes the difference between child node SID and its parent node SID, so if
> the models are structured sensibly, and CBOR SIDs are allocated sensibly,
> then
> they will generally only be 1 or 2 bytes long.
> 
> (7) p 19, sec 5.2.1.  The YANG Data Model
> 
>    2.  Protocol Coupling.  A significant amount of existing YANG tooling
>        presumes the use of YANG with a specific management protocol.
> 
> I don't think that this is correct.  E.g., OpenConfig uses YANG but doesn't use
> NETCONF - instead they have defined their own transport protocol using
> gRPC
> (called gNMI), which also serves as an alternative to YANG Push.
>
> (8) p 19, sec 5.2.1.  The YANG Data Model
> 
>        RPC execution is strictly limited to those issued by the client.
> 
> This is basically true but not entirely relevant, in that there is no
> restriction that a management client cannot be run as an agent on the
> device.
> Some vendor implementations support this, to serve similar purposes
> desired by
> this architecture.  I.e., for an agent on the device to act on predicable
> events that occur on the device without interaction with a main management
> controller, either for simplicity or latency issues (e.g., take some action
> within a few msecs of when an interface goes down).
>
> (9) p 19, sec 5.2.1.  The YANG Data Model
> 
>          Commands are
>        executed immediately and sequentially as they are received by the
>        server, and there is no method to autonomously execute RPCs
>        triggered by specific events or conditions.
> 
> Please see https://www.ietf.org/archive/id/draft-ietf-netmod-eca-policy-
> 01.txt.
>  This document is adopted, but currently expired.  It would be worth
> checking
> with the authors on its current status, but there is already interest in
> standardising a data model for agents on a device to act as you describe (or at
> least similarly to what you describe).
>
> (10) p 19, sec 5.2.2.  XML-Based Management Protocols
> 
>    NETCONF [RFC6241], RESTCONF [RFC8040], and CORECONF
>    [I-D.ietf-core-comi] each provide the mechanisms to install,
>    manipulate, and delete the configuration of network devices.  These
>    network management protocols use the same XML information set, but
>    provide different encodings of the abstract data model it describes.
> 
> I don't really understand what you mean by the same XML information set.
> The
> data is modelled in YANG and encoded in XML, JSON, CBOR (with or without
> SIDs).
>  Even in the conventional network management space, it is plausible that
> over
> time there will be a migration away from XML towards JSON + CBOR.
>
> (11) p 19, sec 5.2.2.1.  NETCONF
> 
>    NETCONF is a stateful, XML-based protocol that provides a RPC syntax
>    to retrieve, edit, copy, or delete any data nodes or exposed
>    functionality on a server.  It requires that underlying transport
>    protocols support long-lived, reliable, low-latency, sequenced data
>    delivery sessions.
> 
> NETCONF is defined and used this way, but I don't think that this has to be its
> fundamental nature.  E.g., some controllers open a new NETCONF
> connection to
> make a configuration change and then close it again, and such are not really
> relying on any sort of long-lived connection.  Further, the NMDA
> architecture,
> RFC 8342, is designed around the concept of decoupling changing the
> configuration to enacting that configuration change, and monitoring it
> through
> subscriptions rather than in the RPC reply.  I.e., the architecture is already
> migrating towards a path when the synchronous reply to a NETCONF edit
> operation
> may not be all that important.
>
> (12) p 20, sec 5.2.2.2.  RESTCONF
> 
>    RESTCONF is a stateless RESTful protocol based on HTTP.  RESTCONF
>    configures or retrieves individual data elements or containers within
>    YANG data models by passing JSON over REST.  This JSON encoding is
>    used to GET, POST, PUT, PATCH, or DELETE data nodes within YANG
>    modules.
> 
> As per above, RESTCONF supports XML or JSON, and very likely CBOR in
> future,
> which would likely be a small update.
>
> (13) p 20, sec 5.2.2.2.  RESTCONF
> 
>    RESTCONF is a stateless protocol because it presumes that it is
>    running over a stateful secure transport (HTTP over TLS).  Also,
>    RESTCONF presumes that a single pull of information can be made in a
>    single round-trip.  In this way, RESTCONF is only stateless between
>    queries - not internal to a single query.
> 
> Yes, but mechanisms like YANG Push can somewhat be used to mitigate this.
> E.g., already in the gNMI world, there is a move a way from synchronous get
> requests to asynchronous requests (once or periodic) where the request is
> made
> and the results are then streamed back (either to the client, or somewhere
> else) at some point in the future.  These operations are asynchronous with
> respect to the caller.
>

EJB_C2: Let me make a few general comments on Section 5, which has had several rounds of review to date. We agree that there is active and motivating work being done in these areas, and that things will evolve and adapt over time. Further, we think that some of these evolutions will help with the DTNMA needs (and some might not). We would be happy to remove any wording from Section 5 which is incorrect (of course) and would be happy to add some statements that these protocols and encodings are evolving. 

EJB_C2: Many of the comments you make above do make us understand that the existing normative work is not currently supporting these use cases - hence the reference to the evolving work, and we think that is a good thing and its results may well be how we could implement all or most of this for DTN management. The DTNMA document is a logical architecture and is not meant to "compete" with those standards

EJB_C2: However, I would hope that Section 5 is not considered inappropriate in those cases where it has provided an accurate assessment of the limitations (for our use case) of existing work, even if there is more work coming over the next several years. 



> (14) p 21, sec 6.  Motivation for New Features
> 
>    Management mechanisms that provide DTNMA desirable properties do not
>    currently exist.
> 
> This is true - but I still believe that small enhancements, some of which are
> already planned may well get you to where you need to go without starting
> from
> scratch with an entirely new management architecture.

EJB_C3: As you mention in many of the comments above, there is active work in bringing forward elements of the proposed DTNMA already.  To that end, I don't see this document as producing a "competing" architecture, but a logical architecture that solves the DTN problem.  I am unsure of the "starting from scratch" comment. In the comment around EJB_D3 you mention this approach is closer to how these devices are managed today. DTNMA-like solutions are also in operational use today. So it is not our intent to start a new architecture. 



> (15) p 21, sec 6.  Motivation for New Features
> 
>    1.  Open Loop Control.  Freedom from a request-response architecture,
>        API, or other presumption of timely round-trip communications.
>        This is particularly important when managing networks that are
>        not built over an HTTP or TCP/TLS infrastructure.
> 
> As per above, the existing network management architecture supports this
> by
> allowing management clients to run on the device (and potentially expose
> their
> own North-bound management interfaces).

EJB_C4: Yes, but who is managing the local management clients, and what assumptions are built into that management?



> (16) p 21, sec 6.  Motivation for New Features
> 
>    2.  Standard Autonomy Model.  An autonomy model that allows for
>        standard expressions of policy to guarantee deterministic
>        behavior across devices and vendor implementations.
> 
> As per above, there is already some work happening in this area.

EJB_C5: If there is some work happening here, then that does make it a new feature.  I would hope that this emerging work is also informed by the autonomy models that have been used to keep critical assets safe when operating in delayed and denied environments, as our work has. We feel there is good utility in our autonomy model - though we also understand this might be a model used for certain purposes that are not as motivating for non-DTN autonomy approaches.

EJB_C5: Recommend replacing the text "Management mechanisms that provide DTNMA desirable properties do not currently exist" to acknowledge new, emerging development, that various approaches are being explored, and that there is a need to specify and standardize motivating principles here to understand how and which of these approaches solve our goals. 



> (17) p 21, sec 6.  Motivation for New Features
> 
>    3.  Compressible Model Structure.  A data model that allows for very
>        compact encodings by defining and exploiting common elements of
>        data schemas.
> 
> As per above, YANG CBOR SIDs already allow for a pretty compact encoding.
> This
> may still be too high for a use case, but there is a clear tradeoff here
> between flexibility vs encoding size.  E.g., if know the exact schema that is
> being encoded, and if the server sends all values, then it potentially doesn't
> need to encode the keys.  But this requires client and server being exactly in
> sync w.r.t. the data model, so it is probably less resilient to failures.

EJB_C6: Agreed that there is good focus by many on compact encodings. Perhaps we annotate that the tradeoffs here might be dependent on the assumptions of the comms environment.



> (18) p 22, sec 7.  Reference Model
> 
>    There are a multitude of ways in which both existing and emerging
>    network management protocols, APIs, and applications can be
>    integrated for use in challenged environments.  However, expressing
>    the needed behaviors of the DTNMA in the context of any of these pre-
>    existing elements risks conflating systems requirements, operational
>    assumptions, and implementation design constraints.
> 
> This is true.  But if you want to properly justify why a new architecture is
> needed, then I still think that it worth looking at what an architecture would
> look like extending the existing management infrastructure that IETF
> supports.
> Of course, there are benefits in having a targeted architecture specifically
> for your use-case, but there are also big benefits in reusing much of what is
> already there, or focussing the changes on the specific pieces that you need
> (and that then other use cases may also benefit from).

EJB_C7: Agreed, and I think that we have tried to address what we are trying to do by defining a logical architecture versus developing a competing physical architecture.  



> (19) p 23, sec 7.1.  Important Concepts
> 
>    The DTNMA differs from some other management architectures in three
>    significant ways, all related to the need for a device to self-manage
>    when disconnected from a managing device.
>    1.  Pre-shared Definitions.  Managing and managed devices should
>        operate using pre-shared data definitions and models.  This
>        implies that static definitions should be standardized whenever
>        possible and that managing and managed devices may need to
>        negotiate definitions during periods of connectivity.
> 
> This appears to be broadly the same with the regular NETCONF YANG
> management
> architecture, and is also one of the goals with the IETF YANG packages and
> versioning work
> (https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages).
> I.e.,
> so that the device can efficiently share a reference to its schema with a
> management client without needing to download the full schema for YANG
> library.

EJB_C8: I am not sure this is the same, but, again, as emerging work it is not complete and, thus, I think fair to say it is a new thing. 



> (20) p 23, sec 7.1.  Important Concepts
> 
>    2.  Agent Self-Management.  A managed device may find itself
>        disconnected from its managing device.  In many challenged
>        networking scenarios, a managed device may spend the majority of
>        its time without a regular connection to a managing device.  In
>        these cases, DAs manage themselves by applying pre-shared
>        policies received from managing devices.
> 
> As per my previous comments, I think that existing management clients are
> already starting to do this.  Perhaps a key difference here is that in regular
> network management, the agents would likely only provide an assistance
> role
> than perhaps being the primary configuration management mechanism.

EJB_C9: Being the primary configuration management mechanism is an important difference. Also, there are actions a DTNMA, manager can take beyond managing system configuration as part of the deterministic stimulus-response model. A good bit of the consideration in that model is what to restrict to allow DAs to be able to validate actions and to prevent general scripting-like issues such as infinite loops/recursions. 



> (21) p 23, sec 7.1.  Important Concepts
> 
>    3.  Command-Based Interface.  Managing devices communicate with
>        managed devices through a command-based interface.  Instead of
>        exchanging variables, objects, or documents, a managing device
>        issues commands to be run by a managed device.  These commands
>        may create or update variables, change data stores, or impact the
>        managed device in ways similar to other network management
>        approaches.  The use of commands is, in part, driven by the need
>        for DAs to receive updates from both remote management devices
>        and local autonomy.
> 
> Okay, this one we don't do, but then I'm not convinced that it is a great way
> of managing remote devices.  Mostly, the existing network management is
> moving
> towards intent based configuration.  I.e., where the data model expresses
> the
> desired configuration state for the device, and the device is responsible, on
> its own, to take whatever necessary steps are required to transition from the
> current state to reach that desired state.  It feels to me that this is more
> robust that sending a sequence of commands, because if the device isn't in
> the
> anticipated state, or if some of those commands fail, then it risks leaving the
> device is an unknown and unexpected state.  I think that sending commands
> should probably be restricted to fixing stuff when it is broken rather than as
> a mainline configuration mechanism.

EJB_C10: Certainly the command approach is the preferred approach for many critical systems operating in delayed/disrupted environments. The important aspect being understanding and predicting how a system is reacting when you cannot talk to it. Some easy examples to talk about are very expensive spacecraft, such as the command-based autonomy model for New Horizons (https://www.sciencedirect.com/science/article/pii/S0094576507000604) which took photos of Pluto or the DART mission autonomy (https://ieeexplore.ieee.org/abstract/document/10207457) which was the mission that hit asteroid Dimorphos.

EJB_C10: Which is not to say that DTN NM is only for spacecraft, but more to say that deterministic command-based systems are (and will continue to be) an important capability, and there is some part of that that can be purposed for utility in safing network functions in DTN environments.

EJB_C10: on a final note, our logical architecture here is to find good ways to explain the needs for DTNMA in a *logical* architecture and then do the work of mapping implementations and physical solutions into the body of work that is being done in the IETF. Which is the opposite of trying to come up with something new from scratch.