Subject: [mif] Fwd: I-D Action: draft-cao-mif-srv-dis-ps-00.txt

From: Zhen Cao <[email-masked]>
Date: Tue, 23 Oct 2012 15:38:31 +0800

Dear All,

This is a new draft on service discovery in a multiple interface
environment.

Comments are welcome, thank you in advance.

Best regards,
cz
---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Oct 15, 2012 at 9:19 PM
Subject: I-D Action: draft-cao-mif-srv-dis-ps-00.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Service Discovery in a Multiple Connection
Environment: Problem Statement
        Author(s)       : Zhen Cao
        Filename        : draft-cao-mif-srv-dis-ps-00.txt
        Pages           : 8
        Date            : 2012-10-15

Abstract:
   This document analyzes the problem of service discovery in a multiple
   connection environment.  A multiple connection environment consists
   of multiple-interfaces nodes connecting to multiple networks or
   mutliple provisioning domains.  Given a type of service a mutliple-
   interfaced client is looking for, the discovery progress ought to
   return a correct pointer to the service instance that the client is
   able to access.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-cao-mif-srv-dis-ps

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-cao-mif-srv-dis-ps-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Zhen Cao <[email-masked]>
Date: Fri, 26 Oct 2012 11:28:57 +0800

Hi Pierrick,

Thank you very much for you comments, see my response inline.

On Wed, Oct 24, 2012 at 7:59 PM, <[email-masked]> wrote:
>
> Hi Zhen,
>
>
>
> I think, the problem you’re describing is valid. Did you check Homenet WG? I remember a presentation describing the Homenet use-cases, and multihoming was one of the use-cases. I guess they have a similar problem with service discovery…

I remember there was a presentation from Daniel (France Telecom). I
would review that as a solution document.

> What is a Service domain ? A definition  is needed IMHO.

will add definition in our slides and revisions.

> When reading step 1 in Section 2  (the host send a query to find a service), a question comes immediately to the mind:  On which interface the service discovery request must be sent? Shouldn’t we have a step 0 “discovery of the service discovery server”  ? –I guess, it is the problem 1 you have identified, it leads to requirelent “Service Directory Service Configuration”. Right? Just to be sure I understood correctly the logic of the I-D….

Yes, I agree. I will add step zero.

>
> In step 2, you wrote: Service Request Handling: any entity that receives the query request should handle the request. I slightly disagree; actually a service discovery entity is expected to proceed to request concerning the services from its domain; the service discovery server on the public WiFi interface cannot handle the requests for 3GPP only service discovery.

[cz] I mean it should handle the query. To check if it has such
information is also a “handling” in this regards.

> In step 4: I do not understand why you add the last statement “unless it is the service domain that has met a problem.”

[cz] I mean the server is down, e.g., a web server is down.

> Problem 2:  it seems that it is the same problem than for DNS selection: some DNS answers are only valid on a given interface. The FQDN which can be reached on a single interface are expected to be resolved by the DNS server from that interface (e.g. a private 3GPP fqdn is resolved by 3GPP dns servers not by public Wifi DNS servers).

[cz] I admit that problem 2 is solvable by the mif-dns solution. But
mif-dns solution is limited in that it only solves the problem of the
service directory configuration.

> Problem 3:  this problem should not exist with proper service discovery server configuration (service which access is limited to a given interface is resolved by SD servers from that interface) .

[cz] in a SRV query, the port contained in the response may be blocked
on that interface. This is one of the example where problem 3 exists.
The service discovery server could sometimes not that smart, and the
management of the discovery server is different from the
infrastructure, e.g, host use google public dns as discovery server in
its access network.

> In conclusion, I agree there is a problem. But the problem is a problem of service discovery server selection, just as the DNS server selection.. The figure 2 illustrates very well the problem. What is required to solve the problem is to be able to request the proper SD server depending on the reachability of the service (service which access is limited to a given interface is resolved by SD servers from that interface) . Actually, we have a problem because SD server are node scoped and cannot be per interface.
>

[cz] the same thing as above, the discovery server most time do not
have full knowledge of the servers and infrastructure information.
that's where the concerns arise.

> Typo on section 2: s/The serivce discovery process/service discovery process

Thanks for pointing it out.

> BR,
>
> Pierrick
>
>
>
>
>
> De : [email-masked] [mailto:[email-masked]] De la part de Zhen Cao
> Envoyé : mardi 23 octobre 2012 09:39
> À : mif
> Objet : [mif] Fwd: I-D Action: draft-cao-mif-srv-dis-ps-00.txt
>
>
>
> Dear All,
>
>
>
> This is a new draft on service discovery in a multiple interface environment.
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>         Title           : Service Discovery in a Multiple Connection Environment: Problem Statement
>         Author(s)       : Zhen Cao
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.