Subject: [PCN] WGLC on draft-ietf-pcn-marking-behaviour-02

From: [email-masked] (Scott O. Bradner)
Date: Mon, 6 Apr 2009 08:45:47 -0400 (EDT)

this starts a WGLC on draft-ietf-pcn-marking-behaviour-02 - comments to
the list by April 20th please

Scott

---

From: <[email-masked]>
Date: Wed, 8 Apr 2009 11:11:27 +0100

Some LC comments. They're all clarifications, consistency etc
Thanks
phil

Title:
Change to "Metering and marking behaviour of PCN-nodes"
Reason: architecture i-d uses "marking" to refer only to "setting the
codepoint" (& not as shorthand for "metering & setting the codepoint")

Abstract:
Some tweaking needed for above point.

Intro:
Some tweaking needed for above point. (after the first half a page, the
doc mostly is already ok in the way it uses the term "marking")
Introduce the "common capsule" about PCN (first para of the architecture
doc)
Is the para about other PCN docs needed?

"traffic condition"
[made this comment already on ML] Instead of "traffic conditioning" a
better term to use would be "dropping". Because in the diffserv docs,
'conditioning' is used to refer collectively to metering /marking
/shaping /dropping.

"meter operates on the aggregate of all PCN-pkts" - or: "operates on
all"

S2.2
traffic conditioning -> dropping

S2.3 & 2.4
[Michael suggested this off list] the terminology "TBthreshold.fill" etc
is quite cumbersome. I think I'll re-phrase to follow what eg RFC2211
does:
T & E for the two token buckets [threshold & excess]
Tr, Tb, Tt [& explain what these are] [rate, bucket depth, threshold
level]
Er, Eb

S2.4: Delete " The PCN-excess-rate is greater than (or
   equal to) the PCN-threshold-rate."
Doesn't seem appropriate to have this as a MUST. It's already mentioned
in the informative appendix.

2.5
the last para ("Note:...") seems appropriate for the informative.
appendix rather than the normative main sections. The very last sentence
is however normative.
Result:
S2.5 has this para:
   A PCN-packet MUST be marked to reflect the metering results by
   setting its encoding state appropriately, as specified by the
   specific encoding scheme that applies in the PCN-domain. A consistent
choice MUST be made throughout a PCN-domain.

The appendix gains this para:
In some deployment scenarios there may be only two PCN encoding
   states available (PCN-marked and not-marked).  In such scenarios, the
   deployment chooses whether the Threshold meter function or the
   Excess traffic meter function triggers a packet to be PCN-marked;
   a consistent choice needs to be made throughout a PCN-domain.

S7 Authors, Acks:
Could be improved?

Refs:
The i-d "draft-ietf-pcn-blah" could be hidden in text [kept in xml]

B.4
"CL/SM edge behaviour" - guess these needs a little explanation /ref of
what CL & SM are?

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ Scott O. Bradner
{ Sent: 06 April 2009 13:46
{ To: [email-masked]
{ Subject: [PCN] WGLC on draft-ietf-pcn-marking-behaviour-02
{ 
{ 
{ this starts a WGLC on draft-ietf-pcn-marking-behaviour-02 - comments
to
{ the list by April 20th please
{ 
{ Scott
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn