[icnrg] FW: FW: New Version Notification for draft-trossen-rtgwg-rosa-00.txt

[Dirk Trossen <[e-mail]>]

Dear ICNlers,

We have released an I-D on routing on service addresses (atop IPv6), which has some of its roots in ICN concepts (and technologies), as also Jens pointed out on the RTG WG list. 

As a draft, there is little related work included per se but a longer documentation on our end (intended as an extended paper with evaluations) lists the various efforts, including those in this RG on service-centric operations. 

If this is of any interest to the community, please feel free to join the discussion on the RTG WG list. 

Best,

Dirk

-----Original Message-----
From: rtgwg <[e-mail]> On Behalf Of Dirk Trossen
Sent: 28 October 2022 09:12
To: Jens Finkhaeuser <[e-mail]>; [e-mail]
Subject: RE: FW: New Version Notification for draft-trossen-rtgwg-rosa-00.txt

Hi Jens,

Thanks for the comments, please see inline.

Best,

Dirk

-----Original Message-----
From: rtgwg <[e-mail]> On Behalf Of Jens Finkhaeuser
Sent: 27 October 2022 20:37
To: [e-mail]
Subject: Re: FW: New Version Notification for draft-trossen-rtgwg-rosa-00.txt

Hi all,

I have a few smaller comments, I think.

1. Since I've been pulled into icnrg, I can't help but notice that ROSA could work for ICN. The only concern here is related to naming; in ROSA, "services" are addressed, in ICN it's "named data objects". Maybe a more generic term like "resource" is better? At any rate, reference to ICN could be made.

(ROSA = Routing on Service Addresses)
(ROAR = Routing on Addresses [for] Resources)

[DOT] I like ROAR 😉 Indeed, ROSA has a provenance in concepts of ICN (which may not be surprising considering previous work of mine) and a longer document on ROSA includes this more clearly. In this draft, the clearest linkage comes through the proposed usage of RFC8609 for constructing the service address. The approach in ROSA though is to look at the problem overall as one of service delivery, so even if you move from, say URL type names to resource names, the view on 'services' remains (as in invocating some sort of transactional interaction with the destination, which may be the choice of one of possibly many). So even if you were to use ROSA with rather fine-grained, say chunk-level naming, the service would be that of 'retrieving the chunk' and the problem remains that of selecting one of possibly many locations where that chunk may reside. Again, this is similar to what the ICN community has been working on but ROSA tries to embody this in a service-centric approach over an IPv6 EH shim overlay to make the routing itself tractable (since routing entries in the intermediary SARs are limited to those 'services' that have a relationship with the ROSA provider and do not include generally ALL services possible to invoke). 

2. Pinning to a service instance/locator as described in 5.4 is of course reasonable for TCP, etc. but is slightly at odds with multi-homing. If the service is multi-homed, it would make sense to announce all of its locators as belonging to the same instance. In-path routers can then proceed as before. But if the client is multi-homed as well, it may need to be/run its own ingress SAR to decide on the best link. For the smoothest failover, it should be able to make packet-by-packet routing decisions without disrupting the session.

All of which is to say that pinning to an instance and pinning to a locator might best be treated separately. That is (going back to 5.2):

- announce multiple instance IPs (multi-homed service) along with an instance ID
- in service responses, include the the instance ID and currently selected instance IP
- then in the socket layer, pin to the instance ID and let a local SAR resolve that to the instance IP based on local multi-homing knowledge

[DOT] I fully agree with your reasoning and we had similar thoughts, including also the support for multicast (we have some parallel work, also presented partially to the IETF already, on DLTs, assessing the impact of DLTs on networks with the intention of using ROSA concepts to realize the costly diffusion multipoint operation so inherent for many DLT platforms). Coming back to your suggestion, this is absolutely possible. My worry though was that complicating the operations of the SAR (as you say '...to decide on the best link') was not the best starting point for me in an initial draft. So we left multi-homing aspect out of this initial version. But I am happy to revisit this (and will come back to you explicitly on this) if this work will progress positively. 

This, however, can also be added in a later extension.

3. On 5.6 (Interconnection), there are other options than using DNS. In either case, that only works for DNS-compatible service identifiers, which may be what you intend with the new socket (address) type you describe. But it would for e.g. use in ICN impose unnecessary constraints. Maybe making that resolution step an implementation detail of the SAG. A simple scheme prefix for service identifiers could be used to distinguish the preferred resolution methods, while keeping the option of using non-DNS-compatible service identifiers.

[DOT] indeed, I should have made it clearer that our focus is the interconnection to DNS-exposed services and via the DNS. You could also envision the use of private mapping services, in which case ROSA will become a  limited domain technology not interconnecting with the Internet at all, yet allowing for connecting to other ROSA domains. 

None of which speaks against the proposal, really.
[DOT] Thanks for the positive view on this work!

Jens

> -----Original Message-----
> From: rtgwg [e-mail] On Behalf Of Dirk Trossen
> Sent: 24 October 2022 11:02
> To: [e-mail]
> Subject: FW: New Version Notification for 
> draft-trossen-rtgwg-rosa-00.txt
> 

> Dear all,
> 

> We (Luis from Telefonica and myself) have posted an I-D on 'routing on service addresses' (see below), outlining an approach to direct IP packets based on service address information rather than network locator addresses in an end-to-end manner. For this, we suggest the use of IPv6 extension headers, utilized by a shim overlay atop IPv6 and realized by what we call a ROSA provider.
> 

> We have requested a presentation slot for the upcoming IETF meeting in London but I would love to hear feedback and comments already on the list, if possible.
> 

> I am also looking forward to any discussions at the IETF, including as side discussions, with those interested in this topic.
> 

> Many thanks!
> 

> Best,
> 

> Dirk
> 

> -----Original Message-----
> > From: [e-mail] [e-mail]
> > 

> > Sent: 24 October 2022 10:56
> > To: Luis M. Contreras [e-mail];
> > Dirk Trossen [e-mail]; Luis Contreras 
> > [e-mail]
> > 

> > Subject: New Version Notification for 
> > draft-trossen-rtgwg-rosa-00.txt
> > 

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

> > Name: draft-trossen-rtgwg-rosa
> > Revision: 00
> > Title: Routing on Service Addresses
> > Document date: 2022-10-24
> > Group: Individual Submission
> > Pages: 31
> > URL: https://www.ietf.org/archive/id/draft-trossen-rtgwg-rosa-00.txt
> > Status: https://datatracker.ietf.org/doc/draft-trossen-rtgwg-rosa/
> > Htmlized: 
> > https://datatracker.ietf.org/doc/html/draft-trossen-rtgwg-rosa
> > 

> > Abstract:
> > This document proposes a novel communication approach which reasons 
> > about WHAT is being communicated (and invoked) instead of WHO is 
> > communicating. Such approach is meant to transition away from 
> > locator-based addressing (and thus routing and forwarding) to an 
> > addressing scheme where the address semantics relate to services 
> > being invoked (e.g., for computational processes, and their 
> > generated information requests and responses).
> > 

> > The document introduces Routing on Service Addresses (ROSA), as a 
> > realization of what is referred to as 'service-based routing' (SBR).
> > Such routing is designed to be constrained by service-specific 
> > parameters that go beyond load and latency, as in today's best 
> > effort or traffic engineering based routing, leading to an approach 
> > to steer traffic in a service-specific constraint-based manner.
> > 

> > Particularly, this document outlines sample ROSA use case scenarios, 
> > requirements for its design, and the ROSA system design itself.
> > 

> > The IETF Secretariat
> > 

> > _______________________________________________
> > rtgwg mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtgwg