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

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

Zahed,

  This all sounds very reasonable to me.

-Ed


---
Edward J. Birrane, III, Ph.D. (he/him/his)
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
  

> -----Original Message-----
> From: Zaheduzzaman Sarker <[e-mail]>
> Sent: Thursday, September 16, 2021 6:22 AM
> To: Birrane, Edward J. <[e-mail]>; Rob Wilton (rwilton)
> <[e-mail]>; Rick Taylor <[e-mail]>; The
> IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: [EXT] Re: Robert Wilton's Block on charter-ietf-dtn-01-00: (with
> BLOCK and COMMENT)
> 
> APL external email warning: Verify sender
> [e-mail] before clicking links or attachments
> 
> Hi All,
> 
> Thanks to Rob for his great review and to Rick , Ed for their responses to the
> comments. I think things got a bit clarified and I would like to propose
> multiple actions to way forward -
> 
> - clearly there are some confusions on what is specific to DTN and what can
> be solved with existing technologies. I am sure in DTN we don't want to come
> up with a generic solution problem for the OPS. Hence,  we write clear text in
> the charter that DTN will only focus on issues related specifically to DTN and
> will constantly consult with NETCONF and NETMOD to analyze the solution
> based on DTN requirements.
> 
> - for AMA draft, we take it back to the WG, update with gap analysis and
> specify DTN requirements. It might also be the case that the term
> "asynchronous" is creating some confusion, I may need some bikeshedding.
> Even this document has been worked under the current charter, we
> continue the work under the new charter and use this document to
> communicate the DTN requirement with OPS area. So this goes under a new
> work item.
> 
> - The new charter takes on naming, addressing and OPS topics, hence it is
> better that we have eyes from the experts on those from early on. For that
> in DTN, we make the "early review" a habit.  Also try to recruit WG
> consultant/advisor(s) from OPS, Routing and INT area if possible. We have
> been talking with those area experts in the previous occasions hence we
> might already have an idea who the advisors could be. I can work with the
> chairs and other ADs for finding interested experts. Another way to find
> them could be that we work on gap analysis and requirements and then have
> a joint interim with OPS and other related areas. Then we also have fair
> chance to see the interests from other areas and get opinions straight.
> 
> - Routing is still out of scope of the current charter, but we point in the
> charter that we will be talking with rtgwg, when we discuss topics that relate
> to routing.
> 
> If this plan sounds reasonable then I will work the DTN chair to reflect this in
> the charter text. So, please send your opinion(s).
> 
> BR
> Zahed
> 
> 
> On 2021-09-14, 15:36, "iesg on behalf of Birrane, Edward J." <iesg-
> [e-mail] on behalf of [e-mail]> wrote:
> 
>     Rob, Rick,
> 
>       Thank you for this discussion, and my apologies for not being able to
> chime in sooner.
> 
>       Rob brings up an excellent point, which is that the "gap analysis" portion
> of the existing AMA document was written prior to the standardization of
> RESTConf, changes to YANG for IoT, COAP, and others.   However, we have
> been tracking those changes and (we think) we understand where our needs
> are unique in the DTN community.
> 
>       Some of our devices are very, very low on resources. Not simply "IoT"
> devices, but distributed sensors with environmental energy harvesting,
> spacecraft, and microcontrollers. In these cases, lack of compute and lack of
> regular power/comms is what makes their operation require delay-
> disruption tolerance.  We are quite excited, still, about the novelty of some
> of our approach in the areas of:
> 
>       - No end-to-end communication. Once configured, a node needs to
> manage itself.
>       - A predicate autonomy model (time and state) and not based on
> scripting.
>       - Very terse encodings. I get significant push back adding just 1-2 bytes to
> an entire message, much less a single ID.
> 
>       Which is not to say we can't have areas of cooperation and coordination!
> 
>       - I know of at least one group that is using COAP to carry AMP messages -
> they are solving different parts of the problem.
>       - A masters thesis a few years back was done on the differences between
> the "AMP" model and the YANG module, and that student build a YANG-
> AMP bridge and demonstrated it at IETF104
> (https://datatracker.ietf.org/meeting/104/materials/slides-104-dtn-
> ampnetconf-interop-01).
>       - There was some effort put into a YANG model of some of the AMP work
> (https://datatracker.ietf.org/doc/html/draft-bsipos-dtn-amp-yang-01)
> 
>       Some of these are, of course, dated. But... I am fairly confident that as we
> go forward we can better identify and deconflict the parts of this approach
> which are unique to the DTN community.  As Rick mentioned, when we
> engaged with other working groups, the message we received at the time
> was that the work was interesting, but very niche and not something
> particularly applicable outside of the DTN community. And I don't think that
> overall sentiment has changed - this is a common DTN management
> problem, but not a common network management problem.
> 
>       For the charter and initial work, I suggest a few things to help us be much
> more clear about how to avoid any kind of duplication or inefficiency:
> 
>       1. The AMA document needs a refresh to include an improved "gap
> analysis" of items that came up in the past few years. When we had originally
> written AMA we moved on to other work but this is a great place to coalesce
> our understanding. I suggest the re-write of the AMA get early OPs review.
> 
>       2. Clarifications to the charter text that any management work on DTNs is
> done in ways which are unique to DTN problems and not in areas where
> existing mechanisms are sufficient. DTN really does have unique problems
> and I think it would not take very long to clarify them.
> 
>       3. Clear text in the charter of example working groups that should be
> included in these communications. It has always been our intention (and
> desire!) to get more OPs area expertise in understanding our constrained
> approach. We have, to date, been far less successful in getting our approach
> seen as having enough impact outside of DTN to warrant significant cycles
> from other groups who are, understandably, quite busy.
> 
>       -Ed
> 
>     ---
>     Edward J. Birrane, III, Ph.D. (he/him/his)
>     Embedded Applications Group Supervisor
>     Space Exploration Sector
>     Johns Hopkins Applied Physics Laboratory
>     (W) 443-778-7423 / (F) 443-228-3839
> 
> 
> 
>     > -----Original Message-----
>     > From: Rob Wilton (rwilton) <[e-mail]>
>     > Sent: Tuesday, September 14, 2021 7:45 AM
>     > To: Rick Taylor <[e-mail]>; The IESG
> <[e-mail]>
>     > Cc: [e-mail]; [e-mail]
>     > Subject: [EXT] RE: Robert Wilton's Block on charter-ietf-dtn-01-00: (with
>     > BLOCK and COMMENT)
>     >
>     > APL external email warning: Verify sender [e-mail] before
> clicking
>     > links or attachments
>     >
>     > 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