[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
Hi All,
I think there is now a possible solution to progress this. The confusion
all stemmed from the WG's desire to have a record kept of PCN
experiments which then led to the source of the confusion in the
baseline document's Appendix A.
My proposed solution (based on the comments over the past 3 days) aims
to do two things, firstly to clarify that PCN is an alternative marking
behaviour that Operators can specify for certain DSCPs (without changing
the scheduling or other behaviours), secondly it should recommend 1 (or
more) DSCPs that are currently suitable and should list what we believe
are the criteria for suitability AND/OR explain what we would expect
needed to happen if people wanted to suggest other DSCPs that it could
apply to (either existing or new ones). This second bit is more thorny
and I am not sure I am best placed to do it. I would welcome any offers
of text for that bit...
The end result will be that we have a doc that really makes no IANA
requests, that suggests a suitable DSCP to apply PCN to initially and
that explains what makes that DSCP suitable...
Toby
> -----Original Message-----
> From: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf Of
> toby.moncaster at bt.com
> Sent: 14 August 2009 14:06
> To: lars.eggert at nokia.com; pcn at ietf.org
> Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
>
> Hi Lars,
>
> Sorry not to get back to you earlier - been busy at work so this went
> on
> a back-burner for a few days.
>
> The original intention of having registration was to avoid confusion
> during any early experimental adoption of PCN however that could be
> done
> purely unofficially by having a list of DSCPs on the IETF wiki and
just
> politely asking developers to consult it and add any new ones they are
> using. But there will need in future to be a process to formally
> register certain standards (pool 1) DSCPs as PCN-compatible since this
> effectively replaces ECN as the default behaviour for such DSCPs. So
> my
> suggestion is:
>
> Change the IANA section to say something along the following lines (I
> will get IANA assistance with crafting exact text):
>
> "IANA will be asked to set up a registry of PCN-compatible Diffserv
> codepoints. The decision as to whether to enable PCN for a given pool
1
> codepoint must be made by the appropriate IETF Transport Area Working
> Group (TSVWG?) which will then request IANA to add this to the
> registry."
>
> Clarify at start of A.1 that the decision of which DSCPs to apply PCN
> to
> has to be made by TSVWG and is separate to this document which just
> defines the process and the encoding.
>
> Change the last sentence of A.1 to "IANA will maintain a list of
> PCN-compatible Diffserv Codepoints."
>
> Would this cover things appropriately? I did wonder about asking IANA
> to
> maintain the experimental registry but I am not sure if they are able
> to
> do that sort of thing? If so the following could be added to the IANA
> section:
>
> "During the early stages of adoption it is envisaged that PCN will be
> used experimentally using pool 2 or 3 DSCPs (experimental or local
> use).
> Whilst these DSCPs are not controlled by IANA normally, a request will
> be made to maintain a list of PCN experiments along with the DSCPs
> these
> experiments are using."
>
> Once I get the nod from WG I will release a new version of the I-D
with
> these updates...
>
> Toby
>
> > -----Original Message-----
> > From: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf
Of
> > Lars Eggert
> > Sent: 14 August 2009 12:27
> > To: pcn at ietf.org
> > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
> >
> > Hi,
> >
> > I'm waiting to hear from the authors/WG.
> >
> > Lars
> >
> > On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote:
> >
> > > Hi,
> > >
> > > this document is ready, except for one issue:
> > >
> > > Section 7., paragraph 1:
> > >> This document makes no direct request to IANA. However this
> > > document
> > >> allows for a set of Diffserv Codepoints to be assigned
different
> > > ECN
> > >> semantics within a controlled domain as described in [RFC4774].
> A
> > >> list of such DSCPs will be maintained by the PCN working group.
> > >
> > > DISCUSS: This text isn't aligned with appendix A.1. The text
here
> > > says
> > > "the WG will maintain a list of DSCPs that are OK", while the
> > > beginning of appendix A.1 says "the WG decided to not define
with
> > > which DSCPs PCN can be used" (but then the end of A.1 talks
about
> > > maintaining a list again.) Which is it? If there is to be a
list,
> > > you
> > > need to create an IANA registry, write management procedures for
> it
> > > (see RFC5226) and populate it with some initial values. (WGs are
> > > ephemeral, which is why the PCN WG can't be the maintainer of
> this
> > > list, IANA has to be.) If you want to leave it fully open for
> > > deployments, you need to remove this confusion from the text.
> > >
> > > Lars
> > >
> > >
> > > Nits:
> > >
> > > Section 4., paragraph 3:
> > >> to prevent future compatability issues.
> > >
> > > Nit: s/compatability/compatibility/
> > >
> > >
> > > Section 4.2., paragraph 1:
> > >> that is guaranteeed to be copied down into the inner header
upon
> > >
> > > Nit: s/guaranteeed/guaranteed/
> > >
> > >
> > > Section 6., paragraph 1:
> > >> always copy the CE codepoint from teh outer header into the
> inner
> > >
> > > Nit: s/teh/the/
> > >
> > >
> > > Section 6., paragraph 2:
> > >> header in decapsulation (unless the inner packet is not-ECT).
> > > If an
> > >> operator it is essential that any operator wishing to allow ECN
> to
> > >> exist end-to-end ensures there are no tunnel end-points within
> the
> > >> PCN-domain.
> > >
> > > "If an operator it is essential that any operator..." - wording
> > >
> > >
> > > Section 12., paragraph 0:
> > >> 12. References
> > >
> > > Should be updated; see idnits report.
> > >
> > >
> > > Appendix A., paragraph 2:
> > >> a given PCN-domain is dependant on the nature of the traffic
> > > entering
> > >
> > > Nit: s/dependant/dependent/
> > >
> > > <smime.p7s><ATT00001.txt>
>
> _______________________________________________
> PCN mailing list
> PCN at ietf.org
> https://www.ietf.org/mailman/listinfo/pcn