Re: FW: New Version Notification for draft-trossen-rtgwg-rosa-00.txt

[Jens Finkhaeuser <[e-mail]>]

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)


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

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.

None of which speaks against the proposal, really.

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