Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt

From: "Toby Moncaster" <[email-masked]>
Date: Sun, 10 Jul 2011 16:46:15 +0100

Hi All,

After much change and debate we have finally posted a revised version of the
3-in-1 encoding. Given the fairly significant changes since the document
went through its first WGLC the WGCs may decide it needs another WGLC...

http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-06.txt

http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.html

http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.pdf

http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.xml

http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.unpg

Diffs from version 5:

http://moncaster.com/3-in-1-diff-05--06.html 

Toby

---

From: "Toby Moncaster" <[email-masked]>
Date: Mon, 11 Jul 2011 21:04:47 +0100

Hi All,

There are a couple of nits with this version. Rather than issue a -07
version so soon after the -06 (and so near the deadline) I would rather hold
these to any final revision following the WGLC (if there is another one).

There is also one significant (potentially) outstanding issue, namely
whether it is right to mandate that 01 MUST mean ThM and 11 MUST mean ETM in
all cases. Some people are pushing for a slightly more complicated
formulation where:

.         If both meters are being used to mark traffic, 01 MUST mean ThM
and 11 MUST mean ETM. 

.         If only ETM meter running, 11 MUST mean ETM

.         If only ThM meter running, 01 MUST mean ThM and 11 MAY mean ETM

Not sure if that's the clearest way of expressing it - basically the
argument is if we restrict 11 to never mean ThM you restrict the
applicability of this encoding in networks with pre-RFC6040 tunnels.

This would be an excellent issue to get some discussion time in Quebec.

Toby

From: [email-masked] [mailto:[email-masked]] On Behalf Of Toby
Moncaster
Sent: 10 July 2011 16:46
To: [email-masked]
Subject: Re: [PCN] New Version Notification for
draft-ietf-pcn-3-in-1-encoding-06.txt

Hi All,

 

Diffs from version 5:

Toby

---

From: <[email-masked]>
Date: Tue, 12 Jul 2011 09:33:56 +0100

That's not how I'd put it, although you may illustrate that my suggestion is stupid.
It's more like,

*         If only ThM meter running, then packets are either marked 01 or 11; the same choice MUST be made by all nodes in the PCN-domain; the former choice is the default but the latter MAY be used where a pre-RFC6040 tunnel endpoint exists within the PCN-domain

Maybe this is too complicated and doesn't give enough gain to be worth bothering with, but the text changes would be something like:-

In S4.3
The behaviour of
   PCN-interior nodes in this case is defined in Section 5.2.3.1<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-06#section-5.2.3.1>.
=>

The behaviour of

   PCN-interior nodes in this case is defined in Section 5.2.3.

{new text in brackets below}

"Exception case" refers to S4.3 - this is where a "pre-RFC6040 tunnel endpoint exists

   within a PCN-domain" (and "every PCN-node in the PCN-domain MUST be

   configured so that it never sets the ThM codepoint")

5.2.3.2.  Marking using only the Threshold-meter Function

   The excess-traffic-meter function SHOULD be disabled and MUST NOT
   trigger any packet marking.

{<new/ In normal circumstances the following applies:/new>}
   The PCN-interior node SHOULD raise a management alarm if it receives
   an ETM packet, but the frequency of such alarms SHOULD be limited.

   If the threshold-meter function indicates a need to mark the packet:

   o  the PCN-interior node MUST change NM to ThM;

   o  the PCN-interior node MUST NOT change ETM to any other codepoint.
      It SHOULD raise an alarm as above.

{<new/ In the "Exception case" described in Section 4.3, it is possible for either the excess-traffic-meter or for the threshold-meter to trigger packets to be marked '11'. All PCN-nodes in the PCN-domain MUST be configured with the same choice. The excess-traffic-meter case was described in Section 5.2.3.1. For the threshold-meter case the following rules apply:
   The PCN-interior node SHOULD raise a management alarm if it receives
   an 01 packet, but the frequency of such alarms SHOULD be limited.

   If the threshold-meter function indicates a need to mark the packet:

   o  the PCN-interior node MUST change NM to 11;

   o  the PCN-interior node MUST NOT change 10 to any other codepoint.
      It SHOULD raise an alarm as above.
/new>}

(probably easiest to insert it as a separate sub-section)

phil

From: [email-masked] [mailto:[email-masked]] On Behalf Of Toby Moncaster
Sent: 11 July 2011 21:05
To: 'Toby Moncaster'; [email-masked]
Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt

Hi All,

There are a couple of nits with this version. Rather than issue a -07 version so soon after the -06 (and so near the deadline) I would rather hold these to any final revision following the WGLC (if there is another one).

There is also one significant (potentially) outstanding issue, namely whether it is right to mandate that 01 MUST mean ThM and 11 MUST mean ETM in all cases. Some people are pushing for a slightly more complicated formulation where:

*         If both meters are being used to mark traffic, 01 MUST mean ThM and 11 MUST mean ETM.

*         If only ETM meter running, 11 MUST mean ETM

*         If only ThM meter running, 01 MUST mean ThM and 11 MAY mean ETM

Not sure if that's the clearest way of expressing it - basically the argument is if we restrict 11 to never mean ThM you restrict the applicability of this encoding in networks with pre-RFC6040 tunnels.

Toby

From: [email-masked] [mailto:[email-masked]] On Behalf Of Toby Moncaster
Sent: 10 July 2011 16:46
To: [email-masked]
Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt

Hi All,

After much change and debate we have finally posted a revised version of the 3-in-1 encoding. Given the fairly significant changes since the document went through its first WGLC the WGCs may decide it needs another WGLC...

Diffs from version 5:

Toby

---

From: <[email-masked]>
Date: Thu, 14 Jul 2011 09:43:59 +0100

Ok, Bob has persuaded me my suggestion is stupid.
It creates ambiguity. There is no demand for this capability. So let's forget about it.
Phil/

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 12 July 2011 09:34
To: [email-masked]; [email-masked]
Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt

In S4.3
The behaviour of

The behaviour of

phil

Hi All,

Toby

Hi All,

Diffs from version 5:

Toby

---

From: "Toby Moncaster" <[email-masked]>
Date: Sat, 16 Jul 2011 11:55:08 +0100

