Hi Adrian,

Thanks for the interest and comments. Please see inline for some thoughts and 
replies.

Best,

Dirk

-----Original Message-----
From: Adrian Farrel [mailto:[email protected]] 
Sent: 09 March 2022 18:36
To: Dirk Trossen <[email protected]>; [email protected]; 
[email protected]
Subject: RE: New Version Notification for 
draft-trossen-rtgwg-impact-of-dlts-00.txt

Hi Dirk,

Thanks for the notification about this document.

I've been reading it (hooray) and I have some questions (boo).
[DOT] Great you read it and questions are very welcome; we only just started so 
have questions ourselves to go after in the future work.

I have heard some people proposing the use of blockchain (and so DLT) as a way 
of signing things in the routing world. For example, routing advertisements 
(either at the BGP level or within IGPs) could be signed, and blockchain could 
be used as these advertisements are passed on. I have also heard discussion of 
using blockchain for proof of transit both in regular packet flows (e.g., iOAM) 
and in Service Function Chaining where proof of execution of functions is 
desired.

[DOT] Yes, the IIC whitepaper, where this work originated, talked about those 
network-related usages of DLTs. The draft currently does not cover this since 
it looks at DLTs as an application for some sort of distributed 
storage/consensus, regardless of what that data may be. We based on our initial 
evaluation on Ethereum, i.e. a PoW (proof-of-work) based DLT system. Given the 
nature of the proof, its communication patterns, which we continue to decipher 
from the code,included as a first version in the draft, are particularly 
chatty. This comes largely from the diffusion nature of its (multipoint) 
communication, resulting in a rather large overhead of connection attempts, 
failures but also re-attempts to uphold the random nature of the diffusion pool 
(we are working on experimental quantifications of such overhead with the first 
results included in the draft). Such chattiness is an issue for any application 
IMO, let alone one that actually intends to 'manage' distributed network data.
  OTOH, proof-of-stake (PoS) approaches may help, also leading to different 
overlay management approaches (based on our current understanding - do note 
that we are not DLT experts but networking folks looking at an application and 
its impact on networks). Whether or not that would make them more suitable to 
network-related management tasks is something a DLT expert may be able to 
answer.

Such approaches seem to provide for a recursion of the impact of DLTs. That is, 
the networking needed to resolve DLTs is itself subject to DLTs that need to be 
resolved.

[DOT] Yes, indeed, see above about the chattiness over an infrastructure that 
the application itself intends to manage. It reminds me a bit of SDN and 
OpenFlow, where the former was touted to enable novel routing mechanisms beyond 
'just IP', yet its control protocol requires an IP infrastructure to manage the 
switches. So we built indeed SDN-based test beds in the past, where the control 
plane included the routing and protocol we had removed in the data plane. When 
presenting this work, it always made for funny remarks ;-)

Have you seen anything like this and what do you think are the consequences?
[DOT] What the consequences of this may be is difficult to judge IMO. Maybe an 
SDN-like situation, i.e., still having an IP-based control overlay which then 
manages the remaining IP service plane? Another possible direction to look into 
is using ANIMA concepts to bootstrap (and maintain) a DLT-like control overlay. 
But this is also why we are asking the community for possible network 
innovations that may help improve on the efficacy of DLTs. One approach we 
looked into, as an example but this still needs more work, is 'L3-based service 
routing' as a form of semantic routing (hence the hint to the semantic routing 
discussions in the draft). Here, we interpret the DLT as a service provided 
across the network. I could see this being provided as a baseline/bootstrap 
service through which to manage the (service routing) data that is being 
enriched over time by other services. But again, we were hoping to find more 
folks in the community who have thought deeper along those lines; we are ju
 st at the start of doing so.

Thanks,
Adrian

-----Original Message-----
From: rtgwg <[email protected]> On Behalf Of Dirk Trossen
Sent: 02 March 2022 13:16
To: Dirk Trossen <[email protected]>; [email protected]; 
[email protected]
Subject: RE: New Version Notification for 
draft-trossen-rtgwg-impact-of-dlts-00.txt

All,

We have posted an updated to the draft below at 
https://datatracker.ietf.org/doc/draft-trossen-rtgwg-impact-of-dlts/. 

We now welcome Mike McBride and Xinxin Fan as additional co-authors and have 
also added language into the introduction to clarify our initial insights being 
limited to PoW -based DLT systems, which lead to some characteristic 
communication patterns and associated inefficiencies compared to, say, 
PoS-based systems. 

Please provide any comments you may have on the draft and/or its insights, 
including any interests in contributing in its expansion (e.g., to other DLT 
systems).

Best,

Dirk

-----Original Message-----
From: routing-discussion [mailto:[email protected]] On Behalf 
Of Dirk Trossen
Sent: 14 February 2022 16:16
To: [email protected]; [email protected]
Subject: FW: New Version Notification for 
draft-trossen-rtgwg-impact-of-dlts-00.txt

All,

We posted the draft below to continue a piece of work initiated in the Industry 
IoT Consortium (IIC) on understanding the "Impact of DLTs on provider 
networks", leading to the whitepaper at 
https://www.iiconsortium.org/pdf/2022-01-10-Impact-of-Distributed-Ledgers-on
-Provider-Networks.pdf

With this draft, we solicit feedback from the wider IETF community on our 
insights regarding DLTs with the desire to broaden our findings with the 
expertise we can find here but also to capture possible network and routing 
innovations that may improve on the impacts we have identified.

If you have any comments or would like to contribute to this work, please do 
let us know, either on the list or directly to the authors.

Best,

Dirk (on behalf of the authors)

-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: 14 February 2022 16:10
To: David Guzman <[email protected]>; Dirk Trossen 
<[email protected]>
Subject: New Version Notification for
draft-trossen-rtgwg-impact-of-dlts-00.txt


A new version of I-D, draft-trossen-rtgwg-impact-of-dlts-00.txt
has been successfully submitted by Dirk Trossen and posted to the IETF
repository.

Name:           draft-trossen-rtgwg-impact-of-dlts
Revision:       00
Title:          Impact of DLTs on Provider Networks
Document date:  2022-02-14
Group:          Individual Submission
Pages:          16
URL:
https://www.ietf.org/archive/id/draft-trossen-rtgwg-impact-of-dlts-00.txt
Status:
https://datatracker.ietf.org/doc/draft-trossen-rtgwg-impact-of-dlts/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-trossen-rtgwg-impact-of-dlts


Abstract:
   This document discusses the impact of distributed ledger technologies
   being realized over IP-based provider networks.  The focus here lies
   on the impact that the DLT communication patterns have on efficiency
   of resource usage in the underlying networks.  We provide initial
   insights into experimental results to quantify this impact in terms
   of inefficient and wasted communication, aligned along challenges
   that the DLT realization over IP networks faces.

   This document is intended to outline this impact but also
   opportunities for network innovations to improve on the identified
   impact as well as the overall service quality.  While this document
   does not promote specific solutions that capture those opportunities,
   it invites the wider community working on DLT and network solutions
   alike to contribute to the insights in this document to aid future
   research and development into possible solution concepts and
   technologies.

   The findings presented here have first been reported within the
   similarly titled whitepaper released by the Industry IoT Consortium
   [IIC_whitepaper].

 



The IETF Secretariat


_______________________________________________
routing-discussion mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/routing-discussion

_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to