Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option

[<[e-mail]>]

Dear Dave,

For your question about DHCP, I have already answered to this question here: http://www.ietf.org/mail-archive/web/pcp/current/msg02258.html.

Additional items in which PCP is superior to DHCP are:

* Retrieving the information directly from the discovered PCP Server(s) is more flexible from an operational perspective: think about changing the PREFIX64 configured to a NAT64, for planned maintenance operations the traffic may be redirected to another NAT64 (can be achieved by using a distinct PREFIX64 for that backup NAT64), deployment of several NAT64 with distinct PREFIX64s, etc. 

* For organizations which adopt a two-level indirection (centralized DHCP server for generic configuration) and a regional team to operate regional portions of the network, the information about the PREFIX64 used in each regional area may not be available at the DHCP level. 

* Unlike DHCP, applications may embed a PCP Client (see for instance http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00#section-4.2)

Cheers,
Med 

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] De la 
>part de Dave Thaler
>Envoyé : dimanche 27 janvier 2013 03:26
>À : [e-mail]
>Objet : Re: [pcp] WG Call for Adoption: 
>draft-boucadair-pcp-nat64-prefix64-option
>
>I have read the draft and the list discussion.
>
>I think there is need for a mechanism to explicitly learn the 
>PREFIX64, and indeed
>in the document shepherd writeup I did for 
>http://tools.ietf.org/html/draft-ietf-
>behave-nat64-learn-analysis-03 I referred to this draft:
>> The document specifies a heuristic that is not perfect and so some
>> points were rough, but the constraint for this document was 
>to operate
>> without changes to code (only configuration) in existing networks.
>> Given that constraint, there was strong consensus.  Relaxing the
>> constraint would allow one to do better, and that is the focus of a
>> draft recently submitted to the PCP WG.
>
>So I do not think this draft should update or obsolete that 
>one, as the 
>constraints are quite different.   That is, use an explicit 
>mechanism if supported,
>else use the heuristic.
>
>I believe draft-boucadair-pcp-nat64-prefix64-option needs work but is
>a decent starting point (for instance it should not keep both 
>the Opcode and the
>Option, and in my view the Option is better) should the PCP WG 
>take on this
>work.   The biggest open question that would affect adoption 
>however is the 
>one Teemu raised in the email below:
>" what is the benefit of defining PCP option instead of DHCPv6 option?"
>After all, we're defining a DHCP option to learn the PCP 
>server(s), so why
>wouldn't the client be able to learn the PREFIX64(s) in the 
>same DHCP exchange?
>
>I haven't seen an answer to this question yet, and would like 
>to see consensus
>on the answer before confirming adoption.
>
>-Dave
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> [e-mail]
>> Sent: Thursday, January 3, 2013 11:01 PM
>> To: [e-mail]; [e-mail]
>> Subject: Re: [pcp] WG Call for Adoption: 
>draft-boucadair-pcp-nat64-prefix64-
>> option
>> 
>> Hi,
>> 
>> If the PCP server readily has information about Pref64::/n, 
>then why not tell
>> that to PCP client indeed. But if it has not, then I would 
>ask what is the
>> benefit of defining PCP option instead of DHCPv6 option?
>> 
>> In the Behave WG we have been working on analysis of 
>different Pref64::/n
>> discovery tools, currently in RFC Editor:  
>http://tools.ietf.org/html/draft-ietf-
>> behave-nat64-learn-analysis-03
>> 
>> The Behave's work resulted in heuristic approach being 
>selected, which is
>> currently in AD evaluation: 
>http://tools.ietf.org/html/draft-ietf-behave-
>> nat64-discovery-heuristic-13
>> 
>> Should this document formally update learn-analysis and have 
>a section with
>> similar analysis, stating pros and cons and then concluding 
>why it is useful to
>> have this solution for PCP deployment scenarios?
>> 
>> In this document I would like to see text talking about 
>relation to said analysis
>> document and heuristic approach. For example, if a host does 
>Pref64::/n
>> discovery with heuristic approach for its generic use (such 
>as local AAAA
>> record synthesis), is there utility for SIP client to 
>perform separate discovery
>> also with PCP client?
>> 
>> Nit: the IPv4-only SIP UA can be IPv4-only, but terminology 
>about IPv6-only
>> SIP UE is not that accurate IMHO: the draft's SIP UA in 
>IPv6-only *access*
>> seems to be quite capable of understanding IPv4-world (adding IPv4
>> addresses to SDP offer), hence maybe better say SIP UA in 
>IPv6-only access,
>> instead of IPv6-only SIP UA?
>> 
>> Best regards,
>> 
>> 	Teemu
>> 
>> 
>> 
>> > -----Original Message-----
>> > From: [e-mail] [mailto:[e-mail]] 
>On Behalf Of
>> > ext Reinaldo Penno (repenno)
>> > Sent: 03. tammikuuta 2013 01:30
>> > To: [e-mail]
>> > Subject: [pcp] WG Call for Adoption:
>> > draft-boucadair-pcp-nat64-prefix64-
>> > option
>> >
>> > Hello,
>> >
>> > First of all, Happy new Year!
>> >
>> > Based on the discussions at IETF Atlanta Meeting we would like to
>> > start call of adoption on a few drafts, with the first one below.
>> >
>> > This email starts a 2-week consensus call on adopting
>> >
>> >      Title           : Learn NAT64 PREFIX64s using PCP
>> >      Author(s)       : M. Boucadair
>> >      Filename        : 
>draft-boucadair-pcp-nat64-prefix64-option-02.txt
>> >      URL             :
>> > 
>http://tools.ietf.org/id/draft-boucadair-pcp-nat64-prefix64-option-02.
>> > txt
>> >
>> > Please read the current revision and state you opinion 
>either for or
>> > against adoption (and with reasoning why) in the mailing list. The
>> > call for adoption ends 16th January 2013.
>> >
>> >
>> > Thanks,
>> >
>> >
>> > _______________________________________________
>> > pcp mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/pcp
>> _______________________________________________
>> pcp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pcp
>_______________________________________________
>pcp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcp
>