Subject: Re: [PCN] I-D Action:draft-ietf-pcn-encoding-comparison-03.txt

From: Bob Briscoe <[email-masked]>
Date: Mon, 08 Nov 2010 11:01:57 +0800

Georgios,

Do you think we should ask for WGLC on this now?

Bob

At 18:43 22/10/2010, Georgios Karagiannis wrote:
>Hi all
>
>A new version (03) of the draft-ietf-pcn-encoding-comparison has just
>been submitted. We (and especially Kwok) implemented severeal
>modifications compared to version 02, please see below:
>
>http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcn-encoding-comparison-03
>
>Best regards,
>Georgios
>
>
>On 10/22/2010, "[email-masked]" <[email-masked]>
>wrote:
>
> >A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> >This draft is a work item of the Congestion and Pre-Congestion 
> Notification Working Group of the IETF.
> >
> >
> >       Title           : Pre-Congestion Notification Encoding Comparison
> >       Author(s)       : K. Chan, et al.
> >       Filename        : draft-ietf-pcn-encoding-comparison-03.txt
> >       Pages           : 38
> >       Date            : 2010-10-21
> >
> >Pre-congestion notification (PCN) is a link-specific and load-
> >dependent packet marking mechanism for Differentiated Services
> >networks.  The packet markings are evaluated by egress nodes of PCN
> >domains and the result is used for admission control and flow
> >termination decisions.  Two different types of markings have been
> >defined.  This document gives a summary of the marking requirements,
> >the constraints to encode them in the current IP header (version 4
> >and above), and it explains why the PCN WG currently supports
> >different encoding schemes for PCN marking.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-pcn-encoding-compari 
> son-03.txt
> >
> >Internet-Drafts are also available by anonymous FTP at:
> >ftp://ftp.ietf.org/internet-drafts/
> >
> >Below is the data which will enable a MIME compliant mail reader
> >implementation to automatically retrieve the ASCII version of the
> >Internet-Draft.
>_______________________________________________
>PCN mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: <[email-masked]>
Date: Fri, 12 Nov 2010 17:10:46 +0000

(on-list)

My mental model is that we have the Baseline encoding as Standards track and 3-in-1 as Experimental track. This doesn't need an update to the baseline (nor its obsoletion). 

The Baseline has words about restrictions /guidelines on Experimental encodings so that they're compatible with the baseline. If 3-in-1 is standards track, then those guidelines would be wrong - in fact it would then be hard to see how to allow any Experimental encodings.

This leads me to think there are (only) 2 possibilities:-

* Baseline RFC5696 + Experimental 3-in-1 (which does not update baseline)
* Baseline + 3-in-1 as a new Standards track doc

I'm strongly in favour of the first option, since this requires no more work (or almost none).

This discussion also makes me think that 3-in-1 should be moved through WG last call, *then* the encoding comparison has its final updates & is WGLC. 

-----Original Message-----
From: Briscoe,RJ,Bob,XVR9 BRISCORJ R 
Sent: 12 November 2010 15:59
To: Eardley,PL,Philip,DEE1 R
Cc: [email-masked]
Subject: RE: [PCN] I-D Action:draft-ietf-pcn-encoding-comparison-03.txt

Phil,

BTW, do we need to be off-list? Feel free to cc reply to PCN list.

Yours are all good points.

1/ I think the comparison draft should also make it clear that 
choosing encodings for stds track does not preclude also allowing 
experimental track ones. For instance, neither baseline nor 3-in-1 
support e2e ECN or ECMP. So if someone wishes to experiment with 
them, we're not stopping them.

2/ There is still the question of whether we should:
* produce a single RFC that OBSOLETES baseline and describes both 
baseline and 3-in-1 in one RFC.
* or take 3-in-1 through to RFC as an UPDATE to baseline.

Personally I think the former would be less confusing for future 
implementers. But it's not how we've currently written 3-in-1.

Bob

At 05:19 08/11/2010, [email-masked] wrote:
>Basically i think yes, but:
>
>- now bob's tunnelling is done and we'll only go forward with one 
>exptal extension [if i understand right], this should come clearer 
>as a conclusion.
>- note [check throughout], rfc 3260 the correct terminology seems to 
>be: DSField - 6 bits
>
>- Fig 6, i know this got updated several times. Suggest check this 
>is the final versionin the soon-to-be-rfc
>
>- section 4 says PCN WG produces 4 different pcn encodings. My 
>impression is that we're not going forward with all 4 but only 2 
>[baseline + 3-in-1] will be rfcs. Therefore this section needs some adjustment:
>- in the intro
>- suggest leave the bulk of the section untouched
>- add a short section 5, which is the "final answer" - ie the 
>baseline + 1 extended encoding, and the key points why they were 
>chosen [minimise use of DSCPs, allow non-PCN traffic, etc]. I think 
>it would be very useful for a reader to be able to skip to the final 
>answer and the summary of Why these 2 encodings were chosen.
>
>-----Original Message-----
>From: Georgios Karagiannis [mailto:[email-masked]]
>Sent: 08 November 2010 10:51
>To: Briscoe,RJ,Bob,XVR9 BRISCORJ R
>Cc: Eardley,PL,Philip,DEE1 R
>Subject: RE: [PCN] I-D Action:draft-ietf-pcn-encoding-comparison-03.txt
>
>
>  Hi Bob
>
>It is okay with me! Hoever, Phil had previously some comments on the
>comparison draft,
>and I would like to konow if he is satsified with this version!
>
>Best regards,
>Georgios
>
>
> > -----Original Message-----
> > From: Bob Briscoe [mailto:[email-masked]]
> > Sent: maandag 8 november 2010 4:02
> > To: Georgios Karagiannis
> > Cc: [email-masked]
> > Subject: Re: [PCN] I-D
> > Action:draft-ietf-pcn-encoding-comparison-03.txt
> >
> > Georgios,
> >
> > >http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcn-encoding-co
>mparison-0
> > >3
> > >
> > >Best regards,
> > >Georgios
> > >
> > >

