Subject: Re: [pcp] PCP in Service Provider Networks - (was Re: Comments on draft-cheshire-pcp-recovery-02)

From: RJ Atkinson <[email-masked]>
Date: Fri, 4 Nov 2011 09:57:02 -0400

Folks,

I suspect that some of the underlying concerns here could be
resolved by making editorial changes (and NOT making any 
protocol changes) to the draft-ietf-pcp-base specification 
-- and maybe also to the PCP Rapid Recovery specification.

1) Meaning of the word "device" in the PCP specifications

**I think the current use of the word "device" in various 
  places in the PCP Base specification might be confusing 
  to some readers. 

I read the word "device" to mean either a "logical device" 
or a component of a logical system, where a single physical 
system might contain  multiple independent logical systems 
OR a single logical system might be spread across more than 
one physical package ("chassis").  Some other readers of the 
base specification might interpret the word "device" as 
meaning a single physical package ("chassis").  

(DISCLAIMER: I don't claim to understand other folks' system 
internals.  Separately, my crystal ball is broken, so I also 
don't know what other folks are thinking.  Several guesses
follow, please be gentle if I guess incorrectly. :-)

My guess, quite possibly confused or wrong, and based entirely
from Reinaldo's comments and diagram, is that he is thinking 
about a single physical system ("chassis") that contains 
multiple independent logical systems (e.g. Virtual System 1, 
Virtual System 2) that have *disjoint* sets of client-facing 
network interfaces.  Specifically, PCP-client-facing interface
X is associated with 1 and only 1 virtual system, for all X
that are present in the chassis.

[NB: I'll abbreviate "Virtual System 1" as "VS1" hereafter.]

(A) As I read both the base specification and also the Rapid
Recovery specification, VS1 and VS2 are NOT the same system,
but are instead separate independent logical systems that 
happen to exist in the same physical chassis, each of which
has its own separate PCP Server function and NAT/Firewall 
function, and which have disjoint sets of PCP-client-facing 
network interfaces.  In this understanding, if the PCP Server 
function associated with VS1 reboots, or otherwise PCP state 
for VS1 might have been lost, then the PCP Rapid Recovery 
messages are sent out all potentially PCP-client-facing 
network interfaces associated with VS1, but NOT out any 
potentially PCP-client-facing interfaces that are NOT 
associated with VS1.

(B) However, if someone else read the word "device" in the 
PCP Base specification and in the Rapid Recovery specification 
differently, such a person might understand those documents 
to say that if the PCP Server associated with VS1 rebooted, 
or otherwise PCP state might have been be lost, then 
PCP Rapid Recovery messages must be sent out all potentially 
PCP-client-facing interfaces of the chassis.

At this point, it would be helpful if the several authors of
the PCP Base Specification and the author of the PCP Rapid
Recovery specification could clarify on the PCP list 
whether (A), (B), or (C) some other meaning is intended 
by those documents.

Depending upon the answers from those folks, it might be
sensible to make a purely editorial pass (across both the
PCP Base Specification and the PCP Rapid Recovery specification)
to minimise the use of the word "device" or to edit the word 
"device" to say something more flexible (possibly "logical 
device" or "virtual system" instead) instead.  [Edit to taste]

2) PCP Conceptual Model

Another thing that might be considered are edits to 
Section 4 of the PCP Base specification to show 3
conceptual components -- splitting the PCP Server
function from the NAT/Firewall function and also
updating the text accordingly.  

One might also update the Title of Section 4 to
be something more like "PCP Conceptual Model"
or "PCP Concept of Operations" and to talk not
only about the relationship between the "PCP
Server" and its "NAT/Firewall" but also include
some text about the relationship between the "PCP Client" 
and "PCP Server".  That would not be a huge change,
since Figure 1 already shows the PCP Client.

Now, it is outside our scope to say how the PCP Server 
function communicates with its NAT/Firewall function 
if they are separate packages, and we would NOT want 
to force anyone to implement the two separately, 
but it might help clarify the PCP operational concept 
while reducing the probability that an implementer
would misunderstand the "conceptual model" as being
a requirement for a "specific implementation approach".

LAST:

As I noted at the top, I don't think any of this
represents any change to the PCP protocol or to 
the intended PCP Concept of Operations. Instead,
these purely would be clarifying edits to reduce 
the potential for misunderstanding.

Yours,

Ran

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 4 Nov 2011 18:39:41 -0400

Hello,

Some comments inline...

> [NB: I'll abbreviate "Virtual System 1" as "VS1" hereafter.]

Correct, or across multiple chassis, exactly like SDNs.

> a requirement for a "specific implementation approach".

As I mentioned in our thread, whoever wants to separate PCP Server and CGN
will certainly need to deal with that. My concern (other than VSs) is the
separation of subscriber facing interfaces (which have PCP clients on the
end of it) from (PCP Server + CGN) and its implication on base and RR specs

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

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 5 Nov 2011 06:54:12 -0400

> Correct, or across multiple chassis, exactly like SDNs.

Thanks.  That is helpful to understand.

So, as near as I can tell, the existing PCP specs
(e.g. base, Rapid Recovery) do not prevent 
(A) multiple virtual systems in one chassis 
or (B) a single system spread across multiple chassis.

As I read the spec, and it would help if the authors
would clarify whether I'm confused, the specs are always
talking about a single "logical" system or "logical" device, 
which an implementer can package anyway the implementer 
desires -- so long as the external behaviour is the same 
as if it had been packaged together as a single system 
in a single box.

If that is the bit that is problematic for you, I think 
the authors could make a light editorial pass on both the 
base spec and the Rapid Recovery spec and make it more clear 
that the word "device" means "logical device" or "virtual
device".  (NB: I don't think the specs/protocols themselves 
need to change to support this, I'm thinking of purely editorial
changes.)

> end of it) from (PCP Server + CGN) and its implication on base and RR specs

This part I don't fully understand yet, mainly because
where the several PCP specs talk about interfaces,
I understand those to be interfaces *of* the CGN.

I do not grasp how a CGN could be built that is both
useful and also has zero network interfaces.

If you could explain that piece in more detail, that
at least would help me understand your concerns better.

Cheers,

Ran

---

From: Reinaldo Penno <[email-masked]>
Date: Sat, 5 Nov 2011 19:56:27 -0400

> I understand those to be interfaces *of* the CGN.

Right.

> useful and also has zero network interfaces.

Please refer to my earlier picture. The CGN/NAT certainly has interfaces ,
but PCP clients are not directly connected.

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 7 Nov 2011 06:23:47 -0500

>> I understand those to be interfaces *of* the CGN.

I'm glad there is agreement on that. :-)

> Please refer to my earlier picture. The CGN/NAT certainly
> has interfaces, but PCP clients are not directly connected.

In some deployment models consistent with your earlier description
and picture, (at least) some PCP clients still might be directly 
connected.  If the virtual system has lost state, then 
(by definition) the virtual system *cannot* know a priori 
where the PCP clients are or might be.

Your complaint earlier was that you did not want to send 
the Rapid Recovery out all of the CGN/NAT interfaces 
associated with that virtual system **for performance reasons** 
-- which appears to be different from what you said just above.

Yours,

Ran

(PS:  Feel free to write longer notes with more explanation.
     Your current notes are admirably short, but consequently
     are not very clear to (at least) several folks on the 
     PCP list.  :-)