OK, that means the current document is ready to ship apart from a couple of
minor nits (one typo and one where I used the phrase "single marking
schemes" where I meant to say "schemes only using one PCN marking")

I am not sure if either of the other authors is in Quebec, if so perhaps
they can summarise the state of the document to the WG and seek guidance on
whether we need to get another WGLC or not.

Toby

From: [email-masked] [mailto:[email-masked]] 
Sent: 14 July 2011 09:44
To: [email-masked]; [email-masked]
Subject: RE: [PCN] New Version Notification for
draft-ietf-pcn-3-in-1-encoding-06.txt

It creates ambiguity. There is no demand for this capability. So let's
forget about it.

Phil/

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 12 July 2011 09:34
To: [email-masked]; [email-masked]
Subject: Re: [PCN] New Version Notification for
draft-ietf-pcn-3-in-1-encoding-06.txt

That's not how I'd put it, although you may illustrate that my suggestion is
stupid.

It's more like,

.         If only ThM meter running, then packets are either marked 01 or
11; the same choice MUST be made by all nodes in the PCN-domain; the former
choice is the default but the latter MAY be used where a pre-RFC6040 tunnel
endpoint exists within the PCN-domain

Maybe this is too complicated and doesn't give enough gain to be worth
bothering with, but the text changes would be something like:-

In S4.3

The behaviour of

   PCN-interior nodes in this case is defined in Section 5.2.3.1
<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-06#section-5.2.3.
1> . 

=>

The behaviour of

{new text in brackets below}
"Exception case" refers to S4.3 - this is where a "pre-RFC6040 tunnel
endpoint exists
   within a PCN-domain" (and "every PCN-node in the PCN-domain MUST be
   configured so that it never sets the ThM codepoint")

 

{<new/ In the "Exception case" described in Section 4.3, it is possible for
either the excess-traffic-meter or for the threshold-meter to trigger
packets to be marked '11'. All PCN-nodes in the PCN-domain MUST be
configured with the same choice. The excess-traffic-meter case was described
in Section 5.2.3.1. For the threshold-meter case the following rules apply:

/new>}

phil

Hi All,

Toby

Hi All,

 

Diffs from version 5:

Toby

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 25 Jul 2011 11:53:38 +0100

Toby,

For the benefit of the list, I did a thorough 
read through and I produced an update, but we 
decided not to post before the deadline.

I would argue that we should post this update for 
WGLC rather than merging it with any other 
requests for update from the WGLC. There are 
significant improvements to clarity, which will 
otherwise not be reviewed. In particular, both 
the following changes are fairly major reworkings of text:

* Clarified that each operator not the IETF chooses which DSCP(s)
are PCN-compatible, and made it unambiguous that only PCN-nodes
recognise that PCN-compatible DSCPs enable the 3-in-1 encoding.
* Corrected the final para of "Rational for Different Behaviours
in Schemes with Only One Marking" (new heading for Appendix D)

Bob

At 11:55 16/07/2011, Toby Moncaster wrote:
>Content-Type: multipart/alternative;
>         boundary="----=_NextPart_000_0015_01CC43AF.3751FE80"
>Content-Language: en-gb
>
>OK, that means the current document is ready to 
>ship apart from a couple of minor nits (one typo 
>and one where I used the phrase “single marking 
>schemes” where I meant to say “schemes only using one PCN marking”)
>
>I am not sure if either of the other authors is 
>in Quebec, if so perhaps they can summarise the 
>state of the document to the WG and seek 
>guidance on whether we need to get another WGLC or not.
>
>Toby
>
>It creates ambiguity. There is no demand for 
>this capability. So let’s forget about it.
>Phil/
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of [email-masked]
>Sent: 12 July 2011 09:34
>That’s not how I’d put it, although you may 
>illustrate that my suggestion is stupid.
>It’s more like,
>
>·         If only ThM meter running, then 
>packets are either marked 01 or 11; the same 
>choice MUST be made by all nodes in the 
>PCN-domain; the former choice is the default but 
>the latter MAY be used where a pre-RFC6040 
>tunnel endpoint exists within the PCN-domain
>
>Maybe this is too complicated and doesn’t give 
>enough gain to be worth bothering with, but the 
>text changes would be something like:-
>
>In S4.3
>The behaviour of
>    PCN-interior nodes in this case is defined 
> in 
> <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-06#section-5.2.3.1>Section 
> 5.2.3.1.
>=>
>
>The behaviour of
>
>“Exception case” refers to S4.3 – this is where 
>a “pre-RFC6040 tunnel endpoint exists
>
>    within a PCN-domain” (and “every PCN-node in the PCN-domain MUST be
>
>    configured so that it never sets the ThM codepoint”)
>
>
>
>{<new/ In the “Exception case” described in 
>Section 4.3, it is possible for either the 
>excess-traffic-meter or for the threshold-meter 
>to trigger packets to be marked ‘11’. All 
>PCN-nodes in the PCN-domain MUST be configured 
>with the same choice. The excess-traffic-meter 
>case was described in Section 5.2.3.1. For the 
>threshold-meter case the following rules 
>apply:   The PCN-interior node SHOULD raise a management alarm if it receives
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Toby Moncaster
>Sent: 11 July 2011 21:05
>There are a couple of nits with this version. 
>Rather than issue a -07 version so soon after 
>the -06 (and so near the deadline) I would 
>rather hold these to any final revision 
>following the WGLC (if there is another one).
>
>There is also one significant (potentially) 
>outstanding issue, namely whether it is right to 
>mandate that 01 MUST mean ThM and 11 MUST mean 
>ETM in all cases. Some people are pushing for a 
>slightly more complicated formulation where:
>
>·         If both meters are being used to mark 
>traffic, 01 MUST mean ThM and 11 MUST mean ETM.
>·         If only ETM meter running, 11 MUST mean ETM
>·         If only ThM meter running, 01 MUST mean ThM and 11 MAY mean ETM
>
>Not sure if that’s the clearest way of 
>expressing it – basically the argument is if we 
>restrict 11 to never mean ThM you restrict the 
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Toby Moncaster
>Sent: 10 July 2011 16:46
>To: [email-masked]
>After much change and debate we have finally 
>posted a revised version of the 3-in-1 encoding. 
>Given the fairly significant changes since the 
>document went through its first WGLC the WGCs 
>may decide it needs another WGLC...
>
><http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-06.txt>http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-06.txt
><http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.pdf>http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.pdf
><http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.unpg>http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.unpg
>
>
>Diffs from version 5:
>
><http://moncaster.com/3-in-1-diff-05--06.html>http://moncaster.com/3-in-1-diff-05--06.html 
>
>
>Toby
>_______________________________________________
>PCN mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design