Subject: [pcp] GET/NEXT OpCode

From: <[email-masked]>
Date: Mon, 14 Mar 2011 10:15:50 +0100

Dear all,

A new version of the PCP Failure I-D has been submitted: http://tools.ietf.org/html/draft-boucadair-pcp-failure-01.

Only one OpCode is used to retrieve the explicit mappings from the PCP Server.

Comments are welcome.

Cheers,

Med

********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************

---

From: Dave Thaler <[email-masked]>
Date: Sun, 27 Mar 2011 14:55:26 +0000

I've read through this draft, and have two questions.

1)      I don't quite understand the scenario where a client needs to get any state from the server.   Specifically, if there's no entity actually listening, then there's not much point in having a mapping open for it.  And if there is an entity listening, the client can detect that and use that fact rather than getting it from the server.   It seems like that approach would work regardless of how many layers of PCP there are, or how many entities reboot at the same time.

2)      I can however imagine that there is a need to enumerate state on the server for management purposes.  But for that scenario, rather than re-inventing GET/GETNEXT logic, one can simply define a MIB and leverage existing SNMP support for GET/GETNEXT, especially since it seems like one might want to have a MIB anyway.

-Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 14, 2011 10:16 AM
To: [email-masked]
Subject: [pcp] GET/NEXT OpCode

Dear all,

Comments are welcome.

Cheers,

Med

---

From: Dave Thaler <[email-masked]>
Date: Sun, 27 Mar 2011 14:58:59 +0000

Forgot to add a comment (that is not a question).

I do believe there are some good points in the doc that should
result in additions to the base doc, though I'm not convinced there's
any new syntax required.   For example, I do agree that the base
spec should say something about what a client should do on an
IP address change.  For example, if I have an app listening to
INADDR_ANY / IN6ADDR_ANY, and the host's IP address changes,
the app obviously continues listening, but the PCP client needs
to notice the change and trigger PCP messages, as noted in the
failure document.   I agree that this should be added to the base spec.

-Dave

From: Dave Thaler
Sent: Sunday, March 27, 2011 4:55 PM
To: [email-masked]'; [email-masked]
Subject: RE: GET/NEXT OpCode

-Dave

Dear all,

Comments are welcome.

Cheers,

Med

---

From: <[email-masked]>
Date: Sun, 27 Mar 2011 18:44:01 +0200

Dear Dave,

Take the example of a reboot of an IWF or a CPE, if the mappings are not stored in a permanent storage, the IWF/PCP Client will loose the state. This is problematic if you want to access to your webcam from outside for instance.

The GET/NEXT can also be used to avoid stale mappings on the CGN otherwise you will need to send a "delete all" which may induce issues in case several PCP Clients are enabled in the LAN or are embedded in the same host.

Cheers,
Med

________________________________
De : Dave Thaler [mailto:[email-masked]]
Envoyé : dimanche 27 mars 2011 16:55
À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Objet : RE: GET/NEXT OpCode

-Dave

Dear all,

Comments are welcome.

Cheers,

Med

---

From: Dave Thaler <[email-masked]>
Date: Sun, 27 Mar 2011 16:57:55 +0000

Med writes:
> Take the example of a reboot of an IWF or a CPE, if the mappings
> are not stored in a permanent storage, the IWF/PCP Client will 
> loose the state. This is problematic if you want to access to your 
> webcam from outside for instance.  

I don't see that as any different from the case where the IWF/CPE
is the server and the host is the client.  If the IWF/CPE reboots 
and it has no persistent storage, it'll lose state unless/until the 
client refreshes the state, which it can do without enumerating.

> The GET/NEXT can also be used to avoid stale mappings on the
> CGN otherwise you will need to send a "delete all" which may
> induce issues in case several PCP Clients are enabled in the LAN
> or are embedded in the same host.
 
If the client drops off the network, and may or may not be 
replaced with another client with the same IP address,
you have stale mappings.  This case is no different.
And regarding a "delete all", if the server keeps the port number
of the PCP client, then a "delete all" would be unambiguous and
apply only to that port.

-Dave
________________________________________

-Dave

Dear all,

---

From: Francis Dupont <[email-masked]>
Date: Mon, 28 Mar 2011 09:23:41 +0200

In your previous mail you wrote:

   1) I don't quite understand the scenario where a client needs to
   get any state from the server.  Specifically, if there's no entity
   actually listening, then there's not much point in having a mapping
   open for it.

=> there are two answers: the theorical one and the practical one.

About the theory I'll use set maths: what we want is synchronization,
i.e., C = S where C is the client view of explicit dynamic mappings,
and S is the server one. What we have is the refresh all operations,
which gives C included in S (the idea is to get both C included in S
and S included in C which is known to be equivalent to C = S),
and explicitly by 'delete all' or implicitly after server reboot,
S is the empty set. It is not enough.

About the practice you have intermediate nodes (IWF/proxies) and
of course any elements of S which are not in C are stale mappings
which have no good properties.

   And if there is an entity listening, the client can
   detect that and use that fact rather than getting it from the
   server.  It seems like that approach would work regardless of how
   many layers of PCP there are, or how many entities reboot at the
   same time.
   
=> this is in fact an argument which could prove the client doesn't
need stable/persistent storage to know its explicit dynamic mapping set.
   
   2) I can however imagine that there is a need to enumerate state on
   the server for management purposes.  But for that scenario, rather
   than re-inventing GET/GETNEXT logic, one can simply define a MIB
   and leverage existing SNMP support for GET/GETNEXT, especially
   since it seems like one might want to have a MIB anyway.
   
=> I don't buy this argument for two reasons: in theory you can do
anything using the MIB so why bother with PCP? In practice I don't
believe you'll get SNMP access to home gateways (remember there are
two kind of Ethernet switches and the real difference is SNMP support
or not), nor ISPs will give SNMP access on CGNs to users: SNMP is
a typical ISP management tool.

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Mon, 28 Mar 2011 09:33:45 +0200

any new syntax required.

=> I believe this means 'required in the base document'.
Without a clear criterion about what should go in the base document
and what could go in extensions I can't answer:
 - it is clear GET/NEXT is not very useful for Home Gateways
 - at the opposite it is critical for IWF/CGN combination
BTW I can ask the same question about the PEER stuff: the fact it is
in the base document does mean it is mandatory to support?
If this is the case be prepared to receive objections...

   For example, I do agree that the base
   
=> the goal of the failure document is to provide material to
improve the specs, including the base spec where it should be.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Mon, 28 Mar 2011 09:43:50 +0200

=> the 'if' is not in the protocol specs so doesn't apply.

Regards