Dear all,
I wanted to come back to the three questions raised during the ROSA
presentation at today's RTG WG meeting (two of them at the mic and one I
discovered in the chat log):
1. Extension header needs clarification (David L.): the ROSA draft in
Section 7.2 includes the message types introduced by ROSA, initially directed
from the client to its ingress SAR, then either directed to the selected
service instance or the next SAR hop.
2. SAR needs a full table; how does it get the information (Aijun W.): as
outlined in Section 7.4 and 7.5, ROSA may use an overlay routing protocol (we
have not fixed the choice here yet) to distribute the service address->instance
locator mapping, where each service instance sends an instance announcement to
the ROSA overlay (based on the service announcement message outlined in Section
7.2).
* I don't exactly know what the 'full table' parts exactly refers to but
recall the actual question at the mic seemingly asking about the size of the
table. As replied during the session, the table size is bound by the number of
services announcing to the ROSA provider. Thus, not all services (available,
e.g., in the Internet) are included in the table but only those having a
relationship with the ROSA provider. As described in the draft, we foresee ROSA
providers, e.g., for service categories or specific application classes. For
instance, a 55 mobile operator may serve as a ROSA provider for its edge
computing services. Here, we would not expect a large number, maybe 100 or
100s, i.e., still small. In our initial prototype, based on eBPF, we can
service 1000000 service addresses quite easily, using hashmaps in eBPF.
3. Is there a development requirement for client? (Louis C. - on the chat):
yes, we do outline in Section 7.3 the changes to clients since the usual
explicit lookup plus subsequent socket to IP plus sending operations are now
'shortcut' with an in-band discovery, so this is bound to affect the client
realization of protocols. In our prototype, we realized a new socket type
(AF_ROSA) where a user space library manages the service request/response plus
affinity messaging outlined in Figure 4 in Section 7.4. With this, the socket
type of abstraction remains largely unchanged but there are, of course, changes
to the application protocol realization, e.g., of HTTP, since the DNS lookup is
now replaced with the provisioning of the service name to the new socket (which
translates the name into a binary address).
* Important here is the complementary nature of ROSA, i.e., we'd expect
applications being adapted for which the benefits are quite clear. So this is
unlikely to affect very many of the application you may use today, for which
DNS+IP works just fine. Over time, we may see more and more application and app
protocol adaptations.
>From my side, I wanted to also come back on possible ways forward and
>specifically ask the community here the following:
If we were to organize a side meeting on this during the next IETF117,
* Would you be interested in joining such side meeting to see what this is
about and where it could go?
* Would you be interested in contributing thoughts to this discussion?
* Would be interested in contributing to material (in the form of drafts)
as groundwork for this discussion?
Please note that the second item is not limited to great ideas to make this
work (though would love to hear those) but may also include thoughts on what
aspects may be difficult, why we should be careful doing this, maybe even why
not doing this at all (in a constructive, reasoned manner, not just not liking
it). If you have any particular view on those questions above, please indicate
this either on the list or send an email to me to gauge the interest as well as
to include you in any further communication for planning such side meeting.
Best,
Dirk
P.S.: thanks to David for jumping in as note taker, as I noticed in the notepad.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
