Re: [dtn] [EXTERNAL] Éric Vyncke's No Objection on draft-ietf-dtn-bpbis-21: (with COMMENT)

["Burleigh, Scott C (US 312B)" <[e-mail]>]

Éric, one further note on interoperability: a fourth implementation of BPv7 – in NASA’s “ION” open-source DTN implementation – has been successfully tested for interoperability with uPCN.  The ION implementation is not yet ready for release to other testers, though, so it wasn’t be included in the implementation status section.

Scott

From: Eric Vyncke (evyncke) <[e-mail]>
Sent: Wednesday, February 5, 2020 11:24 PM
To: Burleigh, Scott C (US 312B) <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; Fred Templin <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [EXTERNAL] Éric Vyncke's No Objection on draft-ietf-dtn-bpbis-21: (with COMMENT)

Scott

Thank you for your quick reply, I appreciate.

I am still concerned by the fact that each network operator is responsible for assigning the ID of endpoints as it assumed that there will be no ‘leak’ from one DTN network to another one.

It is also a pity that the interop testing has been done only between two implementations out of three.

NB: the above sentences are non-blocking.

Best regards

-éric

From: "Burleigh, Scott C (US 312B)" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 6 February 2020 at 04:05
To: Eric Vyncke <[e-mail]<mailto:[e-mail]>>, The IESG <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Fred Templin <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [EXTERNAL] Éric Vyncke's No Objection on draft-ietf-dtn-bpbis-21: (with COMMENT)

Éric, thanks for your review.  Version 22 of the bpbis spec has been posted, and it responds to some of your comments, but here are some more detailed remarks:

C1) is there any reason why the reserved bits in section 4.3.1 are not specified with the usual 'transmitted as 0 and ignored by receiver' ?
The style of sections 4.1.3 and 4.1.4 is inherited from RFC 5050, but certainly we can change it if there’s a convention we need to follow.

C2) in section 4.1.5, is there a registry or a mechanism to avoid / detect identifier collisions ?
There isn’t one yet; for now, each network operator is responsible for assigning the IDs of endpoints in its own network.  When one is developed, it will likely be defined in its own RFC(s) rather than in this protocol specification.

C3) just curious, why is it version 7 ?
It’s descended from BP version 6, which is defined in RFC 5050.

C4) in section 4.3.2, if the bundle age is expressed in microseconds, then I would suggest to define exactly 'most recently forwarded': by which component of the bundle node ? is it measured at the completion of the action (e.g., layer-2 serialization is finished). Section 5.4 adds some more information but not enough to my taste (is it when the forwarding decision is made or when the convergence layer has accepted it).
Excellent point.  Bundle age is expressed in microseconds for the benefit of future implementations that may be able to assert and utilize precise bundle age values in ways not yet identified.  For now, the only purpose of bundle age is to trigger deletion of the bundle when the bundle’s expiration time is reached, and expiration time is only at 1-second granularity (creation time plus time-to-live).  Time-to-live values are themselves highly inexact guesses as well, for now; margins of several seconds or even minutes are not uncommon.  So for the time being I think the precision in definition you are suggesting would be overkill.

C5) in section 4.3.3., why not following the usual method of hop-limit starting at a non-zero value and being decremented at each forwarding operation ? it is like using DTN time from 2000 rather than the usual timestamp definition. Nothing bad or blocking, but, I wonder why re-inventing the wheel if there is no real reason
There is some possibility that the hop count might be used for mechanisms beyond loop detection, such as network metrics; for these purposes, it would likely be more useful for the hop count to be a genuine count, monotonically increasing.  The epoch for DTN time is 2000 to somewhat reduce the sizes of time values, saving a little bit of transmission overhead.

C6) the possibility of having a single bundle to generate multiple reports along its path to the 'report-to' endpoint ID per section 5.6 could possibly be used for an amplification attacks + resource exhaustion attack on traversed nodes. Should a rate limiting be mentioned ?
Mirja Kühlewind was concerned about this too.  New text has be inserted into section 5.1 to address the issue.

C7) section 5.9, should the re-assembly process time out ? E.g., taking into account the max bundle age ?
Because the fragments are themselves bundles, and all bundles have expiration times, reassembly will always time out when the fragments expire.

C8) section 8, I have hard time to parse the following "the Bundle Protocol version 7 specification draft (version 6)" even if I think I got it right
That text has been revised to make it a little easier to parse.

C9) section 8, an interop status (if any) between the three existing implementations would be welcome
The paragraph discussing PyDTN notes that PyDTN is interoperable with uPCN.  The interoperability of the Terra implementation is unknown at this time.
Scott

-----Original Message-----
From: Éric Vyncke via Datatracker <[e-mail]<mailto:[e-mail]>>
Sent: Monday, February 3, 2020 10:40 AM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Fred Templin <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Éric Vyncke's No Objection on draft-ietf-dtn-bpbis-21: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-dtn-bpbis-21: No Objection

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. And it is a really interesting topic !

The document is not really easy to read with some long and convoluted sentence such as
  "An application data unit is the unit
   of data whose conveyance to the bundle's destination is the purpose
   for the transmission of some bundle that is not a fragment (as
   defined below)."

Another one:
  "The payload for a bundle
   forwarded in response to reception of a bundle is the payload of the
   received bundle."

The above sentences and others make the reading really difficult. Probably too late to change now...

The section 3.2 go a little too deep IMHO in details (do we care whether the BPA is general-purpose computer?)

As a side note, I would be interested by the potential use of this bundle protocol to transport the future webpack ;-)

Please find below some non-blocking COMMENTs.
C1) is there any reason why the reserved bits in section 4.3.1 are not specified with the usual 'transmitted as 0 and ignored by receiver' ? C2) in section 4.1.5, is there a registry or a mechanism to avoid / detect identifier collisions ? C3) just curious, why is it version 7 ? C4) in section 4.3.2, if the bundle age is expressed in microseconds, then I would suggest to define exactly 'most recently forwarded': by which component of the bundle node ? is it measured at the completion of the action (e.g., layer-2 serialization is finished). Section 5.4 adds some more information but not enough to my taste (is it when the forwarding decision is made or when the convergence layer has accepted it). C5) in section 4.3.3., why not following the usual method of hop-limit starting at a non-zero value and being decremented at each forwarding operation ? it is like using DTN time from 2000 rather than the usual timestamp definition. Nothing bad or blocking, but, I wonder why re-inventing the wheel if there is no real reason C6) the possibility of having a single bundle to generate multiple reports along its path to the 'report-to' endpoint ID per section 5.6 could possibly be used for an amplification attacks + resource exhaustion attack on traversed nodes. Should a rate limiting be mentionned ?
C7) section 5.9, should the re-assembly process time out ? E.g., taking into account the max bundle age ? C8) section 8, I have hard time to parse the following "the Bundle Protocol version 7 specification draft (version 6)" even if I think I got it right C9) section 8, an interop status (if any) between the three existing implementations would be welcome

I hope that this helps to improve the document,

Regards,

-éric