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

[Zaheduzzaman Sarker <[e-mail]>]

Thanks Rob, thanks Ed.

Then we should proceed to execute this plan.

BR
Zahed

On 2021-09-24, 12:29, "Rob Wilton (rwilton)" <[e-mail]> wrote:

    Hi Zahed,

    Sorry for the delayed response, but yes, I think that this is a good way forward.

    Regards,
    Rob


    -----Original Message-----
    From: Birrane, Edward J. <[e-mail]> 
    Sent: 21 September 2021 14:34
    To: Zaheduzzaman Sarker <[e-mail]>; Rob Wilton (rwilton) <[e-mail]>; Rick Taylor <[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)

    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