Subject: [dtn] Alexey Melnikov's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS)

From: Alexey Melnikov via Datatracker <[email-masked]>
Date: Thu, 06 Feb 2020 04:10:54 -0800

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

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

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpbis/

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

Preliminary DISCUSS, I am likely to Defer the document, as I have more detailed
comments.

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: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Thu, 6 Feb 2020 16:55:52 +0000

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.

Scott

-----Original Message-----
From: Alexey Melnikov via Datatracker <[email-masked]> 
Sent: Thursday, February 6, 2020 4:11 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; Fred Templin <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: [EXTERNAL] Alexey Melnikov's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS)

Preliminary DISCUSS, I am likely to Defer the document, as I have more detailed comments.

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.