Subject: [PCN] 3-in-1: no threshold-marking in pre-RFC6040 PCN domains

From: Michael Menth <[email-masked]>
Date: Sun, 10 Jul 2011 23:10:26 +0200

Hi Toby and all,

I think we should clearly point out that threshold marking in 
pre-RFC6040 networks is not possible with 3-in-1 encoding which is a 
fundamental difference to baseline encoding. Section 4.3 could be 
improved in this respect (shorter and clearer):

"The 3-in-1 encoding is applicable in situations where two marking 
behaviours
are being used in the PCN-domain. The 3-in-1 encoding can also be used with
only one marking behaviour, in which case one of the codepoints MUST NOT be
used throughout the PCN-domain (see Section 5.2.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] (see Section 4.2). There is one
exception to this rule outlined next.

It may not be possible to upgrade every pre-RFC6040 tunnel endpoint within a
PCN-domain. In such cirsumstances a limited version of the 3-in-1 encoding
can still be used but only under the following stringent condition. If any
pre-RFC6040 tunnel endpoint exists within a PCN-domain then every 
PCN-node in
the PCN-domain MUST be configured so that it never sets the ThM codepoint.
The behaviour of PCN-interior nodes in this case is defined in Section
5.2.3.1. In all other situations where legacy tunnel endpoints might be
present within the PCN domain, the 3-in-1 encoding is not applicable."

->

"3-in-1 is applicable if all tunnel decapsulators comply with RFC6040. It is
able to support excess-traffic marking and threshold marking. A subset 
of the
encoding may also be used in pre-RFC6040 networks. Then, the ThM codepoint
MUST NOT be used. As a consequence, it is possible to use excess-traffic
marking in such networks but not threshold marking. This is a difference to
the obsoleted RFC5696."

Regards,

     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: <[email-masked]>
Date: Mon, 11 Jul 2011 08:51:40 +0100

I dont mind some re-wording, however I'm not sure about your proposal.

- the obsoleted 5696 doesn't mention 'threshold marking'
- 5696 doesnt allow 01 marking - it leaves it open to be defined elsewhere for EXP use
- I think 5696 should be briefly mentioned in the Intro, but not talked about in the main part of the doc (ie the part that defines the standard should just define the std)
-  with 3in1 in a pre-6040 environemnt, ie where only the 11 encoding is used and not 01. Although the obvious case is that this is set by the excess traffic meter, I see no reason in principle why this shouldn't be set by the threshold meter

Best wishes,
phil
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Menth
Sent: 10 July 2011 22:10
To: [email-masked]
Subject: [PCN] 3-in-1: no threshold-marking in pre-RFC6040 PCN domains

Hi Toby and all,

->

Regards,

     Michael

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

---

From: Michael Menth <[email-masked]>
Date: Mon, 11 Jul 2011 10:06:32 +0200

Hi Phil,

> -  with 3in1 in a pre-6040 environemnt, ie where only the 11 encoding is used and not 01. Although the obvious case is that this is set by the excess traffic meter, I see no reason in principle why…

Currently the document does not allow it. See
http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-06#section-5.2.3.2
If we want to leave such a hole open, we must explicitly say that. 
Otherwise it's forbidden. I don't say that we need to do it, we just 
need to know what we standardize and clearly communicate that.

Regards,

     Michael