[Ieprep] proposed charter

[Curtis Villamizar <[e-mail]>]

Two people sent me private email pointing to the email message with
the proposed charter.

http://www1.ietf.org/mail-archive/web/ieprep/current/msg02421.html

Thanks.

Seems mostly reasonable to me.  One paragraph seems open ended and may
be a source of trouble for other reasons.

  If there is an existing group that can extend a protocol or
  mechanism, IEPREP will generate only a requirements document for
  those groups to evaluate. If there is not an existing group that can
  extend a protocol or mechanism, IEPREP will prepare requirements and
  discuss the extension of that protocol/mechanism or
  protocols/mechanisms within IEPREP.

This is a promise to liason with anybody and everbody that intends to
work in this area and to step back and let that other group do the
protocol work.  The IESG favors (with good reason) WG charters that
propose to do work rather than WG charters that propose to sit back
and watch the ITU do work in that area.  A good example (and closely
related to this sort of work) where the result coming from the ITU was
not at all useful is the ITU QoS requirements work in the mid to late
1990s.  This may be looking too much like more of the same.

This is off topic for a charter discussion but please bear with me.
If anyone responds to this part of the email, consider changing the
subject.  I'm getting way out ahead of the "requirements first, then
solutions" process but the way I envision ETS working is as follows.

SIP and microflow RSVP control flow must preceed traffic flow.  SIP is
seen only at ingress and egress.  Microflow RSVP is seen only by
SIP/RSVP gateways at ingress, egress, and provider boundaries.  Within
a provider's core, both the microflow RSVP control traffic and the
actual traffic is typically carried within MPLS signaled with RSVP/TE,
although this is entirely up to the provider (they are free to use
edge-to=-edge microflow RSVP if they prefer).  If MPLS/TE is used then
the reservation reflects the sum of microflow RSVP reservations but
the microflow reservations are seen only at provider boundaries.
SIP/uflow-RSVP gateway addresses can/should be assigned such that at
provider boundaries the control traffic can be diverted to dedicated
SIP/RSVP capable hardware rather than put this function on the
provider IP peering routers.

Traffic is marked with DSCP marking across providers but within
providers is typically carried in MPLS.  If the number of priorities
is small (possibly true for early deployments) then it may simplify
deployment.  There are only a few IP-Prec values available (some are
already used for network control traffic).  EF has only one value at
this point.  AF has 4 AF classes with 3 drop preferences in each and
seems to be the most likely candidate but leaves no room for AF
services of less importance than ETS such as commercial VPN.  If the
number of priorities is small it may be sufficient to use a DSCP to
EXP mapping.  Otherwise, a full Diffserv-TE implementation may be
needed.

As long as the number of priority/preemption classes remains too open
ended, the mapping onto DSCP and Diffserv-TE remains uncertain.  For
example, there has to be a strong technical justification for five
priority classes, not just "because ITU specified five" before there
is much of a chance for a set of new DSCP values to be assigned as
anything other than experimental.

Note that there is nothing wrong with using a set of experimental DSCP
values, even in early deployments.  If multiple providers use these a
set of DSCP values can be assigned in the non-experimental space with
identical semantics and then later the experimental DSCP depricated
when no longer used (and then reused by the next grand experiment).
If no one ever uses some of the values assigned as experimental, then
they can be depricated without replacements.  Writing new code is work
but changing to a new set of constants is not very hard.  You know -
running code and all that...

Any effort which requires the whole world to agree before getting
started will never get started.

Curtis

_______________________________________________
Ieprep mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ieprep