Hi,Yi: Thanks for your follow-up comments. See my reply inline below. Regards! -Qin
From: Yi Yang (yiya) [mailto:[email protected]] Sent: Friday, November 22, 2013 11:44 AM To: Qin Wu; [email protected]; [email protected] Cc: [email protected]; Daniel King; [email protected] Subject: Re: [dnssd] Solicit feedback to draft-wu-pce-dns-pce-discovery-03 Hi Qin, Inline with [yi]: From: Qin Wu <[email protected]<mailto:[email protected]>> Date: Wednesday, November 20, 2013 10:18 PM To: Yi Yang <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Daniel King <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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:[email protected]] Sent: Thursday, November 21, 2013 10:21 AM To: Qin Wu; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Daniel King; [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> Date: Thursday, November 7, 2013 1:01 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Daniel King <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
