RE: Is the advertisement (IGP) of available BW at each pre-emptio n le vel is a DS-TE- requirement ?

[neil.2.harrison@bt.com]

Hi Francois, you wrote 14 November 2001 09:38:

NH=> 2nd, largest BW packing of 'path entities' is the most efficient way to
do things if all path entities have the same survivability attribute.  I can
imagine a case of large(r) L-LSP carrying BE traffic and a small(er) E-LSP
carrying VPN traffic.......if I have an availability SLA to meet for the VPN
LSP, then irrespective of the size of the BE LSP I ought to restore the VPN
traffic before I even consider the BE traffic.


FLF=> Perhaps, we could add a 3rd example based on your above scenario with
something like this.

"Yet another Service Provider may elect to configure the following in order
to (i) ensure that Premium Data LSPs are never driven away from their
shortest path because of Best-Effort LSPs while (ii) optimize global network
resource utilization by favoring placement of large LSPs first:
-       all large size Premium Data LSPs to preemption priority 0
-       all small size Premium Data LSPs to preemption priority 1
-       all large size Best-Effort LSPs to preemption priority 2
-       all small size Best-Effort LSPs to preemption priority 3"

Is that in line with the scenario you described?

NH=> Sort-of, but not quite.......the key point was actually the 1st item
that you snipped.  So I have re-inserted it here:
"1st, there is no relationship between a packets up-state forwarding (QoS)
requirements and its 'importance' (vis-a-vis its need to survive over some
other packet, in either the same or different DS class)....DS classes simply
do not give this information.  For example, using LDP and like-DS-class
merging across  VPN populations allows no control over per VPN topology
survivability.  This is a problem IMO."

If you look at what I have written here there is no attempt made to
associate Voice, Data or BE classifications with a survivability metric (for
the reasons I alluded to above).  Further, voice in VPN_X may be mission
critical and in another VPN_Y it may not.  Likewise, or vice-versa, some
data applications.  If I were a VPN customer I would not be happy to learn
that the probability of my traffic surviving a failure was an
indeterministic function of all other VPN/other traffic of class_Z active at
the time, and in the region of, a failure.  I would simply want my VPN
traffic in total to survive (irrespective of its DS classifications)
according to some contract I had with the SP.

Now whilst this does not immediately address what you were discussing, it is
an important factor when LDP and VPNs are considered....since unless you
have the ability to manipulate the 'survivability attribute' of an LSP
entity irrespective of some arbitrary 'voice/data/BE' badge you can't really
start to address the problem (note that I am talking about VPNs here, not
some public service offerings which can be aggregated).

So, with LDP and like-DS-class merging across VPNs we have an intractable
problem IMO.  If however one used E-LSPs and associated an 'effective BW'
and 'survivability' attribute with that LSP now you can start to address the
issue meaningfully, ie the object that is being prioritised for restoration
is the LSP, not the pkts therein which as I noted you can't rank in
survivability needs anyway.

regards, Neil