Subject: Re: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt

From: <[email-masked]>
Date: Fri, 5 Aug 2011 10:03:12 +0100

Here are some small comments - the doc looks very good and is ready for IESG i think

S1

<<   The baseline encoding defined in [RFC5696<http://tools.ietf.org/html/rfc5696>] described how two PCN>>

Delete 'baseline' - just confusing for people in the future

<<   This document extends the baseline encoding by redefining the EXP>>

   This document amends the [RFC5696] encoding by redefining the 01

(and a couple of lines earlier where you mention EXP, add that this is 01 codepoint)

S2.1

<<   Threshold-marked codepoint:  a codepoint that indicates packets that

      have been marked at a PCN-interior-node as a result of an

      indication from the threshold-metering function [RFC5670<http://tools.ietf.org/html/rfc5670>].

      Abbreviated to ThM.>>

I wonder if this would be clearer as

   Threshold-marked codepoint:  a codepoint that indicates a packet has been threshold-marked, that is a packet that

      has been marked at a PCN-interior-node as a result of an

      indication from the threshold-metering function [RFC5670<http://tools.ietf.org/html/rfc5670>].

      Abbreviated to ThM.

[firstly clearer to refer to 'packet' than 'packets', secondly uses the term 'threshold-marked' which was defined in 5559]

Similarly for excess-traffic-marked codepoint

<<   Not-marked codepoint:  a codepoint that indicates PCN-packets but

      that are not PCN-marked.  Abbreviated to NM.>>

delete 'but'

S3

<< A PCN-node (i.e. a node within a PCN-domain) will be configured to

   recognise certain DSCPs as PCN-compatible.  Appendix A<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#appendix-A> discusses the

   choice of suitable DSCPs.  In Figure 1 'DSCP n' indicates such a PCN-

   compatible DSCP.  Within the PCN-domain, any packet carrying a PCN-

   compatible DSCP is a PCN-packet as defined in [RFC5559<http://tools.ietf.org/html/rfc5559>].>>

A PCN-node (i.e. a node within a PCN-domain) will be configured to

   recognise certain DSCP(s) as PCN-compatible.  Appendix A<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#appendix-A> discusses the

   choice of suitable DSCP(s).  In Figure 1 'DSCP n' indicates such a PCN-

   compatible DSCP.  Within the PCN-domain, any packet carrying a PCN-

   compatible DSCP and with the ECN-field anything other than 00 (Not-PCN) is a PCN-packet as defined in [RFC5559<http://tools.ietf.org/html/rfc5559>].

[DSCPs => DSCP(s). And added phrase in last sentence]

4.2

Delete "the baseline encoding "

With => that has [a Not-marked codepoint...]

4.3

<< For the full 3-in-1 encoding to apply, any tunnel endpoints (IP-in-IP

   and IPsec) within the PCN-domain MUST comply with the ECN

   encapsulation and decapsulation rules set out in [RFC6040<http://tools.ietf.org/html/rfc6040>] (see

   Section 4.2<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#section-4.2>).  There is one exception to this rule outlined next.

With one exception (see next paragraph), any tunnel endpoints (IP-in-IP

   and IPsec) within the PCN-domain MUST comply with the ECN

   encapsulation and decapsulation rules set out in [RFC6040<http://tools.ietf.org/html/rfc6040>] (see

   Section 4.2<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#section-4.2>).

S5

<< As mentioned in Section 4.3<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#section-4.3> above, all PCN-nodes MUST comply with

   [RFC6040<http://tools.ietf.org/html/rfc6040>].>>

All PCN-nodes MUST comply with [RFC6040<http://tools.ietf.org/html/rfc6040>]. Since PCN is a new capability, this is considered a reasonable requirement.

[note that it isn't mentioned in Section 4.3<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#section-4.3> !]

S5.2.3

<< Observant readers may spot an apparent inconsistency

   between the two following cases.  Appendix D<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#appendix-D> explains the rationale

   behind this inconsistency.

Appendix D<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#appendix-D> explains the rationale for the behaviours defined in this section.

[i see no reason to worry the average reader with talk of inconsistency.]

S5.3

<<   marking is used it should treat ETM as ThM.  However it SHOULD raise>>

   marking is used it SHOULD treat ETM as ThM.  However it SHOULD raise

s6.1

<< PCN-ingress-

   nodes ensure that any packets entering the PCN-domain have the ECN

   field in their outermost IP header set to the appropriate PCN

   codepoint.  >>

CHANGE TO "appropriate codepoint" (as it may be appropriate to set it to 00, which isn't a PCN codepoint)

6.2

Thre => there

10

Criticism is misspelt

Appendix A

The para "PCN-marking is intended...

It wasn't clear to me whether PCN is operating on the whole aggregate of classes together, or on each class separately. Or whether either is possible.

App B

<< a.  flow signalling associates

a.  flow signalling, which associates

<< Interactive Real-Time,

       Broadcast TV >>

These have slightly different names in App A

<< Figure 2: Separation of tunneling and PCN actions

=> tunnelling

   a) Does not require admission control:

   b) Requires Admission-control:

i think it would be helpful to add "The e2e ECN traffic is not treated as PCN-traffic" and "The e2e ECN traffic is treated as PCN-traffic"

<<

     *  The PCN-ingress places this traffic in a tunnel with a PCN-

         compatible DSCP in the outer header.  The PCN-egress zeroes the

         ECN-field before decapsulation.

      *  The PCN-ingress drops CE-marked packets and the PCN-egress

         zeros the ECN field of all PCN packets.

This can't be quite right, something like

     *  The PCN-ingress places this traffic in a tunnel with, in the outer header, a PCN-

         compatible DSCP and the ECN-field set to Not-PCN.  The PCN-egress zeroes the

         (outer) ECN-field before decapsulation.

      *  The PCN-ingress drops CE-marked packets and otherwise sets the ECN-field to NM, and sets the DCSP to a PCN-         compatible DSCP [or requires that it's already in such a DSCP??]. The PCN-egress zeroes the ECN field of all PCN packets; note this turns off e2e ECN.

[note, 'zeroes']

[i'm not sure about the last bullet, is this what you mean>?]

You could also correct PCN-ingress to PCN-ingress-node throughout the section; ditto PCN-egress.

<<Note that a PCN interior node may turn

      ECT(0) into ECT(1), which would not be compatible with the

      (currently experimental) ECN nonce [RFC3540<http://tools.ietf.org/html/rfc3540>].>>

Well a PCN-interior-node doesn't know about ECT. Change to:

Note that a PCN-interior-node may change the ECN-field from 10 to 01 (NM to ThM), which would be interpreted by the e2e ECN as a change from ECT(0) into ECT(1) -- hence it would not be compatible with the (currently experimental) ECN nonce [RFC3540<http://tools.ietf.org/html/rfc3540>].

App C

<<But [RFC5129<http://tools.ietf.org/html/rfc5129>] was written while

   PCN specifications were in early draft stages>>

The 'But' makes it sound like you're updating 5129 (i don't think you are, if i remember right)

ECT(0) -> NM

Etc (all 6 bullets need to be changed)

After the last bullet you could add

"The above sets of codepoints are required for every PCN-compatible DSCP."

App D

In title & , Discrepancy -> Difference

Apparent discrepancy -> slight difference

(to me, discrepancy implies something is wrong)

<<The behaviour with only threshold marking keeps to the rule that

      ETM is more severe and must never be changed to ThM even though

      ETM is not a valid marking in this case.  >>

The behaviour with only threshold marking keeps to the rule of Section 5.2.1 that

      ETM is more severe and must never be changed to ThM (even though

      ETM is not a valid marking in this case).

First bullet

Your argument also means that a ThM should be corrected to ETM (since the excess-traffic-metering behaviour depends on ETM marks on arriving packets). At the moment it only gets corrected when the meter wants to ETM mark the pkt.

But making this correction would require different code compared with the standard behaviour.

Personally i'd just delete the first bullet. If not, make it the second one (as it's harder to understand)

Best wishes
phil

Philip Eardley
Research and Technology Strategy

This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott O Bradner
Sent: 31 July 2011 18:38
To: Toby Moncaster
Cc: [email-masked]
Subject: Re: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt

sigh - tooooo long a IETF meeting  :-)

Scott

On Jul 31, 2011, at 6:09 AM, Toby Moncaster wrote:

I'm guessing you mean comments by August 15? (otherwise this will be a ~350
day LC!)

Toby

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
Scott O. Bradner
Sent: 30 July 2011 20:40
To: [email-masked]<mailto:[email-masked]>
Subject: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt

this starts a WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt

comments by July 15 please

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

Scott Bradner

Harvard University Information Technology
Security | Policy, Risk & Compliance
+1 617 495 3864
29 Oxford St., Room 407
Cambridge, MA 02138
www.harvard.edu/huit<http://www.harvard.edu/huit>

---

From: Michael Menth <[email-masked]>
Date: Sun, 07 Aug 2011 16:20:05 +0200

Hi all,

I have mostly editorial comments highlighted in the attached Word file.

Regards,

     Michael

Am 30.07.2011 21:39, schrieb Scott O. Bradner:
> [email-masked]

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 18 Aug 2011 10:34:51 +0100

Michael,

I like nearly all your editorial changes.

In a couple of cases, they have made me notice an even better way of 
saying it. But in the first two cases, I prefer the original to your 
suggestion. I have said why in my annotation of your annotations here 
(mine are in red in the PDF)
<http://bobbriscoe.net/projects/ipe2eqos/pcn/marking/draft-ietf-pcn-3-in-1-encoding-07-MM-BB.doc>
<http://bobbriscoe.net/projects/ipe2eqos/pcn/marking/draft-ietf-pcn-3-in-1-encoding-07-MM-BB.pdf>

Bob

>>comments by July 15 please

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Michael Menth <[email-masked]>
Date: Thu, 18 Aug 2011 11:55:08 +0200

Hi Bob,

the changes are fine with me.

Best wishes,

     Michael

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://www-kn.informatik.uni-tuebingen.de

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 18 Aug 2011 11:08:08 +0100

Phil,

Agree with everything. A few reponses inline....

At 10:03 05/08/2011, [email-masked] wrote:
>Content-Language: en-US
>Content-Type: multipart/alternative;
> 
>boundary="_000_9510D26531EF184D9017DF24659BB87F32E4B38A1DEMV65UKRDdoma_"
>
>Here are some small comments – the doc looks 
>very good and is ready for IESG i think
>
>S1
>
><<   The baseline encoding defined in 
>[<http://tools.ietf.org/html/rfc5696>RFC5696] described how two PCN>>
>
>Delete ‘baseline’ – just confusing for people in the future
>
>       indication from the threshold-metering 
> function [<http://tools.ietf.org/html/rfc5670>RFC5670].
>       Abbreviated to ThM.>>
>
>    Threshold-marked codepoint:  a codepoint 
> that indicates a packet has been threshold-marked, that is a packet that
>       indication from the threshold-metering 
> function [<http://tools.ietf.org/html/rfc5670>RFC5670].
>       Abbreviated to ThM.
>
>[firstly clearer to refer to ‘packet’ than 
>‘packets’, secondly uses the term ‘threshold-marked’ which was defined in 5559]
>
>delete ‘but’
>    recognise certain DSCPs as 
> PCN-compatible. 
> <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#appendix-A>Appendix 
> A discusses the
>    compatible DSCP is a PCN-packet as defined 
> in [<http://tools.ietf.org/html/rfc5559>RFC5559].>>
>
>    recognise certain DSCP(s) as 
> PCN-compatible. 
> <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#appendix-A>Appendix 
> A discusses the
>    compatible DSCP and with the ECN-field 
> anything other than 00 (Not-PCN) is a 
> PCN-packet as defined in [<http://tools.ietf.org/html/rfc5559>RFC5559].
>
>Delete “the baseline encoding “
>
>    encapsulation and decapsulation rules set 
> out in [<http://tools.ietf.org/html/rfc6040>RFC6040] (see
> 
><http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#section-4.2>Section 
>4.2).  There is one exception to this rule outlined next.
>
> >>
>
>    encapsulation and decapsulation rules set 
> out in [<http://tools.ietf.org/html/rfc6040>RFC6040] (see
> 
><http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#section-4.2>Section 
>4.2).
>
>S5
>
><< As mentioned in 
><http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#section-4.3>Section 
>4.3 above, all PCN-nodes MUST comply with
>    [<http://tools.ietf.org/html/rfc6040>RFC6040].>>
>
>All PCN-nodes MUST comply with 
>[<http://tools.ietf.org/html/rfc6040>RFC6040]. 
>Since PCN is a new capability, this is considered a reasonable requirement.
>[note that it isn’t mentioned in 
><http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#section-4.3>Section 
>4.3 !]
>
>S5.2.3
>
>    between the two following 
> cases. 
> <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#appendix-D>Appendix 
> D explains the rationale
><http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#appendix-D>Appendix 
>D explains the rationale for the behaviours defined in this section.
>
>CHANGE TO “appropriate codepoint” (as it may be 
>appropriate to set it to 00, which isn’t a PCN codepoint)
>
>6.2
>
>Thre => there
>
>10
>
>Criticism is misspelt
>
>Appendix A
>
>The para “PCN-marking is intended...
>
>It wasn’t clear to me whether PCN is operating 
>on the whole aggregate of classes together, or 
>on each class separately. Or whether either is possible.

[BB] That depends totally on whether the classes 
are all treated with the same scheduling 
behaviour. If they're all in different queues, 
PCN cannot be applied to the aggregate. If 
they're all in the same queue, PCN cannot be applied to each class separately.

>i think it would be helpful to add “The e2e ECN 
>traffic is not treated as PCN-traffic” and “The 
>e2e ECN traffic is treated as PCN-traffic”

[BB] Unclear what you are asking for.

>This can’t be quite right, something like
>
>      *  The PCN-ingress places this traffic in 
> a tunnel with, in the outer header, a 
> PCN-compatible DSCP and the ECN-field set to 
> Not-PCN.  The PCN-egress zeroes the (outer) ECN-field before decapsulation.

[BB] Surely not. The intention is to preserve the 
ECN field in the inner, and use PCN in the outer 
over the PCN domain. Your proposal would prevent PCN being used.

>       *  The PCN-ingress drops CE-marked 
> packets and otherwise sets the ECN-field to NM, 
> and sets the DCSP to a PCN-compatible DSCP [or 
> requires that it’s already in such a DSCP??]. 
> The PCN-egress zeroes the ECN field of all PCN 
> packets; note this turns off e2e ECN.
>
>[note, ‘zeroes’]
>
>[i’m not sure about the last bullet, is this what you mean>?]

[BB] Yes

>You could also correct PCN-ingress to 
>PCN-ingress-node throughout the section; ditto PCN-egress.
>
>       (currently experimental) ECN nonce 
> [<http://tools.ietf.org/html/rfc3540>RFC3540].>>
>
>Well a PCN-interior-node doesn’t know about ECT. Change to:
>
>Note that a PCN-interior-node may change the 
>ECN-field from 10 to 01 (NM to ThM), which would 
>be interpreted by the e2e ECN as a change from 
>ECT(0) into ECT(1) –- hence it would not be 
>compatible with the (currently experimental) ECN 
>nonce [<http://tools.ietf.org/html/rfc3540>RFC3540].
>App C
>
><<But [<http://tools.ietf.org/html/rfc5129>RFC5129] was written while
>The ‘But’ makes it sound like you’re updating 
>5129 (i don’t think you are, if i remember right)

[BB] OK. Delete 'But'.

>“The above sets of codepoints are required for every PCN-compatible DSCP.”

[BB] Yup.

>(to me, discrepancy implies something is wrong)

[BB] OK, but no need to say 'slight', given it's a complete reversal.

>Your argument also means that a ThM should be 
>corrected to ETM (since the 
>excess-traffic-metering behaviour depends on ETM 
>marks on arriving packets). At the moment it 
>only gets corrected when the meter wants to ETM mark the pkt.
>
>But making this correction would require 
>different code compared with the standard behaviour.
>
>Personally i’d just delete the first bullet. If 
>not, make it the second one (as it’s harder to understand)

[BB] You're right. I agree we should just remove the first bullet.
And I suggest we add your sentence about 
requiring different code at the end of the remaining bullet.

Thanks

Bob

>This email contains BT information, which may be 
>privileged or confidential. It's meant only for 
>the individual(s) or entity named above. If 
>you're not the intended recipient, note that 
>disclosing, copying, distributing or using this 
>information is prohibited. If you've received 
>this email in error, please let me know 
>immediately on the email address above. Thank 
>you. We monitor our email system, and may record your emails.
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Scott O Bradner
>Sent: 31 July 2011 18:38
>To: Toby Moncaster
>Cc: [email-masked]
>From: 
><mailto:[email-masked]>[email-masked] 
>  [mailto:[email-masked]] On Behalf Of
>
>Scott O. Bradner
>
>Sent: 30 July 2011 20:40
>
>To: <mailto:[email-masked]>[email-masked]
>
><mailto:[email-masked]>[email-masked]
>
><http://www.harvard.edu/huit>www.harvard.edu/huit
>
>
>
>

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 18 Aug 2011 11:17:04 +0100

Scott,

Now WGLC is over, we've had two useful reviews from Michael (a 
co-author) and Phil with a reasonably large number of editorial changes.

Assuming the outstanding conversations converge, I don't think there 
are any disagreements on the technical effect, or on anything normative.

I think there's enough editorial changes to warrant a rev before 
sending to the IESG. However, if you would rather it goes straight to 
the IESG, I wouldn't fight. if I recall correctly none of the 
requested changes imply the existing text is completely incomprehensible.

Your call...

Bob

At 23:38 31/07/2011, Scott O Bradner wrote:
>>>From: <mailto:[email-masked]>[email-masked]

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 18 Aug 2011 11:24:50 +0100

Bob,

Is there any chance you will be able to take over the pen for a final round
of tweaks now the WGLC is over? I'm going to be fairly busy over the next
few weeks.

Toby

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob
Briscoe
Sent: 18 August 2011 11:08
To: [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt

Phil,

Content-Language: en-US

Here are some small comments - the doc looks very good and is ready for IESG
i think
 
S1

<<   The baseline encoding defined in
[RFC5696 <http://tools.ietf.org/html/rfc5696> ] described how
two PCN>>

Delete 'baseline' - just confusing for people in the
future

<<   This document extends the baseline encoding by
redefining the EXP>>

   This document amends the [RFC5696] encoding by
redefining the 01

(and a couple of lines earlier where you mention EXP, add that this
is 01 codepoint)

S2.1

<<   Threshold-marked codepoint:  a codepoint
that indicates packets that

      have been marked at a
PCN-interior-node as a result of an

      indication from the
threshold-metering function
[RFC5670 <http://tools.ietf.org/html/rfc5670> ].

      Abbreviated to
ThM.>>

   Threshold-marked codepoint:  a codepoint that
indicates a packet has been threshold-marked, that is a packet
that

      has been marked at a
PCN-interior-node as a result of an

      indication from the
threshold-metering function
[RFC5670 <http://tools.ietf.org/html/rfc5670> ].

      Abbreviated to ThM.

[firstly clearer to refer to 'packet' than 'packets', secondly uses
the term 'threshold-marked' which was defined in 5559]

<<   Not-marked codepoint:  a codepoint that
indicates PCN-packets but

      that are not PCN-marked. 
Abbreviated to NM.>>

delete 'but'

S3

<< A PCN-node (i.e. a node within a PCN-domain) will be
configured to

   recognise certain DSCPs as PCN-compatible. 
 <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#appendix-A> 
Appendix A
<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#appendix-A>
discusses the

   choice of suitable DSCPs.  In Figure 1 'DSCP n'
indicates such a PCN-

   compatible DSCP.  Within the PCN-domain, any
packet carrying a PCN-

   compatible DSCP is a PCN-packet as defined in
[RFC5559 <http://tools.ietf.org/html/rfc5559> ].>>

A PCN-node (i.e. a node within a PCN-domain) will be configured
to

   recognise certain DSCP(s) as PCN-compatible. 
 <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#appendix-A> 
Appendix A
<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#appendix-A>
discusses the

   choice of suitable DSCP(s).  In Figure 1 'DSCP n'
indicates such a PCN-

   compatible DSCP.  Within the PCN-domain, any
packet carrying a PCN-

   compatible DSCP and with the ECN-field anything other
than 00 (Not-PCN) is a PCN-packet as defined in
[RFC5559 <http://tools.ietf.org/html/rfc5559> ].

 
4.2

4.3

<< For the full 3-in-1 encoding to apply, any tunnel endpoints
(IP-in-IP

   and IPsec) within the PCN-domain MUST comply with the
ECN

   encapsulation and decapsulation rules set out in
[RFC6040 <http://tools.ietf.org/html/rfc6040> ]
(see

 <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#section-4.2> 
Section 4.2
<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#section-4.2>
).  There is one exception to this rule outlined
next.

With one exception (see next paragraph), any tunnel endpoints
(IP-in-IP

   and IPsec) within the PCN-domain MUST comply with the
ECN

   encapsulation and decapsulation rules set out in
[RFC6040 <http://tools.ietf.org/html/rfc6040> ]
(see

 <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#section-4.2> 
Section 4.2
<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#section-4.2>
).  

S5

<< As mentioned in
 <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#section-4.3> 
Section 4.3
<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#section-4.3>
above, all PCN-nodes MUST comply with

[RFC6040 <http://tools.ietf.org/html/rfc6040> ].>>

All PCN-nodes MUST comply with
[RFC6040 <http://tools.ietf.org/html/rfc6040> ]. Since PCN is
a new capability, this is considered a reasonable requirement.

[note that it isn't mentioned in
 <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#section-4.3> 
Section 4.3
<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#section-4.3>
!]

S5.2.3

<< Observant readers may spot an apparent
inconsistency

   between the two following cases. 
 <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#appendix-D> 
Appendix D
<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#appendix-D>
explains the rationale

 
 <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#appendix-D> 
Appendix D
<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#appendix-D>
explains the rationale for the behaviours defined in this
section.

[i see no reason to worry the average reader with talk of
inconsistency.]

S5.3

<<   marking is used it should treat ETM as
ThM.  However it SHOULD raise>>

   marking is used it SHOULD treat ETM as ThM. 
However it SHOULD raise

s6.1

<< PCN-ingress-

   nodes ensure that any packets entering the PCN-domain
have the ECN

   field in their outermost IP header set to the
appropriate PCN

   codepoint. 

CHANGE TO "appropriate codepoint" (as it may be appropriate to set
it to 00, which isn't a PCN codepoint)

6.2

Thre => there

10

Criticism is misspelt 

Appendix A

It wasn't clear to me whether PCN is operating on the whole
aggregate of classes together, or on each class separately. Or whether
either is possible.

[BB] That depends totally on whether the classes are all treated with the
same scheduling behaviour. If they're all in different queues, PCN cannot be
applied to the aggregate. If they're all in the same queue, PCN cannot be
applied to each class separately.

App B

 

       Broadcast TV

 

<< Figure 2: Separation of tunneling and PCN
actions

=> tunnelling

i think it would be helpful to add "The e2e ECN traffic is not
treated as PCN-traffic" and "The e2e ECN traffic is treated as
PCN-traffic"

 

<< 

     *  The PCN-ingress places this traffic
in a tunnel with a PCN-

         compatible DSCP in
the outer header.  The PCN-egress zeroes the

         ECN-field before
decapsulation.

      *  The PCN-ingress drops
CE-marked packets and the PCN-egress

         zeros the ECN field
of all PCN packets.

     *  The PCN-ingress places this traffic
in a tunnel with, in the outer header, a PCN-compatible DSCP and the
ECN-field set to Not-PCN.  The PCN-egress zeroes the
(outer) ECN-field before decapsulation.

[BB] Surely not. The intention is to preserve the ECN field in the inner,
and use PCN in the outer over the PCN domain. Your proposal would prevent
PCN being used.

      *  The PCN-ingress drops CE-marked
packets and otherwise sets the ECN-field to NM, and sets the DCSP to a
PCN-compatible DSCP [or requires that it's already in such a DSCP??]. The
PCN-egress zeroes the ECN field of all PCN packets; note this turns off
e2e ECN.

[note, 'zeroes']

[BB] Yes

You could also correct
PCN-ingress to PCN-ingress-node throughout the section; ditto
PCN-egress.

      ECT(0) into ECT(1), which would not
be compatible with the

      (currently experimental) ECN nonce
[RFC3540 <http://tools.ietf.org/html/rfc3540> ].>>

Note that a PCN-interior-node may change the ECN-field from 10 to 01
(NM to ThM), which would be interpreted by the e2e ECN as a change from
ECT(0) into ECT(1) -- hence it would not be compatible with the
(currently experimental) ECN nonce
[RFC3540 <http://tools.ietf.org/html/rfc3540> ].

App C

<<But
[RFC5129 <http://tools.ietf.org/html/rfc5129> ] was written
while

   PCN specifications were in early draft
stages>>

The 'But' makes it sound like you're updating 5129 (i don't think
you are, if i remember right)

[BB] OK. Delete 'But'.

ECT(0) ->
NM

"The above sets of codepoints are required for every PCN-compatible
DSCP."

[BB] Yup.

App D

<<The behaviour with
only threshold marking keeps to the rule that

      ETM is more severe and must never be
changed to ThM even though

      ETM is not a valid marking in this
case.  >>

The behaviour with only threshold marking keeps to the rule of
Section 5.2.1 that

      ETM is more severe and must never be
changed to ThM (even though

      ETM is not a valid marking in this
case).  

First bullet

Your argument also means that a ThM should be corrected to ETM
(since the excess-traffic-metering behaviour depends on ETM marks on
arriving packets). At the moment it only gets corrected when the meter
wants to ETM mark the pkt. 

But making this correction would require different code compared
with the standard behaviour.

Personally i'd just delete the first bullet. If not, make it the
second one (as it's harder to understand)

[BB] You're right. I agree we should just remove the first bullet.
And I suggest we add your sentence about requiring different code at the end
of the remaining bullet.

Thanks

Bob

 

Best wishes
phil
 Philip Eardley   

This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not
the intended recipient, note that disclosing, copying, distributing or using
this information is prohibited. If you've received this email in error,
please let me know immediately on the email address above. Thank you. We
monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000
 
From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Scott O Bradner
Sent: 31 July 2011 18:38
To: Toby Moncaster
Cc: [email-masked]
Subject: Re: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt

Scott

Toby

-----Original Message-----

From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of

Scott O. Bradner

Sent: 30 July 2011 20:40

To: [email-masked]

 

Scott

PCN mailing list

[email-masked]

 
Scott Bradner
 
www.harvard.edu/huit

---

From: <[email-masked]>
Date: Thu, 18 Aug 2011 11:27:43 +0100

PCN-traffic"

[phil] i meant:

<< There are three cases for how e2e ECN traffic may wish to be treated
   while crossing a PCN domain:

   a) Does not require admission control:

A summary of the approach here is (i think)  "The e2e ECN traffic is not
treated as PCN-traffic"

similarly, for b) Requires Admission-control

summary is "The e2e ECN traffic is treated as

PCN-traffic"

<<

     *  The PCN-ingress places this traffic in a tunnel with a PCN-compatible DSCP in the outer header.  The PCN-egress zeroes the ECN-field before decapsulation.

      *  The PCN-ingress drops CE-marked packets and the PCN-egress zeros the ECN field of all PCN packets.

     *  The PCN-ingress places this traffic in a tunnel with, in the outer header, a PCN-compatible DSCP and the

ECN-field set to Not-PCN.  The PCN-egress zeroes the (outer) ECN-field before decapsulation.

[BB] Surely not. The intention is to preserve the ECN field in the inner, and use PCN in the outer over the PCN domain. Your proposal would prevent PCN being used.

[phil] ok, PCN is applied the e2e ECN traffic (I can't remember why i said set to Not-PCN).

Best wishes
phil
 Philip Eardley

From: [email-masked] [ mailto:[email-masked]] On Behalf Of Scott O Bradner
Sent: 31 July 2011 18:38
To: Toby Moncaster
Cc: [email-masked]
Subject: Re: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt

Scott

Toby

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [ mailto:[email-masked]] On Behalf Of
Scott O. Bradner
Sent: 30 July 2011 20:40
To: [email-masked]<mailto:[email-masked]>
Subject: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt

Scott

Scott Bradner

---

From: Scott Bradner <[email-masked]>
Date: Thu, 18 Aug 2011 08:40:50 -0400

please update the ID first

tnx

Scott

On Aug 18, 2011, at 6:17 AM, Bob Briscoe wrote:

> Scott,
> 
> Now WGLC is over, we've had two useful reviews from Michael (a co-author) and Phil with a reasonably large number of editorial changes.
> 
> Assuming the outstanding conversations converge, I don't think there are any disagreements on the technical effect, or on anything normative.
> 
> I think there's enough editorial changes to warrant a rev before sending to the IESG. However, if you would rather it goes straight to the IESG, I wouldn't fight. if I recall correctly none of the requested changes imply the existing text is completely incomprehensible.
> 
> Your call...
> 
> 
> Bob
> 
>>>> From: [email-masked] [ mailto:[email-masked]] On Behalf Of
>>>> Scott O. Bradner
>>>> Sent: 30 July 2011 20:40
>>>> To: [email-masked]

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 18 Aug 2011 15:14:33 +0100

Scott,

OK

Bob

At 13:40 18/08/2011, Scott Bradner wrote:
>>Assuming the outstanding conversations converge, I don't think 
>>there are any disagreements on the technical effect, or on anything normative.
>>
>>sending to the IESG. However, if you would rather it goes straight 
>>to the IESG, I wouldn't fight. if I recall correctly none of the 
>>>>>From: <mailto:[email-masked]>[email-masked] [ 
>>>>>mailto:[email-masked]] On Behalf Of
>>>>>Scott O. Bradner
>>>>>Sent: 30 July 2011 20:40

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 18 Aug 2011 15:19:47 +0100

Toby,

I was just going to offer, when I saw your email.
As I have all the edits in foreground memory at the mo, I'll do it now.

If you have any pent up edits since -07, pls send 
the xml. Otherwise I'm going to start from the 
-07.xml, assuming I can find it on your site (or otherwise the data tracker).

Bob

At 11:24 18/08/2011, Toby Moncaster wrote:
>Bob,
>
>Is there any chance you will be able to take 
>over the pen for a final round of tweaks now the 
>WGLC is over? I’m going to be fairly busy over the next few weeks.
>
>Toby
>
>[mailto:[email-masked]] On Behalf Of Bob Briscoe
>[<http://tools.ietf.org/html/rfc5696>RFC5696] described how
>
>two PCN>>
>
>
>Delete ‘baseline’ – just confusing for people in the
>
>future
>
>
>[<http://tools.ietf.org/html/rfc5670>RFC5670].
>
>
>       Abbreviated to
>
>ThM.>>
>
>
>[<http://tools.ietf.org/html/rfc5670>RFC5670].
>
>
>       Abbreviated to ThM.
>
>
>[firstly clearer to refer to ‘packet’ than ‘packets’, secondly uses
>
>the term ‘threshold-marked’ which was defined in 5559]
>
>
>[<http://tools.ietf.org/html/rfc5559>RFC5559].>>
>
>
>[<http://tools.ietf.org/html/rfc5559>RFC5559].
>
>
>[<http://tools.ietf.org/html/rfc6040>RFC6040]
>
>(see
>
>
>
>
>
>
>4.2).  There is one exception to this rule outlined
>
>next.
>
>
> >>
>
>
>[<http://tools.ietf.org/html/rfc6040>RFC6040]
>
>(see
>
>
>
>
>
>
>[<http://tools.ietf.org/html/rfc6040>RFC6040]. Since PCN is
>
>D explains the rationale for the behaviours defined in this
>
>section.
>
>
>CHANGE TO “appropriate codepoint” (as it may be appropriate to set
>
>it to 00, which isn’t a PCN codepoint)
>
>
>6.2
>
>
>Thre => there
>
>
>10
>
>
>Criticism is misspelt
>
>
>Appendix A
>
>
>It wasn’t clear to me whether PCN is operating on the whole
>
>i think it would be helpful to add “The e2e ECN traffic is not
>
>treated as PCN-traffic” and “The e2e ECN traffic is treated as
>
>PCN-traffic”
>
>[BB] Surely not. The intention is to preserve 
>the ECN field in the inner, and use PCN in the 
>outer over the PCN domain. Your proposal would prevent PCN being used.
>
>
>
>
>
>
>PCN-compatible DSCP [or requires that it’s already in such a DSCP??]. The
>
>ECT(0) into ECT(1) –- hence it would not be compatible with the
>
>[<http://tools.ietf.org/html/rfc3540>RFC3540].
>
>
>App C
>
>
><<But
>
>[<http://tools.ietf.org/html/rfc5129>RFC5129] was written
>
>while
>
>
>The ‘But’ makes it sound like you’re updating 5129 (i don’t think
>
>“The above sets of codepoints are required for every PCN-compatible
>
>DSCP.”
>
>[BB] Yup.
>
>
>
>
>
>
>App D
>
>
>Personally i’d just delete the first bullet. If not, make it the
>
>second one (as it’s harder to understand)
>
>From: [email-masked] [ 
>mailto:[email-masked]] On Behalf Of Scott O Bradner
>Sent: 31 July 2011 18:38
>To: Toby Moncaster
>Cc: [email-masked]
>  [ mailto:[email-masked]] On Behalf Of
>Scott O. Bradner
>Sent: 30 July 2011 20:40
><https://www.ietf.org/mailman/listinfo/pcn>https://www.ietf.org/mailman/listinfo/pcn
>

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 18 Aug 2011 15:20:21 +0100

Michael,

Tx

Bob

At 10:55 18/08/2011, Michael Menth wrote:
>>In a couple of cases, they have made me notice an even better way 
>>of saying it. But in the first two cases, I prefer the original to 
>>your suggestion. I have said why in my annotation of your 
>>annotations here (mine are in red in the PDF)

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 18 Aug 2011 17:51:40 +0100

Michael,

While making your changes, I noticed one I had missed in Appx B, case b).

BEFORE:
"The PCN-ingress-node places this traffic in a tunnel with a 
PCN-compatible DSCP in the outer header. The PCN-egress zeroes the 
ECN-field before decapsulation."
AFTER:
"The PCN-ingress-node places this traffic in a tunnel with a 
PCN-compatible DSCP in the outer header."

I don't understand why you want this last sentence deleted. It seems 
right to me.

Bob

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 18 Aug 2011 17:53:50 +0100

I think I uploaded the xml to the datatracker - I certainly intended to.

Don't think I had any additional edits, and I agreed with pretty much all
you said to Phil about his comments. He is probably right about clarifying
the types of traffic we define in the appendix (the bit he had to re-explain
to you).

Re your comment RJB 1 in your pdf of Michael's edit: we could alter "revert"
which may confuse some people to "effectively downgrades the packet to Not
Marked", but would be happy to stick with revert if no one else has views.

I also agree with your other comment (not accepting Michael's reworked
paragraph in 4.3).

Toby

From: Bob Briscoe [mailto:[email-masked]] 
Sent: 18 August 2011 15:20
To: Toby Moncaster
Cc: [email-masked]; [email-masked]
Subject: RE: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt

Toby,

If you have any pent up edits since -07, pls send the xml. Otherwise I'm
going to start from the -07.xml, assuming I can find it on your site (or
otherwise the data tracker).

Bob

Bob,

Toby
 
<mailto:[email-masked]> ] On Behalf Of Bob Briscoe
 
Phil,

Content-Language: en-US

 
S1

[RFC5696 <http://tools.ietf.org/html/rfc5696> ] described
how

two PCN>>

future

<<   This document extends the baseline encoding
by

redefining the EXP>>

   This document amends the [RFC5696] encoding
by

redefining the 01

(and a couple of lines earlier where you mention EXP, add that
this

is 01 codepoint)

S2.1

<<   Threshold-marked codepoint:  a
codepoint

 

      have been marked at a

 

      indication from the

 

      Abbreviated to

ThM.>>

 

indicates a packet has been threshold-marked, that is a
packet

that

      has been marked at a

 

      indication from the

 

      Abbreviated to ThM.

[firstly clearer to refer to 'packet' than 'packets', secondly
uses

 

 

<<   Not-marked codepoint:  a codepoint
that

 

      that are not PCN-marked.

Abbreviated to NM.>>

delete 'but'

S3

<< A PCN-node (i.e. a node within a PCN-domain) will
be

configured to

 

   choice of suitable DSCPs.  In Figure 1 'DSCP
n'

indicates such a PCN-

   compatible DSCP.  Within the PCN-domain,
any

packet carrying a PCN-

in

[RFC5559 <http://tools.ietf.org/html/rfc5559> 
].>>

A PCN-node (i.e. a node within a PCN-domain) will be
configured

to

 

   choice of suitable DSCP(s).  In Figure 1 'DSCP
n'

indicates such a PCN-

   compatible DSCP.  Within the PCN-domain,
any

packet carrying a PCN-

   compatible DSCP and with the ECN-field anything
other

 

[DSCPs => DSCP(s). And added phrase in last
sentence]

4.2

 

 

4.3

<< For the full 3-in-1 encoding to apply, any tunnel
endpoints

(IP-in-IP

   and IPsec) within the PCN-domain MUST comply with
the

ECN

   encapsulation and decapsulation rules set out
in

(see

 
 <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#section-4.2> 
Section 4.2
<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#section-4.2>
).  There is one exception to this rule
outlined

next.

 

With one exception (see next paragraph), any tunnel
endpoints

(IP-in-IP

   and IPsec) within the PCN-domain MUST comply with
the

ECN

   encapsulation and decapsulation rules set out
in

(see

 

S5

<< As mentioned in

 

[RFC6040 <http://tools.ietf.org/html/rfc6040> 
].>>

[RFC6040 <http://tools.ietf.org/html/rfc6040> ]. Since
PCN is

a new capability, this is considered a reasonable
requirement.

 

S5.2.3

inconsistency

 

 

 

 <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#appendix-D> 
Appendix D
<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-07#appendix-D>
explains the rationale for the behaviours defined in
this

section.

[i see no reason to worry the average reader with talk
of

inconsistency.]

S5.3

<<   marking is used it should treat ETM
as

 

However it SHOULD raise

s6.1

<< PCN-ingress-

   nodes ensure that any packets entering the
PCN-domain

have the ECN

   field in their outermost IP header set to
the

appropriate PCN

   codepoint. 

 

CHANGE TO "appropriate codepoint" (as it may be appropriate to
set

 

6.2

Thre => there

10

Criticism is misspelt 

Appendix A

 

It wasn't clear to me whether PCN is operating on the
whole

aggregate of classes together, or on each class separately. Or
whether

either is possible.

 

App B

 

 

 

       Broadcast TV

 

 

actions

=> tunnelling

 

 

 

i think it would be helpful to add "The e2e ECN traffic is
not

treated as PCN-traffic" and "The e2e ECN traffic is treated
as

PCN-traffic"

 

<< 

     *  The PCN-ingress places this
traffic

in a tunnel with a PCN-

         compatible DSCP
in

 

         ECN-field
before

decapsulation.

      *  The PCN-ingress
drops

 

         zeros the ECN
field

of all PCN packets.

 

 

     *  The PCN-ingress places this
traffic

in a tunnel with, in the outer header, a PCN-compatible DSCP and
the

ECN-field set to Not-PCN.  The PCN-egress zeroes
the

 

      *  The PCN-ingress drops
CE-marked

packets and otherwise sets the ECN-field to NM, and sets the DCSP to
a

PCN-compatible DSCP [or requires that it's already in such a
DSCP??]. The

PCN-egress zeroes the ECN field of all PCN packets; note this turns
off

e2e ECN.

[note, 'zeroes']

[i'm not sure about the last bullet, is this what you
mean>?]

[BB] Yes

You could also correct

PCN-ingress to PCN-ingress-node throughout the section;
ditto

PCN-egress.

 

      ECT(0) into ECT(1), which would
not

be compatible with the

      (currently experimental) ECN
nonce

[RFC3540 <http://tools.ietf.org/html/rfc3540> 
].>>

Well a PCN-interior-node doesn't know about ECT. Change
to:

Note that a PCN-interior-node may change the ECN-field from 10 to
01

(NM to ThM), which would be interpreted by the e2e ECN as a change
from

ECT(0) into ECT(1) -- hence it would not be compatible with
the

 

App C

<<But

[RFC5129 <http://tools.ietf.org/html/rfc5129> ] was
written

while

stages>>

The 'But' makes it sound like you're updating 5129 (i don't
think

[BB] OK. Delete 'But'.

ECT(0) ->

NM

 

"The above sets of codepoints are required for every
PCN-compatible

DSCP."

[BB] Yup.

 

App D

 

 

<<The behaviour with

 

      ETM is more severe and must never
be

 

      ETM is not a valid marking in
this

case.  >>

The behaviour with only threshold marking keeps to the rule
of

Section 5.2.1 that

      ETM is more severe and must never
be

 

      ETM is not a valid marking in
this

case).  

First bullet

Your argument also means that a ThM should be corrected to
ETM

(since the excess-traffic-metering behaviour depends on ETM marks
on

arriving packets). At the moment it only gets corrected when the
meter

 

But making this correction would require different code
compared

 

Personally i'd just delete the first bullet. If not, make it
the

Thanks

Bob

 

Best wishes
phil
 Philip Eardley   

From: [email-masked] [  <mailto:[email-masked]>
mailto:[email-masked]] On Behalf Of Scott O Bradner
Sent: 31 July 2011 18:38
To: Toby Moncaster
Cc: [email-masked]
Subject: Re: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt

Scott

Toby

-----Original Message-----
From: [email-masked] [  <mailto:[email-masked]>
mailto:[email-masked]] On Behalf Of
Scott O. Bradner
Sent: 30 July 2011 20:40
To: [email-masked]
Subject: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt

 
Scott

Scott Bradner