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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Rick,

Thanks for the extra information.

I've put some more comments inline ...

Bringing my conclusion to the top, for this DTN charter cycle I would suggest that it would be helpful for the management aspects of DTN to focus on:

- Documenting the specific requirements for network management in DTN networks.
- Understanding what aspects of those requirements are not met by current network management protocols (NETCONF, RESTCONF, CORECONF), YANG.
- An understanding of whether it would be feasible to extend the existing network management protocols to cover those requirements.
- Good communication with NETCONF, NETMOD, and CORE WGs as these requirements are developed.

I think that once the shape of the solution is better understood it will become clear how specific the solution is to DTN and also where is the best place to progress the work.


> -----Original Message-----
> From: Rick Taylor <[e-mail]>
> Sent: 13 September 2021 10:33
> To: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: RE: Robert Wilton's Block on charter-ietf-dtn-01-00: (with BLOCK and
> COMMENT)
> 
> 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.

Okay.

I think that it would really helpful to enumerate what the DTN specific network management requirements, and whether they can be sensibly satisfied by extending the existing network management protocols, noting that there has already been some interest in extending network management protocols to support asynchronous messages (but these would probably still expect to see responses in the order of minutes rather than hours).

> 
> 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.

Some parts being different is fine/expected.

But I'm still not quite sure whether what you require for the DTN use case couldn't be accomplished by say extending NETCONF to support asynchronous messages, and a binary encoding, and a delay tolerant transport.  Also, with Alvaro mentioning MANET, I'm trying to understand whether what is being proposed is specific to DTN, or more general.

Note, the desire to add asynchronous configuration operations has come up before for NETCONF in draft-ietf-netmod-opstate-reqs-04 (also referenced below).
There have also been some discussions about adding binary encoding support to NETCONF (draft-mahesh-netconf-binary-encoding-01).

I.e., it looks like there is already some interest is enhancing NETCONF to cover some of your requirements, but it is not clear to me whether that would mean that NETCONF would cover all of them.

> 
> >
> > (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.

I think that providing regular updates to NETMOD and perhaps NETCONF/OPSAWG would be helpful.

> 
> >
> > (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.

I find it hard to know where the work should be done, because I don't have a good feel about what shape the solution should take.

> 
> 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.

I think that this will be NETMOD for the use of YANG, and possible NETCONF for your new management protocols, or extensions to the existing NETCONF management protocols.

> 
> >
> > (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.

I believe that some network management architecture for managing 'regular' networks is effectively also moving in this direction.

E.g., if a controller is trying to update the configuration for 10k devices, then trying to manage that a distributed transaction, or synchronously update each device, isn't the best model.


> 
> >
> >  - 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.

Yes, but as above, there has already been some interest in whether adding a binary encoding to NETCONF could make sense.


> 
> >
> > 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).

I would suggest that you also have a look at:
draft-openconfig-netmod-opstate-01 - the background precursor to this work
draft-ietf-netmod-opstate-reqs-04, which also covered requirements for asynchronous configuration operations.

If you have questions on this, then let me know.


> 
> >
> >  - 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.

The key points of the numbering system is:
 - scope the IDs globally rather than relative to the parent.
 - encode them efficiently (because CBOR encodes smaller numbers in less bytes).

In theory, for streaming telemetry data, you could end up sending this as a set of tuples of the form (global-id, keys, value), where the global-id represents the path, the keys are to any list items in the path from the root of the schema to the leaf being returned.


> 
> >
> >  - 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 Push is the latter, i.e., either a receiver, or through configuration, a client makes a subscription on the server that says:
 - send me the new data, whenever any of these data nodes (or their children) change (perhaps dampened)
 - or periodically send me the new data for these data nodes (or their children).

A client would not be expected to make a get request when it is notified of new data, there is no need, since the notifications already contain all of the relevant data.  Putting aside the underlying transport, the data flow from server to the receivers is logically asynchronous, it is just a stream of data.

> 
> >
> >  - 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.

Yes, hopefully that aligns somewhat with my suggestion at the top of my reply?

Thanks,
Rob


> 
> Cheers,
> 
> Rick