[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Draft-ietf-tewg-diff-te-reqts-01.txt
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