Subject: Re: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers

From: <[email-masked]>
Date: Fri, 27 Sep 2013 15:58:01 +0200

Dear all,

Thanks for those who already answered to this message. I'm re-sending to seek for more opinions.

Thanks in advance.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de
>[email-masked]
>Envoyé : mardi 13 août 2013 08:26
>À : [email-masked]
>Objet : [pcp] draft-ietf-pcp-dhcp: multiple pcp servers
>
>Dear all,
>
>The design of the DHCP PCP option (http://tools.ietf.org/html/draft-ietf-
>pcp-dhcp-08) assumes:
>(1) multiple pcp servers may be received from the same DHCP server.
>(2) one pcp server may be reachable with multiple IP addresses.
>(3) when multiple pcp servers are returned, the pcp client will need to
>contact all these servers.
>(4) It is up to an administrative entity to return one or multiple pcp
>servers. No restriction is made by design.
>
>FWIW, this design was in the draft since -02.
>
>Dave is echo'ing a comment which objects this design and advocates for
>restricting the design to return only one pcp server and it is up to the
>administrative entity to sync the state in all enabled PCP servers. IMO,
>this objection is not technically sound, at least for the following
>reasons:
>
>(1) The protocol cannot discover in one single request all external IP
>addresses and port numbers. Imagine the case where a NPTv6 and NAT64 boxes
>are deployed. The PCP client has no means to learn with one single request
>to a single PCP server both the external IPv4 address (assigned by the
>NAT64 device) and the external IPv6 address assigned by the NPTv6 box. The
>same issue is encountered when multiple NAT configured with distinct pool
>are in place.
>
>(2) A host connected to a multi-homed domain, in which FW are located at
>the border router in front of each adjacent domain, will need to open
>pinholes in these FW if it want to receive incoming traffic from a remote
>peer.
>
>(3) The protocol does not specify how state synchronization is to be
>achieved between several PCP servers. The task is even complex when these
>pcp servers are controlling functions of distinct types (e.g., NAT44, FW,
>NAT64, Port Range Router, etc.). Other issues are raised (see to the pcp-
>server-selection thread)
>
>(4) Mandating one and only one pcp server is to be returned is really
>deployment-specific. This assumption will induce a lot of complexity at the
>network side
>
>For those who are objecting the design as currently documented in -07, it
>is time to raise your concern (preferably with the technical arguments that
>motivate your point). If no technical argument is made, the current design
>will be maintained as it is.
>
>Cheers,
>Med
>
>-----Message d'origine-----
>De : BOUCADAIR Mohamed OLNC/OLN
>Envoyé : lundi 12 août 2013 07:56
>À : 'Dave Thaler'; Ted Lemon
>Cc : Reinaldo Penno (repenno) ([email-masked]); Dan Wing
>([email-masked])
>Objet : RE: PCP DHCP I-D: your feedback is needed
>
>Hi Dave,
>
>I disagree to put the constraint on the network deploying many PCP servers
>to coordinate state instantiating. This is a deployment specific assumption
>which is not trivial to honor.
>
>A domain may deploy various pcp server controlling functions which are not
>of the same nature, e.g., a domain may deploy:
>* one or multiple nat64 provisioned to IPv6-only hosts
>* one or multiple nptv6 provisioned to IPv6-only and dual stack hosts
>* one or multiple nat44 provisioned to IPv4-only and dual stack hosts
>* one or multiple IPv4 fw
>* one or multiple IPv6 fw
>* multiple flow-based access routers
>* etc.
>
>The design as currently document in the pcp server selection draft (and its
>dhcp instantiation) does not make any deployment assumption. As such:
>* an administrative entity can return one single IP address but instead it
>must ensure state are installed in other servers.
>* an administrative entity can return multiple servers; it is up to the
>client to contact these servers to install the state.
>
>This is much more better than constraining the design by non-valid
>deployment assumptions.
>
>I agree, this should be discussed in the list.
>
>Cheers,
>Med
>
>>-----Message d'origine-----
>>De : Dave Thaler [mailto:[email-masked]]
>>Envoyé : mercredi 7 août 2013 19:56
>>À : Ted Lemon; BOUCADAIR Mohamed OLNC/OLN
>>Cc : Reinaldo Penno (repenno) ([email-masked]); Dan Wing
>>([email-masked])
>>Objet : RE: PCP DHCP I-D: your feedback is needed
>>
>>I think this thread should move to the main WG mailing list, so Ted if you
>>agree,
>>please forward/respond on this thread there.
>>
>>This is related to my comments on draft-ietf-pcp-server-selection-01.txt.
>>
>>If the app needs semantics of "contact each PCP server" then you need to
>>know
>>how to distinguish PCP servers.  Now more recently various members of the
>>WG (e.g. Stuart) have disputed the notion that an app needs to "contact
>>each PCP
>>server" and so we do not have consensus that this is required.   Stuart
>>proposed
>>that it's the PCP server's job to coordinate with any other servers
>managed
>>by
>>the same entity (or to steal a term from MIF... within the same
>>provisioning domain).
>>No one has given a counter argument, and so I said in email we should
>start
>>with that
>>assumption.
>>
>>You do need to distinguish provisioning domains (for reasons discussed in
>>MIF that
>>apply to PCP like they do to anything else).   So the only remaining
>>interesting case
>>I think is figure 2 in section A.2 of draft-ietf-pcp-server-selection-
>>01.txt where if
>>you have a local gateway with a DHCP server (e.g. a home gateway) that's
>>multi-homed
>>to two external provisioning domains each with their own PCP server(s),
>>what do you
>>get from DHCP?  I think the best answer here is to make the local gateway
>>be a
>>PCP proxy, and so DHCP just gives you its address.
>>
>>In such a solution, I believe there is no need to differentiate between
>>multiple
>>IPs of the same server vs multiple IPs of different servers.  That is, you
>>communicate
>>with any one server IP, and you assume that it will take care of making
>>sure that
>>all servers with any of those IPs get the info.
>>
>>I believe this then removes any new concepts from DHCP and requires no
>>additional support in DHCP servers.
>>
>>-Dave
>>
>>> -----Original Message-----
>>> From: Ted Lemon [mailto:[email-masked]]
>>> Sent: Wednesday, August 7, 2013 8:26 AM
>>> To: [email-masked]
>>> Cc: Dave Thaler; Reinaldo Penno (repenno) ([email-masked]); Dan Wing
>>> ([email-masked])
>>> Subject: Re: PCP DHCP I-D: your feedback is needed
>>>
>>> On Aug 7, 2013, at 3:00 AM, [email-masked] wrote:
>>> > Ok, done.
>>>
>>> Thanks.
>>>
>>> Can you explain your motivation for adding new text differentiating
>>between
>>> multiple IP addresses that refer to the same PCP server, and multiple IP
>>> addresses that refer to different PCP servers?   Is this something the
>>working
>>> group asked to have added to the document?   I think this is a new
>>concept in
>>> the current document, and of course, it requires special support in the
>>DHCP
>>> server and DHCP client just for PCP.
>>>
>>> This is not the only issue with your current set of edits to the
>>document, but
>>> I'd just like to get clarity on this one issue before proceeding on to
>>the next.
>>>
>>
>>
>
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp

