Re: Draft-ietf-tewg-diff-te-reqts-01.txt

[Jim Boyle <jimpb@nc.rr.com>]

--*** Requirements Draft ***----

Well, here's my perspective on this section.  In effect, it states that
the network should perform in a way that I would like.  However I think
that it is a bit too structural, and mechanistic, for my tastes.

So rewording that whole section (2.5), I'd suggest

   "A source LSR only sets up an LSP if bandwidth appears available
    along the path at that class.  An intermediate node along the path
    accepts the LSP if the required bandwidth is available at this
    class. This may cause preemption as allowed through local
    configuration or default behavior, though this can not be
    pre-determined from remote hosts such as the source LSR".

If you look in the Scenarios in Section 1, a lot of the functionality
spelled out in Section 2 might be a bit over spelled out, with this
section and class-types and inter-class-type premption rules being one
example.

Folks have posted to the list that there is no reason to preempt across
class-types, and insist that class-types follow some strict pecking order
of preemptability (and their classes thus fall in line between these).

Here's an example where you might want the bandwidth of one "class-type"
to preempt that in another.  Say you have two class-types, call them VPN-A
and VPN-B.  In each, they run "working" LSPs at priority 2 and "protect"
LSPs at 4.  In this case, you might not want the protect LSPs of VPN-A to
preempt the working ones of VPN-B, in fact you'd probably like the working
LSPs of VPN-B to preempt the protect LSPs in VPN-A.  Of course
technically you could consider this as four classes as well.

--*** Fade to draft-boyle-tewg-ds-nop-00.txt ***---

In case you were wondering exactly how one might create a similar
solution with my draft..  Pick four "priorities" at random, X1, X2,
X3, X4 (say {7,2,1,4}) Now as a matter of network policy.  VPN-A
working -> X1 = 7, VPN-A protect -> X2 = 2, VPN-B working -> X3 = 1,
VPN-B protect -> X4 = 4 (of course in practice one could use something
more intuitive and aligned with a default behavior).  On the routers,
state that the max-bandwidth per link is Y (e.g. "600 Mbs", "2.5 Gbs",
etc..)  and that Y - X1 - X3 >= 0 and Y - X1 - X2 - X3 - X4 >= 0 (see
draft for better config suggestions, e.g. groupings).  Now each router
will advertise what is available at X1, X2, X3, X4.  When one has an
LSP to setup, just check the topology at that priority and set it up.

Jim



On Mon, 13 Aug 2001 Nihal.Samaraweera@vf.vodafone.co.uk wrote:

> Hi Francois,
>
> I have been reading the requirement document and would like to make
> following comments regarding the detailed requirements (section 2).
>
> According to the section 2.5.2, the high priority traffic in one class type
> must have the ability to pre-empt low priority traffic in other class type.
>
>
> As I think, this doesn't maintain the priority requirements for diffserv
> classes. For example, this allows an AF traffic trunk to pre-empt an EF
> traffic trunk that has been assigned a lower preemption priority.  In other
> wards, it would be very difficult to implement preemption across class types
> without defining a relationship between preemption priority and the class
> priority.
>
> Summarizing/copying the requirement describe in section 2.2,
>
> (a) If a high priority class does not use up all of its bandwidth, the
>      next highest priority class should be able to make use of this unused
>      bandwidth.
>
> (b) If a lower priority class (e.g. AF) used some of the unused
>      bandwidth of a higher priority class (e.g. EF), the high priority
>      class should be able to reclaim this bandwidth where necessary.
>
> (c) lower priority class-Types (e.g., Best Effort) should not be
>      completely starved by higher priority classes.
>
> (d) Highest priority classes, should only be routed away from their
>      shortest path when they would exceed their own bandwidth
>      constraints. They should not be routed away from their shortest
>      path because of lower priority classes.
>
> Requirements a, b and d are related to the preemption requirements in
> section 2.5. Could this be addressed, if the service provider implements a
> unique preemption priority for each class type (or diffserv class)
> consistently within the administration domain (as a best common practice).
>
> Regarding the solution for configuring the bandwidth constrains,
> I.e., P(N-1)% of CT(N-1), P(N-2)% of CT(N-1)+CT(N-2),.......
>
> While I agree with your solution, I think that you need only to configure a
> minimum bandwidth allocation for a traffic class (to address requirement c)
> and a maximum allocation to satisfy the delay jitter requirements.   Is this
> a simplified configuration?
>
> Final point,
>
> Both RSVP-TE and CR-LDP (with draft-ietf-mpls-crlsp-modify-03.txt) allow the
> ingress router to modify the bandwidth of an existing LSP.  Although this
> draft addresses the capability of creating LSP dynamically, this does not
> address the requirement of dynamic modification of LSP to cater the current
> demand of the bandwidth over an existing LSP.  For example, a VPN user may
> request the SP to increase the bandwidth requirement between two sites for a
> given traffic class.
>
> Thanks,
>
> Nihal Samaraweera.
> Senior Systems Engineer,
> Core Network Development (Technology),
> Vodafone Limited, UK.
> TEL:		+44 1635 685927
> Mobile:	+44 7884 230941
>