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

Zhen Cao <zehn.cao@gmail.com> Fri, 26 October 2012 03:28 UTC

Return-Path: <zehn.cao@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9C121F86EA for <mif@ietfa.amsl.com>; Thu, 25 Oct 2012 20:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.475
X-Spam-Level:
X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNUKte2eHh2v for <mif@ietfa.amsl.com>; Thu, 25 Oct 2012 20:28:58 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5051821F86DB for <mif@ietf.org>; Thu, 25 Oct 2012 20:28:58 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id 9so3635788iec.31 for <mif@ietf.org>; Thu, 25 Oct 2012 20:28:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=g9vLwp8nJryISi89nug0gH94BpJhRH/2+E064bNoA2Q=; b=SaFaTZARIF7mNH0DebcXIUaYdB07HOgtL6IcVKUEeRdEfbQ3XeXoKJq9IyKs2SOXpq I8lD/8YpdHJLmh465ke87dD8A9AtjOcgPAebz/JrfG1ybkJGVdaT6cS9CkeFgQDbHSA7 mESfxK7lV9WRSbohwGGRHBaykYr/aXNSbTGTaZ9UxfBJ5jKiUZRjj46OmAFwvSmOGgEP HkdUBy0aNL/FzS0mkzBYOwFAqq8E78f6JI1zZQHOJ98IGkbhVuYrMuM56pJSDblj6tw+ m55r/MiD5LUU0JRLQ63/qXQ4vS9dkDjwZmT3kpsWcCcvbFiLMClBQFiz0ifYCGDck7+p PLig==
MIME-Version: 1.0
Received: by 10.50.212.8 with SMTP id ng8mr692346igc.64.1351222137828; Thu, 25 Oct 2012 20:28:57 -0700 (PDT)
Received: by 10.64.64.102 with HTTP; Thu, 25 Oct 2012 20:28:57 -0700 (PDT)
In-Reply-To: <3745_1351079968_5087D820_3745_163_10_81C77F07008CA24F9783A98CFD706F710477F6@PEXCVZYM12.corporate.adroot.infra.ftgroup>
References: <20121015131910.25587.13444.idtracker@ietfa.amsl.com> <CAProHATr+y6Rya=7U=TagnJQLk+ohuzwnNovPieES9sZZTQfSQ@mail.gmail.com> <3745_1351079968_5087D820_3745_163_10_81C77F07008CA24F9783A98CFD706F710477F6@PEXCVZYM12.corporate.adroot.infra.ftgroup>
Date: Fri, 26 Oct 2012 11:28:57 +0800
Message-ID: <CAProHASeuur4t0xC6XBLLpMFde4ZWs01uim05Oy5zBVUvxKZ_g@mail.gmail.com>
From: Zhen Cao <zehn.cao@gmail.com>
To: pierrick.seite@orange.com
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: mif <mif@ietf.org>
Subject: Re: [mif] Fwd: I-D Action: draft-cao-mif-srv-dis-ps-00.txt
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Oct 2012 03:28:59 -0000

Hi Pierrick,

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

On Wed, Oct 24, 2012 at 7:59 PM, <pierrick.seite@orange.com> 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 : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] 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.
>
>
>
> Comments are welcome, thank you in advance.
>
>
>
> Best regards,
>
> cz
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Mon, Oct 15, 2012 at 9:19 PM
> Subject: I-D Action: draft-cao-mif-srv-dis-ps-00.txt
> To: i-d-announce@ietf.org
>
>
>
> 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
> I-D-Announce@ietf.org
> 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
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.