Subject: [Pce] NAPTR vs S-NAPTR in draft-wu-pce-dns-pce-discovery-02

From: Qin Wu <[email-masked]>
Date: Fri, 23 Aug 2013 09:58:14 +0000

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-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, August 12, 2013 3:18 PM
To: [email-masked]
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-masked]
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

---

From: "Daniel King" <[email-masked]>
Date: Sun, 25 Aug 2013 19:00:05 +0100

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"(?), 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. For authorization,  CA and TLS may provide a solution. 

Br, Dan. 

-----Original Message-----
From: Qin Wu [mailto:[email-masked]] 
Sent: 23 August 2013 10:58
To: [email-masked]
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.

Regards!
-Qin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, August 12, 2013 3:18 PM
To: [email-masked]
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:

_______________________________________________
I-D-Announce mailing list
[email-masked]
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

---

From: Qin Wu <[email-masked]>
Date: Tue, 27 Aug 2013 06:56:01 +0000

Hi,Dan:
Thank for your comments, see my reply inline below.

Regards!
-Qin
-----Original Message-----
From: Daniel King [mailto:[email-masked]] 
Sent: Monday, August 26, 2013 2:00 AM
To: Qin Wu; [email-masked]
Cc: Dhruv Dhody; 'Diego R. Lopez'
Subject: RE: NAPTR vs S-NAPTR in draft-wu-pce-dns-pce-discovery-02

Hi Qin, 

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

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-masked]] 
Sent: 23 August 2013 10:58
To: [email-masked]
Cc: Dhruv Dhody; Daniel King; Diego R. Lopez
Subject: NAPTR vs S-NAPTR in draft-wu-pce-dns-pce-discovery-02

Hi,folks:

Regards!
-Qin
-----Original Message-----

Abstract: