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 [email protected] On Behalf Of Dirk Trossen > Sent: 24 October 2022 11:02 > To: [email protected] > 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: [email protected] [email protected] > > > > Sent: 24 October 2022 10:56 > > To: Luis M. Contreras [email protected]; Dirk > > Trossen [email protected]; Luis Contreras > > [email protected] > > > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/rtgwg
publickey - [email protected] - 0x5C345E9C.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
