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

"Yi Yang (yiya)" <yiya@cisco.com> Fri, 22 November 2013 03:44 UTC

Return-Path: <yiya@cisco.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 71D441ADEC4; Thu, 21 Nov 2013 19:44:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.511
X-Spam-Level:
X-Spam-Status: No, score=-8.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514, USER_IN_DEF_DKIM_WL=-7.5] 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 c8Bz6qdy4BiT; Thu, 21 Nov 2013 19:44:40 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id A744C1ADEC1; Thu, 21 Nov 2013 19:44:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24939; q=dns/txt; s=iport; t=1385091873; x=1386301473; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=aCLtRo8gjg035LlsHEMiLJE35Ep6O+ScAyYU8Lebkig=; b=XEY/Mfy4t1CgHcJPB2OSd75CTmiDezj20PqaU+UKZl0pF+0E/ubbbBUq HGzUeWMGneHZfg2coEEdNGEQOkXVcCFiXSNabJe+SHtSt/TmVnjSuwppL l8+1eK0oS7ifrfz9uVpbD/bETpByuOZoB5U0e6j7rkieH73GzjlWG181U E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnAGANHSjlKtJV2d/2dsb2JhbABZgkNEOFOzb4hMgSQWdIIlAQEBBC06BA4SAQgOAwMBAQEhBzkUCQgBAQQBDQUbh2YNwRKOKkYRBgEGhCwDmBOBMJBggyiBaUE
X-IronPort-AV: E=Sophos;i="4.93,749,1378857600"; d="scan'208,217";a="1409044"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 22 Nov 2013 03:44:22 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAM3iME5012399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 03:44:22 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.19]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 21 Nov 2013 21:44:21 -0600
From: "Yi Yang (yiya)" <yiya@cisco.com>
To: Qin Wu <bill.wu@huawei.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: Ac7bfAhe4xbRw6boTAe6OJLJbskmmQK7KwoAAAEXYoAANBv7AA==
Date: Fri, 22 Nov 2013 03:44:21 +0000
Message-ID: <CEB4395D.1C5FB%yiya@cisco.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA43C595CD@nkgeml501-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.7.130812
x-originating-ip: [10.116.75.8]
Content-Type: multipart/alternative; boundary="_000_CEB4395D1C5FByiyaciscocom_"
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 22 Nov 2013 01:29:11 -0800
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 03:44:43 -0000

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.

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?


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.

In addition, per RFC 6763, the key should not be more than 9 character long, and no space should be used in key, unless it's really necessary.

[Qin]: Good point, Thanks for pointing this out. I think I can limit the key to less than 9 character if multiple records is allowed.

Also, it's recommended to have a version tag in the TXT record.  (see section 6 of RFC 6763 for more details).  With these in mind, the TXT record in section 7.3 of your draft can be re-written as:
ex2._pce._tcp.example.com: Type TXT, class IN, 0x09 txtvers=1, 0x0e scope=inter-as, 0x1a capability=link constraint, 0x0b domain=as10, 0x10 peerDomain=area1

[Qin]: So you proposed to have all the PCE information in the same TXT record and in addition, add version tag to the TXT record?
Your proposal seems like one optimization solution which looks good to me. Thanks for your proposed change.

Yi


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