Subject: Re: [PCN] plan for PCN encodings, now ecn-tunnel is in last call

From: <[email-masked]>
Date: Mon, 5 Jul 2010 17:27:39 +0100

Agree with bob';s proposals, except I don't think we should obsolete the baseline encoding until the new tunnel behaviour is widespread

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of SATOH Daisuke
> Sent: 29 June 2010 09:31
> To: [email-masked]
> Cc: CHAN, Kwok Ho; PCN IETF list
> Subject: Re: [PCN] plan for PCN encodings, now ecn-tunnel is
> in last call
>
>
> Dear Bob, Michael, and all
>
>
> On Tue, 29 Jun 2010 01:34:55 +0200
> Michael Menth <[email-masked]> wrote:
>
> > Hi Bob and all,
> >
> > Bob Briscoe schrieb:
> > > Joe, Daisuke, Toby, Michael, Kwok,
> > >
> > > I writing to you all as co-authors of the various PCN encoding
> > > drafts
> > > and RFCs, and to Kwok as author of the encoding comparison draft.
> > >
> > > I have started this conversation between you all rather than
> > > starting
> > > numerous side conversations between slightly different sets of
> > > co-authors. I have also included the PCN list as there
> are others with
> > > interest in the outcome (not least the chairs). I hope
> that's OK -
> > > otherwise please accept my apologies and feel free to switch to
> > > off-list mode.
> > >
> > > The IETF last call on ietf-tsvwg-ecn-tunnel will end on 6 Jul 10.
> > > Assuming it goes thru without substantive changes, I
> would like to
> > > suggest a plan for how to deal with all the experimental
> PCN encodings
> > > and then to try to update the drafts accordingly before
> the Maastricht
> > > deadline.
> > >
> > > * draft-ietf-pcn-3-in-1-encoding -> add applicability to sm{1} ->
> > > stds
> > > track
> > ok
>
> OK
>
>
> >
> > > * RFC5696 (baseline encoding) -> obsoleted by 3-in-1 encoding{2}
> > On the one hand I like the idea to have only a single relevant
> > encoding.
> > On the other hand I am not 100% sure that baseline encoding
> is no longer
> > needed as it may take some time until new tunnels will be deployed.
> >
> > I also thought that another advantage of baseline might be that it
> > requires only two PCN states so that it requires fewer
> codepoints in the
> > MPLS header. However, the same can be done with 3-in-1
> encoding if only
> > one marking scheme is used. After reading rfc 5129 it seems
> to me that
> > pcn is considered only in the appendix and that only 3-in-1 is
> > considered but baseline is not.  Therefore, when defining a
> necessary
> > adaptation from 3-in-1 to mpls shim, it is possible to define a
> > translation for three and for two used pcn states in that
> document. Hm,
> > has anybody understood me? Am I correct?
> >
>
> As Michael writes, adaptaion from 3-in-1 to mpls shim is necessary.
>
>
>
>
>
>
> > > * draft-ietf-pcn-3-state-encoding -> expt track or expire{3}
> > ok
>
> OK
>
> >
> > > * draft-ietf-pcn-psdm-encoding -> leave to expire?
>
> OK.
>
>
> > ok. I saw some positive comments about psdm. However, I think what
> > people like is rather the implicit probing feather than the
> encoding
> > itself. I'll provide a write-up to separate implicit probing (edge
> > behavior for admission control) from the encoding issue and
> make clear
> > that it equally works with baseline or 3-in-1 encoding.
> >
> > > * draft-satoh-pcn-st-marking -> (expired) -> leave to expire?
> > ok
>
> OK
>
> Best regards,
> Daisuke
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn
>

---

From: "Toby Moncaster" <[email-masked]>
Date: Tue, 6 Jul 2010 10:38:05 +0100

I think that is a sensible compromise... We don't want to be left with an
encoding that doesn't work because vendors haven't adopted the new
tunnelling approach.

One idea I had was to try and incorporate baseline as a limited
functionality or compatibility mode within 3-in-1. Not really had a chance
to think through the implications though (I am currently fixated on conex
and haven't really got back up to speed with PCN).

Toby

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 05 July 2010 17:28
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [PCN] plan for PCN encodings, now ecn-tunnel is in last
> call
> 
> Agree with bob';s proposals, except I don't think we should obsolete
> the baseline encoding until the new tunnel behaviour is widespread
>