Re: [Pce] [dnssd] Solicit feedback to draft-wu-pce-dns-pce-discovery-03

Qin Wu <bill.wu@huawei.com> Fri, 22 November 2013 04:02 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CF71ADEC4; Thu, 21 Nov 2013 20:02:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.211
X-Spam-Level:
X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKFmX0GrVZjP; Thu, 21 Nov 2013 20:02:03 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 34E161AD8ED; Thu, 21 Nov 2013 20:02:02 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAO78086; Fri, 22 Nov 2013 04:01:54 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 22 Nov 2013 04:01:09 +0000
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 22 Nov 2013 04:01:23 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 22 Nov 2013 12:01:19 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "Yi Yang (yiya)" <yiya@cisco.com>, "dnssd@ietf.org" <dnssd@ietf.org>, "cheshire@apple.com" <cheshire@apple.com>
Thread-Topic: [dnssd] Solicit feedback to draft-wu-pce-dns-pce-discovery-03
Thread-Index: Ac7bfAhe4xbRw6boTAe6OJLJbskmmQK7KwoAAAEXYoAANBv7AAAB9cAg
Date: Fri, 22 Nov 2013 04:01:18 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA43C5DB51@nkgeml501-mbs.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABA43C595CD@nkgeml501-mbs.china.huawei.com> <CEB4395D.1C5FB%yiya@cisco.com>
In-Reply-To: <CEB4395D.1C5FB%yiya@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.149]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C5DB51nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "pce@ietf.org" <pce@ietf.org>
Subject: Re: [Pce] [dnssd] Solicit feedback to draft-wu-pce-dns-pce-discovery-03
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Nov 2013 04:02:06 -0000

Hi,Yi:
Thanks for your follow-up comments.
See my reply inline below.

Regards!
-Qin

From: Yi Yang (yiya) [mailto:yiya@cisco.com]
Sent: Friday, November 22, 2013 11:44 AM
To: Qin Wu; dnssd@ietf.org; cheshire@apple.com
Cc: pce@ietf.org; Daniel King; julien.meuric@orange.com
Subject: Re: [dnssd] Solicit feedback to draft-wu-pce-dns-pce-discovery-03

Hi Qin,

Inline with [yi]:

From: Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>>
Date: Wednesday, November 20, 2013 10:18 PM
To: Yi Yang <yiya@cisco.com<mailto:yiya@cisco.com>>, "dnssd@ietf.org<mailto:dnssd@ietf.org>" <dnssd@ietf.org<mailto:dnssd@ietf.org>>, "cheshire@apple.com<mailto:cheshire@apple.com>" <cheshire@apple.com<mailto:cheshire@apple.com>>
Cc: "pce@ietf.org<mailto:pce@ietf.org>" <pce@ietf.org<mailto:pce@ietf.org>>, Daniel King <daniel@olddog.co.uk<mailto:daniel@olddog.co.uk>>, "julien.meuric@orange.com<mailto:julien.meuric@orange.com>" <julien.meuric@orange.com<mailto:julien.meuric@orange.com>>
Subject: Re: [dnssd] Solicit feedback to draft-wu-pce-dns-pce-discovery-03

Hi,Yi:
Thank for your valuable feedback. Please see my reply inline below.

Regards!
-Qin
From: Yi Yang (yiya) [mailto:yiya@cisco.com]
Sent: Thursday, November 21, 2013 10:21 AM
To: Qin Wu; dnssd@ietf.org<mailto:dnssd@ietf.org>; cheshire@apple.com<mailto:cheshire@apple.com>
Cc: pce@ietf.org<mailto:pce@ietf.org>; Daniel King; julien.meuric@orange.com<mailto:julien.meuric@orange.com>
Subject: Re: [dnssd] Solicit feedback to draft-wu-pce-dns-pce-discovery-03

Hi Wu Qin,

A couple of comments on the draft:

