Subject: [dtn] EID encoding (Was: Re: Convergence Layer Adapter - Endpoint IDs (CLA-EID))

From: "Clark, Gilbert J. (GRC-LCN0)" <[email-masked]>
Date: Mon, 9 Dec 2019 08:51:01 +0000

Hi,

Extracting a very small piece of this text for additional conversation and transplanting into a new thread here…

So we would have to wait for IANA to approve the scheme and then update the code in all of bundle node, seems like a lot of unnecessary bureaucracy, why not just a string for encoding EIDs?

The benefit of encoding this way is that it avoids string processing in the general case.  I personally see this as a feature, not a bug.

Cheers,
Gilbert

The views expressed in this mail reflect the opinions of the author.  They are, therefore, not intended to reflect official positions of NASA or the U.S. Government.

---

From: Loiseau lucien <[email-masked]>
Date: Tue, 10 Dec 2019 10:47:17 +0800

Hi,

I agree that this may be beneficial for device with strong computing
limitation. Still the RFC doesn't say how to deal with a scheme that has no
encoding definition. Assuming that because this node doesn't know such
definition it should drop this bundle would go against the late binding
principle (maybe this scheme is only relevant once it has reached a certain
region).

If we don't want to have string representation for EID, maybe we could
reserve an IANA number for unknown or experimental EID scheme (say 254). In
that case, encoding of an unknown EID would be the 2-tuples consisting of
cbor integer 254 followed by a cbor text string representation of the
entire EID (scheme included otherwise this information is lost). Node
unwilling to perform string processing would simply drop or forward blindly
this bundle to a more capable node.

What do you think?

On Mon, Dec 9, 2019 at 4:51 PM Clark, Gilbert J. (GRC-LCN0) <
[email-masked]> wrote:

> *So we would have to wait for IANA to approve the scheme and then update
> the code in all of bundle node, seems like a lot of unnecessary
> bureaucracy, why not just a string for encoding EIDs?*
>
>
>
> The benefit of encoding this way is that it avoids string processing in
> the general case.  I personally see this as a feature, not a bug.
>
>
>
> Cheers,
>
> Gilbert
>
>
>
> The views expressed in this mail reflect the opinions of the author.  They
> are, therefore, not intended to reflect official positions of NASA or the
> U.S. Government.
>
>
>

--
Lucien Loiseau

---

From: "Clark, Gilbert J. (GRC-LCN0)" <[email-masked]>
Date: Tue, 10 Dec 2019 15:59:58 +0000

I don’t have a strong opinion for or against an IANA reservation described below.  If it would be useful, that seems fine.

However, in response to “RFC doesn’t say how to deal with a scheme that has no encoding definition”, my reading of the draft in this instance would go as follows:

Per 5.4, “Step 2: The bundle protocol agent MUST determine whether or not forwarding is contraindicated for any of the reasons listed in Figure 4.”

In Figure 4, listed under 6.1.1, reason code 5 is listed as “Destination endpoint ID unintelligible.“

As such, in the event that a destination EID is unintelligible (e.g. unknown scheme), my expectation would be that forwarding would be contraindicated and section 5.4.1 would apply.  In the event the scheme for a different EID isn’t understood, then I think it becomes an implementation question … but given that CBOR specifies the length of the field, I do not think it would have a negative impact on bundle decoding in the abstract.  As such, I think the behavior in such a case could be safely addressed as an implementation detail.

I expect someone will correct the above if / as needed, but … this is my interpretation of the current version of the draft.

-Gilbert

From: Loiseau lucien <[email-masked]>
Date: Monday, December 9, 2019 at 9:47 PM
To: "Clark, Gilbert J. (GRC-LCN0)" <[email-masked]>
Cc: Brian Sipos <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: EID encoding (Was: Re: [dtn] Convergence Layer Adapter - Endpoint IDs (CLA-EID))

Hi,

I agree that this may be beneficial for device with strong computing limitation. Still the RFC doesn't say how to deal with a scheme that has no encoding definition. Assuming that because this node doesn't know such definition it should drop this bundle would go against the late binding principle (maybe this scheme is only relevant once it has reached a certain region).

If we don't want to have string representation for EID, maybe we could reserve an IANA number for unknown or experimental EID scheme (say 254). In that case, encoding of an unknown EID would be the 2-tuples consisting of cbor integer 254 followed by a cbor text string representation of the entire EID (scheme included otherwise this information is lost). Node unwilling to perform string processing would simply drop or forward blindly this bundle to a more capable node.

What do you think?

On Mon, Dec 9, 2019 at 4:51 PM Clark, Gilbert J. (GRC-LCN0) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Cheers,
Gilbert

--
Lucien Loiseau

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Wed, 18 Dec 2019 21:47:27 +0000

Lucien, I agree with Gilbert on this (the “late binding” principle refers to the binding of BP EIDs to convergence-layer endpoints; the destination EID should always be intelligible to every BP node on the end-to-end path) and also on his earlier “feature, not a bug” post.  Experimental EID schemes are fine, but if they are experimental then the corresponding experimental BP implementations can be designed to handle them.

We already have a pretty general mechanism for EIDs that are represented as strings: the “dtn” scheme.  I don’t think there’s a document anywhere that mandates any particular syntactic structure for the scheme-specific part of a dtn-scheme EID.  In BPv7 we simply encode such an EID as a 2-tuple comprising CBOR integer 1 followed by a CBOR text string, exactly as you propose for unknown/experimental.

Actually I think the CLA EID concept constitutes a more profound challenge to the DTN late binding principle: a bundle whose destination EID is coded in the CLA scheme would be bound to a particular convergence-layer endpoint at the moment of creation, and it would therefore become undeliverable if the destination node got bound to a different CL endpoint while the bundle was in transit.  This is exactly the problem that late binding was intended to address.

Put another way, doesn’t the CLA EID scheme make the user application responsible for knowing about, and selecting, convergence-layer protocol endpoints at the destination node?  I don’t know of any operational use cases where this would be helpful; can you describe some?

Scott

From: dtn <[email-masked]> On Behalf Of Clark, Gilbert J. (GRC-LCN0)
Sent: Tuesday, December 10, 2019 8:00 AM
To: Loiseau lucien <[email-masked]>
Cc: Brian Sipos <[email-masked]>; [email-masked]
Subject: Re: [dtn] [EXTERNAL] Re: EID encoding (Was: Re: Convergence Layer Adapter - Endpoint IDs (CLA-EID))

-Gilbert

From: Loiseau lucien <[email-masked]<mailto:[email-masked]>>
Date: Monday, December 9, 2019 at 9:47 PM
To: "Clark, Gilbert J. (GRC-LCN0)" <[email-masked]<mailto:[email-masked]>>
Cc: Brian Sipos <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: EID encoding (Was: Re: [dtn] Convergence Layer Adapter - Endpoint IDs (CLA-EID))

Hi,

What do you think?

Cheers,
Gilbert

--
Lucien Loiseau