Re: [dtn] [EXTERNAL] Alexey Melnikov's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)

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

Thanks.  Some responses in-line below.

Scott

-----Original Message-----
From: Alexey Melnikov via Datatracker <[e-mail]> 
Sent: Friday, February 7, 2020 6:09 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; Fred Templin <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: [EXTERNAL] Alexey Melnikov's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)

Alexey Melnikov has entered the following ballot position for
draft-ietf-dtn-bpbis-22: Discuss

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am looking forward for this document to be finished and approved as an RFC.
Before I can recommend this, I have several DISCUSS points and comments that I would like to address:

1) Routing decisions, discovery of endpoints to contact for forwarding and retry strategies are listed as out-of-scope for this document. This is not sufficient for writing an interoperable implementation, unless there is a separate document that provides such details.

**********
	(From my February 6 , 8:56 AM response)

Absolutely, we anticipate that over time a wide variety of strategies for topology discovery and route selection will be developed to support BP forwarding in a variety of operational scenarios.  Most implementations to date have simply used static routing tables, just to enable interoperability testing.  One published standard for BP routing does exist, but it's not yet an IETF standard: the Schedule-Aware Bundle Routing "Blue Book" published by the Consultative Committee for Space Data Systems (https://public.ccsds.org/Pubs/734x3b1.pdf) is currently in operational use on-board the International Space Station.  SABR was developed in the context of version 6 of the Bundle Protocol, not the current draft, but it is equally applicable to BPv7 since the representation of endpoint IDs has not changed.

BP typically relies on the retry strategies of the transport ("convergence layer") protocols it runs over, in hop-by-hop fashion, as end-to-end retransmission is suboptimal in a delay-tolerant network.  One element of retry strategy that is identified in the BP draft, though, is this: as noted in Step 5 of section 5.4, failure in transmission at the convergence layer may cause the bundle protocol agent to initiate another attempt to forward the bundle, possibly using a different route and/or different transport protocol.

In addition, a "custody transfer" mechanism for retry at the bundle layer itself is defined in the Bundle-in-Bundle Encapsulation protocol specification, a separate Internet Draft that we hope to advance to IESG review soon.  (The most recent edition of that draft expired a couple of days ago, and I haven't yet had time to re-post it.)

As noted in section 8, three implementations of BPv7 have been announced to date, and two of those implementations -- PyDTN and uPCN -- have been shown to be interoperable.

**********

Below I describe 3 relevant places in the text and suggest some possible ways of addressing my DISCUSS:

5.4. Bundle Forwarding

   Step 2: The bundle protocol agent MUST determine whether or not
   forwarding is contraindicated (that is, rendered inadvisable) for
   any of the reasons listed in Figure 4. In particular:

     . The bundle protocol agent MAY choose either to forward the
        bundle directly to its destination node(s) (if possible) or to
        forward the bundle to some other node(s) for further
        forwarding. The manner in which this decision is made may
        depend on the scheme name in the destination endpoint ID and/or

Lack of this information (how node to forward to are discovered) would prevent interoperability. (By comparison, SMTP specification which has somewhat similar design contains information about how next nodes to forward to are selected.)

		This information is provided in other documents, such as the CCSDS Schedule-Aware Bundle Routing standard.

I think you need to create a new section in this document specifying requirements on URI scheme documents and include this as a MUST level requirement there. (If you already have a document that does this, you can just normatively point to it.)

		Can you please explain what you mean by "requirements on URI scheme documents"?
		I don't know of any requirements on URI scheme documents that are implied by this specification.  Can you give an example?

        on other state but in any case is beyond the scope of this
        document. If the BPA elects to forward the bundle to some other
        node(s) for further forwarding but finds it impossible to
        select any node(s) to forward the bundle to, then forwarding is
        contraindicated.

     . Provided the bundle protocol agent succeeded in selecting the
        node(s) to forward the bundle to, the bundle protocol agent
        MUST subsequently select the convergence layer adapter(s) whose
        services will enable the node to send the bundle to those
        nodes.  The manner in which specific appropriate convergence
        layer adapters are selected is beyond the scope of this
        document.

Similar to the above: lack of description of how convergence layers are discovered (for example this might include discovery using DNS or something
else) or, alternatively, a mandatory to implement convergence layer would affect interoperability. I think you need to add this as a requirement to section 7 ("Services Required of the Convergence Layer").

		Adding a mandatory-to-implement convergence layer adapter in section 7 is an excellent idea.
		A specification for the TCP convergence-layer adapter is being proposed concurrently with the BPv7 and BPsec specifications.
		If the Working Group agrees, we can simply reference that specification in section 7.

Also having some (even non normative) information about which convergence layer to select if multiple are available would be useful.

        If the agent finds it impossible to select any
        appropriate convergence layer adapter(s) to use in forwarding
        this bundle, then forwarding is contraindicated.

   Step 5: When all selected convergence layer adapters have informed
   the bundle protocol agent that they have concluded their data
   sending procedures with regard to this bundle, processing may depend
   on the results of those procedures.  If completion of the data
   sending procedures by all selected convergence layer adapters has
   not resulted in successful forwarding of the bundle (an
   implementation-specific determination that is beyond the scope of
   this specification), then the bundle protocol agent MAY choose (in
   an implementation-specific manner, again beyond the scope of this
   specification) to initiate another attempt to forward the bundle.

Similar to the above: retries affect interoperability and should be documented as description of a convergence layer document.
I think you need to add this as a requirement to section 7 ("Services Required of the Convergence Layer").

		I think mandating implementation of TCPCL in section 7 would address this issue.

   In that event, processing proceeds from Step 4 of Section 5.4.

2) As pointed out by Benjamin Schwartz:

