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 20:39
To: [email protected]; Int-area
Subject: RE: RE: [Int-area] Call for comments of the draft Service Routing in
MEC
Hi Zongpeng,
Thanks for the answers. Please see inline.
Best,
Dirk
From: [email protected] <[email protected]>
Sent: 02 August 2022 11:36
To: Dirk Trossen <[email protected]>; Int-area <[email protected]>
Subject: Re: RE: [Int-area] Call for comments of the draft Service Routing in
MEC
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:
1. 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?
2. 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?
3. 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?
4. 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]
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.
[DOT] that is not my point though. If the input to your hash function is a
structured name, the possible size of the namespace determines the conflict
probability, doesn’t it? So how do you avoid that two MEC services may map onto
the same (hashed) service IP?
[zongpeng2] As talked in the draft and slides, I agree there may be conflicts.
However, we can find it in advance. As talked in the draft,
we can
enable the mechanism only on the most essential service. Another
option is to change the HASH algorithm that is running on the clients
and the severs to make a better Hash result
I can change the misleading expression about how many conflicts may exist
in the draft. [zongpeng2]
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.
[DOT] It is not about using anycast IP addresses or not but the situation that
a service IP may be assigned to more than one network location (where a
possibly virtualized service endpoint resides). So this one-to-many relation is
missing, also relating then to Q3 on how to select one of the possibly many DA
IP addresses where those service endpoints may reside.
[zongpeng2] Agree. A service IP may be assigned to more than one network
locations. However, it is not the main point of the draft. It can be solved by
other mechanisms in other drafts in my opinion. [zongpeng2]
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.
[DOT] I can’t see the mapping though. So are you suggesting a QUIC-based
indirection mechanism (as you ‘transfer to these connections to a more
preferred address’)? This would replace the DNS indirection with the QUIC-based
one, still leaving an indirection though?
[zongpeng2] I mean we can refer to the mechanism in QUIC, and perhaps we
can save one round trip. As talked in the draft, The value of the
Service Routing IP exists mainly in the period of establishing the
connection. [zongpeng2]
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.
[DOT] CAN proposes an on-path mapping of service ID to binding ID (your service
IP to DA IP). In your reply to Q3, you seem to indicate the continued use of an
indirection, i.e., off-path mechanism for resolving the service IP to one of
the possibly many DA IPs. This is a crucial difference to me. OTOH, I would
also argue that equating service IP with service ID and DA IP with binding ID
makes dyncast (and any other solution for CAN) a solution for what you propose.
[zongpeng2] I do not think it is much related to the draft, but I will try to
give some explanations according to my understanding.
In CAN, I do not think we must have an on-path mapping
of service ID to binding ID. It is OK that routers just forward according to
DA.
The route for the server IP should be static, and the
route for the service ID may be relatively dynamic.
CAN is mainly about the new mechanism on the control
plane, and its routing decision can influence the data plane. IMHO, CAN needs
not to invent a new mechanism on the data plane.
In CAN, the Ingress node near to the clients can do LB
based on service ID with the considerations of service info from the Server
side.
On the control plane, there is a mapping relationship
between the service ID and the server IPs. The control plane can make a
decision about the current chosen server.
On the data plane, the outgoing interface of the
service ID is the tunnel to the chosen server IP. [zongpeng2]
[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