---

From: "Toby Moncaster" <[email-masked]>
Date: Sat, 13 Nov 2010 10:00:46 -0000

Inline 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 12 November 2010 17:11
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [PCN] I-D Action:draft-ietf-pcn-encoding-comparison-03.txt
> 
> (on-list)
> 
> My mental model is that we have the Baseline encoding as Standards
> track and 3-in-1 as Experimental track. This doesn't need an update to
> the baseline (nor its obsoletion).

Although at some point in future we would need to address moving 3-in-1 to
STDs track... 

> 
> The Baseline has words about restrictions /guidelines on Experimental
> encodings so that they're compatible with the baseline. If 3-in-1 is
> standards track, then those guidelines would be wrong - in fact it
> would then be hard to see how to allow any Experimental encodings.
> 

you /could/ choose the second option. That would still need to address
legacy cases where Bob's new RFC hasn't been implemented (I guess 3-in-1
would be presented as an extension with a MUST to implement the updated
tunnelling). But as I say above, at some point in future, if 3-in-1 proves
successful it will need to be moved to STDs track anyway so there will still
be work to be done. On the other hand creating a merged document will take
ages. 

How about this as a possibility: 3-in-1 is altered so it has 2 modes of
operation:

_Limited Mode_ is the same as baseline and is used when the tunnelling isn't
there. This would set out the encoding and state that it is the same as
RFC5696.

_Full Mode_ is the full 3-in-1. Tunnelling becomes a MUST, etc.

Limited and Full modes can't be run in the same PCN-domain (or can they? I
assume not...).

That way, if it is a success it should be pretty easy to subsequently
obsolete baseline encoding and move the new document to STDs track?

> 
> This discussion also makes me think that 3-in-1 should be moved through
> WG last call, *then* the encoding comparison has its final updates & is
> WGLC.

I'm sort of tempted to agree - originally the encoding comparison was meant
to present all the encoding options along with pros and cons to allow a
choice to be made. Baseline sort of obsolete that, so now encoding
comparison has to act as a historical record of how we chose the encodings
we did. If 3-in-1 is going to be a significant and viable alternative to
baseline then it needs a thorough treatment in the comparison document.

Toby

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 15 Nov 2010 12:34:17 +0100

Hi Phil, Hi all

> * Baseline RFC5696 + Experimental 3-in-1 (which does not 

It also makes sense to me, to first move 3-in-1 
through WG last call, and then the encoding comparison 
has its final updates & is WGLC!

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: vrijdag 12 november 2010 18:11
> Cc: [email-masked]; [email-masked]
> Subject: RE: [PCN] I-D 
> My mental model is that we have the Baseline encoding as 
> Standards track and 3-in-1 as Experimental track. This 
> doesn't need an update to the baseline (nor its obsoletion). 
> 
> The Baseline has words about restrictions /guidelines on 
> Experimental encodings so that they're compatible with the 
> baseline. If 3-in-1 is standards track, then those guidelines 
> would be wrong - in fact it would then be hard to see how to 
> allow any Experimental encodings.
> 
> This discussion also makes me think that 3-in-1 should be 
> moved through WG last call, *then* the encoding comparison 
> has its final updates & is WGLC. 
> 
> Subject: RE: [PCN] I-D 
> 1/ I think the comparison draft should also make it clear 
> that choosing encodings for stds track does not preclude also 
> allowing experimental track ones. For instance, neither 
> baseline nor 3-in-1 support e2e ECN or ECMP. So if someone 
> wishes to experiment with them, we're not stopping them.
> 
> * produce a single RFC that OBSOLETES baseline and describes 
> both baseline and 3-in-1 in one RFC.
> Personally I think the former would be less confusing for 
> future implementers. But it's not how we've currently written 3-in-1.
> 
> 
> Bob
> 
> >Subject: RE: [PCN] I-D 
> > > > >       Filename        : 
> draft-ietf-pcn-encoding-comparison-03.txt
> > > > >       Pages           : 38
> > > > >       Date            : 2010-10-21
> > > > >