Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option

Hi Dan, 

Please see inline. 

Cheers,
Med 

>-----Message d'origine-----
>De : Dan Wing [mailto:dwing@cisco.com] 
>Envoyé : mardi 11 septembre 2012 19:08
>À : BOUCADAIR Mohamed OLNC/NAD/TIP; 'Simon Perreault'
>Cc : pcp@ietf.org
>Objet : RE: [pcp] PREFIX64 PCP Option for NAT64: 
>draft-boucadair-pcp-nat64-prefix64-option
>
>> -----Original Message-----
>> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of
>> mohamed.boucadair@orange.com
>> Sent: Tuesday, September 11, 2012 2:53 AM
>> To: Simon Perreault
>> Cc: pcp@ietf.org
>> Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: 
>draft-boucadair-pcp-
>> nat64-prefix64-option
>> 
>> Hi Simon,
>> 
>> I updated the draft with a new OpCode to retrieve the list 
>of PREFIX64.
>> The new version is available at:
>>  
>http://tools.ietf.org/html/draft-boucadair-pcp-nat64-prefix64-option-
>> 01
>> 
>> The new version includes also some comments from Reddy.
>> 
>> Please feel free to comment the new version of the draft.
>
>Thanks for the draft showing both choices.
>
>The message flow for the new PCP Opcode implies there is always
>an additional round trip.

Med: This is only an example for this particular case. I added a new flow example when no MAP is needed.

  There is only an additional round-trip
>if MAP (or PEER) is used.  If, on the other hand, the host only
>needed to learn the NAT64 prefix (and then it set up a TCP 
>connection), the number of messages on the network is exactly
>the same for the MAP option or the new Opcode, assuming the PCP
>client simply leaves the dangling MAP-created mapping until its
>Lifetime expires.

Med: Fully agree. Note another order may be followed to send the requests in the examples of the draft. The purpose is to show how it works not to compare the opcode vs option at this stage. 

>
>-d
>
>
>
>> Cheers,
>> Med
>> 
>> 
>> >-----Message d'origine-----
>> >De : Simon Perreault [mailto:simon.perreault@viagenie.ca]
>> >Envoyé : jeudi 6 septembre 2012 17:29
>> >À : BOUCADAIR Mohamed OLNC/NAD/TIP
>> >Cc : pcp@ietf.org
>> >Objet : Re: [pcp] PREFIX64 PCP Option for NAT64:
>> >draft-boucadair-pcp-nat64-prefix64-option
>> >
>> >Le 2012-09-06 11:04, mohamed.boucadair@orange.com a écrit :
>> >> Med: I'm open to evaluate which approach is better: new opcode vs.
>> >> new option. We need first to agree this is valid problem to solve.
>> >
>> >There is clearly a need to discover the NAT64 prefix:
>> >draft-ietf-behave-nat64-learn-analysis
>> >draft-ietf-behave-nat64-discovery-heuristic
>> >
>> >Note that the analysis draft does not consider PCP. Maybe it should.
>> >Looking at the list of pros and cons for DHCPv6, PCP would be
>> >different,
>> >and better in some aspects.
>> >
>> >Personally I would much prefer using PCP than the heuristic
>> >when PCP is
>> >available.
>> >
>> >Simon
>> >--
>> >DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>> >NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>> >STUN/TURN server               --> http://numb.viagenie.ca
>> >
>> _______________________________________________
>> pcp mailing list
>> pcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcp
>
>