Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt

[Steven Blake <slblake at petri-meat.com>]

We want to advance this document quickly.  Please come to Minneapolis
with comments prepared.  Or better yet, send them to the list ASAP.


On Thu, 2008-10-02 at 15:29 +0100, philip.eardley at bt.com wrote:

> Hi,
> This is the update to the marking behaviour draft, which (I think)
> includes all the discussion we had on the list and in Dublin about the
> previous version (draft-eardley-pan-marking-behaviour-01)
> 
> Summary of changes:
> 
>    o  Removed material concerning per domain behaviour and PCN-boundary-
>       node operation (temporarily archived to Appendix C)
> it was agreed that this draft should be just about the 'per-hop'
> behaviour. 
> 
> We need a draft about the per-domain behaviour. This will be very short,
> eg saying that all nodes in the PCN-domain have to be configured to do
> the same type of marking, the same choice about encoding states, do
> policing at the ingress-node etc. ietf-pcn-baseline-encoding Appendix B
> also indicates some things that the PCN-boundary-nodes need to do.
> I (& Toby) don't have time to write this per-domain behaviour draft
> (hoping for volunteer(s)!)
> 
> There's also the Info edge behaviour draft or drafts. Some of the
> material in Appendix C might be useful for that.
> 
> 
>    o  Removed mention of downgrading as an option for per-hop traffic
>       conditioning.  In fact, downgrading is no longer allowed because S
>       2.6 now says "A PCN-node MUST NOT ...change a PCN-packet into a
>       non PCN-packet".
> 
>    o  Traffic conditioning is now a MAY.  Since in general flow
>       termination (not traffic conditioning) is PCN's method for
>       handling problems of too much traffic.
> I think I got the conclusion on this right, but would appreciate people
> checking. I think a MAY captures best our conclusion (rather than a
> SHOULD or not talking about it all)
> 
>    o  Metered-packets: competing-non-PCN-packets now MAY be metered.
>       Since it is recommended that the operator doesn't allow any
>       competing-non-PCN-traffic, and (if there is) there are potentially
>       other ways of coping.
> This was the discussion with Christian recently about Section 6.5 of the
> architecture draft. 
> In the previous draft, it was a MUST to meter these
> competing-non-PCN-packets. This seems onerous when we also recommend
> that there is no such traffic. 
> 
>    o  No changes (outside traffic conditioning & metering of competing-
>       non-PCN-traffic) to the Normative sections of the draft.
> 
>    o  Appendix B.1 added about competing-non-PCN-traffic.  Recommended
>       that there is no such traffic, but guidance given if there is.
> 
> 
> Sorry this has taken me longer than expected to get out.
> 
> I'll do another rev before Minneapolis. I believe (or at least hope!)
> that it'll then be ready for last call/
> 
> Best wishes
> phil
> 
> { -----Original Message-----
> { From: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf Of
> { Internet-Drafts at ietf.org
> { Sent: 02 October 2008 13:45
> { To: i-d-announce at ietf.org
> { Cc: pcn at ietf.org
> { Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt
> { 
> { A New Internet-Draft is available from the on-line Internet-Drafts
> { directories.
> { This draft is a work item of the Congestion and Pre-Congestion
> { Notification Working Group of the IETF.
> { 
> { 
> { 	Title           : Marking behaviour of PCN-nodes
> { 	Author(s)       : P. Eardley
> { 	Filename        : draft-ietf-pcn-marking-behaviour-00.txt
> { 	Pages           : 22
> { 	Date            : 2008-10-02
> { 
> { This document standardises the two marking behaviours of PCN-nodes:
> { threshold marking and excess traffic marking.  Threshold marking
> { marks all PCN-packets if the PCN traffic rate is greater than a first
> { configured rate.  Excess traffic marking marks a proportion of PCN-
> { packets, such that the amount marked equals the traffic rate in
> { excess of a second configured rate.Requirements Language
> { 
> { The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> { "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> { document are to be interpreted as described in RFC 2119 [RFC2119].
> { 
> { A URL for this Internet-Draft is:
> { http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-behaviour-
> { 00.txt
> { 
> { Internet-Drafts are also available by anonymous FTP at:
> { ftp://ftp.ietf.org/internet-drafts/
> { 
> { Below is the data which will enable a MIME compliant mail reader
> { implementation to automatically retrieve the ASCII version of the
> { Internet-Draft.
> _______________________________________________
> PCN mailing list
> PCN at ietf.org
> https://www.ietf.org/mailman/listinfo/pcn


Regards,

// Steve

_______________________________________________
PCN mailing list
PCN at ietf.org
https://www.ietf.org/mailman/listinfo/pcn