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

From: Qin Wu <[email-masked]>
Date: Thu, 7 Nov 2013 06:01:12 +0000

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

---

From: Qin Wu <[email-masked]>
Date: Thu, 21 Nov 2013 03:18:23 +0000

Hi,Yi:
Thank for your valuable feedback. Please see my reply inline below.

Regards!
-Qin
From: Yi Yang (yiya) [mailto:[email-masked]]
Sent: Thursday, November 21, 2013 10:21 AM
To: Qin Wu; [email-masked]; [email-masked]
Cc: [email-masked]; Daniel King; [email-masked]
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-masked]<mailto:[email-masked]>>
Date: Thursday, November 7, 2013 1:01 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Daniel King <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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.

Regards!
-Qin Wu

---

From: Qin Wu <[email-masked]>
Date: Fri, 22 Nov 2013 04:01:18 +0000

Hi,Yi:
Thanks for your follow-up comments.
See my reply inline below.

Regards!
-Qin

Sent: Friday, November 22, 2013 11:44 AM

Hi Qin,

Inline with [yi]:

From: Qin Wu <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 20, 2013 10:18 PM
To: Yi Yang <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Daniel King <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dnssd] Solicit feedback to draft-wu-pce-dns-pce-discovery-03

Hi,Yi:

Regards!
-Qin
From: Yi Yang (yiya) [mailto:[email-masked]]
Sent: Thursday, November 21, 2013 10:21 AM
To: Qin Wu; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Daniel King; [email-masked]<mailto:[email-masked]>
Subject: Re: [dnssd] Solicit feedback to draft-wu-pce-dns-pce-discovery-03

Hi Wu Qin,

[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.

[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.

[yi]: Yes.

[Qin]: I see.

Hi,DNSSDers:

Regards!
-Qin Wu

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Thu, 21 Nov 2013 02:21:02 +0000

Hi Wu Qin,

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. 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. 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:

Yi

Hi,DNSSDers:

Regards!
-Qin Wu

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Thu, 21 Nov 2013 02:22:41 +0000

Forgot to attach. :-)

Yi

From: Yi Yang <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 20, 2013 9:21 PM
To: Qin Wu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Daniel King <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dnssd] Solicit feedback to draft-wu-pce-dns-pce-discovery-03

Hi Wu Qin,

Yi

Hi,DNSSDers:

Regards!
-Qin Wu

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Fri, 22 Nov 2013 03:44:21 +0000

Hi Qin,

Inline with [yi]:

Hi,Yi:

Regards!
-Qin

Hi Wu Qin,

[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.

[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?

[yi]: Yes.

Yi

Hi,DNSSDers:

Regards!
-Qin Wu