1. IMO, NAPTR may not be necessary. Instead, a dns-sd based solution should provide pretty much same functions. Please see the attached pic for an example of sequence diagram when dns-sd is used. Please note, while PCC only sends a PTR query for pce service,  the DNS server may sends additional records in it response for efficiency. Please refer to section 12 of RFC 6763 for more details.

[Qin]: Thank for clarification on how to use DNS-SD in RFC6733 to discover PCE server.
In theory, both NAPTR and PTR works.
However in my understanding, NAPTR and PTR are used to deal with different case.
PTR is used to deal with the case where User Equipment (UE) initiated DNS-based discovery and selection procedures is allowed
while NATPR is used to deal with the case where Network Equipment initiated DNS-based discovery and selection procedure is allowed.

[yi]: I don't see any doc stating that. Actually, PTR is widely used for reverse lookup, and NAPTR was originally developed for URN resolution.

[Qin]: See 3GPP TS 29.303, section 1. It proposes to use NAPTR as well to locate SGW or PGW node.

Take RFC6408 "Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage" as an example, RFC6408 use NAPTR rather than PTR and look at two cases:
a. when a Diameter client needs to discover a first-hop
Diameter agent.   Here Diameter Client is Network device, e.g., NAS, Diameter Agent.

b. when a Diameter agent needs to
discover another agent for further handling of a Diameter operation. Here Diameter Agent is also a network device that support AAA protocol.


draft-wu-pce-dns-pce-discovery-03 follows example in RFC6408 and try to leverage Dynamic Delegation Discovery System (DDDS) Application
defined in RFC3958 to map domain name, application service name, and application protocol dynamically
to target server and port.

So my feeling is PTR is more appropriate for enterprise network use case or home network use case while NATPR is more appropriate for ISP network use case.

[yi]: One feature of S-NAPTR is it allows a combination of application service and protocol. While such a combination might be specific enough for the use case mentioned in RFC3968, or RFC6408, unfortunately it's not specific enough for PCE lookup - Why not just use TXT records?

[Qin]: Just to clarify, PCE server supports various application service, e.g., stateful PCE, P2MP PCE, H-PCE service, Global Concurrent Optimization service,
For transport, PCE mandatory to support TCP, however in some deployment scenarios, they may also support TLS over TCP.
The feature of S-NATPR you described above is what we are looking for.


2. For TXT record, it seems you split it into multiple records, and put each key/value pair into a different record. This is not necessary.

[Qin]: can multiple records be carried in one DNS message?

[yi]: Yes.

[Qin]: I see.


From: Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>>
Date: Thursday, November 7, 2013 1:01 AM
To: "dnssd@ietf.org<mailto:dnssd@ietf.org>" <dnssd@ietf.org<mailto:dnssd@ietf.org>>, "cheshire@apple.com<mailto:cheshire@apple.com>" <cheshire@apple.com<mailto:cheshire@apple.com>>
Cc: "pce@ietf.org<mailto:pce@ietf.org>" <pce@ietf.org<mailto:pce@ietf.org>>, Daniel King <daniel@olddog.co.uk<mailto:daniel@olddog.co.uk>>, "julien.meuric@orange.com<mailto:julien.meuric@orange.com>" <julien.meuric@orange.com<mailto:julien.meuric@orange.com>>
Subject: [dnssd] Solicit feedback to draft-wu-pce-dns-pce-discovery-03

Hi,DNSSDers:
The draft-wu-dns-pce-discovery was presented twice in the PCE Working Group since Last Berlin meeting (http://tools.ietf.org/html/draft-wu-pce-dns-pce-discovery-03<http://tools.ietf.org/html/draft-wu-pce-dns-discovery-003> ) and is dealing with DNS based PCE discovery.
Currently the draft almost complete protocol design. For the followup, at the request of PCE WG chair, we like to ask some review from DNS experts in the DNSSD WG
and solicit feedback to this draft.

If you are interested and would like to offer help for review, I will appreciate very much.
Please freely send your comments to either the list or directly to us.

Regards!
-Qin Wu