[T2TRG] Service affinity and CoRE discovery: draft-bormann-t2trg-affinity-00.txt

Carsten Bormann <cabo@tzi.org> Mon, 30 August 2021 20:47 UTC

Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
Date: Mon, 30 Aug 2021 22:47:18 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <AF6DA9E5-26F4-4B6B-9CD8-683C212F6AFE@tzi.org>
References: <163035614587.3586.6118459960841659156@ietfa.amsl.com>
To: t2trg@irtf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/t2trg/Oh4tYw_sqaiiCdRzx0W2SvKrRws>
Subject: [T2TRG] Service affinity and CoRE discovery: draft-bormann-t2trg-affinity-00.txt
Precedence: list

Some of you may know that I'm interested in ways to stabilize client-server relationships where the server is reached via anycast and routing might change, but the client is interested in continuing to talk to the same server for the duration of a service invocation.

Earlier this year I had submitted draft-bormann-dyncast-affinity with one approach to achieve this, which requires the client to address the server with a rotating address that is tied down for a specific service invocation at the start of that invocation.  The routing system is expected to honor this hint by using routing information from the time that address was current, even if the service invocation takes longer than the update rhythm for that information.

The question was of course how a client would learn about what exactly to do here.

I have updated the draft, now draft-bormann-t2trg-affinity, with examples from CoRE /.well-known/core and resource-directory.
If you are interested in this (e.g., for edge computing), comments are welcome.

Grüße, Carsten



> Begin forwarded message:
> 
> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-bormann-t2trg-affinity-00.txt
> Date: 2021-08-30 at 22:42:25 CEST
> To: "Carsten Bormann" <cabo@tzi.org>
> Message-Id: <163035614587.3586.6118459960841659156@ietfa.amsl.com>
> 
> 
> A new version of I-D, draft-bormann-t2trg-affinity-00.txt
> has been successfully submitted by Carsten Bormann and posted to the
> IETF repository.
> 
> Name:		draft-bormann-t2trg-affinity
> Revision:	00
> Title:		Providing Instance Affinity in Dyncast
> Document date:	2021-08-30
> Group:		Individual Submission
> Pages:		9
> URL:            https://www.ietf.org/archive/id/draft-bormann-t2trg-affinity-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-bormann-t2trg-affinity/
> Html:           https://www.ietf.org/archive/id/draft-bormann-t2trg-affinity-00.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-bormann-t2trg-affinity
> 
> 
> Abstract:
>   Dyncast support in a network provides a client with a fresh optimal
>   path to a service provider instance, where optimality includes both
>   path and service provider characteristics.  As a service invocation
>   usually takes more than one packet, dyncast needs to provide instance
>   affinity for each service invocation.  Naive implementations of
>   instance affinity require per-application, per service-invocation
>   state in the network.
> 
>   The present short document defines a way to provide instance affinity
>   that does not require, but also does not rule out per-application
>   state.
> 
>   It also discusses how the information that an application needs to
>   operate this mechanism can be provided via the discovery mechanisms
>   offered by a CoRE (Constrained RESTful Environments) server, either
>   in "/.well-known/core" or via the CoRE resource directory.

[T2TRG] Service affinity and CoRE discovery: draf… Carsten Bormann