Subject: [PCN] 3-in-1: add some text on partially PCN-capable tunnels

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

Hi Toby and all,

I see an issue with tunnels starting outside PCN domains and ending 
inside PCN domains. I believe this should be clarified in an appendix to 
3-in-1 because this touches the coexistence between PCN and ECN.

RFC5559 says: http://tools.ietf.org/html/rfc5559#section-4.7

    Potential issues arise for a "partially PCN-capable tunnel", ie,
    where only one tunnel endpoint is in the PCN-domain:

    1.  The tunnel originates outside a PCN-domain and ends inside it.
        If the packet arrives at the tunnel ingress with the same
        encoding as used within the PCN-domain to indicate PCN-marking,
        then this could lead the PCN-egress-node to falsely measure pre-
        congestion.

    2.  The tunnel originates inside a PCN-domain and ends outside it.
        If the packet arrives at the tunnel ingress already PCN-marked,
        then it will still have the same encoding when it's decapsulated,
        which could potentially confuse nodes beyond the tunnel egress.

    In line with the solution for partially capable Diffserv tunnels in
    [RFC2983], the following rules are applied:

    o  For case (1), the tunnel egress node clears any PCN-marking on the
       inner header.  This rule is applied before the "copy on
       decapsulation" rule above.

    o  For case (2), the tunnel ingress node clears any PCN-marking on
       the inner header.  This rule is applied after the "copy on
       encapsulation" rule above.

I believe the first bullet gives a wrong recommendation for case (1). If 
a CE-marked packet is tunneled, the rule clears that CE-mark and the 
packet may leave the PCN domain without CE-mark. This violates RFC4774. 
However, this issue could be solved by dropping such packets, but that 
would be a nasty solution because finding them might be tricky. 
Therefore, I'd be rather in favor to say that such tunnels SHOULD/MUST 
not be used.

An appendix in the 3-in-1 doc could correct this issue.

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 09:07:53 +0100

I don't see why 3in1 is the right place to deal with this. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Menth
Sent: 10 July 2011 22:11
To: [email-masked]
Subject: [PCN] 3-in-1: add some text on partially PCN-capable tunnels

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:43:55 +0200

> I don't see why 3in1 is the right place to deal with this.
The encoding doc is the right place to deal with the tunneling issues 
because we redefine the ECN field in this doc. Therefore, we must assure 
that the redefinition complies with RFC4774. Partially PCN-capable 
tunnels may violate RFC4774. That is why the encoding document is the 
right place for this issue. It's about the same reason why deal with the 
coexistence of ECN and PCN marking in the appendix.

Makes sense?

Regards,

     Michael

---

From: <[email-masked]>
Date: Mon, 11 Jul 2011 17:04:12 +0100

Doesnt make sense to me.

Firstly, if 5559 is wrong then let's do an Erratum. It is not really pertinent to this draft. Come to think of it, ecn considerations are not very relevant either.  Suggest we have one draft that does one thing.

Secondly, the issue anyway is complicated, since 5559 is correct for 6040 tunnels. And in your scenario there are various possibilities for how to handle. 5559 may also be misleading - the "rules" are supposed to mean "do something that has this effect, although not necessarily by this method". Anyway, it needs some thought. Not only for us writing, but also for reviewers & iesg - another reason to keep it separate. It will undoubtedly hold up the progress of the 3in1 draft whilst we try and get this right. Apart from this issue we seem ready to WG last call, so suggest we keep separate and progress the encoding - 'strike whilst the iron is hot'

Phil/

-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: 11 July 2011 09:44
To: Eardley,PL,Philip,DES8 R
Cc: [email-masked]
Subject: Re: [PCN] 3-in-1: add some text on partially PCN-capable tunnels

Makes sense?

Regards,

     Michael