Subject: [PCN] Open issues on architecture draft.

From: <[email-masked]>
Date: Thu, 22 Nov 2007 13:32:04 -0000

Hi,

Hi,

Scott & Steven asked me to prepare a list of
open/problematic/controversial issues on the draft-pcn-architecture-02. 
Please feel free to add things that are missing.

We should try & close these issues, or at least advance them, before
Vancouver. To make the meeting itself as useful as poss.

I've divided them into issues that I think need some discussion, and
issues that I think are closed but I want to make sure.

Known issues needing some discussion
=====================================
1. OAM (Section 8)
The text needs reviewing. Personally I think it needs only minor
refinements, but it needs an OAM expert to read it.
See bob's request
http://www1.ietf.org/mail-archive/web/pcn/current/msg00911.html 

2. Partially PCN-capable tunnel
(ie one end of the tunnel is in the PCN-domain, the other end isn't)
the new text in S5.7 needs checking. 
See http://www1.ietf.org/mail-archive/web/pcn/current/msg00929.html 

3. Probing
I believe the current S7 (new in version -02) is too much of a
discussion to be appropriate for this architecture doc.
There's no consensus on:
A) in what circumstance(s) probing is actually useful or not
B) whether the decision on A can be punted until later (although probing
isn't, I think, in the scope of the initial Charter, the answer to A
seems to affect significantly what kind of marking behaviour is good).

Need to decide on this for all 3 (or 4) reasons that people have
discussed for probing (see S7.3):
(1) no PCN-traffic on the ingress-egress-aggregate, so can't estimate
level of pre-congestion on it
(2) ECMP (a) traffic unbalanced across ECMP paths, so decision based on
level of pre-congestion on ingress-egress-aggregate is likely to be
inaccurate
         (b) base decision on level of pre-congestion on ECMP path, but
no PCN-traffic on the path
(3) PCN-domain extends towards end terminals, probe for every admission
decision

for what it's worth, my personal opinion is:
(1) & (2b) it isn't worth probing for (Lars's solution of "just
admitting" has equal or fewer drawbacks)
(3) is out of scope 
(2a) I'm undecided about

4. ECN support in a PCN domain
just raised by Magnus
http://www1.ietf.org/mail-archive/web/pcn/current/msg00923.html 

Issues that I think are closed 
===============================
no need to say anything if you agree they're closed, but shout now if
you want to discuss them!

5. Open issues in S6
S6 lists some open issues and says " NOTE: Potential solutions are out
of scope for this document." Is this ok?
Personally I think it's ok. If not it would probably be most problematic
for the topics where we know of no ideal solutions (ECMP, flash crowds &
maybe tunnelling)
NB Just to be clear: "Open issues" in S6 means: issues that need careful
consideration by the operator in their deployment situation, and
sometimes during subsequent PCN WG work eg the Milestone on
PCN-boundary-node behaviour. It doesn't mean: "issues that will be
solved in a later version of this architecture draft". 

6. Generic signalling model
archit draft says 'you could make decision at ingress, egress or
centralised node & this will involve signalling of (1) measurements from
metering node to decision node (2) decision from decision node to
node(s) doing admission, termination & policing of flows.'
It was deliberately left vague. Assumed that the later Milestones would
cover what the options were in detail, their reqts etc for boundary-node
behaviour & signalling protocols. 

7. Vagueness on marking behaviours, encoding schemes, edge measurements
Archit draft basically says these things will be decided by other
Milestone docs. Assume this is ok. 
Qus: when the decisions are made, should we revise the archit doc to
reflect this (eg it would simplify text in S4.1 & 4.2)? if decision
allows more than one option, presumably this would be under operator
control either at deployment time or through Config OAM - should the
archit doc be revised later eg to capture how to choose which option?
My view: we shouldn't hold up the archi doc for this.

8. Introduction
is this understandable? Should it offer a gentler intro, eg as an
evolutionary step on the ietf qos activities?
My view: it's ok [but then I've read it several 100s times!]

9. Charter scope
there's text in S3 Assumptions like "The PCN charter restricts the
initial scope...". Someone might say 'an RFC should be written
independently of what a charter says'
Personally I think it's ok, it reflects the situation at the time it's
written. Also I found it too hard to write without referring to the
Charter's scope.

10. Terminology
there is always something to discuss

11. Refs
There are mixed formats, rfcs aren't in order, etc
Help: Is there xml in XMLmindXML editor format with best practice?

_______________________________________________
PCN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pcn

---

From: Tom Taylor <[email-masked]>
Date: Thu, 22 Nov 2007 19:12:29 -0500

Looks like I'm too late to comment :) -- I've tried and failed to find a copy of 
arch-02 on the web. The PCN charter page link and Datatracker give me "document 
not found", and it isn't in ISI's archive. So far I haven't found it on Google 
either.

> Hi,
...

---

From: Tom Taylor <[email-masked]>
Date: Fri, 23 Nov 2007 02:40:39 -0500

I found the message in which you distributed the document. The OAM section looks 
great, though I may think of something later. I'll probably have some editorial 
suggestions for the earlier sections, but I'll send those privately.

Tom Taylor wrote:
> Looks like I'm too late to comment :) -- I've tried and failed to find a 
> copy of arch-02 on the web. The PCN charter page link and Datatracker 
> give me "document not found", and it isn't in ISI's archive. So far I 
> haven't found it on Google either.
>

---

From: Steven Blake <[email-masked]>
Date: Wed, 28 Nov 2007 13:47:23 -0500

Philip et. al., 

I think there are open issues surrounding Sec. 5.6,
namely:

- how an egress node associates a received packet with an 
  ingress-egress aggregate

- whether centralized nodes are in scope for the architecture

Regarding the former: I don't believe that it is the responsibility of
PCN to mandate a mechanism for making the packet->aggregate association,
nor is it our responsibility to define protocol mechanisms to facilitate
this (although I would appreciate input from the ADs).  It would be good
to discuss the issue in more detail in the document; e.g., list
alternatives, discuss trade-offs, etc.

Regarding the latter issue: I have a strong opinion.  I think this needs
more discussion by the working group.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven Blake                <[email-masked]>
Ericsson/Redback Networks               +1 919-472-9913

---

From: Michael Menth <[email-masked]>
Date: Wed, 28 Nov 2007 22:22:17 +0100

Hi Steven,

> alternatives, discuss trade-offs, etc.

I think the association of packet - ingress-egress-aggregate could 
depend on the scenario in which PCN is applied. MPLS tunnels might help 
or also per-flow classifiers at the PCN ingress and egress when some 
resource signalling protocol is used. We've called this "deployment 
models" in Section 2.2 of
http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-01.txt

Regards,

   Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn