Subject: Re: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-03.txt

From: <[email-masked]>
Date: Thu, 7 May 2009 15:01:16 +0100

Some LC comments:

Non-NIT:
4.1  A PCN-interior-node MUST observe the rules for valid and invalid
   codepoint transitions as set out in the following table.  The precise
   rules governing which valid transition to use are set out in
   [I-D.ietf-pcn-marking-behaviour]

unfortunately it doesn't - thought we'd decided best to handle here?
anyway, all it would need would be something like:
NM -> PM if meter indicates to mark
EXP -> PM maybe allowed in exptal extension

NITS

Abstract:
Unmarked and marked - use the defined terms

Throughout:
think the rfc style guide has "Diffserv" & "IPsec"

4.1 - "It MUST set the not-PCN
   (00) codepoint on all other packets.
You mean: packets with the PCN-compatible codepoint

4.2 There are a number of factors that
   were considered before deciding to set 10 as the NM state.  

Insert: "(instead of 01)!

4.3 "traffic scheduling and conditioning" - would metering & marking be
better? Not sure scheduling is mentioned. conditioning is about (latest
edit) to be replaced by "dropping" ['conditioning' has a wider meaning
to diffserv experts]

5 "otehr"

6 except where => unless

8

pcn-compatible enabled - capitalisation is different from terminilogy

the architecture used to determine whether => how

pcn edge node => PCN-boundary-node

12 - table loos odd
marking behaviour title is changing to ""Metering and marking behaviour
of PCN-nodes"

Appendix
Say it's informative

A.2 
Title & text: Not marked => not-marked

phil

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ [email-masked]
{ Sent: 28 April 2009 17:48
{ To: [email-masked]
{ Subject: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-03.txt
{ 
{ The working group last call for
draft-ietf-pcn-baseline-encoding-03.txt
{ starts now, and will end in two weeks (Tuesday May 12).  Please send
{ comments to the list.
{ 
{ http://tools.ietf.org/html/draft-ietf-pcn-baseline-encoding
{ 
{ 
{ Regards,
{ 
{ // Steve
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn

---

From: Steven Blake <[email-masked]>
Date: Wed, 13 May 2009 19:19:56 +0000

On Tue, 2009-04-28 at 09:47 -0700, [email-masked] wrote:

> The working group last call for draft-ietf-pcn-baseline-encoding-03.txt
> starts now, and will end in two weeks (Tuesday May 12).  Please send
> comments to the list.
> 
> http://tools.ietf.org/html/draft-ietf-pcn-baseline-encoding

The WGLC for this draft was scheduled to close yesterday, but I only saw
comments from Philip Eardley.  If you have any comments on this draft,
please submit them this week.

Regards,

/////////////////////////////////////////////
Steven Blake       [email-masked]
Extreme Networks              +1 919-884-3211

---

From: <[email-masked]>
Date: Mon, 18 May 2009 16:22:10 +0100

All,

I'm trying to address various WGLC comments I've received from Gorry and
Phil to do with baseline encoding. One comment that Gorry had relates to
the choice of DSCP and whether these need to be standardised. I think
our discussions led to the conclusion that we would rather wait till we
see whether PCN is successful before we try and get a standards DSCP out
of IANA and meantime will have PCN as an optional behaviour that can be
turned on within a controlled domain. However this leads to a question
of inter-operability between different vendors (a requirement for
standards track protocols I believe). My suggestion is that we (PCN WG)
maintain a list of the DSCPs different vendors have designated as
PCN-compatible (just as we are going to maintain a list of the
experimental DSCPs for the experimental extensions).

We also need to address another concern - will we need to notify IANA
that we are proposing a new marking behaviour that can be applied to
certain "appropriate" DSCPs. Should we in fact as a WG define the set of
existing DSCPs that we believe can use PCN? This moves well outside my
area of expertise so I would welcome an answer from a DiffServ expert.
Currently I am proposing making the IANA considerations section read:

"This document makes no direct request to IANA. However this document
allows
 for a set of DiffServ Codepoints to be assigned different ECN semantics
within
 a controlled domain as described in RFC4774. A list of such
 DSCPs will be maintained by the PCN working group."

Would this be sufficient or do we need to be more precise? For instance
should we define that only those DSCPs for real-time traffic are
suitable, or those for admission controlled traffic, or what?

Toby

---

From: <[email-masked]>
Date: Tue, 19 May 2009 08:42:51 +0200

Toby,

to me your proposal to stay experimental is sound, but also the 
argument to have certain reserved DSCP values for PCN experiments 
is a good one. 

Maybe the chairs could provide some guidance on the best way to 
proceed? 

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, May 18, 2009 5:22 PM
To: [email-masked]
Subject: Re: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-03.txt

All,

Toby

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

---

From: Steven Blake <[email-masked]>
Date: Tue, 19 May 2009 08:27:34 -0400

> Maybe the chairs could provide some guidance on the best way to 

I expect that getting one or more Pool 1 (standards-action) DSCP values
assigned to PCN at this stage would be highly unlikely to happen.  So as
mentioned before, we can choose some Pool 2/3 (experimental/local use)
values for experimentation and announce them to the world.

There may be some value in recommending certain "appropriate" DSCPs for
use by flows/applications that can/should receive PCN treatment.  On the
other hand, we assume flow classification at the edges, so it might not
help that much.

Regards,

// Steve

---

From: <[email-masked]>
Date: Tue, 19 May 2009 15:55:02 +0100

I will post a revised document probably tomorrow morning. Hopefully it
will suitably address this point as well as the other WGLC points that
have been raised.

Toby

> From: Steven Blake [mailto:[email-masked]]
> Sent: 19 May 2009 13:28
> To: [email-masked]
> Cc: Moncaster,T,Toby,CXR9 R; [email-masked]

---

From: <[email-masked]>
Date: Thu, 28 May 2009 12:40:19 +0100

Exptal DSCP seems OK to me, due to practical issues of releasing stds
dscps. I assume it's correct for the i-d to be stds track (it makes
sense to me, as the draft is more than just a dscp)

Also, my understanding is that the dscp assigned in
draft-ietf-tsvwg-admitted-realtime-dscp is suitable for pcn (eg PCN
meets the requirements of S2.2 Capacity admission control). Not sure of
the progress of that doc though?

Best wishes
phil 

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ Steven Blake
{ Sent: 19 May 2009 13:28
{ To: [email-masked]
{ Cc: [email-masked]
{ Subject: Re: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-03.txt
{ 
{ On Tue, 2009-05-19 at 08:42 +0200, [email-masked] wrote:
{ 
{ > Toby,
{ >
{ > to me your proposal to stay experimental is sound, but also the
{ > argument to have certain reserved DSCP values for PCN experiments
{ > is a good one.
{ >
{ > Maybe the chairs could provide some guidance on the best way to
{ > proceed?
{ 
{ I expect that getting one or more Pool 1 (standards-action) DSCP
values
{ assigned to PCN at this stage would be highly unlikely to happen.  So
as
{ mentioned before, we can choose some Pool 2/3 (experimental/local use)
{ values for experimentation and announce them to the world.
{ 
{ There may be some value in recommending certain "appropriate" DSCPs
for
{ use by flows/applications that can/should receive PCN treatment.  On
the
{ other hand, we assume flow classification at the edges, so it might
not
{ help that much.
{ 
{ 
{ Regards,
{ 
{ // Steve
{ 
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn