Re: [pcp] WG last call on draft-ietf-pcp-upnp-igd-interworking-01

[<[e-mail]>]

Dear Dave,

Thank you for the detailed review. 

Please see inline.

Cheers,
Med 

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] De la 
>part de Dave Thaler
>Envoyé : samedi 28 juillet 2012 02:32
>À : [e-mail]
>Objet : Re: [pcp] WG last call on 
>draft-ietf-pcp-upnp-igd-interworking-01
>
>A marked up version with my full comments is available at:
>http://research.microsoft.com/~dthaler/draft-ietf-pcp-upnp-igd-
>interworking-01.pdf
>
>A summary of the main non-editorial issues follows:
>
>1) The UPnP IGD state variables and methods fall into two 
>categories: those
>relevant to port mapping, and those not relevant to port 
>mapping.   Currently
>some the latter are listed as "not applicable", some are 
>omitted from the document,
>and of those not omitted, I think some of the statements 
>aren't correct.   Instead,
>I think this doc should be scoped to only discussion of the 
>first category and say
>the rest are covered in [IGD2], without enumerating them.   

Med: I removed non-applicable variables from the document.

>And I think we should
>also say that an IGD with the IWF MUST be compliant to [IGD2]. 
>  I believe that
>will maximize the chance of interoperability with UPnP-IGD clients.
>

Med: Added to Section 4.1 this sentence: 
"The UPnP IGD-PCP Interworking Function MUST support IGD:2 behavior."
 

>2) The doc currently assumes that there's only one 
>ExternalIPAddress.

Med: Yes, it assumes one external IP address is assigned per CPE not per UPnP CP. This is aligned with REQ#2 of http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-08.

   I don't
>think that's as scalable, and it's certainly not required by 
>the PCP protocol.
>Instead, I think we should explicitly state that the 
>ExternalIPAddress should be stored
>on a per control-point basis, so that different control points 
>could see different 
>values.   Each value comes from the PCP responses for mappings 
>for that control point.
>This means that just because there's a collision in external 
>port for some other
>control point doesn't mean that adding a mapping will fail.   
>It would only fail
>if that other control point used the same ExternalIPAddress as 
>the requesting one.
>If the requesting control point hadn't yet been assigned an 
>ExternalIPAddress, then
>the request should be relayed to the PCP server(s).    [See 
>also my comment #10
>on the pcp-dhcp draft.]    Section 11.3 of the pcp-base spec 
>already has logic where
>the server will accept a port MAP request even when one IP 
>already has a mapping,
>as long as it has another available external IP that can 
>service the request.

Med: I don't have a problem to relax this constraint to be on a per CP basis rather than per CPE. If there is no objection from the WG, I will implement the change you are requesting for.  

>
>3) It would be good to add a paragraph, say in the discussion 
>of Figure 4 
>(Cascaded NAT scenario), explaining that without the PCP IWF, 
>the control point
>would see an "ExternalIPAddress" and port of the WAN link 
>between the IGD
>and NAT2, not the public address/port on the Internet.   With 
>the PCP IWF,
>the control point will instead see the public address/port on 
>the Internet.
>It will no longer see the intermediate address/port between the IGD and
>NAT2, even though it would be useful for communication with another
>host  behind the same NAT2 but not behind the IGD.   Such 
>learning is not
>supported, and so it would be good to point that out.   This 
>helps the reader
>understand the point of the rest of the logic.

Med: I added this new text:

   Without the involvement of the IGD-PCP Interworking Function, the UPnP
   CP would retrieve an external IP address and port number having a
   limited scope and which can not be used to communicate with hosts
   located beyond NAT2 (i.e., assigned by the IGD and not the ones
   assigned by NAT2 in Figure 4).

>
>4) Renewals are mentioned in passing under the 
>"PortMappingLeaseDuration"
>state variable.   However the behavior is never specified.   
>This should be added
>as a new section 5.10.
>

