Re: [dtn] Robert Wilton's Block on charter-ietf-dtn-01-00: (with BLOCK and COMMENT)

[Rick Taylor <[e-mail]>]

Hi Rob,

Thanks for the comments.  I think your block is justified as we need to have this discussion, and hopefully I can clarify a few points.

Comments inline...

> -----Original Message-----
> From: Robert Wilton via Datatracker [mailto:[e-mail]]
> Sent: 09 September 2021 10:37
> To: The IESG
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Robert Wilton's Block on charter-ietf-dtn-01-00: (with BLOCK and
> COMMENT)
> 
> Robert Wilton has entered the following ballot position for
> charter-ietf-dtn-01-00: Block
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-dtn/
> 
> 
> 
> ----------------------------------------------------------------------
> BLOCK:
> ----------------------------------------------------------------------
> 
> Sorry for putting a block on this charter, but the charter for this WG seems to
> be moving significantly into the network management space.
> 
> In particular, this work seems to be predicated on the assumption that it
> better to define a custom management protocol and data modelling
> language for
> the DTN use case rather than reusing, or extending, the existing network
> management work defined in NETMOD and NETCONF WGs.  This may be the
> right
> answer, but it not intuitively obvious to me that this is the case (some
> further details provided in the comment section).

I think you're half right here.  We have evidence that management protocols designed for an end-to-end connected environment do not work in a deeply delayed/disrupted network.  For example the New Horizons probe floating past Pluto runs a management stack that is a precursor to the work we are attempting to standardise in the WG.  That being said, although the existing OPS area protocols appear unsuitable, the data-modelling is most definitely not.

What we would like to do is to re-use all the great work from NETMOD, but use an alternate transport and processing model more suitable for end-to-end disconnected environments.  We are all absolutely agreed that this does not mean discarding/ignoring all of NETCONF/NETMOD and rolling our own management stack, but it does mean some parts have to be different.

> 
> (1) There needs to be more discussion with relevant WGs (NETCONF,
> NETMOD, CORE)
> to understand whether the existing network management protocols and data
> modelling language could cover the DTN use case, or be reasonably extended
> to
> do so.

Yes, there does.  We have attempted to engage with those groups, but as with all IETF WG's they are busy and focussed on their own topics, and turning up with a weird corner cases is disruptive.  Ed and I have had extensive discussions with Dean Bogdanovic over the years, which has helped us understand what is re-useable and what is not - and there is a great deal of cross over with the timed/event-driven config change proposals that reappear constantly in NETMOD - however, we have failed to attract enough attention to get the work adopted within the OPS area.

> 
> (2) If there is consensus that the existing IETF management stack can be
> reasonably extended to cover the DTN use case, then there should be
> discussion
> about where that work is done, which would depend on the specific nature
> of the
> work.

The same argument has been put forward by Alvaro concerning Routing in DTNs.  Yes, there is definite cross-over here, however, we have a really productive (small) WG that is focussed and keen to continue working on these topics, and would rather not dilute the enthusiasm by moving this work into another area.  This does not preclude constant communication and peer-review with the relevant WGs in other areas, but we believe for this charter cycle the authoring should remain in the DTN WG, even if Transport isn't really the correct area.  In the future, yes, let's split the work into the correct areas, but currently we do not have the huge interest to support such fragmentation.

To this end, we are adding a mandate to the end of the charter to force the WG to work closely with the relevant areas on each cross-over topic, and for management that is definitely NETMOD.

> 
> (3) Otherwise, if the consensus is that an entirely separate management
> stack
> is appropriate, then I think that the solution needs to be tightly constrained
> to the DTN use case, and not framed as a generic asynchronous management
> architecture.

We don't believe it is appropriate, and I am actively pushing back against a bespoke solution for DTNs.  We must be able to re-use YANG modelling, and best-practice from NETCONF, even if XML-over-SSH is not the correct transport.  In my mind AMA could be rebranded as DTNCONF: fundamentally the round-trip time and the transport is the issue - the rest is 'just' good old data modelling.

> 
> Rob
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Looking at the charter, and specifically at draft-ietf-dtn-ama-01,
> Asynchronous
> Management Architecture (which is in DTN WGLC), it seems to be built on the
> following assumptions:
>  - network management is generally synchronous

Not necessarily 'synchronous', that might have been a bad choice of word, but definitely end-to-end connected:  I can send 'do this' and pretty promptly I can get an acknowledgement.  In a DTN, this assumption does not hold.

> 
>  - A different data modelling language (i.e., not YANG) is required to model
>  asynchronous management data

Fair criticism.  The original work was done in isolation and was based on an SNMP-like approach.  Since then much work has gone into moving to a more NETMOD transactional approach, but there is still work to do.  At their core the current drafts expect a tree-like data model that can be modified, so mapping to YANG is entirely feasible, and this an area where we definitely need help.

> 
>  - There are no efficient encodings of management data modelled in YANG.

I'm not sure this is correct.  I think the original authors looked at NETCONF 1.0 and worried when they saw lots of XML on the wire.

> 
> But I don't think that these assumptions necessarily hold:
>  - NMDA, RFC 8342, was architected with a goal of supporting an eventual
>  consistency model (specifically, supporting a temporal separation between
>  sending the desired configuration to a device and the device enacting that
>  configuration)

We (I) am unaware of this work, and I suppose that underlines the need for better communication between the WGs.  This 'temporal separation' is an important part of management in DTNs (where the round-trip time may be hours), but there is a need for autonomy as well which may go further that RFC 8342 (I need to go read it).

> 
>  - In addition to NETCONF, there are also the RESTCONF and CoAP
> management
>  interface protocols that could be considered.

We have looked at both RESTCONF and CoAP.  RESTCONF suffers the same problems as NETCONF because it requires a bidirectional end-to-end connection, but the CBOR encodings in CoAP are really useful - the numbering system is odd, but there is a lot that can be reused.

> 
>  - YANG Push, RFC 8641, allows for subscriptions to be notified of when data
>  changes, or periodic updates.  I.e., entirely push rather than pull.

We have spent a lot of time with Eric Voit as he was first proposing YANG-Push.  The concepts are similar, and there are lots of parts that can be re-used, but it's more of a 'call me back when something changes' model (i.e. just restarting the end-to-end connection) than what is needed in a DTN.  What we really need is YANG-Post, i.e. "send me a mail when something happened, telling me what you just did"

> 
>  - YANG just models data and that should have no bearing on whether the
>  protocol mechanisms used to move that data are synchronous or
> asynchronous.

Completely agree.

> 
>  - The CBOR and CBOR SID encodings of YANG data encode the data in a
> compact
>  binary format.

Completely agree. I personally think the CBOR-SID numbering is a bit weird for IOT reasons, but there is definite opportunities to align.  The DTN stack is built on CBOR, so it should be a no-brainer.

In conclusion:  I think you raise a good list of points that should be discussed before anything DTN management related is standardised.  Some we have considered, some we have not, but either way we must make sure that there is good communication and peer-review between the WGs/Areas.  As I've said above, purely to keep up the good momentum we have in the current DTN WG, I do not want to split the work out - but it should be considered when the WG next re-charters.  In the meantime we will mandate that the management documents must receive early review by the OPS area, and the chairs will ensure that WG does not disappear off to make bespoke management solutions, as long as the relevant OPS Area WGs can find the cycles to help us avoid mistakes?  Ironically Alvaro has also expressed an interest in seeing the AMA work done in the Routing Area, as it addresses some charter items for the MANET working group - so we really are spanning many areas here - but I firmly believe we need to grow more before we can consider reorganisation.

Cheers,

Rick