Hi,Dan: Thank for your comments, see my reply inline below. Regards! -Qin -----Original Message----- From: Daniel King [mailto:[email protected]] Sent: Monday, August 26, 2013 2:00 AM To: Qin Wu; [email protected] Cc: Dhruv Dhody; 'Diego R. Lopez' Subject: RE: NAPTR vs S-NAPTR in draft-wu-pce-dns-pce-discovery-02
Hi Qin, Thanks for further educating the PCE WG on the protocol mechanics of DNS :-) Two scenarios where S-NATPR may provide to be the better mechanism, assuming we need service capability query/discovery in the future. This capability discovery could be: 1. When a PCC needs to discover a H-PCE Parent PCE. 2. When a PCC needs to discover a PCE for specific capability, stateful, GCO, P2MP, etc. In each scenario the PCC would be able to discover required capability, as each query using DNS S-NATPR would provide a response that includes: Service-tag (pce) Protocol (tcp) Application (gco) This might be represented as "pce:tcp+gco"(?), [Qin]: Following example described in the section 5.1 of RFC6408, it is better to represent it as "pce+gco:tcp" the resolution process provided by S-NAPTR DDDS [RFC3958] would allow the matching SRV or A record of a suitable PCE. Actually, this type of method and capability exposes some issues. How do we enforce policy with S-NAPTR and make sure a PCE is allowed to provide path computation response, or the PCC is even allowed to send a path computation request. [Qin]: How S-NAPTR has to do with policy enforcement is not clear to me. It seems to me the job of S-NAPTR is tolook up the PCE server's name using the DNS to get an IP address associated with the name. It then begins a connection to a particular port at that address, and sends an initial message to the PCE server. I am not sure S-NAPTR should also take care the subsequence PCEP communication. However your comment do point toward one thing, i.e., how to deal with failing to connect to PCE server. NAPTR allow using another IP address as connection address to re-connect to PCE server if the "A" or "AAAA" lookups returned more than one IP address. For authorization, CA and TLS may provide a solution. [Qin]: For authorization, I think we are using DNSSEC. DNSSEC can be used to protect domain name or certificate association obtained from DNS server. S-NAPTR allow us choose other transport than TCP,i.e., TLS/TCP if TLS/TCP transport can be supported. Br, Dan. -----Original Message----- From: Qin Wu [mailto:[email protected]] Sent: 23 August 2013 10:58 To: [email protected] Cc: Dhruv Dhody; Daniel King; Diego R. Lopez Subject: NAPTR vs S-NAPTR in draft-wu-pce-dns-pce-discovery-02 Hi,folks: In the current DNS based PCE discovery draft, we use NAPTR to lookup PCE service and query SRV record and AAA record for a DNS domain name. In the draft, we only uses NAPTR flags 'a','s', "replacement expression", "regular expression" is not used. The S-NAPTR procedure i.e., the "Straightforward-NAPTR" procedure, is defined in IETF RFC 3958 and describes a Dynamic Delegation Discovery System (DDDS) application procedures on how to resolve a domain name, application service name, and application protocol dynamically to target server and port by using both NAPTR and SRV resource records. The S-NAPTR simplifies the use of NAPTR by limiting the NAPTR flags only to "a", "s" and "". Comparing with using NAPTR, S-NAPTR requires only a subset of NAPTR strictly bound to domain names, without making use of the REGEXP field of NAPTR and make client resolution process much more predictable and efficient since multiple levels of redirection by using the "" flag and REGEXP field may lead to a deep chaining of resource records over time in the DNS configuration. In addition, some sadi that S-NATPR enables DNS lookup of services by using resource names while NAPTR by domain name, when using resource name We don't need to follow domain name syntax. Therefore I think using resource name is more flexible than using domain name and it is better for this draft to base on S-NAPTR specification [RFC3958] instead of following NAPTR defined in RFC3403. Any comments or opinions? Regards! -Qin -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Monday, August 12, 2013 3:18 PM To: [email protected] Subject: I-D Action: draft-wu-pce-dns-pce-discovery-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Path Computation Element (PCE) Discovery using Domain Name System(DNS) Author(s) : Qin Wu Dhruv Dhody Daniel King Diego R. Lopez Filename : draft-wu-pce-dns-pce-discovery-02.txt Pages : 18 Date : 2013-08-11 Abstract: Discovery of the Path Computation Element (PCE) within an IGP area or routing domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. However, in some deployment scenarios PCEs may not wish, or be able, to participate within the IGP process, therefore it would be beneficial for the Path Computation Client (PCC) (or other PCEs) to discover PCEs via an alternative mechanism to those proposed in [RFC5088] and [RFC5089]. This document specifies the requirements, use cases, procedures and extensions to support discovery via DNS for PCE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wu-pce-dns-pce-discovery There's also a htmlized version available at: http://tools.ietf.org/html/draft-wu-pce-dns-pce-discovery-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-wu-pce-dns-pce-discovery-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list [email protected] 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 _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
