Subject: [PCN] 3-in-1 document

From: David Harrington <[email-masked]>
Date: Thu, 15 Mar 2012 13:14:15 -0400

Hi,

The IESG has a few questions.

1) Since the edge behaviors have now been moved to Experimental, and
3-in-1 deals with the edge behaviors, should 3-in-1 also be Experimental?

2) (for additional information to help IESG understand) Has 3-in-1 been
implemented? Has it been used in real-world environments? Should this be
published as Experimental until it is clear it works?

3) if RFC5696 has become not recommended, should it be declared historic,
possibly independent of the status of the 3-in-1 draft?

--
David Harrington
Director, Transport Area
Internet Engineering Task Force (IETF)
[email-masked]
+1-603-828-1401

---

From: <[email-masked]>
Date: Thu, 15 Mar 2012 17:35:18 +0000

Couple of quick comments:

On 1)
I seem to remember that when RFC5696 was published, there was discussion about the status of this & it was agreed it should be standards track. Since 3-in-1 replaces 5696, it too should be standards track.

http://tools.ietf.org/html/draft-ietf-pcn-encoding-comparison-09#section-5 explains how we got to 3-in-1 replacing 5696. 

Incidentally, the edge behaviours moved from Informational to Experimental (not from standards track to experimental), so I don't see why this should prompt any change in status of 3-in-1.

On 3)
3-in-1 obsoletes rfc5696. If the normal practice is to declare obsoleted rfcs historic, then suggest we do that; if not, then don't.
If the 3-in-1 draft is not approved then rfc5696 is not obsolete.
If the 3-in-1 draft is experimental then rfc5696 is not obsolete - i think the 3-in-1 draft needs to be re-written as an extension of the baseline (and incidentally this is very probably non-trivial to write & non-trivial for the reader to understand)

Best wishes
phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Harrington
Sent: 15 March 2012 17:14
To: <[email-masked]>
Subject: [PCN] 3-in-1 document

Hi,

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

---

From: Toby Moncaster <[email-masked]>
Date: Thu, 15 Mar 2012 17:39:14 +0000

> 3-in-1 deals with the edge behaviors, should 3-in-1 also be Experimental?

Before I say anything else can I challenge your sentence: 3-in-1 does not deal with the edge behaviours, it's the other way round. 3-in-1 deals with how PCN marks are conveyed between the pcn-nodes and the pcn-egress-nodes. The edge behaviours are about what the PCN system does with those marks. 

With that in mind I STRONGLY feel 3-in-1 should remain as standards track. The aim of having the 2 edge behaviours as experimental (I believe) is to establish which is best (and as Phil says, they were intended to be informational).

a) we will have to make it standards track when/if one of the edge behaviours succeeds

b) To make 3-in-1 experimental will require extensive re-writing. It has already been through the pain of us deciding that to make it workable it has to obsolete RFC5696. If we have it as experimental, then it is an experiment that is incompatible with the current standard (RFC5696) and so we have to require anyone running any form of PCN to NOT follow a current standard, and instead implement another experiment - messy at best, and definitely confusing.

c) Architecturally, the encoding is a fundamental building block, as are the marking and metering (RFC5670). The edge behaviours are applications of the fundamental blocks… 

> published as Experimental until it is clear it works?

In what way could it NOT work? This isn't all that difficult… The only issues are what happens when an implementor fails to correctly implement the standard. Frankly, that is out of the remit of the IETF - we have designed this to be safe in every possible misconfiguration, so I can't see that an experiment can show anything...

> possibly independent of the status of the 3-in-1 draft?

Its status HAS to depend on that of the 3-in-1. If it is to become historic (as opposed to obsolete) then, in the absence of 3-in-1 being a standard we end up with PCN having NO encoding (given experimental carries no weight). 

I applaud the IESG trying to control the number of RFCs in the standards track, but the main point of control has to be in the chartering of the working groups.

Toby

---

From: Pete Resnick <[email-masked]>
Date: Thu, 15 Mar 2012 15:14:14 -0500

Hi Toby,

Being one of the IESG folks that asked the question, I have a couple of 
followup questions/comments. Other IESG members may^h^h^h almost 
certainly do have different thoughts than I :-) , but this discussion 
helps my thinking a lot.

On 3/15/12 12:39 PM, Toby Moncaster wrote:

> ...I STRONGLY feel 3-in-1 should remain as standards track. The aim of having the 2 edge behaviours as experimental (I believe) is to establish which is best (and as Phil says, they were intended to be informational).
>    

OK, this was an important point that I didn't understand, and I do think 
it needs a mention in the two experimental documents: You are saying 
that the experiment is about picking which of the two should be used. 
That's not clear in those two documents now, and a little text would 
help greatly. That cleanly separates the issue of the status of the 
3-in-1 document from the other two.

> a) we will have to make it standards track when/if one of the edge behaviours succeeds

Interesting. And on this point: The WG believes ("proposed") that the 
approach in 3-in-1 is the correct approach ("standard"), and will be, 
whichever of the two experimental documents turns out to be used, 
correct? That would make me very comfortable with Proposed Standard.

> b) To make 3-in-1 experimental will require extensive re-writing. It has already been through the pain of us deciding that to make it workable it has to obsolete RFC5696. If we have it as experimen…

So, let me skip down to question 3, because on this point I think there 

> Its status HAS to depend on that of the 3-in-1. If it is to become historic (as opposed to obsolete) then, in the absence of 3-in-1 being a standard we end up with PCN having NO encoding (given exp…

So, the question was slightly different from my perspective: Let's make 
believe that the 3-in-1 effort has not yet started. Is the current use 
of PCN in 5696 a bad idea? Should people not be doing it at all and 
should just wait for a new way to do it? If so, then making 5696 
Historic (independent of what is to be done with 3-in-1) is the right 
thing to do.

If the answer is, no, people are quite reasonable to continue to use 
5696 until 3-in-1 gets out the door, at which point we think 3-in-1 is 
the better thing to do, then I think I agree with your assessment.

> I applaud the IESG trying to control the number of RFCs in the standards track, but the main point of control has to be in the chartering of the working groups.

So here's the funny thing: I am someone who thinks that we make too many 
things Experimental (or worse, BCP) and that *more* of our work belongs 
on the Standards Track (and progressed!). The only confusion for me (and 
I suspect others) was why the -sm and -cl documents were experiments, 
and that led to my questions about the 3-in-1 document. If what you say 
is correct (that the experiment is to decide between -sm and -cl), I 
think that clarifies the other question quite well. I'm a big proponent 
of having the WG (and the IETF writ large) decide how these things 
should go, but it's the IESG's responsibility to make sure that we all 
understand the basis on which the decision is made and that there's 
consensus on that.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Toby Moncaster <[email-masked]>
Date: 15 Mar 2012 20:48:29 +0000

On Mar 15 2012, Pete Resnick wrote:

>> ...I STRONGLY feel 3-in-1 should remain as standards track. The aim of 
>> having the 2 edge behaviours as experimental (I believe) is to establish 
>> which is best (and as Phil says, they were intended to be 
>> informational).
>>    
>

I have always believed that PCN is designed in a modular fashion. We have a 
set of core concepts (metering, marking, encoding), an architecture and 
then 2 possible approaches for edge behaviours. So on that basis, yes, the 
status of this encoding is a separate issue to the status of the edge 
behaviours

>correct? That would make me very comfortable with Proposed Standard.

That is my understanding of why it was decided to move the two edge 
behaviours to experimental - however I would have to defer to Tom to 
confirm or deny that

>
>> b) To make 3-in-1 experimental will require extensive re-writing. It 
>> has already been through the pain of us deciding that to make it 
>> workable it has to obsolete RFC5696. If we have it as experimental, then 
>> it is an experiment that is incompatible with the current standard 
>> (RFC5696) and so we have to require anyone running any form of PCN to 
>> NOT follow a current standard, and instead implement another experiment 
>> - messy at best, and definitely confusing.
>>    
>
>> Its status HAS to depend on that of the 3-in-1. If it is to become 
>> historic (as opposed to obsolete) then, in the absence of 3-in-1 being a 
>> standard we end up with PCN having NO encoding (given experimental 
>> carries no weight).
>

RFC5696 is the only reasonable approach in the world that existed before 
RFC6040 became a draft standard.

It was designed to work (and so still does work), but it has the major 
issue of preventing the CL edge behaviour from becoming a standard.

Now that RFC6040 has been published we believe that the new encoding is a 
better option. It is a complete superset of RFC5696, it takes advantage of 
the new tunneling rules, it is "safe" and it allows CL to be a viable edge 
behaviour. We believe (based on simulations) that SM performs significantly 
less well than CL. However SM has a lower implementation barrier for 
vendors...

>the better thing to do, then I think I agree with your assessment.

I would certainly be happy for RFC5696 to continue until 3-in-1 is 
published - the original intent was to have them co-existing, but during 
the process of refining 3-in-1 we actually realised that they can't 
co-exist after all.

>
>> I applaud the IESG trying to control the number of RFCs in the 
>> standards track, but the main point of control has to be in the 
>> chartering of the working groups.
>

That sounds a very sensible view. I am certainly not a fan of the idea that 
you make something experimental as a sort of back-door to getting it to 
RFC.

Toby

---

From: Tom Taylor <[email-masked]>
Date: Thu, 15 Mar 2012 20:08:41 -0400

I think the experiment is to choose between the two behaviours. I never 
previously thought of it that way because the set of potential edge 
behaviours was supposed to be open-ended, but these two are what we have 
ended up with for the moment at least.

On 15/03/2012 4:48 PM, Toby Moncaster wrote:
>> Being one of the IESG folks that asked the question, I have a couple
>> of followup questions/comments. Other IESG members may^h^h^h almost
>>> ...I STRONGLY feel 3-in-1 should remain as standards track. The aim
>>> of having the 2 edge behaviours as experimental (I believe) is to
>>> establish which is best (and as Phil says, they were intended to be
>>> informational).
>>
>> OK, this was an important point that I didn't understand, and I do
>> think it needs a mention in the two experimental documents: You are
>> saying that the experiment is about picking which of the two should be
>> used. That's not clear in those two documents now, and a little text
>> would help greatly. That cleanly separates the issue of the status of
>> the 3-in-1 document from the other two.
>
> I have always believed that PCN is designed in a modular fashion. We
> have a set of core concepts (metering, marking, encoding), an
> architecture and then 2 possible approaches for edge behaviours. So on
> that basis, yes, the status of this encoding is a separate issue to the
> status of the edge behaviours
>
>>
...

---

From: David Harrington <[email-masked]>
Date: Thu, 15 Mar 2012 23:01:45 -0400

Hi,

Is the goal to choose between the two and only standardize one?
I was of the impression both might be standardized and the choice was a
deployment decision based on environmental considerations.
Was I wrong on that point?

---

From: <[email-masked]>
Date: Fri, 16 Mar 2012 08:39:33 +0100

Hi Dave,

you are correct. Am MPLS domain probably is not able to spend more than one codepoint
for ECN/PCN functions. That's why SM behaviours remain to be useful. In pure IP
domains, CL may be used.

My understanding of all that is that the edge behaviours are experimental, as they
involve signaling, policy decisions and so on. Complexity, if you want.

The marking behaviour specified by 3-in-1 is simpler and I agree with others, this
can be implemented and it should be implemented the way specified. To me, 3-in-1 is
a building block which can be used even if the edge behaviours see no implementation
at all. That of course would require different standardised edge or end system
behaviours (the paket markings need to be interpreted correctly).

The edge behaviours contain useful and important information besides signaling and
policy decisions. So I think parts of what's specified there is useful, even if they
are never deployed.

Regards, Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Harrington
Sent: Friday, March 16, 2012 4:02 AM
To: Tom Taylor; [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] 3-in-1 document

Hi,