Re: [dtn] DTN addressing, routing, and ownership

"Birrane, Edward J." <Edward.Birrane@jhuapl.edu> Mon, 13 July 2020 19:00 UTC

Return-Path: <Edward.Birrane@jhuapl.edu>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577A43A1B15 for <dtn@ietfa.amsl.com>; Mon, 13 Jul 2020 12:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhuapl.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0vf1fWZH4tT for <dtn@ietfa.amsl.com>; Mon, 13 Jul 2020 12:00:52 -0700 (PDT)
Received: from aplegw02.jhuapl.edu (aplegw02.jhuapl.edu [128.244.251.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79643A18C2 for <dtn@ietf.org>; Mon, 13 Jul 2020 12:00:25 -0700 (PDT)
Received: from pps.filterd (aplegw02.jhuapl.edu [127.0.0.1]) by aplegw02.jhuapl.edu (8.16.0.42/8.16.0.42) with SMTP id 06DJ08Cs190887 for <dtn@ietf.org>; Mon, 13 Jul 2020 15:00:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=JHUAPLDec2018; bh=TEft9V08hKyu6lYlRr78VaEGeYGc+9VDtdyulDmie0U=; b=laHNsiGfiv9FrJ2U3WVPC5z4OGEEVJLScK4JW0D0C75RMOhn3Fv3gP42KWo/gh01dO/C Ybrb+1NyK6JovFSccpcSirxtJPlLetFsydtqNA2YB3ra2+7rdaDfUypaEAe0edD3sPdc TttpvYL7JHry2BpPFFjzq7487GNjytLDt00vrbFgDveox7A8mVgfhfZddWSQRhL0NGfr OH7wb3CXtZW4lqhvpbHO4I8YEsS9DozzeLDSC6Z5eSNDOqe3EvCyVcK2qA2h/pwrL1Nd p0qJIzlm5SZ0cj9B3s8T6ln18DdGaGZOvO+WpD5wkISH9N1O08zkyb1MFfATUl2FFk+d Rw==
Received: from aplex04.dom1.jhuapl.edu (aplex04.dom1.jhuapl.edu [128.244.198.162]) by aplegw02.jhuapl.edu with ESMTP id 3279mwhpsy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <dtn@ietf.org>; Mon, 13 Jul 2020 15:00:23 -0400
X-CrossPremisesHeadersFilteredBySendConnector: APLEX04.dom1.jhuapl.edu
Received: from aplex01.dom1.jhuapl.edu (128.244.198.5) by APLEX04.dom1.jhuapl.edu (128.244.198.162) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 13 Jul 2020 15:00:23 -0400
Received: from aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50]) by aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50%25]) with mapi id 15.00.1497.006; Mon, 13 Jul 2020 15:00:23 -0400
From: "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>
To: "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: DTN addressing, routing, and ownership
Thread-Index: AQHWTVTx85boqEKc/0KX1l4tcd8Z7ajwYw9ggACsSIuAADE/cIAARK9GgABMkECAAJD44IAAVUhXgAAMdtCAAMyxRIACstXggAg0BAKAAQM/gIABjETAgACM80CAADFSkIADvs7AgAAaEOCAAArhdoAAH3vwgAAoUtuAAAIQAA==
Date: Mon, 13 Jul 2020 19:00:22 +0000
Message-ID: <d922e5d2ca544d239351ba8a3fbf4cbb@aplex01.dom1.jhuapl.edu>
References: <MN2PR13MB356748622EBD29B0028737E19F910@MN2PR13MB3567.namprd13.prod.outlook.com>, <095534b510e44eeebe2d02865eafd10d@jpl.nasa.gov> <MN2PR13MB3567754EE9D8D3C7D19DBD259F6F0@MN2PR13MB3567.namprd13.prod.outlook.com>, <631c36b735934d7eb0df5873536b6ee4@jpl.nasa.gov> <MN2PR13MB35671B6724A93836F3F94F2C9F6F0@MN2PR13MB3567.namprd13.prod.outlook.com> <6990ef88820a400f8c3be2c33310c5f6@jpl.nasa.gov>, <38A5475DE83986499AEACD2CFAFC3F9801F585B226@tss-server1.home.tropicalstormsoftware.com> <MN2PR13MB356752E2F1BBB69FDDA274E79F6C0@MN2PR13MB3567.namprd13.prod.outlook.com>, <0e03648eb66849a68193d5a2e1ebcf3e@jpl.nasa.gov> <MN2PR13MB35670F9E35992C2008683B2B9F6D0@MN2PR13MB3567.namprd13.prod.outlook.com>, <d52af6dc5d4b4ec5a1fb9473598ea579@jpl.nasa.gov> <MN2PR13MB3567A58E070E00DCE177002C9F640@MN2PR13MB3567.namprd13.prod.outlook.com> <df0be49bf9124bcdbb8e0e74c510c280@jpl.nasa.gov> <38A5475DE83986499AEACD2CFAFC3F9801F585C2CF@tss-server1.home.tropicalstormsoftware.com> <058a85379305497fa5fadde67b83f9ad@jpl.nasa.gov> <6becf7a7504540c38e6a16c25ec870bd@aplex01.dom1.jhuapl.edu> <38A5475DE83986499AEACD2CFAFC3F9801F585C7D1@tss-server1.home.tropicalstormsoftware.com>, <86815474597745198fbc50366b7e27a3@aplex01.dom1.jhuapl.edu> <54b9f12780ce4e778be3912d7945ae57@dlr.de>, <38A5475DE83986499AEACD2CFAFC3F9801F585C86C@tss-server1.home.tropicalstormsoftware.com> <679817635918483c9d6cd5bbfcfe878e@dlr.de>
In-Reply-To: <679817635918483c9d6cd5bbfcfe878e@dlr.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [128.244.198.168]
Content-Type: multipart/alternative; boundary="_000_d922e5d2ca544d239351ba8a3fbf4cbbaplex01dom1jhuapledu_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: APLEX04.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-13_16:2020-07-13, 2020-07-13 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/z4Xre7XYTB-NgqwrVXobyIgvMII>
Subject: Re: [dtn] DTN addressing, routing, and ownership
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jul 2020 19:00:59 -0000

