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

[<[e-mail]>]

Hi Scott,

the passage you quote should result from a misconfiguration or an attack.

      Treatment of non-PCN-packets confused with a PCN-packet
      due to DSCP/ECN codepoinzt setting:
      ...
      In the absence of any operator-specific
      configuration for this case, by
      default an implementation SHOULD re-mark
      the DSCP to zero.
      ...
      Clearing the ECN field is not an appropriate
      policing action, because a network node ought not to interfere
      with an e2e signal.  Even if such packets seem like an attack,
      drop would be overkill, because such an attack can be neutralised
      by just re-marking the DSCP.  And DSCP re-marking in the network
      is legitimate, because the DSCP is not considered an e2e signal.

What's done here is remarking of a flow with a DSCP that has been
agreed between two parties. On a consumer UNI, this may be an attack,
on an NNI, this could indicate a misconfiguration. In the latter case,
a management alert seems reasonable. Text to that may be added.

I further quote the PCN architecture, which is informational, on the
Ingress Node behaviour:

      Police - police, by dropping any packets received with a DSCP
      indicating PCN transport that do not belong to an admitted flow.
      (A prospective PCN-flow that is rejected could be blocked or
      admitted into a lower-priority behaviour aggregate.)  Similarly,
      police packets that are part of a previously admitted flow, to
      check that the flow keeps to the agreed rate or flowspec (eg, see
      [RFC1633] for a microflow and its NSIS equivalent).

This isn't in line with the proposed 3-in-1 (standards track) behaviour.
Does this require an "Errata" atatement for RFC5559 (I'm not an expert on
editing RFCs and may be wrong here)?

Regards,

Ruediger

________________________________

From: [e-mail] [mailto:[e-mail]] On Behalf Of Bradner, Scott
Sent: Tuesday, March 20, 2012 5:37 PM
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]>
                From: Bob Briscoe <[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 <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]>
                        To: <[e-mail]>,
                                <[e-mail]>, <[e-mail]>,
                                <[e-mail]>, <[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