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

From: <[email-masked]>
Date: Mon, 13 Aug 2001 11:01:16 +0100

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

---

From: Jim Boyle <[email-masked]>
Date: Mon, 13 Aug 2001 22:03:13 -0400 (EDT)

--*** 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