Subject: [PCN] FW: New Version Notification for draft-ietf-pcn-3-in-1-encoding-04

From: "Toby Moncaster" <[email-masked]>
Date: Tue, 11 Jan 2011 09:37:16 -0000

I have released an updated version of the 3-in-1 encoding reflecting the recent publication of Bob's tunnelling RFC (RFC6040).

Txt at: http://www.ietf.org/id/draft-ietf-pcn-3-in-1-encoding-04.txt
HTML at: http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-04.html
XML at: http://www.ietf.org/id/draft-ietf-pcn-3-in-1-encoding-04.xml
UNPG at: http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-04.unpg 

Diffs at:

http://moncaster.com/PCN/PCN-3-in-1-diff-03--04.html 

NEXT STEPS FOR WG:

We now need to decide the next steps for the document. Originally this was menat to be one of a set of experimental extensions to RFC5696 baseline encoding. However that was changed with the publication of RFC6040.

Given that RFC6040 is standards track the suggestion from the authors is that this document should become a standards track extension to baseline encoding. That seems to give the greatest flexibility to operators:

If you know your PCN-domain is fully compliant with RFC6040 and you want to use both marking behaviours you choose 3-in-1 encoding

If the PCN-domain uses legacy tunnels you have to use baseline encoding

If the PCN-domain only uses threshold marking you use baseline encoding

If (in future) an edge behaviour emerges calling for just excess-traffic-marking then you use either baseline or 3-in-1 encoding.

If the WG agree then the next version of this will be standards track, and I believe this is probably in a fit state for WGLC...

Toby 

> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[email-masked]]
> Sent: 11 January 2011 09:24
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: New Version Notification for draft-ietf-pcn-3-in-1-encoding-04
> 
> 
> A new version of I-D, draft-ietf-pcn-3-in-1-encoding-04.txt has been
> successfully submitted by Toby Moncaster and posted to the IETF
> repository.
> 
> Filename:	 draft-ietf-pcn-3-in-1-encoding
> Revision:	 04
> Title:		 Encoding 3 PCN-States in the IP header using a
> single DSCP
> Creation_date:	 2011-01-11
> WG ID:		 pcn
> Number_of_pages: 13
> 
> Abstract:
> The objective of Pre-Congestion Notification (PCN) is to protect the
> quality of service (QoS) of inelastic flows within a Diffserv domain.
> On every link in the PCN domain, the overall rate of the PCN-traffic
> is metered, and PCN-packets are appropriately marked when certain
> configured rates are exceeded.  Egress nodes provide decision points
> with information about the PCN-marks of PCN-packets which allows them
> to take decisions about whether to admit or block a new flow request,
> and to terminate some already admitted flows during serious pre-
> congestion.
> 
> This document specifies how PCN-marks are to be encoded into the IP
> header by re-using the Explicit Congestion Notification (ECN)
> codepoints within a PCN-domain.  This encoding builds on the baseline
> encoding of RFC5696 and provides for three different PCN marking
> states using a single DSCP: not-marked (NM), threshold-marked (ThM)
> and excess-traffic-marked (ETM).  Hence, it is called the 3-in-1 PCN
> encoding.
> 
> 
> 
> The IETF Secretariat.

---

From: Michael Menth <[email-masked]>
Date: Tue, 11 Jan 2011 10:54:28 +0100

A small addition ...

Am 11.01.2011 10:37, schrieb Toby Moncaster:
> If you know your PCN-domain is fully compliant with RFC6040

... or does not use tunnels inside the PCN domain ...
(I think that's right? I hope we've captured that?)

> and you want to use both marking behaviours you choose 3-in-1 encoding
>
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn

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

---

From: Steven Blake <[email-masked]>
Date: Sat, 22 Jan 2011 20:56:15 -0500

On Tue, 2011-01-11 at 09:37 +0000, Toby Moncaster wrote:

> I have released an updated version of the 3-in-1 encoding reflecting
> the recent publication of Bob's tunnelling RFC (RFC6040).
> 
> HTML at:
> http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-04.html
> UNPG at:
> http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-04.unpg 
> 
> Diffs at:
> 
> We now need to decide the next steps for the document. Originally this
> was menat to be one of a set of experimental extensions to RFC5696
> baseline encoding. However that was changed with the publication of
> RFC6040.
> 
> Given that RFC6040 is standards track the suggestion from the authors
> is that this document should become a standards track extension to
> baseline encoding. That seems to give the greatest flexibility to
> operators:
> 
> If you know your PCN-domain is fully compliant with RFC6040 and you
> want to use both marking behaviours you choose 3-in-1 encoding
> 
> If (in future) an edge behaviour emerges calling for just
> excess-traffic-marking then you use either baseline or 3-in-1
> encoding.
> 
> If the WG agree then the next version of this will be standards track,
> and I believe this is probably in a fit state for WGLC...

I am happy to start a WGLC on this draft, but the WG needs to decide
whether or not to move it to standards track (assuming that is ok with
the ADs).

Any comments?

Regards,

// Steve

---

From: <[email-masked]>
Date: Mon, 24 Jan 2011 10:00:35 +0000

I'm happy with this approach, providing it won't delay it. In other words, happy to be guided by the ADs advice

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Steven Blake
Sent: 23 January 2011 01:56
To: Toby Moncaster
Cc: 'pcn'
Subject: Re: [PCN] FW: New Version Notification for draft-ietf-pcn-3-in-1-encoding-04

Any comments?

Regards,

// Steve

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 28 Jan 2011 09:49:21 +0000

Hi all

I also agree with this proposal!

Best regards,
Georgios