In Section 5.4.2

Consistency: This section relies on the presence of a Previous Node block, but nothing in the forwarding procedure instructs any agent to add a Previous Node block.

		Right, Ben Kaduk pointed this out as well.  Language will be added in version 23 of the draft.

Correctness: If two nodes both opt to return failed bundles, how are they to avoid a ping-pong loop?

		But on what basis would you terminate the ping pong, since on one of those cycles a way out of the loop might appear?
		I think the answer is that the bundle lifetime and hop count mechanisms will eventually cause the bundle to be destroyed, stopping the routing loop.

3) As pointed out by Benjamin Schwartz:

In Section 5.6

Error handling: What about CBOR parsing failures?

		A CBOR parsing failure would constitute a malformation of the block; Step 3 of 5.6 explains how block malformations are handled.

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

**********************************************************************
* Note, that I am conducting an experiment when people aspiring to be*
* Area Directors get exposed to AD work ("AD shadowing experiment"). *
* As a part of this experiment they get to review documents on IESG  *
* telechats according to IESG Discuss criteria document and their    *
* comments get relayed pretty much verbatim to relevant editors/WGs. *
* As an AD I retain responsibility in defending their position when  *
* I agree with it.                                                   *
* Recipients of these reviews are encouraged to reply to me directly *
* about perceived successes or failures of this experiment.          *
**********************************************************************

I also have some comments on Benjamin's comments below marked with "[[Alexey]]:"

The following comments were provided by Benjamin Schwartz <[e-mail]>:

Benjamin would have balloted *DISCUSS* on this document. He wrote:
This draft’s content seems sound but the text is difficult to understand and needs some editorial improvements.

## Abstract

Nit: Abstract should be before status.

		The document was prepared using Joe Touch's  2-Word-v2.0.template.dot, and it passes the idnits check. 

Nit: “specification for Bundle Protocol” -> “for the Bundle Protocol”.

		Sure.

## Section 1

Title: If this document doesn’t describe the operation, routing, or management of bundles, maybe it doesn’t describe a complete protocol.  Consider retitling to “Bundle Protocol Version 7: Format and Architecture”

[[Alexey]]: This relates to my DISCUSS points, but my DISCUSS position is stronger than this statement.

		Please see my response to the DISCUSS position.
		I would note that RFC 791 doesn't include procedures for making routing decisions (absent source routing) or retrying transmissions.

## Section 4.1.3

Nit: It would be clearer to move the reserved and unassigned flags to an IANA considerations section, here and throughout.

		They appear in the IANA considerations section as well.

## Section 4

Phrasing: “The last item of the array ... SHALL be a CBOR "break" stop code.”
 This seems like a misuse of the word “item”.  I would suggest “The array SHALL be terminated by a CBOR “break” stop code.”  Similarly in Section 4.2.1.

		Good catch, will fix this.

## Section 4.1.4

Clarity: The “(Boolean)” specifiers seem redundant.  What is a non-boolean flag?

Clarity: The two lists here seem redundant.  Can they be collapsed?

		Okay.

Clarity: The phrasing “...the value of the "Transmit status report if block can't be processed" flag in every canonical block…” suggests that these flags should be named or numbered before attempting to describe them.

## Section 4.1.5.1

These two sentences seem contradictory:

* “Any scheme conforming to [URIREG] may be used in a bundle protocol endpoint ID.” * “The first item of the array SHALL be the code number identifying the endpoint's URI scheme [URI], as defined in the registry of URI scheme code numbers”

Please rephrase.

		Other reviewers have remarked on this as well; revision will appear in version 23 of the draft.

[[Alexey]]: This is similar to Roman's DISCUSS.

## Section 5.4.2

Consistency: This section relies on the presence of a Previous Node block, but nothing in the forwarding procedure instructs any agent to add a Previous Node block.

		Yes, will be addressed in version 23.

Correctness: If two nodes both opt to return failed bundles, how are they to avoid a ping-pong loop?

		Please see my response to the DISCUSS item.

[[Alexey]]: I included these in the DISCUSS portion of my ballot.

##Section 5.6

Error handling: What about CBOR parsing failures?

		Please see my response to the DISCUSS item.

[[Alexey]]: I included these in the DISCUSS portion of my ballot.

## Section 5.8

Clarity: The insistence, here and earlier, that a bundle is only fragmented into two packets, and that this can then be performed recursively, seems unhelpful.  Bundles can be fragmented into arbitrarily many pieces, and this binary subdivision concept is not actually present in the protocol.  I suggest removing it from the text as well.

		Why is this unhelpful?  It's the formal procedure by which bundles are fragmented.  Let's not remove it.

## Section 6.1

Formatting: This table is excessive for a single value.

		We anticipate additional values in the future.  Let's have the table.

Clarity: The text specifies the contents twice, which is unhelpful for comprehension.

		I think it's actually helpful.  The 3-line overview introduces the concept of an administrative record and the last 3 paragraphs mandate the representation.

## Section 10

Formatting: The extra line breaks in the vertical dividers are distracting. Please fill them in or remove the breaks if possible.

		I am hoping this is something that the RFC editors handle.