Hi Zongpeng,
Thanks for the answers. Please see inline.
Best,
Dirk
From: duzongp...@foxmail.com <duzongp...@foxmail.com>
Sent: 02 August 2022 11:36
To: Dirk Trossen <dirk.tros...@huawei.com>; Int-area <Int-area@ietf.org>
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
________________________________
duzongp...@foxmail.com<mailto:duzongp...@foxmail.com> &
duzongp...@chinamobile.com<mailto:duzongp...@chinamobile.com>
From: Dirk Trossen<mailto:dirk.tros...@huawei.com>
Date: 2022-08-02 15:47
To: duzongp...@foxmail.com<mailto:duzongp...@foxmail.com>;
Int-area<mailto:Int-area@ietf.org>
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]
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.
[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?
1.
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.
1. 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?
1.
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.
[zongpeng]
Best,
Dirk
From: Int-area <int-area-boun...@ietf.org<mailto:int-area-boun...@ietf.org>> On
Behalf Of duzongp...@foxmail.com<mailto:duzongp...@foxmail.com>
Sent: 02 August 2022 03:58
To: Int-area <Int-area@ietf.org<mailto:Int-area@ietf.org>>
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
________________________________
duzongp...@foxmail.com<mailto:duzongp...@foxmail.com> &
duzongp...@chinamobile.com<mailto:duzongp...@chinamobile.com>
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
