Subject: [PCN] New Version: draft-ietf-pcn-3-in-1-encoding-09.txt

From: Bob Briscoe <[email-masked]>
Date: Mon, 12 Mar 2012 03:30:11 +0000

PCN folks,

Following IESG review (particularly Adrian Farrel's being the most 
comprehensive and useful), we've posted a new version of the PCN 
3-in-1 encoding.

As well as a number of editorial changes, some technical changes were 
needed in order to satisfy Adrian's request to specify exactly what 
an implementer has to do at the ingress to allow ECN to co-exist with 
PCN, and what defaults should be set to.

In particular, for a non-PCN packet (i.e. doesn't match any 
flow-state) that clashes with a PCN DSCP and is ECN-capable, the 
recommended choice of 3 is:

       *  re-mark the DSCP to a DSCP that is not PCN-compatible;

        [...] 
In the
       absence of any operator-specific configuration for this case, by
       default an implementation SHOULD re-mark the DSCP to zero.

Actually, the whole of the ingress behaviour section (5.1) has been 
re-written, incorporating material that was previously repeated in 
both edge-behaviours (agreed with IESG and with edge-behaviour 
authors, of course). Altho it largely does the same thing 
technically, it is written to cover the complete range of possible 
scenarios, and it now gives defaults and recommended choices. I don't 
think it's controversial, but shout if it is.
<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1>

Bob

PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09:

       *  Added note about fail-safe to protect other traffic in the
          event of tunnel misconfiguration.

       *  Changed section heading to be about applicability of
          environments to the encoding, rather than the encoding to the
          environments.

       *  Completely re-wrote PCN-ingress Node Behaviour section.

       *  Changed PCN interior node to PCN-node where the term was
          intended to include all PCN-nodes.

       *  Clarified status of ECN/PCN co-existence appendix.  Removed
          inconsistent assertion in this appendix that an admission-
          control DSCP alone can indicate that arriving traffic is PCN-
          traffic.

       *  A few clarifying editorial amendments and updated refs.

>From: <[email-masked]>
>To: <[email-masked]>,
>         <[email-masked]>, 
> <[email-masked]>,
>         <[email-masked]>, <[email-masked]>
>Date: Sun, 11 Mar 2012 17:52:23 -0700
>Subject: New Version Notification - draft-ietf-pcn-3-in-1-encoding-09.txt
>
>New version (-09) has been submitted for 
>draft-ietf-pcn-3-in-1-encoding-09.txt.
>http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.txt
>
>
>Diff from previous version:
>http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcn-3-in-1-encoding-09
>
>IETF Secretariat.

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design