I don't disagree that there are cases where certain schemes do and do not make sense.  For example, using an IP address on a deep-space spacecraft seems unnecessary and using an IPN address on a node on the Internet seems unnecessary.

Maybe a simpler question is: could I have a bundle whose source EID is simply:  "www.eds_discount_emporium.com:1234'  and do we really need to develop a new scheme to represent that?

I certainly defer to those with more knowledge on URI syntax as to whether BPbis should add a defined scheme id to its registry of allowed schemes.

-Ed

Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Principal Staff, Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423<tel:(443)%20778-7423> / (F) 443-228-3839<tel:(443)%20228-3839>

From: Jeremy.Mayer@dlr.de <Jeremy.Mayer@dlr.de>
Sent: Monday, July 13, 2020 2:53 PM
To: rick@tropicalstormsoftware.com; Birrane, Edward J. <Edward.Birrane@jhuapl.edu>; dtn@ietf.org
Subject: [EXT] Re: DTN addressing, routing, and ownership

APL external email warning: Verify sender Jeremy.Mayer@dlr.de<mailto:Jeremy.Mayer@dlr.de> before clicking links or attachments




Rick,

I considered both ways, but I think that, for the sake of argument here, the http URI is the "primary" URI, with the IPN portion appended to it. However, you're right, in that you should use the query component(s) as a delimiter. If you use the URI query component as the BP EID, you can maintain full compatibility with L4 load balancers, etc, which can perform forwarding decisions based upon that query. That also maintains compatibility with websocket URI's.



Thanks,

Jeremy

________________________________
From: Rick Taylor <rick@tropicalstormsoftware.com<mailto:rick@tropicalstormsoftware.com>>
Sent: Monday, July 13, 2020 6:32:06 PM
To: Mayer, Jeremy; Edward.Birrane@jhuapl.edu<mailto:Edward.Birrane@jhuapl.edu>; dtn@ietf.org<mailto:dtn@ietf.org>
Subject: RE: DTN addressing, routing, and ownership

Hi Ed,

I'm with Jeremy on this.  HTTP makes a fine CLA as HTTP defines a transport already.   The http:// schema specifies the address *and* the transport.

@Jeremy: would your example be better as http+ipn:[ipn_parts]#[http_resource?query] ?

(One day I will finish my HTTP-REST CLA draft)

Rick

From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Jeremy.Mayer@dlr.de<mailto:Jeremy.Mayer@dlr.de>
Sent: 13 July 2020 15:48
To: Edward.Birrane@jhuapl.edu<mailto:Edward.Birrane@jhuapl.edu>; dtn@ietf.org<mailto:dtn@ietf.org>
Subject: Re: [dtn] DTN addressing, routing, and ownership


Ed,

Throwing in my $0.02: I'm not entirely sure that http is a valid scheme from this perspective. I consider http (& webSockets, IMAP, carrier pigeon, etc) to be a "CLA++", where it's actually a last-hop convergence layer scheme.

Therefore, it might be preemptive to start creating "non-DTN-specific" scheme names. Instead, we should strongly consider the use of the oft-forgotten-yet-completely-valid '+' character within the scheme name for these types of use-cases. We can use that character to specify dtn/ipn (which essentially outline the behavior of BP) and the the associated CLA path. If we go this way, some schemes would look like: http+ipn://[http URL]#[ipn URI].



Thanks,

Jeremy

________________________________
From: dtn <dtn-bounces@ietf.org<mailto:dtn-bounces@ietf.org>> on behalf of Birrane, Edward J. <Edward.Birrane@jhuapl.edu<mailto:Edward.Birrane@jhuapl.edu>>
Sent: Monday, July 13, 2020 3:57:29 PM
To: dtn@ietf.org<mailto:dtn@ietf.org>
Subject: Re: [dtn] DTN addressing, routing, and ownership

One other comment on supported EID schemes:

The split between DEST and DST_PORT does indeed formally exist for the ipn EID scheme: node number and service number.  We could do the same sort of thing for the dtn scheme, but the WG has not yet reached consensus on the detailed syntax of dtn-scheme EIDs.  It's not that we haven't recognized this issue, it's that the issue is addressed in the EID schemes rather than in the protocol specification itself.

[EJB]  Looking at section 10.6 I see dtn: and ipn: as defined scheme names. Is there something that breaks if we also allow an http: scheme in this registry? For those simpler cases where late binding is *not* needed then a standard IP is fine, and otherwise a "host name" or loopback can be used for late binding instead.

[EJB] In no way am I suggesting to  not use dtn: or ipn:, but perhaps http: should also be included as a possibility?