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]; [email protected] Cc: [email protected]; Daniel King; [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. 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. 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? 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 <[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