---

From: Ted Lemon <[email-masked]>
Date: Fri, 27 Sep 2013 16:16:50 -0400

>> will be maintained as it is.

Excuse me, Med, but are you saying that you propose to do the consensus call yourself?

It's pretty clear to me that there is strong objection to this proposal, but when the person objecting does so, nobody responds.   So that's an unaddressed objection.   The WG chairs are much more on top of the discussion than I am, so I am not personally trying to assert that the consensus is one way or another, but I would certainly like to see a meaningful debate on this topic, and not just a lot of assertions that go unanswered.

Do you intend to come to the working group meeting in Vancouver?

The person objecting to your proposed use model is an implementor of clients.   You are a deployer of servers.   You and that person have _very_ different views of the network.   It's not surprising that you disagree, but you need to work out your differences.   It would help if other potential client implementors would weigh in on the conversation.

(When I say "client implementors," I do not mean people who've written test clients—I mean people who intend to write clients that users will use.)

---

From: <[email-masked]>
Date: Mon, 30 Sep 2013 10:24:43 +0200

Hi Ted,

No, this is not a consensus call. This is a  gentle reminder for guidance from the WG.

I already recorded your objection to the use of multiple options. 

We don't need to wait for the physical meeting to progress the document. I would hope we can make some progress using the mailing list. 

Cheers,
Med

>De : Ted Lemon [mailto:[email-masked]]
>Envoyé : vendredi 27 septembre 2013 22:17
>À : BOUCADAIR Mohamed IMT/OLN
>Cc : [email-masked]
>Objet : Re: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers
>
>It's pretty clear to me that there is strong objection to this proposal,
>but when the person objecting does so, nobody responds.   So that's an
>unaddressed objection.   The WG chairs are much more on top of the
>discussion than I am, so I am not personally trying to assert that the
>consensus is one way or another, but I would certainly like to see a
>meaningful debate on this topic, and not just a lot of assertions that go
>unanswered.
>
>The person objecting to your proposed use model is an implementor of
>clients.   You are a deployer of servers.   You and that person have _very_
>different views of the network.   It's not surprising that you disagree,
>but you need to work out your differences.   It would help if other
>potential client implementors would weigh in on the conversation.
>
>(When I say "client implementors," I do not mean people who've written test
>clients-I mean people who intend to write clients that users will use.)

---

From: Ted Lemon <[email-masked]>
Date: Mon, 30 Sep 2013 09:20:11 -0400

> I already recorded your objection to the use of multiple options. 

If you recorded my objection to the use of multiple options, it sounds like you are in fact evaluating consensus.   Regardless, it is not me of whom I was speaking in my previous message—Stuart Cheshire has raised substantive objections to your proposed deployment model, and you have not answered them.

---

From: <[email-masked]>
Date: Mon, 30 Sep 2013 15:39:52 +0200

Re-,

I already answered to a message form Stuart on the deployment model; please check http://www.ietf.org/mail-archive/web/pcp/current/msg03345.html 

Cheers,
Med

>Envoyé : lundi 30 septembre 2013 15:20
>If you recorded my objection to the use of multiple options, it sounds like
>you are in fact evaluating consensus.   Regardless, it is not me of whom I
>was speaking in my previous message-Stuart Cheshire has raised substantive
>objections to your proposed deployment model, and you have not answered
>them.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 30 Sep 2013 10:26:20 -0400

> I already answered to a message form Stuart on the deployment model; please check http://www.ietf.org/mail-archive/web/pcp/current/msg03345.html 

You explained your deployment model, and I think it was a helpful explanation, but you didn't address the problem he described.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 30 Sep 2013 15:09:31 +0000

Is this a good formulation of the problem: "what does a client that
receives multiple PCP server address should do if it can not (or does not)
have code to make use of them?"

On 9/30/13 7:26 AM, "Ted Lemon" <[email-masked]> wrote:

>> I already answered to a message form Stuart on the deployment model;
>>please check 
>>http://www.ietf.org/mail-archive/web/pcp/current/msg03345.html
>
>You explained your deployment model, and I think it was a helpful
>explanation, but you didn't address the problem he described.
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 30 Sep 2013 11:17:45 -0400

> have code to make use of them?"

I think there are two issues that we are conflating into one:

1. Under what circumstances and through what mechanism would a DHCP client be configured with multiple PCP servers?
2. How does a PCP client deal with multiple PCP servers?

As I mentioned to Med, I think privately, I think there is no circumstance in which multiple PCP servers make sense for a single egress.   The situation where multiple servers do make sense is if the network is multihomed, or the client has multiple interfaces.   So I think it's actually a multiple provisioning domain problem, and that is the only case where we need to deal with this.

(See https://datatracker.ietf.org/doc/draft-anipko-mif-mpvd-arch/ for details on the multiple provisioning domain problem.)