Re: [pcp] well-known address for PCP [was Re: Comments on draft-ietf-pcp-server-selection-01]

[<[e-mail]>]

Dan,

For the typical use case you mentioned (i.e., PCP service operated by an operator), having an explicit provisioning means to enabled/disable PCP service is more likely for various reasons such as:

* Avoid overloading the network with useless traffic (e.g., limit the usage of radio resources for the mobile network). 
* Flow-based access control policies may not be managed by an on-path device (e.g., separate PCP server and PCP-controlled device model)
* Multiple flow-based policies may be enforced at multiple entry points. Having a means to interact with all of them in // is likely to be required.
* The node which enforces the flow-based policies may not be able to relay the request to another upstream PCP-controlled device (e.g., not explicitly configured to do so)
* The anycast-based model will require Epoch values are appropriately configured in multiple servers listening on the same address; if not the client won't be able to detect state loss when a failure occurs.
* The anycast-based model cannot work in the proxy model if non-explicit server(s) is configured to the proxy: this is a simple forwarding issue (the proxy should listen on anycast address and use that same address to reach the upstream server).  

Cheers,
Med

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] De la part de Dan
>Wing
>Envoyé : vendredi 16 août 2013 04:49
>À : Stuart Cheshire
>Cc : [e-mail]; [e-mail]
>Objet : [pcp] well-known address for PCP [was Re: Comments on draft-ietf-
>pcp-server-selection-01]
>
>
>On Aug 15, 2013, at 7:06 PM, Stuart Cheshire <[e-mail]> wrote:
>
>> On 8 Aug, 2013, at 07:28, Dave Thaler <[e-mail]> wrote:
>>
>>> Stuart asserted that communicating with one is sufficient, and simpler
>for the
>>> client, because it's the PCP server's job to communicate with the other
>ones
>>> to permit incoming ICE connectivity checks.  If you disagree with that,
>>> please respond with a technical argument as to why having the client
>>> communicate with both is better than having one server communicate
>>> with the other.
>>
>> Dave has represented my opinion accurately, but I'll elaborate a little.
>>
>> Today, a network client makes a NAT mapping (or a firewall hole) by
>sending an outbound TCP SYN. That is all. If there are nested NATs, the
>client doesn't have to know about that. If there are parallel NATs with
>multiple network ingress and egress points, then the client doesn't have to
>know about that either. The NAT that sees the outbound TCP SYN is
>responsible for communicating with its NAT peers to ensure that the right
>state is created so that inbound traffic is handled correctly.
>>
>> Right now the Mac OS X and iOS PCP client handles only a single PCP
>server. I suspect it will only ever handle a single PCP server. I suspect
>that many consumer electronics products like network security cameras will
>also only support a single PCP server. So if you're a network router vendor
>that's selling a product that lets the customer load-balance across
>multiple ingress and egress paths, then you'd better make it look like a
>single PCP server to the client, or it won't work and you won't be able to
>sell it. If you're providing nested NAT, then you'd better make it look
>*exactly* like a single PCP server to the client (i.e. recursive PCP), or
>it won't work and you won't be able to sell it.
>>
>> I had originally advocated that the PCP client sends its PCP requests to
>a fixed well-known anycast address, and it's up to the network to do the
>right thing with that. In a simple network with a single NAT, the NAT
>intercepts the PCP request and handles it. In a more complicated network,
>the network may have to do more complicated things, but that's transparent
>to the client.
>>
>> However, I was not successful arguing for a fixed well-known any cast
>address, so instead the client sends its requests to its default router. I
>suspect Mac OS X and iOS may only ever send their PCP requests to their
>default router.
>
>We have encountered use cases where such a well-known anycast address would
>be very useful, most notably with draft-wing-pcp-flowdata where an existing
>non-PCP-aware router or NAT is in the local network and the ISP is
>operating a PCP-speaking and draft-wing-pcp-flowdata-aware router, and we
>want to use draft-wing-pcp-flowdata to ask the ISP to provide
>differentiated service for a certain flow (e.g., make Skype or Netflix work
>better than BitTorrent in the downstream direction).  Reinaldo wrote up
>draft-kiesel-pcp-ip-based-srv-disc, but as it wasn't on PCP's agenda I have
>not researched how Reinaldo's proposal differs from draft-cheshire-pcp-
>anycast.
>
>-d
>
>
>> This means that if you want to sell some fancy network product that
>supports parallel and/or nested NATs and firewalls, it had better work with
>clients that only send requests to their default router, because that's all
>you're going to see in the field for quite some time.
>>
>> It's easy to write documents telling PCP clients what they should be
>doing, but I'd like to see some vendors stepping up and volunteering for
>that commitment. Do we have a vendor of some $49 network security camera
>volunteering to support multiple PCP servers? How would that even work? If
>it requires *any* user configuration, it's a non-starter. Once you accept
>manual user configuration, it's easier to just make some port mappings by
>hand. The win of PCP is that it allows plug-and-play zero configuration
>operation. The moment the user has to configure the device with the address
>of its PCP server, it's easier to configure the NAT gateway with a manual
>port mapping. And if you suppose a DHCP option to do this configuration,
>the home gateway has to be updated to support that DHCP option, and if you
>have to update the home gateway then it's easier to put recursive PCP
>support into the gateway (works today with all PCP clients) than it is to
>add support for the PCP DHCP option
> (d
>> oesn't work until clients are updated to understand the new option).
>>
>> Stuart Cheshire
>>
>> _______________________________________________
>> pcp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pcp
>
>_______________________________________________
>pcp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcp