Hi, Dirk
Thanks for the reply.
Please see in line.
Best Regards
Zongpeng Du
[email protected] & [email protected]
From: Dirk Trossen
Date: 2022-08-02 15:47
To: [email protected]; Int-area
Subject: RE: [Int-area] Call for comments of the draft Service Routing in MEC
Hi Zongpeng,
Thanks for pointing out the draft again (I couldn’t attend the full INTArea
meeting last week due to conflicts with other meetings).
Let me try to summarize the proposed mechanism, hoping I understood it right:
you are proposing to use the lower 128bit for identifying a service IP address,
unlike a DA IP address. A client can then send a request directly to the
service IP, possibly even initiating a traditional DNS resolution to obtain a
DA IP address in parallel. I hope I got this right.
[zongpeng] Yes. The IP can be made by hashing the domain name. [zongpeng]
Questions from my side:
In Section 5, you mention the handling of hash conflicts. What confuses me is
the reference to few initial services that would make hash conflicts less
likely. Isn’t the likelihood of a hash conflict driven by the overall pool of
possible services, which are, well, all URL-based names? Why is the (likely
much more limited) pool of MEC services only driving the hash conflict
resolution here?
A ‘service IP’ is, in my view, an anycast relationship, if we consider (e.g.,
virtualized) service endpoints to be deployed in possibly more than one (edge)
network location. I kind of miss this semantic aspect in the document. That
would also then introduce not just one DA IP but a pool of possible many DA
IPs, right?
I am a little confused by Section 4, which outlines that clients (and server)
are responsible for the service IP to DA IP mapping. On which basis is this
mapping done? Is there any signaling of service IP to DA IP involved? On which
basis is this mapping being done?
With the above questions in mind, I wonder how this proposed routing relates to
the CAN (compute-aware networking) or dyncast efforts (see, e.g.,
https://datatracker.ietf.org/doc/draft-li-dyncast-architecture/)? Particularly
the dyncast method of using anycast mapping of a service ID to a binding ID
(which is a DA IP) sounds rather similar to what you are proposing Am I missing
the key difference? If so, what is that difference?
[zongpeng]
1. Yes. You are right. Conflicts may exist, but if it is not a service in MEC,
we perhaps will not initiate the mechanism in parallel, and just do the normal
DNS procedure.
2. Agree. We can use an anycast IP instead here, perhaps with an anycast
prefix. We can explore that situation. However, we think that the "hashed IP"
in the document can be an anycast IP address or a unicast address. The main
concern of the draft is to locate a service in an MEC by using a new mechanism,
and is not to choose a service instance among many MECs.
3. In QUIC, there is a "Server's Preferred Address". Perhaps it can help the
mapping process. QUIC allows servers to accept connections on one IP address
and attempt to transfer these connections to a more preferred address shortly
after the handshake.
4. IMHO, CAN can also make the binding of service ID (anycast) and a server IP
(unicast). However, as mentioned before, in the document, the "hashed IP" can
be an anycast IP address or a unicast address. In the former situation, perhaps
they can work together.
[zongpeng]
Best,
Dirk
From: Int-area <[email protected]> On Behalf Of [email protected]
Sent: 02 August 2022 03:58
To: Int-area <[email protected]>
Subject: [Int-area] Call for comments of the draft Service Routing in MEC
Hi, all
We have recently proposed a new version of the draft
https://datatracker.ietf.org/doc/draft-du-intarea-service-routing-in-mec/
And we introduced it in the last meeting.
We are glad that anyone who is interested in can give some suggestions.
Thanks.
Abstract
This document introduces a service routing mechanism in the scenario of
Multi-access Edge Computing, which can bypass the DNS procedure.
A slide is also available:
https://datatracker.ietf.org/meeting/114/materials/slides-114-intarea-service-routing-in-multi-access-edge-computing-ietf114-00
Thanks to the comments of EV in the meeting. And I will send it to the
v6ops as well.
Best Regards
Zongpeng Du
[email protected] & [email protected]
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
