Subject: [pcp] Comments on draft-cheshire-pcp-recovery-02

From: RJ Atkinson <[email-masked]>
Date: Tue, 1 Nov 2011 09:54:23 -0400

Earlier, Dave Thaler wrote:
> 1) This draft uses port 5350 rather than the existing PCP port 5351.
> It contains no justification that I saw as to why it
> cannot use the same port number.  Port space is scarce,
> so this should either justify why it needs two, or else
> (my preference) use the same port number as PCP.

Agreed.

(Might this be a aimple typing error ?  :-)

> 2) It says "MUST inform PCP clients of this fact by multicasting
> the UDP packet shown below on all multicast-capable interfaces".  
> The implication is that it must do so even if it has some way to
> know (e.g. a CGN being manually configured with that topological
> knowledge) that there are no PCP clients on that interface,
> which results in extra overhead.
> I wanted to point this out in case anyone felt this is an issue
> and there is some reason to change to a SHOULD.  
> I'm personally fine either way.

I am fine with the current text.  I don't think the overhead
added would be significant, even on low-bandwidth RF links.

I dislike watering the requirement down to "SHOULD" here, 
as it defeats the purpose of this mechanism (i.e. ensuring 
that PCP deployments achieve the needed resilience).

If some folks found the current wording greatly objectionable, 
I could live with "MUST ... unless" style wording, where the
"unless" clause exempted interfaces with no possibility 
of a PCP client being connected via that interface.  
In this case, "no possibility" does not mean "unlikely".

Yours,

Ran

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 01 Nov 2011 09:52:24 -0700

> (Might this be a aimple typing error ?  :-)

Actually no, it's intentional. Originally we used to use the same  
port for client requests and server announcements, but some time in  
2007 we ran into problems (described below), and switched to a  
different announcement port. I have added this text to the draft:

    Note: The reason that server-to-client restart announcements use a
    port (5350) that's different from the client-to-server request port
    (5351) is for pragmatic implementation reasons.  A single device may
    have multiple roles.  A multi-function home gateway may also provide
    printer sharing.  A home computer may also provide "Internet  
Sharing"
    (NAT) functionality.  Such devices need to act as both a PCP Server
    and a PCP Client at the same time, and the software that implements
    the PCP Server on the device may not be the same software component
    that implements the PCP Client.

    o  The software that implements the PCP Server needs to listen for
       unicast client requests.

    o  The software that implements the PCP Client needs to listen for
       multicast Rapid Recovery restart announcements.

    In most networking APIs is is difficult or impossible to have two
    independent clients listening for both unicasts and multicasts on  
the
    same port at the same time.  For this reason it makes sense to have:

    o  A single PCP Server listening for unicast client requests on port
       5351, and

    o  Zero, one, or more independent PCP Clients listening (using
       SO_REUSEPORT or equivalent) for multicast restart  
announcements on
       port 5350.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org