Subject: Re: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21

From: Simon Perreault <[email-masked]>
Date: Wed, 12 Feb 2014 17:20:19 -0500

All,

Here's my review...

Summary: This draft contains major issues that need to be resolved
before being sent to IESG.

> 3.  IP Address Selection
> 
>    These steps specify the behavior to be followed by the PCP client to
>    contact a PCP server when the PCP client has multiple IP addresses
>    for a single PCP server.

How does the client know that those addresses belong to a single PCP server?

Does this work when there are multiple addresses that belong to multiple
PCP servers, or does it need to be a single server?

Are we assuming that there is always a single PCP server per interface,
and therefore all addresses can only belong to a single server by
definition?

>    1.  If the PCP client can use both address families when
>        communicating to a particular PCP server, the PCP client SHOULD
>        select the source address of the PCP request to be of the same IP
>        address family as its requested PCP mapping (i.e., the address
>        family of the Requested External IP Address).

This is wrong. You can't pick a source address based on the requested
external address family. You can only pick the address family. For
example, you can decide that you're going to use IPv6 to request an IPv6
external address, but that does not help decide which source IPv6
address you're going to use.

And this is even more fundamentally wrong. The address family of the PCP
request depends on your internal address family, not the suggested
external address family. If your server is listening on IPvX, you send
your PCP request over IPvX. Otherwise you have to play games with
THIRD_PARTY. The external address family has nothing to do with it.

In fact, the source address you're going to select has to be one your
server is listening on. Otherwise you'll have to play games with
THIRD_PARTY. Often servers just listen on the wildcard address, so that
does not help you pick one particular address, but if that's not the
case then you don't have a choice.

Finally, "Requested External IP Address" is not a PCP term. I think you
mean "Suggested External IP Address".

>    2.  Whenever communicating with a PCP server, the rules of Section 6
>        of [RFC6724] SHOULD be followed by using the source address
>        selected in the previous step as input to the destination address
>        selection algorithm.

Step 1 did not yield a particular source address. It yielded an address
family. You still need to pick a particular source address.

>    3.  The PCP client initializes its Maximum Retransmission Count (MRC)
>        to 4.
> 
>    4.  The PCP client sends its PCP message to the PCP server's IP
>        address following the retransmission procedure specified in
>        Section 8.1.1 of [RFC6887].  If no response is received after MRC
>        attempts, the PCP client re-tries the procedure excluding the
>        destination addresses which did not respond.  The PCP client
>        SHOULD ignore any response received from an IP address after
>        exhausting MRC attempts for that particular IP address.  If, when
>        sending PCP requests, the PCP client receives a hard ICMP error
>        [RFC1122] it SHOULD immediately try the next IP address from the
>        list of PCP server' IP addresses.
> 
>    5.  If the PCP client has exhausted all IP addresses configured for a
>        given PCP server, the procedure is repeated every fifteen minutes
>        until the PCP request is successfully answered.
> 
>    6.  Once the PCP client has successfully received a response from a
>        PCP server's IP address, it sends subsequent PCP requests to the
>        same server's IP address until that IP address becomes non-
>        responsive, which causes the PCP client to follow the steps above
>        to contact its PCP server.

Do we reset the destination address set then? That is, are addresses
that failed previously now potentially good again?

> 4.  Multiple Interfaces
> 
>    When an end host has multiple interfaces concurrently active (e.g.,
>    IEEE 802.11 and 3G), a PCP client would discover different PCP
>    servers over different interfaces.  A host may have multiple network
>    interfaces (e.g, 3G, IEEE 802.11, etc.); each configured differently.
>    Each PCP server learned MUST be associated with the interface via
>    which it was learned.  Particularly, the PCP client relies on the
>    source IP address of an outgoing PCP request to select which PCP
>    server(s) to use.

That last sentence would be wrong following my feedback to section 3.

> 5.  Example: Multiple PCP servers on a Single Interface
> 
>    Figure 1 depicts an example that is used to illustrate the server
>    selection procedure specified in Section 3.
> 
>                                ISP Network
>                              |              |
>        .........................................................
>                              |              |        Subscriber Network
>                      +-------+------+  +----+---------+
>                      | PCP-Server-A |  | PCP-Server-B |
>                      |              |  |              |
>                      +-------+------+  +----+---------+
>             192.0.2.1        |              |     198.51.100.1
>             2001:db8:2222::1 |              |     2001:db8:3333::1
>                              |              |
>                              |              |
>                       -------+--------------+-----------
>                                      |
>                                      |    203.0.113.0
>                                      |    2001:db8:1111::1
>                                  +---+---+
>                                  | Host  |
>                                  +-------+
> 
>                                  Figure 1

The PCP servers in this figure look like routers. To make things clearer:

- Remove the connection from each PCP server to the ISP network.

- Draw the "PCP-controlled device". That one would look like a router
and would be sitting on the border between the subscriber network and
the ISP network. Connect it to both PCP servers and the host. No need
for addresses.

Is there only one PCP-controlled device, or does each server control its
own device?

>    The PCP client sends two PCP requests at the same time,

Really? The algorithm from section 3 does not seem to allow parallel
requests. I'm lost.

>    the first to
>    192.0.2.1 (corresponding to PCP-Server-A) and the second to
>    198.51.100.1 (corresponding to PCP-Server-B).  The path to
>    198.51.100.1 is working so a PCP response is received.  Because the
>    path to 192.0.2.1 is broken, no PCP response is received.  The PCP
>    client retries 4 times to elicit a response from 192.0.2.1 and
>    finally gives up on that address and sends a PCP message to
>    2001::db8:1111:1.  That path is working, and a response is received.
>    Thereafter, the PCP client should continue using that responsive IP
>    address for PCP-Server-A (2001:db8:1111::1).  In this particular
>    case, it will have to use THIRD_PARTY option for IPv4 mappings.

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

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 18 Feb 2014 14:20:44 +0000

Hi,

>How does the client know that those addresses belong to a single PCP

A PCP client, via DHCP for example, can learn a list of IP addresses for
the same PCP server and a list of unique PCP servers.
https://tools.ietf.org/html/draft-ietf-pcp-dhcp-09#page-5

>PCP servers, or does it need to be a single server?

It works in both cases.

The draft first describes how a PCP client goes about contacting a PCP
server that has multiple addresses. The same steps are to be followed for
each unique PCP server learnt (each of which may again have multiple
addresses).

>From the draft:
"If several PCP servers are configured, each with multiple IP addresses,
the PCP client contacts all PCP servers in parallel following the steps
described above."

>and therefore all addresses can only belong to a single server by

No, we're not making that assumption.

>address you're going to use.

Agreed. What is currently described addresses PEER and MAP+FILTER cases
where source and destination IP addresses are known.
In case of MAP, what you say is right. For MAP, based on the address
family the client intends to listen on, the client makes an appropriate
request to each distinct server. We'll have to fix this.

>mean "Suggested External IP Address".

Ok.

>that failed previously now potentially good again?

Yes, the client has to attempt contacting the servers again.

>Is there only one PCP-controlled device, or does each server control its

Each server controls its own device. With this clarification, do you still
think the figure needs to be updated? The text below the figure
illustrates how the client goes about contacting the two distinct servers.

>Really? The algorithm from section 3 does not seem to allow parallel

It does, as described in an earlier comment and the last paragraph of
http://tools.ietf.org/html/draft-ietf-pcp-server-selection-02#section-3.
There are two potential scenarios. A single server having multiple
addresses AND multiple PCP servers itself. The draft tries to address both
scenarios. If this is unclear, we'll have to see how to re-organize to
make it more obvious.

-Prashanth

>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp

---

From: Simon Perreault <[email-masked]>
Date: Tue, 18 Feb 2014 09:28:08 -0500

> the PCP client contacts all PCP servers in parallel following the steps

Good. That makes sense.

> Yes, the client has to attempt contacting the servers again.

Ok. It would be nice to mention it explicitly.

> think the figure needs to be updated?

Yes.

> scenarios. If this is unclear, we'll have to see how to re-organize to

I think that would be necessary.

Thanks,
Simon