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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 26 Feb 2014 03:08:36 +0000

> -----Original Message-----
> From: Simon Perreault [mailto:[email-masked]]
> Sent: Tuesday, February 18, 2014 7:58 PM
> To: Prashanth Patil (praspati); [email-masked]
> Subject: Re: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due
> by FEB 21
> 
> Le 2014-02-18 09:20, Prashanth Patil (praspati) a écrit :
> >> How does the client know that those addresses belong to a single PCP
> >> server?
> >
> > 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
> >
> >
> >>
> >> Does this work when there are multiple addresses that belong to
> >> multiple 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."
> 
> Good. That makes sense.
> 
> >>>    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?
> >
> > Yes, the client has to attempt contacting the servers again.
> 
> Ok. It would be nice to mention it explicitly.
> 
> >>> 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?
> >
> > Each server controls its own device. With this clarification, do you
> > still think the figure needs to be updated?
> 
> Yes.

Can you please provide more details why this figure needs to be updated ?

-Tiru

> 
> >>>    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.
> >
> > 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.
> 
> I think that would be necessary.
> 
> Thanks,
> 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: Simon Perreault <[email-masked]>
Date: Wed, 26 Feb 2014 08:20:11 -0500

> Can you please provide more details why this figure needs to be updated ?

Because:

1. The PCP servers look like routers. They should not be connected at
the top.

2. The PCP-controlled device(s) is/are not shown. We don't know whether
there are two PCP servers controlling a single device or two PCP servers
each controlling its own device.

Simon