Re: [PCN] 3-in-1 document

[Toby Moncaster <[e-mail]>]

On Mar 15 2012, Pete Resnick wrote:

>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.

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

>
>> 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.

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.
>>    
>
>So, let me skip down to question 3, because on this point I think there 
>is some confusion:
>
>> 3) if RFC5696 has become not recommended, should it be declared historic,
>> 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).
>
>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.

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...

>
>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 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.
>
>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.

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

>
>pr
>
>