Re: [PCN] lets try again - a chair asking this time

[<[e-mail]>]

Hi all,



I think that the changes satisfy nicely the comments of Adrian!



Best regards,

Georgios





________________________________
Van: [e-mail] [[e-mail]] namens [e-mail] [[e-mail]]
Verzonden: dinsdag 20 maart 2012 17:46
Aan: [e-mail]; [e-mail]
Onderwerp: Re: [PCN] lets try again - a chair asking this time

Seems good to me. I like the inclusion of material previously in both the edge behaviour docs

From: [e-mail] [mailto:[e-mail]] On Behalf Of Bradner, Scott
Sent: 20 March 2012 16:37
To: [e-mail]
Subject: [PCN] lets try again - a chair asking this time

please let the list know what you think

Scott

Scott O Bradner
Senior Technology Consultant

Begin forwarded message:



Date: Mon, 12 Mar 2012 03:30:11 +0000
To: "PCN IETF list" <[e-mail]<mailto:[e-mail]>>
From: Bob Briscoe <[e-mail]<mailto:[e-mail]>>
Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt

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: <[e-mail]<mailto:[e-mail]>>
To: <[e-mail]<mailto:[e-mail]>>,
        <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>,
        <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
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

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design