Med: I added this new section:

5.10.  Renewal

   Because of the incompatibility of mapping lifetimes between UPnP IGD
   and PCP, the IGD-PCP Interworking Function MUST simulate long and
   even infinite lifetimes.  Indeed, for requests having a requested
   PortMappingLeaseDuration longer than 65535 or infinite, the IGD-PCP
   Interworking Function MUST set the requested PCP Lifetime of the
   corresponding PCP request to 65535.  Furthermore, the IGD-PCP
   Interworking Function MUST maintain an additional timer set to the
   initial requested PortMappingLeaseDuration.  Upon receipt of a
   positive answer from the PCP server, the IGD-PCP Interworking
   Function relays the corresponding UPnP IGD response to the requesting
   UPnP CP with PortMappingLeaseDuration set to the same value as the
   one of the initial request.  Then, the IGD-PCP Interworking Function
   MUST renew the instructed PCP mapping until the expiry of
   PortMappingLeaseDuration.  Responses received when renewing the
   mapping MUST NOT be relayed to the UPnP CP.

   In case an error is encountered during mapping renewal, the IGD-PCP
   Interworking Function has no means to inform the UPnP CP.



>5) The assumption in UPnP-IGD is that 
>GetSpecificPortMappingEntry() can not
>return something that wouldn't be returned by 
>GetGenericPortMappingEntry()
>and GetListOfPortMappings().   Section 5.8 breaks that, 
>without giving any justification.
>That is, it says GetListOfPortMappings and 
>GetGenericPortMappingEntry are
>served locally, never relayed, but that 
>GetSpecificPortMappingEntry can be
>relayed when no mapping is found.   This is inconsistent.  I 
>think it should be
>handled locally as well, to retain consistency.   Yes that 
>means you can't use
>it to look up third party information about other IGDs.   And 
>that's a good thing.

Med: The motivation for this is as mentioned in the draft: 

"some
      applications uses GetSpecificPortMapping() to check whether a
      mapping exists."

These applications check whether a specific mapping is instantiated, if not these applications sent a request to install that mapping. 
If GetSpecificPortMappingEntry() is served locally, this will lead to application error. It is efficient to relay GetSpecificPortMappingEntry() rather than serving it locally.


>
>-Dave
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On 
>Behalf Of Dave
>> Thaler
>> Sent: Friday, July 13, 2012 1:08 PM
>> To: [e-mail]
>> Subject: [pcp] WG last call on 
>draft-ietf-pcp-upnp-igd-interworking-01
>> 
>> From the IETF 83 minutes:
>> > 1330-1340 UPnP-IGD Interworking Function             
>(Mohamed Boucadair, 10)
>> >           Document: draft-ietf-pcp-upnp-igd-interworking-01
>> >           Slides: 
>http://www.ietf.org/proceedings/83/slides/slides-83-pcp-1.pdf
>> >
>> > Any objections to starting a WG Last Call on this?
>> > Francis objected that the issue of an IGD client that asks 
>for a lifetime
>> >     longer than the PCP server is willing to grant can 
>never be solved,
>> >     and therefore the entire work item is futile.
>> > Dave: This is an issue, but not an open issue.
>> > Dave: will confer with Alain about whether to start WG Last Call.
>> 
>> The chairs have agreed to start a WG last call.   We've seen 
>no additional
>> discussion on this draft since last IETF, so this email 
>initiates a last call on
>> draft-ietf-pcp-upnp-igd-interworking-01.   This call will 
>conclude in two
>> weeks (Friday July 27th), just prior to IETF.   Hopefully 
>that will allow
>> for discussion of WGLC comments in Vancouver.
>> 
>> We need at least 5 reviewers.  Please send comments to the list.
>> 
>> Thanks,
>> -Dave
>> 
>> 
>> 
>> 
>> _______________________________________________
>> pcp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pcp
>
>
>_______________________________________________
>pcp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcp
>